2021-04-01 00:15:51 <omni> when you follow the git log link http://git.alpinelinux.org/cgit/aports/log/?h=v3.13.4 in the release notes you're 301 redirected to https://git.alpinelinux.org/aports/log/
2021-04-01 00:38:57 <otlabs> hi ppl
2021-04-01 01:00:24 <halosghost> sup
2021-04-01 01:01:19 <otlabs> all good
2021-04-01 01:01:31 <otlabs> and you?
2021-04-01 01:03:39 <otlabs> got some trouble packaging $subpackage-libs and do not know what is wrong
2021-04-01 01:05:39 <otlabs>  /usr/bin/abuild: cd: line 2377: can't cd to /home/builder/aports/testing/rav1e/pkg/rav1e-libs: No such file or directory
2021-04-01 01:54:16 <Shiz> omni: seems like it didn't install anything then
2021-04-01 01:54:34 <Shiz> to the libs subpackage install dir
2021-04-01 01:55:07 <omni> they left?
2021-04-01 01:56:41 <Shiz> alas
2021-04-01 01:56:45 <Shiz> sorry for the mishighlight
2021-04-01 01:57:58 <omni> no worries
2021-04-01 01:58:29 <omni> I beleive it's !19985
2021-04-01 05:01:41 <ikke> mbuffer fails on armhf / armv7. I believe it's because they are built at the same time, and one test is trying to allocate more then half the memory
2021-04-01 06:55:01 <ncopa> morning
2021-04-01 06:55:11 <ncopa> maybe disable the test that eats the memory
2021-04-01 07:25:04 <ncopa> ceph build is broken
2021-04-01 07:25:21 <ncopa> 194bdb909ede4372ab095cbf7c7ac8196bfe761a
2021-04-01 07:25:25 <ncopa> +_py3_sitelib="$(find /usr/lib -iname "site-packages")"
2021-04-01 07:26:18 <ncopa> interesting things happens when there are more than a single "site-packages", forexample if you have had python2 packages installed at some point
2021-04-01 07:54:32 <omni> hmm.. how much RAM does the armv7 CI builder have compared to the arm* builders?
2021-04-01 07:59:55 <omni> I'm going on a hunch that something else is going on..
2021-04-01 08:05:46 <omni> mbuffer warns that it's allocating more than half of available memory on the x86 builder too, but not on x86_64
2021-04-01 08:07:52 <ikke> I believe 32G
2021-04-01 08:09:00 <HRio> can you have a look on !19930 and !19931 ?
2021-04-01 08:10:09 <HRio> works fine for a few days in testing here
2021-04-01 08:56:14 <omni> ikke: they hit SSIZE_MAX, but why only the armv7 and armhf builders and not x86 too? and why no (warning of) trying to allocate half of that on neither of the archs in CI?
2021-04-01 08:56:41 <ikke> Not sure
2021-04-01 09:00:46 <omni> I don't think it's because they're built at (roughly) the same time since it's a short test and they seem to've been built ~2min apart
2021-04-01 09:02:14 <ikke> Ok, it was just a guess because they are on the same host
2021-04-01 09:04:14 <omni> first make (test) create an uncompressed tar archive of the mbuffer source, that shouldn't be too large, then creates a file with an md5 checksum (with openssl) for the test.tar archive
2021-04-01 09:04:22 <omni> then the first test is ./mbuffer -i test.tar -p10 | ./mbuffer -q -P 90 | openssl md5 > test0.md5
2021-04-01 09:05:09 <omni> where, on 32bit archs, both processes say mbuffer: warning: allocating more than half of available memory
2021-04-01 09:05:52 <omni> on the builders
2021-04-01 09:06:11 <omni> and on the armv7 & armhf builders go mbuffer: fatal: Cannot address so much memory (16777216*160=2684354560>2147483647).
2021-04-01 09:07:44 <omni> mbuffer-20210328/settings.c: fatal("Cannot address so much memory (%lld*%d=%lld>%lld).\n",Blocksize,Numblocks,Blocksize*(long long)Numblocks,(long long)SSIZE_MAX);
2021-04-01 09:16:38 <ncopa> how does Blocksize end up that big?
2021-04-01 09:18:55 <omni> right?
2021-04-01 10:06:52 <ncopa> i think its a compiler bug
2021-04-01 10:12:54 <omni> on the builders but not CI-builders?
2021-04-01 10:15:01 <ncopa> i can reproduce it in my lxc env
2021-04-01 10:15:06 <ncopa> its super weird
2021-04-01 10:18:26 <ncopa> no.. i think i was tricked by reusing a global var in my debug printf
2021-04-01 10:33:58 <MartijnBraam> hello, it seems like changes between 4.2.0 and 4.1.0 of tiff on the various branches of alpine are creating quite a mess
2021-04-01 10:34:32 <MartijnBraam> since 4.1.0 -> 4.2.0 changes some things that makes apps segfault if they use certain tiff tags and the apps that depend on in need a rebuild
2021-04-01 10:48:52 <ikke> hmm, why would a rebuild fix it?
2021-04-01 10:49:07 <ikke> https://abi-laboratory.pro/index.php?view=timeline&l=libtiff
2021-04-01 10:49:14 <ikke> very little soname changes (2 additions)
2021-04-01 10:49:29 <ikke> symbols changes*
2021-04-01 10:57:31 <MartijnBraam> the symbols didn't change, but one of the functions takes a variable number of arguments and they changed the number of arguments for one call
2021-04-01 10:57:44 <MartijnBraam> so it segfaults if you don't rebuild
2021-04-01 10:58:45 <MartijnBraam> (at least alpine didn't cherry pick the breaking changes on top of 4.1.0 but didn't update the internal version constants)
2021-04-01 11:03:38 <ikke> so offically libtiff should have bumped the soname?
2021-04-01 11:04:20 <MartijnBraam> I think so, not sure what the rules are but it breaks at least
2021-04-01 11:04:42 <ikke> Me neither, but it seems an ABI breaking change
2021-04-01 11:06:08 <ikke> These packages depend on tiff: https://tpaste.us/ejyV
2021-04-01 11:07:12 <MartijnBraam> it's ony an issue when the applications use the specific call that changed, which is a call for DNG related stuff so it won't be used by most dependencies
2021-04-01 11:07:31 <MartijnBraam> at least megapixels is affected :P
2021-04-01 11:08:02 <MartijnBraam> rawtherapee probably
2021-04-01 11:08:15 <MartijnBraam> darktable
2021-04-01 11:09:21 <ikke> ok
2021-04-01 11:09:32 <ikke> Any way to get a list of affected programs, then?
2021-04-01 11:10:42 <ncopa> MartijnBraam: so they broke the ABI
2021-04-01 11:10:59 <MartijnBraam> it's basically all software that uses the TIFFTAG_CFAPATTERN constant
2021-04-01 11:11:07 <ncopa> thsy should have changed the soname
2021-04-01 11:11:17 <ncopa> s/thsy/they/
2021-04-01 11:11:17 <alpine-meetbot> ncopa meant to say: they should have changed the soname
2021-04-01 11:11:39 <ncopa> should be reported upstream
2021-04-01 11:11:44 <MartijnBraam> yeah, I guess that means soname rebuilds would've been done automagically?
2021-04-01 11:12:02 <ikke> not automatically, but it would have been more visible
2021-04-01 11:12:15 <ikke> someone would still need to bump the pkgrel on the affected packages
2021-04-01 11:12:18 <ncopa> we wouldnt push it with without rebuild with soname change
2021-04-01 11:12:34 <MartijnBraam> right
2021-04-01 11:12:48 <ncopa> the soname is supposed to change when there are ABI breaking changes to prevent things like this
2021-04-01 11:18:46 <ncopa> oh, its worse... the 4.2.0 release was a security fixes release
2021-04-01 11:18:54 <ncopa> this is bad
2021-04-01 11:18:57 <MartijnBraam> yeah isn't it fun
2021-04-01 11:19:16 <MartijnBraam> also alpine has already done the 4.1.0 -> 4.2.0 -> 4.1.0 -> 4.2.0 thing
2021-04-01 11:19:24 <MartijnBraam> and is now going for an encore on stable
2021-04-01 11:19:45 <ikke> lol
2021-04-01 11:20:34 <ncopa> do  you have any references? with the mentioned ABI breaking changes?
2021-04-01 11:22:51 <Ariadne> ncopa: do you know who runs the current CVE bot?
2021-04-01 11:23:03 <ncopa> CVE bot?
2021-04-01 11:23:10 <Ariadne> the thing that opens the bug reports on gitlab
2021-04-01 11:23:13 <Ariadne> about the CVEs
2021-04-01 11:23:18 <Ariadne> i... assume that is a bot
2021-04-01 11:23:24 <Ariadne> and not like a person manually opening it
2021-04-01 11:23:35 <ncopa> its not a bot :)
2021-04-01 11:24:02 <Ariadne> what the actual fuck
2021-04-01 11:24:16 <Ariadne> i mean, i appreciate their dedication
2021-04-01 11:25:11 <Ariadne> but i am surprised to learn this
2021-04-01 11:27:48 <MartijnBraam> there's only this basically: https://gitlab.com/libtiff/libtiff/-/blob/master/ChangeLog#L922
2021-04-01 11:33:37 <Hello71> I assumed it wasn't a bot on the basis that the filed bugs actually make sense and aren't garbage security scanner output
2021-04-01 11:34:07 <Ariadne> Hello71: there's enough data in the security feeds to generate those reports
2021-04-01 11:34:15 <Hello71> regarding tiff and sonames, I think this is what symbol versioning is supposed to be for
2021-04-01 11:34:25 <Ariadne> symbol versioning is evil
2021-04-01 11:34:40 <Hello71> Ariadne: aren't their filed bugs filtered somehow
2021-04-01 11:35:10 <Hello71> it doesn't seem to be "all high cvss scores" which is what the crappy scanners use
2021-04-01 11:39:19 <Ariadne> the NVD feed has not just scores but trait data like "0day exploit known to be in the wild," "remotely exploitable," etc
2021-04-01 11:39:53 <Ariadne> so if you filter on the right traits, you can find the security issues that matter
2021-04-01 11:40:25 <Ariadne> the system i am designing matches based on source package and a configurable set of traits
2021-04-01 11:46:58 <Hello71> hm, ok
2021-04-01 11:47:15 <Hello71> I thought that data was not that reliable
2021-04-01 11:52:22 <Ariadne> well, CVSS scores are not really that reliable, imo
2021-04-01 11:52:37 <Ariadne> the vector string is though
2021-04-01 11:53:00 <Ariadne> assuming the issue reporter fills it out correctly
2021-04-01 11:53:39 <Ariadne> but our current system has that problem too, as the security reports, while processed by hand, are not processed by a security engineer
2021-04-01 17:10:57 <maxice8> !20000
2021-04-01 17:14:16 <mps> !40000
2021-04-01 17:14:27 <mps> ;)
2021-04-01 17:19:32 <ikke> Ariadne: would your sollution replace secdb?
2021-04-01 17:21:22 <Ariadne> no
2021-04-01 17:21:32 <Ariadne> i mean, eventually
2021-04-01 17:21:35 <Ariadne> but not immediately
2021-04-01 17:22:03 <Ariadne> the plan is to keep the secfixes notations in the APKBUILD, but we will likely rewrite the extraction of those notations as part of this
2021-04-01 17:22:30 <Ariadne> i believe you mentioned that there was edge cases with it
2021-04-01 17:22:42 <ikke> Reason why I'm asking is this
2021-04-01 17:22:45 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/secdb/-/merge_requests/2
2021-04-01 17:22:47 <ikke> yes
2021-04-01 17:22:50 <ikke> due to lua
2021-04-01 17:23:07 <ikke> lua cannot differentiate between [] and {}
2021-04-01 17:24:56 <Ariadne> yep
2021-04-01 17:25:01 <Ariadne> i'll write a new extractor in python
2021-04-01 17:25:09 <Ariadne> i need to add additional keywords anyway
2021-04-01 17:25:32 <Ariadne> e.g. secfixes-cpe-match-origin: "foo" for cases where our source packages don't match upstream
2021-04-01 19:11:35 <Ariadne> skarnet: i'm not sure that its worth arguing with that person
2021-04-01 19:11:45 <Ariadne> skarnet: i looked at his other posts and he's basically a concern troll
2021-04-01 19:17:30 <L1Cafe> How are you creating the AMIs?
2021-04-01 19:17:47 <L1Cafe> https://alpinelinux.org/cloud/
2021-04-01 19:17:57 <ikke> L1Cafe: mcrute is doing that for us
2021-04-01 19:18:28 <L1Cafe> Maybe they can elaborate, I'd be interested in looking into it and seeing if there's room for improvement
2021-04-01 19:19:03 <ikke> L1Cafe: the goal is to generalize it more
2021-04-01 19:20:11 <L1Cafe> For adapting it to other clouds, right ikke ?
2021-04-01 19:20:35 <ikke> yes
2021-04-01 19:21:16 <skarnet> Ariadne: I just wanted to correct the record, I have no intention of engaging any further.
2021-04-01 19:22:03 <Ariadne> sure just thought i would mention it :P
2021-04-01 19:24:40 <omni> haha, I saw now that I hadn't looked closely at !19785 after squashing, that I had created a patch file with the same name and similar content as one I had removed because it wasn't used (the test had worked for a couple of releases?)
2021-04-01 19:24:59 <omni> uh, no, !18785
2021-04-01 19:25:18 <omni> why do the keys move around sometimes?
2021-04-01 19:25:50 <ikke> what keys?
2021-04-01 19:26:43 <omni> the ones I'm pushing to type words and such
2021-04-01 19:26:53 <ikke> no clue
2021-04-01 19:27:25 <omni> some call it "keyboard alignment error"
2021-04-01 19:28:32 <omni> since I rarely look them, they may jump around without me noticing, untill I push the big one to the right
2021-04-01 19:59:00 <ekhas> how do i compile with gcc6?
2021-04-01 20:04:22 <afontain_> well, alpine doesn't have gcc6 packaged, IIRC
2021-04-01 20:04:45 <afontain_> postmarketOS do though, for compatibility reasons
2021-04-01 20:04:52 <afontain_> why do you need gcc6 for ?
2021-04-01 20:05:30 <ekhas> gcc6 is in pkgs
2021-04-01 20:06:24 <Ariadne> ekhas: export CC="gcc-6"
2021-04-01 20:06:27 <ekhas> trying to compile palemoon patched for 3.8 and abandoned since
2021-04-01 20:06:45 <Ariadne> export CXX="g++-6"
2021-04-01 20:06:46 <Ariadne> etc
2021-04-01 20:07:09 <ekhas> tried export CC=gcc-6 didn't work
2021-04-01 20:07:14 <Ariadne> you need both
2021-04-01 20:07:19 <ekhas> i build it with abuild
2021-04-01 20:07:27 <Ariadne> ok
2021-04-01 20:07:36 <Ariadne> well you need to put that in your APKBUILD
2021-04-01 20:07:42 <afontain_> did you set it in the APKBUILD?
2021-04-01 20:07:54 <ekhas> no how do i do taht?
2021-04-01 20:08:13 <halosghost> add that as a line
2021-04-01 20:08:19 <halosghost> an APKBUILD is just a shell script
2021-04-01 20:08:33 <Ariadne> also, gcc6 will be dropped eventually.  it's just there to provide a bootstrap path for java
2021-04-01 20:09:08 <ekhas> i'll build it now and hopefully the binary will work in later version
2021-04-01 20:19:02 <ekhas> how do i add g++6? says libstdc++10 breaks 6 and g++10 breaks 6
2021-04-01 20:21:42 <ekhas> removed gcc but abuild adds it again
2021-04-01 20:25:10 <ikke> It would only add it as a dependency
2021-04-01 20:25:41 <ekhas> what is a dep of?
2021-04-01 20:25:57 <ekhas> g++6 installs w/out g++6
2021-04-01 20:26:04 <ekhas> sry
2021-04-01 20:26:07 <ikke> show your deps + makedepends
2021-04-01 20:26:18 <ekhas> gcc6 installs w/out g++6
2021-04-01 20:27:02 <ekhas> i try to add by hand
2021-04-01 20:27:43 <Ariadne> i guess gcc6 needs to have a provides= for gcc
2021-04-01 20:27:54 <ikke> g++6 depends on gcc
2021-04-01 20:27:59 <Ariadne> but i do not really want to do a rebuild of gcc6 because i suspect it may FTBFS
2021-04-01 20:28:20 <Ariadne> ikke: yes, this is the problem i ran into when i planned to introduce gcc-11 to testing
2021-04-01 20:28:49 <ikke> Ariadne: would that not be a problem for 3.14?
2021-04-01 20:28:57 <ikke> if it ftbfs?
2021-04-01 20:29:04 <Ariadne> ikke: i guess we will find out :)
2021-04-01 20:29:09 <ikke> heh
2021-04-01 20:29:46 <ekhas> i have diskless system and just rebooted to start over
2021-04-01 20:30:21 <Ariadne> i think you would be better off figuring out why pale moon does not build with gcc 10
2021-04-01 20:30:32 <ekhas> freshly rebooted g++6 won'
2021-04-01 20:30:38 <ekhas> won't get added
2021-04-01 20:30:53 <ekhas> i tried gcc10
2021-04-01 20:31:34 <ekhas> says bad_alloc does not name type in namespace std
2021-04-01 20:32:04 <ekhas> gcc doesn't add g++6
2021-04-01 20:32:40 <Ariadne> need to add #include <new> to those files
2021-04-01 20:32:47 <Ariadne> that will get you std::bad_alloc
2021-04-01 20:34:05 <ekhas> there's some else
2021-04-01 20:34:14 <ekhas> lemme try compile it with gcc now
2021-04-01 20:37:43 <ikke> I cannot even install g++6 on edge
2021-04-01 20:37:51 <ikke> due to conflicts
2021-04-01 20:38:05 <ekhas> i'm on 13 same
2021-04-01 20:38:20 <ekhas> gcc6 installs tho
2021-04-01 20:40:02 <ekhas> compiling it with gcc as is
2021-04-01 20:40:14 <ekhas> will take some time to get to those errors
2021-04-01 20:46:58 <ekhas> this is the palemoon aport https://github.com/tanertas/aports/tree/palemoon/testing/palemoon
2021-04-01 20:47:43 <ekhas> built fine on 3.8
2021-04-01 21:04:05 <ekhas> ok the errors are bad_alloc and nothrow_t not found in std
2021-04-01 21:08:46 <ekhas> and a ton of warnings like dynamic exception specifications deprecated in c++11
2021-04-01 21:23:28 <Ariadne> CXXFLAGS="-std=gnu++98"
2021-04-01 21:24:37 <ekhas> ok lemme try
2021-04-01 21:29:03 <ekhas> piling
2021-04-01 21:52:20 <ekhas> same thing bad_alloc and nothro_t in namespace std do not name a type
2021-04-01 21:53:28 <ekhas> at same spot
2021-04-01 22:02:20 <nmeum> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10741
2021-04-01 22:03:23 <ekhas> 404?
2021-04-01 22:04:42 <ekhas> checked the log and 1 of the lines has -std=gnu++0x
2021-04-01 22:04:55 <ekhas> cant find 98
2021-04-01 22:05:22 <ekhas> i gues it got overridden
2021-04-01 22:05:48 <ekhas> i guess my export got overridden
2021-04-01 22:09:56 <ekhas> the line containing gnu++0x at the log end which makes sense since that's what prolly needs fixed
2021-04-01 22:24:17 <ekhas> tried CXX="-std=gnu++98" doesn't build at all
2021-04-01 22:24:42 <sam_> CXXFLAGS
2021-04-01 22:25:01 <ekhas> yea i figured there's difference
2021-04-01 22:25:30 <ekhas> CXXFLAGS didn't work either per above
2021-04-02 01:23:48 <Ariadne> nmeum: i can't see it
2021-04-02 08:19:44 <ncopa> morning... sigh... i think we need improve the release process if we are going to make stable releases every week
2021-04-02 08:21:10 <ncopa> i have 1125 commits for the pytho 3.9 rebuilds
2021-04-02 08:27:06 <ikke> That's quite a project
2021-04-02 08:27:47 <ncopa> and its challenging because the aports tree is alive, so every day i need to rebase and resolve a number of conlifcts and rebuild those
2021-04-02 08:28:22 <ncopa> im skipping a few packages, like py3-adblock, which involves rust and does fails to builds (after buliding for long time)
2021-04-02 08:29:12 <ncopa> py3-openzwave also. it pulls something from git and tries to build that, but does not work with python 3.9. there are posts saying that re-running cython should solve it, but there is no indication on how to do that
2021-04-02 08:30:46 <ncopa> i think i have approx 400 packages left
2021-04-02 08:31:03 <ncopa> i get lots of errors like:
2021-04-02 08:31:06 <ncopa> distutils.errors.DistutilsError: Command '['/usr/bin/python3', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpse2vk2i5', '--quiet', 'colorama>=0.4.3']' returned non-zero exit status 1.
2021-04-02 08:31:20 <ncopa> which is due to missing dep
2021-04-02 08:31:25 <ncopa> its normally trivial to solve
2021-04-02 08:31:51 <ncopa> it just takes time to manually fix those, since they are *many*
2021-04-02 08:33:48 <ncopa> and in this case, its not even in the package im trying to build
2021-04-02 08:33:58 <ncopa> so it must be some of the deps that are broken
2021-04-02 08:41:04 <ncopa> ugh. its py3-twine thats broken
2021-04-02 08:41:16 <ncopa> and it also needs rfc3986
2021-04-02 08:41:32 <ncopa> i have created a few py3-* packages for missing deps so far, but im getting tired
2021-04-02 08:41:43 <ikke> ncopa: maybe there is a way you can share your progress so far so that others can help fix things?
2021-04-02 08:42:32 <ncopa> if I can share my ~/packages/ over http somehow
2021-04-02 08:42:53 <ikke> dev.a.o?
2021-04-02 08:42:53 <afontain_> (darkhttpd is really cool)
2021-04-02 08:43:15 <ncopa> other option is to push what i have so far for main and community, and let testing be broken til things are cleaned up
2021-04-02 08:43:21 <afontain_> (but https is nice too)
2021-04-02 08:43:24 <ikke> Put it in ~/public
2021-04-02 08:43:59 <ncopa> i was more thinking of simply share the dev machine, so people have realtime access
2021-04-02 08:44:03 <ncopa> otherwise i
2021-04-02 08:44:18 <ncopa> otherwise i'll have to rsync in between each build
2021-04-02 08:45:27 <ncopa> but, right now, what woudl help is if someone cleaned up the py3-twine package, added py3-rfc2986 and py3-colorama to the deps
2021-04-02 08:45:31 <ncopa> and check that all other deps are there
2021-04-02 08:45:39 <ncopa> and push to current master
2021-04-02 08:45:46 <mps> does releases should be made so often
2021-04-02 08:46:09 <ncopa> or simply createing a py3-rfc3986 package would help
2021-04-02 08:46:36 <ikke> mps: the way our docker images are built require new releases to get them to update
2021-04-02 08:46:52 <mps> docker users should use edge, not stables
2021-04-02 08:47:15 <ikke>  No, that's generally bad advise
2021-04-02 08:47:27 <mps> heh
2021-04-02 08:47:45 <ncopa> production users, regardless of docker or not, should use stable
2021-04-02 08:48:14 <ncopa> and that said, we have made 2 stable releases without any edge snapshot yet
2021-04-02 08:48:18 <mps> 'one size fits all' usually doesn't work well
2021-04-02 08:48:21 <ikke> There were 2 CVE's that affected packeges included in the base image
2021-04-02 08:48:39 <ncopa> thats why we have both rolling release (edge) and stable releases
2021-04-02 08:49:15 <mps> but then you will have to make new release of stable on every change
2021-04-02 08:49:35 <ncopa> yup. thats what im complaining about
2021-04-02 08:49:39 <mps> cve or bugfix
2021-04-02 08:50:19 <mps> that is big job
2021-04-02 08:50:22 <ncopa> fortunately we dont have that much in the base image, so there are not that often there are changes
2021-04-02 08:50:26 <ncopa> yes, it is
2021-04-02 08:50:47 <nmeum> Adran
2021-04-02 08:50:50 <nmeum> oops
2021-04-02 08:51:06 <nmeum> Ariadne: it's confidential, don't you have access to confidental apk-tools issues?
2021-04-02 08:51:29 <ncopa> ikke: could we give Ariadne permission to view confidential issues on apk-tools?
2021-04-02 08:51:42 <ikke> ncopa: I wonder if we could have a 3.13 tag that's updated more often
2021-04-02 08:51:47 <ikke> ncopa: sure
2021-04-02 08:51:49 <nmeum> ty
2021-04-02 08:52:34 <ikke> Docker tag I mean
2021-04-02 08:53:15 <ikke> Not sure if that can be done for docker library images
2021-04-02 08:53:17 <ncopa> i guess we could. it was discussed some time ago, and IIRC i suggested more lightweight releases
2021-04-02 08:53:25 <ncopa> for docker only releases
2021-04-02 08:54:24 <ncopa> that is special git tag that only generates the minirootfs
2021-04-02 08:55:02 <ncopa> but at the time i think we concluded that we should probably ship proper releases with updated kernels anyway
2021-04-02 08:59:55 <ncopa> btw, i got a report yesterday that asterisk package messes up the permissions of /tmp
2021-04-02 09:00:10 <ncopa> it looks like the asterisk init.d script might be able to do so
2021-04-02 09:01:20 <ikke> Ariadne should now have access
2021-04-02 09:13:09 <nmeum> nice, thanks
2021-04-02 09:27:21 <ncopa> then we have fun things like:
2021-04-02 09:27:24 <ncopa> >>> py3-dnsrobocert: Fetching py3-dnsrobocert-3.9.0.tar.gz::https://github.com/adferrand/dnsrobocert/archive/v3.9.0.tar.gz
2021-04-02 09:27:24 <ncopa> >>> py3-dnsrobocert: Checking sha512sums...
2021-04-02 09:27:24 <ncopa> py3-dnsrobocert-3.9.0.tar.gz: FAILED
2021-04-02 09:27:55 <ikke> FUN
2021-04-02 09:28:54 <ncopa> i can either ignore it and skip the package (unless there are others that depends on it) or i refresh the checksum or spend time investigate why it fails
2021-04-02 09:30:34 <ncopa> no diff on the extracted tarball
2021-04-02 09:30:46 <ncopa> wait
2021-04-02 09:32:42 <ncopa> the diff https://tpaste.us/OQj8
2021-04-02 09:33:15 <ikke> Woah
2021-04-02 09:33:23 <ikke> That's a big diff
2021-04-02 09:34:06 <ikke> Did they tag a wrong commit?
2021-04-02 09:45:25 <ncopa> I reported it upstream https://github.com/adferrand/dnsrobocert/issues/341
2021-04-02 09:46:09 <ncopa> i hope the remaining 400 rebuilds does not have similar problems so we can get python 3.9 before the autumn....
2021-04-02 10:22:37 <omni> but you're saying that we could help by fixing some of the python aports so that you could merge those with your 3.9 efforts?
2021-04-02 10:22:53 <omni> if someone hasn't already, I could have a look at the three you mentioned above
2021-04-02 10:31:22 <ncopa> omni: creating a py3-rfc3986 package would help
2021-04-02 10:41:21 <ikke> ncopa: should I add a reverse proxy to forward http to your container?
2021-04-02 10:52:21 <ncopa> thats an option. i wonder how to share the git stuff though
2021-04-02 10:52:32 <ikke> yeah, was wondering about that as well
2021-04-02 10:53:02 <ikke> You could remove the .gitlab-ci.yml and push it to your fork
2021-04-02 10:54:41 <ncopa> i have 1240 commits now
2021-04-02 10:55:36 <ncopa> i wonder if i should just push and once main is built others can help with the remaining testing packages
2021-04-02 10:56:26 <ikke> yes, I suppose
2021-04-02 10:56:43 <ikke> we did that for gcc-10 and time_t 64-bits as well
2021-04-02 10:58:59 <omni> ncopa: I'm on it
2021-04-02 11:01:03 <ncopa> omni: thanks! can you please `git format-patch -1 --stdout | tpaste` it to me when its done?
2021-04-02 12:26:24 <omni> ncopa: https://tpaste.us/JY54 !20022
2021-04-02 12:30:13 <omni> although shellcheck didn't like it, perhaps I should try -exec instead of | xargs
2021-04-02 12:37:21 <omni> ncopa: https://tpaste.us/8jaW
2021-04-02 12:41:55 <ikke> find also has -delete
2021-04-02 13:02:01 <omni> oh
2021-04-02 13:02:24 <omni> I admit I'm one of those lazy find users who often grep its output
2021-04-02 14:37:32 <Hello71> -delete doesn't do the same thing though
2021-04-02 14:39:07 <Hello71> you'd have to do find \( -name __pycache__ -o  -path '*/__pycache__/*' \) -delete
2021-04-02 14:39:29 <Hello71> or just -path '*/__pycache__*' -delete if you don't mind deleting __pycache__2 or __pycache__~
2021-04-02 14:41:15 <Ariadne> nmeum: i'm writing validation code for every tar field in an apk package
2021-04-02 14:42:30 <nmeum> Ariadne: good idea, I really think that parser could be improved a lot :D
2021-04-02 14:42:39 <Ariadne> well
2021-04-02 14:42:48 <nmeum> haven't found anything else though (yet)
2021-04-02 14:42:52 <Ariadne> the apk-tools 3.0 format is much better
2021-04-02 14:43:02 <Ariadne> because it is not a tar :)
2021-04-02 14:43:14 <Ariadne> but we will have to keep this format around for a while yet
2021-04-02 14:43:19 <Ariadne> so it makes sense to harden it
2021-04-02 14:43:19 <nmeum> yep
2021-04-02 14:43:26 <Ariadne> because nobody will touch it ever again probably :P
2021-04-02 14:44:19 <afontain_> the tar-pit 🙂
2021-04-02 14:44:46 <nmeum> it's also not the only parser in apk-tools, would be neat to also test others (e.g. apkindex parser, …)
2021-04-02 14:46:27 <Ariadne> i think our apkindex parser is ok
2021-04-02 14:48:35 <nmeum> the format is also simpler, but you never know...
2021-04-02 15:04:15 <Ariadne> nmeum: you missed a field
2021-04-02 17:19:38 <PureTryOut[m]2> @maribu:matrix.org, Cogitri, maxice8, so it seems for some people Pipewire-pulse has suddenly started replacing pulseaudio on their system, even they did not install pipewire-pulse themselves
2021-04-02 17:19:48 <PureTryOut[m]2> The provider_priority seems to be set correctly, how can this happen?
2021-04-02 17:32:19 <nmeum> Ariadne: the gnu tar format page I read didn't mention that prefix is also null-terminated
2021-04-02 17:32:32 <Ariadne> nmeum: :D
2021-04-02 17:32:47 <Ariadne> nmeum: it is, in POSIX.
2021-04-02 17:32:51 <Ariadne> all strings are
2021-04-02 17:33:13 <DylanVanAssche_> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/iYstuUtCsqDPcVsNTeegtuMU/message.txt >

2021-04-02 17:33:19 <nmeum> > The name, linkname, magic, uname, and gname are null-terminated character strings. All other fields are zero-filled octal numbers in ASCII.
2021-04-02 17:33:30 <nmeum> idk I guess the gnu folks just forgot to mention it
2021-04-02 17:35:15 <ikke> heh
2021-04-02 17:38:56 <Ariadne> nmeum: if that is the same page i was looking at, it seemed to be not the greatest quality :)
2021-04-02 17:41:21 <nmeum> it's a hosted on gnu.org so that checks out :3
2021-04-02 17:41:25 <nmeum> s/a//
2021-04-02 17:41:25 <alpine-meetbot> nmeum meant to say: it's  hosted on gnu.org so that checks out :3
2021-04-02 18:03:52 <Marian[m]1> PureTryOut (matrix.org)  Have you confirmed that a higher number represent a higher priority? It is not uncommon that smaller numbers are used for higher prio.
2021-04-02 18:06:27 <PureTryOut[m]2> I have yes, as seen on the wiki
2021-04-02 18:06:47 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/solver.c#L646
2021-04-02 18:06:48 <PureTryOut[m]2> And I can say that at least on my pulseaudio system it has indeed not randomly installed pipewire-pulse
2021-04-02 18:06:55 <craftyguy> "A numeric value which is used by apk-tools to break ties when choosing a virtual package to satisfy a dependency. Higher values have higher priority. "
2021-04-02 18:06:59 <ikke> /* Prefer highest declared provider priority. */
2021-04-02 18:08:20 <craftyguy> on my system, something insists on installing pipewire-pulse and removing pulseaudio entirely after upgrade. if I try to remove pipewire-pulse, these things say they block that:   pipewire-pulse: gnome-tweaks phosh postmarketos-ui-phosh pipewire lang
2021-04-02 18:08:34 <craftyguy> nothing explicitly depends on pipewire-pulse
2021-04-02 18:08:51 <craftyguy> but it's impossible to remove it and replace it with the real pulseaudio
2021-04-02 18:10:13 <craftyguy> hmm 'provides' considers the value to be a virtual package if no version is given (per the wiki), but in this case it's not a virtual package, it (pulseaudio) is a real package
2021-04-02 18:10:18 <craftyguy> is that the problem?
2021-04-02 18:10:34 <ikke> yes
2021-04-02 18:10:59 <ikke> it should do provides="pulse-$pkgver-r$pkgrel"
2021-04-02 18:11:08 <craftyguy> PureTryOut[m]2: ^
2021-04-02 18:11:13 <PureTryOut[m]2> Hm...
2021-04-02 18:11:35 <PureTryOut[m]2> But doesn't that mean that if pulseaudio has a higher version, it'll get preferred over pipewire-pulse even if you want pipewire-pulse?
2021-04-02 18:12:38 <ikke> If you have pipewire-pulse installed, I would not expect it to be replaced with pulse
2021-04-02 18:12:46 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/solver.c#L639
2021-04-02 18:12:49 <PureTryOut[m]2> Hmm ok, let's try that then
2021-04-02 18:12:55 <ikke> /* Prefer installed (matches here if upgrading) */
2021-04-02 18:18:19 <PureTryOut[m]2> ikke: like this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20031
2021-04-02 18:19:27 <ikke> with an =
2021-04-02 18:19:42 <ikke> pulseaudio-$pkgver-r$pkgrel -> pulseaudio=$pkgver-r$pkgrel
2021-04-02 18:21:27 <PureTryOut[m]2> Ah yes
2021-04-02 18:48:38 <Ariadne> nmeum: going to deploy the hotfix
2021-04-02 18:48:53 <ikke> Ariadne: I guess we should request a CVE for this?
2021-04-02 18:48:59 <Ariadne> yes
2021-04-02 18:49:10 <Ariadne> i can do it
2021-04-02 18:49:12 <ikke> ok
2021-04-02 19:03:27 <craftyguy> so now that pipewire-pulse is doing the right thing, my system still thinks pulseaudio is a virtual package(?), and won't let me remove it. 'apk add pulseaudio' is a noop (apk returns without doing anything)
2021-04-02 19:03:51 <craftyguy> s/remove it/remove pipewire-pulse/
2021-04-02 19:03:51 <alpine-meetbot> craftyguy meant to say: so now that pipewire-pulse is doing the right thing, my system still thinks pulseaudio is a virtual package(?), and won't let me remove pipewire-pulse. 'apk add pulseaudio' is a noop (apk returns without doing anything)
2021-04-02 19:05:05 <craftyguy> I don't see an obvious way to "apk del pipewire-pulse --I-really-know-what-I-am-doing-ignore-reverse-dependencies-and-just-do-it"
2021-04-02 19:05:20 <craftyguy> (on Arch it would be 'pacman -Rdd <package>')
2021-04-02 19:08:33 <Ariadne> craftyguy: `apk add '!pipewire-pulse'`
2021-04-02 19:09:04 <craftyguy> well that's efffing cool. TIL
2021-04-02 19:09:19 <craftyguy> Ariadne: that worked :D thank you
2021-04-02 19:09:30 <dalias> why the '' ? :)
2021-04-02 19:09:35 <dalias> ! is not special to shell :)
2021-04-02 19:09:53 <craftyguy> ya I ran it without the ''
2021-04-02 19:09:54 <dalias> </bashsuckstroll>
2021-04-02 19:09:57 <Ariadne> dalias: in bash and ash it can invoke a previous command :)
2021-04-02 19:09:57 <PureTryOut[m]2> Oh wow, that ! is new to me
2021-04-02 19:10:01 <PureTryOut[m]2> Is that a force thing?
2021-04-02 19:10:09 <Ariadne> no, nothing is being forced
2021-04-02 19:10:18 <ikke> PureTryOut[m]2: it marks a conflict
2021-04-02 19:10:20 <ikke> conflict
2021-04-02 19:10:21 <dalias> ariadne, yeah it's one of bash's horrible willful conformance bugs
2021-04-02 19:10:24 <Ariadne> you are adding a constraint
2021-04-02 19:10:25 <dalias> and very dangerous
2021-04-02 19:10:38 <PureTryOut[m]2> Ah cool
2021-04-02 19:10:47 <Ariadne> that says you do not want pipewire-pulse
2021-04-02 19:10:57 <Ariadne> apk add does not actually install anything
2021-04-02 19:11:06 <Ariadne> it just adds constraints
2021-04-02 19:11:09 <dalias> :)
2021-04-02 19:11:12 <ikke> it updates world
2021-04-02 19:11:20 <Ariadne> the installation happens as a side effect
2021-04-02 19:11:41 <craftyguy> huh, I hadn't thought of it that way before
2021-04-02 19:11:42 <Ariadne> in apk3, it will be possible to defer side effects from apk add/del btw
2021-04-02 19:12:00 <Ariadne> yes, it seems most people do not think the way i think :)
2021-04-02 19:12:01 <ikke> hence it's not called 'apk install'
2021-04-02 19:12:13 <PureTryOut[m]2> Interesting!
2021-04-02 19:12:38 <Ariadne> anyway
2021-04-02 19:17:40 <dalias> this kinda explains why updating is so hard
2021-04-02 19:19:32 <caskd> wonder if it would be possible to predistribute a world file with fixed version and have people install it afterwards
2021-04-02 19:20:14 <caskd> that way one could distribute fixed-version install scripts without sharing a tarball
2021-04-02 19:22:17 <craftyguy> ikke: my (entirely naive) thought for why it is 'add' and not 'install' is that 'add' is 50% shorter to type :D
2021-04-02 19:27:41 <Ariadne> caskd: yes.  if you drop in an /etc/apk/world and run `apk fix` it will do exactly that
2021-04-02 19:28:25 <caskd> ooh
2021-04-02 19:28:28 <caskd> interesting
2021-04-02 19:30:39 <craftyguy> oh that's cool
2021-04-02 19:32:59 <skarnet> so 'apk fix' actually means 'make the actual state match the state as viewed by the apk db' ?
2021-04-02 19:33:16 <Ariadne> yes
2021-04-02 19:33:26 <Ariadne> or at least, attempt to
2021-04-02 19:33:33 <skarnet> of course
2021-04-02 19:35:41 <afontain_> this `apk add '!pipewire-pulse'` thing is wonderful
2021-04-02 19:35:46 <afontain_> 
ACTION takes note

2021-04-02 19:36:12 <caskd> apk is pretty nice
2021-04-02 19:36:26 <caskd> fell in love at first use
2021-04-02 19:36:30 <caskd> still love it today
2021-04-02 19:37:57 <afontain_> I love it, except for those weird conflicts where you want to tear apart /etc/apk/world
2021-04-02 19:39:15 <skarnet> nothing weird about wanting to tear apart the world from time to time
2021-04-02 19:40:43 <Cogitri> PureTryOut[m]2: Hmm,not sure how to fix that, I guess pulseaudio needs a higher provider_priority for itself
2021-04-02 19:40:50 <caskd> i absolutely hate the ncurses -> ncurses-libs dep
2021-04-02 19:40:54 <caskd> it annoys me
2021-04-02 19:41:03 <caskd> with it's fixed version
2021-04-02 19:41:06 <dalias> ?
2021-04-02 19:41:07 <caskd> so i know that feeling
2021-04-02 19:41:50 <dalias> is that the same as the nasty -dev -> -lib version dep ?
2021-04-02 19:42:00 <dalias> the one that breaks all upgrades
2021-04-02 19:42:08 <Cogitri> PureTryOut[m]2: I can give that providers stuff a go tomorrow, taking a day off for birthday today :p
2021-04-02 19:42:40 <caskd> nope, it's the one where if a package that depends on something that depends on ncurses wants to upgrade i must upgrade both ncurses and ncurses-libs as well
2021-04-02 19:42:52 <caskd> happens a lot when i upgrade my unbound config
2021-04-02 19:46:21 <PureTryOut[m]2> Cogitri: already fixed
2021-04-02 19:50:17 <Cogitri> Oh, neat
2021-04-02 19:51:41 <ikke> Cogitri: problem was it was declared as a virtual package
2021-04-02 19:52:54 <Cogitri> Ah, I'll have to take a look at the commit later, I still don't have a great understanding of how replaces&provides works
2021-04-02 19:53:38 <ikke> provides="foo" is a virtual provides
2021-04-02 19:53:53 <ikke> provides="foo=1-r2" is a concrete provides
2021-04-02 19:54:11 <ikke> virtual packages should only be used for something that does not actually exist
2021-04-02 19:54:30 <PureTryOut[m]2> craftyguy: that is probably also how we would've fixed the Mesa issues we had in the past...
2021-04-02 19:54:47 <craftyguy> PureTryOut[m]2: yeah, in hindsight :P
2021-04-02 19:54:49 <ikke> PureTryOut[m]2: I think that one was more complex?
2021-04-02 19:55:00 <ikke> or maybe yes
2021-04-02 19:55:49 <PureTryOut[m]2> I don't believe so
2021-04-02 20:04:35 <kunkku> is anyone else experiencing strange "BAD archive" errors on "apk upgrade" at edge?
2021-04-02 20:04:42 <omni> yes
2021-04-02 20:04:47 <omni> was just about to say something
2021-04-02 20:04:57 <ikke> Ariadne: ^
2021-04-02 20:05:01 <omni> ERROR: gcc-10.2.1_git20210328-r0: BAD archive
2021-04-02 20:05:09 <Ariadne> hmm
2021-04-02 20:05:12 <omni> ERROR: g++-10.2.1_git20210328-r0: BAD archive
2021-04-02 20:05:29 <Ariadne> sigh :P
2021-04-02 20:05:33 <kunkku> I have issues on multiple systems with varying packages
2021-04-02 20:05:45 <artok> just did rpi4 upgrade, no errors
2021-04-02 20:05:47 <ikke> kunkku: apk-tools has just been patched
2021-04-02 20:05:48 <Ariadne> hotfix worked for me on apk upgrade >_<
2021-04-02 20:05:56 <Ariadne> let me relax it
2021-04-02 20:05:58 <Ariadne> i know why
2021-04-02 20:07:24 <Ariadne> try with new apk-tools -r2
2021-04-02 20:07:37 <Ariadne> its because some archives have things they shouldn't
2021-04-02 20:07:53 <Ariadne> or, rather are not actually supported by apk-tools
2021-04-02 20:07:59 <omni> I noticed this on gitlab CI
2021-04-02 20:08:47 <ikke> I hope we didn't break the builders :P
2021-04-02 20:09:07 <Ariadne> they should just need `apk fix` if we did
2021-04-02 20:09:21 <Ariadne> anyway
2021-04-02 20:09:34 <Ariadne> -r2 relaxes the hotfix
2021-04-02 20:09:57 <Ariadne> can somebody verify that it is working for them please :)
2021-04-02 20:10:31 <Ariadne> kunkku: can you repeat with the apk-tools hotfix hotfix version :)
2021-04-02 20:17:04 <Ariadne> we backed out the hotfix
2021-04-02 20:17:09 <Ariadne> i'm not sure why it is defective
2021-04-02 20:17:23 <Ariadne> will dig into it this weekend
2021-04-02 20:39:43 <kunkku> now works
2021-04-02 20:40:47 <kunkku> let me know if you need help in reproducing
2021-04-02 20:41:16 <ikke> kunkku: it also happened on the builders
2021-04-02 20:41:24 <ikke> kunkku: what arch were you on?
2021-04-02 20:42:05 <kunkku> x86_64
2021-04-02 20:42:10 <ikke> ok
2021-04-02 20:42:19 <ikke> Maybe there were multiple issues :(
2021-04-02 20:42:42 <ikke> After the first hotfix-fix, things still failed on 32-bits arches
2021-04-02 20:43:21 <kunkku> failing pkgs were linux-lts-5.10.27-r0 and py3-faker-7.0.1-r0
2021-04-02 20:43:45 <ikke> ERROR: python3-3.8.8-r0: BAD archive
2021-04-02 20:43:51 <ikke> ERROR: meson-0.57.1-r0: BAD archive
2021-04-02 20:43:55 <ikke> ERROR: directfb-1.7.7-r3: BAD archive
2021-04-02 20:44:03 <ikke> ERROR: directfb-dev-1.7.7-r3: BAD archive
2021-04-02 20:44:16 <ikke> and more
2021-04-02 20:44:53 <omni> I saw the same issue on all archs in CI
2021-04-02 20:59:22 <ikke> ok
2021-04-02 21:03:18 <ikke> Ariadne: Do you mean this regarding the apk-3.0 field names? https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/apk_adb.c#L343
2021-04-02 21:10:47 <Ariadne> yup
2021-04-02 21:41:22 <caskd> oh no i've been hit by the same replace problem with pulse
2021-04-02 21:41:40 <afontain_> pipewire-pulse?
2021-04-02 21:41:43 <caskd> yep
2021-04-02 21:41:55 <ikke> git add '!pipewire-pulse'
2021-04-02 21:41:58 <ikke> apk*
2021-04-02 21:42:01 <afontain_> this is quite annoying tbh
2021-04-02 21:42:26 <ikke> should be fixed now
2021-04-02 21:42:57 <caskd> right now? or before i asked?
2021-04-02 21:43:11 <ikke> before you asked
2021-04-02 21:43:17 <caskd> uhh, not really
2021-04-02 21:43:19 <ikke> but you need to run that command to get rid of it
2021-04-02 21:43:24 <caskd> since i just updated
2021-04-02 21:43:29 <ikke> the original issue is fixed
2021-04-02 21:43:48 <ikke> but you need to do something extra to get back to the original situation
2021-04-02 21:44:24 <caskd> i updated the remote apkindex a few seconds before asking
2021-04-02 21:44:29 <caskd> so i don't think so
2021-04-02 21:44:52 <ikke> caskd: did you run `apk add '!pipewire-pulse'`A
2021-04-02 21:44:56 <caskd> well, yes
2021-04-02 21:45:06 <caskd> but is this supposed to be default behaviour now?
2021-04-02 21:45:14 <caskd> pipewire over normal pulse?
2021-04-02 21:45:22 <ikke> no
2021-04-02 21:45:56 <caskd> imma test this on my other device as well to see if this fix actually worked
2021-04-02 21:46:43 <ikke> caskd: it was the result of an incorrect declaration in the pipewire-pulse package
2021-04-02 21:47:04 <caskd> i understand that
2021-04-02 21:47:19 <caskd> but i just updated the stuff and it still happened
2021-04-02 21:47:27 <caskd> without using local apkindex cache
2021-04-02 21:49:23 <ikke> caskd: what mirror do you use?
2021-04-02 21:49:29 <caskd> dl-cdn
2021-04-02 21:50:01 <ikke> hmm, ok
2021-04-02 21:50:16 <ikke> I test it in docker, and it always installs just pulseaudio for me
2021-04-02 21:50:52 <ikke> caskd: when do you get pipewire-pulse?
2021-04-02 21:51:07 <caskd> i'm looking into it
2021-04-02 21:53:36 <caskd> pulseaudio-alsa still installs it
2021-04-02 21:54:08 <caskd> it installs pipewire better said
2021-04-02 21:54:12 <caskd> which replaces pulse
2021-04-02 21:57:54 <ikke> yes, I see
2021-04-02 23:34:34 <alexeymin> https://builds.sr.ht/~postmarketos/job/475926 looks like it suffers from "BAD archive" too
2021-04-03 02:32:45 <Ariadne> alexeymin: yes you'll probably have to resubmit the builds that were affected by the botched hotfix
2021-04-03 02:41:32 <ericonr> Ariadne: did you see https://github.com/rust-lang/compiler-team/issues/422 ?
2021-04-03 02:41:50 <Ariadne> no
2021-04-03 02:41:52 <Ariadne> did they fuck it up
2021-04-03 02:42:21 <ericonr> still reading
2021-04-03 02:42:34 <Ariadne> looks ok
2021-04-03 02:42:40 <ericonr> 
ACTION appreciates the high level of trust Ariadne has on the rust team

2021-04-03 02:43:27 <ericonr> and yes, it looks ok
2021-04-03 02:44:18 <ericonr> it would seem they didn't tag alex explicitly as I think you requested, but if he hasn't complained by now I don't think he's going to veto it later (can he even veto stuff?)
2021-04-03 02:45:08 <Ariadne> i dunno
2021-04-03 07:30:49 <nmeum> Ariadne: maybe we should only use the null terminator checks for now
2021-04-03 07:31:28 <nmeum> Ariadne: it somewhat suboptimal that the bug is now public without an applied fix ':)
2021-04-03 07:31:42 <nmeum> *is
2021-04-03 07:36:26 <ikke> Ah, it was made public already?
2021-04-03 08:06:57 <nmeum> well, a hotfix was applied but then reverted again :S
2021-04-03 08:10:09 <ikke> Yes
2021-04-03 08:10:28 <ikke> I was there ;-)
2021-04-03 08:11:29 <afontain_> it was a hot hotfix, so you had to drop it
2021-04-03 08:11:54 <afontain_> 
ACTION ->[]

2021-04-03 08:12:29 <ikke> :-D
2021-04-03 11:20:59 <omni> qin 1
2021-04-03 11:21:03 <omni> uh
2021-04-03 12:57:09 <mps> openrc 0.43 is released
2021-04-03 12:58:15 <ikke> 19h ago
2021-04-03 13:01:12 <mps> I see minimals patches there
2021-04-03 13:05:43 <omni> I'd like to track the Blocksize weirdness discovered on builders for 32bit archs through the mbuffer tests but am not sure how to phrase it in a gitlab issue
2021-04-03 13:09:50 <nmeum> mps: are you working on an update?
2021-04-03 13:16:36 <mps> nmeum: no
2021-04-03 13:17:30 <mps> I don't have much time now, but if no one start to work on it I will in a few days
2021-04-03 13:17:55 <mps> will be good to upgrade it before freeze
2021-04-03 13:18:05 <ikke> yes
2021-04-03 13:18:57 <ikke> https://github.com/OpenRC/openrc/compare/0.42.1...0.43
2021-04-03 13:19:59 <mps> ikke: there is Changelog file :)
2021-04-03 13:20:22 <nmeum> there is a news file also
2021-04-03 13:20:28 <nmeum> they changed the checkpath behaviour a bit
2021-04-03 13:20:45 <nmeum> https://github.com/OpenRC/openrc/blob/master/NEWS.md#openrc-043
2021-04-03 13:20:49 <ikke> mps: changelog files can lie :P
2021-04-03 13:20:56 <nmeum> not sure yet but might cause some issues with existing services I guess
2021-04-03 13:21:02 <mps> ikke: heh :)
2021-04-03 13:21:31 <ikke> "Performance improvements and bugfixes"
2021-04-03 13:22:23 <mps> nmeum: yes, noticed it as posible issue which will require some more tests and works
2021-04-03 13:23:29 <mps> and we have not small number of patches in aport which needs to be carefully checked
2021-04-03 13:23:33 <jvoisin> https://github.com/OpenRC/openrc/compare/0.42.1...0.43#diff-86a543adfd1a08d1b33f8507e54a1f0cee357c94d095d9619c57098081a9b29bR26 this one looks fun
2021-04-03 13:25:07 <nmeum> !20056
2021-04-03 13:25:56 <mps> a lot of changes are about supervisor
2021-04-03 13:26:02 <nmeum> haven't dared rebooting with this installed yet
2021-04-03 13:26:16 <mps> nmeum: you are fast, really
2021-04-03 13:26:39 <nmeum> well, didn't have to rebase any patches so it was kind of easy
2021-04-03 13:26:49 <nmeum> just had to remove the ones already applied
2021-04-03 13:27:01 <mps> if it builds I can test on my testing aarch64 box
2021-04-03 13:27:12 <nmeum> it builds
2021-04-03 13:27:22 <mps> \o/
2021-04-03 13:27:24 <nmeum> at least locally x86_64
2021-04-03 13:27:35 <nmeum> *on
2021-04-03 13:29:02 <Ariadne> [02:30] <nmeum> Ariadne: maybe we should only use the null terminator checks for now
2021-04-03 13:29:08 <Ariadne> yes seems reasonable
2021-04-03 13:29:24 <Ariadne> i can prepare a patch that does only that
2021-04-03 13:29:36 <nmeum> if it doesn't cause any regressions that would be nice
2021-04-03 13:29:46 <nmeum> idk fabled also mentioned that he wanted to coordinate this
2021-04-03 13:29:54 <nmeum> because it also needs to be backported to the stable branches
2021-04-03 13:30:00 <nmeum> etc. p..
2021-04-03 13:30:38 <nmeum> the problem is just that it has been disclosed now, it's not super critical but still unideal I guess
2021-04-03 13:35:00 <Ariadne> i prefer to wait for fabled.  the vulnerability is minor
2021-04-03 13:35:14 <Ariadne> i already made an attempt to hotfix it :p
2021-04-03 13:36:13 <nmeum> lets wait for fabled then
2021-04-03 13:36:29 <nmeum> did you request a cve?
2021-04-03 13:40:56 <Ariadne> yes
2021-04-03 13:41:32 <Ariadne> i agree that the scope of the original hotfix (plus checking the prefix field) is likely safe
2021-04-03 13:41:42 <Ariadne> but we should validate all fields
2021-04-03 13:46:02 <Ariadne> OpenRC 0.43 boots for me on my test machine and on my laptop
2021-04-03 13:46:07 <Ariadne> i think we can send it
2021-04-03 13:49:06 <mps> now it is merged I don't need to test :)
2021-04-03 13:49:26 <Ariadne> i tested it for you :)
2021-04-03 13:50:57 <mps> heh, I have specific setup, with some specific changes for libudev-zero
2021-04-03 13:51:34 <mps> will check after coffee break
2021-04-03 13:58:57 <ikke> And I guess nobody bothered to backport the curl CVE yet
2021-04-03 14:07:40 <mps> nmeum: openrc boots on my aarch64 edge with libudev-zero, some warnings though but nothing serious
2021-04-03 14:07:44 <mps> Ariadne: ^
2021-04-03 14:08:40 <nmeum> what kind of warnings do you get?
2021-04-03 14:09:43 <mps> not related to openrc but networking/ifquery. I'll look later why that
2021-04-03 14:15:45 <mps> hm, /etc/init.d/chronyd start => ifquery: unrecognized option: auto
2021-04-03 14:17:44 <Ariadne> and which ifquery are you using?
2021-04-03 14:18:18 <Ariadne> ifupdown-ng has --auto, but maybe Debian ifupdown does not
2021-04-03 14:18:21 <mps> ifupdown (not -ng)
2021-04-03 14:18:51 <mps> lets try with busybox ifupdown
2021-04-03 14:18:51 <Ariadne> well, that seems like a defect with ifupdown (not -ng) :p
2021-04-03 14:18:59 <Ariadne> busybox ifupdown does not have ifquery at all
2021-04-03 14:19:25 <mps> huh, how then is instaled in my box
2021-04-03 14:19:36 <mps> ahm, sorry
2021-04-03 14:19:53 <mps> lets reboot
2021-04-03 14:20:05 <Ariadne> i'll pray for your networking setup
2021-04-03 14:20:07 <Ariadne> :)
2021-04-03 14:21:01 <mps> it worked ;)
2021-04-03 14:21:27 <mps> only chronyd didn't started
2021-04-03 14:21:51 <ikke> Hmm, curl did not backport the CVE patches, and they do not apply on older releases :(
2021-04-03 14:21:52 <ikke> not even 3.13
2021-04-03 14:23:50 <Ariadne> hmm, i believe we enter freeze next friday
2021-04-03 14:24:08 <Ariadne> i guess i should get ifupdown-ng 0.11 released next week :)
2021-04-03 14:24:14 <mps>  /etc/init.d/networking need fix for ifquery
2021-04-03 14:25:08 <Ariadne> i didn't write it, so it's not my department :p
2021-04-03 14:25:47 <ikke> Ariadne: any idea about what time the AlpineConf will be held?
2021-04-03 14:25:57 <Ariadne> no idea yet :D
2021-04-03 14:26:12 <Ariadne> probably afternoon eastern time, morning US time
2021-04-03 14:27:52 <ikke> right
2021-04-03 14:28:42 <Hello71> wondering if we should set -march=i686 -mtune=generic for x86
2021-04-03 14:28:50 <dalias> which curl cve?
2021-04-03 14:28:55 <ikke> 2
2021-04-03 14:28:59 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12568
2021-04-03 14:29:11 <Hello71> does anyone actually use alpine chroot on i386
2021-04-03 14:29:16 <Hello71> ikke: can dalias see that?
2021-04-03 14:30:21 <Hello71> dalias: CVE-2021-22876, CVE-2021-22890
2021-04-03 14:30:21 <ikke> ah, no
2021-04-03 14:33:56 <ikke> 
ACTION thinks we should open up this CVE issues

2021-04-03 14:36:10 <Ariadne> Hello71: i have alpine in service on i586 class machines
2021-04-03 14:36:56 <Hello71> ok what about march=i586? i don't know what gcc means exactly by "(No scheduling is implemented for this chip.)" but it sounds bad
2021-04-03 14:37:02 <Hello71> for i486
2021-04-03 14:37:31 <Ariadne> there is no need to implement instruction scheduling for i486 because i486 implementations do not speculate
2021-04-03 14:37:55 <Ariadne> so it is not bad, per se
2021-04-03 14:40:39 <Ariadne> Hello71: i also had i486 class machines in service until last year
2021-04-03 14:40:58 <Ariadne> Hello71: alpine already requires i486 as baseline anyway
2021-04-03 14:41:35 <Hello71> just wondering if our programs would run faster if we added a -march, but it sounds like there's not much difference between i386 and i486 in userspace anyways
2021-04-03 14:41:50 <Hello71> and also i guess people who care about performance are on x86_64 anyways
2021-04-03 14:42:18 <Ariadne> the Via C3 also doesn't speculate
2021-04-03 14:43:01 <Ariadne> basically, instruction scheduling means that you can reorder instructions to allow the speculation (stuff like branch prediction) engine to stay running for longer times
2021-04-03 14:43:08 <Ariadne> but not relevant on i486
2021-04-03 14:52:42 <Hello71> right
2021-04-03 14:52:52 <Hello71> but what happens when you do -march=i486 -mtune=generic
2021-04-03 14:54:27 <ikke> Someone from debian backported it: https://salsa.debian.org/debian/curl/-/merge_requests/10/diffs
2021-04-03 14:57:50 <mps> I like openrc, it was easy to fix non existing 'ifquery' in /etc/init.d/networking. systemd fix would be mess
2021-04-03 15:08:12 <ikke> PureTryOut[m]2: terraform-provider-libvirt failed on armhf as well
2021-04-03 15:08:32 <PureTryOut[m]2> I see, will disable
2021-04-03 15:36:24 <ikke> Ariadne: "Receiving objects:  95% (896794/941961), 993.12 MiB | 9.60 MiB/s"
2021-04-03 15:36:39 <ikke> installing packages using git clone
2021-04-03 15:45:42 <timlegge> finally got back to !18374 if anyone has time to review
2021-04-03 16:15:56 <Ariadne> ikke: ??
2021-04-03 16:16:23 <Ariadne> ikke: installing what packages using git clone? :p
2021-04-03 16:17:14 <ikke> in general
2021-04-03 16:17:42 <Ariadne> my proposal isn't about using git clone to install packages, but to fetch the sources in abuild
2021-04-03 16:18:05 <ikke> yes, that's what's happening
2021-04-03 16:18:35 <Ariadne> are you referring to debian's way of doing packaging? :)
2021-04-03 16:18:42 <Ariadne> i still don't follow :P
2021-04-03 16:19:18 <ikke> this was archlinux (aur)
2021-04-03 16:21:00 <Ariadne> ah
2021-04-03 16:43:54 <mps> nmeum: Ariadne: hm, /etc/init.d/networking don't need any fix with new openrc, I removed one local 'thing' and it works without any problem
2021-04-03 16:46:03 <mps> timlegge: ikke: !18374
2021-04-03 16:47:02 <mps> ikke: how to check test on mips64, I'm not sure timlegge have mips64 box to test
2021-04-03 16:48:29 <timlegge> No I don't actually - happy to revert that part though
2021-04-03 16:48:47 <ikke> I can check it
2021-04-03 16:49:01 <ikke> Soon(tm) we will have CI for mips64 as well
2021-04-03 16:50:13 <mps> so, we can merge it (though I wonder why this pkg is introduced to posix system)
2021-04-03 16:51:31 <mps> lets see will it pass builders
2021-04-03 16:51:35 <ikke> Oh
2021-04-03 16:51:39 <ikke> I was just building it on mips
2021-04-03 16:51:51 <mps> ah, sorry
2021-04-03 16:51:58 <ikke> but it succeeded
2021-04-03 16:52:20 <mps> I thought no one will check it first
2021-04-03 16:52:32 <ikke> 18:48:46          @ikke │ I can check it  :-)
2021-04-03 16:53:04 <ikke> Ariadne: I guess there is no spec (yet) for the abd format
2021-04-03 16:53:15 <ikke> adb*
2021-04-03 16:53:16 <mps> aha, but 'I can' doesn't mean 'I will'
2021-04-03 16:53:31 <mps> :)
2021-04-03 16:53:40 <ikke> In generally that does mean that one will
2021-04-03 16:54:14 <mps> yet another 'fine point' of english :P
2021-04-03 16:54:38 <ikke> it would be kind of strange when someone mentions that they are able to do something, but then refrain from doing that
2021-04-03 16:54:56 <ikke> "Can you check this for me?" "Yes, I can"
2021-04-03 16:55:04 <detha> One could say that.
2021-04-03 16:56:10 <ikke> One could say a lot
2021-04-03 16:57:03 <mps> I can do a lot of 'strange things' but that doesn't mean I will do, quite opposite. but nvm
2021-04-03 16:57:37 <detha> rfc854 has a nice set of WILL/WONT/DO/DONT for this
2021-04-03 16:58:16 <mps> rfc is different in meaning of these words
2021-04-03 18:39:28 <maxice8> Merging poppler upgrade soon, a few hours (includes libreoffice rebuild due to soname changes)
2021-04-03 19:27:40 <Ariadne> [10:53:02] <ikke> Ariadne: I guess there is no spec (yet) for the abd format
2021-04-03 19:27:45 <Ariadne> not yet, i can write on tho
2021-04-03 19:35:01 <ikke> I have this for the v2 format: https://gitlab.alpinelinux.org/alpine/go/-/merge_requests/1
2021-04-03 19:38:50 <ikke> py3-rss2email fails with: "/usr/bin/python3: No module named pip"
2021-04-03 19:39:13 <maxice8> please don't add pip
2021-04-03 19:39:30 <ikke> I won't
2021-04-03 19:39:48 <ikke> I thought that pip was built-in to python3 now
2021-04-03 19:39:48 <maxice8> thanks, I'm looking into it
2021-04-03 19:39:52 <maxice8> missing py3-sgmllib3k in the depends=
2021-04-03 19:40:28 <ikke> right, makes sense
2021-04-03 19:40:37 <ikke> ['/usr/bin/python3', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmps4o9v2_4', '--quiet', 'sgmllib3k']
2021-04-03 19:40:50 <ikke> wasn't this caught in CI?
2021-04-03 19:41:01 <ikke> Was this not caught*
2021-04-03 19:41:08 <maxice8> It caught another and I thought it was the last of it
2021-04-03 19:41:13 <ikke> aha, ok
2021-04-03 22:34:26 <maxice8> merging poppler
2021-04-04 08:54:13 <Newbyte> Could it be an issue that I bumped the pkgrel in the first commit instead of the last one in a merge request+
2021-04-04 08:54:15 <Newbyte> ?*
2021-04-04 08:55:01 <Newbyte> Like, could it happen that it gets built from the first commit (which doesn't build, requires the last commit)?
2021-04-04 09:13:51 <ikke> Newbyte: no, it does not matter what commit bumps a pkgrel
2021-04-04 09:14:16 <ikke> for the build process, commits don't matter at all, it just looks at the final result
2021-04-04 10:48:23 <Newbyte> Got it, thanks
2021-04-04 10:48:55 <Newbyte> Also, can a package have multiple maintainers?
2021-04-04 10:49:50 <ikke> No, there is only one possibly entry for maintainers
2021-04-04 10:49:57 <ikke> But
2021-04-04 10:50:09 <ikke> I think the idea is that we support teams that maintain packages
2021-04-04 10:50:26 <ikke> But that would only make sense for teams that maintain a lot of packages
2021-04-04 10:51:06 <Newbyte> Yeah, I can think of some odd cases where I'd like to be some sort of co-maintainer of a package without forming a team for that
2021-04-04 11:04:28 <ikke> Hmm, Assertion failed: sizeof(void *) == 4 (src/boot/system_test.c: system_test: 33)
2021-04-04 11:25:20 <skarnet> that's so cute
2021-04-04 11:32:41 <ikke> But it's wrong?
2021-04-04 11:33:30 <ikke> https://www.youtube.com/watch?v=hspNaoxzNbs
2021-04-04 11:33:31 <tehcloud> it's wrong on my system ;)
2021-04-04 12:47:31 <ikke> It incorrectly determines MIPS_64 -s 32-bits
2021-04-04 12:47:40 <ikke> Or rather, fails to see it as 64-bits
2021-04-04 13:03:16 <ikke> Ariadne: Is __mips64 a good constant to test against?
2021-04-04 13:21:45 <ikke> At least it's working
2021-04-04 15:01:34 <caskd> how does one cross compile with abuild without the build-base-ARCH problems?
2021-04-04 15:07:47 <caskd> oh, this is -devel
2021-04-04 15:07:49 <caskd> whoops
2021-04-04 15:11:46 <ikke> isn't that what -devel is for?
2021-04-04 15:12:11 <caskd> seems more like a support question
2021-04-04 15:12:14 <caskd> but i figured it out
2021-04-04 15:12:20 <caskd> found bootstrap.sh
2021-04-04 15:13:00 <ikke> note that this is generally just used for cross-compiling a build toolchain
2021-04-04 15:13:11 <ikke> not for a generic cross-compiler
2021-04-04 15:13:30 <caskd> oh
2021-04-04 15:13:47 <caskd> i want to setup a env for building packages on another arch
2021-04-04 15:13:52 <caskd> wouldn't this be the right way?
2021-04-04 15:14:02 <ikke> most likely not
2021-04-04 15:14:23 <ikke> note that we do not cross-compile software except for the build toolchain
2021-04-04 15:14:32 <caskd> hmm, i see
2021-04-04 15:15:32 <caskd> postmarketos project does that on the host though, wonder how they do it
2021-04-04 15:15:48 <caskd> don't want to use the hacky toolchain they have
2021-04-04 15:15:50 <ikke> qemu perhaps?
2021-04-04 15:16:02 <caskd> ikke: i think it's related with binfmt
2021-04-04 15:16:08 <caskd> since i need that mounted for builds
2021-04-04 15:16:18 <ikke> then it's qemu-user
2021-04-04 15:16:22 <caskd> oh
2021-04-04 16:15:24 <andypost> Is the message a sound of CI issue? https://gitlab.alpinelinux.org/andypost/aports/-/jobs/363908#L48
2021-04-04 16:18:54 <omni> any of these interesting to get in before freeze? !17891 !19793 !19682 !17649 !19482 !18096
2021-04-04 16:23:32 <dalias> reading old scrollback..
2021-04-04 16:25:00 <ikke> algitbot: ?
2021-04-04 16:25:02 <ikke> andypost: ?
2021-04-04 16:25:12 <ikke> ah
2021-04-04 16:30:21 <andypost> ikke, I mean CI runner's docker
2021-04-04 16:32:31 <ikke> that the job runs already means docker must be running
2021-04-04 16:33:43 <ikke> I've retried it to see if it persists
2021-04-04 16:36:37 <nmeum> ikke: does fzf work for you with the default find command? for me it fails (iirc we had this conversation before)
2021-04-04 16:40:03 <ikke> nmeum: plain `fzf` works for me
2021-04-04 16:40:20 <ikke> nmeum: what's not working for you?
2021-04-04 16:41:02 <nmeum> > [Command failed: set -o pipefail; command find -L . -mindepth 1 \( -path '*/\.*' \) -prune -o -type f -print -o -type l -print 2> /dev/null | cut -b3-]
2021-04-04 16:41:17 <nmeum> but if I set FZF_DEFAULT_COMMAND it works
2021-04-04 16:41:34 <nmeum> e.g. FZF_DEFAULT_COMMAND="fd --type f"
2021-04-04 16:41:38 <ikke> nmeum: I thought we fixed that
2021-04-04 16:41:53 <nmeum> yeah I thought so too, strange that it works for you then
2021-04-04 16:42:01 <ikke> I have find installed
2021-04-04 16:42:19 <ikke> hmm, but even without, it works
2021-04-04 16:42:34 <ikke> ah, ash?
2021-04-04 16:42:40 <nmeum> weird, I can't even find an exec call in the strace
2021-04-04 16:42:45 <ikke> ash does not support pipefail
2021-04-04 16:42:55 <nmeum> I use ksh it should support pipefail
2021-04-04 16:42:56 <ikke> I run zsh
2021-04-04 16:42:58 <ikke> oh, ok
2021-04-04 16:43:00 <nmeum> but let me try with a different shell
2021-04-04 16:44:29 <nmeum> hmhmhm
2021-04-04 16:44:41 <nmeum> now it works in the same shell, maybe it's racy somehow I will investigate this further
2021-04-04 16:44:47 <nmeum> thanks for letting me know that it works for you though :)
2021-04-04 16:44:52 <ikke> np
2021-04-04 18:40:00 <Ariadne> ikke: yes
2021-04-04 18:40:07 <ikke> Ariadne: thanks
2021-04-04 20:59:20 <mps> anyone knows does void linux have -with-mode=thumb for gcc on armv7
2021-04-04 21:08:07 <maxice8> https://github.com/void-linux/void-packages/blob/master/common/build-profiles/armv7l.sh
2021-04-04 21:10:21 <mps> looks like that are options added to xbps build, though I don't know how xbps works
2021-04-04 21:11:18 <mps> I meant to ask, is gcc on armv7 uses -with-mode=thumb by default in void linux
2021-04-05 08:55:27 <mps> interesting, some of next kernel will allow x.x.x.0 as normal IP address
2021-04-05 08:59:20 <mps> ip add route default 192.168.1.0 will be ok
2021-04-05 09:00:08 <mps> network 'version' of /dev/null :)
2021-04-05 09:00:23 <ncopa> depends on the netmask i suppose?
2021-04-05 09:00:32 <mps> no
2021-04-05 09:00:37 <mps> and yes
2021-04-05 09:01:24 <mps> zero (0) will acceptable as last octet for IPv4
2021-04-05 09:02:05 <mps> so, 192.168.1.0/29 as ip address will be ok
2021-04-05 09:02:42 <mps> maybe even 192.168.0.0/16
2021-04-05 09:03:07 <mps> valid ip addresses, I mean
2021-04-05 09:04:05 <mps> looks like I have to by some modern book for kernel and not use these 20 and more years old
2021-04-05 09:11:17 <PureTryOut[m]2> maxice8: hey what happened? I see you're orphaning a ton of packages, do you have no need for them anymore?
2021-04-05 10:21:51 <nmeum> I think maxice8 is simply not using these specific packages anymore
2021-04-05 10:53:07 <maxice8> Not using Alpine on my desktop anymore, orphaning packages I don't use
2021-04-05 14:33:45 <mps> interesting idea for those who wonts/needs high git commits on aports ;)
2021-04-05 14:34:13 <mps> take and remove maintainership of packages daily
2021-04-05 14:35:03 <mps> s/wonts/wants/
2021-04-05 14:35:03 <alpine-meetbot> mps meant to say: interesting idea for those who wants/needs high git commits on aports ;)
2021-04-05 14:47:04 <Ariadne> [03:02:02] <mps> so, 192.168.1.0/29 as ip address will be ok
2021-04-05 14:47:28 <mps> Ariadne: yes
2021-04-05 14:47:32 <Ariadne> technically they have always been valid, but their lack of validity is a side effect in how BSD implemented routing tables (as a trie)
2021-04-05 14:47:41 <mps> right
2021-04-05 14:47:50 <Ariadne> linux, windows, etc copied the BSD implementation
2021-04-05 14:48:18 <mps> I think I read somewhere that it actually work long time on some (OS) systems
2021-04-05 14:48:38 <Ariadne> so what they've done here, is make it possible for a trie node to have subnodes for the host route and the network-wide route
2021-04-05 14:49:08 <Ariadne> in other words, it is possible, but it will be less efficient to contact those hosts
2021-04-05 14:49:10 <mps> 'trie node'?
2021-04-05 14:49:26 <Ariadne> a leaf
2021-04-05 14:49:34 <mps> aha, thanks
2021-04-05 14:49:47 <Ariadne> a node can be either a branch or a leaf
2021-04-05 14:49:53 <mps> right
2021-04-05 14:50:32 <Ariadne> i don't see the point of this over performing ops to reclaim the /6 used for multicast
2021-04-05 14:51:00 <mps> I think that is actually never enforced by any standard, but long time passed when I read these standards
2021-04-05 14:52:03 <mps> if you make /29 split network you will one IP address address, which is about 15% increase :)
2021-04-05 14:52:26 <mps> s/one/none more/
2021-04-05 14:52:26 <alpine-meetbot> mps meant to say: if you make /29 split network you will none more IP address address, which is about 15% increase :)
2021-04-05 14:53:06 <mps> 255 is still reserved for broadcast
2021-04-05 14:55:51 <RootWyrm> linux didn't copy things. they smoked a lot of crack and came up with their own insanity. anyone claiming .0 is 'not a valid address' has been wrong since the advent of classless.
2021-04-05 14:58:46 <mps> well, practically it worked always on linux though with 'strange' behavior, if we want to nitpick
2021-04-05 14:59:00 <RootWyrm> which is, like most things in their ip and routing stack, incorrect behavior.
2021-04-05 15:00:59 <RootWyrm> if i have 10.10.10.0/23, then 10.10.10.255 and 10.10.11.0 are both valid addresses. otherwise, it's not a /23
2021-04-05 15:02:41 <mps> did you check this
2021-04-05 15:04:05 <Ariadne> RootWyrm: Linux NET4 is directly based on the BSD networking stack
2021-04-05 15:05:26 <mps> isn't it rewriten from scratch long ago
2021-04-05 15:05:59 <RootWyrm> Ariadne: except it's not because it has specific broken behaviors all over the place
2021-04-05 15:06:07 <mps> first versions of linux had BSD net stack practically
2021-04-05 15:06:34 <Ariadne> RootWyrm: name me a networking stack that does not have broken behavior :)
2021-04-05 15:06:38 <RootWyrm> nope, not even back in '94. they were getting things horribly wrong then and many of those broken behaviors are still present
2021-04-05 15:07:11 <RootWyrm> Ariadne: FreeBSD. Otherwise, you aren't here, period.
2021-04-05 15:07:23 <mps> RootWyrm: I can't remember dates, but I'm sure that first linux version had BSD based stack
2021-04-05 15:07:27 <RootWyrm> JunOS is FreeBSD. Not a lot of modifications to the base stack.
2021-04-05 15:07:33 <Ariadne> 
ACTION lol

2021-04-05 15:08:08 <Ariadne> JunOS does not use the host networking stack
2021-04-05 15:08:20 <Ariadne> only for connection to the RE for management purposes
2021-04-05 15:08:37 <Ariadne> it pushes the learned routing table directly into the FPCs (line cards)
2021-04-05 15:08:58 <mps> 'JunOS' must be important thing because I can't remember what is/was it ;P
2021-04-05 15:09:14 <Ariadne> the management plane OS that runs on juniper devices
2021-04-05 15:09:29 <Ariadne> also JunOS is being replaced with a Linux-based solution
2021-04-05 15:09:34 <Ariadne> RIP
2021-04-05 15:09:35 <mps> aha, thanks again for reminder
2021-04-05 15:10:06 <Ariadne> there are also plenty of ways to make the FreeBSD networking stack fall over
2021-04-05 15:10:14 <RootWyrm> wow, what? that is ... just ... WOW
2021-04-05 15:10:25 <mps> and long time didn't read 'word' juniper in IT news
2021-04-05 15:10:57 <Ariadne> RootWyrm: yes, they call it JunOS Evolved
2021-04-05 15:11:14 <Ariadne> RootWyrm: it is literally built on linuxkit
2021-04-05 15:11:16 <RootWyrm> Ariadne: lolol that is not even what it is
2021-04-05 15:11:42 <Ariadne> ?
2021-04-05 15:11:52 <Ariadne> i'm ust telling you what they are doing at juniper
2021-04-05 15:12:15 <RootWyrm> but hey. whatever. facebook posts make people virologists, why wouldn't hn crank that up to 11?
2021-04-05 15:12:31 <Ariadne> i do not read hacker news
2021-04-05 15:12:40 <RootWyrm> Ariadne: except that's their SDN stuff following on from contrail
2021-04-05 15:12:46 <RootWyrm> which is not core router
2021-04-05 15:13:11 <Ariadne> RootWyrm: you can run JunOS E on MX
2021-04-05 15:15:00 <RootWyrm> yes, when operating as an edge. where things like 'stability' and 'actually working' are nice-to-haves.
2021-04-05 15:21:35 <Ariadne> RootWyrm: anyway, we are talking aobout 10.10.10.0 being valid in 10.10.10.0/24
2021-04-05 15:22:28 <RootWyrm> ... uh, it's _not_ valid there.
2021-04-05 15:24:40 <Ariadne> it can be, in the way that i described (by allowing 10.10.10.0/32 to have a more specific routing table entry)
2021-04-05 15:25:21 <Ariadne> many networking stacks outside of the BSD-derived ones allow this since day 1 :)
2021-04-05 15:27:05 <RootWyrm> uh, wat?
2021-04-05 15:28:08 <RootWyrm> lo1: inet 172.17.0.0 netmask 0xffffffff
2021-04-05 15:28:16 <RootWyrm> so, also not a correct statement.
2021-04-05 15:28:57 <Ariadne> definitely a correct statement
2021-04-05 15:29:12 <RootWyrm> you literally just said "BSD can't do this"
2021-04-05 15:29:23 <Ariadne> modern BSD can
2021-04-05 15:29:33 <RootWyrm> that ain't 'modern.'
2021-04-05 15:30:03 <Ariadne> when i say "BSD", i talk about the original BSD release back in the 80s :)
2021-04-05 15:30:34 <RootWyrm> which would then make the statement irrelevant since it hasn't been in use since the 80's.
2021-04-05 15:30:57 <Ariadne> no, but the networking stack has been used since the 80's :)
2021-04-05 15:31:12 <RootWyrm> even bsdi/386 could do that.
2021-04-05 15:31:20 <Ariadne> anyway, this conversation is becoming quite hostile
2021-04-05 15:31:26 <Ariadne> so, i am going to step away from it :)
2021-04-05 15:31:54 <Ariadne> RootWyrm: what is this story with NuGet?
2021-04-05 15:32:14 <RootWyrm> what story with nuget?
2021-04-05 15:32:26 <Ariadne> they want us to retain symantec's soon-to-be-expired root certificates for some period of time
2021-04-05 15:32:38 <Ariadne> and plan to "disable signature verification" as a workaround
2021-04-05 15:32:42 <RootWyrm> "they" who?
2021-04-05 15:32:53 <Ariadne> they being Loic Sharma at microsoft
2021-04-05 15:33:26 <Ariadne> https://gitlab.alpinelinux.org/alpine/ca-certificates/-/issues/1
2021-04-05 15:33:45 <RootWyrm> hang on
2021-04-05 15:34:50 <RootWyrm> oh, yeah, no. so you're all wrong.
2021-04-05 15:36:01 <Ariadne> well, a microsoft person reached out to me on twitter and asked if we could retain those CAs for a while, and then loic showed up, and his explanation is a bit... concerning :)
2021-04-05 15:36:30 <RootWyrm> 1) transitioning CAs is not a reasonable ask. the issue is in long lived static packages. you would invalidate and break a LOT of stuff. 2) disabling signature verification is a terrible idea, enough said there.
2021-04-05 15:36:53 <Ariadne> yeah, that makes sense
2021-04-05 15:37:50 <Ariadne> RootWyrm: is it possible to include the trust root with nuget itself?
2021-04-05 15:38:13 <RootWyrm> but nuget lives in it's own special hell that i tend to not be a part of. mono, the solution is to use the separate cert store and retain symantec certs.
2021-04-05 15:38:34 <RootWyrm> but nuget standalone doesn't have an isolated cert store
2021-04-05 15:38:42 <Ariadne> i guess what we can do is add a secondary ca-certificates package for the symantec certs
2021-04-05 15:38:56 <Ariadne> which installs them into the trust store
2021-04-05 15:39:06 <Ariadne> thanks for the background :)
2021-04-05 15:39:15 <mps> wait, RootWyrm is from ms?
2021-04-05 15:40:37 <RootWyrm> sure thing. the real problem is essentially that: nuget relies on code signing certificates. and everybody assumed that CAs wouldn't do stupid shit. (bad assumption.)
2021-04-05 15:40:37 <Ariadne> i mean, i'm not into outing people without their consent
2021-04-05 15:40:58 <RootWyrm> and no, i'm not from MS. not an employee, do not speak for them, etc. I'm part of the .NET Foundation though.
2021-04-05 15:41:25 <Ariadne> isn't that just MS with a different logo at this point
2021-04-05 15:41:26 <Ariadne> lol
2021-04-05 15:41:47 <RootWyrm> don't we fucking wish. then we'd have money.
2021-04-05 15:41:49 <mps> let me look who is behind .NET Foundation
2021-04-05 15:42:50 <Ariadne> ok, 3 "evil" companies and 4 unknown ones
2021-04-05 15:42:52 <Ariadne> ;)
2021-04-05 15:43:26 <RootWyrm> anyhow, the whole way nuget works is: you get a code signing cert (which may have a validity period of basically infinity,) you sign the package with it, then you register the pub on the registry. and because dumb, code signing certificates may not have _any_ expiry from some CAs.
2021-04-05 15:43:44 <Ariadne> yep
2021-04-05 15:44:08 <Ariadne> and then symantec sold their CA and digicert shut it down
2021-04-05 15:44:12 <Ariadne> i got it now :)
2021-04-05 15:44:15 <mps> and cookies to follow us :)
2021-04-05 15:44:51 <RootWyrm> and then, to the surprise of approximately nobody who's actually looked into things, the CAs issuing cheap code signing certs did dumb shit. coupled with "this code hasn't needed to change in 6 years" and yeah, it's just all kinds of fun.
2021-04-05 15:46:00 <RootWyrm> well, this isn't the first rodeo. remember that there was also root CAs that got breached, which issued code signing certs.
2021-04-05 15:46:21 <Ariadne> anyway, gotta run for now
2021-04-05 15:49:35 <mps> always wondered why the web/http cookie are not called by real name "cuckoo's egg"
2021-04-05 15:53:37 <ikke> heh
2021-04-05 16:04:02 <RootWyrm> I pinged some folks to see what's up with NuGet signing plans, got a feeling the answer is "just going away."
2021-04-05 17:54:16 <ncopa> im seeing the end of the tunnel of the python 3.9 rebuilds
2021-04-05 17:54:26 <ikke> wow
2021-04-05 17:54:26 <ncopa> i might push python 3.9 today
2021-04-05 17:54:35 <ikke> firefox is blocking x86
2021-04-05 17:54:38 <Cogitri> Neat
2021-04-05 17:54:41 <Cogitri> Less neat
2021-04-05 17:54:50 <ncopa> less neat indeed :)
2021-04-05 17:55:12 <ericonr> ncopa: do push 3.9.4, 3.9.3 had an ABI break :(
2021-04-05 17:55:33 <ncopa> python 3.9.3?
2021-04-05 17:55:35 <ncopa> ok
2021-04-05 17:55:35 <Cogitri> > out of memory allocating 290004184 bytes after a total of 3305472 bytes
2021-04-05 17:55:36 <Cogitri> Yikes
2021-04-05 17:56:13 <ericonr> ncopa: yes
2021-04-05 17:56:23 <ericonr> 3.9.4 came out yesterday I think
2021-04-05 17:56:52 <ericonr> Cogitri: ikke: hope you're able to solve that, we didn't manage to :/
2021-04-05 17:57:01 <ncopa> i hope i dont need to rebuild all the 1000++ packages due to the ABI breakage....
2021-04-05 17:57:24 <Cogitri> Hm, I don't think we can do much about the OOM w/ FF, can we?
2021-04-05 17:57:35 <ikke> Cogitri: limit jobs?
2021-04-05 17:57:50 <ncopa> i think we can figure out what consumes the memory
2021-04-05 17:57:58 <ncopa> and find some workaround
2021-04-05 17:58:04 <ncopa> what does other distros do?
2021-04-05 17:58:08 <ikke> That machine has 64G of memory
2021-04-05 17:58:31 <ncopa> no wonder it runs out of memory then. firefox uses alot... :)
2021-04-05 17:58:36 <Cogitri> ikke: the problem is that g++ tries to alloc more than 4G per process
2021-04-05 17:58:45 <Cogitri> Maybe we can try w/o -pipe
2021-04-05 17:58:57 <ikke> right, so hence my suggestion to limit the amount of processes
2021-04-05 17:59:24 <ericonr> it runs out of address space, not system memory
2021-04-05 17:59:28 <Cogitri> Yes
2021-04-05 17:59:39 <Cogitri> Because 32-bit it can't allocate more than 4G
2021-04-05 17:59:39 <ikke> oh, like that
2021-04-05 17:59:42 <ikke> understood
2021-04-05 17:59:58 <ncopa> it might be that it tries to allocate based on available memory
2021-04-05 18:00:03 <Cogitri> I'll give w/o -pipe a go in my dev container, could someone disable ff on x86 for the time being?
2021-04-05 18:01:19 <ikke> I can disable it for the time being
2021-04-05 18:02:03 <ikke> it's already disabled on armhf / armv7
2021-04-05 18:02:40 <Cogitri> Oh, okie, wondered how it worked on those already
2021-04-05 18:02:48 <ikke> yeah, me too
2021-04-05 18:03:39 <Cogitri> Hm, there's no flag to disable -pipe in GCC and the FF build system automatically adds it, fun
2021-04-05 18:03:45 <Cogitri> Might as well give clang a go first then
2021-04-05 18:03:50 <ncopa> only 2 packages left for the pytho 3.9 rebuild
2021-04-05 18:04:37 <ncopa> whee!!!! \o/
2021-04-05 18:05:12 <ncopa> now its just to update to python 3.9.4 and rebase again
2021-04-05 18:05:43 <ikke> edge has a bit of catching up to do
2021-04-05 18:05:47 <ikke> x86*
2021-04-05 18:09:07 <ericonr> ncopa: re. 3.9.3, it broke ABI from 3.9.2, 3.9.4 restored it. stuff using cython and the C api can break weirdly due to it; we got an error where running `python setup.py cython` segfaulted
2021-04-05 18:09:52 <ericonr> so you shouldn't have to rebuild locally to test, just be sure to have everything in the builders built with 3.9.4
2021-04-05 18:10:34 <ericonr> they decided to ok a change to a public struct's fields because "the padding made it okay", and then broke 32-bit platforms where the padding *wasn't* ok
2021-04-05 18:13:40 <ncopa> ok. thanks for the heads-up. turs out i was using python 3.9.2
2021-04-05 18:13:52 <ncopa> s/turs/turns/
2021-04-05 18:13:52 <alpine-meetbot> ncopa meant to say: ok. thanks for the heads-up. turns out i was using python 3.9.2
2021-04-05 18:18:42 <ncopa> i wonder if i should just push the 1500 commits or spend a few ours trying to group them into a fewer big commits
2021-04-05 18:22:35 <Cogitri> I'd say either push all of them or make one gigantic py3.9 commit
2021-04-05 18:22:47 <Cogitri> We won't revert them anyway so a giga commit wouldn't be bad
2021-04-05 18:23:22 <ncopa> there are like removal of individual packages, and some new introduced packages and some cleanups etc
2021-04-05 18:23:44 <ncopa> ok, i think I'll just push them as 1500 commits
2021-04-05 18:26:48 <ncopa> i guess I'll have to catch up on some other stuff rest of the week, and then I should start work on getting the 3.14 builders up
2021-04-05 18:27:02 <ncopa> I should also look over abuild and make new release
2021-04-05 18:28:00 <ncopa> python 3.9 pushed!
2021-04-05 18:28:02 <ncopa> \o/
2021-04-05 18:29:50 <ncopa> there was a handful of packages that i didnt have patience for to fix
2021-04-05 18:30:11 <ncopa> i'll let the maintainers of those deal with it
2021-04-05 18:37:37 <ikke> segfault on s390x
2021-04-05 18:38:10 <ikke> make[1]: Leaving directory '/home/buildozer/aports/main/python3/src/Python-3.9.4'
2021-04-05 18:38:12 <ncopa> ugh...
2021-04-05 18:38:13 <ikke> Segmentation fault
2021-04-05 18:38:21 <ikke> in the check function
2021-04-05 18:38:31 <ncopa> i guess that will have to wait til tomorrow...
2021-04-05 18:41:26 <ncopa> ...unless someone else beats me to it
2021-04-05 18:42:13 <ncopa> have a nice evening!
2021-04-05 18:43:10 <ikke> o/
2021-04-05 18:43:19 <ikke> Thanks for your work on this :)
2021-04-05 18:53:22 <omni> cool!
2021-04-05 19:24:11 <omni> there fail2ban failed on x86_64
2021-04-05 19:25:14 <ikke> yes
2021-04-05 19:25:34 <ikke> lots of tests failed, strange
2021-04-05 19:25:54 <omni> has it succeeded on any other arch?
2021-04-05 19:30:39 <omni> doesn't look like it's been run yet
2021-04-05 19:30:57 <ikke> Right
2021-04-05 19:31:25 <omni> but tests are avoided on s390x|mips64|armhf so they shouldn't fail on it
2021-04-05 19:34:34 <ikke> ugh
2021-04-05 19:35:22 <ikke> fail2ban is broken but apparently just ignored
2021-04-05 19:36:36 <omni> disable tests on all archs until python 3.9 is in?
2021-04-05 19:37:08 <ikke> disable fail2ban on all arches? :)
2021-04-05 19:37:51 <omni> well *shrug* I could have a look at it afterwards
2021-04-05 19:38:09 <ikke> these tests seem to indicate fail2ban is broken
2021-04-05 19:38:38 <omni> I'd like to look at brinding py3-adblock back
2021-04-05 19:38:52 <omni> *bringing
2021-04-05 19:39:06 <omni> (how did I even manage to spell to that)
2021-04-05 19:39:52 <mps> grinding* :)
2021-04-05 19:42:41 <omni> yes, I will try to grind py3-adblock back
2021-04-05 19:52:12 <omni> is there a way to undelete aports and preserve previous git history?
2021-04-05 19:53:26 <ikke> I think you can just restore the aport, git should be able to trace back it's history
2021-04-05 19:53:57 <mps> checkout commit before delete?
2021-04-05 19:54:45 <mps> or git rebase
2021-04-05 19:55:36 <omni> oh, yeah
2021-04-05 19:58:04 <mps> heh, also I will never learn git 'fine points'
2021-04-05 19:58:28 <ikke> git checkout <commit> path/to/aports
2021-04-05 19:58:36 <ikke> where <commit> is indeed the commit before the delete
2021-04-05 20:03:02 <omni> yes, I did that previously but didn't check the history, just assumed/feared it would get lost like when you move a file
2021-04-05 20:03:27 <ikke> omni: it's not lost
2021-04-05 20:03:34 <ikke> git does not track moves
2021-04-05 20:03:36 <mps> ca28e4dedb7936b30b3b984048ca8c2eedfa0c2d
2021-04-05 20:03:40 <ikke> it infers them when necessary
2021-04-05 20:04:34 <mps> very shoooort^Wlong line in git commit
2021-04-05 20:05:00 <ikke> wheej
2021-04-05 20:05:44 <mps> gitlab is worse than gitolite, I'll dare to say
2021-04-05 20:06:15 <mps> shame on me why I advocate gitlab
2021-04-05 20:06:33 <mps> advocated*
2021-04-05 20:08:46 <omni> ikke: sure, "lost" then, hard to follow
2021-04-05 20:09:06 <ikke> omni: git log --follow path/to/file
2021-04-05 20:09:56 <omni> thanks!
2021-04-05 20:12:36 <omni> but that doesn't work on whole directories with contents?
2021-04-05 20:12:45 <ikke> sure
2021-04-05 20:13:22 <mps> sometimes I use git reset $commit_id
2021-04-05 20:13:40 <mps> sometimes it works but sometimes doesn't
2021-04-05 20:14:54 <ikke> Can you elaborate?
2021-04-05 20:15:11 <mps> --follow works only for one file
2021-04-05 20:15:31 <mps> ikke: you ask me?
2021-04-05 20:15:47 <ikke> yes, regarding --reset not working
2021-04-05 20:16:16 <mps> git reset sometimes doesn't do what i intend
2021-04-05 20:16:37 <mps> to resurrect removed things
2021-04-05 20:17:03 <ikke> just git reset does not restore files
2021-04-05 20:17:09 <ikke> git checkout
2021-04-05 20:17:16 <mps> git reset --hard $commit_id is safer but as result could be risky
2021-04-05 20:17:27 <ikke> it does something different
2021-04-05 20:17:33 <ikke> it changes your current branch
2021-04-05 20:18:38 <mps> I'm not sure because that was long ago, but I think with git reset I got redmine aport
2021-04-05 20:21:21 <mps> sure, git reset --hard restores deletet files, just checked
2021-04-05 20:21:34 <ikke> yes it does
2021-04-05 20:21:47 <ikke> but you cannot use it to restore deleted aports from the past
2021-04-05 20:22:15 <mps> hmm, then I misunderstood problem 'at desk'
2021-04-05 20:48:57 <omni> 
ACTION impatiently watching paint dry

2021-04-05 21:30:09 <omni> oh no! armv7 & x86 failed at fail2ban
2021-04-05 22:28:03 <omni> go armhf! go x86! 🏎
2021-04-05 22:49:37 <omni> armhf could be the winner! will x86, x86_64 or armv7 catch up? only time will tell!
2021-04-05 23:16:24 <maxice8> working on py3-yarl
2021-04-05 23:18:44 <maxice8> py3-yarl fixed, working on py3-ansicolor
2021-04-05 23:19:51 <maxice8> py3-ansicolor fixed, working  on py3-freezegun
2021-04-06 00:28:38 <omni> inflection-0.5.1.tar.gz: FAILED
2021-04-06 00:34:54 <omni> broken https://distfiles.alpinelinux.org/distfiles/inflection-0.5.1.tar.gz or in retrieval?
2021-04-06 01:42:38 <maxice8> lol ppc64le has python3.8 installed
2021-04-06 01:44:00 <maxice8> and aarch64
2021-04-06 01:50:55 <Ariadne> quality
2021-04-06 02:04:03 <maxice8> as far as I can see they (aarch64|ppc64le) have been building py3.8 modules
2021-04-06 04:32:41 <ikke> hmm
2021-04-06 04:33:59 <ikke> oh, gdb..
2021-04-06 04:34:42 <ikke> oof
2021-04-06 04:38:45 <maxice8> how bad is it ?
2021-04-06 04:39:34 <ikke> packages in main are indeed built against python 3.8
2021-04-06 04:39:41 <ikke> for those arches
2021-04-06 04:41:32 <ikke> I wonder if we could just remove those packages and let the builder rebuild them
2021-04-06 04:45:29 <maxice8> We can try
2021-04-06 04:45:30 <maxice8> we can also try re-using arch="noarch" from other arches and revbump the ones that are arch-specific
2021-04-06 04:46:46 <ikke> the signatures won't match
2021-04-06 04:49:40 <maxice8> oh
2021-04-06 04:50:13 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12579
2021-04-06 05:02:06 <craftyguy> why were many python apps rebuilt?
2021-04-06 05:02:41 <craftyguy> oh, python 3.9
2021-04-06 05:27:47 <ikke> maxice8: py3-tldextract wants to install setuptools_scm, what was the sollution to that?
2021-04-06 05:28:10 <maxice8> remove it and add version =
2021-04-06 05:28:14 <maxice8> I'll take a look
2021-04-06 05:30:05 <ikke> ah, in the setup.pu?
2021-04-06 05:32:10 <maxice8> yeah I'm working on it, i'll make an MR as an example
2021-04-06 06:38:00 <ncopa> morning
2021-04-06 06:38:06 <ikke> Morning
2021-04-06 06:38:17 <ncopa> so ppc64le is broke?
2021-04-06 06:38:27 <ikke> And aarch64
2021-04-06 06:38:56 <ikke> I removed gdb already, but packages need to be rebuilt
2021-04-06 06:39:39 <ncopa> i suggest we purge everythign in ~/packages older than a given timestamp
2021-04-06 06:42:22 <ncopa> find -type f -newer main/ppc64le/python3-3.9.4-r0.apk
2021-04-06 06:42:29 <ncopa> i can handle ppc64le
2021-04-06 06:43:52 <ncopa> ppc64le is handled
2021-04-06 06:51:20 <ncopa> aarch64 is also taken care of now
2021-04-06 07:51:21 <mps> hmm, zathura fail with 'warning: failed to update database table layout: sha256' with latest sqlite-libs
2021-04-06 07:51:50 <mps> rebuild should fix this, I think?
2021-04-06 08:15:39 <ncopa> problem with s390x is that it runs out of stack space
2021-04-06 08:18:52 <Marian[m]1> Is anyone using Alpine on a Raspberry Pi 3B?
2021-04-06 08:28:53 <Newbyte> what's your question?
2021-04-06 08:29:38 <mps> huh, RPI
2021-04-06 08:29:52 <mps> worst arm SBC
2021-04-06 08:30:03 <mps> Marian[m]1: :)
2021-04-06 08:31:17 <Marian[m]1> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/mugBAUZxrkAJBsZEseARsBQT/message.txt >

2021-04-06 08:31:50 <mps> Marian[m]1: I don't but some people told earlier they use RPi3
2021-04-06 08:32:04 <Marian[m]1> Downgrading to older firmware fixes the issue. Second, bluetooth stopped working with todays upgrade / reboot. I haven't found the issue yet.
2021-04-06 08:32:54 <Marian[m]1> I can reproduce the issue with wifi on 4 different Rasberry Pi 3B boards, I'm quite certain it is a software issue. All the same behavior: Downgrade firmware and wifi starts to work again.
2021-04-06 08:33:40 <mps> I have '[    5.540359] cfg80211: failed to load regulatory.db' for long time, but wifi always worked
2021-04-06 08:35:15 <mps> Marian[m]1: you are university professor, iirc?
2021-04-06 08:38:36 <maxice8> How's the process on aarch64 and ppc64le ?
2021-04-06 08:39:43 <mps> Marian[m]1: are you using armv7 or aarch64 flavor on this rpi?
2021-04-06 08:40:28 <Marian[m]1> aarch64
2021-04-06 08:41:15 <mps> I have same error you posted in matrix.org link but wifi works quite fine, aarch64 edge and stable
2021-04-06 08:41:28 <maxice8> looking at libblockdev
2021-04-06 08:41:57 <ncopa> i have an rpi3
2021-04-06 08:42:44 <ncopa> but its not running
2021-04-06 08:42:55 <ncopa> im working on python on s390x. it is running out of stack space
2021-04-06 08:43:43 <ncopa> i wonder if we shoudl increase thread stack space for all arches or only s390x
2021-04-06 08:43:55 <ncopa> s390x has a calling convention that uses more stack
2021-04-06 08:44:13 <mps> omg, no
2021-04-06 08:44:18 <Marian[m]1> @mps: You're also using a system install, don't you?
2021-04-06 08:44:30 <mps> Marian[m]1: yes
2021-04-06 08:44:43 <ncopa> Marian[m]1: is the edge or 3.13.x
2021-04-06 08:44:48 <mps> ncopa: increase it on needed arches
2021-04-06 08:45:04 <ncopa> mps: yeah, i think that makes sense
2021-04-06 08:52:05 <Marian[m]1> mps: edge
2021-04-06 08:54:42 <mps> Marian[m]1: I use mediatek and rockchip arm64, boot works fine with edge
2021-04-06 08:55:01 <Marian[m]1> @mps: what is your kernel cmdline? Maybe that is the issue for me
2021-04-06 08:55:11 <mps> that must be something related to RPi and their firmare, I think
2021-04-06 08:56:07 <mps> here: cros_secure console=tty0 earlyprintk=tty0 init=/sbin/init root=PARTUUID=e18b1d35-2e41-0842-83ca-c4252ab610b7/PARTNROFF=1 rootwait rw noinitrd loglevel=7
2021-04-06 08:56:22 <mps> but I doubt is useful to you
2021-04-06 09:09:00 <Marian[m]1> @mps: Thanks, it was helpful. I had no `cmdline.txt` at all and the default set up ttyAMA0 (used for bluetooth) as console - which obviously broke bluetooth operation :-/
2021-04-06 09:12:21 <mps> heh
2021-04-06 09:54:50 <maxice8> What's the difference between 'aport built' and 'aport total' in build.a.o ?
2021-04-06 10:19:37 <ncopa> maxice8: if there is a push with 10 updates, the "aport built" will show the progress of those 10 packages. "aport total" is the total packages in the repo.
2021-04-06 10:24:50 <maxice8> ty
2021-04-06 10:57:23 <Cogitri> Can I push things again?
2021-04-06 10:57:51 <ikke> I think so, it's just behind all the python packages
2021-04-06 11:01:25 <Cogitri> Okay, wasn't sure how likely the builders are to blow up and I didn't want to inhibit fixing them
2021-04-06 11:02:46 <maxice8> They will just be slotted in between python3 stuff
2021-04-06 11:02:56 <maxice8> if you're lucky they might get built in between the explosions!
2021-04-06 11:03:03 <ikke> especially things in main
2021-04-06 11:03:21 <ikke> they will be built first behind the python stuff after a failure
2021-04-06 11:03:33 <ikke> (because main was already built)
2021-04-06 11:04:35 <ikke> another day, another CVE
2021-04-06 11:04:54 <ikke> DoS
2021-04-06 11:53:27 <indy> hi all, which packaging phase is the best for locating test results (from cmake/ctest), i would like to submit them to azure devops as customer is using it for cd/ci?
2021-04-06 11:54:45 <indy> is builddir removed once abuild finishes job?
2021-04-06 11:55:50 <PureTryOut[m]2> A shocking amount of Python packages seem to download dependencies from Pip rather than use system deps. Actually enforcing `options="!net"` would've given us a whole lot less trouble
2021-04-06 11:57:58 <ddevault> is python broken on edge?
2021-04-06 11:58:47 <ddevault> yes, I see the builders working on 3.9
2021-04-06 11:58:59 <ddevault> it would be nice if large breakages like this could be uploaded atomically
2021-04-06 12:00:04 <minimal> anyone willing to merge !19817? Its been sitting for 6-7 days since I made the last change to it
2021-04-06 12:05:47 <Cogitri> ddevault: Right now it's atomically uploaded, but per-repo
2021-04-06 12:05:56 <ddevault> I see
2021-04-06 12:06:04 <Cogitri> So if the builder is done with main, it'll upload all of main but community is broken
2021-04-06 12:18:07 <mps> minimal: could you tell what it does in a few words (commit msg is riddle for me, and analyzing changes will take some time)
2021-04-06 12:20:19 <minimal> mps: normally when sshd init runs for 1st time it automatically creates DSA, ECDSA, RSA, and ED25519 host keys. This MR lets you configure which of these will be created, instead of all 4, and also lets you control the key bit length of ECDSA and RSA host keys.
2021-04-06 12:20:37 <minimal> its intended for VM and cloud images typically
2021-04-06 12:21:22 <mps> how this is handled by running setup-alpine (install alpine)
2021-04-06 12:21:41 <minimal> its nothing to do with setup-alpine
2021-04-06 12:22:00 <Shiz> lemme see
2021-04-06 12:22:19 <minimal> its to do with openssh-server (and openssh-server-pam)
2021-04-06 12:22:42 <mps> minimal: if it is not related to setup-alpine/setup-sshd why then this is needed at all
2021-04-06 12:22:52 <Shiz> mps: what are you talking about
2021-04-06 12:23:15 <Shiz> minimal: my main concern with this MR is that it makes us liable for the key types generated; if a new key type is added, we'll need to update the script too
2021-04-06 12:23:16 <minimal> mps: as I explained, its for when someone has build their own Alpine images wih sshd - typically for VM or cloud-images
2021-04-06 12:23:24 <mps> Shiz: can't get why this can't be set after installation
2021-04-06 12:23:48 <minimal> so in a VM image the 1st time you create a VM using such an image sshd will want to create SSH host keys
2021-04-06 12:23:48 <Shiz> i still don't get what you're talking about, what does this have to do with installation
2021-04-06 12:24:35 <mps> Shiz: I thought it will somehow change generating keys during installation
2021-04-06 12:24:39 <minimal> mps: you don't install a VM, you create a VM using a OS image which contains no SSH host keys, so the keys are created once that VM 1st runs
2021-04-06 12:25:53 <mps> minimal: you mean prepared VMs will have key, and after you use it to install new VM from it?
2021-04-06 12:26:09 <Hello71> mps: no
2021-04-06 12:26:16 <mps> and you want/need new key
2021-04-06 12:26:33 <minimal> Shiz: the existing ssh init.d runs "ssh-keygen -A" which only generates those 4 types of keys even though there are extra types that could be generated
2021-04-06 12:26:58 <Shiz> minimal: yes, but then the liability lies with openssh to update their keygen tool when they add a new key type
2021-04-06 12:27:00 <Shiz> which they will
2021-04-06 12:27:12 <minimal> mps: prepared VM images will contain *no* keys, otherwise if you created 2 VMs using the same image they would both have the same host keys, which is bad.
2021-04-06 12:27:24 <mps> yes
2021-04-06 12:27:26 <Shiz> (there are no commonly used other types than those 4 right now, and they updated it when they added the ed25519 key type)
2021-04-06 12:27:56 <Shiz> I'm just stating the concern that this will add a maintenance burden, not saying to reject the change, but it is a concern :)
2021-04-06 12:30:36 <minimal> Shiz: I agree that potentially there's a "minor" maintenance burden, as you pointed out other host key types are not typically used. The idea of this change to to improve security - if someone wants to only use ED25519 host keys for "maximum" security then this config lets them ensure other key types won't be created
2021-04-06 12:31:05 <minimal> Shiz: "out of the box" this change acts in the same way as before
2021-04-06 12:32:55 <mps> my opinion it will be set to ED25519 to be default, rest options are on user to set
2021-04-06 12:33:20 <Shiz> no
2021-04-06 12:34:39 <Shiz> minimal: aside from some minor stylistic things (I'd use ${bit_size:+-b $bit_size} in the command line directly and just set it from an eval, removing some more complex logic), the rest of the MR lgtm
2021-04-06 12:34:44 <Shiz> (but notably it's not my decision to make)
2021-04-06 12:35:37 <minimal> ncopa is the maintainer but obviously he's up to his neck with Python currently
2021-04-06 12:37:29 <minimal> I'd expect mcrute to be interested in it for the Alpine AWS images he builds
2021-04-06 12:46:35 <minimal> Shiz: any chance you could give the MR a thumb-up if you're happy?
2021-04-06 14:46:23 <ncopa> minimal: as I understand this is needed due to some cloud providers has allow/deny-lists for what keys are allowed?
2021-04-06 14:48:27 <minimal> ncopa: it need as any Alpine VM or Cloud images will have no SSH host keys contained in them and so the keys will be automatically generated when sshd runs during 1st boot. This MR allows the image creator to define which types of host key (and the key bit length of some of them) will be created.
2021-04-06 14:49:04 <minimal> its a security-related change - enabled the image creator to define a more restrictive host key policy
2021-04-06 14:49:40 <ncopa> who is imposing those policies? the cloud provider?
2021-04-06 14:49:55 <minimal> the person creating the OS image
2021-04-06 14:50:08 <ncopa> oh , ok
2021-04-06 14:50:25 <minimal> so for example mcrute may be interested in this for the AWS Alpine images he builfs
2021-04-06 14:50:35 <minimal> s/builfs/builds/
2021-04-06 14:50:35 <alpine-meetbot> minimal meant to say: so for example mcrute may be interested in this for the AWS Alpine images he builds
2021-04-06 14:50:48 <ncopa> so its not the cloud provider that prevents you to use certain ssh host keys
2021-04-06 14:51:21 <ncopa> i had the impression that could providers requires you to use specific host keys, or forbids you to use some host keys
2021-04-06 14:51:27 <minimal> nope, host keys have always been created by /etc/init.d/sshd (it typically calls "ssh-keygen -A")
2021-04-06 14:51:45 <ncopa> so it basically does not have anything to do with could providers
2021-04-06 14:52:06 <minimal> if any of DSA/ECDSA/ED25519/RSA host key files are missing then "ssh-keygen -A" will generate them
2021-04-06 14:52:44 <ncopa> yes, i understand that. that is how upstream openssh works
2021-04-06 14:53:44 <minimal> yupe, my MR is to change that "blind" lets ensure that all of the 4 types are present logic to be configurable to "lets ensure that the intended key type(s) are present"
2021-04-06 14:54:16 <minimal> so in my local (KVM) case I only want ED25519 host keys generated
2021-04-06 14:56:18 <ikke> Just out of curiosity, does it matter what keys the set offers?
2021-04-06 14:59:18 <ikke> As a client, you could restrict what keys you trust
2021-04-06 15:03:20 <ncopa> I also share Shiz's concern that we need to maintain the key list. If the ssh-keygen -A list changes upstream for whatever reason, we will very likely miss it and use old default list
2021-04-06 15:03:51 <minimal> ikke: this is from a server perspective, so when hardening a machine I'll change /etc/ssh/sshd_config to only load ed25519. However in case that config accidently gets changed (defaulted) to load other key types I don't want the other key type files around to be accidentally used
2021-04-06 15:03:54 <minimal> ncopa:
2021-04-06 15:04:41 <Shiz> how about that if the key list is empty, we do -A
2021-04-06 15:04:46 <Shiz> if it's specified, we generate those types
2021-04-06 15:04:52 <Shiz> then default it to empty
2021-04-06 15:04:54 <ncopa> thats definitively better
2021-04-06 15:06:22 <minimal> ncopa: all I can say is that the ssh-keygen manpage indicates "-A" is only intended to generate those specific 4 types, not all key types that may be added (there are other types already not generated)
2021-04-06 15:07:29 <Shiz> that is true, but it was updated for ed25519
2021-04-06 15:08:07 <ncopa> the other thing i'm thinking of is that we can not be the only ones having this problem. how does other distros handle it?
2021-04-06 15:10:30 <ncopa> seems like the official way is to use `ssh-keygen -A` and then use HostKeyAlgorithms in /etc/ssh/sshd_config to restrict what keys/algos to use. https://security.stackexchange.com/a/159269
2021-04-06 15:11:54 <ncopa> It is also questionable to why you would want restrict some of those keys https://security.stackexchange.com/a/29267
2021-04-06 15:12:29 <minimal> ncopa: its a OS image issue rather a distro issue. E.g. for Debian maybe Debian Cloud images do this
2021-04-06 15:12:48 <ncopa> how they do it?
2021-04-06 15:12:49 <ikke> This is not restricted to cloud images
2021-04-06 15:13:11 <ikke> Hosts would need this as well
2021-04-06 15:13:24 <ikke> Bare metal
2021-04-06 15:15:47 <minimal> ikke: yeah I'm actually using it for bare metal as well as KVM VMs
2021-04-06 15:16:46 <minimal> Shiz: an earlier version of the MR still used "ssh-keygen -A" when the key list was empty - however when I added the configurable key lengths for ECDSA and RSA I had to stop using "-A" in that scenario
2021-04-06 15:17:19 <minimal> I guess I could add a fallback-fallback where if key list is empty and key length settings are both empty then use "-A" :-)
2021-04-06 15:19:57 <minimal> ncopa: that stackexchange article doesn't mention ED25519 and its from 2013 so may or may not be relevant for today's security situations...
2021-04-06 15:20:10 <Ariadne> oh, good
2021-04-06 15:20:16 <Ariadne> somebody is writing a replacement for GNU dialog
2021-04-06 15:26:33 <minimal> ncopa: an example document that shows disabling of some SSH host key types plus re-generating key types with longer key bit lengths: https://www.sshaudit.com/hardening_guides.html
2021-04-06 16:12:37 <ikke> PureTryOut[m]2: These packages are missing dependencies. setuptools tries to compensate by installing the packages through pip, but because we don't have pip shipped with python3 (on purpose), it cannot automatically install them
2021-04-06 16:12:45 <RootWyrm> ncopa: redhat doesn't handle it correctly, fyi
2021-04-06 16:12:58 <ikke> Because this has been the case for quite some time, lots of packages are missing dependencies
2021-04-06 16:50:34 <craftyguy> quite a few py3 packages seems to be signed with some unknown (to my install) key, is that expected?
2021-04-06 16:50:51 <craftyguy> e.g. ERROR: py3-requests-2.25.1-r3: BAD signature
2021-04-06 16:51:28 <ikke> what arch?
2021-04-06 16:51:39 <craftyguy> aarch64
2021-04-06 16:52:10 <ikke> that explains
2021-04-06 16:52:44 <ikke> We had to purge packages built since yesterday as the python3.9 rebuild was bodged for aarch64
2021-04-06 16:52:51 <ikke> but dl-cdn still had the old package in cache
2021-04-06 16:52:57 <ikke> We need to purge it
2021-04-06 16:53:02 <craftyguy> ah. but they signing key changed?
2021-04-06 16:53:10 <ikke> not the key
2021-04-06 16:53:16 <ikke> but the signature recorded in the apkindex
2021-04-06 16:53:54 <craftyguy> ok, so I just need to wait for things to get rebuilt and trickle down to the dl-cdn mirrors?
2021-04-06 16:54:44 <ikke> craftyguy: I can purge the cache on dl-cdn so that it's forced to download the rebuilt package
2021-04-06 16:55:16 <craftyguy> ok that might be helpful for others too
2021-04-06 16:55:21 <craftyguy> thank you
2021-04-06 16:55:24 <ikke> yeah
2021-04-06 17:15:28 <ikke> craftyguy: for now, could you give a list of packages that you have issues with? Then I can quickly purge those while working on a more exhaustive method
2021-04-06 17:18:35 <craftyguy> ikke: ya one sec
2021-04-06 17:19:01 <RootWyrm> ikke: sounds like it needs a varnish rule
2021-04-06 17:19:27 <ikke> RootWyrm: we have looked into it in the past, but could not find something trivial
2021-04-06 17:20:01 <RootWyrm> it's not /strictly/ trivial, no. it's been a while since i've written them so i gotta dredge my old configs.
2021-04-06 17:20:03 <craftyguy> ikke: https://bpa.st/raw/27WQ
2021-04-06 17:20:13 <ikke> craftyguy: thanks
2021-04-06 17:20:27 <craftyguy> I can strip the version off and just give a list of packages if that's more helpful
2021-04-06 17:21:06 <ikke> I need the version
2021-04-06 17:21:08 <RootWyrm> basically need a cache control pragma on the origin side and i think i had some health checks to trigger certain things.
2021-04-06 17:21:33 <ikke> RootWyrm: note that dl-cdn is backed by vastly
2021-04-06 17:21:51 <RootWyrm> ikke: yes, i'm familiar, hence why i said varnish. i'm also a fastly user.
2021-04-06 17:22:02 <ikke> ok
2021-04-06 17:24:15 <RootWyrm> I know it was shenanigans with beresp.http.Surrogate-Control and beresp.http.Cache-Control to force a check every ~60 minutes
2021-04-06 17:29:03 <ikke> craftyguy: can you retry?
2021-04-06 17:30:25 <craftyguy> yep
2021-04-06 17:31:21 <craftyguy> ikke: nice, they all upgraded. thank you :)
2021-04-06 18:46:39 <PureTryOut[m]2> ikke: I know what is happening. Like I said this would've been caught way earlier if network access was blocked, so setuptools couldn't install it even if it wanted too
2021-04-06 18:46:56 <ikke> PureTryOut[m]2: not on the builders
2021-04-06 18:47:03 <ikke> or CI
2021-04-06 18:47:46 <PureTryOut[m]2> Of course it would've on CI. Right now network access in build stage isn't blocked there, but it would've been caught when the package got upgraded if it was blocked
2021-04-06 18:48:58 <ikke> We need a good way to block network access without relying on bubblewrap
2021-04-06 18:49:18 <ikke> A crude way would be to just block DNS somehow
2021-04-06 18:50:19 <PureTryOut[m]2> I guess bubblewrap can't be used in containers?
2021-04-06 18:50:27 <ikke> PureTryOut[m]2: (Sorry, I misunderstood what you were initially saying)
2021-04-06 18:50:35 <ikke> PureTryOut[m]2: correct, it requires SYS_CAP_ADMIN
2021-04-06 18:50:47 <ikke> which, as you hopefully understand, is not desired
2021-04-06 18:50:47 <PureTryOut[m]2> Ah too bad
2021-04-06 18:50:55 <PureTryOut[m]2> Yeah I do 😉
2021-04-06 18:55:06 <ikke> Hmm
2021-04-06 18:55:17 <ikke> I just tried it again, it seems to work in my container now
2021-04-06 18:56:38 <ikke> (lxc)
2021-04-06 18:58:31 <RootWyrm> just create with a null network
2021-04-06 18:59:17 <ikke> It does need networking
2021-04-06 18:59:23 <ikke> just not during the build/package phase
2021-04-06 18:59:34 <ikke> prepare/build/check/package
2021-04-06 18:59:53 <PureTryOut[m]2> Oh that would be good then if it just works
2021-04-06 18:59:55 <ikke> It needs to be able to fetch packages that are declared as dependencies
2021-04-06 18:59:57 <RootWyrm> would need to do retrieval outside the container if the package build is in the container
2021-04-06 19:00:18 <ikke> RootWyrm: That's a larger change
2021-04-06 19:00:27 <RootWyrm> which means prefetching the whole shebang, which isn't too terrible, but yes. it's a big change.
2021-04-06 19:00:54 <PureTryOut[m]2> hmm? building without networking already works with `abuild rootbld`
2021-04-06 19:00:55 <ikke> RootWyrm: rootbuild, if it works, pretty much covers it
2021-04-06 19:01:03 <ikke> PureTryOut[m]2: building, not fetching sources
2021-04-06 19:01:12 <PureTryOut[m]2> Yes that is what I'm saying
2021-04-06 19:01:28 <PureTryOut[m]2> Obviously you need network access to fetch the sources lol
2021-04-06 19:01:39 <ikke> PureTryOut[m]2: I'm not sure what you were replying to then
2021-04-06 19:02:26 <PureTryOut[m]2> In response to RootWyrm saying you need to do some special things for retrieving sources etc. Building without network access already works, if you use rootbld
2021-04-06 19:04:34 <ikke> PureTryOut[m]2: in docker it's not working though
2021-04-06 19:04:44 <PureTryOut[m]2> Ah darn
2021-04-06 19:05:01 <detha> ikke: what probably works is only allowing network access through a proxy, and only setting http[s]_proxy when desired
2021-04-06 19:05:14 <detha> (that bites me every time here)
2021-04-06 19:05:43 <afontain_> what bites?
2021-04-06 19:06:38 <detha> for $reasons, network access is limited to a proxy. There is a ridiculous number of things that assumes direct internet access is a right
2021-04-06 19:07:52 <afontain_> maybe doing some tricks with veth or network bridges could help
2021-04-06 19:07:55 <afontain_> (I never tried)
2021-04-06 19:08:09 <afontain_> so that you can enable or disable the interface at wish
2021-04-06 19:08:35 <detha> run in a different netns?
2021-04-06 19:09:00 <afontain_> ^
2021-04-06 19:11:07 <Hello71> shouldn't it be possible to run unshare -Un in docker?
2021-04-06 19:11:26 <ikke> unshare: unshare(0x0): Operation not permitted
2021-04-06 19:16:34 <Hello71> hm.
2021-04-06 19:16:41 <Hello71> why is it 0x0
2021-04-06 19:16:48 <ikke> I did not give parameters
2021-04-06 19:16:50 <Hello71> oh, seccomp
2021-04-06 19:16:55 <ikke> unshare: unshare(0x50000000): Operation not permitted
2021-04-06 19:18:12 <Hello71> it "requires CAP_SYS_ADMIN" in the sense that docker automatically allows it with --cap-add=CAP_SYS_ADMIN
2021-04-06 19:19:20 <ikke> right
2021-04-06 19:19:50 <ikke> but I ran into issues before with lxc as well
2021-04-06 19:19:55 <ikke> but now it seems to just work
2021-04-06 19:46:02 <Ariadne> detha: idea: tap device which speaks ip and then tunnels everything through a proxy
2021-04-06 19:54:25 <Hello71> if you can add a tuntap device why not just use iptables
2021-04-06 19:54:31 <Hello71> (netfilter)
2021-04-06 20:05:33 <Ariadne> because that is significantly more cpu intensive
2021-04-06 20:05:41 <Ariadne> you can just default-route the tunnel
2021-04-06 20:46:28 <Hello71> not sure what use case you're talking about
2021-04-06 20:46:42 <Hello71> iptables -m uid would be much much faster than anything tuntap based
2021-04-06 20:46:55 <Hello71> but your match condition would need to be iptables/netfilter compatible
2021-04-06 20:58:30 <Ariadne> netfilter is not faster than a routing table lookup
2021-04-06 23:47:57 <maxice8> py3-fsspec is failing on ppc64le because it has the wrong source archive
2021-04-07 04:49:50 <maxice8> looking at py3-gnupg
2021-04-07 04:50:54 <ikke> a test failure
2021-04-07 04:55:37 <maxice8> mercurial on x86 is having test failures
2021-04-07 05:00:45 <ikke> on other arches as well
2021-04-07 05:01:55 <ikke> s390x, mips64
2021-04-07 05:02:05 <ikke> aarch64
2021-04-07 07:46:06 <mps> is the aarch64 'BAD signature' fixed, or we have to wait
2021-04-07 08:06:48 <ncopa> im working on it, but it seems like the hostname is not set in the dhcp request
2021-04-07 08:08:18 <ncopa> build-edge-aarch64 [~]# (ps xa | grep udhcp && cat /etc/network/interfaces ) | tpaste
2021-04-07 08:08:18 <ncopa> https://tpaste.us/byoZ
2021-04-07 08:08:32 <ncopa> i wonder if that is related the ifupdown-ng update?
2021-04-07 08:09:59 <ikke> ncopa: there is a setting now
2021-04-07 08:11:24 <mps> huh, -ng (Not Good), usually sign of it :)
2021-04-07 08:12:15 <ikke> use_hostname_for_dhcp
2021-04-07 08:12:31 <ikke> https://github.com/ifupdown-ng/ifupdown-ng/blob/master/doc/ADMIN-GUIDE.md#ifupdown-ng-configuration
2021-04-07 08:12:47 <ncopa> i think there was a hack to make it backwards compatible with current `hostname $(hostname)` configs
2021-04-07 08:13:16 <ikke> That setting is the official replacement
2021-04-07 08:13:42 <ncopa> use_hostname_for_dhcp does not seem to help
2021-04-07 08:14:02 <ncopa> ifupdown-ng-0.11.0-r0
2021-04-07 08:16:06 <ikke> It worked before
2021-04-07 08:16:30 <ncopa> "$IF_DHCP_HOSTNAME" does not appear to be set
2021-04-07 08:16:31 <ikke> Did you add it to the config file?
2021-04-07 08:16:35 <ncopa> yes
2021-04-07 08:21:33 <ncopa> its a regression
2021-04-07 08:36:31 <ncopa> mps: i have purged the cdn cache for all aarch64 packages newer than python 3.9.4-r0
2021-04-07 08:36:37 <ncopa> so the cache should be ok now
2021-04-07 08:37:10 <ncopa> let me do the same with ppc64le
2021-04-07 08:44:12 <mps> ncopa: looks like it is ok now, thanks
2021-04-07 08:55:17 <maxice8> some packages depend on mercurial and need to be disabled too
2021-04-07 09:38:06 <ncopa> 👍
2021-04-07 10:43:08 <ikke> ncopa: dnsrobocert checksum is failing again
2021-04-07 10:43:31 <ikke> You fixed it 5 days ago
2021-04-07 10:45:03 <ikke> Oh, I had it set to fetch from distfiles
2021-04-07 11:08:54 <ikke> andypost: you upgraded protobuf, but not rebuilt dependencies
2021-04-07 11:17:48 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20237
2021-04-07 11:17:53 <ikke> !20237
2021-04-07 11:21:51 <ikke> uhh: "protobuf-dev (no such package)"
2021-04-07 11:22:21 <ikke> fun
2021-04-07 11:22:48 <ikke> we'll lose a lot of packages on 32-bits due to thsi
2021-04-07 11:24:34 <ikke> #12584 !14682
2021-04-07 11:24:47 <ikke> !14628
2021-04-07 11:25:25 <Cogitri> Oof
2021-04-07 15:18:23 <Ariadne> ncopa: looking into the dhcp regression
2021-04-07 15:20:56 <ncopa> thanks
2021-04-07 15:21:15 <ncopa> im banging my head into the protobuf testsuite
2021-04-07 15:21:43 <ikke> What is it failing on?
2021-04-07 15:21:58 <ncopa> there are 4 tests that fails on 32 bit
2021-04-07 15:22:07 <ncopa> i disabled those and reported it upstream
2021-04-07 15:22:24 <ncopa> a couple of them caught my attention
2021-04-07 15:23:09 <ncopa> involves something that is called SpaceUsed() which calculate how much space is used
2021-04-07 15:23:29 <ncopa> interestingly enough, it reports that it uses more on 32 bit than on 64 bit
2021-04-07 15:24:36 <ncopa> i kinda thought it had to do with pointer sizes, but I would have expected that it would use more on 64 bit
2021-04-07 15:24:40 <ncopa> but i think i have found it
2021-04-07 15:26:38 <ncopa> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/arena.cc#L424
2021-04-07 15:26:55 <ncopa> sizeof(AllocationPolicy) is smaller on 32 bit than on 64bit
2021-04-07 15:41:29 <Ariadne> i think google just assumes 32-bit doesn't exist anymore
2021-04-07 15:41:31 <Ariadne> :)
2021-04-07 15:41:48 <hg> Ariadne: what's a 32?
2021-04-07 15:42:00 <hg> :)
2021-04-07 15:43:36 <Ariadne> ncopa: dhcp hostname fixed.  when barbarossa (a debian person working on ifupdown-ng) converted the dhcp terms into the semantic dhcp vocabulary, he forgot about the special handling that hostname has to make $(hostname) work
2021-04-07 15:44:11 <Ariadne> i wrote a regression test for it
2021-04-07 15:44:15 <ikke> nice
2021-04-07 15:48:34 <ikke> Ariadne: ifupdown-ng fails some tests on aarch64
2021-04-07 15:49:02 <Ariadne> thats because ncopa did `set -x` on the dhcp executo
2021-04-07 15:49:03 <Ariadne> r
2021-04-07 15:49:11 <ikke> oh
2021-04-07 15:49:16 <ericonr> Ariadne: I'd expect protobuf to work on 32bit devices, given that it can be useful with microcontrollers and such :/
2021-04-07 15:49:45 <ericonr> anyway, at least for a chromium OS project I touched, I was informed they don't even have infra set up to run 32-bit tests for that
2021-04-07 15:49:48 <Ariadne> though i guess we should fix that and always use the executors bundled with ifupdown-ng
2021-04-07 15:49:50 <ikke> ericonr: your complaint should be towrads googlee
2021-04-07 15:50:13 <ericonr> ikke: oh yeah, they syck
2021-04-07 15:50:16 <ericonr> suck
2021-04-07 15:50:33 <ericonr> it's just of all their shit, I expected protobuf to be the least fucked ;)
2021-04-07 15:50:51 <ikke> Any of the packages listed here would not work anymore on 32-bits arches if protobuf is missing: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20237/commits
2021-04-07 15:50:58 <ikke> s/Any/None
2021-04-07 15:50:58 <alpine-meetbot> ikke meant to say: None of the packages listed here would not work anymore on 32-bits arches if protobuf is missing: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20237/commits
2021-04-07 15:52:01 <ikke> Ariadne: should that be fixed on the aarch64 host?
2021-04-07 15:52:08 <Ariadne> yes
2021-04-07 15:52:26 <Ariadne> /usr/libexec/ifupdown-ng/dhcp
2021-04-07 15:52:59 <ikke> fixed
2021-04-07 16:15:25 <RootWyrm> Ariadne: btw, chimed in on https://gitlab.alpinelinux.org/alpine/ca-certificates/-/issues/1 - no ETA on the timestamping stuff as of yet.
2021-04-07 16:15:40 <Ariadne> RootWyrm: thanks for your input
2021-04-07 16:15:56 <Ariadne> i presume you intend to nudge them in a... better direction
2021-04-07 16:15:58 <RootWyrm> The big thing is the NuGet tracking issue
2021-04-07 16:16:15 <Ariadne> disabling signature verification seems bad
2021-04-07 16:16:27 <Cogitri> Is someone looking into the protobuf fallout already w/ protobuf-c or can I pkgrel bump that?
2021-04-07 16:16:35 <RootWyrm> That's the better direction, the timestamping stuff. But it's not ready yet. Been on the 'eventually' list ... well ... uh ... what year is it again?
2021-04-07 16:17:14 <RootWyrm> The timestamping they're talking about is RFC 5816
2021-04-07 16:17:24 <Ariadne> thats what i assumed
2021-04-07 16:17:52 <RootWyrm> Yeah. It's just been on the back burner for a REALLY damn long time because ... I honestly don't know why.
2021-04-07 16:18:08 <Ariadne> well i think it is ok to include the symantec certs for some period of time
2021-04-07 16:18:14 <Ariadne> in a subpackage
2021-04-07 16:18:38 <RootWyrm> Yeah, that's easy to back out later too.
2021-04-07 16:18:38 <Ariadne> if they are expired, they can't be used in a browser or whatever anyway
2021-04-07 16:18:46 <Ariadne> so risk is minimal
2021-04-07 16:18:57 <RootWyrm> "Don't need 'em, apk del ca-certificates-symantec"
2021-04-07 16:19:15 <ikke> Cogitri: !20237
2021-04-07 16:19:16 <RootWyrm> Also as I mentioned, it's a very minor impact with the Docker builds.
2021-04-07 16:21:47 <Cogitri> ikke: Whoops
2021-04-07 16:21:49 <RootWyrm> Ariadne: is this going to affect 3.12 as well?
2021-04-07 16:21:55 <Ariadne> no
2021-04-07 16:22:10 <RootWyrm> OK so it'd only impact .NET 5 and later
2021-04-07 16:22:14 <Ariadne> we generally don't update ca-certificates in previous releases
2021-04-07 16:22:26 <ikke> Cogitri: that's how I realized that it was disabeled on 32-bits
2021-04-07 16:22:33 <ikke> and the impact
2021-04-07 16:22:34 <Ariadne> unless there is some compelling reason
2021-04-07 16:24:05 <dalias> related: i wish browsers had ux to "detrust" bad root CAs without deleting them
2021-04-07 16:24:15 <dalias> so that, when you navigate to a site using them
2021-04-07 16:24:23 <Cogitri> ikke: Oh, can we merge that now that protobuf is enabled again?
2021-04-07 16:24:36 <ikke> Cogitri: waiting for the pipeline to succeed
2021-04-07 16:24:40 <dalias> instead of just a generic cert error you'd see "this site's certificate is signed by a root CA you detrusted..."
2021-04-07 16:24:49 <dalias> with a manual per-site "allow" option
2021-04-07 16:28:18 <RootWyrm> Ariadne: well, most folks consider 'actively untrusted certs' a compelling reason ;)
2021-04-07 16:29:06 <Cogitri> ikke: Okie
2021-04-07 16:29:09 <RootWyrm> and there is a means to untrust via CRL
2021-04-07 16:29:25 <RootWyrm> i.e. Symantec would be cessationOfOperation in a CRL
2021-04-07 16:36:09 <Ariadne> i think what dalias was saying is that he would like to see it be easier to make such a CRL
2021-04-07 16:36:21 <Ariadne> i.e. click symantec cert, click detrust, done
2021-04-07 16:39:01 <Hello71> firefox already has this?
2021-04-07 16:39:16 <dalias> hello71, not with the ux i described
2021-04-07 16:39:42 <dalias> specifically, being informed that the site's cert was signed by a detrusted ca rather than just being invalid
2021-04-07 16:39:47 <Hello71> i mean you can't do it strictly as specified
2021-04-07 16:39:51 <dalias> with the option to "retrust this ca, but only for this site"
2021-04-07 16:39:58 <Hello71> because there may be multiple possible certification paths
2021-04-07 16:40:48 <dalias> there's one really shitty root CA, i forget which one but they were implicated in some involvement with a backdoor business and broke root CA rules a few times
2021-04-07 16:41:14 <dalias> and i deleted them, but i have one credit card whose payment site uses them >_<
2021-04-07 16:41:54 <dalias> and to be able to pay i have to open developer console, find the subdomains that are not working, try to open those api urls manually in a new tab, then accept and save the "invalid" cert
2021-04-07 16:41:59 <dalias> and redo this if the cert ever changes
2021-04-07 16:42:32 <dalias> i want to just have a prompt that says "yourshittycreditcard.com is using a certificate signed by a root CA you chose not to trust. would you like to trust it for this site only?"
2021-04-07 16:44:03 <dalias> oh and to make it even more fun, it's an amazon store card, and since it's not a physical card you can use anywhere else, they never even sent me the full card number, so it's impossible to call and pay by phone. the site with the broken cert is the ONLY way to pay
2021-04-07 16:45:07 <dalias> i would just not use it, but the 5% back is really nice and more than pays for my prime membership
2021-04-07 16:52:10 <Ariadne> dalias: but it's bank level security
2021-04-07 16:52:17 <Ariadne> why do you doubt it
2021-04-07 16:52:17 <Ariadne> :D
2021-04-07 16:53:17 <[[sroracle]]> thanks for reminding me to remove the horrible MITM certificate i needed to install for work
2021-04-07 16:53:19 <dalias> of course they want to do business with the same CA who's selling backdoors to the backdoor enterprise MITM company they buy their asset control shit from :-p
2021-04-07 16:56:02 <ikke> Cogitri: s390x succeeded :_
2021-04-07 16:56:06 <ikke> :)
2021-04-07 17:05:27 <Cogitri> Yay :D
2021-04-07 17:10:20 <ikke> 3/6 succeeded (funnily enough, 32-bits is behind)
2021-04-07 17:46:15 <andypost[m]> The new release is soon  https://github.com/protocolbuffers/protobuf/releases/tag/v3.16.0-rc1 it will need to bump all again, foes it make sense for 3.15?
2021-04-07 17:46:40 <andypost[m]> *does
2021-04-07 17:46:41 <Ariadne> depends on how bad the pain level is
2021-04-07 17:47:38 <andypost[m]> I mean pb has monthly release cycle and it's pain to bump it so often
2021-04-07 17:48:04 <Cogitri> Well if tests worked and we didn't have to re-enable it's it's not too bad really
2021-04-07 17:48:13 <Cogitri> And if it weren't in the middle of py3.9 rebuilds
2021-04-07 17:49:19 <ikke> andypost[m]: we _need_ to rebuild, otherwise packages are broken
2021-04-07 17:49:48 <andypost[m]> Main problem is to split dependency bumps to fit into CI
2021-04-07 17:50:03 <ikke> andypost[m]: we can split them per repo
2021-04-07 17:50:07 <ikke> main / community / testing
2021-04-07 17:50:08 <Cogitri> Yup
2021-04-07 17:50:21 <andypost[m]> That's where I stuck in icu upgrade
2021-04-07 17:50:23 <Cogitri> And IMHO building them on one arch should be sufficient
2021-04-07 17:50:53 <Cogitri> As in build icu/protobuf once on all arches, build rebuilds only on one arch (e.g. in a dev container)
2021-04-07 17:50:56 <ikke> yeah, I pushed them, even though the job was stopped due to timeout
2021-04-07 17:51:17 <Cogitri> Yeah, I doubt such rebuilds would fail on one arch but not another
2021-04-07 17:51:38 <Cogitri> Or rather it's so rare that it's ok to just risk it and fix the builders if it really does go wrong
2021-04-07 17:54:11 <ikke> Cogitri: in this case is was good, in that it caught the 32-bits issue :)
2021-04-07 17:55:31 <Cogitri> Fair, but if the same person does all of that at the same time something like that couldn't happen
2021-04-07 17:55:59 <ikke> right
2021-04-07 17:56:07 <ikke> they would've just disabled it :P
2021-04-07 18:06:11 <andypost> is there a reason to have gtest in main and rebuild it every aport? https://gitlab.alpinelinux.org/search?utf8=%E2%9C%93&search=googletest%2Farchive&group_id=2&project_id=1&scope=&search_code=true&snippets=false&repository_ref=master&nav_source=navbar
2021-04-07 18:07:36 <Ariadne> the embedded gtests should not be used ideally, but it involves fixing each packagee by hand
2021-04-07 18:20:44 <Cogitri> It's not ideal but not too much of a problem since it's just for the test executables, isn't it?
2021-04-07 18:30:07 <Hello71> dalias: there are a number of really shitty root CAs ;)
2021-04-07 18:33:59 <dalias> :)
2021-04-07 18:34:19 <dalias> browsers should really just announce an EOL on all but LE
2021-04-07 18:36:22 <PureTryOut[m]2> Cogitri: it is just for tests yes. gtest, at least in the past, was made to be embedded so all projects use it like that. Annoyingly
2021-04-07 18:36:48 <dalias> i hate gtest
2021-04-07 18:37:01 <Ariadne> me too
2021-04-07 18:37:21 <dalias> and i hate packages that make it hard or nonobvious to build without building their tests
2021-04-07 18:37:27 <Ariadne> i tried to use it for something and found myself unimpressed with it
2021-04-07 18:37:33 <dalias> once i wasted like an hour getting a broken build to compile...
2021-04-07 18:37:45 <PureTryOut[m]2> Same
2021-04-07 18:37:57 <ikke> hmm, libphonenumber failed on s390x
2021-04-07 18:37:59 <dalias> only to find out that the project itself was all just python source files that didnt need to be compiled at all and the build was failing in useless tests that needed C test framework shit
2021-04-07 18:38:02 <ikke> -Werror
2021-04-07 18:38:10 <Ariadne> ikke: well i do not think anyone is going to make phone calls on a mainframe
2021-04-07 18:38:14 <PureTryOut[m]2> ikke: in case of libphonenumber, always retry it at least 2 times first before you look into it
2021-04-07 18:38:22 <PureTryOut[m]2> And yeah I doubt anyone needs it on s390x lol
2021-04-07 18:38:23 <ikke> PureTryOut[m]2: heh
2021-04-07 18:38:29 <Ariadne> that sounds terrifying
2021-04-07 18:38:36 <Ariadne> can we figure out why it needs to be retried
2021-04-07 18:38:41 <dalias> dogma around tests is so stupid. tests are for developers and *maybe* for distros
2021-04-07 18:38:44 <dalias> not for end users
2021-04-07 18:38:57 <dalias> but mainly for developers
2021-04-07 18:39:47 <ikke> integration tests can be usefull for distros
2021-04-07 18:39:51 <ikke> unittests less so
2021-04-07 18:40:48 <dalias> yeah
2021-04-07 18:41:04 <Ariadne> all of my stuff does integration tests mostly
2021-04-07 18:41:10 <Ariadne> that's what i like about kyua/atf
2021-04-07 18:41:10 <PureTryOut[m]2> Ariadne: afaik it's a race condition, things compiled in the wrong order. But unsure
2021-04-07 18:41:11 <Ariadne> :)
2021-04-07 18:42:08 <Ariadne> PureTryOut[m]2: do you know what build system it uses?  maybe we can fix it?
2021-04-07 18:42:13 <PureTryOut[m]2> CMake
2021-04-07 18:42:34 <Ariadne> maybe we can switch it to use ninja?
2021-04-07 18:42:52 <Ariadne> with samu, the build should always be deterministic
2021-04-07 18:43:22 <ericonr> dalias: tests (can) help catch library incompatibilities, so they help distros a lot
2021-04-07 18:43:30 <dalias> yeah
2021-04-07 18:43:51 <ericonr> and well, not all upstreams are great, so running tests locally also creates bug reports to send their way
2021-04-07 18:44:35 <ericonr> libzstd had a buggy release on 32-bit devices once, for example; OpenSUSE caught it when running the test suite
2021-04-07 18:44:38 <ikke> ericonr: right, integration tests
2021-04-07 18:45:57 <dalias> well much of this would be cost if upstream were actually using their own tests to catch their bugs
2021-04-07 18:46:04 <dalias> rather than oursourcing it to users/distros :-p
2021-04-07 18:46:19 <dalias> like at the very least test at least one 32-bit target
2021-04-07 18:46:50 <ericonr> there are *so many* projects not testing on 32-bit properly, it's kinda sad :/
2021-04-07 18:47:42 <dalias> well it shouldnt even need dedicated testing mostly, but ppl do so much stupid stuff
2021-04-07 18:47:55 <dalias> long/size/ptr mixup is the worst
2021-04-07 18:48:34 <dalias> but sometimes it's also "soft" stupid things like assuming vm space is huge
2021-04-07 18:48:48 <dalias> oh also assuming file sizes fit in size_t/long/whatever
2021-04-07 18:49:30 <ericonr> at least musl doesn't have the LFS madness to
2021-04-07 18:49:36 <ericonr> ... make things even worse
2021-04-07 18:49:45 <ikke> LFS?
2021-04-07 18:49:50 <ericonr> large file support
2021-04-07 18:49:53 <ikke> ah
2021-04-07 18:51:07 <ericonr> dalias: anyway, the issues vary; sometimes it's just some weird edge case in the test suite, sometimes it's things that can't even build because the constant is too big to fit in the variable type
2021-04-07 18:51:42 <ikke> It's not for nothing that our policy is to run the test suite if present
2021-04-07 18:51:59 <Ariadne> yes, i pushed hard for that for a reason
2021-04-07 18:52:00 <Ariadne> :)
2021-04-07 18:52:31 <ikke> I recall the nginx incident
2021-04-07 18:52:51 <Ariadne> yeah we actually have found CVEs in software just by running the tests
2021-04-07 18:52:52 <Ariadne> :)
2021-04-07 18:55:09 <dalias> :)
2021-04-07 18:55:34 <dalias> yeah i dont mean to criticize distros for doing it
2021-04-07 18:55:48 <dalias> rather packages that ship in a way that the tests get built/run when you just want to compile
2021-04-07 19:44:43 <ikke> armhf is idle :)
2021-04-08 02:19:39 <maxice8> x86-64 is done
2021-04-08 04:37:48 <ikke> dnsrobocert keeps giving issues
2021-04-08 07:27:55 <mps> can we instruct somehow abuild in APKBUILD to ignore error in some commands
2021-04-08 07:28:12 <Cogitri> cmd || true
2021-04-08 07:29:02 <Cogitri> PureTryOut[m]: Seems like qmlkonsole tries to pull in qt5-qtsvg >= 5.15.3 but we only have 5.15.2 in the repos
2021-04-08 07:29:12 <PureTryOut[m]2> I know, working on it
2021-04-08 07:31:35 <mps> Cogitri: thanks, it worked
2021-04-08 07:36:13 <Cogitri> Thanks for looking into it :)
2021-04-08 08:10:20 <Cogitri> https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Flib%2Fpython3.8%2F*&name=&branch=edge&arch=x86_64 we still have quite a lot of packages which try to use py3.8 I think (?)
2021-04-08 08:15:29 <ncopa> morning
2021-04-08 08:15:50 <ncopa> thank you for helping cleaning up after the python 3.9 update
2021-04-08 08:18:13 <maxice8> bumping stuff for python3.9 rebuilds
2021-04-08 08:19:06 <ncopa> thanks!
2021-04-08 08:31:36 <PureTryOut[m]2> Hmm, I need to update QtWebengine as it has security fixes upstream, but no new tags will be made by The Qt Company. This package includes lots of git submodules, so I can't just get a tarball from a  a specific commit and be done with it, as that will exclude the submodules. Gentoo vendors their own tarball created directly from the upstream git repo, can we do the same?
2021-04-08 08:33:43 <Cogitri> Yup
2021-04-08 08:34:09 <Cogitri> Create a snapshot function in the APKBUILD, then we can upload a tarball to dev.a.o
2021-04-08 08:35:03 <PureTryOut[m]2> Cool thanks
2021-04-08 08:40:58 <PureTryOut[m]2> How would I test this locally? I can't just set the srcurl to dev.a.o as the tarball won't be there yet
2021-04-08 08:41:06 <ikke> ncopa: I guess we can create a dev account for PureTryOut[m]2?
2021-04-08 08:42:41 <ncopa> ikke: PureTryOut[m]2 has git push access right?
2021-04-08 08:42:48 <ikke> Yes
2021-04-08 08:43:01 <ncopa> then no problem with account on dev.a.o
2021-04-08 08:43:17 <ikke> OK, will arrange
2021-04-08 08:43:23 <PureTryOut[m]2> 🎉 thanks!
2021-04-08 08:43:34 <ncopa> we should probably come up with a better solution for archive.a.o/dev.a.o so devs can upload files to our archive
2021-04-08 08:53:30 <ikke> Maybe tied to the gitlab account?
2021-04-08 09:08:06 <PureTryOut[m]2> That would be the easiest if possible yes
2021-04-08 09:16:51 <ikke> The only thing we need to think about is how to prevent it from being abused
2021-04-08 09:27:00 <PureTryOut[m]2> Only allow people with git push access I guess?
2021-04-08 15:25:52 <nmeum> ikke: regarding the fzf problem: do you have bash installed?
2021-04-08 15:26:44 <nmeum> https://github.com/junegunn/fzf/blob/764316a53d0eb60b315f0bbcd513de58ed57a876/src/reader.go#L103-L112
2021-04-08 15:27:14 <nmeum> if you don't set FZF_DEFAULT_COMMAND it seems to me fzf will force execution with bash and if you don't have bash installed it just fails with "command failed" to execute
2021-04-08 15:28:28 <ikke> nmeum: yeah, I have bash installed
2021-04-08 15:28:52 <nmeum> that's why the default command works for you but not for me :)
2021-04-08 15:28:56 <ikke> nod
2021-04-08 15:29:13 <nmeum> not sure what would be the best way to fix this because the error message is very confusing and I think it would be desirable to have fzf work by default
2021-04-08 15:29:28 <nmeum> we can either make it depend on bash or patch it to ensure it doesn't execute the default command with bash
2021-04-08 15:29:49 <ikke> does it use bash just as a shell to execute that default command?
2021-04-08 15:30:24 <ikke> We could patch it to use sh
2021-04-08 15:30:29 <nmeum> yes, to make sure the shell supports `set -o pipefail`
2021-04-08 15:30:48 <ikke> ash supports that
2021-04-08 15:31:04 <nmeum> ok, so just patch it to make it use ash then?
2021-04-08 15:31:07 <nmeum> let me quickly test that :)
2021-04-08 15:31:12 <ikke> nmeum: thanks
2021-04-08 15:31:17 <nmeum> np
2021-04-08 15:33:29 <ikke> probably you know this already, but src/reader.go:102
2021-04-08 15:35:22 <nmeum> yeah, linked the code above :)
2021-04-08 15:36:20 <ikke> ah, missed that
2021-04-08 15:36:26 <ikke> or overlooked it
2021-04-08 15:41:00 <nmeum> !20288
2021-04-08 15:41:06 <nmeum> works for me
2021-04-08 15:41:28 <nmeum> also note: this is only relevant for people who haven't set FZF_DEFAULT_COMMAND manually so I guess this shouldn't cause any breakage
2021-04-08 15:41:48 <ikke> s/bash/ash?
2021-04-08 15:41:48 <alpine-meetbot> ikke meant to say: does it use ash? just as a shell to execute that default command?
2021-04-08 15:41:56 <ikke> euhm, no :P
2021-04-08 15:42:08 <ikke> In the commit message
2021-04-08 15:42:20 <nmeum> hm?
2021-04-08 15:42:30 <ikke> 'do require bash by default'
2021-04-08 15:42:35 <nmeum> Aaaa
2021-04-08 15:42:37 <nmeum> I forgot the "not"
2021-04-08 15:42:40 <ikke> ah
2021-04-08 15:42:50 <nmeum> good catch!
2021-04-08 15:43:03 <nmeum> fixed :)
2021-04-08 17:09:58 <donoban> does anyone know if return value from "docker run abuild..." is used for something (tests, CI pipelines..) and if there is any poblem disabling 'set -e' on dabuild script? I'm trying to achieve container/image reuse but I need to handle it after the docker run command (which in case of error interrupts the script)
2021-04-08 17:10:38 <ikke> We do not use dabuild in CI
2021-04-08 17:13:36 <donoban> ok so could I just disable set -e?
2021-04-08 17:14:04 <ikke> I don't know
2021-04-08 17:15:19 <donoban> ok
2021-04-08 17:59:14 <donoban> I forked and pushed some changes but I don't see a merge option
2021-04-08 18:04:55 <afontain_> if you got in "merge requests" there should be a large green button
2021-04-08 18:04:59 <afontain_> s/got/go
2021-04-08 18:04:59 <alpine-meetbot> afontain_ meant to say: if you go in "merge requests" there should be a large green button
2021-04-08 18:07:01 <donoban> oh I found it thanks afontain_
2021-04-08 19:32:54 <aptalca> Hey guys, I'm trying to update the community package for Audacity to 3.0.0, but it seems the latest version requires a custom version of one of the dependencies: wxWidgets and the repo version doesn't cut it. Is there an example of a build using a custom dependency build prior to the actual build for the package in APKBUILD? Thanks
2021-04-08 19:34:42 <ikke> aptalca: I guess it should be a separate package
2021-04-08 19:35:18 <donoban> a custom version means an older version?
2021-04-08 19:35:20 <aptalca> gotcha. Any restrictions or guidance on what to name the custom build of the package?
2021-04-08 19:35:35 <ikke> donoban: a patched version
2021-04-08 19:35:37 <aptalca> no, the audacity team forked the repo and added a bunch of their own custom commits to it
2021-04-08 19:36:03 <donoban> ouch
2021-04-08 19:36:06 <aptalca> right, a patched version
2021-04-08 19:36:33 <Ariadne> we don't negotiate with terrorists, drop the package
2021-04-08 19:36:34 <ikke> The question is if these packages would conflict
2021-04-08 19:36:35 <Ariadne> :)
2021-04-08 19:36:50 <ikke> Use patched wx3.1.3. from https://github.com/audacity/wxWidgets. If you use a wx3.0 version Audacity will be unstable and crash.
2021-04-08 19:36:55 <aptalca> Ariadne: lol
2021-04-08 19:38:53 <donoban>  This branch is 25 commits ahead, 3294 commits behind wxWidgets:master.
2021-04-08 19:39:21 <aptalca> I'm somewhat familiar with alpine build tools and submitted a few PRs in the past. I thought this would be a simple pkgver update and backport but it got a lot more complicated :)
2021-04-08 19:39:35 <ikke> yeah, I can imagine
2021-04-08 19:40:59 <Ariadne> donoban: like i said, we don't negotiate with terrorists
2021-04-08 19:41:04 <Ariadne> :)
2021-04-08 19:41:15 <donoban> from https://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets "Linux currently needs none of these patches, so it is OK if Debian for example builds with stock wxWidgets (of the version we use, and with accessibility enabled)."
2021-04-08 19:41:46 <Ariadne> ah
2021-04-08 19:41:52 <donoban> hehe Ariadne I'm just pretty surprised about this
2021-04-08 19:41:59 <Ariadne> so this is the same situation as how audacious had to patch gtk
2021-04-08 19:42:01 <Ariadne> on windows
2021-04-08 19:42:06 <Ariadne> because it was hopelessly broken
2021-04-08 19:42:21 <afontain_> something something upstreaming
2021-04-08 19:42:29 <Ariadne> afontain_: we tried
2021-04-08 19:42:29 <donoban> or maybe the wiki is outdted, are you sure that the custom version is needed aptalca ?
2021-04-08 19:42:30 <ikke> oh, so it only needs it for other OS's
2021-04-08 19:42:40 <aptalca> I tried a local build but get an error about unpatched wxWidgets. Posted in an issue here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12590
2021-04-08 19:43:19 <afontain_> maybe you can take some patch debian already figured out?
2021-04-08 19:44:02 <Ariadne> well those "building for distros" points are largely unacceptable
2021-04-08 19:44:08 <Ariadne> we are not going to use bundled libraries
2021-04-08 19:44:31 <aptalca> I don't see 3.0.0 in either debian or ubuntu repos
2021-04-08 19:44:41 <Ariadne> likely because they don't negotiate with terrorists either
2021-04-08 19:45:46 <ikke> cmake-proxies/wxWidgets/CMakeLists.txt:240
2021-04-08 19:46:35 <ikke> It expects Audacity in the version string of wxwidgets
2021-04-08 19:47:33 <afontain_> probably upstream would accept a patch to make this build used on Windows only, if the intentions of the fork are the what they stated
2021-04-08 19:48:41 <Ariadne> "Linux currently needs none of these patches, so it is OK if Debian for example builds with stock wxWidgets (of the version we use, and with accessibility enabled)."
2021-04-08 19:48:49 <Ariadne> " Debian for example builds with stock wxWidgets (of the version we use, and with accessibility enabled)."
2021-04-08 19:49:01 <ikke> You could just patch out that check and see if it works
2021-04-08 19:49:07 <Ariadne> we don't negotiate with terrorists
2021-04-08 19:49:25 <Ariadne> they are implying if we do not build it the way they want, they will come and terrorize us
2021-04-08 19:51:03 <aptalca> it is my understanding that the custom wxWidget was a requirement for 2.X releases as well, but it wasn't enforced through cmake (at least on linux) but on 3.0.0 it is enforced. I'm wondering if that statement on their wiki is outdated and that linux version of 3.0.0 also requires it
2021-04-08 19:51:50 <ikke> arch does not have audacity 3.0.0 yet either
2021-04-08 19:52:46 <ikke> nor does voidlinux
2021-04-08 20:03:51 <ericonr> yeah the void maintainer orphaned the package when that wxwdigets requirement came out lol
2021-04-08 20:04:15 <ericonr> Ariadne: debian patches out terrorists, they skip negotiating :p
2021-04-08 20:04:39 <Ariadne> right :)
2021-04-08 20:05:38 <ericonr> do you folks patch out the wxwdigets ABI warning?
2021-04-08 20:10:09 <Ariadne> No
2021-04-08 20:10:21 <Ariadne> we are trying to figure out what to do about this :)
2021-04-08 20:34:20 <bl4ckb0ne> mps: no news from kobol, i mail them and the armbian dev directly
2021-04-08 20:34:38 <bl4ckb0ne> the kobol guy cc'd me the armbian dev, no news since the 5th
2021-04-08 20:46:24 <mps> bl4ckb0ne: thanks for info
2021-04-08 20:47:05 <mps> bl4ckb0ne: could you give a link to their answer
2021-04-08 20:59:49 <bl4ckb0ne> nothing much interesting
2021-04-08 21:00:12 <bl4ckb0ne> i asked for the schematics and they told me they are waiting to recover their nre cost
2021-04-08 21:00:19 <bl4ckb0ne> but they can share some sections if i ask
2021-04-08 21:01:16 <bl4ckb0ne> also havent try to poke at the pcie config
2021-04-08 21:02:19 <mps> bl4ckb0ne: ok. though I think drivers would be more interesting for us than schematics
2021-04-08 21:11:19 <bl4ckb0ne> yup
2021-04-08 21:11:31 <bl4ckb0ne> ill ping you if i get an answer or if i make any progress
2021-04-08 21:13:11 <ollieparanoid[m]> hi all. this patch probably needs to be reverted to fix qt related build errors: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/qt5-qtsvg/0002-Bump-version.patch
2021-04-08 21:13:12 <ollieparanoid[m]> I'm testing it right now and will make a MR to aports
2021-04-08 21:32:19 <ollieparanoid[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20307
2021-04-08 21:33:22 <ollieparanoid[m]> this will fix build-edge-x86 and probably other builders getting stuck there
2021-04-08 21:34:27 <Ariadne> why was the patch added to begin with?  do you know?
2021-04-08 21:35:22 <Ariadne> ah
2021-04-08 21:35:29 <Ariadne> PureTryOut[m]2: ping
2021-04-08 21:38:46 <ollieparanoid[m]> Ariadne: I think PureTryOut is offline. apparently as part of a kde patchset, and kde has forked qt now. looks like patches were cherry picked from there, and this one was included by accident
2021-04-08 21:38:57 <ollieparanoid[m]> I'll check if there are more version bump patches that got in
2021-04-08 21:39:03 <Ariadne> yes i did the revert
2021-04-08 21:39:14 <ollieparanoid[m]> thanks
2021-04-08 21:39:14 <Ariadne> we should make sure that if we follow the KDE fork that we do it cleanly
2021-04-08 21:40:38 <ollieparanoid[m]> +1
2021-04-08 21:41:01 <ollieparanoid[m]> so looks like no other MODULE_VERSION bump patches: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20234
2021-04-08 21:46:04 <donoban> Trying to upgrade telegram desktop I discovered this https://github.com/telegramdesktop/tdesktop/blob/dev/docs/api_credentials.md , was old packages working with test api_id/hash? So you need an API key for build some "open source" :S
2021-04-08 23:02:10 <Ariadne> donoban: does seem to be using the test id/hash
2021-04-08 23:02:40 <Ariadne> donoban: and it does seem to work fine for me
2021-04-08 23:14:50 <Ariadne> donoban: though i agree that this is kind of a bummer.  just more proof that telegram is not really free software
2021-04-08 23:24:28 <Ariadne> -- Build files have been written to: /home/kaniini/aports/community/libphonenumber/src/libphonenumber-8.12.20/cpp/build
2021-04-08 23:24:28 <Ariadne> ninja: multiple rules generate '../src/phonenumbers/metadata.h'
2021-04-08 23:24:36 <Ariadne> digging into this libphonenumber race condition :)
2021-04-08 23:38:28 <Ariadne> ok solved libphonenumber :)
2021-04-09 00:12:27 <maxice8> ty
2021-04-09 01:27:10 <bl4ckb0ne> i think i have a lead on the sata driver mps
2021-04-09 01:27:52 <bl4ckb0ne> https://paste.sr.ht/~bl4ckb0ne/587722d08ab44128890f3b4cbee20d43b9921b7b
2021-04-09 01:35:21 <bl4ckb0ne> starting a build on my side
2021-04-09 05:30:46 <Ariadne> if you need context on the 3.15 -> 15 thing
2021-04-09 05:31:16 <Ariadne> its because 3.15 will be the 15th release of alpine using the now-evergreen musl "ABI"
2021-04-09 05:31:25 <Ariadne> i use ABI very loosely there
2021-04-09 05:31:27 <Ariadne> :p
2021-04-09 06:02:43 <ncopa> morning
2021-04-09 06:02:56 <ncopa> seems like firefox build fails on 3.13-stable branch
2021-04-09 06:03:27 <mps> bl4ckb0ne: better use modprobe instead of insmod. modprobe will 'resolve' modules dependenciies, while with insmod you have to do that 'manually' one by one
2021-04-09 06:04:15 <mps> good morning :)
2021-04-09 07:37:40 <ikke> Morning
2021-04-09 09:31:38 <Cogitri> omni: 3fcd479d3a5eb99e9c7b83b7b1b3429b73625a63
2021-04-09 09:32:01 <Cogitri> https://paste.gnome.org/pm4urofes
2021-04-09 09:35:05 <omni> huh, thanks!
2021-04-09 09:35:53 <Cogitri> Hm, seems like that's a py3.9 think?
2021-04-09 09:35:54 <Cogitri> https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/py3-ssdeep/py3-ssdeep-3.4-r1.log
2021-04-09 09:36:03 <Cogitri> ikke: ^
2021-04-09 09:37:08 <ikke> Will look at it later
2021-04-09 09:38:07 <Cogitri> Thanks
2021-04-09 09:38:09 <omni> Cogitri: but weird?
2021-04-09 09:38:20 <donoban> ey guys, this "'uint32_t' does not name a type" are common musl incompatiblity? https://tpaste.us/nWOp
2021-04-09 09:39:58 <omni> Cogitri: it ran 3 tests here
2021-04-09 09:40:01 <omni> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/py3-zulip/py3-zulip-0.7.1-r1.log
2021-04-09 09:40:37 <maxice8> @donoban: yes, but it is not musl's fault as far as I understand
2021-04-09 09:41:26 <Cogitri> omni: huh,weird
2021-04-09 09:41:34 <Cogitri> Maybe because armv7 isn't done building things yet (?)
2021-04-09 09:42:13 <donoban> maybe there is a wrong included header
2021-04-09 09:47:32 <donoban> Seems that works adding "#include <stdint.h>" :)
2021-04-09 10:18:42 <donoban> I think that the release tarball is not well done, I found two wrong include references to their own code
2021-04-09 11:06:58 <ikke> Trying to figure out what's happening with py3-ssdeep
2021-04-09 11:07:06 <ikke> These errors just happen during the check phase
2021-04-09 11:40:29 <donoban> what is the standard workflow for creating patches when trying to fix an APKBUILD?
2021-04-09 11:41:48 <Cogitri> Submit a MR at gitlab
2021-04-09 11:42:05 <Cogitri> https://paste.gnome.org/pwpmw2fja <- fun, the GCC of 3.13 has an ICE trying to build FF :D
2021-04-09 11:42:05 <donoban> but I mean a patch to the src code of the package
2021-04-09 11:43:12 <donoban> e.g.: https://tpaste.us/zxyv
2021-04-09 11:44:13 <donoban> was this created with a git repo clone of telegram?
2021-04-09 11:46:34 <Cogitri> Ah, diff,git diff or git format-patch works. You can either do that from a git clone of the repo or just do `abuild unpack` and do `git init` in the source and do you changes
2021-04-09 11:47:01 <donoban> ah, last seems the best way
2021-04-09 11:58:02 <Cogitri> ncopa: Are you already looking into rebuilding the remaining py3.8 packages?
2021-04-09 12:08:09 <ncopa> not really
2021-04-09 12:08:14 <ncopa> not today at least
2021-04-09 12:14:30 <Cogitri> Okay, I can start bumping things without clashing with you then
2021-04-09 12:50:39 <omni> is it mostly/only testing left?
2021-04-09 12:51:59 <Cogitri> omni: https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Flib%2Fpython3.8%2F*&name=&branch=edge all of those are left
2021-04-09 13:07:20 <omni> ah
2021-04-09 13:29:50 <ncopa> Cogitri: thank you. I appreciate
2021-04-09 13:31:58 <mps> I vote for 'yy-mm' version, 20.06 for example
2021-04-09 13:32:21 <mps> 21.06, actually :)
2021-04-09 13:33:25 <mps> and, 21.06.{1,2,....}
2021-04-09 13:33:48 <jvoisin> à la Ubuntu?
2021-04-09 13:34:06 <mps> hmm, something like
2021-04-09 13:34:37 <mps> personally, I would prefer 21.06.03, i.e. exact date
2021-04-09 13:38:20 <mps> and, I'm not against to keep current numbering, i.e. 4.1 ...
2021-04-09 13:40:08 <omni> I vote for glyphs, "release 🏆 is out!"
2021-04-09 13:41:49 <mps> omni: emoticons would be better than. alpine :), then ;), :/ etc
2021-04-09 13:42:09 <Cogitri> Does someone happen what's up with this? https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/umockdev/umockdev-0.15.5_git20210315-r0.log
2021-04-09 13:42:13 <Cogitri> Only fails on 32-bit
2021-04-09 13:43:39 <omni> mps: then :-, then :\, then :|, then :/ again and so on
2021-04-09 13:45:37 <mps> =)
2021-04-09 14:12:42 <Cogitri> > kubeadm-bash-completion*: Running split function _kubeadm_bash...
2021-04-09 14:12:42 <Cogitri> Segmentation fault
2021-04-09 14:12:44 <Cogitri> Yuck
2021-04-09 14:47:16 <bl4ckb0ne> mps: modprobed the module successfuly and did a rc-service modules restart
2021-04-09 14:47:20 <bl4ckb0ne> still no output on lspci
2021-04-09 14:47:30 <bl4ckb0ne> but my kernel build is not done, so there's a bit of hope
2021-04-09 14:48:27 <sh4rm4^bnc> ncopa, when did alpine switch to musl ? the announcement page lacks a date
2021-04-09 14:59:06 <mps> bl4ckb0ne: this is strange. is there anything about 'pci' in dmesg output
2021-04-09 14:59:38 <bl4ckb0ne> nothing beside "libata version 3.00 loaded"
2021-04-09 14:59:52 <bl4ckb0ne> cant reboot, still building linux-edge
2021-04-09 15:00:06 <bl4ckb0ne> i tried `echo 1 > /sys/bus/pci/rescan` with no success
2021-04-09 15:00:51 <mps> wait, you have PCI interface detected, but not sata driver?
2021-04-09 15:00:59 <bl4ckb0ne> yep
2021-04-09 15:01:06 <mps> aha
2021-04-09 15:01:07 <bl4ckb0ne> thers some weird stuff going on
2021-04-09 15:01:34 <mps> I thought you say PCI subsystem is not detected
2021-04-09 15:01:53 <bl4ckb0ne> i was going the wrong way
2021-04-09 15:02:08 <bl4ckb0ne> [    2.063302] ehci-pci: EHCI PCI platform driver
2021-04-09 15:02:10 <bl4ckb0ne> [    2.064923] ohci-pci: OHCI PCI platform driver
2021-04-09 15:02:20 <bl4ckb0ne> seems that the jmb585 is ahci
2021-04-09 15:02:41 <mps> and I doubt that rebuilding kernel will help without patches, for example some from armbian kernel
2021-04-09 15:02:56 <bl4ckb0ne> yeah
2021-04-09 15:03:01 <bl4ckb0ne> still no answer from armbian
2021-04-09 15:03:35 <bl4ckb0ne> im really considering putting it in the closet and throw a couple of bucks to build a x86_64 nas
2021-04-09 15:03:59 <mps> I looked at kernel 5.12-rc6 (running it on my rk3399) but there is no sign of that driver
2021-04-09 15:05:20 <mps> bl4ckb0ne: option for you could be to use armbian kernel with alpine userspace, ofc if you want/like to use alpine
2021-04-09 15:05:39 <bl4ckb0ne> interessting
2021-04-09 15:06:49 <mps> I 'can imagine' you asking why mps didn't proposed that earlier :)
2021-04-09 17:59:57 <Cogitri> Does someone know what https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/ansible-lint/ansible-lint-4.3.7-r4.log is about?
2021-04-09 18:00:44 <Ariadne> uhh
2021-04-09 18:00:56 <Ariadne> maybe something wrong with the configuration file for setup.py in ansible-lint?
2021-04-09 18:01:10 <Ariadne> i admit i have not seen this one ever from setuptools :D
2021-04-09 18:01:34 <ikke> Not sure if it's similar, but py3-ssdeep is failing attributes missing as well
2021-04-09 18:05:23 <wsinatra> don't have specifics, but the armv7 ecosystem in general for python3 is a little weird post-rebuild
2021-04-09 18:06:06 <ikke> ansible-lint fails on other arches as well now
2021-04-09 18:16:53 <Ariadne> yes, fails to build on my aarch64 machine and my x86_64 laptop
2021-04-09 18:21:39 <Ariadne> i want to advance gcc snapshot forward to 20210409
2021-04-09 18:21:43 <Ariadne> is now a good time to do that?
2021-04-09 18:22:02 <Ariadne> or are people going to need the builders idle
2021-04-09 18:22:21 <mps> gcc 10.3 is released
2021-04-09 18:22:31 <Ariadne> oh, is it
2021-04-09 18:22:39 <mps> I think so
2021-04-09 18:22:47 <mps> have to check again
2021-04-09 18:22:54 <Ariadne> yes, it is
2021-04-09 18:22:58 <Ariadne> well, that's fine
2021-04-09 18:23:12 <Ariadne> 20210409 snapshot will be gcc 10.3 then :)
2021-04-09 18:23:20 <mps> about 178 fixes from 10.2 :)
2021-04-09 18:23:54 <Ariadne> there are already fixes in 10.3 :)
2021-04-09 18:24:15 <mps> heh, I didn't expect otherwise
2021-04-09 18:24:28 <Cogitri> I think it'd be nice if the Builders were fixed so py3.9 is completed first
2021-04-09 18:24:40 <Ariadne> yeah
2021-04-09 18:24:42 <Cogitri> But I don't have time to deal with this today anymore, so I guess gcc can be done first
2021-04-09 18:24:45 <Ariadne> lets tackle py3.9
2021-04-09 18:26:16 <ikke> UserWarning: Unknown distribution option: 'test_suite'
2021-04-09 18:26:21 <ikke> This happens to ssdeep as well
2021-04-09 18:27:49 <Ariadne> [options.entry_points]
2021-04-09 18:27:56 <Ariadne> i think if we change this to [entry_points] it will fix
2021-04-09 18:29:19 <Ariadne> hmm no
2021-04-09 18:29:42 <ikke> There seems to be some issue with setuptools / distutils
2021-04-09 18:29:50 <ikke> https://stackoverflow.com/questions/8295644/pypi-userwarning-unknown-distribution-option-install-requires
2021-04-09 18:33:12 <Ariadne> https://bugs.archlinux.org/task/70023
2021-04-09 18:36:32 <Ariadne> this ansible-lint seems old
2021-04-09 18:42:29 <andypost[m]> It needs lots of new deps
2021-04-09 18:43:19 <Ariadne> seems to be a setuptools bug
2021-04-09 18:44:55 <Ariadne> >>> a = tuple()
2021-04-09 18:44:55 <Ariadne> >>> b = tuple()
2021-04-09 18:44:55 <Ariadne> True
2021-04-09 18:44:55 <Ariadne> >>> a is b
2021-04-09 18:44:57 <Ariadne> uhhhhhhh
2021-04-09 18:45:16 <Ariadne> let me check python 3.8
2021-04-09 18:45:20 <Ariadne> i think this is a bug!
2021-04-09 18:45:56 <Ariadne> hmm
2021-04-09 18:46:11 <Ariadne> 3.8 also deduplicates tuple()
2021-04-09 18:47:35 <Ariadne> git blame on setuptools is unenlightening
2021-04-09 18:48:49 <Ariadne> well, whatever
2021-04-09 18:48:51 <Ariadne> i have a workaround
2021-04-09 18:48:55 <Ariadne> it may be "wrong" though
2021-04-09 18:51:42 <dalias> uhg why do languages even expose things like this...
2021-04-09 18:52:22 <andypost[m]> Ariadne: I used to in !18606
2021-04-09 18:53:37 <andypost[m]> Delayed til 3.9
2021-04-09 18:54:51 <ericonr> Ariadne: the dynamic musl rust MCP thingy was posted to reddit
2021-04-09 18:54:52 <andypost[m]> Meantime I recall few issues because of changes in 1.1 and 1.2 in yaml specs
2021-04-09 18:54:56 <ericonr> 88 comments :o
2021-04-09 18:55:01 <Ariadne> ericonr: FFS
2021-04-09 18:55:18 <ericonr> :D
2021-04-09 18:55:19 <Ariadne> great now we get to fight techbros
2021-04-09 18:55:24 <dalias> *sigh*
2021-04-09 18:55:32 <ericonr> haven't read yet
2021-04-09 18:55:35 <Ariadne> alpine should just stop negotiating with terrorists and drop rust
2021-04-09 18:55:43 <dalias> i so hate reddit and hn (basically the same thing)
2021-04-09 18:55:59 <Ariadne> ikke: i came up with https://tpaste.us/LwWl
2021-04-09 18:56:07 <Ariadne> ikke: it allows these packages to build
2021-04-09 18:56:08 <dalias> ariadne, that means dropping firefox which means being a non-desktop/workstation distro
2021-04-09 18:56:08 <ericonr> Ariadne: linux-next has rust already :PP
2021-04-09 18:56:16 <Ariadne> ikke: i have no idea how fucked the idea is tho
2021-04-09 18:56:21 <Ariadne> ikke: shall i send it?
2021-04-09 18:56:30 <andypost[m]> Diversity is not always about terrorism
2021-04-09 18:56:35 <dalias> ericonr, that's rather a misrepresentation, it's some weird optional junk
2021-04-09 18:57:01 <ikke> Ariadne: hmm
2021-04-09 18:57:04 <Ariadne> andypost[m]: no, but shipping a toolchain which is broken on musl systems is :)
2021-04-09 18:57:12 <ericonr> dalias: for now, I'm curious to see how it progresses into the future
2021-04-09 18:57:20 <dalias> ericonr, linus won't even allow c++
2021-04-09 18:57:22 <ericonr> but the fact is, some integration *already* exists
2021-04-09 18:57:25 <dalias> i dont think you have anything to fear
2021-04-09 18:57:46 <ericonr> fair
2021-04-09 18:58:12 <Ariadne> to be fair it takes a lot of discipline to write high quality C++
2021-04-09 18:58:25 <ericonr> really, rust in kernel is not even as bad as rust in userspace, the target specification and shenanigans would be much simpler
2021-04-09 18:58:27 <Ariadne> algitbot: do you flip a coin
2021-04-09 18:58:28 <ikke> Ariadne: doesn't that mean a lot of metadata will be missing?
2021-04-09 18:58:39 <ikke> Ariadne: I guess for dependencies that does not matter, but other things?
2021-04-09 18:58:46 <dalias> ericonr, *nod* but the need for non-bootstrappable tooling is awful
2021-04-09 18:58:50 <ikke> Ariadne: or is this just for that entry_points?
2021-04-09 18:59:01 <Ariadne> hmm
2021-04-09 18:59:07 <Ariadne> idk
2021-04-09 18:59:15 <Ariadne> i hate this
2021-04-09 18:59:30 <ikke> Ariadne: My understanding is that setuptools is supposed to monkeypatch distutils (sigh)
2021-04-09 18:59:52 <andypost[m]> Ariadne: atm I can't get what matrix they are testing https://github.com/swoole/swoole-src/pull/4104/files#diff-34f6f011c8bb8ce30fca0061bae061efa7442bf313759586af21945ff2807adfR96
2021-04-09 19:00:01 <ericonr> dalias: that it is :/
2021-04-09 19:00:25 <Ariadne> i'll just let Cogitri figure it out
2021-04-09 19:00:27 <Ariadne> back to GCC :)
2021-04-09 19:00:45 <Cogitri> Not sure if letting me figure out python things will work out so well :D
2021-04-09 19:01:51 <Ariadne> ikke: i don't think my patch is harmful
2021-04-09 19:02:34 <Ariadne> it just removes KeyError for situations where something is unset
2021-04-09 19:02:38 <andypost[m]> Part of dependencies are needed for tests only so could get skip, and there is never release
2021-04-09 19:02:40 <Ariadne> which is fine because we are setting?
2021-04-09 19:02:42 <Ariadne> idk
2021-04-09 19:02:49 <Ariadne> this is unpleasant
2021-04-09 19:04:39 <dalias> things will be so much better once there's a rust implementation in gcc
2021-04-09 19:04:54 <ericonr> the ABI mismatches will still exist :/
2021-04-09 19:05:28 <dalias> especially if it can bootstrap the llvm one for ppl who want it
2021-04-09 19:05:38 <dalias> but i would be happy to just throw out all the llvm stuff
2021-04-09 19:06:00 <dalias> i guess the llvm one is nice to have if you want to target wasm
2021-04-09 19:09:15 <Ariadne> ericonr: link to this reddit thread
2021-04-09 19:09:37 <ericonr> I should warn you, it has bad takes
2021-04-09 19:09:49 <Ariadne> of coruse it does
2021-04-09 19:09:51 <Ariadne> its reddit
2021-04-09 19:09:52 <ericonr> https://www.reddit.com/r/rust/comments/mn76kt/major_change_proposal_update_the_existing_musl
2021-04-09 19:09:53 <Ariadne> its rust
2021-04-09 19:09:54 <alpine-meetbot> [REDDIT] Major Change Proposal: Update the existing musl targets to be dynamically linked (https://github.com/rust-lang/compiler-team/issues/422) to r/rust | 147 points (96.0%) | 89 comments | Posted by sanxiyn | Created at 2021-04-09 - 02:05:20UTC
2021-04-09 19:11:43 <Ariadne> let me put it this way, if these people come and sealion their way into fucking us out of having a usable rust toolchain, i'm just going to spend my time working on ways to end rust
2021-04-09 19:12:33 <dalias> oh, i will raise hell if that happens
2021-04-09 19:12:41 <dalias> for calling this a fucking "major change proposal"
2021-04-09 19:12:46 <dalias> which it is not
2021-04-09 19:12:49 <dalias> it's a small bugfix
2021-04-09 19:13:09 <dalias> i raised that in the meeting and was told MCP is just a misnomer for "minor change proposal"
2021-04-09 19:13:20 <dalias> but if their bad naming screws this up i will be very very mad
2021-04-09 19:13:26 <Ariadne> Not every peice of software is maintained. I, personally, have written software that I believe is unmaintained and will be broken by this patch. If the scientists who use it come back to it in two years and try and make a small change this change will probably entirely block them. Warnings for awhile is simply not an adequate excuse to make breaking changes to stable software.
2021-04-09 19:13:31 <Ariadne> don't worry mr. rustdragon
2021-04-09 19:13:34 <ericonr> hey, I just read that
2021-04-09 19:13:36 <Ariadne> your code won't compile in 2 years anyway
2021-04-09 19:13:41 <ericonr> lmao
2021-04-09 19:13:46 <dalias> downvote all the shit comments like that
2021-04-09 19:14:12 <ericonr> why do people consider toolchain changes as breaking code
2021-04-09 19:14:18 <Ariadne> because half the rust features it uses will have been replaced with new rust features
2021-04-09 19:14:44 <Ariadne> also who the fuck uses rust and musl in scientific computing
2021-04-09 19:15:16 <Ariadne> all of my attempts at evangelism of musl in the scientific computing world have resulted in "the math library is not the same as glibc, so we can't use it sorry"
2021-04-09 19:16:50 <dalias> in any case if they screw this up we just continue to patch
2021-04-09 19:16:52 <dalias> and call rust broken
2021-04-09 19:16:58 <dalias> which is no different from the status quo
2021-04-09 19:17:09 <Ariadne> well, no, it is slightly different
2021-04-09 19:17:21 <Ariadne> because now we have, what the children call these days, "reciepts"
2021-04-09 19:17:34 <Ariadne> receipts, rather
2021-04-09 19:17:40 <Ariadne> so we just cancel them
2021-04-09 19:17:42 <Ariadne> or whatever
2021-04-09 19:22:22 <dalias> no that's not how anything works
2021-04-09 19:28:20 <Ariadne> https://www.reddit.com/r/rust/comments/mn76kt/major_change_proposal_update_the_existing_musl/gtyrkjt/?utm_source=reddit&utm_medium=web2x&context=3
2021-04-09 19:28:21 <alpine-meetbot> [REDDIT] Major Change Proposal: Update the existing musl targets to be dynamically linked (https://github.com/rust-lang/compiler-team/issues/422) to r/rust | 145 points (96.0%) | 94 comments | Posted by sanxiyn | Created at 2021-04-09 - 02:05:20UTC
2021-04-09 19:28:23 <Ariadne> this person's take annoyed me
2021-04-09 19:28:41 <Ariadne> to the point that i willingly signed up for a reddit account
2021-04-09 19:28:55 <omni> trying to upgrade maturin I found that they did this https://github.com/PyO3/maturin/commit/fe41da6a7d1ad5940bfec161ed1d2d556d0856fb letting target_triple from `rustc -vV` but the platforms crate doesn't know of *-alpine-linux-musl so built maturin will fail to run
2021-04-09 19:30:15 <ericonr> omni: ugh
2021-04-09 19:30:18 <Ariadne> :D
2021-04-09 19:30:23 <omni> if I let target_triple be (for example) x86_64-unknown-linux-musl it'll run fine (on x86_64, in this case)
2021-04-09 19:30:26 <Ariadne> omni: WHICH IS WHY I AM TRYING TO FIX THIS OMG
2021-04-09 19:30:33 <Ariadne> omni: it won't
2021-04-09 19:30:37 <ericonr> iirc maturin depends on a crate that replicates the markdown target table
2021-04-09 19:30:43 <Ariadne> omni: you'll wind up with musl staticly linked into the python module
2021-04-09 19:30:45 <ericonr> so you need to use official rust targets for it to work right
2021-04-09 19:30:59 <ericonr> python3-setuptools_rust passes the flag for no static musl
2021-04-09 19:31:01 <ericonr> on musl targets
2021-04-09 19:31:03 <omni> Ariadne: oh, ah
2021-04-09 19:31:05 <Ariadne> oh ok
2021-04-09 19:31:10 <ericonr> I don't remember what maturin does
2021-04-09 19:31:11 <Ariadne> well anyway
2021-04-09 19:31:15 <Ariadne> this is why i am trying to fix this shit
2021-04-09 19:31:24 <ericonr> the inner workings of the python-rust integration are lost on me
2021-04-09 19:31:40 <ericonr> but we do have a working python3-adblock package on void, at least
2021-04-09 19:31:43 <Ariadne> i almost wanted to ask him if he expected his rust code to compile in 2 years
2021-04-09 19:31:51 <Ariadne> haha
2021-04-09 19:31:58 <ericonr> Ariadne: I think another commenter did ask that
2021-04-09 19:32:28 <Ariadne> i am also confused about scientific computing on musl
2021-04-09 19:32:39 <Ariadne> every time anyone from here has tried to evangelize
2021-04-09 19:32:42 <Ariadne> people are like
2021-04-09 19:32:48 <Ariadne> OMG MUSL MATH LIB SUCKS
2021-04-09 19:33:02 <Ariadne> because its not bug compatible with glibc
2021-04-09 19:33:13 <Ariadne> apparently all of our science now depends on bug compatibility with glibc
2021-04-09 19:33:15 <Ariadne> sad if true
2021-04-09 19:34:12 <ericonr> Ariadne: if scientist-written code *only* depends on bug compatibility and not also random UB, I'd be happy already :p
2021-04-09 19:34:13 <ikke> It probably invalidates all their research :P
2021-04-09 19:34:52 <dalias> :)
2021-04-09 19:39:34 <mps>  /nick kurt_goedel math axsioms are wrong /nick mps :)
2021-04-09 19:39:47 <ikke> :)
2021-04-09 19:43:13 <ikke> Is that goedel from goedel, escher, bach?
2021-04-09 19:44:38 <mps> no, this one https://en.wikipedia.org/wiki/Kurt_G%C3%B6del
2021-04-09 19:44:39 <alpine-meetbot> [WIKIPEDIA] Kurt Gödel | "Kurt Friedrich Gödel (; German: [ˈkʊɐ̯t ˈɡøːdl̩] (listen); April 28, 1906 – January 14, 1978) was a Austrian-German-American logician, mathematician, and analytic philosopher. Considered along with Aristotle and Gottlob Frege to be one of the most significant logicians in history, Gödel had an immense..."
2021-04-09 19:44:51 <ikke> ok
2021-04-09 19:44:58 <mps> can't find anything better right now
2021-04-09 19:45:34 <mps> https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
2021-04-09 19:45:35 <alpine-meetbot> [WIKIPEDIA] Gödel's incompleteness theorems | "Gödel's incompleteness theorems are two theorems of mathematical logic that demonstrate the inherent limitations of every formal axiomatic system capable of modelling basic arithmetic.  These results, published by Kurt Gödel in 1931, are important both in mathematical logic and in the philosophy of mathematics..."
2021-04-09 19:46:58 <wdtTP2O82Kft> yes, this kurt goedel is the same as in egb
2021-04-09 19:48:01 <mps> and people wonders what is wrong with science which is based on math ;)
2021-04-09 20:28:53 <omni> "Failed to create a virtualenv: Os" ..hmm...
2021-04-09 20:35:41 <omni> Ariadne: did you remove your comment and account again?
2021-04-09 20:35:47 <Ariadne> no
2021-04-09 20:35:56 <Ariadne> i think reddit is having issues
2021-04-09 20:36:31 <omni> huh, ok
2021-04-09 20:38:42 <ericonr> you might be hidden because no karma or something
2021-04-09 20:38:49 <ericonr> reddit also works in mysterious ways
2021-04-09 20:39:43 <omni> never ben a fan of forums but I end up reading something there once in a while
2021-04-09 20:39:47 <dalias> any idea who the OP is?
2021-04-09 20:40:07 <skarnet> the reddit servers are the most dysfunctional of all big social media platforms
2021-04-09 20:40:10 <omni> btw, *.reddit.com could be replaced with teddit.net for your convenience
2021-04-09 20:40:15 <skarnet> they're regularly down or partially down
2021-04-09 20:40:21 <dalias> if it's someone actually involved with the project i want to complain to the rust folks we're in touch with
2021-04-09 20:40:23 <skarnet> the authentication fails on a regular basis
2021-04-09 20:40:23 <skarnet> etc.
2021-04-09 20:40:42 <dalias> because putting this in front of a bikeshed crowd with no stake in the outcome was an asshole move
2021-04-09 20:42:15 <Ariadne> dalias: i have already complained in zulip, they agree this is unfortunate
2021-04-09 20:42:36 <dalias> good
2021-04-09 20:42:42 <ericonr> it's a random person it seems
2021-04-09 20:42:47 <ericonr> they like to flame debates though
2021-04-09 20:42:56 <dalias> i think this should be a call to fix the naming of MCPs
2021-04-09 20:43:03 <dalias> s/Major/Minor/
2021-04-09 20:43:42 <Ariadne> red tape proposal
2021-04-09 20:43:43 <Ariadne> :)
2021-04-09 20:44:00 <Ariadne> to be honest, this should have been solved years ago
2021-04-09 20:44:09 <Ariadne> had i known this was such a disaster, i would have taken action then
2021-04-09 20:44:32 <Ariadne> then again, there were only a few hundred million musl installs at the time, so maybe they wouldn't have been swayed so easily
2021-04-09 20:45:00 <Ariadne> Alpine has only started to be taken "seriously" in that way in the past 2 years imo
2021-04-09 20:45:43 <Ariadne> and in 2017, a gentoo-musl dev tried to fix it and they told them to pound sand
2021-04-09 20:45:48 <ericonr> from seeing him in issues I think he's suffering a lot of burnout, but crichton made some bad decisions on rust :/
2021-04-09 20:45:55 <dalias> :/
2021-04-09 20:46:19 <dalias> it's so stupid this was even an issue because it's *out of the scope* of the language
2021-04-09 20:46:24 <ericonr> :D
2021-04-09 20:46:28 <Ariadne> i think had crichton came and talked to us in #musl we would have been able to find a solution that made everyone happy from day 1
2021-04-09 20:46:30 <dalias> it's a part of the target specification
2021-04-09 20:46:48 <dalias> maybe i need to write up a musl abi document that says toolchains produce dynamic binaries by default :-p
2021-04-09 20:46:58 <ericonr> dalias: rust is rustc, rustc tied to cargo, therefore toolchain == language for most folks
2021-04-09 20:47:21 <dalias> yes that's one of the fundamental problems of rust
2021-04-09 20:47:21 <Ariadne> i think if you are going to do weird shit with somebody's work, you should probably go talk to that somebody first
2021-04-09 20:47:40 <Ariadne> it is just a matter of politeness
2021-04-09 20:47:43 <dalias> *nod*
2021-04-09 20:56:03 <Ariadne> and in fairness, -dynmusl was something we could have begrudgingly lived with
2021-04-09 20:56:08 <Ariadne> they didn't want that
2021-04-09 20:56:17 <Ariadne> so obviously we are going to move to protect our interests
2021-04-09 20:56:21 <Ariadne> :)
2021-04-09 21:32:30 <Ariadne> i wonder how difficult it would be to just build a curses emulation package on top of a good term lib, like notcurses
2021-04-09 21:32:59 <dalias> i dont want -dynmusl either
2021-04-09 21:36:03 <Ariadne> well, i don't either, but it would have been livable
2021-04-09 21:44:28 <ericonr> Ariadne: notcurses depends on ncurses directly :/
2021-04-09 21:45:05 <ericonr> or is it libtinfo?
2021-04-09 21:47:36 <dalias> -dynmusl is a declaration that musl is second-class
2021-04-09 21:50:09 <Ariadne> ericonr: it’s only libtinfo
2021-04-09 21:50:25 <Shiz> Ariadne: I reached out to the rust devs at the time, it got ignored
2021-04-09 21:50:57 <Ariadne> Shiz: so in other words the only reason they care now is because we have 2 billion installs? :)
2021-04-09 21:51:09 <Shiz> tbf i never bothered to ping
2021-04-09 21:51:11 <Shiz> :p
2021-04-09 21:51:33 <Ariadne> i suspect it has a lot to do with it
2021-04-09 21:51:34 <Shiz> https://internals.rust-lang.org/t/refining-cross-platform-crt-static-semantics/5085
2021-04-09 21:51:36 <Shiz> was my thread
2021-04-09 21:51:59 <dalias> btw iirc the static linked musl target is broken still
2021-04-09 21:52:08 <dalias> it links both their shipped libc and the system one
2021-04-09 21:52:26 <dalias> so *all* upsteam musl targeting in rust is currently broken
2021-04-09 21:53:50 <afontain_> ouch
2021-04-09 21:54:18 <afontain_> conclusion from the rust folks: musl is broken
2021-04-09 21:54:30 <afontain_> conclusion from the musl folks: rust is broken
2021-04-09 21:55:55 <Ariadne> huh?
2021-04-09 21:56:11 <Ariadne> the conclusion from the rust developers is now that rust was broken
2021-04-09 21:56:31 <Ariadne> the rust users may be a different story, but i don’t think that’s a huge concern
2021-04-09 21:56:32 <afontain_> okok, conclusion from the reddit rust folks :P
2021-04-09 21:56:41 <dalias> and this is partly a symptom of rust folks not understanding what a cross compiler is
2021-04-09 21:57:05 <dalias> if you're providing your own system libraries for a target that might be different from host, that's a cross compiler
2021-04-09 21:57:15 <Ariadne> it’s only the rust developers that i care about
2021-04-09 21:57:20 <dalias> if you're using the native system libraries on the host, that's a native compiler
2021-04-09 21:57:41 <dalias> if you're mixing them, you have a broken toolchain
2021-04-09 21:57:49 <dalias> guess which one rust is...
2021-04-09 21:58:07 <sam_> :D
2021-04-09 22:00:17 <dalias> acting as a cross compiler targeting musl (esp static musl) is great
2021-04-09 22:00:24 <dalias> but mixing that with linking host libs is not
2021-04-09 22:01:26 <Ariadne> since these are mozillians i am just going to start saying their use of musl is equivalently problematic as a modified version of firefox
2021-04-09 22:02:24 <afontain_> "… except that one is broken"
2021-04-09 22:05:35 <ericonr> Ariadne: I don't like that argument
2021-04-09 22:05:41 <ericonr> mozilla's stance sucks
2021-04-09 22:06:55 <Ariadne> i’m not a fan of it but they “get it”
2021-04-09 22:07:35 <Ariadne> and i’m willing to use language they “get” in order to keep peoples eye on the ball
2021-04-09 22:08:09 <Ariadne> it is not even a “wrong” position.  we are certainly unhappy about what they have done with musl.
2021-04-09 22:08:39 <Ariadne> in the same way mozilla would be if somebody took firefox and broke it and said it was firefox
2021-04-09 22:09:13 <Ariadne> sometimes you have to frame things in a way that makes sense to their worldview
2021-04-09 22:09:15 <Ariadne> :)
2021-04-09 22:09:44 <Ariadne> and the promotion of the idea that musl is for static linking has done harm to musl
2021-04-09 22:09:57 <sam_> oh man do I want to go to reddit to find out the drama
2021-04-09 22:10:03 <Ariadne> as we can see in the reddit post
2021-04-09 22:11:03 <Ariadne> i mean the reddit thread is boring
2021-04-09 22:11:09 <Ariadne> do as you wish tho
2021-04-09 22:11:24 <Ariadne> it’s a lot of bad takes
2021-04-09 22:11:29 <omni> not hard to find
2021-04-09 22:11:38 <sam_> what's actually.. happened?
2021-04-09 22:12:13 <Ariadne> nothing has happened, other than the zulip discussion having idiots join and make bad arguments
2021-04-09 22:12:58 <Ariadne> and i think we have been nicer than mozilla would be if the situation were reversed
2021-04-09 22:14:10 <Ariadne> but a lot of people on rust think alpine and openwrt and so on are static linked
2021-04-09 22:14:14 <Ariadne> which is pretty funny
2021-04-09 22:14:57 <sam_> 
ACTION nods

2021-04-09 22:15:04 <dalias> how do they think that works??
2021-04-09 22:15:11 <dalias> firefox requires dynamic linking afaik
2021-04-09 22:15:23 <dalias> and of course python does
2021-04-09 22:16:23 <Ariadne> really i think having discovered the true depths of depravity that alex crichton went to with the ride he took musl on
2021-04-09 22:16:38 <Ariadne> we have been quite reserved in our response
2021-04-09 22:16:48 <Ariadne> we just want it fixed
2021-04-09 22:19:53 <ericonr> firefox dlopen's a whole menagerie of libraries, I doubt it can do static linking
2021-04-09 22:31:26 <Ariadne> i don’t really know where the musl == static linking meme came from
2021-04-09 22:31:29 <Ariadne> probably hacker news
2021-04-09 22:33:04 <Ariadne> as i pointed out when you download a toolchain from musl.cc it doesn’t spit out static binaries unless you ask it to
2021-04-09 22:33:14 <Ariadne> so why does rustc?
2021-04-09 22:36:59 <omni> should the linter trigger on comments?
2021-04-09 22:44:23 <Hello71> my guess is glibc != static linking, musl != glibc, therefore musl = static linking
2021-04-09 22:44:30 <Hello71> me do good maths
2021-04-09 22:44:39 <afontain_> lol
2021-04-09 23:37:07 <ddevault> it looks like the version number discussion is already resolved against the change, which is the outcome I would have argued for
2021-04-09 23:37:22 <ddevault> so to quickly add my 2c here instead: the existing scheme is also a marketing feature for alpine
2021-04-09 23:37:53 <ddevault> 15 => ∞ is a chromium-style versioning scheme that just says we crap out releases whenever we feel like it and there's no meaningful difference between them
2021-04-09 23:38:03 <ddevault> dated releases say we release when the clock shows the appropriate time and just hope it's good
2021-04-09 23:40:27 <ddevault> major.minor.patch says we release it when it's ready, and you can learn something useful from the numbers
2021-04-10 01:19:58 <Hello71> i think Ariadne's point is that the numbers don't have useful information anymore
2021-04-10 01:20:09 <Ariadne> right, basically
2021-04-10 01:20:15 <Ariadne> it's all numberwang anyway
2021-04-10 01:28:06 <ddevault> that a four is unlikely does not make the 3 unmeaningful
2021-04-10 01:28:37 <ddevault> hindsight is 20:20 anyway, maybe someday there will be a 4
2021-04-10 01:29:12 <ddevault> alpine pre-dates musl entirely, after all
2021-04-10 01:34:45 <Ariadne> it seems unlikely that alpine will ever switch from musl
2021-04-10 01:35:02 <ddevault> it seems unlikely that alpine will ever switch from uclibc
2021-04-10 01:35:09 <Ariadne> no, that was very likely
2021-04-10 01:35:28 <Ariadne> we *forked* uclibc afterall :)
2021-04-10 01:36:09 <ddevault> well, argue it as we might, dropping the major version number is a decision lacking foresight
2021-04-10 01:36:16 <ddevault> and the patch number is definitely useful
2021-04-10 01:36:25 <Ariadne> i don't really care what the version number is
2021-04-10 01:36:31 <ddevault> then don't change it
2021-04-10 01:36:42 <Ariadne> i was just restarting the conversation since we decided to postpone until after 3.14
2021-04-10 01:36:43 <Ariadne> :)
2021-04-10 01:36:44 <ddevault> if you don't care, don't change things. tends to work out better that way
2021-04-10 01:36:56 <skarnet> the root of the problem is that semver is insufficient
2021-04-10 01:37:08 <ddevault> perfect is the enemy of good
2021-04-10 01:37:08 <skarnet> you really need 4 numbers, not 3, to capture an accurate version
2021-04-10 01:37:21 <Ariadne> you need 5 numbers
2021-04-10 01:37:24 <skarnet> because the "major" often becomes a "lifetime" number that never changes
2021-04-10 01:37:32 <Ariadne> so you can reflect the author's mood at release time
2021-04-10 01:37:35 <Ariadne> using numerology
2021-04-10 01:37:36 <ddevault> how about 3 numbers and read the changelog
2021-04-10 01:37:51 <skarnet> you need lifetime.major.minor.patch
2021-04-10 01:38:16 <skarnet> the 3 in Alpine was designed as a major
2021-04-10 01:38:17 <ddevault> "never" is a word that people only ever use on a webshit move-fast-and-break-things timeline
2021-04-10 01:38:20 <skarnet> but has become a lifetime
2021-04-10 01:38:25 <ddevault> I for one hope that alpine is still good in 20 years
2021-04-10 01:38:35 <Ariadne> yeah uhh
2021-04-10 01:38:38 <skarnet> it's a very classic evolution in version numbers, but people don't learn
2021-04-10 01:38:46 <Ariadne> i'll probably have jumped out of a balcony by then
2021-04-10 01:38:48 <ddevault> and 20 years ago, linux itself wasn't a thing
2021-04-10 01:38:48 <Ariadne> soooo
2021-04-10 01:38:50 <skarnet> and stick to 3-number semver because there's a website or something
2021-04-10 01:38:51 <Ariadne> :p
2021-04-10 01:39:04 <ddevault> well, at least you won't be proposing version numbering changes anymore :P
2021-04-10 01:39:34 <skarnet> bold of yall to assume tech as we know it will still be a thing in 20 years
2021-04-10 01:39:34 <ddevault> though if alpine drives its devs to jump off of balconies the version numbers don't really matter at that point
2021-04-10 01:39:56 <ddevault> all major air traffic control systems run on technology which has not been upgraded in 30 years or more, skarnet
2021-04-10 01:40:14 <skarnet> oh, that's not what I meant
2021-04-10 01:40:19 <Ariadne> honestly i am assuming systemd will gain hard AI capabilities and the US military will have been stupid and deployed systemd on the systems which launch the nukes
2021-04-10 01:40:44 <skarnet> that will only make the apocalypse come sooner and by accident
2021-04-10 01:40:47 <Ariadne> and we will all be driving around in a post-nuclear wasteland
2021-04-10 01:40:56 <ddevault> the rover which landed on Mars in February is running VxSphere
2021-04-10 01:40:59 <Ariadne> fighting boston robotics robomutts
2021-04-10 01:41:04 <ddevault> which was first released in 1987
2021-04-10 01:41:09 <Ariadne> VxWorks
2021-04-10 01:41:13 <ddevault> err, VxWorks
2021-04-10 01:41:15 <skarnet> yall are imagining a future with more tech
2021-04-10 01:41:22 <skarnet> that's not what will happen
2021-04-10 01:41:59 <skarnet> the future will be current tech slowly breaking down due to lack of mineral resources and energy
2021-04-10 01:42:16 <skarnet> and people taping it together with wire and hope
2021-04-10 01:42:26 <Ariadne> and yet systemd will still exist
2021-04-10 01:42:38 <skarnet> it will be one of the first things to go away
2021-04-10 01:42:50 <skarnet> because when shtf you go for efficiency
2021-04-10 01:42:55 <ddevault> I can tell you one thing: collapseOS won't be around
2021-04-10 01:43:05 <Ariadne> what is collapseOS
2021-04-10 01:43:15 <ddevault> a thing which thinks it will be around after the apocalypse
2021-04-10 01:43:21 <ddevault> and actually contains a fork of some of my code I think
2021-04-10 01:43:24 <Ariadne> It is a Forth (why Forth?) operating system and a collection of tools and documentation with a single purpose: preserve the ability to program microcontrollers through civilizational collapse.
2021-04-10 01:43:25 <Ariadne> i umm
2021-04-10 01:43:27 <Ariadne> ok
2021-04-10 01:43:29 <Ariadne> :)
2021-04-10 01:43:33 <skarnet> not as long as your code is Go :P
2021-04-10 01:43:37 <ddevault> z80 assembly in this case
2021-04-10 06:54:09 <ikke> omni: in general the linter should not act on comments, with a few exceptions
2021-04-10 07:03:31 <xybre> I know I'm late to reply, but Collapse has a whole page on why forth. And forth is really great for quickly building small self-hosting systems. C exists for most things, but can't be bootstrapped as easily into a full OS.
2021-04-10 07:06:38 <mps> forth is 'safe' language because it is simple. used in a lot of NASA, JPL and similar things where reliability is _really_ important
2021-04-10 07:07:19 <mps> oh, and israelis jet fighter
2021-04-10 07:07:35 <mps> fighters*
2021-04-10 07:08:35 <mps> but forth requires some 'changes' in programmers mind, which is hardest thing to achieve
2021-04-10 07:09:47 <mps> there are some CPUs in which forth is machine language, RTX2000 and similar
2021-04-10 07:10:53 <mps> but forth is different paradigm, though Postscript in actually forth interpreter
2021-04-10 07:11:54 <mps> something else, zathura segfaults on edge (aarch64 at least) and rebuild fixes this
2021-04-10 07:12:13 <mps> not sure which lib is cause
2021-04-10 07:12:27 <mps> probably sqlite-libs upgrade
2021-04-10 07:14:18 <mps> so, how should commit msg be written: 'rebuild to fix segfault'
2021-04-10 07:45:39 <afontain_> mps: it would be nice to figure out what change broke abi though, so that everything else that have the dependency can be rebuilt
2021-04-10 08:10:04 <mps> afontain_: yes, I agree. but I would have to 'go back' (rewind FS) on my test box, running strace and probably gdb, maybe something more to find what is 'casus belli'
2021-04-10 08:10:28 <mps> or, simply rebuild
2021-04-10 08:11:57 <mps> and, my intuition says: sqlite-libs. wanna bet? :)
2021-04-10 08:15:27 <mps> I lost ;)
2021-04-10 08:15:33 <mps> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL
2021-04-10 08:16:17 <mps> ' <... ppoll resumed> <unfinished ...>) = ?'
2021-04-10 08:18:09 <mps> no, I win, removing bookmarks.sqlite fixes problem even without rebuild zathura
2021-04-10 08:18:52 <mps> but got 'warning: failed to update database table layout: sha256'
2021-04-10 09:58:08 <omni> ikke: it complained when I surrounded with backticks in a comment, so I switched to double quotes
2021-04-10 09:58:22 <ikke> omni: aha ok
2021-04-10 10:00:44 <ikke> Do you have a link to the job?
2021-04-10 10:07:35 <donoban> I'm stuck on this missing header: fatal error: pc/sctp_data_channel.h: No such file or directory which seems part of Google WebRTC but I investigated archlinux and fedora packages, they use the same telegram tarball and I don't find where they get this header file (obv is not inside the tarball)
2021-04-10 10:09:07 <ikke> and it's not a dependency?
2021-04-10 10:09:52 <donoban> I guess...
2021-04-10 10:10:00 <ikke> donoban: https://github.com/archlinux/svntogit-community/blob/packages/telegram-desktop/trunk/PKGBUILD#L21
2021-04-10 10:10:05 <ikke> there they seem to do something with that
2021-04-10 10:10:09 <donoban> uhM
2021-04-10 10:10:26 <donoban> I found it on archlinux, they package it on libtg_owt
2021-04-10 10:10:37 <ikke> aha
2021-04-10 10:11:24 <donoban> https://archlinux.org/packages/community/x86_64/libtg_owt/
2021-04-10 10:11:38 <donoban> https://github.com/desktop-app/tg_owt
2021-04-10 10:12:07 <donoban> it's a pretty crazy mix of dependencies
2021-04-10 10:13:04 <omni> ikke: sure https://gitlab.alpinelinux.org/omni/aports/-/jobs/368018 the comment was: # enable interpreter `python` hack
2021-04-10 10:13:27 <ikke> omni: thanks
2021-04-10 10:13:42 <ikke> This should certainly not trip on comments
2021-04-10 10:14:53 <donoban> so the "right" way is packagint this tg_owt? and add as make dep for telegram-desktop?
2021-04-10 10:15:16 <ikke> donoban: I suppose so
2021-04-10 10:16:15 <donoban> Replaces:  libwebrtc
2021-04-10 10:16:20 <donoban> (on archlinux)
2021-04-10 10:16:37 <donoban> but telegram-desktop is the only packaga which requires it
2021-04-10 10:16:52 <ikke> I don't see libwebrtc on alpine
2021-04-10 10:17:07 <ikke> https://pkgs.alpinelinux.org/packages?name=*webrtc*&branch=edge&arch=x86_64
2021-04-10 10:17:12 <omni> ikke: didn't think so either, but I was tired and my friend had left me with a glass of liqour so I didn't want to exclude myself from the equation =)
2021-04-10 10:18:12 <donoban> well, if I create libtg_owt should do it in testing and move also telegram-desktop to testing?
2021-04-10 10:19:45 <ikke> donoban: new dependencies can usually be created directly in the repo that needs them
2021-04-10 10:20:02 <donoban> ok
2021-04-10 10:20:37 <donoban> better calling it libtg_owt altough upstream calls it tg_owt?
2021-04-10 10:21:07 <ikke> we tend to prefer upstream naming
2021-04-10 10:21:26 <donoban> ouch, there are no release nor tagging :\
2021-04-10 10:21:43 <ikke> fun
2021-04-10 10:21:55 <ikke> Can you get a snapshot from a commit?
2021-04-10 10:22:23 <donoban> yes I think, arch uses libtg_owt 0.git4.2d804d2-1
2021-04-10 10:22:41 <ikke> https://github.com/desktop-app/tg_owt/archive/e5a67a122e5094eefec7b7da0c41792e036f4f8e.tar.gz
2021-04-10 10:22:51 <donoban> "tg_owt::git+${url}.git#commit=${_commit}"
2021-04-10 10:23:08 <ikke> We don't support git urls
2021-04-10 10:23:36 <donoban> ahm, and I see that they use 3 source origins
2021-04-10 10:23:47 <donoban> tg_owt, libvpx and libvyuv
2021-04-10 10:24:07 <donoban> and set as git submodules
2021-04-10 10:24:15 <donoban> it seems that telegram does a heavy use of git submodules
2021-04-10 10:26:03 <donoban> another option is try to disable tgcalls
2021-04-10 10:26:10 <ikke> If it's a submodule, you could include it in the same package
2021-04-10 10:26:11 <donoban> and build telegram without it :\
2021-04-10 10:26:31 <donoban> download the 3 tarballs and then unpack according?
2021-04-10 10:26:46 <ikke> Yes
2021-04-10 10:26:59 <donoban> https://tpaste.us/lEew
2021-04-10 10:27:03 <donoban> there is what arch does
2021-04-10 10:27:18 <ikke> yeah, they build directly from a git repo
2021-04-10 10:27:40 <donoban> and the no-tgcalls option? xd
2021-04-10 10:27:56 <ikke> If you are the maintainer, it's for you to decide :)
2021-04-10 10:28:50 <donoban> hehe ok
2021-04-10 10:32:26 <donoban> In the main of keeping it simple, it seems the best decision :D
2021-04-10 10:33:11 <donoban> In the aim*
2021-04-10 10:47:43 <ikke> omni: interesting, I've already added a testcase for that, but it has been skipped for now
2021-04-10 11:01:16 <ikke> omni: it's difficult to exclude comments in the way that we currently implemented linting
2021-04-10 12:02:41 <ikke> anyone working on nld5 (x86_64 dev containers) right now?
2021-04-10 12:06:49 <mps> yes
2021-04-10 12:07:10 <mps> but I can stop
2021-04-10 12:07:19 <ikke> I'm planning to upgrade it
2021-04-10 12:07:35 <mps> ok, in a minute I will stop
2021-04-10 12:08:08 <mps> finished :)
2021-04-10 12:09:40 <ikke> lxc-create works with clandmeters patch
2021-04-10 12:09:53 <ikke> I guess we want to include that?
2021-04-10 12:12:30 <mps> I think so
2021-04-10 12:19:45 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20344
2021-04-10 12:29:02 <ikke> mps: will reboot nld5 soon
2021-04-10 12:29:53 <mps> NP
2021-04-10 12:31:05 <mps> will you upgrade kernel also
2021-04-10 12:31:51 <ikke> yes
2021-04-10 12:32:25 <mps> that what I'm waiting for long, thanks
2021-04-10 12:46:22 <ikke> It's up again
2021-04-10 12:46:37 <ikke> ugh
2021-04-10 12:46:49 <ikke> still using old kernel
2021-04-10 12:47:17 <ikke> -vanilla
2021-04-10 12:49:20 <mps> huh
2021-04-10 12:49:20 <ikke> rebooting one more time
2021-04-10 12:49:30 <ikke> it still had -vanilla, so it was not upgraded
2021-04-10 12:49:49 <mps> just wanted to 'scorn'
2021-04-10 12:50:23 <ikke> rebooting one more time
2021-04-10 12:50:30 <mps> go
2021-04-10 12:57:15 <ikke> nld5-dev1 [~]# uname -r
2021-04-10 12:57:18 <ikke> 5.10.27-0-lts
2021-04-10 12:57:56 <ikke> I'm happy that we found and fixed the lxc problem with 3.13
2021-04-10 12:57:59 <mps> ehm, I expeted 5.11.12-edge ;)
2021-04-10 12:58:04 <ikke> mps: :P
2021-04-10 12:59:02 <mps> we should move clamav to community, imo
2021-04-10 13:00:55 <mps> now we have to take risking clamav upgrade for 3.12-stable from 0.102.4 to 0.103.2
2021-04-10 13:18:45 <Cogitri> So, does someone know what's with py3-setuptools now knowing some keys (like tests) anymore?
2021-04-10 13:18:55 <ikke> Cogitri: not really
2021-04-10 13:21:18 <Cogitri> :/
2021-04-10 13:21:41 <Cogitri> I don't really know much Python so not sure if I can be of help with that
2021-04-10 13:22:14 <ikke> I do know python, but not the whole setuptools ecosystem
2021-04-10 13:24:43 <Hello71> is there an issue?
2021-04-10 13:25:20 <ikke> many packages fail
2021-04-10 13:25:23 <ikke> when running check
2021-04-10 13:25:47 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-mips64/testing/py3-pyroma/py3-pyroma-2.6-r1.log
2021-04-10 13:25:50 <ikke> for example
2021-04-10 13:30:23 <Hello71> i mean filed
2021-04-10 13:30:35 <ikke> ah
2021-04-10 13:30:40 <ikke> Not yet
2021-04-10 14:30:45 <ericonr> Cogitri: 'test' is supposedly a deprecated target
2021-04-10 14:30:52 <ericonr> in setuptools
2021-04-10 14:31:01 <Cogitri> Huh
2021-04-10 14:31:04 <ericonr> they should print a warning every time you run it
2021-04-10 14:31:08 <ikke> yes, it does
2021-04-10 14:31:15 <Cogitri> Ah, I guess because they're moving away from setup.py?
2021-04-10 14:31:16 <ikke> but it should at least still work
2021-04-10 14:31:25 <ericonr> did they finally remove it, maybe?
2021-04-10 14:31:35 <ericonr> python packaging is a fucking mess
2021-04-10 14:31:35 <ikke> No, the target still works
2021-04-10 15:33:33 <caskd-Alex> Are there any updates in the provider_priority problems and pulseaudio-alsa ?
2021-04-10 15:33:41 <caskd-Alex> related to pipewire?
2021-04-10 15:36:12 <Cogitri> wdym?
2021-04-10 15:37:09 <caskd-Alex> there was a conflict on installing/upgrading pulseaudio-alsa that resulted in pipewire being installed even though pulse should've been the first by priority
2021-04-10 15:37:46 <caskd-Alex> because pipewire-pulse provides pulseaudio-alsa and that is installed even though the priority is lower
2021-04-10 15:39:34 <PureTryOut[m]2> That has already been fixed a few days ago
2021-04-10 15:39:51 <PureTryOut[m]2> As in, it won't happen to people updating now. But if it has already replaced pulseaudio, it won't automatically undo itself
2021-04-10 15:40:03 <PureTryOut[m]2> https://postmarketos.org/edge/2021/04/02/pipewire-pulse/
2021-04-10 15:41:22 <caskd-Alex> that's not what i'm talking about
2021-04-10 15:43:10 <caskd-Alex> while the pipewire-pulse problem was fixed, this provides (i assume bug) is still there
2021-04-10 15:43:26 <caskd-Alex> i am gonna dig through the dep solver to see if i can find why this happens
2021-04-10 16:05:11 <caskd-Alex> http://0x0.st/-Ta6.txt line 172750 to 172763 are relevant here
2021-04-10 16:07:24 <caskd-Alex> so apparently because it provides more it is chosen over pulseaudio-alsa
2021-04-10 16:09:10 <PureTryOut[m]2> Makes sense, pulseaudio-alsa doesn't have a priority set
2021-04-10 16:09:16 <PureTryOut[m]2> So I guess that needs changing
2021-04-10 16:09:32 <caskd-Alex> it does
2021-04-10 16:09:39 <PureTryOut[m]2> Oh huh
2021-04-10 16:09:52 <PureTryOut[m]2> Ignore me then 😛
2021-04-10 16:10:18 <caskd-Alex> it solves more package deps with one install
2021-04-10 16:10:33 <caskd-Alex> idk why this would even be a choice other than for saving space
2021-04-10 16:11:18 <caskd-Alex> lemme try to build it without this in the dep calculation and see if anything changes
2021-04-10 16:11:27 <caskd-Alex> and hope that i don't break world and have to restore a snapshot
2021-04-10 16:13:18 <caskd-Alex> yep that does it
2021-04-10 16:13:34 <caskd-Alex> so uhh, should i open a pull request about this or discuss it more?
2021-04-10 16:14:03 <caskd-Alex> since idk if anything else would break as result
2021-04-10 16:14:07 <caskd-Alex> even though i highly doubt
2021-04-10 16:18:11 <caskd-Alex> or even moving it below installed packages helps more
2021-04-10 16:22:10 <caskd-Alex> http://0x0.st/-TaF.diff here's the relevant diff i tested with
2021-04-10 18:19:09 <dalias> ariadne, good to hear things are going smoothly with rust side :)
2021-04-10 18:19:29 <Ariadne> so far
2021-04-10 18:19:44 <dalias> ariadne, we really should write up the static linking bug (2 libcs) too, but avoid mixing it with this issue
2021-04-10 18:19:59 <dalias> because i'm pretty sure all existing static linking of musl by rustc is broken, too...
2021-04-10 18:19:59 <Ariadne> well both are going to be fixed
2021-04-10 18:20:08 <dalias> ah are they on it already?
2021-04-10 18:41:36 <artok> mps: have that kernel config update script around?
2021-04-10 18:42:12 <artok> mps: I just got new hd's to my builder machine so I'll be able to run again some builds
2021-04-10 18:45:37 <ericonr> dalias: from my debugging the double linking didn't seem to happen
2021-04-10 18:46:04 <ericonr> they scrape libc.a from their liblibc.rlib file before linking if one forces normal linking
2021-04-10 18:46:26 <L1Cafe> ikke Ariadne what do we need to do to get the kubernetes packages into a stable release? They’re currently on edge testing
2021-04-10 18:47:10 <Ariadne> L1Cafe: you should ask fcolista to move it to community, by filing a bug
2021-04-10 18:47:36 <dalias> ericonr, for both dynamic and static linking?
2021-04-10 18:47:43 <dalias> what does the liblibc.rlib even exist for then??
2021-04-10 18:47:49 <dalias> and why does it have a copy of musl inside it?
2021-04-10 18:48:04 <L1Cafe> Ariadne: they should file a bug or should I do that?
2021-04-10 18:53:57 <Ariadne> you should
2021-04-10 18:54:17 <Ariadne> dalias: the liblibc.rlib is the rust binding to libc
2021-04-10 18:54:27 <Ariadne> dalias: which occasionally embeds musl
2021-04-10 18:55:48 <dalias> but when does it embed?
2021-04-10 18:55:55 <dalias> whenever it's doing that it's almost surely broken
2021-04-10 18:55:59 <dalias> musl is not embeddable
2021-04-10 18:58:28 <mps> artok: here https://tpaste.us/5VqE
2021-04-10 18:59:12 <artok> thanks
2021-04-10 18:59:22 <mps> np :)
2021-04-10 19:24:50 <ericonr> dalias: it embeds it in the target stuff shipped with official rust toolchains (obtained via rustup)
2021-04-10 19:24:58 <ericonr> musl distros patch the embedding out
2021-04-10 19:25:33 <ericonr> when I forced dynamic linking using that toolchain, it stripped libc.a from liblibc.rlib
2021-04-10 19:26:23 <ericonr> I don't think that toolchain supports static linking with an external libc.a (and it doesn't pass -lc to the linker either), so there shouldn't be any situation where we get two libcs in the same file
2021-04-10 19:36:49 <dalias> do they have an equivalent thing for cross-compiling to glibc target?
2021-04-10 19:36:59 <dalias> or is this some wacky musl-specific thing they did ?
2021-04-10 19:38:00 <dalias> i'm pretty sure the last time this was discussed we saw 2 libcs being linked
2021-04-10 20:09:30 <Ariadne> dalias: it is musl specific yes
2021-04-10 20:19:07 <dalias> *sigh*
2021-04-10 20:19:16 <dalias> why would they do this differently for musl?
2021-04-10 23:44:29 <ericonr> because "create self contained binaries" is a language feature they wanted
2021-04-10 23:44:47 <ericonr> and the only way to do so on linux without reimplementing libc is by linking to musl
2021-04-10 23:45:27 <ericonr> dalias: last time I discussed this here, I also asked on tulip about it, the conclusion seemed to be only one libc
2021-04-11 00:22:23 <dalias> ok, well we should review it
2021-04-11 05:35:21 <Gottox> is the reporter of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3976 here?
2021-04-11 05:38:00 <ikke> Gottox: not here on irc afaik
2021-04-11 05:39:00 <Gottox> okay. afaics the bug is only triggered on musl systems, which is rather strange.
2021-04-11 05:39:47 <Gottox> funny bug. :D
2021-04-11 05:43:23 <i1l> Can someone with admin rights open this channel in Matrix client and set the room image?
2021-04-11 05:45:02 <ikke> I don't have matrix setup
2021-04-11 06:31:11 <Guest94145> merge !20241 plz
2021-04-11 06:45:29 <ikke> will be merged
2021-04-11 08:21:15 <DylanVanAssche_> Gottox: I'm on Matrix, but I'm in this room
2021-04-11 08:23:01 <Gottox> ah, great!
2021-04-11 08:23:27 <Gottox> I actually have no idea how that happens. Did you do any debugging yet?
2021-04-11 08:24:57 <DylanVanAssche_> Gottox: Well I tried to do some debugging and I have no clue where to even begin/start... I ran the shell in a separate window and have the same issue, I looked into the logs but couldn't see anything obvious. My debugging info is all in the upstream issue.
2021-04-11 08:49:15 <Gottox> I need to find a good place to start debugging... :D
2021-04-11 10:43:26 <donoban> I'm reading a paper about "Exploring New Host-Based Intrusion Detection, Recovery, and Response Approaches" that poses some ideas about the service manager roles that could be interesting now that Alpine is in process of write a new one "from scratch"
2021-04-11 10:45:17 <donoban> alotugh maybe is too complex for the simplicity priority of alpine, it would be nice if at least the base design allows to expand it
2021-04-11 10:46:46 <donoban> basically the service manager doesn't just start/stop/kill services, it also has the posiblity of restore them to a "safe" state, and to run them on different degraded state (e.g., with read-only filesystem, CPU quota, network quota...)
2021-04-11 10:48:25 <bratkartoffel> are there any objections prior merging these MR? !17784 and !19094
2021-04-11 10:48:45 <donoban> https://hal.inria.fr/tel-02417644/document (in case anyone is curious)
2021-04-11 10:49:27 <skarnet> donoban: this is waaaay out of scope for a service manager
2021-04-11 10:49:47 <donoban> hehe
2021-04-11 10:49:58 <skarnet> it can be done as a specific monitor for services that need it
2021-04-11 10:50:08 <skarnet> but that's about it
2021-04-11 10:50:46 <skarnet> it's more about service monitoring, in a service-specific way, than about "service management" as in machine state management, i.e. startup sequence and state changes
2021-04-11 10:52:30 <donoban> well the article itself tries to achieve something pretty complicated
2021-04-11 10:53:02 <donoban> the service monitoring could and should be run as another part, which reads logs and looks for points of interest
2021-04-11 10:53:23 <skarnet> the article uses "service manager" when it really means "process supervisor"
2021-04-11 10:53:44 <skarnet> I really hate it when people use vague terminology without exactly defining what it means
2021-04-11 10:53:52 <donoban> but then I don't see so out of scope that the service manager handles the low level part of limit the permissions of a service
2021-04-11 10:54:13 <skarnet> that's not the job of a service manager
2021-04-11 10:54:24 <skarnet> that's service policy
2021-04-11 10:54:37 <skarnet> and more precisely, longrun service policy
2021-04-11 10:54:57 <donoban> so when you say on openRC
2021-04-11 10:55:02 <donoban> run this service as user X
2021-04-11 10:55:10 <donoban> is that out of scope?
2021-04-11 10:55:33 <skarnet> no, because openrc is conflating several things
2021-04-11 10:56:17 <skarnet> you should obviously be able to configure service policy in the *interface*
2021-04-11 10:56:30 <skarnet> some of that policy applies to the service manager
2021-04-11 10:56:46 <skarnet> other parts are applied by the process supervisor
2021-04-11 10:57:12 <skarnet> dropping permissions is something that is done at the process supervisor level
2021-04-11 10:57:20 <donoban> and at this moment in alpine is there no process supervisor?
2021-04-11 10:57:48 <donoban> supervise-daemon*
2021-04-11 10:58:06 <skarnet> there are several, but by default what is used is either none at all or openrc's own supervise-daemon which does *some* of the work of a process supervisor
2021-04-11 10:58:11 <skarnet> (including dropping permissions)
2021-04-11 10:58:48 <skarnet> so what the interface does is telling either supervise-daemon or start-stop-daemon to drop permissions
2021-04-11 10:59:01 <donoban> well I don't see any problem if there are different parts
2021-04-11 10:59:21 <skarnet> I very much hope so because that's how you keep stuff small XD
2021-04-11 10:59:44 <donoban> the objective is that the system could mitigate an instrusion or problem if some service without losing avalaibity in the whole system
2021-04-11 11:00:26 <skarnet> yeah, there are several parts required for that
2021-04-11 11:00:34 <skarnet> a global one, and a local one
2021-04-11 11:00:42 <skarnet> the global one can be run as a normal service
2021-04-11 11:00:52 <skarnet> the local one is just how you run the service you want to monitor
2021-04-11 11:01:26 <skarnet> basically instead of running "foo", you run "service-monitor foo" and service-monitor has service-specific config somewhere
2021-04-11 11:01:29 <donoban> in the article, the main monitor part is most based on linux auditd
2021-04-11 11:01:58 <skarnet> it's a Ph.D. thesis, not an article :D
2021-04-11 11:02:06 <donoban> well hehe
2021-04-11 11:02:55 <skarnet> anyway yes you can run an auditd and have the service-monitor part be a client of it
2021-04-11 11:03:21 <skarnet> my point is that it can be done in a 100% modular way without needing to involve the service manager
2021-04-11 11:03:34 <donoban> "We extend the service manager to checkpoint and restore the stateof  services." this sould be task of the service supervisor?
2021-04-11 11:04:03 <skarnet> not even that, if it can be done independently, which I believe it can
2021-04-11 11:04:26 <donoban> they use CRIU for that
2021-04-11 11:04:31 <skarnet> but if it cannot, then yes, it would be the job of a process supervisor
2021-04-11 11:04:35 <donoban> CRUI and snapper
2021-04-11 11:05:41 <donoban> so, in your opinion, what is the problem with openRC so alpine is going to do a new system manager?
2021-04-11 11:06:53 <donoban> s/system/service/ :D
2021-04-11 11:06:54 <alpine-meetbot> donoban meant to say: so, in your opinion, what is the problem with openRC so alpine is going to do a new service manager?
2021-04-11 11:06:55 <skarnet> yeah, you can totally do it in a separate layer (and CRIU looks to be shady stuff which is only portable on x86 and arm)
2021-04-11 11:07:34 <skarnet> so I'd say, there's something there but it's still an academic paper and doing that kind of thing in production would... take time
2021-04-11 11:07:43 <skarnet> especially if we want to do it in a clean way :)
2021-04-11 11:08:11 <donoban> yes yes I was so pretty excited because I saw that alpine was doing a new service manager
2021-04-11 11:08:20 <donoban> so I though it would be nice to think a little in the ideas of the paper
2021-04-11 11:08:22 <skarnet> what really grinds my gears is when people need functionality in a service and their first line of thought is "we'll extend the service manager"... that's systemd think
2021-04-11 11:09:07 <donoban> hehe, look at this: "You can see in Table6.1thedifferent projects we modified where we added in total nearly3600lines of C code"
2021-04-11 11:09:20 <donoban> 2,639 new lines to systemd
2021-04-11 11:09:43 <skarnet> yeah forget it
2021-04-11 11:10:27 <skarnet> academic projects man
2021-04-11 11:10:37 <donoban> maybe is even simple to achieve something similar on a docker based infraestructure
2021-04-11 11:10:46 <skarnet> "we modified systemd in the following way: A, B, C..."
2021-04-11 11:10:57 <skarnet> and then they think their stuff is production-ready :(
2021-04-11 11:11:59 <donoban> well I will finish the read, there are interesting things :)
2021-04-11 11:12:01 <skarnet> well containers are the steamroller way of restricting a service
2021-04-11 11:12:19 <skarnet> sure you can get a lot of control if you run a service in a container
2021-04-11 11:12:43 <donoban> well they use systemd in a containerized wey... each service runs owns namespace/cgroup..
2021-04-11 11:13:18 <skarnet> yeah well you don't go any heavier than that
2021-04-11 11:13:30 <donoban> I think that there is an intention of new alpine service manager supports namespaces and cgroups
2021-04-11 11:13:51 <skarnet> again: this is not the job of the service manager
2021-04-11 11:14:06 <donoban> hehe
2021-04-11 11:14:09 <skarnet> running a service in a container can be done independently
2021-04-11 11:14:51 <skarnet> the service manager interface can support syntax for telling the process supervisor to run a service in specific namespaces/cgroups
2021-04-11 11:15:08 <skarnet> so yeah we'll be able to do it
2021-04-11 11:15:26 <skarnet> but terminology is important :)
2021-04-11 11:15:26 <donoban> I understand your view but also see pretty comfortable to specify in service description, "run this in a container"...
2021-04-11 11:15:52 <skarnet> it's exactly what I said :)
2021-04-11 11:16:00 <skarnet> you'll be able to do that
2021-04-11 11:16:04 <donoban> ah
2021-04-11 11:16:06 <donoban> I see
2021-04-11 11:16:06 <skarnet> with a nice declarative interface
2021-04-11 11:17:07 <donoban> great
2021-04-11 11:17:17 <skarnet> to answer your earlier question: there are *several* problems with openrc
2021-04-11 11:17:37 <skarnet> you can find some of them here: https://skarnet.com/projects/service-manager.html#comparison
2021-04-11 11:18:09 <skarnet> I haven't listed everything because that page isn't supposed to dive into all the technical details
2021-04-11 11:18:15 <skarnet> but it gives the main ones
2021-04-11 11:19:54 <donoban> oh, I feel that I've already read it but let's do again :)
2021-04-11 11:21:21 <skarnet> it was published early on Friday so you probably haven't read it before ;)
2021-04-11 11:22:16 <donoban> hahah lol
2021-04-11 11:22:30 <donoban> so I read something similar :S
2021-04-11 11:25:57 <donoban> so you are the same as: https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine/
2021-04-11 11:27:16 <donoban> for a moment I thought there was a prefork :D
2021-04-11 11:33:57 <skarnet> no, it's the same project :)
2021-04-11 11:41:37 <donoban> I didn't expect soo many red/orange flags on OpenRC, systemd seems a better option :D
2021-04-11 11:43:36 <afontain_> well, there is a difference between "doesn't do it", and "it does, assuming it work?"
2021-04-11 11:44:31 <donoban> It depends on how optimistic you are :)
2021-04-11 11:44:38 <afontain_> but yeah, systemd is not that bad generally speaking
2021-04-11 11:45:19 <skarnet> yeah, systemd looks greener, but that's because the comparison is mostly about features, not design
2021-04-11 11:45:42 <afontain_> my experience with half the advanced systemd features is "well, it's supposed to work, but it actually doesn't seem to do anything?"
2021-04-11 11:46:27 <skarnet> if there were more questions about "how is this stuff designed? what's the code quality? how does it respect the user?" etc. then there would be a lot more red in systemd's column
2021-04-11 11:46:28 <afontain_> (but maybe it's just me)
2021-04-11 11:47:00 <skarnet> I haven't used systemd enough to be able to tell you ;)
2021-04-11 11:48:54 <afontain_> I bet :P
2021-04-11 11:50:20 <skarnet> oh, I have used it extensively enough :P
2021-04-11 11:50:27 <skarnet> but I haven't delved into the esoteric features
2021-04-11 11:50:55 <caskd> you really don't want to unless you want to find out about them and why everyone hates them
2021-04-11 17:17:05 <omni> would x86 be i586 ("w/o SSE") or i686?
2021-04-11 17:17:30 <ikke> We target i586
2021-04-11 17:17:37 <omni> thanks!
2021-04-11 18:58:50 <dalias> even base i686 lacks sse btw
2021-04-11 18:59:06 <dalias> (at least sse2, which is needed for sse to be of any use; original sse1 was basically useless)
2021-04-11 19:15:46 <omni> ok
2021-04-11 19:16:03 <omni> how do we know things aren't accidentally built for i686?
2021-04-11 19:19:04 <Cogitri> We don't really check for that I think
2021-04-11 19:19:35 <Cogitri> There was some talk to just require SSE(2) in future Alpine releases
2021-04-11 19:27:31 <omni> I like the idea of being able to run modern software on old hardware, even if I don't think I personallyhave any 32bit x86 that old... (or do I..?)
2021-04-11 19:28:35 <omni> is armv7 hf or does this not mean much? https://pkgs.alpinelinux.org/contents?file=*cpython-*.so&path=&name=python3&branch=edge&repo=main&arch=armv7
2021-04-11 19:29:03 <Ariadne> Cogitri: that wouldbe unfortunate, as there are many alpine installs in the field based on x86 SoCs that do not support SSE(2)
2021-04-11 19:30:22 <ikke> armv7 should be hardfloat, right?
2021-04-11 19:30:33 <Ariadne> yes, armv7 is hardfloat
2021-04-11 19:31:07 <omni> ok, cool
2021-04-11 19:31:21 <Ariadne> Cogitri: i hope if we do switch to i686 that we will introduce a new arch for this, so that i can keep i586 alpine going without it being confusing
2021-04-11 19:31:25 <omni> how do they differ, though, armv7 and armhf?
2021-04-11 19:31:34 <ikke> armhf is armv6
2021-04-11 19:31:38 <Ariadne> armhf is armv6, with hardfloat (it's optional in armv6)
2021-04-11 19:31:38 <omni> ah
2021-04-11 19:31:58 <Ariadne> armel is armv5, which we no longer build packages for
2021-04-11 19:32:42 <omni> what is armv7l? (=
2021-04-11 19:34:27 <Cogitri> Ariadne: I'd rather not go through all that effort for an effectively dead arch
2021-04-11 19:34:43 <omni> I'm banging my head against maturin and with some help from upstream I got tests to pass for x86_64 and aarch64 but still have issues with 32bit x86 and armv7 (and armhf might not be possible, can't test)
2021-04-11 19:34:58 <Cogitri> We we want to keep i686 SSE free, then so be it but let's not make the overhead of maintaining packages even greater with yet another arch next to no one will use
2021-04-11 19:35:03 <ikke> omni: I can test for you if you want
2021-04-11 19:35:05 <Cogitri> s/We/if/
2021-04-11 19:35:05 <alpine-meetbot> Cogitri meant to say: if we want to keep i686 SSE free, then so be it but let's not make the overhead of maintaining packages even greater with yet another arch next to no one will use
2021-04-11 19:35:59 <omni> ikke: cool! I'll tell you if I get the tests to pass for armv7, don't think they'll run on armhf before that..
2021-04-11 19:36:13 <ikke> nod
2021-04-11 19:41:45 <Ariadne> Cogitri: i agree, it is better to keep x86 on i586, since "desktop" users are all likely to use the x86_64 port instead if they want performance
2021-04-11 19:42:05 <Ariadne> but technically, armel is still available
2021-04-11 19:42:08 <ikke> That would make sense to me
2021-04-11 19:42:30 <Ariadne> i do build armel packages for alpine for a specific customer
2021-04-11 19:42:42 <Ariadne> (a very limited package set)
2021-04-11 19:43:25 <Ariadne> and in the case of x86 becoming i686, i am sure people would ask for the i586 port to be kept going
2021-04-11 19:43:26 <ikke> for some sort of bsc?
2021-04-11 19:43:29 <ikke> sbc?
2021-04-11 19:43:29 <Ariadne> even if unofficially
2021-04-11 19:43:32 <Ariadne> yeah
2021-04-11 19:43:53 <Ariadne> very similar to the octeon port
2021-04-11 19:45:09 <Ariadne> there's an organization that has tens of thousands of sensors out in the world measuring atmospheric quality
2021-04-11 19:45:22 <ikke> aha, interesting
2021-04-11 19:45:24 <Ariadne> they use alpine, on armel, on these boards, because of the run from ram
2021-04-11 19:45:31 <ikke> nice
2021-04-11 19:46:00 <Cogitri> Interesting
2021-04-11 19:46:19 <Cogitri> And I think it's fair that we have a limited package set for those arches
2021-04-11 19:46:31 <Ariadne> well publicly we have a 0 package set for armel
2021-04-11 19:46:47 <Ariadne> because its not worth supporting at distro level anymore
2021-04-11 19:47:00 <Ariadne> though i am planning to start an "alpine ports" project to improve that
2021-04-11 19:47:05 <ikke> armhf support is only due to rpi zero
2021-04-11 19:47:07 <Cogitri> But at times I wonder if having mips64 with all packages enabled by default (or rather lots of them disabled because they don't work and probably more being silently broken) is worth it
2021-04-11 19:48:57 <Cogitri> And maybe phasing out armhf would be worth it too
2021-04-11 19:49:07 <Ariadne> Cogitri: yes, that's the goal of the alpine ports project
2021-04-11 19:49:45 <Ariadne> Cogitri: i plan to introduce mips64hf as a replacement for mips64 architecture that is hardfloat.
2021-04-11 19:49:57 <Ariadne> Cogitri: which should be basically same story as s390x
2021-04-11 19:50:26 <Ariadne> Cogitri: but i still need to support the mips64 softfloat due to octeon having a broken FPU
2021-04-11 19:51:19 <Ariadne> Cogitri: i also plan for mips64el to be hardfloat when we start supporting loongson
2021-04-11 19:51:35 <Ariadne> most of the problems with the mips port is that its softfloat
2021-04-11 19:52:38 <omni> hardsink?
2021-04-11 19:52:47 <Ariadne> ?
2021-04-11 19:53:04 <omni> nvm me
2021-04-11 19:53:16 <Ariadne> hardfloat means we use the hardware FPU
2021-04-11 19:53:22 <Ariadne> softfloat means we emulate an FPU
2021-04-11 19:54:17 <omni> I meant broken fpu, that it doesn't float *badum*
2021-04-11 19:54:45 <Cogitri> Oh wow I get it now :D
2021-04-11 19:55:00 <Ariadne> octeon (until octeon 3) has an FPU that does not properly implement some instructions
2021-04-11 19:55:06 <Ariadne> to get around patents
2021-04-11 19:55:44 <Ariadne> those patents expired with octeon 3, so they implemented the full MIPS FPU
2021-04-11 19:56:08 <Ariadne> there are other mips64 CPUs coming out too, like the fungible NPU
2021-04-11 19:56:20 <Ariadne> so there is value in the mips64 port in some way, but probably as a hardfloat port
2021-04-11 19:56:48 <Cogitri> So what's the roadmap for arch removal/addition?
2021-04-11 19:56:55 <Ariadne> no idea
2021-04-11 19:57:00 <Cogitri> Remove mips64 non hardfloat and armhf, add riscv?
2021-04-11 19:57:09 <ikke> at least armhf will be supported for the time being
2021-04-11 19:57:14 <Ariadne> armhf we keep around
2021-04-11 19:57:18 <Ariadne> pi zero needs it
2021-04-11 19:57:23 <Ariadne> postmarketOS needs it too
2021-04-11 19:57:23 <hg> I still want someone to make a 1-bit-addressable machine
2021-04-11 19:57:29 <Ariadne> N900 is armhf
2021-04-11 19:57:34 <hg> (and support it well enough that I can actually use it)
2021-04-11 19:58:03 <ikke> hg: so that you can address individual bits? :D
2021-04-11 19:58:04 <Ariadne> 1-bit addressing could not support even a single byte of ram :)
2021-04-11 19:58:07 <ikke> heh
2021-04-11 19:58:21 <hg> ikke: yes
2021-04-11 19:58:32 <Ariadne> oh, i see
2021-04-11 19:58:46 <Ariadne> so you could do bitwise math without having to pack it into a byte?
2021-04-11 19:58:51 <hg> yes
2021-04-11 19:59:00 <ikke> So you would need to have 512 bits systems :P
2021-04-11 19:59:03 <Ariadne> i think riscv has an extension for that
2021-04-11 19:59:09 <hg> and languages with sense could compile booleans down to a single bit
2021-04-11 19:59:13 <hg> ugh
2021-04-11 19:59:17 <hg> how much I want that
2021-04-11 19:59:22 <hg> native dense arrays
2021-04-11 19:59:25 <hg> native bitarrays
2021-04-11 19:59:37 <hg> please, someone do it
2021-04-11 19:59:39 <hg> do it for me
2021-04-11 19:59:41 <hg> and for science
2021-04-11 19:59:55 <ikke> Sounds very expensive
2021-04-11 20:00:19 <hg> hell, it could let you have arbitrarily-sized, fixed width integers with hardware accel
2021-04-11 20:00:22 <hg> oh my god
2021-04-11 20:00:25 <hg> thedesires
2021-04-11 20:07:51 <Cogitri> Ariadne: Btw, do you happen to know if there's a way to update the info of an apk_database without closing&opening it again?
2021-04-11 20:08:17 <Ariadne> no, an apk2 database has to be rescanned by reopening it
2021-04-11 20:08:24 <Ariadne> apk3 it will "just work"
2021-04-11 20:08:25 <Cogitri> Ah that's unfortunate
2021-04-11 20:08:37 <Cogitri> apk-polkit-rs currently spends a rather significant amount of time closing and opening the db between transactions
2021-04-11 20:08:51 <Ariadne> what is a transaction in apk-polkit-rs?
2021-04-11 20:09:14 <Ariadne> you should be able to just submit the entire upgrade transaction to libapk and run it as a single tx
2021-04-11 20:09:47 <Cogitri> A transaction is a single package upgrade since gnome-software demands that level of control
2021-04-11 20:12:05 <Ariadne> gnome software can't batch it?
2021-04-11 20:12:09 <Ariadne> wtf :D
2021-04-11 20:12:33 <Ariadne> but yah unfortunately due to the way the database format works, you have to rescan it every time
2021-04-11 20:12:53 <Ariadne> apk gets around this by batching transactions
2021-04-11 20:13:18 <Cogitri> Ah, g-s can batch it, but users have the abilities to click upgrade for each package in the UI
2021-04-11 20:13:34 <Ariadne> yeah, so if they do it that way it will be slow
2021-04-11 20:13:40 <Ariadne> but if g-s batches it it shouldn't be too bad
2021-04-11 20:13:50 <Cogitri> Yeah, then it's not too bad
2021-04-11 20:14:21 <Cogitri> Btw, not sure where to submit proposals for apkv3 but would be neat if libapk didn't print things to stdout
2021-04-11 20:14:43 <ikke> apk-tools project
2021-04-11 20:14:46 <ikke> or mailing list
2021-04-11 20:15:30 <Ariadne> Cogitri: this is fixed in apk3, by the apk_log subsystem
2021-04-11 20:15:37 <Cogitri> Great
2021-04-11 20:15:44 <mps> I build kernel in arvm7 mode for nokia N900
2021-04-11 20:15:47 <Ariadne> you can subscribe to apk_log events and handle them however you want
2021-04-11 20:16:01 <Ariadne> mps: and it works?  i thought OMAP processors were all armv6
2021-04-11 20:16:31 <omni> ikke: I'm not gonna get anywhere with this right now !20321, please try on armhf if you want, see if you get similar or other errors, have suggestions etc
2021-04-11 20:16:50 <Cogitri> Ariadne: Yay, excited for apkv3 :)
2021-04-11 20:17:32 <mps> Ariadne: yes, it works
2021-04-11 20:18:24 <Ariadne> oh, n900 is cortex-a8
2021-04-11 20:18:26 <Ariadne> which is armv7
2021-04-11 20:18:27 <mps> I have alpine armv7 on it
2021-04-11 20:18:39 <omni> Cogitri: it can't be slower than dnf
2021-04-11 20:18:50 <ikke> does-not-finish? :P
2021-04-11 20:19:17 <omni> oh, I thought it was "did not finish"
2021-04-11 20:20:05 <omni> even my beaglebone (white) is armv7
2021-04-11 20:21:33 <Cogitri> omni: always fun when dnf needs to fetch 120MB of repo data just do I can install some 12KB package
2021-04-11 20:21:42 <ikke> w0t
2021-04-11 20:21:58 <Cogitri> although it's still faster than apt for me
2021-04-11 20:21:59 <omni> Cogitri: or just to search for a package...
2021-04-11 20:22:04 <Cogitri> Yeah
2021-04-11 20:22:53 <Cogitri> especially fun since it fetches repo data again if I do `sudo dnf install` and do `dnf search` without root again afterwards
2021-04-11 20:28:36 <omni> also rpi pico (2021-01), all 1 models and compute module 1 seem to be armv6 (but at least those are old)
2021-04-11 23:56:59 <omni> qtwebengine package is missing qtwebengine
2021-04-11 23:57:47 <Cogitri> Yup, we already have an issue for that I think
2021-04-11 23:57:54 <Cogitri> only contains some pdf stuff for some reason
2021-04-11 23:59:43 <omni> an mr too...
2021-04-12 00:02:37 <omni> with failing builds
2021-04-12 00:12:11 <omni> could we revert the latest commit of qt5-qtwebengine until it's fixed?
2021-04-12 00:26:23 <omni> where can I find the repo with the e0b4b9436033e9bc376597ed90dd1fca9cdc90ff commit?
2021-04-12 00:27:20 <omni> oh, nvm, it's just another branch
2021-04-12 00:44:04 <omni> https://github.com/qt/qtwebengine/commit/e0b4b9436033e9bc376597ed90dd1fca9cdc90ff =/
2021-04-12 01:29:15 <omni> I mean, I see why you'd want to update to that, there are also a few other chromium bumps before that commit
2021-04-12 06:00:20 <i1l-test> skarnet pure-menu does not working for me (Android): https://skarnet.com/#menu
2021-04-12 06:03:08 <i1l-test> alpinelinux.org's working.
2021-04-12 06:33:40 <ncopa> morning
2021-04-12 06:34:03 <ikke> o/
2021-04-12 06:34:04 <Ariadne> hi
2021-04-12 06:35:48 <ncopa> seems like there happened alot over the weekend. im gonna get some breakfast and then im gonna thank you ppl
2021-04-12 06:51:19 <maribu[m]> $ apk info --who-owns /usr/lib/python3.8/site-packages/pyparsing.py
2021-04-12 06:51:19 <maribu[m]> /usr/lib/python3.8/site-packages/pyparsing.py is owned by py3-parsing-2.4.7-r2
2021-04-12 06:51:50 <maribu[m]> That is already the most recent version. The latest git commit is rebuild against python3.9. Maybe rebuilt again?
2021-04-12 06:53:39 <Ariadne> on what arch?
2021-04-12 06:54:02 <maribu[m]> Never mind, looks like I had local rebuilds installed.
2021-04-12 07:42:08 <Cogitri> Seems like kubernetes still SEGFAULTs on aarch64 during build :/
2021-04-12 08:03:17 <ncopa> Ariadne: thank you for the gcc 10.3 update
2021-04-12 08:04:11 <ncopa> and thank you for raising the alpine 15 release version thing. i think its good to ask the question once in a while. and I don't think we should underestimate the value of marketing
2021-04-12 08:05:13 <ncopa> ikke: thank you for setting the foot down on the mailing list, showing that we don't tolerate harassing
2021-04-12 08:06:50 <ncopa> Ariadne: do we continue use gcc 10.x stable branch git snapshots? why dont we stick to the 10.3 release?
2021-04-12 08:08:55 <ncopa> i will try have a look at the aarch64 kubernetes thingy later today
2021-04-12 08:17:37 <Cogitri> Thanks
2021-04-12 08:18:30 <ikke> Can someone look into meson?
2021-04-12 08:25:51 <mps> we need to 'fix' clamav for previous stable releases, 3.12 and back. problem is backporting 'fixes' is a lot of work and questionable safety
2021-04-12 08:26:42 <mps> other option upgrade to latest upstream stable on all our supported releases
2021-04-12 08:26:54 <mps> nothing depends on clamav-dev
2021-04-12 08:27:40 <mps> on older releases problem could appear in some 'interfaces' (options) to other programs
2021-04-12 08:29:30 <mps> and we should move such programs to community
2021-04-12 09:22:08 <PureTryOut[m]2> b.a.o says it's building qt5-qtwebengine on aarch64, but clicking on the link to go to the build log returns a 404. Why is that?
2021-04-12 09:22:32 <ncopa> logs are not compied til after the build is done
2021-04-12 09:51:15 <PureTryOut[m]2> That does not seem to be true, I could actively follow the log when it was building it for x86_64
2021-04-12 09:52:10 <Cogitri> It's only the case for some builders (like aarch64 and ppc64le I think)
2021-04-12 09:54:27 <mps> PureTryOut[m]2: only x86_64 is in 'real-time'. other at the end
2021-04-12 09:54:33 <PureTryOut[m]2> Oh interesting
2021-04-12 09:54:46 <mps> afaik, have to add
2021-04-12 10:14:16 <ncopa> yeah, so that is because the distfiles happens to be on the same host as x86_64. It used to be shared with x86 too in the past, over NFS, but now it is only x86_64
2021-04-12 10:14:44 <ncopa> we will likely move that to separate host at somepoint, so then will not even x86_64 be realtime
2021-04-12 10:35:56 <skarnet> i1l-test: I know and I have no idea why it's not working because it's copied directly from the pure site where it works :/
2021-04-12 10:36:13 <skarnet> if alpinelinux.org's based on the same thing I'll take a look.
2021-04-12 10:51:26 <ikke> For some reason, meson does not install the meson binary on s390x
2021-04-12 10:52:03 <ikke> Might be a setuptools issue?
2021-04-12 10:56:56 <ikke> https://tpaste.us/kkbw
2021-04-12 11:02:44 <ikke> /usr/lib/python3.9/distutils/dist.py:274: UserWarning: Unknown distribution option: 'entry_points'
2021-04-12 11:02:47 <ikke> that explains
2021-04-12 11:04:25 <omni> are clocks running late on the builders? (like a week)
2021-04-12 11:04:42 <ikke> omni: what builder?
2021-04-12 11:07:20 <ikke> Fixed meson on s390x (removed old (newer) py3-setuptools package and rebuilt meson)
2021-04-12 11:08:55 <omni> ikke: possibly all of them? I noticed in timestamps on the first line of log files and in file listings on b.a.o/buildlogs
2021-04-12 11:09:17 <ikke> date returns april 12th
2021-04-12 11:09:24 <ikke> Mon Apr 12 11:09:06 UTC 2021
2021-04-12 11:09:34 <omni> https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/py3-qtwebengine/py3-qtwebengine-5.15.2-r1.log
2021-04-12 11:09:52 <ikke> That's 5 days ago?
2021-04-12 11:10:04 <omni> but it was this morning
2021-04-12 11:10:27 <ikke> build-edge-armv7 [~]# date
2021-04-12 11:10:30 <ikke> Mon Apr 12 11:10:18 UTC 2021
2021-04-12 11:12:29 <omni> algitbot: what had you trigger? # date ?
2021-04-12 11:12:47 <ikke> omni: [pr] #
2021-04-12 11:12:59 <omni> good answer, bot
2021-04-12 11:13:30 <ikke> last commit to py3-qtwebengine was about 3 weeks ago
2021-04-12 11:15:28 <ikke> omni: that log file was created on april 7th
2021-04-12 11:15:29 <omni> oooh! *faceapalm*
2021-04-12 11:15:55 <ikke> did you mean qt5-qtwebengine?
2021-04-12 11:16:15 <omni> yes, thought I was looking at that...
2021-04-12 11:16:27 <omni> sorry 'bout that
2021-04-12 11:16:35 <ikke> no problem
2021-04-12 11:19:35 <omni> not through my first cup of coffee yet =)
2021-04-12 12:34:50 <ncopa> kubeadm does not segfautl when linked static
2021-04-12 13:07:47 <minimal> dalias: what's your view on https://github.com/microsoft/mimalloc ? Not for general use but for selective "performance" use (i.e. big Java programs like Elasticsearch). Wondering whether its worth making an official aport for it (I've had it packaged locally for a while)
2021-04-12 13:14:56 <ericonr> ncopa: TEXTRELs?
2021-04-12 13:42:27 <omni> I forget, was there a way to get a view what's in the pipeline queue for a builder?
2021-04-12 13:44:22 <ncopa> ericonr: not sure. but it seems it works if i add -buildmode=pie which seems to be unintentional disabled
2021-04-12 13:47:18 <ericonr> sounds like textrel :p
2021-04-12 13:47:28 <ericonr> Go toolchain is kind of weird in some places
2021-04-12 13:47:37 <ncopa> yeah
2021-04-12 13:47:58 <ericonr> readelf -d, if you don't remember the command for it
2021-04-12 13:49:13 <ncopa> im just adding -buildmode=pie now and are also backporting removal of external coreutils/findutils dependency
2021-04-12 14:11:40 <dalias> minimal, i saw nothing exciting about it. the marketing material muddles that the interesting features they designed it around are only for a custom API they needed for whatever language runtime they were using it with, and aren't available with standard malloc api
2021-04-12 14:12:23 <dalias> ncopa, uhg what did they do? add -fno-pie of their own?
2021-04-12 14:14:19 <ncopa> no. but our go toolchain no longer do PIE by default, instead we set GOFLAGS=-buildmode=pie in the builder env. The kubernetes APKBUILD overrides the GOFLAGS
2021-04-12 14:14:30 <ncopa> without appending -buildmode=pie
2021-04-12 14:17:45 <dalias> ...
2021-04-12 14:17:59 <dalias> if link is pie by default, go probably needs to be setup as pie by default too
2021-04-12 14:46:57 <ikke> omni: it's not exposed
2021-04-12 14:54:08 <omni> ah, then I know =)
2021-04-12 15:33:15 <ncopa> Ariadne: do you know what the status of rust with musl is?
2021-04-12 15:47:50 <omni> !20148
2021-04-12 15:54:55 <ikke> omni: should I still check that on armhf?
2021-04-12 16:32:59 <omni> ikke: I have a separate mr where I thought I'd continue to work on arm*
2021-04-12 16:33:08 <ikke> ok
2021-04-12 16:33:09 <omni> but now I can't seem to reach gitlab.a.o?
2021-04-12 16:33:17 <ikke> up for me
2021-04-12 16:33:21 <omni> hmm...
2021-04-12 16:34:41 <omni> "took too long to respond"
2021-04-12 16:35:24 <ikke> gitlab page?
2021-04-12 16:37:45 <omni> gitlab everything, I get "TLS handshake timeout" from lab, but it's probably some networking issues at my end of the string, although everything else seem to work fine
2021-04-12 16:42:48 <omni> there we go
2021-04-12 17:02:50 <Ariadne> ncopa: as previously stated, postponed until 3.15
2021-04-12 17:03:02 <Ariadne> ncopa: at the current rate of red tape, that might even be 3.16
2021-04-12 17:03:20 <Ariadne> :)
2021-04-12 17:05:25 <Hello71> alpine 4.0: finally with rust support
2021-04-12 17:07:10 <Cogitri> Well, we support Rust right now too, just not on some exotic arches and with a downstream patch to patch in our triplets
2021-04-12 17:14:22 <Ariadne> yes but he was asking about the fixing of all of this
2021-04-12 17:14:23 <Ariadne> :p
2021-04-12 17:25:47 <ncopa> ok. thanks
2021-04-12 19:10:48 <donoban> hi, if I have many sources in an APKBUILD can I specify where extract some of them?
2021-04-12 19:12:10 <ikke> donoban: they will always be unpacked in srcdir
2021-04-12 19:12:54 <omni> but you can move/copy around, preferrably in a prepare() stage
2021-04-12 19:12:57 <ikke> If you need to move them to a certain location, you can do that in the prepare stage
2021-04-12 19:12:59 <ikke> \yes
2021-04-12 19:13:12 <donoban> uhM
2021-04-12 19:14:10 <omni> donoban: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#prepare.28.29
2021-04-12 19:14:20 <donoban> problem is that two of them don't have a main dir, a lot of files are dumped to src
2021-04-12 19:14:40 <donoban> thanks
2021-04-12 19:14:56 <ikke> donoban: oh, not fun
2021-04-12 19:15:09 <omni> what is it?
2021-04-12 19:15:28 <donoban> telegram-desktop
2021-04-12 19:15:45 <donoban> or more accurately tg_owt
2021-04-12 19:16:01 <ikke> where do you get the archive from?
2021-04-12 19:16:02 <donoban> upstream builds it using two git submodules
2021-04-12 19:16:27 <donoban> the problematic are like:
2021-04-12 19:16:35 <donoban>         libvpx.tar.gz::https://chromium.googlesource.com/webm/libvpx/+archive/b41ffb53f1000ab2227c1736d8c1355aa5081c40.tar.gz
2021-04-12 19:35:43 <omni> looks like build-edge-armv7 has been stuck on community/telepathy-glib for quite a while... all day, if you ask me
2021-04-12 19:42:43 <ikke> it's stuck on tests
2021-04-12 21:58:59 <donoban> I'm trying with this "workaround" https://tpaste.us/PKWe
2021-04-12 21:59:33 <donoban> I don't see other alternative, some files have the same name so get directly overwritten
2021-04-13 00:01:32 <omni> hmm... https://pkgs.alpinelinux.org/contents?path=%2A%2F__pycache__&page=10564&branch=edge
2021-04-13 00:01:50 <omni> is compiling and packaging python bytecode intentional?
2021-04-13 00:26:39 <Ariadne> Yes.  We don't want to regenerate bytecode at install time.
2021-04-13 01:20:12 <minimal> Ariadne: has it ever by thought to package only the Python bytecode and not the py files?
2021-04-13 02:23:32 <Ariadne> [20:20] <minimal> Ariadne: has it ever by thought to package only the Python bytecode and not the py files?
2021-04-13 02:23:35 <Ariadne> yes, it has
2021-04-13 02:23:52 <Ariadne> we concluded not to do it because backtracked depend on source to be helpful
2021-04-13 06:30:47 <ncopa> good morning
2021-04-13 06:34:48 <Cogitri> Morning
2021-04-13 06:34:49 <Cogitri> Seems like a got a merge commit on 3.11-stable :/
2021-04-13 07:21:23 <Cogitri> PureTryOut[m]2: error: '__NR_fstatat' was not declared in this scope; did you mean 'sys_fstatat'? on aarch64 w/ qt5-qtwebengine
2021-04-13 08:08:07 <ikke> Seems like they are trying to do direct syscalls?
2021-04-13 08:09:20 <Cogitri> That's probably for allowing some syscalls in the seccomp sandbox
2021-04-13 08:34:07 <PureTryOut[m]2> Cogitri: is that while trying to run it?
2021-04-13 08:37:26 <Cogitri> Nop, on the builders
2021-04-13 08:40:31 <ikke> Ariadne: https://github.com/opencve/opencve
2021-04-13 08:41:11 <PureTryOut[m]2> Cogitri: but qt5-qtwebengine has already successfully built for aarch64?
2021-04-13 08:44:11 <Cogitri> Oh, that was armv7, whoops
2021-04-13 08:44:12 <Cogitri> https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/qt5-qtwebengine/qt5-qtwebengine-5.15.3_git20200401-r1.log
2021-04-13 08:44:18 <Cogitri> But seems like that as an old log?
2021-04-13 08:44:49 <Cogitri> Sorry about that, just saw the error message in #alpine-commits this morning
2021-04-13 08:45:57 <mps> ncopa: did you read my notes here about clamav upgrade ideas/problems for older stable releases
2021-04-13 08:46:29 <mps> I don't want to bother c_landmeter with this because he is 'short with time'
2021-04-13 09:02:07 <ncopa> mps: i saw that yo commented but i didnt look up the details
2021-04-13 09:02:47 <ncopa> but in general, i am in favor of using updated upstream release if possible (it does not break anything or require any config changes)
2021-04-13 09:03:03 <ncopa> i think that is preferred over backporting patches
2021-04-13 09:10:48 <mps> ok, I think upgrade to latest stable release for 3.12 and 3.11 will not break users systems
2021-04-13 09:11:47 <PureTryOut[m]2> Cogitri: haha np. Seems armv7 did fail indeed, will look into it
2021-04-13 09:14:03 <ikke> ncopa: what removes old packages from the builder repositories? py3-setuptools was reverted, but on some arches, the 'newer' version was still present, so it was still used
2021-04-13 09:17:30 <omni> PureTryOut[m]2: is it the bundled ninja? could samurai be used instead?
2021-04-13 09:17:49 <PureTryOut[m]2> Why would the bundled ninja be it?
2021-04-13 09:18:02 <omni> no, sorry
2021-04-13 09:18:21 <omni> dunno
2021-04-13 09:26:50 <PureTryOut[m]2> Funny, the file that is failing hasn't been changed in 7 years...
2021-04-13 09:28:00 <mps> bits rust-ed :)
2021-04-13 09:29:00 <PureTryOut[m]2> Maybe it just needs to retry, Qt5Webengine do be like that...
2021-04-13 09:29:02 <ncopa> ikke: after apk repo build is done it will remove old packages
2021-04-13 09:29:19 <ikke> Ah, OK, explains
2021-04-13 09:36:46 <omni> when resurrecting, should I bump py3-adblock? !20148
2021-04-13 09:37:33 <omni> I'm leaning towards yes, since it's a rebuild
2021-04-13 09:44:31 <omni> so I did, can't hurt
2021-04-13 10:54:48 <donoban> Any clue of what is trying to rename and why?
2021-04-13 10:54:49 <donoban> >>> tg_owt-dev*: Running split function dev...
2021-04-13 10:54:51 <donoban> mv: can't rename '/home/builder/aports/community/tg_owt/pkg/tg_owt/usr/include': Directory not empty
2021-04-13 10:55:55 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1883
2021-04-13 10:55:58 <ikke> or
2021-04-13 10:56:03 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1891
2021-04-13 10:56:24 <donoban> let me check thanks
2021-04-13 11:07:19 <omni> PureTryOut[m]2: unfortunately, the retry didn't succeed
2021-04-13 11:12:17 <PureTryOut[m]2> Noticed
2021-04-13 12:04:13 <mps> in !20428 author want to remove CVE id which is related only on windows.
2021-04-13 12:04:49 <mps> I'm not sure about this
2021-04-13 12:05:19 <mps> do we keep/write unrelated CVEs
2021-04-13 12:11:30 <ikke> Maybe to satisfy bad security scanners
2021-04-13 12:14:51 <ddevault> has anyone encountered an issue with python aports in which they no longer install binaries
2021-04-13 12:15:13 <Cogitri> ddevault: Yes, setuptools==56 broke stuff
2021-04-13 12:15:15 <Cogitri> We downgraded back to 52 for the time being
2021-04-13 12:15:40 <ddevault> okay, thanks
2021-04-13 12:15:45 <ddevault> is there a ticket I can read?
2021-04-13 12:16:28 <Cogitri> Unfortunately I don't think we have a ticket for that, just IRC logs and  5ec095166176c72ac27a27b0c695e20626ddcb79
2021-04-13 12:16:38 <Cogitri> 5ec095166176c72ac27a27b0c695e20626ddcb79
2021-04-13 12:16:52 <Cogitri> Ugh, clipboard didn't want to work the way I wanted it to :D ca7f4b5b3c6fe3292cb32600417d0fbf49d255ac
2021-04-13 12:17:07 <ddevault> is Leo on IRC?
2021-04-13 12:17:13 <Cogitri> maxice8: ^
2021-04-13 12:17:24 <ddevault> maxice8: have you poked upstream about this?
2021-04-13 12:17:38 <maxice8> No
2021-04-13 12:17:42 <ddevault> can you?
2021-04-13 12:18:28 <mps> ikke: didn't understood your answer
2021-04-13 12:20:04 <maxice8> I can try but we de-vendor their dependencies and Arch Linux doesn't have this problem (on 54.2.0) as far as I can tell
2021-04-13 12:20:42 <ddevault> if nothing else, we should write down what we know *somewhere*, so that we can work (gradually) towards a long-term solution
2021-04-13 12:24:45 <maxice8> I added a warning above pkgver= in the APKBUILD, if necessary I can open an issue
2021-04-13 12:28:24 <ddevault> yeah, please do
2021-04-13 12:33:58 <maxice8> opened
2021-04-13 12:44:17 <ddevault> thanks!
2021-04-13 14:55:35 <crosbymichael> is there a good way to update checksums on a system like macOS?  or should I just try and compile abuild to do this?
2021-04-13 14:56:30 <ikke> Abuild is a shell script
2021-04-13 14:58:21 <crosbymichael> it looks like there are other abuild-* that are compiled
2021-04-13 14:59:08 <ikke> Right, the helpers
2021-04-13 14:59:40 <ikke> But for updating checksums, they are not required
2021-04-13 15:00:05 <crosbymichael> nice
2021-04-13 15:00:23 <ikke> But otherwise you'd have to calculate the sha512sums of the source files and upsets them
2021-04-13 15:00:31 <ikke> Including the names
2021-04-13 15:01:00 <crosbymichael> ya, i'm too lazy to do that by hand ;)
2021-04-13 15:25:46 <ncopa> there is also a docker wrapper script, docker-abuild https://gitlab.alpinelinux.org/alpine/docker-abuild
2021-04-13 15:31:26 <artok> that should get more love, it seems
2021-04-13 15:33:56 <ncopa> it needs love, yes
2021-04-13 15:34:17 <skarnet> who doesn't
2021-04-13 15:34:53 <artok> just checked that my edits for that indeed were on the hd that broke
2021-04-13 15:35:24 <artok> 
ACTION forks

2021-04-13 15:45:40 <Ariadne> i wish we could remove FIPS support from NSS and OpenSSL
2021-04-13 15:45:55 <Ariadne> we are not FIPS-certified, so it seems bad to give people that footgun
2021-04-13 15:47:47 <Ariadne> #12313
2021-04-13 15:47:53 <Ariadne> i think we solve this by removing FIPS mode
2021-04-13 15:49:17 <Ariadne> but that change will piss people off, so *grumble*
2021-04-13 15:55:31 <jvoisin> oh, Google is funding reproducible builds for Alpine?
2021-04-13 15:58:16 <Ariadne> among other things, yes
2021-04-13 15:59:01 <dalias> why does stripping inhibit fips mode??
2021-04-13 15:59:21 <Ariadne> dalias: because the cryptographic module is "signed"
2021-04-13 15:59:32 <Ariadne> during build
2021-04-13 15:59:57 <Ariadne> stripping the module changes the checksum, invalidates the "signature"
2021-04-13 16:00:06 <Ariadne> i use quotes here intentionally
2021-04-13 16:00:11 <ericonr> the build also verifies that sources weren't patched, doesn't it?
2021-04-13 16:00:20 <Ariadne> nope :D
2021-04-13 16:00:36 <Ariadne> FIPS mode is dumb
2021-04-13 16:00:37 <ericonr> oh, that might be openssl, then
2021-04-13 16:00:38 <Ariadne> anyway
2021-04-13 16:00:51 <ericonr> I had read some about FIPS, but yeah, it all seemed very dumb
2021-04-13 16:01:07 <Ariadne> government at its finest
2021-04-13 16:13:14 <maxice8> 207c2384584cd70909e3d00761c770850e475d87
2021-04-13 16:13:32 <maxice8> seems like a mixup happened while ncopa was pushing it removed some packages
2021-04-13 16:13:47 <Hello71> heh
2021-04-13 16:16:31 <maxice8> pushed it all back up
2021-04-13 16:23:30 <ikke> py3-adblock fails
2021-04-13 16:24:04 <ikke> This was something ncopa alreayd mentioned and omni is/was trying to address
2021-04-13 16:24:54 <maxice8> disabled for now
2021-04-13 16:32:53 <omni> !20148
2021-04-13 16:33:10 <ikke> nof
2021-04-13 16:33:11 <ikke> nod*
2021-04-13 16:33:30 <ikke> You need to rebase it now and fix conflcts
2021-04-13 16:33:45 <omni> oh, brb
2021-04-13 16:40:07 <ikke> What should we do about the curl CVEs (!12568). The provided patches only apply on edge
2021-04-13 16:40:14 <ikke> #12568
2021-04-13 16:40:30 <ikke> (https://gitlab.alpinelinux.org/alpine/aports/-/issues/12568
2021-04-13 16:44:49 <mps> backport or ask Daniel (upstream) to make proper for older versions
2021-04-13 16:45:01 <omni> there, I think I've fixed the conflicts
2021-04-13 16:45:49 <mps> omni: for #12568 ?
2021-04-13 16:46:09 <omni> no, !20148
2021-04-13 16:46:16 <mps> ah
2021-04-13 16:47:23 <omni> qutebrowser installs on aarch64, x86 & x86_64 are blocked by its dependency py3-adblock not being available
2021-04-13 18:21:40 <ikke> regarding coccinelle: https://systeme.lip6.fr/pipermail/cocci/2021-March/008526.html
2021-04-13 21:32:18 <ericonr> Ariadne: not to shame a specific dev (which is why I'm not sharing on zulip), but another instance of musl==static, where someone forces static linkage for all musl targets: https://github.com/benfred/remoteprocess/blob/master/build.rs
2021-04-13 21:32:38 <Ariadne> :D :D :D :D :D :D
2021-04-13 21:33:09 <Ariadne> my suggestion would be to open a bug
2021-04-13 21:35:30 <dalias> uhg
2021-04-13 21:35:37 <dalias> is it this same person?
2021-04-13 21:36:06 <dalias> hmm one thing cargo probably really needs...
2021-04-13 21:36:10 <Cogitri> cargo-c forces static libraries on musl too noe I think
2021-04-13 21:36:23 <Cogitri> s/noe/now/
2021-04-13 21:36:23 <alpine-meetbot> Cogitri meant to say: cargo-c forces static libraries on musl too now I think
2021-04-13 21:36:34 <dalias> a facility for keeping a local patch repository to fix shit like this
2021-04-13 21:36:54 <dalias> when the upstream is intentionally hostile
2021-04-13 21:37:40 <Cogitri> https://github.com/lu-zero/cargo-c/issues/180
2021-04-13 21:38:38 <Cogitri> They seem willed to make dynamic musl linking work once rustc has caught up though
2021-04-13 21:38:42 <Cogitri> > Once cargo is able to tell the difference between musl-with-dylibs and musl-without it will work out of box. :)
2021-04-13 21:40:41 <omni> s,box,crate,
2021-04-13 21:42:11 <ericonr> dalias: debian and fedora create a local crate repository
2021-04-13 21:42:38 <ericonr> but this requires packaging each crate dependency
2021-04-13 21:42:44 <ericonr> so lots of humantime
2021-04-13 21:43:08 <dalias> i posted there
2021-04-13 21:47:38 <ericonr> Ariadne: we are going to open one
2021-04-13 21:53:47 <Ariadne> i think we're going to have to actually write a spec about this
2021-04-13 21:53:48 <Ariadne> ;/
2021-04-13 21:57:25 <donoban> I don't know if this is related, but I had a undefined reference on telegram-desktop wich I solved using DBUILD_SHARED_LIBS=OFF on tg_owt lib
2021-04-13 22:09:48 <Hello71> rust build.rs system is totally broken anyways
2021-04-13 22:10:14 <Hello71> here's a whole crate of footguns, have your pick
2021-04-13 22:10:24 <Hello71> pun intended
2021-04-14 05:03:05 <hg> hmm
2021-04-14 05:03:09 <hg> fex isn't packaged for alpine
2021-04-14 05:03:12 <hg> I should do that
2021-04-14 05:03:17 <hg> and also actually try it out
2021-04-14 06:21:38 <ncopa> good morning
2021-04-14 06:22:10 <ncopa> ikke: re curl CVE, can we upgrade to latest version? I prefer upgrade over backport patches if possible
2021-04-14 06:55:28 <mps> aieee! agreed
2021-04-14 06:55:42 <mps> and same for clamav?
2021-04-14 07:06:14 <mps> !20468
2021-04-14 07:07:03 <mps> do we have to rewrite secfixes there or keep them as they are now
2021-04-14 07:29:35 <omni> secfixes should be written as in what version of our package a vulnerabilit was patched, right?
2021-04-14 07:32:41 <mps> secfixes data/notes are useless for anything except marketing
2021-04-14 07:35:04 <ncopa> i disagree. and i dont think we should underestimate the value of marketing
2021-04-14 07:35:10 <omni> well, a user might want to see if they really need to upgrade their package
2021-04-14 07:35:56 <ncopa> there are security scanners out there, that will flag our packages. the seclist comments help those scanners to avoid false positives
2021-04-14 07:36:50 <ikke> ncopa: have to look if there are soname bumps
2021-04-14 07:37:09 <ncopa> ikke: yeah, im checking it now
2021-04-14 07:37:26 <ncopa> I also saw that there is a bug in 7.76.0 so they did a 7.76.1
2021-04-14 07:37:28 <mps> old saying 'lies, damned lies and marketing' :)
2021-04-14 07:37:48 <mps> that is why I dislike marketing
2021-04-14 07:38:28 <ncopa> its a somewhat necessary "evil" imho
2021-04-14 07:39:26 <mps> I'm just user of alpine, and because that marketing of the alpine doesn't have any value
2021-04-14 07:39:55 <mps> to me, forgot to add at the end of previous sentence
2021-04-14 07:40:00 <omni> I think that saying is for statistics but, sure, marketing is often to fool someone into buyng something they didn't know they needed
2021-04-14 07:40:01 <ncopa> the alpine project has always been about actually fixing things rather than talking about how good we are
2021-04-14 07:40:14 <omni> but besides the point
2021-04-14 07:40:24 <mps> for me, quality is important
2021-04-14 07:40:32 <ncopa> "marketing" part has mostly been taken care of by others
2021-04-14 07:40:40 <ncopa> mps: agree
2021-04-14 07:41:44 <mps> and to add, I'm not against adding these sec info (and other 'marketing') data, but they are not priority for me
2021-04-14 07:41:50 <ncopa> imho, our job is to work on the high quality part. then others will discover, and others will do the marketing. "have you noticed that alpine docker images are very quick to fix the CVEs?"
2021-04-14 07:42:59 <mps> and I understand quite well that my POV is not only one, other people see it differently
2021-04-14 07:43:00 <ncopa> our priority has always been to actually fixing the issues over telling others about it
2021-04-14 07:43:19 <ncopa> reporting the issues has always been secondary
2021-04-14 07:43:30 <ncopa> reproting that things have been fixed that is
2021-04-14 07:43:38 <ncopa> actually fixing has always been priority
2021-04-14 07:44:30 <mps> yes, fixing something wrong is what I see as priority
2021-04-14 07:45:50 <ncopa> exactly
2021-04-14 07:47:02 <ncopa> telling people that it is fixed is secondary, but not worthless, imho
2021-04-14 07:47:47 <detha> if one wants Alpine to be accepted in corporate environments, one should never underestimate the stupidity of auditors
2021-04-14 07:48:30 <mps> detha: I don't want 'Alpine to be accepted in corporate environments'
2021-04-14 07:49:17 <mps> I don't care actually, but this shouldn't be 'main goal'
2021-04-14 07:49:37 <detha> mps: I would like to be able to use Alpine wherever it fits. And unfortunately, corporate environments are part of that
2021-04-14 07:49:42 <mps> if some corporation find it useful I'm not against, ofc
2021-04-14 07:50:43 <mps> so, we have make it acceptable by 'stupidity of auditors'? no thanks :)
2021-04-14 07:53:12 <detha> Consider it a way of reducing unnecessary work in sending 'yes it is a version <$x, but the patches for CVE-nnn have been backported' responses
2021-04-14 07:53:32 <omni> but for the original question, I'd say, don't "rewrite" 'secfixes:', add to it
2021-04-14 07:54:25 <omni> if a secfix is later patched in an upstream release it was still patched earlier by us
2021-04-14 07:54:57 <mps> omni: my doubt is about thing when the secfixes are already there, added by patching, and new release have it now
2021-04-14 07:55:13 <mps> omni: right
2021-04-14 08:03:02 <ncopa> do we have any developer docs for on-boarding new committers? I think we don't
2021-04-14 08:03:35 <ikke> Not aware of any
2021-04-14 08:03:44 <ncopa> for people who are not active on IRC, and get git push access
2021-04-14 08:04:14 <ikke> Should be part of the developed handbook
2021-04-14 08:04:29 <ikke> developers
2021-04-14 08:04:50 <ncopa> i think we should have some sort of mentorship for new committers, have a person that can give the special attention for a period of time
2021-04-14 08:16:49 <Ariadne> mps: with the new secfixes service coming online (hopefully friday), it will be more useful, because we will know what has and has not been patched
2021-04-14 08:18:39 <Ariadne> but yes, i am skeptical on the whole "patch tuesday" thing
2021-04-14 08:19:07 <Ariadne> on the other hand, the lack of a perceived, coherent security response in alpine is something people find detrimental
2021-04-14 08:19:16 <Ariadne> which is why i am trying to change this :)
2021-04-14 08:21:02 <mps> Ariadne: thanks ;)
2021-04-14 08:21:44 <Ariadne> (and the only thing maintainers need to do is just keep doing what they are doing anyway -- keeping secfixes up to date)
2021-04-14 08:23:06 <mps> but yes, 'central db' of secfixes is good to have
2021-04-14 08:23:22 <Ariadne> obviously, the system i am building won't do anything useful without annotating the secfixes in the APKBUILD
2021-04-14 08:24:39 <mps> nvm, you did a first step in right direction, I hope
2021-04-14 08:58:34 <mps> maxice8: !20474
2021-04-14 08:58:53 <mps> I upgraded it about hour ago
2021-04-14 08:58:58 <maxice8> oh
2021-04-14 08:59:01 <maxice8> forgot to rebase
2021-04-14 08:59:15 <mps> heh, happens to me also
2021-04-14 09:30:01 <mps> how to add extra -I/dir to cmake
2021-04-14 09:47:30 <ncopa> py3-pikepdf no longer builds in 3.13-stable
2021-04-14 09:47:34 <ncopa> no idea why
2021-04-14 09:47:50 <ncopa> g++: error: build/temp.linux-x86_64-3.8/src/qpdf/page.o: No such file or directory
2021-04-14 09:47:54 <ncopa> no idea how to fix it
2021-04-14 09:48:11 <ncopa> but it prevents us from fixing a cve
2021-04-14 10:14:14 <ncopa> im gonna tag stable releases now. are there anything important that should go in before the release?
2021-04-14 11:36:20 <Newbyte> Where should discussions about Alpine as an organisation be brought?
2021-04-14 11:42:17 <mps> I doubt that 'Alpine organization' exists
2021-04-14 11:43:26 <mps> alpine is more like 'wild life ecosystem'
2021-04-14 11:43:52 <mps> and that is good, imo
2021-04-14 13:07:06 <maxice8> Hey Ikke does the aports-qa-bot has admin permissions ?
2021-04-14 13:16:19 <tehcloud> reading the backlog here... Alpine is widely used in "corporate environments" at least in the form of the base image for most docker based deployments...
2021-04-14 13:16:29 <tehcloud> can confirm, I use it in a corporate environment
2021-04-14 13:18:15 <mps> E tu, son Brutus
2021-04-14 13:18:37 <mps> tehcloud: :)
2021-04-14 13:19:12 <tehcloud> focus on quality is what sells the distro
2021-04-14 13:21:05 <mps> what about correctness
2021-04-14 13:21:26 <Thermi> Please don't make a committee
2021-04-14 13:21:29 <tehcloud> well... that is part of the quality discussion, as is minimalism
2021-04-14 13:21:43 <Thermi> It worked thus far. Don't change a running system.
2021-04-14 13:21:49 <tehcloud> and yes, committees lead to bad decisions because you can't have real discussions anymore, instead you appease people's emotions
2021-04-14 13:22:04 <Thermi> Or we make a comittee of autists
2021-04-14 13:22:15 <tehcloud> <--- is autist
2021-04-14 13:22:19 <Thermi> <- is also an autist
2021-04-14 13:22:26 <Thermi> (a little bit only luckily)
2021-04-14 13:22:27 <tehcloud> lol.... yes, many of us probably are ;)
2021-04-14 13:22:58 <mps> 'autist' means?
2021-04-14 13:23:10 <tehcloud> anyway, I like this distro as it is now... focus on quality and minimalism
2021-04-14 13:23:11 <Thermi> Do you want my medical history?
2021-04-14 13:23:24 <Thermi> If you're in Switzerland, I could send you a copy.
2021-04-14 13:23:47 <tehcloud> build the quality product, and it shall be adopted, catering to corporate interests for the sake of catering to corporate interests does not lead anywhere positive
2021-04-14 13:24:33 <mps> tehcloud: keeping it minimal with my local branches 'eats' most of my time for alpine
2021-04-14 13:25:04 <mps> so I don't have much time to devote to alpine
2021-04-14 13:26:04 <MY-R> ===== release 3.13.5 ===== and already new kernel version :P
2021-04-14 13:50:11 <Ariadne> error: internal error: qemu unexpectedly closed the monitor: Failed to open module: Error relocating /usr/bin/../lib/qemu/ui-spice-core.so: egl_texture_blend: symbol not found
2021-04-14 13:50:17 <Ariadne> why
2021-04-14 13:51:50 <mps> did you installed all qemu modules
2021-04-14 13:52:00 <Ariadne> yes
2021-04-14 13:52:38 <mps> qemu-ui-opengl
2021-04-14 13:53:36 <mps> I have no idea, didn't had such error
2021-04-14 13:54:06 <mps> qemu-ui-egl-headless maybe
2021-04-14 13:55:31 <Ariadne> qemu-ui-opengl
2021-04-14 13:56:41 <Ariadne> thanks
2021-04-14 13:57:18 <mps> np
2021-04-14 13:59:22 <mps> MY-R: what is new kernel version?  5.10.30? :)
2021-04-14 14:00:15 <Ariadne> also why does power in the east bay have to fail again
2021-04-14 14:01:37 <mps> apk add west-bay ;)
2021-04-14 14:02:28 <mps> well, apk don't have 'move' subcmd
2021-04-14 14:08:36 <MY-R> mps: ye 5.10.30 :P and it got 3 CVE's in "nfc" :P
2021-04-14 14:09:38 <mps> nfc subsystem deserves lifetime CVE
2021-04-14 14:09:46 <MY-R> heh ye
2021-04-14 14:10:15 <ncopa> ugh... i shoudl have done the release yesterday
2021-04-14 14:10:50 <mps> no, new kernels are released about hour or two ago
2021-04-14 14:12:12 <mps> Date:   Wed Apr 14 08:42:14 2021 +0200
2021-04-14 14:12:41 <mps> what? +0200
2021-04-14 14:12:53 <mps> 2021
2021-04-14 14:13:02 <mps> hmm
2021-04-14 14:13:12 <mps> ah, 14
2021-04-14 14:13:29 <mps> :14
2021-04-14 14:13:42 <Ariadne> 14
2021-04-14 14:13:56 <mps> hmm, who can understand algitbot AI
2021-04-14 14:14:17 <ikke> pr 14
2021-04-14 14:14:34 <mps> Apr 14
2021-04-14 14:14:39 <mps> :D
2021-04-14 14:17:38 <Ariadne> ah
2021-04-14 14:17:48 <Ariadne> makes sense
2021-04-14 14:19:01 <Thermi> Hey guys libpwquality is broken
2021-04-14 14:19:10 <Thermi> It doesn't find a symbol that's defined in libintl
2021-04-14 14:19:23 <Thermi> From the start, it was broken. In 3.11 already
2021-04-14 14:19:27 <Thermi> In Edge too.
2021-04-14 14:19:44 <Thermi> How to check? ldd /usr/lib/libpwquality.so.1:
2021-04-14 14:19:53 <Thermi> Error relocating /usr/lib/libpwquality.so.1: libintl_dgettext: symbol not found
2021-04-14 14:20:01 <Ariadne> hmm
2021-04-14 14:20:35 <Ariadne> you didn't install gettext-tiny right
2021-04-14 14:20:42 <Ariadne> its in testing on edge
2021-04-14 14:21:01 <Ariadne> though that should coexist fine right now with libintl
2021-04-14 14:23:59 <Thermi> Why should I? It's not a dependency of anything
2021-04-14 14:24:12 <Thermi> And it wasn't in 3.11 either, it's not in the docker image
2021-04-14 14:24:42 <Ariadne> i was just pondering that as being a possible problem, but does not seem to be
2021-04-14 14:25:02 <Ariadne> anyway, gnu gettext is going away soon
2021-04-14 14:25:12 <Ariadne> 3.14 will be the last release with it
2021-04-14 14:25:25 <Ariadne> so this will fix itself
2021-04-14 14:27:36 <hg> Ariadne: is something replacing the GNU's gettext?
2021-04-14 14:27:56 <Ariadne> gettext-tiny from sabotage
2021-04-14 14:28:01 <hg> interdesting
2021-04-14 14:28:03 <hg> 
ACTION loks into it

2021-04-14 14:28:05 <Ariadne> musl itself already has gettext
2021-04-14 14:28:10 <Ariadne> we just need the tools
2021-04-14 14:29:26 <dalias> i think it's a configure problem from mixing gnu gettext and musl
2021-04-14 14:29:47 <Ariadne> yes, likely
2021-04-14 14:29:54 <dalias> configure probably detects that it doesn't need to link gnu libintl for gettext, but then uses the gnu header that alpine shipped in place of musl's
2021-04-14 14:29:58 <Ariadne> good thing that is being solved in 3.15 :D
2021-04-14 14:30:06 <dalias> (by doing a broken symbol-only configure check)
2021-04-14 14:30:12 <dalias> :)
2021-04-14 14:30:14 <dalias> yay
2021-04-14 14:42:54 <ncopa> can someone please help me review https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.10.9-3.11.11-3.12.7-released.md
2021-04-14 14:43:16 <ncopa> and https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/master/posts/Alpine-3.13.5-released.md
2021-04-14 14:54:22 <ncopa> fcolista: can you help me with the libosinf db? https://gitlab.com/libosinfo/osinfo-db/-/issues/78
2021-04-14 14:58:00 <nmeum> for some reason dl-cdn contains packages which have long been extinct in aports for instance https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/android-tools-zsh-completion-5.8-r1.apk the current version of the android-tools package is 31.0.0, why is that ancient subpackage is still around on the mirror? 🤔
2021-04-14 15:03:15 <ncopa> dl-cdn caches the packages. check the dl-master.alpinelinux.org/alpine
2021-04-14 15:06:12 <maxice8> automatic maintainer assignment: https://gitlab.alpinelinux.org/Cogitri/aports-qa-bot/-/merge_requests/7 this might interest some
2021-04-14 15:06:48 <ncopa> awesome
2021-04-14 15:07:29 <nmeum> nice!
2021-04-14 15:07:40 <nmeum> ncopa: it's also on the master for some reason http://dl-master.alpinelinux.org/alpine/edge/main/x86_64/android-tools-zsh-completion-5.8-r1.apk
2021-04-14 15:07:57 <donoban> hi, is there any problem if I modify two APKBUILDS on same merge request? One is a makedep of the another
2021-04-14 15:08:00 <nmeum> it's also on the mirrors idk
2021-04-14 15:08:13 <nmeum> that package needs to be removed somehow
2021-04-14 15:08:40 <nmeum> because I am pushing a new zsh-comletion subpackages but androidt-tools has moved to community/ in the meantime and it would be annoying to have two packages with the same name in different repos
2021-04-14 15:08:43 <ncopa> donoban: thats fine, specially if they are related. might still be nice to have two commits in the PR though
2021-04-14 15:08:53 <ncopa> nmeum: is it in the index?
2021-04-14 15:08:57 <donoban> yes inside the mr there are separated commits
2021-04-14 15:09:12 <ncopa> donoban: should be ok to have them in same PR
2021-04-14 15:09:19 <donoban> ok great
2021-04-14 15:09:36 <nmeum> ncopa: shows up with `apk info android-tools-zsh-completion`, so yeah I guess it's still in the APKINDEX for some reason
2021-04-14 15:09:51 <ncopa> apk search --origin --exact android-tools-zsh-completion
2021-04-14 15:10:02 <ncopa> says that it comes from zsh
2021-04-14 15:10:19 <nmeum> ahhh!!!!
2021-04-14 15:10:23 <nmeum> my bad then
2021-04-14 15:10:31 <ncopa> :)
2021-04-14 15:11:02 <ncopa> its confusing indeed
2021-04-14 15:13:47 <fcolista> yes ncopa !
2021-04-14 15:14:09 <ikke> maxice8: it should be backed by algitbot, which has admin permissions indeed
2021-04-14 15:14:44 <maxice8> ty, that is vital otherwise using the /Users API doesn't give us the Email address
2021-04-14 15:15:02 <maxice8> I have no clue how to do otherwise short of implemented a txt or something that we populate manually
2021-04-14 15:16:33 <ncopa> fcolista: can you please respond to https://gitlab.com/libosinfo/osinfo-db/-/issues/78 and say that you will follow up?
2021-04-14 15:21:40 <ikke> maxice8: assuming that they even use the same e-mail address
2021-04-14 15:22:35 <maxice8> It is the only reasonable thing I could find to connect, username used definitively does not as I found out painfully
2021-04-14 15:27:47 <fcolista> ncopa, done
2021-04-14 15:28:29 <donoban> I'm getting "sha512sum: WARNING: 1 of 1 computed checksums did NOT match" on build pipeline but in my computer checksum seems correct
2021-04-14 15:28:52 <ikke> donoban: cached filed?
2021-04-14 15:29:09 <donoban> uhM, let me check
2021-04-14 15:29:17 <donoban> "dabuild clean" cleans the cache?
2021-04-14 15:29:29 <ikke> No
2021-04-14 15:29:42 <ikke> abuild cleancache
2021-04-14 15:29:47 <ikke> (dabuild)
2021-04-14 15:30:21 <donoban> yep, new checksums :)
2021-04-14 15:30:28 <donoban> thanks ikke
2021-04-14 15:30:43 <ikke> np, the question is why the checksums changed in the first place
2021-04-14 15:31:03 <donoban> I switched to different versions
2021-04-14 15:31:21 <donoban> since are git commit versions
2021-04-14 15:31:35 <ikke> You should add the commit hash to the archive filename than
2021-04-14 15:31:35 <donoban> maybe I ended with an old cached version :\
2021-04-14 15:31:45 <donoban> ok
2021-04-14 15:32:18 <ikke> or rather
2021-04-14 15:32:23 <ikke> hmm
2021-04-14 15:32:41 <ikke> yeah, commit hash is best
2021-04-14 15:33:32 <nmeum> ideally $pkgver should change if you switch to a new commit
2021-04-14 15:33:59 <donoban> yes main source has already $pkgver reference, the problem is that it needs two external libs
2021-04-14 15:34:04 <nmeum> ah
2021-04-14 15:34:09 <donoban> and I set a fixed filename
2021-04-14 15:34:24 <donoban> now adding a $_lib_commit for each one
2021-04-14 19:06:00 <Thermi> Ariadne: I opened an issue regarding the libpwquality breakage: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12608
2021-04-14 19:08:33 <donoban> I get different sha512sum from the same URL: https://chromium.googlesource.com/libyuv/libyuv/+archive/ad890067f661dc747a975bc55ba3767fe30d4452.tar.gz
2021-04-14 19:08:51 <ikke> donoban: probably not deterministic :(
2021-04-14 19:09:08 <donoban> wow ikke,
2021-04-14 19:09:31 <donoban> maybe it differs due the source IP?
2021-04-14 19:10:04 <donoban> what should I do in this situation?
2021-04-14 19:10:20 <Cogitri> We could mirror it
2021-04-14 19:10:26 <Cogitri> Not much else we can do
2021-04-14 19:10:37 <ikke> yes, but that's not ideal
2021-04-14 19:11:04 <donoban> uhM, I'm gonna check if I can download it on another format
2021-04-14 19:12:21 <donoban> I'm gona try to diff the downloaded files...
2021-04-14 19:13:50 <ericonr> donoban: googlesource isn't deterministic
2021-04-14 19:13:56 <ericonr> they create a tarball on the spot
2021-04-14 19:14:06 <donoban> ah, thanks ericonr
2021-04-14 19:14:16 <ikke> Other sites as well, but semi deterministic
2021-04-14 19:14:28 <donoban> so probably is some kind of timestamp which differs
2021-04-14 19:14:31 <ikke> yes
2021-04-14 19:14:36 <ericonr> yup, I believe that's the case
2021-04-14 19:15:53 <ericonr> I think they reimplement git-archive in a very bad way
2021-04-14 19:16:08 <ikke> sr.ht used to have this problem as well, but they fixed it
2021-04-14 19:16:16 <donoban> even tags version are non-deterministic?
2021-04-14 19:16:25 <ericonr> sr.ht changed compression recently, though :(
2021-04-14 19:16:29 <ericonr> broke a bunch of checksums
2021-04-14 19:16:32 <ikke> right
2021-04-14 19:16:42 <ericonr> sourceforge changed the tar they used too :/
2021-04-14 19:16:46 <ikke> gitlab apparently also can be different between versions
2021-04-14 19:17:13 <ikke> git's official stance is that you should not rely on git archive output being deterministic
2021-04-14 19:20:05 <donoban> uhM there is a github mirror
2021-04-14 19:20:09 <donoban> https://github.com/webmproject/libvpx/releases
2021-04-14 19:20:18 <ikke> that should be more reliable
2021-04-14 19:20:51 <ikke> what does help is that at least for our builders, we mirror archive on distfiles
2021-04-14 19:21:34 <donoban> f88c588145b5164e98531b75215e119056cd806a9dbe6599bb9dab35c0af0ecd4b3daabee7d795e412a58aeb543d5c7dc0107457c4bd8f4d434e966e8e22a32d  first.tar
2021-04-14 19:21:36 <donoban> f88c588145b5164e98531b75215e119056cd806a9dbe6599bb9dab35c0af0ecd4b3daabee7d795e412a58aeb543d5c7dc0107457c4bd8f4d434e966e8e22a32d  second.tar
2021-04-14 19:21:38 <donoban> :D
2021-04-14 19:21:50 <donoban> I hope it builds fine with this version
2021-04-14 19:22:06 <ericonr> yeah github is reliable there, the only issue is that some upstreams don't sync often
2021-04-14 19:22:11 <donoban> is sha512 encouraged against sha256?
2021-04-14 19:22:18 <ericonr> I guess if it's setup as a mirror it sync automatically
2021-04-14 19:24:46 <ikke> donoban: abuild uses sha512sum by defautlt
2021-04-14 19:25:22 <donoban> ok
2021-04-14 19:26:33 <donoban> This seems an "unoffcial mirror" https://github.com/lemenkov/libyuv
2021-04-14 19:33:00 <donoban> lol, that guy even opened a issue for an official github mirror https://bugs.chromium.org/p/libyuv/issues/detail?id=851
2021-04-14 19:36:19 <mps> repeating question, how to add extra -I/dir to cmake
2021-04-14 19:36:40 <mps> extra include dir, I mean
2021-04-14 20:18:58 <PureTryOut[m]2> ikke: should we start to make an effort to move a lot of stuff from testing to community? We talked about this recently and testing is way too full with packages that have been in that repo for years
2021-04-14 20:19:18 <ikke> PureTryOut[m]2: it should be in cooporation of the maintainer
2021-04-14 20:19:27 <ikke> s/of/with
2021-04-14 20:19:27 <alpine-meetbot> ikke meant to say: PureTryOut[m]2: it should be in cooporation with the maintainer
2021-04-14 20:20:08 <PureTryOut[m]2> Sure, but lots of maintainers either aren't active anymore or just aren't interested in moving it, even though that's not the point of the testing repo
2021-04-14 20:20:38 <ikke> right, but that means we either have to find a maintainer, or move it to unmaintained
2021-04-14 20:21:04 <PureTryOut[m]2> Yeah ok so let's start tagging maintainers and ask them to move it then, and move to unmaintained if they aren't available anymore
2021-04-14 20:22:03 <ikke> I can start with my own :P
2021-04-14 20:22:13 <PureTryOut[m]2> That'd be a start haha
2021-04-14 20:22:18 <PureTryOut[m]2> Same here though
2021-04-14 20:33:41 <ikke> PureTryOut[m]2: And I know at least one maintainer that doesn't want to have the burden of maintaining versions for half a year in community
2021-04-14 20:34:08 <PureTryOut[m]2> Then they probably shouldn't maintain the package though?
2021-04-14 20:34:37 <ikke> They are / were maintaining the latest version in edge/testing
2021-04-14 20:35:08 <ikke> And yes, that's not what testing is for
2021-04-14 20:37:23 <Newbyte> what package is that?
2021-04-14 20:38:27 <ikke> not a single package, multiple packages
2021-04-14 21:13:10 <donoban> abuild supports zip files for source tarballs?
2021-04-14 21:14:06 <ikke> donoban: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L520
2021-04-14 21:15:08 <donoban> maybe it fails because some filename already exists
2021-04-14 21:15:54 <donoban> + unzip -x ../libvpx-19d71f6b351fe992ae34b114eebd872c383a6bdb.zip -d src/third_party/libvpx/source/libvpx/
2021-04-14 21:15:55 <donoban> unzip: can't open ../libvpx-19d71f6b351fe992ae34b114eebd872c383a6bdb.zip[.zip]
2021-04-14 21:16:32 <donoban> uhM, is not abuild command, it seems another line that I added to unpack on the right place
2021-04-14 21:17:59 <donoban> lol it's may fault, I mixed the .tar with the ,zip :D
2021-04-14 21:18:05 <ikke> heh
2021-04-14 21:33:43 <PureTryOut[m]2> How do you find out about reverse dependencies with apk? As in, how do I see what depends on some specific package?
2021-04-14 21:34:16 <[[sroracle]]> apk search -qrx package
2021-04-14 21:34:24 <[[sroracle]]> or any atom
2021-04-14 21:35:02 <[[sroracle]]> you can also use apk info -r for locally installed packages
2021-04-14 21:35:20 <[[sroracle]]> (search does both, info does only locally installed)
2021-04-14 21:38:16 <PureTryOut[m]2> Hmm ok thanks. That helps me, but doesn't solve my problem 😢
2021-04-14 21:38:54 <[[sroracle]]> what are you trying to do?
2021-04-14 21:40:24 <PureTryOut[m]2> We are trying to solve an issue where instead of pulseaudio it pulls in pipewire-pulse, but seemingly only on new installs (not upgrade). This seems to happen when one installs both gnome-session and gnome-settings-daemon, but not if you install one or the other
2021-04-14 21:41:11 <[[sroracle]]> is this on alpine installs?
2021-04-14 21:41:17 <[[sroracle]]> or pmOS
2021-04-14 21:41:18 <PureTryOut[m]2> Yes
2021-04-14 21:41:20 <PureTryOut[m]2> Alpine
2021-04-14 21:41:26 <PureTryOut[m]2> And because of that also happens on pmOS
2021-04-14 21:41:33 <[[sroracle]]> let me look at the index
2021-04-14 21:45:55 <PureTryOut[m]2> Ok even worse, `apk add pulseaudio-alsa pulseaudio` reproduces it
2021-04-14 22:00:14 <[[sroracle]]> hmph
2021-04-14 22:00:34 <[[sroracle]]> the mini rootfses should not use HTTPS repositories if they don't also include ca-certificates...
2021-04-14 22:01:13 <donoban> https://gitlab.alpinelinux.org/donoban/aports/-/pipelines/78896 armv7 fails due a bug they fixed 5days ago but I'm considering disabling it until next release
2021-04-14 22:13:55 <[[sroracle]]> disqualify_package: pulseaudio-alsa-14.2-r5 (conflicting provides)
2021-04-14 22:15:02 <[[sroracle]]> https://tpaste.us/vZxZ
2021-04-14 22:15:37 <donoban> is not !arm7 enough for disable armv7?
2021-04-14 22:16:09 <[[sroracle]]> !armv7 not !arm7
2021-04-14 22:16:20 <donoban> oh I read it on the wiki
2021-04-14 22:16:40 <donoban> "Package architecture(s) to build for. Can be one or several seperated by whitespace of: x86, x86_64, arm7, armhf, aarch64, ppc64le, s390x, mips64, all, or noarch"
2021-04-14 22:16:48 <[[sroracle]]> seems to be a typo to me
2021-04-14 22:16:56 <donoban> the other are right?
2021-04-14 22:17:03 <[[sroracle]]> yeah those look correct i think
2021-04-14 22:17:14 <donoban> ok
2021-04-14 22:27:54 <[[sroracle]]> PureTryOut[m]2: what was the rationale for !20031?
2021-04-14 22:28:32 <[[sroracle]]> i think apk does not like it when two provider names conflict AND versions are given, if i'm reading the source correctly
2021-04-14 22:29:13 <Cogitri> I think before that pipewire-pulse was overwriting pulse audio for everyone, not just be a drop-in replacement on request
2021-04-14 22:29:32 <[[sroracle]]> what a mess...
2021-04-14 22:31:53 <craftyguy> yeah pipewire-pulse had a provides=pulseaudio, which made pulseaudio a virtual package and it overrode the actual pulseaudio package. at least that's my understanding
2021-04-14 22:32:19 <craftyguy> PureTryOut[m]2: your patch won't reintroduce that problem again ^^ ?
2021-04-14 22:32:41 <craftyguy> oh wait, nevermind, that was the old fix XD
2021-04-14 22:33:20 <[[sroracle]]> the correct solution therefore must be something like the following
2021-04-14 22:34:45 <[[sroracle]]> the provider name should be something more generic, and pipewire-pulse and pulseaudio provide that name(s) instead. this would require rebuilding all rdeps that use those names as well.
2021-04-14 22:35:06 <[[sroracle]]> i'm not sure if alpine has done anything like that to fake "choice" packages but adelie has with /bin/sh.
2021-04-14 22:35:33 <[[sroracle]]> we have bash-binsh and dash-binsh both provide "/bin/sh" name (with NO version), and set provider priority correctly. then people can choose whichever
2021-04-14 22:36:32 <[[sroracle]]> and apk has no problems with this, other than when you switch between the two (a file conflict occurs, but i think that could be fixed with replaces= or something. but that seems obvious enough that we probably already tried that)
2021-04-14 22:36:33 <craftyguy> that makes sense. in the meantime could the pipewire-pulse subpackage be dropped until something like that is implemented?
2021-04-14 22:36:55 <[[sroracle]]> i leave that to yall to figure out :)
2021-04-14 22:39:09 <[[sroracle]]> in general though i don't think you can use provides= while also letting both packages exist at the same time (rather it's usually used in order to facilitate package renaming or replacement)
2021-04-14 22:39:20 <[[sroracle]]> with one of them using that name, that is
2021-04-14 22:39:35 <[[sroracle]]> so that would also apply to pulseaudio-bluez and whatever the other one was as well
2021-04-14 23:05:42 <Ariadne> [[sroracle]]: as long as the versioned provide isn't 100% equivalent, it is fine.  otherwise it needs to be disambiguated with provides_priority
2021-04-14 23:06:16 <Ariadne> [16:00:33] <[[sroracle]]> the mini rootfses should not use HTTPS repositories if they don't also include ca-certificates...
2021-04-14 23:06:18 <Ariadne> yes
2021-04-14 23:06:29 <Ariadne> we should include ca-certificates in alpine-base
2021-04-14 23:06:31 <Ariadne> imo
2021-04-14 23:48:04 <Hello71> https://lkml.org/lkml/2021/4/14/1023: Concerning architectures, we already support `x86_64`, `arm64` and `ppc64le`. Adding support for variants of those as well as `riscv`, `s390` and `mips` should be possible with some work.
2021-04-15 00:33:39 <minimal> Ariadne: I like the idea of gettext-tiny. One potential issue I forsee with gettext going away after Alpine 3.14, gettext package includes envsubst program which I've seen over the years recommended for & used in many Docker containers as a simple way to template config files, and obviously Alpine is used a lot as a base OS for container images........so unless its decided to package up envsubst as a separate package then I forsee
2021-04-15 00:33:39 <minimal> complaints as various people's containers break
2021-04-15 00:39:08 <Hello71> i don't think (it says) we're killing gettext, just not using it for building packages
2021-04-15 00:42:13 <dalias> i think you could install tools from gnu gettext, just not the library
2021-04-15 00:42:18 <dalias> the file format is mostly compatible
2021-04-15 00:42:44 <dalias> except that we don't do the (non-shareable, contrary to gettext design) SYSDEP strings hack that gnu gettext does
2021-04-15 00:43:09 <dalias> instead we have the po->mo compiler expand out all possible variants of the SYSDEP-parametrized strings
2021-04-15 00:48:24 <minimal> Hello71: Ariadne said earlier that gettext was going away after 3.14 so I took that to mean that it would no longer be packaged. I always thought it was strange that envsubst has been part of gettext in the first place.
2021-04-15 00:49:13 <Ariadne> minimal: can a replacement envsubst be written?
2021-04-15 00:49:31 <Ariadne> minimal: what does it do, etc
2021-04-15 00:50:49 <Hello71> https://github.com/stephenc/envsub seems to be an alternative... written in rust :p
2021-04-15 00:50:53 <minimal> minimal: dunno, have used it for a couple of years. Like it said its a "poor person's templating tool", you can write shell scripts that use it to replace references to shell variables in a template file, often used as a quick-and-nasty alternative to jinja etc in Docker images
2021-04-15 00:51:02 <Hello71> Ariadne: https://man.archlinux.org/man/envsubst.1
2021-04-15 00:51:28 <Hello71> it's like debian man pages but not three years out of date (although i guess that doesn't really matter here)
2021-04-15 00:51:38 <Ariadne> so
2021-04-15 00:51:41 <Ariadne> what it does is
2021-04-15 00:51:46 <Ariadne> you input
2021-04-15 00:51:48 <minimal> Hello71: yeah there's various alternatives - was just pointing out the likelyhood of existing Docker images failing in the future when rebuilt again Alpine 3.15 if envsubst is no longer present
2021-04-15 00:51:52 <Ariadne> say
2021-04-15 00:51:57 <Ariadne> Hello ${WORLD}
2021-04-15 00:52:03 <Ariadne> and it replaces ${WORLD} ?
2021-04-15 00:53:00 <minimal> say you create a quick-and-nasty Docker image for nginx, you could use envsubst to create a working nginx.conf from a template file
2021-04-15 00:53:29 <minimal> Ariadne: an example article from one of the Prometheus team: https://www.robustperception.io/environment-substitution-with-docker
2021-04-15 00:53:59 <Hello71> nginx seems like a bad use because it already uses the dollar sign for variables
2021-04-15 00:54:08 <Ariadne> minimal: so it does what i said?
2021-04-15 00:54:15 <Hello71> although i guess nginx variables are mostly lowercase
2021-04-15 00:54:21 <minimal> Hello71: that was an off-the-top-of-my-head example
2021-04-15 00:54:54 <minimal> I'm not saying its a good way to do things, just that its an not-uncommon way some people do things
2021-04-15 00:54:54 <Ariadne> ok
2021-04-15 00:55:00 <Ariadne> $VAR and ${VAR} only
2021-04-15 00:55:04 <Ariadne> i can write this in 5 minutes lmfao
2021-04-15 00:55:21 <Ariadne> i dont think this should be in gettext though
2021-04-15 00:55:23 <Ariadne> that's crazy
2021-04-15 00:55:37 <minimal> I was only pointing out a possible future scenario of floods of complaints if/when its gone
2021-04-15 00:55:55 <minimal> Ariadne: yeah I said earlier I never understood why its in gettext in the first place
2021-04-15 00:57:16 <minimal> no sure if its possible to batter the gettext configure stuff into submission to only build envsubst
2021-04-15 01:01:15 <minimal> Hello71: here's someone's nginx example using envsubst:  https://thepracticalsysadmin.com/templated-nginx-configuration-with-bash-and-docker/
2021-04-15 01:04:29 <Ariadne> envsubst
2021-04-15 01:04:33 <Ariadne> does not even support escaping
2021-04-15 01:04:36 <Ariadne> what the fuck
2021-04-15 01:04:37 <minimal> so I guess the question is whether there's something 100% compatible with envsubst that could be symlinked to /usr/bin/envsubst in the future for backwards compatibility
2021-04-15 01:05:04 <minimal> Ariadne: yeah, I did say it was for cheap-and-nasty templating lol
2021-04-15 01:05:29 <Ariadne> i almost have a replacement for this written lol
2021-04-15 01:06:28 <minimal> is this part of a future Ariadnebox (busybox, toybox competitor) ? ;-)
2021-04-15 01:15:23 <Ariadne> % envsubst \$HOME
2021-04-15 01:15:27 <Ariadne> this program is cursed
2021-04-15 06:53:37 <Cogitri> https://lkml.org/lkml/2021/4/14/1023
2021-04-15 07:09:51 <i1l-test> will it bring zfs in-kernel 🤡 ?
2021-04-15 07:51:22 <mps> I'm surprised how many decades I read every years announces about new computer technology which will solve all problems :)
2021-04-15 07:52:54 <mps> no, it will not, only will fill 'pockets' of greedy people
2021-04-15 08:57:22 <PureTryOut[m]2> craftyguy: in the meantime not the entire subpackage should be dropped, people depend on it already (willingly). Instead we could temporarily remove the provides instead
2021-04-15 08:59:49 <ncopa> morning
2021-04-15 09:00:03 <ncopa> envsubst might be useful as a busybox applet
2021-04-15 09:02:05 <Cogitri> Merged lots of things and closed some stale MRs, let's hope I didn't blow the builders up
2021-04-15 09:02:47 <ncopa> thanks!
2021-04-15 09:02:52 <Cogitri> Sure :)
2021-04-15 09:02:54 <Cogitri> ncopa: I'd appreciate if you could go through the MRs you've been assigned to and either merge them, leave a suggestion/assign someone else or close them
2021-04-15 09:04:40 <Cogitri> I mean no need to do that right now, but some MRs have been stale waiting for review for some months now 😅
2021-04-15 09:40:43 <donoban> hi, has something changed related to /var/run on edge? Tinyproxy fails on start because /var/run/tinyproxy is removed
2021-04-15 09:41:58 <Cogitri> Not really, but files/directories in /var/run are wiped each boot (it's just a tmpfs)
2021-04-15 09:42:10 <Cogitri> But that has been the case since basically forever?
2021-04-15 09:42:17 <donoban> uhM
2021-04-15 09:42:40 <donoban> until yesterday it was working fine, and here I have alpine 3.13 and also works fine
2021-04-15 09:43:25 <ncopa> the /var/run is normally a symlink to /run and /run is normally a tmpfs so it does not survive reboots. the script that starts tinyproxy should make sure the directory exists
2021-04-15 09:43:30 <mps> openrc upgrade?
2021-04-15 09:44:03 <donoban> so just add 'mkdir -p /var/run/tinyproxy/' ?
2021-04-15 09:44:34 <mps> or change it to use /run/tinyproxy
2021-04-15 09:44:39 <donoban> I tried that too
2021-04-15 09:44:42 <mps> if possible
2021-04-15 09:44:48 <donoban> and get a infite symbolic loop error
2021-04-15 09:44:54 <donoban> :S
2021-04-15 09:45:02 <donoban> let me try
2021-04-15 09:45:29 <donoban>  tinyproxy      [  crashed  ]
2021-04-15 09:45:36 <mps> is the /var/run/tinyproxy hardocoded in it
2021-04-15 09:45:39 <donoban> now it is fresh boot
2021-04-15 09:45:57 <mps> hardcoded*
2021-04-15 09:46:11 <donoban> uhM, on init.d conf no, on tinyproxy...
2021-04-15 09:46:28 <donoban> yes
2021-04-15 09:46:48 <donoban> PidFile "/var/run/tinyproxy/tinyproxy.pid"
2021-04-15 09:48:04 <donoban> note that this line was modified by me
2021-04-15 09:48:11 <donoban> on default setup it starts but openRC reports it as crashed
2021-04-15 09:50:39 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20078 , this working fine until this morning (on edge)
2021-04-15 09:51:22 <mps> yesterday openrc is upgraded, maybe some changes in it causes this
2021-04-15 09:51:42 <mps> what openrc version is installed
2021-04-15 09:51:54 <donoban> openrc (OpenRC) 0.43.2.57c1eaacac
2021-04-15 09:54:19 <mps> uh
2021-04-15 09:54:34 <mps> apk version openrc?
2021-04-15 09:54:52 <donoban> openrc-0.43.2-r0
2021-04-15 09:55:30 <mps> aha, there is change about removal of the slash, but forgot what
2021-04-15 09:56:30 <donoban> I'm trying to replace all conf from '/var/run/tinyproxy/tinyproxy.pid' to '/run/tinyproxy.pid'
2021-04-15 09:57:02 <donoban> uhM
2021-04-15 09:57:39 <donoban> there are some lines on start_pre() (init.d/tinyproyxy), enforcing the use of a tinyproxy directory
2021-04-15 09:57:48 <mps> https://github.com/OpenRC/openrc/commit/63db2d99e730547339d1bdd28e8437999c380cae
2021-04-15 09:58:41 <mps> but I doubt this change cause your problem
2021-04-15 10:02:08 <donoban> https://tpaste.us/DMpO this checks that tinyproxy.pid is not directly '/run/tinyproxy.pid'
2021-04-15 10:03:14 <donoban> what about adding there
2021-04-15 10:03:32 <donoban> some "mkdir -p $piddir" =
2021-04-15 10:03:33 <donoban> ?
2021-04-15 10:04:26 <donoban> I don't see nothing similar on other init scripts
2021-04-15 10:05:01 <donoban> and only tinyproxy is using that $piddir var
2021-04-15 10:05:33 <mps>  /etc/init.d/utmpd:      mkdir -p -m 0755 /run/utmps
2021-04-15 10:06:40 <donoban> or better just remove that useless folder?
2021-04-15 10:06:42 <donoban> :\
2021-04-15 10:06:43 <mps> you can use "mkdir -p /var/run/tinyproxy"
2021-04-15 10:08:26 <donoban> I don't understand why it wants to use a custom directory
2021-04-15 10:08:29 <mps> proper solution will be patch tinyproxy to use configurable path for pid file
2021-04-15 10:09:12 <donoban> uhM, maybe it can be set with a commandline option
2021-04-15 10:09:41 <donoban> uhM, it seems that it doesnt
2021-04-15 10:12:14 <donoban> I will opt for this two optios: adding a "mkdir -p .." to init.d script vs using only /run/tinyproxy.pid and remove the code that checks the existence of /var/run/tinyproxy dir (in the init.d too)
2021-04-15 10:12:15 <mps> config option, #PidFile "@localstatedir@/run/tinyproxy/tinyproxy.pid
2021-04-15 10:12:56 <donoban> uhm do you mean on /etc/tinyproxy/tinyproxy.conf ?
2021-04-15 10:13:29 <mps> don't know, I don't use tinyproxy, but it should be there iiuc
2021-04-15 10:14:09 <donoban> yes there is a conf file that APKBUILD is already editing
2021-04-15 10:14:47 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20078/diffs#97a1ecbfca7f2f05fc479c13b1b83a365a538c49_25_25
2021-04-15 10:14:57 <donoban> uhM, lol
2021-04-15 10:15:21 <mps> so, maybe 'PidFile /run/tinyproxy.pid'
2021-04-15 10:15:45 <donoban> problem is that before this morning it seems that openRC or some other thing was auto createing the /run/tinyproxy/ directory
2021-04-15 10:16:20 <donoban> if we want to use directly /run/tinyproxy.pid, there is some check on /etc/init.d/tinyproxy wich has to bee removed
2021-04-15 10:17:13 <donoban> https://tpaste.us/BE7W
2021-04-15 10:17:24 <donoban> see start_pre() func
2021-04-15 10:17:45 <mps> tinyproxy.pre-install is problem
2021-04-15 10:18:20 <mps> it creates user home dir /var/run/tinyproxy which is removed after reboot
2021-04-15 10:19:27 <donoban> so better remove that dir and the start_pre() check?
2021-04-15 10:20:27 <mps> no, fix /etc/tinyproxy/tinyproxy.conf with 'PidFile /run/tinyproxy.pid'
2021-04-15 10:21:18 <donoban> yes but if not removed the start_pre() on https://tpaste.us/BE7W
2021-04-15 10:21:26 <donoban> openRC will complain on rc-service start..
2021-04-15 10:21:49 <mps> hmm, yes
2021-04-15 10:22:10 <donoban> I saw that error before talking here
2021-04-15 10:22:42 <donoban> but I suppose that it is nothing important, just use /run/tinyproxy.pid and remove that check right?
2021-04-15 10:23:08 <mps> worth trying
2021-04-15 10:25:31 <mps> pidfile=$(get_config PidFile /run/${SVCNAME}.pid)
2021-04-15 10:25:44 <mps> in init.d file
2021-04-15 10:26:44 <donoban> ok ok, I will update the MR
2021-04-15 10:27:07 <mps> and 'PidFile "/run/tinyproxy.pid" in /etc/tinyproxy/tinyproxy.conf
2021-04-15 10:27:53 <mps> huh, what a mess of config
2021-04-15 10:28:11 <mps> no, this is one-shot solution
2021-04-15 10:30:30 <donoban> hehe
2021-04-15 10:31:18 <mps> so, 'PidFile "/run/tinyproxy/tinyproxy.pid" in /etc/tinyproxy/tinyproxy.conf
2021-04-15 10:33:25 <ncopa> Ariadne: some time ago python devs asked about help setting up a buildbot node for testing musl for the python test farm. IIRC you volunteered to make that happen? how is that going? if you are busy with other things maybe we should ask someone else set that up?
2021-04-15 10:39:27 <ikke> ncopa: do you think it makes sense to upgrade sudo as well on stable branches?
2021-04-15 10:39:33 <ikke> We now carry custom patches for CVEs
2021-04-15 10:41:21 <donoban> mps: ? so do you want maintain the '/run/tinyproxy/' dir?
2021-04-15 10:41:52 <mps> donoban: tinyproxy is not 'in good shape' and should be fixed, init script and pre-install
2021-04-15 10:42:23 <mps> donoban: no, I wrote about current state of init script
2021-04-15 10:42:36 <donoban> ah ok ok
2021-04-15 10:42:42 <mps> but this should be fixed (and whole package)
2021-04-15 10:43:17 <mps> if you use it please make it in better shape and post MR
2021-04-15 10:43:20 <ncopa> ikke: i absolutely think we should
2021-04-15 10:43:30 <ikke> ncopa: ok, will work on that
2021-04-15 10:43:32 <ncopa> backporting patches is risky
2021-04-15 10:43:34 <ikke> yes
2021-04-15 10:44:19 <mps> donoban: if you don't want to 'mess' with it, I will try to find some time (which is long time promise :) )
2021-04-15 10:44:26 <ncopa> i think i had a look at some sudo CVE thats unfixed for 3.10 a couple of weeks ago
2021-04-15 10:44:36 <ncopa> i think the sudo version we use there is unsupported
2021-04-15 10:44:47 <mps> ncopa: clamav also
2021-04-15 10:44:52 <donoban> mps: I can do it, I'm using tinyproxy everyday :)
2021-04-15 10:45:01 <ncopa> if we are note able to upgrade, we might find patches from debian
2021-04-15 10:45:04 <ikke> ncopa: yes, I backported a fix for 3.11, but 3.10 was not trivial
2021-04-15 10:45:10 <mps> donoban: good, do it!
2021-04-15 10:45:21 <ikke> ncopa: I did look at debian / ubuntu for those backports
2021-04-15 10:45:32 <donoban> ok :D
2021-04-15 10:45:37 <ikke> But I think upgrading is better
2021-04-15 10:47:24 <mps> ncopa: ikke: clandmeter: can we move clamav to community. afaik nothing depends on it in main
2021-04-15 10:47:47 <ikke> mps: Users might depend on it in main ;-)
2021-04-15 10:48:11 <mps> users of old (alpine stable) geeting a lot of these msgs 'WARNING: Your ClamAV installation is OUTDATED!'
2021-04-15 10:48:26 <mps> and 'WARNING: Local version: 0.102.4 Recommended version: 0.103.2'
2021-04-15 10:48:31 <ikke> right
2021-04-15 10:48:55 <ikke> So we either move it to community, or upgrade to the latest version in main
2021-04-15 10:49:12 <mps> options are, backport stable release to every alpine stable, or move to community
2021-04-15 10:49:20 <ikke> :)
2021-04-15 10:49:23 <mps> :)
2021-04-15 10:50:21 <mps> anyway, anyone who use such things shouldn't use outdated releases, be it clamav or alpine
2021-04-15 10:59:46 <ncopa> we should probably move clamav to community if upstream does not provide support for the time we need
2021-04-15 11:00:21 <ncopa> can we upgrade from 0.102.* -> 0.103.x or does that require config file changes?
2021-04-15 11:07:15 <mps> ncopa: I did this upgrade yesterday for 3.12-stable
2021-04-15 11:07:49 <mps> should work for 3.11-stable but I wanted to test it first
2021-04-15 11:08:33 <ncopa> good
2021-04-15 11:24:26 <mps> donoban: !20078  did you read COMMITSTYLE.md
2021-04-15 11:25:00 <donoban> ;( I didn't, but never its too late :D
2021-04-15 11:25:06 <mps> :)
2021-04-15 11:28:43 <nmeum> ikke: regarding the failing zsh tests: couly you tell me if the output of locale(1) differs in the build environment on the builders and the CI? (if that information is easy to obtain for you)
2021-04-15 11:30:13 <donoban> uhM mps , should handle the case when tinyproxy is already installed and there are both init.d&etc files?
2021-04-15 11:30:18 <nmeum> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10665 I think this would really be nice to have to ease debugging different build behaviour on the CI and the builders
2021-04-15 11:33:16 <mps> donoban: I don't agree. pkgs in repo should be 'clean', removing cruft is on the user/admin shoulders
2021-04-15 11:33:57 <mps> keep errors because pkg have errors is false stance
2021-04-15 11:33:58 <donoban> ok, anyway the actual version is already broken xd
2021-04-15 11:49:26 <mps> hmm, looking on clamav upgrade for 3.10-stable
2021-04-15 11:50:07 <mps> 3.10-stable expires in about half month, it is worth troubles to upgrade clamav on it
2021-04-15 12:15:44 <clandmeter> mps: I'm ok with moving to main
2021-04-15 12:16:57 <Cogitri> Interesting, mrustc has been upgraded to rust 1.39: https://github.com/thepowersgang/mrustc/
2021-04-15 12:17:52 <Cogitri> But that still means 13 steps to get a working, up-to-date rustc
2021-04-15 12:18:53 <PureTryOut[m]2> Which was how many steps before?
2021-04-15 12:20:09 <Cogitri> I think previously it supported 1.29
2021-04-15 12:20:17 <Cogitri> So 13 instead of 23 steps
2021-04-15 12:20:49 <PureTryOut[m]2> That's amazing!
2021-04-15 12:32:28 <mps> clandmeter: thanks.
2021-04-15 12:32:39 <mps> ikke: ncopa: ^ ?
2021-04-15 12:33:02 <mps> clandmeter: you mean moving to community ?
2021-04-15 12:52:11 <clandmeter> Uhm yes :)
2021-04-15 12:55:52 <ikke> nmeum: I can look in a couple of hours
2021-04-15 14:03:30 <mps> ncopa: we have https://github.com/RPi-Distro/bluez-firmware/ in linux-firmware. and there is https://github.com/RPi-Distro/bluez-firmware/blob/master/broadcom/BCM-LEGAL.txt file
2021-04-15 14:04:13 <mps> we need free software lawyer in 'our community'
2021-04-15 14:31:04 <PureTryOut[m]2> Hmm qt5-qtwebengine fails on checksums on the x86 builder which makes no sense as I updated those and the other arches seem to have succeeded
2021-04-15 14:33:03 <Cogitri> Let's give it another go for good measure
2021-04-15 14:33:15 <PureTryOut[m]2> It already did twice itself lol
2021-04-15 14:37:30 <Cogitri> Oh :D
2021-04-15 14:40:56 <ikke> Can check in a bit
2021-04-15 14:51:56 <Cogitri> Yeah, seems like it failed for a third time, good call PureTryOut[m]2 :D
2021-04-15 14:52:43 <PureTryOut[m]2> Also I have a lot of CI jobs failing because of timing out while downloading sources 😢
2021-04-15 14:52:48 <PureTryOut[m]2> I constantly have to retry them
2021-04-15 15:03:20 <PureTryOut[m]2> Also, how often does https://pkgs.alpinelinux.org get updated?
2021-04-15 15:03:39 <Cogitri> It gets updated once the builders upload their stuff
2021-04-15 15:03:52 <PureTryOut[m]2> Ah ok makes sense, thanks
2021-04-15 15:04:09 <PureTryOut[m]2> Darn it x86_64 builders, just hurry up with chromium will ya? 😛
2021-04-15 15:08:05 <ikke> pkgs.a.o has a 15m sync job
2021-04-15 15:08:20 <ikke> but it needs to be available on the mirrors before it sees the updates
2021-04-15 15:15:19 <skarnet> hey - could someone please merge !20516 when convenient? thanks!
2021-04-15 15:15:55 <ikke> nmeum: https://tpaste.us/yN58
2021-04-15 15:15:58 <ikke> that's on the builder
2021-04-15 15:16:35 <Cogitri> skarnet: I'll merge it once CI went over it
2021-04-15 15:16:48 <Cogitri> Are any of those upgrades worth backporting?
2021-04-15 15:16:49 <ikke> nmeum: in docker, none of those are set
2021-04-15 15:18:37 <skarnet> Cogitri: thanks! and no, no fires to extinguish, just a regular update (they fix an annoying build bug but Alpine is not impacted)
2021-04-15 15:25:35 <Cogitri> Okie 👍
2021-04-15 16:01:03 <ikke> PureTryOut[m]2: the archive of distfiles has a different checksum as the file on dev.a.o
2021-04-15 16:01:38 <PureTryOut[m]2> Yes I updated the file on dev.a.o, but I updated the checksum accordingly (and it seems to have worked on CI and all other arches)
2021-04-15 16:02:02 <ikke> yes, but the builders try to fetch the archive first from distfiles
2021-04-15 16:02:11 <ikke> and as the archive is available there, that's what they use
2021-04-15 16:02:23 <PureTryOut[m]2> Oh, ugh
2021-04-15 16:02:26 <ikke> was the old archive not deterministic?
2021-04-15 16:02:58 <PureTryOut[m]2> It was a copy of a git repo and I reverted a commit in that repo, which I then repackaged. I guess I had to take the new latest commit
2021-04-15 16:03:46 <PureTryOut[m]2> https://git.alpinelinux.org/aports/tree/community/qt5-qtwebengine/APKBUILD#n104
2021-04-15 16:04:59 <ikke> You probably should add $(git rev-parse HEAD) as $_commit in the snapshot funciton
2021-04-15 16:05:02 <ikke> function*
2021-04-15 16:05:15 <ikke> Then the archive will always have the proper commit hash
2021-04-15 16:06:54 <PureTryOut[m]2> Wait, how exactly?
2021-04-15 16:08:33 <ikke> PureTryOut[m]2: maybe it's easier to add that revert as a patch?
2021-04-15 16:08:47 <ikke> right now, you checkout a commit, but revert that, but get a different commit
2021-04-15 16:08:56 <ikke> well, revert something on top of that commit
2021-04-15 16:09:09 <PureTryOut[m]2> Yeah I guess as patch will be better...
2021-04-15 16:09:41 <ikke> so you get a different archive, but with the same hash as the old archive
2021-04-15 16:09:48 <ikke> in the filename
2021-04-15 16:11:39 <ikke> That's what causes this issue
2021-04-15 16:11:51 <PureTryOut[m]2> Yeah I get what causes it. I'll just apply that revert as patch
2021-04-15 16:57:21 <PureTryOut[m]2> Ok, wtf? I did just that, the archive should now be the same as before but it's still failing on checksums...
2021-04-15 16:59:49 <PureTryOut[m]2> Seems checksum of new archive isn't the same as before the wrong change... Wtf
2021-04-15 17:01:10 <PureTryOut[m]2> Ok I'll just name the new archive differently to force it to stop using the distfiles one
2021-04-15 17:01:27 <ikke> I can remove the distfiles archive
2021-04-15 17:02:07 <PureTryOut[m]2> Oh that would work too
2021-04-15 17:03:24 <ikke> done
2021-04-15 18:00:58 <nmeum> ikke: ah, thanks. that might explain the build failure
2021-04-15 18:06:33 <Ariadne> ncopa: i haven't been able to get to it yet, i assumed you wanted the infra team to do it anyway
2021-04-15 18:07:08 <ikke> Ariadne: what is the idea for it?
2021-04-15 18:09:57 <Ariadne> provide an alpine host to the python team for their buildbot
2021-04-15 18:09:59 <Ariadne> simple as that :p
2021-04-15 18:10:30 <ikke> ok
2021-04-15 18:21:04 <ikke> Ariadne: what dns record did you have in mind again for the cve tracker?
2021-04-15 18:21:17 <Ariadne> security.*
2021-04-15 18:21:24 <ikke> ok
2021-04-15 18:21:46 <Ariadne> unless you wanna use something else :p
2021-04-15 18:23:13 <ikke> no
2021-04-15 19:52:47 <omni>  
2021-04-15 19:53:05 <ikke>  
2021-04-15 20:21:19 <mps> qt5-qtwebengine on armv7 fail
2021-04-15 20:21:38 <ikke> yes, still
2021-04-15 20:21:59 <mps> ugh
2021-04-15 20:22:15 <ikke> It cannot find __NR_fstatat
2021-04-15 20:22:28 <mps> ah
2021-04-15 20:22:45 <ikke> Does that ring a bell?
2021-04-15 20:23:58 <mps> yes
2021-04-15 20:24:56 <mps> on armv7 '/usr/include/bits/syscall.h:#define __NR_fstatat64      327'
2021-04-15 20:25:24 <ikke> 64 bits variant
2021-04-15 20:27:04 <mps> grep -r _NR_fstatat /usr/include/ | tpaste => https://tpaste.us/K5J9
2021-04-15 20:27:35 <ikke> that explains I guess why __NR_fstat cannot be found
2021-04-15 20:28:34 <mps> not sure if some other header file contains it on arm32
2021-04-15 20:28:46 <mps> maybe something C++ specific
2021-04-15 20:29:37 <mps> uh, how big is this source tarball? ;)
2021-04-15 20:30:05 <ikke> 2G :P
2021-04-15 20:30:37 <mps> nonsense, and I thought chromium is monster :)
2021-04-15 20:30:44 <ikke> haha
2021-04-15 20:30:46 <PureTryOut[m]2> qt5-qtwebengine is Qt + chromium
2021-04-15 20:31:07 <mps> ah :D
2021-04-15 20:31:30 <mps> nonsense^2
2021-04-15 20:31:38 <PureTryOut[m]2> Exactly
2021-04-15 20:32:29 <mps> unpacked it is 4GB
2021-04-15 20:34:39 <mps> does it makes sense to build it on armv7, chromium can't be built on it afaik
2021-04-15 20:35:06 <ikke> lots of packages depend on it
2021-04-15 20:35:25 <PureTryOut[m]2> Yes that makes sense, and it has built there before
2021-04-15 20:35:27 <PureTryOut[m]2> At least on postmarketOS it's very useful to have it
2021-04-15 20:37:14 <mps> looks like __NR_fstatat is guarded in source by #ifdefs, but it still fails
2021-04-15 20:37:44 <mps> #ifndef , I mean
2021-04-15 20:38:46 <mps> 
ACTION hides from this issue

2021-04-15 20:46:38 <ikke> mps: where did you find that code, I cannot seem to find it?
2021-04-15 20:47:05 <mps> which one?
2021-04-15 20:47:20 <ikke> that's mentioned in the error
2021-04-15 20:48:08 <mps> abuild unpack, grep -r _NR_fstatat .
2021-04-15 20:49:32 <mps> btw, it fails om x86_64 also, didn't even looked why
2021-04-15 20:50:57 <PureTryOut[m]2> ugh, checksums again
2021-04-15 20:51:05 <PureTryOut[m]2> ikke: guess you didn't remove distfile for x86_64?
2021-04-15 20:51:30 <ikke> there is just one distfiles
2021-04-15 20:52:05 <PureTryOut[m]2> Oh, huh
2021-04-15 20:52:15 <PureTryOut[m]2> Then why did it fail now...
2021-04-15 20:54:49 <ikke> 9620b9cc8585c108fa1798f6bc98975d0054ce744ce551edea9405505172492a2b9391fda164d34217f099fe352adbcba906e203000ff98916beb653666fbd57  qtwebengine-e0b4b9436033e9bc376597ed90dd1fca9cdc90ff.tar.gz.a41f847d
2021-04-15 21:16:30 <donoban> Hi, I would like to push some changes on a MR but only for check armv7 builder, is there some way for disable the others without manual cancelling?
2021-04-15 21:16:54 <ikke> no
2021-04-15 21:17:06 <donoban> hehe ok
2021-04-15 21:18:08 <donoban> uhM well, I could set arch=armv7 on APKBUILD until I fix it
2021-04-15 21:18:15 <omni> yeah
2021-04-15 21:18:32 <ikke> don't forget to remove that again, though :)
2021-04-15 21:18:40 <donoban> hehe yes np
2021-04-15 21:20:19 <donoban> or could I setup an armv7 build env on my x86_64 pc?
2021-04-15 21:20:55 <ikke> you could use qemu
2021-04-15 21:21:04 <ikke> either system or user
2021-04-15 21:21:57 <donoban> ok I will check another day, I would like to fix the MR first
2021-04-15 21:41:32 <donoban> ey mps I see that "/var/run/tinyproxy/" is created as tinyproxy user home. If pidfile is moved to "/run/tinyproxy.pid", what should I do with the home dir? Use '/dev/null'?
2021-04-15 21:57:17 <omni> 
ACTION is on edge

2021-04-15 21:59:01 <omni> I went from 3.13.5 to edge and my /var/run/xen disappeared so I had to recreate it
2021-04-15 21:59:13 <donoban> uhM..
2021-04-15 21:59:27 <donoban> that seems very similar to my problem this morning with tinyproxy
2021-04-15 22:03:27 <donoban> omni: could you try to reboot?
2021-04-15 22:03:37 <donoban> In my case it fails again on each restart
2021-04-15 22:03:56 <omni> huh
2021-04-15 22:04:18 <omni> yeah, looking at openrc now
2021-04-15 22:04:39 <omni> since nothing relevant to this seem to have changed with xen
2021-04-15 22:05:14 <donoban> there was an openrc update yesterday
2021-04-15 22:05:34 <donoban> I think that it removes or stopped the creating of /var/run/XXXX dirs
2021-04-15 22:06:02 <donoban> I was tryint to move /var/run/tinyproxy/tinyrpoxy.pid to /var/run/tinyproxy.pid
2021-04-15 22:06:07 <donoban> but it the problem is more generic...
2021-04-15 22:07:34 <donoban> s/it/if/
2021-04-15 22:07:34 <alpine-meetbot> donoban meant to say: but if the problem is more generic...
2021-04-15 22:11:30 <omni> perhaps /run should be used instead... after all, /var/run is a symlink to it
2021-04-15 22:12:04 <omni> I'll try first to just reboot and see if I get the same issue, then fiddle with the rc script
2021-04-15 22:12:36 <donoban> since each reboot all the /run && /var/run is lost
2021-04-15 22:12:48 <donoban> I assume that before the update openrc was creating the directories
2021-04-15 22:22:46 <omni> this did it for me: doas sed -i "s,/var/run,/run," /etc/init.d/xendomains
2021-04-15 22:22:53 <omni> https://github.com/openrc/openrc/issues/201
2021-04-15 22:24:34 <donoban> oh great
2021-04-15 22:24:45 <donoban> so that's all the mistery :D
2021-04-15 22:42:03 <donoban> lol
2021-04-15 22:42:38 <donoban> building telegram on armvy, InSnap() is returning True :\, is not Snap it is InAlpine() :@
2021-04-15 22:43:40 <donoban> It just gets SNAP env var, what strange...
2021-04-15 23:47:52 <omni> hmm.. I seem to have lost the ability to scroll with two parallel fingers on the pad rodent after the upgrade
2021-04-15 23:48:52 <omni> oh, only in qutebrowser
2021-04-16 00:00:36 <dalias> lovely..
2021-04-16 00:00:48 <dalias> why is that even application specific? :/
2021-04-16 00:04:46 <omni> no idea
2021-04-16 00:06:26 <omni> I forgot to bump pkgrel in !20529 but perhaps it's the only thing that was blocking !20297 ?
2021-04-16 00:07:09 <omni> so it could be incorporated in that instead of building 4.14.1-r5
2021-04-16 00:14:08 <maxice8> the builders are having troubles with distfiles
2021-04-16 00:27:40 <omni> I'm happy to see that I am not FLoCed by our chromium-browser, even though this does not seem to be due to an active effort at our end
2021-04-16 00:34:14 <hg> omni: switch to links
2021-04-16 00:34:25 <hg> surely that won't be clealry identifying 😛
2021-04-16 00:39:24 <omni> there's the reasonably fast netsurf
2021-04-16 00:39:37 <omni> and kristall is pretty nice, it also has support for superior protocols
2021-04-16 00:40:03 <hg> I'd love to use netsurf but it crashes on sites I want to use
2021-04-16 00:40:12 <hg> not heard of kristall, I'll have to give that a try
2021-04-16 00:40:17 <hg> plus, I really do want vim-like browsing
2021-04-16 00:40:48 <omni> yeah, me too, unfortunately those two lack that
2021-04-16 00:40:53 <hg> ☹
2021-04-16 00:41:07 <hg> I also really like dillo hypothetically, but again, crashy and no vimlike
2021-04-16 00:41:16 <hg> clearly what I want isn't widely-wanted
2021-04-16 00:42:34 <omni> I think kristall won't even show the sites that crash for you in netsurf, it has pretty limited web-support (does it even show images?)
2021-04-16 00:42:41 <hg> hehe
2021-04-16 04:29:20 <ikke> maxice8: how so?
2021-04-16 06:36:43 <mps> donoban: omni: https://bugs.gentoo.org/782808
2021-04-16 06:36:55 <mps> will be upgraded soon
2021-04-16 06:39:41 <ikke> donoban: omni I do recall someone mentioning that the behavior of checkpath changed in regards to following symlinks
2021-04-16 06:40:06 <ikke> That probably causes this issue
2021-04-16 06:40:34 <mps> ikke: I did mentioned it yesterday
2021-04-16 06:41:05 <ikke> Right
2021-04-16 06:41:38 <mps> I created MR, will merge when pass CI
2021-04-16 06:42:10 <mps> (hope it is not risk to merge it before morning coffee :) )
2021-04-16 06:43:09 <mps> hmm, a lot of blockers on builders
2021-04-16 06:44:45 <ikke> So this is an actual bug
2021-04-16 06:48:30 <mps> 'The issue happens because /var/run is a symlink and the change between 0.43.1 and 0.43.2 broke this case, so I will work on this today'
2021-04-16 06:48:37 <ikke> Yup
2021-04-16 06:48:47 <mps> hope it is fixed now
2021-04-16 07:03:15 <Ariadne> ugh
2021-04-16 07:23:36 <ncopa> morning
2021-04-16 07:24:07 <ncopa> seems like edge builderes are stuck due to checksum errors for xen?
2021-04-16 07:24:27 <indy> hi all, can i somehow parametrize os release in apkbuild?
2021-04-16 07:25:22 <indy> i have from 3rd party archive with binary for 3.12 and 3.13
2021-04-16 07:26:13 <indy> is there way to have single apkbuild for two os releases?
2021-04-16 07:30:27 <ncopa> everything is possible. the impossible just takes longer time...
2021-04-16 07:31:32 <Ariadne> indy: the better way to do that is to have different repo for 3.12 and 3.13
2021-04-16 07:31:40 <ncopa> the way we do it in alpine is to have separate git branches, which means there are different copies of the same APKBUILD
2021-04-16 07:33:34 <PureTryOut[m]2> checksums of `main/xen` need regenerating, it's failing on the builders
2021-04-16 07:36:54 <ncopa> im on it
2021-04-16 07:40:38 <ncopa> so, the openrc update dropped to use the /var/run thingy?
2021-04-16 07:41:08 <PureTryOut[m]2> py3-pelican and bcc also need their checksums regenerated
2021-04-16 07:41:54 <ncopa> why?
2021-04-16 07:42:06 <PureTryOut[m]2> Because they are failing on the checksum check 😛
2021-04-16 07:42:14 <PureTryOut[m]2> on the builders
2021-04-16 07:42:42 <ncopa> so, when that happens, something is different than expected. are the checksum correct and the files wrong or the files checked in correct and checksum wrong?
2021-04-16 07:43:00 <PureTryOut[m]2> I do not know, just reporting what I see on the logs of the builders
2021-04-16 07:43:05 <ncopa> and how did it end up different than expected
2021-04-16 07:43:31 <ncopa> did someone modify the source to inject a backdoor?
2021-04-16 07:43:55 <PureTryOut[m]2> on 3 completely separate irrelevant packages? Could be but I doubt it
2021-04-16 07:43:58 <ncopa> my point is, its not just to update the checksums
2021-04-16 07:44:04 <PureTryOut[m]2> I get you
2021-04-16 07:44:10 <Thermi> Download the files
2021-04-16 07:44:12 <PureTryOut[m]2> As I said, just reporting what I saw on the builders
2021-04-16 07:44:14 <Thermi> extract them in a jail
2021-04-16 07:44:21 <Thermi> compare the dirs
2021-04-16 07:44:26 <Thermi> if they're the same, it's fine
2021-04-16 07:44:30 <ncopa> thats what i normally do
2021-04-16 07:44:36 <Thermi> Telling PureTryOut[m]2
2021-04-16 07:46:14 <ncopa> 👍
2021-04-16 07:46:51 <Thermi> You could do it easy and just make a local git repo and extract into it, commit, extract the second archive over it, check the difference
2021-04-16 07:47:02 <Thermi> OBVIOUSLY only do that if there's no .git dir in any of the archives.
2021-04-16 07:58:00 <ncopa> this is the problem 0f74849ab77c0e032e147b85c0f0e2600d41a833
2021-04-16 07:58:30 <ncopa> -source="$pkgname-$pkgver.tar.gz::https://github.com/iovisor/bcc/releases/download/v$pkgver/bcc-src-with-submodule.tar.gz"
2021-04-16 07:58:38 <ncopa> +source="$pkgname-$pkgver.tar.gz::https://github.com/iovisor/bcc/archive/v$pkgver.tar.gz
2021-04-16 07:59:00 <ncopa> different files are downloaded, same target filename
2021-04-16 07:59:22 <ncopa> so the stored cache fails
2021-04-16 08:01:00 <ncopa> problem is that our file cache is super simple and stupid and people dont expect that
2021-04-16 08:01:09 <ncopa> or dont know that we cache the sources
2021-04-16 08:05:49 <ncopa> i guess we really need a smarter cache
2021-04-16 08:05:51 <ncopa> :-/
2021-04-16 08:09:18 <ncopa> py3-pelican seems to have exactly the same issue
2021-04-16 08:09:20 <ncopa> 68da843018346f66c160a9bc11ad8248bca63612
2021-04-16 08:10:10 <PureTryOut[m]2> I wonder how that last one got through review, we actively prevent $pkgname from being used in the srcurl, so $_pkgname should be kept out as well
2021-04-16 08:10:13 <ncopa> changed the generated tarball fro mgithub to the stored tarball on pythonhosted, with different checksum, but exactly the same filename
2021-04-16 08:12:04 <ncopa> we should document it somehow, somewhere
2021-04-16 08:12:10 <ncopa> tbh, i dont really want a smarter cache
2021-04-16 08:12:18 <ikke> Me neither
2021-04-16 08:12:39 <ncopa> if you have a filename, then that filename should be unique
2021-04-16 08:12:39 <ikke> But we need a way to catch this earlier
2021-04-16 08:12:47 <jvoisin> sorry for breaking things :'(
2021-04-16 08:12:53 <ncopa> it happens
2021-04-16 08:13:02 <ncopa> it means that we need to document things better
2021-04-16 08:13:15 <nmeum> I still think we should store distfiles in /var/cache/distfiles/$pkgname/<whatever> to avoid these kinds of things entirely
2021-04-16 08:13:36 <ncopa> i dont think it would solve those two issues
2021-04-16 08:13:40 <ncopa> and it shouldnt either
2021-04-16 08:14:13 <ncopa> if you have two different files: foo-1.0.tar.gz and foo-1.0.tar.gz, how do you know which is which?
2021-04-16 08:14:19 <ikke> CI step to verify the hash on distfiles I guess?
2021-04-16 08:14:32 <nmeum> ah, I misread the issue then
2021-04-16 08:14:45 <ncopa> oh you mean the c89dd19072ba4127388f02a0e1fcdc51e163881ded53eb1fb8c342f02ed3b5242318e43999f46c9d976811a7cad0eef2c61d2172eb5c8e13b5ec883b6e8a8058 version of foo-1.0.tar.gz. sorry i though you meant the 0e1fae86ab914cce59c84db97c4661a454674f5e41682785aa82088e34cc9f4170b442f292fdc25c58d4c675269aa26b0652f63ca809596a175fc544d9b5fb61 version
2021-04-16 08:15:00 <PureTryOut[m]2> A CI step to verify the hash on distfiles as ikke suggested sounds good yes
2021-04-16 08:15:46 <ncopa> and if distfiles gives 404 it just moves on with success
2021-04-16 08:18:32 <mps> ncopa: I hope openrc bug is fixed in latest upgrade (merged it about hour ago), waiting for it on mirrors to check
2021-04-16 08:18:54 <ncopa> ok. i wasnt even aware that openrc had a bug :)
2021-04-16 08:19:44 <mps> well, also I wasn't sure even I posted changed commit url here yesterday
2021-04-16 08:20:27 <mps> it looked a little strange, but not as bug to me
2021-04-16 08:21:05 <mps> but looks like it is fixed in this morning release. lets see
2021-04-16 08:23:02 <ncopa> thank you for taking care of it
2021-04-16 08:24:55 <mps> just upgraded (mirrors, mirrors :) ) and tested with tinyproxy, looks like it is fixed. donoban: can you check
2021-04-16 08:25:16 <indy> Ariadne, ncopa i'll try another question, can i use some environment variable in APKBUILD?
2021-04-16 08:25:38 <mps> ncopa: I dislike too much 'thanks'
2021-04-16 08:26:07 <mps> though they are pleasant, I admit :)
2021-04-16 08:27:17 <mps> anyway, thanks for thanks
2021-04-16 08:27:55 <ncopa> you're welcome :)
2021-04-16 08:28:07 <indy> Ariadne, ncopa or is everything unset?
2021-04-16 08:28:41 <ncopa> indy: no, everything is not unset. there are env vars like GOFLAGS, CFLAGS, LDFLAGS, PATH etc that are set
2021-04-16 08:29:06 <ncopa> there are also things like CC and JOBS, which might be set
2021-04-16 08:29:46 <ncopa> i think I have used ${CC:-gcc} some places, so we can override the system compiler
2021-04-16 08:29:58 <ncopa> there are also vars like CHOST that are set
2021-04-16 08:30:33 <indy> as it is binary i can hence 'misuse' those variables?
2021-04-16 08:30:54 <ncopa> i dont understand, what you mean. sorry
2021-04-16 08:33:38 <indy> will write later now must go afk
2021-04-16 08:45:46 <donoban> ey mps , I could check but what piddfile should I have?
2021-04-16 08:48:31 <mps> donoban: default one
2021-04-16 08:49:41 <mps> apk del --purge tinyproxy, then remove /etc/tinyproxy/tinyproxy.conf and /etc/init.d/tinyproxy, and the apk add tinyproxy
2021-04-16 08:50:33 <donoban> ok
2021-04-16 09:15:53 <donoban> sorry mps I'm a little busy I will check it in a while :D
2021-04-16 09:17:58 <mps> donoban: np, no hurry. I already tested
2021-04-16 09:18:11 <donoban> ok
2021-04-16 09:37:56 <ncopa> re qt5-webengine on armv7. it seems that there are no __NR_fstatat on armv7, only __NR_fstatat64
2021-04-16 09:39:48 <ncopa> it also seems that we dont build chromium for armv7, only aarch64 and x86_64
2021-04-16 09:41:49 <PureTryOut[m]2> Yes but we did build qt5-qtwebengine for armv7 before. And quite a lot of packages depend on it
2021-04-16 09:43:23 <ncopa> looks like they had the issue in void linux previousy https://chocimier.github.io/voidlinux-archive/void-packages:issues:5495.html
2021-04-16 09:45:08 <ikke> They undefd fstat64
2021-04-16 09:50:52 <indy> ncopa, so i have two archives with binaries and 3.12 /3.13 in name, one git repo with APKBUILD. currently i have 3.12 hardcoded in source filename, i was thinking using same APKBUILD for 3.12 and 3.13 putting ${CC} instead of hardcoded 3.12
2021-04-16 09:52:03 <indy> and use "CC=3.12 abuild"
2021-04-16 09:53:47 <indy> and "CC=3.13 abuild"
2021-04-16 09:56:05 <ikke> CC is the compiler, you should not use it for other things
2021-04-16 09:56:31 <ikke> But you can certainly use variables for that
2021-04-16 09:56:41 <mps> "CC=tcc" would be interesting :)
2021-04-16 09:56:55 <ncopa> PureTryOut[m]2: so i guess we need to fix qtwebengine. Might be a good first step to report it upstream if it not already is
2021-04-16 09:57:57 <mps> this must be bug in chromium code
2021-04-16 10:00:50 <ncopa> likely
2021-04-16 10:01:57 <indy> ikke, ncopa it works :) https://dpaste.org/dmpY
2021-04-16 10:02:02 <PureTryOut[m]2> ncopa: upstream (Qt) has no interest in fixing this as they moved to Qt6
2021-04-16 10:02:12 <PureTryOut[m]2> As for Chromium, probably someone with more knowledge about the bug should report it
2021-04-16 10:04:44 <omni> sorry 'bout my sloppy xen mr earlier, missing to bump pkgrel and checksums
2021-04-16 10:06:13 <omni> was the armv7 gitlab CI builder the same hardware as the arm64 one but running in 32bit mode?
2021-04-16 10:11:30 <ncopa> in general, chromium requires significant amount resources so we only build ig for aarch64 and x86_64 currently
2021-04-16 10:11:56 <ncopa> i dont have time to dig into chromium, so someone else need to step up
2021-04-16 10:16:42 <donoban> mps: After purge and reinstall it works, after rebooting tinyproxy -> [  crashed  ] :(
2021-04-16 10:17:40 <donoban> also this error: "WARNING: logging deactivated (can't log to stdout when daemonized)" is fixed setting a log option (syslog/file) on tinyproxy.conf
2021-04-16 10:18:29 <donoban> now I'm like before https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20078 , openRC reports it as crashed but it is running
2021-04-16 10:27:33 <mps> donoban: thanks for report
2021-04-16 10:28:29 <donoban> wops my last push failed due missing checksum
2021-04-16 10:28:39 <donoban> do you want I fix and try again?
2021-04-16 10:29:05 <mps> sorry, I'm too busy now to look at anything on alpine
2021-04-16 10:29:11 <indy> ncopa, ikke thanks for help :)
2021-04-16 10:29:17 <donoban> ok ok, see you later
2021-04-16 11:34:14 <ncopa> chromium actually builds on armv7, but it fails to link
2021-04-16 11:40:51 <omni> files installed by community/rust packages are owned by 1000:1000 since when?
2021-04-16 11:54:35 <omni> (for me since I went from 3.13.5 to edge, but why?)
2021-04-16 15:09:58 <ikke> omni: hmm, are they?
2021-04-16 16:06:57 <mps> huh, every two or three days new kernel stable release. looks like -rc is more stable, it is released once in a week :)
2021-04-16 16:14:16 <donoban> hehe
2021-04-16 16:25:29 <mps> donoban: I looked at tinyproxy and tested it again. it works fine with upgraded openrc
2021-04-16 16:26:09 <donoban> ouch
2021-04-16 16:26:13 <mps> though warning is there but this should be fixed in conf file, I think
2021-04-16 16:26:26 <donoban> and rc-status shows it running?
2021-04-16 16:26:28 <donoban> after reboot
2021-04-16 16:26:45 <mps> in what runlevel you put it?
2021-04-16 16:27:22 <mps> 'WARNING: logging deactivated (can't log to stdout when daemonized)'
2021-04-16 16:28:31 <mps> there is no cmdline option for it to control log destination, so this must be fixed in conf file
2021-04-16 16:28:56 <donoban> on default
2021-04-16 16:29:08 <mps> alpine should make tailored tinyproxy.conf
2021-04-16 16:29:17 <donoban> I fixed it on APKBUILD
2021-04-16 16:29:25 <mps> good
2021-04-16 16:29:47 <donoban> it has to uncomment a log option, I did /var/log/tiniproxy/ instead syslog
2021-04-16 16:29:56 <donoban> specially because in the default config it floods a lot
2021-04-16 16:29:58 <mps> also pidfile should be set in conf file by alpine
2021-04-16 16:30:10 <donoban> yes
2021-04-16 16:30:23 <donoban> but the current APKBUILD doesn't take in account that that lines are commented in tinyproxy
2021-04-16 16:30:37 <mps> and .pre-install should be fixed to not create home dir for it
2021-04-16 16:31:10 <mps> donoban: 'sed' in package() could fix this
2021-04-16 16:31:36 <mps> I don't know does tinyproxy really needs home dir
2021-04-16 16:31:58 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20078/diffs#97a1ecbfca7f2f05fc479c13b1b83a365a538c49 I fixed one sed and add another
2021-04-16 16:32:05 <donoban> wopcs
2021-04-16 16:32:09 <donoban> I always confuse the bot :\
2021-04-16 16:32:44 <donoban> so better just unset the home folder? or set /dev/null?
2021-04-16 16:35:57 <mps> don't create home (-H)
2021-04-16 16:36:45 <mps> 'adduser -h' to see options
2021-04-16 16:37:12 <donoban> ah ok ok
2021-04-16 16:37:37 <donoban> I just checked /etc/fstab and see that almost users have some home dir
2021-04-16 16:37:45 <donoban> so I though that maybe was useful for something
2021-04-16 16:37:58 <donoban> lol
2021-04-16 16:38:09 <donoban> s/fstab/passwd/
2021-04-16 16:38:10 <alpine-meetbot> donoban meant to say: I just checked /etc/passwd and see that almost users have some home dir
2021-04-16 16:38:43 <donoban> take a look, almost all users have some home dir
2021-04-16 16:38:55 <donoban> and some have /dev/null
2021-04-16 16:39:28 <mps> home could be set to /dev/null I think, but maybe some thinks differently
2021-04-16 16:45:17 <donoban> ok
2021-04-16 17:19:39 <mps> PureTryOut[m]2: what about temporary disable qt5-qtwebengine on armv7 to deblock builder?
2021-04-16 19:24:26 <PureTryOut[m]2> mps: I guess temporarily it's fine yes. I just don't know how to fix it and a lot of packages depend on it 😢
2021-04-16 19:24:35 <PureTryOut[m]2> I'll make an issue for it at least
2021-04-16 19:28:17 <PureTryOut[m]2> disabled
2021-04-16 19:28:38 <ikke> PureTryOut[m]2: the void issue that ncopa linked to mentioned #undefing fstat64
2021-04-16 19:28:54 <PureTryOut[m]2> The source already does that though
2021-04-16 19:29:05 <mps> PureTryOut[m]2: thanks
2021-04-16 19:29:42 <mps> yes, it is complicated to find solution for such big code
2021-04-16 19:29:54 <PureTryOut[m]2> ikke: https://invent.kde.org/qt/qt/qtwebengine-chromium/-/blob/33.0.1750.170-based/chromium/third_party/lss/linux_syscall_support.h#L132
2021-04-16 19:30:12 <ikke> ok
2021-04-16 19:30:42 <PureTryOut[m]2> although maybe it needs to undef fstatat instead?
2021-04-16 19:31:37 <ikke> perhaps
2021-04-16 19:34:54 <omni> ikke: yes, and I've also chowned files root:root, reinstalled the package with 'apk fix' and had their files reverted to 1000:1000 ownership
2021-04-16 19:35:28 <ikke> omni: what package
2021-04-16 19:35:33 <omni> this is the rust package itself and any of its subpackages
2021-04-16 19:36:05 <omni> @edge
2021-04-16 19:36:48 <ikke> omni: I see, they seem to be owned by buildozer
2021-04-16 19:37:15 <ikke> https://tpaste.us/wPyK
2021-04-16 19:38:25 <omni> whose uid:gid is 1000:1000, so any system with it installed will have them owned by the first user
2021-04-16 19:39:06 <ikke> yes
2021-04-16 19:39:13 <omni> but I didn't really see what should've introduced this
2021-04-16 19:39:51 <omni> between 1.47.0-r2 and now
2021-04-16 19:40:46 <omni> well, there are these tar steps...
2021-04-16 19:41:24 <dalias> :-p
2021-04-16 19:41:38 <dalias> that should probably be fixed in general infrastructure
2021-04-16 19:41:47 <dalias> it should not be possible to package files owned by inappropriate uids
2021-04-16 19:42:21 <omni> right?
2021-04-16 19:43:01 <ikke> We first need to figure out what's causing this in the first place
2021-04-16 19:43:03 <omni> was it through this 04ecd3b0271b8a9e4bf6679499bc329859c00d42 ?
2021-04-16 22:20:59 <Ariadne> do not revert 04ecd3b0271b8a9e4bf6679499bc329859c00d42
2021-04-16 22:25:17 <Ariadne>       --no-same-owner        extract files as yourself (default for ordinary
2021-04-16 22:25:17 <Ariadne>                              users)
2021-04-16 22:25:19 <Ariadne> this is why
2021-04-16 22:25:21 <Ariadne> fakeroot
2021-04-16 22:31:01 <Ariadne> pushing fix
2021-04-16 22:32:21 <Ariadne> omni: http://dup.pw/alpine/aports/15cd4972fbd2
2021-04-16 23:12:08 <Hello71> funny thing is, i think linux-firmware has the same problem
2021-04-16 23:19:01 <omni> Ariadne: kewl!
2021-04-16 23:25:36 <omni> still think I agree with dalias though
2021-04-16 23:29:02 <Ariadne> yes,that will be fixed in apk3
2021-04-16 23:46:41 <omni> great stuff!
2021-04-16 23:51:40 <omni> seems like some packages have been rebuilt but kept their $pkgver-r$pkgrel, like pmbootstrap
2021-04-16 23:52:16 <omni> but I guess I should've remembered to add -a to 'pkg upgrade' anyway
2021-04-17 00:52:14 <minimal> Ariadne: pkgs.alpinelinux.org shows 2 gettext-tiny packages! One maintained by you in testing and another maintained by TBK in community.
2021-04-17 00:52:39 <Ariadne> minimal: mine supercedes the one maintained by TBK
2021-04-17 00:53:12 <Ariadne> minimal: it is all going to plan
2021-04-17 00:54:02 <minimal> so if someone does a "apk add gettext-tiny" in Edge which one gets installed?
2021-04-17 00:56:29 <minimal> Ariadne: ^^
2021-04-17 00:57:25 <Ariadne> who knows
2021-04-17 00:57:26 <Ariadne> who cares
2021-04-17 00:57:36 <Ariadne> (answer: mine)
2021-04-17 00:58:44 <minimal> Ariadne: is gettext-tiny ready to be used yet? I'm working on some MRs for a couple of packages and at least one of them currently uses gettext and was wondering whether to change to gettext-tiny
2021-04-17 01:59:32 <Ariadne> minimal: no
2021-04-17 02:00:00 <Ariadne> minimal: it depends, if the software does not depend on libintl it should be fine
2021-04-17 02:01:01 <minimal> ok, I'll hold off on that for now
2021-04-17 02:29:03 <dalias> minimal, nothing needs gettext-tiny as a runtime dep. it might need it as a build dep for the po->mo tools
2021-04-17 02:31:27 <minimal> dalias: I was thinking in terms of a package currently using gettext-dev as a makedepends and whether to change that to gettext-tiny-dev
2021-04-17 02:34:09 <Ariadne> gettext-tiny-dev just provides a libintl.a stub for really special programs
2021-04-17 02:34:30 <Ariadne> usually you don't want it
2021-04-17 02:34:52 <Ariadne> unless you have a really special (and i don't mean that in a nice way) program which looks for weird GNU libintl symbols
2021-04-17 02:40:58 <minimal> Ariadne: it was procps I was looking at that uses libintl
2021-04-17 04:05:03 <tomleb> I am working on adding my first package to alpine (in testing). It's a prometheus exporter. I see some prometheus exporter have a prefix of `prometheus-`, is this required ?
2021-04-17 05:38:39 <Ariadne> tomleb: it should ideally match the name of the upstream project
2021-04-17 11:16:18 <jvoisin> from https://releases.llvm.org/12.0.0/docs/ReleaseNotes.html → Many Sanitizers (asan, cfi, lsan, msan, tsan, ubsan) have support for musl-based Linux distributions.
2021-04-17 12:02:24 <donoban> Hi, I would like to diable a build option only for armv7
2021-04-17 12:02:37 <ikke> what kind of build option?"
2021-04-17 12:02:54 <donoban> disable dbus integration
2021-04-17 12:03:05 <donoban> it fails on armv7
2021-04-17 12:03:09 <donoban> but works fine on others
2021-04-17 12:04:41 <ikke> case $CARCH in; armv7) ;; *) add_build_option;; esac
2021-04-17 12:04:47 <ikke> something like that
2021-04-17 12:05:05 <ikke> if it fails on armv7, I guess it fails on armhf as well
2021-04-17 12:05:23 <donoban> arhmf is disable already due missing dependency
2021-04-17 12:05:29 <ikke> ok
2021-04-17 12:05:38 <ikke> any idea why it's just failing on armv7?
2021-04-17 12:06:05 <donoban> uhM, I don't remeber exactly had other problems later let me check
2021-04-17 12:07:43 <donoban> main problem is that upstream doesn't support officially arm
2021-04-17 12:08:17 <donoban> https://gitlab.alpinelinux.org/donoban/aports/-/jobs/372405#L4653
2021-04-17 12:08:53 <donoban> some undefined vars or methods on glibmm, also tried with different version
2021-04-17 12:09:13 <donoban> finally discovered that it could be avoided disabling dubs integraton
2021-04-17 12:09:18 <ikke> ok
2021-04-17 12:09:25 <ikke> means no notifications, I guess
2021-04-17 12:09:49 <donoban> well at least in the desktop integrated method
2021-04-17 12:09:59 <donoban> maybe it uses some alternative like send-notify
2021-04-17 12:10:23 <donoban> I can't test armv7, maybe I should buy some device
2021-04-17 12:10:29 <donoban> raspberry pi?
2021-04-17 12:10:38 <ikke> rpi3 I guess
2021-04-17 12:10:50 <ikke> rpi4 is aarch64
2021-04-17 12:11:11 <donoban> ok
2021-04-17 12:17:34 <artok> any rpi 2 and up should do with armv7
2021-04-17 12:18:04 <ikke> does rpi4 aarch64 support 32-bits mode?
2021-04-17 12:18:31 <mps> ikke: why you give bad advises around :P
2021-04-17 12:19:11 <mps> donoban: don't buy anything with broadcom
2021-04-17 12:27:08 <artok> ikke: yeah it does
2021-04-17 12:28:50 <artok> ikke: they tend to run armhf "official" raspberry pi os on all boards
2021-04-17 12:50:32 <donoban> mps: anything with broadcom?
2021-04-17 12:51:43 <donoban> it seems that my laptop is broadcom free :D
2021-04-17 12:54:08 <mps> donoban: exynos, rockchip, allwinner based boards are usually more open and linux friendly
2021-04-17 12:54:16 <mps> not perfect ofc
2021-04-17 12:54:48 <donoban> ok good to know
2021-04-17 12:55:54 <mps> I forgot to mention ammlogic also (and there is more but writting from head)
2021-04-17 12:58:10 <mps> donoban: iirc you asked about qemu armv7 guest on x86_64?
2021-04-17 13:19:14 <tomleb> Ariadne: Ok, thanks
2021-04-17 13:25:24 <donoban> mps: I asked some days ago yes
2021-04-17 14:32:27 <tomleb> Is it okay for a APKBUILD to have something like _commit="$pkgver" to make it easier to test other git commits? For example, let's say I have a git tag of 0.0.1, then I wouldn't need something like _commit="..", but it does make it easier later to test non tagged releases.
2021-04-17 14:36:18 <tomleb> I couldn't find any package using this so I'll assume that it's better to not use that. I'll just use $pkgver.
2021-04-17 14:37:56 <Cogitri> tomleb: I don't see what would be different with having _commit variable that you change instead of changing pkgver?
2021-04-17 16:00:49 <donoban> this tmpfs mount is failing on firejail: mount("tmpfs", proc, "tmpfs", flags|MS_NOSUID|MS_NODEV, options) , it just says "Invalid argument"
2021-04-17 16:01:49 <donoban> proc seems something like '/proc/self/fd/...'
2021-04-17 16:24:29 <donoban> >>> firejail: Package is up to date , could I force dabuild to build again without removing it or modifying the APKBUILD version?
2021-04-17 16:24:54 <Cogitri> It just checks for the last modified date
2021-04-17 16:25:12 <Cogitri> you could open your text editor, save the file immediately without doing changes and build again
2021-04-17 16:25:16 <donoban> uhM, the last modified that of ..?
2021-04-17 16:25:18 <donoban> APKBUILD?
2021-04-17 16:25:24 <Cogitri> Yes
2021-04-17 16:25:26 <donoban> ok
2021-04-17 16:26:05 <donoban> it doesnt work :\
2021-04-17 16:27:19 <Cogitri> Should work if your editor allows saving unchanged files
2021-04-17 16:27:24 <Cogitri> e.g. nano does it just fine
2021-04-17 16:27:35 <ikke> donoban: -f
2021-04-17 16:28:04 <Cogitri> Oh, or that works too :D
2021-04-17 16:28:20 <donoban> I read the help and -f says force to run as root
2021-04-17 16:28:32 <donoban> ahh
2021-04-17 16:28:34 <donoban> it was -F
2021-04-17 16:28:39 <donoban> ehh
2021-04-17 16:28:40 <donoban> :)
2021-04-17 16:31:44 <donoban> ouch, it ended overwriting my changes -_-
2021-04-17 16:33:34 <donoban> I should used build arg
2021-04-17 16:39:55 <donoban> if I run: "dabuild -kKr build" it fails due "configure: error: "*** gawk not found ***"", if remove the 'build', it builds fine but downloads again the sources
2021-04-17 16:40:52 <ikke> donoban: deps build
2021-04-17 16:41:06 <donoban> ahmM, thanks
2021-04-17 16:48:17 <tomleb> Cogitri: Humm, iirc pkgver can't be a git commit, I'll have to try again though just to be sure
2021-04-17 16:48:42 <ikke> it cannot
2021-04-17 17:00:42 <donoban> maybe what I'm trying to do is just not possible, I want to modify some lines in the source, run dabuild, run apk upgrade, test the changes. It seems that runninng 'dabuild -kKrf deps build' doesn't create a new package
2021-04-17 17:01:03 <donoban> I mean doing this without incrementing pkgrel
2021-04-17 17:01:32 <ikke> to create the actual package, you need more:
2021-04-17 17:02:26 <donoban> if incrementing the pkgrel is easier path... I will do it :)
2021-04-17 17:02:33 <ikke> the whole sequence is: deps unpack prepare build rootpkg index
2021-04-17 17:02:44 <ikke> oh, also check
2021-04-17 17:02:51 <donoban> uhM ok
2021-04-17 17:03:29 <donoban> I guess that apk upgrade won't work if the version/release is the same right?
2021-04-17 17:03:34 <donoban> I should remove and add again?
2021-04-17 17:03:53 <ikke> apk upgrade -a
2021-04-17 17:10:17 <mps> donoban: I have some scripts to install armv7 in qemu on x86_64
2021-04-17 17:10:35 <donoban> oh great
2021-04-17 17:11:04 <mps> have to check did they still works, but I think they will
2021-04-17 17:11:25 <donoban> Warning: MOunting: /proc/self/fd/5 flags: 32 ops: mode=2755,uid=1000,gid=1000W
2021-04-17 17:11:38 <donoban> this is the mount that fails
2021-04-17 17:12:21 <donoban> is direct qemu based or libvirt?
2021-04-17 17:12:35 <mps> qemu only
2021-04-17 17:12:39 <donoban> hehe I supposed
2021-04-17 17:12:52 <donoban> I'm thinking removing libivrt
2021-04-17 17:12:59 <mps> why? sorry for curiosa ;)
2021-04-17 17:13:04 <mps> ah
2021-04-17 17:13:15 <donoban> well, mostly because I don't like it modifies firewall rules
2021-04-17 17:13:23 <donoban> just because I have also docker and my own rules
2021-04-17 17:13:37 <donoban> so it's likely to fail something
2021-04-17 17:13:37 <mps> I tried libvirt long ago on debian and concluded that is not useful
2021-04-17 17:14:42 <donoban> well it is useful specially if you don't all the different qemu options, devices, etc...
2021-04-17 17:14:56 <mps> yes, all these helper are more hassle than useful
2021-04-17 17:15:03 <donoban> if you don't know*
2021-04-17 17:15:23 <mps> if 'you' don't know then don't 'do'
2021-04-17 17:15:55 <mps> or by windows :P
2021-04-17 17:15:55 <donoban> hehe, that will limite computers for very few people....
2021-04-17 17:16:48 <mps> there are a lot of free jobs around for people who don't like to learn ;)
2021-04-17 17:16:52 <donoban> maybe if I want to use more VM's could be interesting, but I only need 1 at this moment, directly connected to host, so libvirt is not very helpful
2021-04-17 17:17:27 <donoban> directly I mean without even NAT ^^
2021-04-17 17:18:10 <mps> yes, I run qemu in default net mode or with tuntap bridged to host
2021-04-17 17:18:40 <mps> these are simple and stable, and fully under 'my' control
2021-04-17 17:18:53 <donoban> I would like to fix this firejail error :\
2021-04-17 17:19:34 <donoban> maybe should ask in #linux
2021-04-17 17:19:53 <mps> let me prepare tea and after that I will check my qemu armv7 script
2021-04-17 17:20:02 <donoban> ok thanks
2021-04-17 17:20:58 <mps> ideas about this is from clandmeter
2021-04-17 17:21:26 <mps> and I had a hope that the ncopa will make armv7 install iso image
2021-04-17 17:22:33 <donoban> uhM, there isn't?
2021-04-17 17:23:44 <mps> no, not yet
2021-04-17 17:23:52 <donoban> lol, (talking about libvirt)
2021-04-17 17:23:53 <donoban> localhost:~$ sudo iptables -L LIBVIRT_OUT -n | wc
2021-04-17 17:23:55 <donoban>        90       625      6519
2021-04-17 17:24:15 <donoban> it seems it's duplicating its rules eac reboot
2021-04-17 17:24:45 <donoban> at least it forced iptables to run after it
2021-04-17 17:24:52 <donoban> I*
2021-04-17 17:25:18 <mps> NAT is/was bad idea from the start
2021-04-17 17:25:37 <donoban> uhM.. It's hard to say
2021-04-17 17:26:12 <donoban> but it is not NAT, it's something related with domains names
2021-04-17 17:26:53 <donoban> but it ignores that there already rules because I use iptables-save...
2021-04-17 17:27:11 <donoban> I will try to run it in user mode before removing :D
2021-04-17 17:58:10 <mps> donoban: https://tpaste.us/8jYk
2021-04-17 17:58:20 <donoban> 👍
2021-04-17 17:58:38 <mps> you will have to tweak it for your use case
2021-04-17 17:59:17 <mps> and this is not alpine officiall, I made these things for testing booting armv7 in efi mode
2021-04-17 17:59:37 <mps> as you can see there debian efi for armv7 is used
2021-04-17 17:59:40 <donoban> well, I would like to have build some package and test it
2021-04-17 18:00:22 <donoban> I discovered something with my firejail problem :\
2021-04-17 18:01:04 <donoban> if I use --private=~/someDIr , it works the first time, but the second I get the same error
2021-04-17 18:02:04 <donoban> the most rare is that my debug info don't appear in the working case :\ it seems a different path
2021-04-17 18:02:42 <donoban> bah, I'm gonna postpone this until I upgrade to edge
2021-04-17 18:04:27 <donoban> looks a simple script
2021-04-17 18:05:32 <donoban> why does it need qemu-efi-arm_2021 from debian?
2021-04-17 18:13:07 <maxice8> armhf and armv7 failed over distfiles again
2021-04-17 18:13:11 <maxice8> for boost1.76
2021-04-17 18:13:25 <ikke> maxice8: curl: (22) The requested URL returned error: 404
2021-04-17 18:13:32 <ikke> distfiles does not even have it
2021-04-17 18:13:36 <ikke> this is the shared local distfiles issue
2021-04-17 18:13:52 <maxice8> ok
2021-04-17 18:16:30 <mps> donoban: we don't have it in alpine
2021-04-17 18:18:31 <donoban> I see
2021-04-17 18:36:41 <donoban> one doubt guys, this error: "/usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/libtg_owt.so.0.0.0: undefined reference to `webrtc::ScreenDrawerLock::Create()'", means that libtg_owt.so is wrong, or since it was build with -DBUILD_SHARED_LIBS=ON , maybe the current env is missing some lib which contains that reference?
2021-04-17 18:37:21 <donoban> building it with -DBUILD_SHARED_LIBS=OFF works...
2021-04-17 18:42:32 <caskd> building tg_owt with shared libs or tdesktop?
2021-04-17 18:44:13 <donoban> uhM, both
2021-04-17 18:44:27 <caskd> what the hell
2021-04-17 18:44:27 <donoban> tg_owt off, tdesktop on, works
2021-04-17 18:44:37 <donoban> ah sorry
2021-04-17 18:44:51 <caskd> i have no clue why building shared libs would even change the available symbols
2021-04-17 18:45:24 <caskd> thanks for going through the hell me a Newbyte didn't want to go through :))
2021-04-17 18:45:31 <caskd> the latest versions are a mess
2021-04-17 18:45:47 <donoban> well, I was happy becoming a mantainer of a package
2021-04-17 18:45:54 <donoban> if knew all this stuff before
2021-04-17 18:46:00 <donoban> I probably will selected another :D
2021-04-17 18:46:07 <caskd> understandable
2021-04-17 18:46:23 <caskd> i would've bumped it myself but yeah... you see why i kinda gave up
2021-04-17 18:46:43 <donoban> well one option is to use -DBUILD_SHARED_LIBS=OFF for this release
2021-04-17 18:46:50 <donoban> and on the next one try to fix again
2021-04-17 18:47:04 <donoban> if Cogitri is agree :)
2021-04-17 18:47:19 <caskd> yeah, hopefully the main devs will fix the build system mess they have
2021-04-17 18:47:46 <donoban> also there is another problem, libvpxv is already packaged but tdkestop telegram uses the source directly
2021-04-17 18:47:50 <caskd> digging through the endless cmakefiles and bolierplate code is a pain
2021-04-17 18:48:07 <caskd> donoban: yeah, you have to modify some things and header includes
2021-04-17 18:48:11 <donoban> I would like to use alpine pacakge but it will require modify some cmake and I'm very noob with it
2021-04-17 18:48:25 <caskd> donoban: cmake is easy if you keep it clean
2021-04-17 18:48:29 <caskd> problem is, they don't
2021-04-17 18:52:57 <donoban> I think this is the only difference:
2021-04-17 18:52:58 <donoban> if (BUILD_SHARED_LIBS)
2021-04-17 18:53:00 <donoban>     set(CMAKE_POSITION_INDEPENDENT_CODE ON)
2021-04-17 18:53:02 <donoban> endif()
2021-04-17 18:53:15 <caskd> that shouldn't change anything though
2021-04-17 18:53:43 <caskd> (related to this problem)
2021-04-17 18:55:49 <donoban> well I'm gonna push with static link and rethink tomorrow
2021-04-17 18:56:53 <caskd> does it build fine if you do it that way?
2021-04-17 18:57:02 <donoban> yes
2021-04-17 18:57:13 <donoban> it worked some days ago but armv7 failed
2021-04-17 18:57:26 <donoban> now armv7 works too disabling dbus integration and small patches
2021-04-17 19:06:57 <maxice8> automaintainer has been merged into aports-qa-bot
2021-04-17 19:18:43 <Cogitri> So once we update the bot, it can automatically assign the`Maintainer` of an APKBUILD to a MR
2021-04-17 19:19:05 <donoban> lol
2021-04-17 19:19:18 <donoban> I though that it was going to auto update packages :D
2021-04-17 19:19:49 <Cogitri> Ah no, it doesn't have the brains for that :D
2021-04-17 19:20:00 <donoban> s/though/tought
2021-04-17 19:20:00 <alpine-meetbot> donoban meant to say: I tought that it was going to auto update packages :D
2021-04-17 19:20:19 <donoban> hehe
2021-04-17 19:20:35 <donoban> Cogitri: what do you think about the SHARED_LIB problem?
2021-04-17 19:20:55 <donoban> in any case it is not a lib used for anything else :\
2021-04-17 19:57:46 <Cogitri> Hm, if we really can't avoid it we can go for static for now
2021-04-17 19:57:54 <Cogitri> As long as upstream knows about it
2021-04-17 20:12:52 <donoban> upstream says they only support static link :\
2021-04-18 11:01:49 <ikke> FYI: I'm going to upgrade the gitlab instance now, so it will become unavailable for a bit
2021-04-18 11:10:41 <donoban> good luck
2021-04-18 11:10:43 <donoban> ;)
2021-04-18 11:12:30 <ikke> I'm always a bit nervous :)
2021-04-18 11:12:42 <ikke> altough I've already tested the upgrade before
2021-04-18 11:13:23 <donoban> hehe, many things in there
2021-04-18 11:13:39 <donoban> could you rollback if goes wrong?
2021-04-18 11:13:55 <ikke> We make a db backup before the upgrade
2021-04-18 11:14:14 <donoban> great
2021-04-18 11:14:20 <ikke> in the worst case, we could restore a machine backup as well
2021-04-18 11:15:10 <donoban> it's all under control :D
2021-04-18 11:15:43 <mps> donoban: there is new tinyproxy upstream release
2021-04-18 11:16:04 <donoban> oh, secfix?
2021-04-18 11:16:14 <mps> no
2021-04-18 11:16:21 <mps> 'normal'
2021-04-18 11:17:10 <mps> if you are interested to make upgrade, please do, else I will do in next few days
2021-04-18 11:17:48 <donoban> ok, but should I do a separate PR? or merge it with the pid/log problems PR?
2021-04-18 11:18:48 <ikke> It's starting again
2021-04-18 11:19:38 <donoban> ikke: so gitlab.alpinelinux.org is all alpine hosted?
2021-04-18 11:19:45 <ikke> donoban: yes
2021-04-18 11:19:46 <mps> donoban: I would create new MR with upgrade and fixes, but you are free to do however you like. if you intend to maintain pkg
2021-04-18 11:19:50 <donoban> I thought it was a "private" part of gitlab
2021-04-18 11:19:57 <ikke> donoban: we host our own instance :)
2021-04-18 11:20:14 <ikke> And it's up :)
2021-04-18 11:20:18 <ikke> \o/
2021-04-18 11:20:58 <donoban> :)
2021-04-18 11:21:07 <donoban> What's new!
2021-04-18 11:22:13 <ikke> The ? on the top right has a "What's new" entry
2021-04-18 11:22:30 <donoban> yes it auto popups on enter
2021-04-18 11:22:51 <donoban> (or I clicked accidentally :P)
2021-04-18 11:23:52 <ikke> https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/
2021-04-18 11:24:01 <ikke> https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/
2021-04-18 11:24:10 <ikke> (We jumped from 13.7 to 13.9)
2021-04-18 11:26:21 <Cogitri> Does someone know what's up with pdns on the builders? I'd like to merge the all-java MR but would be neat to have clean builders for that
2021-04-18 11:27:07 <ikke> https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/#click-and-drag-multiline-merge-request-comments
2021-04-18 11:27:32 <ikke> You can now click+drag to comment on multiple lines in code reviews
2021-04-18 11:27:56 <omni> I'm thinking of packaging that cursed font, should it go under /usr/share/fonts/misc? what is /usr/share/fonts/local?
2021-04-18 11:28:10 <ikke> Cogitri: let me grab the logs
2021-04-18 11:30:12 <ikke> Cogitri: https://tpaste.us/V7Lz
2021-04-18 11:38:31 <donoban> mps: instead creating a new, I will rename the current :D
2021-04-18 11:39:24 <donoban> Is possible to check on a builder if a openRC service starts correctly?
2021-04-18 11:40:49 <ikke> You mean as part of a test?
2021-04-18 11:40:57 <donoban> yes
2021-04-18 11:41:05 <ikke> The builders do not run as root, so you cannot start/stop services
2021-04-18 11:41:17 <donoban> oh I see
2021-04-18 11:46:32 <donoban> "WARNING: obsolete config item on line 200" uHM
2021-04-18 11:47:25 <donoban> it seems that they deprecated some configuration options
2021-04-18 11:47:56 <ikke> Who are they?
2021-04-18 11:48:01 <donoban> tinyproxy
2021-04-18 11:48:04 <ikke> ah
2021-04-18 11:48:11 <donoban> hehe
2021-04-18 11:49:27 <donoban> well I guess that it's not alpine problem right?
2021-04-18 11:50:35 <ikke> no
2021-04-18 11:51:09 <donoban> uhM, I'm also considering moving logfile from '/var/log/tinyproxy/tiniproxy.log' , to '/var/log/tinyproxy.log"
2021-04-18 11:56:32 <donoban> mps: if you want to take a look https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20078
2021-04-18 12:10:02 <mps> donoban: as I wrote 'do whatever you like' but also I wrote what I would do. 'read context of my msg' :)
2021-04-18 12:11:10 <sh4rm4^bnc> 
ACTION tinyproxy author here

2021-04-18 12:11:31 <donoban> oh :D
2021-04-18 12:11:47 <mps> heh
2021-04-18 12:12:34 <sh4rm4^bnc> i'd suggest to run tinyproxy in foreground from openrc
2021-04-18 12:12:43 <sh4rm4^bnc> without pidfiles and antiquated shit like that
2021-04-18 12:13:10 <sh4rm4^bnc> tinyproxy -d -c tinyproxy.conf and make openrc redirect stdout/stderr to log
2021-04-18 12:14:02 <donoban> uhM, I see
2021-04-18 12:14:29 <donoban> by redirect to log is it possible to a custom log file? default config is very verbose, a pain if it goes to messages
2021-04-18 12:14:51 <mps> sh4rm4^bnc: does it need some dirs to keep caches or something else
2021-04-18 12:14:53 <sh4rm4^bnc> i'm not too familiar with openrc but runit does it automatically
2021-04-18 12:15:00 <sh4rm4^bnc> mps: not any more
2021-04-18 12:15:15 <mps> ah, good improvement
2021-04-18 12:15:52 <ShaRose> suppose I should wait for a few days to submit an update for the zrepl package
2021-04-18 12:15:52 <sh4rm4^bnc> my runit script looks like this
2021-04-18 12:15:53 <mps> yes, running daemons with runit is quite easy
2021-04-18 12:15:55 <sh4rm4^bnc> SUSER=rodaemon
2021-04-18 12:15:56 <sh4rm4^bnc> SHOME=/home/$SUSER/tinyproxy
2021-04-18 12:15:56 <sh4rm4^bnc> # tp needs to be statically compiled!
2021-04-18 12:15:56 <sh4rm4^bnc> exec chpst -/ $SHOME -u $SUSER:$SUSER \
2021-04-18 12:16:08 <sh4rm4^bnc> /src/tinyproxy -d -c tinyproxy.conf
2021-04-18 12:17:11 <sh4rm4^bnc> that's chrooted so you need a resolv.conf in there
2021-04-18 12:17:31 <mps> or void linux runit script :)
2021-04-18 12:17:34 <sh4rm4^bnc> but you can also just remove the chroot flag to chpst
2021-04-18 12:17:53 <sh4rm4^bnc> mps, what does void do differently ?
2021-04-18 12:18:17 <mps> https://tpaste.us/maLV
2021-04-18 12:18:56 <donoban> sh4rm4^bnc: is there any way for reloading filter list without restarting the service?
2021-04-18 12:19:01 <mps> huh, why tpaste.us is unstable from yesterday
2021-04-18 12:19:06 <donoban> some service reload
2021-04-18 12:19:41 <sh4rm4^bnc> donoban, sighup in daemon mode or sigusr1 in any mode
2021-04-18 12:20:26 <sh4rm4^bnc> mps, what that tinyproxy_ thing they copy around ?
2021-04-18 12:20:36 <donoban> I will like handling it properly
2021-04-18 12:21:22 <mps> sh4rm4^bnc: I newer used voil linux, so don't know, but looks like group settings
2021-04-18 12:21:36 <mps> s/voil/void/
2021-04-18 12:21:36 <alpine-meetbot> mps meant to say: sh4rm4^bnc: I newer used void linux, so don't know, but looks like group settings
2021-04-18 12:30:29 <sh4rm4^bnc> makedepends="asciidoc" can be removed
2021-04-18 12:30:54 <sh4rm4^bnc> tarball ships with pre-generated manpages
2021-04-18 12:31:05 <donoban> ok
2021-04-18 12:31:18 <sh4rm4^bnc> if they need to be redone, it's now done with pod2man (ships with perl5)
2021-04-18 12:34:21 <donoban> I would like to know skarnet opinion about running it in foreground/background
2021-04-18 12:34:59 <donoban> but I'm trying to setup it as you said ^^
2021-04-18 12:35:08 <sh4rm4^bnc> i'd personally also do user/group stuff via chpst rather than setting it via config
2021-04-18 12:36:21 <donoban> is not user/group integrated in openrc?
2021-04-18 12:36:46 <ikke> mps: good question (re tpaste)
2021-04-18 12:36:54 <sh4rm4^bnc> donoban, maybe
2021-04-18 12:39:11 <sh4rm4^bnc> so imo the complete sed statement on line 23 could be removed, unless openrc requires the pidfile
2021-04-18 12:39:24 <donoban> command_user="user:group"
2021-04-18 12:39:45 <donoban> yeah I'm trying to do it
2021-04-18 12:40:02 <donoban> but now get stuck on the log: WARNING: logging deactivated (can't log to stdout when daemonized)
2021-04-18 12:40:18 <sh4rm4^bnc> tinyproxy -d
2021-04-18 12:40:22 <donoban> it's already
2021-04-18 12:40:35 <donoban> uhM
2021-04-18 12:40:48 <donoban> uhM
2021-04-18 12:41:09 <donoban> it is ignoring this: command_args_foreground="-d -c ${CONFFILE}"
2021-04-18 12:41:11 <donoban> uch
2021-04-18 12:41:37 <donoban> problem is that if remove the _foreground part (which seemst that it ignroes), it gets trapped on rc-service restart
2021-04-18 12:41:39 <sh4rm4^bnc> openrc seems a whole lot more complicated than runit ^_^
2021-04-18 12:41:57 <donoban> maybe I had to explicit tell that its not daemonized
2021-04-18 12:42:04 <ikke> donoban: you need to set a supervisor
2021-04-18 12:42:09 <donoban> command_background=false ?
2021-04-18 12:42:25 <ikke> https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md
2021-04-18 12:42:47 <donoban> ah ok
2021-04-18 12:42:55 <donoban> thanks ikke
2021-04-18 12:43:02 <ikke> openrc expects by default that services fork themselves
2021-04-18 12:43:20 <ikke> (or does for them, if they don't do it)
2021-04-18 12:44:51 <mps> just to note from my yesterday look at tinyproxy, I feel it would be good to have more cli options. though I don't use tinyproxy so my opinion is irrelevant
2021-04-18 12:46:08 <donoban>  2527 root      0:00 supervise-daemon tinyproxy --start /usr/bin/tinyproxy -- -d -c /etc/tinyproxy/tinyproxy.conf
2021-04-18 12:46:12 <sh4rm4^bnc> it's either "configuration via config file" or "configuration via commandline", having both usually results in a mess
2021-04-18 12:49:18 <donoban> uhM, this way you end having an additional process for the service
2021-04-18 12:49:35 <donoban> I'm not sure if I prefer the pidfile :D
2021-04-18 12:49:45 <donoban> I got to go for a while, see you guys
2021-04-18 12:50:28 <sh4rm4^bnc> the additional process is for free, the supervisor is already loaded for other services
2021-04-18 13:06:58 <ikke> sh4rm4^bnc: no, each process gets its own supervisor process
2021-04-18 13:07:00 <ikke> with openrc
2021-04-18 13:07:06 <ikke> It's kind of 'hacked on';
2021-04-18 13:07:24 <sh4rm4^bnc> yeah, but the process image is already mapped to r/o memory
2021-04-18 13:08:06 <sh4rm4^bnc> hacked on ?
2021-04-18 13:08:06 <ikke> Right
2021-04-18 15:12:04 <skarnet> donoban: that, or you can use the runit script exactly as it is on void, and just launch it under s6, which exists on Alpine :P
2021-04-18 15:12:49 <donoban> uhM, I'm currently running the process on foreground, and letting openRC move it to background and generate the pidfile
2021-04-18 15:13:26 <skarnet> that's start-stop-daemon doing it on openrc's behalf
2021-04-18 15:13:36 <skarnet> it's the "regular" way of doing it when you don't have a supervisor
2021-04-18 15:13:57 <skarnet> and it sucks, but supervise-daemon sucks as well for other reasons, so, pick your poison. :P
2021-04-18 15:13:57 <donoban> I like to have all the stuff (user, pidfile, log file), on the same place
2021-04-18 15:14:02 <donoban> and it seems a good way for achieve it
2021-04-18 15:14:27 <donoban> what is the real benefit of supervise-daemon? auto restart the service if crashes?
2021-04-18 15:14:56 <skarnet> that's about it. They didn't understand all the benefits of supervision, so wrote a half-assed thing and that's about all it does.
2021-04-18 15:15:49 <skarnet> with s6, you also have better logging management, service addressing without knowing the pid, and other control features.
2021-04-18 15:16:11 <donoban> uhM yeah but what about the alpine default package setup?
2021-04-18 15:16:26 <donoban> I really don't have any preference, if it just works...
2021-04-18 15:16:50 <skarnet> default alpine atm is use openrc, with or without supervise-daemon
2021-04-18 15:16:53 <skarnet> again, pick your poison
2021-04-18 15:16:59 <donoban> hehe
2021-04-18 15:17:23 <donoban> so I think that running it with -d, removing al sed -e tinyproxy config, and let openRC set user/group, pidfile and logfile
2021-04-18 15:17:43 <maxice8> boost upgrade is going well with versioned version
2021-04-18 15:17:53 <maxice8> aside from the fact I messed it up a bit
2021-04-18 15:18:03 <skarnet> donoban: that's probably the simplest. Short of a real supervision suite it's about the same thing
2021-04-18 15:23:17 <mps> donoban: default for alpine is still openrc as skarnet told
2021-04-18 15:24:04 <donoban> yes yes
2021-04-18 15:24:36 <mps> that means you have to make needed changes in aports for tinyproxy
2021-04-18 15:25:09 <mps> don't forget home dir fix
2021-04-18 15:25:32 <donoban> I noticed that the original version, was getting some variables in the init.d script from the /etc/tinyproxy/tinyproxy.conf , even if that option are commented, which is pretty difficult to understand
2021-04-18 15:25:47 <donoban> now all openRC related things are inside the init.d script
2021-04-18 15:26:09 <donoban> I feel that is more easy to manage
2021-04-18 15:26:48 <skarnet> init.d should be mechanism and .conf files policy
2021-04-18 15:27:03 <mps> packaging is not about 'easy' but to follow distro style
2021-04-18 15:27:30 <donoban> hehe ok ok
2021-04-18 15:28:11 <mps> I would do a lot of things differently but have to 'obey' alpine style
2021-04-18 15:28:23 <donoban> well
2021-04-18 15:28:35 <donoban> the function that tinyproxy uses for get variables from the other file config
2021-04-18 15:28:46 <donoban> is not used in any other init.d script..., so it is not too much alpine likely
2021-04-18 15:29:23 <mps> well, there are a lot of crap^W'things' which do not follow style
2021-04-18 15:31:53 <donoban> maybe it comes from gentoo
2021-04-18 15:32:07 <donoban> it has: # Copyright 1999-2018 Gentoo Authors
2021-04-18 15:33:28 <mps> could be, a lot of alpine pkgs have this
2021-04-18 15:33:43 <mps> copy-paste ;)
2021-04-18 15:35:52 <donoban> https://tpaste.us/9j54
2021-04-18 15:36:10 <donoban> do you see 'obeying' alpine style?
2021-04-18 15:37:30 <donoban> command_args_foreground is not necessary
2021-04-18 15:38:11 <donoban> and I'm going to add a reload handler :D
2021-04-18 15:42:42 <ikke> donoban: command_args_foreground is only necessary when the program needs to be explicitly told to remain on the foreground and you are using a supervisor
2021-04-18 15:42:50 <donoban> yes yes I removed it
2021-04-18 15:43:11 <donoban> I forgot to delete with deleting supervisor
2021-04-18 15:43:23 <donoban> do you know what is needed for add a reload() func?
2021-04-18 15:43:50 <donoban> when used for filtering is nice to reload the config without killing the process
2021-04-18 15:44:49 <ikke> donoban: the service needs to support it
2021-04-18 15:45:01 <ikke> usualy through a signal (USR1, for example)
2021-04-18 15:45:11 <donoban> yes yes I know it arleady
2021-04-18 15:45:18 <donoban> here is what I missed: extra_started_commands="reload"
2021-04-18 15:45:22 <ikke> ah
2021-04-18 15:49:38 <donoban> localhost:/etc/init.d$ sudo rc-service tinyproxy reload
2021-04-18 15:49:40 <donoban>  * Reloading tinyproxy ...
2021-04-18 15:49:57 <donoban> NOTICE    Apr 18 17:49:27.782 [19520]: Reloading config file
2021-04-18 15:51:14 <ikke> :)
2021-04-18 15:52:11 <donoban> uhM...
2021-04-18 15:52:38 <donoban> it seems that it reloads config but no filter file
2021-04-18 15:52:45 <donoban> sh4rm4^bnc: is that possible?
2021-04-18 15:53:23 <sh4rm4^bnc> it reloads filter file too
2021-04-18 15:53:51 <donoban> uhm..
2021-04-18 15:54:09 <donoban> maybe I had already a connection opened?
2021-04-18 15:54:24 <donoban> now I tested from filtered to unfiltered and it worked :)
2021-04-18 15:56:41 <sh4rm4^bnc> if it doesnt display "filter file reloaded" maybe that should be added
2021-04-18 15:57:13 <donoban> well don't bother, I just thought it was not reloading it
2021-04-18 16:03:27 <donoban> APKBUILD:12:variable set to empty string: makedepends="" so just remove it?
2021-04-18 16:03:49 <ikke> yes
2021-04-18 16:03:53 <donoban> ok
2021-04-18 18:49:30 <maxice8> fcolista: thanks for handling openvas
2021-04-18 19:42:50 <ShaRose> So, it's working NOW, but in the future, if a make a package that has occasional test failures due to timeouts due to build server load, should I just skip the tests or?
2021-04-18 19:43:18 <ikke> Maybe increase the timeouts?
2021-04-18 19:43:58 <ShaRose> it's in the go tests, not even sure how to tbh
2021-04-18 19:44:42 <ShaRose> as it is if I get failures I just rerun them until they all pass: last time it was just one, but this time I had to rerun like 3 times
2021-04-18 19:44:55 <ikke> yeah, that's not ideal
2021-04-18 19:45:03 <ikke> seems like those timeouts are too tight
2021-04-18 19:46:06 <ShaRose> https://gitlab.alpinelinux.org/ShaRose/aports/-/jobs/374524 at least I'm ASSUMING it's timeouts
2021-04-18 19:48:37 <ikke> https://github.com/zrepl/zrepl/blob/master/util/optionaldeadline/optionaldeadline_test.go#L74
2021-04-18 19:51:13 <ikke> Would be interesting to see the actual amount of time passed
2021-04-18 22:36:32 <Cogitri> Hm, what way did provider_priority count again? The higher the number, the higher the importance?
2021-04-18 22:37:53 <caskd-Alex> yeah
2021-04-19 06:11:03 <fcolista> @maxice8, np. I didn't realized immedatedly that was failing at x86 :-/
2021-04-19 06:20:08 <ikke> Cogitri: just think of it as a version
2021-04-19 06:25:47 <[[sroracle]]> ah that is a useful way to think of it :)
2021-04-19 06:49:42 <Cogitri> Oh indeed :)
2021-04-19 07:52:39 <mps> ncopa: any progress about making armv7 virt iso
2021-04-19 07:52:50 <ncopa> nope
2021-04-19 07:53:00 <mps> ok
2021-04-19 07:53:04 <ncopa> im currently moving some of the builders to new arm server
2021-04-19 07:54:48 <PureTryOut[m]2> Cogitri: why is there glibmm with version 2.66 (and being outdated) and glibmm2.68?
2021-04-19 08:00:50 <Cogitri> PutryTryOut[m]2: Because they broke the API with glibmm2.68
2021-04-19 08:00:57 <Cogitri> Also changed the pkgconfig file and so on
2021-04-19 08:01:48 <Cogitri> Same for cairomm1.16, pangomm2.48 etc.
2021-04-19 08:08:21 <PureTryOut[m]2> Oh darn, ok
2021-04-19 08:16:56 <ncopa> mps: btw, did you work on the ovmf update?
2021-04-19 08:31:15 <mps> ncopa: I tried again previous week but without any progress :(
2021-04-19 08:32:18 <mps> I don't understand why it fails nearly at the end of build. Tried to apply some 'tricks' from debian but without results
2021-04-19 08:32:46 <mps> searched net, again without any success
2021-04-19 08:40:31 <ncopa> ok
2021-04-19 08:59:48 <mps> maybe someone who understand python could help
2021-04-19 09:23:59 <donoban> understand python code or python interanls?
2021-04-19 09:24:16 <donoban> s/interanls/internals
2021-04-19 09:24:16 <alpine-meetbot> donoban meant to say: understand python code or python internals?
2021-04-19 09:35:04 <mps> donoban: python failed for some strange on MR !18588
2021-04-19 09:35:21 <mps> and I don't understand how to debug this
2021-04-19 09:37:39 <donoban> " This job is archived. Only the complete pipeline can be retried. " can I read the logs with "the complete pipeline"?
2021-04-19 09:38:52 <donoban> well I will try to build myself
2021-04-19 09:46:16 <mps> restart failed CI
2021-04-19 09:47:24 <mps> hmm, no option to restart archived ones
2021-04-19 09:47:56 <donoban> I'm trying to clone your branch on my repository
2021-04-19 09:48:09 <donoban> tried with git fetch without success
2021-04-19 09:48:30 <mps> lets try to fake it by rebase :)
2021-04-19 09:49:06 <donoban> uhM, not sure what exactly do
2021-04-19 09:49:39 <donoban> do I need to add your repository to some remote?
2021-04-19 09:50:18 <mps> donoban: I use this https://tpaste.us/49Q1 to download MR and apply it locally
2021-04-19 09:51:18 <mps> I don't know much about add repositories and messing with them
2021-04-19 09:51:20 <donoban> mmM, I would prefer the "native git way"
2021-04-19 09:52:20 <donoban>  * [new branch]            edk2-0.0.202011-r2                        -> mps/edk2-0.0.202011-r2
2021-04-19 09:52:23 <donoban> :D
2021-04-19 09:53:02 <mps> I don't intend to become git usage expert :)
2021-04-19 09:53:30 <donoban> hehe me neither
2021-04-19 09:55:34 <mps> actually I know how to trigger it on CI, 'git push --force mps' will work I think
2021-04-19 09:56:52 <donoban> the error is not very informative
2021-04-19 09:57:05 <donoban> build.py...
2021-04-19 09:57:07 <donoban>  : error 7000: Failed to execute command
2021-04-19 09:57:09 <donoban>         make tbuild [/home/builder/aports/community/edk2/src/edk2-edk2-stable202011/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib]
2021-04-19 09:57:40 <mps> hmm, 'git push --force mps' doesn't work on archived MR
2021-04-19 09:58:05 <mps> let me run it locally
2021-04-19 09:58:49 <mps> donoban: yes, this ' build.py...'
2021-04-19 09:59:50 <mps> 'apk search cmd:tbuild' doesn't show anything
2021-04-19 10:00:17 <mps> and I concluded it must be something in python
2021-04-19 10:01:28 <mps> donoban: btw, I merged tinyproxy this morning
2021-04-19 10:01:31 <donoban> I don't know, I could investigate it at night
2021-04-19 10:01:39 <donoban> yeah I saw it! great :D
2021-04-19 10:02:05 <donoban> I noticed that there are identations errors on init.d file
2021-04-19 10:02:14 <donoban> but beh, better fix on next release
2021-04-19 10:02:59 <mps> yes, or you can do that without pkgrel bump, to not forget
2021-04-19 10:04:18 <donoban> well, just removed an if clause and didnt' removed the \tabs in the two lines inside
2021-04-19 10:04:33 <donoban> do you think is worth to bump pkgrel?
2021-04-19 10:09:29 <mps> I don't have strong opinion, but if you are 'git commit number hunter' then yes
2021-04-19 10:10:17 <mps> anyway, fix is good always, especially if it not breaks :)
2021-04-19 10:11:06 <mps> though I skip such things because I don't like to waste time on 'small things'
2021-04-19 10:11:30 <donoban> hehe is my feeling about it
2021-04-19 10:11:40 <donoban> is less than small
2021-04-19 10:12:43 <mps> I usually make notes on such things for next upgrade and usually forgot them on next upgrade :)
2021-04-19 10:13:04 <donoban> 👍 noted :P
2021-04-19 10:53:09 <donoban> mps:  the real problem seems not related with python: make: *** [GNUmakefile:315: /home/builder/aports/community/edk2/src/edk2-edk2-stable202011/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/DEBUG/BootMaintenanceManager.c] Illegal instruction (core dumped) , could be GNU<->musl problem?
2021-04-19 10:59:56 <mps> huh, how I missed this in build log :/
2021-04-19 11:01:19 <donoban> hehe because is not properly separated from the std log
2021-04-19 11:02:51 <donoban> also it seems that the file 'BootMaintenanceManager.c' doesn't exist :\
2021-04-19 11:03:55 <donoban> maybe it's generated on build but I'm theorically keeping all files with abuild -k
2021-04-19 11:04:50 <donoban> I got to go for the rest of the day, I will continue at night if I'm not too tired
2021-04-19 11:06:48 <mps> donoban: thanks for help
2021-04-19 11:07:16 <donoban> np, see you :)
2021-04-19 11:21:27 <PureTryOut[m]2> Cogitri: uh, glib-dev seems broken. It fails to include it's own files. `/usr/include/glib-2.0/glib.h:30:10: fatal error: glib/galloca.h: No such file or directory`
2021-04-19 11:22:51 <PureTryOut[m]2> Also the pkgconfig file points to `/usr/include` while it's files are actually in `/usr/include/glib-2.0`
2021-04-19 11:23:17 <Cogitri> That seems to be just fine to me?
2021-04-19 11:23:32 <Cogitri> Since you do #include <glib-2.0/header.h>
2021-04-19 11:23:51 <PureTryOut[m]2> This particular application I'm trying to compile doesn't, and glib-dev itself doesn't 🤔
2021-04-19 11:24:48 <Cogitri> Ah whoops it's include <glib/header.h>
2021-04-19 11:25:19 <PureTryOut[m]2> Still, why does `/usr/include/glib-2.0/glib.h` fail to include `glib/galloca.h`?
2021-04-19 11:25:20 <Cogitri> `Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include`
2021-04-19 11:25:27 <Cogitri> Is in the pkgconfig file
2021-04-19 11:25:35 <Cogitri> So it seems A-OK to me
2021-04-19 11:25:58 <Cogitri> includedir= is the system includedir, not the includedir of that particular package
2021-04-19 11:26:02 <PureTryOut[m]2> The pkgconfig file sure but as said, glib fails to include it's own files. Or is this a case of the build system of this particular application being broken?
2021-04-19 11:26:25 <Cogitri> I very much suspect the latter
2021-04-19 11:26:50 <Cogitri> It doesn't pass -I/usr/include/glib-2.0 to the CC when the Cflags field in the pkg-config file says it should
2021-04-19 11:27:29 <PureTryOut[m]2> Hmm ok annoying
2021-04-19 11:28:28 <Ariadne> PureTryOut[m]2: have you verified that glib/galloca.h is actually present
2021-04-19 11:28:49 <Cogitri> It is
2021-04-19 11:29:05 <PureTryOut[m]2> It is indeed
2021-04-19 11:29:17 <Cogitri> The problem is just that it doesn't include glib's cflags
2021-04-19 11:29:21 <Ariadne> mps: fwiw if you go ahead and opt-in to using remake as system make ahead of time, it will show those errors more clearly
2021-04-19 11:29:22 <Cogitri> Things which happen if the application doesn't use meson :p
2021-04-19 11:29:38 <Ariadne> mps: this is the main reason i want to replace GNU make with remake, the error output is *much* more intuitive
2021-04-19 11:29:39 <PureTryOut[m]2> (or CMake, or any other sane build system)
2021-04-19 11:29:44 <PureTryOut[m]2> This is still using a plain Makefile damn it
2021-04-19 11:29:54 <Cogitri> Ugh
2021-04-19 11:30:10 <PureTryOut[m]2> https://github.com/AsteroidOS/mce/blob/master/Makefile#L279
2021-04-19 11:30:13 <Ariadne> sorry i was talking about mps's issue with OVMF
2021-04-19 11:30:15 <Ariadne> :)
2021-04-19 11:30:18 <PureTryOut[m]2> You'd think that would do the trick no?
2021-04-19 11:30:45 <Ariadne> yes, that should do the trick
2021-04-19 11:31:04 <Ariadne> do you have a build log?
2021-04-19 11:31:07 <Cogitri> Could you paste the entire log?
2021-04-19 11:31:12 <Cogitri> Ah, beat me to it :D
2021-04-19 11:31:15 <PureTryOut[m]2> In a sec
2021-04-19 11:33:21 <PureTryOut[m]2> Oh, huh. I noticed I was missing some other deps still and added those to get a cleaner log without "missing dep" warnings, and now it suddenly is able to find glib without problems
2021-04-19 11:34:04 <mps> Ariadne: thanks for info, it is worth trying
2021-04-19 11:34:23 <Ariadne> mps: yes, that is why i want to make remake the default make instead of gmake
2021-04-19 11:34:44 <mps> how it is used? just 'remake' instead of 'make' or need something else/more
2021-04-19 11:35:01 <Ariadne> remake will, assuming that the build system is not clobbering the jobserver, display the entire failure path at the end of the build log
2021-04-19 11:35:41 <Ariadne> yes, if you just use remake package
2021-04-19 11:35:45 <Ariadne> `remake` will work
2021-04-19 11:35:50 <Ariadne> if you add remake-make
2021-04-19 11:35:54 <Ariadne> it will replace gmake with remake
2021-04-19 11:36:03 <Ariadne> in which case you don't have to do *anything* :
2021-04-19 11:36:06 <Ariadne> :P*
2021-04-19 11:36:33 <mps> Ariadne: heh, so simple
2021-04-19 11:37:29 <Ariadne> https://twitter.com/ariadneconill/status/1382508590028574720 shows the improved error tracing in remake
2021-04-19 11:37:31 <Ariadne> :)
2021-04-19 11:37:49 <Ariadne> the part at the bottom will always be at the end of the build log
2021-04-19 11:38:26 <skarnet> that's a very nice feature but doesn't justify replacing a package in itself over trying to upstream the feature into gmake
2021-04-19 11:38:42 <skarnet> I'm not married to gmake and if remake is compatible I'm happy
2021-04-19 11:38:44 <Cogitri> PureTryOut[m]2: Ah, no proper error handling in make, nice :)
2021-04-19 11:38:58 <skarnet> but replacing a package sounds like more work than upstreaming a feature
2021-04-19 11:39:11 <skarnet> unless of course there are *other* additional reasons for replacing a package
2021-04-19 11:39:17 <Ariadne> skarnet: remake is a fork of gmake, and it passes the gmake 4.3 testsuite
2021-04-19 11:39:19 <Ariadne> :)
2021-04-19 11:39:26 <Ariadne> gmake itself is dead upstream
2021-04-19 11:39:31 <PureTryOut[m]2> Cogitri: yup, screw this "build system"
2021-04-19 11:39:34 <Cogitri> Ariadne: Could you please check that gobject-introspection and things using its m4 macros still work with your make replacement?
2021-04-19 11:39:35 <skarnet> oh? shame
2021-04-19 11:39:48 <Ariadne> Cogitri: it's not mine, but it does
2021-04-19 11:39:57 <Ariadne> Cogitri: i've been using it for a few months now
2021-04-19 11:39:59 <Ariadne> :)
2021-04-19 11:40:08 <Ariadne> i have even built OpenJDK wth it
2021-04-19 11:40:09 <skarnet> one of the two GNU packages that build easily
2021-04-19 11:40:17 <skarnet> shame that it's dead :/
2021-04-19 11:40:24 <Cogitri> Okie, just figured it'd be worth mentioning since it seems like some BSDs have problems with that since g-i assumes that GNU make is used
2021-04-19 11:40:35 <Ariadne> Cogitri: for all purposes, remake *is* gmake
2021-04-19 11:40:36 <Ariadne> :)
2021-04-19 11:40:46 <Cogitri> Ok 👍
2021-04-19 11:41:20 <mps> someone mentioned some time ago that s/he made PKGBUILD to ABUILD convert script, anyone knows about this, url or hint
2021-04-19 11:41:55 <Ariadne> in fact, gmake 4.3 is just some things backported from remake
2021-04-19 11:41:56 <mps> Ariadne: just used remake and it works, though didn't fixed edk2 build :)
2021-04-19 11:42:12 <Ariadne> mps: yeah it won't fix anything, but it makes tracing easier
2021-04-19 11:43:17 <Ariadne> skarnet: the author of remake does not wish to assign his copyright to FSF anyway
2021-04-19 11:43:24 <Ariadne> skarnet: so a fork was unfortunately the only way :p
2021-04-19 11:43:49 <skarnet> the GPL made another victim
2021-04-19 11:43:57 <skarnet> well no
2021-04-19 11:44:11 <skarnet> not the GPL, the FSF's copyright assignment policy
2021-04-19 11:44:56 <skarnet> (I understand the idea behind the GPL, I do not understand the idea behind the copyright assignment policy)
2021-04-19 11:46:55 <Ariadne> skarnet: https://remake.readthedocs.io/en/latest/features.html outlines basically the motivations for why he forked it into remake, and he previously worked on gmake too
2021-04-19 11:48:54 <skarnet> he makes a lot of good points but none of those are motivations to fork the project. Copyright assignment would be one but it's not listed here. :P
2021-04-19 11:49:33 <Ariadne> the FSF did not want those features :P
2021-04-19 11:50:26 <skarnet> "we do not want to make our software better" explains a lot about GNU in general :P
2021-04-19 11:52:21 <Ariadne> anyway, remake has been quite helpful for me in debugging weird build problems
2021-04-19 11:52:34 <Ariadne> and it passes the entire GNU make 4.3 testsuite
2021-04-19 11:52:40 <Ariadne> there will likely never be a GNU make 4.4
2021-04-19 11:53:36 <skarnet> well if remake is fully compatible and is actually developed and maintained by someone with experience with make then I'm fully onboard with it
2021-04-19 11:54:59 <Ariadne> the problem is that GNU's idea of portable code is, well
2021-04-19 11:55:03 <Ariadne> stuck in the 1980s
2021-04-19 11:55:13 <skarnet> yeah, I've seen the ifdef forests
2021-04-19 11:55:32 <Ariadne> and the chief GNUsiance is especially a nuisance when it comes to removing all of that
2021-04-19 12:00:05 <Ariadne> and the best part of remake is
2021-04-19 12:00:17 <Ariadne> the remake maintainer rebases on whatever gmake is doing
2021-04-19 12:00:23 <Ariadne> so if there is ever a gmake 4.4
2021-04-19 12:00:28 <Ariadne> it will be compatible :p
2021-04-19 12:01:53 <Ariadne> but for gmake 4.3 and current gmake git, it is just badly done backports from remake
2021-04-19 12:02:00 <Ariadne> which is why 4.3 shipped with bugs :D
2021-04-19 12:20:40 <skarnet> pushed !20619 for review and testing by minimal (not on the chan atm) who's working on utmps integration, please DO NOT merge it before his approval
2021-04-19 12:21:11 <Cogitri> Best to mark it as WIP then
2021-04-19 12:21:19 <Cogitri> So it can't be merged by accident
2021-04-19 12:21:35 <skarnet> ah yes, forgot about that
2021-04-19 12:22:02 <skarnet> not that it would break anything if it was merged, but I don't want it to go under the radar before he has a chance to see what I modified XD
2021-04-19 12:23:03 <skarnet> I used the "mark as draft" button on the gitlab UI, it says "Draft:" instead of "WIP:" but I suppose it serves the same purpose
2021-04-19 12:27:29 <mps> donoban: building edk2 got this in dmesg out: [775790.568724] traps: VfrCompile[47569] trap invalid opcode ip:5626fa3849da sp:7ffef035c710 error:0 in VfrCompile[5626fa381000+65000]
2021-04-19 12:28:16 <mps> on x86_64
2021-04-19 12:32:29 <Ariadne> what the absolute fuck
2021-04-19 12:32:48 <Ariadne> is VfrCompile a binary blob or something
2021-04-19 12:36:22 <mps> yes
2021-04-19 12:37:04 <mps> I think it is built locally in first phase in build
2021-04-19 12:48:21 <ikke> mps:  toapk
2021-04-19 12:49:30 <mps> ikke: thanks
2021-04-19 12:55:35 <ncopa> Ariadne: do you have any recommendation for a unit test framework for C? would like to add some unit tests for abuild-fetch
2021-04-19 12:55:42 <Ariadne> atf-c
2021-04-19 12:55:48 <Ariadne> and kyua :)
2021-04-19 12:57:07 <ncopa> ok. whats good with it?
2021-04-19 12:57:20 <ncopa> certainly not the docs... :)
2021-04-19 13:13:07 <Ariadne> :D
2021-04-19 13:13:20 <Ariadne> https://www.mankier.com/3/atf-c-api
2021-04-19 13:13:25 <Ariadne> the docs are, ok
2021-04-19 13:13:27 <Ariadne> the docs suck :D
2021-04-19 13:18:14 <Ariadne> skarnet: by the way, the GPL is the main reason apk-tools directly uses OpenSSL
2021-04-19 13:18:29 <Ariadne> skarnet: as a result, we can argue that OpenSSL is a "system library"
2021-04-19 13:18:39 <Ariadne> which makes it compatible with GPL programs when it otherwise would not be
2021-04-19 13:18:56 <Ariadne> but OpenSSL 3.x is switching to Apache-2
2021-04-19 13:18:58 <Ariadne> soooooo
2021-04-19 13:19:14 <Ariadne> :)
2021-04-19 13:19:31 <Ariadne> and, bluntly, removing OpenSSL from the base system would sure be a security win
2021-04-19 13:19:37 <skarnet> oh, definitely
2021-04-19 13:20:14 <skarnet> well if you want to port it to bearssl I'm definitely willing to help, but I don't know the apk-tools code well enough
2021-04-19 13:20:28 <Ariadne> i think we port the TLS part to use libtls
2021-04-19 13:20:47 <Ariadne> and then include a lightweight cryptographic ops library with apk-tools
2021-04-19 13:21:15 <Ariadne> the latter is already "planned" anyway
2021-04-19 13:21:27 <skarnet> what kind of ops?
2021-04-19 13:21:45 <Ariadne> RSA signature verification, Curve25519 signature verification, etc
2021-04-19 13:21:50 <Ariadne> i assume libsodium would work here
2021-04-19 13:21:59 <skarnet> yeah it should
2021-04-19 13:22:42 <Ariadne> the tls helper in our busybox package was written against libtls to allow us to switch the implementation later anyway
2021-04-19 13:22:52 <skarnet> depending on the parts of openssl apk-tools is currently using it may or may not be simpler to port it to libtls than to raw bearssl
2021-04-19 13:22:54 <Ariadne> like, we seriously have no love for OpenSSL here :p
2021-04-19 13:23:15 <skarnet> if it's simpler then libtls will be fine, for the underlying implementation we have mcf :P
2021-04-19 13:23:19 <Ariadne> skarnet: there's two parts
2021-04-19 13:23:40 <skarnet> the TLS part and the verification part?
2021-04-19 13:23:43 <Ariadne> right
2021-04-19 13:23:54 <Ariadne> the TLS part is basically textbook openssl TLS code
2021-04-19 13:23:57 <Ariadne> nothing special there
2021-04-19 13:24:15 <skarnet> yeah so libtls/bearssl will work, and libsodium will work for signatures
2021-04-19 13:24:50 <Ariadne> well i am not sure
2021-04-19 13:24:54 <Ariadne> does libsodium actually do RSA?
2021-04-19 13:25:01 <Ariadne> i thought it only did curve25519 etc
2021-04-19 13:26:00 <Ariadne> yeah
2021-04-19 13:26:04 <Ariadne> it only does the DJB stuff
2021-04-19 13:26:24 <Ariadne> since apk-tools uses RSA, we need to support that, just with something more pleasant than libcrypto
2021-04-19 13:26:25 <skarnet> well there are RSA signature primitives in bearssl as well :P
2021-04-19 13:27:14 <Ariadne> i think the first step would be to factor the cryptographic ops so that a chosen crypto module can be compiled in at build time
2021-04-19 13:27:23 <Ariadne> then we just write whatever backend we need
2021-04-19 13:27:25 <skarnet> yeah
2021-04-19 13:28:05 <Ariadne> which is technically on the proverbial roadmap for apk-tools
2021-04-19 13:28:18 <Ariadne> i'll open a bug
2021-04-19 13:28:26 <Ariadne> so we can come up with a solid design
2021-04-19 13:29:27 <Ariadne> with openssl moving to an acceptable license, we no longer need that "system library" exception
2021-04-19 13:43:23 <Ariadne> skarnet: feel free to deposit your thoughts here: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10744
2021-04-19 13:44:23 <PureTryOut[m]2> Hmm. `qml-asteroid` is not in the repo for ppc64le even though it isn't disabled there and the builder for that arch is idle
2021-04-19 13:50:14 <maxice8> fcolista: no worries
2021-04-19 13:57:09 <ericonr> Ariadne: I have tried porting parts of void's xbps to BearSSL, the crypto APIs are so close to each other that porting is actually really simple
2021-04-19 13:57:32 <ericonr> the abstraction would mostly allow picking one or the other at compile time, I guess
2021-04-19 13:57:32 <Ariadne> ericonr: yes, but it is nice to have an abstraction layer
2021-04-19 13:58:21 <ericonr> fair
2021-04-19 13:58:48 <ericonr> hm, you folks also carry a vendored in libfetch
2021-04-19 13:59:14 <ericonr> I have aspirations of porting it to use bearssl instead of openssl, though for now that'd come at the cost of tls 1.3 support
2021-04-19 13:59:16 <Ariadne> its a fork
2021-04-19 13:59:18 <Ariadne> of libfetch
2021-04-19 13:59:20 <Ariadne> actually
2021-04-19 13:59:22 <Ariadne> :D
2021-04-19 13:59:43 <Ariadne> ours is... quite modified!
2021-04-19 13:59:50 <ericonr> well, it's not a system library :P
2021-04-19 14:00:11 <ericonr> does libtls give enough control for libfetch shenanigans?
2021-04-19 14:00:26 <Ariadne> likely!
2021-04-19 14:00:45 <Ariadne> we literally wrote the TLS code our fork uses :)
2021-04-19 14:01:14 <ericonr> ah, neat :)
2021-04-19 14:03:11 <ericonr> Ariadne: your version still has this bug: https://github.com/void-linux/xbps/pull/349/files
2021-04-19 14:03:26 <ericonr> we hit it when downloading things from sourceforge
2021-04-19 14:03:49 <Ariadne> abuild-fetch uses curl(1)
2021-04-19 14:03:50 <ericonr> it didn't work in normal mode but worked in verbose mode
2021-04-19 14:04:10 <Ariadne> anyway
2021-04-19 14:04:13 <ericonr> well, I expect some weird mirror could also trigger it
2021-04-19 14:04:17 <Ariadne> maybe we should collaborate on a libfetch fork
2021-04-19 14:04:18 <Ariadne> :p
2021-04-19 14:04:31 <ericonr> it seems everyone has a libfetch fork
2021-04-19 14:04:45 <ericonr> the netbsd and freebsd version are quite different :/
2021-04-19 14:05:54 <ericonr> but yes, more people working on a canonical version would be nice
2021-04-19 14:06:49 <ericonr> btw, that bug above is a logic one (not a missing workaround for weird hosts), though it's unlikely to ever be hit
2021-04-19 14:38:45 <PureTryOut[m]2> Can anyone explain to me why qml-asteroid is missing from ppc64le, even though the builder has moved on to other packages committed later?
2021-04-19 14:40:12 <Cogitri> PureTryOut[m]2: Seems like it's still building things in testing/
2021-04-19 14:40:27 <Cogitri> It'll only upload the entire changeset of testing/ once it's done building the entirety of testing/
2021-04-19 14:40:30 <PureTryOut[m]2> Right now yes but earlier it was idle and the package wasn't their either
2021-04-19 14:40:45 <PureTryOut[m]2> I asked about this about an hour ago as well and it was idle back then
2021-04-19 14:40:53 <Cogitri> Hum, maybe it didn't upload for some reason then - but I suppose ikke would now more about that
2021-04-19 14:41:13 <Cogitri> Weird that it was idle earlier though - I merged the openjdk bump yesterday
2021-04-19 14:41:15 <Cogitri> Maybe that was just a display bug (?)
2021-04-19 14:41:43 <PureTryOut[m]2> I guess it already finished the openjdk build?
2021-04-19 15:02:38 <PureTryOut[m]2> OpenJDK7 is failing on aarch64 btw
2021-04-19 15:18:00 <ikke> PureTryOut[m]2: qml-asteroids has not been built
2021-04-19 15:19:24 <Cogitri> OpenJDK7: > You must have autoconf 2.59 or later installed.
2021-04-19 15:19:26 <Cogitri> Wat
2021-04-19 15:19:42 <Cogitri> How does this happen now
2021-04-19 15:21:31 <ikke> autoconf policy:
2021-04-19 15:21:34 <ikke>   2.71-r0:
2021-04-19 15:21:49 <ikke> (37/244) Installing autoconf (2.71-r0)
2021-04-19 15:21:55 <ikke> so it's drunk
2021-04-19 15:22:41 <ikke> it seems ppc64le has not pulled the commits with qml-asteroid yet
2021-04-19 15:23:50 <ikke> PureTryOut[m]2: I expect it to be built after openjdk is finished
2021-04-19 15:27:52 <PureTryOut[m]2> Ok then b.p.o was bugged I guess
2021-04-19 15:45:02 <rahmanshaber[m]> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/bQyAKWBBWJpawHGYcExpDygR/message.txt >

2021-04-19 15:45:14 <skarnet> Ariadne, ericonr: curl can now be built against bearssl, so although it's still something big, depending on curl for fetching is doable now
2021-04-19 15:45:57 <ncopa> i puahsed autoconf 2.70 first, then upgraded int to 2.71
2021-04-19 15:46:00 <Ariadne> bearssl has all the same memory safety verification capabilities rust gives anyway, from T0
2021-04-19 15:46:01 <Ariadne> :p
2021-04-19 15:46:03 <ncopa> im working on openjdk7 now
2021-04-19 15:46:13 <Cogitri> Thanks
2021-04-19 15:47:13 <skarnet> Ariadne: T0 is only used in the X509 decoder engine though IIRC
2021-04-19 15:47:23 <Ariadne> skarnet: nope
2021-04-19 15:47:33 <maxice8> wait autoconf was upgraded ?
2021-04-19 15:47:45 <Ariadne> skarnet: it is used in the SSL engine too
2021-04-19 15:47:45 <skarnet> in parts of the TLS engine as well? I didn't look too deep inside
2021-04-19 15:47:50 <Ariadne> well, TLS
2021-04-19 15:48:01 <Ariadne> it seems to be used anywhere that memory safety needs to be verified :)
2021-04-19 15:48:14 <ncopa> yes, i upgraded it
2021-04-19 15:48:22 <skarnet> that's cool
2021-04-19 15:48:47 <ncopa> wanted to upgrade autoconf before we start bootstrap the 3.14 builders
2021-04-19 15:49:07 <ncopa> also need to tag new abuild release, but need to fix the abuild-fetch problem first
2021-04-19 15:49:23 <skarnet> to me the killer feature is "zero malloc, all the engine is in the stack" though
2021-04-19 15:49:42 <skarnet> because buffer overflows are easier to avoid than memory leaks
2021-04-19 15:49:48 <mps> yes, bearssl looks good
2021-04-19 15:50:22 <Ariadne> sure, i'm just saying that bearssl checks the box that some ask about rustls for
2021-04-19 15:50:31 <skarnet> well if it even has mps's approval then it's awesome, confirmed :P
2021-04-19 15:50:40 <ikke> :D
2021-04-19 15:50:45 <Ariadne> rustls is, incidentally, not something i want to deal with
2021-04-19 15:50:56 <ikke> We should make a mps seal of approval ;-)
2021-04-19 15:51:04 <Ariadne> literally, it is the ASM crypto code from openssl, wrapped in rust
2021-04-19 15:51:15 <Ariadne> so basically the exact opposite of what i want :P
2021-04-19 15:51:21 <skarnet> Ariadne: the more you say "rust" the more I want to run away
2021-04-19 15:51:30 <skarnet> can we please talk about *good* software
2021-04-19 15:51:35 <Ariadne> skarnet: i'm okay with using rust where it makes sense
2021-04-19 15:51:45 <mps> it's a pity I don't have time to deep learn all about bearssl
2021-04-19 15:51:47 <jvoisin> to rust away
2021-04-19 15:51:48 <skarnet> yeah, to write browsers :P
2021-04-19 15:52:34 <skarnet> ikke: only if it makes seal noises *oink*
2021-04-19 15:52:43 <skarnet> oink is pigs, what does the seal say?
2021-04-19 15:52:43 <mps> huh, CI don't know about remake https://gitlab.alpinelinux.org/mps/aports/-/jobs/375143#L97
2021-04-19 15:53:03 <ikke> mps: it's still in testing
2021-04-19 15:53:15 <ikke> so community packages cannot depend on it
2021-04-19 15:53:20 <mps> can I ask removal of skarnet from this channel
2021-04-19 15:53:28 <ikke> You can always ask
2021-04-19 15:53:37 <mps> then do this
2021-04-19 15:53:53 <skarnet> mps doesn't like seals? but they're cute :(
2021-04-19 15:54:00 <dalias> <Ariadne> literally, it is the ASM crypto code from openssl, wrapped in rust
2021-04-19 15:54:04 <dalias> lol
2021-04-19 15:54:12 <dalias> i hate how that happens
2021-04-19 15:54:15 <skarnet> "safety"
2021-04-19 15:54:16 <Ariadne> dalias: yes this makes it somehow memory safe
2021-04-19 15:54:20 <dalias> new lang, exciting for safety...
2021-04-19 15:54:22 <Ariadne> dalias: no, i don't get it either
2021-04-19 15:54:32 <dalias> then all the actual libraries you have to use are FFI to existing known-shitty C
2021-04-19 15:54:51 <Ariadne> i did a call with a rustls person last week
2021-04-19 15:54:55 <Ariadne> and i was like
2021-04-19 15:54:57 <dalias> this was going on with ocaml ~7 years ago
2021-04-19 15:55:06 <Ariadne> "but it's just wrapping the openssl ASM code"
2021-04-19 15:55:11 <dalias> "crypto in ocaml!"
2021-04-19 15:55:30 <dalias> "no, actually only the high level logic is in ocaml. all the primitives are the same shitty C+asm"
2021-04-19 15:55:41 <Ariadne> <them> well the high level TLS part is in rust!
2021-04-19 15:55:51 <Ariadne> yeah that's the boring part
2021-04-19 15:55:57 <dalias> not really
2021-04-19 15:56:22 <dalias> the high level part is the part that's not trivially memory safe
2021-04-19 15:56:32 <Ariadne> true
2021-04-19 15:56:45 <dalias> the asm doesn't deal with any object lifetimes
2021-04-19 15:56:54 <dalias> it's just "input buffer here, output buffer there"
2021-04-19 15:57:11 <skarnet> I suspect a Rust X509 parser is just as ugly as a C one :P
2021-04-19 15:57:16 <dalias> you could even make a model for rust to prove its memory safety, i suspect
2021-04-19 15:57:24 <Ariadne> skarnet: i think a rust X509 parser can be done cleanly
2021-04-19 15:57:39 <Ariadne> i wrote one in elixir, which is another ML-like
2021-04-19 15:57:43 <Ariadne> it was not too bad
2021-04-19 15:57:44 <skarnet> Ariadne: yes, write a Rust backend for T0
2021-04-19 15:57:44 <dalias> as much as i criticize it i'm actually rather excited about the possibilities of rust
2021-04-19 15:57:56 <dalias> i'd really love to see it not suck
2021-04-19 15:58:05 <Ariadne> dalias: working on it
2021-04-19 15:58:15 <ncopa> im worried about the no-stable-ABI part
2021-04-19 15:58:18 <dalias> just found out about the "stdlib assumes malloc can't fail" bs and *facepalm*
2021-04-19 15:58:26 <dalias> but i think it's fixable
2021-04-19 15:58:47 <Ariadne> ncopa: i have some ideas on how we can solve that
2021-04-19 15:58:58 <dalias> ncopa, i'm not so worried about ABI because i'd like to *get rid of* ABI (unnecessary shared library boundaries) as much as possible
2021-04-19 15:59:13 <dalias> ideally most things can be static linked
2021-04-19 15:59:29 <Ariadne> dalias: unfortunately dynamically linked crates is the only way we can slim things down
2021-04-19 15:59:44 <Ariadne> static linked hello world is like 700KB
2021-04-19 15:59:52 <Ariadne> without dynamic linked crates
2021-04-19 15:59:57 <skarnet> that's exactly why I hate giant runtimes
2021-04-19 15:59:58 <dalias> yeah but that's a linking bug in rust
2021-04-19 16:00:09 <dalias> or in their stdlib implementation
2021-04-19 16:00:11 <ncopa> dynamic libs is the only way that security fixes wil actually be fixed
2021-04-19 16:00:14 <Ariadne> librsvg is 9MB
2021-04-19 16:00:19 <Ariadne> because rust
2021-04-19 16:00:21 <Ariadne> :D
2021-04-19 16:00:22 <dalias> ncopa, that's an old myth
2021-04-19 16:00:32 <Ariadne> its not
2021-04-19 16:00:37 <skarnet> ncopa: security bugs in Rust? that can't possibly happen, didn't you get the memo? Rust is SAFE
2021-04-19 16:00:59 <dalias> if you have a package system that documents dependencies you can just fix all the packages depending on the insecure lib, automatically
2021-04-19 16:01:01 <Ariadne> we wont rebuild 20k packages that depend on musl because it gets a CVE
2021-04-19 16:01:26 <Ariadne> yes, we can automatically set up the rebuilds
2021-04-19 16:01:27 <mps> ok, I revoke request of skarnet removal
2021-04-19 16:01:30 <dalias> ariadne, you wouldnt have to tho
2021-04-19 16:01:34 <Ariadne> we do not want that :p
2021-04-19 16:02:02 <dalias> say there's a CVE in wcsnrtombs
2021-04-19 16:02:16 <dalias> you rebuild the one package that used it :-p
2021-04-19 16:02:28 <Ariadne> yeah our tools arent that smart
2021-04-19 16:02:29 <Ariadne> :p
2021-04-19 16:02:43 <ncopa> this Arch guy, did a check on the status of go apps, for known cves in go
2021-04-19 16:02:54 <Ariadne> haha :D
2021-04-19 16:02:55 <skarnet> ah yes, let's maintain a list of every libc entry point that every package uses
2021-04-19 16:03:00 <skarnet> I can't see any drawback to that
2021-04-19 16:03:04 <dalias> skarnet, you don't have to do it manually
2021-04-19 16:03:12 <ncopa> and checked how many of the apps was rebuild with the fixed go. the numbers was depressing
2021-04-19 16:03:21 <dalias> ncopa, lol :)
2021-04-19 16:03:54 <dalias> anyway even if you do static linking to libc and system libs, i think dynamic-linked crates are probably a bad idea
2021-04-19 16:03:55 <ncopa> so, while, yes, it is theoretically possible to solve the issue, but in practice that does not happen
2021-04-19 16:04:17 <dalias> except possibly for ones that really are major shared functionality with stable API/ABI and need for upgrades
2021-04-19 16:04:25 <dalias> sorry
2021-04-19 16:04:27 <dalias> i meant
2021-04-19 16:04:33 <dalias> anyway even if you do dynamic linking to libc and system libs, i think dynamic-linked crates are probably a bad idea
2021-04-19 16:04:44 <wdtTP2O82Kft> you have a link to this arch guys effort/report?
2021-04-19 16:04:45 <ncopa> and rebuilding 1000 packages every time there is a security vulnerability will likely not happen in practice
2021-04-19 16:04:53 <ncopa> it was on twitter
2021-04-19 16:04:53 <Ariadne> dalias: its mainly libstd i want to link dynamically :p
2021-04-19 16:05:03 <dalias> ariadne, i think that's fairly reasonable
2021-04-19 16:05:08 <ncopa> and it was not very scientific. just a check
2021-04-19 16:05:30 <Ariadne> dalias: the microdeps i think are not a big deal
2021-04-19 16:05:44 <dalias> making shared libs out of the microdeps sounds liek an awful idea
2021-04-19 16:05:51 <dalias> especially if they're not designed to do that upstream
2021-04-19 16:05:57 <Ariadne> precisely
2021-04-19 16:06:36 <dalias> btw, personally i've started building everything i build by hand as static-linked now
2021-04-19 16:06:45 <wdtTP2O82Kft> btw https://github.com/mitls/mitls-curl - should be safe, it's formally verified...
2021-04-19 16:06:50 <dalias> because alpine keeps breaking shared libs (removing old soname when new version is released, etc :-p)
2021-04-19 16:07:29 <ncopa> wdtTP2O82Kft: https://twitter.com/MortenLinderud/status/1363785029957152769
2021-04-19 16:07:34 <Cogitri> Having shared libs/std wouldn't necessarily fix CVEs if the vulnerable function is generic though
2021-04-19 16:07:47 <wdtTP2O82Kft> thanks ncopa!
2021-04-19 16:08:01 <Cogitri> Then you'd have to rebuild the package anyway since the implementation was copy/pasted into the final application (like with C++ templates)
2021-04-19 16:08:16 <dalias> cogitri, indeed. there always *will* be potential scenarios where you have to rebuild 10000 packages to fix a cve
2021-04-19 16:08:32 <dalias> like if the compiler has a codegen bug that introduces vulns in everything (or a backdoor :)
2021-04-19 16:08:33 <Ariadne> Cogitri: that's not why
2021-04-19 16:08:38 <ncopa> yes, so the problem is that sable ABI alone will not solve the problem
2021-04-19 16:08:48 <ncopa> thats why im saying that it worries me
2021-04-19 16:08:49 <dalias> this is true even now
2021-04-19 16:09:16 <dalias> if you built the whole system with gcc 11.1 and found out gcc 11.1 introduces wrong codegen that bypasses a certain type of range check...
2021-04-19 16:09:22 <dalias> you'd have to rebuild the whole system
2021-04-19 16:09:32 <ncopa> yup. and that does not happen in practice
2021-04-19 16:09:49 <dalias> things almost that bad have happened
2021-04-19 16:09:57 <dalias> with wrong codegen bugs
2021-04-19 16:10:13 <ncopa> i mean, the rebuild of the world does not happe
2021-04-19 16:10:24 <dalias> :(
2021-04-19 16:10:27 <skarnet> we clearly need to do codegen at run time to avoid rebuilds because of compiler bugs
2021-04-19 16:10:32 <dalias> lol
2021-04-19 16:10:41 <ncopa> :)
2021-04-19 16:10:52 <Ariadne> Cogitri: the reason why i want dynamic std crate is to cut down the install sizes of rust dependencies
2021-04-19 16:11:01 <Ariadne> that's it
2021-04-19 16:11:01 <dalias> just interpret and you can dynamically replace the interpreter if there's a bug :)
2021-04-19 16:11:03 <Ariadne> that's all
2021-04-19 16:11:05 <Ariadne> :p
2021-04-19 16:11:16 <ikke> Something like that should also be possible for go, right?
2021-04-19 16:11:25 <Ariadne> no idea
2021-04-19 16:11:27 <Ariadne> probably not
2021-04-19 16:11:31 <ikke> I see references to shared linking
2021-04-19 16:11:32 <Cogitri> Ariadne: Ah, that's fair, but I wonder how much of an impact it makes when LTO and generics are a thing
2021-04-19 16:11:33 <ncopa> go has same problem, also link static
2021-04-19 16:11:34 <ikke> in the help
2021-04-19 16:11:36 <Ariadne> the go people hate shared linking
2021-04-19 16:11:48 <ncopa> people of rust hate shared linking
2021-04-19 16:11:51 <Ariadne> Cogitri: LTO hello world is still 600kb
2021-04-19 16:12:05 <Ariadne> Cogitri: dynamic libstd hello world is 17kb (C version is 14kb)
2021-04-19 16:12:39 <ikke> go build -linkshared
2021-04-19 16:12:45 <Ariadne> fascinating
2021-04-19 16:12:50 <ikke> go build -buildmode=shared
2021-04-19 16:12:50 <Ariadne> we should do it then
2021-04-19 16:13:39 <Ariadne> i would like to see more alpine tools written in rust/go/etc :)
2021-04-19 16:13:49 <ncopa> i think swift is interesting https://gankra.github.io/blah/swift-abi/
2021-04-19 16:13:55 <Ariadne> mainly because its easier to not shoot yourself in the foot with these languages
2021-04-19 16:13:59 <Cogitri> Ariadne: Sure, but a hello-world isn't really a reallife example
2021-04-19 16:14:00 <ncopa> yeah, me too
2021-04-19 16:14:16 <Ariadne> Cogitri: ifupdown-ng is 61KB
2021-04-19 16:14:23 <ncopa> i'd like a go library for parsing apkindex, apkbuilds etc
2021-04-19 16:14:26 <dalias> cogitri, there's plenty of real-life code that should be <100k or even <50k
2021-04-19 16:14:27 <Ariadne> Cogitri: the rust version would still be 10x larger
2021-04-19 16:14:38 <dalias> making each of those binaries 700k is awful
2021-04-19 16:14:40 <halosghost> ncopa: is there a C library for that?
2021-04-19 16:14:43 <Ariadne> ^^^^
2021-04-19 16:14:51 <dalias> especially since all the duplicated code will be resident in memory in multiple instances
2021-04-19 16:14:54 <dalias> evicting stuff you want
2021-04-19 16:14:59 <ncopa> halosghost: not really, but there is Lua
2021-04-19 16:15:04 <halosghost> ooh
2021-04-19 16:15:16 <halosghost> 
ACTION wants moar lua in the world

2021-04-19 16:15:27 <ncopa> i started to write an APKBUILD parser in C that spit out json
2021-04-19 16:15:30 <skarnet> minimal: what is paths.h ?
2021-04-19 16:15:30 <ncopa> but that stalled
2021-04-19 16:15:32 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/go
2021-04-19 16:15:33 <wdtTP2O82Kft> hey, don't forget zig. quite exciting without the c++ aftertaste
2021-04-19 16:15:35 <Hello71> i wonder how well (poorly) ksm works vs overly static linked binaries
2021-04-19 16:15:36 <Cogitri> dalias: Sure, but a usual Rust app would use  generics whereas a hello world doesn't
2021-04-19 16:15:48 <halosghost> wdtTP2O82Kft: I loved where zig started; I should take another look at it
2021-04-19 16:15:53 <ikke> https://gitlab.alpinelinux.org/alpine/go/-/tree/add-apkindex
2021-04-19 16:16:03 <Hello71> i guess it requires the code to be aligned properly
2021-04-19 16:16:10 <Ariadne> wdtTP2O82Kft: 5 minutes ago you suggested a TLS implementation which requires .NET :)
2021-04-19 16:16:11 <wdtTP2O82Kft> i actually have a server that i run in production, that i wrote in zig
2021-04-19 16:16:18 <halosghost> I wonder if anyone is working on making frama-c work with zig…
2021-04-19 16:16:24 <ncopa> ikke: nice!
2021-04-19 16:16:25 <Hello71> although didn't someone say that aix does that nonsense
2021-04-19 16:17:16 <Ariadne> Cogitri: there is still significant code reduction
2021-04-19 16:17:26 <Ariadne> by the way, anyone here who wants to rewrite alpine in rust
2021-04-19 16:17:31 <wdtTP2O82Kft> Ariadne: i thoght that mitls-curl is c-only, they output c code from their f# model.
2021-04-19 16:17:31 <ncopa> my thinking is that C isn't really going anywhere, even if there are those modern C-replacement languages
2021-04-19 16:17:32 <Ariadne> this is something you are REQUIRED to solve
2021-04-19 16:17:59 <Ariadne> "why not use uutils to replace busybox" somebody asked
2021-04-19 16:18:05 <ncopa> heh
2021-04-19 16:18:07 <Ariadne> and the answer is simple
2021-04-19 16:18:13 <Ariadne> it would belike 15MB binary
2021-04-19 16:18:14 <ncopa> it'd be 100MB
2021-04-19 16:18:28 <Cogitri> ncopa: Yes, if only because C works really nicely for dynamic linking
2021-04-19 16:18:29 <ikke> uutils is rust?
2021-04-19 16:18:32 <Cogitri> Yup
2021-04-19 16:18:45 <skarnet> writing such low-level utilities in Rust is also nonsensical
2021-04-19 16:18:56 <Ariadne> skarnet: not sure i agree
2021-04-19 16:19:01 <Ariadne> i see benefits to it
2021-04-19 16:19:06 <skarnet> we don't have to agree on everything
2021-04-19 16:19:18 <minimal> skarnet: its from musl-dev package
2021-04-19 16:19:36 <skarnet> my position is that C is *the* language for low-level utilities, and Rust has a place, but a bit higher in the food chain
2021-04-19 16:19:52 <skarnet> minimal: thanks, let me check
2021-04-19 16:19:54 <ncopa> they are pushing for rust in the linux kernel
2021-04-19 16:20:02 <wdtTP2O82Kft> yeah, rewriting tools in rust that have the threatmodel of calc.exe, claiming doing it for safety is nonsense
2021-04-19 16:20:05 <Ariadne> skarnet: i think there is a lot of value to teaching people to write C to MISRA standard
2021-04-19 16:20:27 <ikke> are there good / free references for the MISRA standard?
2021-04-19 16:21:41 <skarnet> dalias: is musl's /usr/include/paths.h meant to emulate what glibc does, or is it like your bits/alltypes.h to centralize definitions?
2021-04-19 16:21:49 <minimal> skarnet: as musl doesn't support utmp/utmpx it defined "dummy" values for utmp/wtmp files there
2021-04-19 16:22:11 <skarnet> minimal: yes, I understand that, I'm just wondering about the nonstandard header file
2021-04-19 16:22:41 <skarnet> because there should be zero reason for applications to ever include <paths.h> directly
2021-04-19 16:22:56 <skarnet> and am wondering whether patching busybox to remove that is the correct fix
2021-04-19 16:23:14 <mps> ikke: https://misra.org.uk/Publications/tabid/57/Default.aspx
2021-04-19 16:23:33 <ikke> mps: thanks
2021-04-19 16:23:35 <Ariadne> ikke: yes, cppcheck, clang-analyzer and gcc 11 -fanalyzer will all warn about MISRA violations
2021-04-19 16:24:45 <minimal> skarnet: busybox certainly use a "#include <paths.h>" and I'm sure I've seen at least one other package do that (to get non-utmp-related defines)
2021-04-19 16:25:47 <skarnet> I suspect that's something to be fixed but I'm waiting for dalias's confirmation
2021-04-19 16:26:24 <skarnet> ikke: the link you want is https://misra.org.uk/LinkClick.aspx?fileticket=vfArSqzP1d0%3d&tabid=57
2021-04-19 16:26:47 <skarnet> finding it in the list of publications is ugh
2021-04-19 16:26:52 <ikke> yeah, thanks
2021-04-19 16:27:29 <minimal> skarnet: coreutils, linux-pam, openrc, shadow, and util-linux all reference paths.h
2021-04-19 16:28:11 <skarnet> all famous paragons of good C
2021-04-19 16:28:19 <skarnet> but I guess it's a de facto standard
2021-04-19 16:28:44 <skarnet> I'll modify utmps to work around it then
2021-04-19 16:29:31 <Ariadne> skarnet: all on my list to kill
2021-04-19 16:29:33 <Ariadne> :)
2021-04-19 16:29:43 <skarnet> ah, no, that's annoying, I can't redefine it because then it makes the #include order change things
2021-04-19 16:29:53 <PureTryOut[m]2> 
ACTION uploaded an image: (1KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/iiZkTiPxGdvHxqPtjPFxEZRW/Screenshot_20210419_182947.png >

2021-04-19 16:30:04 <PureTryOut[m]2> Can someone please remove that white pixel from the favicon of Gitlab?
2021-04-19 16:30:12 <Ariadne> no
2021-04-19 16:30:15 <minimal> skarnet: of all of those busybox is the only one I'm (currently) having the duplicate defines issues with
2021-04-19 16:30:16 <skarnet> the problem is that utmp definitions should be confined to <utmp.h> and <utmpx.h>, not spread around in generic headers
2021-04-19 16:30:17 <Ariadne> like literally
2021-04-19 16:30:18 <PureTryOut[m]2> It has been bothering the living hell out of me all day
2021-04-19 16:30:22 <Ariadne> it is impossible
2021-04-19 16:30:29 <Ariadne> gitlab itself is putting it there
2021-04-19 16:30:30 <Ariadne> :/
2021-04-19 16:30:32 <PureTryOut[m]2> How is that impossible lol
2021-04-19 16:30:33 <ikke> PureTryOut[m]2: hmm, does not show up for me
2021-04-19 16:30:41 <PureTryOut[m]2> It still retrieves it from somewhere
2021-04-19 16:30:53 <Ariadne> gitlab has JS
2021-04-19 16:30:59 <Ariadne> which regenerates the favicon
2021-04-19 16:31:02 <wdtTP2O82Kft> oh, mitls-curl indeed depends on an external mitls install. meh. sorry for bringing it up.
2021-04-19 16:31:04 <Ariadne> its a bug in gitlab
2021-04-19 16:31:11 <skarnet> I have 2 tabs on gitlab, one with the white pixel, the other one without it
2021-04-19 16:31:27 <PureTryOut[m]2> 😢
2021-04-19 16:31:57 <PureTryOut[m]2> Oh refreshing the tab made it dissapear. But I guess it'll be back then
2021-04-19 16:32:15 <ikke> PureTryOut[m]2: Probably has to do with things like notifications / new comments
2021-04-19 16:32:18 <Ariadne> ^
2021-04-19 16:32:40 <Ariadne> yes go complain to gitlab
2021-04-19 16:32:42 <Ariadne> :D
2021-04-19 16:32:47 <PureTryOut[m]2> That would be one shitty way to show it
2021-04-19 16:32:57 <PureTryOut[m]2> If it stays like this I will haha
2021-04-19 16:32:59 <skarnet> minimal: the issue is that utmps needs to redefine the path to wtmp, it's doable in utmps/utmpx.h, but it's not doable if the musl definition is in paths.h
2021-04-19 16:33:02 <PureTryOut[m]2> I can not work like this!
2021-04-19 16:35:54 <Ariadne> mps: i can move remake to community or something
2021-04-19 16:36:07 <minimal> skarnet: yeah I was surprised to see musl putting UTMP and WTMP defs in paths.h rather than /usr/include/utmp.h - I'm guessing that musl did this to handle some software that included paths.h but not utmp.h and expected those defines.
2021-04-19 16:36:21 <Ariadne> mps: i wasn't planning to move it from testing until 3.14 was branched
2021-04-19 16:36:22 <mps> btw, MISRA is not something special, that I how I learned C 30 years ago
2021-04-19 16:36:39 <Ariadne> oh yeah misra isn't anything special at all
2021-04-19 16:36:50 <mps> Ariadne: ok, I will revert to make
2021-04-19 16:37:21 <Ariadne> my plan was just to replace make with remake in main after 3.14 is branched
2021-04-19 16:37:38 <mps> remake will not fix bug in edk2 anyway :)
2021-04-19 16:38:09 <skarnet> minimal: yeah, and now I probably need to just remove the definition of _PATH_UTMP and _PATH_WTMP in utmps/utmpx.h, but software that links against utmps should just never use those macros
2021-04-19 16:38:16 <skarnet> because the paths.h values will be incorrect
2021-04-19 16:38:32 <skarnet> the only legit macro is WTMPX_FILE
2021-04-19 16:38:45 <skarnet> and we probably should patch busybox so it uses that instead
2021-04-19 16:38:57 <Ariadne> of course not, the benefit of remake is having actually useful error output (as long as the build system doesn't clobber the jobserver anyway)
2021-04-19 16:40:46 <mps> Ariadne: right, but anyway thanks for pointing to it, it will be useful for local testing builds
2021-04-19 16:40:58 <minimal> skarnet: I thought about patching busybox for that. Whatever changes you decide to make to utmps may well change build behaviour for the other packages using paths.h/utmp.h/utmpx.h so I'd have to then rebuild those to see what, if anything, may change and need fixed. Down the rabbithole we go.....lol
2021-04-19 16:41:31 <skarnet> oh wait actually _PATH stuff is only is Ariadne's utmp.h addition
2021-04-19 16:42:05 <skarnet> yeah the real fix is to patch bb so it doesn't use utmp.h
2021-04-19 16:42:13 <skarnet> make it use utmpx.h instead
2021-04-19 16:42:30 <skarnet> and WTMP_FILE instead of _PATH_WTMP
2021-04-19 16:44:25 <skarnet> alternatively just remove the paths.h inclusion... probably less effort. And there's no perfect solution anyway.
2021-04-19 16:46:10 <Hello71> Ariadne: does that work with recursive make?
2021-04-19 16:46:39 <minimal> skarnet: and what about the file defines in paths.h pointing to the wrong place?
2021-04-19 16:46:40 <Ariadne> Hello71: yes, as long as the jobserver doesn't get clobbered
2021-04-19 16:46:41 <Hello71> particularly thinking of kbuild/openjdk where the error is frequently hundreds or thousands of lines up
2021-04-19 16:46:54 <Ariadne> Hello71: yes, it works for those
2021-04-19 16:47:02 <Hello71> hm, ok
2021-04-19 16:47:15 <Hello71> not sure i understand how but i'll take your word for it
2021-04-19 16:47:22 <skarnet> minimal: as long as the software doesn't include paths.h we don't care
2021-04-19 16:47:29 <Ariadne> Hello71: gnu make has a "job server"
2021-04-19 16:47:36 <Hello71> yes
2021-04-19 16:47:43 <Hello71> the thing with the pipes
2021-04-19 16:48:09 <skarnet> minimal: again the *only* thing we need with those paths is to give clients read access to wtmp
2021-04-19 16:48:11 <Hello71> (that hangs half the time when i use make -l, but that's a seprate issue)
2021-04-19 16:48:12 <Ariadne> Hello71: the job server is extended in remake to know about the origin of every job
2021-04-19 16:48:48 <skarnet> minimal: so _PATH_UTMP is totally irrelevant (and software that uses it should be fixed anyway to stop accessing the file directly) and _PATH_WTMP should be patched into WTMPX_FILE
2021-04-19 16:48:54 <Hello71> but how does it pass up the error
2021-04-19 16:48:59 <Hello71> or does it not actually print the error at the end
2021-04-19 16:49:08 <Ariadne> it does, at the end
2021-04-19 16:49:15 <minimal> skarnet: and software that needs to include paths.h for other defines in there?
2021-04-19 16:49:19 <Hello71> right, i see how you can have a proper backtrace
2021-04-19 16:49:27 <Hello71> but how does it move the error to the end
2021-04-19 16:49:41 <skarnet> minimal: then they need to be checked for _PATH_[UW]TMP use, and patched if necessary
2021-04-19 16:49:46 <Hello71> ninja-like buffering?
2021-04-19 16:49:55 <skarnet> if they don't use them, it's fine
2021-04-19 16:49:58 <Ariadne> idk i haven't looked into it too deeply
2021-04-19 16:50:06 <Ariadne> i just know the jobserver tracks the errors
2021-04-19 16:50:46 <Ariadne> perhaps it uses socketpairs instead of pipes :)
2021-04-19 16:51:23 <Hello71> hm, i guess it necessarily buffers the errors, or at least does a tee
2021-04-19 16:52:15 <Ariadne> it would buffer the errors
2021-04-19 16:52:25 <Ariadne> but they could be communicated via socketpair back to the jobserver
2021-04-19 16:52:34 <Ariadne> its pretty straightforward really
2021-04-19 16:52:39 <Hello71> mm.
2021-04-19 16:53:01 <Ariadne> then when jobserver terminates, errors are printed
2021-04-19 16:53:18 <Ariadne> Hello71: note, it does not capture the *compiler* error
2021-04-19 16:53:24 <Hello71> oh
2021-04-19 16:53:27 <skarnet> minimal: I pushed the WTMP_FILE change in !20619, please approve when you're done and I'll remove the draft tag so it can be merged
2021-04-19 16:53:32 <Ariadne> yeah, sorry it's not that good :p
2021-04-19 16:53:34 <Hello71> i think i misread your screenshot earlier
2021-04-19 16:53:44 <Hello71> iirc ninja can do that
2021-04-19 16:53:49 <Hello71> or maybe it's meson
2021-04-19 16:54:07 <Ariadne> ninja and samurai can do that yes
2021-04-19 16:54:45 <Ariadne> Hello71: however, even though it does not capture compiler error output, it is still useful
2021-04-19 16:54:48 <minimal> skarnet: having a look now
2021-04-19 16:54:56 <Hello71> yes
2021-04-19 16:54:59 <Ariadne> Hello71: because you can just check the backtrace at the end
2021-04-19 16:55:07 <Ariadne> and go
2021-04-19 16:55:21 <Ariadne> oh arch/x86_64/whatever.o failed to compile
2021-04-19 16:55:38 <Ariadne> which on its own doesnt tell you much, but then you can retry it
2021-04-19 16:55:45 <Ariadne> the cool thing is
2021-04-19 16:56:01 <Ariadne> you can have remake actually retry the failed job at the end
2021-04-19 16:56:10 <Ariadne> which *does* get you compiler output
2021-04-19 16:58:11 <Hello71> only if it properly restores all the context
2021-04-19 16:58:32 <Hello71> given the number of makefiles that break with just -j2, i'm not optimistic :p
2021-04-19 16:58:56 <Ariadne> you can also do
2021-04-19 16:59:00 <Ariadne> make --post-mortem
2021-04-19 16:59:14 <Ariadne> and when there's an error, instead of just terminating
2021-04-19 16:59:25 <Ariadne> you can inspect the make engine's state at the moment of the job failure
2021-04-19 16:59:38 <Ariadne> it has a debugger :D
2021-04-19 16:59:55 <Hello71> mm.
2021-04-19 17:00:12 <Hello71> is it time for APKBUILD sh -> make conversion? :p
2021-04-19 17:00:28 <ikke> :D
2021-04-19 17:00:34 <ikke> full circle
2021-04-19 17:01:16 <Ariadne> lets not and say we didn't
2021-04-19 17:01:26 <Hello71> imho even though makefile is a little clunky, the issue is that gnu make debugging sucks
2021-04-19 17:01:35 <Ariadne> yes
2021-04-19 17:01:41 <Ariadne> remake fixes *that* problem
2021-04-19 17:01:43 <Ariadne> :p
2021-04-19 17:03:27 <maxice8> Hello71: APKBUILD.spec
2021-04-19 17:03:44 <Ariadne> can we ban maxice8 pls
2021-04-19 17:03:57 <maxice8> ok
2021-04-19 17:04:02 <Ariadne> im kidding
2021-04-19 17:04:04 <Ariadne> ^_^
2021-04-19 17:04:13 <ikke> /mode +b maxice8
2021-04-19 17:04:31 <Hello71> ono
2021-04-19 17:04:42 <dalias> skarnet, paths.h is just a junk header that was included because some stuff used it.
2021-04-19 17:04:48 <dalias> musl does not use it whatsoever
2021-04-19 17:05:08 <Hello71> does remake parse faster than gnu make? i remember waiting several seconds for buildroot to just parse
2021-04-19 17:05:17 <dalias> in particular it's not a source of configuration or policy
2021-04-19 17:05:29 <Ariadne> Hello71: no,
2021-04-19 17:05:38 <skarnet> dalias: yeah that's what I suspected, the problem is that it contains utmp macros outside of utmp.h and utmpx.h so those macros are pretty hard to redefine
2021-04-19 17:05:44 <Ariadne> i mean i haven't benchmarked it
2021-04-19 17:05:51 <dalias> skarnet, i see...
2021-04-19 17:05:53 <Ariadne> but i doubt there is any difference in parsing speed
2021-04-19 17:05:55 <Hello71> just because of macros on macros on macros on includes on macros
2021-04-19 17:06:02 <dalias> i would just have alpine patch musl's paths.h to match the utmp policy
2021-04-19 17:06:25 <Ariadne> we can do that
2021-04-19 17:06:32 <Ariadne> what should it have ?
2021-04-19 17:06:43 <skarnet> _PATH_WTMP should be /var/log/wtmp
2021-04-19 17:06:44 <skarnet> and that's it
2021-04-19 17:06:55 <dalias> paths.h has lots of stuff in it that's "policy content" and not policy that libc really has any care over
2021-04-19 17:07:06 <dalias> so it's totally reasonable for distros to change that if it conflicts
2021-04-19 17:07:27 <skarnet> _PATH_UTMP is totally irrelevant for utmps but the macro definition could be removed, to check for software that uses it and patch it
2021-04-19 17:07:42 <dalias> :)
2021-04-19 17:08:15 <Ariadne> ok
2021-04-19 17:08:28 <Ariadne> i don't want to do that right now since we are already in a soft freeze
2021-04-19 17:08:36 <Ariadne> can it wait until 3.14 is branched?
2021-04-19 17:08:39 <skarnet> totally
2021-04-19 17:09:02 <skarnet> minimal is working on building alpine with utmps, that's why we're looking at those things now
2021-04-19 17:09:02 <Ariadne> cool, ping me when we do that i guess :)
2021-04-19 17:09:14 <Ariadne> oh good
2021-04-19 17:09:19 <Ariadne> i am glad minimal is finishing it
2021-04-19 17:09:34 <skarnet> yeah I think we're pretty close
2021-04-19 17:09:36 <minimal> Ariadne: I'm the one who triggered this conversation as I'm testing utmp stuff locally. I can tested the suggested changes locally for now and once it all appears working we can look at them after 3.14
2021-04-19 17:09:55 <Ariadne> since i got busy with other things :p
2021-04-19 17:10:13 <Ariadne> minimal: i guess just open an MR against the musl package
2021-04-19 17:10:20 <skarnet> Ariadne: how come? it *never* happens to you. :P
2021-04-19 17:10:42 <minimal> Ariadne: I will once I'm sure it all works :-)
2021-04-19 17:11:07 <Ariadne> skarnet: i haven't perfected human cloning yet
2021-04-19 17:11:25 <skarnet> sheep cloning works and bunnies are smaller
2021-04-19 17:12:15 <Ariadne> bunnies clone themselves if they are not fixed
2021-04-19 17:13:01 <Ariadne> or at least if you have two bunnies, you'll wind up with 2^6 bunnies by the end of the month
2021-04-19 17:13:02 <Ariadne> :p
2021-04-19 17:13:42 <skarnet> we need to harness that wonderful food source
2021-04-19 17:13:48 <skarnet> 
ACTION exits, fast

2021-04-19 17:14:16 <Ariadne> the only bunnies i have are artificial
2021-04-19 17:14:24 <Ariadne> no food source here :)
2021-04-19 17:52:24 <nmeum> Ariadne: forking your alpine-gcc-patches on gitlab takes ages :D maybe it's quicker if you just git-am(1) my git-format-patch?
2021-04-19 17:53:21 <nmeum> > Forking in progress: Please wait while we import the repository for you.
2021-04-19 17:53:30 <nmeum> 💤
2021-04-19 17:53:42 <Ariadne> :D
2021-04-19 17:53:58 <Ariadne> no rush on it
2021-04-19 17:54:04 <Ariadne> just send me an MR when you can
2021-04-19 17:54:09 <Ariadne> so i don't lose the patch
2021-04-19 17:54:26 <Ariadne> because i rebase all the patches when i update to a new git snapshot
2021-04-19 17:55:15 <nmeum> yeah, I really like the idea of keeping larger patchsets in a dedicated repo. I do the same locally for busybox
2021-04-19 17:55:25 <nmeum> ok, gitlab is done forking
2021-04-19 18:01:14 <nmeum> done
2021-04-19 18:43:00 <mps> looks like armv7 CI is stuck
2021-04-19 19:44:09 <donoban> hi
2021-04-19 19:45:04 <donoban> I've just read it mps VfrCompile is part of edk2?
2021-04-19 19:50:18 <donoban> ey Cogitri , I thought that it is rare that packaged libvpx causes the link error because it is not include in APKBUILD, I take a look and it seems that there is a definition in a .asm file and other .c file
2021-04-19 19:52:01 <donoban> e.g. one duplicated reference is between and intrapred_neon.c.o intrapred_neon_asm.asm.S.o :S
2021-04-19 19:54:31 <mps> donoban: yes, it is built during build process
2021-04-19 19:54:59 <mps> donoban: here is new (upgrade to latest edk2) MR !20626
2021-04-19 19:55:19 <donoban> and it also fails? :D
2021-04-19 19:55:32 <mps> yes
2021-04-19 19:55:41 <donoban> hehe
2021-04-19 19:56:07 <mps> but this time because of illegal instruction
2021-04-19 19:58:27 <andypost[m]> any idea what caused 35% size cut "graphviz: 6944 KiB -> 4548 KiB"?  https://gitlab.alpinelinux.org/andypost/aports/-/jobs/375293#L6375
2021-04-19 20:02:29 <ikke> You'd have to compare the packages
2021-04-19 20:02:39 <ikke> there are no files missing (otherwise checkapk would have shown that)
2021-04-19 20:21:13 <ericonr> Ariadne: skarnet: rustls is a complete joke
2021-04-19 20:21:22 <ericonr> it only works on ARM, aarch64 and x86
2021-04-19 20:21:47 <ericonr> they don't carry almost any fallback code for archs not supported by the ASM that they import from BoringSSL
2021-04-19 20:23:34 <ericonr> which would have been a fine way of showing that Rust can be fast/portable, and to test asm impls vs a reference thing
2021-04-19 20:23:59 <ericonr> but no, any project using rustls is very limited on what it can even be built for
2021-04-19 20:28:03 <mcf> Ariadne: i've done bearssl ports for several packages using libcrypto. as ericonr said, the apis are close enough that it is usually pretty easy. coming up with a nice abstraction layer should be quite doable
2021-04-19 20:28:30 <mcf> the main gotcha for rsa with bearssl is that the private key decoder drops the public key parts, and can only recompute them for keys where p and q are 3 mod 4 (about 25% of keys i believe)
2021-04-19 20:34:12 <ericonr> ah, a correction
2021-04-19 20:34:23 <ericonr> rustls's limitations are due to ring
2021-04-19 20:34:28 <ericonr> which is the underlying crypto library
2021-04-19 20:34:57 <ericonr> rustls could in fact be entirely portable if there was any interest in a properly portable backend
2021-04-19 21:21:04 <andypost[m]> ikke: locally I see no difference, maybe some settings in CI is different but on builders result is different https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20632#note_153298
2021-04-19 21:21:48 <ikke> You know you can download the package from ci?
2021-04-19 21:22:10 <andypost[m]> ah, thank you!
2021-04-19 22:55:51 <skarnet> !20619 can be merged now, thanks minimal :)
2021-04-20 00:40:26 <sh4rm4^bnc> hmm, did i just DOS git.al.org with my crappy connection ?
2021-04-20 00:43:06 <Ariadne> no
2021-04-20 00:43:14 <Ariadne> :)
2021-04-20 00:47:18 <sh4rm4^bnc> still getting 502's
2021-04-20 01:12:48 <Ariadne> [14:28:28] <mcf> the main gotcha for rsa with bearssl is that the private key decoder drops the public key parts, and can only recompute them for keys where p and q are 3 mod 4 (about 25% of keys i believe)
2021-04-20 01:12:49 <Ariadne> uhhh
2021-04-20 01:12:53 <Ariadne> that sounds bad?
2021-04-20 01:50:19 <mcf> well, when signing something with RSA, you only need the private key
2021-04-20 01:50:47 <skarnet> yeah you shouldn't even have a public key in an encoded private key file
2021-04-20 01:51:38 <mcf> i suppose the main issue for apk-tools is that there is no RSA public key decoder, it can only decode the public key from within a X.509 cert
2021-04-20 01:52:32 <skarnet> but where are public keys encoded if not in certs?
2021-04-20 01:53:15 <skarnet> oh, you mean for /etc/apk/keys which are not in a cert? those are RSA?
2021-04-20 01:57:53 <ericonr> mcf: yes, the lack of a decoder sucks; I actually sent an email to Pornin asking about adding that API, he answered with a guide on how to write one :)
2021-04-20 01:57:55 <mcf> yeah, i believe the public keys are just some inner ASN.1 structure, not certs (not sure exactly the format)
2021-04-20 01:58:08 <ericonr> I can forward it to you, in that case
2021-04-20 01:58:11 <ericonr> if you wish
2021-04-20 01:58:52 <mcf> sure, i'd be interested in that
2021-04-20 01:59:01 <ericonr> for that matter, the esp8061 arduino repo carries a bearssl fork for which they implemented an RSA decoder
2021-04-20 01:59:32 <ericonr> ugh
2021-04-20 01:59:42 <ericonr> esp8266
2021-04-20 02:06:42 <ericonr> mcf: https://github.com/esp8266/Arduino/tree/da6ec83b5fdbd5b02f04cf143dcf8e158a8cfd36/tools/sdk/ssl and https://github.com/esp8266/Arduino/tree/da6ec83b5fdbd5b02f04cf143dcf8e158a8cfd36/tools/sdk/ssl
2021-04-20 02:07:11 <ericonr> https://github.com/earlephilhower/bearssl-esp8266/commit/0c27e4145af5886156c4dfb59292ffbbd041e6c0
2021-04-20 02:07:33 <Ariadne> well anyway, that is certainly a blocker for using bearssl in apk-tools itself
2021-04-20 02:09:18 <skarnet> until someones write a public RSA key decoder :P
2021-04-20 02:11:13 <mcf> like the one ericonr just linked? :P
2021-04-20 02:11:20 <mcf> that would indeed be nice to see in upstream bearssl
2021-04-20 02:12:37 <ericonr> mcf: forwarded the guide your way as well
2021-04-20 02:13:18 <skarnet> did that guy actually take the time to understand T0 and write a decoder in it? o.O
2021-04-20 02:14:41 <skarnet> since the work since to already have been done there's a small chance pornin could upstream it
2021-04-20 02:14:45 <skarnet> I can try and press him
2021-04-20 02:14:51 <skarnet> since the work seems*
2021-04-20 02:16:21 <mcf> ericonr: thanks :) those in-depth replies from thomas pornin are always fantastic
2021-04-20 02:17:49 <skarnet> ericonr: can I please read it too?
2021-04-20 03:02:04 <ericonr> skarnet: query
2021-04-20 06:08:07 <rahmanshaber[m]> Please anyone review this MR
2021-04-20 06:08:08 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20638
2021-04-20 06:39:48 <indy> hi all, what is proper way to get some 'backport' from master (edge) to 3.13?
2021-04-20 06:40:41 <Cogitri> Make a branch based on 3.13-stable on your fork, cherry pick the commit you want to backport, make a MR against upstream/3.13-stable
2021-04-20 06:42:58 <Cogitri> b8d1f2ee7911 lol
2021-04-20 06:43:27 <Cogitri> https://git.alpinelinux.org/aports/commit/?id=b8d1f2ee7911 I guess that's one way to check for autoconf >= 2.59too :D
2021-04-20 06:51:31 <mps> hm, we have upgraded autoconf, probably some packages will need to be checked with it
2021-04-20 06:54:09 <Cogitri> If they have similarly (broken) tests for the version, yup
2021-04-20 06:59:01 <Cogitri> Fixing openjdk8 for the same thing now
2021-04-20 06:59:25 <ncopa> i think there are a number of packages that will break with new autoconf, but i also expect other distros to have patches
2021-04-20 07:01:23 <Ariadne> could always just package old autoconf
2021-04-20 07:01:26 <Ariadne> thats what freebsd do
2021-04-20 07:01:27 <Ariadne> :D
2021-04-20 07:03:07 <mps> new openssh pass !20640
2021-04-20 07:04:04 <indy> Cogitri, thanks - https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20641
2021-04-20 07:04:31 <mps> can someone else test it doesn't break login on remotes. It works for me but at least one test in different setup would be good before merge
2021-04-20 07:07:18 <Gottox> is someone with gnome 40 running on alpine here an can verify this issue? https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4148
2021-04-20 07:08:26 <Cogitri> Gottox: Sounds like https://gitlab.alpinelinux.org/alpine/aports/-/issues/12605
2021-04-20 07:10:16 <Gottox> Interesting. They marked it as a dup for a glibc issue.
2021-04-20 07:10:33 <Gottox> But I can't reproduce it here with similiar hardware.
2021-04-20 07:10:46 <Gottox> here = glibc
2021-04-20 07:13:45 <Cogitri> I don't have the problem on F34 Silverblue on my desktop either
2021-04-20 07:14:29 <Cogitri> On my laptop it sometimes likes to flash when I resume (as in I see the lock screen, then it goes black again and then after a few seconds it shows GDM again)
2021-04-20 08:20:06 <PureTryOut[m]2> Can abuild not create empty directories in packages?
2021-04-20 08:46:22 <PureTryOut[m]2> ppc64le seems to be stuck on openjdk16, I swear it was building it yesterday evening as well
2021-04-20 08:49:08 <mps> ncopa: regarding edk2, I create yet another MR (!20626) which is upgrade to latest upstream release, but also this fails but with different error than previous MR
2021-04-20 08:50:09 <mps> it fails with 'illegal instruction' when running one binary which is built during compiling
2021-04-20 08:51:28 <mps> we can create bug report on gitlab.a.o about this and post url to upstream on github
2021-04-20 08:52:00 <mps> I would do all this but I don't have GH account
2021-04-20 10:06:47 <donoban> hi
2021-04-20 10:06:52 <donoban> GH is GitHub?
2021-04-20 10:10:37 <mps> donoban: yes
2021-04-20 10:11:15 <mps> i.e. 'General Headquarter' of free software ;>
2021-04-20 10:11:22 <donoban> ok I can post it
2021-04-20 10:11:24 <donoban> hehe
2021-04-20 10:11:51 <donoban> " we can create bug report on gitlab.a.o", where is it?
2021-04-20 10:12:01 <Shiz> well there you go
2021-04-20 10:12:03 <Shiz> :p
2021-04-20 10:12:59 <mps> donoban: algitbot knoows some of $.a.o
2021-04-20 10:13:10 <donoban> yeah I see
2021-04-20 10:13:43 <donoban> I meant, is the bug report already opened?
2021-04-20 10:14:04 <mps> no, not yet
2021-04-20 10:21:57 <mps> donoban: I have to boot my x86_64 box to try build edk2 and collect all relevant info (even dmesg out) for filling bug report
2021-04-20 10:22:43 <mps> will do later today (don't use x86_64 much in last times)
2021-04-20 10:22:57 <donoban> ok ok
2021-04-20 10:23:11 <donoban> what is your main arch?
2021-04-20 10:23:48 <mps> arm64 and sometime arm32
2021-04-20 10:25:23 <donoban> I would have to consider when buying next computer, all my life in x86 ^^
2021-04-20 10:25:33 <mps> about 5 years ago I switched to arm for workstation
2021-04-20 10:27:09 <mps> though I used asus transfomer with dock with keyboard as a 'notebook' from about 10 years ago, with debian on it
2021-04-20 10:27:50 <mps> tf101 asus is also arm32
2021-04-20 10:29:31 <donoban> I'm happy with Lenovo Thinkpad :D
2021-04-20 10:31:32 <mps> I would like to use/have risc-V notebook designed as chromebooks are
2021-04-20 10:31:59 <mps> but that will not happen soon, I fear
2021-04-20 10:57:32 <PureTryOut[m]2> b.p.o is being weird recently. Right now it says it's building community/ceph on aarch64, but according to the build log it has already finished
2021-04-20 10:59:47 <ikke> well, it _is_ building ceph
2021-04-20 11:03:38 <PureTryOut[m]2> Huh but the log showed it was finished 🤔
2021-04-20 11:04:09 <PureTryOut[m]2> Oh actually no it didn't finish, it failed
2021-04-20 11:04:16 <PureTryOut[m]2> > No space left on device.
2021-04-20 11:04:19 <ikke> PureTryOut[m]2: one trick: it should end with "signing the index"
2021-04-20 11:04:20 <PureTryOut[m]2> That seems like an issue
2021-04-20 11:04:30 <ikke> if it does not end with that, it was not succesfully built
2021-04-20 11:04:37 <PureTryOut[m]2> Ok good to know
2021-04-20 11:04:45 <PureTryOut[m]2> So is the aarch64 builder out of space then?
2021-04-20 11:04:49 <ikke> no
2021-04-20 11:05:08 <ikke> at least, not the new builder :)
2021-04-20 11:05:11 <PureTryOut[m]2> I don't understand what is happening then...
2021-04-20 11:09:31 <PureTryOut[m]2> ikke: could you verify what's up with the aarch64 builder then? Something is definitely off
2021-04-20 11:10:13 <ikke> Sun, 18 Apr 2021 16:30:14 +0000
2021-04-20 11:10:21 <ikke> I think this is before ncopa move the builders
2021-04-20 11:11:14 <PureTryOut[m]2> So maybe b.p.o is just still looking at the old builder then?
2021-04-20 11:11:22 <ikke> no
2021-04-20 11:11:30 <ikke> it's the old log your are looking at
2021-04-20 11:11:51 <ikke> these logs are not updated live
2021-04-20 11:12:21 <PureTryOut[m]2> That I realize. But why does b.p.o still show it's building community/ceph then and link to some old log?
2021-04-20 11:12:57 <ikke> b.a.o just links to a predicted location for the log
2021-04-20 11:13:04 <ikke> right now, that location still has the old version
2021-04-20 11:13:15 <ikke> once the build is finished, the new version of the log will be uploaded
2021-04-20 11:13:22 <ikke> It's not a very smart system
2021-04-20 11:14:06 <PureTryOut[m]2> So because it failed earlier, it's now redoing the build but it still points to the log of the failed builed?
2021-04-20 11:14:09 <PureTryOut[m]2> *build
2021-04-20 11:14:12 <ikke> yes
2021-04-20 11:14:20 <PureTryOut[m]2> Ah, yes that's confusing
2021-04-20 11:21:52 <ikke> ncopa: found this nice overview about different types of locking in linux: https://gavv.github.io/articles/file-locks/
2021-04-20 11:30:11 <ncopa> ikke: im reading the manpage, and i think i know what the problem is
2021-04-20 11:32:26 <ncopa> nice overview btw
2021-04-20 12:04:37 <indy> can anybody please look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20641 ?
2021-04-20 12:11:57 <tmlind> mps: somehow we get this with emacs-nox: emacs: could not load dump file "/usr/lib/emacs/27.2/aarch64-alpine-linux-musl/emacs.pdmp": out of memory
2021-04-20 12:12:21 <tmlind> mps: nuking that file allows emacs to run though
2021-04-20 12:16:20 <mps> tmlind: sorry, but I don't use emacs and don't have experience with it. and can't remember that I worked anything on it for alpine
2021-04-20 12:16:53 <mps> tmlind: or I don't understand your comment
2021-04-20 12:17:58 <mps> hmm, I'm laying, I enabled it on aarch64
2021-04-20 12:19:22 <tmlind> mps: heh ok :)
2021-04-20 12:19:51 <tomleb> I recently added a new package to aports (my first package!) and the APKBUILD was creating a new user so that it doesn't run as root. I now realize that it must run as root, do I need to do some special upgrade script to remove the user? Or I just remove the pre-install script and let it be.
2021-04-20 12:25:18 <ncopa> ikke: i believe the file lock problem is due to posix record locks are associated with pid, so the lock is not visible accross pid-namespaces (containers)
2021-04-20 12:29:20 <ikke> Aha, would make sense
2021-04-20 12:44:48 <donoban> tomleb: I think that apk never removes users
2021-04-20 12:45:22 <ericonr> ncopa: NOTES mentions l_pid can be kinda useless with NFS, and I would expect the same principles to apply to ns
2021-04-20 12:45:32 <ericonr> the kernel even has: static pid_t locks_translate_pid(struct file_lock *fl, struct pid_namespace *ns)
2021-04-20 12:47:08 <skarnet> tomleb: let it be, we'll reconsider when we're out of uids :D
2021-04-20 12:47:36 <mps> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e
2021-04-20 12:47:59 <mps> Red IBM, (Extend, Embrace ....)
2021-04-20 12:48:54 <skarnet> tomleb: in general, removing a user is a security issue because the uid can get reassigned and files created under the old user will have the wrong permissions. In your case it's not a real issue but "never remove users" is good policy; you can leave a comment in your APKBUILD that says "olduser" is unused and was a mistake, and that's it
2021-04-20 12:49:30 <skarnet> just don't create it in newer versions of your package :)
2021-04-20 12:51:03 <ericonr> mps: wtf
2021-04-20 12:54:07 <mps> ericonr: you read it? :(
2021-04-20 12:55:54 <ericonr> well, if that's quoted exactly it sucks hard
2021-04-20 12:55:58 <skarnet> very healthy employer rules
2021-04-20 12:56:25 <ericonr> I'd understand "you're being paid to do this, please use your corporate email here"
2021-04-20 12:56:49 <Hello72> i bet they get fired for posting it publicly
2021-04-20 12:57:21 <mps> Hello72: maybe this is her/his intention
2021-04-20 12:58:56 <mps> and this is 'revenge' to such bad employer (or just bad manager)
2021-04-20 12:59:45 <mps> but that shows how is bad that linux now tied too much too much to big corporations
2021-04-20 13:02:26 <donoban> omg :\
2021-04-20 13:03:23 <ericonr> Hello72: by posting to the ML, you mean?
2021-04-20 13:03:30 <Hello72> yes
2021-04-20 13:03:36 <ericonr> https://lore.kernel.org/netdev/161887560929.13803.2397044457894925895.git-patchwork-notify@kernel.org/T/#t <-- "You are awesome, thank you!" ironic
2021-04-20 13:07:21 <Gottox> :D
2021-04-20 13:34:45 <mps> ikke: ncopa: linux 5.12 will have idmap mounts which will solve some of these propblems I think. https://lore.kernel.org/lkml/20210213130042.828076-1-christian.brauner@ubuntu.com/T/#u
2021-04-20 14:01:37 <Thermi> mps: Cogitri I belive the armv7 builder is stuck
2021-04-20 14:10:53 <Cogitri> Thermi: You mean the CI runner?
2021-04-20 14:10:58 <Thermi> Cogitri: yes
2021-04-20 14:11:18 <Cogitri> I think ikke was working on that already (?)
2021-04-20 14:18:18 <Thermi> Cogitri: Well, at the moment it's still not doing any of the jobs that are relevant to me, so I don't know if it's still suck or just working on the queue
2021-04-20 14:18:35 <Thermi> Content of my message thus: Unknown if problem is solved or not
2021-04-20 14:18:36 <ncopa> i am not able to reproduce he locking issue with unshare(1) either
2021-04-20 14:18:51 <ncopa> weird. i have no clue whats going on
2021-04-20 14:24:29 <tomleb> skarnet: Thanks, good point on the security issue as well, I hadn't thought of that. I'll just remove the pre-install script and remove the pkgusers=, pkggroups= fields in APKBUILD
2021-04-20 15:45:41 <Ariadne> i can tell you if i had a manager talk to me like in that IBM commit, i would quit
2021-04-20 15:48:19 <ikke> First ask compensation for the 100% time
2021-04-20 15:49:07 <mps> ikke: this is possible only in Europe :)
2021-04-20 15:49:58 <mps> I mean european countries
2021-04-20 15:54:07 <mps> when I was employed in former Yugoslavia every minute of overtime work was payed and at double rate
2021-04-20 15:54:50 <ikke> Thermi: Cogitri armv7 is not stuck atm
2021-04-20 15:55:14 <mps> but we made 'big' step forward (to nowhere)
2021-04-20 15:56:09 <mps> (old good times. (I'm old obviously))
2021-04-20 16:32:15 <donoban> uhM, if I uderstand correctly the IBM guy wants to continue working on it but the company moved him to other thing so he changed the mail to his personal account?
2021-04-20 16:32:58 <Hello72> could be
2021-04-20 16:40:32 <jvoisin> stupid question, with regarde to https://gitlab.alpinelinux.org/alpine/aports/-/commit/68da843018346f66c160a9bc11ad8248bca63612
2021-04-20 16:40:43 <jvoisin> the source archive was updated
2021-04-20 16:40:45 <jvoisin> by kep the same name
2021-04-20 16:40:52 <jvoisin> is there a way to tell the mirrors to get the new one?
2021-04-20 16:41:00 <jvoisin> because currently, they're serving the old (broken) one
2021-04-20 16:41:44 <ikke> jvoisin: You mean distfiles?
2021-04-20 16:42:24 <jvoisin> maybe?
2021-04-20 16:42:35 <jvoisin> (check the commit, you'll see the issue)
2021-04-20 16:42:45 <ikke> Yes, I did check the commit
2021-04-20 16:42:55 <ikke> That would only show up on the actual builders
2021-04-20 16:43:07 <ikke> It's something we would need to fix manually
2021-04-20 16:43:32 <jvoisin> can I help to make this happen?
2021-04-20 16:43:41 <ikke> I can do it now
2021-04-20 16:43:56 <jvoisin> oh
2021-04-20 16:43:58 <jvoisin> amazing, thanks ♥
2021-04-20 16:45:03 <ikke> I've renamed it
2021-04-20 16:46:54 <ikke> This was already a couple of days ago?>
2021-04-20 16:47:33 <jvoisin> the issue of not having the package rebuilt with the "new" source archive has always been there, since the merging of the commit
2021-04-20 16:48:05 <maxice8> There is a duplicate gettext-tiny in testing/ and community/
2021-04-20 16:50:51 <minimal> maxice8: yeah I pointed this out last week - Ariadne indicated its intentional lol
2021-04-20 16:51:01 <ikke> and temporary
2021-04-20 16:52:40 <maxice8> I see
2021-04-20 18:41:39 <mps> indy: why do you split pkg in !20659 and then add all them to depends
2021-04-20 18:42:41 <ikke> mps: to have a single meta-package that gets you everything if you want?
2021-04-20 18:43:59 <mps> ikke: util-linux have a lot of binaries, so we should split them all?
2021-04-20 18:44:35 <indy> mps, to keep subpackages part of util-linux for those who installs whole util-linux
2021-04-20 18:44:57 <mps> I can't see usefulness of such splits
2021-04-20 18:45:48 <indy> mps, our customer needs only flock, uuidgen and logger. as he wants to have containers smaller as possible, such split make sense
2021-04-20 18:46:25 <mps> oh, no. customers dictates alpine development :)
2021-04-20 18:47:09 <afontain_> mps, 2021: oh no, minimalism dictates alpine development
2021-04-20 18:47:22 <afontain_> (kidding)
2021-04-20 18:47:25 <indy> mps, :) to me, i would go even further, like in openwrt
2021-04-20 18:47:38 <indy> afontain_, +1 :)
2021-04-20 18:47:39 <mps> afontain_: besides pmOS :) (also kidding)
2021-04-20 18:48:51 <mps> anyway, I'm not against splits where it makes sense
2021-04-20 18:50:00 <mps> indy: believe me or not I contemplated idea to make openwrt desktop and forget alpine :)
2021-04-20 18:57:50 <indy> mps, :) i'm contemplating moving from openwrt to yocto
2021-04-20 18:58:28 <indy> mps, related request in !20659
2021-04-20 18:58:37 <indy> mps, for edge
2021-04-20 19:01:19 <mps> indy: yes, commented it above
2021-04-20 19:48:54 <donoban> Cogitri: I built tg_owt with packaged libvpx :D, now building... telegram-desktop :)
2021-04-20 19:55:47 <Cogitri> Nice 👍
2021-04-20 20:02:01 <donoban> it was lot easier than I thought
2021-04-20 20:38:40 <donoban> beh, same error :\
2021-04-21 02:15:09 <Thermi> ERROR: unable to select packages:
2021-04-21 02:15:09 <Thermi>   openjdk11-jre-headless (no such package):
2021-04-21 02:15:11 <Thermi> WTF did you dooooo
2021-04-21 02:15:15 <Thermi> (On builders)
2021-04-21 02:17:30 <Thermi> aaaah nvm
2021-04-21 02:17:52 <Thermi> only available on x86_64 and sx390 because of the arch field in the APKBUILD of openjdk11
2021-04-21 02:18:56 <Thermi> Nvm, more than those. Just no 32 bit arches
2021-04-21 02:18:57 <tomleb> Are there good reasons to prevent reading some pid file? For example, I see /run/syslogd.pid is 0640 instead of 0644.
2021-04-21 02:19:08 <Thermi> AFAIK not.
2021-04-21 02:19:38 <Thermi> As long as hidepid for procfs is set to 0, anybody can see any thread/process.
2021-04-21 02:19:56 <Thermi> With 2, you can't see those anymore. Maybe the PID is useful for anything else then.
2021-04-21 02:20:28 <tomleb> Same for chrony, where /run/chrony/ is 0640 (although this one contains both chronyd.pid and chronyd.sock)
2021-04-21 02:20:41 <Thermi> Probably because of the umask of the process
2021-04-21 02:20:59 <tomleb> Could this be considered as a "bug" that needs fixing?
2021-04-21 02:21:23 <Thermi> Report it and see if anybody gives it any priority.
2021-04-21 02:21:41 <Thermi> Search for it first though, obviously.
2021-04-21 02:22:29 <tomleb> Would https://gitlab.alpinelinux.org/alpine/aports/-/issues be the right place?
2021-04-21 02:22:36 <Thermi> Yes
2021-04-21 02:22:50 <tomleb> Alright, thank you. Yeah, I'll do a search first and report if I don't find anything
2021-04-21 02:23:26 <Thermi> w
2021-04-21 02:23:26 <Thermi> yw
2021-04-21 02:51:03 <tomleb> Couldn't find any issues that exists already so I created this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12623
2021-04-21 06:09:23 <Cogitri> Ariadne: Would be nice if it were possible to filter security.a.o by maintainer
2021-04-21 06:45:05 <ikke> Cogitri: consider opening issues on the project as feature requests
2021-04-21 06:55:54 <Ariadne> Cogitri: yes, coming soon :)
2021-04-21 06:59:36 <Cogitri> Nice 👍
2021-04-21 07:00:09 <Cogitri> ikke: Ah yes, will do next time :)
2021-04-21 07:00:29 <Cogitri> Just saw the announcement when I was eating breakfast so I took a quick look on my phone
2021-04-21 07:12:59 <skarnet> !20619 can now be merged
2021-04-21 09:58:22 <ncopa> did we have a problem with libtiff?
2021-04-21 09:58:26 <ncopa> the ABI broke?
2021-04-21 10:26:15 <PureTryOut[m]2> Is there a way to make abuild use GNU make for a particular package? I'm testing something but adding "make" to the makedepends still seems to call non-GNU make
2021-04-21 10:28:57 <PureTryOut[m]2> Oh never mind, I'm confusing make and automake
2021-04-21 10:29:03 <mps> PureTryOut[m]2: alpine default make is gnu make
2021-04-21 10:29:06 <mps> ah,
2021-04-21 10:32:27 <afontain_> I was wondering if it was about the remake make replacement package from testing
2021-04-21 10:32:46 <afontain_> (but no)
2021-04-21 11:48:30 <mps> do we need to enable hidpi mouse on armv7, #12618
2021-04-21 11:49:04 <mps> new kernels will be released in few minutes
2021-04-21 11:49:45 <PureTryOut[m]2> Why not? At least 1 user would like it
2021-04-21 11:50:28 <mps> and user nick is PureTryOut[m]2 ? ;)
2021-04-21 11:50:46 <PureTryOut[m]2> No not me personally haha, but the user reporting that issue
2021-04-21 11:51:40 <mps> I didn't noticed armv7 is mentioned there
2021-04-21 11:52:21 <PureTryOut[m]2> Oh sorry, they asked for the kernel in general
2021-04-21 11:52:30 <PureTryOut[m]2> Then probably not, I doubt many people are using armv7 desktops. aarch64 is more useful
2021-04-21 11:54:09 <mps> yes, I think aarch64 and x86_64 makes sense, not sure for other
2021-04-21 11:54:42 <mps> though I have one armv7 notebook/chromebook
2021-04-21 11:54:57 <mps> and it have hdmi
2021-04-21 11:55:40 <mps> ok, for now aarch64 and x86_64 are enough, if someone asks we can enable it on other
2021-04-21 11:56:39 <mps> going to coffee to read changelog in quiet room
2021-04-21 11:57:17 <mps> and I wonder when the people will learn to not chat while they are making coffee :D
2021-04-21 12:21:01 <mps> PureTryOut[m]2: interesting, this two are already enabled on armv7 in linux-edge :)
2021-04-21 12:21:27 <PureTryOut[m]2> Ha
2021-04-21 12:26:12 <mps> and in -lts is CONFIG_USB_EHCI_TT_NEWSCHED=y but not CONFIG_USB_EHCI_ROOT_HUB_TT is not set
2021-04-21 12:26:16 <mps> ncopa: ^
2021-04-21 12:34:46 <rahmanshaber[m]> Please Review this MR.
2021-04-21 12:34:46 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20673
2021-04-21 12:38:41 <PureTryOut[m]2> Did a review, please apply the comments I made
2021-04-21 12:38:51 <mps> https://fossbytes.com/secure-linux-distros-privacy-anonymity/, interesting only alpine is based on alpine :)
2021-04-21 12:44:16 <caskd> sorry if this was asked as i don't keep up with this chat as much but is everyone afriad of the breakage on python packages
2021-04-21 12:44:25 <caskd> both youtube-dl and qutebrowser are broken on edge
2021-04-21 12:44:52 <PureTryOut[m]2> youtube-dl works fine for me?
2021-04-21 12:44:55 <caskd> is everyone aware*
2021-04-21 12:45:00 <caskd> PureTryOut[m]2: on edge?
2021-04-21 12:45:11 <PureTryOut[m]2> Yes
2021-04-21 12:45:30 <caskd> ModuleNotFoundError: No module named 'youtube_dl'
2021-04-21 12:45:33 <caskd> hmm
2021-04-21 12:45:42 <caskd> same with qutebrowser
2021-04-21 12:46:35 <caskd> falling back to latest-stable works fine
2021-04-21 12:47:10 <PureTryOut[m]2> Please make sure you are running Python 3.9 and you have the latest packages
2021-04-21 12:47:19 <mps> caskd: apk update ; apk upgrade -a
2021-04-21 12:47:52 <mps> I had this problem when python 3.9 was not built completely
2021-04-21 12:48:17 <mps> after full upgrade problem disappeared
2021-04-21 12:48:58 <PureTryOut[m]2> Exactly
2021-04-21 12:50:33 <caskd> hm, that should be it
2021-04-21 12:50:36 <caskd> had 3.8
2021-04-21 12:50:51 <caskd> gonna wait until it's done to confirm
2021-04-21 13:13:23 <caskd> ok, yeah it was python version
2021-04-21 13:30:29 <Ariadne> mps: yes i would like to see it :)
2021-04-21 13:36:38 <mps> Ariadne: what? hidpi mouse on usb?
2021-04-21 13:36:46 <Ariadne> yes
2021-04-21 13:37:12 <mps> heh, install linux-edge 5.11.16 and you will have it :)
2021-04-21 13:37:13 <Ariadne> i dont think those options are actually about hidpi mice though
2021-04-21 13:37:27 <Ariadne> i think they have to do with enabling a specific buggy hidpi mouse
2021-04-21 13:37:28 <mps> right, it is general
2021-04-21 13:37:55 <Ariadne> anyway, an alpine desktop using friend complained about having to patch his kernel to enable the option
2021-04-21 13:37:56 <mps> could be usable for other buggy devices too
2021-04-21 13:37:59 <Ariadne> so i told him open a bug :P
2021-04-21 13:38:24 <mps> yes, I saw your twit (though I don't use twitter)
2021-04-21 13:39:51 <mps> all these drivers are strange, few days ago I discovered that I have to enable sunxi touchscreen driver to read SOC sensors
2021-04-21 13:40:59 <Ariadne> :D
2021-04-21 13:41:27 <Ariadne> maybe it enables an I2C driver as a side effect?
2021-04-21 13:42:03 <mps> no, I2C was enabled long time ago
2021-04-21 13:44:43 <mps> but it is strange, will look deeply on it when find some time
2021-04-21 13:45:07 <mps> could be that it enables something else
2021-04-21 13:49:56 <caskd> shut up
2021-04-21 13:50:54 <caskd> idc
2021-04-21 13:50:58 <caskd> oh
2021-04-21 13:51:01 <caskd> wait wrong chat
2021-04-21 13:51:03 <caskd> damn irssi
2021-04-21 13:51:04 <caskd> mb
2021-04-21 14:16:19 <mps> interesting times for linux https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/
2021-04-21 14:16:48 <mps> GKH banned university of Minesota to send patches to kernel
2021-04-21 14:25:31 <mps> so, yes, upgrade your kernels ASAP
2021-04-21 14:26:05 <mps> in short, they posted intentionally patches with bugs
2021-04-21 14:27:25 <mps> and we will have probably new release today
2021-04-21 14:34:39 <tehcloud> holy shit...
2021-04-21 14:39:49 <skarnet> popcorn time!
2021-04-21 14:44:44 <donoban> :\
2021-04-21 14:48:00 <mps> I hope BDFL^W'Alpine' can learn something from this ;)
2021-04-21 14:49:10 <donoban> do you know what he refers with "and published a paper based on that work."?
2021-04-21 14:50:40 <mps> read GKH msgs in thread there, url is given but I wouldn't go again over all thread
2021-04-21 14:50:57 <ikke> I understood the patches never made it to a release
2021-04-21 14:51:11 <Cogitri> donoban: They made a scientific paper describing what they did
2021-04-21 14:55:34 <mps> 1https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf
2021-04-21 14:55:45 <donoban> lol
2021-04-21 14:55:52 <donoban> thats the worse option that I was thinking
2021-04-21 14:58:26 <mps> ikke: GKH do some reverts, so probably it is already merged
2021-04-21 14:59:06 <ikke> Yes, was apparently included in stable branches
2021-04-21 14:59:25 <mps> I'm out, and  my kernel git tree is not with me so can't look now
2021-04-21 15:00:04 <ikke> "A lot of these have already reached the stable trees"
2021-04-21 15:01:36 <jvoisin> https://security.alpinelinux.org/ looks fancy
2021-04-21 15:02:05 <donoban> yeah it seems very nice :)
2021-04-21 15:03:35 <caskd> ooh fancy
2021-04-21 15:13:39 <ikke> It is interesting though that these patches made it through
2021-04-21 15:15:06 <donoban> I wonder if the paper had considered the importance of being some reputable university, maybe the same patches sent from an uknown anonymous guy would be analyzed more deeply and rejected :\
2021-04-21 15:15:25 <halosghost> ikke: IMO, all it proves is that (noting Linus's Law) the kernel doesn't quite have “enough eyeballs” yet
2021-04-21 15:15:48 <halosghost> personally, I kind of think that professor should be fired wholesale
2021-04-21 15:16:16 <halosghost> (doing research (which is so clearly done on-people it's not even funny) without talking to an IRB at all is kind of insane)
2021-04-21 15:16:17 <ikke> donoban: The wisdom goes that it should not matter who is providing a patch
2021-04-21 15:16:17 <Ariadne> there is never 'enough' eyeballs
2021-04-21 15:16:35 <ikke> donoban: You should not accept a patch just because it's from someone you know
2021-04-21 15:16:36 <halosghost> Ariadne: I don't necessarily disagree
2021-04-21 15:16:45 <halosghost> Ariadne: but if that's the case, then was there any point to the research at all?
2021-04-21 15:16:49 <Ariadne> anyway this is not surprising to me!
2021-04-21 15:17:00 <Ariadne> i've written about this before
2021-04-21 15:17:16 <Ariadne> if you are a nation state actor or whatever and you want to poison a source tree
2021-04-21 15:17:19 <Ariadne> it makes sense
2021-04-21 15:17:24 <Ariadne> to send in patches that are legit
2021-04-21 15:17:30 <Ariadne> until they get lax with reviewing your shit
2021-04-21 15:17:32 <donoban> ikke: yeah, the classic security dilema, who trusting? do you want to untrust everyone? you cant :\
2021-04-21 15:17:42 <Ariadne> then you start slipping in backdoors
2021-04-21 15:17:55 <Ariadne> people were like "nah nobody will try that"
2021-04-21 15:17:56 <Ariadne> haha
2021-04-21 15:18:03 <Hello72> yes, their problem is that they were lazy and started out with the crap
2021-04-21 15:18:09 <Ariadne> correct
2021-04-21 15:19:14 <mps> what is worse, who knows how many such things exists in code which are still not detected
2021-04-21 15:19:27 <ikke> donoban: What I'm saying is that (I know the reality is different) is that trust should not play a role at all when reviewing patches
2021-04-21 15:20:47 <donoban> yes I agree :), maybe some kind of patch review where all the authors are hidden... uhM
2021-04-21 15:20:50 <ikke> ie, the reason why (at least git.git) is not relying on GPG signatures is that they do not care who the uahtor is
2021-04-21 15:20:53 <ikke> author*
2021-04-21 15:21:59 <ericonr> why is f7f0e8106bd5fcacd5384c50187c1159f11fc9eb using a static param struct instead of what's passed to sched_setscheduler?
2021-04-21 15:23:25 <ikke> maribu[m]: ^
2021-04-21 15:23:36 <Ariadne> its a backdoor
2021-04-21 15:23:38 <Ariadne> obv
2021-04-21 15:23:49 <donoban> heh
2021-04-21 15:24:35 <mps> :D
2021-04-21 15:25:21 <ericonr> hm
2021-04-21 15:25:26 <ericonr> doesn't this make rtkit a noop?
2021-04-21 15:25:36 <Ariadne> they got the patch from UMN
2021-04-21 15:25:39 <Ariadne> obviously
2021-04-21 15:25:42 <ericonr> lol
2021-04-21 15:26:41 <mps> late Jon Postel robustness rule should be reverted to 'be conservative in what you accept and be conservative in what you send' :)
2021-04-21 15:27:09 <ericonr> isn't the robustness rule what fucked the internet anyway :p
2021-04-21 15:27:14 <Ariadne> basicallhy
2021-04-21 15:27:16 <Ariadne> -h
2021-04-21 15:27:19 <ericonr> "take all the crap in"
2021-04-21 15:27:20 <mps> ericonr: right :)
2021-04-21 15:27:40 <Ariadne> anyway, in secfixes-tracker v0.2
2021-04-21 15:27:47 <Ariadne> you can fetch all of that data as JSON-LD
2021-04-21 15:27:48 <ikke> (just deployed)
2021-04-21 15:28:03 <donoban> did you add linux-lts?
2021-04-21 15:28:11 <Ariadne> if any of you people work for a security company and aggressively scrape it, you will be banned
2021-04-21 15:28:46 <Ariadne> donoban: there's no mapping rule for that yet
2021-04-21 15:29:09 <mps> Ariadne: you mean 'security theatre' ;p
2021-04-21 15:29:16 <donoban> ey Ariadne it would be nice to add an sec-acf too, but maybe based on apk3?
2021-04-21 15:29:22 <Ariadne> mps: yes
2021-04-21 15:29:36 <Ariadne> donoban: a what?
2021-04-21 15:29:44 <ikke> acf module I guess
2021-04-21 15:29:45 <donoban> an acf page for security report
2021-04-21 15:29:48 <donoban> yes
2021-04-21 15:29:52 <Ariadne> i mean, i guess
2021-04-21 15:29:55 <Ariadne> not my department
2021-04-21 15:30:03 <ikke> you'd have to ask ttrask
2021-04-21 15:30:10 <Ariadne> there's like 3 different panels you can install for alpine
2021-04-21 15:30:14 <Ariadne> acf is just one of them
2021-04-21 15:30:47 <minimal> mps: quite a large revert list: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
2021-04-21 15:31:11 <donoban> I have POC for acf-docker, it needs a few things
2021-04-21 15:31:15 <mps> minimal: yes, I saw this
2021-04-21 15:31:37 <donoban> Ariadne: what you mean with "panels"?
2021-04-21 15:31:57 <donoban> web-based interface?
2021-04-21 15:32:05 <mps> minimal: now you understand why I'm so conservative with your patches :P
2021-04-21 15:32:24 <Ariadne> donoban: yes
2021-04-21 15:32:35 <donoban> uhM, I only knew acf
2021-04-21 15:32:46 <minimal> mps: I'm a white hat - honest! ;-)
2021-04-21 15:32:50 <Ariadne> there is acf and then ACF2
2021-04-21 15:32:54 <Ariadne> and then some other one
2021-04-21 15:32:59 <Ariadne> that i dont remember the name of right now
2021-04-21 15:33:03 <Ariadne> i dont use any of that stuff :p
2021-04-21 15:33:18 <minimal> mps: my white hat just got a little gray in the wash lol
2021-04-21 15:33:19 <mps> minimal: jk, but I think you understand
2021-04-21 15:33:29 <donoban> hehe, it's useful on some cases
2021-04-21 15:41:33 <mps> better gray than red hat :)
2021-04-21 15:41:40 <rahmanshaber[m]> Please review the MR
2021-04-21 15:41:40 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20676
2021-04-21 15:42:59 <minimal> I see kernel patches from this guy going back at least 2 years - not saying they are all necessarily suspect but they seem to fit the pattern of submitting memory "protection" patches
2021-04-21 15:45:55 <mps> hah, so this is long planned and carefully conducted operation
2021-04-21 15:47:01 <mps> Sun Tzu section on spies, classic :)
2021-04-21 15:47:31 <mps> and Machiavelly wrote about this
2021-04-21 15:48:46 <Ariadne> cue every security company hammering security.alpinelinux.org
2021-04-21 15:48:53 <Ariadne> its fine
2021-04-21 15:49:00 <Ariadne> we will start to return rickroll to them :)
2021-04-21 15:49:18 <ikke> package: "never", cve: "gonna give you up"
2021-04-21 15:49:38 <minimal> no idea, I just noticed that 4.19.47 seems to have 5 patches from him: https://lore.kernel.org/lkml/20190531093132.GB23111@amd/T/
2021-04-21 15:51:51 <maribu[m]> @ericonr: As written in the patch, I just took the implementations of https://git.musl-libc.org/cgit/musl/commit/?id=61be1cfec1f5da66c68f92a6939e3a38e673c9d6 - I don't know what the reason is to only pass over the scheduling policy and not the priority. It is not given in that patch set.
2021-04-21 15:54:04 <Ariadne> mps: fwiw i agree with you that almost all of these security companies are not really doing anything useful
2021-04-21 15:54:53 <ericonr> maribu[m]: thing is, it isn't passing anything
2021-04-21 15:54:58 <ericonr> +        return syscall(SYS_sched_setscheduler, pid, 0, &def);
2021-04-21 15:55:08 <ericonr> musl's version at that time was a stub
2021-04-21 15:55:32 <ericonr> instead of using sched, it used 0, instead of using params, it used def
2021-04-21 15:55:42 <mps> Ariadne: yes, I know from personal experience :)
2021-04-21 15:56:13 <ericonr> I think copying from glibc makes more sense, since theirs is the version that works with rtkit
2021-04-21 15:56:34 <mps> I was owner of one small such 'company'
2021-04-21 15:57:26 <maribu[m]> Yes, it should have passed over sched instead of 0. I copied the wrong path :-/
2021-04-21 15:58:45 <mps> that patch is reason I didn't merged it
2021-04-21 15:59:13 <mps> though I didn't analyzed it
2021-04-21 15:59:30 <maribu[m]> https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/sched_sets.c;h=83023caed8628b150a8744352fa68e0534baba86;hb=HEAD - looks like glibc isn't doing something reasonable as well...
2021-04-21 15:59:39 <mps> and not sure how useful this pkg
2021-04-21 15:59:51 <ericonr> maribu[m]: it's glibc :p
2021-04-21 16:00:11 <ericonr> ah, you're looking at the wrong file
2021-04-21 16:00:26 <ericonr> see, glibc has multiple implementations of each function spread across their code base
2021-04-21 16:00:38 <ericonr> posix/ is mostly the stub stuff that all returns ENOSYS
2021-04-21 16:01:23 <minimal> mps: I used to work at a well known internet security firm and couldn't understand on my 1st day why everyone had wireless keyboards (unencrypted model to save $5 per keyboard).
2021-04-21 16:02:09 <ericonr> maribu[m]: and if you grep for sched_setscheduler, you get 81 files with results :)
2021-04-21 16:02:47 <maribu[m]> But none implementing it...
2021-04-21 16:03:10 <ericonr> I'm trying to find it, I had it once
2021-04-21 16:03:59 <maribu[m]> I can find an implementation for hurd and the fallback posix one.
2021-04-21 16:05:28 <mps> minimal: you asked and give answer, to save money ;P
2021-04-21 16:05:36 <mps> that' why
2021-04-21 16:05:52 <mps> that's why
2021-04-21 16:06:37 <ericonr> maribu[m]: disassembling libc.so.6 I can see sched_setscheduler definitely calls a syscall
2021-04-21 16:06:59 <ericonr> so it's *somewhere*
2021-04-21 16:06:59 <minimal> mps: I showed site IT Admin a website on how to build cantenna-based circuit to log these keyboards from 20+ metres away and pointed out the public parking spots down the side of the building near my desk......he just didn't care :-(
2021-04-21 16:09:11 <maribu[m]> Well, security companies are selling a sense of security. It is just like anti virus. It doesn't work. But when things break, you can say: But we did everything we could, even bought an anti virus!!!111eleven
2021-04-21 16:09:59 <ikke> lol
2021-04-21 16:11:36 <mps> yes, real security problem are managers. so someone have to invent 'antivirus' to remove them from IT
2021-04-21 16:11:59 <maribu[m]> There are companies that sell alibis for when you want to have an affair. I think many security companies are like this. Replace having an affair with "not giving a shit about security" and alibi with "some magic security voodoo".
2021-04-21 16:12:36 <ericonr> maribu[m]: just run a program linked against sched_setscheduler under gdb and you can find the file where the functions is defined :p
2021-04-21 16:12:40 <ericonr> very practical
2021-04-21 16:12:51 <Hello72> mps: simple solution, just add someone to work between managers and IT. we will call it, uh... "middle management"
2021-04-21 16:12:58 <ericonr> Breakpoint 1, sched_setscheduler () at ../sysdeps/unix/syscall-template.S:120
2021-04-21 16:13:22 <mps> Hello72: aieee! yet another layer in security :)
2021-04-21 16:13:35 <ericonr> anyway, that would lead me to assume the function is a thin wrapper around the syscall
2021-04-21 16:14:19 <ericonr> so it would pass all the args
2021-04-21 16:14:28 <maribu[m]> ericonr: I agree. I will adapt the wrapper to just pass the args as is.
2021-04-21 16:17:48 <ericonr> :)
2021-04-21 16:18:24 <maribu[m]> Let's see if I can get sound on firefox with super low latency without cracking noises now. If I do, I'm pretty sure rtkit works as expected.
2021-04-21 16:28:09 <maribu[m]> Cool: Sound is working fine in online videos in firefox with default pipewire config while maxing out all cores compiling. (Previously, it was stuttering without increasing latency for me even without other load on the system.)
2021-04-21 16:30:41 <maribu[m]> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/aJkDxeqseYIlQKjuVTydFDhp/message.txt >

2021-04-21 16:32:22 <maribu[m]> Just the nice level part (with also previously worked) did already help quit a bit, though.
2021-04-21 16:33:25 <maribu[m]> (Btw: Does the pasting of the log messages is reasonably disabled in IRQ? I have no idea how the matrix <--> IRQ bridge handles this.)
2021-04-21 16:34:18 <Ariadne> it sends a link
2021-04-21 16:35:27 <mps> maribu[m]: IRC, I was surprised by IRQ
2021-04-21 16:36:17 <maribu[m]> @mps: :-D
2021-04-21 20:35:34 <Thermi> There's a problem in Java on s390x: https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/376680#L13319
2021-04-21 20:35:34 <Thermi> Known?
2021-04-21 20:35:43 <Thermi> > #  SIGFPE (0x8) at pc=0x000003ffaa4da612 (sent by kill), pid=4014, tid=4036
2021-04-21 20:36:31 <Thermi> Known.
2021-04-21 20:36:34 <Thermi> !12275
2021-04-21 20:36:43 <Thermi> #12275 ?
2021-04-21 20:36:46 <Thermi> There.
2021-04-21 20:41:32 <Ariadne> :D
2021-04-21 20:42:13 <Thermi> Cheap fun.
2021-04-21 20:50:38 <Thermi> @ncopa Please let me know your thoughts: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20664#note_153486
2021-04-21 20:57:39 <Thermi> I kind of hate that I always step into such issues like the one with s390x
2021-04-21 21:03:52 <ikke> Thermi: I just wonder if setting proxy settings (even if they are different for maven) is the responsibility of the user?
2021-04-21 21:14:26 <Thermi> ikke: I don't understand that question. If the user sets a proxy in the environment, he/she/it surely wants it to be used for building packages, too?!
2021-04-21 21:14:57 <Thermi> If he/she/it doesn't want that, then he variables surely wouldn't be set, at the very least not for the invocation of abuild?
2021-04-21 21:15:05 <ikke> sure, but is it abuilds responsibility to account for differences?
2021-04-21 21:15:55 <Thermi> The alternative is that the user needs to investigate any failure to use the proxy when it's encountered and manually adjust the environment at a maximum of X times for X packages, even if the problem is known upstream
2021-04-21 21:16:12 <Thermi> At the very least it'd be very convenient to have that problem taken care off for any user
2021-04-21 21:16:17 <Thermi> (and at least for maven)
2021-04-21 21:16:45 <ikke> If they would build manually with maven, they would run in the same issue
2021-04-21 21:17:22 <Thermi> Yes, but people don't build packges for fun but to use the software.
2021-04-21 21:17:26 <ikke> Thermi: in fact, if they would run maven manually to test things, it would not work
2021-04-21 21:17:58 <ikke> would be strange if building with abuild magically works, but not without it
2021-04-21 21:18:08 <Thermi> So generally, you want stuff to work at a maximum of times it would work without intervention by any of the bguild tools?
2021-04-21 21:18:48 <Thermi> That will result in any user trying to build any package that has a build system with such works to ... 1) Investigate the issue by him/her/itself 2) fix it by him/her/itself
2021-04-21 21:18:54 <Thermi> And that TBH just sucks.
2021-04-21 21:19:06 <Thermi> Because then the effort is duplicated X*N times
2021-04-21 21:19:26 <Thermi> (X := number of distinct build systems with such issues; N := number of users)
2021-04-21 21:20:04 <Thermi> I think it is reasonable to fix it in abuild, but print a message on stdout or stderr that says that this is done
2021-04-21 21:20:37 <ikke> or just warn
2021-04-21 21:20:48 <Thermi> E.g. "Detected maven in maedepends. Fixing up envs MAVEN_OPTS[...]"
2021-04-21 21:20:51 <ikke> maven is broken, make sure to set these proxy settings to make it less broken
2021-04-21 21:21:12 <Thermi> If we just warn then it's again an effort being duplicated X*N times.
2021-04-21 21:21:35 <ikke> Yes, but it's explicit
2021-04-21 21:21:47 <Thermi> And what does that get us?
2021-04-21 21:21:56 <ikke> and abuild does not need to know how maven sets proxy settings
2021-04-21 21:22:02 <Thermi> How does that help anyone?
2021-04-21 21:22:55 <Thermi> If it's not fixed up in abuild, the code to fix the proxy settings needs to be included in every APKBUILD, or set by each user after the proxy is set so the environment envs for maven are fixed up before maven is invoked
2021-04-21 21:24:00 <Thermi> We can make an effort to get maven devs to fix this in maven itself. Until then, the best solution is to just fix it in abuild. That way there's no duplication, usability is improved.
2021-04-21 21:24:23 <Thermi> The point of computers is to reduce effort. I think having abuild deal with this for the time being is going exactly into that direction.
2021-04-21 21:24:45 <c705> good luck trying to get CCupstream to do *anything*
2021-04-21 21:25:03 <Thermi> Pfff. Then we can just patch it in aports.
2021-04-21 21:25:35 <c705> usually, that's the approach distro maintainers take, yes
2021-04-21 21:26:00 <Thermi> (I have my own opinion on distro maintainers ususally patching stuff, but I'll hold my tongue now)
2021-04-21 21:26:03 <ikke> patching it would make more sense then to add the logic to abuild
2021-04-21 21:26:22 <Thermi> The latter is the smallest effort to improve the situation for all users right now.
2021-04-21 21:26:45 <c705> Thermi: well, either we patch is, they patch it, or we ignore it. if option 2 isn't going to happen, then what do you prospose?
2021-04-21 21:26:49 <ikke> Thermi: I have a feeling that people who use proxies and maven already know about it
2021-04-21 21:27:23 <Thermi> ikke: The ones that do that _right now_ *probably* already know it. And then there is the unknown amount of people that will encounter this problem in the future.
2021-04-21 21:27:44 <Thermi> I really, REALLY don't want to have to improve my understanding of java to patch this.
2021-04-21 21:29:14 <ikke> building good software is also a matter of setting good boundaries, and I feel that network settings our out of scope for abuild
2021-04-21 21:29:17 <Thermi> c705: Like I wrote, fix it in abuild until it's patched in maven. Then we can remove the fix in abuild.
2021-04-21 21:29:44 <ikke> then people with old versions of maven ask it to restore it
2021-04-21 21:29:52 <Thermi> Why would they?
2021-04-21 21:29:55 <ikke> because they've come to rely on it
2021-04-21 21:29:59 <Thermi> How?
2021-04-21 21:30:05 <Thermi> Seperate proxies for maven and other software?
2021-04-21 21:30:12 <Thermi> No proxy for using maven?
2021-04-21 21:31:39 <Thermi> Rely on maven not using a configured proxy?
2021-04-21 21:31:58 <ikke> rely on abuild setting correct proxy settings
2021-04-21 21:32:00 <Thermi> Or rely on maven using a different proxy than the one set in http_proxy and other "normal" vars for setting http proxies?
2021-04-21 21:32:15 <Thermi> Ah, you mean if we theoretically fixed this up in abuild?
2021-04-21 21:32:20 <ikke> yes
2021-04-21 21:32:33 <ikke> https://xkcd.com/1172/
2021-04-21 21:32:34 <alpine-meetbot> https://xkcd.com/1172 | Workflow | Alt-text: There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.
2021-04-21 21:32:34 <Thermi> I understood it as rely on how it is right now (no fix up in abuild)
2021-04-21 21:33:04 <Cogitri> Also, I doubt that when have the hack in abuild it'd ever get removed
2021-04-21 21:33:33 <Cogitri> I still think that since the builders don't need it'd be fine to just ignore this
2021-04-21 21:33:40 <Thermi> ikke: That xkcd is absurd, but I see your point.
2021-04-21 21:33:52 <Cogitri> It's not going to get tested by us anyway so it's just a matter of time until it breaks
2021-04-21 21:34:30 <Thermi> The proposed code in abuild just sets up maven env vars (adds -Dopt=val for proxy settings). It translates the stuff in http_proxy and no_proxy, and ..., to maven opts.
2021-04-21 21:35:57 <ikke> Thermi: the absurdity is ofcourse part of the humor of the xkcd
2021-04-21 21:36:24 <Thermi> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20664/diffs#6c0f4f6b244560a13f17c5fdf7bdbc261645af88_0_25
2021-04-21 21:36:40 <Thermi> That's the code in question.
2021-04-21 21:36:53 <Thermi> It jsut sets MAVEN_OPTs and JAVA_TOOL_OPTIONS.
2021-04-21 21:36:55 <Thermi> *just sets
2021-04-21 21:37:10 <ikke> 3333https://www.hyrumslaw.com/
2021-04-21 21:37:12 <Thermi> We can of course make it append the settings to the current values
2021-04-21 21:37:46 <ikke> maybe a separate maven helper :)
2021-04-21 21:37:58 <ikke> ofcourse that still means that it would need to be fixed for each aport
2021-04-21 21:38:00 <Thermi> Does something like that already exist for something different?
2021-04-21 21:38:09 <Thermi> Fixing it for every aport sucks.
2021-04-21 21:38:16 <Thermi> *every pertained
2021-04-21 21:38:38 <Thermi> It already sucks for the three packages for jitsi.
2021-04-21 21:38:58 <ikke> I guess because you use a proxy
2021-04-21 21:39:18 <nmeum> I agree with Cogitri on this one
2021-04-21 21:39:19 <Thermi> My employer uses a proxy. I just am the poor dude tasked with moving that into aports.
2021-04-21 21:39:21 <Cogitri> abuild-meson exists
2021-04-21 21:39:47 <ikke> as a separate helper
2021-04-21 21:39:52 <Cogitri> If we really have to include this, I'd day make an abuild-maven that takes care of it instead od making abuild do iy
2021-04-21 21:40:03 <Cogitri> ikke: Good thinking
2021-04-21 21:41:42 <nmeum> even in a sepaarate helper it won't get tested by us as we are not using this feature, causing it to break eventually
2021-04-21 21:41:58 <Thermi> There are currently 4 packages using maven in aports
2021-04-21 21:42:16 <Thermi> Not many users are pertained by this.
2021-04-21 21:42:33 <ikke> yes, all the more reason not to put it in abuild
2021-04-21 21:42:33 <Thermi> commons-daemon, java-jansi-native, java-postgresql-jdbx and clojure
2021-04-21 21:42:49 <ikke> the usecase if very limited
2021-04-21 21:43:13 <ikke> my feeling is that the numbers are too low for it to make sense
2021-04-21 21:43:21 <nmeum> +1
2021-04-21 21:43:48 <Thermi> The use case is anybody building any package using maven at any time, in an environment that requires the usage of an explicite proxy.
2021-04-21 21:44:17 <ikke> then they run into it, google how to set proxy settings for maven, fix it, and be done with it
2021-04-21 21:44:26 <Thermi> Done N times.
2021-04-21 21:44:40 <ikke> yes, but my feeling is that N is low
2021-04-21 21:45:43 <ikke> it's impossible to quantify it
2021-04-21 21:46:38 <ikke> https://stackoverflow.com/questions/1251192/how-do-i-use-maven-through-a-proxy
2021-04-21 21:47:56 <ikke> https://github.com/eirslett/frontend-maven-plugin/issues/323
2021-04-21 21:48:22 <Cogitri> And those users wouldn't use abuild nor our helper
2021-04-21 21:48:51 <Cogitri> So really, if you want to lessen the amount of people running into it, it'd have to be fixed upstream instead of us working around it
2021-04-21 21:49:51 <Thermi> Okay. We'll discuss it.
2021-04-21 22:42:40 <Thermi> We discussed it. We'll fix it locally using a script in profile.d.
2021-04-21 22:42:50 <Thermi> And maybe report it upstream.
2021-04-22 00:53:28 <thycoticent> I'm trying to learn how to build packages.  I've gotten the build of a "hello, world" program to work but abuild tries to sign the package, it says it can't read my key file.
2021-04-22 00:53:45 <thycoticent> https://pastebin.com/Dk5sErcb
2021-04-22 00:56:59 <thycoticent> It looks like it's prepending a colon to the path of my signing key's path?  Not sure how that's getting there.
2021-04-22 01:22:36 <tomleb> thycoticent: Look inside ~/.abuild/abuild.conf
2021-04-22 01:23:23 <thycoticent> That was it, tomleb!  Thanks.
2021-04-22 03:28:24 <thycoticent> Is it possible to get abuild to stop saying "Packages must not put anything under /srv, /usr/local or /opt" ?
2021-04-22 03:32:07 <ericonr> don't let packages install files there?
2021-04-22 03:33:07 <thycoticent> I'm trying to pack up a proprietary binary for my company to use internally.  The programs are installed to /opt/ and expect all their files to be there.
2021-04-22 03:33:48 <thycoticent> Was kinda hoping I could override it somehow so the developers can just apk add this package I built.
2021-04-22 03:34:16 <maxice8> add `options="!fhs"`
2021-04-22 03:35:35 <maxice8> to the APKBUILD
2021-04-22 03:36:07 <thycoticent> Perfect.  Thanks, maxice8!
2021-04-22 08:02:37 <ncopa> good morning
2021-04-22 08:09:06 <Ariadne> hi
2021-04-22 08:13:28 <Cogitri> Morning
2021-04-22 08:16:27 <donoban> hello ^^
2021-04-22 08:32:40 <Cogitri> Ariadne: Thanks again for s.a.o, fixed (almost) all of the pending CVEs for the packages I maintain now :)
2021-04-22 08:32:59 <Cogitri> https://security.alpinelinux.org/srcpkg/gnome-autoar <- That seems odd though? It displays CVE-2021-28650 as both resolved and unresolved
2021-04-22 08:33:30 <donoban> cuantic bug :P
2021-04-22 08:36:57 <donoban> I installed and started utmps, have an empty file on /var/run/utmp but firejail complains "Warning: cannot find /var/run/utmp"
2021-04-22 08:51:40 <exception> Gm
2021-04-22 09:01:41 <exception> @Cogitri might be because of the older version which is listed as well? Idk
2021-04-22 09:38:23 <skarnet> donoban: /var/run/utmp is not used with utmps, openrc mistakenly creates it because it encodes policy (obviously), minimal has patches to fix it
2021-04-22 09:38:57 <skarnet> and I don't know how firejail works but it may have a setting for utmp which would need to be adjusted
2021-04-22 09:41:07 <donoban> uhM thanks skarnet , if some app is designed to work with utmp should work also with utmps?
2021-04-22 09:41:32 <donoban> after properly adjustment :)
2021-04-22 09:41:35 <skarnet> if the app has been written correctly, yes
2021-04-22 09:42:11 <skarnet> unfortunately utmp is very much underspecified and people rarely fill in the blanks with correct behaviours and policies
2021-04-22 09:42:17 <donoban> ok i will take a look on firejail internals, at least I see lot of things fixed betwen alpine 3.13 and edge
2021-04-22 09:42:35 <donoban> I thought that trying to fix them before upgrading to edge was a waste of time
2021-04-22 09:42:36 <skarnet> so you have lots of wild assumptions running around, such as the place where the utmp file lives (which apps should *never* access directly)
2021-04-22 09:43:20 <donoban> uhM, they should use some kernel syscall or service?
2021-04-22 09:43:37 <skarnet> any work to fix utmp support in apps is appreciated :) but sync up with minimal, who's centralizing all that info
2021-04-22 09:43:51 <donoban> honestly I don't have idea about utmp/s, probably should read something before disturb you :)
2021-04-22 09:43:57 <skarnet> apps should only use the getutx* and pututxline() functions
2021-04-22 09:44:12 <skarnet> which make no mention of where the actual utmp db is
2021-04-22 09:44:30 <skarnet> anything else is a glibc extension and cannot be made to work in a secure way
2021-04-22 09:45:13 <skarnet> the only underspecified thing that apps have a legit reason to know is the location of the wtmp file, and it's in order to *read* it, not write it
2021-04-22 09:45:21 <donoban> so if firejail says: "Warning: cannot find /var/run/utmp", looks bad
2021-04-22 09:45:44 <skarnet> yeah, they assume something
2021-04-22 09:46:04 <donoban> ok
2021-04-22 09:58:08 <Ariadne> Cogitri: it is because the old version does not get marked as "unpublished"
2021-04-22 09:59:01 <Ariadne> Cogitri: also a CVE can be both in resolved/unresolved state if for example 3.12 isn't fixed
2021-04-22 10:00:02 <Cogitri> Ahh, got it, that makes sense :)
2021-04-22 10:01:32 <Ariadne> i'm going to improve the display of CVEs to make it more obvious
2021-04-22 10:01:53 <donoban> Ariadne: having also report for edge won't be useful?
2021-04-22 10:02:16 <Ariadne> donoban: we do not presently build a security database for edge, so the system cannot track anything
2021-04-22 10:02:24 <Ariadne> once edge has a security database, it will be enabled
2021-04-22 10:02:25 <Ariadne> :)
2021-04-22 10:02:31 <donoban> ah ok, great :)
2021-04-22 10:02:34 <Ariadne> all of that is config work :)
2021-04-22 10:03:59 <Ariadne> anyway, secfixes-tracker 0.3 has improved heuristics
2021-04-22 10:04:07 <Ariadne> so false positives should be substantially reduced
2021-04-22 10:36:55 <mps> firejail depends on dbus, why?
2021-04-22 10:41:17 <donoban> it has dbus filtering options
2021-04-22 10:41:50 <donoban> you can disable dbus for a process or limit its domain for talk/listen/own
2021-04-22 10:41:55 <mps> is it needed on systems without dbus installed?
2021-04-22 10:42:17 <donoban> uhM, I don't think it needs it for run
2021-04-22 10:42:51 <donoban> but I should check to confirm,  probably it assumes that there is dbus is running in some cases
2021-04-22 10:43:02 <mps> we should remove dbus from depends in firejail
2021-04-22 10:43:22 <donoban> I had some problems because it doesn't found dbus session socket
2021-04-22 10:43:34 <donoban> but if you run same process with --noprofile it worked fine
2021-04-22 10:44:30 <mps> actually I built it locally without dbus and use it
2021-04-22 10:45:13 <donoban> :)
2021-04-22 10:48:30 <mps> I build too much pkgs locally, maybe I could fork alpine :)
2021-04-22 10:52:14 <donoban> hehe, well, your fork of aports is like an alpine fork
2021-04-22 10:53:11 <donoban> why don't you use dbus? just trying to be mininal?
2021-04-22 10:53:30 <mps> no, I just have too much branches for particular pkgs
2021-04-22 10:53:37 <skarnet> because dbus is a fdo PoS, that's why
2021-04-22 10:54:18 <mps> simply, I don't need dbus
2021-04-22 10:54:38 <mps> and e/udev, btw
2021-04-22 10:54:45 <donoban> hMm.., fdo Point Of Sale? :\
2021-04-22 10:54:54 <skarnet> piece of shit.
2021-04-22 10:54:58 <donoban> ahh
2021-04-22 10:55:02 <mps> :D
2021-04-22 10:55:25 <donoban> hehe
2021-04-22 10:58:37 <mps> donoban: to clarify, I'm not against all these dbus,udev,pulseaudio,pipewire,... but these should be optional for people who want to use them and not installed by default
2021-04-22 10:59:39 <tomleb> Having recently added a package to aports/testing, what is the process to make it into community?
2021-04-22 11:00:02 <ikke> tomleb: verify that it works, make a merge request that moves it
2021-04-22 11:00:21 <PureTryOut[m]2> And make sure everything it depends on is also in community
2021-04-22 11:00:30 <donoban> yes I understand, I'm currently using KDE, some days ago I changed my wifi and thought about installing network-manager but reconfigured it using setup-interfaces and yeah, I don't feel that I need a network manager
2021-04-22 11:01:39 <tomleb> Ok
2021-04-22 11:01:46 <mps> donoban: you know for iwd and iwgtk?
2021-04-22 11:02:06 <donoban> uhM no I don't
2021-04-22 11:02:24 <mps> hehe, apk info iwd
2021-04-22 11:02:47 <donoban> I saw that wicd is unmaintained, I used it long time ago :D
2021-04-22 11:02:55 <mps> though, it depends on dbus, lol
2021-04-22 11:03:34 <mps> and guess who is maintainer, rofl
2021-04-22 11:03:57 <donoban> iwd is a replacement for wpa_supplicant?
2021-04-22 11:04:34 <mps> iwd is NG wifi daemon
2021-04-22 11:05:42 <mps> it have dhcp client in it, FILS implementation and more
2021-04-22 11:06:16 <exception> But you use it without dbus?
2021-04-22 11:06:20 <exception> How
2021-04-22 11:06:26 <mps> exception: no
2021-04-22 11:06:54 <exception> O
2021-04-22 11:07:03 <mps> but I'm just testing version without dbus, and will add it to alpine in few days
2021-04-22 11:07:11 <PureTryOut[m]2> What is the policy for naming font packages? Should they be prefixed with ttf-?
2021-04-22 11:08:50 <mps> PureTryOut[m]2: that is right question, which I ask myself. I 'feel' font-... is best naming scheme but not sure
2021-04-22 11:09:16 <PureTryOut[m]2> Hmm both ttf- and font- are used a lot it seems
2021-04-22 11:09:28 <PureTryOut[m]2> Well, majority font-
2021-04-22 11:09:31 <PureTryOut[m]2> I guess I'll go for that then
2021-04-22 11:10:02 <mps> I agree :)
2021-04-22 11:54:48 <Hello72> donoban: wicd is very obsolete
2021-04-22 11:54:57 <Hello72> same with wireless-tools (which we should remove from setup-interfaces)
2021-04-22 11:58:40 <Ariadne> Hello72: wireless-tools is still used by ifupdown-ng to connect to non-WPA networks
2021-04-22 12:05:58 <donoban> hehe I only felt a little nostalgic about wicd
2021-04-22 12:21:23 <rahmanshaber[m]> Hi, is the server busy or i did something wrong in APKBUILD, arch64 is so there for the package
2021-04-22 12:21:23 <rahmanshaber[m]> https://pkgs.alpinelinux.org/packages?name=paperde&branch=edge
2021-04-22 12:25:47 <PureTryOut[m]2> Just wait, it takes a bit sometimes for the packages to appear on pkgs.a.o and in the repos
2021-04-22 12:26:33 <mps> heh, some people thinks that alpine devs only work for them ;>
2021-04-22 12:27:50 <tomleb> You don't ?!
2021-04-22 12:30:35 <Hello72> Ariadne: :|
2021-04-22 12:30:53 <Hello72> is there any reason to use it over iw?
2021-04-22 12:31:27 <Ariadne> probably not
2021-04-22 12:32:02 <Hello72> then we can probably also remove wext from kernel, which i think some distros have already done?
2021-04-22 12:32:13 <Ariadne> at some point ys
2021-04-22 12:32:31 <Ariadne> i'll look into switching ifupdown-ng
2021-04-22 12:32:36 <Ariadne> maybe we can do it in 3.15
2021-04-22 12:51:15 <Cogitri> What's the timeline for 3.14?
2021-04-22 12:51:21 <Cogitri> Can I still fit LLVM12 in? :)
2021-04-22 12:55:25 <exception> Milestone says something like 14 may or something like it
2021-04-22 13:20:23 <Ariadne> Cogitri: we are already in soft freeze
2021-04-22 13:20:41 <Ariadne> thats why i have been focusing on security.a.o
2021-04-22 13:48:27 <minimal> donoban: yes as skarnet said I'm working on package utmps-enablement. Haven't looked at firejail yet so not sure whether a simple rebuild to enable utmps support is all that is needed or whether any patching is needed.
2021-04-22 14:06:33 <Cogitri> Ariadne: Alrighty then
2021-04-22 14:07:59 <PureTryOut[m]2> Ariadne: what does soft freeze mean in this case?
2021-04-22 14:08:50 <Ariadne> PureTryOut[m]2: think very carefully about pushing big stuff
2021-04-22 14:09:08 <Ariadne> PureTryOut[m]2: if it can wait until after 3.14 release, at this point, it is better to wait
2021-04-22 14:09:20 <PureTryOut[m]2> And when is 3.14 due?
2021-04-22 14:09:27 <Ariadne> in may :)
2021-04-22 14:09:38 <Ariadne> alpineconf 2021 is basically "alpine 3.14 release party"
2021-04-22 14:09:38 <Ariadne> :)
2021-04-22 14:09:39 <PureTryOut[m]2> Oh that's quick damn, thanks
2021-04-22 14:24:31 <Ariadne> Cogitri: how risky is LLVM12?
2021-04-22 14:34:29 <PureTryOut[m]2> KDE Gear 21.04 got released today which I still want in really if CI goes green
2021-04-22 14:35:09 <Cogitri> Ariadne: Not sure really, haven't really looked at it much other than the release notes yet
2021-04-22 14:51:13 <donoban> minimal: ok
2021-04-22 14:51:42 <donoban> I use firejail for almost everything, I will try to investigate it
2021-04-22 14:52:17 <jvoisin> donoban: isn't firejail a trashfire security-wise?
2021-04-22 14:53:53 <donoban> uhM, I like the concept
2021-04-22 14:55:36 <Ariadne> what jvoisin said
2021-04-22 14:55:40 <Ariadne> don't use firejail
2021-04-22 14:55:42 <Ariadne> it's garbage
2021-04-22 14:55:47 <Ariadne> we should honestly rm it from alpine
2021-04-22 14:55:48 <Ariadne> :D
2021-04-22 14:55:54 <minimal> donoban: as firejail is using namespace and seccomp then that could be affecting its ability to access /var/run/utmp but as skarnet mentioned that file isn't actually used - firejail would need to be rebuilt to use the correct on that utmps manages
2021-04-22 14:57:14 <donoban> Ariadne jvoisin and do you like some app isolation alternive or just run them?
2021-04-22 14:57:31 <Ariadne> its called lxc
2021-04-22 14:57:37 <jvoisin> ^
2021-04-22 14:58:50 <donoban> uhM, lxc containers? I should try them but I don't hope that graphics/sound are easily handled
2021-04-22 14:59:56 <jvoisin> lxc: https://linuxcontainers.org/
2021-04-22 15:00:12 <jvoisin> https://linuxcontainers.org/lxc/introduction/ even
2021-04-22 15:02:54 <donoban> ok I will try it
2021-04-22 15:04:40 <jvoisin> Ariadne: I agree with removing firejail from Alpine. It's useless at best, often harmful
2021-04-22 15:06:12 <Hello71> i thought the main problem with firejail is it's basically free privilege escalation for anyone who can run it (which is everybody by default)
2021-04-22 15:06:37 <Hello71> but other than that, how did you enjoy the play
2021-04-22 15:06:49 <donoban> you need to enable it for custom users
2021-04-22 15:07:36 <donoban> it has a /etc/firejail/firejail.users
2021-04-22 15:08:06 <ericonr> https://github.com/netblue30/firejail/commit/fb9f2a5fb3ac1ebbb14302ecdf3c840b70b090da#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810 <-- their vuln "fix" for overlayfs kinda bothered me :/
2021-04-22 15:08:19 <donoban> I'm agree that it can be a risk for systems with many local users
2021-04-22 15:09:38 <Hello71> donoban: yes but by default this file does not exist (at least upstream), so everybody can use
2021-04-22 15:11:27 <donoban> hM, I don't know
2021-04-22 15:11:34 <donoban> I'm gonna try removing it
2021-04-22 15:12:51 <donoban> yep it has that behaviour, maybe it should created by default
2021-04-22 15:13:20 <donoban> but well the common usage is run sudo firecfg after install, wich creates it
2021-04-22 15:18:41 <donoban> ericonr: well it's just disabled until properly fixed :\ safe solution :D
2021-04-22 15:19:03 <Ariadne> the safe solution is to rm firejail
2021-04-22 15:19:08 <Ariadne> but people keep bringing it back
2021-04-22 15:19:10 <Ariadne> :p
2021-04-22 15:19:36 <jvoisin> replace it with an empty script
2021-04-22 15:19:38 <skarnet> "firejail" sounds kinda secure... and it actually gains privileges?
2021-04-22 15:19:57 <skarnet> just for using such a name and gaining privileges it should go to trash jail
2021-04-22 15:19:58 <donoban> but the privilege gain is from the local user
2021-04-22 15:20:07 <skarnet> do I look like I care
2021-04-22 15:20:16 <donoban> not for the app you are running "firejailed"
2021-04-22 15:20:31 <donoban> at least with other cve's not sure with this overlayfs bug
2021-04-22 15:20:42 <skarnet> yeah well that would be a very, very low bar to clear now wouldn'tit
2021-04-22 15:20:58 <skarnet> "ohey I made a container that doesn't give root to the contained app!"
2021-04-22 15:21:06 <skarnet> applause please
2021-04-22 15:23:53 <ericonr> it needs privileges to set up the sandbox around the program
2021-04-22 15:24:21 <ericonr> for that matter, bwrap on some distros is suid as well
2021-04-22 15:24:30 <donoban> well
2021-04-22 15:24:40 <skarnet> those programs should run as daemons started by root and have a client-server model
2021-04-22 15:24:49 <skarnet> no suid required
2021-04-22 15:24:51 <donoban> I know that there are better isolation alterantives, firejail is just very easy to use
2021-04-22 15:25:05 <ericonr> oh, undoubtedly
2021-04-22 15:25:12 <Hello71> that's just an argument against the sudo model
2021-04-22 15:25:29 <Hello71> i actually don't know of any firejail vulnerabilities specifically related to suid
2021-04-22 15:25:30 <donoban> the passwordless sudo hehe
2021-04-22 15:25:33 <skarnet> yes, yes it is
2021-04-22 15:25:42 <jvoisin> bwrap doesn't have a horrible history of trivial privesc
2021-04-22 15:26:09 <Hello71> the problem is that firejail offers too much unchecked functionality, which it could do just as well (poorly) as a daemon
2021-04-22 15:26:14 <donoban> uhM, I think that they imply privlege scalation due the suid
2021-04-22 15:30:34 <Ariadne> all i am hearing here is git rm */firejail/*
2021-04-22 15:30:37 <Ariadne> :)
2021-04-22 15:31:16 <donoban> haha there are also some comments about firejail and utmps ;)
2021-04-22 15:31:27 <Ariadne> skarnet: what would be great is if we had capsicum in alpine
2021-04-22 15:31:52 <Ariadne> skarnet: then we could have a daemon which hands out permissions (as sealed capability descriptors passed via SCM_RIGHTS) as a client-server model
2021-04-22 15:33:20 <skarnet> maybe
2021-04-22 15:34:07 <skarnet> I'm still of the opinion that capabilities and similar initiatives have a lesser bang for the buck than just using the unix basic permissions the right way
2021-04-22 15:35:16 <Hello71> like suid? :p
2021-04-22 15:35:27 <Hello71> "the right way to use suid is not to"
2021-04-22 15:35:37 <skarnet> exactly
2021-04-22 15:36:00 <skarnet> isn't it awesome when you try to gotcha me and realize we were in agreement all along?
2021-04-22 15:36:16 <ericonr> capabilities suck because CAP_SYS_ADMIN was overloaded :/
2021-04-22 15:36:23 <skarnet> that as well
2021-04-22 15:38:06 <mps> yes, firejail is not serious solution to security
2021-04-22 15:38:54 <mps> I used it about 4-5 years ago on debian a little for firefox but removed after few days
2021-04-22 15:39:10 <mps> qemu is solution
2021-04-22 15:39:29 <skarnet> ah yes, the legendary minimalist and lightweight solution
2021-04-22 15:39:36 <donoban> :D
2021-04-22 15:39:40 <donoban> Qubes OS
2021-04-22 15:40:14 <mps> but for 'simple' isolation I use lxc
2021-04-22 15:54:35 <mps> aiee, looks like firefox finally doesn't crash on armv7
2021-04-22 16:24:12 <tmlind> wow yeah looks like i can now view the local weather forecast that uses javascript with firefox
2021-04-22 16:51:14 <mps> tmlind: nice to hear
2021-04-22 17:05:18 <SpaceToast> \o latest edge dnsmasq doesn't print its version with `dnsmasq --version`, which breaks lxd bringing its network up
2021-04-22 17:05:42 <SpaceToast> this should probably be added to the check() function (just `dnsmasq --version | grep -q "$pkgver"` should do, I think)
2021-04-22 17:11:01 <mps> hah, yes
2021-04-22 17:11:11 <mps> interesting
2021-04-22 17:12:09 <SpaceToast> I built it plainly with my scuffed metabuild system from HEAD and didn't have any such issues, so it's probably a patch or something similar breaking it
2021-04-22 17:16:53 <mps> hmm, don't see fix on https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary
2021-04-22 17:21:02 <SpaceToast> let me see if building the tag does anything
2021-04-22 17:22:29 <SpaceToast> building the tag itself also works as expected, so it's definitely something in the APKBUILD or a patch or something like that that's misbehaving
2021-04-22 17:24:53 <mps> bld/get-version
2021-04-22 17:26:25 <mps> unknown sort type
2021-04-22 17:27:13 <SpaceToast> aha, that'd do it
2021-04-22 17:27:28 <SpaceToast> I build from git, and it uses git logic in those scenarios, so that also explains it
2021-04-22 17:27:34 <mps> it needs coreutils in makedepends to 'find' version
2021-04-22 17:28:29 <mps> or patching bld/get-version to fix sort
2021-04-22 17:28:42 <SpaceToast> makes sense, yeah
2021-04-22 17:29:01 <mps> coreutils is easier ;)
2021-04-22 17:29:49 <mps> will fix it later in evening, thanks for report
2021-04-22 17:29:57 <SpaceToast> ^^ nw \o
2021-04-22 17:30:35 <mps> btw, nice to see you again
2021-04-22 17:30:46 <SpaceToast> thanks :)
2021-04-22 17:31:06 <SpaceToast> I'm not really around per se, work and so on and so forth, but if I find something in edge that isn't in a release, it's usually best if I at least make sure people are aware, eh
2021-04-22 17:31:50 <mps> yes
2021-04-22 17:32:41 <c705> Ariadne: does the new cve tracking system pick up when the latest lts kernel is avaliable from upstream?
2021-04-22 17:33:00 <Ariadne> c705: no
2021-04-22 17:33:46 <Ariadne> c705: it only tracks CVEs
2021-04-22 17:34:05 <Ariadne> c705: and we are still associating upstream CPE matches with our own source package names
2021-04-22 17:34:29 <c705> do you think it would be a good idea to have something like that in place? linux-lts-5.10.29-r0 is the latest avaliable under 3.13x but upstream is shipping .32
2021-04-22 17:35:25 <Ariadne> no, i don't
2021-04-22 17:35:38 <Ariadne> releases are releases
2021-04-22 17:35:38 <c705> why?
2021-04-22 17:35:44 <Ariadne> we will update the kernel when we update the kernel
2021-04-22 17:36:18 <c705> but .29 is old. it doesn't get security fixes
2021-04-22 17:36:31 <Ariadne> yes
2021-04-22 17:37:06 <Ariadne> and when we do 3.13.x update we bump the kernel to latest version at that tim
2021-04-22 17:37:08 <Ariadne> e
2021-04-22 17:38:00 <c705> but how often does that happen? doesn't the kernel remain susceptable during that time when upstream ships a new version and we decide we're going to update 3.13
2021-04-22 17:38:29 <Ariadne> if there is a CVE in linux
2021-04-22 17:38:33 <Ariadne> then we would update it
2021-04-22 17:39:08 <c705> and the new cve tracker would catch that I imagine?
2021-04-22 17:40:16 <Ariadne> ideally, yes
2021-04-22 17:40:39 <Ariadne> however, i suspect a CPE rewrite rule will be needed to match it up
2021-04-22 17:41:07 <Ariadne> if you are aware of a recent linux CVE, i can check to see
2021-04-22 17:41:09 <Ariadne> :)
2021-04-22 17:41:11 <c705> okay, thanks for the info
2021-04-22 17:41:44 <c705> i am not, but I have often seen a vulnerable kernel shipped with lts alpine, last I remember was during the sudo fiasco last year
2021-04-22 17:42:04 <c705> I had to push hard to get that patched, but I understand now if I have a cve it will be easier to do
2021-04-22 17:43:36 <c705> Ariadne: you can actually check CVE-2021-29155. not sure if that affects 5.10.x
2021-04-22 17:43:51 <Ariadne> you can check it too
2021-04-22 17:43:58 <Ariadne> https://security.alpinelinux.org/vuln/ CVE-2021-29155
2021-04-22 17:44:00 <Ariadne> er
2021-04-22 17:44:02 <Ariadne> https://security.alpinelinux.org/vuln/CVE-2021-29155
2021-04-22 17:44:28 <Ariadne> answer: no match rules
2021-04-22 17:44:29 <Ariadne> :(
2021-04-22 17:45:38 <Ariadne> no CPE data at all
2021-04-22 17:45:40 <Ariadne> wow
2021-04-22 17:45:49 <Ariadne> good work US government
2021-04-22 17:46:57 <mps> I think this is fixed in linux-edge 5.11.16 ;)
2021-04-22 17:47:04 <Ariadne> no secfixes data at all for this CVE
2021-04-22 17:47:06 <Ariadne> er
2021-04-22 17:47:08 <Ariadne> for linux-lts
2021-04-22 17:47:15 <c705> yeah, right, that makes sense
2021-04-22 17:47:19 <Ariadne> so i dont think any scanner is triggering
2021-04-22 17:47:29 <Ariadne> on linux-lts
2021-04-22 17:47:31 <Ariadne> hmmph
2021-04-22 17:47:38 <Ariadne> you can do umm
2021-04-22 17:47:48 <Ariadne> curl 'https://services.nvd.nist.gov/rest/json/cve/1.0/CVE-2021-29155' | jq
2021-04-22 17:48:15 <c705> yeah, i was using that as an example, but it doesn't affect 5.10.x
2021-04-22 17:48:41 <Ariadne> if you do
2021-04-22 17:48:44 <Ariadne> curl 'https://services.nvd.nist.gov/rest/json/cve/1.0/CVE-2021-29155' | jq .result.CVE_Items[0].configurations.nodes[0]
2021-04-22 17:48:48 <c705> I don't see anything recent, but if something severe comes through, I'll check. i keep an eye on oss-security
2021-04-22 17:48:48 <Ariadne> given some CVE
2021-04-22 17:48:58 <Ariadne> it will output the CPE rules
2021-04-22 17:49:11 <Ariadne> we consume those CPE rules and map them to alpine source package names (APKBUILDs)
2021-04-22 17:49:49 <Ariadne> but that CVE has no CPE rules
2021-04-22 17:50:17 <Ariadne> so we will have to check kernel CVEs until we find a CPE match rule
2021-04-22 17:50:25 <Ariadne> then we can set up the mapping
2021-04-22 17:51:30 <Ariadne> hope that explains it :)
2021-04-22 17:51:45 <c705> yeah, much better than what was there before (nothing). appreciate the efforts
2021-04-22 18:27:06 <Danct12> hi, in order for wifi to work on the pi4 linux-firmware-cypress needs to be installed, can anyone look at this merge request?
2021-04-22 18:27:08 <Danct12> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20738
2021-04-22 18:29:58 <Ariadne> i left a review
2021-04-22 18:32:34 <mps> apk add linux-firmware-cypress?
2021-04-22 18:34:15 <mps> what if someone doesn't like to use wifi?
2021-04-22 18:35:51 <Danct12> i guess we should remove linux-firmware-brcm dependency from the kernel then
2021-04-22 18:36:39 <mps> probably
2021-04-22 18:37:25 <mps> SpaceToast: pushed fix for dnsmasq, hope it will be on mirrors in 15-30 minutes
2021-04-22 18:37:46 <SpaceToast> I'll try to remember to check then, if you don't hear from me it's because I forgot
2021-04-22 18:38:00 <mps> :)
2021-04-22 18:55:47 <SpaceToast> mps: looks good from what I'm seeing
2021-04-22 19:02:49 <mps> SpaceToast: thanks for testing and confirm
2021-04-22 20:01:39 <maxice8> Why always `exit 0` in post- and pre- scripts?
2021-04-22 20:02:39 <skarnet> don't exit 0 if you encounter a sufficiently serious error that you want to fail the package installation
2021-04-22 20:03:15 <skarnet> I suppose most nonzero exit codes in those scripts aren't that fatal. :)
2021-04-22 21:39:33 <[[sroracle]]> regarding bwrap, it doesn't need suid on alpine last i checked because alpine allows unprivileged users to create new user namespaces. would be nice to migrate towards removing the suid bit on it
2021-04-22 21:39:47 <[[sroracle]]> (which i have been using that way on Adélie for months now, including building software inside it :)
2021-04-22 23:21:11 <maxice8> I think it already is
2021-04-22 23:50:48 <[[sroracle]]> ah, you switched it over in december :) thank you for that
2021-04-22 23:53:43 <[[sroracle]]> maxice8: i think options=suid should be removed in that case so that it doesn't sneak back in
2021-04-23 00:47:42 <maxice8> nice catch
2021-04-23 00:49:17 <maxice8> take the opportunity and see if tests can be enabled too
2021-04-23 05:19:37 <rahmanshaber[m]> Can anyone see why this package's arch64 is missing
2021-04-23 05:19:37 <rahmanshaber[m]> https://pkgs.alpinelinux.org/packages?name=paperde&branch=edge
2021-04-23 05:23:05 <ikke> aarch64 builder is hanging on openjdk
2021-04-23 05:27:20 <rahmanshaber[m]> any idea when it will be free?
2021-04-23 08:18:13 <Cogitri> Ariadne: Since you know the berkeley-db situation better: Mind commenting on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8569#note_154036 ?
2021-04-23 08:50:40 <Ariadne> it's banned, there is no room for debate
2021-04-23 08:52:35 <Cogitri> Yes, it's banned, but I wasn't sure what's the reason for it
2021-04-23 08:52:53 <Cogitri> They mentioned that upstream doesn't see the problem with using berkeley and as such won't swith away from it
2021-04-23 08:55:28 <Ariadne> why do we need to package AGPL web apps?
2021-04-23 08:57:02 <Ariadne> but sure, Thermi is right that AGPL is compatible with AGPL
2021-04-23 09:00:19 <Ariadne> Cogitri: the talking point is likely something like "distros are deprecating and *removing* bsddb"
2021-04-23 09:14:22 <Cogitri> Right, but why are they removing it?
2021-04-23 09:20:31 <donoban> Does anybody know how to search where "XTestGrabControl" is included? I thought it was on /usr/lib/libXtst.so but still complaining about undefined symbol
2021-04-23 09:20:58 <Ariadne> Cogitri: because AGPL for a *library* is insane
2021-04-23 09:28:03 <donoban> it seems there: 00000000000044ea T XTestGrabControl
2021-04-23 09:34:12 <Ariadne> are the -l flags in the right order?
2021-04-23 09:34:32 <donoban> uhM, I don't know
2021-04-23 09:34:58 <donoban> I tpaste the link command
2021-04-23 09:35:02 <donoban> I can*
2021-04-23 09:36:12 <donoban> https://tpaste.us/g6r5
2021-04-23 09:37:17 <donoban> it seems that puts libxtst.so between .a files without any -l flag
2021-04-23 09:38:17 <donoban> but there are others .so files
2021-04-23 09:38:34 <donoban> I don't know exactly how to tell cmake to add it
2021-04-23 09:38:55 <Ariadne> libtg_owt.so is not linked against libXtst
2021-04-23 09:39:01 <Ariadne> thats your problem
2021-04-23 09:39:22 <donoban> ah, so I need to add id and rebuild tg_owt?
2021-04-23 09:39:33 <Ariadne> yes
2021-04-23 09:39:40 <donoban> ok, thanks Ariadne
2021-04-23 09:39:49 <donoban> I hope it works finally :D
2021-04-23 09:47:08 <donoban> [29/29] Linking CXX executable telegram-desktop , No errors! great
2021-04-23 09:47:50 <donoban> (4/4) Upgrading telegram-desktop (2.4.11-r0 -> 2.7.1-r0) :D
2021-04-23 11:58:27 <ncopa> Cogitri: i havent started bootstrap the 3.14 builders yet, so i think it should be ok to squeeze in llvm12
2021-04-23 11:58:40 <ncopa> as i understand there was no big/dramatic changes there
2021-04-23 11:59:01 <ncopa> and it will probably help maintain the stable branch in the future
2021-04-23 12:01:08 <Cogitri> Okay 👍️
2021-04-23 12:05:15 <caskd> Did anything recently happen with openrc on edge? init.d/networking disappeared
2021-04-23 12:05:43 <ikke> Hmmm, you are the 2nd to face this
2021-04-23 12:07:21 <ikke>  Building a docker netbox with aports packages instead of everything with pip: 2 minutes build time instead of 20
2021-04-23 12:07:35 <ikke> docker netbox image
2021-04-23 12:09:59 <caskd> reinstalling the package is fine
2021-04-23 12:10:04 <caskd> odd that it happened though
2021-04-23 12:10:15 <ikke> Yes k
2021-04-23 13:38:25 <Habbie> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12047 - Packages in community that link to OpenSSL and are GPL but have no exception
2021-04-23 13:38:37 <Habbie> pdns and pdns-recursor do have that exception, but apparently not in a place where you could spot it
2021-04-23 13:38:39 <Habbie> how can i help?
2021-04-23 13:38:41 <Habbie> (i'm with powerdns)
2021-04-23 13:45:47 <Ariadne> just mak a note on the issuee
2021-04-23 13:46:47 <Ariadne> that was just a list of packages to check based on SPDX data
2021-04-23 13:47:01 <Ariadne> if you say there is an OpenSSL exception, you can add the OpenSSL SPDX tag to $license
2021-04-23 13:47:28 <Ariadne> if you want to go that far anyway :)
2021-04-23 13:54:33 <Habbie> that sounds like it would enable automation
2021-04-23 13:56:46 <Habbie> it also looks like a bunch of work, so i'll make a ticket for ourselves and comment on the issue
2021-04-23 13:59:13 <Habbie> thanks Ariadne
2021-04-23 13:59:52 <Ariadne> yes it seems that the powerdns way of doing the openssl exception is not already covered by SPDX
2021-04-23 14:00:24 <Ariadne> i found one for openvpn though :)
2021-04-23 14:00:56 <Habbie> we just put a bunch of text in a lot of comments
2021-04-23 14:01:04 <Habbie> and in our debian/ dirs ;)
2021-04-23 14:04:10 <Ariadne> there is text in NOTICE
2021-04-23 14:05:07 <Habbie> ah there it is
2021-04-23 14:05:13 <Habbie> 'git grep -i openssl' on our tree was overwhelming so i missed it
2021-04-23 14:12:02 <Habbie> would it be frowned upon if in https://gitlab.alpinelinux.org/Habbie/aports/-/pipelines/79809
2021-04-23 14:12:22 <Habbie> i marked it WIP and re-enabled aarch64 just to have your Gitlab CI show me what's broken?
2021-04-23 14:14:45 <ikke> No
2021-04-23 14:14:53 <Hello71> that's fine
2021-04-23 14:15:56 <Habbie> thanks
2021-04-23 14:26:56 <Ariadne> by the way we love when upstream acts as package maintainer in alpine
2021-04-23 14:27:04 <Ariadne> so, you know, feel free to claim maintainership of powerdns :p
2021-04-23 14:29:03 <mps> especially if upstream use alpine ;)
2021-04-23 14:30:04 <Ariadne> well yeah :p
2021-04-23 14:31:12 <mps> hm, question: how to cut out newline character when reading line from file in ash?
2021-04-23 14:31:45 <mps> (use Perl, Luke :) )
2021-04-23 14:37:30 <mps> only sed?
2021-04-23 14:37:34 <skarnet> `cat file` will chomp; read line will chomp as well
2021-04-23 14:38:09 <Habbie> Ariadne, i was just pondering (walking outside does that to a person) i should at least -notice- when you mark things broken :)
2021-04-23 14:38:23 <Ariadne> :D
2021-04-23 14:38:24 <Habbie> mps, we don't use alpine a lot, sorry :)
2021-04-23 14:38:33 <mps> 'cat with chomp'? where is chomp?
2021-04-23 14:38:41 <skarnet> mps: it's normally pretty rare that newlines are an annoyance in shell, if there's ONE thing that the shell gets more or less right, it's ease of working around newlines
2021-04-23 14:38:51 <Habbie> Ariadne, for debian we have a buildbot job that scans their 'about to be deleted' yaml, i think we should be including more distros
2021-04-23 14:38:54 <skarnet> no, the backticks will autochomp
2021-04-23 14:39:12 <skarnet> i.e. a = `cat file` -> the last newline isn't in $a
2021-04-23 14:39:24 <Habbie> besides 'open tickets' and 'marked broken in the APKBUILD', can you suggest any other places we could check automatically to see that our help might be welcome?
2021-04-23 14:39:44 <mps> skarnet: I did this but looks like I messed something
2021-04-23 14:40:04 <skarnet> if you have 2 newlines at the end you'll still have to deal with one :D
2021-04-23 14:40:19 <Ariadne> Habbie: not sure :)
2021-04-23 14:40:43 <mps> skarnet: no, just one. probably messed something else. thanks for hint
2021-04-23 14:40:55 <ikke> Habbie: officially we should make tickets and assign them to the maintainer
2021-04-23 14:41:57 <Habbie> ikke, right, but i see that hasn't happened for existing tickets and the current maintainer either :)
2021-04-23 14:42:05 <mps> Habbie: I was long time debian user and now I'm sorry for those who didn't swithed to alpine, yet :)
2021-04-23 14:42:23 <ikke> Yes, that's something we should improve on
2021-04-23 14:42:24 <Habbie> should i have arch="all" or no arch line at all in my APKBUILD?
2021-04-23 14:42:32 <ikke> Former
2021-04-23 14:42:35 <Habbie> ta
2021-04-23 14:45:06 <mps> skarnet: hah, yes. I messed something else in script. thanks again for hint
2021-04-23 14:45:24 <skarnet> np
2021-04-23 14:53:35 <Habbie> mm, gitlab search has RSS
2021-04-23 14:55:18 <Ariadne> please be nice to our servers if you use that :p
2021-04-23 14:55:37 <Habbie> i'll trust evolution-rss to be nice :)
2021-04-23 14:57:26 <Habbie> default is 60 minutes
2021-04-23 14:57:34 <Ariadne> there was a security company that was scraping our secfixes data by spidering the cgit
2021-04-23 14:57:36 <Ariadne> :D
2021-04-23 14:58:00 <Habbie> hah
2021-04-23 15:03:07 <mps> got arm32 workstation with alpine edge fully working, 4GB ram, 8 cpus, 1920x1080 display, 16GB emmc. not bad :)
2021-04-23 15:05:00 <Habbie> hmm, Merge Request search does not have rss
2021-04-23 15:08:05 <Habbie> do you prefer a single squashed commit once I'm done? or does that depend on how many things I changed in an APKBUILD?
2021-04-23 15:11:39 <mps> Habbie: depends, if you make related and not big final change than squash
2021-04-23 15:11:58 <Habbie> mps, thanks, i'll use my usual judgment then
2021-04-23 15:12:30 <mps> heh, I wanted to say 'use common sense' :)
2021-04-23 15:12:47 <ikke> fixes to earlier commits should be fixed up
2021-04-23 15:13:05 <mps> 
ACTION is known as kind person ;)

2021-04-23 15:13:09 <Habbie> ikke, of course, coherent story and all
2021-04-23 15:13:10 <Habbie> mps, haha
2021-04-23 15:17:19 <Habbie> find: unrecognized: -ls
2021-04-23 15:17:20 <Habbie> oh no
2021-04-23 15:19:23 <Habbie> ah, the APKBUILD i stole some code from installs findutils :)
2021-04-23 16:00:35 <nmeum> ikke: could you do me a favor and run `abuild snapshot` for !20656 ? 🥺
2021-04-23 16:05:10 <ikke> done
2021-04-23 16:05:30 <ikke> I think you should be able to get an account on dev.a.o so that you can do it yourself
2021-04-23 16:14:30 <nmeum> yeah that would be neat
2021-04-23 16:14:55 <nmeum> can you just extract my ssh key from my gitlab account or should I send it to you?
2021-04-23 16:15:02 <nmeum> thanks though for taking care of it
2021-04-23 17:40:44 <Thermi> Do you have a script for building X packages from aports while resolving interdependencies and ordering them correctly?
2021-04-23 17:41:05 <Thermi> e.g. I want to build B which depends on A, and I don't have A. So the script automatically builds A first
2021-04-23 17:41:29 <ikke> ap builddirs (from aports-lua)
2021-04-23 17:41:34 <Thermi> thx
2021-04-23 17:41:52 <ikke> that script only lists the order to build them in ftr
2021-04-23 17:42:15 <Thermi> was lua-aports
2021-04-23 17:42:28 <ikke> oh, thanks, yes
2021-04-23 17:55:23 <Thermi> Hrmpf. No tool to just feed output into xargs abuild or something
2021-04-23 17:55:23 <Thermi> :(
2021-04-23 17:56:02 <ikke> That's what we do for our CI
2021-04-23 17:56:08 <ikke> or at least, something like that
2021-04-23 18:36:29 <Habbie> who is Leo and why are they pushing to my MR? :) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20756
2021-04-23 18:38:49 <mps> Habbie: alpine developer, maxice8 here
2021-04-23 18:39:24 <Habbie> maxice8, hi! you pushed to my MR, a rebase i think? but you reverted part of my work :)
2021-04-23 18:39:34 <maxice8> Yes it was a rebase
2021-04-23 18:39:51 <maxice8> Apologies if it removed part of the work
2021-04-23 18:40:05 <Habbie> or perhaps i had not pushed that yet, that's also possible, i realise now
2021-04-23 18:40:17 <ikke> maxice8: do you use --force-with-lease?
2021-04-23 18:40:20 <Habbie> anyway, i pushed again, and gitlab says i need to rebase, but there's nothing to rebase
2021-04-23 18:41:17 <maxice8> @Ikke no
2021-04-23 18:41:25 <ikke> maxice8: maybe a good habbit to learn :)
2021-04-23 18:41:30 <Habbie> i should also learn that habit
2021-04-23 18:41:39 <maxice8> I have it by default but have -f for `maintainer-push`
2021-04-23 18:41:42 <Hello71> Habbie: your commit's parent is 8919461d, master is at 0239e25b
2021-04-23 18:42:08 <Habbie> i see my mistake
2021-04-23 18:42:14 <Habbie> habbie git@gitlab.alpinelinux.org:Habbie/aports.git (fetch)
2021-04-23 18:42:16 <Habbie> habbie git@gitlab.alpinelinux.org:Habbie/aports.git (push)
2021-04-23 18:42:19 <Habbie> origin git@gitlab.alpinelinux.org:Habbie/aports.git (fetch)
2021-04-23 18:42:20 <Habbie> origin git@gitlab.alpinelinux.org:Habbie/aports.git (push)
2021-04-23 18:42:23 <Habbie> spot the difference :D
2021-04-23 18:42:28 <maxice8> $ git config --global --get-regexp '^alias.p'
2021-04-23 18:42:29 <maxice8> alias.p push --force-with-lease
2021-04-23 18:42:38 <ikke> Habbie: I guess the answer is no :P
2021-04-23 18:42:44 <Habbie> ikke, :)
2021-04-23 18:43:49 <maxice8> http://ix.io/30XK I just use this
2021-04-23 18:44:32 <ikke> blank
2021-04-23 18:45:35 <maxice8> I need a new paste provider
2021-04-23 18:46:42 <Habbie> i see it but it took a while to load
2021-04-23 18:47:04 <ikke> for me it remains blank
2021-04-23 18:48:47 <maxice8> try again, works now for me
2021-04-23 18:50:01 <Habbie> now it shows me garbage
2021-04-23 18:50:10 <mps> tpaste works https://tpaste.us/49l1
2021-04-23 19:07:05 <mps> hmm https://gitlab.alpinelinux.org/mps/aports/-/jobs/378124#L125 x86 doesn't have asm/hwcaps.h ?
2021-04-23 19:07:37 <mps> hwcap.h*
2021-04-23 19:15:34 <Thermi> bpaste.net is also a good paste provider
2021-04-23 19:50:21 <donoban> Hi guys
2021-04-23 19:50:30 <ikke> o/
2021-04-23 19:50:38 <skarnet> so as I was saying it's obviously donoban's fault
2021-04-23 19:50:42 <donoban> I wanted to revert two commits but for not adding more revert commits I decided to reset
2021-04-23 19:50:50 <donoban> yeah sure
2021-04-23 19:51:03 <donoban> if something is broken 99% I am the responsable :D
2021-04-23 19:51:16 <skarnet> always blame the person who just joined
2021-04-23 19:51:30 <skarnet> if you don't know why, they do!
2021-04-23 19:51:36 <donoban> well, can I push after rebase my repo or gitlab will always reject it?
2021-04-23 19:51:48 <donoban> rebase/reset
2021-04-23 19:52:19 <donoban> ohh
2021-04-23 19:52:22 <donoban> --force did the trick
2021-04-23 19:52:41 <skarnet> when in doubt, use the Force
2021-04-23 19:52:47 <donoban> ;)
2021-04-23 19:53:43 <donoban> I try two or three times on local until works, then push and instantly see trivial errors
2021-04-23 19:53:51 <donoban> trying to fix that errors all fails :(
2021-04-23 19:53:59 <donoban> it's a nightmare
2021-04-23 19:54:04 <skarnet> git is a harsh mistress
2021-04-23 19:54:28 <donoban> well my problem is with abuild patching
2021-04-23 19:55:03 <donoban> >>> tg_owt: cmake_fixes.patch
2021-04-23 19:55:05 <donoban> patching file CMakeLists.txt
2021-04-23 19:55:11 <donoban> he is happy this time :)
2021-04-23 20:16:26 <donoban> the depencies of a package are gerenated when building it right?
2021-04-23 20:17:29 <donoban> I wonder what is really needed to add in depends=""
2021-04-23 20:17:53 <Thermi> are /var/run and /run/ considered different?
2021-04-23 20:18:04 <Thermi> On some distros the latter is symliked to the former
2021-04-23 20:18:13 <donoban> I think that /var/run is a symlink
2021-04-23 20:18:26 <donoban> 22 09:23 run -> /run
2021-04-23 20:18:29 <Thermi> It is.
2021-04-23 20:18:34 <skarnet> basically /run made /var/run obsolete, so it should be a symlink nowadays
2021-04-23 20:18:37 <skarnet> not that it really matters
2021-04-23 20:19:10 <skarnet> the point of those directories is that they're writable (but only by root) even when / is read-only
2021-04-23 20:19:54 <skarnet> historically /var/run was used because /var is by definition writable, but at some point people realized they needed an *early* writable filesystem, before /var is mounted
2021-04-23 20:20:00 <skarnet> and so /run was created
2021-04-23 20:20:30 <skarnet> (and it's normally a tmpfs)
2021-04-23 20:20:56 <skarnet> and since the amount of data in /var/run has always been very small, it doesn't make much sense to keep a separate directory
2021-04-23 20:21:14 <skarnet> so, everything goes to /run and there's a symlink to keep everyone happy.
2021-04-23 20:27:02 <donoban> https://gitlab.alpinelinux.org/donoban/aports/-/jobs/378199 ouch this failed but it doesn't seem "my fault"
2021-04-23 20:27:56 <donoban> I don't know what happened :\
2021-04-23 20:28:12 <donoban> (dinner time)
2021-04-23 20:32:09 <Thermi> I have an issue here where openrc-run doesn't do the checkpaths in start_pre
2021-04-23 20:33:08 <Thermi> Also, stdout and stderr are not captured by syslog
2021-04-23 20:36:18 <skarnet> stdout and stderr are never captured by syslog, you need a specific service setup if that's what you want
2021-04-23 20:38:13 <Thermi> Hrm.
2021-04-23 20:38:27 <Thermi> not even as part of openrc?
2021-04-23 20:55:23 <skarnet> openrc doesn't do magic, it can't plug stuff that is not syslog into syslog XD
2021-04-23 20:55:48 <skarnet> there's a specific program for that, called 'logger', idr which package provides it
2021-04-23 20:56:12 <skarnet> but tbh if a daemon is logging to stderr (which is the right thing), redirecting its output to syslog is a waste
2021-04-23 20:56:40 <skarnet> better use a dedicated logger reading on the daemon's stderr, so you don't have to pay the cost of the fan-in fan-out mechanism of syslog and your logs are more greppable
2021-04-23 20:57:02 <mps> logger is in util-linux
2021-04-23 21:03:19 <skarnet> ah right
2021-04-23 21:04:39 <Thermi> skarnet: you know, openrc executing a service can plug stdin, stdout, and stderr anywhere they want. Like systemd can do.
2021-04-23 21:05:40 <skarnet> they can redirect it to any file descriptor, yes, but syslog is not a regular file descriptor.
2021-04-23 21:05:47 <skarnet> it's a specific API.
2021-04-23 21:10:31 <Thermi> skarnet: I know that. You can do a select over fds though. It is possible. Just not implemented in openrc I guess.
2021-04-23 21:11:21 <donoban> Thermi: your problem with checpaths is related with /var/run?
2021-04-23 21:11:51 <Thermi> donoban: I do not know if it is caused by anything having to do with the path or openrc just not running that section. I have to check that first.
2021-04-23 21:12:06 <Thermi> It's a new problem though.
2021-04-23 21:12:15 <donoban> Well I think that they did some some fixes related with checpath and symblinks
2021-04-23 21:12:22 <skarnet> it's not implemented for good reason: 1) it's useless, because daemons that log to stderr know what they're doing and generally do NOT want their logs to go to syslog, else they would use syslog(). 2) there's already a tool to do that, logger.
2021-04-23 21:12:30 <donoban> it broke tinyproxy start and other services
2021-04-23 21:12:57 <Thermi> At least throw an error goddamnit.
2021-04-23 21:13:14 <Thermi> This "silent failure" thing is the worst.
2021-04-23 21:14:22 <donoban> /usr/lib/libtg_owt.so.0.0.0: undefined reference to `webrtc::VectorDifference_SSE2_W32(unsigned char const*, unsigned char const*)'
2021-04-23 21:14:24 <donoban> collect2: error: ld returned 1 exit status
2021-04-23 21:14:30 <donoban> the nightmare doesn't end :\
2021-04-23 21:24:34 <Habbie> maxice8, thanks!
2021-04-23 21:25:00 <maxice8> welcome
2021-04-23 21:25:48 <Habbie> maxice8, i believe 20756 should also be good to go now
2021-04-23 21:26:04 <maxice8> I'll look at it soon, I'm looking at !20755
2021-04-23 21:26:17 <ikke> !20756
2021-04-23 21:26:24 <Habbie> sure, did not mean to rush, mentioned in case you saw the flux on it earlier and figured i might not be done :)
2021-04-23 21:29:23 <donoban> does anyone know if ppc64le supports SSE2?
2021-04-23 21:29:36 <Thermi> SSE2 is x86(_64) specific
2021-04-23 21:29:44 <donoban> ok
2021-04-23 21:29:46 <Thermi> Their feature set is probably called something different
2021-04-23 21:30:00 <maxice8> @Ikke: ty
2021-04-23 21:30:11 <ikke> :)
2021-04-23 21:30:21 <Habbie> maxice8, i see that you rebase before merge - is that so you don't generate a merge commit?
2021-04-23 21:30:34 <maxice8> yes, no merge commits are allowed
2021-04-23 21:30:40 <Habbie> ah
2021-04-23 21:30:50 <Habbie> is the rebase a button in gitlab?
2021-04-23 21:31:35 <maxice8> yes but I use a script that uses glab which uses the API
2021-04-23 21:31:36 <Habbie> no, because we talked about push -f earlier
2021-04-23 21:31:37 <maxice8> http://ix.io/2Twz
2021-04-23 21:31:51 <ikke> Habbie: yes, we rebase everything in aports
2021-04-23 21:31:58 <Habbie> maxice8, ah
2021-04-23 21:31:58 <maxice8> gitlab checks if it can rebase without conflicts
2021-04-23 21:32:02 <maxice8> if it can then it offers a button
2021-04-23 21:32:04 <Habbie> ah!
2021-04-23 21:32:10 <maxice8> if not it prompts you to check the branch locally, resolve the conflict and push
2021-04-23 21:32:16 <Habbie> so slightly different than github's buttons to merge without merge commits
2021-04-23 21:32:31 <Habbie> maxice8, and that's what you did earlier because the license fix caused a conflict, i realised later :)
2021-04-23 21:32:31 <maxice8> gitlab doesn't have a rebase&&merge like github
2021-04-23 21:32:58 <maxice8> and we don't have merge trains (paid feature)
2021-04-23 21:34:35 <Habbie> oh wow
2021-04-23 21:34:41 <Habbie> i've wanted that in github for ages
2021-04-23 21:35:22 <Habbie> (i just read https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ )
2021-04-23 21:35:59 <Habbie> every few months we have two back-to-back merges that 'break eachother'
2021-04-23 21:41:49 <tomleb> What is the Contributor comment for in APKBUILD files? What is the difference between the Maintainer one? (Sorry, couldn't find this on the wiki after a quick search)
2021-04-23 21:43:04 <Habbie> judging from community/pdns, there's a maintainer and also a bunch of people that contributed changes at some point
2021-04-23 21:43:36 <Habbie> and I guess I forgot to add myself to that today ;)
2021-04-23 21:43:50 <Habbie> but it's also possible my guess about the meaning of the fields is completely wrong
2021-04-23 21:43:53 <mps> contributor field should be removed
2021-04-23 21:44:34 <mps> it is misleading
2021-04-23 21:45:29 <Habbie> mps, what does it mean/did it mean?
2021-04-23 21:46:57 <mps> I think it is intended for serious contribution to pkg, and to contact contributor if maintainer is unreachable
2021-04-23 21:47:26 <Habbie> ah
2021-04-23 21:47:36 <mps> but nowadays all devs can be contacted in such cases
2021-04-23 21:47:42 <Habbie> then i did not forget to add myself; although i would like to be contacted about the ports i touched ;)
2021-04-23 21:47:51 <Habbie> right, makes sense
2021-04-23 21:48:41 <mps> don't worry, we will 'find' you from git log :)
2021-04-23 21:48:49 <Habbie> :)
2021-04-23 21:49:07 <Habbie> i'm not worried, and also i added this channel to my autojoin
2021-04-23 21:49:42 <mps> if you are upstream you may ask to take maintainership
2021-04-23 21:49:53 <Habbie> yes, somebody else suggested that earlier as well
2021-04-23 21:50:00 <Habbie> and if we used alpine ourselves, we'd do that
2021-04-23 21:50:05 <Habbie> but we don't, so i'm still pondering
2021-04-23 21:50:46 <mps> you are talking about pdns?
2021-04-23 21:51:03 <mps> ah, well
2021-04-23 21:51:07 <Habbie> yes
2021-04-23 21:51:37 <mps> but I can't remember that I see current maintainer active for long time
2021-04-23 21:52:04 <Habbie> and pdns-recursor and dnsdist have no maintainer listed
2021-04-23 21:52:31 <mps> last commit from s/he is bc84f7f31fc5d955514638e4570bae10ff1189fc
2021-04-23 21:52:40 <mps> 2011
2021-04-23 21:52:46 <mps> year
2021-04-23 21:52:48 <Habbie> mps, just saw that too, yes
2021-04-23 21:52:54 <Habbie> so then better me than 'nobody'
2021-04-23 21:53:01 <mps> I agree
2021-04-23 21:53:05 <Habbie> where i'm counting somebody who has not been seen as 10 years as 'nobody' too, without wanting to be rude
2021-04-23 21:53:15 <Habbie> mps, do i just do a MR and put myself in there?
2021-04-23 21:53:17 <mps> np
2021-04-23 21:53:53 <mps> usual practice is to send mail to maintainer and CC to alpine-devel ML
2021-04-23 21:54:05 <Habbie> ah, i'm not subscribed (yet?)
2021-04-23 21:54:15 <Habbie> let's see how busy that is
2021-04-23 21:54:27 <Habbie> alpine-devel or alpine-aports?
2021-04-23 21:54:33 <mps> if no answer in a week or two then you will be 'accepted'
2021-04-23 21:54:49 <Habbie> oh, only a few mails a week, awesome
2021-04-23 21:55:01 <mps> alpine-devel, alpine-aports is practically dead
2021-04-23 21:55:16 <Habbie> ok
2021-04-23 21:55:30 <Habbie> Your subscription to ~alpine/devel is confirmed! To unsubscribe in the future, send an
2021-04-23 21:55:34 <Habbie> it.. did not ask for a confirmation
2021-04-23 21:55:36 <Habbie> that's a bit icky
2021-04-23 21:56:19 <mps> actually all alpine MLs are dead for me ;)
2021-04-23 21:56:23 <Habbie> why?
2021-04-23 21:56:50 <mps> don't ask, don't want yet another round of flame war here
2021-04-23 21:56:55 <Habbie> alright
2021-04-23 22:42:10 <Habbie> well, i got one ringing endorsement on alpine-devel :)
2021-04-23 22:49:57 <tomleb> Yeah I was surprised not to see lot of patches in ~alpine/aports
2021-04-23 22:50:12 <Shiz> https://bugzilla.mozilla.org/show_bug.cgi?id=1707316
2021-04-23 22:50:18 <Shiz> didn't we recently talk about fx segfaulting? :)
2021-04-23 22:51:07 <tomleb> What machines are people using for ppc64le?
2021-04-23 22:51:39 <Habbie> i have a ppc64 VM from IBM
2021-04-23 23:14:11 <tomleb> Can I assume that the build machine has more than 1G of RAM? I'm packaging an app that crashes if I don't configure a minimum amount of RAM for the build.
2021-04-23 23:28:03 <Thermi> Yes
2021-04-23 23:30:23 <tomleb> Thank you
2021-04-24 00:48:05 <tomleb> when should checkpath be used in openrc services? If I'm already creating the directory in the package() function
2021-04-24 02:51:03 <Ariadne> tomleb: i have an IBM SC812 (POWER8) and IBM S922 (POWER9)
2021-04-24 02:51:31 <Ariadne> er, S812LC
2021-04-24 03:17:21 <tomleb> right, a server, however in the bugzilla above, its a firefox user. So I'm wondering who's using that arch for desktop :)
2021-04-24 03:39:10 <tomleb> Ariadne: What are using these servers for? Just regular server or ppc builds?
2021-04-24 03:40:26 <Ariadne> tomleb: there are people using alpine on Talos
2021-04-24 03:40:34 <Ariadne> tomleb: which is a workstation ppc64 board
2021-04-24 03:41:23 <tomleb> From raptors?
2021-04-24 03:42:27 <tomleb> I've seen them before, too expensive for me
2021-04-24 03:58:31 <Ariadne> i have a blackbird, it is very ok
2021-04-24 04:00:59 <tomleb> In alpine, is it necessary to build golang apps with -extldflags '-static' ?
2021-04-24 04:18:50 <Ariadne> for what purpose?
2021-04-24 04:18:58 <Ariadne> you should not do that if you're building an APK
2021-04-24 04:19:11 <Ariadne> if you're building a binary you plan to redistribute to others, it probably makes sense to do that
2021-04-24 04:22:48 <tomleb> Ok, well I see a few examples of packages that do that. For example k3s.
2021-04-24 04:40:47 <tomleb> I'm currently using alpine-chroot-install for my dev environment. So far so good. I'm wondering how to start services in /etc/init.d. Currently, if I run rc-service servie start, it says my service is already started. Any idea ?
2021-04-24 04:41:25 <tomleb> Ah, I should've read.. It's right there. touch /run/openrc/softlevel
2021-04-24 06:15:36 <ikke> tomleb: there aer a few exceptions where some binaries are built that will run on guest systems
2021-04-24 06:15:41 <ikke> so they need to be static
2021-04-24 06:15:50 <ikke> (re golang -static)
2021-04-24 06:16:46 <ikke> tomleb: re checkpath: one usecase is for creating directories in /run, which is tmpfs
2021-04-24 07:42:18 <ikke> PureTryOut[m]2: konsole has a test failure on armv7
2021-04-24 07:46:45 <mps> huh, github is a stupid thing
2021-04-24 07:47:07 <mps> and gitlab also
2021-04-24 07:49:49 <mps> gitlab just messed my latest 'git push mps' from branch in master
2021-04-24 07:50:12 <ikke> what happened
2021-04-24 07:50:45 <mps> there is ' You pushed to 3.13-stable 4 minutes ago' and button 'create merge request'
2021-04-24 07:51:11 <mps> before that I merged dovecot xapian to 3.13
2021-04-24 07:51:42 <mps> and after that I pushed new branch to gitlab, wireguard-tools
2021-04-24 07:52:32 <ikke> mps: what does 'git config push.default' return for you?
2021-04-24 07:52:34 <mps> lets play more
2021-04-24 07:53:08 <mps> empty answer
2021-04-24 07:59:29 <ikke> I guess you already removed 3.13-stable from your fork
2021-04-24 08:05:04 <mps> no, I merged to 3.13 from other contributor, not my MR
2021-04-24 08:06:41 <mps> hah, I merged another MR and it is now cleaned
2021-04-24 08:07:18 <mps> very interesting :)
2021-04-24 08:25:52 <PureTryOut[m]2> algitbot: retry master
2021-04-24 08:25:58 <PureTryOut[m]2> It works 🎉
2021-04-24 08:26:00 <ikke> :)
2021-04-24 08:54:25 <mps> did bratkartoffel invented real AI finally :) so much MRs in short time
2021-04-24 08:55:19 <bratkartoffel> sounded good in my head to file it as separate MRs... but after looking at it now I think it was a bad idea
2021-04-24 08:56:03 <bratkartoffel> at least I learned something about the gitlab api and why I should not use it
2021-04-24 08:56:34 <bratkartoffel> sorry... hope I didn't break something?
2021-04-24 08:56:37 <mps> bratkartoffel: no, it is ok imo
2021-04-24 08:57:27 <mps> jk because I surprised by bug number in short time
2021-04-24 08:57:49 <mps> s/bug/MRs/
2021-04-24 08:57:49 <alpine-meetbot> mps meant to say: jk because I surprised by MRs number in short time
2021-04-24 08:58:30 <mps> (if you fight with they will inhabit your brain :) )
2021-04-24 08:58:42 <mps> (if you fight with bugs they will inhabit your brain :) )
2021-04-24 08:59:31 <donoban> Hi
2021-04-24 09:00:12 <donoban> there is any problem with syslog and chronyd pidfiles being readable by anynone? I was reading this issue https://gitlab.alpinelinux.org/alpine/aports/-/issues/12623
2021-04-24 09:04:16 <donoban> hehe I was surprised too about the long round of MR's
2021-04-24 09:04:54 <donoban> bratkartoffel: what problems did you have?
2021-04-24 09:08:20 <mps> maribu[m]: what keeps upgrade avarice to 2.14
2021-04-24 09:10:15 <mps> btw, and dfu-util to 0.10
2021-04-24 09:31:12 <donoban> uhM, lol
2021-04-24 09:31:28 <donoban> complains about: Warning: cannot find /var/run/utmp
2021-04-24 09:31:52 <donoban> but it instead looks for: Looking: /dev/null/utmp
2021-04-24 09:34:20 <maribu[m]> @mps: I'll have a look at avarice and dfu-util tonight
2021-04-24 09:36:14 <maribu[m]> I think texlive should also have a new release. They usually have them in April
2021-04-24 09:37:20 <mps> maribu[m]: thanks, you saved me some time :)
2021-04-24 09:38:55 <mps> and I always forget to explain my idea about gcc-avr. actually I wanted to keep it in previous release
2021-04-24 09:39:59 <mps> i.e. 9.2 series
2021-04-24 09:40:28 <mps> maybe I will create new package with name gcc-avr9
2021-04-24 09:43:14 <mps> and then you could do what you planned with current releases
2021-04-24 09:43:19 <mps> maribu[m]: ^
2021-04-24 09:47:53 <mps> I need help from someone who know ppc64le build, this https://gitlab.alpinelinux.org/mps/aports/-/jobs/378820#L184
2021-04-24 09:48:24 <mps> !20824
2021-04-24 11:00:29 <Pawlakus> I have an issue with lvm2-2.02.187-r1, lvdisplay works, lvextend/lvcreate throws 'No command with matching syntax recognised.', not sure how it is possible to compile lvm2 without create/extend support... same with `lvm lvcreate` or `lvm lvextend`
2021-04-24 11:02:16 <Pawlakus> ok nevermind, syntax was wrong. apologies.
2021-04-24 11:17:42 <tomleb> ikke: thanks and thanks
2021-04-24 12:22:11 <Ariadne> Thermi: so kopano is a microsoft exchange server emulator, right?
2021-04-24 12:22:33 <Ariadne> Thermi: how can an end-user of kopano comply with the AGPL license to have a prominent link to download kopano source code if there is no UI for that part?
2021-04-24 12:22:59 <Ariadne> i think we are going to have to reject kopano in alpine, unless there is a good answer to that question
2021-04-24 12:23:25 <Ariadne> i am honestly thinking about amending our policies to disallow AGPL period
2021-04-24 12:23:48 <Ariadne> it seems to me that there is a new meme with AGPL, and that is, license violation entrapment
2021-04-24 12:23:56 <mps> +1
2021-04-24 12:24:29 <Ariadne> and i don't think it is nice to put our users in a situation where they become non-compliant with a license out of the box
2021-04-24 12:24:41 <mps> yes
2021-04-24 12:25:36 <Ariadne> the latest being minio
2021-04-24 12:25:51 <mps> we need some kind of written policy for some things
2021-04-24 12:25:59 <Ariadne> make a software, then once people are hooked, change the license so everyone is screwed
2021-04-24 12:26:17 <tehcloud> open the gates, invite everyone in, shut the gates
2021-04-24 12:26:24 <mps> like mongo or qt
2021-04-24 12:26:28 <Ariadne> (i fail to see how minio itself can be AGPL compliant, it has no UI)
2021-04-24 12:26:45 <Ariadne> well, qt pulled a dick move, but they only restricted LTS
2021-04-24 12:27:20 <mps> wait, their greed is not yet grown enough :)
2021-04-24 12:27:34 <tehcloud> Qt has always been a licensing shitshow
2021-04-24 12:27:48 <tehcloud> I recall that being part of the motivation to build GNOME back in the good old days
2021-04-24 12:27:53 <Ariadne> mps: there is always KDE's "free Qt foundation"
2021-04-24 12:28:03 <Ariadne> so if they pull some mega dick move
2021-04-24 12:28:04 <mps> tehcloud: that was reason I never tried to learn it
2021-04-24 12:28:08 <Ariadne> we will have Qt under BSD license
2021-04-24 12:28:09 <Ariadne> :D
2021-04-24 12:28:48 <mps> I tried learn gtk
2021-04-24 12:28:54 <tehcloud> the toolkit situation is generally bad
2021-04-24 12:28:56 <Ariadne> i think this AGPL stuff is far worse than the Qt situation
2021-04-24 12:29:05 <tehcloud> I had to abandon GTK and now I am using FLTK for UI stuff :p
2021-04-24 12:29:10 <tehcloud> ugly but works
2021-04-24 12:29:19 <mps> heh, FLTK was nice
2021-04-24 12:29:28 <Ariadne> these companies are doing this with AGPL because they want to entrap people into having to pay license fees
2021-04-24 12:29:42 <Ariadne> they're not using AGPL for software freedom
2021-04-24 12:29:44 <Ariadne> :D
2021-04-24 12:30:07 <mps> yes, and this is why I'm against companies involvement in alpine
2021-04-24 12:30:12 <tehcloud> yeah, AGPL is a bit fishy overall... it's really on the extreme end
2021-04-24 12:31:25 <skarnet> software freedom integrists: let's do a license that will force corporations to release their source code!
2021-04-24 12:31:39 <mps> I don't know for sure english meaning of word 'company' but as I understand it from latin it means a gang to go in war to robe all around
2021-04-24 12:31:46 <skarnet> corporations: hmmm... oh hey! we could use that license to force people to pay us more!
2021-04-24 12:32:09 <skarnet> software freedom integrists: <surprised pikachu face>
2021-04-24 12:34:04 <mps> have to repeat Descartes words: if the people understand true meaning of words at least half of all world dellusions will disappear
2021-04-24 12:35:03 <skarnet> that is... not what Descartes said
2021-04-24 12:35:25 <mps> I wrote from head with my bad english
2021-04-24 12:36:44 <skarnet> Descartes's point about delusions is that we can only perceive the world through our senses
2021-04-24 12:36:55 <tehcloud> he probably said it En Francais
2021-04-24 12:37:18 <skarnet> and our senses are lying to us, so we need Reason in order to make up a correct representation of the world
2021-04-24 12:37:53 <skarnet> I don't think he said anything about "half of all the world's delusions disappearing"
2021-04-24 12:37:58 <Ariadne> [06:30:06] <mps> yes, and this is why I'm against companies involvement in alpine
2021-04-24 12:38:01 <mps> that is other thing, and true
2021-04-24 12:38:03 <Ariadne> well that ship sailed a decade ago
2021-04-24 12:38:34 <mps> I mean to answer skarnet
2021-04-24 12:39:34 <Ariadne> but i do think that rejecting software that is VC-funded might not be an unreasonable idea
2021-04-24 12:39:54 <Ariadne> since this seems to keep happening
2021-04-24 12:40:45 <tehcloud> another option is something along the lines of the Debian "non-free" strategy if someone does care to package stuff up that is not aligned with the distro's philosophy
2021-04-24 12:40:53 <mps> it is not problem if the software funded by companies, problem is awkward licenses
2021-04-24 12:41:44 <skarnet> the problem is when VC-funded companies bait and switch licenses
2021-04-24 12:42:58 <Ariadne> yes, minio went from MIT to AGPL
2021-04-24 12:43:12 <Ariadne> but there is no way that i see for a minio install to be compliant with AGPL
2021-04-24 12:43:19 <Ariadne> it is a web server
2021-04-24 12:43:26 <Ariadne> there is no GUI
2021-04-24 12:43:38 <Ariadne> (there is an optional GUI for it, but the core does not have one built in)
2021-04-24 12:43:56 <skarnet> a web *server* with a *GUI*?
2021-04-24 12:44:08 <Ariadne> yes, it allows you to browse the filesystem it is serving
2021-04-24 12:44:20 <Ariadne> (minio is a web server that implements the Amazon S3 API)
2021-04-24 12:44:24 <skarnet> <infinite scream>
2021-04-24 12:44:39 <Cogitri> Btw I don't think llvm12 for 3.14 will happen, more IR test failures in llvm12 and clang changed things in the buildsystem and I won't have time to look into that until next weekend or so
2021-04-24 12:44:57 <Ariadne> minio itself makes sense
2021-04-24 12:45:12 <Ariadne> because a lot of software supports S3 for file uploads etc
2021-04-24 12:45:29 <Ariadne> but i dont see how it can be compliant with AGPL
2021-04-24 12:48:37 <Ariadne> ghostscript is compliant because it isnt used in a network setting
2021-04-24 13:00:51 <ikke> if there is no user interface or menu, then that clause does not apply is my reading of it
2021-04-24 13:01:35 <ikke> if there is, and you make changes, you can as well include the required notice
2021-04-24 13:08:30 <Hello71> Ariadne: is it though? what if i run mediawiki and imagemagick calls ghostscript for thumbnails
2021-04-24 13:09:16 <Ariadne> ikke: if that's true then why is ghostscript AGPL?
2021-04-24 13:09:17 <Ariadne> :)
2021-04-24 13:09:50 <Ariadne> Hello71: who knows, this is why i don't like AGPL so much anymore :)
2021-04-24 13:15:44 <wdtTP2O82Kft> nice rce in exiftool CVE-2021-22204
2021-04-24 13:17:06 <Ariadne> no CPE data provided in that CVE
2021-04-24 13:17:09 <Ariadne> harrumph
2021-04-24 13:19:06 <Ariadne> we're not vulnerable in edge
2021-04-24 13:20:06 <Ariadne> ah, because our source packagename is perl-image-exiftool
2021-04-24 13:21:21 <Ariadne> oh, no, there's no CPE data for real
2021-04-24 13:21:24 <Ariadne> yuck :)
2021-04-24 13:55:57 <ddevault> my bandwidth for riscv64 is 1-2 weeks every 4-5 months
2021-04-24 13:57:31 <ddevault> plus the occasional serendipitous "I need to use riscv64 for something and I might as well fix some alpine issues so I have a useful host to work from"
2021-04-24 13:57:43 <Ariadne> :D
2021-04-24 13:58:17 <Ariadne> ddevault: well, i think if rvs wants this and is willing to do the work, maybe that makes the most sense
2021-04-24 13:58:25 <ddevault> indeed
2021-04-24 13:58:27 <Ariadne> because he works on a downstream derivative of alpine full time
2021-04-24 13:58:44 <ddevault> I can provide shell access on an rv64 host to anyone who intends to work on it
2021-04-24 13:59:00 <Ariadne> i think we will wind up doing the builds with qemu-user
2021-04-24 13:59:07 <Ariadne> but yes, real porting hardware is good to have
2021-04-24 13:59:27 <ddevault> well, one of the major issues that needs to be addressed to move rv64 forward is that the boot story is full of holes on real hardware
2021-04-24 13:59:47 <Ariadne> (i'm not thrilled about qemu-user, but i think the real hardware options are all too slow to keep up at a reasonable pace)
2021-04-24 13:59:55 <ddevault> though working on that remotely would be annoying for anyone
2021-04-24 14:00:11 <Ariadne> i suspect rvs is able to get rv64 hardware
2021-04-24 14:00:14 <ikke> Ariadne: is there an advantage to qemu-user rather than qemu-system?
2021-04-24 14:00:19 <ddevault> depends on the amount of money you want to spend
2021-04-24 14:00:20 <Ariadne> ikke: it is way faster
2021-04-24 14:00:23 <ikke> Ariadne: aha
2021-04-24 14:00:26 <ddevault> enough slow hosts working in parallel can keep up with a large build queue
2021-04-24 14:00:43 <ddevault> and they're not really that slow, I did the entire bootstrapping effort so far on a native host
2021-04-24 14:00:45 <ikke> our current build infra does not handle parralel builds sadly
2021-04-24 14:00:47 <Ariadne> yes, but our current build system doesn't support distributing jobs yet
2021-04-24 14:00:55 <ddevault> solvable problem
2021-04-24 14:01:10 <ikke> yes, but not short term
2021-04-24 14:01:15 <Ariadne> yes, we can switch to apkfoundry
2021-04-24 14:01:19 <ddevault> we will not have working rv64 in the short term
2021-04-24 14:01:24 <Habbie> Ariadne, wait, which one is faster? qemu-user or qemu-system?
2021-04-24 14:01:30 <Ariadne> Habbie: -useer
2021-04-24 14:01:35 <Habbie> right, i hoped so :)
2021-04-24 14:01:45 <Ariadne> this damn keyboard is dying on mee
2021-04-24 14:01:57 <ikke> Ariadne: I have the same with my laptop keyboard
2021-04-24 14:02:01 <ikke> very anoying
2021-04-24 14:02:04 <Ariadne> thankfully i get paid next week and will be going immdiately to best buy to get a temporary machine
2021-04-24 14:02:21 <ddevault> you can take your pick from my pile of keyboards if you want
2021-04-24 14:02:28 <ddevault> it's next to the pile of monitors
2021-04-24 14:02:33 <Ariadne> hah
2021-04-24 14:02:57 <Ariadne> well regarding hw in the long term
2021-04-24 14:03:03 <Ariadne> we can probably get sifive to sponsor hw
2021-04-24 14:03:27 <ikke> ncopa has ideas for the build infra btw
2021-04-24 14:03:31 <ddevault> they weren't super receptive when I spoke to them about getting hw for builds.sr.ht runners a couple of years ago
2021-04-24 14:03:54 <ddevault> or rather they were somewhat receptive, but lacked an org structure which could fulfill such a request
2021-04-24 14:05:20 <Ariadne> if not, sifive, then i suspect linux foundation could fulfill the request, since they want it anyway for EVE
2021-04-24 14:05:22 <Ariadne> :p
2021-04-24 14:58:54 <wdtTP2O82Kft> Ariadne: it was an eval in perl: https://github.com/exiftool/exiftool/commit/cf0f4e7dcd024ca99615bfd1102a841a25dde031#diff-fa0d652d10dbcd246e6b1df16c1e992931d3bb717a7e36157596b76bdadb3800L233
2021-04-24 14:59:31 <Ariadne> wdtTP2O82Kft: yep i saw.  i have done the security upgrade in 3.13
2021-04-24 15:13:57 <maribu[m]> 
ACTION  < https://matrix.org/_matrix/media/r0/download/matrix.org/eiTNgsIqiNxhZgLrGZwccbWw/message.txt >

2021-04-24 15:14:12 <maribu[m]> s/1/-1/
2021-04-24 15:16:55 <mps> huh
2021-04-24 15:17:35 <mps> sending url without any word about context?
2021-04-24 15:18:02 <Ariadne> heh my partner who is a lawyer says the minio license change may actually be illegal, as there is no evidence of a CLA or relicensing campaign
2021-04-24 15:18:05 <Ariadne> :D
2021-04-24 15:31:04 <Hello71> the bigger problem might be selling "Commercial" license without CLA: https://min.io/pricing
2021-04-24 15:56:51 <Ariadne> .
2021-04-24 17:20:27 <Ariadne> Hello71: yes, i don't see how that is possible
2021-04-25 08:22:56 <Dadrophenia> If I wanted to package a musical instrument tuner that supports alsa, oss, pulseaudio, and jack, would the proper convention be to make different packages for each of the supported sound libraries rather than making all of those dependencies?
2021-04-25 08:24:50 <ikke> Dadrophenia: That would be appreciated (separate subpkacages)
2021-04-25 08:41:23 <mps> +1
2021-04-25 08:41:57 <mps> same should be for firefox, mpv etc ... :)
2021-04-25 08:47:22 <ikke> Issue is that it's quite expensive in time to build a project like firefox multiple times
2021-04-25 09:17:09 <mps> if 'exensive' is so important I think building these packages without cruft^Wpulse,pipewire,jack... will be less expensive :P
2021-04-25 09:20:08 <ikke> It's always a matter of trade-offs. In different situations, you have to make different choices
2021-04-25 09:21:26 <ikke> What's cruft for one person, is a bare necessity for the other. Who should we cater for?
2021-04-25 09:21:38 <mps> hah, interesting. trade basic principle for 'commodity'
2021-04-25 09:22:12 <mps> we should cater for 'small and simple'
2021-04-25 09:22:22 <ikke> small, simple and limited?
2021-04-25 09:22:38 <mps> right, I forgot limited ;p
2021-04-25 09:23:33 <mps> seriously, I don't see strong reason to use alpine if it is as debian/ubuntu/fedora/arch
2021-04-25 09:23:47 <mps> because of musl?
2021-04-25 09:24:28 <mps> yes, musl is good reason but waste my time with other problems on alpine is not worth for me
2021-04-25 09:25:02 <ikke> The issue is that it's not easy to have optional dependencies if the software does not support it
2021-04-25 09:25:19 <mps> a lot less effort would be run debian with openrc, or maybe arch if it can work without systemd
2021-04-25 09:26:05 <mps> 
ACTION wants alpine as it was 2-3 years ago

2021-04-25 09:26:35 <ikke> I wonder if it would be possible to create shims for these dependencies that get replaced if you install the actual implementation
2021-04-25 09:26:36 <mps> don't tell me 'use 3.9'
2021-04-25 09:28:21 <mps> ok, enough grumble from me for today. sunny day is outside :)
2021-04-25 09:28:49 <ikke> If we had inifinite resources (build time, mirror space, developer time)l, we would just provide all possible combinations that people might want
2021-04-25 09:30:13 <mps> hehe, space and time are infinite, say mps with quantum physic hat on
2021-04-25 09:30:13 <ikke> mps: don't get me wrong, I do feel your 'pain'
2021-04-25 09:31:26 <mps> ikke: I don't feel pain about these anymore as with other open source 'things' :)
2021-04-25 09:31:43 <mps> s/anymore/more/
2021-04-25 09:31:43 <alpine-meetbot> mps meant to say: ikke: I don't feel pain about these more as with other open source 'things' :)
2021-04-25 09:31:58 <mps> s/anymore/more than/
2021-04-25 09:31:59 <alpine-meetbot> mps meant to say: ikke: I don't feel pain about these more than as with other open source 'things' :)
2021-04-25 10:11:22 <donoban> hi
2021-04-25 10:12:05 <donoban> mps: with debian/ubuntu/fedora/arch, you mean as a desktop?
2021-04-25 10:14:04 <mps> donoban: probably as desktop and *bsd on servers
2021-04-25 10:15:01 <mps> sure, I know they are not perfect
2021-04-25 10:15:15 <donoban> hehe
2021-04-25 10:15:47 <donoban> well, I'm currently using alpine as desktop like a football team holigan
2021-04-25 10:16:17 <mps> all my family use alpine as desktop
2021-04-25 10:16:25 <donoban> great! :D
2021-04-25 10:17:24 <mps> xfce4 and awesome wm, no so called big DEs
2021-04-25 10:17:25 <donoban> so you are only worried about big programs like firefox not being properly subpackaged?
2021-04-25 10:17:54 <mps> I'm not woried, I don't like useless cruft in them
2021-04-25 10:18:08 <Ariadne> i have some ideas
2021-04-25 10:18:24 <mps> my ears ready
2021-04-25 10:18:25 <Ariadne> the main point is making aports integrate better with the system
2021-04-25 10:18:41 <Ariadne> then you can rebuild packages with different option selections like freebsd
2021-04-25 10:19:20 <donoban> but Ariadne the problem is when the upstream are not worried about this, like in telegram
2021-04-25 10:19:46 <Ariadne> donoban: well that's too bad for telegram
2021-04-25 10:20:00 <mps> Ariadne: does this idea means user should rebuild packages
2021-04-25 10:20:22 <donoban> I suppose that in firefox there are similar problems
2021-04-25 10:20:29 <Ariadne> mps: yes, if they do not like the defaults
2021-04-25 10:20:50 <mps> i.e. specific package I want to be different than it is in release
2021-04-25 10:21:01 <Ariadne> yep
2021-04-25 10:21:05 <Ariadne> i want to make that easy
2021-04-25 10:21:11 <Ariadne> there's a few ways we can do it
2021-04-25 10:21:22 <mps> heh, that is what I do in my local branches
2021-04-25 10:21:27 <Ariadne> having a @local tagged repo and pinning packages to @local for example
2021-04-25 10:22:01 <Ariadne> the larger issue is making abuild aware of build-options
2021-04-25 10:22:15 <Ariadne> ncopa and i talked about that a few years ago but then life happened and it got tabled :P
2021-04-25 10:22:52 <mps> yes, like what happens with most good ideas
2021-04-25 10:23:04 <Ariadne> well today reality is a lot different
2021-04-25 10:24:12 <Ariadne> things are more stable for a lot of the developers working on these ideas :)
2021-04-25 10:25:10 <donoban> Off Topic: I'm considering removing firejail xd
2021-04-25 10:25:50 <mps> from aports?
2021-04-25 10:25:56 <donoban> lol no
2021-04-25 10:26:00 <donoban> from my computer
2021-04-25 10:26:17 <mps> I had a hope :)
2021-04-25 10:26:21 <donoban> hahaha
2021-04-25 10:26:36 <donoban> I honestly don't bother if there are things on aports that I don't use
2021-04-25 10:26:38 <Ariadne> i mean
2021-04-25 10:26:46 <Ariadne> i'm considering removing firejail :)
2021-04-25 10:26:48 <donoban> but I suppose that for you is pretty different
2021-04-25 10:26:54 <Ariadne> from aports :)
2021-04-25 10:27:11 <mps> no objections from me ;)
2021-04-25 10:27:17 <Ariadne> the problem is somebody will put it back
2021-04-25 10:27:21 <Ariadne> because they don't know better
2021-04-25 10:27:22 <Ariadne> :D
2021-04-25 10:27:30 <donoban> the maintainer? it seems a nice guy
2021-04-25 10:27:35 <donoban> he*
2021-04-25 10:27:37 <donoban> :\
2021-04-25 10:27:48 <Ariadne> it does not matter if the maintainer is nice if the software he is maintaining is a security hole :D
2021-04-25 10:27:59 <Ariadne> my job is literally removing security holes from alpine
2021-04-25 10:28:24 <donoban> uhM, I'm not sure if "security hole" is exagerated
2021-04-25 10:28:30 <mps> Ariadne: iirc, once upon a time you talked about making list of packages for removal
2021-04-25 10:28:38 <Ariadne> yes
2021-04-25 10:28:40 <donoban> but I only will install it on single user desktops
2021-04-25 10:28:49 <donoban> never on servers, or shared systems
2021-04-25 10:29:06 <Ariadne> donoban: you might not want to download random programs from the internet too
2021-04-25 10:29:11 <Ariadne> because i guarantee you
2021-04-25 10:29:16 <Ariadne> i could root your box via firejail
2021-04-25 10:29:18 <Ariadne> if i wanted to
2021-04-25 10:29:30 <Ariadne> i mean, i'm not that kind of person obviously
2021-04-25 10:29:39 <Ariadne> but if you `curl | sh` shit
2021-04-25 10:29:48 <Ariadne> that shit could root you via firejail
2021-04-25 10:29:49 <Ariadne> 100% sure
2021-04-25 10:29:56 <mps> yes
2021-04-25 10:29:58 <donoban> uhM
2021-04-25 10:30:01 <donoban> the problem
2021-04-25 10:30:06 <donoban> is that in my currnet computer
2021-04-25 10:30:12 <donoban> is near the same to become donoban that become root
2021-04-25 10:30:20 <donoban> there is nothing more value for root that for donoban
2021-04-25 10:30:30 <Ariadne> that's not true
2021-04-25 10:30:33 <donoban> like in most single user deskstops
2021-04-25 10:30:35 <Ariadne> root is very valuable
2021-04-25 10:30:38 <Ariadne> even on single user machine
2021-04-25 10:30:50 <donoban> uhM
2021-04-25 10:30:54 <Ariadne> for example i can install a rootkit that you won't be aware of
2021-04-25 10:31:06 <Ariadne> and then exfiltrate your data without your knowledge
2021-04-25 10:31:32 <donoban> I will consider the game lost before that
2021-04-25 10:31:40 <donoban> if you can't be root
2021-04-25 10:31:43 <Ariadne> the game was lost as soon as you installed firejail :D
2021-04-25 10:31:45 <donoban> what will you do?
2021-04-25 10:31:46 <mps> game is lost long ago
2021-04-25 10:31:49 <donoban> hehe
2021-04-25 10:32:35 <Ariadne> if i am an attacker, i could serve you a webpage (via an advert or whatever) that gets code execution in your browser and then use firejail to privesc
2021-04-25 10:33:13 <donoban> uhM, but theorically in that sceneario firejail should protect me
2021-04-25 10:33:38 <donoban> anyway I open most random links with torbrowser on flatpak which uses brwap
2021-04-25 10:33:44 <Ariadne> no, what protects you in that scenario is firefox using seccomp to block exec(2) syscall
2021-04-25 10:34:21 <Ariadne> (there have literally been browser to root privesc using firejail btw)
2021-04-25 10:35:06 <donoban> well I honestly was happy with it, but tried to fix some errors and uhM..
2021-04-25 10:36:17 <donoban> It complains about ("cannot find /var/run/utmp\n"), but in reallity it was trying to open "/dev/null/utmp"
2021-04-25 10:36:38 <donoban> which is pretty uggly debug warning
2021-04-25 10:36:43 <mps> do someone keep notes for next stable? I just moved clamav from main to community and this should be mentioned in release notes
2021-04-25 10:36:49 <Ariadne> that means they are using paths.h for no reason
2021-04-25 10:36:50 <Ariadne> :D
2021-04-25 10:37:06 <donoban> and see some blocks of code just commented, pretty rare on an official release
2021-04-25 10:37:17 <donoban> I feel that they are trying to achieve more than they can afford
2021-04-25 10:37:29 <donoban> because they try to support a lot of programs configuration by default
2021-04-25 10:37:36 <Ariadne> yes this might be why i keep saying to not use it :D
2021-04-25 10:37:38 <ikke> mps: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0
2021-04-25 10:38:08 <ikke> mps: I can add it for you if you want
2021-04-25 10:39:01 <mps> ikke: please do, and thanks
2021-04-25 10:41:28 <ikke> mps: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0#ClamAV_moved_to_community
2021-04-25 10:41:45 <Ariadne> can we delete firejail :D
2021-04-25 10:44:00 <mps> ikke: thanks, especially about nice explanation. I couldn't do such explanation
2021-04-25 10:48:06 <ikke> Ariadne: We could open an issue on gitlab and ping @itoffshore
2021-04-25 10:48:58 <Ariadne> i just question the value of shipping a package that is fundamentally conceptually flawed
2021-04-25 10:49:09 <Ariadne> that describes itself as "security" tool
2021-04-25 10:49:42 <Ariadne> if you really want this, you should use bubblewrap which does this without being SUID
2021-04-25 10:50:09 <ikke> yes, it's just polite to do this in discussion with the maintainer
2021-04-25 10:50:43 <Ariadne> https://github.com/igo95862/bubblejail
2021-04-25 10:50:45 <Ariadne> :)
2021-04-25 10:51:02 <Ariadne> i could see a postmarketOS user installing firejail to their phone
2021-04-25 10:51:10 <Ariadne> and then getting utterly owned
2021-04-25 10:51:11 <donoban> another problem is that many profiles are broken in the default setup, mainly due utmpfs and some mount errors
2021-04-25 10:51:34 <Ariadne> haha so its broken too :D
2021-04-25 10:51:50 <donoban> it needs a little love to work
2021-04-25 10:51:52 <donoban> hehe
2021-04-25 10:52:03 <Ariadne> this is quickly becoming meme security
2021-04-25 10:52:29 <donoban> well, I suppose that this problems are related with alpine
2021-04-25 10:52:35 <donoban> the profiles are mostly based on ubuntu/debian
2021-04-25 10:53:02 <donoban> but it would be a pain to adapt a lot of profiles for alpine specifics things
2021-04-25 11:00:15 <Ariadne> donoban: no, the problem with firejail is that it exists at all
2021-04-25 11:00:41 <donoban> :)
2021-04-25 11:02:05 <donoban> https://seclists.org/oss-sec/2017/q1/25
2021-04-25 11:02:44 <donoban> "any non-privileged user could mount a tmpfs over any location. Eg mount over /etc to get root shell:
2021-04-25 11:08:49 <Ariadne> lik
2021-04-25 11:08:51 <Ariadne> e
2021-04-25 11:08:54 <Ariadne> i don't get it
2021-04-25 11:09:00 <Ariadne> is this thing a troll?
2021-04-25 11:09:16 <Ariadne> or some elaborate hoax created by an APT?
2021-04-25 11:09:21 <Ariadne> they recommend using it with tor!
2021-04-25 11:09:52 <donoban> hM, how?
2021-04-25 11:12:58 <Ariadne> well an APT would want to convince users to use a trivially defeated security tool because then your average person will think they have security they don't actually have
2021-04-25 11:14:45 <donoban> do you mean the thread that I pasted? do you see it as a firejail defense?
2021-04-25 11:18:20 <Ariadne> i see it as more proof that firejail is a troll
2021-04-25 11:18:32 <Ariadne> not allowing users to mount over /etc is security 101
2021-04-25 11:18:56 <donoban> where did you see they recommend use it with tor?
2021-04-25 11:19:03 <Ariadne> it is recommended on firejail website!
2021-04-25 11:19:55 <donoban> this HOWTO: Firejailed Tor Browser ?
2021-04-25 11:19:57 <Ariadne> yes
2021-04-25 11:20:00 <Ariadne> and like
2021-04-25 11:20:04 <Ariadne> the picture of the cat
2021-04-25 11:20:14 <Ariadne> the cat can clearly escape that box
2021-04-25 11:20:14 <donoban> LOL
2021-04-25 11:20:18 <donoban> hahaha
2021-04-25 11:20:21 <Ariadne> this has to be a troll
2021-04-25 11:20:24 <donoban> hahahahaha
2021-04-25 11:20:42 <donoban> I didn't see the cat lol
2021-04-25 11:20:48 <donoban> its epic, Firejailed!
2021-04-25 11:21:00 <Ariadne> completely meaningless
2021-04-25 11:21:07 <Ariadne> just like firejail itself
2021-04-25 11:25:37 <donoban> (1/1) Purging firejail (0.9.64.4-r1), I will miss the cat :\
2021-04-25 11:26:07 <ikke> Firejail-cat-as-a-service
2021-04-25 11:26:17 <donoban> hehe
2021-04-25 11:26:55 <Ariadne> the current version in community has open CVE
2021-04-25 11:27:01 <Ariadne> i think i am going to just nuke this thing
2021-04-25 11:27:11 <donoban> lol
2021-04-25 11:27:36 <donoban> that's because I want https://security.alpinelinux.org/ for edge :D
2021-04-25 11:28:27 <donoban> uhm it was fixed on edge
2021-04-25 11:28:38 <donoban> well "fixed", I think that it just disabled overlays
2021-04-25 11:28:50 <ikke> donoban: I'm working on updating the secfix db generator
2021-04-25 11:29:01 <donoban> oh great ikke :)
2021-04-25 11:29:05 <ikke> It will use the new alpinelinux.org/releases.json
2021-04-25 11:29:50 <Ariadne> donoban: :D :D :D :D :D :D :D :D :D :D :D
2021-04-25 11:30:09 <donoban> what happens? hehe
2021-04-25 11:30:18 <Ariadne> well, now it is gone
2021-04-25 11:30:23 <ikke> alpine/aports:master | Ariadne Conill | community/firejail: remove | http://dup.pw/alpine/aports/a583a65eab6c
2021-04-25 11:30:23 <Ariadne> so that happened :P
2021-04-25 11:30:24 <donoban> I opened an issue yesterday on firejail github
2021-04-25 11:30:36 <Ariadne> yeah i wouldn't waste your time
2021-04-25 11:30:40 <Ariadne> this guy is clearly trolling
2021-04-25 11:30:53 <Ariadne> soon he will probably publish a paper about it
2021-04-25 11:31:01 <Ariadne> like those guys who got vulnerabilities into linux
2021-04-25 11:31:02 <donoban> hehe I don't think that
2021-04-25 11:31:17 <donoban> I feel that his project has too big scope for being a security thing
2021-04-25 11:31:27 <donoban> security is too complex
2021-04-25 11:31:51 <Ariadne> i pray that it does not return
2021-04-25 11:31:55 <Ariadne> i have removed it before
2021-04-25 11:31:59 <donoban> haha
2021-04-25 11:32:12 <ikke> We should have some kind of flag on options="suid" packages
2021-04-25 11:32:25 <Ariadne> the CI should scream bloody murder about options=suid
2021-04-25 11:32:52 <ikke> But it should allow existing / approved suid programs
2021-04-25 11:33:01 <Ariadne> yes agree
2021-04-25 11:35:14 <donoban> Now I see that they totally ignored my issue
2021-04-25 11:35:29 <donoban> there are 3 newer issues with answers
2021-04-25 11:35:46 <donoban> but well, there other issues withoy any answer too
2021-04-25 11:36:09 <Ariadne> yeah
2021-04-25 11:36:12 <Ariadne> thats because
2021-04-25 11:36:13 <donoban> I think the title is pretty expresive: "Warning: cannot find /var/run/utmp" but looks for "/dev/null/utmp" instead xd
2021-04-25 11:36:16 <Ariadne> this whole thing is a troll
2021-04-25 11:36:42 <Ariadne> we are being trolled right now by it in fact
2021-04-25 11:36:44 <donoban> at least you could fix your warning message
2021-04-25 11:36:50 <Ariadne> because we are continuing to discuss this troll
2021-04-25 11:37:03 <donoban> nah hehe
2021-04-25 11:37:11 <donoban> it's enought for today, I laught a lot with the cat photo
2021-04-25 11:37:13 <donoban> :D
2021-04-25 11:37:37 <Ariadne> anyway for the love of god, please do not bring firejail back from the dead again
2021-04-25 11:38:51 <donoban> I will MR, zombiejail
2021-04-25 11:39:47 <Ariadne> bubblejail looks nice enough
2021-04-25 11:39:51 <Ariadne> package that :p
2021-04-25 11:40:04 <Ariadne> it at least uses a sandboxing technology that is actually reasonable
2021-04-25 11:40:30 <donoban> uhM
2021-04-25 11:40:36 <donoban> python + brwap?
2021-04-25 11:40:43 <donoban> it seems a better start
2021-04-25 11:41:56 <donoban> I have to try, I want sandbox for just work organization more than security itself
2021-04-25 11:42:16 <donoban> I removed firejail but still have some apps running on firejails
2021-04-25 11:42:25 <donoban> I need some replacement
2021-04-25 11:59:32 <donoban> pkgdesc="Bubblejail's design is based on observations of Firejail's faults."
2021-04-25 12:11:03 <mps> hmm again, ' You pushed to 3.13-stable 1 minute ago' and button 'Create merge request'
2021-04-25 12:11:41 <ikke> mps: what is the output of the git push command that you did?
2021-04-25 12:13:14 <mps> I merged one MR, alpine/aports:3.13-stable | Duncan Bellamy | community/dcc: upgrade to 2.3.168 | http://dup.pw/alpine/aports/1865ed243012
2021-04-25 12:14:15 <mps> maybe it will disappear after some time, like yesterday
2021-04-25 12:19:36 <Cogitri> mps: Yes, it'll disappear after a while
2021-04-25 12:20:03 <Cogitri> gitlab just detects that you've "pushed" (merged) to a branch that's not the default branch and as such offer you to make a merge request to the default branch
2021-04-25 12:26:35 <mps> Cogitri: aha, thats what happened yesterday. thanks for explanation
2021-04-25 12:32:07 <mps> this is new annoyance^Wfeature after gitlab upgrade
2021-04-25 12:35:43 <ikke> ah yes, I should have known
2021-04-25 13:06:58 <Ariadne> donoban: ha
2021-04-25 13:07:17 <Ariadne> donoban: it is probably better to use $pkgdesc for what it actually does though.
2021-04-25 13:10:46 <minimal> donoban: the utmp file warning is due to the location of the utmp file defined differently in 2 different include files - I have a patch locally for musl to fix this (part of the utmps-enablement patches I'm working on)
2021-04-25 13:12:29 <minimal> Ariadne: what are you thoughts on my comment on !20659 ?
2021-04-25 13:14:21 <Ariadne> minimal: NAK on revert
2021-04-25 13:14:30 <Ariadne> minimal: fix it in a way that retains the subpackages
2021-04-25 13:14:39 <minimal> Ariadne: I didn't ask for a revert, mps did.
2021-04-25 13:15:10 <minimal> It was about util-linux having deps to drag in all the other subpackages
2021-04-25 13:15:36 <Ariadne> oh
2021-04-25 13:15:40 <Ariadne> i think that should be fixed
2021-04-25 13:15:50 <Ariadne> i dont have any opinion on fixing it
2021-04-25 13:16:18 <Ariadne> however you think it can be fixed without removing the subpackages is fine
2021-04-25 13:16:22 <minimal> so if I install util-linux to use 1 or 2 of the binaries in it I don't really want hexdump, cfdisk, etc also installed
2021-04-25 13:16:40 <ikke> then install the individual tools you need?
2021-04-25 13:17:04 <Ariadne> thats why the previous MR split out those 3 tools yes
2021-04-25 13:17:16 <Ariadne> i think solution is to split out more tools and have util-linux as a metapackage
2021-04-25 13:17:22 <ikke> yes, exactly
2021-04-25 13:17:34 <ikke> install util-linux, you get everythign
2021-04-25 13:17:41 <ikke> need just a specific tool, install that
2021-04-25 13:17:45 <Ariadne> ok well somebody do that :P
2021-04-25 13:17:57 <Ariadne> or i can look at it later
2021-04-25 13:18:06 <Ariadne> right now i am working on wpa-supplicant CVE
2021-04-25 13:19:00 <ikke> I'm working on the secdb generator
2021-04-25 13:19:06 <minimal> ikke: any when I install util-linux for "mount" or "fstrim" or one of the other 20-30-odd binaries that are in the main util-linux package I'm also getting 9 other subpackages auto installed that I don't want
2021-04-25 13:19:12 <minimal> s/any/and/
2021-04-25 13:19:12 <alpine-meetbot> minimal meant to say: ikke: and when I install util-linux for "mount" or "fstrim" or one of the other 20-30-odd binaries that are in the main util-linux package I'm also getting 9 other subpackages auto installed that I don't want
2021-04-25 13:19:56 <ikke> minimal: the subpackages should not have those as dependencies
2021-04-25 13:20:04 <ikke> if they do, that should be fixed
2021-04-25 13:20:19 <minimal> ikke: the subpackages don't - its the main package that has *all* the subpackages as deps
2021-04-25 13:20:25 <Ariadne> 
ACTION nominates minimal to fix it

2021-04-25 13:20:44 <ikke> minimal: yes, doesn't it make sense that when you install util-linux, you get everything?
2021-04-25 13:20:54 <Ariadne> fix it by splitting more stuff out
2021-04-25 13:20:57 <Ariadne> :)
2021-04-25 13:21:05 <Ariadne> this really is the right way
2021-04-25 13:21:16 <Ariadne> split every utility out that anyone actually wants
2021-04-25 13:21:24 <Ariadne> then leave the miscillaneous stuff in util-linux
2021-04-25 13:21:35 <Ariadne> that is how i would fix it anyway
2021-04-25 13:21:37 <minimal> nope, if I want "mount" for example as Busybox's mount doesn't support something that util-linux's mount do I may not want "apk add util-linux" to also trigger the install of "lsblk" to replace busybox's lsblk
2021-04-25 13:21:51 <Ariadne> ok, so do "apk add lsblk"
2021-04-25 13:21:54 <Ariadne> and "apk add mount"
2021-04-25 13:21:59 <ikke> yes, exactly
2021-04-25 13:22:01 <Ariadne> that's what we are telling you
2021-04-25 13:22:08 <ikke> install mount if you just want moount
2021-04-25 13:22:09 <Ariadne> split out everything
2021-04-25 13:22:11 <minimal> Ariadne: yes the ultimate fix is to split every single binary into a subpackage, but that would be 30+ subpackage - not sure if many would be happy with that
2021-04-25 13:22:18 <Ariadne> who cares
2021-04-25 13:22:32 <Ariadne> i am sure people will live with it
2021-04-25 13:22:33 <Ariadne> :P
2021-04-25 13:23:10 <ikke> minimal: the issue is that everyone would have a different opinion of what should be included in a minimum util-linux
2021-04-25 13:23:48 <minimal> minimal: agreed, that's why I mentioned needing a "general decision"
2021-04-25 13:24:00 <ikke> are you mentioning yourself now? :P
2021-04-25 13:24:06 <Sheila> the 'general decision' is 'split every command'
2021-04-25 13:24:57 <Ariadne> i'm just telling you what the logic was when we started splitting util-linux
2021-04-25 13:25:02 <minimal> from his comment mps doesn't want subpackages, so who gets to merge or reject merge for subpackages?
2021-04-25 13:25:27 <ikke> Maintainer Natanael Copa
2021-04-25 13:25:38 <Ariadne> :D
2021-04-25 13:25:51 <Ariadne> christ
2021-04-25 13:26:06 <Ariadne> i will deal with this in a minute
2021-04-25 13:27:26 <Ariadne> we will just make every single program its own package and then have util-linux be a metapackage, as originally intended
2021-04-25 13:29:03 <minimal> Ariande: that's what I'd thought, and then individual package maintainers can decide whether to depend on util-linux in general or define a list of individual subpackages deps instead
2021-04-25 13:29:56 <Ariadne> yes
2021-04-25 13:29:59 <Ariadne> do that
2021-04-25 13:30:04 <Ariadne> that's what we've been saying :p
2021-04-25 13:30:37 <minimal> apart from mps
2021-04-25 13:32:24 <Ariadne> i don't think that was what he was asking for
2021-04-25 13:32:29 <Ariadne> rather for it to be made consistent
2021-04-25 13:32:34 <Ariadne> or the previous split be reverted
2021-04-25 13:32:45 <Ariadne> he can certainly correct me if i am wrong :)
2021-04-25 13:33:29 <minimal> Ariadne: boolean logic, he used an "and", not an "or" ;-)
2021-04-25 13:34:38 <minimal> anyway I can work on an MR for 1 binary per subpackage, obviously for after 3.14
2021-04-25 13:36:07 <skarnet> that's a hell of a way to approach granularity
2021-04-25 13:36:35 <Ariadne> :D
2021-04-25 13:36:43 <Ariadne> skarnet: everyone suffers
2021-04-25 13:37:04 <skarnet> I mean it's probably adequate for util-linux, but other packages may have more integration between binaries and natural granularity may be JUST A BIT more coarse
2021-04-25 13:37:18 <Ariadne> well, my proposal is not every single binary
2021-04-25 13:37:23 <Ariadne> but have like, the ones people actually want
2021-04-25 13:37:26 <Ariadne> split out
2021-04-25 13:37:31 <Ariadne> and then have util-linux-misc
2021-04-25 13:37:33 <Ariadne> for the rest
2021-04-25 13:37:38 <Ariadne> and then util-linux pulls it all
2021-04-25 13:37:40 <Ariadne> :P
2021-04-25 13:37:53 <Ariadne> instead of having $depends list, _mv_bin() could generate an install-if rule
2021-04-25 13:38:16 <Ariadne> i'll outline my thoughts
2021-04-25 13:38:18 <Ariadne> in a moment
2021-04-25 13:38:23 <minimal> Ariadne: that's what I'd originall thought - but if the util-linux package (containing less commonly used binaries) still drags in all the other subpackages via deps then you'd be right back to the current situation
2021-04-25 13:38:32 <skarnet> I'm down for that experiment on util-linux, and then analyze server logs to see how many people install separate parts as opposed to the full util-linux metapackage
2021-04-25 13:38:35 <Ariadne> minimal: no
2021-04-25 13:38:43 <skarnet> my guess is that most people will just get the whole thing
2021-04-25 13:38:44 <Ariadne> minimal: the rest of the bins would go in *util-linux-misc*
2021-04-25 13:38:53 <Ariadne> minimal: util-linux would just be metapackage
2021-04-25 13:39:05 <Ariadne> minimal: i'll respond on the MR
2021-04-25 13:40:11 <minimal> ok, thanks Ariadne.
2021-04-25 13:44:20 <Ariadne> minimal: i am merging !20659 for now, but feel free to work on the solution i outlined for 3.15
2021-04-25 13:45:06 <minimal> skarnet: I'm thinking in terms of other package's deps rather than what people manually install - e.g. I maintain the cloud-utils-growpart subpackage and the guy's working on the official Alpine AWS images mentioned its deps were too "heavy" so I tweaked it to use various util-linux subpackages to make it more lightweight (they still ended up writing their own code rather than using cloud-utils-growpart)
2021-04-25 13:45:31 <mps> this is not good, I have to say
2021-04-25 13:46:23 <Ariadne> yes everything we do is not good
2021-04-25 13:46:29 <Ariadne> thanks for the doom and gloom report
2021-04-25 13:46:51 <Ariadne> minimal: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12637
2021-04-25 13:46:57 <mps> when I wanted to split vim there were objections, and vim with all its files is a lot bigger than util-linux
2021-04-25 13:47:01 <Ariadne> you can like self-assign i guess if you want
2021-04-25 13:47:06 <ikke> mps: Sorry, but I have a feeling this is quite contradictory to what you normally say
2021-04-25 13:47:25 <Ariadne> mps: objections from who ?
2021-04-25 13:47:37 <Ariadne> mps: i definitely support having a vim-minimal
2021-04-25 13:47:56 <mps> there is stalled MR, can't find now because i fixing laptop
2021-04-25 13:48:00 <Ariadne> to the extent that i can support that
2021-04-25 13:48:06 <Ariadne> since i do not use vim
2021-04-25 13:48:07 <Ariadne> :p
2021-04-25 13:48:27 <minimal> mps: its not specifically about size, its about wanting to use a binary but not wanting other binary to also be installed that will override Busybox's equivalent
2021-04-25 13:48:32 <Ariadne> ^
2021-04-25 13:48:51 <Ariadne> yes this is basically
2021-04-25 13:49:06 <Ariadne> busybox's implementation of some util-linux programs are better than the util-linux one
2021-04-25 13:49:09 <Ariadne> and vice versa
2021-04-25 13:49:18 <Ariadne> so allowing people to choose the individual programs is the right way
2021-04-25 13:49:29 <Ariadne> for example i prefer busybox top over util-linux one
2021-04-25 13:49:54 <mps> minimal: as I wrote in MR, I agree with you
2021-04-25 13:50:04 <bratkartoffel> can someone please merge !20775, !20781 and !20782? with these build tools merged I think the my other MRs will go green on CI
2021-04-25 13:50:07 <Ariadne> then why are you mad that we are implementing that :p
2021-04-25 13:50:39 <mps> Ariadne: I think we are too chaotic nowadays
2021-04-25 13:50:52 <mps> that is main problem for me
2021-04-25 13:51:04 <Ariadne> as you've been saying for the past several years
2021-04-25 13:51:17 <mps> we 'don't know' right way to do things
2021-04-25 13:51:20 <Sheila> the vim one is !13680
2021-04-25 13:51:32 <mps> Sheila: thanks
2021-04-25 13:51:55 <Sheila> and I'm not sure 'save ~2MB from 2-3dozen MB package' is actually sound
2021-04-25 13:52:29 <Ariadne> mps: in that MR, the consensus was to create a more generic vim-minimal package instead of just splitting syntax files
2021-04-25 13:52:32 <mps> Sheila: this is intended as first in serie
2021-04-25 13:52:42 <Ariadne> that's what maxice8 was saying
2021-04-25 13:52:46 <Ariadne> by "yes, do that"
2021-04-25 13:53:08 <Ariadne> as we have for iproute2
2021-04-25 13:53:13 <mps> Ariadne: yes, I know and all this I explained here when created MR
2021-04-25 13:53:38 <Sheila> and I'd prefer to see an actually minimal approach versus piecemeal axing away at things
2021-04-25 13:54:01 <Ariadne> so what are you complaining about?  the feedback in !13680 is that splitting out the vim syntax files isn't enough verses just making a vim-minimal subpackage
2021-04-25 13:54:04 <Ariadne> :p
2021-04-25 13:54:16 <Sheila> e.g. I'd expect vim-minimal to have at least a *few* syntax files, e.g. for config
2021-04-25 13:54:44 <mps> Ariadne: :P
2021-04-25 13:55:04 <Ariadne> they did not say "don't work on this", they said go farther than just splitting syntax files
2021-04-25 13:55:28 <Sheila> ^
2021-04-25 13:55:51 <Sheila> (I maintain vim package for Adélie, so I'm interested in this work too)
2021-04-25 13:56:03 <mps> ehm, I don't have more time now, have to fix wifi driver on this new-old chromebook which is my workstation
2021-04-25 13:56:06 <Ariadne> bratkartoffel: i'll look at it in a sec, i'm just wrapping up hostapd security fixes
2021-04-25 13:56:12 <Ariadne> mps: :)
2021-04-25 13:56:35 <Ariadne> mps: yes, fixing wifi driver is better than arguing over this :)
2021-04-25 13:56:58 <mps> btw, built kernel on arm32 in about 45 minutes. not bad
2021-04-25 13:57:42 <Ariadne> my oak chromebook is pretty speedy with the work you did to get mainline kernel going on it
2021-04-25 13:57:43 <mps> lets reboot and see did I had luck with driver fixes
2021-04-25 13:57:48 <Ariadne> almost as fast as my honeycomb
2021-04-25 13:58:11 <mps> yes, oak is really fast, though it is old model
2021-04-25 13:58:35 <mps> but I broke keyboard on it :(
2021-04-25 13:58:36 <Ariadne> i'm not complaining, i only paid 150$ for it new
2021-04-25 13:59:04 <Ariadne> the POS laptop i have that is dying on me now cost almost 3 grand
2021-04-25 13:59:14 <Ariadne> and the chromebook is nearly as fast as that thing too
2021-04-25 14:00:05 <Ariadne> alright, pushed hostapd and wpa-supplicant fixes
2021-04-25 14:00:32 <Ariadne> bratkartoffel: i don't know shit about java
2021-04-25 14:00:38 <Ariadne> bratkartoffel: what order do i need to push these in
2021-04-25 14:01:21 <Sheila> iirc ant is needed for maven, not sure about gradle
2021-04-25 14:02:17 <Ariadne> yeah thats what i figured
2021-04-25 14:03:23 <Ariadne> bratkartoffel: ok merged
2021-04-25 14:09:59 <bratkartoffel> Ariadne: thanks, i'll keep an eye on the build
2021-04-25 14:12:26 <donoban> Ariadne: the pkgdesc was a joke :D
2021-04-25 14:13:13 <donoban> I'm getting this error on rootpkg: "mv: can't rename '/home/builder/aports/testing/bubblejail/pkg/Bubblejail/usr/share/fish/completions': No such file or directory"
2021-04-25 14:13:42 <donoban> ah I think that I discovered the problem
2021-04-25 14:25:39 <donoban> it uses "fish/vendor_completions.d'", should I patch it to 'fish/completions' ?
2021-04-25 14:59:05 <Ariadne> yes
2021-04-25 14:59:13 <Ariadne> just rename it in prepare()
2021-04-25 14:59:22 <Ariadne> prepare() { default_prepare; mv whatever  whatever }
2021-04-25 14:59:35 <Ariadne> o whatever
2021-04-25 14:59:37 <Ariadne> idk
2021-04-25 15:00:57 <donoban> ah, I patched the meson.build file
2021-04-25 15:01:09 <donoban> well, I think that the dir doesn't exist before build
2021-04-25 15:10:07 <donoban> test fails due undefined KeyError: 'XDG_RUNTIME_DIR'
2021-04-25 15:10:19 <donoban> should I define it arbitrary in check()?
2021-04-25 15:10:45 <donoban> XDG_RUNTIME_DIR=/run/user/1000 ?
2021-04-25 15:13:51 <donoban> uhM, maybe is not possible to run this checks on a container/builder since it will try to seccomp some process
2021-04-25 15:31:25 <donoban> localhost:~/.local/share/bubblejail/instances/FirefoxInstance$ bubblejail run FirefoxInstance
2021-04-25 15:31:27 <donoban> b"bwrap: Can't find source path /etc/ld.so.cache: No such file or directory\n"
2021-04-25 15:36:09 <Ariadne> :D
2021-04-25 15:36:14 <Ariadne> its gonna have to be patched i guess
2021-04-25 15:36:18 <Ariadne> that's a glibc file
2021-04-25 15:36:23 <Ariadne> we dont have that here
2021-04-25 15:36:39 <donoban> yeah I had some idea about it
2021-04-25 15:36:50 <donoban> it seems that it's directly brwap error
2021-04-25 15:37:13 <donoban> but maybe is a bubblejail passing some wrong option
2021-04-25 15:37:26 <ericonr> yes
2021-04-25 15:37:33 <ericonr> see solution in https://gitlab.gnome.org/GNOME/gnome-desktop/-/merge_requests/107
2021-04-25 15:38:19 <donoban> ah great
2021-04-25 15:48:29 <donoban> ohh it works!
2021-04-25 15:49:00 <donoban> I noticed it changes my user home with an standard user name
2021-04-25 15:49:03 <donoban> file:///home/user/Downloads/
2021-04-25 15:49:08 <donoban> +1 for privacy lol
2021-04-25 15:50:46 <Ariadne> :)
2021-04-25 15:51:07 <Ariadne> see, its nice to use actually good software
2021-04-25 15:51:09 <Ariadne> verses firejail
2021-04-25 15:51:13 <Ariadne> which is actually a troll
2021-04-25 15:52:04 <donoban> yeah
2021-04-25 16:01:44 <donoban> !20852
2021-04-25 16:02:32 <donoban> probably it needs more testing
2021-04-25 16:06:07 <Ariadne> donoban: see the notes i left
2021-04-25 16:07:35 <donoban> ok thanks
2021-04-25 16:09:05 <donoban> Ariadne: what line do you see redundat? the builddir=$srcdir ?
2021-04-25 16:09:13 <Ariadne> yes
2021-04-25 16:09:25 <donoban> if I remove it, it fails patching
2021-04-25 16:09:32 <donoban> >>> bubblejail: Unpacking /var/cache/distfiles/bubblejail-0.4.2.tar.gz...
2021-04-25 16:09:34 <donoban> >>> ERROR: bubblejail: Is $builddir set correctly?
2021-04-25 16:09:36 <donoban> >>> ERROR: bubblejail: prepare failed
2021-04-25 16:09:46 <Ariadne> hmm, what is in $srcdir
2021-04-25 16:09:57 <donoban> let me check
2021-04-25 16:10:15 <Ariadne> normally builddir is initialized to "$srcdir"/$pkgname-$pkgver
2021-04-25 16:10:27 <donoban> ah
2021-04-25 16:10:37 <donoban> the problem is that it has all the tarball on src
2021-04-25 16:10:45 <Ariadne> i guess keep it then
2021-04-25 16:10:45 <donoban> it doesnt has a $pkgname-$pkgver dir
2021-04-25 16:10:58 <donoban> ok
2021-04-25 16:11:06 <Ariadne> though we should figure out why
2021-04-25 16:11:25 <donoban> maybe is just the way they created the tar.gz?
2021-04-25 16:11:42 <Ariadne> guess so
2021-04-25 16:12:17 <donoban> maybe the unpack could check if there is a main dir or not, and in the second case create it
2021-04-25 16:12:23 <Ariadne> ehh
2021-04-25 16:12:30 <Ariadne> nah
2021-04-25 16:12:35 <donoban> it will break too many things
2021-04-25 16:12:37 <donoban> xd
2021-04-25 16:12:38 <Sheila> yes, tarball is improperly packed
2021-04-25 16:12:59 <Ariadne> PureTryOut[m]2: i note in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20844#note_154415 you say to remove a pmOS-specific comment about qmlplugindump failing
2021-04-25 16:13:09 <Ariadne> PureTryOut[m]2: is there anything we can do from our side to solve that?
2021-04-25 16:14:46 <Sheila> if you use https://github.com/igo95862/bubblejail/archive/refs/tags/0.4.2.tar.gz instead of https://github.com/igo95862/bubblejail/releases/download/0.4.2/bubblejail-0.4.2.tar.gz you get a properly-packed tarball
2021-04-25 16:15:07 <Ariadne> ah, i guess https://bugs.launchpad.net/qemu/+bug/1895305 is this issue
2021-04-25 16:16:09 <Ariadne> i have some ideas as to what this might be
2021-04-25 16:16:12 <Ariadne> i'll dig into it
2021-04-25 16:19:40 <donoban> ah, ok Sheila I will fix it
2021-04-25 17:12:59 <Ariadne> z3ntu: i'm working on fixing qemu
2021-04-25 17:13:18 <z3ntu> oh cool :D
2021-04-25 17:14:00 <z3ntu> Ariadne: keep me updated on what you find :)
2021-04-25 17:14:45 <Ariadne> z3ntu: glibc signals SIGRT32 for a thread cancel, musl signals SIGRT33
2021-04-25 17:16:04 <Ariadne> the other difference is that musl uses tkill(2) instead of tgkill(2)
2021-04-25 17:16:26 <Ariadne> so, the next step is to check how qemu handles tkill/tgkill redirections
2021-04-25 17:16:48 <Ariadne> probably uninitialized or truncated data somewhere
2021-04-25 17:16:58 <Ariadne> thats what it was last time i debugged this sort of thing
2021-04-25 17:19:39 <Ariadne> rt_sigprocmask(SIG_SETMASK, ~[BUS KILL SEGV STOP RTMIN RT_1 RT_2], NULL, 8) = 0
2021-04-25 17:19:39 <Ariadne> tkill(1352, SIGRT_4)                    = ?
2021-04-25 17:19:39 <Ariadne> +++ killed by SIGRT_4 +++
2021-04-25 17:19:40 <Ariadne> hmm :)
2021-04-25 17:20:43 <Ariadne> so i think something isnt being set up right by qemu
2021-04-25 17:23:08 <Ariadne> hmm
2021-04-25 17:23:09 <Ariadne> ignore-signals-33-and-64-to-allow-golang-emulation.patch
2021-04-25 17:25:28 <Ariadne> i'm pretty sure it is this
2021-04-25 17:27:18 <Ariadne> \h:\w\$ qemu-aarch64 ./musl-static.out
2021-04-25 17:27:18 <Ariadne> zsh: unknown signal  qemu-aarch64 ./musl-static.out
2021-04-25 17:27:27 <Ariadne> so the RT36 comes from ash
2021-04-25 17:27:28 <Ariadne> ok
2021-04-25 17:32:10 <Ariadne> i dont think we need this patch anymore anyway
2021-04-25 17:32:19 <Ariadne> because go uses a different signalling mechanism these days
2021-04-25 17:33:57 <Ariadne> i'm checking
2021-04-25 17:39:03 <Ariadne> ok
2021-04-25 17:39:06 <Ariadne> yeah
2021-04-25 17:39:08 <Ariadne> its this patch
2021-04-25 17:39:11 <Ariadne> which we dont even need anyway
2021-04-25 17:40:04 <Ariadne> nanabozho:~/aports/community/qemu/src/qemu-5.2.0/build-static/aarch64-linux-user$ ./qemu-aarch64 ~/qemu-pthread_cancel/musl-static.out
2021-04-25 17:40:04 <Ariadne> OK, alive
2021-04-25 17:42:31 <Ariadne> z3ntu: got it ^
2021-04-25 17:42:40 <Ariadne> z3ntu: this is our bug, it doesn't affect upstream
2021-04-25 17:44:45 <z3ntu> I do recall seeing this patch in aports, not sure why I didnt try without this patch...
2021-04-25 17:45:25 <Ariadne> 5.2.0-r5 has the patch removed
2021-04-25 17:45:27 <Ariadne> we don't need it
2021-04-25 17:45:34 <Ariadne> go uses a totally different signalling mechanism now
2021-04-25 17:45:39 <Ariadne> with eventfd
2021-04-25 17:45:58 <Ariadne> and i suspect the patch was broken anyway
2021-04-25 17:52:43 <donoban> Ariadne: did you write soemthing to firejail maintainer? I suppose that it's something really minor but maybe would be nice to add to https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0 , for users that currently using it
2021-04-25 17:56:36 <Ariadne> donoban: why would i write to a troll and/or APT?
2021-04-25 17:57:18 <donoban> uHM, are you sure is he a troll?
2021-04-25 17:57:26 <Ariadne> yeah
2021-04-25 17:57:29 <Ariadne> i'm pretty sure
2021-04-25 17:57:42 <donoban> https://pkgs.alpinelinux.org/packages?name=&branch=edge&maintainer=Stuart+Cardall
2021-04-25 17:57:43 <Ariadne> you have to work at making such a broken software
2021-04-25 17:57:48 <Ariadne> oh
2021-04-25 17:57:52 <Ariadne> the package maintainer
2021-04-25 17:57:55 <donoban> yes
2021-04-25 17:57:57 <donoban> :D
2021-04-25 17:58:00 <Ariadne> i did notify him that it was removed
2021-04-25 17:58:22 <donoban> ok
2021-04-25 17:59:17 <skarnet> Ariadne: Hanlon's razor cuts again
2021-04-25 17:59:46 <Ariadne> skarnet: nah
2021-04-25 18:00:02 <Ariadne> skarnet: firejail is so bad that you would have to intentionally do it this badly
2021-04-25 18:00:22 <skarnet> that can be said of a lot of bad things in the world, and yet
2021-04-25 18:00:48 <Ariadne> but still
2021-04-25 18:01:00 <Ariadne> what value can be derived with talking to an upstream that produced ... that
2021-04-25 18:01:12 <Ariadne> at some point you just have to cut your losses
2021-04-25 18:01:31 <skarnet> oh, I agree
2021-04-25 18:01:40 <skarnet> it doesn't change the outcome
2021-04-25 18:01:59 <Ariadne> its ok
2021-04-25 18:02:04 <donoban> well at least there is a promising alternative
2021-04-25 18:02:57 <Ariadne> i'm planning to use firejail as an example program to break in future cybersecurity curriculum that i teach, if i ever wind up doing that again
2021-04-25 18:03:31 <Ariadne> even the most novice reverse engineer should be able to jailbreak from firejail
2021-04-25 18:03:33 <Ariadne> :)
2021-04-25 18:03:40 <skarnet> firejailbreak
2021-04-25 18:04:24 <Ariadne> z3ntu: anyway thanks for your work on the testcase
2021-04-25 18:08:55 <Ariadne> donoban: i accepted your bubblejail package
2021-04-25 18:09:38 <ikke> Ariadne: forgot to squash commits
2021-04-25 18:09:45 <Ariadne> f
2021-04-25 18:10:11 <donoban> great :D
2021-04-25 18:10:20 <donoban> I wil test intensively this week
2021-04-25 18:10:27 <donoban> probably I should push some fix
2021-04-25 18:10:29 <ikke> donoban: would be nice if you could squash / fixup commits
2021-04-25 18:10:47 <donoban> uhM, how?
2021-04-25 18:10:53 <ikke> git rebase
2021-04-25 18:11:14 <Ariadne> no point in doing it now
2021-04-25 18:11:32 <donoban> well but I don't know exactly what to do next time
2021-04-25 18:11:54 <donoban> I have an opened MR
2021-04-25 18:11:55 <Ariadne> git rebase --interactivee
2021-04-25 18:11:56 <donoban> with tons of commits
2021-04-25 18:12:03 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20480
2021-04-25 18:12:13 <donoban> could I fix this?
2021-04-25 18:12:22 <ikke> yes
2021-04-25 18:12:37 <donoban> let me try
2021-04-25 18:12:39 <Ariadne> yes with git rebase --interactive
2021-04-25 18:13:22 <donoban> let "noop" as comment?
2021-04-25 18:13:40 <ikke> git rebase -i master
2021-04-25 18:14:10 <donoban> uhM
2021-04-25 18:14:49 <donoban> conflicts :\
2021-04-25 18:15:17 <ikke> git rebase --abort
2021-04-25 18:15:37 <ikke> What branch did you base your feature branch on?
2021-04-25 18:15:53 <donoban> uhmM
2021-04-25 18:16:06 <donoban> note that I first did: git rebase --interactiv
2021-04-25 18:16:21 <donoban> I suppose that it's based on master
2021-04-25 18:16:29 <donoban> but probably on a older master
2021-04-25 18:18:02 <donoban> currently I see all commits on git log
2021-04-25 18:18:19 <donoban> maybe should pull from upstream master before doing the rebase?
2021-04-25 18:18:27 <Ariadne> git pull --rebasee
2021-04-25 18:18:30 <Ariadne> git pull --rebase
2021-04-25 18:18:33 <Ariadne> then do
2021-04-25 18:18:43 <Ariadne> git rebase origin/master --interactive
2021-04-25 18:19:06 <donoban> git pull --rebase or git pull upstream --rebase?
2021-04-25 18:19:15 <donoban> first only does
2021-04-25 18:19:17 <donoban> localhost:~/aports$ git pull --rebase
2021-04-25 18:19:19 <donoban> ⚠ redirecting to https://gitlab.alpinelinux.org/donoban/aports.git/
2021-04-25 18:19:21 <donoban> Already up to date.
2021-04-25 18:19:33 <Ariadne> ok then
2021-04-25 18:19:39 <Ariadne> git rebase origin/master --interactivee
2021-04-25 18:19:45 <Ariadne> it should only show you your own commits
2021-04-25 18:19:56 <donoban> yes
2021-04-25 18:20:06 <donoban> great
2021-04-25 18:20:09 <donoban> ahh
2021-04-25 18:20:10 <donoban> conflict agian
2021-04-25 18:20:13 <donoban> same conflict than before
2021-04-25 18:20:15 <Ariadne> :D
2021-04-25 18:20:22 <donoban> localhost:~/aports$ git rebase origin/master --interactive
2021-04-25 18:20:23 <donoban> Auto-merging community/tg_owt/APKBUILD
2021-04-25 18:20:25 <donoban> CONFLICT (content): Merge conflict in community/tg_owt/APKBUILD
2021-04-25 18:20:35 <Ariadne> resolve it
2021-04-25 18:20:36 <donoban> can I force my version?
2021-04-25 18:20:36 <Ariadne> then do
2021-04-25 18:20:48 <Ariadne> git add community/tg_owt/APKBUILD *after* fixing the file with your editor
2021-04-25 18:20:54 <Ariadne> then git rebase --continue
2021-04-25 18:21:10 <donoban> ok
2021-04-25 18:26:07 <donoban> something is wrong here
2021-04-25 18:27:18 <donoban> this source:         libyuv-$_libyuv_commit.zip::https://codeload.github.com/lemenkov/libyuv/zip/$_libyuv_commit is totally lost when I do the rebase
2021-04-25 18:27:36 <donoban> it's replaced with googlesource URLS that were problematic with checksums
2021-04-25 18:27:56 <donoban> I try to fix the conflict and the right URL has dissapeared :\
2021-04-25 18:28:25 <donoban> uhM
2021-04-25 18:32:37 <donoban> I'm gonna save the file before rebasing and then replacing it
2021-04-25 18:36:50 <donoban> >>> tg_owt: Updating the sha512sums in APKBUILD...
2021-04-25 18:36:52 <donoban> sha512sum: can't open 'cmake_fixes.patch': No such file or directory
2021-04-25 18:36:54 <donoban> >>> ERROR: tg_owt: sha512sum failed
2021-04-25 18:36:56 <donoban> great, it removed it :|
2021-04-25 18:37:43 <donoban> maybe is easier to close this MR and reopen another
2021-04-25 18:37:44 <donoban> :D
2021-04-25 18:42:56 <Sheila> nah, `git rebase --abort` and check the log for your commits specifically, then rebase with that range.
2021-04-25 18:43:12 <donoban> uhM
2021-04-25 18:43:53 <PureTryOut[m]2> Ariadne: not really, it's a Qemu bug afaik. More details in https://gitlab.com/postmarketOS/pmbootstrap/-/issues/1970
2021-04-25 18:44:05 <Ariadne> it is
2021-04-25 18:44:11 <Ariadne> we fixed it already
2021-04-25 18:44:11 <Ariadne> :p
2021-04-25 18:44:49 <Ariadne> or rather i did
2021-04-25 18:44:55 <Ariadne> earlier today
2021-04-25 18:45:39 <PureTryOut[m]2> Oh lol nice. But we don't have packages in pmOS anymore with that problem 😛 Thanks for any future packages though!
2021-04-25 18:45:49 <PureTryOut[m]2> Got a link to the fix so I can mention it in the issue?
2021-04-25 18:46:03 <Ariadne> i updated it
2021-04-25 18:46:18 <PureTryOut[m]2> Oh derp lol
2021-04-25 18:47:34 <donoban> Sheila: it seems that I end on the same problems
2021-04-25 18:50:03 <Sheila> `git rebase -i FirstCommitOfInterest...LastCommitOfInterest`, I think?
2021-04-25 18:50:11 <donoban> yes
2021-04-25 18:50:27 <donoban> well, without the ...
2021-04-25 18:51:48 <donoban> honestly is more simple to go master and overrwite the files
2021-04-25 18:51:48 <Sheila> ah, well, that's why it didn't work. you want to specify the range of commits, not the first and last, hence the ...
2021-04-25 18:52:13 <donoban> uhm , I always get something like this
2021-04-25 18:52:34 <donoban> https://tpaste.us/axbB
2021-04-25 18:53:06 <donoban> but then it conlficts and conflicts and conflicts
2021-04-25 18:53:20 <donoban> I fix, git commit add, git rebase --continue, conflict
2021-04-25 18:53:58 <donoban> I can save both tg_owt, telegram dirs, create a new branch from master overwrite them and just commit
2021-04-25 18:54:06 <donoban> community/telegram-desktop: upgrade to 2.7.1 (add maintainer)  :D
2021-04-25 18:54:27 <Sheila> you could also try `git rebase -i HEAD~5`, given how recent it is.
2021-04-25 18:54:43 <donoban> let's try :D
2021-04-25 18:54:47 <Sheila> (maybe ~6)
2021-04-25 18:55:29 <donoban> Successfully rebased and updated detached HEAD.
2021-04-25 18:55:39 <donoban> but I guess it is not final yet
2021-04-25 18:56:38 <donoban> uhM, now git status says:
2021-04-25 18:56:43 <donoban> HEAD detached at refs/heads/telegram-newtry
2021-04-25 18:58:48 <Sheila> you were able to merge your commits in to one, though, right?
2021-04-25 18:58:58 <Sheila> s/merge/rebase/
2021-04-25 18:58:58 <alpine-meetbot> Sheila meant to say: you were able to rebase your commits in to one, though, right?
2021-04-25 18:59:23 <donoban> uhM, with last command?
2021-04-25 19:05:20 <Sheila> yes.
2021-04-25 19:07:49 <donoban> sorry Sheila , I appreciate your effort on doing it with the right way, but I give up for today :)
2021-04-25 19:07:58 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20855
2021-04-25 19:09:56 <donoban> oh my god
2021-04-25 19:10:01 <donoban> build failed :(
2021-04-25 19:15:26 <donoban> well, now I have an easy game
2021-04-25 19:15:33 <donoban> could I mix this two commits? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20855/commits
2021-04-25 19:15:48 <donoban> I tried "git rebase -i" and "git rebase -i master"
2021-04-25 19:19:37 <Sheila> so what did you do when the screenful of commits popped up? cos the process is basically just replacing 'pick' with 'fixup' for the commits *after* the one you want to use the commit message for, and you can reorder commits to make it easier.
2021-04-25 19:20:51 <donoban> I didn't modify nothing
2021-04-25 19:22:33 <Sheila> okay, then here you would do `git rebase -i HEAD~2` and change 'pick' before the last commit in the list to 'fixup', then save and quit.
2021-04-25 19:22:53 <donoban> well I did pulled from upsteram
2021-04-25 19:23:00 <donoban> and now I have another commit
2021-04-25 19:23:33 <donoban> let's try... I hope not to end your patience :S
2021-04-25 19:24:13 <Sheila> okay. in the future, before you do any work, do `git checkout -b somebranchname` and don't pull on anything while in that branch. (you can switch branches via `git branch`)
2021-04-25 19:24:34 <donoban> yes yes I've already do that
2021-04-25 19:24:45 <donoban> let me show you
2021-04-25 19:25:15 <donoban> https://tpaste.us/qgmy
2021-04-25 19:25:33 <donoban> my two commits and the third from upstream
2021-04-25 19:25:49 <Sheila> okay. `pick da10fc61cc Add missing files` -> `fixup da10fc61cc Add missing files`
2021-04-25 19:26:18 <Sheila> and cut and paste the third one so that it's the first in the list.
2021-04-25 19:26:19 <donoban> should I rename to community/telegram-desktop: upgrade to 2.7.1 (add maintainer) ?
2021-04-25 19:26:31 <Sheila> no, don't touch anything else.
2021-04-25 19:26:57 <donoban> ah
2021-04-25 19:27:07 <donoban> so I should replaced all the picks with fixup?
2021-04-25 19:27:18 <Sheila> no. only the one I specifically told you.
2021-04-25 19:27:29 <donoban> i mean when I had 50 commits
2021-04-25 19:28:09 <Sheila> again, no. only the commits you are specifically flattening in to the parent commit.
2021-04-25 19:30:04 <donoban> the 99%
2021-04-25 19:30:10 <donoban> the idea is not left just 1 commit?
2021-04-25 19:30:30 <donoban> lol
2021-04-25 19:30:32 <donoban> Sheila⏪
2021-04-25 19:30:44 <donoban> now the other commit is on my MR
2021-04-25 19:30:46 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20855/commits
2021-04-25 19:31:11 <Sheila> yes, that is why I told you to put it at the top.
2021-04-25 19:31:21 <donoban> I did it!
2021-04-25 19:31:49 <donoban> in my git log it is before my commit
2021-04-25 19:32:00 <donoban> maybe
2021-04-25 19:32:02 <Sheila> okay, brainfart on my end; it should have been `drop`ed
2021-04-25 19:32:02 <donoban> if I rebase the MR
2021-04-25 19:32:25 <Sheila> (that is, replace `pick` before it with `drop` when you rebase)
2021-04-25 19:32:33 <donoban> ok
2021-04-25 19:32:57 <Sheila> and don't pull upstream mid-work again ;)
2021-04-25 19:33:36 <donoban> fixup a682714fd6 Use different URL for get properly packed tarball
2021-04-25 19:33:38 <donoban> drop 11d0ca3667 community/cloud-utils: add growpart reliability patch
2021-04-25 19:33:40 <donoban> pick 5f3d8af279 community/telegram-desktop: upgrade to 2.7.1 (add maintainer)
2021-04-25 19:33:54 <donoban> hehe yes sorry
2021-04-25 19:34:21 <Sheila> no, leave that first one alone since its parent commit isn't listed here
2021-04-25 19:34:45 <donoban> uhM, I don't get it
2021-04-25 19:35:31 <Sheila> the commit you're want to flatten that first one in to isn't in the list, so it should be left alone.
2021-04-25 19:35:58 <donoban> should redo with HEAD~4?
2021-04-25 19:38:41 <Sheila> if those commits are already upstream, it's best to leave it alone.
2021-04-25 19:39:28 <donoban> Successfully rebased and updated refs/heads/telegram.
2021-04-25 19:39:36 <donoban> this seems good
2021-04-25 19:40:21 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20855/commits
2021-04-25 19:40:24 <donoban> yeah! :D
2021-04-25 19:41:09 <donoban> so the policy is 1 upgrade / new packet / similar... -> 1 commit ?
2021-04-25 19:41:18 <Sheila> :toot:
2021-04-25 19:42:33 <Sheila> donoban: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md
2021-04-25 19:42:53 <donoban> oh yes :)
2021-04-25 19:43:14 <donoban> I will read before doing anything
2021-04-25 19:44:36 <tomleb>   Is it better/faster to use gitlab for patches or mailing list? My patch still hasn't been added and I have no feedback on it. Am I too impatient? :)
2021-04-25 19:46:06 <mps> tomleb: gitlab is better
2021-04-25 19:47:07 <mps> usually faster also
2021-04-25 19:49:27 <ikke> :fmt.Printf("%#v", releases)
2021-04-25 19:58:23 <wdtTP2O82Kft> i was wondering, if firejail sucks, but bubblewrap doesnt (i suppose its not suid?), then i wonder what about minijail or nsjail, how do all these compare to each other, why does bubblewrap come out on top?
2021-04-25 19:59:01 <ikke> We already use bubblewrap
2021-04-25 20:00:00 <wdtTP2O82Kft> oh? where and how?
2021-04-25 20:00:48 <ikke> abuild uses bubblewrap when you use rootbuild
2021-04-25 20:01:18 <wdtTP2O82Kft> oh. right. that makes sense. but that is more of a dev feature, and less of a security feature i guess?
2021-04-25 20:01:29 <ikke> Right
2021-04-25 20:02:22 <wdtTP2O82Kft> but firejail,bubblewrap,nsjail and minijail are marketed as security tools. and i wonder about them in that context
2021-04-25 20:03:33 <Sheila> firejail is just not a security tool, despite attempts to market it as one.
2021-04-25 20:04:09 <Sheila> I can't comment on nsjail or minijail, though.
2021-04-25 20:08:28 <wdtTP2O82Kft> well, i guess it also depends on the threatmodell, it might make sense to use firejail to sandbox things and increase security in terms of rce, but on the otherhand it also decreases security when it comes to lpe - or is there more to it?
2021-04-25 20:13:20 <Sheila> firejail is incredibly broken and not developed with real security in mind, is the problem.
2021-04-25 20:14:11 <wdtTP2O82Kft> do you have references for this? i'm very interested in learn about this (and also in comparison to the other 3 tools i listed)
2021-04-25 20:17:21 <wdtTP2O82Kft> oh. cloudflare also built something similar with very good seo in mind, called it sandbox
2021-04-25 20:17:42 <Sheila> >sandbox >good seo >mfw
2021-04-25 20:18:03 <Thermi> Why does abuild think "    masked in: --no-network"
2021-04-25 20:18:06 <Thermi> ?
2021-04-25 20:18:06 <Sheila> Ariadne did some poking this morning, hence it being removed from Alpine (again)
2021-04-25 20:18:44 <Thermi> I'm just invoking abuild
2021-04-25 20:19:10 <Ariadne> Thermi invoking it how
2021-04-25 20:19:30 <Thermi> https://bpa.st/DXHA
2021-04-25 20:19:39 <Thermi> Pasted into the shell directly
2021-04-25 20:19:47 <Ariadne> no idea
2021-04-25 20:19:51 <Thermi> Fucking abuild
2021-04-25 20:19:59 <Ariadne> it shouldn't be invoking apk with --no-network theree
2021-04-25 20:21:09 <Ariadne> wdtTP2O82Kft: firejail has had a gazillion CVEs
2021-04-25 20:21:21 <Ariadne> wdtTP2O82Kft: it is also SUID
2021-04-25 20:22:36 <Ariadne> wdtTP2O82Kft: one of the CVEs was so utterly stupid, you could bind-mount over /etc and then root the system that way (e.g. by replacing /etc/shadow)
2021-04-25 20:23:10 <wdtTP2O82Kft> yeah, i saw that, but looking at https://firejail.wordpress.com/download-2/cve-status/ - it seems there was a bunch in 2016, but only 2 / year in the last to years.
2021-04-25 20:23:30 <Ariadne> yes, well the correct number is zero
2021-04-25 20:23:38 <Ariadne> we will not be readding it
2021-04-25 20:24:18 <Thermi> Ariadne: apk lies: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/commit.c#L425
2021-04-25 20:24:18 <wdtTP2O82Kft> there's not many packages with 0, based on that argument, alpine would be easily maintained :P
2021-04-25 20:24:33 <Sheila> there are vulnerabilities in it even today, or so I was told this morning.
2021-04-25 20:24:41 <Sheila> basic newbie-tier shit.
2021-04-25 20:25:32 <wdtTP2O82Kft> and i guess it has to be suid if it wants to do container stuff
2021-04-25 20:25:34 <Ariadne> Thermi: ah, you have some orphaned dependency i guess
2021-04-25 20:25:45 <Ariadne> wdtTP2O82Kft: no it doesn't
2021-04-25 20:26:22 <Ariadne> you can do clone(2) into a new userns without root privilege
2021-04-25 20:26:31 <Thermi> Guess I have to rebuild the VM then. I didn't do any esoteric shit in it.
2021-04-25 20:26:43 <Thermi> Or the notebook's HW (likely) fucks with me.
2021-04-25 20:26:48 <Ariadne> Thermi try using apk fix
2021-04-25 20:27:01 <dalias> ariadne, lol wtf how could you root the system by bind-mounting over /etc/shadow?
2021-04-25 20:27:17 <Ariadne> dalias: supply new /etc/shadow :)
2021-04-25 20:27:19 <Thermi> bind mount a shadow file over it with a known root password
2021-04-25 20:27:38 <dalias> yes but then there's nothing that will be interpreting your replacement with top-level-user-namespace root
2021-04-25 20:27:48 <Ariadne> nono
2021-04-25 20:27:50 <dalias> only things running inside your namespace
2021-04-25 20:27:52 <dalias> which run as you
2021-04-25 20:27:53 <Ariadne> nonono
2021-04-25 20:27:58 <Sheila> you're assuming it's using namespaces.
2021-04-25 20:27:58 <Thermi> :D
2021-04-25 20:28:04 <Ariadne> firejail was doing this outside the namespace
2021-04-25 20:28:16 <dalias> lmao wtf
2021-04-25 20:28:30 <Ariadne> it was using unionfs wrong
2021-04-25 20:28:33 <Ariadne> or some shit
2021-04-25 20:28:37 <Ariadne> there's a CVE about it
2021-04-25 20:28:50 <dalias> this sounds like it would jut be world-breaking
2021-04-25 20:28:55 <Ariadne> but basically
2021-04-25 20:28:59 <dalias> before you even get to the 'this is a vuln' stage
2021-04-25 20:29:02 <Ariadne> you could give some flag to firejail
2021-04-25 20:29:03 <dalias> like everything on the system would break
2021-04-25 20:29:08 <Ariadne> yeah so
2021-04-25 20:29:13 <Ariadne> you could give some flag to firejail
2021-04-25 20:29:15 <wdtTP2O82Kft> zomg so much more jailing tools: https://www.linuxor.sk/index.php?cat=linkz&doc=technologies-linux-sandbox
2021-04-25 20:29:17 <dalias> because you fucked up the top-level mount namespace's /etc
2021-04-25 20:29:20 <Ariadne> like --mount /etc:/whatever
2021-04-25 20:29:25 <Ariadne> and the top level /etc
2021-04-25 20:29:27 <Ariadne> gets replaced
2021-04-25 20:29:34 <dalias> why is firejail suid anyway??
2021-04-25 20:29:40 <tomleb> mps: thanks, I'll use gitlab for following patches
2021-04-25 20:29:48 <dalias> you can do anything it *should* be doing without root
2021-04-25 20:30:28 <Sheila> because it's badly-written software.
2021-04-25 20:30:38 <dalias> :-p
2021-04-25 20:30:41 <Sheila> (which is precisely why it shouldn't be)
2021-04-25 20:31:37 <Ariadne> https://seclists.org/oss-sec/2017/q1/25
2021-04-25 20:31:43 <Ariadne> the --tmpfs thing still works to this day
2021-04-25 20:32:03 <Ariadne> just build yourself a nice chain of SUID commands to run
2021-04-25 20:32:07 <Ariadne> its so stupid
2021-04-25 20:32:15 <Ariadne> but basically you can --tmpfs /etc
2021-04-25 20:32:44 <Ariadne> the system is entirely screwed of course if you actually do this
2021-04-25 20:32:47 <Ariadne> but it will let you gain root
2021-04-25 20:32:48 <Ariadne> ;)
2021-04-25 20:32:51 <Hello71> "--tmpfs allowd only as root user"
2021-04-25 20:32:54 <Ariadne> yeah
2021-04-25 20:33:03 <Ariadne> there's ways around that :p
2021-04-25 20:33:37 <Sheila> anyway a good jail operates on least-privilege. firejail...fails that egregiously.
2021-04-25 20:34:55 <skarnet> "--tmpfs /sbin" is much funnier
2021-04-25 20:35:58 <Ariadne> like i said
2021-04-25 20:36:01 <Ariadne> this software is so bad
2021-04-25 20:36:04 <Ariadne> it has to be a troll
2021-04-25 20:37:42 <Ariadne> i don't want to sound elitist but i feel like "security software" shipped by alpine should be written by people with some level of clue
2021-04-25 20:37:52 <Ariadne> not... whatever this is
2021-04-25 20:39:06 <skarnet> please sound elitist and own it
2021-04-25 20:39:13 <Sheila> ^
2021-04-25 20:39:16 <skarnet> tech desperately needs it
2021-04-25 20:40:23 <Ariadne> also the last time this came up
2021-04-25 20:40:28 <Ariadne> firejail had code like
2021-04-25 20:40:38 <Ariadne> if (!strcmp(getenv("USER"), "root")) {...}
2021-04-25 20:40:42 <Ariadne> sooooooo
2021-04-25 20:40:45 <Ariadne> :)
2021-04-25 20:40:55 <skarnet> lmfao
2021-04-25 20:41:33 <Ariadne> i don't wanna kink shame but...
2021-04-25 20:41:41 <skarnet> that's still not "troll" to me, that's "first year compsci student who wants to become famous with securitah"
2021-04-25 20:42:54 <Ariadne> isn't that the same thing tho
2021-04-25 20:43:21 <skarnet> now that you put it that way
2021-04-25 20:43:49 <Ariadne> but anyway, if you can gain euid=0
2021-04-25 20:43:58 <Ariadne> then it will gladly let you play with --tmpfs
2021-04-25 20:44:01 <Ariadne> sooooooo
2021-04-25 20:44:10 <Ariadne> just throwing that out there
2021-04-25 20:44:29 <skarnet> tbh with euid=0 I don't need firejail to do kinky shit with tmpfs :P
2021-04-25 20:44:58 <Ariadne> i think the only reason why this has a lack of CVEs is because any security person who comes near it just starts laughing hysterically
2021-04-25 20:45:56 <Ariadne> but its gone from alpine again
2021-04-25 20:46:00 <Sheila> should sponsor a student-level hackathon with prizes for best exploit, etc.
2021-04-25 20:46:02 <Ariadne> and hopefully this time it remains gone
2021-04-25 20:46:03 <Ariadne> from alpine
2021-04-25 20:46:05 <Ariadne> :)
2021-04-25 20:47:15 <Ariadne> but yeah if you can get by its (broken) root checks
2021-04-25 20:47:21 <Ariadne> it will let you do all sorts of kinky shit
2021-04-25 20:47:22 <Ariadne> :p
2021-04-25 20:47:55 <Ariadne> i suspect at least 50% of the people on this channel could break it
2021-04-25 20:47:58 <Sheila> env USER=root firejail ...
2021-04-25 20:47:58 <Ariadne> :p
2021-04-25 20:48:09 <Ariadne> Sheila: for certain versions yes
2021-04-25 20:48:18 <Ariadne> not sure if that one is still usable
2021-04-25 20:48:26 <Ariadne> i'm sure there's something equally moronic tho
2021-04-25 20:59:24 <Ariadne> ikke: maybe we should replace all of lua-aports with your Go stuff?
2021-04-25 20:59:53 <ikke> Slowly working on it
2021-04-25 22:12:17 <donoban> wdtTP2O82Kft: I just started today with bubblejail and I feel that apart that it uses bwrap (which is theorically more robust and tested than firejail, and optionally nosuid) and written in python (theorically safer and arch indepent), I feel that it has a better design
2021-04-25 22:15:28 <donoban> firejail uses a massive set of rules defined on /etc/firejail/, at least in alpine most applications fail in some rule so or just use --noprofile and adapt to your needs or modifiy the configuration files
2021-04-25 22:19:52 <c705> donoban: i think you're supposed to define your own "local" profiles that override the defaults, but yeah, same idea
2021-04-25 22:20:10 <donoban> with bubblejail you have a few predefined profiles and services and you then define instances, I think that its a more organized way than hundreds of files on /etc/firejail
2021-04-25 22:21:22 <donoban> yes but if I have to set up my own pofiles don't ship it with hundreds of them supposed to work
2021-04-25 22:22:24 <donoban> bubblejail only has 8 profiles and at least firefox works as shipped :D
2021-04-25 22:22:52 <c705> donoban: it's preconfigured for systemd systems. 80% of the time they work
2021-04-25 22:23:19 <donoban> yes I guess that it's mostly based on ubuntu/debian/arch... but well
2021-04-25 22:23:21 <c705> better than shipping it with nothing. and most of the configuration works, it's just you might need minor teaks here and there which is what the local config do
2021-04-25 22:23:36 <c705> is it perfect? nah. but it's a pretty easy way to get sandboxing going
2021-04-25 22:24:05 <donoban> I don't know if removing it was really needed but here it does not have much affection
2021-04-25 22:24:52 <c705> and i probably wouldn't call python a "safe" language, but i've used firejail for a while and it works well for me
2021-04-25 22:26:36 <donoban> well I think it should be less error prone / memory safe / easy to maintain...
2021-04-25 22:27:17 <c705> memory safe, easy to maintain sure. but the duck typing leads to runtime throws, espcially if it was developed like shit
2021-04-25 22:28:52 <donoban> hehe well I don't know what to say, I was using fireijail until day, in fact I have some firejail process still running
2021-04-25 22:29:46 <donoban> I'm excited about migrate to bubblejail but I understand your feeling if you are using firejail for long time
2021-04-25 22:32:21 <donoban> it's time for sleep! good night guys see you tomorrow :D
2021-04-25 22:36:02 <wdtTP2O82Kft> hmm,  my question was not so much in defense of firejail, it was more like, what other solutions are there and how do they compare, see also nsjail, minijail for example
2021-04-26 00:14:24 <dalias> from what i read above, firejail is *much* worse than nothing
2021-04-26 00:14:52 <dalias> there is utterly no excuse for a sandbox to be suid
2021-04-26 00:16:02 <dalias> ariadne, how does dropping a horribly insecure package interact with security?
2021-04-26 00:16:06 <wdtTP2O82Kft> i'm confused, it seems both nsjail and minijail also need suid for some features
2021-04-26 00:16:36 <dalias> is there a notification of any sort that it was dropped for unfixed vuln reasons and that if you still have the last version that was available, it's insecure and should be removed?
2021-04-26 00:17:00 <dalias> wdttp2o82kft, presumably because ppl making this stuff don't know what they're doing ... ?
2021-04-26 00:17:15 <wdtTP2O82Kft> minijail is the sandbox on android
2021-04-26 00:17:53 <dalias> on android it might be because there are still devices with 15-year-old kernels...
2021-04-26 00:18:08 <ericonr> dalias: sandboxes not requiring root is more of a linux thing with user namespaces than a general *nix thing, right?
2021-04-26 00:24:42 <dalias> ericonr, if so, only because nobody else has bothered to do it right
2021-04-26 00:31:52 <wdtTP2O82Kft> hmmm, i just tried minijail works if i don't give it '-u nobody', however if i do, only with a sudo prefix it works. my kernel is 5.10, and i have minijail0 cap_setuid=eip
2021-04-26 00:41:27 <dalias> it's probably just minijail being misdesigned
2021-04-26 01:33:00 <craftyguy> why would building an app that uses getcontext fail only on ppc64? https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/379942#L956
2021-04-26 01:33:07 <craftyguy> (all other archs are fine)
2021-04-26 02:47:31 <dalias> maybe a bug in libucontext?
2021-04-26 02:59:08 <craftyguy> how? the failure is from ld: undefined reference to symbol 'getcontext'
2021-04-26 02:59:28 <craftyguy> even though libucontext-dev is installed, and no other arch have that problem
2021-04-26 02:59:37 <craftyguy> so maybe it's incomplete on ppc64 ?
2021-04-26 03:01:19 <craftyguy> ah this (libucontext) is Ariadne's project, maybe you know what's up with that :)
2021-04-26 03:11:27 <Sheila> add -lucontext to $LIBS
2021-04-26 03:17:14 <Sheila> (basically what's happening is that it doesn't know it needs to link libucontext, so however you tell meson to do that is what will fix it.)
2021-04-26 03:17:44 <Sheila> it's weird that it's only ppc64el that fails, though.
2021-04-26 03:18:06 <Sheila> craftyguy: ^
2021-04-26 03:29:49 <craftyguy> ah thanks, I'll try that
2021-04-26 03:38:02 <craftyguy> Sheila: nice that worked, thanks for the help :)
2021-04-26 04:19:47 <Thermi> Ariadne: I figured out what changed and broke at the very least my kopano service scripts. It looks like openrc circular dependency resolving broke because it doesn't break weak dependencies (want) first. Instead it just deadlocks.
2021-04-26 05:56:51 <mps> tomleb: I forgot to add that gitlab have APKBUILD linter and CI (which are very useful for review patches) and integrated bug/issue system
2021-04-26 05:57:09 <mps> (and not so good web interface :) )
2021-04-26 06:13:02 <Newbyte> craftyguy could be that its build scripts conditionally link differently depending on architecture, for example
2021-04-26 06:13:30 <Ariadne> dalias: well i did drop the package :p
2021-04-26 06:18:29 <mps> security is like a God, no one knows what is it but everyone talk about it
2021-04-26 06:18:48 <ncopa> good morning
2021-04-26 06:19:00 <mps> and there are even churches and priests of security
2021-04-26 06:19:09 <Ariadne> Thermi: yes, it seems like lots of regressions in openrc 0.43.x
2021-04-26 06:19:11 <mps> good morning :)
2021-04-26 06:19:17 <Ariadne> Thermi: i'm disappointed so far with it
2021-04-26 06:20:50 <Ariadne> dalias: as for package removal announcement, i can send a notice to alpine-devel list and make a note in the 3.14 release notes
2021-04-26 06:22:23 <mps> Ariadne: I see that you merged nvme-cli. does it build on ppc64le?
2021-04-26 06:23:13 <Ariadne> i can check but our ppc64le builder is MIA anyway
2021-04-26 06:23:47 <Ariadne> which is not good since we're about to do the 3.14 rebuild i guess
2021-04-26 06:23:49 <mps> yes, it is. nvme-cli failed in CI on ppc64le
2021-04-26 06:24:13 <Ariadne> let me check it on my ppc64le box
2021-04-26 06:24:33 <Ariadne> but first let me `apk fetch --force coffee` IRL
2021-04-26 06:24:51 <mps> sure, I just did that :)
2021-04-26 06:26:38 <craftyguy> Newbyte: yeah, it's probably something like that
2021-04-26 06:29:13 <Ariadne> mps: >>> nvme-cli: Building community/nvme-cli 1.14-r0 (using abuild 3.7.0-r1) started Mon, 26 Apr 2021 00:28:44 -0600
2021-04-26 06:29:40 <Ariadne> nvme-rpmb.c:201:19: error: 'PATH_MAX' undeclared (first use in this function); did you mean 'AF_MAX'?
2021-04-26 06:29:42 <Ariadne> indeed
2021-04-26 06:29:47 <Ariadne> but this is easy to fix
2021-04-26 06:30:20 <mps> yes, I think we had patch for this in some previous git commit for it
2021-04-26 06:31:03 <mps> can't access my dev lxcs right now to check
2021-04-26 06:32:26 <Ariadne> its because they aren't including limits.h
2021-04-26 06:32:52 <Ariadne> i guess on other platforms it winds up included somehow
2021-04-26 06:34:09 <mps> probably (black/white magic)
2021-04-26 06:35:47 <Ariadne> i'll send a PR to them in a moment
2021-04-26 06:39:22 <tbodt> why are old versions of packages deleted from pkgs.alpinelinux.org? they don't seem to actually take that much space, I've been archiving them for about 4 months and it takes up under 20gb (just the latest version of everything is about 15gb)
2021-04-26 06:42:13 <Cogitri> tbodt: Because old packages break when sonames are bumped
2021-04-26 06:42:44 <tbodt> ah I guess if you want the old version of something you also need the APKINDEX from that point
2021-04-26 06:45:51 <Ariadne> mps: https://github.com/linux-nvme/nvme-cli/pull/1019
2021-04-26 06:46:33 <Ariadne> tbodt: i want to set up an archive where you can get the alpine package tree at any date (for reproducible builds)
2021-04-26 06:46:45 <tbodt> I did this actually
2021-04-26 06:46:55 <Ariadne> wow, great!
2021-04-26 06:47:10 <mps> Ariadne: I see, you are so fast :)
2021-04-26 06:47:24 <tbodt> apk.ish.app/v3.12-2021-04-24/main/x86/APKINDEX.tar.gz
2021-04-26 06:47:49 <tbodt> however I only did it for x86 and 3.12
2021-04-26 06:55:21 <Thermi> 
ACTION mubles "something something testing suites"

2021-04-26 06:55:26 <Thermi> 
ACTION *mumbles

2021-04-26 07:07:10 <Ariadne> Thermi: more like lets find somebody willing to pour gas on s6 so we can get off this ride
2021-04-26 07:29:36 <Thermi> How are pkgusers coordinated between builder and installed location? I got 'pkggroups="kopano http"' in the APKBUILD, but the http group doesn't exist on the system after installing and even after defining it, the gid doesn't match up
2021-04-26 07:29:54 <Thermi> So what magic do I have to perform for that to work? For nginx it at the very least seems to work without post install chown
2021-04-26 07:37:31 <ikke> pre-install script
2021-04-26 07:40:54 <Thermi> Generally, how is it guaranteed that uids and gids generated at build time using pkgusers and pkggroups don't conflict between different packages?
2021-04-26 07:41:52 <ikke> tar matches it by name
2021-04-26 07:41:54 <Thermi> Is the uid and gid of the users and groups recorded in the packages and then at install time a lookup in /etc/groups and /etc/shadow is done?
2021-04-26 07:41:59 <Thermi> Hmmmh.
2021-04-26 07:42:02 <Thermi> HMMMH,
2021-04-26 07:42:03 <Thermi> I see.
2021-04-26 07:42:08 <Thermi> So basically what I guessed it does.
2021-04-26 07:42:53 <ikke> If the name is not found, it will use the actual uid/gid
2021-04-26 09:19:30 <markand> so I'm the maintainer of retroarch package and 2 weeks ago without any notice or approval a version was merged including a new patch provided in it
2021-04-26 09:19:55 <markand> is there a policy somewhere about why being a maintainer seems to be just a "name figuring" in APKBUILD?
2021-04-26 09:22:14 <markand> I'm talking about !20220
2021-04-26 09:22:56 <markand> while I think it's cool that other people may look at the package you're maintaining, it's not cool that you aren't notified at all
2021-04-26 09:23:22 <markand> especially since this merge request forgot to update other packages as well (retroarch-assets for example)
2021-04-26 09:24:00 <Cogitri> markand: Sorry about that. We're currently working on aports-qa-bot so that it automatically assigns you to review MRs that touch your packages
2021-04-26 09:25:06 <Cogitri> Usually we'd wait a week or two for the maintainer to respond and if they don't respond and the change is only minor (e.g. a minor version bump), we'd merge it. If there's a bigger change we'd wait longer for the maintainer/assign a new maintainer if they don't respond any more
2021-04-26 09:25:31 <markand> the merge request was merged the next day it was proposed for this one
2021-04-26 09:25:43 <markand> submitted on april 6, merged on april 7
2021-04-26 09:29:51 <Ariadne> i think it would be nice to have a field indicating whether "fast" non-maintainer changes are welcome
2021-04-26 09:30:26 <Cogitri> Hm, not sure if that's worth it
2021-04-26 09:30:49 <Cogitri> If the maintainer doesn't respond within X days, do we really want to block the MR for (potentially) ever?
2021-04-26 09:30:57 <skarnet> I would definitely appreciate such a field
2021-04-26 09:31:07 <Ariadne> Cogitri: of coure not
2021-04-26 09:31:21 <Cogitri> I think a general guideline ("please wait X days for the maintainer to respond") would be best
2021-04-26 09:31:40 <Ariadne> Cogitri: yes, but some are OK with fast changes
2021-04-26 09:31:52 <Ariadne> Cogitri: so having a field makes sense
2021-04-26 09:32:05 <ikke> If the maintainer does not respond, do they still maintain that package?
2021-04-26 09:32:12 <Ariadne> ^
2021-04-26 09:33:06 <Ariadne> in other distros, there is a cutoff after 14-21 days usually where a non-maintainer change is allowed, unless the maintainer opts into fast changes
2021-04-26 09:34:31 <Ariadne> having a field allows for a maintainer to signal specific policy regarding each package
2021-04-26 09:34:55 <Ariadne> for example, with gcc, i don't want "fast" changes, because i want new patches to be sent to my patch queue
2021-04-26 09:35:22 <Ariadne> but for audacious, i don't care
2021-04-26 09:35:57 <Cogitri> Sure, but it's yet another thing contributors and reviewer have to check
2021-04-26 09:37:26 <Ariadne> aren't you writing a bot? :p
2021-04-26 09:38:18 <Cogitri> Sure, we can try to automate part of it
2021-04-26 09:38:31 <Ariadne> we plan to add other fields to APKBUILD for other purposes, why not add fields explaining the disposition of the package
2021-04-26 09:38:55 <ncopa> we also allow maintainers to maintain packages without actually having git push access, right? would be nice to have a bot setting a label "maintainer" or similar, which means it likely can be fast-tracked
2021-04-26 09:39:48 <Cogitri> Yes, most of the time maintainers don't have push access
2021-04-26 09:39:52 <ncopa> Ariadne: btw, would it make sense to have an IRC channel or similar for alpineconf?
2021-04-26 09:39:57 <ikke> We do need a good way to map maintainers to gitlab users
2021-04-26 09:40:10 <Cogitri> Yup
2021-04-26 09:40:14 <ncopa> the email address?
2021-04-26 09:40:17 <Cogitri> Would be nice if we solved that first
2021-04-26 09:40:40 <Cogitri> ncopa: We bot currently tries that but not everyone has the same email in gitlab and the APKBUILD
2021-04-26 09:40:59 <ncopa> understand. solving that is a prerequisite
2021-04-26 09:41:11 <Sheila> you guys already have meta-fields like bump restrictions. bump policy isn't far-fetched at all.
2021-04-26 09:41:29 <ncopa> is it possible to have multiple emails connected to a gitlab account?
2021-04-26 09:41:32 <Ariadne> ncopa: yes likely
2021-04-26 09:41:33 <Cogitri> Yup
2021-04-26 09:42:02 <Cogitri> You can have multiple emails connected. One is the primary notification email (where you get emails), the others are in there for things like GPG keys
2021-04-26 09:42:16 <Ariadne> yes but how do you reverse map
2021-04-26 09:42:41 <ncopa> im thinking we could start with searching for the maintainer email in gitlab and set the "fast-track" label based on that
2021-04-26 09:43:08 <ncopa> maintainers who dont have that email in gitlab won't get the fast-track label
2021-04-26 09:43:13 <Ariadne> there is also #alpine-security now
2021-04-26 09:43:19 <ncopa> awesome!
2021-04-26 09:43:40 <ikke> It was there already for quite some time
2021-04-26 09:43:44 <Cogitri> ncopa: But it's a per-package, not a per-maintainer setting so I don't see what that'd be for?
2021-04-26 09:43:46 <ikke> Just not used
2021-04-26 09:44:15 <jvoisin>  /j #alpine-security
2021-04-26 09:44:16 <jvoisin> meh
2021-04-26 09:44:20 <ncopa> :)
2021-04-26 09:44:44 <ncopa> good monday morning jvoisin :)
2021-04-26 09:45:14 <jvoisin> Merry Monday to you as well ncopa :)
2021-04-26 09:53:07 <Ariadne> you could even have something like
2021-04-26 09:53:13 <Ariadne> # NMC-Threshold: 14d
2021-04-26 09:53:15 <Ariadne> or
2021-04-26 09:53:21 <Ariadne> # NMC-Threshold: 0d
2021-04-26 09:53:49 <Ariadne> thus would allow a maintainer to ask explicitly "please give me X days to review this package"
2021-04-26 09:54:37 <Cogitri> Sure
2021-04-26 09:55:25 <Cogitri> Maybe we could have a kanban board with a queue for MRs which are ready for "general" review and another one for MRs which need maintainer approval
2021-04-26 09:56:44 <Sheila> would security bumps bypass the review threshold?
2021-04-26 09:56:51 <Sheila> (e.g. CVE attached)
2021-04-26 10:09:33 <Ariadne> Sheila: yes, obviously
2021-04-26 10:11:26 <Sheila> figured, but thought it worth bringing up so it's explicit. :)
2021-04-26 10:41:34 <markand> 14 days in absence of field in APKBUILD seems correct IMHO
2021-04-26 10:43:19 <skarnet> still would like to be at least notified on any NMU, even if the "wait for the maintainer to approve" part is skipped for security fixes
2021-04-26 10:48:30 <ikke> We could have different values: need-approval, notify, accept, or something liek that
2021-04-26 11:01:42 <Cogitri> I think we should always notify the maintainer
2021-04-26 11:02:04 <Cogitri> I don't see the value of a maintainer when they don't know what's going on with the package
2021-04-26 11:02:55 <Cogitri> So the bot would always assign the maintainer to review the thing and if the maintainer doesn't answer in the specified timeframe move the MR to the "general review" queue
2021-04-26 11:07:38 <mps> Cogitri: I agree
2021-04-26 11:08:40 <mps> though there are maintainers who explicitly stated to me that I can freely work on their pkgs
2021-04-26 11:09:09 <mps> so, maybe not always wait for maintainer answer
2021-04-26 11:09:28 <mps> I would say 'use common sense' (as usual)
2021-04-26 11:09:56 <mps> there is no bot who can replace human brain
2021-04-26 11:10:16 <ikke> No, and it will not do so
2021-04-26 11:10:29 <ikke> But it can make things a bit easier
2021-04-26 11:10:50 <mps> yes, I see it is a helpful tool
2021-04-26 12:21:27 <markand> that's why you may add an optout keyword in the APKBUILD
2021-04-26 12:21:37 <markand> but by default *IT MUST* requires maintainer approval
2021-04-26 12:21:51 <markand> otherwise I'd need to edit a bunch of APKBUILD to tell "make sure to notify me"
2021-04-26 12:45:44 <mps> no one is owner of anything in alpine
2021-04-26 12:54:20 <Hello71> yes, if you want a distro where maintainer approval is required and therefore nothing ever gets done then go to gentoo or debian
2021-04-26 12:55:01 <Hello71> debian barely works because there's enough people that it slowly grinds forward. gentoo doesn't and doesn't
2021-04-26 12:55:04 <mps> kernel 5.12 have some new features, https://kernelnewbies.org/Linux_5.12
2021-04-26 12:55:52 <mps> idmap is interesting for containers
2021-04-26 12:56:30 <mps> and also preemt mode select from boot cmdline
2021-04-26 12:56:50 <mps> preempt*
2021-04-26 13:03:56 <Ariadne> Hello71: it is generally polite to allow a maintainer to review changes though
2021-04-26 13:04:30 <Ariadne> i am a supporter of fast non-maintainer changes, but the default should not be that.
2021-04-26 13:04:37 <Hello71> yes, but it needs to be a social expectation, not a policy
2021-04-26 13:04:50 <Hello71> otherwise you start having policy policies and meeting meetings
2021-04-26 13:05:04 <Ariadne> even in debian you can NMU any package at any time
2021-04-26 13:05:49 <Ariadne> however if you do so in bad faith, it will make it harder for you to get things cosigned in the future
2021-04-26 13:06:49 <Ariadne> that is basically the guideline we have always followed here until lately
2021-04-26 13:07:02 <Ariadne> sometimes things get pushed too quickly.
2021-04-26 13:10:00 <Ariadne> the maintainer should always be able to specify their preferences
2021-04-26 13:10:11 <Ariadne> within reason.
2021-04-26 13:11:34 <Ariadne> so i propose a way to allow maintainers to signal those preferences, which would be combined with a conservative default review window (7 or 14 days)
2021-04-26 14:19:32 <minimal> will someone merge !20853 please?
2021-04-26 15:13:42 <i1l-test> 
ACTION meeting meetings sniffing mittens, like real elbonian

2021-04-26 18:40:07 <ikke> ncopa: https://pkg.go.dev/gitlab.alpinelinux.org/alpine/go/pkg/releases@v0.2.0 :)
2021-04-26 18:45:20 <Hello71> while we are bashing firejail: https://github.com/netblue30/firejail/blob/master/src/firejail/fs.c#L1080
2021-04-26 19:14:07 <ncopa> ikke: awesome
2021-04-26 19:14:31 <ncopa> some WIP I have in my tree: https://tpaste.us/5Vl7
2021-04-26 19:15:03 <ikke> ncopa: working on secdb generator in go now
2021-04-26 19:15:41 <ikke> gitlab.alpinelinux.org/alpine/go is meant as a collection of libraries that can be reused
2021-04-26 19:27:21 <ncopa> understand. I had something like this in mind: https://tpaste.us/vZXW
2021-04-26 19:28:00 <ncopa> the NewFromBuffer was to make it easier to add testcases
2021-04-26 19:28:12 <ikke> Right, is a good improvement
2021-04-26 19:28:17 <ikke> I just created something quickly
2021-04-26 19:28:45 <ikke> But having it in a repo makes it easy to improve upon
2021-04-26 19:29:19 <ncopa> yes, very good
2021-04-26 19:29:26 <ncopa> need to go now. thanks!
2021-04-26 19:29:29 <ikke> o/
2021-04-26 22:10:58 <wdtTP2O82Kft> i made a feature comparison between bubblewrap, nsjail and minijail: https://ctrlc.hu/~stef/jails.txt
2021-04-26 22:54:34 <hedonist> Ariadne: only read the beginning of your service manager aritcle so far (it's on my to-read list tonight), but I'm already really excited for it
2021-04-26 22:56:21 <tomleb> hedonist: got a link?
2021-04-26 22:56:44 <hedonist> https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine/
2021-04-26 22:56:57 <Ariadne> that is old :P
2021-04-26 22:57:14 <hedonist> haha
2021-04-26 22:57:23 <hedonist> how old? (no date shown on the article itself)
2021-04-26 22:57:39 <skarnet> if you want the technical details, they're here: https://skarnet.com/projects/service-manager.html
2021-04-26 22:57:43 <hedonist> Ariadne: it was posted on lobsters, so it's the first I've seen it and will likely get a fair bit more traffic
2021-04-26 22:57:57 <Ariadne> oh no
2021-04-26 22:57:59 <hedonist> skarnet: :D
2021-04-26 22:58:03 <Ariadne> i'll have to go into nginx
2021-04-26 22:58:10 <Ariadne> and redirect to rickroll.mp4
2021-04-26 22:58:42 <skarnet> wait until it's posted to hackernews, then do that
2021-04-26 22:59:29 <hedonist> Ariadne: lol
2021-04-26 22:59:29 <hedonist> oh, incidentally, don't worry about it too much, lobsters just went down
2021-04-26 22:59:29 <hedonist> ☺
2021-04-26 22:59:32 <Ariadne> yeah
2021-04-26 22:59:39 <Ariadne> strange coincidence
2021-04-26 23:00:16 <hedonist> it's back
2021-04-26 23:00:32 <hedonist> (possibly, it was never down and instead my internets were)
2021-04-26 23:02:39 <Ariadne> well at least the comment section for both of those submissions aren't clownworld
2021-04-26 23:03:21 <Ariadne> i was expecting
2021-04-26 23:03:38 <Ariadne> WOMAN IN TECH IS COMPLAINING ABOUT SOMETHING, SHE IS WRONG, HONK HONK HONK
2021-04-26 23:04:19 <skarnet> is lobsters like that?
2021-04-26 23:04:52 <hedonist> skarnet: yes
2021-04-26 23:05:03 <Sheila> it's double-hipster /.
2021-04-26 23:05:05 <hedonist> skarnet: so are all places on the internet I've been present
2021-04-26 23:05:23 <skarnet> hedonist: you need to hang in better circles
2021-04-26 23:05:51 <Sheila> I have a pretty good success rate at avoiding that kind of nonsense.
2021-04-26 23:05:51 <hedonist> skarnet: lobsters, however, is one of the communities where a large contingent of users proposed a code of conduct, and the mods / a very vocal (I believe, minority) of users rejected it out-of-hand
2021-04-26 23:05:55 <hedonist> skarnet: so, that's awesome
2021-04-26 23:06:08 <hedonist> Ariadne: I'm sorry that's what you've come to expect :(
2021-04-26 23:06:15 <hedonist> skarnet: also, I just try to stop hanging out in those places
2021-04-26 23:06:31 <hedonist> skarnet: e.g., I still look at lobsters for news but I haven't posted / logged in in a very long time
2021-04-26 23:06:37 <hedonist> (and I try to avoid the comments)
2021-04-26 23:07:00 <Ariadne> i don't even have an account on that site, or want one
2021-04-26 23:07:14 <Ariadne> anyway this is like an #alpine-offtopic thing
2021-04-26 23:08:17 <tomleb> Damn, and I just created openrc-exporter to monitor my alpine services. Well, I guess the s6-rc replacement isn't yet ready anyway
2021-04-26 23:08:58 <skarnet> you still have time
2021-04-26 23:09:21 <hedonist> Ariadne: indeed
2021-04-26 23:09:23 <skarnet> but if you need real supervision for your daemons, s6 is packaged for alpine ;)
2021-04-26 23:09:51 <hedonist> I'm very much looking forward to playing with s6; I've never worked with it personally, but I've heard only good things
2021-04-26 23:11:25 <tomleb> skarnet: what do you mean by this? (Also I join #alpine-offtopic in case we want to move that discussion there)
2021-04-26 23:11:40 <skarnet> hedonist: well you can start right away, but the final version of the nextgen service manager will look nothing like what exists today ^^
2021-04-26 23:11:56 <hedonist> skarnet: haha
2021-04-26 23:12:05 <hedonist> skarnet: my migration to alpine is… incremental
2021-04-26 23:12:15 <hedonist> so, there's some time left ☺
2021-04-26 23:12:31 <skarnet> there is some time left indeed because I need to *write* it first, too :P
2021-04-26 23:13:08 <skarnet> tomleb: what is "this" that I should elaborate on?
2021-04-26 23:13:25 <hedonist> skarnet: I've heard that can get in the way of people using something ☺
2021-04-26 23:17:28 <tomleb> skarnet: in #alpine-offtopic
2021-04-26 23:48:27 <tomleb> I keep seeing "Fast-forward merge is not possible. Rebase the source branch onto the target branch". Does this prevent merging and I need to rebase? For !20872
2021-04-26 23:53:17 <hedonist> tomleb: sounds like it
2021-04-26 23:53:29 <hedonist> tomleb: pro-tip; `git pull --rebase` is a hell of a drug
2021-04-26 23:54:20 <tomleb> hedonist: I already have this by default, yes.
2021-04-27 00:00:57 <skarnet> fast-forward merge generally only works in the blessed case when you're the only one working on a project. :P
2021-04-27 00:01:40 <skarnet> those pesky devs who insist on modifying master while you're working on your branch!
2021-04-27 00:16:27 <hedonist> lol
2021-04-27 00:28:03 <hedonist> skarnet: out of interest, have you considered using any formal methods for the new service manager? (e.g., frama-c)
2021-04-27 00:29:02 <skarnet> I don't think it would be useful tbh
2021-04-27 00:29:23 <skarnet> it's still in the range of complexity I can handle without such tools
2021-04-27 00:29:47 <hedonist> fer nuff
2021-04-27 00:30:29 <skarnet> the problems with C appear when you have a large shared codebase with implicit assumptions and too loose guidelines
2021-04-27 00:30:44 <hedonist> indeed
2021-04-27 00:31:00 <hedonist> though, I do long for a world where all C software is complimented by formal methods
2021-04-27 00:31:01 <skarnet> people make changes according to a set of assumptions that isn't the same the previous committer made
2021-04-27 00:31:08 <skarnet> and boom, you introduce a bug
2021-04-27 00:31:19 <skarnet> that's the kind of thing formal methods can avoid
2021-04-27 00:31:39 <skarnet> for a small team project under a certain level of complexity, the overhead just isn't worth it
2021-04-27 00:31:51 <skarnet> you just need to pay attention to what you're doing :)
2021-04-27 00:31:57 <hedonist> :)
2021-04-27 08:37:00 <mps> mcrute: hehe, alpine/aports:master | Mike Crute | community/bird: move to community, from where not from to
2021-04-27 09:03:42 <mps> anyone know what C lib or include is needed for __free_fn_t
2021-04-27 09:23:22 <donoban>  hi guys
2021-04-27 09:26:25 <donoban> wdtTP2O82Kft: very nice, interesting the code base difference altough brwap misses resources limiting freatures.
2021-04-27 09:28:55 <mps> hah, glibc /usr/include/search.h
2021-04-27 09:30:42 <mps> libc6-dev:amd64: /usr/include/search.h
2021-04-27 09:39:08 <mps> so, musl doesn't have __free_fn_t
2021-04-27 10:01:07 <Ariadne> mps: no, it's a GNU-ism
2021-04-27 10:04:38 <mps> yes, I looked at glibc source
2021-04-27 10:04:49 <mps> thanks for confirmation
2021-04-27 10:11:06 <skarnet> generally speaking any __-prefixed symbol in an application is bad news
2021-04-27 10:13:27 <mps> skarnet: iiuc, use them in appications
2021-04-27 10:15:00 <skarnet> on the contrary: *do not* use __ stuff in applications if you want your applications to be portable
2021-04-27 10:16:26 <mps> skarnet: sorry, I meant to say 'not use' instead of 'use'. need another coffee round
2021-04-27 10:16:41 <skarnet> right XD
2021-04-27 10:20:40 <mps> ncopa: just to add context, this __free_fn_t is in drbd-utils 9.17.0
2021-04-27 10:21:22 <mps> because that I made !20912, so no latest and shinny upgrade :)
2021-04-27 12:14:13 <ericonr> skarnet: what do you mean, I'm not supposed to be using __compar_fn_t in my code??
2021-04-27 12:14:36 <ericonr> seriously though, it would have been nice of glibc to have removed that from headers by now, then upstreams would have been forced to fix their shit
2021-04-27 12:32:22 <jvoisin> https://openwrt.org/releases/21.02/notes-21.02.0-rc1 OpenWRT switched from mbedTLS to WolfSSL
2021-04-27 12:33:58 <Hello71> i think the message is a bit misleading, since previously the default was "no tls"
2021-04-27 12:34:22 <Hello71> previously = in 19.07
2021-04-27 12:34:49 <Hello71> i think it changed during 21.02 release process
2021-04-27 12:47:26 <dalias> uhg wolfssl is so bad
2021-04-27 12:50:35 <jvoisin> but it's paying for the development of curl :P
2021-04-27 13:16:29 <dalias> :-p
2021-04-27 13:17:15 <dalias> TBH i think a lot of the badness was that the client i worked with who was using it insisted on some ridiculous nondefault flags for the bignum code and stuff
2021-04-27 13:17:24 <dalias> that made it malloc every limb or something
2021-04-27 13:19:18 <ericonr> it claims to be an embedded SSL library, so I'd hope it can also do stuff in non allocation-heavy manners :/
2021-04-27 13:19:41 <ericonr> their licensing is kind of heavy, though
2021-04-27 13:27:19 <Ariadne> i prefer BearSSL personally.
2021-04-27 13:29:33 <Sheila> I favour menagerieSSL (that is, everyone just implement libtls API) :v
2021-04-27 13:32:10 <mps> hmm 'scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib/scribus/plugins/' in ...'
2021-04-27 13:33:02 <mps> first time see this when building pkg. do I need some special settings in APKBUILD?
2021-04-27 13:35:14 <ericonr> Ariadne: I think it's the main (only?) "embedded" library that claims compatibility with OpenSSL
2021-04-27 13:37:15 <ericonr> (wolfssl)
2021-04-27 13:39:21 <dalias> mps, it's a bug in whatever built that
2021-04-27 13:40:24 <dalias> either they put a build-dir-relative rpath in the binary as a bad hack to let yoy run it in the build dir without installing, or they mistakenly think relative paths are origin-relative (that needs ${ORIGIN}) rather than working-dir-relative
2021-04-27 13:43:19 <mps> dalias: thanks for explanation
2021-04-27 14:03:31 <mps> gcc 11.1 released https://gcc.gnu.org/pipermail/gcc/2021-April/235922.html
2021-04-27 14:03:53 <mps> too late for alpine 3.14
2021-04-27 14:12:23 <Ariadne> mps: gcc 11 is not happening until 3.16 at least
2021-04-27 14:13:15 <Ariadne> (though i have rebased the patchset)
2021-04-27 14:17:25 <mps> Ariadne: yes, I know that you added some patches to 10.2
2021-04-27 14:17:38 <Ariadne> we're on 10.3
2021-04-27 14:17:44 <Ariadne> the patchset is already rebased on 11
2021-04-27 14:17:49 <mps> aha, didn't looked
2021-04-27 14:18:01 <Ariadne> i want to stick with 10.x through 3.15 though
2021-04-27 14:18:25 <Ariadne> we're having a pretty good run with gcc 10 now, and i don't want to have more fires to deal with on that front just yet
2021-04-27 14:18:41 <mps> I would like to stick with 8.2 (or it was 8.3) :)
2021-04-27 14:19:33 <Ariadne> ericonr: i dont see OpenSSL compatibility as a feature tbh :p
2021-04-27 14:19:49 <Ariadne> not in a library that has like 20 ssl backends anyway
2021-04-27 14:26:13 <mps> dalias: just fyi, solved above rpath issue for scribus by adding -DWANT_DISTROBUILD=True to cmake
2021-04-27 14:28:11 <dalias> *sigh*
2021-04-27 14:28:25 <dalias> this is not only needed for distro
2021-04-27 14:28:34 <dalias> it's needed not to have a severe bug in the binary
2021-04-27 14:32:44 <mps> well, I don't care much, hope original poster to include scribus in alpine will take maintainership in near future
2021-04-27 14:33:17 <mps> I don't like much such big software
2021-04-27 14:34:21 <mps> just wanted to help, because OP had illness and couldn't continue work on it
2021-04-27 14:48:47 <mps> Ariadne: thanks for upgrade dnsmasq in 3.13. obviously I forgot this when upgraded for edge
2021-04-27 15:51:21 <Thermi> Ariadne: Do you have a moment for a query? I want to talk about the AGPL situation
2021-04-27 15:53:49 <Ariadne> Thermi: sure
2021-04-27 16:37:46 <PureTryOut[m]2> maribu: seems you're the maintainer of opencv. Any chance you could move it to community at some point?
2021-04-27 17:52:03 <maribu[m]> I stopped using it, so I'm relying on user feedback for issues and new releases :-( I only needed it for a single demo project, and likely will never need it again. I don't think I'm the right person to push it to community.
2021-04-27 17:52:04 <maribu[m]> But feel free to adopt the package!
2021-04-27 18:15:04 <PureTryOut[m]2> Oh sure, that'd be fine
2021-04-27 23:06:07 <tomleb> mps: Taking a chance, are you Michal, helping me get navidrome packaged?
2021-04-28 00:17:31 <Ariadne> i dont think so
2021-04-28 00:21:04 <wdtTP2O82Kft> btw i'm still looking into nsjail/minijail/bwrap. and i noticed, that bwrap expects compiled bpf files for seccomp, but has no tool on it's own to do so. nsjail comes with its own dls: kafel - which allows for some nice definition of rules. but minijail i think goes further, it has some nice tools to generate policy files from strace/audit.log and a python script to compile it down to bpf,
2021-04-28 00:21:06 <wdtTP2O82Kft> might be worth packaging...
2021-04-28 00:23:44 <Hello71> sure, as long as you maintain it
2021-04-28 00:26:24 <dalias> wdttp2o82kft, what are you trying to accomplish with a sandbox?
2021-04-28 00:26:44 <dalias> didnt we find minijail had serious flaws?
2021-04-28 00:27:44 <wdtTP2O82Kft> no that was firejail
2021-04-28 00:28:20 <wdtTP2O82Kft> minijail is the chromeos/android tool used by google to sandbox everything.
2021-04-28 00:28:39 <Ariadne> i don't want any "jail" that is SUID
2021-04-28 00:29:05 <wdtTP2O82Kft> well. bwrap is not suid
2021-04-28 00:29:14 <Ariadne> yes, i know :)
2021-04-28 00:29:23 <wdtTP2O82Kft> but needs something that feeds it binary bpf files if you wanna use seccomp
2021-04-28 00:29:56 <Ariadne> i am just saying anything that is suid would be rejected
2021-04-28 00:29:57 <wdtTP2O82Kft> and what i'm talking about are two such solutions from the other two tools i look at
2021-04-28 00:30:09 <Ariadne> i am trying to reduce the number of SUID programs in alpine
2021-04-28 00:30:11 <Ariadne> :P
2021-04-28 00:30:29 <wdtTP2O82Kft> i'm talking about tools that generate seccomp bpf files
2021-04-28 00:30:31 <wdtTP2O82Kft> not jails
2021-04-28 00:30:36 <Ariadne> yeah thats fine
2021-04-28 00:30:55 <Ariadne> i am just saying please do not package anything that requires options=suid :p
2021-04-28 00:31:06 <wdtTP2O82Kft> i'm not saying anything like that
2021-04-28 00:31:17 <wdtTP2O82Kft> i'm talking about tools that spit out binary bpf files
2021-04-28 00:31:22 <wdtTP2O82Kft> that can be fed into bwrap
2021-04-28 00:31:57 <wdtTP2O82Kft> since brwap does not support anything else but reading these rules from an open fd
2021-04-28 00:35:21 <dalias> fwiw seccomp is nearly impossible to make into a viable sandbox
2021-04-28 00:35:52 <dalias> it doesn't have facilities to intercept and rewrite things that can't be blocked but also can't be allowed directly
2021-04-28 00:36:20 <dalias> it's useful for very specific known code where you have whole swarths of functionality you can nuke and still get done what you want but that's about all
2021-04-28 00:36:28 <dalias> namespaces are much more powerful for actual sandboxing
2021-04-28 00:41:19 <wdtTP2O82Kft> i guess that's true for firefox, but a simple dhcp client for example might be possible, possibly also daemons like unbound
2021-04-28 00:41:54 <dalias> it's a lot of work and error-prone to sandbox them with seccomp
2021-04-28 00:42:01 <dalias> it's trivial to sandbox them with namespaces
2021-04-28 00:42:36 <dalias> now seccomp is a great mitigation for bugs in the kernel (turn off access to syscalls that have nothing to do with the functionality)
2021-04-28 00:42:54 <dalias> but just allowlisting syscall patterns you know they use is likely to break with updates to the application *or libc*
2021-04-28 00:43:17 <wdtTP2O82Kft> sure
2021-04-28 00:45:36 <dalias> btw note that unshare(1) is more powerful and useful *without any actual programming*, or just some shell script 'programming', than most big sandbox implementations
2021-04-28 00:45:53 <dalias> for example see my https://github.com/richfelker/usand
2021-04-28 00:56:22 <Ariadne> yes i am very skeptical about seccomp sandboxing too, for the reasons dalias mentions
2021-04-28 06:25:04 <mps> tomleb: no, I'm not. my username on gitlab is also mps as nick here
2021-04-28 06:39:10 <indy> hi all, any timeframe for branching of π?
2021-04-28 06:40:03 <ncopa> i havent started work on the 3.14 builders yet. i would guess we have it out at the end of May
2021-04-28 06:41:04 <indy> ncopa, thanks
2021-04-28 10:08:50 <donoban> hi, is it possible to move bubblejail to community before 3.14 release?
2021-04-28 10:15:10 <Ariadne> yes open an MR doing it
2021-04-28 10:18:23 <donoban> ok, I tested so far firefox/telegram and electrum, all working fine
2021-04-28 10:19:08 <donoban> well, I don't have sound in telegram maybe because it uses alsa instead pulseaudio
2021-04-28 11:20:51 <Ariadne> FYI: i am planning to do a mass orphan of packages which have not had maintainer involvement in security fixes after 3.14 release
2021-04-28 11:28:16 <donoban> good
2021-04-28 11:48:29 <Ariadne> ncopa: mps: ping
2021-04-28 11:50:19 <Ariadne> ncopa: mps: qemu 5.2.0 in alpine has a lot of unpatched security vulnerabilities.  all of which are fixed in 6.0.0-rc5.  should we upgrade to 6.0.0-rc5?
2021-04-28 11:56:13 <tomleb> Once a package has been pushed to edge/testing, what's the next step? I know I can move it to community eventually. But that's still for edge isn't ? So how are packages updated for older version (eg: 3.12)?
2021-04-28 11:58:14 <mps> Ariadne: if we want to upgrade qemu why not wait for 6.0.0 release? I expect it JIT (just-in-time) for 3.14 :)
2021-04-28 11:58:24 <Ariadne> mps: okay :)
2021-04-28 11:58:34 <Ariadne> tomleb: they're not
2021-04-28 11:58:47 <Ariadne> tomleb: there is no way to go from edge/testing to something already released
2021-04-28 11:59:13 <mps> though I asked for preparing upgrade to 3.14 earlier and 'no' as answer
2021-04-28 11:59:34 <Ariadne> mps: i am ok with upgrade to qemu 6.0 in 3.14
2021-04-28 11:59:42 <mps> s/and/and got/
2021-04-28 11:59:42 <alpine-meetbot> mps meant to say: though I asked for preparing upgrade to 3.14 earlier and got 'no' as answer
2021-04-28 11:59:42 <Ariadne> some of these issues look pretty nasty
2021-04-28 11:59:50 <Ariadne> i would like to see them fixed
2021-04-28 12:00:12 <mps> I still think we should upgrade
2021-04-28 12:01:07 <Ariadne> yes, i agree
2021-04-28 12:01:11 <Ariadne> you have my support to do it
2021-04-28 12:01:12 <Ariadne> :)
2021-04-28 12:01:18 <mps> :)
2021-04-28 12:01:56 <Ariadne> the alternative is backporting like 50 patches
2021-04-28 12:02:01 <Ariadne> i dont think its worth it
2021-04-28 12:02:09 <Ariadne> better to just go to 6.0
2021-04-28 12:02:15 <Ariadne> even for 3.13 imo
2021-04-28 12:02:26 <Ariadne> or perhaps just tell people who use qemu to upgrade to 3.14
2021-04-28 12:02:41 <mps> iirc, BDFL was against. maybe he is now convinced ;)
2021-04-28 12:07:01 <mps> tomleb: Ariadne: I think we had moving from testing to stable branch few times, though for really exceptional cases
2021-04-28 12:13:00 <Ariadne> maybe i remove firejail from 3.13 too
2021-04-28 12:13:02 <Ariadne> :)
2021-04-28 12:13:36 <Ariadne> mps: lets just do it :)
2021-04-28 12:13:49 <Ariadne> i guess wait for 6.0 release tho
2021-04-28 12:18:31 <tomleb> Ariadne: Let's say I have a community package in 3.12, and now we're 3.13, can I update the package in 3.12 (eg: security fixes)? I guess I'm having issues understanding the lifecycle of a package.
2021-04-28 12:18:52 <Ariadne> tomleb: yes, you open an MR with a fix
2021-04-28 12:19:05 <Ariadne> tomleb: pinging @teams/security will likely get a fast review :)
2021-04-28 12:19:38 <Ariadne> but, you can't go from edge/testing into a stable release generally.
2021-04-28 12:19:45 <Ariadne> like for a new package
2021-04-28 12:19:53 <donoban> oh my god
2021-04-28 12:19:59 <donoban> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20941/commits
2021-04-28 12:20:11 <donoban> git is not my friend :\
2021-04-28 12:21:51 <donoban> yeah I fixed it! :D
2021-04-28 12:58:35 <danyspin97> Hi there! Can I ask here questiones regarding APKBUILD?
2021-04-28 12:59:16 <afontain_> sure
2021-04-28 13:00:06 <danyspin97> if a program use code with different licenses (i.e. src/ under AGPL-3 and lib/ under MIT) should both be mentioned in the license tag?
2021-04-28 13:01:04 <ikke> Yes, combined with AND
2021-04-28 13:01:38 <danyspin97> license="AGPL-3.0 && MIT" is it correct?
2021-04-28 13:01:58 <ikke> The word 'AND'
2021-04-28 13:02:05 <danyspin97> I see, thanks! :)
2021-04-28 15:12:20 <Ariadne> mcf: ping
2021-04-28 15:13:31 <Ariadne> mcf: i'm being asked about https://github.com/michaelforney/samurai/pull/74/files, the person asking alleges that alpine is violating your copyright on samurai, because we just declare the license in the APKBUILD (using SPDX labels) and do not physically install the LICENSE file.
2021-04-28 15:13:39 <Ariadne> mcf: what is your opinion on this?
2021-04-28 15:20:24 <Sheila> donoban: one thing you can do that won't require rebasing is using `git commit --amend`; that will add your current set of changes to the last commit.
2021-04-28 15:22:16 <PureTryOut[m]2> Huh, what's up with the ppc64le builder? It's not available on b.a.o?
2021-04-28 15:23:48 <ikke> PureTryOut[m]2: it's awol
2021-04-28 15:24:25 <PureTryOut[m]2> Fun
2021-04-28 15:24:33 <ikke> ibm is looking at it, but they need to physically access the device
2021-04-28 15:24:50 <Ariadne> if it does not get un-AWOL soon, i'll make arrangements to have my POWER8 machine reracked
2021-04-28 15:25:02 <Ariadne> (it's the faster of the two i have)
2021-04-28 15:25:16 <donoban> thanks Sheila but I'm not sure exactly in what case I should use it. Maybe I wrongly created that branch from telegram branch instead master.
2021-04-28 15:28:56 <Sheila> donoban: mostly it'd allow you to make changes without having to rebase. for branches, I recommend `git checkout master; git checkout -b blah` specifically as that way later branches won't interfere with earlier ones or vice-versa.
2021-04-28 15:30:45 <donoban> so, I try do a PR, some revisor says, "there is an error there", I fix it and use 'commit --amend'? then push :)
2021-04-28 15:31:36 <Sheila> yeah
2021-04-28 15:32:48 <ikke> But only do that if the fix should go in the last commit
2021-04-28 15:33:07 <ikke> if you have multiple commits, and that fix fixes something in an earlier commit, git commit --amend is not appropriate
2021-04-28 15:33:19 <Sheila> ^
2021-04-28 15:33:30 <donoban> I see I see
2021-04-28 15:34:09 <Sheila> yes, in that case make a new commit and rebase so that you can roll the fix in to the commit you're fixing.
2021-04-28 15:34:13 <donoban> but common aport commits, "community/pkg: upgrade X", almost any fix could be ammended to it
2021-04-28 15:34:55 <ikke> It requires a bit of common sense
2021-04-28 15:35:01 <donoban> thanks for the tip :)
2021-04-28 15:35:18 <ikke> small fixes can indeed go into the same commit, if the amount of changes become larger, it might make sense to split it up
2021-04-28 15:35:37 <donoban> yeah, I understand :D
2021-04-28 16:03:17 <thycoticent> TIL that setting the APK environment variable can screw up your abuild runs....
2021-04-28 16:03:48 <thycoticent> [0] [me@alpox00 ~/ports/aports/community/IshyTinker]$ abuild checksum; echo $?
2021-04-28 16:03:51 <thycoticent> >>> IshyTinker: Updating the sha512sums in APKBUILD...
2021-04-28 16:03:54 <thycoticent> 0
2021-04-28 16:03:56 <thycoticent> [0] [me@alpox00 ~/ports/aports/community/IshyTinker]$ APK=1 abuild checksum; echo $?
2021-04-28 16:04:00 <thycoticent> 127
2021-04-28 16:04:53 <Ariadne> yes
2021-04-28 16:05:09 <Ariadne> this should probably be documented
2021-04-28 16:05:19 <Ariadne> but ${APK} is supposed to reference the /sbin/apk binary
2021-04-28 16:05:32 <Ariadne> this is to allow abuild to be used on non-alpine systems
2021-04-28 16:12:47 <thycoticent> Yeah, a wiki entry would be helpful.  Took me a hot minute to figure that one out.
2021-04-28 17:53:01 <arwn> i'm learning how to package the dotnet sdk. on the dotnet website it says to extract the files into DOTNET_ROOT and add that to path. of course that doesn't work for a global package. should my package extract it to /opt and make a symlink of dotnet in /usr/local/bin?
2021-04-28 17:53:30 <arwn> DOTNET_ROOT being /home/$USER/dotnet anyways
2021-04-28 18:03:48 <mps> donoban: are you around? I created bug report (finally, I'm bad on these tasks) about edk2 failed build #12640
2021-04-28 18:12:18 <mps> I didn't 'see' tbk for some time here
2021-04-28 18:12:47 <ikke> 2 months ago
2021-04-28 18:13:45 <mps> I create !20937 and it failed on CI on x86_64 and aarch64, but pass fine on my lxcs
2021-04-28 18:14:08 <mps> and tbk is maintainer, not sure what to do with this
2021-04-28 18:14:24 <mps> (no, will not send mail to ML)
2021-04-28 18:15:40 <ikke> Seems to be timing related
2021-04-28 18:15:47 <ikke> xpected 114968 >= 100000 && 15 >= 5 && 15 <= 10 (context: type eval line 27 cmd {assert {$omem >= 100000 && $time_elapsed >= 5 && $time_elapsed <= 10}} proc ::test)
2021-04-28 18:16:17 <ikke> It takes 15 (seconds?), but expected to be between 5 and 10
2021-04-28 18:16:50 <ikke> [err]: Client output buffer soft limit is not enforced if time is not overreached in tests/unit/obuf-limits.tcl
2021-04-28 18:42:59 <mps> yes
2021-04-28 18:43:59 <mps> does it make sense to merge in hope that builder will be fast enough
2021-04-28 18:52:11 <Thermi> @Ariadne Do you want to be mentioned in issues regarding AGPL-3.0 compliance in aports?
2021-04-28 18:52:47 <Ariadne> Thermi: lets hold off for now.  we can do this audit after 3.14 is released.
2021-04-28 18:53:02 <Thermi> Ariadne: Alright. I just opened an issue for bareos.
2021-04-28 18:53:15 <Thermi> Like 10 seconds before you wrote it.
2021-04-28 18:53:23 <Ariadne> Thermi: i do appreciate your taking initiative to audit our packages for compliance though :)
2021-04-28 18:53:32 <Thermi> Ariadne: Well, you told me to open issues. :P
2021-04-28 18:53:53 <ikke> Opening issues is fine
2021-04-28 18:53:56 <Ariadne> yes, because you inquired about auditing :)
2021-04-28 18:54:08 <Thermi> It's about 55 packages that need to be audited
2021-04-28 18:54:20 <Ariadne> and we should check all of our AGPL packages to make sure they are actually providing the source code notice
2021-04-28 18:54:25 <Thermi> Takes about 5 minutes each
2021-04-28 18:54:37 <ikke> Ariadne: afaik, that's only requried if there are modifications, not?
2021-04-28 18:54:45 <Thermi> Well, only the ones having changed source code need to provide notices
2021-04-28 18:54:51 <ikke> right
2021-04-28 18:55:04 <Ariadne> ikke: the ones that are changed need their URLs changed, but all of them are really supposed to have the notice
2021-04-28 18:55:16 <ikke> Why?
2021-04-28 18:55:17 <Ariadne> this was the opinion of the FSF when Pleroma and Mastodon enquired about it
2021-04-28 18:55:35 <ikke> If we did not change it, and upstream does not provide it, why does that matter?
2021-04-28 18:55:45 <Ariadne> it means upstream itself is not in compliance
2021-04-28 18:55:48 <Ariadne> which is a bug
2021-04-28 18:55:56 <ikke> How can upstream not be in compliance?
2021-04-28 18:55:57 <Ariadne> just not a bug that is of grave severity to *us* :)
2021-04-28 18:56:05 <ikke> They can do whatever they want
2021-04-28 18:56:09 <Thermi> Assuming upstream is the actual copyright holder
2021-04-28 18:56:12 <ikke> yes
2021-04-28 18:56:13 <Sheila> the software upstream provides must comply with the license they choose
2021-04-28 18:56:26 <Ariadne> if they don't obey their own license, then the license is arguably void
2021-04-28 18:56:36 <Ariadne> don't look at me, i didn't invent this stuff
2021-04-28 18:56:38 <Thermi> Upstream can just distribute the source under a second or third license
2021-04-28 18:56:45 <Ariadne> yep
2021-04-28 18:56:48 <Thermi> They just distribute it to themselves under a "do whatever" license
2021-04-28 18:56:53 <ikke> I guess the issue is when there are multiple copyright holders?
2021-04-28 18:57:07 <Ariadne> but if they slap AGPL on it and then don't provide the source link, it's still a dick move
2021-04-28 18:57:08 <Ariadne> :p
2021-04-28 18:57:14 <ikke> https://writing.kemitchell.com/2021/01/24/Reading-AGPL.html
2021-04-28 18:57:17 <Thermi> I can only shrug to that.
2021-04-28 18:57:32 <Thermi> Ariadne: I sent an email to FSF regarding clarification clause 13. I think then we have definitive answer.
2021-04-28 18:57:39 <Thermi> Or it spins of into another discussion.
2021-04-28 18:58:16 <arwn> would someone be able to spoon feed me just a bit. i'm trying to package dotnet. https://pastebin.com/raw/tQcDcwCg this fails when i `abuild -r` saying `/usr/bin/abuild: cd: line 2377: can't cd to /home/arwn/packages/community/dotnet/pkg/dotnet: No such file or directory`
2021-04-28 18:58:48 <Thermi> Does that directory exist?
2021-04-28 18:58:48 <ikke> arwn: seems like nothing is installed in $pkgdir
2021-04-28 18:59:13 <arwn> Thermi: it does not, but if i mkdir it, it's deleted and i get the same error
2021-04-28 18:59:21 <Thermi> When is it deleted?
2021-04-28 18:59:32 <ikke> Thermi: abuild -r does clean, which removes $pkgdir
2021-04-28 18:59:36 <Thermi> Okay.
2021-04-28 18:59:49 <ikke> arwn: in the package() function, you need to copy things to $pkgdir
2021-04-28 18:59:52 <Ariadne> arwn: to be clear, we won't accept an APKBUILD that repackages random binaries downloaded from somewhere
2021-04-28 19:00:02 <ikke> nod
2021-04-28 19:00:10 <Thermi> ikke: I guess just install -Dm xxx foo bar
2021-04-28 19:00:20 <Thermi> AFAIR -D mkdirs all dirs in the path
2021-04-28 19:00:23 <ikke> Wasn't there someone from the dotnet community that was looking into packaging dotnet for alpine?
2021-04-28 19:00:27 <ikke> Thermi: yes, correct
2021-04-28 19:00:38 <Thermi> Just checked. It's correct. :P
2021-04-28 19:00:39 <Ariadne> ikke: yes
2021-04-28 19:00:41 <Thermi> ikke: ty
2021-04-28 19:00:47 <arwn> Ariadne: i'm just learning right now, but if this is easy enough i could see about building it from source so i can submit it.
2021-04-28 19:01:03 <ikke> arwn: https://github.com/dotnet/core/tree/main/tools/dotnet-bootstrap
2021-04-28 19:01:15 <Ariadne> arwn: it depends on microsoft doing a lot of stuff atm.  they are working to make it possible
2021-04-28 19:01:22 <ikke> arwn: these things are generally 'not easy' (tm)
2021-04-28 19:01:31 <Ariadne> this is largely a "patiently wait" situation atm
2021-04-28 19:01:43 <Ariadne> we are waiting on them to finish rolling out their new build system (Arcade)
2021-04-28 19:02:12 <ikke> arwn: problem is that bootstrapping is tricky, you need something to start from
2021-04-28 19:02:26 <ikke> generally, these languages are built on top of itself
2021-04-28 19:04:38 <ikke> We could try to urge upstreams to provide an option to show the source location in the interface
2021-04-28 19:05:15 <mcf> Ariadne: that seems to be a legal question about alpine packages in general rather than samurai in particular. some other alpine packages (e.g. ninja or curl) also don't package the license file
2021-04-28 19:05:42 <Ariadne> mcf: yes, it is our policy to just use the SPDX labels
2021-04-28 19:05:44 <mcf> it doesn't seem to be common practice for the package itself to install its license file, but some distributions add it to their packages
2021-04-28 19:05:51 <mcf> i mean, that seems fine to me
2021-04-28 19:06:15 <ikke> some are of the opinion that the license should be shipped with the software
2021-04-28 19:06:48 <Ariadne> it is an interesting topic
2021-04-28 19:07:08 <Ariadne> if a user has an alpine livecd, with no working internet connection, then that scenario i suppose would be non-compliant
2021-04-28 19:07:28 <Ariadne> one possible workaround would be to include a set of common licenses as part of alpine-base
2021-04-28 19:07:48 <Ariadne> though there are also the copyright statements, too
2021-04-28 19:08:14 <Ariadne> i think SPDX should create a vocabulary for specifying copyright statements as they have licenses (with both the SPDX URIs and the SPDX short labels)
2021-04-28 19:10:02 <Ariadne> if they did that, then gitlab and github and so on could provide those copyright assertions in linked-data way, as we do with SPDX
2021-04-28 19:21:38 <Ariadne> okay
2021-04-28 19:21:43 <Ariadne> i think i have a solution to this
2021-04-28 19:21:52 <Ariadne> we just add some metadata to the APKBUILDs
2021-04-28 19:22:13 <Ariadne> copyright="$srcdir/COPYING"
2021-04-28 19:22:35 <Ariadne> and then we can extract all of that into a tree of linked objects using the SPDX vocabulary
2021-04-28 19:22:44 <Ariadne> and then deduce the ones we need on the livecd
2021-04-28 19:22:50 <Ariadne> and voila, we are compliant
2021-04-28 19:24:50 <Ariadne> next SPDX meeting is on may 6
2021-04-28 19:24:56 <Ariadne> i'll call in and ask them about this
2021-04-28 19:27:45 <dalias> :)
2021-04-28 19:28:15 <dalias> silly solution: make each package 'depend on' a package that provides its license text :-p
2021-04-28 19:29:11 <dalias> and yes, for licenses that require including the license text with binaries i think you need to have a copy somewhere *offline* in the distributed files
2021-04-28 19:29:20 <dalias> some only require including it with source tho
2021-04-28 19:33:49 <skarnet> iirc debian and fedora provide the license for foo in the foo-doc package, as a file under /usr/share/foo
2021-04-28 19:34:13 <skarnet> or /usr/share/doc/foo
2021-04-28 19:37:08 <Habbie> debian does that but generally not in a separate -doc package
2021-04-28 19:37:33 <Habbie> :/usr/share/doc $ ls */copyright | wc -l
2021-04-28 19:37:34 <Habbie> 585
2021-04-28 19:37:36 <Habbie> debian
2021-04-28 19:38:46 <arwn> where should a package stick a monolithic folder of "stuff" that all needs to be together to run, if not in /opt?
2021-04-28 19:52:47 <dalias> /opt isn't for packages is it?
2021-04-28 19:52:53 <dalias> aiui it's for unpackaged software
2021-04-28 19:53:11 <Hello71> i mean it's kind of a "shurg" area
2021-04-28 19:53:18 <dalias> skarnet, that ends up duplicating a lot of files
2021-04-28 19:54:10 <ikke> arwn left
2021-04-28 19:55:17 <skarnet> duplicating a lot of files? if you install the sources along, sure
2021-04-28 19:55:33 <skarnet> if you don't... that's just a license file.
2021-04-28 19:55:53 <Hello71> regarding licenses, arch has a fairly KISS solution: a chunky "licenses" package that is required by "base" metapackage and installs /usr/share/licenses/*. then, each package states license=GPL-2 or whatever, which you can look up yourself in /usr/share/licenses. if a package uses a license not in the standard set, it should put it at /usr/share/doc/$pkgname/LICENSE or similar (in its own
2021-04-28 19:55:56 <Hello71> package)
2021-04-28 19:57:22 <Hello71> skarnet: i think dalias' point is that we don't want to install 100 identical copies of gpl-2.0.txt. i guess it would be fine if they're all symlinks
2021-04-28 19:58:04 <skarnet> ah, ok, that makes sense
2021-04-28 20:30:48 <donoban> hi
2021-04-28 20:32:39 <donoban> mps: do you want forward it to upstream?
2021-04-28 20:45:08 <mps> donoban: do whatever you think
2021-04-28 20:45:49 <donoban> hehe ok
2021-04-28 20:46:37 <mps> I don't have github account
2021-04-28 20:46:57 <donoban> I checked their github repository but they don't handle the issues there
2021-04-28 20:47:06 <donoban> they use a bugzilla server
2021-04-28 20:47:25 <donoban> https://bugzilla.tianocore.org/
2021-04-28 20:47:28 <mps> also I didn't saw issue tracker there
2021-04-28 20:48:04 <mps> huh, is registration required to post bug?
2021-04-28 20:48:18 <donoban> yes
2021-04-28 20:48:49 <donoban> don't worry I'm gonna search and post one if I don't find anything useful
2021-04-28 20:48:57 <mps> huh.huh
2021-04-28 21:07:46 <donoban> ough this bugtrack is pretty uggly, I will ping you if they answer something
2021-04-28 21:07:55 <donoban> https://bugzilla.tianocore.org/show_bug.cgi?id=3363
2021-04-28 21:08:03 <donoban> I've attached the full log from pipeline
2021-04-28 21:15:57 <mps> donoban: thanks, I'm really grateful to you
2021-04-28 21:16:27 <donoban> np, I hope they reply :)
2021-04-28 21:16:43 <mps> yes, I have bugzilla account on kernel.org, it is ugly but less than github/gitlab :)
2021-04-28 21:17:11 <donoban> hehe, at lest they have emoticons :P
2021-04-28 21:17:58 <donoban> I'm going to sleep, see you tomorrow :)
2021-04-28 21:19:26 <mps> emoticons? you mean these two characters ':)'
2021-04-28 21:19:46 <mps> also I'm going to bed, good night
2021-04-28 21:19:52 <ikke> o/
2021-04-28 21:20:06 <mps> \o
2021-04-28 21:20:34 <donoban> :laught: :D
2021-04-28 21:20:45 <donoban> what happened to my emoj plugin -_-
2021-04-28 21:21:30 <donoban> well good night :)
2021-04-28 21:23:32 <ikke> edge repos are now also tracked on https://security.alpinelinux.org
2021-04-28 21:23:59 <Ariadne> donoban, mps: this appears to be fortify-related
2021-04-28 21:24:44 <Ariadne> which means VfrCompile is doing something wrong
2021-04-28 21:24:54 <ikke> (except testing, we do not track security for testing, you're on your own, there)
2021-04-28 21:24:55 <mps> uh, why do you take my sleep ;)
2021-04-28 21:25:15 <Ariadne> i can look into it
2021-04-28 21:25:44 <mps> thanks, and good night also to you (and all)
2021-04-28 21:28:28 <ikke> I'm out as well
2021-04-28 21:29:56 <Ariadne> have a good sleep
2021-04-28 21:30:06 <Ariadne> i think i will investigate this after having dinner :)
2021-04-29 05:44:25 <ikke> maribu[m]: texmf-dist has build issues
2021-04-29 05:44:34 <ikke> on armv7 and aarch64
2021-04-29 06:00:26 <maribu[m]> Thanks, will take a look.
2021-04-29 06:03:36 <maxice8> opinions on !20949 ?
2021-04-29 06:20:17 <mps> ah, Aisha
2021-04-29 06:20:44 <mps> will look later more
2021-04-29 07:10:16 <ncopa> morning
2021-04-29 07:10:44 <ncopa> eselect is kinda scary. where do we draw the limit?
2021-04-29 07:12:19 <mps> maxice8: nack for !20949
2021-04-29 07:12:30 <Cogitri> Yeah, and we'd usually just solve this with providers/replace instead of something as complex as eselect
2021-04-29 07:12:44 <mps> it depends on bash and having bash in alpine base is not good idea
2021-04-29 07:17:10 <mps> good morning
2021-04-29 07:17:46 <mps> ncopa: I would like to draw limits little above the base
2021-04-29 07:19:55 <desultory> just to put it out there as I wander off: there's nothing about eselect that fundamentally requires bash; sure there'd be a bit of a rewrite involved but if you think that you need eselect and you don't want bash, it's entirely doable.
2021-04-29 07:21:15 <mps> rewrite anything is doable
2021-04-29 07:44:14 <donoban> hi
2021-04-29 07:48:59 <donoban> ikke: nice
2021-04-29 07:52:04 <donoban> I'm not sure if this applies to openvpn community version https://security.alpinelinux.org/vuln/CVE-2020-7224
2021-04-29 07:55:27 <mps> ikke: redis failed on builder with same reason as on CIs
2021-04-29 07:57:06 <mps> disable these tests or tweak builders?
2021-04-29 08:08:53 <ikke> If it's purely a timing issue, perhaps increase time?
2021-04-29 08:09:03 <ikke> But maybe we should ask upstream about it
2021-04-29 08:10:23 <mps> not sure what to do, tbh
2021-04-29 08:24:48 <maribu[m]> @ikke: Can you give me a link to the build log? My RPi (aarach64) builds texfmf-dist just fine :/
2021-04-29 08:26:05 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/texmf-dist/texmf-dist-2021.58710-r0.log
2021-04-29 08:31:34 <maribu[m]> How like is a file corruption during the build being the cause?
2021-04-29 08:33:36 <maribu[m]> Are checksums checked during unpack()? The APKBUILD is overwriting the default `unpack()` function to unpack the script files during packaging instead, as texmf-dist is noarch and no building is done.
2021-04-29 08:34:42 <maribu[m]> If the zip file was just not correctly downloaded but the checksum check was skipped by overloading unpack, this would explain the log. (And obviously, the checksum check should be re-added.)
2021-04-29 08:36:24 <maribu[m]> Yep. I just modified the checksum in the APKBUILD  by hand and it still builds :/ At least the source code is downloaded via HTTPS. I'll check if I can fix this.
2021-04-29 08:40:11 <maribu[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20958
2021-04-29 08:51:00 <ikke> These arches share the same builder
2021-04-29 09:08:45 <ncopa> i think im gonna tag an abuild release
2021-04-29 11:14:17 <mps> maribu[m]: you are welcome :)
2021-04-29 11:16:04 <ikke> ncopa: is the new abuild version supposed to contain the concurrent download fix?
2021-04-29 11:16:30 <ncopa> ikke: yes
2021-04-29 11:16:36 <ikke> ok, good :)
2021-04-29 11:16:54 <ncopa> there are more work to do with abuild, but i think i need to limit myself and ship it
2021-04-29 11:16:58 <ikke> It seems the texmf-dist package is hitting it as well
2021-04-29 11:17:05 <ikke> ncopa: yes, makes sense
2021-04-29 11:17:16 <ncopa> most work has been on adding tests
2021-04-29 11:17:22 <ikke> which is very good
2021-04-29 11:17:29 <ncopa> i think we should have tests for as much as possible
2021-04-29 11:17:38 <Ariadne> https://github.com/AppImage/appimage.github.io/blob/master/code/worker.sh#L213
2021-04-29 11:17:41 <ncopa> and preferrible we should write the tests before we write the code :)
2021-04-29 11:17:48 <Ariadne> i saw this eldritch horror, so now you all must too
2021-04-29 11:18:03 <ncopa> aw!
2021-04-29 11:18:08 <ncopa> please let me un-see that
2021-04-29 11:18:11 <ikke> :D
2021-04-29 11:18:26 <ikke> ncopa: anything keeping https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/85 from being merged?
2021-04-29 11:18:33 <ncopa> i was thinkgin that we should try move things like newapkbuild, abump, apkgrel etc to atools
2021-04-29 11:18:54 <ncopa> and i think abuild should call things liks secfixes-check if its available
2021-04-29 11:20:46 <Ariadne> its sure going to be funny when we flip the switch and apks aren't tarballs anymore
2021-04-29 11:21:45 <ncopa> ikke: i guess not. just need to verify that it works as intended :)
2021-04-29 11:23:12 <Ariadne> cue: "how can we get firejail back in alpine"
2021-04-29 11:23:15 <ncopa> ikke: might need to be rebased
2021-04-29 11:23:28 <Ariadne> answer: rewrite it from scratch so it's actually secure and not requiring SUID
2021-04-29 11:23:28 <Ariadne> :D
2021-04-29 11:23:37 <Sheila> "use bubblejail instead"
2021-04-29 11:25:15 <Ariadne> oh well, i fully believe removing firejail was the absolutely right thing for us to do
2021-04-29 11:25:32 <Ariadne> when you're the first distro to do something, you're going to have pain like thi
2021-04-29 11:25:33 <Ariadne> s
2021-04-29 11:30:04 <mps> this is good start, there are a lot more candidates ;>
2021-04-29 11:30:57 <mps> till all finish in /dev/melting_pot
2021-04-29 11:31:34 <mps> and we are all secure, small and simple :D
2021-04-29 12:51:53 <tomleb> Is it possible to get the pid file from a daemon started with supervise-daemon?
2021-04-29 12:52:13 <tomleb> From an init.d script
2021-04-29 12:55:54 <tomleb> I know that it stores it in /run/supervise-<service>.pid.. Maybe I can rely on that.
2021-04-29 13:45:32 <skarnet> the better question is, if you're using a supervisor, why would you ever need the pid?
2021-04-29 13:45:53 <skarnet> the *point* of a supervisor is to provide an interface to control the process *without* having to rely on the pid
2021-04-29 13:46:08 <skarnet> but maybe that's just another basic thing openrc did not understand :/
2021-04-29 13:47:10 <mps> wait, supervised process with openrc supervise-daemon have pid?
2021-04-29 13:47:34 <skarnet> mps, every process on Unix has a pid, you should know that by now
2021-04-29 13:47:37 <skarnet> 
ACTION runs

2021-04-29 13:48:29 <skarnet> but yes, apparently they have a pid file, which they kinda have to have internally, but it should not be user-visible
2021-04-29 13:48:33 <mps> I mean, in some files
2021-04-29 16:03:34 <tomleb> skarnet: right, in my case it's because the app supports user signals to trigger some stuff (eg: reload, etc). I'm already using supervise-daemon to supervise the process, I just need to be able to kill -SIGUSR1 to it too
2021-04-29 16:06:01 <mps> donoban: Ariadne: I fixed 'Illegal instruction' failure in !20626 by adjusting previous patch which I overlooked
2021-04-29 16:06:38 <ikke> tomleb: wouldn't you use openrc then to forward those signals?
2021-04-29 16:06:48 <Ariadne> mps: that's naughty
2021-04-29 16:07:03 <donoban> great :)
2021-04-29 16:07:17 <Ariadne> adjusted previous patch by adding "#define _FORTIFY_SOURCE 0" :D
2021-04-29 16:07:17 <donoban> but pipeline failed?
2021-04-29 16:07:26 <tomleb> ikke: I'm trying to add a extra_started_commands= command, yes, just not sure how to do it with supervise-daemon
2021-04-29 16:07:29 <mps> but it still fail on some build.py invocations
2021-04-29 16:07:41 <mps> Ariadne: :)
2021-04-29 16:07:48 <Ariadne> yeah it probably still crashes :p
2021-04-29 16:08:07 <skarnet> tomleb: if supervise-daemon doesn't offer you an interface to do that, you could run your app under s6, and it would work. ;)
2021-04-29 16:08:11 <Ariadne> fortify is about fail fast
2021-04-29 16:08:16 <ikke> tomleb: maybe ask in #openrc
2021-04-29 16:08:24 <ikke> there is a dedicated channel
2021-04-29 16:08:43 <tomleb> Yeah, should've asked there first. thanks!
2021-04-29 16:09:48 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/382256#L665
2021-04-29 16:10:07 <mps> make: *** No rule to make target
2021-04-29 16:11:02 <mps> and more of these
2021-04-29 16:11:06 <mps> huh
2021-04-29 16:42:40 <mcrute> Ariadne: saw your tweet about not using tar to unpack apks... in the new world how does one bootstrap apk itself? currently the AMI script is using the tar trick but I'm thinking about ways to improve it
2021-04-29 16:42:59 <Ariadne> one downloads, and uses apk-tools-static.
2021-04-29 16:43:03 <Ariadne> as they should do now :)
2021-04-29 16:43:13 <mcrute> isn't that itself an apk?
2021-04-29 16:43:29 <Ariadne> yes but we will provide it in another form for bootstrapping
2021-04-29 16:44:30 <Cody> Can anyone direct me to a "how to" tutorial on building Alpine from source? I'm trying to learn how to build Alpine for Docker containers...
2021-04-29 16:44:59 <mcrute> oh prefect, that's what I'm doing already so we'll probably just need to make a minor tweak to pull a different tar in the future :-)
2021-04-29 16:47:23 <ikke> Cody: what exactly do you mean with building alpine from source?
2021-04-29 16:47:27 <mcrute> any objection to me merging the setup-cloud-images script (by a different name of course) into alpine-conf? I think it would be valuable to share some of the logic already there
2021-04-29 16:55:50 <mcrute> ugh... nm... I now remember why I didn't do that in the first place
2021-04-29 16:56:22 <mcrute> you have to bootstrap alpine then do the alpine install within the bootstrapped alpine from within another OS image otherwise it's "chicken meet egg" time
2021-04-29 17:00:15 <mcrute> Ariadne: the security db stuff is super awesome! one of my favorite features is being able to see at a glance what versions of a package are in all releases :-D
2021-04-29 17:03:47 <Cody> ikke - Like however the alpine .tar.gz's are generated? Similar to the ones listed in the downloads page?: https://alpinelinux.org/downloads/
2021-04-29 17:04:08 <Cody> Whatever that process is?
2021-04-29 17:04:27 <mps> Cody: look aports/scripts
2021-04-29 18:02:54 <Cody> @mps I did get that far, but I'm having trouble running `mkimage.sh`. Seem like it relies on `apk` and a few other build-type dependencies.
2021-04-29 18:03:10 <Cody> Like, I need alpine to build alpine?
2021-04-29 18:03:34 <ikke> Building the images, yes
2021-04-29 18:04:34 <ikke> building alpine from scratch would mean you first bootstrap a chroot, including apk-tools
2021-04-29 18:04:42 <ikke> a build toolchain
2021-04-29 18:04:53 <ikke> then you start building more and more packages
2021-04-29 18:05:17 <ikke> then, after all packages are built, you can make an image
2021-04-29 18:08:47 <Cody> Is there a guide somewhere that demonstrates how to do this? I tried googling it, but didn't find any resources.
2021-04-29 18:10:05 <Cody> Like, if you take a look at:
2021-04-29 18:10:05 <Cody> https://github.com/alpinelinux/docker-alpine/blob/489953694b9dd165f615dc01971971ddf55701f8/x86_64/Dockerfile
2021-04-29 18:10:06 <Cody> I want to know the least steps in order to generate the tar.gz shown on line 2.
2021-04-29 18:10:06 <Cody> Does that require the build toolchain you mentioned?
2021-04-29 18:12:50 <ikke> You need at least apk-static
2021-04-29 18:13:04 <ikke> then you can manually create a chroot from pre-built packages
2021-04-29 18:15:16 <Cody> Gotcha, I'll start there, I guess
2021-04-29 19:31:05 <jona> hello, with the help of the postmarketos irc channel, i have made an APKBUILD for a simple colorpicker, that i would like to submit
2021-04-29 19:31:37 <ikke> jona: welcome
2021-04-29 19:31:42 <jona> what is the preferred way, gitlab or mailing list?
2021-04-29 19:31:49 <ikke> gitlab is preferred
2021-04-29 19:32:04 <jona> do i need an account at gitlab for that?
2021-04-29 19:32:26 <ikke> yes, though you could connect your gitlab.com or github.com account
2021-04-29 19:35:10 <jona> ok, will do
2021-04-29 19:36:44 <mps> I 'give up' with !20626 don't understand all this complicated build in it
2021-04-29 19:37:12 <mps> for my use cases will use these things from debian
2021-04-29 19:41:03 <Ariadne> mps: i will try to look into it next week
2021-04-29 19:41:09 <Ariadne> mps: can you assign the bug you opened to me?
2021-04-29 19:44:14 <mps> sure, and thanks
2021-04-29 19:44:59 <mps> done
2021-04-29 19:58:07 <dalias> do any alpine folks have a beagle-v? :)
2021-04-29 19:59:26 <mps> is it risc-v?
2021-04-29 19:59:33 <Ariadne> one of the zededa guys has one
2021-04-29 20:00:08 <Ariadne> that's not directly alpine, but in the alpine universe
2021-04-29 20:14:32 <dalias> yes, it seems viable to build with
2021-04-29 20:33:27 <Ariadne> 8gb ram is still a bummer
2021-04-29 20:33:36 <Ariadne> but i guess better than nothing
2021-04-29 20:35:40 <dalias> 8gb is 4x what my laptop has so...
2021-04-29 20:36:07 <Ariadne> stuff like firefox
2021-04-29 20:36:14 <Ariadne> requires like 20gb ram to build
2021-04-29 20:36:16 <dalias> excited to get it up and running. it's probably faster than most if not all of my x86 boxes
2021-04-29 20:36:17 <Ariadne> ;/
2021-04-29 20:36:28 <Ariadne> what x86 boxes are that
2021-04-29 20:36:34 <dalias> atoms and celerons
2021-04-29 20:36:37 <Ariadne> oh
2021-04-29 20:36:39 <Ariadne> ok :)
2021-04-29 20:36:45 <Ariadne> i was like, whaaaaaaaaa
2021-04-29 20:36:57 <dalias> oh i have the core i7 low-power thing but it's been shelved since spectre
2021-04-29 21:06:55 <jona> so i tried to do a merge request but the build failed at 'Executing "step_script" stage of the job script' with "fatal: could not read Username for 'https://gitlab.alpinelinux.org': No such device or address"
2021-04-29 21:11:14 <RootWyrm_> Chrome requires ∞GB of RAM to build
2021-04-29 21:16:21 <RootWyrm_> I'm being sorely tempted to build a couple of boxes with these https://www.asrockrack.com/general/productdetail.asp?Model=EPYC3451D4I2-2T#Specifications
2021-04-29 21:16:40 <RootWyrm_> 512GB in ITX, why not?
2021-04-29 21:19:54 <Ariadne> only infinity GB?
2021-04-29 21:20:05 <Ariadne> i feel like it needs more still :)
2021-04-29 21:20:49 <Ariadne> heres an idea
2021-04-29 21:20:52 <Ariadne> what if we use zram
2021-04-29 21:20:57 <Ariadne> and shitty SSDs
2021-04-29 21:21:01 <Ariadne> from micro center
2021-04-29 21:21:03 <Ariadne> as "RAM"
2021-04-29 21:21:05 <Ariadne> :D
2021-04-29 21:21:19 <RootWyrm_> hey now. they're not shitty. they're just without brand premiums.
2021-04-29 21:21:27 <Ariadne> nah i'm talking like
2021-04-29 21:21:35 <Ariadne> those really slow write MLC ones
2021-04-29 21:21:44 <Ariadne> that you can get for 20 bucks
2021-04-29 21:21:49 <Ariadne> that are basically SD cards
2021-04-29 21:22:12 <RootWyrm_> those aren't MLC, those are TLC/QLC and should be burned.
2021-04-29 21:22:20 <Ariadne> yo what
2021-04-29 21:22:36 <Ariadne> those epyc boards look pretty... epyc
2021-04-29 21:22:41 <Ariadne> haaaaaaa
2021-04-29 21:22:48 <Ariadne> i might have to get me one of those for my colo
2021-04-29 21:22:53 <Ariadne> or two
2021-04-29 21:23:05 <RootWyrm_> this is the one to get though: https://www.asrockrack.com/general/productdetail.asp?Model=EPYC3451D4U-2L2T2O8R#Specifications
2021-04-29 21:23:15 <RootWyrm_> "here we gave you 4x10GbE"
2021-04-29 21:23:27 <Ariadne> hmm
2021-04-29 21:23:41 <RootWyrm_> "what? no, not 2SFP/2RJ split. 2+2"
2021-04-29 21:24:02 <Ariadne> i wish it was 4xSFP
2021-04-29 21:24:12 <Ariadne> then i could hook up a QSFP to SFP breakout cable
2021-04-29 21:24:16 <Ariadne> i have a ton of em
2021-04-29 21:43:14 <mps> hehe, did I told yesterday that I expect qemu 6.0.0 release soon :)
2021-04-29 21:43:25 <RootWyrm_> i don't think the CS4227 can do breakout
2021-04-29 21:43:49 <RootWyrm_> oh wait, wrong direction. nevermind. i've been stuck switch shopping today.
2021-04-29 23:45:38 <andypost[m]> Is armhf ddge builder hanging on community/dssim 3.0.1-r0
2021-04-30 00:28:14 <Ariadne> andypost[m]: sure looks like it
2021-04-30 03:15:28 <maxice8> aports-qa-bot now assigns maintainers when possible
2021-04-30 06:44:12 <clandmeter> good morning
2021-04-30 06:44:58 <clandmeter> Ariadne: nice work on alpineconf. didnt even notice it had already so many proposals for talks.
2021-04-30 07:14:39 <mps> clandmeter: good morning :)
2021-04-30 07:14:46 <mps> good morning to all
2021-04-30 07:23:01 <mps> ncopa: postfix 3.6.0 is release yesterday. should we upgrade it for 3.14 alpine or after?
2021-04-30 07:23:15 <mps> released*
2021-04-30 07:24:40 <mps> it have important and incompatible changes, '3.6 deprecates terminology that implies white is better than black. Instead, Postfix prefers 'allowlist', 'denylist' :)
2021-04-30 07:26:23 <mps> another important pkg is qemu 6.0.0 (also released yesterday)
2021-04-30 07:27:18 <mps> it has secfixes, which we will have to backport to 5.2.0 if we do not upgrade
2021-04-30 07:29:28 <mps> Ariadne and I already 'voted' for qemu upgrade
2021-04-30 08:27:10 <ncopa> mps: +1 for both postfix 3.6 and qemu 6
2021-04-30 08:33:09 <mps> good, already started on qemu, have to check all our patches
2021-04-30 08:34:24 <mps> have to finish some $day_jobs first
2021-04-30 08:43:03 <mps> hah, auto assign works now
2021-04-30 08:44:52 <Cogitri> Yup, the bot should automatically assign the maintainer now (if author != maintainer), feel free to ping me or maxice8 if something doesn't work
2021-04-30 08:46:30 <mps> it works, just wonder how ncopa handle his mailbox :)
2021-04-30 08:46:43 <mps> will handle*
2021-04-30 08:50:58 <mps> would someone add to release notes for 3.14 this url http://www.postfix.org/announcements/postfix-3.6.0.html for postfix
2021-04-30 09:13:00 <ncopa> ikke: what do you think about doing the test like this? https://tpaste.us/DMll?hl=true
2021-04-30 09:15:38 <ncopa> updated patch that actually works: https://tpaste.us/BElR?hl=true
2021-04-30 09:25:24 <ikke> ncopa: looks fine to me
2021-04-30 09:40:19 <Newbyte> If the test suite for a package only does linting and type checking, should it be run in the Alpine package?
2021-04-30 09:47:21 <Cogitri> Sure, doesn't hurt
2021-04-30 09:47:39 <Newbyte> It fails though … :(
2021-04-30 09:48:06 <Cogitri> Best to ask upstream about it then
2021-04-30 09:49:17 <Newbyte> Also: I packaged community/mirage as mirage, but upstream prefers it to be packaged as mirage-im I learnt now. The reasoning is that there is other software called mirage, so it's better to make the distinction. However, Alpine doesn't have any other software called mirage, and if I put that mirage-im provides mirage you couldn't really have a mirage package anyway
2021-04-30 09:49:21 <Newbyte> What do you think?
2021-04-30 09:51:17 <ikke> What will users try to install?
2021-04-30 09:51:30 <Newbyte> Probably mirage
2021-04-30 09:51:39 <Newbyte> Some distributions call it matrix-mirage though
2021-04-30 09:52:04 <ikke> What does their readme suggest?
2021-04-30 09:58:54 <Newbyte> What do you mean?
2021-04-30 09:59:09 <Newbyte> The readme just says mirage in the top heading
2021-04-30 09:59:17 <Newbyte> but their contributing guide suggests to package it as mirage-im
2021-04-30 10:12:07 <donoban> Hi guys, I like mirage-im, with just mirage I would confuse it with ocaml mirage
2021-04-30 10:12:50 <Newbyte> don't language-specific packages usually have some sort of prefix or such?
2021-04-30 10:13:02 <Newbyte> like how all python packages start with py3-
2021-04-30 10:14:03 <Newbyte> However, there is an image viewer called mirage
2021-04-30 10:14:09 <Newbyte> Like, just mirage
2021-04-30 10:14:22 <donoban> uhM, I didn't know it
2021-04-30 10:14:29 <Newbyte> In Fedora the "mirage" package is this image viewer
2021-04-30 10:14:34 <Newbyte> So it could be confusing
2021-04-30 10:14:51 <donoban> it looks nice
2021-04-30 10:15:07 <donoban> " A fast and simple image viewer "
2021-04-30 10:15:22 <donoban> it misses "secure" :D
2021-04-30 10:16:54 <donoban> or they migrate the project from sourceforge or it semes abandoned
2021-04-30 12:26:38 <Ariadne> lrwxrwxrwx 1 root root 72 Apr  8 17:15 /usr/include/systemd -> /home/buildozer/aports/community/elogind/pkg/elogind/usr/include/elogind
2021-04-30 12:26:39 <Ariadne> wut
2021-04-30 12:27:06 <Ariadne> $ apk info -W /usr/include/systemd
2021-04-30 12:27:06 <Ariadne> /usr/include/systemd is owned by elogind-dev-246.10-r2
2021-04-30 12:27:07 <Ariadne> hmm
2021-04-30 12:35:22 <Ariadne> well i fixed that :)
2021-04-30 12:48:04 <walbon> clandmeter, hi, I am looking for the issue in the ppc-builder hosted by unicamp. So, did you see the Rafael's emails about the ETA and an alternative machine?
2021-04-30 12:49:29 <walbon> ow! my bad, you are not on the thread, kevin and nathael are.
2021-04-30 12:49:47 <walbon> ncopa, ^
2021-04-30 12:50:02 <walbon> ikke, ^
2021-04-30 12:59:34 <ncopa> hi
2021-04-30 13:00:46 <walbon> ncopa, I am talking about the Rafael's email from Unicamp/IBM to support the ppc builder.
2021-04-30 13:00:58 <ncopa> walbon: i guess a vm will work but it will require some work to set it up I guess
2021-04-30 13:01:23 <walbon> I see
2021-04-30 13:02:10 <ncopa> walbon: do you know if there are any hope to get it back?
2021-04-30 13:02:23 <Ariadne> ncopa: hmm, abuild is failing to build on x86
2021-04-30 13:02:39 <walbon> ncopa, actually we don't how much effort will be need to able again the machine back.
2021-04-30 13:02:54 <Ariadne> worst case scenario, i have an IBM S812LC i can set up as builder
2021-04-30 13:03:00 <walbon> ncopa, yes, it will be back but not soon i guess
2021-04-30 13:03:51 <Ariadne> i would prefer to not have to do that though, i'm running near the limit of power i am alloted at my colo
2021-04-30 13:03:52 <ncopa> not soon means "not til monday" or "not within a month/year"?
2021-04-30 13:04:41 <walbon> not till monday
2021-04-30 13:04:50 <Ariadne> oh, thats fine then :)
2021-04-30 13:04:54 <ikke> Yes
2021-04-30 13:05:17 <ncopa> i think if we get it early next week will be fine
2021-04-30 13:05:26 <walbon> ok
2021-04-30 13:06:47 <ncopa> i wonder if taking out the disks and put them in a new machine is an option
2021-04-30 13:07:17 <Ariadne> i would assume that is what they would do
2021-04-30 13:07:50 <Ariadne> at least on my S812LC and S922 the disks are on sleds
2021-04-30 13:07:57 <Ariadne> just like any other server
2021-04-30 13:08:24 <Ariadne> petitboot is petitboot, it doesn't require any special variables in NVRAM to work
2021-04-30 13:08:32 <Ariadne> so swapping the disks should work
2021-04-30 13:08:38 <Ariadne> unless its the disks that are dead
2021-04-30 13:08:43 <Ariadne> in which case, we cry :)
2021-04-30 13:09:02 <ncopa> walbon: thank you very much for helping us with this. the machine is very useful, and kinda essential for the ppc64le port :)
2021-04-30 13:09:20 <ncopa> if the disks are dead we'll probably panic, yes :)
2021-04-30 13:11:46 <walbon> ncopa, welcome. If possible answer the Rafael's emails, he is in charge of laboratory.
2021-04-30 13:15:21 <RootWyrm_> what's the origin system?
2021-04-30 13:15:50 <ncopa> walbon: will do. thank!
2021-04-30 13:16:27 <walbon> ncopa, you're welcome
2021-04-30 13:26:29 <Ariadne> RootWyrm_: original system?  i think it is an S812LC like mine
2021-04-30 13:27:07 <Ariadne> they might have upgraded it to a POWER9 machine though
2021-04-30 13:27:41 <RootWyrm_> then possibly swappable if it's whole machine partitioned.
2021-04-30 13:27:58 <Ariadne> yeah they should be able to just swap the disks
2021-04-30 13:28:10 <Ariadne> it's not a VM or anything
2021-04-30 13:28:25 <RootWyrm_> Partition != VM
2021-04-30 13:28:39 <RootWyrm_> S812LC does whole machine, IVM, and HMC.
2021-04-30 13:30:03 <maxice8> Ikke: thanks for reporting the ERRors that come out of aports-qa-bot to Cogitri
2021-04-30 13:30:11 <RootWyrm_> I also don't recall if the S812L does serial locking in OPAL unfortunately.
2021-04-30 13:32:06 <Ariadne> RootWyrm_: yeah i mean that it's not an LPAR
2021-04-30 13:32:10 <Ariadne> its powernv
2021-04-30 13:32:17 <RootWyrm_> That's IVM
2021-04-30 13:32:46 <RootWyrm_> (Which I will always hate the name of.)
2021-04-30 13:32:47 <Ariadne> hmm?  powernv is bare metal
2021-04-30 13:32:56 <Ariadne> isn't it?
2021-04-30 13:33:02 <Ariadne> i thought PowerNV = Power Non-Virtualized
2021-04-30 13:33:11 <RootWyrm_> Oh wait, yeah... forgot OPAL does _that_
2021-04-30 13:34:10 <Ariadne> all my Alpine ppc64le are baremetal and report OPAL/PowerNV in cpuinfo :)
2021-04-30 13:34:20 <Ariadne> so i think all they need to do is swap the disks
2021-04-30 13:34:50 <RootWyrm_> Possibly, but as I said, I don't remember if the S812L does serial locking. Since it's still got MIC.
2021-04-30 13:36:56 <Ariadne> admittedly, i've never swapped disks on mine, so i dunno either :)
2021-04-30 13:37:21 <Ariadne> but it seems to me like all you would have to do is 'approve' the change in MIC
2021-04-30 13:37:32 <Ariadne> how one does that i have no idea :)
2021-04-30 13:37:41 <RootWyrm_> Oh god no. It's nowhere near that simple.
2021-04-30 13:38:15 <Ariadne> my understanding is that the MIC serial locking feature is mostly for mitigating 'evil maid' style attacks
2021-04-30 13:38:24 <Ariadne> so i am surprised it is more complex than that
2021-04-30 13:38:39 <RootWyrm_> Very much not the case. S812L's still have classical ASMI as I recall.
2021-04-30 13:40:41 <RootWyrm_> Plus OPAL's abysmal.. one of the many, many reasons I keep L's out of any environment. It's actually easier to swap disks on an HMC partitioned system.
2021-04-30 13:41:00 <ncopa> im looking at the abuild issue on x86 builder
2021-04-30 13:41:51 <ikke> maxice8: yes, will keep an eye on it
2021-04-30 13:59:28 <ncopa> i have pushed abuild 3.8.0_rc1 to edge
2021-04-30 13:59:47 <ncopa> please keep an eye on breakages
2021-04-30 14:10:29 <opal> >Plus OPAL's abysmal..
2021-04-30 14:10:30 <opal> rude
2021-04-30 14:38:24 <RootWyrm_> opal: hahaha, sorry. ;)
2021-04-30 14:46:59 <ddevault> is Marian Buschsieweke in this channel?
2021-04-30 14:47:12 <Cogitri> maribu[m]: ^
2021-04-30 14:47:50 <ddevault> maribu[m]: I think the latest tex updates broke some of my documents
2021-04-30 14:47:54 <ddevault> maribu[m]: xdvipdfmx:fatal: Cannot proceed without .vf or "physical" font for PDF output...
2021-04-30 14:51:35 <ddevault> maribu[m]: I fixed it with this series of commands: https://paste.sr.ht/~sircmpwn/fd974e8b992d3361eb8ed7676799e69ffbf417fc
2021-04-30 14:51:42 <ddevault> maribu[m]: might be something for the post-update, dunno
2021-04-30 15:54:40 <andypost[m]> ncopa: is fresh abuild changed format of checksums?
2021-04-30 15:55:37 <ikke> yes
2021-04-30 16:27:56 <maribu[m]> ddevault: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21009 should hopefully fix the issue for others affected. I think running fmtutil-sys again on texlive updates might make sense anyway.
2021-04-30 16:28:42 <ddevault> thanks maribu[m]
2021-04-30 16:40:01 <maribu[m]> you're welcome. Thanks for reporting!
2021-04-30 17:03:29 <donoban> mps: Ariadne "If VfrCompile contained undefined behavior, I wouldn't be surprised. Please compile VfrCompile with conservative / permissive compiler settings." would he refer to gcc flags? Maybe the VfrCompile problem is already fixed and unrelated with next error
2021-04-30 17:03:47 <Ariadne> donoban: can you step back from the tianocore thing
2021-04-30 17:05:46 <donoban> what you want
2021-04-30 17:06:12 <Ariadne> i'm looking into why VfrCompile crashes with fortify
2021-04-30 17:06:39 <Ariadne> playing telephone is just adding noise, not actual signal
2021-04-30 17:10:20 <mps> Ariadne: we should express kindness to people who want to help
2021-04-30 17:10:54 <Ariadne> donoban: i do appreciate your opening a bug with the tianocore bugzilla though :)
2021-04-30 17:11:27 <mps> maybe donoban didn't noticed our talk last night
2021-04-30 17:11:42 <ncopa> andypost[m]: yes https://gitlab.alpinelinux.org/alpine/abuild/-/commit/f523aabce3101c941d796baa84c2666b8a7dbecc
2021-04-30 17:11:45 <donoban> hehe it's the only thing that ocurred to me
2021-04-30 17:11:57 <donoban> uhM, probably I missed something
2021-04-30 17:12:09 <Ariadne> mps: well i noted it on the bugzilla too :)
2021-04-30 17:12:27 <Ariadne> tianocore saying they don't care if their code is buggy doesn't tell us anything helpful :)
2021-04-30 17:12:51 <mps> donoban: I assigned issue to Ariadne and forgot it existed ;)
2021-04-30 17:13:13 <donoban> he said "he is not surprised" maybe he really cares :)
2021-04-30 17:13:35 <Ariadne> that's... not the vibe i get from that message :D
2021-04-30 17:14:35 <donoban> well, I was going to say that the makefile error is on a clean build
2021-04-30 17:15:07 <Ariadne> lets focus on diagnosis first
2021-04-30 17:15:26 <Ariadne> the makefile error is whatever
2021-04-30 17:15:40 <Ariadne> we will fix it, after we fix VfrCompile
2021-04-30 17:16:13 <donoban> ok ok
2021-04-30 18:10:32 <mps> is there method to revert some changes in git branch after 'git add ; git commit'
2021-04-30 18:11:55 <afontain_> git reset HEAD^
2021-04-30 18:12:05 <afontain_> it will "uncommit" the last commit
2021-04-30 18:12:26 <afontain_> or specifically, change the branch so that it points to the commit you passed
2021-04-30 18:12:44 <afontain_> (--hard will also remove the changes in your work dir)
2021-04-30 18:13:36 <mps> afontain_: no, I don't want to revert commit
2021-04-30 18:14:11 <mps> probably asking something hard to explain and actually imposible to be done
2021-04-30 18:14:28 <afontain_> well, it's not a "git revert"
2021-04-30 18:15:34 <mps> did it 'manually' by copying back deleted files
2021-04-30 18:17:52 <mps> looks like that worked
2021-04-30 19:13:51 <omni> barely anything is impossible, just not straight forward (or, when it comes to git, consistent)
2021-04-30 19:15:51 <mps> !21007
2021-04-30 19:16:25 <omni> you can check out a deleted file from history if you know a commit hash where it existed, or checkout relative to the hash where it was deleted (~1)
2021-04-30 19:16:51 <mps> omni: I was talked about single commit
2021-04-30 19:27:32 <omni> mps: your latest commit removed the file? 'git checkout HEAD~1 -- <file to restore>'
2021-04-30 19:36:18 <mps> omni: thanks, but I can't test this now because I did this manually by copying deleted file from archive and added it again
2021-04-30 19:36:54 <mps> good to remember
2021-04-30 19:45:52 <Dadrophenia> I got a couple of packages merged into testing that were `arch="all"` with all their pipelines passing, but they didn't seem to get into the repos for ppc64le. This is causing issues for that arch with my package that depends on these already-merged packages. Anyone know what's going on here?
2021-04-30 19:46:14 <Dadrophenia> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20999
2021-04-30 19:47:01 <mps> Dadrophenia: ppc64 builder is on 'vacation'
2021-04-30 20:24:53 <Ariadne> Dadrophenia: as mps said, ppc64 builder is presently down due to a hardware fault.  the current sponsor (Unicamp) is looking at fixing the hardware fault.  hopefully it will be back on monday.
2021-04-30 20:25:28 <Ariadne> if not, i am staging a POWER8 machine i took out of service as a replacement builder. :)
2021-04-30 20:44:26 <Dadrophenia> Sounds good, thanks for the responses!
2021-04-30 21:17:26 <tomleb> Hum, just me or abuild-keygen does not work anymore on edge? I'm getting no output, just exit code 1
2021-04-30 21:48:48 <Ariadne> seems to work for me
2021-04-30 23:02:12 <tomleb> maybe alpine-chroot-install is broken somehow now.. weird
2021-04-30 23:05:13 <tomleb> It's been working fine until today
2021-04-30 23:11:12 <tomleb> This is the faulty commit. I removed `set -e` and it started working again. https://gitlab.alpinelinux.org/alpine/abuild/-/commit/754270e4607d31f7ffed502411e616251cb49460
2021-04-30 23:17:59 <tomleb> Gonna be pushing a fix
2021-04-30 23:27:43 <tomleb> My fix here: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/93