2020-01-01 04:56:45 <north1> phew
2020-01-01 04:56:48 <north1> almost done with telegram-desktop
2020-01-01 04:56:58 <north1> overall, needed a lot of adaptation
2020-01-01 04:57:07 <north1> it sets -Werror unconditionally and also in a way that overrides CMAKE_CXX_FLAGS
2020-01-01 04:57:12 <north1> so that was... annoying
2020-01-01 04:57:29 <north1> ran into 3 different errors due to gcc9, so apparently tdesktop doesn't use gcc9
2020-01-01 11:35:00 <mps> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-ARM-Hardware
2020-01-01 11:35:16 <mps> Linux 5.5 Lands Broadcom BCM2711 / Raspberry Pi 4 Bits
2020-01-01 11:36:26 <mps> someone with RPi4 and kernel build experience could try to build it on alpine
2020-01-01 12:32:13 <artok> might as well do that tomorrow latest
2020-01-01 13:33:18 <nixfloyd_> can someone have a look and eventually merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2652 ?
2020-01-01 13:34:33 <nixfloyd_> same for https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2653 but the pipeline is failing for this one (it does fix the package and makes it actually work, the 2.14.0r0 build is sort of broken)
2020-01-01 18:19:08 <_ikke_> ddevault: any issues with https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2652?
2020-01-01 18:19:44 <ddevault> +1
2020-01-01 18:20:05 <_ikke_> thanks
2020-01-01 20:18:02 <qiu3344> Hi, I recently installed runit on Alpine and I noticed much a faster system statup. Maybe we consider using it as the default?
2020-01-01 20:18:37 <north1> Doubt it, runit doesn't have integration and features OpenRC has like one-shot services and dependency tracking
2020-01-01 20:18:40 <mps> runit as init 1
2020-01-01 20:18:43 <_ikke_> qiu3344: These kind of questions often work better on the mailing list
2020-01-01 20:18:55 <north1> and if you're going to runit might as well take s6 instead
2020-01-01 20:20:16 <mps> we discussed this few times
2020-01-01 20:20:16 <qiu3344> s6 is also an good option. I mean both are faster than openrc
2020-01-01 20:20:35 <_ikke_> there is more to it than just raw speed
2020-01-01 20:20:49 <mps> imo, s6 is not best option for init 1
2020-01-01 20:21:48 <qiu3344> _ikke_: I know, but I don't think that one-shot services are worth the slow boot
2020-01-01 20:21:54 <mps> and as _ikke_ say, speed is not only what should be considered for switch to something else
2020-01-01 20:22:39 <_ikke_> qiu3344: maybe for you it is not, but maybe for others it is
2020-01-01 20:23:03 <_ikke_> and dependency tracking seems pretty important
2020-01-01 20:23:41 <_ikke_> but like I said, these kind of questions are better suited for the mailing list
2020-01-01 20:23:49 <north1> mps (IRC): testing 5.4.7 until now no blocks but i didn't start my games and stuff
2020-01-01 20:23:57 <north1> compiling telegram-desktop which has been a chore
2020-01-01 20:24:41 <_ikke_> I typically just use the webinterface, is there an advantage to the desktop client?
2020-01-01 20:24:45 <north1> the cmake is confusing, should have just used meson
2020-01-01 20:25:28 <north1> _ikke_ (IRC): I didn't use the webinterface in a long time, last time i stopped because it didn't cooperate with my Vimium extension
2020-01-01 20:25:54 <north1> it would grab attention really obnoxiously and i would find myself typing a message instead of navigating the tabs and content
2020-01-01 20:26:34 <mps> north1: also testing 5.4.7, works for now fine though I tested only with some 'heavy' videos
2020-01-01 20:27:51 <_ikke_> north1: I use vimium, and it seems to work just fine with it
2020-01-01 20:28:08 <_ikke_> better than whatsapp
2020-01-01 20:29:23 <north1> yeah but it is not hard to work better than whatsapp that doesn't even allow pressing ESC to unfocus
2020-01-01 20:30:07 <_ikke_> heh
2020-01-01 20:30:14 <_ikke_> that's *so* anoyi
2020-01-01 20:30:17 <_ikke_> anoying
2020-01-01 20:47:51 <kaniini> qiu3344: alpine is not a 'ricer' distribution, who cares if we shave 1 second off boot
2020-01-01 20:48:21 <kaniini> qiu3344: systemd is fast.  should we use systemd?
2020-01-01 20:48:52 <north1> yes :D
2020-01-01 20:48:54 <kaniini> my point here being that the init system choice has more to do with usability than speed
2020-01-01 20:49:14 <kaniini> runit is fast, but openrc is easier for most people to understand
2020-01-01 20:49:18 <_ikke_> agreed. Speed is nice, but should not be the sole factor
2020-01-01 20:49:20 <kaniini> same with s6
2020-01-01 20:50:00 <qiu3344> I wouldn't say that openrc is easier to understand than runit
2020-01-01 20:50:03 <kaniini> this is not to say that we are happy with openrc, there are many things about it that are suboptimal
2020-01-01 20:50:36 <kaniini> qiu3344: openrc matches traditional UNIX way of managing services, basically.  runit and s6 do things differently.
2020-01-01 20:50:47 <kaniini> qiu3344: openrc usage comes down to principle of least surprise
2020-01-01 20:51:24 <kaniini> and, as you note, it is possible to use other init systems with alpine already.
2020-01-01 20:51:48 <north1> if openrc with its pidfile tracking is the least surprise then it is failing
2020-01-01 20:52:09 <kaniini> north1: i mean in terms of CLI
2020-01-01 20:52:34 <kaniini> north1: as i have said many timees over the years, i would like to replace openrc with something else, but the problem is, that something else does not yet exist
2020-01-01 20:52:38 <mps> pmtr? https://troydhanson.github.io/pmtr/
2020-01-01 20:53:26 <qiu3344> yay another init system ;)
2020-01-01 20:53:40 <kaniini> systemd is too complex, upstart is dead and the idea of using an event-driven expert system to manage init is kind of dubious anyway, s6/runit are completely different UX-wise than what we ship now
2020-01-01 20:53:46 <mps> long time ago I built debian router with runit as init 1, but now I wouldn't
2020-01-01 20:54:38 <north1> i'm slowly replacing start-stop-daemon with supervise-daemon on OpenRC
2020-01-01 20:54:52 <north1> so at least we get runit/s6 style supervision, actually daemontools' supervision by djb
2020-01-01 20:54:58 <kaniini> north1: yes, we should really just do a sprint some weekend to get that done
2020-01-01 20:55:30 <mps> north1: should I repeat my disagreement :)
2020-01-01 20:56:10 <north1> mps (IRC): yes, ncopa put limits where i can touch it (busybox daemons)
2020-01-01 20:56:23 <kaniini> but anyway, it is unlikely that an init system that fits our needs (in terms of product) will come along
2020-01-01 20:56:55 <north1> kaniini (IRC): sure
2020-01-01 20:57:23 <kaniini> as for busybox daemons, i think it is ok to move them to supervise-daemon eventually
2020-01-01 20:57:31 <kaniini> but busybox daemons are... somewhat finnicky
2020-01-01 20:58:17 <north1> ncopa was concerned with the ram usage increasing because one supervise-daemon instance is started per-service, i have 5 instances taking 1.0MB (432 Private + 634 Shared)
2020-01-01 20:58:34 <north1> dbus + wpa_cli + wpa_supplicant + low-memory-monitor + dhcpcd
2020-01-01 20:58:55 <kaniini> i think 1MB is reasonable, but maybe we can cut it down a little more
2020-01-01 20:59:49 <kaniini> anyway, new package landing soon: macifrename, which renames NICs based on mac address and optional configuration (default: eth0 = lowest MAC, ethN = highest MAC)
2020-01-01 21:00:56 <kaniini> this is especially useful for broken embedded boards where the NICs are labelled one way but wired another way
2020-01-01 21:01:13 <kaniini> like basically every UBNT device ever
2020-01-01 21:01:15 <AinNero> i have a usecase for this ^
2020-01-01 21:01:22 <AinNero> box with 5 ports
2020-01-01 21:01:23 <mps> kaniini: I would prefer kernel index for interface names
2020-01-01 21:01:27 <AinNero> and shitting ordering
2020-01-01 21:01:31 <kaniini> mps: i can add that as well
2020-01-01 21:02:02 <kaniini> mps: made a note to add it in v0.2
2020-01-01 21:02:42 <mps> thanks, but be careful, sometimes kernel indexing is not 'stable' :)
2020-01-01 21:04:04 <kaniini> anyway, i need to figure out how to make sure macifrename init script runs before networking
2020-01-01 21:04:16 <kaniini> i guess depend() { before net }
2020-01-01 21:04:48 <mps> think so
2020-01-01 21:04:54 <mps> I*
2020-01-01 21:05:29 <_ikke_> ugh, to fix salt on alpine-3.10 I need a package which only exists in 3.11 :(
2020-01-01 21:08:02 <_ikke_> I'll work around it
2020-01-01 21:24:31 <kaniini> _ikke_: just backport it lol
2020-01-01 21:24:58 <_ikke_> fix is easy enough
2020-01-01 21:25:05 <_ikke_> though, less flexible I guess
2020-01-01 21:46:57 <kaniini> ah, now eth0 is eth0 :)
2020-01-01 22:02:54 <kaniini> AinNero: i'll commit it in upstream aports repo this evening :)
2020-01-01 22:13:57 <pedrolucas> is gnu coreutils bad?
2020-01-01 22:15:34 <_ikke_> imho, not necessarily
2020-01-01 22:32:49 <pedrolucas> dunno, been reading a lot of people saying gnu coreutils is bad or bloated/poorly designed
2020-01-01 22:32:54 <pedrolucas> wanna understand why
2020-01-01 22:34:37 <danieli> busybox wasn't chosen because coreutils is 'bad' per se, just that it doesn't align with the project goals
2020-01-01 22:35:28 <_ikke_> mostly because it's a lot smaller / requires less dependencies, so ideal for small embedded systems
2020-01-01 23:03:40 <_ikke_> salt does not support tornado6 for the time being. Would it make sense to have a py3-tornado5 package?
2020-01-01 23:04:12 <_ikke_> It's not a simple patch to support tornado 6 as far as I can see
2020-01-01 23:50:56 <north1> @mps so far so good with 5.4.7, finished suffering with telegram-desktop (for now, it is not done, so more suffering tomorrow after i go to MediaMarkt)
2020-01-01 23:56:40 <mps> north1: heh, ok. you deserve rest. enjoy if like markets :)
2020-01-01 23:56:50 <north1> https://gitlab.alpinelinux.org/Leo/aports/-/jobs/29775 :D
2020-01-02 04:46:08 <nixfloyd_> ddevault: another one: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2661 (this would make the package feature-complete, as far as I can tell)
2020-01-02 04:47:11 <ddevault> left comment
2020-01-02 04:50:46 <nixfloyd_> replied, will push another commit in a bit
2020-01-02 04:51:14 <ddevault> sorry, been kind of distracted today
2020-01-02 04:51:19 <ddevault> could have caught that in the first one
2020-01-02 04:52:52 <nixfloyd_> np :) just pushed the change
2020-01-02 04:53:05 <nixfloyd_> thanks for creating the port in the first place
2020-01-02 07:01:31 <north1> phew
2020-01-02 07:01:36 <north1> finally got telegram-desktop to work
2020-01-02 07:07:27 <north1> @mps 5.4.7 seems to have fixed my issues with hangups
2020-01-02 07:51:30 <north1> https://git.alpinelinux.org/aports/commit/?id=5711a53f69ae53a67391178e57a36b8891a47cc3 https://git.alpinelinux.org/aports/commit/?id=d5448a5817e5ea7bc288cbf897c1368553bc16ab Total of 408 lines removed
2020-01-02 08:56:48 <monado> clandmeter I joined
2020-01-02 08:56:53 <monado> what’s up?
2020-01-02 08:58:47 <clandmeter> monado: this is devel
2020-01-02 08:59:01 <monado> Oh, didn’t read
2020-01-02 09:24:10 <mps> north1: nice, so it is fixed now (I hope). anyone tried 5.4.7 on threadripper (or however it is called)
2020-01-02 09:27:13 <danieli> I'll give alpine a spin on AMD Zen 2 next week when I get the new chip
2020-01-02 09:27:29 <danieli> same architecture as the new threadripper chips
2020-01-02 09:29:36 <north1> @PureTryOut approval on !2660 ?
2020-01-02 09:30:43 <mps> danieli: ok, and np, ncopa didn't pushed it yet anyway
2020-01-02 09:32:11 <mps> just want to log what issues can be closed by upgrade to 5.4.7, there are few opened for kernel 5.4
2020-01-02 09:36:15 <danieli> mps: what was that threadripper issue on gitlab?
2020-01-02 09:36:43 <mps> MCE issue which is fixed in 5.4.7
2020-01-02 09:37:40 <mps> let me look at issues
2020-01-02 09:38:55 <mps> hmm, looks like it is not on issues on GL, but reported over IRC
2020-01-02 09:39:18 <mps> sorry to misleading you
2020-01-02 09:41:31 <PureTryOut[m]> north1: yeah definitely
2020-01-02 09:47:54 <MY-R> north1, good job with telegram!
2020-01-02 09:55:29 <z3ntu> Btw PureTryOut , forgot to CC you for https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2660
2020-01-02 09:55:59 <z3ntu> That fixes launching ktrip on pmOS
2020-01-02 10:55:48 <PureTryOut[m]> Awesome
2020-01-02 11:27:50 <ncopa> north1: im pushing boost 1.72 update
2020-01-02 11:28:00 <ncopa> i managed to build all packages exceot blender
2020-01-02 11:28:12 <north1> Alright
2020-01-02 11:28:16 <ncopa> s/exceot/except/
2020-01-02 11:28:16 <alpine-meetbot> ncopa meant to say: i managed to build all packages except blender
2020-01-02 11:28:18 <north1> I'm not available for action though
2020-01-02 11:28:26 <north1> Currently taking train to Stuttgart
2020-01-02 11:28:31 <ncopa> should not be neccesary
2020-01-02 11:28:38 <ncopa> i think it will all build
2020-01-02 11:28:55 <ncopa> i will ask the blender maintainer to try fix blender
2020-01-02 11:29:11 <ncopa> its in testing so i dont think it matters that much
2020-01-02 13:51:12 <mps> ncopa: do you have some tools when changing kernel configs for more archs/flavors or you do all 'by hand'
2020-01-02 13:53:31 <mps> when I enabled NFT_FIB I did that by hand on all archs I have one by one, abuild unpack prepare ; cd src/build.X ; scripts/config -m $option ; make olddefconfig ; cp .config ../../config-$arch/$flavor
2020-01-02 13:54:13 <mps> a lot of manual works, not hard but could lead to errors if something is overlooked
2020-01-02 14:45:31 <ncopa> mps: i have  a script that runs oldconfig for me for all the arches
2020-01-02 14:45:52 <ncopa> https://tpaste.us/WRdL
2020-01-02 14:51:06 <mps> I see. does it works on one arch or you have to run it on every arch
2020-01-02 14:53:03 <mps> your script is just this what I do manually, and with sugar added
2020-01-02 14:53:36 <mps> will copy it and use next time
2020-01-02 15:15:05 <mps> to not forget to tell, I didn't make upgrade to 5.4.7 for linux-rpi not because I don't care but I can't upload patch to dev.a.o
2020-01-02 15:59:21 <ncopa> np
2020-01-02 16:03:48 <ncopa> weird, libphonenumber fails on builder but builds in my dev env
2020-01-02 16:34:32 <_ikke_> ncopa: lol, whac-a-mole. Now it fails on ppc64le :)
2020-01-02 17:09:14 <kaniini> hi
2020-01-02 17:09:37 <mps> ncopa: should the 5.4.7 be backported to 3.11
2020-01-02 17:09:54 <kaniini> is 5.4.7 in already?
2020-01-02 17:10:01 <kaniini> if so, i need to rebase my mips64 crimes
2020-01-02 17:10:09 <mps> in edge, yes
2020-01-02 17:10:32 <kaniini> i need to figure out what i am doing with the kernel packaging, it's like the only thing not upstream at this point
2020-01-02 17:11:03 <mps> mips64 ?
2020-01-02 17:11:08 <kaniini> yes
2020-01-02 17:11:29 <kaniini> a more formal announcement later :)
2020-01-02 17:11:53 <mps> ah, nice :)
2020-01-02 17:13:00 <kaniini> we are still working on some of the legwork of doing the port
2020-01-02 17:15:39 <kaniini> however, it is our goal to support the alpine ecosystem in a way it has not been supported previously
2020-01-02 17:20:52 <clandmeter> kaniini: ok ill quit my job
2020-01-02 17:21:09 <clandmeter> :)
2020-01-02 17:22:25 <vkrishn> hi, what would be gitlab url for http://bugs.alpinelinux.org/ ?
2020-01-02 17:23:03 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/issues
2020-01-02 17:23:18 <vkrishn> thanks
2020-01-02 17:30:06 <ollieparanoid[m]> some qt library depending on so:libboost_thread.so.1.71.0 needs to be bumped, because boost was upgraded. I can't find out the exact pkgname right now, maybe somebody wants to look into it?
2020-01-02 17:37:34 <vkrishn> alpine packages lmdb, any thoughts on having it enabled in php7, https://www.php.net/manual/en/dba.installation.php
2020-01-02 17:37:45 <vkrishn> its been available since PHP 7.2.0
2020-01-02 17:38:33 <Cogitri> ollieparanoid[m]: I think the builders are still going, so it might just take a little until the conflict is resolved
2020-01-02 17:39:27 <vkrishn> no one cares about irc logs anymore :( ?
2020-01-02 17:39:41 <mps> uhm, forgot to set CONFIG_UEVENT_HELPER_PATH for armv7
2020-01-02 17:39:48 <mps> 
ACTION hides

2020-01-02 17:40:05 <vkrishn> alpine-linux been not logged for over a month now
2020-01-02 17:41:13 <mps> vkrishn: I mentioned this this morning on infra, and also few days ago
2020-01-02 17:42:24 <vkrishn> it happened before, previous issue was writable directory (permission) related
2020-01-02 17:42:58 <_ikke_> But in this case it's just one channel
2020-01-02 17:43:18 <vkrishn> yes, same issue, only alpine-linux
2020-01-02 17:43:34 <vkrishn> cannot recal, maybe 2-3yrs back
2020-01-02 17:45:19 <vkrishn> any idea what does /usr/lib/preloadable_libiconv.so do in pkg, gnu-libiconv ?
2020-01-02 17:45:40 <vkrishn> do I need to enable it to use iconv in php7 ?
2020-01-02 17:45:50 <kaniini> you LD_PRELOAD it and it replaces musl iconv with GNU libiconv
2020-01-02 17:48:41 <vkrishn> LD_PRELOAD in docker, norwal web-install or cli ?
2020-01-02 17:49:03 <vkrishn> normal*
2020-01-02 17:52:46 <vkrishn> was trying to install, nette, https://doc.nette.org/en/3.0/requirements, checker shows iconv issue
2020-01-02 17:54:52 <vkrishn> works in cli, with LD_PRELOAD
2020-01-02 17:58:14 <vkrishn> oh, tpaste.us not working
2020-01-02 17:58:31 <vkrishn> working now
2020-01-02 17:59:01 <vkrishn> testing iconv in cli http://tpaste.us/gkXr
2020-01-02 18:00:07 <AinNero> vkrishn: wait
2020-01-02 18:00:34 <vkrishn> ok
2020-01-02 18:00:52 <AinNero> could you paste the checker output?
2020-01-02 18:01:06 <AinNero> just want to make sure its not that the php extension is just not enabled
2020-01-02 18:02:13 <vkrishn> before, http://tpaste.us/evrW
2020-01-02 18:02:18 <AinNero> usually, php has different *.ini files depending on the SAPI
2020-01-02 18:02:48 <vkrishn> after, http://tpaste.us/kyr4
2020-01-02 18:04:21 <AinNero> yes, seems like LD_PRELOAD is the right way
2020-01-02 18:10:30 <vkrishn> ICONV_IMPL can be unknown, right ?
2020-01-02 18:11:10 <vkrishn> or should be patched to show musl or libiconv ?
2020-01-02 18:11:37 <AinNero> dont know if nette needs it
2020-01-02 18:12:25 <vkrishn> https://github.com/nette/sandbox/pull/98
2020-01-02 18:16:05 <vkrishn> test-iconv.php is working without pkg gnu-libiconv installed
2020-01-02 18:16:15 <vkrishn> kinda confused
2020-01-02 18:16:43 <_ikke_> vkrishn: logs are created again
2020-01-02 18:17:16 <vkrishn> thanks
2020-01-02 18:17:38 <vkrishn> test-iconv.php is working without pkg gnu-libiconv installed in web install ^
2020-01-02 18:17:44 <_ikke_> apparently just a restart was enough
2020-01-02 18:17:45 <vkrishn> but cli needs it
2020-01-02 18:17:50 <vkrishn> ah, ok
2020-01-02 18:20:37 <vkrishn> improved the test file for both web/cli http://tpaste.us/ObEm
2020-01-02 18:23:31 <vkrishn> cannot test in docker yet
2020-01-02 18:28:40 <vkrishn> not an issue in nette only, https://github.com/lorisleiva/laravel-docker/pull/30
2020-01-02 19:11:21 <vkrishn> improved the test file, http://tpaste.us/wno5
2020-01-02 19:12:13 <vkrishn> is there a place where these tests can be organized, maybe, https://gitlab.alpinelinux.org/alpine/aports/snippets ?
2020-01-02 19:30:34 <vkrishn> seems an issue in php7-opcache, http://tpaste.us/JxKv
2020-01-02 19:31:15 <vkrishn> would try to change order in ini files
2020-01-02 19:38:18 <vkrishn> current default ordering prefix in /etc/php7/conf.d/ is 00_, suggestion, to set base at 20_
2020-01-02 20:04:27 <artok> ncopa: you had now rpi4 ?
2020-01-02 20:31:54 <clandmeter> artok: i think he does
2020-01-02 20:34:15 <mps> artok: yes, he told he got one
2020-01-02 20:34:31 <mps> and I borrowed rpi zero w
2020-01-02 20:34:57 <mps> we tested 3.11.2 on these two before release
2020-01-02 20:38:08 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2684
2020-01-02 20:39:10 <_ikke_> Fix salt by having a dedicated tornado5 package
2020-01-02 20:49:37 <vkrishn> same issue with ini ordering, http://tpaste.us/JxKv <- php7-opcache
2020-01-02 20:49:49 <vkrishn> re-ordering*
2020-01-02 20:59:35 <artok> well my rpi4 doesn't boot with the installer
2020-01-02 20:59:47 <artok> need to move boot/* to root folder of the sd as before
2020-01-02 21:05:50 <ddevault> iggy: https://gitlab.alpinelinux.org/alpine/aports/issues/11102
2020-01-02 21:08:44 <mps> artok: 3.11.2 tarball?
2020-01-02 21:12:36 <artok> yah
2020-01-02 21:13:35 <mps>  armv7 or aarch64 tarball?
2020-01-02 21:13:59 <artok> aarch64
2020-01-02 21:14:27 <mps> hm
2020-01-02 21:14:38 <artok> as the bootloader is on rpi4 memory
2020-01-02 21:15:23 <mps> we can n_copa tomorrow how he booted it
2020-01-02 21:15:24 <artok> might be that it has something different from the .bin that runs rpi3.. I'll check the rpi3 soon
2020-01-02 21:16:44 <mps> btw, I built u-boot for zero w, and can select different kernels from boot menu
2020-01-02 21:18:18 <mps> hmm, looking in http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/aarch64/alpine-rpi-3.11.2-aarch64.tar.gz all dtbs and other files are in proper places
2020-01-02 21:19:22 <vkrishn> AinNero: https://pasteboard.co/IO9KQyS.png <- checker from nette install
2020-01-02 21:20:43 <artok> dtbs and so on are, but initramfs and kernel are under boot/
2020-01-02 21:21:11 <artok> my pi4 doesn't boot until i move them to root and edit config.txt
2020-01-02 21:21:24 <mps> they should there, did you looked in config.txt
2020-01-02 21:21:41 <mps> be there*
2020-01-02 21:21:49 <AinNero> vkrishn: this looks expected as with musl iconv
2020-01-02 21:22:00 <AinNero> i dont think i can tell you more than you already know yourself
2020-01-02 21:22:23 <artok> config.txt s/boot\///
2020-01-02 21:22:41 <artok> removing subdirectory from there, and it works
2020-01-02 21:23:47 <mps> in my case it works without touching config.txt
2020-01-02 21:24:15 <artok> which bootloader it has?
2020-01-02 21:24:20 <vkrishn> AinNero: ok, would try to install in apache+php(normal, not fpm), see if that works
2020-01-02 21:24:48 <artok> from https://www.raspberrypi.org/downloads/ recovery to sd for update
2020-01-02 21:28:00 <mps> hm, strange, n_copa confirmed that it works on rpi4
2020-01-02 21:31:16 <artok> indeed
2020-01-02 21:31:35 <artok> hence the question, would it be older bootloader
2020-01-02 21:31:51 <artok> which runs hotter
2020-01-02 21:32:17 <artok> without cooling, it will start throttling fast
2020-01-02 21:32:39 <mps> also ncopa told that is hot
2020-01-02 21:32:51 <mps> it is hot*
2020-01-02 21:33:25 <artok> without fans, even that heatsink is really hot
2020-01-02 21:33:26 <mps> rpi zero is not too much hot
2020-01-02 21:34:29 <mps> btw, if you missed, rpi4 is merged in 5.5 kernel
2020-01-02 21:34:44 <artok> actually I did one build for 5.5
2020-01-02 21:35:31 <mps> heh, nice
2020-01-02 21:36:22 <artok> just haven't installed it, but seems that it has correct dtb, dts files
2020-01-02 21:37:40 <artok> no overlays dir, though
2020-01-02 21:44:01 <ddevault> iggy: another: https://gitlab.alpinelinux.org/alpine/aports/issues/11103
2020-01-02 23:03:45 <ddevault> iggy: https://gitlab.alpinelinux.org/alpine/aports/issues/11104
2020-01-02 23:03:56 <ddevault> iggy: (I intend to write some patches once I'm done flushing out all of the issues)
2020-01-02 23:08:02 <micro4lpha> Hey guys
2020-01-02 23:08:14 <micro4lpha> I'm trying to build an alpine nginx with a custom website/config
2020-01-02 23:09:38 <micro4lpha> should I do a Dockerfile with docker pull amd64/alpine, going on EC2 ECS AMI
2020-01-02 23:10:12 <clandmeter> micro4lpha: this is not a support channel
2020-01-02 23:10:18 <clandmeter> try #alpine-linux
2020-01-02 23:14:14 <micro4lpha> right, sorry
2020-01-02 23:36:48 <ollieparanoid[m]> Cogitri: thanks, you were right - it's resolved now :)
2020-01-03 08:24:11 <leo_> @ncopa ping
2020-01-03 08:24:28 <leo_> can you check on https://github.com/alpinelinux/aports/pull/12189 ?
2020-01-03 08:28:39 <ncopa> hi
2020-01-03 08:29:28 <leo_> hey :D
2020-01-03 08:29:42 <clandmeter> looks like jason didnt read the pr template
2020-01-03 08:29:59 <leo_> i wouldn't either since i create PRs and MRs from the commandline
2020-01-03 08:30:12 <clandmeter> im adding a note for him
2020-01-03 08:30:51 <leo_> wouldn't it be better to have the github bot tell users who make new PRs to make MRs ?
2020-01-03 08:31:16 <clandmeter> we can do that  also
2020-01-03 08:31:23 <clandmeter> this was the idea
2020-01-03 08:47:34 <zenny> Reporting here, too besides alpine-linux channel as if it looks like a bug: "Good morning, I am trying lxc in alpine 3.11.2 (ref. https://wiki.alpinelinux.org/wiki/LXC), but there are two issues. Even after installing lxc-templates package, it reports that alpine template is not available (lxc-create: alpine: lxccontainer.c: do_lxcapi_create: 1817 Unknown template "alpine"). Second, when I tried to use the dummy kernel module inside /
2020-01-03 08:49:12 <mps> apk add lxc-templates-legacy-alpine ?
2020-01-03 09:02:54 <zenny> mps: tried, that gives the lxc template, yet lxc fumes out a bunch of errors: " cgroup - cgroups/cgroup.c:cgroup_init:54 - Failed to initialize cgroup driver" despite "cgroup_enable=memory swapaccount=1" appended to /boot/extlinux.conf and rebooted.
2020-01-03 09:03:33 <mps> hm, /etc/init.d/cgroups start ?
2020-01-03 09:29:11 <zenny> mps: yep and tahnks, that did the trick, yet the dummy module fails to load on boot, despite /etc/moprobe.d/dummy.conf has 'dummy' enabled!
2020-01-03 09:31:32 <mps> zenny: I'm not sure you can load modules in lxc without some 'fine' tweaks
2020-01-03 09:32:36 <mps> and, on host do 'rc-update add cgroups' to be ready when you reboot host
2020-01-03 09:33:35 <zenny> mps: I am not trying inside lxc container, but to the host alpine kernel itself to create a dummy0 port to br0 (https://wiki.alpinelinux.org/wiki/LXC#Creating_a_LXC_container_without_modifying_your_network_interfaces)
2020-01-03 09:34:03 <mps> ah, then add it in /etc/modules
2020-01-03 09:35:07 <mps> /etc/moprobe.d/*.conf is for configuring modules and not for load
2020-01-03 09:36:13 <mps> or in '/etc/modules-load.d/*.conf' instead of '/etc/modules' (though I prefer later)
2020-01-03 10:02:00 <zenny> mps: Thanks, but I am stuck with the connection to internet from lxc container after following this (https://wiki.alpinelinux.org/wiki/LXC#Creating_a_LXC_container_without_modifying_your_network_interfaces)! Any clue?
2020-01-03 10:06:41 <clandmeter> ah we have aarch64 iso's now. nice
2020-01-03 10:07:27 <mps> zenny: please ask this on #alpine-linux, this channel is for development
2020-01-03 10:08:02 <mps> clandmeter: you didn't noticed it earlier :) iirc it is made on your request
2020-01-03 10:08:33 <clandmeter> cant catch all things here :)
2020-01-03 10:08:48 <clandmeter> it was on my todo
2020-01-03 10:08:53 <clandmeter> somewhere deep down
2020-01-03 10:09:04 <clandmeter> but somebody beat me to it, i guess it was ncopa
2020-01-03 10:09:10 <mps> yes
2020-01-03 10:09:50 <zenny> mps: Thanks, done as suggested. However, the alpine-linux channel appears to be sleeping though with 370 users online. :-)
2020-01-03 10:11:35 <mps> wait some time till they wake up :)
2020-01-03 10:12:38 <mps> and finish coffee, breakfast etc...
2020-01-03 11:23:46 <PureTryOut[m]> The x86_64 Gitlab runner seems to be down
2020-01-03 11:25:55 <_ikke_> let me check
2020-01-03 12:21:31 <PureTryOut[m]> Is there anything preventing https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2230 from being merged?
2020-01-03 12:22:16 <mps> !2230
2020-01-03 12:31:04 <Cogitri> I'll go through it this evening and merge then
2020-01-03 12:31:20 <Cogitri> Kind of busy due to exams right now, sorry about the merge conflicts
2020-01-03 13:44:42 <PureTryOut[m]> Cogitri: I want to upstream Phosh and Phoc to Alpine, are you fine with me setting you as the maintainer?
2020-01-03 13:48:46 <Cogitri> Sure :)
2020-01-03 14:01:03 <PureTryOut[m]> How are Rust packages packaged so far? Are all Cargo deps just downloaded and compiled in statically?
2020-01-03 14:05:41 <_ikke_> yes
2020-01-03 14:07:28 <PureTryOut[m]> Hmm ok, hopefully that changes in the future then
2020-01-03 14:08:32 <_ikke_> Would require someone willing to take up the challenge to start packaging all the dependencies
2020-01-03 14:08:56 <_ikke_> And then there is the question of depenency conflicts
2020-01-03 14:09:03 <PureTryOut[m]> Well I don't mind doing some, if I had an example on how to compile Rust stuff dynamically rather than statically
2020-01-03 14:09:16 <_ikke_> that's the other part of the challenge
2020-01-03 14:12:08 <z3ntu> I just know that Arch Linux packages some Go libraries properly, e.g. https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/golang-github-ruudk-golang-pdf417 but that doesn't help much with Rust unfortunately
2020-01-03 14:12:26 <_ikke_> z3ntu: at least nice to know how to do it fr go
2020-01-03 14:12:28 <_ikke_> for
2020-01-03 14:13:10 <mps> anyone have issue with download patches from GL.a.o
2020-01-03 14:13:25 <mps> curl https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1582.patch
2020-01-03 14:13:34 <mps> doesn't work for me
2020-01-03 14:13:40 <_ikke_> for me neither
2020-01-03 14:14:03 <_ikke_> 200 with nothing returned
2020-01-03 14:14:10 <mps> same here
2020-01-03 14:14:13 <_ikke_> I think that happens for certain patches
2020-01-03 14:14:35 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1582/diffs -> no preview for this filetype
2020-01-03 14:14:43 <_ikke_> Not sure why that happens
2020-01-03 14:14:44 <z3ntu> Fedora seems to package Rust libraries nicely from what I can tell - https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/
2020-01-03 14:15:33 <mps> _ikke_: could be because fail on CI
2020-01-03 14:15:42 <mps> hmm , no
2020-01-03 14:15:52 <_ikke_> no, very unlikely
2020-01-03 14:15:53 <mps> I downloaded some which failed
2020-01-03 14:16:01 <_ikke_> You can still fetch the branch
2020-01-03 14:16:07 <_ikke_> but the diff is somehow empty
2020-01-03 14:16:30 <_ikke_> maybe because it detects a binary somehow?
2020-01-03 14:20:12 <mps> have no idea
2020-01-03 14:39:50 <Cogitri> z3ntu: Fedora only packages the sources
2020-01-03 14:40:00 <Cogitri> As such you still statically the entire thing together
2020-01-03 14:40:09 <Cogitri> You just don't download it again every time
2020-01-03 14:40:52 <Cogitri> Which is nice and all but since Rust devs don't need to upgrade deps too quickly due to Cargo doing everything for them it's a massive, massive pain with loads of packages duplicate just with different versions
2020-01-03 14:41:40 <Cogitri> You can't really do dynamic linking with Rust for that reason too, devs don't upgrade in a timely manner since statically linking everything works for them and the ABI isn't stable so you'll need to recompile everything with every rustc re-release
2020-01-03 14:42:07 <Cogitri> And rebuilding some 200-350 deps per Rust application isn't fun
2020-01-03 14:42:23 <z3ntu> hmm
2020-01-03 14:42:58 <z3ntu> The golang-* packages in Arch Linux are also just packaged source files
2020-01-03 14:43:00 <mps> ( maybe D will supersede rust )
2020-01-03 14:43:38 <z3ntu> I doubt that
2020-01-03 14:43:43 <mps> sorry for OT comment
2020-01-03 14:47:27 <Cogitri> I doubt it too, although I do very much like D right now :)
2020-01-03 14:47:37 <Cogitri> They have different applications tho
2020-01-03 14:47:53 <Cogitri> I don't really see the worth of packaging the source files other than generating work :)
2020-01-03 14:53:17 <PureTryOut[m]> 
ACTION wonders when Rust will get a stable ABI

2020-01-03 14:54:42 <AinNero> PureTryOut[m]: lemme guess, never
2020-01-03 14:55:02 <PureTryOut[m]> Let's hope that's incorrect
2020-01-03 14:55:29 <AinNero> i can't think of much that got better in terms of interface stability
2020-01-03 15:17:10 <Cogitri> The trend towards language package managers being a necessity certainly is a bit worrying
2020-01-03 16:00:26 <ddevault> alpine's postgresql package is nice, nice work jakub
2020-01-03 16:00:39 <ddevault> psql version upgrades make my blood run cold
2020-01-03 16:25:51 <ncopa> ddevault: im not sure he reads IRC, maybe send him a thanks-email or on twitter
2020-01-03 16:26:28 <ddevault> few communities agree less than Alpine about how to work together, yet somehow manage to anyway
2020-01-03 16:27:18 <ncopa> i think we could add a postgresql-update subpackage, with a build of the binaries of previous release, to make upgrades
2020-01-03 16:27:24 <ncopa> similar to what fedora does
2020-01-03 16:28:02 <ncopa> heh, yeah, its amazing that we manage work together despite the different opinions :)
2020-01-03 16:28:47 <mps> having different opinions are good, not bad
2020-01-03 16:29:01 <ncopa> +1
2020-01-03 16:29:55 <mps> only important (imo) to not be personally agreesive
2020-01-03 16:30:02 <ncopa> the challenge is when opinions on *how* to work together is that different, but still manage to work somehow , as ddevault pointed out
2020-01-03 16:30:46 <mps> 'calm down, and wait some time'
2020-01-03 16:31:26 <ddevault> ncopa: I prefer the approach that doesn't use the old release binaries
2020-01-03 16:31:38 <ddevault> pgdumpall is a more elegant and failure resistant solution imo
2020-01-03 16:32:06 <mps> pgdumpall is safest, ime
2020-01-03 16:32:37 <ddevault> pg upgrades are an absolute nightmare and the current system on alpine is the one that makes me lose the least sleep
2020-01-03 16:32:41 <ddevault> let's not emulate anyone else
2020-01-03 16:33:44 <mps> also, i don't dare to use pg_upgrade on production servers
2020-01-03 16:34:35 <ddevault> my current strategy is to set up a secondary machine which resembles the prod SQL server, dump the database onto it, do a dry run of the upgrade, then validate everything works correctly, before destroying it and repeating the process with prod
2020-01-03 16:35:15 <mps> maybe first step is to make different major versions coinstallable and after that see what could be good next step
2020-01-03 16:36:12 <ncopa> dump/restore is the safest, indeed
2020-01-03 16:36:53 <ncopa> i was thinking having a pg_upgrade as an option for those who dare :)
2020-01-03 16:38:20 <mps> if two version runs on different ports on same machine, something like 'pg_dumpall ... | psql -p $diffport' could work, though not tried in production
2020-01-03 16:42:35 <mps> though did that on backup server over network
2020-01-03 16:45:12 <mps> problem with pg_dumpall is that it will only dump data which exist when it started and not data updated/inserted during its run, what could be issue for big DB
2020-01-03 16:46:38 <ddevault> I shut off the server during upgrades
2020-01-03 16:46:41 <ddevault> you can't get around the downtime anyway
2020-01-03 16:46:50 <ddevault> the server process*
2020-01-03 16:47:27 <ddevault> in theory you could set up something with streaming replication and a bunch of pgbouncers to maybe get no read-only downtime
2020-01-03 16:47:29 <mps> also I do, but there are people who need 'small' downtime
2020-01-03 16:47:42 <ddevault> but honestly that feels fragile as fuck when I've tried it
2020-01-03 16:48:10 <ddevault> I've been meaning to sit down one of these days, replicate the prod database to localhost, and experiment with a bunch of different replication strategies and upgrade paths
2020-01-03 16:48:16 <mps> afaik, streaming replication works only with same major version
2020-01-03 16:48:22 <ddevault> err, I meant logical replication
2020-01-03 16:48:28 <ddevault> I use streaming replication today
2020-01-03 16:48:47 <ddevault> and when I researched logical replication, I felt totally uncomfortable relying on it for production use
2020-01-03 16:49:13 <mps> also I use streaming replication but as hot-standby option, for high availablity
2020-01-03 16:51:00 <ddevault> have you ever successfully cut over to the standby?
2020-01-03 16:51:20 <ddevault> I feel like it makes sense in theory but is difficult to do right in practice
2020-01-03 16:51:27 <ddevault> esp without risking some data loss
2020-01-03 16:51:35 <mps> you mean, change a role of servers?
2020-01-03 16:51:39 <ddevault> aye
2020-01-03 16:51:56 <mps> yes, and a lot of times
2020-01-03 16:52:17 <ddevault> fair enough
2020-01-03 16:52:33 <mps> maybe exaggerate, but not rarely
2020-01-03 16:53:34 <mps> when master fails for whatever reason, switch to slave works fine, except maybe few lost row updates
2020-01-03 16:54:07 <mps> and in such situations it is hard to find if something is lost
2020-01-03 17:41:40 <mps> ncopa: I forgot to ask you, last night artok reported issue with booting RPi4 with aarch64 tarball 3.11.2
2020-01-03 17:42:01 <mps> iirc, you tested it on your board?
2020-01-03 17:42:31 <ncopa> url?
2020-01-03 17:42:56 <ncopa> i tested to boot aarch64 on my rpi4
2020-01-03 17:42:59 <ncopa> (i think)
2020-01-03 17:43:25 <mps> he asked here, I think, or #alpine-linux
2020-01-03 17:43:59 <ncopa> let me check it again
2020-01-03 17:44:38 <mps> chat log begins at 2020-01-02 21:04
2020-01-03 17:44:44 <mps> CET
2020-01-03 17:44:49 <_ikke_> Yes
2020-01-03 17:44:53 <_ikke_> some kind of issue with algitbot
2020-01-03 17:44:58 <_ikke_> I restarted it and then it started working again
2020-01-03 17:45:25 <mps> 2020-01-02 21:59........... artok| well my rpi4 doesn't boot with the installer
2020-01-03 17:45:38 <mps> 2020-01-02 21:59........... artok| need to move boot/* to root folder of the sd as before
2020-01-03 17:45:59 <mps> sorry for not using tpaste
2020-01-03 17:46:30 <_ikke_> 2 lines is acceptible :D
2020-01-03 17:47:22 <mps> I don't have tpaste client installed on my irssi remote box
2020-01-03 17:47:45 <_ikke_>  | curl tpaste.us -F tpaste=\<-
2020-01-03 17:49:09 <mps> I have this as shell script somewhere
2020-01-03 17:52:04 <ncopa> it boots for me
2020-01-03 17:52:24 <ncopa> ah
2020-01-03 17:52:26 <ncopa> the installer
2020-01-03 17:52:31 <mps> thanks for confirmation
2020-01-03 17:53:48 <ncopa> it is quite possible that the installer (sys install) does not work out of the box
2020-01-03 17:54:52 <ncopa> i guess thats something that could be fixed
2020-01-03 17:55:00 <ncopa> not sure how we want it to work though
2020-01-03 17:55:52 <ncopa> we actually only support the "diskless" install on rpi
2020-01-03 17:56:11 <mps> he told he can't boot, had to move files to / and edit config.txt
2020-01-03 17:56:27 <ncopa> yeah
2020-01-03 17:56:41 <ncopa> the setup-disk script is not tested with rpi
2020-01-03 17:56:44 <mps> look here https://dev.alpinelinux.org/irclogs/%23alpine-devel-2020-01.log 2020-01-02 20:04:27
2020-01-03 17:57:42 <mps> setup-disk never worked for me on any arm
2020-01-03 17:58:08 <mps> it doesn't handle mmcblk disks
2020-01-03 17:58:37 <mps> doesn't recognize them as possible install targets
2020-01-03 18:00:08 <_ikke_> ncopa: do you think we might support that in the future?
2020-01-03 18:01:37 <ncopa> yes, why not
2020-01-03 18:01:42 <ncopa> but hum
2020-01-03 18:01:50 <ncopa> i'd like to rewrite setup-disk script
2020-01-03 18:01:55 <ncopa> in lua or something
2020-01-03 18:02:08 <ncopa> i'd like rewrite all the setup scripts in lua
2020-01-03 18:02:21 <ncopa> with linenoise and tab-autocomplete and stuff
2020-01-03 18:02:30 <_ikke_> linenoise?
2020-01-03 18:02:47 <north1> as far as i am aware
2020-01-03 18:02:47 <mps> I looked at it about year ago and thought to add mmcblk but my shell scripting knowledge is not enough
2020-01-03 18:02:51 <ncopa> editline replacement
2020-01-03 18:02:53 <north1> minimal replacement for GNU readline
2020-01-03 18:02:56 <_ikke_> right
2020-01-03 18:03:02 <ncopa> yeah
2020-01-03 18:03:21 <ncopa> and i want be able to go backwards in the installer too
2020-01-03 18:03:33 <_ikke_> right, like a real wizzard
2020-01-03 18:03:35 <ncopa> maybe by pressing esc or similar
2020-01-03 18:03:36 <ncopa> yeah
2020-01-03 18:03:52 <ncopa> and it should take a cloud-init config as input too
2020-01-03 18:03:52 <_ikke_> so first stage is gathering information, and then apply it at the end
2020-01-03 18:04:03 <ncopa> yeah
2020-01-03 18:04:16 <_ikke_> makes unattended installs easy as well
2020-01-03 18:04:17 <ncopa> well, maybe it needs to configure language setting and network early
2020-01-03 18:04:44 <_ikke_> for mirror selection \
2020-01-03 18:05:05 <ncopa> and maybe we should have defaults for everything, so we could have a '--default' option or similar
2020-01-03 18:05:11 <ncopa> similar to --quick
2020-01-03 18:05:33 <ncopa> I'd also like to be able to provide an ssh pub key somehow
2020-01-03 18:05:57 <ncopa> and if you do, it will install sshd and give root login
2020-01-03 18:06:10 <_ikke_> yeah, makes sense
2020-01-03 18:14:05 <AinNero> did i get it correctly, cloud-init is on the official wishlist now?
2020-01-03 18:14:52 <_ikke_> AinNero: seems so
2020-01-03 18:15:20 <ncopa> im open to better alternatives
2020-01-03 18:15:34 <AinNero> i was experienting around with automatically provisioning alpine machines with hetzner, but didn't find an reliable way
2020-01-03 18:15:43 <ncopa> the idea is to use a commnly used config format
2020-01-03 18:15:46 <AinNero> they had support for cloud-init tho
2020-01-03 18:15:56 <ncopa> and i though cloud-init was a defacto standard
2020-01-03 18:16:11 <AinNero> if we get cloud-init support, we could provide hetzner with a base image
2020-01-03 18:16:37 <AinNero> this is surely in the interest of people that pay me
2020-01-03 18:23:21 <mps> AinNero: do you work for hetzner
2020-01-03 18:23:42 <AinNero> no
2020-01-03 18:26:39 <AinNero> hetzner customer tho
2020-01-03 18:28:26 <AinNero> for those people trying to connect the bits, i work for several companies
2020-01-03 18:29:40 <AinNero> but all of them don't want to do manual setup of machines over and over again
2020-01-03 18:35:21 <mps> I looked their site and wanted to create one test instance but docs are not clear
2020-01-03 18:42:25 <AinNero> the cloud UI is slow and laggy, and the cli interface is a buggy go blob
2020-01-03 18:42:31 <AinNero> but it works if you hit it with a wrench
2020-01-03 18:46:37 <mps> I prefer cli, actually most prefer ssh console
2020-01-03 18:47:04 <mps> linode ssh console is good
2020-01-03 18:57:29 <ddevault> I still provision my hosts manually, but I have a checklist
2020-01-03 18:57:47 <ddevault> I generally run through setup-alpine through the virt-manager spice console, then SSH in and run through my checklist from there
2020-01-03 18:58:15 <ddevault> similar process for new physical hosts, I do the bare minimum to be able to SSH in securely, then run the rest of the checklist when I get home from the DC
2020-01-03 20:11:37 <_ikke_> north1: wofi failed due to checksum mismatch
2020-01-03 20:12:05 <north1> Damm
2020-01-03 20:12:20 <north1> I guess they are autogenerated
2020-01-03 20:12:50 <_ikke_> ddevault: seems to come from sourcehut
2020-01-03 20:13:02 <_ikke_> ddevault: should the archives be stable?
2020-01-03 20:13:15 <_ikke_> https://hg.sr.ht/~scoopta/wofi/archive/v1.0.tar.gz
2020-01-03 20:40:38 <ddevault> I'm not sure about hg.sr.ht, _ikke_
2020-01-03 23:31:31 <north1> i disabled wofi for the time
2020-01-03 23:32:03 <_ikke_> thanks
2020-01-03 23:43:26 <north1> Got another lockup with intel
2020-01-03 23:43:35 <north1> on the bright side it took a few days rather than hours
2020-01-04 00:10:00 <PureTryOut[m]> Could someone review https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2125?
2020-01-04 00:13:29 <north1> I can merge if someone give the ok
2020-01-04 00:18:54 <mps> north1: re lock on i915, we leave on the _edge_ :)
2020-01-04 00:46:34 <clandmeter> mps: when you leave on the edge you are longer on it ;-)
2020-01-04 07:21:29 <mps> clandmeter: heh, writing in foreign language just before going to bed is error prone
2020-01-04 07:21:50 <mps> s/leave/live/
2020-01-04 07:21:50 <alpine-meetbot> mps meant to say: north1: re lock on i915, we live on the _edge_ :)
2020-01-04 10:50:11 <mps> rofi-pass on s390x fails with: rofi (missing): required by: .makedepends-rofi-pass-20200104.104839[rofi]
2020-01-04 10:50:36 <mps> so, rofi-pass should be disabled
2020-01-04 10:51:57 <mps> oh, rofi have 'arch=""'
2020-01-04 10:54:14 <PureTryOut[m]> Cogitri: why does gnome-shell depend on ibus? Seems you've put it in there manually
2020-01-04 10:56:46 <Cogitri> It needs it to start IIRC
2020-01-04 10:57:36 <mps> !2125
2020-01-04 10:57:37 <Cogitri> Pretty sure it needs the gtk3 im module
2020-01-04 10:58:10 <mps> what is 'hyperbola'
2020-01-04 11:00:25 <north1> Linux distro
2020-01-04 11:00:44 <paper_> BSD distro in future
2020-01-04 11:02:50 <mps> :)
2020-01-04 11:02:57 <mps> thanks, will look
2020-01-04 11:08:58 <mps> if they use musl I could be interested
2020-01-04 11:15:15 <paper_> I don't think musl is on BSD
2020-01-04 11:16:43 <mps> I know. Their mistake :)
2020-01-04 11:26:03 <PureTryOut[m]> <Cogitri "It needs it to start IIRC"> Hmm ok. I'm wondering since it's desktop entry appears in Phosh (which depends on gnome-shell), but doesn't on the PureOS images. It looks a bit ugly 😉
2020-01-04 11:39:33 <Cogitri> Hm, even so having ibus installed probably isn't a bad idea to have support for languages that don't use European/American (ISO?) keyboards (e.g. Chinese/Japanese)
2020-01-04 11:46:04 <PureTryOut[m]> Well it isn't much of a problem, and I personally don't even use Phosh so it's fine
2020-01-04 11:48:36 <mps> isn't (unwritten) alpine policy minimal dependencies
2020-01-04 12:26:30 <Cogitri> mps: Minimal dependencies while retaining a functional package
2020-01-04 12:26:53 <Cogitri> And tbh if you're installing GNOME I don't think you're onto the super minimal train
2020-01-04 12:30:56 <mps> functional package is broad definition
2020-01-04 12:32:27 <mps> s390x builder segfaulted building testing/gcc-cross-embedded
2020-01-04 14:52:54 <mps> ncopa: if you are reading msgs, last night user ajar on #alpine-linux reported that the aarch64 3.11.2 boot 'out of the box' on rpi4
2020-01-04 14:54:05 <mps> (writing now because I will probably forgot on monday :) )
2020-01-04 15:05:44 <artok> which bootloader ? =)
2020-01-04 15:08:05 <mps> artok: didn't asked, he told something like 'out of the box'
2020-01-04 15:15:07 <artok> time to do rpi-eeprom alpine package
2020-01-04 15:15:08 <artok> =)
2020-01-04 15:16:47 <mps> I read that the rpi4 doesn't use GPU (or it is VPU) to start bootloader, like older models
2020-01-04 15:18:00 <artok> yeah
2020-01-04 15:18:48 <mps> does that mean it can use efi boot loader
2020-01-04 15:20:12 <mps> afaik, all arm64 should have option to use efi
2020-01-04 15:21:16 <artok> there is experimental uefi stuff..
2020-01-04 16:20:00 <Cogitri> Just to make sure: ttf-cantarell has `install_if="gnome-shell"`, isn't that the same as if gnome-shell depended on it?
2020-01-04 16:40:26 <mps> something like this, it will be installed if the gnome-shell installed
2020-01-04 16:41:44 <Cogitri> Yup, so it's equivalent, isn't it?
2020-01-04 16:42:31 <mps> not sure, but I think gnome-shell has no 'strong' deps on it, i.e. if it doesn't exist gnome-shell can be still installed
2020-01-04 16:43:57 <mps> s/strong/strict/
2020-01-04 16:43:57 <alpine-meetbot> mps meant to say: not sure, but I think gnome-shell has no 'strict' deps on it, i.e. if it doesn't exist gnome-shell can be still installed
2020-01-04 16:48:38 <Cogitri> Well, it should certainly be a dep anyway since it's the default font, so I'll go add that. Thanks
2020-01-04 16:49:52 <mps> eh, if we have 'ignore_class_pkgs' :)
2020-01-04 16:51:01 <mps> one of reasons I switched from debian is their (so called) 'dependency hell'
2020-01-04 16:59:33 <Cogitri> I'm pretty sure a font that's required for about 99% of the GNOME packages isn't going to introduce a dependency hell upon us
2020-01-04 17:38:16 <mps> don't know, I have ttf-cantarell installed and no gnome pkgs, but I think deps should be added only when they absolutelly needed. at the end there are virtual pkgs as option
2020-01-04 17:58:12 <_ikke_> Cogitri: epiphany is failing
2020-01-04 17:59:34 <Cogitri> Huh, how did that work in my docker container
2020-01-04 17:59:45 <Cogitri> Anyway, should be an easy fix, thanks for the ping.
2020-01-04 18:49:00 <Cogitri> PureTryOut[m]: Heya, very sorry about the delay on !2230, could you rebase that again? Then I'll merge (sorry :c)
2020-01-04 18:56:17 <PureTryOut[m]> Will do in a sec, currently compiling ghc to test a change
2020-01-04 19:02:26 <PureTryOut[m]> Cogitri: rebased
2020-01-04 19:03:32 <Cogitri> Merged :)
2020-01-04 19:04:11 <PureTryOut[m]> Thanks!
2020-01-04 19:04:58 <PureTryOut[m]> Hmm, seems that commit somehow added a new aport? https://git.alpinelinux.org/aports/diff/testing/kaccounts-providers/APKBUILD?id=d33b26af
2020-01-04 19:05:03 <Cogitri> Hm, should git-cola bee disabled too?
2020-01-04 19:05:20 <Cogitri> Hm, have you pushed that to the MR accidentally?
2020-01-04 19:05:26 <PureTryOut[m]> That package should be reverted, it's already in community with a higher version
2020-01-04 19:05:28 <PureTryOut[m]> Not sure how this happened
2020-01-04 19:05:50 <Cogitri> Rebasing can be weird :)
2020-01-04 19:06:01 <PureTryOut[m]> Oh yeah guess git-cola has to be disabled too
2020-01-04 19:07:04 <Cogitri> Done
2020-01-04 19:08:03 <PureTryOut[m]> Thanks!
2020-01-04 19:33:16 <_ikke_> libphonenumber failed again on x86
2020-01-04 19:33:18 <_ikke_> seems flaky
2020-01-04 19:33:45 <_ikke_> undefined reference to `i18n::phonenumbers::PhoneMetadata::~PhoneMetadata()'
2020-01-04 19:37:40 <PureTryOut[m]> Yeah it tends to do that. Often just restarting the build helps
2020-01-04 19:37:50 <_ikke_> what is causing that?
2020-01-04 19:38:15 <_ikke_> internal dependency missing (random order)?
2020-01-04 19:38:22 <PureTryOut[m]> I don't know to be honest
2020-01-04 19:50:48 <mps> kernel 5.4.8 released, mostly net and scsi fixes
2020-01-05 00:12:58 <ddevault> is Konstantin Kulikov itc?
2020-01-05 00:15:01 <mps> 'itc'? in the channel?
2020-01-05 00:17:21 <ddevault> aye
2020-01-05 00:17:41 <mps> not sure, but iirc nick is kaey
2020-01-05 00:18:07 <ddevault> kaey: is there some trick to building the grafana package? So far I've met with miserable failure
2020-01-05 00:18:08 <mps> north1: thanks (dialog)
2020-01-05 01:02:16 <north1> welcome
2020-01-05 01:14:04 <ddevault> kaey: nevermind, I got it working after some more finageling
2020-01-05 05:12:02 <danieli> I packaged it for internal (infra) use at one point, it is indeed excruciating
2020-01-05 11:09:43 <clandmeter> maintainers, inbound emails coming for out of date pkgs.
2020-01-05 11:22:09 <danieli> ack
2020-01-05 11:22:12 <danieli> i got it clandmeter
2020-01-05 11:52:59 <Cogitri> clandmeter: Can we maybe not flag GNOME packages out of date for uneven releases?
2020-01-05 11:53:13 <Cogitri> I'm getting loads of mails about out of date GNOME packages which actually are up-to-date on the stable branch
2020-01-05 11:53:31 <Cogitri> (Not sure how we'd match those other than with the source URL)
2020-01-05 11:53:41 <Cogitri> So maybe I'll just have to deal with that
2020-01-05 11:58:12 <clandmeter> Cogitri: its using https://release-monitoring.org/
2020-01-05 12:01:33 <Cogitri> Ah, okay
2020-01-05 12:02:23 <clandmeter> i think there is some interface to it to adjust things
2020-01-05 12:02:31 <clandmeter> jirutka set it up before
2020-01-05 12:02:41 <clandmeter> i think there are also a lot of mismatches
2020-01-05 12:02:45 <clandmeter> more than matches
2020-01-05 12:03:09 <clandmeter> i think none of the py3 packages get matched
2020-01-05 12:17:32 <Cogitri> Oh
2020-01-05 16:32:26 <mps> Danct12[m]: I pushed consolation, please if you have time fix spaces and braces in APKBUILD (I will probably forget and don't have much time now to fix these)
2020-01-05 16:38:10 <_ikke_> Cogitri: pu3-cu2qu fails on x86
2020-01-05 16:38:25 <_ikke_> test failures
2020-01-05 16:39:38 <Cogitri> Ugh
2020-01-05 17:55:29 <ddevault> hm, I have an idea for this prometheus stuff I'm working on
2020-01-05 17:55:49 <ddevault> we could add -instrumentation subpackages for packages which support it, such as setting up redis-exporter for redis
2020-01-05 17:55:57 <ddevault> then install it if an instrumentation metapacakge is installed
2020-01-05 19:10:44 <kr0k0_1> Hy guys!
2020-01-05 19:13:17 <Cogitri> Heya
2020-01-05 19:14:25 <Cogitri> ddevault: Hm, having -instrumentation subpkg sounds to me as if that pkg would be generic across different monitoring suits but it'd be prometheus specific, wouldn't it be?
2020-01-05 19:14:37 <ddevault> true
2020-01-05 19:14:40 <Cogitri> Wouldn't a -prometheus subpkg be more appropriate then?
2020-01-05 19:14:42 <kr0k0_1> What's about my MR
2020-01-05 19:14:44 <kr0k0_1> !2705
2020-01-05 19:14:44 <ddevault> aye
2020-01-05 19:14:46 <kr0k0_1> !2705
2020-01-05 19:14:48 <kr0k0_1> !2705
2020-01-05 19:14:50 <kr0k0_1> !2705
2020-01-05 19:14:52 <kr0k0_1> !2705
2020-01-05 19:14:54 <kr0k0_1> !2705
2020-01-05 19:14:56 <kr0k0_1> !2705
2020-01-05 19:14:56 <danieli> wtf
2020-01-05 19:14:56 <ddevault> cut it out, kr0k0_1
2020-01-05 19:14:56 <Cogitri> Uhh
2020-01-05 19:14:58 <kr0k0_1> !2705
2020-01-05 19:14:59 <ddevault> _ikke_: clandmeter: cc
2020-01-05 19:15:00 <kr0k0_1> What's about my MR !2705?
2020-01-05 19:15:00 <danieli> someone mind banning him
2020-01-05 19:15:02 <kr0k0_1> Sorry
2020-01-05 19:15:07 <danieli> _ikke_: clandmeter
2020-01-05 19:15:14 <Cogitri> Timed out?
2020-01-05 19:15:31 <kr0k0_1> Seems so
2020-01-05 19:15:36 <kr0k0_1> Sorry again
2020-01-05 19:16:28 <kr0k0_1> Is there any reason to not merge this?
2020-01-05 19:17:05 <ddevault> ping the maintainer
2020-01-05 19:17:10 <Cogitri> Not at all, but the MR is only two days old and most devs are kind of busy right now (including me), so it might take a little, sorry
2020-01-05 19:17:45 <clandmeter> kr0k0_1: it will be merged when ncopa does a new kernel release.
2020-01-05 19:18:16 <kr0k0_1> Ah ok, thanks guys.
2020-01-05 19:46:40 <mps> who put MR number with ! in branch name? algitbot?
2020-01-05 20:04:48 <_ikke_> ?
2020-01-05 20:06:31 <mps> MR about wireguard
2020-01-05 20:07:00 <_ikke_> I don't see a '!' in the branchname
2020-01-05 20:07:27 <mps> (!  2705)
2020-01-05 20:07:50 <mps> added 2 spaces to not trigger it again
2020-01-05 23:59:13 <XgF> Hey, is there a reason why the Pi kernel config has "CONFIG_PACKET=m" in it instead of "y"? It seems like something very commonly wanted (e.g. its a prerequisite of DHCP). Alternatively, could the packet module be put into the initramfs? I'm trying to netboot Alpine on the Pi family and hitting this catch-22
2020-01-05 23:59:35 <XgF> (I'm looking into the latter but haven't found how what modules are in initramfs is selected yet...)
2020-01-06 00:10:18 <AinNero> XgF: i remember there was an issue related to that module previously
2020-01-06 00:11:05 <XgF> I did find https://gitlab.alpinelinux.org/alpine/aports/issues/9124 though it seems only tangentially related
2020-01-06 00:11:15 <AinNero> (cant view links right now)
2020-01-06 00:11:31 <AinNero> the af_packet module is per default included into the mkinitfs 'network' feature
2020-01-06 00:12:08 <AinNero> otherwise you can load it via /etc/modules or /etc/modprobe.d
2020-01-06 01:04:40 <XgF> I'm currently doing some major initramfs hacks, but I got it working: https://gist.github.com/erincandescent/e1f62327b24c9f2751b70343da8b50f2
2020-01-06 02:27:57 <ddevault> what's the current state of the art for splitting subpackages into sub-subpackages for -openrc
2020-01-06 02:28:13 <ddevault> or in other words, I have a subpackage which has its own daemon, how do I split out its -openrc package
2020-01-06 02:47:51 <ddevault> great
2020-01-06 02:47:54 <ddevault> I have broken apk
2020-01-06 03:11:16 <ddevault> I have made it impossible to uninstall my package
2020-01-06 03:11:18 <ddevault> woohoo
2020-01-06 03:11:22 <ddevault> 
ACTION goes to sleep

2020-01-06 05:34:18 <iggy> ddevault: I saw you issues for ceph. I found out about the mgr thing recently. I originally saw the redhat packaging removing a ton of node deps so thought it was safe (I'm no node guy)... it should be a one line change to fix that. I'm going to look into the other things soon too. Been out of town for a while, just getting back into the swing of things
2020-01-06 05:41:16 <Sodomon> Hello and Happy New Year
2020-01-06 05:41:27 <Sodomon> I have a question.
2020-01-06 05:43:00 <Sodomon> When I do the pull request on github the repo-lockdown bot closes it for me someone knows why?
2020-01-06 05:43:25 <north1> Because github is on lockdown, use gitlab.a.o instead
2020-01-06 05:43:33 <iggy> Sodomon: the project has switched to using gitlab ( gitlab.alpinelinux.org )
2020-01-06 05:45:18 <Sodomon> Ah ok thank you or tell me
2020-01-06 12:20:48 <mps> north1: re kernel build on CI: I thought to tell you to download it when I finished and downloaded myself, but had a fear that I will annoy you and didn't because of that
2020-01-06 12:23:11 <mps> btw, 5.4.8 have some fixes backported from 5.5-rc
2020-01-06 12:25:02 <north1> Please do tell
2020-01-06 12:25:11 <north1> I'm following every update zealously to get this annoyance fixed
2020-01-06 12:25:20 <mps> and 5.5-rc5 (releaed few hours ago) have fixes which I will be backported to 5.4.9 (and GKH wil not wait too long)
2020-01-06 12:26:14 <mps> sorry, my mistake and it is pity that we cannot retrigger particular arch rebuild on CI
2020-01-06 12:26:21 <mps> all or none
2020-01-06 12:27:42 <_ikke_> You
2020-01-06 12:27:44 <_ikke_> can
2020-01-06 12:27:57 <_ikke_> Just retry that specific job
2020-01-06 12:28:06 <mps> _ikke_: yes, i mean other devs cannot
2020-01-06 12:28:52 <mps> or, if I'm wrong would be nice news to me
2020-01-06 12:28:59 <north1> No worries I just made my own MR, downloaded the artifacts and then deleted the branch
2020-01-06 12:30:54 <mps> I see, but again, would be nice if that cna be done in simpler way
2020-01-06 12:34:43 <_ikke_> mps: If you can restart the entire pipeline, I would expect you can restart a single job as well
2020-01-06 12:35:35 <mps> iiuc, I can only do these for MRs I created
2020-01-06 12:35:59 <mps> and for MRs from non official devs on gl.a.o
2020-01-06 12:36:39 <_ikke_> The issue is that you have no permissions on forks
2020-01-06 12:36:51 <_ikke_> Not a lot we can do about afaik
2020-01-06 12:38:00 <mps> understood
2020-01-06 13:19:14 <ddevault> iggy: no worries, thanks
2020-01-06 14:07:03 <Cogitri> PureTryOut[m]: FYI: had to disable kmouth on armhf due to qtdeclarative
2020-01-06 14:34:01 <PureTryOut[m]> Yeah no props. Same problem seems to be with kio-gdrive
2020-01-06 16:09:29 <PureTryOut[m]> So the linter check in the CI doesn't accept "custom" and "proprietary" as values, what are we supposed to do in those cases?
2020-01-06 16:09:37 <PureTryOut[m]> Or should the linter tool be modified to accept those?
2020-01-06 16:09:50 <north1> most likely not
2020-01-06 16:10:23 <north1> There are various ways to deal with it but the most common one that can be done from Alpine's side is accepting a custom: prefix to the license and lint it either way
2020-01-06 16:11:05 <_ikke_> PureTryOut[m]: custom / propriarity are not part of the SPDX list, which is what abuild checks against
2020-01-06 16:11:22 <_ikke_> What north1  suggests would be one solution
2020-01-06 16:11:44 <north1> The best solution would be adopting a SPDX-compliant license which covers almost any usecase you might have and more
2020-01-06 16:12:08 <_ikke_> The question is if we can even distribute those projects
2020-01-06 16:12:25 <PureTryOut[m]> In this case it's for postmarketOS where we use the same linter since yesterday evening
2020-01-06 16:12:28 <PureTryOut[m]> Tons of firmware packages
2020-01-06 16:12:36 <north1> Shouldn't be a question if the license is OSI compliant
2020-01-06 16:13:07 <_ikke_> Does Alpine Linux commit to only ship software with OSI compliant licenses?
2020-01-06 16:13:51 <north1> "The license of the program should be based on the licenses approved by the Free Software Foundation or OSI."
2020-01-06 16:13:53 <PureTryOut[m]> Not currently, there is for example https://pkgs.alpinelinux.org/package/edge/main/armv7/linux-firmware
2020-01-06 16:13:54 <north1> basically, yes.
2020-01-06 16:14:49 <PureTryOut[m]> Still, shouldn't the linter work fine with custom (which may or may not be proprietary) packages as well? They don't necessarily have to be in the Alpine repos
2020-01-06 16:15:09 <_ikke_> PureTryOut[m]: The linter just checks the SPDX database
2020-01-06 16:15:14 <_ikke_> (it's abuild that does this)
2020-01-06 16:15:26 <PureTryOut[m]> Yeah but can a "custom" or "proprietary" entry be added?
2020-01-06 16:15:39 <north1> PureTryOut[m] (IRC): having a non-descript "custom" doesn't help much
2020-01-06 16:16:23 <PureTryOut[m]> Well that's when you also install the LICENSE file. But "proprietary" would be good enough for us
2020-01-06 16:16:58 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n914
2020-01-06 16:17:22 <clandmeter> custom and include the license sounds sane (if the license is sane to distribute it)
2020-01-06 16:17:45 <Cogitri> colista: qownnotes fails on x86 with `install: can't stat '/home/buildozer/aports/testing/qownnotes/src/qownnotes-20.1.1/languages/*.qm': No such file or directory`
2020-01-06 16:18:04 <Cogitri> fcolista: ^
2020-01-06 16:18:33 <PureTryOut[m]> clandmeter: ok, so I guess I'll have to modify abuild then to accept "custom"?
2020-01-06 16:19:20 <clandmeter> PureTryOut[m]: probably best to send a PR and ask others opinion.
2020-01-06 16:19:30 <clandmeter> MR sorry :)
2020-01-06 16:19:49 <_ikke_> perhaps along with some attributes about the specific license?
2020-01-06 16:20:18 <clandmeter> this MR would be to add custom as allowed license?
2020-01-06 16:21:45 <PureTryOut[m]> In my case yes
2020-01-06 16:40:18 <PureTryOut[m]> Wait, it seems I can skip the license check altogether by putting `!spdx` in the options of the APKBUILD, do I see that right?
2020-01-06 16:41:22 <_ikke_> yes, that would work as well
2020-01-06 16:41:32 <PureTryOut[m]> That's good enough for me!
2020-01-06 17:35:21 <PureTryOut[m]> In the alpinelinux/apkbuild-lint-tools Docker image, can changed-aports be made to skip a folder?
2020-01-06 17:41:14 <zfoo__> If abuild is not able to cross-compile how would one bootstrap a system? How are some of the aports (alpine-base, gcc, binutils) built for a new system?
2020-01-06 17:41:34 <iggy> qemu?
2020-01-06 17:41:51 <zfoo__> yeah, but it's slow
2020-01-06 17:43:03 <iggy> I would imagine any new system that needs to be bootstrapped would be too?
2020-01-06 17:46:53 <zfoo__> What I'm looking to do is build a base alpine rootfs for embedded systems and allow one to set any and all flags for their given architecture. Something like buildroot but would be based off alpine.
2020-01-06 17:49:17 <iggy> I think some people have managed to hook cross-compilers into abuild as well
2020-01-06 18:29:31 <Cogitri> But about all packages in alpine don't support crosscompiling
2020-01-06 18:29:42 <Cogitri> So to be honest, it's not fun
2020-01-06 19:09:49 <_ikke_> Cogitri: vpnc is failing
2020-01-06 19:10:04 <_ikke_> checksum failure
2020-01-06 19:15:20 <Cogitri> Ugh, is the thing dynamically generated
2020-01-06 19:15:25 <Cogitri> CI worked
2020-01-06 19:16:06 <Cogitri> While I fix that, is stable CI broken? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2658 tries to pull in a 3.11/testing repo which doesn't work since that's only available for edge
2020-01-06 19:16:28 <Cogitri> Huh, vpnc works locally too
2020-01-06 19:17:19 <_ikke_> strange
2020-01-06 19:18:02 <AinNero> a few minutes ago a cloudflare issue was corrupting my memes
2020-01-06 19:18:14 <AinNero> might be same issue
2020-01-06 19:19:48 <Cogitri> Possibly
2020-01-06 19:20:29 <AinNero> re: checksum failure
2020-01-06 19:27:35 <_ikke_> Cogitri: looking at the 3.11 CI issue
2020-01-06 19:33:32 <Cogitri> Thank you
2020-01-06 19:44:56 <MY-R> cloudflare working bad today at least in EU and from their status page: "Network Congestion and Performance Issues in Europe"
2020-01-06 19:47:13 <MY-R> and that would explain my dns issue with their server returning some empty results
2020-01-06 19:50:31 <_ikke_> my workstation just crashed due to building :-/
2020-01-06 19:53:35 <MY-R> feel sorry! :\
2020-01-06 19:53:42 <MY-R> overheating or GPU?
2020-01-06 19:54:04 <_ikke_> CPU / memory exhaustion
2020-01-06 19:54:27 <_ikke_> Note sure what caused it exactly
2020-01-06 19:55:25 <MY-R> remember on some 4G ram machine firefox could freeze my system to the point when couldnt work on for the next 20 minutes... (ye swap hard on hdd encrypted disk....)
2020-01-06 19:55:41 <MY-R> "resolved" the problem with cgroups memory limit :D
2020-01-06 19:55:43 <_ikke_> This was some kind of kernel lockup, could not even ping the machine anymore
2020-01-06 19:56:49 <MY-R> maybe time do some stress tests? memram test etc?
2020-01-06 19:57:00 <mps> few hours ago my firefox killed by oom
2020-01-06 19:57:11 <MY-R> mps lucky you!
2020-01-06 19:57:26 <mps> suspect is kernel
2020-01-06 19:58:37 <mps> yesterday I had to switch to console and wait few minutes to login as root and kill it because it exhausted all resources
2020-01-06 19:58:39 <MY-R> but ye, there are some weird web pages which eating ram like crazy and firefox basically not doing much with it
2020-01-06 19:58:45 <MY-R> exactly
2020-01-06 19:59:41 <mps> that was on x86_64 with linux-lts 5.4.7, on aarch64 with 'my' kernel all works fine
2020-01-06 19:59:47 <MY-R> so ye that is when memory limit cgroups can help with it so it will never lead to that point, but I dont see any tools in alpine to install I think
2020-01-06 19:59:56 <mps> both boxes have 4GB ram
2020-01-06 20:00:41 <MY-R> I'm glad to hear, thought I'm the only one that got such a problems with browsers (or more like shit web pages)
2020-01-06 20:01:46 <mps> that happens when I forget to add swap
2020-01-06 20:02:18 <mps> if I add swap, firefox sometimes crawl but don't locks or killed
2020-01-06 20:02:19 <MY-R> swap for sure on some ssd/flash memory, right mps?
2020-01-06 20:02:36 <mps> ssd
2020-01-06 20:02:49 <MY-R> ye in that case it helping a lot
2020-01-06 20:03:37 <mps> so, you are not only one with issues using firefox :(
2020-01-06 20:03:51 <MY-R> on chromium got same
2020-01-06 20:04:26 <mps> maybe we are victims of JS miners :)
2020-01-06 20:08:00 <MY-R> mps, ye I was thinking about it but cpu was 90% idle :\ opened same page but in extra tab and boom... swapping hard like wanted dump whole ram in to swap
2020-01-06 20:09:11 <mps> same here, I'm kidding about JS miners, I have blocking addons for JS
2020-01-06 20:10:22 <MY-R> ahh, so blocking JS wont help :\
2020-01-06 20:10:55 <mps> no
2020-01-06 20:11:00 <MY-R> I tried tweak sysctl stuff but tbh better spend that time to get extra ram :D
2020-01-06 20:11:42 <mps> my wife use box with 2GB ram but don't have much issues with FF, except when browsing heave JS pages
2020-01-06 20:12:25 <MY-R> but still, cgroups memory limit was doing good job, firefox could freeze but at least not entire system
2020-01-06 20:12:27 <mps> but her box is still 3.10 and linux-vanilla 4.19.x
2020-01-06 20:12:52 <MY-R> for me "best" kernel was 4.9 :D
2020-01-06 20:13:17 <MY-R> but ye, </offtopic> :)
2020-01-06 20:29:49 <AinNero> 4.4 has lts + cip support until 2030
2020-01-06 20:38:54 <ddevault> preferred place to send abuild patches?
2020-01-06 20:39:00 <ddevault> please say ~alpine/devel
2020-01-06 20:43:34 <_ikke_> ddevault: just send it there, I don't think there is an alternative
2020-01-06 20:43:38 <_ikke_> except for gitlab MR
2020-01-06 20:43:50 <ddevault> it looks like a lot of other people are using gitlab MRs
2020-01-06 20:43:56 <ddevault> I'm guessing my patch will be forwarded to /dev/null on the ML
2020-01-06 20:44:20 <ddevault> it'll be a cold day in hell before I send aports patches to gitlab, though :)
2020-01-06 22:01:33 <danieli> a lot of people are using gitlab MRs just like how a lot of people used github PRs rather than using ML/patchwork/cgit
2020-01-07 19:09:31 <Mikeynl2345> Hi Guys, need a small push in the right direction. I try to automount a usb drive with a specific label, so far all is working, and script get executed. Only the mount command is not executed / working. I am aware of the systemd-udev implementation that creates a subspace, but even chcecken the mount output from the script in a tmp file is now
2020-01-07 19:09:31 <Mikeynl2345> showing the mount. Also the mount command is not throwing any error
2020-01-07 19:09:34 <Mikeynl2345> Thank you :)!
2020-01-07 22:02:16 <_ikke_> The builders are green again
2020-01-08 01:51:34 <ddevault> making good progress on man pages: https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/9
2020-01-08 01:51:38 <ddevault> (for apk)
2020-01-08 05:37:16 <_ikke_> nice
2020-01-08 07:09:38 <_ikke_> north1: podman fails to build
2020-01-08 07:09:56 <north1> I'll take a look soon
2020-01-08 07:10:15 <north1> Am recharging my phone plan
2020-01-08 07:52:58 <Geod2474> Hi
2020-01-08 07:53:33 <Geod2474> I'm trying to download artifacts from Gitlab runners, but it seems the bandwidth is extremely low
2020-01-08 07:54:03 <Geod2474> In the 40 to 50 KB/s range
2020-01-08 07:54:20 <_ikke_> Geod2474: link?
2020-01-08 07:55:10 <Geod2474> I'm in asia (South Korea), and usually have a pretty good bandwidth, even to Europe (I have a server in Paris and usually SCP is around 1MB/s)
2020-01-08 07:55:14 <Geod2474> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2841
2020-01-08 07:56:02 <Geod2474> Seems to manifest with all archs, so I'm going 1 by 1
2020-01-08 08:07:48 <_ikke_> they all come from the same server
2020-01-08 08:08:09 <danieli> yeah, the gitlab data isn't stored on a global cdn to my knowledge
2020-01-08 08:08:36 <_ikke_> no
2020-01-08 08:09:06 <Geod2474> That server is in Europe I suppose ?
2020-01-08 08:09:08 <_ikke_> Yes
2020-01-08 08:09:18 <_ikke_> Geod2474: what is your latency to gitlab.alpinelinux.org?
2020-01-08 08:10:07 <Geod2474> Wow
2020-01-08 08:10:11 <Geod2474> It's bad
2020-01-08 08:10:40 <Geod2474> 36 packets transmitted, 5 packets received, 86.1% packet loss
2020-01-08 08:10:51 <_ikke_> lots of packetloss, strange
2020-01-08 08:11:10 <Geod2474> round-trip min/avg/max/stddev = 237.978/243.778/264.610/10.424 ms
2020-01-08 08:11:27 <_ikke_> Combined with the packetloss that would explain the bad throughput
2020-01-08 08:11:42 <Geod2474> Yep. I don't see the same behavior with my server in Paris:
2020-01-08 08:11:43 <Geod2474> --- pkg.mimiks.net ping statistics ---17 packets transmitted, 16 packets received, 5.9% packet lossround-trip min/avg/max/stddev = 246.680/273.148/345.320/33.143 ms
2020-01-08 08:13:55 <Geod2474> Perhaps the gitlab (or some other piece of infra) is configured with a very low timeout ?
2020-01-08 08:15:28 <mps> hmm, from last night I also see that the traffic is slower, and not only to Alpine server
2020-01-08 08:16:31 <mps> now it is better, probably net admins in some important node are wake up
2020-01-08 08:16:41 <Geod2474> Looks like the packet loss is almost gone now.
2020-01-08 08:17:15 <Geod2474> Throughput is still low but at least the download doesn't stop :)
2020-01-08 08:19:02 <Geod2474> Alternatively, it'd be great if we could download the artifacts programmatically without having to login (e.g. wget)
2020-01-08 08:19:35 <mps> Geod2474: we can, just need url
2020-01-08 08:20:12 <_ikke_> Geod2474: I made your project public, so should be possible now
2020-01-08 08:21:03 <Geod2474> Great, thanks
2020-01-08 14:42:27 <ddevault> can we move the shadow package into main?
2020-01-08 14:44:27 <mps> rationale for that?
2020-01-08 14:45:14 <ddevault> useradd > adduser
2020-01-08 14:45:21 <ddevault> it's part of the base system for lots of other distros
2020-01-08 14:45:25 <ddevault> one of the first things I install on alpine
2020-01-08 14:47:08 <mps> when started to use alpine I though same, but nowadays current is fine with me
2020-01-08 14:47:17 <mps> thought*
2020-01-08 14:47:23 <clandmeter> but why main?
2020-01-08 14:47:44 <clandmeter> its currently in community?
2020-01-08 14:48:22 <mps> yes, http://dl-cdn.alpinelinux.org/alpine/v3.11/community
2020-01-08 15:12:45 <Cogitri> +1 on that question, adduser wfm
2020-01-08 15:14:47 <mps> -1
2020-01-08 15:15:08 <mps> main should be small
2020-01-08 15:19:24 <mps> and removing '#' in /etc/apk/repositories + 'apk update' is not much work
2020-01-08 15:55:17 <PureTryOut[m]> Is there a way to make the `alpinelinux/apkbuild-lint-tools:latest` Docker image skip a given directory, even if it's returned by `changed-aports`?
2020-01-08 15:56:00 <_ikke_> No, there is nothing for that
2020-01-08 15:56:04 <_ikke_> What's the usecase?
2020-01-08 15:56:05 <PureTryOut[m]> Or is there a way to get that `changed-aports` command outside that docker image in a regular Alpine install? I don't see it on https://pkgs.alpinelinux.org/contents
2020-01-08 15:56:56 <_ikke_> Source is here: https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/blob/master/overlay/usr/local/bin/changed-aports
2020-01-08 15:57:33 <PureTryOut[m]> Well for pmOS we want to use it, but skip the "temp/" folder as that folder contains forks of Alpine packages which we want synced as much as possible. Basically we don't want the linting to fail because a package in "temp/" is changed which then forces us to divert to much from upstream
2020-01-08 16:01:30 <_ikke_> Feel free to make a merge request that lets you optionally filter packages
2020-01-08 16:02:17 <_ikke_> maybe some kind of ignore file in the repo or something like th
2020-01-08 16:02:20 <_ikke_> at
2020-01-08 16:03:07 <PureTryOut[m]> Yeah guess I'll do that
2020-01-08 16:19:24 <north1> to atools ?
2020-01-08 16:21:27 <_ikke_> no, alpine-lint-tools
2020-01-08 16:21:34 <north1> oh
2020-01-08 16:21:35 <north1> ok
2020-01-08 16:21:46 <_ikke_> apkbuild-lint-tools*
2020-01-08 16:27:29 <kaniini> ddevault: given that shadow is a source of constant security nightmares, i would rather make it possible for busybox to use PAM
2020-01-08 16:27:36 <kaniini> (optionally)
2020-01-08 16:28:47 <ddevault> that's not why I want shadow
2020-01-08 16:28:50 <ddevault> PAM sucks
2020-01-08 16:29:18 <ddevault> maybe I'll write a shadow clone which only has the parts I like in it
2020-01-08 16:39:56 <clandmeter> ddevault: what is the reason to move it to main? personal preference?
2020-01-08 16:47:50 <ddevault> (1) personal preference
2020-01-08 16:47:54 <ddevault> (2) it seems on-topic for main
2020-01-08 16:47:58 <ddevault> (3) main has support guarantees
2020-01-08 18:13:32 <ddevault> also:
2020-01-08 18:13:38 <ddevault> ninja vs samurai discussion bump
2020-01-08 18:40:59 <Cogitri> I don't mind the switch, to be honest I still don't feel like we'd gain a massive advantage from it but I don't really see disadvantages other than not using what upstreams usually use so it's fine by me
2020-01-08 18:43:47 <ddevault> kaniini had a good post on the mailing list about it
2020-01-08 18:43:59 <ddevault> https://lists.alpinelinux.org/~alpine/devel/%3CCAAOiGNwnzTomzOQ6YjH3t7VHmbfMRZUNXap8GM0Gy_mGS7aKhg%40mail.gmail.com%3E
2020-01-08 18:46:55 <Cogitri> Yup, read it
2020-01-08 18:47:13 <Cogitri> Really was good but since I didn't really have anything to add to that I wasn't sure what to reply
2020-01-08 18:47:17 <Cogitri> 
ACTION dislikes email

2020-01-08 21:26:49 <ddevault> 
ACTION likes email

2020-01-08 21:27:17 <_ikke_> 
ACTION is neutral about e-mail

2020-01-08 21:44:10 <PureTryOut[m]> 
ACTION likes the concept, but hates the server-side mess

2020-01-08 21:44:24 <PureTryOut[m]> Hopefully something like https://github.com/foxcpp/maddy will fix that someday
2020-01-08 21:51:01 <_ikke_> looks nice
2020-01-08 23:16:35 <mps> anyone know how to download patch and not diff from https://phabricator.services.mozilla.com
2020-01-08 23:17:52 <mps> I think I found patch there for firefox 72.0
2020-01-08 23:18:20 <mps> want to try to build it before going to bed :)
2020-01-09 00:43:21 <mps> looks like this patch (https://phabricator.services.mozilla.com/D56873) is not needed, at least for aarch64
2020-01-09 00:43:45 <mps> builds fine in lxc
2020-01-09 01:51:15 <nixfloyd_> ddevault: I would appreciate any comments on https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2864 given your prometheus packaging efforts
2020-01-09 01:51:27 <ddevault> added to my todo list
2020-01-09 01:51:31 <ddevault> but won't be tonight
2020-01-09 01:51:33 <ddevault> I'm off o/
2020-01-09 01:51:49 <nixfloyd_> 
ACTION waves

2020-01-09 08:01:30 <clandmeter> north1: i see a lot of orphan commits?
2020-01-09 08:01:45 <north1> yes
2020-01-09 08:02:21 <clandmeter> any specific reason?
2020-01-09 08:03:00 <north1> consolidating
2020-01-09 08:03:21 <north1> orphaning what i don't use, removing ones i think should be done better by someone else
2020-01-09 08:03:31 <north1> moving the stuff i use to community
2020-01-09 08:04:37 <clandmeter> oh ok
2020-01-09 08:05:07 <clandmeter> if you think its not useful you can also move it to unmaintained
2020-01-09 08:05:34 <mps> ah, good, I was surprised seeing a lot of orphans
2020-01-09 08:06:13 <clandmeter> yeah, maybe it makes sense to bundle them into a single commit next time :)
2020-01-09 08:08:25 <mps> clandmeter: too late, he already orphaned them :)
2020-01-09 08:09:02 <clandmeter> next time... its not a big issue though.
2020-01-09 08:09:23 <north1> PureTryOut[m] (IRC): kdecoration is failing on armhf  due to qtDeclarative
2020-01-09 08:12:22 <PureTryOut[m]> Well, disable it on that arch then 😉
2020-01-09 08:12:34 <north1> sweet
2020-01-09 08:12:38 <north1> lets see the failure waterfall
2020-01-09 08:12:55 <_ikke_> I've already been disabling packages which depend on qtdeclerative
2020-01-09 08:18:07 <north1> @ddevault are there email notifications for when one of your patches change state ? (like when someone sets it as APPLIED)
2020-01-09 08:18:12 <north1> @ikke ty
2020-01-09 08:26:18 <mps> downgrading firefox becoming nightmare :(
2020-01-09 08:27:13 <PureTryOut[m]> Should just be failures related to qtdeclarative not being on armhf
2020-01-09 08:27:20 <mps> 72.0 faults on armv7
2020-01-09 08:27:22 <Cogitri> How come you need to do that?
2020-01-09 08:27:24 <PureTryOut[m]> Just disable those packages wherever it comes up
2020-01-09 08:27:31 <Cogitri> Planned to merge 72.0.1 ASAP
2020-01-09 08:27:46 <Cogitri> What goes wrong about it?
2020-01-09 08:28:08 <mps> ah, 72.0.1 released? didn't seen it
2020-01-09 08:28:24 <mps> Unhandled fault: alignment exception (0x011) at 0xbec84658
2020-01-09 08:41:55 <mps> Cogitri: uh, how is mozilla site is intuitive, but managed to find source. if you plan to work on 72.0.1 upgrade I can do something
2020-01-09 08:42:12 <mps> something else*
2020-01-09 08:46:26 <mps> anyway, started build on armv7, hope will inform you in a hour or two if it works
2020-01-09 08:46:53 <Cogitri> Ah, I think J0WI made a MR for that, didn't he?
2020-01-09 08:47:49 <mps> yes, but it fails on CI
2020-01-09 08:48:30 <mps> and is J0WI here?
2020-01-09 08:48:50 <mps> whoever is s/he
2020-01-09 08:53:07 <Cogitri> I don't think they're on IRC
2020-01-09 08:53:10 <Cogitri> But !2860
2020-01-09 08:54:15 <mps> yes, just seen when you mentioned it
2020-01-09 08:55:04 <mps> last night I built 72.0, but it fails on armv7 (where testing) and it failed with msg posted above
2020-01-09 09:55:34 <nmeum> firefox-esr should also be upgraded asap, but the CI fails currently
2020-01-09 09:55:41 <nmeum> !5017
2020-01-09 09:55:49 <nmeum> !2859 (sorry)
2020-01-09 10:01:40 <mps> nmeum: 72.0.1 faults on armv7, will try to build 68.4.1 and see will it work
2020-01-09 10:04:28 <mps> last night looked at patch on their site, not sure will it fix this 'Bus error'
2020-01-09 10:04:53 <mps> building and testing FF takes time, as you know
2020-01-09 10:22:18 <nmeum> yep
2020-01-09 10:22:52 <nmeum> cannot reproduce the firefox-esr 68.4.1 build error on x86_64 though, build it yesterday and didn't run into any issue so far
2020-01-09 10:25:12 <mps> good, I'm just started build on aarch64, hope it will finish in about hour
2020-01-09 10:27:23 <nmeum> I would honestly prefer being able to reproduce it, no clue why it fails on the CI tbh
2020-01-09 10:29:27 <mps> I found this https://phabricator.services.mozilla.com/rMOZILLACENTRAL8e71fa07fe004c2e4d04db6b9e77cdfbc7810d6a
2020-01-09 10:29:48 <mps> didn't tested yet, so not sure will it help
2020-01-09 10:58:44 <_ikke_> nmeum: You could use the alpinelinux/alpine-gitlab-ci image and try to build it in there
2020-01-09 10:59:00 <_ikke_> (docker image)
2020-01-09 12:13:35 <mps> nmeum: FF 68.4.1 pass build in my lxc aarch64
2020-01-09 12:13:57 <mps> I mean, MR mentioned above
2020-01-09 12:14:10 <mps> !2859
2020-01-09 12:15:42 <nmeum> mps: hm, it also builds fine on my x86_64 machine. I guess it's a CI fuckup then?
2020-01-09 12:15:54 <nmeum> didn't get around to setting up a alpine-gitlab-ci docker yet
2020-01-09 12:17:51 <mps> I think it could be pushed
2020-01-09 13:01:39 <ncopa> #11118 should be mentioned in the commit for firefox-esr
2020-01-09 13:04:19 <mps> commiter should add this as 'fixes: ...' in commit msg
2020-01-09 13:23:23 <ncopa> 👍
2020-01-09 13:28:14 <mps> FF 72.0 works on aarch64 about one hour (or better say, still not faulted )
2020-01-09 13:29:19 <mps> ah, 5.4.10 is released :)
2020-01-09 13:31:19 <mps> day will be busy ;)
2020-01-09 13:33:57 <nmeum> should I just go ahead and push the firefox-esr upgrade, will modify the commit message accordingly…
2020-01-09 13:34:04 <nmeum> s/,/?/
2020-01-09 13:34:04 <alpine-meetbot> nmeum meant to say: should I just go ahead and push the firefox-esr upgrade? will modify the commit message accordingly…
2020-01-09 13:38:03 <mps> well, you told that it build on x86_64 and I tested on aarch64, so I think it is ok to push, for edge at least
2020-01-09 13:38:27 <mps> if it goes well, then backport to 3.11
2020-01-09 13:38:55 <mps> but I think it will go fine on 3.11
2020-01-09 13:44:08 <Cogitri> Sounds good
2020-01-09 13:45:53 <nmeum> referenced #11118 in the commit message and pushed it, I think we should only close #11118 as soon as it has been backported to 3.11
2020-01-09 13:47:20 <nmeum> have to catch a train in a second, let's see if the build finishes in the meantime
2020-01-09 13:53:39 <ddevault> north1: no, but if you join #alpine-commits you'll get highlighted
2020-01-09 13:54:22 <ddevault> it would be a cool feature to support sending those sorts of notifications, though
2020-01-09 13:54:30 <north1> Bummer, would be nice to know when your stuff gets Applied
2020-01-09 13:54:42 <north1> Otherwise I feel like I need to contact the person to let them know
2020-01-09 13:55:21 <mps> use irssi, Luke :)
2020-01-09 14:49:05 <ddevault> north1: it would be cool to subscribe to e.g. ~alpine/aports+patchupdates@lists.a.o
2020-01-09 14:49:19 <ddevault> on my projects I like to tell people their patches have been applied myself, though, so I can thank them for their contribution
2020-01-09 14:49:40 <ddevault> doesn't scale well at aports volume
2020-01-09 14:51:39 <north1> My merge script for gitlab automatically comments, might do something like that for sourcehut
2020-01-09 14:52:15 <ddevault> well, automatically commenting would defeat the purpose
2020-01-09 14:52:21 <ddevault> I like to leave a personal thanks
2020-01-09 14:52:23 <ddevault> not a robot thanks
2020-01-09 14:52:38 <ddevault> but I still see value in having the software let you know what's up
2020-01-09 14:55:07 <north1> The purpose is to notify, the thank you is a formality
2020-01-09 17:55:37 <mps> could someone with alpine build go knowledge fix alertmanager, it looks simple but I'm not sure how go build works with abuild
2020-01-09 17:57:57 <ddevault> what's wrong with alertmanager?
2020-01-09 17:58:56 <Cogitri> It's failing to build on aarch64
2020-01-09 17:59:02 <Cogitri> Pushed ff 72.0.1 btw
2020-01-09 18:00:06 <mps> ddevault: https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/alertmanager/alertmanager-0.20.0-r0.log
2020-01-09 18:00:17 <ddevault> hm, yeah, I don't know any better than you do about this
2020-01-09 18:00:42 <mps> heh, hope someone who know will do something
2020-01-09 18:01:12 <mps> looks like flag is missing or incorrect
2020-01-09 18:01:32 <ddevault> yeah, weird that it wouldn't happen on other arches
2020-01-09 18:01:50 <mps> yes, this is what wonders me
2020-01-09 18:02:30 <mps> Cogitri: are you sure this patch about cpu is needed for FF 72.0.1
2020-01-09 18:03:02 <mps> I built it without this patch for aarch64 and it works fine
2020-01-09 18:03:07 <Cogitri> `this patch about cpu`?
2020-01-09 18:03:17 <mps> give me few secs
2020-01-09 18:05:10 <mps> 8e71fa07fe00.patch
2020-01-09 18:06:44 <mps> did you took it from void linux, looks similar
2020-01-09 18:10:28 <Cogitri> Yes
2020-01-09 18:11:02 <mps> I built 72.0.1 without it and it works on aarch64
2020-01-09 18:11:53 <Cogitri> Well, it apparently works against SEGFAULTs on some machines
2020-01-09 18:12:54 <Cogitri> And according to the upstream bug report it's implemented in Clang 7+ and not in GCC, so to be frank I just went for it
2020-01-09 18:13:11 <Cogitri> Maybe it does work on some platforms without it but I wanted to get that security fix out ASAP
2020-01-09 18:15:05 <mps> yes, that I wan't to ask, just built it for armv7 with similar patch
2020-01-09 18:15:18 <mps> want to see will it work
2020-01-09 18:16:45 <mps> thanks for info
2020-01-09 18:56:38 <kaey> Cogitri: what is value of LDFLAGS on aarch64?
2020-01-09 18:56:38 <kaey> i think LDFLAGS should be escaped with printf %q and ldflags should be prefixed with "local"
2020-01-09 18:56:40 <kaey> https://git.alpinelinux.org/aports/tree/community/alertmanager/APKBUILD
2020-01-09 18:56:41 <kaey> ddevault: ^
2020-01-09 18:56:43 <kaey> would be nice to see output of "env" in build logs btw
2020-01-09 19:01:08 <kaey> alternatively you can invoke "go build" once with "./cmd/amtool ./cmd/alertmanager", then separate ldflags var is not needed
2020-01-09 19:03:33 <ddevault> all of those things are non-POSIX GNUisms
2020-01-09 19:03:47 <ddevault> except for that last suggestion, that sounds good
2020-01-09 19:05:05 <ddevault> actually it seems go build doesn't grok that
2020-01-09 19:05:11 <ddevault> so I'm just gonna copypasta it
2020-01-09 19:05:16 <mps> Cogitri: firefox-72.0.1 fails on armv7
2020-01-09 19:07:02 <kaey> building multiple packages at once should work. what does it say to you?
2020-01-09 19:07:12 <ddevault> hmm, something is fucky here
2020-01-09 19:07:37 <kaey> also local is accepted by aports styleguide
2020-01-09 19:07:45 <kaey> https://git.alpinelinux.org/aports/tree/CODINGSTYLE.md
2020-01-09 19:07:55 <ddevault> nevermind, it works
2020-01-09 19:08:00 <ddevault> I was misinterpreting things
2020-01-09 19:08:08 <ddevault> and I am aware that alpine's style guide permits local, I'm still not going to use it
2020-01-09 19:08:38 <ddevault> wait, no, it doesn't work. It doesn't print anything either, it just doesn't work
2020-01-09 19:08:52 <kaey> then you should prefix vars with underscore, to avoid potential conflicts with vars defined by abuild
2020-01-09 19:09:08 <ddevault> that seems reasonable
2020-01-09 19:09:22 <ddevault> anyway, I have a patch
2020-01-09 19:09:24 <ddevault> sending to aports list
2020-01-09 19:10:02 <Cogitri> mps: Fails as in explodes during runtime?
2020-01-09 19:10:25 <mps> Alignment trap: not handling instruction f9610aef at [<b3d8a382>]
2020-01-09 19:10:44 <mps> bus error
2020-01-09 19:13:05 <mps> full dmesg here http://tpaste.us/kyQZ
2020-01-09 19:14:05 <mps> same happened with my build last night
2020-01-09 19:19:21 <Cogitri> So it's a runtime failure, got it
2020-01-09 19:27:43 <Cogitri> Hm, I guess it's best to ask upstream about it
2020-01-09 19:29:32 <Cogitri> Just for curiosity: Could you try w/ CLang?
2020-01-09 19:29:53 <Cogitri> Since I don't have an armv7 machine I have a hard time debugging runtime bugs on it
2020-01-09 19:32:23 <Cogitri> But since we don't have a -dbg subpackage for FF it will be next to impossible to debug this
2020-01-09 19:33:15 <kaey> add "!strip" to it?
2020-01-09 19:36:45 <Cogitri> More like adding -g to our C{,XX,PP}FLAGS and adding a -dbg subpkg
2020-01-09 19:37:26 <Cogitri> https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/13 by the way :)
2020-01-09 19:37:47 <Cogitri> Right now we either don't offer -dbg packages or they're kind of defunct usually
2020-01-09 19:41:36 <kaey> Since we have -dbg packages I kind of assumed they are built with -g
2020-01-09 19:44:45 <Cogitri> No, they're not as of now
2020-01-09 19:45:10 <Cogitri> We just hope the build system does -g or we have a defunct -dbg packages right now AFAICS
2020-01-09 19:45:56 <Cogitri> Unless the builders have some different flags, but at least for packages build with the default configuration of abuild this holds true
2020-01-09 19:51:15 <Cogitri> ddevault: I'll go ahead and disable alertmanager on aarch64 for now, okay?
2020-01-09 19:51:51 <ddevault> let's just get a better patch in
2020-01-09 19:51:55 <kaey> i've replied on ml about alertmanager just now
2020-01-09 19:51:55 <ddevault> chillax my friend
2020-01-09 19:52:23 <ddevault> testing new patch now
2020-01-09 19:52:35 <ddevault> works, preparing for ML
2020-01-09 19:52:54 <ddevault> thanks kaey
2020-01-09 19:52:55 <Cogitri> Alright, good
2020-01-09 20:08:33 <mps> Cogitri: sorry, I was AFK
2020-01-09 20:09:14 <Cogitri> No worries :)
2020-01-09 20:09:22 <mps> and now don't have time to build FF again for armv7 with clang, hope will find time tomorrow
2020-01-09 20:10:25 <mps> and, also I think it is for upstream report
2020-01-10 11:22:24 <walbon> sull
2020-01-10 11:45:25 <ncopa> PureTryOut[m]: re d33b26afd532c021810d466a6c1a229d6e187ca3
2020-01-10 11:45:43 <ncopa> do i understand it correctly that it does not work in any setup?
2020-01-10 11:45:58 <ncopa> why does not the `make check` capture it?
2020-01-10 12:27:02 <ncopa> do we build our armv7 with neon support?
2020-01-10 12:28:57 <ncopa> i guess not
2020-01-10 12:29:08 <ncopa> i think neon is armv8, right?
2020-01-10 12:30:47 <mps> kernel or userspace?
2020-01-10 12:32:18 <mps> I build my kernels for armv7 with neon always enabled
2020-01-10 12:32:54 <ncopa> userspace
2020-01-10 12:32:59 <ncopa> im looking at nss build
2020-01-10 12:33:14 <ncopa> apparently they assume armv8 for 32 bit arm
2020-01-10 12:33:35 <ncopa> then they explictly set -mfpu=neon
2020-01-10 12:34:01 <ncopa> but dont set it when compile gcm.c
2020-01-10 12:34:15 <ncopa> this commit breaks nss build on armv7: https://github.com/nss-dev/nss/commit/77924fef97a0f4c6a319db896cfc2b18f7d8a49b
2020-01-10 12:34:56 <ncopa> problem is here: https://github.com/nss-dev/nss/commit/77924fef97a0f4c6a319db896cfc2b18f7d8a49b#diff-eb06307b930d20d3df7c636bec101076R24
2020-01-10 12:35:25 <ncopa> they #define USE_ARM_GCM when __ARM_NEON is set
2020-01-10 12:35:53 <ncopa> which it is not on our armv7
2020-01-10 12:35:56 <ncopa> $ gcc -dM -E - < /dev/null| grep ARM_NEON
2020-01-10 12:36:24 <mps> hmm, not sure but looks like this could break
2020-01-10 12:36:41 <ncopa> problem is that they have NEON optimized functions
2020-01-10 12:36:53 <ncopa> which are enabled for all arm32 bit
2020-01-10 12:37:08 <ncopa> but they dont disable the unoptimized variants
2020-01-10 12:37:16 <ncopa> so both gets compiled
2020-01-10 12:37:43 <ncopa> but looking at that make file, they enable armv8 stuff on all 32 bit arm
2020-01-10 12:38:03 <mps> yes, I see
2020-01-10 12:38:05 <ncopa> i guess that works for things like rpi3 and rpi4
2020-01-10 12:38:12 <ncopa> which are armv8
2020-01-10 12:38:36 <ncopa> but i wonder if we want enable armv8 stuff for our ARCH=armv7
2020-01-10 12:38:56 <mps> NEON optimized could work for some armv7 cpus
2020-01-10 12:39:15 <ncopa> armv7 cpus with NEON
2020-01-10 12:39:21 <ncopa> i suppose
2020-01-10 12:39:26 <mps> but doubt it could work for all
2020-01-10 12:39:53 <ncopa> so my question is, do we want build nss with NEON or not
2020-01-10 12:39:57 <ncopa> for armv7
2020-01-10 12:39:58 <mps> yes, from the head, some armv7 have neon 'extension'
2020-01-10 12:40:26 <mps> personally, I would like your idea :)
2020-01-10 12:40:53 <ncopa> my idea?
2020-01-10 12:40:56 <mps> my exynos chromebook (armv7) works very fine
2020-01-10 12:41:08 <mps> ok, your doubt
2020-01-10 12:41:20 <mps> 'so my question is, do we want build nss with NEON or not'
2020-01-10 12:41:27 <minecrell> Ideally there would be some runtime fallback
2020-01-10 12:43:27 <mps> ok, I think NEON can be enabled for armv7 (but not 100% sure, TBH)
2020-01-10 12:43:59 <ncopa> minecrell: agree
2020-01-10 12:44:39 <ncopa> they apparently already do that for nss
2020-01-10 12:45:59 <minecrell> I would say "most" armv7 will have some form of NEON, but it's an optional extension so you can't say it in general. On the other hand, disabling it completely probably disables much needed performance optimizations
2020-01-10 12:46:15 <minecrell> then again, even the FPU seems optional for armv7, so you really can't cover everything :)
2020-01-10 12:46:58 <mps> yes, with armv7 making distro is not easy task
2020-01-10 12:47:38 <mps> with arm, to be more precise, though 64bit are better
2020-01-10 12:50:26 <ncopa> ok, lets keep neon enabled for nss
2020-01-10 12:51:21 <mps> :)
2020-01-10 13:25:29 <clandmeter> What about armhf?
2020-01-10 13:26:03 <clandmeter> Could a user without neon use that instead?
2020-01-10 13:30:08 <mps> as minecrell pointed, runtime fallback would be nice to have
2020-01-10 13:31:29 <mps> looks like a lot of upstream don't care much about older ARMs nowadays
2020-01-10 13:36:50 <Cogitri> Well, if you don't have such hardware it's hard to keep up with all the different ARM stuff
2020-01-10 13:37:41 <mps> yes, sometimes I use term 'ARM jungle'
2020-01-10 13:46:10 <mps> nmeum: sorry to bothering you, did you worked on firefox-esr upgrade for 3.11
2020-01-10 13:46:46 <mps> I started to test it and looks like same patch for edge can be cleanly applied
2020-01-10 13:47:23 <nmeum> yeah, that's what I was thinking as well
2020-01-10 13:47:43 <nmeum> we could just cherry pick it
2020-01-10 13:47:51 <nmeum> I didn't get around to running a test build though
2020-01-10 13:47:51 <mps> if you don't have time I can try to build it in lxc
2020-01-10 13:48:12 <nmeum> if you don't mind, I think I won't manage to do it today
2020-01-10 13:48:25 <mps> ok, I will try now
2020-01-10 13:48:30 <nmeum> ok, thanks a lot
2020-01-10 13:48:38 <nmeum> if it builds fine let me know and I will cherry pick it to the stable branch
2020-01-10 13:49:14 <mps> ofc
2020-01-10 13:52:46 <nmeum> thanks!
2020-01-10 13:54:17 <mps> np :)
2020-01-10 14:15:32 <clandmeter> is there already an issue with the sudo warnings?
2020-01-10 14:15:49 <clandmeter> s/with/for
2020-01-10 14:15:49 <alpine-meetbot> clandmeter meant to say: is there already an issue for the sudo warnings?
2020-01-10 14:22:58 <PureTryOut[m]> ncopa: as far as we tested it on pmOS (on Qemu, and several actual armhf (and armv7 even with a armhf userspace) devices), yeah it's broken on any setup
2020-01-10 14:23:06 <PureTryOut[m]> Why `make check` doesn't capture it, no clue
2020-01-10 14:23:37 <PureTryOut[m]> You can read the Qt bug report I mentioned in the commit for more details
2020-01-10 14:34:47 <MartijnBraam> I'm trying to make some packages now on alpine instead of in postmarketOS and am running into an issue on the abuild checksum step
2020-01-10 14:34:50 <MartijnBraam> https://paste.sr.ht/%7Emartijnbraam/45c94f6ad0da0571aab8fa7d716b91cbdb62164f
2020-01-10 14:37:27 <PureTryOut[m]> Tip: if you don't already, use docker-abuild
2020-01-10 14:38:41 <MartijnBraam> no
2020-01-10 14:38:51 <MartijnBraam> I won't install docker
2020-01-10 14:42:53 <clandmeter> install podman :)
2020-01-10 14:43:53 <ddevault>  /b stew
2020-01-10 14:43:56 <PureTryOut[m]> Well, that's your decision then, docker-abuild makes stuff a whole lot easier
2020-01-10 14:43:56 <ddevault> disregard last
2020-01-10 14:44:21 <MartijnBraam> lol
2020-01-10 14:44:43 <ddevault> MartijnBraam: I hit this too
2020-01-10 14:44:51 <ddevault> chown -R abuild:abuild /var/cache/distfiles
2020-01-10 14:44:59 <ddevault> chmod -R g+rX /var/cache/distfiles
2020-01-10 14:45:00 <MartijnBraam> see
2020-01-10 14:45:11 <MartijnBraam> there must be a solution not using containers as a workaround
2020-01-10 14:45:14 <ddevault> err, use chgrp for that first command, not chown
2020-01-10 14:45:50 <clandmeter> and make sure you are in abuild group
2020-01-10 14:45:55 <ddevault> that too
2020-01-10 14:46:02 <ddevault> and log out and back in to make group changes take effect
2020-01-10 14:46:29 <MartijnBraam> you build using a seperate user?
2020-01-10 14:46:36 <ddevault> no
2020-01-10 14:46:39 <ddevault> just put your user in the abuild group
2020-01-10 14:46:47 <ddevault> on linux group membership changes require the affected user to relog
2020-01-10 14:47:00 <MartijnBraam> abuild:abuild implies the abuild user exists :)
2020-01-10 14:47:10 <ddevault> which is why I corrected myself
2020-01-10 14:47:35 <MartijnBraam> oh that group is already set up
2020-01-10 14:47:51 <mps> adduser user abuild, is enough, ime
2020-01-10 14:48:01 <clandmeter> but docker-abuild is kind of nice, if you want to build cross arches.
2020-01-10 14:48:27 <MartijnBraam> If I want to containerize builds for multiarch I just use pmbootstrap :)
2020-01-10 14:48:40 <ddevault> "docker-$anything is kind of nice" is a tautological falsehood
2020-01-10 14:48:41 <MartijnBraam> s/container/chroot
2020-01-10 14:48:41 <alpine-meetbot> MartijnBraam meant to say: If I want to chrootize builds for multiarch I just use pmbootstrap :)
2020-01-10 14:48:54 <MartijnBraam> lol
2020-01-10 14:52:02 <MartijnBraam> it works now :)
2020-01-10 14:57:53 <Cogitri> MartijnBraam: You van use rootbld instead of docket if you want
2020-01-10 14:58:19 <Cogitri> s/van/can/
2020-01-10 14:58:19 <alpine-meetbot> Cogitri meant to say: MartijnBraam: You can use rootbld instead of docket if you want
2020-01-10 14:59:00 <MartijnBraam> hmm that looks interesting
2020-01-10 14:59:27 <Cogitri> Yup, it's pretty nifty but I still use Docker since that's way faster for me
2020-01-10 15:04:15 <fredrigu_> Hi, so I'm having trouble creating an apk package. I'm using the following script: https://paste.ubuntu.com/p/SPW9RV6f4P/
2020-01-10 15:04:28 <fredrigu_> it works and the result is correct. But the generation is way too slow
2020-01-10 15:04:58 <fredrigu_> any ideas on how to speed up this?
2020-01-10 15:10:45 <ncopa> clandmeter: yes non-neon could use armhf. good point
2020-01-10 15:11:50 <fredrigu_> (also added this as a stackoverflow https://stackoverflow.com/questions/59684341/alpine-linux-create-a-apk-package )
2020-01-10 15:12:12 <ncopa> fredrigu_: you can use pigz instead of gzip to utilize more cpus during compression
2020-01-10 15:13:07 <fredrigu_> ncopa: thanks!
2020-01-10 15:15:25 <ncopa> fredrigu_: i think that fabled has a C version of package creation on the roadmap
2020-01-10 15:15:48 <fredrigu_> ncopa: good to know, perhaps helping him with that is the best way to go
2020-01-10 15:15:49 <ncopa> in addition to new apk format
2020-01-10 15:15:57 <ncopa> yeah
2020-01-10 15:16:41 <fredrigu_> but I need to show progress on my work pretty soon, so I think trying to remove the last cat-line and adding pigz could give me something good enough for now
2020-01-10 15:23:38 <ncopa> not sure how you could get rid of the last cat-line
2020-01-10 15:27:36 <ncopa> we add checksum and signature of the data to the beginning of the .apk so i think its difficult to avoid reading/writing the data twice
2020-01-10 15:28:11 <ncopa> i suppose you could keep it in memory, but then you could as well use tmpfs
2020-01-10 15:41:52 <fredrigu_> ncopa: I was thinking about combining the first and last line. So that I've a control.tar.gz that I append the data.tar.gz to
2020-01-10 15:55:03 <mps> https://gitlab.alpinelinux.org/alpine/alpine-conf/commit/c2275905471687b0cf2470edc20d25f2192b8250
2020-01-10 15:55:43 <mps> this commit introduced issue with 'lbu commit -e'
2020-01-10 15:57:01 <mps> 'enc -ciphers' should be 'list --cipher-commands'
2020-01-10 15:58:03 <mps> probably need more cleanup but I would left this for someone experienced in POSIX shell
2020-01-10 15:58:05 <fredrigu_> ncopa: thanks for answering on stackoverflow as well
2020-01-10 15:59:20 <mps> here is openssl issue https://github.com/elasticdog/transcrypt/pull/48
2020-01-10 16:05:15 <ncopa> hum
2020-01-10 16:05:30 <ncopa> nss on armhf also gets neon support
2020-01-10 16:05:40 <ncopa> which probably is not what we want
2020-01-10 16:05:56 <ncopa> i guess there are not many armv6 board with neon support
2020-01-10 16:12:50 <Cogitri> ncopa: Sorry to distract but how do you feel of merging !2881 for now until someone made a proper fix for the thing?
2020-01-10 16:20:00 <ncopa> Cogitri: i feel its a bit hackish and i suspect there are other packages that may get some problem
2020-01-10 16:20:11 <minecrell> ncopa: NEON was introduced with armv7 afaik, so there should be not a single armv6 board with NEON support
2020-01-10 16:20:33 <ncopa> Cogitri: i would have preferred to solve it from the library instead of from the app linking to it
2020-01-10 16:20:53 <ncopa> but otoh, i dont have time to look at it, so i'm ok to push it as is for now
2020-01-10 16:21:23 <ncopa> long term solution is to fix it upstream, making it iterative instead of recursive
2020-01-10 16:26:17 <PureTryOut[m]> Why does the linter complain about HOSTCC variables in APKBUILDs (it being capitalized and not prefixed with _)? It's used in basically every kernel package and overrides the same variable on the building system, so it isn't custom
2020-01-10 16:27:07 <_ikke_> What part is complaining?
2020-01-10 16:27:42 <_ikke_> We whitelisted some variables, but perhaps forgot that one
2020-01-10 16:29:07 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/IYhaGgCGJjfmdhrUGfueiwDl >

2020-01-10 16:29:15 <PureTryOut[m]> Actually it's just complaining about it not being prefixed with a _, sorry
2020-01-10 16:29:44 <_ikke_> yes, that means it's not whitelisted
2020-01-10 16:29:53 <_ikke_> keyword is 'custom'
2020-01-10 16:30:29 <PureTryOut[m]> Could it be whitelisted then?
2020-01-10 16:30:45 <_ikke_> yes
2020-01-10 16:30:59 <north1> problably yes, i remember whitelisting some variables like that
2020-01-10 16:31:08 <_ikke_> https://gitlab.alpinelinux.org/Leo/atools/
2020-01-10 16:31:12 <north1> it also can't detect usage of cat <<- EOF
2020-01-10 16:31:27 <north1> very annoying when it hits one
2020-01-10 16:45:32 <Cogitri> ncopa: Yup, I'll try looking into it after exams :)
2020-01-10 16:50:18 <north1> any opinions on !2816 ? @everyone
2020-01-10 17:07:57 <mps> north1: there is mentioned build mesa few times, I'm for that solution if someone would make this :)
2020-01-10 17:41:48 <Cogitri> Is the commit msg for !2916 fine?
2020-01-10 17:42:47 <_ikke_> Cogitri: it is okay, but does not render well in markdown
2020-01-10 17:43:07 <_ikke_> community/py3-ufolib2: move from community -> move from testing?
2020-01-10 17:43:28 <ncopa> north1: was not aware of the mesa megadrivers
2020-01-10 17:43:29 <Cogitri> Oh, oops
2020-01-10 17:43:40 <Cogitri> That part was autogenerated by my git hooks
2020-01-10 17:43:42 <ncopa> yes we should definitively merge them
2020-01-10 17:43:48 <Cogitri> Good catch, thanks, ikke
2020-01-10 17:44:06 <_ikke_> Cogitri: if you want to fix markdown: either use an actual list (prefixed with '- ') or add 2 spaces after each item
2020-01-10 17:45:24 <Cogitri> Too late now, I suppose
2020-01-10 17:45:36 <_ikke_> not a big issue
2020-01-10 17:45:37 <Cogitri> Does Markdown format-ability matter for commits?
2020-01-10 17:45:45 <_ikke_> only if you watch them in gitlab
2020-01-10 17:45:59 <Cogitri> Also, maybe you can give !2841 a look since you're here, ncopa? :)
2020-01-10 17:46:08 <_ikke_> I guess it matters when it's used for the merge request description
2020-01-10 17:46:25 <_ikke_> If you read the actual commit message it's already
2020-01-10 17:47:12 <_ikke_> Cogitri: I fixed the description :)
2020-01-10 17:49:58 <Cogitri> Thanks :)
2020-01-10 17:53:12 <minecrell> ncopa: but will only "provides" make apk replace the old packages when upgrading? https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#replaces suggests that's what replaces is for
2020-01-10 17:53:21 <minecrell> but the whole replaces/provides stuff is very confusing for me
2020-01-10 18:21:34 <ncopa> yes, provides should make apk replace the old package
2020-01-10 18:21:59 <ncopa> replaces give apk permissions for one package to take over ownership of files
2020-01-10 18:23:07 <mps> ^ this sentence should go to APKNUILD man page
2020-01-10 18:25:56 <mps> I need advice for !2212
2020-01-10 18:26:51 <mps> delete /etc/iwd/main.conf, try to rewrite it, or inform user on upgrade to fix it manually
2020-01-10 18:27:22 <minecrell> ncopa: And what does "take over ownership of files" mean? mesa-dri-gallium contains all the files for the packages it replaces, so shouldn't it take over them?
2020-01-10 19:54:12 <mps> nmeum: ping
2020-01-10 21:12:56 <mps> looks like he is not online
2020-01-10 21:14:27 <mps> finished firefox-esr 68.4.1 for 3.11 on x86_64, built fine and works fine. I think it could be pushed
2020-01-10 21:16:13 <mps> only commit msg should be changed from 'See #11118' to 'fixes: #11118'
2020-01-10 21:18:35 <_ikke_> oh, that one is confidential
2020-01-10 21:20:41 <mps> oh, sorry. but it is mentioned in edge push
2020-01-10 21:21:14 <mps> (and this CVEs are public for some days already)
2020-01-10 21:21:35 <_ikke_> I was just wondering why algitbot could not find it
2020-01-10 23:17:34 <north1> cargo --features is weird
2020-01-11 08:36:04 <nmeum> mps: pong (sorry was afk yesterday evening). did firefox-esr pass on 3.11?
2020-01-11 08:48:23 <mps> nmeum: np
2020-01-11 08:48:39 <mps> yes, it pass and works fine
2020-01-11 08:49:13 <mps> I installed it on one notebook yesterday and it works without
2020-01-11 08:49:48 <mps> small note: only commit msg should be changed from 'See #11118' to 'fixes: #11118'
2020-01-11 08:50:42 <mps> I will be afk for about 5 hours
2020-01-11 08:50:57 <nmeum> mps: ok, thanks a lot will cherry pick it to 3.11-stable now
2020-01-11 08:52:43 <mps> yes, that it what I did, but 'cherry picked' by hand. time for me to relearn cherry picking :)
2020-01-11 08:52:59 <nmeum> pushed, thanks
2020-01-11 08:53:00 <mps> see you, have to go
2020-01-11 08:53:09 <nmeum> bye
2020-01-11 08:53:14 <nmeum> thanks a lot for testing the change :)
2020-01-11 08:53:26 <mps> np
2020-01-11 09:58:03 <minecrell> ncopa: Ah, I guess you're referring to this: https://gitlab.alpinelinux.org/alpine/apk-tools/blob/67696b2ac658ddea036a2b6b284df993c8363222/src/database.c#L2499-2501 Since the packages remain in the same origin (mesa), there is no replaces needed
2020-01-11 09:58:08 <minecrell> I removed the replaces from https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2816
2020-01-11 11:31:24 <Cogitri> Have you fixed 3.11 CI already, ikke?
2020-01-11 12:10:45 <_ikke_> Cogitri: ah, not yet. What was the issue again?
2020-01-11 12:14:57 <_ikke_> ah yeah, that testing is used for stable branches
2020-01-11 12:15:42 <Cogitri> Yup
2020-01-11 12:15:43 <Cogitri> No worries, just curious
2020-01-11 12:15:59 <_ikke_> I forgot about it, making an issue for it
2020-01-11 12:17:20 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10670
2020-01-11 14:01:23 <Cogitri> Thanks
2020-01-11 15:39:56 <mps> I was in hurry (obviously) at '09:49 mps| I installed it on one notebook yesterday and it works without'. should be ... without problem :0
2020-01-11 15:40:11 <mps> :)
2020-01-11 16:46:11 <paper_> why is alpine using EUI64 by default? even windows vista uses random IPv6 link-local addresses
2020-01-11 16:47:44 <paper_> if someone doesn't know, the problem with EUI64 is that it uses the device's MAC to generate the IP. This means packets can be traced to a specific HW
2020-01-11 16:48:09 <paper_> (only on a local network)
2020-01-11 16:59:04 <paper_> ls
2020-01-11 17:07:08 <MY-R> paper_, https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/alpine-baselayout/APKBUILD#L180
2020-01-11 17:07:44 <MY-R> using but not on your current interface since nobody know what name the interface will have
2020-01-11 17:08:19 <MY-R> ex. net.ipv6.conf.eth0.use_tempaddr
2020-01-11 17:08:36 <MY-R> but not all devices got eth0 so somebody would have to write some script...
2020-01-11 17:11:30 <MY-R> paper_, and even here it is explained: https://wiki.alpinelinux.org/wiki/Sysctl.conf
2020-01-11 17:14:30 <paper_> aha, it's per-interface
2020-01-11 17:17:58 <paper_> hmm... on void there isn't anything like this and I still get random addresses
2020-01-11 17:18:16 <MY-R> and if you want rly random BUT stable (survive reboots) ipv6 address then better use "use_tempaddr" together with generated "stable_secret" so your real MAC address will never leak
2020-01-11 17:21:16 <MY-R> paper_, cus they just using script when interface going up, you can do same: https://github.com/void-linux/void-packages/blob/master/srcpkgs/ppp/files/ipv6-up.d.iface-config.sh
2020-01-11 17:22:36 <MY-R> well, it is for ppp but probably got something like that
2020-01-11 17:24:55 <paper_> hmm... interesting, thanks
2020-01-11 18:45:36 <mps> how to make changes in alpine-conf repo over gl.a.o? same as with aports?
2020-01-11 18:46:10 <mps> i.e. fork, clone, push to forked repo?
2020-01-11 18:47:25 <_ikke_> If you want to make a merge request, then yes
2020-01-11 18:47:29 <_ikke_> it would be the same for every repo
2020-01-11 18:48:03 <mps> yes, MR. looks like I don't have push rights to alpine-conf
2020-01-11 18:49:57 <_ikke_> on git.a.o?
2020-01-11 18:50:05 <mps> yes
2020-01-11 18:51:31 <_ikke_> No, you have not
2020-01-11 18:52:12 <mps> though I would prefer to make patch and post it to paste, if someone is ready to review and push :)
2020-01-11 18:52:22 <mps> tpaste*
2020-01-11 18:52:50 <_ikke_> a MR is easier to reply on
2020-01-11 18:53:52 <mps> hm, yes, but fork, clone, push etc (a lot of things to do for one line change)
2020-01-11 18:54:32 <_ikke_> If it's a oneline change, you could do it directly in gitlab
2020-01-11 18:54:42 <_ikke_> in the web interface
2020-01-11 18:55:00 <mps> true, forgot that
2020-01-11 18:55:39 <mps> but, anyway have make fork of repo alpine-conf?
2020-01-11 18:55:51 <_ikke_> yes
2020-01-11 18:56:20 <mps> hmm, will see
2020-01-11 18:56:38 <mps> _ikke_: thanks for explanation and help
2020-01-11 18:57:02 <_ikke_> I think for a lot of these side repos, we could add trusted users as developers and protect master
2020-01-11 18:57:15 <_ikke_> then they can make merge requests directly on the main project, no need for forks
2020-01-11 18:57:27 <_ikke_> (side repos as in repos besides aports)
2020-01-11 18:58:43 <mps> I expect this will be done when gitlab.a.o become master
2020-01-11 18:59:17 <_ikke_> THis could done even before that
2020-01-11 18:59:35 <_ikke_> assuming that gitlab is the cannonical source for those projects
2020-01-11 19:01:26 <mps> is it already?
2020-01-11 19:03:19 <_ikke_> I don't think so yet
2020-01-11 19:03:39 <_ikke_> We need something to sync the other way around
2020-01-11 19:04:12 <mps> hm, a lot of work
2020-01-11 19:05:03 <mps> I would move to gitlab as cannonical and drop git.a.o, but I'm not you :)
2020-01-11 19:05:26 <mps> you know this better
2020-01-11 19:11:59 <_ikke_> Challenge for aports is that we want to be able to limit who can push to main
2020-01-11 19:15:29 <mps> I thought that GL have this option, and now I know I was wrong
2020-01-11 19:16:41 <_ikke_> You can limit based on branches, not based on the directory being pushed to
2020-01-11 19:17:33 <mps> I learned this from your discussion on -infra
2020-01-11 19:32:30 <_ikke_> Ugh, my wireless network card seems to have some issues
2020-01-11 19:32:52 <_ikke_> I had to remove/rescan it through PCI before was recognized again
2020-01-11 19:37:40 <_ikke_> at least I found a way to fix it without rebooting
2020-01-11 19:48:29 <mps> notebook?
2020-01-11 19:50:22 <_ikke_> yes
2020-01-11 19:52:07 <mps> on #iwd channel I read that some people buy usb wifi because their included in notebooks much too problematic
2020-01-11 19:53:53 <mps> I'm lucky because I use two chromebooks which are made to run linux kernel so don't have much issues with wifi
2020-01-11 19:57:12 <_ikke_> It used to be perfectly stable
2020-01-11 20:03:18 <mps> driver changes then could be cause, if not electronics in it damaged
2020-01-11 20:06:49 <_ikke_> yeah, either one of those
2020-01-12 07:44:56 <_ikke_> Seems docker hub is broken, it no longer returns any images
2020-01-12 07:45:21 <_ikke_> https://hub.docker.com/_/alpine/ (found from search) is returning a 404
2020-01-12 08:54:10 <markand> hello
2020-01-12 08:59:19 <markand> is this address deprecated? https://wiki.alpinelinux.org/wiki/Creating_patches#Only_the_last_commit_with_.27git_send-email.27
2020-01-12 08:59:38 <markand> because the new address seems to be ~alpine/aports@ instead
2020-01-12 09:14:17 <markand> nvm, it looks like the old is aliased, isn't it? so I've sent a package two times, is it possible to discard one? https://lists.alpinelinux.org/~alpine/aports/patches/3223
2020-01-12 09:29:17 <mps> markand: looks good, though I would use 'papirus' and not 'Papirus' (small caps) in description. and does 'for Linux' needed? Alpine is Linux by default
2020-01-12 09:39:38 <markand> I just verbatim copied the project description, should I send a v2?
2020-01-12 09:41:15 <mps> I thought so (about description)
2020-01-12 09:42:35 <mps> I can change it with amend option if you agree with my sugestion, and ofc you can always send v2 (and more if you want :) )
2020-01-12 09:43:16 <markand> no you can do it because I'm still searching the git equivalent of hg email --flag v2 :P
2020-01-12 09:43:39 <markand> I have dozen of ports to package to complete my alpine desktop :-)
2020-01-12 09:47:12 <mps> sorry, meant to say 'change it and commit with amend option before push to aports'
2020-01-12 09:50:54 <markand> yes I agree with your suggestion :)
2020-01-12 09:51:20 <mps> ok, let me find url of your post :)
2020-01-12 09:54:33 <mps> oh, you posted it to community. this will not work except in special cases. it must go to testing first
2020-01-12 09:57:43 <mps> (though, it would be easier to follow over gitlab.a.o)
2020-01-12 09:59:32 <markand> okay
2020-01-12 09:59:51 <markand> I'll do there instead then
2020-01-12 10:02:53 <mps> do what is easier for you
2020-01-12 10:03:11 <mps> I just expressed my preference :)
2020-01-12 10:04:35 <mps> gitlab has CI which checks APKBUILD syntax, build pkg and we can see if there are errors or it fine
2020-01-12 10:09:23 <mps> markand: re "tiled", you don't have to repeat pkgs from makedepends in depends. abuild scans dependant libs and add them automatically
2020-01-12 11:21:45 <markand> so I just add the non -dev in depends or the opposite?
2020-01-12 11:25:30 <_ikke_> Opoositw
2020-01-12 11:26:01 <_ikke_> Add the -dev packages to makedepends, leave them out of depends
2020-01-12 11:26:28 <markand> okay thanks
2020-01-12 11:26:33 <_ikke_> This ofcourse only counts for sodeps
2020-01-12 11:26:57 <russkel> what is the reason behind the -libs subpkg?
2020-01-12 11:47:47 <markand> mps, updated according to your comments and merge requests sent to gitlab
2020-01-12 11:53:42 <mps> markand: https://gitlab.alpinelinux.org/markand/aports/-/jobs/34904
2020-01-12 11:54:14 <mps> pkgver="20200102"
2020-01-12 12:00:13 <mps> looks like s390x CI is stuck
2020-01-12 12:03:12 <mps> markand: pushed with fixing pkgver
2020-01-12 12:06:00 <markand> thanks <3
2020-01-12 12:06:12 <markand> my first contrib \o/
2020-01-12 12:06:31 <markand> next is wesnoth
2020-01-12 12:07:23 <mps> isn't next tiled
2020-01-12 12:07:56 <markand> yes but it's proposed, wesnoth has to be tested yet (and is much more complex)
2020-01-12 12:09:09 <mps> tiled failed on CI, make[1]: /usr/lib/qt5/bin/lrelease: Command not found
2020-01-12 12:10:12 <mps> qt5-qttools-dev should be added to makedepends
2020-01-12 12:11:58 <mps> and pkgver="1.3.1", num literal must be without quotes
2020-01-12 12:13:24 <mps> and small nitpcik, pkgdesc="A powerful tile map editor", s/^A\ //
2020-01-12 12:13:45 <mps> nitpick*
2020-01-12 12:14:58 <mps> this reminds me about George Bernard Show 'Fresh fish sold here' anecdote
2020-01-12 12:15:18 <markand> ?
2020-01-12 12:16:40 <mps> s/Show/Shaw/
2020-01-12 12:16:40 <alpine-meetbot> mps meant to say: this reminds me about George Bernard Shaw 'Fresh fish sold here' anecdote
2020-01-12 12:41:58 <russkel> so openblas-dev has no BLAS header files
2020-01-12 12:42:06 <russkel> but blas-dev does?
2020-01-12 12:47:39 <russkel> https://git.alpinelinux.org/aports/tree/community/openblas/APKBUILD
2020-01-12 12:48:10 <russkel> and according to the git repo https://github.com/xianyi/OpenBLAS they are there in the root directory
2020-01-12 12:52:09 <russkel> okay so apparently it's not installing those headers because NO_BLAS=1
2020-01-12 12:53:53 <mps> hm, why we have blas and openblas in repo
2020-01-12 12:57:06 <russkel> there's no comments as to why it's disabled...
2020-01-12 12:57:22 <russkel> isn't it kind of useless without the header files?
2020-01-12 12:58:38 <mps> ah, blas is subpg of lapack
2020-01-12 13:06:37 <russkel> what do we do mr. mps ?
2020-01-12 13:13:30 <_ikke_> https://undeadly.org/cgi?action=article;sid=20200109141600
2020-01-12 13:14:09 <_ikke_> tldr; openbsd maintainer for firefox won't upgrade it due to being too uplicated
2020-01-12 13:14:15 <russkel> :o
2020-01-12 13:14:20 <_ikke_> (suggests to use firefox-esr)
2020-01-12 13:14:29 <_ikke_> too complicated*
2020-01-12 13:14:48 <russkel> what does testing all rust consumers mean?
2020-01-12 13:16:47 <_ikke_> No idea myself
2020-01-12 13:20:53 <russkel> oh god opencv downloads something in its build process
2020-01-12 13:20:56 <russkel> why are you like thissss
2020-01-12 13:23:01 <mps> russkel: I didn't know that the blas is subpackage of lapack package
2020-01-12 13:25:19 <mps> _ikke_: hm, maybe I should try to build FF 68.4.1 for armv7 instead of trying to fix 72.0.1
2020-01-12 13:26:43 <mps> <grumpy mode> yes, rust is nonsensical lang, as is everything from hipsters </grumpy mode>
2020-01-12 13:27:25 <russkel> shake harder boy!
2020-01-12 13:32:45 <russkel> https://github.com/opencv/opencv/issues/15020
2020-01-12 13:33:04 <russkel> I'm getting the same issue as this, and I think it's some musl libc problem
2020-01-12 13:33:23 <russkel>   return __orig_read(__f, __s, __n);
2020-01-12 13:33:49 <russkel> any one seen that before?
2020-01-12 13:50:04 <Cogitri> russkel/ikke: Testing all rust consumers means making sure all packages depending on Rust still build with it
2020-01-12 13:51:30 <PureTryOut[m]> maxice8: as for making the linter ignore HOSTCC, do I just have to put that variable in https://gitlab.alpinelinux.org/PureTryOut/atools/blob/master/apkbuild-lint#L19
2020-01-12 13:51:30 <PureTryOut[m]> ?
2020-01-12 13:52:16 <russkel> Cogitri, ah right
2020-01-12 13:52:29 <russkel> thanks
2020-01-12 13:52:44 <_ikke_> PureTryOut[m]: yes
2020-01-12 13:52:53 <PureTryOut[m]> Cool thanks
2020-01-12 13:52:58 <_ikke_> PureTryOut[m]: there is also a test suite
2020-01-12 13:53:37 <mps> Cogitri: fyi, firefox 72.0.1 built with -mno-aligned-access still faults when run
2020-01-12 13:53:57 <Cogitri> That's unfortunate :/
2020-01-12 13:54:03 <russkel> https://github.com/opencv/opencv/issues/15020#issuecomment-573417463
2020-01-12 13:54:11 <russkel> can anyone offer a hint on this?
2020-01-12 13:54:46 <Cogitri> Have you tried building it with --enable debug, adding a -dbg subpackage to get better debugging info, mps?
2020-01-12 13:55:28 <mps> no, but dmesg is quite informative
2020-01-12 13:56:04 <mps> Alignment error
2020-01-12 13:56:51 <mps> not sure is this a rust or musl issue, although imo, suspect is rust
2020-01-12 13:57:35 <mps> do you think it is worth some effort to try to build 68.4.1 on armv7?
2020-01-12 13:57:56 <mps> find rustc 'target' which could work
2020-01-12 13:59:06 <mps> but now when kernel 5.4.11 out I will be busy with it
2020-01-12 14:00:02 <mps> I think it finally have important fixes for exynos, allwiner, i915 and amd
2020-01-12 14:21:03 <Cogitri> Well, if you had debug info you would know where it fails :)
2020-01-12 14:21:18 <Cogitri> The rust target thingie should just work in ff
2020-01-12 14:21:48 <mps> unaligned access is not allowed on arm32, that's enough I think
2020-01-12 14:29:52 <Cogitri> Yes, but without debugging info you only know that it's happening somewhere in the FF codebase :)
2020-01-12 14:30:13 <mps> true
2020-01-12 14:30:46 <mps> but I don't have time these days to hunt bug
2020-01-12 14:48:39 <mps> hm, just see more 'Alignment trap: AudioIP~ent RPC (30174)' on armv7 not related to firefox
2020-01-12 15:12:42 <markand> not an autotools expert... can I fix my package for these platforms or should I just ban them in arch variable? https://gitlab.alpinelinux.org/markand/aports/-/jobs/34973
2020-01-12 15:14:18 <_ikke_> markand: you can try to add update_config_guess / update_config_sub to prepare()
2020-01-12 15:16:45 <markand> thanks I do this
2020-01-12 15:22:18 <markand> hmmm I've used push --force to amend the change, it looks like the new build still used the previous version though https://gitlab.alpinelinux.org/markand/aports/commit/0c317fc7f98783409855c33596365746b9be05be
2020-01-12 15:23:39 <_ikke_> It should use the latest version
2020-01-12 15:26:34 <markand> ah yes it does, it was just pending :)
2020-01-12 17:57:13 <mps> north1: fyi, kernel 5.4.11 is here https://gitlab.alpinelinux.org/mps/aports/-/jobs/35076/artifacts/raw/packages/main/x86_64/linux-lts-5.4.11-r0.apk
2020-01-12 17:57:48 <north1> oh nice, thanks
2020-01-12 17:58:36 <mps> downloading it and will test in a few minutes
2020-01-12 17:59:08 <mps> hope it will be better (at least to some degree)
2020-01-12 18:03:58 <north1> 5.4.10 didn't crash for a few hours but crashed right in the middle of a game session and it crashed so hard i had to hold the power button (normally have to just press it down once)
2020-01-12 18:04:42 <north1> Actually it crashed so hard that when i turned it on it would be stuck in the DELL bootsplash until i removed the battery and stick it on again
2020-01-12 18:10:06 <mps> for me it doesn't crash but sometimes is too much loaded that it become unresponsive
2020-01-12 18:10:28 <mps> found that adding some swap helps
2020-01-12 18:11:16 <mps> that is, on x86_64 with i915 video driver
2020-01-12 18:11:28 <mps> X, not wayland
2020-01-12 21:46:49 <craftyguy> what are the right parameters to abuild to have it produce an actual apk file? 'abuild package' just installs into pkg, no apk is created
2020-01-12 21:46:59 <craftyguy> abuild -h doesn't show any obvious way to do this
2020-01-12 21:47:13 <mps> abuild rootpkg
2020-01-12 21:47:53 <craftyguy> mps: where are the resulting apks?
2020-01-12 21:48:07 <craftyguy> (they don't appear in pwd)
2020-01-12 21:48:15 <clandmeter> REPODEST
2020-01-12 21:48:22 <mps> abuild -h shows 'rootpkg     Run 'package', the split functions and create apks as fakeroot'
2020-01-12 21:48:36 <craftyguy> ah
2020-01-12 21:48:43 <craftyguy> clandmeter: thanks
2020-01-12 21:48:50 <mps> usually ~/packages/repo/arch
2020-01-12 21:49:05 <_ikke_> abuild -r to do everything
2020-01-12 21:49:27 <_ikke_> it automatically creates a repo even
2020-01-12 21:51:16 <craftyguy> _ikke_: yeah, normally I would, but I want to override the src dir, so basically skip the fetch/prepare steps
2020-01-12 21:55:05 <_ikke_> what is the usecase? abuild allows you to override a lot of things
2020-01-12 21:55:26 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n437
2020-01-12 21:57:37 <craftyguy> _ikke_: bisecting a regression in a package. it has a lot of subpackages so I thought I'd use the apkbuild to do the hard work
2020-01-12 21:57:59 <craftyguy> oh yeah, maybe I can just add a fetch function that is noop
2020-01-12 21:58:26 <_ikke_> craftyguy: oh, right, if your debugging, doing things step by step is good enough
2020-01-13 07:36:05 <rahmanshaber[m]> please i need help on this
2020-01-13 07:36:05 <rahmanshaber[m]> https://cloud.drone.io/alpinelinux/aports/13532/1/1
2020-01-13 07:36:31 <rahmanshaber[m]> 2 package build failed
2020-01-13 08:10:07 <_ikke_> Archlinux is switching to zstd as compression format, with the main benefit being a huge decrease in decompression time (compared to xz, what they were using)
2020-01-13 08:10:17 <_ikke_> (for packages, I mean)
2020-01-13 08:17:12 <Cogitri> rahmanshaber[m]: First off, use Gitlab
2020-01-13 08:17:36 <rahmanshaber[m]> yeah.
2020-01-13 08:19:54 <markand> mps, did you see my answer regarding autoconf -fi on id3lib?
2020-01-13 08:27:20 <mps> markand: no
2020-01-13 08:27:39 <mps> where?
2020-01-13 08:30:39 <markand> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2974#note_62173
2020-01-13 08:31:37 <markand> _ikke_, I also agree with zstd, at work we've switched to it and reduce by almost 50% our load time
2020-01-13 08:32:01 <markand> the only downside : not available in busybox nor busybox's tar
2020-01-13 08:34:21 <mps> markand: ah, I'm not subscribed to this MR so not got mail. I will look later when finish morning 'tasks' (coffee, brandy, mail etc :) )
2020-01-13 08:34:49 <mps> from the head 'autoreconf -vif' is enough
2020-01-13 08:56:08 <markand> yes, but not for id3lib
2020-01-13 09:44:50 <minecrell> ncopa: Is there anything else I should change for the mesa MR (https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2816) or does that look fine to you now?
2020-01-13 09:46:25 <_ikke_> minecrell: TIL about summaries in markdown
2020-01-13 09:46:38 <minecrell> _ikke_: Well, it's just HTML :p
2020-01-13 09:47:20 <_ikke_> hehe, right, didn't know about that
2020-01-13 09:54:56 <Cogitri> Oh my, that's pretty nice indeed
2020-01-13 10:18:28 <mps> north1: is the kernel 5.4.11 better than previous versions, i.e. does it still locks your machine
2020-01-13 10:19:16 <north1> Didn't test yet, will only be able to test it tonight
2020-01-13 10:19:20 <mps> just read 5.5-rc6 log, and looks like fix for i915 landed there
2020-01-13 10:20:55 <mps> and rereading 5.4.11 log, but don't see this fix there (though git log is not 'clear' or I don't understand it)
2020-01-13 10:21:21 <mps> ok, np. had a hope to hear good news :)
2020-01-13 10:22:22 <mps> markand: so 'autoreconf -vif' doesn't work for !2974
2020-01-13 10:26:55 <markand> mps, no, I think the project is too old
2020-01-13 10:27:28 <markand> void/arch use the same preparation
2020-01-13 10:32:17 <mps> does ./configure work?
2020-01-13 10:40:40 <mps> markand: looks like it doesn't work even with void sample
2020-01-13 10:51:05 <mps> markand: 'configure:10393: checking for iomanip.h' ^M configure:10410: error: Missing a vital header file for id3lib
2020-01-13 11:22:56 <markand> yes as said it's an old library
2020-01-13 11:23:01 <markand> there are lots of patches required
2020-01-13 11:23:18 <markand> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2974/diffs#61d246e49835de26bef61b910a71894e91bfca00
2020-01-13 12:09:25 <pltrz> when creating an APKBUILD, can the source be set to do a git clone instead of downloading a tarball?
2020-01-13 12:25:10 <mps> pltrz: APKBUILD is shell script so it is possible to do a lot hacks
2020-01-13 12:25:45 <mps> ofc, if you build pkg for private repo
2020-01-13 12:27:59 <Cogitri> We don't use git clone for the source though
2020-01-13 12:28:03 <Cogitri> Always use tarballs if possible
2020-01-13 12:29:41 <mps> yes, I forgot to add that 'git clone' will not be accepted to alpine
2020-01-13 12:32:07 <mps> pltrz: you can use commit id as a tarball from github
2020-01-13 12:45:02 <pltrz> thx, it is for private use. it's only available from cgit and doesn't have any tags for a tarball :/ no big deal though, I just set the source blank and put the git-clone into prepare()
2020-01-13 14:43:51 <PureTryOut[m]> Is it possible to use docker-abuild to build for different architectures? It does support an architecture argument, but then docker just complains it can't find the manifest
2020-01-13 14:44:17 <_ikke_> docker does not emulate arches
2020-01-13 14:44:49 <z3ntu> PureTryOut: `DABUILD_ARCH=x86|x86_64|aarch64|armhf|armv7. Specifies architecture for build container. Default: $(uname -m).`
2020-01-13 14:44:50 <PureTryOut[m]> I know, which is why I'm asking if docker-build supported something for it (e.g. automatically running the docker container in some VM)
2020-01-13 14:44:53 <z3ntu> needs binfmt set up though
2020-01-13 14:45:01 <_ikke_> right ^
2020-01-13 14:45:02 <PureTryOut[m]> z3ntu: I know, that is what I mentioned
2020-01-13 14:45:13 <Cogitri> That won't work though, z3ntu
2020-01-13 14:45:36 <Cogitri> Ah, IRC bridge took a little to sync up, don't mind me
2020-01-13 14:45:45 <PureTryOut[m]> But I guess it isn't supported then
2020-01-13 14:46:04 <PureTryOut[m]> Cogitri: well you are running Matrix -> IRC -> Matrix, so of course it'll lag a bit lol
2020-01-13 14:47:23 <_ikke_> PureTryOut[m]: https://gitlab.alpinelinux.org/alpine/docker-abuild#configure-multi-arch-support
2020-01-13 14:47:42 <z3ntu> With https://aur.archlinux.org/packages/qemu-arm-static it works fine on Arch Linux, the *.binfmt files are handled by systemd though (yes, no one knows why^^) so they are not 1:1 applicable to Alpine
2020-01-13 14:48:16 <PureTryOut[m]> _ikke_: oh thanks!
2020-01-13 15:31:34 <PureTryOut[m]> Is there a logo of Alpine Linux available in some package?
2020-01-13 15:36:42 <Cogitri> PureTryOut[m]: Yeah, usually the lag isn't too bad though
2020-01-13 15:42:42 <PureTryOut[m]> So I have a package that needs to display the Alpine logo, but where can I get it from?
2020-01-13 16:27:09 <mps> north1: you are kidding with me :)
2020-01-13 16:33:00 <north1> Uh?
2020-01-13 16:33:57 <mps> how did you manage to push mutt so fast
2020-01-13 16:34:36 <mps> I didn't noticed it finish on CI, and see it pushed
2020-01-13 16:36:10 <north1> It was green, commit changes looked alright
2020-01-13 16:36:21 <north1> Just happened to be at the right place at the right time
2020-01-13 16:36:39 <mps> I'm not criticizing you, just surprised (positive) with your speed
2020-01-13 16:40:09 <mps> there is another 'green' :) !3011
2020-01-13 16:41:55 <_ikke_> done :P
2020-01-13 16:42:37 <mps> heh, I see :)
2020-01-13 16:43:04 <mps> marathon started :)
2020-01-13 16:43:27 <markand> while you are all here, can you have a look to eventually close this one? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2974
2020-01-13 16:43:58 <mps> !2974
2020-01-13 16:44:12 <mps> ah, did you finished it
2020-01-13 16:45:53 <mps> did you read guide about using pkgname in source url, sorry for nitpick
2020-01-13 16:46:02 <mps> ttps://sourceforge.net/projects/$pkgname/files/$pkgname/$pkgver/$pkgname-$pkgver.tar.gz
2020-01-13 16:46:33 <markand> yes I've seen the Cogitri comment on the easytag MR, I'll change it
2020-01-13 16:46:36 <mps> instead of var $pkgname you should use literal package name
2020-01-13 16:46:55 <_ikke_> ah, linting misses that because the source url is not on the same line as the variable
2020-01-13 16:47:07 <mps> not a big problem, but anyway
2020-01-13 16:48:41 <markand> -       https://sourceforge.net/projects/$pkgname/files/$pkgname/$pkgver/$pkgname-$pkgver.tar.gz
2020-01-13 16:48:44 <markand> +       http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz
2020-01-13 16:48:47 <markand> correct like this?
2020-01-13 16:48:50 <markand> (according to the wiki guide)
2020-01-13 16:49:12 <_ikke_> s/\$pkgname/id3lib
2020-01-13 16:49:25 <mps> http://downloads.sourceforge.net/id3lib/files/id3lib/
2020-01-13 16:49:46 <markand> okay, we should edit the page, it still mention the old style: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#source
2020-01-13 16:49:46 <AinNero> why tho? i would have used $pkgname per default
2020-01-13 16:50:10 <_ikke_> package name and project name are only incidentally the same
2020-01-13 16:50:11 <mps> well, personally I don't care
2020-01-13 16:50:13 <markand> yeah newapkbuild generated APKBUILDs that are not lint compliant :P
2020-01-13 16:50:26 <markand> e.g. it still uses quotes under pkgver
2020-01-13 16:51:58 <mps> AinNero: there is no 'one size fits all' for these, so I think we should always check these things
2020-01-13 16:56:38 <markand> mps, pushed the source variable update
2020-01-13 16:58:38 <mps> I see, waiting for CI
2020-01-13 17:01:01 <mps> markand: pushed
2020-01-13 19:07:52 <AinNero> mkinitfs does not have a repo on gitlab
2020-01-13 19:15:59 <AinNero> can i have it get cloned to there?
2020-01-13 19:18:03 <_ikke_> yes, but mirroring should be setup at the same time then
2020-01-13 19:18:17 <AinNero> (i cant do either)
2020-01-13 19:27:04 <_ikke_> I can't (don't know how) to do the latter
2020-01-14 06:28:31 <rahmanshaber[m]> do i need to check anytihng here
2020-01-14 06:28:35 <rahmanshaber[m]> 
ACTION uploaded an image: image.png (29KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/xTzYLmDwafQZIntGSRuFVJBE >

2020-01-14 06:35:37 <Cogitri> As of now, no
2020-01-14 06:36:57 <Cogitri> But it's good practice checking the first box (delete source branch) since you won't need that once the thing is merged anyway and the last box (allow maintainers to do commits) so that once we switch to Gitlab as main git repo we can rebase the MR
2020-01-14 06:43:41 <rahmanshaber[m]> Cogitri: thanks.
2020-01-14 06:43:41 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3030
2020-01-14 06:45:08 <rahmanshaber[m]> why this one failed , it is not related to my commit. but other builds fine
2020-01-14 06:45:08 <rahmanshaber[m]> https://gitlab.alpinelinux.org/rahmanshaber/aports/-/jobs/35715
2020-01-14 06:46:27 <rahmanshaber[m]> Cogitri:
2020-01-14 06:54:19 <Cogitri> Ah yes, the s390x CI runner can be a bit funny at times
2020-01-14 06:58:01 <rahmanshaber[m]> Cogitri: ok, then please accept the MR.
2020-01-14 07:03:27 <Cogitri> Maybe someone else will give it a look, currently busy learning for exams
2020-01-14 09:11:03 <markand> hmmm, what did I miss on my system because abuild -r builds fine but ends with: ERROR: APKINDEX.tar.gz: UNTRUSTED signature
2020-01-14 09:17:37 <markand> I've re-ran abuild-keygen -a -i and deleted ~/packages, worked
2020-01-14 09:31:39 <Cogitri> FWIW deleting the APKINDEX and running `abuild index` probably would've done the trick too
2020-01-14 09:34:50 <hrio[m]> Would be nice if !2947 can be reviewed, fixes a boot failure.
2020-01-14 10:11:02 <Cogitri> ncopa: Can you maybe take a look at 2841 later? Most of D blocks on it right now
2020-01-14 10:19:54 <rahmanshaber[m]> someone please accept the MR. All good .
2020-01-14 10:19:55 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3030
2020-01-14 10:22:14 <mps> does it solve any urgent issue?
2020-01-14 10:22:22 <mps> !3030
2020-01-14 10:22:44 <mps> hm, look like commit msg is wrong
2020-01-14 10:24:21 <mps> hmm, sorry, misslead by 'community/c suite:'
2020-01-14 10:25:42 <mps> anyway, could be better reworded
2020-01-14 10:28:39 <rahmanshaber[m]> mps: yes, for postmarketOS.
2020-01-14 10:29:30 <rahmanshaber[m]> Do yyou want me to change anything?
2020-01-14 10:31:12 <mps> not sure, didn't looked deeply, but if you create MR with more pkgs then prefixing it 'community/c suite:' looks missleading to me
2020-01-14 10:32:01 <mps> I looked for pkg 'c suite' :)
2020-01-14 10:33:21 <mps> though particular commits looks fine
2020-01-14 10:45:26 <ncopa> Cogitri: re !2841 why does it fail?
2020-01-14 10:46:56 <ncopa> ah, "due to the ada thing"
2020-01-14 10:48:04 <Cogitri> Yup
2020-01-14 10:48:25 <Cogitri> I've used the resulting binaries for gdc for a few days now and they work pretty good
2020-01-14 10:48:42 <Cogitri> Although long term we probably don't want to use gdc for anything but boostraping ldc/dmd
2020-01-14 10:48:54 <Cogitri> So we don't have to patch it into shape all the time
2020-01-14 10:55:09 <rahmanshaber[m]> mps: all the apps in that MR is called C Suite
2020-01-14 10:56:13 <mps> I thought it is related to C lang, until looked
2020-01-14 10:57:06 <mps> why not core suite, as pkgs are prefixed (though imo core is also not good name for ui pkgs, but ok)
2020-01-14 11:05:38 <mps> how can we trigger MR to go to CI?
2020-01-14 11:05:52 <rahmanshaber[m]> C means CoreApps. and whole name is CoreApps Suite
2020-01-14 11:06:14 <rahmanshaber[m]> https://cubocore.gitlab.io/
2020-01-14 11:06:18 <rahmanshaber[m]> mps:
2020-01-14 11:06:50 <mps> a lot of MR have 'Could not retrieve the pipeline status.'
2020-01-14 11:07:24 <mps> rahmanshaber[m]: 'CoreApps' looks fine to me :)
2020-01-14 11:08:08 <rahmanshaber[m]> done
2020-01-14 11:08:08 <mps> but I'm not one who should tell you how you will name your software
2020-01-14 11:09:42 <mps> problem is that it is not entered CI so not sure will it build on builders
2020-01-14 11:11:12 <rahmanshaber[m]> <mps "problem is that it is not entere"> ohh, so i have to wait/
2020-01-14 11:12:06 <mps> gitlab is upgraded few minutes ago, this can be reason
2020-01-14 12:13:59 <mps> rahmanshaber[m]: MR passed CI
2020-01-14 12:31:22 <rahmanshaber[m]> great.
2020-01-14 13:13:08 <markand> who use D?
2020-01-14 13:13:21 <markand> I mean, are there even packages written in D in the repository?
2020-01-14 13:14:39 <north1> There is corecollector and Tilix
2020-01-14 13:17:53 <Cogitri> and GtkD
2020-01-14 13:24:27 <ncopa> im kinda frustrated of grub
2020-01-14 13:25:32 <ncopa> so, the main driver for grub vs lilo back then was that with grub you didnt need to rewrite the boot loader every time you had a new kernel
2020-01-14 13:25:48 <ncopa> because you could put that in your grub config
2020-01-14 13:25:59 <mps> yes
2020-01-14 13:26:05 <ncopa> now you need to regenerate the grub config every time you do any change
2020-01-14 13:26:19 <mps> really?
2020-01-14 13:26:37 <ncopa> so instead of running lilo after a config chagne you now need to run grub-mkconfig
2020-01-14 13:26:40 <ncopa> yup
2020-01-14 13:26:47 <ncopa> the config is generated nowdays
2020-01-14 13:27:02 <ncopa> and is insanely complex
2020-01-14 13:27:09 <AinNero> its not technically required, but its the ease of use that drives this
2020-01-14 13:27:19 <AinNero> im confident a static grub config would work out for most usecases
2020-01-14 13:27:50 <mps> long time I used it by creating menu file by hand and had to change it rarely
2020-01-14 13:28:39 <mps> ncopa: iirc, you introduced grub from debian
2020-01-14 13:29:09 <ncopa> grub1 was kinda designed to have static menu.lst
2020-01-14 13:29:17 <ncopa> with grub2 things changed dramatically
2020-01-14 13:29:31 <mps> same can be done with grub2
2020-01-14 13:29:46 <ncopa> that is where i am going at
2020-01-14 13:30:03 <ncopa> i am considering write a grub-mkconfig-alpine
2020-01-14 13:30:16 <ncopa> which creates a simplified static grub config
2020-01-14 13:30:24 <mps> where I have grub I disabled auto update it
2020-01-14 13:31:06 <ncopa> the generated config file is so complex that its not even useful as starting point
2020-01-14 13:31:09 <mps> grub-mkconfig-alpine is good idea
2020-01-14 13:31:36 <ncopa> the problem though, is that every existing grub user is expecting grub to be configured in /etc/default/grub
2020-01-14 13:31:52 <ncopa> debina style
2020-01-14 13:31:57 <Cogitri> 
ACTION likes rEFInd for dynamically generating that

2020-01-14 13:31:59 <ncopa> debian*
2020-01-14 13:32:31 <ncopa> the upstream grub-mkconfig does not even work with alpine
2020-01-14 13:32:40 <ncopa> it tries to work everywhere, but it doesnt
2020-01-14 13:33:20 <mps> even on debian (when used it) I trimmed grub.cfg to something readable at a glance and disabled auto update
2020-01-14 13:34:05 <ncopa> i think we need some sort of gerenrator similar to our update-extlinux
2020-01-14 13:34:25 <mps> update-grub
2020-01-14 13:34:47 <ncopa> so you can `apk add linux-$someflavor` and have it added to your boot menu
2020-01-14 13:34:49 <ncopa> also
2020-01-14 13:35:20 <ncopa> figuring out how to set the default kernel to boot in config is overly complex
2020-01-14 13:35:40 <ncopa> https://unix.stackexchange.com/questions/198003/set-default-kernel-in-grub
2020-01-14 13:35:51 <ncopa> which is my current problem
2020-01-14 13:35:55 <mps> some file in etc, like /etc/grub-config?
2020-01-14 13:36:24 <ncopa> im just thinking that the upstream grub-mkconfig is overengineered
2020-01-14 13:37:08 <mps> it is, imo
2020-01-14 13:37:16 <ncopa> i wonder if we could drop it
2020-01-14 13:37:24 <ncopa> and use rEFInd only
2020-01-14 13:37:30 <ncopa> or similar
2020-01-14 13:37:44 <ncopa> the challenge is that there are not bootloader that works on all architectures
2020-01-14 13:37:56 <mps> it is made to cover as most possible corner cases, and because that it is complicated
2020-01-14 13:37:59 <ncopa> grub is the closest you get
2020-01-14 13:38:21 <ncopa> yeah, it tries to solve all cornercases and as a result it fails to solve the simple ones
2020-01-14 13:38:30 <ncopa> without patching it
2020-01-14 13:42:32 <mps> if you make grub-mkconfig for alpine I'm ready to test it
2020-01-14 13:44:26 <Cogitri> Well, rEFInd works on all my machines that have EFI
2020-01-14 13:46:42 <ncopa> hum, i guess we could have an update-grub
2020-01-14 13:47:00 <ncopa> Cogitri: does it work with arm?
2020-01-14 13:47:17 <ncopa> the good thing with grub is that it works on all architectures (except s390x)
2020-01-14 13:51:04 <mps> afaik, grub doesn't work on arm32
2020-01-14 13:51:13 <ncopa> ah
2020-01-14 13:51:15 <ncopa> true
2020-01-14 13:51:17 <ncopa> uboot
2020-01-14 13:52:06 <MY-R> grub-set-default doesnt work?
2020-01-14 13:52:12 <mps> there are some works to run grub from uboot but nothing usable yet, or I didn't found usable version
2020-01-14 13:53:42 <pltrz> hey guys, I built a small C program (slstatus, the statusbar from suckless for dwm). I am having an issue `strftime: Result string exceeds buffer size` from the datetime string. I am still a beginner in C, and don't really understand. Could anyone point me in the right direction? My initial guess is that this has something to do with musl having some kind of different string size limit than
2020-01-14 13:53:45 <pltrz> glibc?
2020-01-14 13:53:48 <mps> but there are some works to boot arm64 with grub, but also I didn't tested it much, only one version under qemu-aarch64
2020-01-14 13:54:22 <ncopa> MY-R: let me try
2020-01-14 13:57:24 <Cogitri> ncopa: Dunno, I only have x86_64 machines
2020-01-14 13:59:08 <ncopa> autoreconf: running: autopoint --force
2020-01-14 13:59:08 <ncopa> tar: This does not look like a tar archive
2020-01-14 13:59:14 <mps> pltrz: last time I built slstatus it worked, on alpine I mean
2020-01-14 13:59:50 <ncopa> argh.. i wanna throw grub out the window...
2020-01-14 14:00:22 <markand> :-)
2020-01-14 14:01:14 <markand> mps, how do you disable auto generation of grub configuration?
2020-01-14 14:02:06 <ncopa> MY-R: no, grub-set-default does not work for me
2020-01-14 14:03:11 <mps> pltrz: yes, tried again to build slstatus, it works fine
2020-01-14 14:04:29 <pltrz> mps: I am able to build it, but when I have date and time configured in config.h it throws that message
2020-01-14 14:04:54 <pltrz> mps: let me try with default config.h and isolate the problem more
2020-01-14 14:06:34 <ncopa> MY-R: i was wrong. grub-set-default seems to work. its just me who is stupid and dont understand how to use it.
2020-01-14 14:06:36 <mps> markand: add 'exit 0' in line 3, file /usr/sbin/grub-mkconfig :)
2020-01-14 14:06:42 <ncopa> the menu needs to be regenerated
2020-01-14 14:09:36 <ncopa> pltrz: can you please share your config.h?
2020-01-14 14:10:30 <MY-R> ncopa, ye need GRUB_DEFAULT=saved and after grub-mkconfig
2020-01-14 14:10:56 <MY-R> and then setting default one is done by that grub-set-default script without regenerating grub.cfg
2020-01-14 14:13:26 <pltrz> ncopa: https://pastebin.com/raw/3TfCXSgp  -  commented out is the default datetime, which confirmed does work, but when I make a slightly more elaborate one it does not. both can be seen in the config.h
2020-01-14 14:16:33 <ncopa> pltrz: that config compiles for me
2020-01-14 14:17:35 <ncopa> ah, its a runtime error
2020-01-14 14:17:58 <pltrz> ncopa: yeah exactly. sorry if I wasn't clear
2020-01-14 14:25:32 <ncopa> ok, i found it
2020-01-14 14:25:48 <ncopa> pltrz: seems like %l is not posix. use %I instead
2020-01-14 14:26:07 <ncopa> use this as reference: https://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html
2020-01-14 14:27:30 <ncopa> and http://man7.org/linux/man-pages/man3/strftime.3.html fails to mention that %l is an extension
2020-01-14 14:30:30 <rahmanshaber[m]> is my MR merged, i am confused
2020-01-14 14:30:30 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3030
2020-01-14 14:31:21 <pltrz> ncopa: ah I see. thanks so much, musl does not include non-posix extensions, correct?
2020-01-14 14:33:09 <ncopa> pltrz: musl implements some extensions but not all
2020-01-14 14:33:39 <ncopa> basically, the only thing you can expect to be implemented are what is defined in the standards
2020-01-14 14:40:43 <mps> rahmanshaber[m]: patience is one of most important developers virtue :)
2020-01-14 14:40:57 <ncopa> rahmanshaber[m]: seems like its not
2020-01-14 14:41:20 <mps> I wanted to push but would like to have you online here
2020-01-14 14:41:36 <mps> in case it fails on builders
2020-01-14 14:41:54 <ncopa> lets push it
2020-01-14 14:41:54 <mps> it is about 20 pkgs
2020-01-14 14:42:12 <mps> ncopa: ok
2020-01-14 14:42:24 <pltrz> ncopa: thanks for the valuable info :)
2020-01-14 14:43:03 <mps> rahmanshaber[m]: pushed
2020-01-14 14:44:37 <rahmanshaber[m]> mps: and ncopa when you make the apps port them in big distro like Alpine, i needed all the patience in the world.
2020-01-14 14:44:38 <rahmanshaber[m]> thanks for the support
2020-01-14 14:46:18 <mps> rahmanshaber[m]: well, I joking a little, I understand you, don't worry :)
2020-01-14 14:46:57 <rahmanshaber[m]> I understand. thanks
2020-01-14 14:47:32 <mps> you are welcome
2020-01-14 14:54:03 <uqFuRTcjDTf8> wooohoo, back again, i missed you guys ;0
2020-01-14 14:58:28 <mps> rahmanshaber[m]: build-edge-armhf	
2020-01-14 14:58:33 <mps> failed community/coretime
2020-01-14 15:11:48 <rahmanshaber[m]> I build in ci and others.
2020-01-14 15:11:48 <rahmanshaber[m]> mps
2020-01-14 15:12:21 <mps> yes, it passed but we don't have armhf CI
2020-01-14 15:12:40 <mps> it passed on others
2020-01-14 15:51:19 <rahmanshaber[m]> mps: any logs?
2020-01-14 15:52:47 <mps> ask _ikke_, he will know if log can be downoladed
2020-01-14 15:54:40 <mps> or wait next time when it comes from queue to builder
2020-01-14 15:55:07 <_ikke_> what log?
2020-01-14 15:55:35 <mps> community/coretime on armhf
2020-01-14 15:55:50 <rahmanshaber[m]> Yes
2020-01-14 15:56:25 <mps> curl gives me 404
2020-01-14 15:56:30 <_ikke_> what repo?
2020-01-14 15:56:34 <_ikke_> ah
2020-01-14 15:56:44 <mps> edge
2020-01-14 15:56:45 <_ikke_> community
2020-01-14 15:56:53 <mps> community/coretime on armhf
2020-01-14 15:57:12 <_ikke_> Is it this one https://dev.alpinelinux.org/buildlogs/build-edge-armhf/community/coretime/coretime-2.7.0-r0.log ?
2020-01-14 15:57:58 <mps> hmm,
2020-01-14 15:58:32 <mps> on #alpine-commits were reported that it failed
2020-01-14 15:59:13 <_ikke_> Right, 2.8.0
2020-01-14 15:59:22 <_ikke_> hold on
2020-01-14 15:59:34 <mps> 15:57 ..... algitbot| build-edge-armhf:  failed to build coretime:
2020-01-14 15:59:46 <rahmanshaber[m]> But it is v2.7 and new one is v2.8
2020-01-14 15:59:52 <_ikke_> yes
2020-01-14 16:00:39 <rahmanshaber[m]> Maybe there is a old log there.
2020-01-14 16:00:48 <_ikke_> I can look on the builder
2020-01-14 16:08:40 <rahmanshaber[m]> _ikke_:  please do. i check all files and builds, it's v2.8 there
2020-01-14 16:25:08 <_ikke_> I'll check in a moment
2020-01-14 16:26:43 <mps> https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/coretime/coretime-2.8.0-r0.log
2020-01-14 16:26:55 <mps> qt5-qtmultimedia-dev (missing):
2020-01-14 16:27:16 <Cogitri> Happens due to qtdeclarative getting disabled
2020-01-14 16:27:22 <Cogitri> TL;DR disable
2020-01-14 16:27:26 <mps> yes
2020-01-14 16:33:44 <rahmanshaber[m]> but it builds fine in ci...............
2020-01-14 16:33:44 <rahmanshaber[m]> ok so should i add the qt5-multimedia now?
2020-01-14 16:34:18 <rahmanshaber[m]> in APKBUILD file?
2020-01-14 16:34:22 <_ikke_> rahmanshaber[m]: CI does not test armhg
2020-01-14 16:34:25 <_ikke_> armhf
2020-01-14 16:34:46 <rahmanshaber[m]> ohh.
2020-01-14 16:35:15 <rahmanshaber[m]> i am now adding the missing depend.
2020-01-14 16:36:23 <Cogitri> You can't do that
2020-01-14 16:36:29 <Cogitri> Since it's not available on armhf
2020-01-14 16:36:30 <rahmanshaber[m]> Cogitri:  see this. qt5-multimedia is already in the depend
2020-01-14 16:36:30 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/blob/master/community/coretime/APKBUILD
2020-01-14 16:37:09 <rahmanshaber[m]> Qt5-multimedia?
2020-01-14 16:37:41 <mps> rahmanshaber[m]: qt5-multimedia doesn't build on armhf
2020-01-14 16:39:11 <Cogitri> Because qtdeclarative is disabled armhf, which qtmultimedia needs
2020-01-14 16:42:32 <rahmanshaber[m]> corefm also failed .
2020-01-14 16:42:51 <rahmanshaber[m]> is that happened recently?
2020-01-14 16:43:56 <Cogitri> PureTryOut disabled it a week ago or so
2020-01-14 16:44:06 <Cogitri> git log knows better probably
2020-01-14 16:45:21 <rahmanshaber[m]> I see.
2020-01-14 16:48:29 <rahmanshaber[m]> PureTryOut: can you give me a simple explanation ? if it is permanent then i will try to remove qt5-multimedia from depend.
2020-01-14 16:48:59 <PureTryOut[m]> https://git.alpinelinux.org/aports/tree/community/qt5-qtdeclarative/APKBUILD#n13
2020-01-14 16:49:03 <PureTryOut[m]> https://git.alpinelinux.org/aports/commit/community/qt5-qtdeclarative?id=d33b26afd532c021810d466a6c1a229d6e187ca3
2020-01-14 16:49:42 <PureTryOut[m]> You don't need to remove qt5-multimedia from deps if it's required for your program/library, just disable the package on armhf
2020-01-14 16:50:12 <rahmanshaber[m]> so qt5.14 have any fix?
2020-01-14 17:05:03 <PureTryOut[m]> Did you actually read the Qt bug report? It's still open, so no of course it won'tbe fixed in 5.14
2020-01-14 17:17:38 <rahmanshaber[m]> I did. But I bug report only says qml.
2020-01-14 17:31:10 <Cogitri> PureTryOut[m]: Sorry, but do you have time to disable more stuff for qtdeclarative? There's still loads of stuff failing :/
2020-01-14 17:32:54 <PureTryOut[m]> If it's the KDE stuff, I did make 2 MR's for those
2020-01-14 17:33:05 <PureTryOut[m]> <rahmanshaber[m] "I did. But I bug report only say"> Yeah, QML is qt5-qtdeclarative, which is a dep of tons of stuff
2020-01-14 17:33:40 <_ikke_> kcoreaddons
2020-01-14 17:34:01 <Cogitri> Ah, missed those, my bad
2020-01-14 17:35:12 <Cogitri> 
ACTION is merging

2020-01-14 17:36:38 <_ikke_> kdnssd
2020-01-14 17:37:44 <PureTryOut[m]> Np
2020-01-14 22:02:48 <mps> north1: FYI, https://gitlab.alpinelinux.org/mps/aports/-/jobs/36097/artifacts/raw/packages/main/x86_64/linux-lts-5.4.12-r0.apk
2020-01-15 07:22:56 <markand> sh: write error: No space left on device
2020-01-15 07:22:57 <markand> ERROR: Job failed: exit code 1
2020-01-15 07:22:58 <markand> ow
2020-01-15 07:23:05 <markand> this is happening on the gitlab lint
2020-01-15 07:29:18 <Cogitri> Oh, is that my runner?
2020-01-15 07:29:23 <Cogitri> Can you send the job log in here?
2020-01-15 07:33:31 <markand> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3039
2020-01-15 07:33:32 <markand> on this one
2020-01-15 07:41:10 <Cogitri> _ikke_: https://gitlab.alpinelinux.org/markand/aports/-/jobs/36154
2020-01-15 07:41:23 <Cogitri> I suppose that's your runner
2020-01-15 08:42:49 <clandmeter> it is, not sure why he runs it on a private runner.
2020-01-15 08:47:07 <_ikke_> I'll decomission it
2020-01-15 08:47:14 <_ikke_> it was meant to help with running jobs when it was busy
2020-01-15 10:55:07 <MY-R> ncopa, https://github.com/gliderlabs/docker-alpine/issues/476
2020-01-15 10:55:30 <MY-R> their problem werent with dns lookup but with resolving rev dns...
2020-01-15 10:55:34 <MY-R> s
2020-01-15 10:58:30 <MY-R> http://tpaste.us/0Pz6  that is how output of command looks before and after busybox update, they got "null" cus of missing revdns in some local address
2020-01-15 11:03:16 <ncopa> title says: Apparent DNS failure in Docker image alpine:3.8, nslookup: can't resolve '(null)'
2020-01-15 11:03:32 <MY-R> but it resolve correctly addresses
2020-01-15 11:03:39 <ncopa> so the isse was about the "nslookup: can't resolve '(null)'"
2020-01-15 11:03:53 <ncopa> correct. resolving works, but gives error message
2020-01-15 11:04:10 <ncopa> "I'm baffled that nslookup complains yet finds the IP address. In comparison, ping works perfectly."
2020-01-15 11:04:16 <MY-R> but error is about not resolving rev dns
2020-01-15 11:04:48 <MY-R> since he using some local domains and local dns server then he wont get any revdns and that is why getting NULL
2020-01-15 11:05:00 <MY-R> BIG version just disabled check that
2020-01-15 11:06:39 <ncopa> no, nobody gets revdns, because the busybox code does not work with musl
2020-01-15 11:06:45 <MY-R> of course they could set up some proper local dns server which will return rev dns but they didnt so got NULL
2020-01-15 11:06:54 <ncopa> no
2020-01-15 11:07:03 <ncopa> working reverse dens would not solve that
2020-01-15 11:07:10 <ncopa> s/dens/dns/
2020-01-15 11:07:10 <alpine-meetbot> ncopa meant to say: working reverse dns would not solve that
2020-01-15 11:07:21 <ncopa> https://github.com/gliderlabs/docker-alpine/issues/476#issuecomment-457124840
2020-01-15 11:07:24 <MY-R> http://tpaste.us/0Pz6  look, before output got included revdns checks, after upgrade it doesnt even show it
2020-01-15 11:08:29 <ncopa> https://git.busybox.net/busybox/tree/networking/nslookup.c#n208
2020-01-15 11:09:24 <ncopa> the comment says that busybox expects res_init() to find what dns server was used
2020-01-15 11:09:32 <ncopa> but res_init() in musl does nothing
2020-01-15 11:10:33 <ncopa> if you look a the NSLOOKUP_BIG implementation https://git.busybox.net/busybox/tree/networking/nslookup.c#n231 the comment says:
2020-01-15 11:10:56 <ncopa> "musl compatible nslookup"
2020-01-15 11:11:33 <ncopa> implying that the smaller variant is not compatible with musl
2020-01-15 11:11:52 <MY-R> and bigger doesnt show revdns :P
2020-01-15 11:14:17 <MY-R> http://tpaste.us/adWo
2020-01-15 11:14:20 <ncopa> if you need full featured nslookup: apk add cmd:nslooup
2020-01-15 11:14:43 <MY-R> and that is from openwrt.... so every output is little different already
2020-01-15 11:15:02 <MY-R> ye I know
2020-01-15 11:15:36 <rahmanshaber[m]> what this means
2020-01-15 11:15:36 <rahmanshaber[m]> https://gitlab.alpinelinux.org/rahmanshaber/aports/-/jobs/36299
2020-01-15 11:17:51 <ncopa> $ busybox nslookup alpinelinux.org 1.1.1.1 | tpaste
2020-01-15 11:17:51 <ncopa> http://tpaste.us/NmJ6
2020-01-15 11:18:55 <ncopa> rahmanshaber[m]: sounds like there are spaces instead of tabs
2020-01-15 11:19:09 <ncopa> MC:[AL29]:APKBUILD:12:$pkgname should not be used in the source url
2020-01-15 11:19:24 <ncopa> means that you shoudl expand the pkgname instead of use $pkgname
2020-01-15 11:30:22 <tmhoang> ncopa, clandmeter: have you ever have a rootfs packaged as cpio/squashfs and concatenated (i.e. write bin mode) to the initramfs so that when initramfs switch_root/pivot_root, it swtich root to this cpio/squashfs rootfs ?
2020-01-15 11:30:48 <tmhoang> so basically instead of having initramfs image + rootfs image, one would have 1 big fat initramfs image
2020-01-15 11:31:04 <tmhoang> iirc I heard somebody did that before
2020-01-15 11:32:36 <ncopa> no. never done that
2020-01-15 11:32:47 <ncopa> so you mean that the squashfs root is embedded in initramfs?
2020-01-15 11:32:58 <ncopa> why not have the entire rootfs in initramfs then?
2020-01-15 11:33:13 <tmhoang> yes, written to at some byte offset, etc.
2020-01-15 11:33:29 <tmhoang> yeah that's be one way
2020-01-15 11:34:16 <tmhoang> iirc there was some parameter like, root=0xabcdef12345 that point to an address in memory
2020-01-15 11:34:57 <ncopa> why do you want the root as squashfs?
2020-01-15 11:35:37 <tmhoang> could be anything, not just squashfs. I kind of want to pack qcow alpine rootfs into this squashfs/cpio
2020-01-15 11:35:56 <ncopa> you could just tuff everything in the initramfs
2020-01-15 11:36:03 <tmhoang> yeah
2020-01-15 11:36:30 <tmhoang> I just hope that, the rootfs layout (files, contents, etc.) in the initramfs is the same as in the real rootfs
2020-01-15 11:36:50 <ncopa> that should be possible
2020-01-15 11:37:05 <ncopa> then you dont need to do any switch_root/pivot_root
2020-01-15 11:39:11 <ncopa> the reason that we did a switch_root was that we wanted keep the initramfs minimal
2020-01-15 11:39:37 <ncopa> and it also give us the possibility to configure the size of the tmpfs root
2020-01-15 11:39:48 <tmhoang> right
2020-01-15 11:41:50 <ncopa> we also wanted be flexible with what the user has installed in the tmpfs root
2020-01-15 11:42:18 <ncopa> if you have the entire root in a squashfs, then you need to know what you want installed there
2020-01-15 11:42:26 <ncopa> and then you could simply have it all in initramfs
2020-01-15 11:44:03 <rahmanshaber[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/ggYTgTMaebZehcrOzaxFPQsZ >

2020-01-15 11:44:15 <rahmanshaber[m]> sorry for spam.
2020-01-15 11:51:10 <Cogitri> Submit a MR, reviewing something in IRC is a pain
2020-01-15 12:31:29 <rahmanshaber[m]> Cogitri:  https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3074
2020-01-15 13:13:05 <kaniini> ncopa: i have identified another software that needs the pkgconf treatment
2020-01-15 13:13:09 <kaniini> ncopa: PPP
2020-01-15 13:52:43 <ncopa> ok?
2020-01-15 13:59:37 <ncopa> what do you mean with "pkgconf treatment" and why PPP?
2020-01-15 14:05:29 <kaniini> ncopa: PPP needs a complete rewrite
2020-01-15 14:05:40 <kaniini> like, i had the "pleasure" of configuring it, and it is just awful
2020-01-15 14:05:56 <kaniini> it is the same kind of awful that made me want to write pkgconf :P
2020-01-15 14:06:26 <ncopa> oh, ha! that makes sense
2020-01-15 14:06:46 <ncopa> the ppp code is sort of old too
2020-01-15 14:08:41 <kaniini> yeah, well i have dozens more sites to config :(
2020-01-15 14:09:07 <clandmeter> libreppp or pppnext or pppconf? :)
2020-01-15 14:10:10 <kaniini> the whole thing seems unnecessarily fragile
2020-01-15 14:14:36 <kaniini> clandmeter: i am thinking pppclient -t pppoe -i eth0 -u foo@ISP -s SECRET
2020-01-15 14:15:08 <AinNero> is this an artifact on how alpine packages it?
2020-01-15 14:15:38 <kaniini> AinNero: no, the software was originally written in the 1980s and hasn't left the 1980s
2020-01-15 14:16:07 <tmhoang> let's AI it
2020-01-15 14:16:46 <ncopa> :D
2020-01-15 14:17:42 <AinNero> thats no surprise to me
2020-01-15 14:17:58 <AinNero> the modem in my laptop is still interfaces 80ies style
2020-01-15 14:18:05 <AinNero> *interfaced
2020-01-15 14:18:40 <AinNero> there is a newer interface, not sure how its called, afair it makes wwan[0-9] interfaces
2020-01-15 14:18:46 <AinNero> modemmanager has support for that
2020-01-15 14:19:10 <kaniini> thats not the same thing
2020-01-15 14:19:54 <AinNero> what kind of modem do you want to interface with?
2020-01-15 14:20:35 <kaniini> a DSL modem
2020-01-15 14:20:37 <kaniini> don't worry about it
2020-01-15 14:20:41 <kaniini> i know what i am doing (:
2020-01-15 14:21:30 <AinNero> im using ppp-daemon with reconnect like mobile data
2020-01-15 14:25:23 <kaniini> the LTE modem i have just exposes ethernet
2020-01-15 14:28:43 <zfoo_> running abuild gives me an error code (1, no child process), any ideas? https://pastebin.com/6ZjF9pGX
2020-01-15 15:53:19 <ncopa> fedora has atleast 191 patches to grub
2020-01-15 15:53:28 <ncopa> https://src.fedoraproject.org/rpms/grub2/tree/master
2020-01-15 15:53:36 <ncopa> i am tempted to use a handful of them
2020-01-15 15:53:40 <ncopa> remove borders from menu
2020-01-15 15:53:52 <ncopa> remove GNU GRub title
2020-01-15 15:53:59 <ncopa> fix the help text
2020-01-15 15:54:21 <ncopa> https://src.fedoraproject.org/rpms/grub2/blob/master/f/0041-Don-t-draw-a-border-around-the-menu.patch
2020-01-15 15:58:50 <Cogitri> Nice :^)
2020-01-15 15:59:25 <north1> Can't grub release an update?
2020-01-15 16:04:22 <ncopa> there is an update out
2020-01-15 16:04:24 <ncopa> 2.04
2020-01-15 16:04:28 <clandmeter> there is an update
2020-01-15 16:04:29 <clandmeter> or 2
2020-01-15 16:04:29 <ncopa> which im working on
2020-01-15 16:04:52 <clandmeter> i guess fedora is on the latest version?
2020-01-15 16:04:58 <ncopa> yes
2020-01-15 16:05:09 <ncopa> i'd love to remove those borders and stuff
2020-01-15 16:05:16 <ncopa> but im not sure its worth the time
2020-01-15 16:05:38 <clandmeter> i dont really care
2020-01-15 16:05:51 <ncopa> removing the borders will require some related patches that fixes indent and margins and stuff
2020-01-15 16:06:07 <ncopa> i think i'll keep it as upstream for now
2020-01-15 16:06:09 <clandmeter> i dont usually stare at my grub menu
2020-01-15 16:06:15 <ncopa> exactly
2020-01-15 16:13:43 <Cogitri> And messing with grub sounds risky
2020-01-15 16:16:43 <mps> hmm, some time ago thought to make x86 u-boot and test it but never found enough time and incetive :)
2020-01-15 16:17:45 <ncopa> we have syslinux for x86 that is pretty nice
2020-01-15 16:18:15 <ncopa> another thing i wonder is if we actually need a bootloader with uefi
2020-01-15 16:18:22 <MY-R> 
ACTION waiting for grub 2.05 with LUKS2 support

2020-01-15 16:18:24 <ncopa> we could boot directly into kernel as i understand
2020-01-15 16:21:03 <mps> I use syslinux wherever I can, grub is only on some servers where I can't use anything else
2020-01-15 16:21:39 <mps> boot kernel directly is impractical
2020-01-15 16:21:59 <clandmeter> ncopa: will you hack efibootmgr in your new install script?
2020-01-15 16:30:44 <ncopa> i guess i should
2020-01-15 16:35:43 <ncopa> while speaking of booting
2020-01-15 16:36:03 <ncopa> im thinking of if we should do disk images releases
2020-01-15 16:36:12 <ncopa> and if we do, how
2020-01-15 16:36:55 <_ikke_> You mean rather than iso?
2020-01-15 16:37:03 <ncopa> instead of iso yes
2020-01-15 16:37:12 <ncopa> or instead of rpi tarball
2020-01-15 16:37:58 <ncopa> im thinking that we could have 2 partitions, one /boot (vfat for uefi support) and one ext4
2020-01-15 16:38:42 <ncopa> the nice thing with ext4 is that it can be expanded
2020-01-15 16:39:03 <ncopa> but i dont know
2020-01-15 16:39:41 <mps> yes, and I talked here or #alpine-linux about img idea about 6 months ago
2020-01-15 16:40:09 <mps> that is how Armbian do for arm releases for different boards
2020-01-15 16:40:28 <ncopa> we should have a discussion on mailing list i suppose
2020-01-15 16:40:45 <ncopa> basically, i'd like to investigate what different distros do
2020-01-15 16:41:14 <mps> another option would be like Arch alarm, tarball with guide for every SBC/board variant
2020-01-15 16:41:14 <ncopa> ubuntu, arch linux, fedora, void linux, and maybe even bsds
2020-01-15 16:41:59 <mps> arch alarm method is what I would prefer
2020-01-15 16:44:19 <mps> (annoying to repeat, but I dislike new ML, sorry)
2020-01-15 16:45:14 <ncopa> we have understood that
2020-01-15 16:47:12 <mps> nvm, I can prepare script with short guide how to install alpine from tarball on few arm board
2020-01-15 16:47:47 <mps> but would like if someone is ready to proof read it and make/propose changes
2020-01-15 16:48:54 <mps> (this reminds me that I should update script and giude how to install arm under qemu)
2020-01-15 17:09:01 <MY-R> ncopa playing hard with grub, /me preparing usb drive with .iso Alpine just in case of boot recovery ;)
2020-01-15 17:10:15 <ncopa> the main reason that i dont apply the fedora patches for grub is that it may require some work to rebase on next update
2020-01-15 17:10:25 <ncopa> not that grub releases often...
2020-01-15 17:11:09 <MY-R> better keep it "vanilla" as much possible imho
2020-01-15 17:13:11 <MY-R> true, fixing/removing patches after release would be nightmare
2020-01-15 18:32:27 <PureTryOut[m]> So on postmarketOS we have a fork of Alpine's mesa package. It's intended to be installed only on specific devices, use regular mesa everywhere else. However, if we now install an application that depends on mesa, say mpv, on a device that doesn't need our fork of mesa, our fork gets installed anyway. I'm messing around with provides and replaces but can't seem to get it right
2020-01-15 18:32:48 <PureTryOut[m]> Do we need to fork regular mesa to set provider_priority or something?
2020-01-15 18:49:25 <_ikke_> I wonder if there is a default priority
2020-01-15 19:11:50 <RuudKuin67> Hi all, I'd like to enable auto login, tried adding 'auto-login-user' in LightDM, to no avail, any help is appreciated
2020-01-15 19:14:47 <RuudKuin67> Found that apk add alpine-desktop add a few nice applications, Midori needed replacement, so Firefox was implemented with this install command
2020-01-15 19:15:07 <Cogitri> Well, go check up on your logs, I suppose. Asking lightdm upstream probably gives you more results I suppose
2020-01-15 19:16:19 <RuudKuin67> Thx Cogitri i'll try that! keep up the good work...
2020-01-15 19:29:54 <Cogitri> ncopa: grub doesn't seem to be comfy on the builders
2020-01-15 19:39:56 <kaey> there are alternatives to pppd, for ex npppd in openbsd and mpd5 in freebsd, and they're just as complex in configuration
2020-01-15 19:40:18 <kaey> thats because protocol itself is complex
2020-01-15 19:40:50 <kaey> pppoe client can be simple though, for example in openbsd https://man.openbsd.org/ifconfig.8#PPPOE
2020-01-15 19:41:07 <_ikke_> Cogitri: seems an autoconf issue, says it cannot find autopoint, required for gettext
2020-01-15 19:42:17 <Cogitri> Yes
2020-01-15 19:42:26 <Cogitri> Trying with gettext-dev added as dep since that provides autopoint
2020-01-15 19:42:31 <_ikke_> ok
2020-01-15 19:42:38 <Cogitri> Let's see how that goes
2020-01-15 19:42:52 <Cogitri> Autotools sure is fun :^)
2020-01-15 19:42:55 <_ikke_> heh
2020-01-15 19:43:20 <Cogitri> Well, with that dep added autoreconf goes through so that's nice
2020-01-15 19:43:37 <Cogitri> !3083 let's hope it doesn't blow up
2020-01-15 19:43:53 <_ikke_> Cogitri: I'll push it
2020-01-15 19:44:14 <_ikke_> waiting for CI to finish just to be sure
2020-01-15 19:44:41 <Cogitri> Thank you :)
2020-01-15 19:48:41 <Cogitri> And passed, nice
2020-01-15 19:48:50 <_ikke_> good
2020-01-15 19:50:01 <_ikke_> done
2020-01-15 20:03:12 <Cogitri> I think the `closes !3083` didn't actually work, _ikke_
2020-01-15 20:03:25 <_ikke_> Cogitri: correct, it doesn't
2020-01-15 20:03:32 <_ikke_> but it does add a reference at least
2020-01-15 20:33:16 <MY-R> looks like grub/grub-bios working :D but I had to do manualy "grub-install /dev/sda" because after reboot still in menu was showing version 2.02
2020-01-15 20:40:32 <Cogitri> Makes sense, it doesn't automatically upgrade your EFI file/bios boot thingie upon upgrading the package
2020-01-15 20:40:54 <MY-R> yep, true!
2020-01-15 20:52:48 <nmeum> did anybody else ever notice that the localmount openrc services would always fail on shutdown if a process was still using a mountpoint?
2020-01-15 20:53:13 <nmeum> turns out: our localmount services never invoked fuser https://git.alpinelinux.org/aports/commit/?id=6b49c2098d96f6ec7872e48c465cb5f9828da4b1
2020-01-15 21:05:54 <MY-R> nmeum, damn, I have some "red" star from time to time about something like that when shutdown/reboot system but for sure it wasnt about fuser and have no idea how reproduce it :\
2020-01-15 21:07:20 <nmeum> well…it's been bothering me forever. finally got around to investigate it further and fix it
2020-01-15 21:07:44 <nmeum> also found a bug in busybox fuser in the process https://bugs.busybox.net/show_bug.cgi?id=12476
2020-01-15 21:08:02 <MY-R> something with mount/read dunno, is just too quick to notice... will try pay more attention "next" time
2020-01-16 04:22:01 <rahmanshaber[m]> do i need to put this in a single commit?
2020-01-16 04:22:02 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3074
2020-01-16 05:31:38 <_ikke_> rahmanshaber[m]: in one commit you add the apkbuild, in the next you remove it again
2020-01-16 05:32:03 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3074/diffs?commit_id=e38d69f60bc4cdc8534d12eac3ed7287f9da4a50
2020-01-16 05:32:10 <rahmanshaber[m]> _ikke_: i have no idea what i did.
2020-01-16 05:32:19 <rahmanshaber[m]> i really hate git.
2020-01-16 05:32:47 <rahmanshaber[m]> A new MR is the last thing i can do.
2020-01-16 05:32:56 <_ikke_> Not necessary
2020-01-16 05:33:12 <_ikke_> Are you on the massport branch?
2020-01-16 05:34:51 <rahmanshaber[m]> yes
2020-01-16 05:35:06 <_ikke_> does git status say your working tree is clean?
2020-01-16 05:35:46 <rahmanshaber[m]> i did with web IDE. i can't download the aport in my system as net is tooooo slow.
2020-01-16 05:36:00 <_ikke_> ah ok
2020-01-16 05:37:17 <rahmanshaber[m]> in last commit i wanted to move the apkbuild to testing as i added it in community by mistake.
2020-01-16 05:37:43 <_ikke_> I can fix it for you if you want?
2020-01-16 05:38:19 <_ikke_> I cannot find how to do it in the web ide
2020-01-16 05:39:40 <rahmanshaber[m]> <_ikke_ "I can fix it for you if you want"> please do.
2020-01-16 05:40:15 <rahmanshaber[m]> <_ikke_ "I cannot find how to do it in th"> it is very easy to make a MR with it. that's all.
2020-01-16 05:40:49 <_ikke_> yup, indeed
2020-01-16 05:42:58 <_ikke_> rahmanshaber[m]: done
2020-01-16 05:43:05 <rahmanshaber[m]> and that's far i can run with git. so web ide is perfect for me. and it's not that i did not tried to learn git but i am not that good at the workflow.
2020-01-16 05:43:28 <_ikke_> I can create a bundle for aports if you want
2020-01-16 05:43:47 <_ikke_> you could download that over http and resume etc
2020-01-16 05:44:03 <rahmanshaber[m]> <_ikke_ "I can create a bundle for aports"> what is that?
2020-01-16 05:44:41 <_ikke_> rahmanshaber[m]: git history packaged in a single file, which you can clone / fetch from
2020-01-16 05:45:01 <_ikke_> to get the initial aports repo that could help a lot
2020-01-16 05:45:20 <rahmanshaber[m]> how can i use it?
2020-01-16 05:46:16 <_ikke_> I put it on a website, and you download from it using whatever works for you
2020-01-16 05:46:47 <_ikke_> once finished, you do git clone -b master path/to/bundle
2020-01-16 05:47:06 <_ikke_> git clone -b master path/to/bundle aports
2020-01-16 05:48:18 <rahmanshaber[m]> ohh, because of the slow net i can't download the aport?
2020-01-16 05:49:41 <_ikke_> git cloning over a slow net can be painful
2020-01-16 05:49:53 <_ikke_> if the clone is interrupted, you have to start over
2020-01-16 05:50:02 <rahmanshaber[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/WjjbTybeoHPbQcsldOPOQKja >

2020-01-16 05:50:03 <_ikke_> but downloading over http can make that easier
2020-01-16 05:51:41 <_ikke_> ok, so you are already cloning it
2020-01-16 05:51:56 <rahmanshaber[m]> <_ikke_ "but downloading over http can ma"> yes, that will be helpfull if you do that thing you said.
2020-01-16 05:52:23 <_ikke_> ok
2020-01-16 05:52:43 <_ikke_> I've been for 2 weeks in a country where internet was extremely limited :)
2020-01-16 05:54:41 <rahmanshaber[m]> me for ages.
2020-01-16 05:56:06 <_ikke_> cloning from a bundle: Receiving objects: 100% (486791/486791), 146.02 MiB | 29.20 MiB/s, done
2020-01-16 05:56:07 <_ikke_> :)
2020-01-16 05:57:13 <rahmanshaber[m]> nice.
2020-01-16 06:01:27 <_ikke_> https://dev.alpinelinux.org/archive/aports.bundle
2020-01-16 06:03:16 <Cogitri> Morning
2020-01-16 06:03:21 <_ikke_> hi
2020-01-16 07:04:30 <ncopa> morning
2020-01-16 07:05:11 <ncopa> do we want to backport the NFT_FIB_IPV* config changes to 3.11-stable?
2020-01-16 07:05:46 <ncopa> c1a44df21adc1008b4d6432e9c841bdabfcf8ba4, f2ca3420aaf2656a2bcdf30cbd7bac0a33d19ec6, and b521f901c522a1ada8deeeb5278b0e3fac333cf1
2020-01-16 07:06:52 <ncopa> mps: ^^^
2020-01-16 08:22:11 <mps> ncopa: I think we should, they don't remove any 'capability' but add few functionalities
2020-01-16 08:22:56 <mps> only not sure about STACKPROTECTOR options for ppc64le
2020-01-16 08:24:23 <mps> also, I think we should look at #11135 and enable this
2020-01-16 08:34:22 <mps> re backport STACKPROTECTOR for ppc64le, I think it will not cause any issue if backported but not sure because don't have such box or VM to try
2020-01-16 08:36:23 <mps> cherry-pick 5.4.12 and enable serial_ir is what I think is ok
2020-01-16 08:39:30 <mps> ncopa: are you preparing new 3.11 release?
2020-01-16 08:39:40 <ncopa> yes, thats what I'd like to do
2020-01-16 08:40:14 <mps> good, there is a bug in lbu which I would like to fix before release
2020-01-16 08:42:23 <mps> #10451
2020-01-16 08:42:30 <mps> oh, no
2020-01-16 08:42:51 <mps> https://gitlab.alpinelinux.org/alpine/alpine-conf/issues/10451 , this
2020-01-16 08:43:59 <mps> and to look at this one https://gitlab.alpinelinux.org/alpine/alpine-conf/issues/10453
2020-01-16 09:07:01 <ncopa> hum... seems like there is no way to make that a sub project of aports project where we have the release milestones.
2020-01-16 09:07:12 <ncopa> i'd like to have it show up on the 3.11.3 todo-list
2020-01-16 09:08:05 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=3.11.3
2020-01-16 09:08:10 <ncopa> which is empty anyway...
2020-01-16 09:08:25 <ncopa> i'd like a way to generate a todo-list for everthing that needs to be don for a given release
2020-01-16 09:08:42 <ncopa> so we dont miss issues
2020-01-16 09:10:37 <ncopa> re #111135 can we wait with that til next kernel release? it will save some work
2020-01-16 09:10:39 <_ikke_> https://gitlab.alpinelinux.org/groups/alpine/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=v3.11
2020-01-16 09:11:09 <ncopa> #11135
2020-01-16 09:11:31 <ncopa> otherwise i need to rebuild the kernel for edge first, test it and then backport to 3.11
2020-01-16 09:12:04 <ncopa> re STACKPROTECTOR for ppc64le, i think it was a new config knob so we need to configure it one way or the other regardless
2020-01-16 09:12:24 <ncopa> so i figured we can just try to be consistent with the other arches and enable it
2020-01-16 09:13:02 <ncopa> _ikke_: problem is with other (sub) projects like alpine-conf in this case
2020-01-16 09:13:22 <ncopa> which is a different project than alpine/aports
2020-01-16 09:13:50 <ncopa> i guess we can create a proxy issue or tracker issue in alpine/aports
2020-01-16 09:21:02 <mps> todo-list and approximate time for sub release would be 'good thing'
2020-01-16 09:22:31 <mps> we have already 'CONFIG_USB_SERIAL_IR=m' for some arches
2020-01-16 09:27:34 <PureTryOut[m]> Cogitri: sorry could you generate new artifacts for !2908?
2020-01-16 09:28:40 <_ikke_> PureTryOut[m]: I restarted that job
2020-01-16 09:28:52 <PureTryOut[m]> Thanks
2020-01-16 09:50:38 <ocin> I have a alpine USB stick (baked with mkimg scripts + 1 ovl file) and a problem: On a fresh install all is fine but when I boot the stick on a pc where a different apkovl is present on a disk partition (sda1 in that case) the stick tries to use that one, thus modloop verify fails, basically everything is broken and the apkovl from the USB is not loaded at all. I tried loads of alpine_dev, ovl_dev,
2020-01-16 09:50:38 <ocin> apkovl boot parameters (usbdisk, uuid, combinations, ..) but I can just not get the alpine stick to load the apkovl on itself - I am out if ideas now what to try, any ideas?
2020-01-16 09:58:33 <AinNero> ocin: no easy solution
2020-01-16 10:01:54 <AinNero> uhm, the correct modloop should still be found
2020-01-16 10:02:00 <AinNero> even if the other one causes an error
2020-01-16 10:03:11 <ocin> it def says modloop verification failed and only when there is a alpine installed on disk
2020-01-16 10:04:53 <ocin> from my understanding when I use ovl_dev=UUID=XXX-USBSTICK-XXX:vfat it should only seek te overlay on that partition, the usb stick
2020-01-16 10:05:08 <ocin> maybe all that stuff is broken who knows
2020-01-16 10:05:50 <AinNero> in /etc/init.d/modloop, find_modloop, its a loop over all found modloops
2020-01-16 10:06:07 <AinNero> and it returns when it finds one with matching kernel version
2020-01-16 10:06:29 <AinNero> oh, i see
2020-01-16 10:06:35 <ocin> the kernel versions differ huegly
2020-01-16 10:06:40 <AinNero> problem is not the matching kernel version, but the verification
2020-01-16 10:06:57 <AinNero> definitely needs some patches..
2020-01-16 10:08:40 <ocin> the bad thing is it boots into a broken system then where you cant even open the 2nd tty to clear the partition table (which is the workaround)
2020-01-16 10:09:33 <ocin> and I have to use that stick on loads of machines where there is an alpine partition +apkovl already ._.
2020-01-16 10:11:21 <ocin> AinNero: do you have a link to the gitweb of the modloop script?
2020-01-16 10:12:38 <mps> ncopa: ncopa: I don't have experience with alpine-conf repo so here is a fix for 'lbu commit -e' http://tpaste.us/b4EW
2020-01-16 10:13:27 <mps> tested it on rpi zero and it works
2020-01-16 10:13:31 <AinNero> ocin: https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/openrc/modloop.initd
2020-01-16 10:14:10 <mps> also noticed that you fixed linux-lts issue which I thought to work on :)
2020-01-16 10:15:13 <mps> upgrade kernel and these two fixes for alpine-conf is all I have in 'todo' in head for 3.11.3 release
2020-01-16 10:17:10 <mps> about IR_SERIAL, if you are not in hurry for release I can look and make it afternoon or this night
2020-01-16 10:17:25 <nmeum> I also considered backporting 6b49c2098d96f6ec7872e48c465cb5f9828da4b1 to the -stable branch maybe also for the 3.11.3 release?
2020-01-16 10:20:04 <kaey> mps: initramfs has the same check and needs fix
2020-01-16 10:23:17 <mps> kaey: setup-disk ?
2020-01-16 10:24:10 <kaey> mps: https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in#n46
2020-01-16 10:24:16 <ocin> AinNero: so from my understanding it is that the modloop script does not even respect ovl_dev, apkovl, alpine_dev in any way and just grabs all it can find on all mounts and just uses the wrong one? something like this..
2020-01-16 10:25:05 <AinNero> why should the modloop script look after the apkovl settings?
2020-01-16 10:25:14 <AinNero> but yes, thats correct
2020-01-16 10:25:42 <AinNero> alpine_dev isn't honoured at all, documentation referencing it should be updated...
2020-01-16 10:28:37 <mps> kaey: aha, I see
2020-01-16 10:28:40 <mps> true
2020-01-16 10:29:03 <tmhoang> ncopa: re: concatenating cpio rootfs to initramfs yesterday, it works. If the big fat initramfs = (original initramfs + padding bytes + cpio rootfs) is used, the kernel (quite smart!) would then keep extracting all the cpio archives it finds on the memory region where the big fat initramfs is loaded. If my rootfs cpio image has all the contents
2020-01-16 10:29:03 <tmhoang> under main directory like /rootfs.cpio/{dev,sys,proc,lib,usr,etc,...}, then during initramfs phase, there would be a directory at /rootfs.cpio - which I can mount as /sysroot and then switch_root() into that real rootfs
2020-01-16 10:29:33 <tmhoang> the big fat initramfs is not really a cpio archive - it is just a steam of bytes containing 2+ cpio archives
2020-01-16 10:30:02 <tmhoang> *stream of bytes
2020-01-16 10:30:09 <ocin> AinNero: if alpine_dev would be honoured in the sense which docs currently say there would be no problem (if modloop script would also respect that). like "this is the alpine boot dev, you get your stuff from this partition and dont need to look at anything else"
2020-01-16 10:30:17 <AinNero> ocin: which docs?
2020-01-16 10:30:27 <ocin> "docs" idk, the wiki
2020-01-16 10:30:29 <AinNero> its not in the manpage for mkinitfs-bootparams
2020-01-16 10:30:46 <ocin> but thats very outdated it also says cramfs instead of squashfs still lol
2020-01-16 10:31:00 <AinNero> link
2020-01-16 10:31:46 <tmhoang> clandmeter: above ^ might be 1 fancy thinggy for netboot :D
2020-01-16 10:33:10 <tmhoang> it sounds fun but I don't think I'm going into that direction
2020-01-16 10:33:27 <tmhoang> aka. how to generate a canonical rootfs
2020-01-16 10:33:32 <AinNero> tmhoang: IMHO if you have your sysroot as cpio, you can skip the regular initramfs alltogether
2020-01-16 10:34:02 <tmhoang> yeah agreed from yesterday
2020-01-16 10:34:02 <AinNero> and have the kernel start the sysroot directly instead
2020-01-16 10:46:45 <mps> kaey: ncopa: does this make sense http://tpaste.us/1Og9
2020-01-16 10:47:57 <kaey> it does
2020-01-16 11:03:46 <ocin> https://wiki.alpinelinux.org/wiki/Create_a_Bootable_USB @AinNero the troubleshooting section for example
2020-01-16 12:23:44 <north1> @PureTryOut re: pmbootstrap review. I'll review in a few hours, am in course
2020-01-16 12:33:17 <ncopa> nmeum: backporting 6b49c2098d96f6ec7872e48c465cb5f9828da4b1 sounds good
2020-01-16 12:34:33 <nmeum> should probably just build as is, let me do some quick tests…
2020-01-16 12:35:58 <ncopa> mps: i pushed lbu fix to edge, thanks
2020-01-16 12:36:14 <ncopa> i haven't tested it though (i'm trusting that you did)
2020-01-16 12:37:11 <nmeum> !3090 let's see if it passes on the ci have to go now, feel free to merge it if it does pass. otherwise I will look into it later
2020-01-16 12:37:35 <ocin> AinNero: should I open a bug about the modloop issue?
2020-01-16 12:38:54 <ncopa> ocin: sounds like a good idea, i dont have capacity to follow all issues reported on IRC
2020-01-16 12:39:04 <ncopa> provide all details and how to reproduce
2020-01-16 12:43:05 <mps> ncopa: I tested it on rpi zero 3.11.2, it worked in my case
2020-01-16 12:43:42 <ncopa> mps: should we backport db41b322f2c3ac9e1007ce1f77d8784b9b80b455 to 3.11-stable?
2020-01-16 12:44:14 <mps> yes, my daughter needs that! :)
2020-01-16 12:46:26 <mps> I can backport all these things in linux-lts if you are busy, but will need few hours because now I work on some other things for $day_job
2020-01-16 12:47:49 <mps> and, please don't forget to look at initramfs openssl fix  http://tpaste.us/1Og9
2020-01-16 12:48:18 <ncopa> oh it was already cherry-picked, with 3b1c5ee7c1c
2020-01-16 12:49:12 <ncopa> 3b1c5ee7c1c63486a3e87aad63fab21e5e8f1998
2020-01-16 12:49:24 <ncopa> which also seems to include the FIB stuff
2020-01-16 12:49:31 <ncopa> or at least some of the FIB stuff
2020-01-16 12:49:46 <mps> ah, didn't seen it in #alpine-commits
2020-01-16 12:52:14 <mps> ah, you mean linux. yes most is backported already
2020-01-16 12:52:50 <mps> 5.4.12 have another FIB modules enabled
2020-01-16 12:54:59 <ncopa> i think i have it under control now :)
2020-01-16 12:55:02 <ncopa> finally
2020-01-16 12:55:23 <mps> ok
2020-01-16 13:00:14 <ncopa> PureTryOut[m]: d33b26afd532c021810d466a6c1a229d6e187ca3 broke a lot of builds in armhf. can you try help clean that up?
2020-01-16 13:00:37 <ncopa> alternatively we could re-enable it on armhf and let all those packages be broken
2020-01-16 13:00:57 <ncopa> but at least we dont block the builders
2020-01-16 13:01:11 <_ikke_> ncopa: is there a reason disabling a package is not transitive for its dependencies?
2020-01-16 13:01:29 <_ikke_> I guess because it does not know it's disbaled
2020-01-16 13:01:34 <ncopa> ?
2020-01-16 13:01:53 <ncopa> abuild does not know that one of its dependencies are disabled
2020-01-16 13:01:58 <_ikke_> yes, right
2020-01-16 13:02:07 <ncopa> abuild is stupid and simple
2020-01-16 13:02:43 <_ikke_> which is good :)
2020-01-16 13:02:55 <ncopa> i tend to agree :)
2020-01-16 13:06:48 <mps> ncopa: going out for some short time, please if you can post release tarballs for rpi armhf, would like to test it before official release
2020-01-16 14:55:11 <ncopa> i need to do that mkinitfs openssl fix first
2020-01-16 14:55:22 <ncopa> just want make sure it does not break everything
2020-01-16 14:57:11 <AinNero> 
ACTION never finished the automatic testing setup for early boot stuff

2020-01-16 15:09:56 <mps> ncopa: yes, this is important
2020-01-16 15:11:15 <mps> if you do 'lbu commit -d -e' and not have initramfs with fixes it will not boot properly next time
2020-01-16 15:13:48 <PureTryOut[m]> ncopa: yeah I'll have to disable armhf for the entirety of KDE. Already did KDE Frameworks and KDE Plasma, will do KDE Applications next
2020-01-16 15:27:25 <ncopa> weird, i wonder what kcgi chokes on. https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/kcgi/kcgi-0.10.12-r0.log
2020-01-16 15:27:30 <ncopa> does not happen in my dev env
2020-01-16 15:52:53 <ncopa> ok,i know why
2020-01-16 15:53:01 <ncopa> bmake parses MAKEFLAGS
2020-01-16 15:53:28 <ncopa> and the builders has MAKEFLAGS="-j$JOBS -l$JOBS"
2020-01-16 15:53:33 <ncopa> s/has/had/
2020-01-16 15:53:33 <alpine-meetbot> ncopa meant to say: and the builders had MAKEFLAGS="-j$JOBS -l$JOBS"
2020-01-16 15:53:48 <ncopa> i guess bmake did not regocnize the -l$JOBS part
2020-01-16 15:53:50 <ncopa> nasty.
2020-01-16 15:54:01 <_ikke_> ncopa: there is a related issue from PureTryOut[m] :)
2020-01-16 15:54:14 <_ikke_> We ran into that as well with another project
2020-01-16 15:54:39 <ncopa> ok
2020-01-16 15:54:52 <ncopa> i have set MAKEFLAGS="-j$JOBS" for now
2020-01-16 15:55:40 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/infra/issues/10665
2020-01-16 16:32:27 <ncopa> mps: pre-release of armhf here: https://dev.alpinelinux.org/~ncopa/armhf/
2020-01-16 16:33:05 <ncopa> i need to go out for a couple of hours, but will try tag the release later tonight
2020-01-16 16:33:05 <mps> https://dev.alpinelinux.org/~ncopa/armhf/alpine-rpi-20200116-armhf.tar.gz
2020-01-16 16:33:32 <ncopa> would be nice if i could get some help to have the edge builders pass
2020-01-16 16:33:48 <mps> lets search for free mmc card
2020-01-16 16:34:25 <ncopa> anyone else wants to test other arch?
2020-01-16 16:34:47 <ncopa> i have 5 mins to upload other test arch
2020-01-16 16:38:58 <mps> maybe I could try armv7 when finish with rpi armhf
2020-01-16 16:47:44 <ncopa> https://dev.alpinelinux.org/~ncopa/armv7/out/
2020-01-16 16:48:24 <ncopa> would be nice if someone can help write/prepare release notes (excl git shortlog)
2020-01-16 16:48:35 <ncopa> would save me a few mins later
2020-01-16 16:48:42 <ncopa> gotta run. laters
2020-01-16 16:50:19 <mps> ok, will try also test this
2020-01-16 16:50:54 <mps> someone with better git experience should raise hand for rel notes
2020-01-16 16:52:46 <mps> hmm, you didn't added mkinitfs fix?
2020-01-16 16:58:17 <artok> I can do some rpi test now
2020-01-16 16:58:20 <artok> if needed
2020-01-16 16:59:19 <mps> artok: only rpi armhf is put for test
2020-01-16 16:59:41 <artok> oh
2020-01-16 17:00:13 <mps> if you have armhf board url is above
2020-01-16 17:00:44 <mps> or generic armv7, url is also above
2020-01-16 17:02:38 <artok> "just" rpi3b+ and rpi4 next to me
2020-01-16 17:07:19 <mps> if they can work in 32bit mode maybe you can try https://dev.alpinelinux.org/~ncopa/armhf/alpine-rpi-20200116-armhf.tar.gz
2020-01-16 17:09:39 <artok> yeah they work, if there is kernel configured for them
2020-01-16 17:11:06 <mps> aha, so not straightly from tarball release
2020-01-16 17:12:29 <artok> rpi3 and rpi2 have same kernel
2020-01-16 17:12:51 <artok> so armhf should be ok
2020-01-16 17:17:10 <artok> and again I say:
2020-01-16 17:17:28 <artok> if kernel and initramfs are in sd card boot/ folder, it doesn't boot
2020-01-16 17:17:38 <artok> they need to be in the root of the sd card
2020-01-16 17:17:53 <artok> armv7 package tested on rpi3b+
2020-01-16 17:18:24 <artok> on sd card, mv boot/* .
2020-01-16 17:18:29 <mps> yes, I remember
2020-01-16 17:19:01 <mps> but in my case on rpi zero it boot fine though kernel and initramfs are under /boot
2020-01-16 17:19:58 <mps> and some people confirmed that it boots fine on their rpi3 or rpi4 boards
2020-01-16 17:22:13 <artok> and my both boards blink "kernel not found"
2020-01-16 17:22:27 <artok> 7 green led flash
2020-01-16 17:25:59 <mps> I remember your issue, but have not idea why that happens
2020-01-16 17:26:40 <artok> same thing with both of the boards, armv7 and armhf
2020-01-16 17:28:28 <mps> generic armv7 wouldn't work on rpis, afaik
2020-01-16 17:28:45 <artok> generic, no
2020-01-16 17:28:46 <mps> they don't have kernels for rpi
2020-01-16 17:29:36 <artok> but armv7 has rpi packages
2020-01-16 17:29:47 <mps> yes
2020-01-16 17:32:07 <mps> ah, see n_copa created also rpi armv7 besides generic
2020-01-16 17:32:24 <mps> I see*
2020-01-16 17:32:36 <artok> =)
2020-01-16 17:33:00 <mps> could anyone disable coreapps on armhf
2020-01-16 17:36:18 <artok> could you run 'vcgencmd version' on your rpi zero
2020-01-16 17:37:09 <mps> what does this command
2020-01-16 17:38:28 <artok> gives firmware of the videocore
2020-01-16 17:39:23 <artok> ..and the command is under /opt/vc/bin/ , raspberrypi package
2020-01-16 17:53:00 <mps> artok: nothing under /opt dir on armhf
2020-01-16 17:53:21 <artok> apk add raspberrypi,  as said ;)
2020-01-16 17:54:55 <mps> aha
2020-01-16 18:01:51 <mps> artok: /opt/vc/bin/vcgencmd
2020-01-16 18:02:34 <mps> run without any report, just get prompt again
2020-01-16 18:05:01 <artok> have parameter 'version'
2020-01-16 18:05:41 <mps> uh, why didn't tell me, have to reboot :)
2020-01-16 18:06:22 <mps> version 6820edeee4ef3891b95fc01cf02a7abd7ca52f17 (clean) (release) (start)
2020-01-16 18:10:10 <artok> well that is the same as on my rpi3
2020-01-16 18:11:37 <artok> so we can rule out videocore firmware
2020-01-16 18:11:45 <artok> "not being able to boot"
2020-01-16 18:12:59 <artok> ..or does 'vcgencmd vcos version' give same version hash?
2020-01-16 18:13:53 <mps> wait till reboot
2020-01-16 18:14:35 <mps> wifi is bad, dhcp timeout
2020-01-16 18:24:52 <mps>  /opt/vc/bin/vcgencmd vcos version => version 6820edeee4ef3891b95fc01cf02a7abd7ca52f17 (clean)
2020-01-16 18:26:23 <artok> so we're running same firmware 1:1, but I don't get booting done..
2020-01-16 18:26:34 <artok> unless...
2020-01-16 18:26:48 <artok> lemme fire up my poor old hp
2020-01-16 18:33:23 <artok> well no, was not about mac extracting the tar
2020-01-16 18:34:55 <artok> what filesystem id is your SD card first partition?
2020-01-16 18:35:13 <mps> VFAT?
2020-01-16 18:35:44 <artok> id c ?
2020-01-16 18:36:41 <mps> 512M  c Win95 FAT32 (LBA)
2020-01-16 18:37:21 <artok> so there is no difference at all, but my boards can't find the kernel =D
2020-01-16 18:38:17 <mps> you don't have big enough hammer? :)
2020-01-16 18:46:52 <artok> mc hammer
2020-01-16 19:56:21 <mps> ok, tested both release tarballs, armhf for RPi and generic armv7 on allwinner A20 board
2020-01-16 19:56:57 <mps> both works fine in diskless mode (lbu for saving changes)
2020-01-16 19:57:57 <mps> but both have issue when using 'lbu commit -e -d', i.e. this works fine for saving changes
2020-01-16 19:59:04 <mps> but on next boot both have problem to recognize openssl enc cipher and don't boot properly
2020-01-16 20:00:19 <mps> unpacking initramfs, change 'openssl list -1 -cipher-commands ...' and repack back initramfs solves this problem
2020-01-16 20:00:26 <mps> ncopa: ^
2020-01-16 20:01:34 <mps> without this hack got 'initramfs emergency recovery shell launched. Type 'exit' to continue boot' on both boards
2020-01-16 20:02:09 <mps> mkinitfs changes should be added
2020-01-16 20:05:05 <mps> i.e. upgrade mkinitfs to 3.4.5 on 3.11-stable
2020-01-16 20:16:39 <ncopa> ah, i forgot that part. thanks! for testing
2020-01-16 20:16:43 <ncopa> will backport it
2020-01-16 20:20:12 <mps> ok
2020-01-16 20:57:52 <ddevault> what is the purpose of the setup-apkcache command
2020-01-16 20:57:54 <ddevault> ncopa?
2020-01-16 20:58:31 <ddevault> it seems a lot more complex than just making the symlink, I'm not sure what it's trying to accomplish with mountpoints and such
2020-01-16 21:18:10 <ncopa> ddevault: ping me tomorrow about it
2020-01-16 21:18:15 <ddevault> can do
2020-01-16 21:18:15 <ncopa> i need tag 3.11.3 now
2020-01-16 21:24:35 <clandmeter> ddevault: im not sure (i didnt look at the code) but it normally is used on tmpfs installs.
2020-01-16 21:24:40 <ddevault> / high
2020-01-16 21:24:42 <ddevault> disregard
2020-01-16 21:24:51 <ddevault> clandmeter: thanks
2020-01-16 21:25:02 <ddevault> another question: what's the difference between apk add -u and apk add -l
2020-01-16 21:26:44 <clandmeter> so it probably has some logic to find the boot media like usb
2020-01-16 21:30:06 <clandmeter> i have not played much with those switches, some of them are also vague to me.
2020-01-16 21:30:28 <clandmeter> i think i never ever used -l
2020-01-16 21:33:18 <ddevault> reading the code and this is some arcane shit
2020-01-16 21:33:26 <ddevault> the solver might deserve its own manual page
2020-01-16 21:34:06 <ncopa> thank you for putting an effort in the docs
2020-01-16 21:34:13 <ddevault> np
2020-01-16 21:34:18 <ncopa> very needed and very valuable
2020-01-16 21:34:35 <clandmeter> it sure is
2020-01-16 21:36:30 <ncopa> i am so stupid
2020-01-16 21:36:40 <ncopa> oh no
2020-01-16 21:37:01 <ncopa> we need a new release engineer
2020-01-16 21:37:20 <ncopa> im gonna fire myself
2020-01-16 21:37:24 <ddevault> current best effort summary of these flags: https://paste.sr.ht/~sircmpwn/59940138c58ece2e00eff18e574fb37006a1ce04
2020-01-16 21:37:31 <ddevault> ncopa: what happened?
2020-01-16 21:37:38 <ncopa> i did a bad tag *again*
2020-01-16 21:37:50 <ddevault> I use a script to prevent that, you can use it if you wish
2020-01-16 21:37:54 <ddevault> ping me when you have put out the fires
2020-01-16 21:38:16 <ncopa> im so tired of this
2020-01-16 21:38:25 <ncopa> i dont even know where to start with the fires
2020-01-16 21:38:33 <ncopa> so what i did
2020-01-16 21:38:54 <ncopa> i created a new milestone in gitlab for next release, 3.11.4
2020-01-16 21:39:02 <ncopa> i updated alpine-base to 3.11.3
2020-01-16 21:39:09 <ncopa> then i tagged v3.11.4
2020-01-16 21:39:27 <ncopa> so the generated release will be v3.11.4
2020-01-16 21:39:36 <ncopa> there is no v3.11.3
2020-01-16 21:39:54 <ddevault> is the milestone used as an input into anything?
2020-01-16 21:40:27 <ddevault> it's not going to hurt anyone to just skip .3 and move on to .4, citing errors in the release process
2020-01-16 21:40:29 <ncopa> no, its just to organize the issues. i mentioned it only as an excuse for my mistake
2020-01-16 21:40:52 <ncopa> gitlab milestone is irrelevant
2020-01-16 21:41:04 <ncopa> the problem was that the "3.11.4" was in my head
2020-01-16 21:41:58 <MY-R> ncopa, you probably made it so many times that already got "muscle" memory, maybe time to print some page with checklist? :D
2020-01-16 21:42:07 <ddevault> https://drewdevault.com/2019/10/12/how-to-fuck-up-releases.html
2020-01-16 21:42:18 <ncopa> whats more embarrasing is that i did similar mistake last release
2020-01-16 21:42:28 <ncopa> MY-R: i do have a checklist
2020-01-16 21:42:33 <ncopa> oh well
2020-01-16 21:42:35 <MY-R> :D
2020-01-16 21:42:54 <ncopa> the mistake is to do the work when im tired
2020-01-16 21:42:57 <ncopa> late evening
2020-01-16 21:43:00 <ncopa> late in the week
2020-01-16 21:43:08 <ncopa> shouldnt do release on fridays either
2020-01-16 21:43:35 <ncopa> but "at some point you need shoot your engineers and just ship the product"
2020-01-16 21:43:43 <ncopa> otherwise it never gets out
2020-01-16 21:44:08 <ddevault> note: today is thursday
2020-01-16 21:44:23 <ncopa> but its late and im tired
2020-01-16 21:44:31 <ddevault> :)
2020-01-16 21:44:36 <ddevault> ship when the sun is out
2020-01-16 21:44:37 <ncopa> and i dont want to ship it tomorrow becuase its not good to release on fridays...
2020-01-16 21:44:52 <ncopa> oh well
2020-01-16 21:45:13 <ddevault> wait, are you suggesting abort the release train and deal with it tomorrow?
2020-01-16 21:45:18 <ddevault> _next time_ don't release when it's last
2020-01-16 21:45:24 <ddevault> it'll probably get worse if you stop halfway there now
2020-01-16 21:46:15 <ncopa> hum
2020-01-16 21:46:21 <ncopa> i have two options
2020-01-16 21:46:27 <ddevault> when it's late*
2020-01-16 21:46:42 <ncopa> 1) announce 3.11.4 and pretend nothing happened
2020-01-16 21:47:06 <MY-R> wait, so same mistake like with .1 version? :D
2020-01-16 21:47:13 <ncopa> people may notice that /etc/os-release and /etc/alpine-release says 3.11.3
2020-01-16 21:47:25 <ncopa> MY-R: almost same mistake
2020-01-16 21:47:32 <MY-R> I mentioned today about it so you can blame me :D
2020-01-16 21:47:44 <ncopa> i tagged before I did the commit
2020-01-16 21:48:08 <ncopa> second option is to tag v3.11.3 too
2020-01-16 21:48:26 <MY-R> "commit" - check!
2020-01-16 21:48:29 <MY-R> "tag" - check!
2020-01-16 21:48:31 <MY-R> :P
2020-01-16 21:48:34 <ncopa> and then delete the 3.11.4 files
2020-01-16 21:48:35 <ddevault> suggested resolution: https://paste.sr.ht/~sircmpwn/b83db49c38983cf2957519b01dbb2b9475c2aada
2020-01-16 21:49:06 <ncopa> yeah that is the cleanest thing to do
2020-01-16 21:49:33 <ncopa> i could also delete v3.11.4 and jump to v3.11.5 next time
2020-01-16 21:49:44 <ddevault> up to you
2020-01-16 21:49:52 <ddevault> jumping to 3.11.5 now is least likely to cause you annoyances in the future
2020-01-16 21:50:03 <ddevault> but 3.11.3 now and skip .4 later is probably possible
2020-01-16 21:53:19 <mps> hmm, tomorrow is also nice day for release
2020-01-16 21:55:14 <ncopa> i tagged 3.11.3
2020-01-16 21:55:21 <ncopa> i will skip 3.11.4 next time
2020-01-16 21:56:11 <ncopa> i need a githook for checking this
2020-01-16 21:56:14 <ncopa> before push
2020-01-16 21:57:33 <ddevault> https://git.sr.ht/~sircmpwn/dotfiles/tree/master/bin/semver
2020-01-16 22:04:46 <ncopa> im going to bed. will announce 3.11.3 tomorrow
2020-01-16 22:06:22 <ddevault> o/
2020-01-16 22:06:27 <mps> very good idea, good night
2020-01-16 22:07:20 <mps> and, sleep well and don't think about alpine, please :) everything is ok
2020-01-16 22:16:35 <MY-R> :D
2020-01-16 22:39:26 <alpurn> Not sure how many of you are also in #alpine - but I believe this question may be better asked here - I am a (third-party) package maintainer and am struggling to understand what I'm missing in this build process.
2020-01-16 22:39:50 <alpurn> This is what's being executed : https://git.riboflav.in/snippets/4
2020-01-16 22:40:40 <alpurn> To clarify : ppp is fetched, the apkindex is signed however when the OS boots on a pi - ppp is nowhere to be found (also lives in /etc/apk/world)
2020-01-16 22:41:29 <alpurn> The strange piece here is that usb_modeswitch *is* included in the running image - it is included in precisely the same manner.
2020-01-16 22:43:49 <ddevault> https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/9
2020-01-16 22:43:54 <ddevault> all of the man pages are now written
2020-01-17 05:48:36 <rahmanshaber[m]> please accept this MR. i will enble "check" in next release.
2020-01-17 05:48:36 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3074
2020-01-17 05:50:38 <_ikke_> rahmanshaber[m]: just removing the "!check" option is not enough, you will need to define a check() function that calls some kind of test suite
2020-01-17 05:51:35 <rahmanshaber[m]> is this new? because i ported 19 apps that did not required that "check" option.
2020-01-17 05:51:47 <_ikke_> since when?
2020-01-17 05:51:56 <_ikke_> that has been the case for more then a year now
2020-01-17 05:52:36 <rahmanshaber[m]> https://github.com/alpinelinux/aports/pull/9716
2020-01-17 05:53:16 <rahmanshaber[m]> <_ikke_ "rahmanshaber: just removing the "> how i will add that test suite in check option? and reference ?
2020-01-17 05:53:38 <_ikke_> rahmanshaber[m]: do you know if there even is a test suite for those projects?
2020-01-17 05:54:18 <rahmanshaber[m]> what project? coreapps?
2020-01-17 05:54:40 <_ikke_> doesn't seem so
2020-01-17 05:54:44 <_ikke_> at least not for coretoppings
2020-01-17 05:56:05 <rahmanshaber[m]> there is no test suite for coreapps. they are just simple desktop apps, don't know what to test on this
2020-01-17 05:56:08 <_ikke_> so the comment from Cogitri means that you add a short comment in the APKBUILD why no tests are run. In this case because there are no tests (I can add that comment)
2020-01-17 05:57:21 <rahmanshaber[m]> <_ikke_ "so the comment from Cogitri mean"> please do.
2020-01-17 05:57:50 <rahmanshaber[m]> giiiiiiiitttt. what an innovation.
2020-01-17 05:58:06 <rahmanshaber[m]> i will add that comment in next release MR.
2020-01-17 05:58:07 <_ikke_> done and pushed
2020-01-17 05:59:38 <rahmanshaber[m]> MR closed means it added, right?
2020-01-17 06:02:31 <_ikke_> yes
2020-01-17 06:03:02 <_ikke_> We don't do actual merges, but apply the commits on the latest master
2020-01-17 06:03:16 <_ikke_> so gitlab doesn't recognize it's merged
2020-01-17 06:04:16 <rahmanshaber[m]> ohh. A thanks form the heart _ikke_ . thanks a lot.
2020-01-17 06:04:25 <_ikke_> No problem
2020-01-17 06:04:30 <_ikke_> You're welcome
2020-01-17 06:07:35 <rahmanshaber[m]> waiting here to to see the MR as packages. Love this things.
2020-01-17 06:07:36 <rahmanshaber[m]> https://pkgs.alpinelinux.org/packages
2020-01-17 06:07:57 <_ikke_> that will take about 30 minutes
2020-01-17 06:35:00 <ncopa> morning
2020-01-17 06:35:06 <ncopa> im continuing with the 3.11.3 release now
2020-01-17 06:37:18 <Cogitri> Morning :)
2020-01-17 06:53:47 <ncopa> does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.11.3-released.html
2020-01-17 07:03:40 <Cogitri> Looks good to me, but I haven't followed 3.11 too closely
2020-01-17 07:13:39 <ncopa> drats
2020-01-17 07:13:50 <ncopa> armhf is still defunct
2020-01-17 07:13:53 <ncopa> and i did snapshot
2020-01-17 07:14:17 <ncopa> there are no snapshot for armhf in other words
2020-01-17 07:16:28 <Cogitri> What's defunct about it? :o
2020-01-17 07:16:58 <ncopa> this d33b26afd532c021810d466a6c1a229d6e187ca3
2020-01-17 07:17:08 <ncopa> but there are a ton of packages that depends on it
2020-01-17 07:17:13 <ncopa> and those was not disabled
2020-01-17 07:17:37 <ncopa> so now we ahve a zillion errors liek: https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/kaccounts-providers/kaccounts-providers-19.12.0-r1.log
2020-01-17 07:18:41 <ncopa> im seriously considering nuking armhf of the orbit...
2020-01-17 07:19:14 <Cogitri> Ah right, I somehow had hoped that we had taken care of that now since the builders seemed happy for a bit a few days ago after disabling loads of KDE packages
2020-01-17 07:19:37 <Cogitri> Well, I certainly wouldn't veto dropping armhf
2020-01-17 07:20:13 <Cogitri> Maybe a todo for 3.12
2020-01-17 07:43:14 <ncopa> but i think it would be better if someone could help fix https://bugreports.qt.io/browse/QTBUG-65246
2020-01-17 08:00:52 <ncopa> i need to go out for a few hours. it would be awesome if someone could help me make the armhf builder pas one way or the other
2020-01-17 08:01:31 <ncopa> i may be able to manually hack the 20200117 snashot so we can push a new edge docker image
2020-01-17 08:01:39 <ncopa> i cannot do that without armhf
2020-01-17 08:02:06 <ncopa> as it would result in edge docker image for armhf would disappear
2020-01-17 08:02:29 <ncopa> unless i start track different versions of different arches manually...
2020-01-17 08:02:42 <Cogitri> I can look into it, most of the difficult exams are done now fortunately
2020-01-17 08:02:56 <ncopa> Cogitri: i hope you did good in those
2020-01-17 08:03:05 <ncopa> that it went well
2020-01-17 08:05:12 <markand> anyone for https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2976 ?
2020-01-17 08:07:55 <ncopa> sigh.... this release has been an uphill battle...
2020-01-17 08:08:31 <_ikke_> ncopa: at least, congrats
2020-01-17 08:08:46 <ncopa> lat point on the checklist: celebrate....
2020-01-17 08:08:58 <_ikke_> \o/\/o\/o4
2020-01-17 08:44:38 <fredrigu> where can I find the source code for pkgs.aplinelinux.org, if I want to host my own version of it
2020-01-17 08:48:21 <Cogitri> ncopa: I don't have the results yet, but I think they went OK
2020-01-17 08:48:25 <Cogitri> Thanks :)
2020-01-17 08:48:50 <_ikke_> fredrigu: https://github.com/alpinelinux/aports-turbo
2020-01-17 09:23:38 <fredrigu> _ikke_: thanks
2020-01-17 09:37:30 <clandmeter> fredrigu: if you like using docker: https://gitlab.alpinelinux.org/alpine/infra/docker/aports-turbo
2020-01-17 10:13:33 <fredrigu> clandmeter: thanks!
2020-01-17 11:05:17 <mps> so, what is current 3.11 subrelease? 3.11.3 or 3.11.4
2020-01-17 11:08:00 <mps> 3.11.3 officially, but I see 3.11.4 tarballs also made
2020-01-17 11:09:13 <mps> on 3.11.3 lbu commit -e (encrypt) is still not fixed
2020-01-17 11:09:46 <mps> hmm, still isn't fixed*
2020-01-17 11:10:49 <mps> and I don't know is this important bug
2020-01-17 12:21:35 <fredrigu> I've a recollection about that there has been a discussion about having multiple versions of the same apk in the same repo. Is this only something I've dreamed?
2020-01-17 12:22:13 <_ikke_> fredrigu: maybe package variants (recent discussion)?
2020-01-17 12:23:12 <fredrigu> hmm, maybe. I don't recall that discusion
2020-01-17 12:23:36 <_ikke_> https://lists.alpinelinux.org/~alpine/devel/%3Caa66ed8e48403563b5bdcf9f87da924eae654559.camel%40cogitri.dev%3E
2020-01-17 12:26:17 <fredrigu> no, that was not what I thought about. But that's also an interesting discussion. What I mean is say pkgA_v1.0 has a security update pkgA_v1.1, then in alpine pkgA_v1.0 will be removed from the apk-repository. Instead of just adding pkgA_v1.1 and have both in the repo
2020-01-17 12:26:27 <fredrigu> I'm not sure why this is done this way
2020-01-17 12:26:38 <_ikke_> fredrigu: mostly to save space
2020-01-17 12:26:49 <_ikke_> storing every package version takes up a lot of space
2020-01-17 12:27:21 <fredrigu> ah I see, but apk should be able to handle it?
2020-01-17 12:27:41 <_ikke_> It might also only store one version in the index
2020-01-17 12:30:26 <fredrigu> hmm, that's interesting
2020-01-17 12:31:34 <fredrigu> seems as I need to investiga this some more
2020-01-17 12:38:01 <clandmeter> Check fabled email about new apktools
2020-01-17 12:38:21 <clandmeter> It mentions better support for multiple versions
2020-01-17 12:39:01 <clandmeter> Not sure in which case
2020-01-17 12:39:57 <_ikke_> fredrigu: this one https://lists.alpinelinux.org/~alpine/devel/%3C20191230145542.1a7ca9cf%40vostro%3E
2020-01-17 12:40:29 <clandmeter> Could be only the build part he refers to
2020-01-17 12:58:17 <fredrigu> clandmeter: _ikke_ thanks! That's more what I wanted
2020-01-17 14:06:02 <ddevault> gz on the release :)
2020-01-17 14:06:07 <ddevault> fraught as it may have been
2020-01-17 14:09:58 <mps> 'gz'
2020-01-17 14:10:08 <ddevault> contrats
2020-01-17 14:10:14 <ddevault> congrats*
2020-01-17 14:10:18 <mps> aha, thanks
2020-01-17 14:10:28 <mps> thanks for explanation
2020-01-17 14:11:03 <mps> but encrypted lbu is not fixed, 'lbu commit -e'
2020-01-17 14:58:15 <ddevault> ncopa: when you get a few minutes, can you take a look at this patch? https://lists.alpinelinux.org/~alpine/devel/patches/3214
2020-01-17 16:02:04 <ncopa> ddevault: looking at it now
2020-01-17 16:02:20 <ncopa> my desktop is freezing
2020-01-17 16:02:23 <ddevault> thanks :)
2020-01-17 16:02:25 <ddevault> oh :(
2020-01-17 16:02:59 <alpurn> make -j
2020-01-17 16:03:02 <markand> omg 49 pages of patches with some from 13 years ago Oo
2020-01-17 16:03:29 <ncopa> i think its the gpu that freezes
2020-01-17 16:04:18 <ncopa> [88278.571863] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
2020-01-17 16:04:18 <ncopa> [88280.705132] i915 0000:00:02.0: Resettin[88278.571863] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
2020-01-17 16:04:18 <ncopa> [88280.705132] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0g rcs0 for hang on rcs0
2020-01-17 16:06:53 <mps> ncopa: uname -a
2020-01-17 16:08:56 <mps> maybe related to this https://lists.freedesktop.org/archives/dri-devel/2020-January/252142.html
2020-01-17 16:16:08 <ncopa> Linux ncopa-desktop 5.4.12-1-lts #2-Alpine SMP Thu, 16 Jan 2020 12:36:31 UTC x86_64 Linux
2020-01-17 16:16:38 <ncopa> i think north1 had freezes on intel gpu as well some time ago
2020-01-17 16:16:45 <ncopa> not sure it was fixed upstream
2020-01-17 16:16:47 <north1> Still have
2020-01-17 16:16:56 <ncopa> ah, so they didnt backport it yet
2020-01-17 16:17:06 <ncopa> ok
2020-01-17 16:17:23 <ncopa> maybe i should try backport it myself
2020-01-17 16:17:54 <Cogitri> I sometimes have that too on my laptop :c
2020-01-17 16:18:07 <ncopa> there was some nasty conflicts which i have commented before, but i think i got the answer i needed
2020-01-17 16:18:15 <ncopa> so i belive it should be possible to backport it
2020-01-17 16:18:22 <ncopa> and see what happens :)
2020-01-17 16:18:42 <ncopa> will try allocate time for it next week
2020-01-17 16:19:30 <ncopa> (im on my macbook right now...)
2020-01-17 16:19:54 <ncopa> ddevault: re that patch 1) awesome! would be great with crypt support out of the box
2020-01-17 16:20:12 <mps> I looked in 5.5-rc6 but didn't found what should be backported, and even if found I can't test because my i915 works without big issues after 5.4.5 or 5.4.6
2020-01-17 16:21:28 <ncopa> 2) I have always tried to minimize the number of questions asked, so i wonder if we can skip the extra "do you want to crypt Y/N"
2020-01-17 16:21:40 <ddevault> so always encrypt?
2020-01-17 16:22:03 <ddevault> I feel like users need informed consent for encryption
2020-01-17 16:22:04 <ncopa> well, or we could have a "sys" "syscrypt" opt or similar
2020-01-17 16:22:28 <ddevault> because they have to be aware of the implications (forget password and it's lost forever) and understand how to be a good steward of encrypted data
2020-01-17 16:22:32 <ddevault> hm, maybe
2020-01-17 16:22:46 <ddevault> can you say as much in the form of a reply to the thread on the ML?
2020-01-17 16:22:58 <ncopa> will do when i get my machine working
2020-01-17 16:23:05 <ddevault> thanks!
2020-01-17 16:23:35 <ncopa> another thing, i think we cannot use the USE_CRYPT var in install_mounted_root function (or what it is called)
2020-01-17 16:24:01 <ddevault> how so?
2020-01-17 16:24:05 <ncopa> because you can manually create the partitions the way you want, and then run: setup-disk /mounted-root
2020-01-17 16:24:26 <ncopa> so it needs to figure out itself that it is encrypted or not
2020-01-17 16:24:34 <ncopa> actually, that may be the first step
2020-01-17 16:24:34 <ddevault> hm, understood
2020-01-17 16:25:07 <ncopa> so you can mount xfs or some other filesystem, have /home on different partition etc
2020-01-17 16:25:16 <ncopa> lvm or mdadm whatever
2020-01-17 16:25:22 <ncopa> in any crazy combo
2020-01-17 16:25:37 <ncopa> and setup-disk /mountpoint will figure it out
2020-01-17 16:25:53 <ncopa> that the idea at least
2020-01-17 16:26:10 <ddevault> I will address this use-case in the next patch
2020-01-17 16:26:28 <ddevault> but also feel like I should state that going off of the setup-alpine rails during an installation is a poor user experience right now
2020-01-17 16:26:47 <ncopa> i guess i shoudl have responded all this in an email, but my desktop is broke :-(
2020-01-17 16:26:55 <ncopa> yeah
2020-01-17 16:26:58 <ddevault> it's alright, I appreciate the feedback regardless
2020-01-17 16:27:18 <ncopa> i havent put too muuch effert recently because what i really want to do is rewrite it in lua or similar
2020-01-17 16:27:33 <ncopa> or maybe even C
2020-01-17 16:27:41 <ddevault> eeeeeeh
2020-01-17 16:27:47 <ncopa> lua
2020-01-17 16:27:49 <ncopa> :)
2020-01-17 16:27:56 <ddevault> eeeeeeh
2020-01-17 16:28:05 <ddevault> honestly I like it as a shell script. Nothing beats shell scripts for stringing commands together
2020-01-17 16:28:21 <ddevault> I'm already uncomfortable with the present level of lua involvement in alpine
2020-01-17 16:28:31 <ncopa> lua is nice
2020-01-17 16:28:36 <ncopa> its small, its fast
2020-01-17 16:28:38 <ddevault> I think a better approach would be to maintain two installation paths
2020-01-17 16:28:41 <ddevault> on rails with setup-alpine
2020-01-17 16:28:51 <ddevault> and off rails with a nice wiki page detailing the manual instructions, using no setup-* scripts at all
2020-01-17 16:29:06 <ncopa> arch linux style
2020-01-17 16:29:07 <ddevault> the latter is how builds.sr.ht's alpine images are built, for example
2020-01-17 16:29:14 <ddevault> aye
2020-01-17 16:29:30 <ddevault> but I think setup-alpine is good for the easy path
2020-01-17 16:29:57 <ncopa> what i´d want is something similar to what we have. looks very simple on the front
2020-01-17 16:30:02 <ncopa> very few questions asked
2020-01-17 16:30:12 <ncopa> you can press enter N times and have a working system
2020-01-17 16:30:17 <pltrz[m]> ddevault: this is something I have always wanted in alpine, but avoided since it wasn't documented that well or the info was fragmented
2020-01-17 16:30:42 <ncopa> but i´d like to be able to go backwards in the "wizard"
2020-01-17 16:30:43 <ddevault> having dissected the alpine installation several times, I'm probably qualified to write those docs
2020-01-17 16:30:53 <ddevault> improving docs is something I'd like focus on in general for alpine
2020-01-17 16:31:04 <ncopa> im so happy that you are helping with that
2020-01-17 16:31:06 <ddevault> but only if the rest of the community is interested in supporting such an installation flow
2020-01-17 16:31:19 <mps> setup-alpine is nice, mostly pressing enter to the end works :)
2020-01-17 16:31:22 <MY-R> I'm setting up full disk encryption with luks - lvm and after reboot using setup-alpine and done :P
2020-01-17 16:31:29 <ncopa> mps: thats the idea
2020-01-17 16:31:43 <ncopa> there is even a -q mode
2020-01-17 16:31:45 <ncopa> quick mode
2020-01-17 16:32:03 <pltrz[m]> ddevault: although my experience is a bit more limited, I'd totally be willing to help out with that
2020-01-17 16:32:10 <ncopa> i also want <tab> autocomplete
2020-01-17 16:32:36 <mps> yesterday when testing release on two boards reinstalling few times on each I was so grateful to author of setup-alpine
2020-01-17 16:33:05 <ncopa> and i´d like to have support for fully automated or parital automated
2020-01-17 16:33:13 <ncopa> so you could feed it with a json or similar
2020-01-17 16:33:20 <ncopa> and it would set it all up for you
2020-01-17 16:33:22 <ddevault> my opinion is that there are two ways of installing the system
2020-01-17 16:33:28 <ddevault> the perscribed way, and the manual way
2020-01-17 16:33:28 <ncopa> no questions asked
2020-01-17 16:33:39 <ncopa> or you could have it ask only about the password
2020-01-17 16:33:44 <ddevault> attempting to automate anything in between is just going to cause either confusion for inexperienced users, or frustration for experienced users
2020-01-17 16:33:45 <ncopa> the rest automatted
2020-01-17 16:34:25 <ddevault> if you know what you want the installation to do, then you can just do it, and if the tool prevents you from tweaking that thing you want to tweak then the whole tool becomes effectively worthless for your installation process
2020-01-17 16:34:33 <ddevault> if you don't know what you want the installation to do, then you probably don't need a lot of knobs to tweak
2020-01-17 16:34:43 <mps> sometimes I install it 'manual way', setup-* in correct order with some actions needed in between
2020-01-17 16:34:58 <ddevault> yeah, I do that sometimes too
2020-01-17 16:35:13 <ddevault> but it's error prone, various things can (and do) fail when you dissect the process like that
2020-01-17 16:35:40 <ddevault> I've also had to completely reboot and start over with the installation procedure because my manual interventions have caused something automated down the line to trip up
2020-01-17 16:35:41 <mps> that's true
2020-01-17 16:36:25 <ncopa> have a nice weekend
2020-01-17 16:36:34 <ddevault> o/
2020-01-17 16:36:36 <mps> \o
2020-01-17 16:39:11 <pltrz[m]> o/
2020-01-17 16:40:32 <Cogitri> I usually just do a chroot install with only apk-static, it's easier to do nonstandard stuff that way
2020-01-17 17:00:37 <mps> north1: fcolista: what you think about backporting just upgraded acme.sh to 3.11
2020-01-17 17:01:11 <mps> I started to test it but you was faster
2020-01-17 17:01:13 <north1> I can do it Sunday if nobody does
2020-01-17 17:01:29 <mps> nice
2020-01-17 17:01:51 <north1> Going to dinner and Saturday I'll be visiting the Black forest
2020-01-17 17:02:10 <mps> 'Black forest'?
2020-01-17 17:02:27 <mps> Schwartzwald?
2020-01-17 17:06:02 <north1> Yes
2020-01-17 17:07:11 <mps> nice, enjoy this beautiful mountain :)
2020-01-17 17:23:19 <north1> Thanks!
2020-01-17 17:29:15 <Cogitri> We don't have a way to say that a package either needs package X or Y during runtime, right?
2020-01-17 17:30:04 <Cogitri> We have kind of a unfortunate situation with libsecret which needs some secret provider and crashes itself (and anything which depends on it) during runtime if there is none available
2020-01-17 17:30:28 <_ikke_> It's the other way around
2020-01-17 17:30:31 <_ikke_> we have provides
2020-01-17 17:30:42 <Cogitri> And we can't just depend on one certain key ring since you can use gnome-keyring, kwallet, keepasxc and so on
2020-01-17 17:30:43 <_ikke_> so more than 1 package can provide a dependency
2020-01-17 17:31:05 <Cogitri> So we can have a virtual/meta package for a secret provider?
2020-01-17 17:31:17 <_ikke_> The problem is, that we don't have a way for users to decide what dependency to pick (like pacman has for example)
2020-01-17 17:31:38 <Cogitri> Yup, apk just tells you to install one of them because it can't decide, doesn't it?
2020-01-17 17:31:52 <Cogitri> (At least it does that for cmd:)
2020-01-17 17:32:05 <_ikke_> With provides it would pick 1 (potentially with the highest priority)
2020-01-17 17:32:37 <_ikke_> If that's the case, it can work
2020-01-17 17:32:41 <Cogitri> Ah, okay
2020-01-17 17:32:58 <_ikke_> Something worth to test I guess
2020-01-17 17:33:07 <Cogitri> Yup, sounds good
2020-01-17 17:33:35 <Cogitri> If the user as the virtual package installed and it pulls in e.g. Gnome-keyring and they install kwallet later on (explicitly so it's in world), would gnome-keyring be purged?
2020-01-17 17:33:49 <_ikke_> I don't think so
2020-01-17 17:33:56 <_ikke_> They don't conflict with eachother
2020-01-17 17:33:57 <Cogitri> Hm, okay
2020-01-17 17:34:06 <_ikke_> Do they conflict?
2020-01-17 17:34:12 <Cogitri> No
2020-01-17 17:34:13 <_ikke_> Ok
2020-01-17 17:34:50 <Cogitri> Expected apk would go "Virtual package's dep is satisfied elsewhere, gnome-keyring isn't in world file, let's purge it" basically
2020-01-17 17:34:54 <Cogitri> But I guess that might be kinda unexpected as well
2020-01-17 17:35:08 <Cogitri> Anyway, I'll give that a to, thanks _ikke_
2020-01-17 17:35:48 <_ikke_> I'm not certain what will happen
2020-01-17 18:28:18 <mps> I hope we don't want apt on alpine
2020-01-17 18:35:47 <Cogitri> Context?
2020-01-17 18:36:07 <_ikke_> I guess the mailing list post about new apk index format
2020-01-17 18:38:00 <mps> _ikke_: if you talking about my msg, then no. ML list posts is ok imo
2020-01-17 18:38:07 <Cogitri> Ah
2020-01-17 18:38:08 <_ikke_> ok :)
2020-01-17 18:38:18 <_ikke_> There were some references to debian there
2020-01-17 18:39:28 <mps> Timos proposal for changes are fine, and I don't have impression that it will finish with complicated dependencies for pkgs
2020-01-17 20:02:07 <Cogitri> Does someone have plans to do a mass purge on issues?
2020-01-17 20:02:26 <Cogitri> I feel like it might be time to close package requests that are some 8 years old
2020-01-17 20:12:51 <mps> kernel 5.4.13 is out. no mention about i915 CVE fix
2020-01-17 20:40:25 <clandmeter> Cogitri: i would start by cleaning issues that make no sense anymore (and are overdue)
2020-01-17 20:40:39 <clandmeter> and i guess the very old ones probably do
2020-01-17 20:40:45 <clandmeter> do not make sense :)
2020-01-17 20:55:28 <Cogitri> Yup, gonna look into those tomorrow
2020-01-17 21:27:52 <_ikke_> FYI: We are going to upgrade gitlab, so it will be unavailable for a moment
2020-01-17 21:29:55 <mps> just in the half if the kernel build ;)
2020-01-17 21:30:17 <mps> s/if/in/
2020-01-17 21:30:17 <alpine-meetbot> mps meant to say: just in the half in the kernel build ;)
2020-01-17 21:30:48 <clandmeter> should not matter if _ikke_ hurries :)
2020-01-17 21:30:59 <clandmeter> the runner will reconnect?
2020-01-17 21:31:08 <clandmeter> maybe it will be offline too long though
2020-01-17 21:31:15 <mps> ah, fantastic
2020-01-17 21:31:20 <_ikke_> I think so, not sure how far it depends on gitlab being online
2020-01-17 21:31:35 <clandmeter> last time it timed out
2020-01-17 21:31:40 <clandmeter> after x ttries
2020-01-17 21:31:45 <clandmeter> maybe we can increase it a bit
2020-01-17 21:32:32 <mps> 'An error occurred while fetching the pipeline.'
2020-01-17 21:32:51 <_ikke_> yes, that's logical
2020-01-17 21:32:53 <clandmeter> oh it was failing lsat time due to artifacts
2020-01-17 21:33:45 <clandmeter> maybe in build it will recoorect
2020-01-17 21:33:49 <clandmeter> reconnect even
2020-01-17 21:33:57 <mps> no problem
2020-01-17 21:34:41 <mps> I'm not complaining
2020-01-17 21:34:57 <_ikke_> It's starting already
2020-01-17 21:34:59 <mps> just wanted to inform you what I see
2020-01-17 21:35:12 <_ikke_> As a compensation, you will get nicer looking logs :)
2020-01-17 21:35:37 <clandmeter> Starting Gitlab..
2020-01-17 21:35:52 <_ikke_> It's up
2020-01-17 21:35:52 <clandmeter> \o/
2020-01-17 21:36:16 <clandmeter> Components: up-to-date
2020-01-17 21:38:17 <_ikke_> mps: seems like the builds are still continuing :)
2020-01-17 21:38:43 <mps> yes, just looking at it
2020-01-17 21:38:51 <_ikke_> Do you like the new logs?
2020-01-17 21:39:40 <mps> logs?
2020-01-17 21:39:51 <_ikke_> log output from CI
2020-01-17 21:39:55 <mps> ah line numbers
2020-01-17 21:40:21 <clandmeter> there is more
2020-01-17 21:40:27 <clandmeter> its more clear for me
2020-01-17 21:40:31 <clandmeter> bigger font
2020-01-17 21:40:47 <clandmeter> not sure
2020-01-17 21:40:54 <clandmeter> ikke is used to looking at it :)
2020-01-17 21:40:59 <mps> yes, fonts are more readable
2020-01-17 21:42:18 <mps> looks like this GL upgrade have more heavy javascript
2020-01-17 21:48:26 <_ikke_> Nicer arrows on the side
2020-01-17 21:48:35 <_ikke_> some parts have time indiciation
2020-01-17 21:49:54 <mps> yes, noticed time in CI logs
2020-01-17 21:51:25 <mps> only some fonts are missing on my side, don't know which one
2020-01-17 21:52:16 <mps> probably ttf-font-awesome
2020-01-17 22:32:05 <MY-R> mps, try with noto fonts: font-noto font-noto-emoji
2020-01-17 22:32:43 <mps> I dislike it in terminals
2020-01-17 22:33:55 <MY-R> emoji? those will work only in few I think
2020-01-17 22:34:59 <mps> they are ugly in st term
2020-01-17 22:35:24 <MY-R> ye can imagine :P
2020-01-17 22:36:17 <MY-R> but color noto looks nice in my hexchat, dont have to copy/paste square icons from irc to google search :D
2020-01-17 22:36:45 <mps> I use irssi for irc
2020-01-17 22:38:16 <MY-R> :<
2020-01-17 22:41:56 <kaniini> north1: you're Leo, right?
2020-01-17 22:42:02 <kaniini> north1: if so, those changes are fine
2020-01-17 22:42:30 <mps> _ikke_: this new pop up about tabs is annoying
2020-01-17 22:44:58 <mps> kaniini: can I PM you
2020-01-17 22:45:05 <kaniini> mps: yes
2020-01-17 22:49:54 <kaniini> oh
2020-01-17 22:50:43 <mps> kaniini: Leo is north1 here
2020-01-17 22:50:49 <kaniini> yeah
2020-01-17 22:50:51 <kaniini> i thought so
2020-01-17 22:51:07 <mps> but he went to visit some mountains
2020-01-17 22:51:12 <north1> kaniini (IRC): ok, good
2020-01-17 22:51:29 <mps> hah, he is here still
2020-01-17 22:51:35 <north1> mps (IRC): Not yet, i was going tomorrow to The Black Forest but decided to go to Ulm instead
2020-01-17 22:51:51 <north1> i really should go sleep so i wake up in time to take the planned route
2020-01-17 22:52:09 <mps> good night and sleep well
2020-01-17 22:53:31 <mps> btw, there is 5.4.13 on CI
2020-01-17 22:53:46 <north1> I saw but i'll stick to 4.x until 5.5.x is out
2020-01-17 22:54:31 <mps> yes, 5.5 is better. I run it on exynos chromebook
2020-01-17 22:54:46 <mps> 5.5-rc6
2020-01-17 22:55:59 <north1> Nice, hopefully the Intel-drm fixes are merged in
2020-01-17 22:56:32 <mps> some are but not sure about your issue
2020-01-17 22:57:22 <mps> but, good night again :)
2020-01-17 23:50:46 <ddevault> maybe before we overhaul apk a survey of current users should be performed to find out what people use it for and why they like it
2020-01-18 01:50:42 <russkel> hey all, any chance someone could lend their expertise in helping me solve this compile error? https://gitlab.alpinelinux.org/russkel/aports/-/jobs/34962#L917
2020-01-18 01:50:53 <russkel> I don't understand what is going on
2020-01-18 01:59:10 <mps> https://gitlab.alpinelinux.org/russkel/aports/-/jobs/34962#L931
2020-01-18 02:00:34 <russkel> that particular function uses some C++ template stuff
2020-01-18 02:05:13 <russkel> https://github.com/opencv/opencv/blob/master/modules/core/src/system.cpp#L1939 ?
2020-01-18 02:08:10 <mps> I'm not so proficient in C++ to debug this
2020-01-18 02:08:24 <russkel> likewise likewise
2020-01-18 02:10:26 <russkel> could it be a namespace issue? is it trying to fortify cv::read instead of some other read function?
2020-01-18 07:59:46 <Cogitri> russkel: Seems like opencv doesn't like D_FORTIFY_SOURCE
2020-01-18 08:00:15 <russkel> Cogitri, yeah and I was wondering specifically why that is
2020-01-18 08:02:27 <Cogitri> Well, unistd.h mentions something about global scope so I guess for *some* reason it evaluates it out of its namespace where it's bound to conflict with read() and write()
2020-01-18 08:03:07 <russkel> I checked and none of the includes in the chain seem to be from within the cv:: namespace
2020-01-18 08:03:13 <russkel> although I could be missing something
2020-01-18 08:03:28 <Cogitri> Yes, we force that with fortify source
2020-01-18 08:03:37 <Cogitri> I'll give it a look in a bit
2020-01-18 08:04:35 <russkel> thanks :D
2020-01-18 11:23:31 <_ikke_> Thunderbird fails with: "Error: selected processor does not support `sbfx r11,r6,#12,#16' in ARM mode"
2020-01-18 11:26:49 <Cogitri> Ah, on armhf?
2020-01-18 11:26:58 <Cogitri> Gotta disable it too, I suppose
2020-01-18 11:32:26 <_ikke_> Cogitri: yes, indeed, armhf
2020-01-18 11:33:09 <Cogitri> Yeah, armhf isn't having a goof couple of days
2020-01-18 14:37:44 <minecrell> north1: The x86_64 CI builder seems to be stuck in your telegram-desktop MR
2020-01-18 14:39:34 <north1> i see
2020-01-18 14:39:43 <north1> failed due to lack of memory, lets hope the builders have enough mem
2020-01-18 14:39:46 <north1> abuild!17
2020-01-18 14:39:54 <north1> algitbot (IRC): no
2020-01-18 14:40:55 <north1> 390a2fe6e6f1eb07f1e018d00abc47c5f6eba6f4 <- beautiful
2020-01-18 14:47:52 <xrs> I have an error in my pipeline. Is this my fault or is something wrong with the CI. https://gitlab.alpinelinux.org/xrs/aports/pipelines/5596
2020-01-18 14:48:06 <xrs> Please help! :)
2020-01-18 14:48:18 <north1> patience
2020-01-18 14:51:20 <_ikke_> xrs: I just happened to notice that one, not sure what is causing that
2020-01-18 14:51:30 <_ikke_> Restarting it to see if it persists
2020-01-18 14:51:50 <north1> @ncopa can you take a look at https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/16 and https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/17 ?
2020-01-18 14:52:08 <xrs> ok
2020-01-18 14:52:41 <_ikke_> nope, still the same :x
2020-01-18 14:53:34 <xrs> _ikke_: I did an action I'm not sure if it was ok. I deleted the branch "gnunet" on gitlab and added the same with git push afterwards. Might this be the cause of the problem?
2020-01-18 14:53:43 <minecrell> xrs: Maybe it's confused because you opened the MR on your own fork
2020-01-18 14:53:45 <minecrell> just a guess
2020-01-18 14:54:05 <xrs> Oh.
2020-01-18 15:02:48 <Cogitri> Seems like armhf is unblocked now.
2020-01-18 15:04:45 <xrs> miecrell: I'm not sure how this happened. Any recommendation before I just restart the pipeline?
2020-01-18 15:04:51 <xrs> minecrell?
2020-01-18 15:05:28 <_ikke_> xrs: make the merge request again alpine/aports, not your personal repo
2020-01-18 15:05:40 <mps> !16
2020-01-18 15:05:58 <xrs> ok, I'll try.
2020-01-18 15:06:35 <xrs> _ikke_: Do I have to do a new one or can I change the old one?
2020-01-18 15:06:54 <mps> north1: 16 applied long time ago. anything new about it
2020-01-18 15:07:21 <north1> mps (IRC): alpine/abuild not alpine/aports
2020-01-18 15:07:42 <mps> oh, ok. sorry
2020-01-18 15:07:45 <north1> i put the full URL above since i don't know how to make algitbot distinguish
2020-01-18 15:07:59 <north1> alpine/abuild!17 ?
2020-01-18 15:08:04 <north1> yeah no
2020-01-18 15:08:12 <mps> right
2020-01-18 15:08:38 <mps> I was surprised because these two are mine MRs
2020-01-18 15:25:30 <xrs> _ikke_: fixed, thanks for the hint.
2020-01-18 16:21:11 <north1> @PureTryOut what did you want to change on atools ?
2020-01-18 16:21:51 <PureTryOut[m]> https://gitlab.alpinelinux.org/Leo/atools/merge_requests/24
2020-01-18 16:22:47 <north1> merged, i'm doing some other stuff as well and will make a release
2020-01-18 16:23:35 <PureTryOut[m]> Awesome thanks!
2020-01-18 16:23:50 <north1> Should we ignore other variables like CFLAGS ?
2020-01-18 16:24:03 <PureTryOut[m]> Probably makes sense yes
2020-01-18 16:59:37 <north1> !3156
2020-01-18 17:00:00 <north1> also recognises some other varaibles abuild uses like depends_libs and depends_doc, etcetc
2020-01-18 17:01:13 <_ikke_> (y)
2020-01-18 17:01:21 <north1> @ikke should we recognise cpandepends,cpanmakedepends and cpancheckdepends ?
2020-01-18 17:01:42 <_ikke_> afaik they are not used anymore
2020-01-18 17:01:50 <north1> they are not but i think abuild-cpan creates them
2020-01-18 17:01:51 <_ikke_> though still prevalent in a lot of packages
2020-01-18 17:01:54 <_ikke_> right
2020-01-18 17:02:07 <north1> they are referenced like depends="$cpandepends"
2020-01-18 17:02:14 <north1> which is funny because sometimes $cpandepends is ""
2020-01-18 17:02:15 <_ikke_> yeah, I've encountered that
2020-01-18 17:02:46 <_ikke_> Is there any reason to separate out those?
2020-01-18 17:02:54 <north1> If you want i can get apkbuild-fixer to transfer cpandepends into depends and rewrite the variable
2020-01-18 17:02:59 <north1> Not that i am aware of but i didn't make abuild-cpan
2020-01-18 17:06:42 <_ikke_> But they are not official variables, so they should be prefixed with _
2020-01-18 17:08:22 <_ikke_> I really like the new CI log output from gitlab
2020-01-18 17:08:25 <_ikke_> a lot clearer
2020-01-18 17:09:13 <Cogitri> 
ACTION is in favour of removing

2020-01-18 17:09:14 <Cogitri> 
ACTION these cpan* variables and fixing  abuild-cpan to not generating them anymore

2020-01-18 17:10:23 <north1> Ok, i'll add them to recognized variables (so apkbuild-lint doesn't ask you to prefix with _) and create their own AL and ask for them to be merged into their respective variable
2020-01-18 17:18:37 <mps> why do we call uboot-tools apk and not u-boot-tools? we already have u-boot apk and uboot-tools made from u-boot
2020-01-18 17:21:18 <_ikke_> Because we love inconsistency :p
2020-01-18 17:21:39 <mps> :)
2020-01-18 17:22:10 <mps> I want to fix it a bit and rename to u-boot-tools
2020-01-18 17:22:50 <mps> or rename u-boot to uboot?
2020-01-18 17:23:14 <north1> There is also pydepends
2020-01-18 17:23:20 <north1> maybe for people that use apkbuild-pypi
2020-01-18 17:23:43 <north1> didn't even knew that existed
2020-01-18 17:24:17 <Cogitri> Same here
2020-01-18 17:25:41 <north1> It seems so unimportant that abuild doesn't even depend on perl-ipc-system-simple so it doesn't even run
2020-01-18 17:58:31 <gu0tvuNHFV8o> i think it's properly called uboot and not u-boot
2020-01-18 18:00:08 <xrs> Hello ppl, here is a refined PR. Please have a look at it: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3155
2020-01-18 18:03:05 <mps> gu0tvuNHFV8o: from u-boot README 'This directory contains the source code for U-Boot,'
2020-01-18 18:04:16 <gu0tvuNHFV8o> wow, mps. thanks. i seem to remember it always referred to as uboot. maybe the inconsistency comes from somewhere else then.
2020-01-18 18:05:42 <mps> Arch linux uses uboot
2020-01-18 18:05:58 <mps> name 'uboot' I mean
2020-01-18 18:07:18 <mps> debian use 'u-boot-tools' and 'u-boot-menu'
2020-01-18 18:28:24 <north1> apkbuild-pypi  is so old it doesn't even have pycheckdepends=
2020-01-18 18:28:53 <north1> do people use it ? i never saw anything written about it. I used apkbuild-cpan once
2020-01-18 18:35:40 <mps> north1: I use apkbuild-cpan to make skeleton APKBUILD and then edit it if need to fix or change something
2020-01-18 18:36:31 <north1> Yes, I used it all the times I had to make a Perl package (once)
2020-01-18 18:36:55 <north1> I mean apkbuild-pypi which doesn't have its own subpackage and doesn't bring the required deps
2020-01-18 18:37:22 <mps> ah, I don't make py pkgs
2020-01-18 18:40:50 <north1> I made quite a few but never with apkbuild-pypi
2020-01-18 19:02:31 <minecrell> Cogitri: I'm guessing we need ncopa's final approval for https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2816? At the moment you seem to be assigned :)
2020-01-18 19:41:03 <mps> _ikke_: this new pop up in gitlab is annoying
2020-01-18 19:44:08 <_ikke_> It should come up only once
2020-01-18 19:44:28 <_ikke_> You mean the one that says the moved the navigation tabs, right?
2020-01-18 19:45:02 <mps> yes
2020-01-18 19:45:18 <_ikke_> I've only had it once
2020-01-18 19:45:21 <mps> but it repeats when I'm not logged in
2020-01-18 19:46:48 <mps> whenever click on some MR
2020-01-18 19:48:30 <_ikke_> I see
2020-01-18 19:49:40 <mps> ok
2020-01-18 19:50:28 <_ikke_> Not something we can do about
2020-01-18 19:51:15 <mps> could be quite annoying for not logged users and visitors
2020-01-18 19:51:54 <_ikke_> agreed
2020-01-18 19:52:11 <_ikke_> Might need to open an issue on gitlab about it
2020-01-18 19:57:19 <Cogitri> minecrell : Ah, I don't have access to main/, so I couldn't merge :)
2020-01-18 19:57:40 <_ikke_> Leo did it
2020-01-18 19:59:37 <Cogitri> Yup, saw the mail
2020-01-18 20:26:52 <minecrell> Ah, thanks :)
2020-01-18 20:30:18 <clandmeter> mps, yes its annoying
2020-01-18 20:30:28 <clandmeter> i had the same thing on gitlab.com
2020-01-18 20:30:56 <clandmeter> i also dont see the added value
2020-01-18 20:35:21 <minecrell> Hmm,so I seems like apk really ignores the provides :/ I have a system where mesa-dri-virtio is installed and it upgraded all other mesa packages, but didn't replace mesa-dri-virtio with mesa-dri-gallium
2020-01-18 20:35:37 <minecrell> so there is essentially a version mismatch now (not critical yet because it was just a re-build)
2020-01-18 20:36:15 <minecrell> (I used apk upgrade --available)
2020-01-18 20:48:44 <minecrell> maybe we need provides="mesa-dri-virtio==$pkgver"?
2020-01-18 20:48:54 <minecrell> The provides/replaces options are really confusing :(
2020-01-18 20:49:21 <_ikke_> yes, I agree
2020-01-18 20:49:32 <_ikke_> there are 2 variants
2020-01-18 20:49:37 <_ikke_> for provides
2020-01-18 20:50:16 <_ikke_> an unqualified provides is meant for virtual dependencies, a package depending on something that can be provided by multiple other packages
2020-01-18 20:51:06 <_ikke_> Then there is a qualified provides (provides="pkgname-$pkgver-r$pkgrel")
2020-01-18 20:51:54 <_ikke_> that's more like an alias for that package
2020-01-18 20:52:51 <minecrell> So is there any combination that would work in this case? it should uninstall mesa-dri-virtio and replace it with mesa-dri-gallium
2020-01-18 20:53:26 <_ikke_> the latter version should work (in combination with replaces if it has (some) equal files
2020-01-18 20:54:00 <minecrell> ncopa mentioned that replaces shouldn't be necessary because the origin ("mesa") of the package didn't change
2020-01-18 20:54:06 <_ikke_> ok
2020-01-18 20:54:15 <_ikke_> then a qualified provides
2020-01-18 20:54:29 <minecrell> So I used the wrong one, yay :)
2020-01-18 20:54:38 <_ikke_> I can merge a fix if needed
2020-01-18 20:54:50 <minecrell> I will try to test it locally, maybe it works this time
2020-01-18 20:54:53 <_ikke_> ok
2020-01-18 20:57:15 <minecrell> _ikke_: is the syntax really provides="pkgname-$pkgver-r$pkgrel"), not provides="$pkgname==$pkgver-r$pkgrel")?
2020-01-18 20:57:27 <minecrell> uh
2020-01-18 20:57:29 <minecrell> just one =
2020-01-18 20:57:34 <minecrell> according to https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#provides
2020-01-18 20:58:37 <_ikke_> euh, yes, one '='
2020-01-18 20:59:34 <Cogitri> Does someone happen to know how setup-gparted-disk ? According to #4603 it tries to call aterm which doesn't exist
2020-01-18 21:05:28 <_ikke_> minecrell: I think the -r$pkgrel part is missing from there
2020-01-18 21:05:46 <minecrell> _ikke_: in the wiki?
2020-01-18 21:05:52 <_ikke_> yes
2020-01-18 21:06:19 <minecrell> yeah, thought so :)
2020-01-18 21:06:39 <_ikke_> provides="py-w3lib=$pkgver-r$pkgrel"
2020-01-18 21:06:42 <_ikke_> example from aports
2020-01-18 21:11:38 <minecrell> (2/7) Purging mesa-dri-virtio (19.3.2-r0)
2020-01-18 21:11:38 <minecrell> (5/7) Installing mesa-dri-gallium (19.3.2-r2)
2020-01-18 21:11:38 <minecrell> 🎉
2020-01-18 21:11:42 <minecrell> thanks _ikke_
2020-01-18 21:15:16 <Cogitri> Nice
2020-01-18 21:19:20 <_ikke_> :-)
2020-01-18 21:26:24 <minecrell> _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3167
2020-01-18 21:29:05 <minecrell> Thanks again :)
2020-01-18 22:04:18 <Cogitri> ikke: Is #6476 still relevant?
2020-01-18 22:04:48 <_ikke_> Cogitri: last time I tried, yes
2020-01-18 22:04:55 <_ikke_> but that was maybe a couple of months ago
2020-01-19 03:42:30 <north1> @Clandmeter https://lists.alpinelinux.org/~alpine/aports/patches/3228 ok with transferring maintainership of riot-web ?
2020-01-19 04:46:14 <ddevault> man, those ARM kernels take their time to cross-compile
2020-01-19 07:02:00 <_ikke_> north1: He already agreed here
2020-01-19 07:04:38 <_ikke_> http://tpaste.us/nadx
2020-01-19 10:03:56 <Cogitri> Do we have a stance on #7423 ? I do agree that it'd be good to actually have a license to aports but it will be near impossible to get all the contributors to agree on the new license now I suppose
2020-01-19 10:12:22 <Cogitri> And another thing: Can we have a label "waiting for upstream" or similiar for issues which have to be solved by upstream?
2020-01-19 10:24:57 <PureTryOut[m]> Is there a reason for not having common folders like "Documents", "Videos" and "Pictures" in `/etc/skel`?
2020-01-19 10:26:10 <minecrell> PureTryOut[m]: Aren't these usually created by some DEs? Those are very "desktop"-specific folders, I wouldn't want to have them on a server or so
2020-01-19 10:26:32 <mps> PureTryOut[m]: why? to follow windows naming scheme?
2020-01-19 10:26:49 <PureTryOut[m]> minecrell: I don't believe so
2020-01-19 10:27:08 <PureTryOut[m]> mps: it's not just a Windows naming scheme, lots of distros do it. I believe it's even part of some XDG standard?
2020-01-19 10:27:24 <PureTryOut[m]> https://wiki.archlinux.org/index.php/Xdg_user_directories
2020-01-19 10:27:35 <mps> other distros adopted it from windows
2020-01-19 10:27:36 <minecrell> Arch Linux doesn't have them in /etc/skel
2020-01-19 10:28:26 <mps> do we need to follow these non-senses
2020-01-19 10:28:41 <PureTryOut[m]> I'm not saying we should, I was just asking why Alpine didn't have those...
2020-01-19 10:28:48 <PureTryOut[m]> Chill guys lol
2020-01-19 10:28:54 <mps> :)
2020-01-19 10:28:55 <Cogitri> lol indeed
2020-01-19 10:29:18 <Cogitri> Imho they really shouldn't be in skel though
2020-01-19 10:29:40 <mps> PureTryOut[m]: please, keep in mind that I never attack anyone personally
2020-01-19 10:29:41 <PureTryOut[m]> I'm probably just going to try and package `xdg-user-dirs`
2020-01-19 10:29:55 <minecrell> yeah, that's what seems to manage them
2020-01-19 10:30:00 <minecrell> including localization support, weird lol
2020-01-19 10:30:03 <Cogitri> Either your DE creates them for you or you run xdg-user-dors-update
2020-01-19 10:30:09 <Cogitri> Yes, we'd need that package for that
2020-01-19 10:30:24 <Cogitri> minecrell: Why would that be weird?
2020-01-19 10:31:11 <minecrell> Cogitri: Idk, if you change your locale it starts moving all folders around or what?
2020-01-19 10:31:32 <mps> alpine is 'small, simple, secure' (still, I hope)
2020-01-19 10:32:37 <PureTryOut[m]> Cogitri: it seems at least on Debian that the DE packages depend on `xdg-user-dirs`
2020-01-19 10:32:47 <Cogitri> minecrell: No
2020-01-19 10:32:56 <Cogitri> Yup, they should do that
2020-01-19 10:33:15 <Cogitri> Wanted to introduce that package but forgot about it, so thanks for doing it now :)
2020-01-19 10:33:45 <Cogitri> minecrell: It depends on the XDG_* variables, so if you don't change them yourself nothing will change if you change your locale
2020-01-19 10:34:16 <mps> why don't have 'Images', 'Movies', 'Writings' .....
2020-01-19 10:34:36 <Cogitri> But these variables allow for neat stuff like GNOME asking you if you want to rename your folders to localized names and it all just works for all programs thanks to the variables
2020-01-19 10:35:01 <Cogitri> (And they also allow putting e.g. your Downloads folder wherever you want, so that's nice)
2020-01-19 10:44:47 <mps> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3173/diffs#ac783fd0311ccf6f79c9b57a0b3696158bacfb62
2020-01-19 10:45:14 <mps> there is variable in pkgdesc, I think this is not ok?
2020-01-19 10:45:46 <mps> i.e. `pkgdesc="Digium Asterisk Hardware Device Interface drivers $_ver"`
2020-01-19 10:49:50 <mps> I mean, '$_ver' should go in pkgdesc
2020-01-19 10:50:03 <Cogitri> I don't think it should
2020-01-19 10:50:14 <Cogitri> Seems pretty redundant when you have pkgver
2020-01-19 10:56:18 <mps> I'm not sure, maybe there are reason for this (different driver major version, for example)
2020-01-19 10:57:08 <mps> if so, I still think that the $_ver should be replaced by literal string
2020-01-19 12:22:47 <mps> are there spell check plugin or option for gitlab
2020-01-19 12:24:21 <Cogitri> Your webbrowser should provide that
2020-01-19 12:25:05 <mps> iirc, redmine has it
2020-01-19 12:49:55 <Cogitri> I don't think any website implements its own spellchecker
2020-01-19 12:50:18 <Cogitri> Since webbrowsers highlight spelling errors already
2020-01-19 12:50:50 <minecrell> I'm pretty sure there is a stupid website out there that does it
2020-01-19 12:50:52 <mps> hm, not sure but I think I saw redmine plugin
2020-01-19 12:51:05 <minecrell> The web is full of garbage ;)
2020-01-19 12:51:19 <mps> heh :)
2020-01-19 12:51:20 <Cogitri> Right, lemme fix that
2020-01-19 12:51:35 <Cogitri> I don't think implementing a spellchecker for your website makes any sense usually
2020-01-19 12:51:44 <minecrell> agreed :p
2020-01-19 12:52:15 <mps> anyway, do you know for firefox spell check plugin which is light
2020-01-19 12:54:09 <minecrell> my Firefox does it without plugin
2020-01-19 12:54:34 <minecrell> Maybe missing some deps
2020-01-19 12:55:17 <mps> minecrell: are you run it on alpine
2020-01-19 12:55:32 <minecrell> nope
2020-01-19 12:58:25 <Cogitri> You don't need any plugin for spellchecking
2020-01-19 12:58:57 <mps> really? how to enable it?
2020-01-19 12:59:21 <minecrell> mps: but just tested on Alpine
2020-01-19 12:59:23 <minecrell> works too
2020-01-19 12:59:31 <minecrell> just right click the input field and make sure check spelling is ticked
2020-01-19 13:01:21 <mps> hm, I was blind :)
2020-01-19 13:01:28 <mps> thanks
2020-01-19 13:17:32 <mps> north1: you are so fast :) thanks
2020-01-19 13:18:58 <north1> Welcome
2020-01-19 13:19:31 <mps> I wanted to ask should we backport !3179 to 3.11
2020-01-19 13:21:10 <_ikke_> Doesn't seem to effectively change anything if I read your commit message correctly
2020-01-19 13:22:12 <mps> _ikke_: try example from bug report before and after upgrade
2020-01-19 13:22:40 <_ikke_> I just read what your commit message said
2020-01-19 13:22:53 <mps> i.e. 'tc qdisc add dev eth0 root netem delay 5000ms 200ms distribution normal' before upgrade
2020-01-19 13:23:15 <_ikke_> "It's the default, so it's not needed" means that it's just removing a redundant option rather than fixing a bug
2020-01-19 13:23:28 <mps> I put fixes: #issue number in commuit msg
2020-01-19 13:24:37 <_ikke_> Then I would suggest improving the commit message for the backport to 3.11
2020-01-19 13:24:47 <mps> oh, right, not beautifully worded, I agree
2020-01-19 13:26:47 <mps> (but to my defense, I'm self taught in english and it's not easy for me to write good commit msgs, which should be short, clear, concise, expressive ... at the same time)
2020-01-19 13:28:48 <_ikke_> We're here to help eachother :)
2020-01-19 13:29:07 <_ikke_> And good commit messages is kind of a pet peeve for me
2020-01-19 13:29:57 <mps> again, agree with you
2020-01-19 13:30:47 <mps> I would like to point all alpine packagers to look sometimes at kernel git log
2020-01-19 13:37:31 <mps> hmm, every week new ncurses release, !3180
2020-01-19 13:58:00 <ddevault> so I'm trying to make an aarch64 standard iso with mkimage.sh which replaces one of the packages from edge with a custom package I have locally
2020-01-19 13:58:05 <ddevault> ./scripts/mkimage.sh --arch aarch64 --repository /home/sircmpwn/packages/main/ --repository http://dl-cdn.alpinelinux.org/alpine/edge/main --profile standard
2020-01-19 13:58:19 <ddevault> but this gives ERROR: http://dl-cdn.alpinelinux.org/alpine/edge/main: UNTRUSTED signature
2020-01-19 13:58:21 <ddevault> hrm
2020-01-19 13:59:02 <ddevault> the keys are copied into the temp root
2020-01-19 14:00:07 <ddevault> are different keys used for aarch64 and x86_64?
2020-01-19 14:00:15 <_ikke_> I think so, yes
2020-01-19 14:00:28 <ddevault> ah
2020-01-19 14:00:40 <ddevault> where can I find those keys
2020-01-19 14:01:15 <mps> ddevault: try with --extra-repository, maybe it could help
2020-01-19 14:01:27 <ddevault> nope
2020-01-19 14:01:34 <mps> hm
2020-01-19 14:01:35 <_ikke_> ddevault: alpine-keys
2020-01-19 14:01:58 <mps> I fought with this some time, but it started suddenly to work
2020-01-19 14:02:00 <ddevault> thanks _ikke_
2020-01-19 14:02:10 <_ikke_> https://git.alpinelinux.org/aports/tree/main/alpine-keys
2020-01-19 14:02:14 <ddevault> that's it
2020-01-19 14:03:17 <mps> ahm, that explains why it suddenly started to work in case, thanks _ikke_
2020-01-19 14:03:29 <mps> in my case*
2020-01-19 14:04:17 <mps> north1: thanks again
2020-01-19 14:10:28 <ddevault> dumb question: is there a way to install foreign packages with a tag
2020-01-19 14:12:00 <ddevault> it's failing when grub can't find aarch64 stuff
2020-01-19 14:12:44 <_ikke_> ddevault: define foreign package?
2020-01-19 14:12:47 <ddevault> foreign architecture
2020-01-19 14:13:48 <_ikke_> I don't think so
2020-01-19 14:13:52 <ddevault> apk add'ing the foreign package just werked
2020-01-19 14:13:56 <_ikke_> ah ok
2020-01-19 14:13:56 <ddevault> I'm sure there will be consequences later
2020-01-19 14:13:58 <ddevault> ¯\_(ツ)_/¯
2020-01-19 14:14:15 <ddevault> that is, I curl -O'd it straight from the mirror and passed the file to apk add
2020-01-19 15:07:56 <PureTryOut[m]> Why do some packages cause `ERROR: <package name>*: lib<some file>.so: path not found`? For example ghc has this, and another package I'm packaging atm as well
2020-01-19 15:08:43 <Cogitri> I suppose because abuild can't automatically trace what package the shared library that package needs is in
2020-01-19 15:08:56 <Cogitri> (This can happen if you forget to install a shared lib)
2020-01-19 15:09:43 <Cogitri> E.g. neovim-qt didn't install it's shared lib by default due to a bug in its CMake files but the nvim-qt binary linked against it so abuild complained about that
2020-01-19 15:12:47 <PureTryOut[m]> I mean, this package is just running `make install`. Not sure why it would fail/forget to install a shared lib
2020-01-19 15:21:44 <Cogitri> Well, what lib is it complaining about? Did it install that lib into /usr/lib as it should?
2020-01-19 15:28:53 <PureTryOut[m]> It's a lib from itself lol
2020-01-19 15:30:06 <PureTryOut[m]> https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/37929#L2939
2020-01-19 15:30:13 <PureTryOut[m]> Same for ghc
2020-01-19 15:50:03 <Cogitri> And there's /usr/lib/libboca-1.0.so.2 in that package?
2020-01-19 15:51:52 <PureTryOut[m]> So far I can only find a regular `libboca-1.0.so` (without the `.2`)
2020-01-19 15:52:00 <PureTryOut[m]> Actually nvm that's a lie
2020-01-19 15:52:04 <PureTryOut[m]> Yeah it's in there
2020-01-19 16:11:10 <Cogitri> Hm, odd
2020-01-19 16:11:16 <Cogitri> Not on PC right now so can't check
2020-01-19 17:49:43 <mps> hm, got conflict when tried to push !3187 :)
2020-01-19 17:50:37 <_ikke_> Leo was ahead of you
2020-01-19 17:50:56 <mps> I see
2020-01-19 17:51:12 <mps> he is too fast :)
2020-01-19 17:51:23 <north1> sorry
2020-01-19 17:52:02 <mps> np, I'm happy seeing it pushed
2020-01-19 17:52:12 <mps> why sorry?
2020-01-19 17:53:09 <mps> BTW Cogitri did a lot of work with old issue requests. awesome
2020-01-19 17:53:58 <mps> my impression is that gitlab.a.o helps us a lot
2020-01-19 18:22:08 <Cogitri> mps: Gonna try working through the rest to close obsolete/already solved ones, thanks for helping :)
2020-01-19 19:23:38 <Cogitri> PureTryOut[m]: FYI I just disabled picard on armhf due to qtdeclarative
2020-01-19 19:43:21 <PureTryOut[m]> Yeah that's fine
2020-01-19 20:14:27 <ddevault> is there a reason we don't just use aarch64 defconfig for linux-lts
2020-01-19 20:38:54 <ddevault> probably cause it's bad, that explains it neatly
2020-01-19 20:39:00 <ddevault> or rather that it doesn't support much
2020-01-19 20:46:57 <Cogitri> Ugh, can't I have Gitlab notify me on any comment on any issue on aports?
2020-01-19 20:47:39 <Cogitri> Right now I can choose between Custom Notification Settings where I can select to get notifications for new&reopened issues or choose Watch and be mail bombed by getting email for all the things
2020-01-19 21:13:18 <_ikke_> Cogitri: I think you know the answer :)
2020-01-19 21:15:55 <Cogitri> Mailbombing it is then, I suppose :P
2020-01-19 21:16:05 <Cogitri> Would be nice if I could choose a different email for aports
2020-01-19 21:16:17 <Cogitri> But I guess I'll just go ahead and make a 2nd account just for these notifications
2020-01-19 21:16:57 <MY-R> or dunno, create some filters on your mail? :D
2020-01-19 21:21:47 <Cogitri> Hmm, that could work but since I check via both my laptop and my phone (via the ProtonMail app) I'm not sure hoe well that'd work
2020-01-19 21:26:17 <MY-R> in protonmail can define filters and select where move or what else to do with not wanted mails
2020-01-19 21:27:41 <MY-R> it even support that: https://protonmail.com/support/knowledge-base/sieve-advanced-custom-filters/
2020-01-19 21:30:04 <Cogitri> Ah right, I used that for when I was actually mailbombed once :^)
2020-01-19 21:30:19 <Cogitri> But I'm not sure how to make the regex for that though
2020-01-19 21:31:35 <MY-R> good start is to enable all notifications and after you will be abble to create good patterns :D
2020-01-19 21:31:51 <Cogitri> Fair enough :P
2020-01-19 22:32:33 <mps> Cogitri: I was afk, trying to help where I can and where I think my words wouldn't be to harsh
2020-01-19 22:34:30 <Cogitri> Ah, no worries :)
2020-01-19 22:34:33 <Cogitri> Thanks
2020-01-19 22:35:26 <mps> ddevault: I was tempted to do 'defconfig' and not only for aarch64 but after comparing results with current configs I tend to agree with linux-lts maintainer, i.e. step-by-step enable features and drivers
2020-01-19 22:35:49 <ddevault> mps: aye, agreed
2020-01-19 22:36:34 <mps> last big config change was for armv7 when linux-lts introduced
2020-01-19 23:02:23 <mps> Cogitri: sorry, still here? I think
2020-01-19 23:02:23 <mps> #7325
2020-01-19 23:02:44 <mps> could be closed. do you agree ?
2020-01-19 23:10:13 <MY-R> mps, for me it can be closed, when I remove etc/hostname then init.d/hostname using what is in conf.d/hostname so working like should :)
2020-01-19 23:11:13 <mps> MY-R: thanks for report
2020-01-19 23:12:44 <MY-R> :)
2020-01-19 23:52:43 <MY-R> #3238
2020-01-19 23:53:40 <MY-R> ^ looks like this can be closed too: https://pkgs.alpinelinux.org/package/v3.11/community/x86_64/dvd+rw-tools
2020-01-19 23:58:53 <mps> yes
2020-01-20 00:13:03 <Cogitri> Closed, thanks
2020-01-20 00:45:05 <MY-R> #3438 can be closed too, "setup-alpine" in "sys" mode when detect EFI then install with GPT layout but GPT wont work in BIOS (error with resources busy when trying play with /boot partition) DISKLABEL=gpt setup-alpine
2020-01-20 00:45:27 <MY-R> Cogitri, are you cleaning up issues?
2020-01-20 00:59:14 <north1> @MY-R yes
2020-01-20 07:46:05 <kaey> upstream made 1.0.8-beta2, I packaged it as 1.0.8b2. now upstream made 1.0.8 but apk thinks 1.0.8<1.0.8b2
2020-01-20 07:46:12 <kaey> what do i do here?
2020-01-20 07:46:49 <kaey> just push it and hope users do apk upgrade -a? it's in testing so i guess it's fine
2020-01-20 07:48:15 <_ikke_> There is not a lot more you can do
2020-01-20 07:48:59 <mps> but it will not 'work', afaik
2020-01-20 07:49:11 <kaey> also why does apk accepts letter after version like this? because of openssl?
2020-01-20 07:49:34 <_ikke_> Lots of version schemes in the wid
2020-01-20 07:49:40 <_ikke_> wild
2020-01-20 07:50:43 <kaey> if b2 will be gone from repos it will work
2020-01-20 07:51:05 <_ikke_> Unless users already have b2 installed
2020-01-20 07:56:40 <kaey> upgrade -a downgrades packages if they're not available in repo
2020-01-20 07:57:40 <mps> yes, ime
2020-01-20 07:57:54 <_ikke_> correct
2020-01-20 07:58:00 <mps> but 'apk add -u' doesn't
2020-01-20 08:02:06 <kaey> after I push branch to my fork gitlab gives me a link to create mr in upstream, previously it worked fine
2020-01-20 08:02:19 <kaey> but now it creates mr into my own fork
2020-01-20 08:04:33 <mps> not related to this in particular, but aren't we against pkgs beta releases
2020-01-20 08:05:00 <kaey> yes, but this was neccessary because of nodejs upgrade
2020-01-20 08:05:36 <mps> yes, there are always exceptions
2020-01-20 08:05:52 <kaey> i complained before, and somebody else was
2020-01-20 08:07:40 <mps> maybe new apk could add '+' as special pkgrel for such cases
2020-01-20 08:10:14 <_ikke_> apk has special support for beta releases fyi
2020-01-20 08:10:19 <_ikke_> and in testing it should not be an issue
2020-01-20 08:10:36 <_ikke_> https://git.alpinelinux.org/apk-tools/tree/src/version.c#n75
2020-01-20 08:38:36 <mps> are this serious or kidding with us !3202
2020-01-20 08:58:24 <Cogitri> I think it's serious since that user might not know the full reach of that
2020-01-20 09:07:05 <ncopa> kaey: yes, to apk  1.0.8b > 1.0.8, so it gets openssl versions correctly
2020-01-20 09:07:23 <ncopa> if you mean beta, then you should use 1.0.8_beta2
2020-01-20 09:08:12 <_ikke_> ncopa: apk version -t '1.0.0' '1.0.0_beta2'
2020-01-20 09:08:15 <_ikke_> <
2020-01-20 09:08:27 <_ikke_> I would expect >
2020-01-20 09:08:54 <ncopa> indeed
2020-01-20 09:08:58 <ncopa> sounds like a bug
2020-01-20 10:30:39 <MY-R> Cogitri, #8599
2020-01-20 10:34:23 <Cogitri> Ah, thanks
2020-01-20 10:59:43 <MY-R> #8760 can close too
2020-01-20 11:00:50 <_ikke_> maybe ask the user to verify the package so that it can be moved to community
2020-01-20 11:02:28 <MY-R> if package working fine then can move it to community just like that?
2020-01-20 11:03:10 <mps> _ikke_: maintainer is Cogitri
2020-01-20 11:04:00 <mps> I looked few days ago to upgrade it, but seeing maintainer I didn't
2020-01-20 11:05:29 <mps> I'll assign this issue to him
2020-01-20 11:05:54 <mps> no, I will not
2020-01-20 11:06:20 <mps> MY-R already answered
2020-01-20 11:06:24 <Cogitri> mps: I don't see a upgrade for it 🤔
2020-01-20 11:06:46 <MY-R> :D
2020-01-20 11:06:54 <Cogitri> alsa-project.org only lists alsa-tools-1.1.7
2020-01-20 11:07:30 <mps> Cogitri: yes, sorry
2020-01-20 11:08:21 <mps> I looked at site and thought it follow alsa-utils release numbers, now I see I was wrong
2020-01-20 11:09:51 <Cogitri> Only knew that since I fell for that twice already :)
2020-01-20 11:11:02 <MY-R> I installed alsa-tools-gui, commands do not segfault or something but dont have any special soundcard/config to test it more :D
2020-01-20 11:11:49 <Cogitri> I only tested that thingie to set different pins for your soundcard
2020-01-20 11:12:02 <Cogitri> Because HP did something weird for my laptop's speaker layout
2020-01-20 11:12:16 <mps> MY-R: looks like this tool is for sound freaks use cases
2020-01-20 11:12:24 <MY-R> mps, yep!
2020-01-20 11:52:16 <ncopa> north1: i pushed new kernel with backport of the intel gpu issue fix
2020-01-20 11:53:06 <north1> Nice
2020-01-20 11:53:14 <north1> Am in Kulturzentrum
2020-01-20 11:53:20 <north1> Will test in a few hours
2020-01-20 11:56:50 <ncopa> 3f3e223c0b11885671d570a90fd820619e894945
2020-01-20 12:04:34 <Cogitri> Neat
2020-01-20 12:07:29 <clandmeter> ncopa: i think dalias was also having issues, not sure its the same problem.
2020-01-20 12:10:54 <mps> yes, a lot of people have this problem and on other distros, not anly alpine
2020-01-20 12:11:57 <mps> problem is introduced with kernel 5.4 and 'backported' to 5.3.12 (iirc)
2020-01-20 12:12:31 <mps> irony is that it is LTS
2020-01-20 12:14:09 <mps> and doesn't look it is fixed (at least not confirmed) in 5.5-rc7
2020-01-20 14:01:24 <ddevault> morning
2020-01-20 14:01:32 <ddevault> seeking reviews on the doc patch for apk https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/9
2020-01-20 14:03:42 <north1> I can take a look but I doubt my usefulness in it
2020-01-20 14:04:26 <_ikke_> heh, I just linked to that page
2020-01-20 14:13:00 <markand> regarding UX if there are no page that defines some guidelines, maybe we could start one to describe a syntax that all alpine tools should follow
2020-01-20 14:53:05 <MY-R> !8874 can close, installing 'lua5.2-lyaml' package "fixing" it
2020-01-20 14:53:17 <MY-R> #8874 that!
2020-01-20 14:54:31 <MY-R> ahh, not aports but "awall" https://gitlab.alpinelinux.org/alpine/awall/issues/8874
2020-01-20 14:55:07 <MY-R> awall#8874 sorry for flood :<
2020-01-20 14:55:38 <Cogitri> Heh
2020-01-20 14:56:33 <MY-R> algitbot, wrrr!
2020-01-20 15:10:47 <north1> Lol
2020-01-20 16:18:35 <alpurn> The documentation is rather fuzzy around the difference of /media/mmcblk0p1/apks/armhf and /media/mmcblk0p1/cache
2020-01-20 16:19:55 <alpurn> I'm preparing an OS signing a custom APK, copying the pubkey to /etc/apk/keys - I sign the APKINDEX.tar.gz and have a ${hostname}.apkvol.tar.gz in /media/mmcblk0p1/
2020-01-20 16:20:50 <alpurn> I also need to include a few additional packages (libpcap, libusb, usb_modeswitch, ppp, etc...)  - they simply do not get installed on boot whether they are in /media/mmcblk0/cache or /media/mmcblk0/apks/armhf
2020-01-20 16:21:11 <alpurn> Can anyone help me determine what I may be missing, happy to share my script.
2020-01-20 16:23:11 <_ikke_> To get packages installed on boot, make sure they are in /etc/apk/world (text file)
2020-01-20 16:23:37 <alpurn> They are indeed.
2020-01-20 16:26:59 <alpurn> Relevant script (redacted, snipped) https://git.riboflav.in/snippets/5
2020-01-20 16:28:16 <alpurn> Ran into this dependency nightmare with the `apk fetch` bits which is why the list is so long, probably not doing that right either :(
2020-01-20 16:28:46 <_ikke_> I don't see you creating a world file?
2020-01-20 16:29:17 <north1> py-setuptools now has deprecated python2
2020-01-20 16:29:19 <_ikke_> which should be part of the apkovl
2020-01-20 16:29:22 <north1> when can we move from python2 ?
2020-01-20 16:29:55 <alpurn> _ikke_: it's in the repo under a directory called fs/
2020-01-20 16:29:57 <_ikke_> When I have time, I want to finish my redo port from python2 to 3
2020-01-20 16:30:13 <north1> can we move trac from main to unmaintained ?
2020-01-20 16:30:53 <alpurn> _ikke_: https://git.riboflav.in/snippets/6 is my world file
2020-01-20 16:31:52 <_ikke_> And you don't get any error message during boot?
2020-01-20 16:31:54 <north1> kodi optionally depends on python2, can it be disabled ?
2020-01-20 16:32:15 <alpurn> _ikke_: negative - nothing in /var/log/messages || dmesg
2020-01-20 16:32:18 <_ikke_> alpurn: what happens when you run apk fix after boot
2020-01-20 16:32:30 <alpurn> Will attempt now.
2020-01-20 16:44:18 <alpurn> _ikke_:  "unsatisfiable constraints" (then the list of packages I did 'apk fetch'
2020-01-20 16:44:44 <_ikke_> Right, so you are missing dependencies
2020-01-20 16:45:38 <alpurn> apk update :: 3.11.2 [/media/mmcblk0/apks] \n OK: 65 distinct packages available
2020-01-20 16:46:32 <_ikke_> It's missing something
2020-01-20 16:46:42 <_ikke_> The message should tell you what is missing
2020-01-20 16:48:28 <alpurn> I've since copied all the *.apk's from cache to apks/armhf
2020-01-20 16:50:28 <_ikke_> verify that you have all the dependencies of the packages that you try to install present in your cache dir
2020-01-20 16:53:10 <north1> :D made some MRs to remove more python2 stuff
2020-01-20 16:56:29 <alpurn> _ikke_: so to clarify: /etc/apk/world are packages that are installed automatically on boot
2020-01-20 16:57:25 <alpurn> And /etc/apk/world should list all the packages in /media/mmcblk0/apks/armhf
2020-01-20 16:57:52 <alpurn> Lastly the additional APK's (suppoprting / dependencies) must live in /media/mmcblk0/cache ?
2020-01-20 20:14:40 <north1> @ncopa can you take a look at these ? https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/16 https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/17 https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/18
2020-01-20 20:17:44 <Cogitri> 
ACTION waits for builders to light up in fire in Rust SIGSEGVs :^)

2020-01-20 20:17:49 <_ikke_> heh
2020-01-20 20:27:48 <north1> @ncopa am on linux-lts-5.4.3-r1, so far so good but i also had 4 days of no-locks uptime on a kernel that eventually locked
2020-01-20 20:28:09 <north1> after a week or so might be a better metric for success
2020-01-20 20:32:27 <_ikke_> Cogitri: yup, SIGSEGV
2020-01-20 20:34:12 <Cogitri> Hooray
2020-01-20 20:34:36 <Cogitri> Thanks for giving it another go already :)
2020-01-20 20:40:41 <mps> north1: I also noticed that the kernel 5.4.{2,3} are better on my aarch64 chromebook, i.e. didn't had issue with emmc card
2020-01-20 20:41:12 <mps> after upgrade to 5.4.6 it started to make mess with emmc again
2020-01-20 20:41:17 <north1> oh
2020-01-20 20:41:28 <north1> i was wondering how intel related to aarch64
2020-01-20 20:49:19 <mps> heh, bugs are not limited by arch borders :)
2020-01-20 20:57:10 <mps> anyone know who is J0WI user, i.e. is s/he on any alpine channel
2020-01-20 20:58:03 <_ikke_> mps: I've never seen them here on irc
2020-01-20 20:59:20 <mps> ok, will be harsh on MR then :P
2020-01-20 21:10:13 <MY-R> maybe there is the reason why 5.4 on main page is showed as stable and not longterm :D
2020-01-20 21:11:59 <mps> MY-R: https://www.kernel.org/category/releases.html it is here
2020-01-20 21:12:03 <MY-R> I saw J0WI (she) few times on irc
2020-01-20 21:12:31 <MY-R> mps, ye I know it is there but still suspicious :P
2020-01-20 21:12:56 <mps> also I'm
2020-01-20 21:13:44 <mps> read yesterday somewhere that ubuntu will use 5.5 as their LTS kernel
2020-01-20 21:14:14 <mps> but we don't have enough man power for such task, I think
2020-01-20 21:14:32 <MY-R> did ever happen before that announced longterm kernel was dropped?
2020-01-20 21:15:56 <mps> I can't remember
2020-01-20 21:19:06 <mps> have to add that the 5.4.13 is very nice on armv7 exynos
2020-01-20 21:21:18 <MY-R> nice because not freezeing like on intel gpus? :D
2020-01-20 21:23:17 <mps> I don't see any issue on it, works fast and stable
2020-01-20 21:24:35 <MY-R> for now! :P
2020-01-20 21:24:51 <mps> knock, knock :)
2020-01-20 21:25:01 <MY-R> heh
2020-01-21 02:45:03 <north1> When can python3 provide cmd:python ?
2020-01-21 07:14:11 <^7heo> hi
2020-01-21 07:14:15 <^7heo> any reason hugo isn't built for i686?
2020-01-21 07:15:37 <north1> @^7heo see answer on #alpine-linux
2020-01-21 07:16:20 <ncopa> arch="all !x86 !s390x" # tests fails on x86 and s390x
2020-01-21 07:16:45 <ncopa> ^7heo: the testsuite fails
2020-01-21 07:20:09 <^7heo> hmm, just the test suite?
2020-01-21 07:20:22 <^7heo> (hi ncopa)
2020-01-21 07:23:54 <ncopa> hi
2020-01-21 07:24:01 <ncopa> yes, i htink so
2020-01-21 07:26:55 <ncopa> could be a broken test, could be a real bu in hugo. in either case it blocked the builder so it was disabled til someone took a closer look at it
2020-01-21 07:28:03 <ncopa> looks like its broke on almost all non-x86_64
2020-01-21 07:28:04 <^7heo> I need it
2020-01-21 07:28:15 <^7heo> I'll take a look.
2020-01-21 07:28:27 <^7heo> I hope it's not too serious.
2020-01-21 07:28:53 <ncopa> at a minimum, it would be helpful to report the exact failure upstream
2020-01-21 07:29:52 <^7heo> are the tests coming from them too?
2020-01-21 07:30:04 <ncopa> yes
2020-01-21 07:30:47 <ncopa> x86 was disabled 603593148a2d42089fcfdafed112a401dc5eb4cd
2020-01-21 07:31:35 <^7heo> ok
2020-01-21 07:32:00 <^7heo> well, I'll get a coffee and take a dive
2020-01-21 07:32:03 <^7heo> bbl
2020-01-21 08:14:50 <Cogitri> Huh, just spotted that firefox and firefox-esr's icon installing is broken https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Fshare%2Ficons*&name=firefox-esr&branch=edge&repo=community&arch=armv7
2020-01-21 08:15:28 <Cogitri> shellcheck helped me find that (we use $png instead of $_png in a loop)
2020-01-21 11:31:58 <MY-R> north1, have you thought about moving 'telegram-desktop' to community repo? :>
2020-01-21 11:32:33 <mps> just see that some qt apps die with 'Illegal instruction' on armv7 when starting them
2020-01-21 11:32:46 <north1> Yes, it is an objective
2020-01-21 11:33:10 <north1> Have lots of stuff to iron out though
2020-01-21 11:33:53 <mps> that must in some qt lib
2020-01-21 11:36:27 <MY-R> I thought that armhf is trouble maker :D
2020-01-21 11:56:32 <mps> or upstream devs
2020-01-21 11:58:05 <MY-R> :\
2020-01-21 12:01:11 <_ikke_> Cogitri: :-)
2020-01-21 12:09:36 <Cogitri> Thanks for adding the CI stuff, ikke :)
2020-01-21 12:35:44 <markand> give me ideas of package to port
2020-01-21 12:36:19 <_ikke_> maybe look at the gitlab issue list for package requests
2020-01-21 12:36:42 <markand> 
ACTION opens firefox

2020-01-21 12:36:51 <Cogitri> dotnetcore :^)
2020-01-21 12:56:51 <north1> markand: systemd bootloader
2020-01-21 12:57:25 <north1> I'm not joking you can actually build it separate from systemd. I did it for void Linux April fools
2020-01-21 13:27:11 <Danct12_> i want systemd bootloader
2020-01-21 13:27:57 <kaniini> mps: likely related to JIT i would think
2020-01-21 14:04:23 <clandmeter> north1: isnt that just gummiboot?
2020-01-21 14:04:54 <north1> Yeah it is a maintained version
2020-01-21 14:05:09 <clandmeter> i didnt know you could still decouple it
2020-01-21 14:05:40 <north1> To be fair, It is not something to expect
2020-01-21 14:06:12 <clandmeter> we were looking for alternatives for grub (before we started using it)
2020-01-21 14:06:37 <north1> Caveat it uses systemd code and systemd does not support musl
2020-01-21 14:06:40 <clandmeter> but there is no other suitable cross arch boot loader
2020-01-21 14:06:51 <north1> It will happily use gnu libc specific extensions
2020-01-21 14:08:09 <north1> Fortunately there is openWRT and nixOS musl patching it
2020-01-21 14:35:20 <_oxr463> Greetings, please review and merge bash-completion 2.10, <https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3259>.
2020-01-21 14:38:27 <north1> _oxr463: I can in a few hours
2020-01-21 14:42:08 <_oxr463> Thanks!
2020-01-21 14:56:11 <_oxr463> Also, new aport for mustach, <https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3260>. Thanks again!
2020-01-21 14:56:16 <markand> yes systemd-boot isn't that bad, I've used it before switching to plain efibootmgr
2020-01-21 14:56:52 <_ikke_> _oxr463: Please take a look at the lint output: https://gitlab.alpinelinux.org/oxr463/aports/-/jobs/38966
2020-01-21 14:57:42 <_oxr463> markand it used to be gummiboot, which was great.
2020-01-21 14:57:59 <_oxr463> _ikke_ will do
2020-01-21 16:57:36 <minecrell> north1: Maybe I read that wrong, are you saying systemd boot uses glibc?
2020-01-21 16:58:14 <north1> No, I'm saying that it uses extensions that are specific to glibc and only test against glibc
2020-01-21 16:58:36 <north1> It will happily use something that musl / posix doesn't have if it makes their lifes easier
2020-01-21 17:00:49 <minecrell> Last time I checked, systemd-boot is built against gnu-efi, which has its own ugly libc-like functions (differently called). I don't think you can really use anything libc specific in there
2020-01-21 17:05:07 <minecrell> At least a year ago you could just take the src/boot/efi dir and compile it outside systemd with minor changes only
2020-01-21 18:22:52 <kaniini> is there any reason why the samurai transition is not yet done?
2020-01-21 18:38:01 <minecrell> kaniini: https://gitlab.alpinelinux.org/alpine/aports/commit/2c7891f0cd17a3010261698b53e60bc4f2bbb468 there isn't actually a provides/replaces in there, is that intended?
2020-01-21 18:39:58 <kaniini> oh
2020-01-21 18:40:44 <kaniini> that is because halfway through i was going to put the symlink in its own package
2020-01-21 18:41:05 <kaniini> but changed my mind
2020-01-21 18:41:46 <kaniini> ninja murders my dev box, samurai does not, samurai has the same default behaviour when not configured so i've been running with samurai in place of ninja for a while now
2020-01-21 19:13:54 <pltrz[m]> kaniini: in which way doas ninja murder your box?
2020-01-21 19:14:21 <pltrz[m]> super resource-intensive?
2020-01-21 19:15:40 <kaniini> pltrz[m]: i use qemu-user to build packages for other architectures than ppc64le.  ninja + qemu-user = tons of qemu-user processes (one for all 192 threads available on my machine) chugging along eating 100% CPU for large projects that use ninja.
2020-01-21 19:16:10 <kaniini> samurai on the other hand allows me to place a hard limit on the number of jobs that will be run at once.
2020-01-21 19:16:36 <kaniini> ninja does as well, but not with an env variable.
2020-01-21 19:18:15 <pltrz[m]> gotcha
2020-01-21 19:18:18 <pltrz[m]> neat!
2020-01-21 19:19:33 <kaniini> so ninja defaults to -j192 on my box, and since most ninja projects are written in C++
2020-01-21 19:19:56 <kaniini> this means i have 192 copies of g++ chugging along slowly eating up lots of RAM for lots of time because it's all being emulated
2020-01-21 19:20:25 <kaniini> even though i have in abuild.conf, export JOBS=64
2020-01-21 19:21:22 <kaniini> and, when you have 192 threads, the main reason you have 192 threads isn't to build a single package with -j192
2020-01-21 19:21:38 <kaniini> but so you can do multiple tasks at once
2020-01-21 19:25:11 <kaniini> pltrz[m]: i have another machine with even more threads.  in the same case, ninja would murder that machine even harder
2020-01-21 19:34:02 <mps> what should be these license http://tpaste.us/4Er4 using SPDX code?
2020-01-21 19:34:57 <_ikke_> This
2020-01-21 19:34:59 <_ikke_> file may be redistributed under the terms of the GNU General Public License.
2020-01-21 19:35:01 <_ikke_> If this does not suit you, contact <tytso@mit.edu> and we can talk."
2020-01-21 19:35:21 <mps> yes
2020-01-21 19:35:38 <mps> GPL-2.0-only?
2020-01-21 19:35:46 <_ikke_> Is there a file header in the source?
2020-01-21 19:36:24 <mps> yes, Copying-policy: GPL
2020-01-21 19:36:33 <_ikke_> but nothing else?
2020-01-21 19:36:36 <mps> setserial.lsm
2020-01-21 19:37:05 <_ikke_> I think GPL-2.0-only would be most likely
2020-01-21 19:37:26 <_ikke_> Considering they are a kernel maintainer, who generally stick to GPLv2
2020-01-21 19:38:30 <mps> mostly this sentence: This file may be redistributed under the GNU Public License
2020-01-21 19:39:34 <mps> _ikke_: also I come to GPL-2.0-only, thanks. will do that
2020-01-21 19:40:43 <mps> yes, original author is T. Ts'o and most his pkgs are GPL2
2020-01-21 19:44:08 <mps> btw, does apk automaticaly handle busybox applets removals in case binary with name of applet is installed
2020-01-21 19:45:20 <_ikke_> mps: yes. bb has a trigger which adds / removes symlinks
2020-01-21 19:46:44 <mps> ah, so I have to put binary in busybox applet symlink dir
2020-01-21 19:47:07 <_ikke_> I don't think so
2020-01-21 19:47:10 <_ikke_> not sure though
2020-01-21 19:47:29 <mps> ok, np. will test it locally before push
2020-01-21 19:47:35 <_ikke_> https://git.alpinelinux.org/aports/tree/main/busybox/busybox.trigger
2020-01-21 19:49:50 <mps> hm, no. have to put binary to exact path as bb applet
2020-01-21 19:52:04 <_ikke_> ok
2020-01-21 19:52:11 <_ikke_> Probably to overwrite it
2020-01-21 19:52:21 <_ikke_> and bb will check whether the binary already exists or nto
2020-01-21 19:52:30 <_ikke_> makes sense then
2020-01-21 19:53:00 <mps> yes, I think so
2020-01-21 19:53:15 <mps> but will test to be sure
2020-01-21 19:53:30 <_ikke_> because the trigger just executes busybox --install -s
2020-01-21 19:56:14 <mps> yes, works fine
2020-01-21 19:57:03 <mps> packaging setserial, for now will left out /etc/init.d and conf file
2020-01-21 20:06:01 <_ikke_> mps: ;-)
2020-01-21 20:08:07 <mps> :\
2020-01-21 20:14:58 <mps> _ikke_: do i need to bump pkgrel to add linux-headers in makedepends
2020-01-21 20:15:11 <_ikke_> no
2020-01-21 20:15:23 <mps> ok, thanks
2020-01-21 20:15:24 <_ikke_> if it's not building, pushing just the fix suffices
2020-01-21 20:17:30 <mps> _ikke_: thanks 1000x
2020-01-21 20:19:35 <_ikke_> np
2020-01-21 20:28:23 <mps> heh, I learned that now builddir is set correct automatically if upstream tarball follow pkgname and pkgver canonically
2020-01-21 20:28:42 <_ikke_> yes, has been so for a while
2020-01-21 20:29:23 <mps> didn't know till few minutes ago, apkbuild-lint told me
2020-01-21 20:29:32 <_ikke_> :)
2020-01-21 22:46:06 <north1> Another thing for aports-lint
2020-01-21 22:46:30 <north1> should we warn when something from alpine-sdk is in makedepends= like make, gcc, musl-dev ?
2020-01-21 22:55:12 <mps> makes sense to me
2020-01-21 22:55:49 <north1> is there a way to get a recursive dependency list from a package ?
2020-01-21 22:56:27 <north1> Like, ask for dependencies of alpine-sdk and it list all the dependencies of it, all of the dependencies of its dependencies and so on.
2020-01-21 22:57:22 <_ikke_> cannot think of something
2020-01-21 22:57:52 <_ikke_> ah, ap recursdeps
2020-01-21 22:58:00 <_ikke_> but it requires the aports tree
2020-01-21 22:58:09 <_ikke_> and doing it per repo
2020-01-21 22:58:31 <north1> Sounds good
2020-01-21 22:58:45 <north1> nice
2020-01-21 22:59:08 <_ikke_> 363 deps for alpine-sdk :D
2020-01-21 22:59:11 <north1> oh, i think it is the other way around
2020-01-22 03:24:45 <north1> Should we replace explicit dependencies on ninja with samurai ? i use CMake -G Ninja
2020-01-22 04:19:51 <ddevault> ncopa: when you have a chance, can you please make the following changes to linux-lts? https://paste.sr.ht/~sircmpwn/4de890d2354457579c8ad68ef06724cdf1dd423e
2020-01-22 04:20:17 <ddevault> I am planning on a series of improvements to alpine's accessibility, this is one of several changes to come
2020-01-22 04:21:01 <ddevault> I also submitted a patch to syslinux adding a command which can play tones, and I'm planning on writing a little package to add TTS to the initrd to do early-boot TTS. Also planning on rolling these up into an accessibility-focused ISO spin
2020-01-22 07:29:14 <ncopa> ddevault: sounds good to me. an issue on gitlab would be helpful, with an explanation why it is wanted (the text above is enough). then i wont forget it and i can refer to it in the commit message
2020-01-22 08:30:28 <clandmeter> north1: care to bring hub to community?
2020-01-22 08:41:38 <clandmeter> err i actually mean lab :)
2020-01-22 08:42:01 <tmhoang> Hi ncopa, the missing luajit and nginx-mod-http-lua* are hitting me at https://github.com/kubernetes/kubernetes/blob/release-1.14/test/images/echoserver/BASEIMAGE . But I guess enabling s390x to luajit in 3.9 and 3.10 is a no-go from you ... But, how about 3.11 ?
2020-01-22 08:43:15 <tmhoang> I'm also working and testing the moonjit on edge/3.12
2020-01-22 08:43:45 <ncopa> right
2020-01-22 08:43:48 <ncopa> hum
2020-01-22 08:44:12 <ncopa> where were the patches?
2020-01-22 08:44:32 <ncopa> so we could add a patch to current luajit for s390x support for 3.11
2020-01-22 08:44:39 <clandmeter> what is the diff between moonjit and luajit?
2020-01-22 08:44:50 <tmhoang> ncopa: patches for luajit ? J0WI or/and I had it in some PR a while ago, digging
2020-01-22 08:44:51 <ncopa> iirc moonjit is a maintained fork of luajit
2020-01-22 08:45:06 <clandmeter> but luajit is also developed right?
2020-01-22 08:45:16 <ncopa> i think its stagnated
2020-01-22 08:45:23 <tmhoang> clandmeter: moonjist old-stable version maintains compatibility of luajit while its latest-stable is a new one. tldr it's a maintained fork
2020-01-22 08:45:44 <clandmeter> luajit latest commit is ysterday?
2020-01-22 08:45:50 <tmhoang> I think moonjit in 3.12/edge is the way to go, really
2020-01-22 08:46:03 <ncopa> they havent merged the s390x support
2020-01-22 08:46:46 <tmhoang> and ppc64le
2020-01-22 08:46:53 <ncopa> "Moonjit is a fork of the inactive LuaJIT project and aims to provide a way forward for existing users of LuaJIT looking for continuity in development and maintenance."
2020-01-22 08:47:01 <tmhoang> patches for ppc64le + s390x have been floating around so long
2020-01-22 08:48:20 <tmhoang> ncopa: so s390x patches (not-merged in upstream, but tested by community and merged in fedora, and maybe ubuntu too) for 3.11, yes ?
2020-01-22 08:48:43 <tmhoang> basically same as ppc64le patches
2020-01-22 08:49:06 <clandmeter> sounds nice, two active project achieve same goals and downstream needs to patch things locally...
2020-01-22 08:49:08 <tmhoang> so we could add a patch to current luajit for s390x support for 3.11 ---> ah i didnt see
2020-01-22 08:49:44 <tmhoang> it looks to me that upstream luajit kinds of want to keep current luajit project but he is kind of busy and dont want to merge too much
2020-01-22 09:01:10 <ncopa> im reading about moonjit vs luajit
2020-01-22 09:01:14 <ncopa> its a bit messy
2020-01-22 09:01:16 <ncopa> re alpine
2020-01-22 09:01:25 <ncopa> we will not push moonjit for 3.11
2020-01-22 09:01:36 <ncopa> we may push it for edge, but we dont know that yet
2020-01-22 09:01:59 <clandmeter> who is we?
2020-01-22 09:01:59 <ncopa> we want luajit with s390x support, and we want it backported to 3.11
2020-01-22 09:02:16 <ncopa> alpine community i suppose
2020-01-22 09:02:20 <clandmeter> :)
2020-01-22 09:02:21 <ncopa> or "me"
2020-01-22 09:02:25 <clandmeter> haha
2020-01-22 09:02:51 <tmhoang> I mean, luajit + s390x patch for 3.11 is different from moonjit on 3.11
2020-01-22 09:02:53 <clandmeter> well i thought maybe there is somebody with  more luajit knowhow
2020-01-22 09:03:17 <ncopa> tmhoang: exactly, im just thining out loud how to get the s390x inn
2020-01-22 09:03:39 <ncopa> so im thinking, we should probably do the luajit + s390x patch in edge first
2020-01-22 09:03:42 <ncopa> test it a bit there
2020-01-22 09:03:52 <tmhoang> ok sounds good
2020-01-22 09:03:55 <ncopa> and make sure that it does not break other stuff
2020-01-22 09:03:59 <ncopa> then backport it to 3.11
2020-01-22 09:04:05 <tmhoang> agreed
2020-01-22 09:04:15 <ncopa> after that we can discuss if we want move to moonjit
2020-01-22 09:04:40 <clandmeter> why are those arch patchend not merge upstream?
2020-01-22 09:05:00 <tmhoang> clandmeter: upstream luajit is busy and not responsive
2020-01-22 09:05:07 <ncopa> they are pretty big
2020-01-22 09:05:17 <ncopa> i saw the pull request. its a zillion of commits
2020-01-22 09:05:28 <ncopa> so i guess its lack of resources to review properly
2020-01-22 09:05:39 <clandmeter> but both dont merge right?
2020-01-22 09:05:41 <ncopa> and upstream may not be familiar with the s390x
2020-01-22 09:05:56 <clandmeter> or moonjit did not get them?
2020-01-22 09:06:10 <ncopa> as i understand, moonjit has merged them already
2020-01-22 09:06:19 <ncopa> booth ppc64le and s390x
2020-01-22 09:06:26 <clandmeter> ah, and thats why tmhoang prefers moonjit?
2020-01-22 09:06:26 <ncopa> but i havent verified that
2020-01-22 09:06:42 <ncopa> i think also other distros are switching to moonjit
2020-01-22 09:06:58 <clandmeter> right
2020-01-22 09:07:09 <clandmeter> well i bumped into this issue already ones or twice
2020-01-22 09:07:22 <clandmeter> where luajit is not available
2020-01-22 09:07:23 <tmhoang> clandmeter: If you look into luajit copmmnit history, they start being active again after moonjit become a thing. Before that, it's super inactive. Moonjit is the only hope for development to go
2020-01-22 09:07:53 <tmhoang> let's forget moonjit for a moment then, sorry I brought that up
2020-01-22 09:08:10 <clandmeter> im not against moonjit nor luajit
2020-01-22 09:08:21 <clandmeter> i just dont want a second libressl
2020-01-22 09:10:02 <ncopa> tmhoang: looks like the simplest thing to do is !2720
2020-01-22 09:10:18 <ncopa> that can be backported
2020-01-22 09:10:22 <ncopa> its a huge patch
2020-01-22 09:10:25 <tmhoang> yes, I'm verifying also
2020-01-22 09:10:49 <tmhoang> I want to make as little change in our patch as little as possible as the original one
2020-01-22 09:19:14 <ncopa> agere
2020-01-22 09:19:25 <ncopa> im looking at the changes in luajit
2020-01-22 09:19:31 <ncopa> this is sort of interesting
2020-01-22 09:19:34 <ncopa> https://github.com/LuaJIT/LuaJIT/commit/981ec8d2aac5cac76bdedd4015b6d32447b29597
2020-01-22 09:19:41 <ncopa> he is removing ppc64 support
2020-01-22 09:19:56 <tmhoang> :(
2020-01-22 09:20:14 <tmhoang> is it ppc64 not ppc64le ?
2020-01-22 09:26:37 <ncopa> not sure
2020-01-22 09:26:50 <ncopa> seems like there are som ppc support left: https://github.com/LuaJIT/LuaJIT/tree/v2.1/dynasm
2020-01-22 09:27:00 <ncopa> im not sure what was removed
2020-01-22 09:56:58 <tmhoang> ncopa: looks like !2720 is getting the patch from https://github.com/LuaJIT/LuaJIT/pull/395, but he makes some small non-functional change
2020-01-22 09:58:02 <tmhoang> I think 395 PR is ok, given it is a little bit outdated compared to moonjit v2.1.2 (compatible with luajit) where it has more fixes for openresty too. Well, let's see
2020-01-22 10:22:00 <Cogitri> Neat, passed all exams, so it's time to go through the remaining issues now, I suppose :P
2020-01-22 10:22:01 <Cogitri> Also nice that we've migrated to samu now
2020-01-22 10:22:45 <_ikke_> Cogitri: congrats
2020-01-22 10:24:43 <Cogitri> Thanks :)
2020-01-22 10:29:21 <markand> woot, mps is very fast :)
2020-01-22 10:34:30 <tmhoang> Cogitri /o
2020-01-22 10:34:34 <tmhoang> Cogitri o/
2020-01-22 10:40:27 <ncopa> Cogitri: congrats!
2020-01-22 10:41:04 <ncopa> tmhoang: im looking at the lua5.1 tests: https://www.lua.org/tests/
2020-01-22 10:41:13 <ncopa> but there are lots of things that does not work
2020-01-22 10:46:41 <tmhoang> ncopa: it relates to luajit ?
2020-01-22 10:49:39 <mps> Cogitri: congrats for exams
2020-01-22 10:55:03 <ncopa> yeah
2020-01-22 12:02:59 <tmhoang> ncopa: another bad news, I think I have to backport to 3.10, since nginx/ docker image pulls from 3.10
2020-01-22 12:10:05 <ncopa> ok
2020-01-22 12:10:13 <ncopa> lets take it one step at the time
2020-01-22 12:11:20 <tmhoang> yep
2020-01-22 12:15:53 <^7heo> first step: sudo rm -rf --no-preserve-root /
2020-01-22 12:15:55 <^7heo> 
ACTION hides

2020-01-22 12:16:13 <_ikke_> maintaining a distro is hard, lets go shopping
2020-01-22 12:16:19 <^7heo> that works too.
2020-01-22 12:16:41 <^7heo> (fun fact, rm -rf / *can* technically brick some mainboards)
2020-01-22 12:16:45 <tmhoang> lol I lauged, thanks
2020-01-22 12:17:07 <^7heo> anytime.
2020-01-22 12:17:16 <_ikke_> ^7heo: probably because efs is mounted and removing files there would brick the firmware
2020-01-22 12:17:37 <^7heo> I'm good for two things and two things only: pointing at stuff that's wrong with complaints; and making cynical jokes about stuff that's wrong.
2020-01-22 12:17:48 <^7heo> _ikke_: correct.
2020-01-22 12:17:50 <_ikke_> wb btw, has been a while (iirc)
2020-01-22 12:17:53 <^7heo> it has.
2020-01-22 12:18:05 <^7heo> and I'm just passing (hopefully, otherwise it means I suck at my job)
2020-01-22 12:18:30 <^7heo> I'm here to get hugo built on i686 (and other 32bit archs as a side effect if at all possible)
2020-01-22 12:18:46 <^7heo> didn't get time for that yesterday, but today I shall try harder.
2020-01-22 12:20:32 <^7heo> and of course, as customary, when something is ill designed, you can count on people to work around the ill design with "solutions" that do nothing good in the long run: https://github.com/systemd/systemd/issues/2402
2020-01-22 12:21:45 <^7heo> anyways, before I rant too much and cause other people to rant at me, I'll go back to idling.
2020-01-22 12:21:48 <^7heo> Tada!
2020-01-22 12:25:29 <north1> Good luck
2020-01-22 12:27:45 <^7heo> danke.
2020-01-22 12:38:09 <^7heo> question: would it make sense to have git-zsh-completion depend on zsh-vcs?
2020-01-22 12:40:56 <ncopa> dunno
2020-01-22 12:41:38 <^7heo> that would solve the vcs_info: function not found issue when using oh-my-zsh
2020-01-22 12:42:33 <AinNero> ^7heo: is this like a recurring thing that you recommend people to rm -rf their disks?
2020-01-22 12:42:44 <^7heo> AinNero: no, that is a joke.
2020-01-22 12:42:59 <^7heo> AinNero: I expect anyone on a -devel channel to be able to understand that.
2020-01-22 12:43:07 <^7heo> AinNero: otherwise they have no business being here.
2020-01-22 12:43:31 <^7heo> I mean, git-zsh-completion can probably function without zsh-vcs, I dunno, but since the functions are separated in different packages (which makes sense), it would also make sense to install the packages for what is probably the most common use case.
2020-01-22 12:43:38 <^7heo> just an idea.
2020-01-22 12:44:01 <AinNero> imagine doing that in the #alpine-linux channel, while some noobie was asking a question
2020-01-22 12:44:23 <^7heo> "imagine doing this in a computer class while being the teacher."
2020-01-22 12:44:30 <^7heo> except, context does matter.
2020-01-22 12:44:33 <^7heo> kthxbye.
2020-01-22 12:45:16 <Cogitri> Thanks, mps, ncopa and tmhoang :)
2020-01-22 12:45:25 <Cogitri> Finally time for fun stuff again
2020-01-22 12:45:37 <^7heo> same here, hugo is building.
2020-01-22 12:45:42 <north1> You joke, but in a computer class we learned about CI and CD and I made a presentation about CI in Void Linux and updated Vim as part of the presentation to show usage of the Travis
2020-01-22 12:46:03 <^7heo> I'll soon re-add the x86 archs in it and try again. :)
2020-01-22 12:46:39 <^7heo> north1: I had terribad computer classes too, with teachers being like "EVERY LINE in C shall be terminated with ;. That is how C works. Even for loops, period."
2020-01-22 12:46:47 <^7heo> of course, most students failed their exams.
2020-01-22 12:48:34 <mps> Cogitri: school is boring and life is beautiful to waste it in school :)
2020-01-22 12:49:02 <Cogitri> Well, uni is way more interesting than school so I don't want to complain too much :P
2020-01-22 12:49:24 <mps> ^7heo: \o
2020-01-22 12:50:04 <^7heo> as Rick (Justin Roiland really) puts it in Rick and Morty: School isn't for intelligent people.
2020-01-22 12:50:09 <^7heo> hi mps
2020-01-22 12:50:57 <AinNero> ^7heo: ah yeah i misremembered, 2017-11-20 22:47:12 in alpine-devel
2020-01-22 12:51:03 <AinNero> but whatev
2020-01-22 12:51:22 <mps> ^7heo: I enjoy reading you jokes (when I have time)
2020-01-22 12:51:26 <^7heo> LD
2020-01-22 12:51:32 <^7heo> s/L/:/
2020-01-22 12:51:32 <alpine-meetbot> ^7heo meant to say: :D
2020-01-22 12:51:35 <^7heo> no shit.
2020-01-22 12:51:53 <^7heo> anyways, gotta go back home, bbl.
2020-01-22 12:52:46 <ncopa> no clue whats wrong with the openjdk11 build system for s390x and ppc64le
2020-01-22 12:53:05 <ncopa> its like it completely lost all the build target dependencies or similar
2020-01-22 13:17:48 <ddevault> ncopa: roger doger, https://gitlab.alpinelinux.org/alpine/aports/issues/11151
2020-01-22 13:41:05 <beginnner> hello, i am beginner. i am creating new package, but i got an issue.https://gitlab.com/red4jg/alpine/blob/master/error_log
2020-01-22 13:45:53 <AinNero> looks like make returns non-zero, but i can't make out why
2020-01-22 13:52:55 <ncopa> ddevault: thanks. i added C-kernel label so i dont forget it when i look at kernel next time
2020-01-22 14:01:33 <markand> ^7heo, re: efi problems, I think the problem is the manufacturers
2020-01-22 14:01:46 <markand> no one should be able to brick a machine by accidentally removing a file
2020-01-22 14:02:44 <markand> so a good machine should simply restore a default efi config if user deleted by mistake
2020-01-22 14:02:46 <kaniini> DECTALK EXPRESS IS RUNNING EXTERNAL POWER ON
2020-01-22 14:03:22 <_ikke_> ..
2020-01-22 14:04:36 <^7heo> markand: the problem is UEFI.
2020-01-22 14:04:46 <markand> the problem is manufacturers
2020-01-22 14:05:09 <^7heo> sure, it's on the manufacturers to take bad specs and bad software and make it less problematic...
2020-01-22 14:05:12 <^7heo> =/
2020-01-22 14:05:31 <markand> no it's the problem of manufacturers to implement badly something
2020-01-22 14:05:33 <markand> 
ACTION looks at ACPI

2020-01-22 14:05:52 <kaniini> ncopa: i would like to figure out the whole kernel mess this release cycle.  can we work on that?
2020-01-22 14:06:21 <markand> if I'd need to build a motherboard myself I'd definitely do some check after powering on that efi is valid or restore with sane defaults (my thinkpad does that)
2020-01-22 14:10:11 <AinNero> didnt they say that UEFI would be much better than the previous BIOS boot?
2020-01-22 14:11:21 <markand> AinNero, EFI simplify lots of things, aka you don't need a bootloader to start an OS now
2020-01-22 14:11:56 <AinNero> simplified, as now you are forced to implement windows executables and FAT32
2020-01-22 14:13:33 <^7heo> EFI isn't UEFI.
2020-01-22 14:14:35 <^7heo> markand: also, yes, of course, motherboard manufacturers *could* fix it, by re-implementing everything better, redesigning what needs to be, and using that.
2020-01-22 14:14:44 <^7heo> markand: but there's really no point in calling this UEFI then.
2020-01-22 14:15:14 <^7heo> if there's a product/solution/software existing, and you do a clean room RE, it's fair to rename it.
2020-01-22 14:19:46 <^7heo> is it expected that hugo fails to build on the git master?
2020-01-22 14:20:40 <^7heo> (it does on my machine, which is effectively an alpine 3.11 VM with almost no packages installed)
2020-01-22 14:22:51 <kaniini> ncopa: i'll just write a mail about it
2020-01-22 14:23:53 <mps> kaniini: you don't need 'cd "$builddir"' anymore
2020-01-22 14:24:05 <mps> in APKBUID, I mean
2020-01-22 14:24:32 <kaniini> mps: fascinating
2020-01-22 14:25:00 <north1> Atools will warn about it
2020-01-22 14:25:07 <north1> With apkbuild-lint
2020-01-22 14:25:24 <kaniini> mps: i will make a note to lint all of my APKBUILDs at some later date
2020-01-22 14:25:33 <mps> yes, last night I learned that $builddir is automatic also, ofc for canonical named upstream packages
2020-01-22 14:26:57 <mps> so, we don't need even this 'builddir="$srcdir/pkgname-$pkgver"' for most packages
2020-01-22 14:26:59 <kaniini> i am just trying to reduce the amount of things i have sitting in my work tree right now :)
2020-01-22 14:27:45 <mps> kaniini: np, I think we are not forced to adopt and fix all this right now, we have a time :)
2020-01-22 14:28:02 <kaniini> is anybody working GCC 10 yet?
2020-01-22 14:28:21 <mps> actually I prefer easy and safe steps
2020-01-22 14:28:29 <mps> is the 10 released?
2020-01-22 14:28:47 <kaniini> it is about to be
2020-01-22 14:29:07 <^7heo> I'll ask again, in case someone reads it now:
2020-01-22 14:29:09 <^7heo> is it expected that hugo fails to build on the git master?
2020-01-22 14:29:26 <mps> ah, yes, I read, some new interesting 'things' (features) will be there
2020-01-22 14:29:42 <kaniini> ^7heo: i can check in a little bit
2020-01-22 14:29:42 <^7heo> actually, does build, fails to execute (SIGSEGV)
2020-01-22 14:29:59 <kaniini> ^7heo: but i suspect it will build and run fine on x86_64
2020-01-22 14:30:02 <^7heo> kaniini: I have been very distant from Alpine for a good two years, I'd love if you could.
2020-01-22 14:30:14 <^7heo> kaniini: oh, I didn't pay attention what arch my VM is emulating.
2020-01-22 14:30:17 <^7heo> kaniini: good catch
2020-01-22 14:30:36 <^7heo> i686, nevermind.
2020-01-22 14:30:38 <^7heo> thanks a bunch!
2020-01-22 14:31:00 <kaniini> mps: http://tpaste.us/yZ8x
2020-01-22 14:33:10 <mps> aha, will look
2020-01-22 14:33:30 <kaniini> mps: any objection to this one?  it allows the uboot-tools to build and it does not matter ultimately as we don't build a bootloader anyway
2020-01-22 14:33:40 <kaniini> (to build on mips64, that is)
2020-01-22 14:33:49 <mps> on the glance looks good
2020-01-22 14:34:20 <mps> and, I don't have any objection
2020-01-22 14:35:51 <kaniini> thx
2020-01-22 14:38:29 <mps> kaniini: :)
2020-01-22 14:38:37 <^7heo> the good thing is, now, since I tried to build it on x86 directly, I know what's up with x86. Segfault.
2020-01-22 14:40:00 <Cogitri> Uhh...since we don't have a license on apk I'm not really permitted to redistribute its source, am I? I'm currently making D bindings for APK but you usually include the C headers in the source repo for the bindings which I'm not sure if I can do that
2020-01-22 14:40:55 <kaniini> apk is GPLv2
2020-01-22 14:41:16 <kaniini> read the files themselves :)
2020-01-22 14:44:18 <Cogitri> Oh, I only grep'ed for GPL, derp
2020-01-22 14:44:20 <Cogitri> Thanks :)
2020-01-22 14:52:34 <Cogitri> Huh, is my Makefile-fu just so dated or does apk-tools not install the headers and stuff?
2020-01-22 14:54:59 <kaniini> it does not
2020-01-22 14:55:53 <kaniini> sent a mail to alpine-devel about procmail
2020-01-22 14:55:59 <kaniini> i would like to send it to a farm upstate
2020-01-22 14:56:24 <^7heo> with many of its peers?
2020-01-22 14:58:51 <kaniini> yes
2020-01-22 14:59:14 <kaniini> but procmail has security problems, and an alternative is available with fdm
2020-01-22 15:00:41 <Cogitri> I probably won't have many supporters for porting apk-tools to meson, right? :P
2020-01-22 15:01:54 <kaniini> lets see: that would require us to put python in the bootstrap path
2020-01-22 15:02:01 <kaniini> yeah, i don't think you will
2020-01-22 15:02:03 <kaniini> :P
2020-01-22 15:03:09 <Cogitri> 
ACTION goes learn Makefiles

2020-01-22 15:04:47 <north1> Cogitri: a costly investment with low returns
2020-01-22 15:07:34 <^7heo> do you guys also think it would be a good idea to have the image size with every image in the download page?
2020-01-22 15:07:39 <^7heo> maybe using tooltips?
2020-01-22 15:07:53 <^7heo> or, if css isn't interpreted, next to the name?
2020-01-22 15:08:15 <kaniini> i'm confused
2020-01-22 15:08:19 <kaniini> what are you doing exact
2020-01-22 15:08:21 <kaniini> ly
2020-01-22 15:08:53 <^7heo> kaniini: are you talking to me?
2020-01-22 15:08:58 <kaniini> yes
2020-01-22 15:09:18 <^7heo> I'm downloading alpine on a VERY bad connection. I'd like to know the size of an image BEFORE initiating ANOTHER HTTP connection.
2020-01-22 15:09:42 <kaniini> ok
2020-01-22 15:09:55 <kaniini> well i think we can just put the size next to the link
2020-01-22 15:10:33 <^7heo> that would be great, and I'd suggest doing it via the title attribute, or CSS tooltips, so it does not get in the way of the current design
2020-01-22 15:16:49 <reidrankin> QQ: does fabled ever hang out in here?
2020-01-22 15:18:19 <kaniini> :D :D :D :D :D :D :D :D :D
2020-01-22 15:18:24 <reidrankin> i've been hacking on the apk-tools signature verification code and was hoping to ask a bad question
2020-01-22 15:21:22 <kaniini> reidrankin: he appears sometimes
2020-01-22 15:21:54 <kaniini> reidrankin: best bet would be to send him a mail
2020-01-22 15:23:14 <ddevault> why was abuild -R removed (to recursively _build_ dependencies, rather than fetch them)
2020-01-22 15:23:30 <ddevault> I relied on that a lot :(
2020-01-22 15:24:01 <kaniini> it did not work reliably
2020-01-22 15:24:12 <mps> ^7heo: wget will tell you length when start download :)
2020-01-22 15:24:58 <kaniini> if nobody objects to procmail removal, i am sending it to a farm upstate at the end of my work day
2020-01-22 15:25:40 <kaniini> it is 2020, lets not go into another decade supporting things that have not had an upstream maintainer since 2001
2020-01-22 15:25:42 <kaniini> :D
2020-01-22 15:28:16 <ncopa> kaniini: yeah, lets nuke it
2020-01-22 15:30:00 <kaniini> ncopa: what are your thoughts on trying to tackle the mess that is kernels in this dev cycle?
2020-01-22 15:30:45 <ncopa> bad time for such question. i feel a bit stressed atm :)
2020-01-22 15:30:50 <kaniini> okay
2020-01-22 15:30:57 <kaniini> i think the first step is to write a mail outlining what the ideal state would be and where we are now, so i will do that in a bit
2020-01-22 15:30:57 <mps> kaniini: what you mean by 'mess'
2020-01-22 15:31:02 <ncopa> i have though a bit on how to solve it
2020-01-22 15:31:35 <ncopa> and i though of have some sort of alpine-defconfig or similar
2020-01-22 15:31:47 <ncopa> not sure whats the best approach
2020-01-22 15:31:48 <kaniini> mps: different archs have different kernels, and we have to have separate APKBUILDs for third-party modules for each kernel
2020-01-22 15:31:59 <kaniini> this leads to some kernels having more coverage than others
2020-01-22 15:32:24 <mps> aha, yes, this is mess
2020-01-22 15:32:27 <kaniini> for example, we have linux-lts, but we also have linux-rpi on ARM and linux-octeon on mips64
2020-01-22 15:32:38 <kaniini> so if you have to use linux-rpi or linux-octeon you lose out on a lot of things
2020-01-22 15:32:59 <ncopa> the linux-lts is a generic kernel
2020-01-22 15:33:08 <ncopa> one size, fits none
2020-01-22 15:33:12 <ncopa> :)
2020-01-22 15:33:34 <kaniini> in some cases (like octeon), the board will never be able to boot the linux-lts kernel, as the board has a wacky hypervisor
2020-01-22 15:33:35 <ncopa> the -rpi is highly specialized
2020-01-22 15:33:42 <mps> I planing to try make rpi zero to use linux-lts
2020-01-22 15:34:17 <mps> but we are locked to 5.4 now, not sure will that work
2020-01-22 15:34:42 <kaniini> and that's the other thing, we may want to offer a kernel that tracks linus's tree
2020-01-22 15:34:46 <kaniini> instead of just LTS
2020-01-22 15:34:47 <mps> 5.5 got RPI4 support
2020-01-22 15:35:09 <kaniini> or we may want to offer a kernel that is based on the Cavium tree for octeon (so we get more hardware offload support)
2020-01-22 15:35:10 <mps> as ncopa wrote, 'one size, fits none'
2020-01-22 15:36:06 <mps> also I contemplated about proposal to split kernels by arches
2020-01-22 15:36:23 <ncopa> im open to suggestions how to do it
2020-01-22 15:36:39 <mps> but not sure, this will require a lot more work, I fear
2020-01-22 15:37:01 <ncopa> but no matter how we do it, the more different kernels and kernelconfigs and thirdparty modules, the more maintenance work it will be
2020-01-22 15:37:48 <ncopa> the current approach is bearable for me atm
2020-01-22 15:37:55 <mps> few months I'm tempted to create testing/linux-armv7-mp (multiplatform), but managed to resist self :)
2020-01-22 15:39:16 <mps> and, in my head 'someone' talking linux-srv (server optimized) and linux-ws (workstation optimized)
2020-01-22 15:40:04 <kaniini> i think splitting by arch may be a good idea
2020-01-22 15:40:33 <ncopa> a differnt aport for each arch?
2020-01-22 15:40:34 <kaniini> but we would still want to agree on a kernel version for a given dev cycle
2020-01-22 15:40:37 <kaniini> yes
2020-01-22 15:40:45 <kaniini> so you have
2020-01-22 15:40:49 <kaniini> linux-${arch}-generic
2020-01-22 15:40:52 <kaniini> for example
2020-01-22 15:41:28 <mps> we have testing/linux-amlogic already, for example
2020-01-22 15:41:30 <kaniini> linux-mips64-generic which would target the MIPS Malta evaluation board (and maybe some SGI kit), linux-mips64-octeon (for Octeon)
2020-01-22 15:41:40 <ncopa> the apkbuilds woudl be similar
2020-01-22 15:41:53 <ncopa> just a nightmare to maintain it
2020-01-22 15:42:05 <kaniini> i'm not sure
2020-01-22 15:42:16 <ncopa> currently i bump version one place and run a script to rebuild the 3rdparty mods
2020-01-22 15:42:28 <kaniini> i think we should discuss in email and figure out the best way to proceed
2020-01-22 15:42:32 <ncopa> yeah
2020-01-22 15:42:49 <kaniini> i suspect riscv is going to be another area where we get a lot of board-specific kernels
2020-01-22 15:43:01 <mps> current status is bearable for now, imo
2020-01-22 15:43:08 <ncopa> i dont mind if you add an linux-octeon that i never need to touch
2020-01-22 15:43:57 <kaniini> then for now what i will do is put the mips evaluation board config in linux-lts (for QEMU targets) and linux-octeon in its own APKBUILD
2020-01-22 15:44:20 <kaniini> but i suspect again that riscv is going to be a situation where we have kernels for every board
2020-01-22 15:44:43 <ncopa> thats unsustainable imho
2020-01-22 15:45:50 <mps> so, risc-v would be bigger jungle than arm. nice
2020-01-22 15:46:20 <mps> I hoped for opposite
2020-01-22 15:46:26 <ncopa> yeah...
2020-01-22 15:46:52 <kaniini> thats why i think splitting by arch makes sense, that way the people who care about riscv maintain their own kernels and so on
2020-01-22 15:47:27 <ncopa> what i am afraid of is that it can slow down relases
2020-01-22 15:47:40 <ncopa> or we end up with releases with different kernel versions
2020-01-22 15:48:18 <kaniini> true
2020-01-22 15:49:47 <mps> Arch linux alarm (ARM) tree http://tpaste.us/YpaP
2020-01-22 15:51:55 <kaniini> and those are all different versions
2020-01-22 15:52:35 <mps> ncopa: btw, we have u-boot and uboot-tools, should we rename uboot-tools to u-boot-tools for consistency
2020-01-22 15:53:09 <mps> no, they are not all different mainline versions, but some yes
2020-01-22 15:53:24 <kaniini> linux-oak is certainly different (3.18)
2020-01-22 15:53:25 <mps> most of them are different .config options
2020-01-22 15:53:53 <mps> oak is different for sure :)
2020-01-22 15:54:09 <kaniini> lol somebody emailed me offlist claiming that they have plans to "revive procmail"
2020-01-22 15:54:11 <mps> did you fixed your issues with it
2020-01-22 15:54:25 <kaniini> mps: yes, i just repacked it with the correct DTB
2020-01-22 15:54:31 <kaniini> good enough for now :D
2020-01-22 15:54:43 <mps> still 3.18
2020-01-22 15:54:53 <kaniini> all the linux-oak stuff is upstream, so i need to sit down and figure that out at some point
2020-01-22 15:55:28 <kaniini> but alpine is a great OS for a chromebook
2020-01-22 15:55:36 <mps> i tried few months ago but didn't managed
2020-01-22 15:55:51 <kaniini> well
2020-01-22 15:55:56 <kaniini> there is TTL serial on the board
2020-01-22 15:55:58 <mps> kaniini: I'm typing right now on one :)
2020-01-22 15:56:03 <kaniini> so i am hoping i can debug that way
2020-01-22 15:56:33 <beginnner> hello
2020-01-22 15:56:41 <kaniini> i might just buy a pinebook pro when they come out with an 11" version
2020-01-22 15:56:46 <mps> I noticed some MediaTek updates in last few kernel
2020-01-22 15:57:05 <mps> kernels*
2020-01-22 15:58:26 <mps> and, I agree, alpine is great everywhere where I tried
2020-01-22 16:10:27 <Cogitri> Uhh...do you guys also get `ninja: unknown tool 'compdb'` since the migration to samu?
2020-01-22 16:10:37 <Cogitri> Meson throws that every time I try to configure a builddir now
2020-01-22 16:23:04 <kaniini> no
2020-01-22 16:24:34 <Cogitri> Hm, I'm getting that for every meson project now
2020-01-22 16:25:55 <Cogitri> With a fully upgraded system, I can't recall that happening with ninja
2020-01-22 16:26:45 <kaniini> https://github.com/michaelforney/samurai/issues/19
2020-01-22 16:26:49 <kaniini> it is a harmless error
2020-01-22 16:26:50 <north1> oh dear
2020-01-22 16:27:10 <Cogitri> Ah yes
2020-01-22 16:27:54 <Cogitri> Somewhat certain that breaks GNOME Builder though
2020-01-22 16:28:43 <kaniini> > GNOME Builder
2020-01-22 16:28:47 <kaniini> this ain't windows
2020-01-22 16:30:37 <kaniini> but yes, that is not expected fallout
2020-01-22 16:30:47 <kaniini> let me see how hard it would be to add support for compdb
2020-01-22 16:31:03 <Cogitri> I wouldn't call users choosing whatever IDE they like as being Windows-y :)
2020-01-22 16:31:05 <Cogitri> Thank you
2020-01-22 16:31:50 <kaniini> Cogitri: if i cannot get an answer soon, we will revert the migration
2020-01-22 16:31:57 <ddevault> mforney: are you available?
2020-01-22 16:32:32 <Cogitri> kaniini: Ah, no need for such extreme steps, I suppose
2020-01-22 16:33:30 <Cogitri> It's only a minor thing breaking, so I don't think we need to rush reverting
2020-01-22 16:34:52 <kaniini> Cogitri: sure but i am a bit annoyed that nobody mentioned that compdb was not implemented in samu, had i known that i would not have been in favor of migrating it
2020-01-22 16:35:30 <ddevault> I was unaware that it was unimplemented, fwiw
2020-01-22 16:36:08 <kaniini> Cogitri: can you make an empty compile_commands.json and see if GNOME Builder still works
2020-01-22 16:36:12 <Cogitri> Well, without trying to prove a point or anything, this almost always happens with such migrations
2020-01-22 16:36:27 <Cogitri> I'm happy that only such a minor thing broke
2020-01-22 16:36:39 <MY-R> https://github.com/NixOS/nixpkgs/pull/77140#issuecomment-571334359
2020-01-22 16:36:50 <ddevault> I grepped gnome-builder for compdb, and came up dry - does it actually use it?
2020-01-22 16:36:55 <Cogitri> kaniini: Ah, it's not that Builder breaks down completely, it just won't be able to build your projects via its UI anymore
2020-01-22 16:37:07 <Cogitri> It uses it for the "Build" button
2020-01-22 16:37:11 <kaniini> doesn't it invoke ninja for that
2020-01-22 16:37:48 <Cogitri> And apparently to know include paths and stuff
2020-01-22 16:38:40 <ddevault> I guess I'm not understanding specifically how it breaks gnome builder
2020-01-22 16:39:43 <kaniini> okay
2020-01-22 16:39:46 <kaniini> who cares
2020-01-22 16:39:51 <kaniini> what does a compile_commands.json look like
2020-01-22 16:39:58 <kaniini> i will just fix it myself
2020-01-22 16:40:08 <ddevault> https://clang.llvm.org/docs/JSONCompilationDatabase.html
2020-01-22 16:40:25 <Cogitri> It gets things CFLAGS from compile_commanda.json so it knows what the include paths etc. are and can do IntelliSense things
2020-01-22 16:40:51 <ddevault> it does seem fairly straightforward
2020-01-22 16:40:57 <ddevault> this is the ninja impl https://github.com/ninja-build/ninja/blob/d986e4db5630cf1c5547e69b5556f006f7d3444a/src/ninja.cc#L764
2020-01-22 16:41:07 <kaniini> and why does samurai not support it
2020-01-22 16:41:10 <Cogitri> Here's how an actual one can look like: http://dpaste.com/2NWSZTX
2020-01-22 16:41:19 <Cogitri> The maintainer stated that he doesn't need it
2020-01-22 16:41:35 <_ikke_> ugh, concatenating json :P
2020-01-22 16:41:37 <ddevault> that was a while ago, I think it was an oversight once 1:1 compatibility became desirable to him
2020-01-22 16:42:11 <kaniini> well we will soon find out if samurai can provide pkgconf-level SLA
2020-01-22 16:42:19 <kaniini> if it cannot, it will have to be reverted
2020-01-22 16:42:23 <kaniini> sorry
2020-01-22 16:42:49 <ddevault> the first step would be an issue
2020-01-22 16:42:51 <ddevault> filing the ticket now
2020-01-22 16:43:08 <kaniini> distributions do not file issues to have pkgconf issues fixed
2020-01-22 16:43:18 <kaniini> they ping me in IRC and everything gets dropped until it is fixed
2020-01-22 16:43:18 <ddevault> well, I'm doing it anyway
2020-01-22 16:45:17 <kaniini> it is great that samurai can build all of alpine, but if it breaks other tools that depend on ninja, it is not acceptable
2020-01-22 16:45:31 <ddevault> https://github.com/michaelforney/samurai/issues/33
2020-01-22 16:45:40 <ddevault> kaniini: yes, I think that's understood
2020-01-22 16:45:47 <kaniini> i knew i should have just written my own ninja replacement
2020-01-22 16:45:54 <ddevault> please relax, kaniini
2020-01-22 16:46:11 <ddevault> people have to sleep
2020-01-22 16:46:15 <ddevault> michael will be around soon enough
2020-01-22 16:48:05 <ncopa> mps: looks like uboot-tools and u-boot has same upstream source package
2020-01-22 16:48:35 <ncopa> i think it make sense to let u-boot-tools be a subpackage of u-boot
2020-01-22 16:49:01 <kaniini> ncopa: that could be messy
2020-01-22 16:49:09 <kaniini> tools are built using sandbox config
2020-01-22 16:50:02 <ncopa> but they are built from same sources?
2020-01-22 16:50:13 <kaniini> yes
2020-01-22 16:50:20 <kaniini> i mean, we can merge the tools i guess
2020-01-22 16:51:13 <ncopa> openjdk11 and gnu make 4.3 is a mess
2020-01-22 16:51:34 <ncopa> need to be reported upstream to oracle that openjdk11 does not build with make 4.3
2020-01-22 16:51:52 <kaniini> GCC 10 is going to be another mess with -fno-common being in the default CFLAGS
2020-01-22 16:52:08 <kaniini> i am going to look into doing a build this week with -fno-common in CFLAGS and see what breaks
2020-01-22 16:52:19 <ncopa> lets clean up the messes we have before we introduce new mess
2020-01-22 16:52:45 <kaniini> well my point about GCC 10 is i want to be ahead of the mess (since it's not coming until March)
2020-01-22 16:56:48 <mps> ncopa: u-boot is only for arm while tools are for other arches
2020-01-22 16:57:08 <mps> or arch's (what is correct term)
2020-01-22 16:57:09 <ddevault> kaniini: the answer to your question on github is yes
2020-01-22 16:57:10 <ddevault> there are several
2020-01-22 16:57:14 <ddevault> I support a rollback now
2020-01-22 16:57:54 <kaniini> well
2020-01-22 16:58:16 <kaniini> i don't think a lot of them are hard to implement
2020-01-22 16:59:02 <kaniini> of the tools, i think compdb and restat are the only ones that are likely needed
2020-01-22 16:59:06 <ddevault> no, but if we don't think that we can ship them before 3.12, then a rollback would be wise
2020-01-22 16:59:46 <kaniini> and restat is new
2020-01-22 16:59:54 <ddevault> well, if the only problem we've run into is gnome builder's compdb stuff
2020-01-22 17:00:10 <ddevault> then just fixing that should be acceptable
2020-01-22 17:04:18 <kaniini> i think compdb and query are the ones we need
2020-01-22 17:08:30 <kaniini> ok
2020-01-22 17:08:34 <kaniini> well
2020-01-22 17:08:52 <kaniini> ncopa: what is going on with openjdk11 and gnu make
2020-01-22 17:19:12 <ncopa> kaniini: build fails. apparently it fails to construct the proper dependency chain https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3224#note_64417
2020-01-22 17:19:42 <ncopa> i could manually do: make <sometarget> and it would build it
2020-01-22 17:20:04 <ncopa> and the build will continue with error on next dependency
2020-01-22 17:20:13 <ncopa> the error is "dependency is missing"
2020-01-22 17:20:20 <ncopa> and it does not know how to build it
2020-01-22 17:20:42 <ncopa> openjdk11 has some super advanced makefiles
2020-01-22 17:20:53 <kaniini> in the GNU Make 4.3 news i see something about comments
2020-01-22 17:20:58 <ncopa> yeah
2020-01-22 17:21:09 <ncopa> not sure if thats the problem
2020-01-22 17:21:11 <ncopa> could be
2020-01-22 17:22:29 <ncopa> could also be regression in make
2020-01-22 17:22:53 <ncopa> should report it upstream somewhere
2020-01-22 17:28:18 <kaniini> the question ultimately is where
2020-01-22 17:30:25 <ncopa> exactly
2020-01-22 17:30:28 <ncopa> and im tired
2020-01-22 17:31:24 <ncopa> oh well... i was this close to tag a snapshot release while builders were idle
2020-01-22 17:31:31 <ncopa> and now armhf fails again
2020-01-22 17:34:14 <ncopa> i wonder what to respond here https://github.com/alpinelinux/docker-alpine/issues/39#issuecomment-577220407
2020-01-22 17:36:35 <ncopa> i guess we need to create new 3.10, 3.9 and 3.8 releases
2020-01-22 17:43:35 <kaniini> ah yes, docker
2020-01-22 17:43:59 <kaniini> well, i think we already know my thoughts on docker (and the arrogance of the commenters in that issue certainly seem to affirm my thoughts)
2020-01-22 17:44:13 <kaniini> my response would be "run apk upgrade -U -a you morons"
2020-01-22 17:44:42 <ncopa> i was initially thinking of a variant of that
2020-01-22 17:44:51 <AinNero> heh, agree
2020-01-22 17:45:07 <kaniini> something like this
2020-01-22 17:47:03 <kaniini> Alpine releases are generated whenever we need to change the boot media.  It is assumed that a user will apply all pending security updates to their installation by using "apk upgrade -U -a" upon initial installation.  It would be resource intensive to release a new point update for every single security update released for an Alpine release, so we make new point releases every so often.  Accordingly, support and security
2020-01-22 17:47:03 <kaniini> updates are dependent on proper usage of the package manager to fetch and install those updates.
2020-01-22 17:47:40 <kaniini> that's "run apk upgrade -U -a you morons" in a nice tone
2020-01-22 17:47:46 <kaniini> alternatively, you could say
2020-01-22 17:48:14 <kaniini> "hey, you know when you install Windows and it wants to update itself for 5 years afterwards?  you need to do the same with Alpine using apk upgrade -U -a when you prepare your container."
2020-01-22 17:48:45 <ncopa> i think they expect the image to be maintained
2020-01-22 17:49:02 <ncopa> which i think is not an unreasonable expectation, given that it is that small
2020-01-22 17:49:02 <kaniini> wouldn't that break things though
2020-01-22 17:49:27 <kaniini> i wonder if we can have a script
2020-01-22 17:49:32 <kaniini> just automatically generate new images
2020-01-22 17:49:33 <kaniini> every day
2020-01-22 17:49:58 <ncopa> we could do somethinglike that
2020-01-22 17:50:01 <kaniini> i don't know about docker really, i just assume that images are checksummed and things are pinned to images with a given checksum
2020-01-22 17:50:08 <ncopa> yup it is
2020-01-22 17:50:23 <kaniini> so if we have alpine:3.10 with checksum X and now it's checksum Y, wouldn't that break it?
2020-01-22 17:50:45 <AinNero> you can make a tag point to another checksum
2020-01-22 17:51:00 <ncopa> nah, it needs to be manually merged into the official library
2020-01-22 17:51:02 <ncopa> the checksum
2020-01-22 17:51:34 <ncopa> what would be nice was if we could run it automatically if a package in base image was changed
2020-01-22 17:51:39 <ncopa> and not every day
2020-01-22 17:51:58 <kaniini> apk ver ?
2020-01-22 17:52:10 <ncopa> the problem is that i link upstream release with the tags in docker
2020-01-22 17:52:26 <ncopa> but it would be good to separate those
2020-01-22 17:52:39 <ncopa> the docker image uses the minirootfs from releases
2020-01-22 17:53:04 <kaniini> makes sense
2020-01-22 17:53:08 <kaniini> well
2020-01-22 17:53:11 <kaniini> then there you go
2020-01-22 17:53:14 <ncopa> but basically, it would be nice if we could tag "light" releases
2020-01-22 17:53:25 <kaniini> just say that the tags correspond to physical releases
2020-01-22 17:53:42 <ncopa> which only builds the minirootfs
2020-01-22 17:54:00 <ncopa> ideally we should tag new relase of 3.10, 3.9 and 3.8
2020-01-22 17:54:00 <kaniini> ah
2020-01-22 17:54:03 <kaniini> so something like
2020-01-22 17:54:07 <kaniini> 3.9.1.1
2020-01-22 17:54:10 <kaniini> 3.9.1.2
2020-01-22 17:54:11 <kaniini> etc
2020-01-22 17:54:14 <ncopa> yup
2020-01-22 17:55:16 <ncopa> and do that every time something in minirootfs changes
2020-01-22 17:59:08 <ncopa> im looking over the kernel configs
2020-01-22 17:59:34 <ncopa> CONFIG_X86_INTEL_TSX_MODE_AUTO=y is on all x86 kernel configs except -virt.x86_64
2020-01-22 17:59:37 <ncopa> where it is OFF
2020-01-22 18:00:06 <ncopa> safest is OFF i suppose
2020-01-22 18:00:19 <ncopa> should we set all to OFF or all to AUTO
2020-01-22 18:04:23 <kaniini> i think OFF
2020-01-22 18:04:27 <kaniini> TSX is broken isnt it
2020-01-22 18:04:52 <ncopa> AUTO enables it on safe platforms it claims
2020-01-22 18:06:11 <kaniini> but are they actually safe :D
2020-01-22 18:06:26 <ncopa> thats the question at hand i guess
2020-01-22 18:07:23 <kaniini> On the other hand, Intel's Skylake or later may combine this cache-based approach with memory ordering buffer (MOB) for the same purpose, possibly also providing multi-versioned transactional memory that is more amenable to speculative multithreading.
2020-01-22 18:07:30 <kaniini> kill it
2020-01-22 18:07:31 <kaniini> kill it now
2020-01-22 18:07:41 <mforney> kaniini: just to check, you aren't middle of implementing compdb for samurai, right?
2020-01-22 18:07:50 <kaniini> mforney: i am not
2020-01-22 18:08:03 <kaniini> i have a few things i need to do ahead of time
2020-01-22 18:08:50 <mforney> okay, i will work on it now. does not seem that difficult, i just never had a use for it
2020-01-22 18:09:11 <kaniini> ncopa: i think we should disable TSX entirely.  based on what i am reading, it all looks quite sketchy.
2020-01-22 18:09:18 <ncopa> mforney: thank you for the quick response
2020-01-22 18:09:28 <ncopa> kaniini: ok will do. thanks!
2020-01-22 18:10:22 <kaniini> ncopa: i suspect TSX is going to be the next vector for a spectre-style bug, so if we can just not be vulnerable, that would be good :D
2020-01-22 18:11:31 <ddevault> thanks mforney
2020-01-22 18:19:06 <Cogitri> Thanks :)
2020-01-22 18:19:16 <kaniini> mforney: welcome to being the maintainer of critical build system infrastructure :D
2020-01-22 18:19:33 <kaniini> the first few months of pkgconf were like this
2020-01-22 18:19:48 <kaniini> some edge case would be missing and it was like "oh fuck we need to ship a release"
2020-01-22 18:19:55 <vivi_> Is the build server that pushes these artifacts public? http://dl-cdn.alpinelinux.org/alpine/v3.11/releases/armhf/
2020-01-22 18:20:09 <kaniini> public in what way
2020-01-22 18:20:09 <vivi_> I'm looking for the build scripts to generate the armhf image
2020-01-22 18:20:19 <kaniini> yes, its on gitlab
2020-01-22 18:20:36 <vivi_> Assuming this one - https://gitlab.alpinelinux.org/alpine
2020-01-22 18:21:05 <vivi_> I've poked around there however have been unable to find the particular script that generates the rootfs for raspberry pi
2020-01-22 18:21:06 <kaniini> see aports/scripts/mkimage.sh
2020-01-22 18:21:13 <vivi_> kaniini++ tyvm!
2020-01-22 18:28:53 <ncopa> i tagged new edge snapshot
2020-01-22 19:15:34 <vivi_> kaniini, https://git.riboflav.in/snippets/7   -- I'm confused about /etc/apk/world, /media/mmcblk0/apk/armhf and /media/mmcblk0/cache - I have a signed apkindex.tar.gz, my pub key is in /etc/apk/keys - for some reason on boot the pi doesn't have all the packages installed
2020-01-22 19:16:21 <vivi_> This is *extremely* hacky code now - caused by desperation :(
2020-01-22 19:18:17 <vivi_> I went as far as running setup-alpine on a pi and rsyncing the apks + cache directory *into* our repository - now it's full of binary blobs agh
2020-01-22 19:20:27 <kaniini> vivi_: does /etc/apk/repositories contain a path to your repo ?
2020-01-22 19:20:51 <vivi_> kaniini, yes, it does.  /media/mmcblk0/apks
2020-01-22 19:21:22 <kaniini> vivi_: are all the packages you want installed placed in /etc/apk/world *inside* the apkovl ?
2020-01-22 19:21:34 <vivi_> Yes, every one of them.
2020-01-22 19:22:44 <kaniini> do you have a boot log?
2020-01-22 19:23:52 <vivi_> I'll get one now - gotta dd this fresh image and I'll capture
2020-01-22 19:24:49 <vivi_> ERROR: busybox-initscripts package mentioned in index not found
2020-01-22 19:25:05 <vivi_> Including 8 others - all of which appear to be highly important.
2020-01-22 19:25:28 <kaniini> are they in the dir?
2020-01-22 19:26:05 <vivi_> 
ACTION mounts sd card

2020-01-22 19:26:39 <vivi_> -rwxr-xr-x 1 root root 8.1K Jan 22 12:32 /tmp/mnt/apks/armhf/busybox-initscripts-3.2-r2.apk
2020-01-22 19:26:58 <vivi_> They're all there.
2020-01-22 19:28:25 <vivi_> mkdir -p /tmp/apk && tar -zxvf /tmp/mnt/apks/armhf/APKINDEX.tar.gz -C /tmp/apk && grep -ir busybox-init /tmp/apk  | wc -l   /////// 4
2020-01-22 19:30:13 <vivi_> kaniini, I'm wondering if it's the `index -vU -o APKINDEX.tar.gz *.apk` and `abuild-sign -k /home/build/.abuild/build-5e1cf9f9.rsa APKINDEX.tar.gz`
2020-01-22 19:30:42 <kaniini> is it `index` or `apk index` ?
2020-01-22 19:31:45 <vivi_> This is where I was confused by the documentation.  I've read it over so many times it no longer makes sense :P  I'm building a custom APK with the instructions exactly from the wiki.  Then copying that APK into /media/mmcblk0/apk/armhf, then creating the APKVOL and the APKINDEX
2020-01-22 19:32:56 <vivi_> But I'd like to try eliminating the custom apk and just getting the CI pipeline to pre-install whatever packages I specify.  That in its own is the struggle.
2020-01-22 19:33:30 <vivi_> I can figure out how to add my custom apack in there after this thing boots with ppp installed by default lol
2020-01-22 19:34:52 <vivi_> Going to break this out into it's own standalone script to attempt to simplify
2020-01-22 19:53:25 <dfnord> hi all. is alpine upgrading php to 7.4 anytime soon?
2020-01-22 20:02:34 <vivi_> dfnord, https://gitlab.alpinelinux.org/alpine/aports/commit/e045f093af466b4d7f159b9e6e4eb8c2834cb6fc
2020-01-22 20:02:51 <vivi_> Looks like it
2020-01-22 20:14:36 <vivi_> kaniini, I've removed everything specific to my build (except for a few configurations) - this *almost* works but reports dependency hell : https://0bin.net/paste/PtVSo84+21c3ES-o#-5lKRk860WcB5K+axdEJlYRX97ClC5dyI5M1Dke4RD7
2020-01-22 20:17:35 <vivi_> And here is the output of the above script : https://0bin.net/paste/66ywTlES6ymIsWM9#bG+Dhmh0nF5Dtm-b4O0fq8ZBi+Dx/Q2mVqs/GCp4LM5
2020-01-22 20:19:02 <dfnord> i mean this one here: https://gitlab.alpinelinux.org/alpine/aports/tree/master/community/php7
2020-01-22 20:38:51 <vivi_> Alright kinda found a fix - with the apk fetch I issue a `-R` flag for recursion - now I'm alpine-base isn't being installed (how?)
2020-01-22 21:01:38 <kaniini> Cogitri: ping
2020-01-22 21:02:14 <north1> kaniini: I believe he is unavailable atm
2020-01-22 21:03:24 <kaniini> mforney: based on testing, i believe your compdb is adequate
2020-01-22 21:05:29 <kaniini> mforney: will there be a 1.0.1 or should i just backport this myself
2020-01-22 21:08:54 <mforney> i'd say just add a patch for now, and i can do a release when we're fairly confident no other changes will be needed
2020-01-22 21:09:24 <kaniini> okay
2020-01-22 21:09:25 <kaniini> cool
2020-01-22 21:09:57 <milliardo> j
2020-01-22 21:10:16 <kaniini> mforney: thanks for your work on this :)
2020-01-22 21:10:35 <mforney> np
2020-01-22 21:34:40 <clandmeter> anyone here have an issue if tpaste would be https only? or can think of an use case that depends on http?
2020-01-22 21:37:41 <MY-R> maybe only those who will try paste something from half working system without certs or with wrong time?
2020-01-22 21:39:11 <clandmeter> right, thats also what i thought
2020-01-22 21:39:33 <MY-R> ye :\
2020-01-22 21:39:47 <clandmeter> question is, do we want to support broken use cases :)
2020-01-22 21:41:16 <MY-R> is more about users who coming and asking for help because soooomehow mirrors not working on their machines or got wrong date/time because just set up arm machine :P
2020-01-22 21:42:00 <clandmeter> thats architectural racisme :)
2020-01-22 21:42:14 <MY-R> or just missing rtc :D
2020-01-22 21:42:22 <clandmeter> there are arm machines with rtc :)
2020-01-22 21:42:39 <clandmeter> and x86 ones without :)
2020-01-22 21:42:52 <MY-R> true :P
2020-01-22 21:43:22 <clandmeter> traefik is just stupid
2020-01-22 21:43:23 <MY-R> and people who still dont have much idea about ntp clients! :P
2020-01-22 21:46:16 <_ikke_> clandmeter: someone says traefik v2 offers a lot more flexibility
2020-01-22 21:46:32 <clandmeter> yes
2020-01-22 21:46:36 <clandmeter> its maybe better
2020-01-22 21:46:48 <clandmeter> but it also means you need to do it per container\
2020-01-22 21:47:09 <clandmeter> that wouldnt be that much work
2020-01-22 21:47:24 <clandmeter> i played with v2 before
2020-01-22 21:47:28 <clandmeter> not sure which hosts
2020-01-22 22:01:04 <Cogitri> kaniini: pong, can test later
2020-01-22 22:01:21 <kaniini> Cogitri: looks like it is working to me :)
2020-01-22 22:13:26 <Cogitri> Neat
2020-01-22 22:43:37 <vivi_> ERROR: udev-init-scripts-33-r0: package mentioned in index not found
2020-01-22 22:44:10 <vivi_> -rwxr-xr-x    1 root     root        1.3K Nov 21  2019 /media/mmcblk0/apks/custom/armhf/udev-init-scripts-33-r0.apk
2020-01-22 22:44:30 <vivi_> Everything else from the directory / volume installed except for this and `hwids-*`
2020-01-22 22:47:22 <vivi_> etc/apk/world includes the udev-init-scripts, hwids-pci, hwids-usb, hwids-udev, hwids-net
2020-01-22 23:47:46 <mps> should the firefox-esr 68.4.2 be 'backported' to 3.11
2020-01-22 23:49:20 <Cogitri> That fixed some CVEs, didn't it?
2020-01-22 23:51:38 <mps> didn't found yet, but probably
2020-01-23 00:33:15 <vivi_> any idea why these five packages would cause an issue despite all others installed the *exact* same way do not make their way into the final OS
2020-01-23 08:27:44 <mps> kernel 5.4.14 is out
2020-01-23 08:28:58 <mps> and I don't see i915 fix there, maybe will see it after coffee :)
2020-01-23 08:51:07 <ncopa> mps: re firefox-esr #11118
2020-01-23 08:54:27 <mps> yes, I know for this one, but I thought it is fixed in 68.4.1
2020-01-23 08:54:56 <markand> am I the only one thinking GitLab UX pretty awful?
2020-01-23 08:55:09 <markand> I goes into alpine/aports, see that I can create a merge request from a recent commit
2020-01-23 08:55:24 <markand> click on it and it opens my own fork to merge my branch into... my master rather than alpine/aports
2020-01-23 08:55:49 <ncopa> mps: the issue is still open so i assume that 68.4.1 was never pushed to 3.11-stable. we could do 68.4.2 while at it
2020-01-23 08:56:40 <_ikke_> markand: I have a feeling this is changed since 12.6
2020-01-23 08:56:50 <ncopa> markand: this is alpine development. please try #gitlab
2020-01-23 08:56:57 <markand> _ikke_, exactly
2020-01-23 08:57:16 <markand> because I think it worked fine few weeks ago
2020-01-23 08:58:42 <mps> ncopa: apk policy firefox-esr =>  http://dl-cdn.alpinelinux.org/alpine/v3.11/community
2020-01-23 08:58:43 <markand> hmmm, my own apkbuild-lint does not show warnings for !3318
2020-01-23 08:59:21 <_ikke_> markand: what version?
2020-01-23 08:59:40 <markand> atools-19.9.1-r0
2020-01-23 09:00:14 <mps> ok, I will create MR to test build before push
2020-01-23 09:00:41 <mps> if we found CVE for it we can add them later
2020-01-23 09:01:30 <north1> @ikke !3278
2020-01-23 09:01:41 <_ikke_> north1: yes, I've seen it, will test it soon
2020-01-23 09:01:46 <north1> yay
2020-01-23 09:01:47 <_ikke_> haven't had the time yet
2020-01-23 09:06:46 <mps> heh, Cogitri just updated his MR with firefox-esr 68.4.2 version.
2020-01-23 09:07:17 <Cogitri> Yup
2020-01-23 09:07:30 <Cogitri> Gonna merge once CI went through, I suppose
2020-01-23 09:08:08 <mps> ok, then I will not create new one
2020-01-23 09:08:12 <Cogitri> And backport it to 3.11 after a little while so icon locations are fixed for that too
2020-01-23 09:08:40 <Cogitri> Huh?
2020-01-23 09:08:45 <mps> ah, you made MR in master
2020-01-23 09:08:56 <Cogitri> That MR only fixes linter nits and the icon install location
2020-01-23 09:09:38 <mps> I'm started to make plain upgrade for 3.11
2020-01-23 09:11:08 <Cogitri> Ah, please do keep doing that then :)
2020-01-23 09:12:11 <mps> I'm watching your MR, will it pass
2020-01-23 09:13:06 <ncopa> im updating kernels in stable branches
2020-01-23 09:13:26 <ncopa> kind of annoyed that i spent an hour yesterday on it and now there is a new version...
2020-01-23 09:14:26 <mps> release often, release early (upstream devs mantra) :)
2020-01-23 09:15:18 <markand> hopefully you don't do that every vim version ;p
2020-01-23 09:16:06 <markand> which has literally dozens of versions per day
2020-01-23 09:16:56 <mps> ncurses releases nearly weekly
2020-01-23 09:17:17 <mps> and kernel LTS :)
2020-01-23 09:17:40 <mps> so, life is not boring ;)
2020-01-23 09:44:35 <ncopa> drats. i merged wrong luajit patch
2020-01-23 09:45:03 <ncopa> im not good at multitasking apparently
2020-01-23 09:45:48 <_ikke_> lol
2020-01-23 09:46:27 <_ikke_> algitbot is so sympathic :-)
2020-01-23 09:56:20 <MY-R> lol :P
2020-01-23 09:58:21 <MY-R> ncopa, tell me who is? better to focus on single thing and do it good instead mess up few at once :D
2020-01-23 09:58:49 <clandmeter> if life was that simple...
2020-01-23 09:58:54 <MY-R> ye
2020-01-23 09:59:18 <_ikke_> focus is a luxury
2020-01-23 09:59:50 <AinNero> algitbot: thanks for the support
2020-01-23 10:00:06 <AinNero> ... i'd be curious to see your code, algitbot
2020-01-23 10:00:25 <MY-R> ye but claiming that somebody is good in many things at once is very naive
2020-01-23 10:00:54 <MY-R> algitbot, AI :)
2020-01-23 10:01:27 <ncopa> algitbot: please behave!
2020-01-23 10:01:46 <clandmeter> i think if we have a lot of free time we could dockerize algitbot and put the scripts in the project.
2020-01-23 10:01:58 <ncopa> yeah, sounds like a good idea
2020-01-23 10:02:04 <clandmeter> but first, let put some ppl on mars.
2020-01-23 10:02:08 <ncopa> lol
2020-01-23 10:02:11 <_ikke_> AinNero: http://www.commitstrip.com/en/2017/06/07/ai-inside/
2020-01-23 10:02:22 <markand> algitbot, give me beer
2020-01-23 10:02:32 <markand> algitbot: give me beer
2020-01-23 10:02:34 <markand> :(
2020-01-23 10:04:56 <ncopa> algitbot: give me a beer
2020-01-23 10:05:16 <ncopa> _ikke_: yeah, thats algitbot!
2020-01-23 10:05:45 <markand> so it only answers to some people
2020-01-23 10:05:51 <_ikke_> no
2020-01-23 10:05:55 <_ikke_> ncopa hotpatched it
2020-01-23 10:05:58 <markand> aah :-)
2020-01-23 10:06:11 <ncopa> 🚱
2020-01-23 10:06:49 <MY-R> connect algitbot with alexa :D
2020-01-23 10:07:07 <_ikke_> ncopa: no potable watter?
2020-01-23 10:07:18 <ncopa> thelounge is stupid
2020-01-23 10:07:21 <_ikke_> heh
2020-01-23 10:07:24 <ncopa> :-p
2020-01-23 10:07:41 <clandmeter> yeah blame it on something else :p
2020-01-23 10:08:30 <MY-R> #60000 :D
2020-01-23 10:08:48 <MY-R> eh :\
2020-01-23 10:09:18 <MY-R> #6000 !
2020-01-23 10:11:54 <ncopa> "This bug was mainly to celebrate the 6000th bug report :)"
2020-01-23 10:11:56 <ncopa> :)
2020-01-23 10:12:30 <_ikke_> heh :-)
2020-01-23 10:12:30 <mps> algitbot: give me advice about my dilemma with !2212 :)
2020-01-23 10:17:01 <MY-R> ps I think #8599 can be closed
2020-01-23 10:19:42 <mps> MY-R: I agree
2020-01-23 11:41:20 <ncopa> im backporting CVE fix to libjpeg turbo
2020-01-23 11:41:40 <ncopa> nasty fix, because they changed tabs to spaces
2020-01-23 11:41:53 <ncopa> and introduced som camelcase vars
2020-01-23 11:42:19 <ncopa> which makes it impossible to do a clean cherrypick and the diff is hard to spot
2020-01-23 11:50:45 <mps> ncopa: did you watch https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/
2020-01-23 11:52:20 <^7heo> mps: it's easy, just use go.
2020-01-23 11:52:29 <^7heo> and node
2020-01-23 11:53:25 <mps> TIMTOW to make distro maintainers to cry :)
2020-01-23 11:54:09 <^7heo> distro maintainer != package maintainer.
2020-01-23 11:54:33 <mps> well, true but not big differences
2020-01-23 11:54:35 <^7heo> most people who will be annoyed at package managers crying will be the package maintainers ;p
2020-01-23 11:54:53 <^7heo> the packages a distro maintainer will care about have low chances of making the package manager cry. Hopefully.
2020-01-23 11:54:59 <^7heo> Unless we're talking about NodeOS.
2020-01-23 11:55:56 <mps> never touched nodejs
2020-01-23 11:56:06 <^7heo> Good for you :)
2020-01-23 11:56:25 <mps> and tend to go back to pure C
2020-01-23 11:56:56 <^7heo> do you think the NSA is watching what you do at all times?
2020-01-23 11:57:37 <mps> I don't care who is watching what I do
2020-01-23 11:57:46 <^7heo> you're not paranoid enough.
2020-01-23 11:57:48 <^7heo> Please don't do C.
2020-01-23 11:58:17 <mps> holy spirit watch on me all time :)
2020-01-23 11:58:43 <^7heo> Ok, you're ready for perl.
2020-01-23 11:59:13 <mps> ^7heo: you have a point, instead of C I'm contemplating about go to assembly
2020-01-23 11:59:53 <mps> heh, how did you know that I do a lot of things in perl :)
2020-01-23 12:00:20 <^7heo> you have the apparent mindset.
2020-01-23 12:02:31 <mps> actually, I think forth is best programming language
2020-01-23 12:03:52 <^7heo> I like malbolge.
2020-01-23 12:03:58 <^7heo> It's more readable than perl
2020-01-23 12:04:04 <^7heo> and it's more efficient than java.
2020-01-23 12:04:56 <mps> perl is readable, ofc, but agree is not for py programmers
2020-01-23 12:05:49 <mps> Cogitri: both of our firefox-esr failed on CI
2020-01-23 12:06:01 <^7heo> mps: perl is a write-only language, it's a well known fact.
2020-01-23 12:06:03 <mps> I will try now in lxc
2020-01-23 12:06:39 <mps> ^7heo: we have #alpine-offtopic channel
2020-01-23 12:09:39 <^7heo> mps: I am aware.
2020-01-23 12:09:45 <^7heo> mps: I do not intend to stay here anyway.
2020-01-23 12:09:54 <^7heo> and if that is a problem, you're very welcome to /ignore me.
2020-01-23 12:10:53 <mps> ^7heo: no, not problem for me, I told that I enjoy to read your 'writings'
2020-01-23 12:11:31 <mps> for years I have only one person in ignore list
2020-01-23 12:25:09 <ncopa> mps: i havent seen it
2020-01-23 12:32:33 <ncopa> finally managed to backport libjpeg-turbo fix
2020-01-23 12:37:38 <mps> how_to_make_package_managers_cry is for free time to relax and smile a little :)
2020-01-23 12:38:21 <_ikke_> It's a fun presentation
2020-01-23 12:38:35 <_ikke_> Very relatable
2020-01-23 12:43:15 <Cogitri> mps: Probably due to running out of RAM
2020-01-23 12:45:00 <Cogitri> _ikke_: X86_64 CI runner doesn't do stuff again, Jobs just time out
2020-01-23 12:47:08 <mps> I started it in x86_64 3.11 lxc to see will it pass
2020-01-23 12:47:16 <_ikke_> Cogitri: ok, I'll check in a moment
2020-01-23 12:48:12 <Cogitri> Thank you :)
2020-01-23 12:49:39 <mps> but I see you pushed it already
2020-01-23 12:49:53 <Cogitri> I pushed my pushes to master not 3.11
2020-01-23 12:50:03 <mps> ah, yes
2020-01-23 12:50:15 <Cogitri> Also, I didn't do an upgrade or anything, I just fixed the icon install location
2020-01-23 12:50:52 <mps> didn't looked carefully to 'algitbot| aports:master'
2020-01-23 12:51:23 <mps> on master it is upgraded few days ago already
2020-01-23 13:00:56 <Cogitri> Yes
2020-01-23 13:07:45 <_ikke_> Cogitri: the runner seems to be working?
2020-01-23 13:08:09 <_ikke_> at least, from a runner perspective
2020-01-23 13:08:14 <_ikke_> Can you show where it's failing?
2020-01-23 13:08:42 <Cogitri> mps' Firefox MR
2020-01-23 13:08:53 <Cogitri> !3319
2020-01-23 13:33:48 <reidrankin> I've been doing some work on apk-tools regarding signature verification recently; I've had to figure out the history of the format from the code, and I'm wondering if anyone can tell me the main rationale for moving from apk format v1 to v2 was?
2020-01-23 13:36:58 <reidrankin> more to the point: I'm not interested in .INSTALL vs .PKGINFO, I'm wondering why the control and data sections are separate gzip blocks instead of the v1 style of there being one tar file and the first non-hidden file being the start of the data block
2020-01-23 13:53:11 <kaniini> reidrankin: index signs control section, control signs data
2020-01-23 13:54:40 <reidrankin> right, but why?
2020-01-23 13:55:27 <reidrankin> it seems that in v1 the signature must have been over control + data; or were signatures not a thing until v2?
2020-01-23 13:56:47 <kaniini> performance reasons
2020-01-23 13:57:08 <kaniini> it allows for deferring checking the data sign ature
2020-01-23 13:57:26 <kaniini> until the subtransaction is about to be committed to disk
2020-01-23 13:57:29 <reidrankin> ah, so an invalid sig can be detected fast.
2020-01-23 13:57:34 <reidrankin> got it.
2020-01-23 13:58:24 <reidrankin> what I've been struggling with is the inability to optimize stuff due to the signature (and datahash) being over the compressed data.
2020-01-23 13:58:26 <kaniini> in order to have a valid installable package that is modified, you have to generate a new control section
2020-01-23 13:58:36 <kaniini> well
2020-01-23 13:58:44 <kaniini> the signature is only of the control part
2020-01-23 13:59:14 <kaniini> that data part is verified by checking each file's checksum individually given a list in the control part
2020-01-23 14:00:11 <reidrankin> no it's not
2020-01-23 14:00:29 <reidrankin> the data part only has a sha256 over the whole gzipped tar stream
2020-01-23 14:00:57 <reidrankin> the individual file checksums are stored in the data section as pax attributes
2020-01-23 14:03:17 <reidrankin> I'm working on a high-assurance embedded system, and what I'm trying to achieve is a boot process that gives the level of assurance that comes with the run-from-ram configuration without requiring a lot of expensive ram to make copies of everything you already have on the block storage
2020-01-23 14:06:21 <reidrankin> it would be really nice if there was a hash of the uncompressed data for that purpose
2020-01-23 14:07:26 <reidrankin> so I might send up a PR for that in a day or two
2020-01-23 14:09:25 <kaniini> well, it has been a while since i looked at it
2020-01-23 14:09:45 <kaniini> reidrankin: we are likely not to accept any changes to the v2 format, as there is a new v3 format under design.
2020-01-23 14:10:09 <kaniini> reidrankin: if you are a stakeholder in this (sounds like you are), you may wish to review the alpine-devel list
2020-01-23 14:10:53 <reidrankin> I've been following Timo's thread regarding the switch to binary formats
2020-01-23 14:15:19 <reidrankin> I'm honestly not too hot on that; I don't really care about the index format, but I really appreciate the simplicity and transparency of the APK format
2020-01-23 14:17:32 <kaniini> you should say so then
2020-01-23 14:17:36 <kaniini> it is not set in stone
2020-01-23 14:18:03 <reidrankin> (I'm not saying I won't come around though; I haven't had time to fully grok his wip branch)
2020-01-23 14:18:23 <kaniini> the whole point of his writing threads about what he wishes to do is to allow him to see if he should pursue this work or not
2020-01-23 14:19:20 <kaniini> i think it makes sense to use a common container format for both packages and the database
2020-01-23 14:19:43 <kaniini> but the benefits are really long term
2020-01-23 14:19:49 <reidrankin> I'm hoping to bring a potential solution to the table, not just negative feedback, so I'm tring to get my thoughts together and maybe PoC it out
2020-01-23 14:20:30 <kaniini> well, my point is this.
2020-01-23 14:21:12 <reidrankin> to clarify: I do like the idea of the common control format, I'm more concerned with what might be done regarding the data section
2020-01-23 14:21:33 <kaniini> lots of people who do have some significant interest in how things go say they are not enthusiastic about the proposed APKv3 format off-the-record
2020-01-23 14:22:16 <kaniini> and i would rather us not wind up in a situation where we have this apk3 that we cannot really ship in alpine (or any other distro) because it's not actually viable
2020-01-23 14:22:36 <ddevault> I am in favor of more incremental improvements to apk
2020-01-23 14:22:47 <kaniini> well that is how things were going
2020-01-23 14:22:53 <reidrankin> ok, let me ask a really bad question
2020-01-23 14:23:01 <ddevault> it seems like we're incrementally building up a spec for a big change
2020-01-23 14:23:06 <ddevault> I'd like to incrementally build up the change instead
2020-01-23 14:23:06 <kaniini> but some things went down, and it is not happening that way right now ;)
2020-01-23 14:23:18 <reidrankin> why not totally rewrite apk-tools in Go
2020-01-23 14:23:57 <kaniini> reidrankin: well, i was expecting you to say rust
2020-01-23 14:24:00 <kaniini> :D
2020-01-23 14:24:08 <reidrankin> i don't know rust yet :P{
2020-01-23 14:24:17 <reidrankin> s/\{//
2020-01-23 14:24:29 <_ikke_> reidrankin: rewriting it in another language does not automatically improve things
2020-01-23 14:24:48 <reidrankin> in the general case, I agree with you
2020-01-23 14:24:57 <kaniini> also rewriting it in Go is undesirable.  right now we can bootstrap apk-tools very early
2020-01-23 14:25:09 <ddevault> s/in Go//
2020-01-23 14:25:33 <kaniini> i dont think apk-tools needs a rewrite anyway
2020-01-23 14:25:43 <kaniini> it is a pretty high quality codebase tbh
2020-01-23 14:25:49 <_ikke_> Rewriting things in a language you are not familiar with can only make things work
2020-01-23 14:25:49 <ddevault> agreed
2020-01-23 14:25:55 <_ikke_> s/work/worse
2020-01-23 14:25:55 <alpine-meetbot> _ikke_ meant to say: Rewriting things in a language you are not familiar with can only make things worse
2020-01-23 14:26:05 <ddevault> rewriting things can only make things worse
2020-01-23 14:26:37 <_ikke_> ddevault: agreed
2020-01-23 14:27:02 <reidrankin> but in this specific case, I've spent something like 72 hours working with the code and I'm still not super happy with my understanding of the format
2020-01-23 14:27:33 <kaniini> rewriting it in Go does not change the format
2020-01-23 14:28:11 <ddevault> well, not deliberately
2020-01-23 14:28:16 <reidrankin> ah, yes, but there's a distinction between the format as it was fairly obviously intended and the format that's actually accepted by the parser
2020-01-23 14:29:07 <reidrankin> for example: you can stick a .PKGINFO in a signature block, and the parser will happily read in the datahash element from it into the sctx struct
2020-01-23 14:31:25 <reidrankin> the only thing that prevents that from being a catastrophic security bug is that that hash is also being hashed, thereby changing the hash away from what you maliciously set it to
2020-01-23 14:32:08 <reidrankin> other things that took me a while to realize include the fact that a control section missing a datahash element will cause the signature check to fall back to hashing the whole control + data section
2020-01-23 14:32:24 <reidrankin> (I can't figure out if that's a bug or a feature)
2020-01-23 14:33:14 <mps> reidrankin: there is already static apk version ;p
2020-01-23 14:33:18 <reidrankin> and the fact that the manifest command tries to dump the hashes of the control scripts, which doesn't make a lot of sense
2020-01-23 14:34:14 <tomz-alpine> is the BCM4360 802.11ac Wireless supported in alpine?
2020-01-23 14:35:34 <reidrankin> the main problem is that C doesn't lend itself well to composing functions or processing data streams, which makes the code not very good self-documentation.
2020-01-23 14:36:23 <ncopa> im tagging releases for 3.10, 3.9 and 3.8 now
2020-01-23 14:37:10 <mps> tomz-alpine: better ask on #alpine-linux, probably will get answer earlier than here
2020-01-23 14:37:32 <tomz-alpine> thanks
2020-01-23 14:38:31 <north1> ncopa: might be worth looking at openjdk security updates on those releases
2020-01-23 14:38:38 <north1> J0w1 made MRs for them
2020-01-23 14:39:02 <reidrankin> anyhow, I'm not saying we should rewrite apk. I'm more interested in the rationale for the status quo - I generally find that things are the way they are for reasons
2020-01-23 14:41:38 <ncopa> north1: i had a long look at it this week
2020-01-23 14:41:46 <ncopa> it does not build with gnu make 4.3
2020-01-23 14:41:59 <ncopa> not sure if its a bug in make or in openjdk makefiles
2020-01-23 14:45:23 <north1> As far as I remember make didn't make it into the older releases
2020-01-23 14:48:04 <ncopa> i like to test it in edge before i push to stable if possible
2020-01-23 14:48:22 <ncopa> it also makes sure that we dont forget it in next major release
2020-01-23 14:48:25 <north1> Alright
2020-01-23 14:48:41 <ncopa> but, may be worth push to stable first in this case
2020-01-23 14:50:25 <Cogitri> kaniini: compile_commands.json is not a flatpak manifest, skipping: <data>:6:67: Parse error: unexpected character `,', expected character `]'
2020-01-23 14:50:44 <Cogitri> Seems like it's not really working still :/
2020-01-23 14:51:03 <kaniini> mforney: looks like there are some escaping issues
2020-01-23 14:55:54 <Cogitri> Added it to https://github.com/michaelforney/samurai/issues/33
2020-01-23 15:29:38 <[[sroracle]]> kaniini: well-put on the ML
2020-01-23 15:36:47 <kaniini> please share your thoughts on the ML.  the whole point of the thread is to discuss the scalability concerns and capture any relevant conclusions as actionable items
2020-01-23 15:41:57 <[[sroracle]]> yeah i will take some time later today to put together a reply
2020-01-23 16:00:51 <mps> hmm, !3319 failed on CI but pass fine in local lxc, x86_64
2020-01-23 16:03:13 <Cogitri> You can click on the buildjob to see why it failed
2020-01-23 16:03:27 <Cogitri> It failed because no builder was available within the timeout limit
2020-01-23 16:04:16 <mps> 'clickjob', where it is?
2020-01-23 16:04:23 <mps> no
2020-01-23 16:04:30 <mps> 'buildjob'
2020-01-23 16:05:25 <Cogitri> 
ACTION uploaded an image: Screenshot_20200123-170437.jpg (409KB) < http://localhost:8008/_matrix/media/r0/download/matrix.exqa.de/ddQbWykdxKILUSlItKAklrsu >

2020-01-23 16:05:38 <Cogitri> Clcik on "build-x86_64" for the log of the x86_64 runner
2020-01-23 16:06:23 <mps> ah, I see, right side
2020-01-23 16:07:40 <mps> always look on middle with log looking for bug :)
2020-01-23 16:07:52 <mps> tunnel vision
2020-01-23 16:09:24 <mps> do you think it is ok to push it to aports without retrying on CI, maybe it will again timeout there
2020-01-23 16:13:13 <mps> Cogitri: btw, your image post is on (your?) localhost
2020-01-23 16:13:16 <MY-R> 17:05 * Cogitri uploaded an image: Screenshot_20200123-170437.jpg (409KB) < http://localhost:8008/_matrix/media/r0/download/matrix.exqa.de/ddQbWykdxKILUSlItKAklrsu >
2020-01-23 16:13:18 <MY-R> ye :D
2020-01-23 16:17:14 <Cogitri> Oh huh
2020-01-23 16:17:16 <Cogitri> That's not good
2020-01-23 16:17:49 <mps> and no problem, imo
2020-01-23 16:18:10 <Cogitri> Probably forgot to change the hostname in some config
2020-01-23 16:26:11 <Cogitri> Yup, should work now
2020-01-23 16:35:31 <AinNero> whats the current performance bottleneck with apk-tools?
2020-01-23 16:35:42 <AinNero> i'd hilight timo teras but i dont know their nick
2020-01-23 16:39:59 <mps> I forgot (if I ever knew for sure) how to push from local 3.xx branch to git.a.o same branch
2020-01-23 16:40:41 <mps> 'git push origin 3.11-stable'?
2020-01-23 16:41:10 <Cogitri> If origin is your git.a.o then yes
2020-01-23 16:41:23 <Cogitri> I'd recommend you check out maxice8's tools, they're really nice for that
2020-01-23 16:42:52 <mps> I have his tools, what to look there
2020-01-23 16:42:58 <reidrankin> quick apk-tools question: anyone have a strong opinion on the ternary operator?
2020-01-23 16:43:36 <Cogitri> I don't like it lots but it can make stuff shorter I suppose
2020-01-23 16:44:40 <Cogitri> mps: pushp can do good things for you if you follow his setup (gitstream remote is git.a.o, upstream is gitlab.a.o, origin is your fork on gitlab) and you use good branch names (e.g. 3.11-firefox-esr)
2020-01-23 16:45:30 <mps> my origin is git.a.o
2020-01-23 16:47:01 <mps> and I didn't created separate branch for FF this time, worked on top of 3.11-stable branch
2020-01-23 16:50:12 <mps> hm, 'git push origin HEAD', maybe
2020-01-23 16:51:53 <mps> _ikke_: sorry to annoy you again, if you have little time ^
2020-01-23 16:52:51 <_ikke_> mps: if you have an upstream set, git push should be enough
2020-01-23 16:53:46 <mps> here is 'git remote -v' http://tpaste.us/Bjnk
2020-01-23 16:54:31 <_ikke_> mps: git branch -vv
2020-01-23 16:54:37 <mps> and current 'git branch' http://tpaste.us/b451
2020-01-23 16:55:05 <mps> and with '-vv' http://tpaste.us/7KQo
2020-01-23 16:55:18 <_ikke_> yes, just git push should work
2020-01-23 16:55:34 <mps> without 'origin'?
2020-01-23 16:55:36 <_ikke_> You see 3.11-stable is tracking origin/3.11 stable
2020-01-23 16:55:37 <_ikke_> yes
2020-01-23 16:55:43 <_ikke_> though it's not wrong to specify origin
2020-01-23 16:55:49 <mps> ok, thanks
2020-01-23 16:56:07 <_ikke_> succeeded :)
2020-01-23 16:56:11 <mps> hah, yes
2020-01-23 16:56:23 <mps> _ikke_: 1000x thanks
2020-01-23 16:56:53 <mps> I have to save in notes this conversation
2020-01-23 17:02:13 <ddevault> fabled: is it security or is it performance? if it's both then the change is too big
2020-01-23 17:15:04 <mps> heh, algitbot learned to automatically set MRs which are pushed to merged status :)
2020-01-23 17:16:51 <_ikke_> mps: did it, or did you happen to just push the exact commit as they are in the MR?
2020-01-23 17:17:56 <mps> that, exactly same commit
2020-01-23 17:18:00 <Cogitri> It only does that if the commit sha of the MR matches what's pushed to gitstream
2020-01-23 17:18:06 <_ikke_> yes
2020-01-23 17:18:16 <_ikke_> then it knows those commits made it into master
2020-01-23 17:18:25 <_ikke_> or the relevant branch
2020-01-23 17:19:27 <mps> aha, I see
2020-01-23 17:57:57 <fabled> ddevault, the format needs to change. both are taken into account. security is the main driver. but performance is a valid thing for indexes too.
2020-01-23 17:59:34 <fabled> ddevault, planning to write the code in reasonable increments. but obviously the file format gets replaced so it's high-impact.
2020-01-23 17:59:48 <ddevault> bleh
2020-01-23 18:00:01 <ddevault> I know it's not constructive, but bleh is how I feel about all of this
2020-01-23 18:00:11 <fabled> then you are not listening
2020-01-23 18:00:17 <fabled> the current format is broken
2020-01-23 18:00:30 <ddevault> I am listening perfectly well
2020-01-23 18:00:41 <ddevault> I don't buy it
2020-01-23 18:01:14 <fabled> https://gitlab.alpinelinux.org/alpine/apk-tools/issues/10670
2020-01-23 18:01:28 <fabled> infact, look at https://gitlab.alpinelinux.org/alpine/apk-tools/issues
2020-01-23 18:01:40 <fabled> and more specifically https://gitlab.alpinelinux.org/alpine/apk-tools/issues?milestone_title=v3.0
2020-01-23 18:01:41 <ddevault> use of sha-1 isn't a format issue, and fixing it does not necessitate an overhaul
2020-01-23 18:01:54 <reidrankin> fabled: I have a MR to fix that just about ready to go
2020-01-23 18:02:21 <fabled> reidrankin, fix what?
2020-01-23 18:02:32 <reidrankin> #10670
2020-01-23 18:02:49 <ddevault> I'm not sure how the link to the issues list justifies your position
2020-01-23 18:02:50 <fabled> the bad signature one, or the sha1 thing?
2020-01-23 18:03:04 <ddevault> very little of this has anything to do with package or index format
2020-01-23 18:03:06 <reidrankin> both actually
2020-01-23 18:03:34 <kaniini> i think we should stick to e-mail instead of being defensive in IRC
2020-01-23 18:03:37 <fabled> reidrankin, the sha1 change is probably format breaking
2020-01-23 18:04:07 <reidrankin> nope, IDK if it was designed to be forwards-compatible on purpose but it is
2020-01-23 18:04:13 <kaniini> the sha1 change could be done in a backwards compatible way.  adelie has used sha256 for over a year.
2020-01-23 18:04:34 <reidrankin> specifically, all the signatures prepended to the file are processed until one that is acceptable is matched
2020-01-23 18:04:37 <fabled> kaniini, the package signature is upstreamed and works. i'm talking about the index having sha1
2020-01-23 18:05:15 <kaniini> fabled: i am just very concerned that we are going to wind up with an rpm4 vs rpm5 situation, where apk consumers stick with current apk and ignore apk3
2020-01-23 18:05:52 <reidrankin> so you can prepend any kind of new signature you want and it'll just be skipped
2020-01-23 18:06:29 <fabled> reidrankin, it breaks the solver in subtle ways
2020-01-23 18:07:25 <fabled> well - those are probably corner cases. but anyway... the reusing the package sha1 as package unique id was a design mistake
2020-01-23 18:07:50 <reidrankin> I don't think the index using sha1 is a breaking change: there's a two-byte prefix "Q1" on the sha1 hashes, "Q" means base64 rather than hexdump but "1" seems to be usable as an algorithm specifier
2020-01-23 18:09:40 <ddevault> SHA-1 for package identity is not a big deal
2020-01-23 18:09:47 <ddevault> so long as it's not the basis of the signatures
2020-01-23 18:09:52 <fabled> ddevault, it is also the signature
2020-01-23 18:10:02 <ddevault> I know, but from my reading of the gitlab issue the two can be solved separately
2020-01-23 18:10:07 <ddevault> the signature one being easier
2020-01-23 18:10:47 <fabled> ddevault, if index is used, the index sha1 is used instead of the per-package signature
2020-01-23 18:11:05 <fabled> though, it probably would make sense to change that
2020-01-23 18:12:19 <fabled> ddevault, your comment is incorrect. it is used to verify authenticity currently
2020-01-23 18:12:29 <fabled> which makes it even more broken
2020-01-23 18:12:46 <ddevault> please correct/clarify in the ticket
2020-01-23 18:14:31 <reidrankin> I have that fixed too; if APK_SIGN_VERIFY_IDENTITY is used, the hash type of the identity passed in is used instead of the default
2020-01-23 18:15:38 <fabled> no, that's not where I want to go.
2020-01-23 18:15:39 <reidrankin> fabled: anyhow, I think part of the problem is that we're overloading the term "apk format"
2020-01-23 18:16:10 <fabled> reidrankin, if we fix the current format, we should drop the "verify identity" and always check signature
2020-01-23 18:16:43 <fabled> and make the identity hash a true unqiue id
2020-01-23 18:16:50 <reidrankin> what happens if you install an unsigned apk?
2020-01-23 18:17:05 <kaniini> --allow-untrusted
2020-01-23 18:17:18 <reidrankin> right, but what goes in the db for that
2020-01-23 18:17:33 <fabled> db does not currently contain signatures
2020-01-23 18:17:46 <fabled> or you mean index?
2020-01-23 18:17:53 <fabled> we can still calculate an unique id for it
2020-01-23 18:18:22 <reidrankin> ok, help me out here for a sec
2020-01-23 18:18:45 <reidrankin> we've got so many things that apk_tar_parse is used for, and I want to make sure I understand
2020-01-23 18:19:17 <reidrankin> first there's the general container format: multiple .tar.gz chunks
2020-01-23 18:20:01 <reidrankin> apk files have zero or more signature chunks, which are tarballs containing only files starting with '.SIGN.'
2020-01-23 18:20:53 <reidrankin> followed by zero or one control chunks, which contain a file called '.PKGINFO', which contains the sha256 of the data section
2020-01-23 18:21:04 <reidrankin> and the data section is everything else
2020-01-23 18:21:09 <fabled> ddevault, ^ the above is reason why the format needs to change. yes, it was built to be easy to be viewed with tar; but in real life it's very difficult to validate and parse properly. the CVEs all relate to the subtle issues the "clever hack" we did brought, or the tar complexities.
2020-01-23 18:21:16 <fabled> reidrankin, yes
2020-01-23 18:21:31 <ddevault> yeah that's a dumb format
2020-01-23 18:21:38 <ddevault> but can be fixed without dropping tar
2020-01-23 18:21:52 <ddevault> one trivial fix is detaching the signature from the package file, like arch does
2020-01-23 18:21:55 <ddevault> but there are other options, too
2020-01-23 18:22:31 <reidrankin> with the caveat that if the control section does not contain a "datahash" line, it's hashed as part of the data section
2020-01-23 18:22:33 <fabled> ddevault, it's not just the packages signature. what I need is a signed manifest also. so the system db can be used to do secure audit
2020-01-23 18:22:49 <ddevault> can you clarify what the "manifest" refers to
2020-01-23 18:23:04 <ddevault> I can guess, but it's better not to
2020-01-23 18:23:09 <fabled> ddevault, manifest = list of files, their hashes, etc. everything except the file data contents
2020-01-23 18:23:36 <ddevault> signing the whole tarball signs those details too
2020-01-23 18:23:46 <ddevault> but I understand what you're getting at
2020-01-23 18:23:54 <fabled> so you did not read my original mai
2020-01-23 18:23:55 <reidrankin> we use that general container format for several things: apks themselves, APKINDEXes, and scripts.tar
2020-01-23 18:23:55 <fabled> mail
2020-01-23 18:24:01 <ddevault> I did read your original mail
2020-01-23 18:24:08 <ddevault> and have re-read the entire thread twice today
2020-01-23 18:24:49 <fabled> ddevault, what I need, is "apk audit" to be able to do full system audit and be able to say "yes, all files match those in packages" based on the installed-db which does not contain the file data
2020-01-23 18:25:17 <reidrankin> apks typically contain a signature, control section with datahash element, and data section
2020-01-23 18:25:23 <ddevault> you're going to have to checksum the file contents to do that, right
2020-01-23 18:25:32 <ddevault> unless you're just verifying that all of the files are where they're supposed to be
2020-01-23 18:25:38 <fabled> ddevault, manifest contains individual file checksums
2020-01-23 18:25:49 <ddevault> aye, and to verify the manifest matches reality you'll have to read and checksum individual files
2020-01-23 18:25:51 <ddevault> correct?
2020-01-23 18:26:07 <fabled> yes
2020-01-23 18:26:21 <reidrankin> APKINDEXes contain a signature section and a data section only
2020-01-23 18:26:22 <fabled> but i cannot regenerate the tarball from system
2020-01-23 18:26:27 <ddevault> why's that?
2020-01-23 18:26:36 <reidrankin> ddevault: compression
2020-01-23 18:26:46 <ddevault> you should sign the uncompressed tarball, naturally
2020-01-23 18:27:13 <fabled> it does not give me enough precision on what mismatched
2020-01-23 18:27:22 <ddevault> what information is missing?
2020-01-23 18:27:23 <fabled> and i cannot then verify individual files
2020-01-23 18:27:38 <ddevault> the latter is a good point
2020-01-23 18:28:06 <fabled> also, there are elements in the tar header that are specific to what tar implementation created it
2020-01-23 18:28:17 <ddevault> 
ACTION shrugs

2020-01-23 18:28:22 <ddevault> we can assume that implementation is always apk
2020-01-23 18:28:28 <reidrankin> scripts.tar contains no signature or control section (essentially just a bare tarball)
2020-01-23 18:28:32 <kaniini> there are good points for all of it, but the question is how to proceed
2020-01-23 18:28:42 <ddevault> I don't think it's reasonable to suggest tar can be used to _create_ apks
2020-01-23 18:28:50 <kaniini> and this is a weak point about alpine in general
2020-01-23 18:28:51 <reidrankin> fabled: I have a grand master plan (TM) I've been thinking about
2020-01-23 18:28:53 <kaniini> we just do things
2020-01-23 18:29:00 <kaniini> we don't sit down and think them through before executing
2020-01-23 18:29:22 <kaniini> while we have had some wins doing this, we have had a lot of lossage too
2020-01-23 18:29:27 <reidrankin> I'm designing a high-assurance embedded system and have basically the same set of requirements
2020-01-23 18:29:49 <reidrankin> with the caveat that the whole thing needs to be checked on boot
2020-01-23 18:30:04 <fabled> reidrankin, i kinda have the same requirement
2020-01-23 18:30:14 <kaniini> (i have the same requirement as well)
2020-01-23 18:30:15 <fabled> i want to do full system audit from initramfs
2020-01-23 18:30:35 <reidrankin> step #1: we replace the PKGINFO file with something new
2020-01-23 18:30:39 <kaniini> (i also have the requirement that i do not break any production systems with a package management fumble)
2020-01-23 18:30:39 <reidrankin> probably binary
2020-01-23 18:30:43 <ddevault> I have a half written email for the list
2020-01-23 18:30:56 <ddevault> but I'm tired of updating my draft during ongoing discussions here
2020-01-23 18:31:06 <ddevault> lemme just post the relevant bits here:
2020-01-23 18:31:16 <reidrankin> something with a manifest embedded in it, instead of the checksums being inside the data tarball like today
2020-01-23 18:31:17 <ddevault> https://paste.sr.ht/~sircmpwn/57850c03604122a115ba54837fd952dbda47b885
2020-01-23 18:32:28 <ddevault> don't answer the second question, I understand why you want this but don't entirely agree that it has to be accomplished in a way that has the design implications you suggest
2020-01-23 18:32:29 <reidrankin> step #2: have the checksums be sha256 merkle hashes
2020-01-23 18:33:57 <reidrankin> specifically, hashes compatible with fs-verity or dm-verity
2020-01-23 18:34:39 <reidrankin> step #3: change the way APKs are stored in the cache
2020-01-23 18:35:28 <reidrankin> decompressing the control block doesn't really add much overhead, so that part's fine
2020-01-23 18:36:02 <reidrankin> but it would be really nice if you could have your install of APK pre-decompress the data section
2020-01-23 18:36:51 <reidrankin> which would mean you need a datahash of the raw data section instead of the gzipped version to be able to verify it
2020-01-23 18:37:21 <reidrankin> step #4: add some logic to apk_tar_parse to handle "exploded" APK files
2020-01-23 18:38:35 <reidrankin> i'm thinking directories containing numbered files, where the concatenation of the files equals the original APK with a decompressed data section
2020-01-23 18:39:44 <reidrankin> step #5: use the exploded APKs as a hardlink farm
2020-01-23 18:41:39 <reidrankin> then you can, optionally of course, turn on fs-verity for all the individual bits, so checking their hash would be an O(1) operation
2020-01-23 18:43:02 <reidrankin> an audit would consist of checking the db for the manifests for each tar file and then using a single ioctl to verify the hash of each file
2020-01-23 18:44:25 <reidrankin> obviously fs-verity itself would need to be completely optional, but implementing its hash as a standard userspace-only sequential hash is a trivial matter
2020-01-23 18:45:49 <reidrankin> In my particular use case, I'll be using the run-from-ram option, so all the packages will need to be installed on every boot.
2020-01-23 18:46:38 <reidrankin> Exploded APKs with merkle checksums will make that very, very fast
2020-01-23 18:47:32 <reidrankin> you start with an overlayfs instance with metacopy=on,index=on,redirect_dir=on
2020-01-23 18:48:07 <reidrankin> with the cache as the lower directory and a blank tmpfs as the upper
2020-01-23 18:49:07 <ddevault> reidrankin: this is good stuff, but can you write it up for the mailing list instead of IRC braindump?
2020-01-23 18:49:31 <reidrankin> ddevault: yeah, i really didn't realize how long this would go
2020-01-23 18:50:16 <fabled> that sounds like a completely new feature to me
2020-01-23 18:50:36 <ddevault> it seems to me like an alternative approach to what is already a large redesign
2020-01-23 18:51:01 <reidrankin> when installing a package, rather than copying the relevant section of the exploded apk over to the overlay, you make a hardlink, which overlayfs will handle
2020-01-23 18:51:23 <ddevault> I would rather not involve overlayfs for the general (i.e. sys install to disk) case
2020-01-23 18:51:37 <fabled> no, it's a new feature. making some repository of extracted APKs and being able to do containers/or overlayfs things out of those via hardlinks
2020-01-23 18:52:31 <ddevault> well, he lost me at that point too
2020-01-23 18:52:44 <ddevault> but leveraging fs-verify for authenticity checks seems like a good idea to me
2020-01-23 18:52:54 <fabled> it's not global
2020-01-23 18:52:57 <ddevault> and it keeps tar!
2020-01-23 18:52:59 <ddevault> global in what sense
2020-01-23 18:53:02 <reidrankin> it totally is a new feature. probably several, but that bit is just the motivation
2020-01-23 18:53:03 <fabled> but yes, IMA is also something i've been looking at
2020-01-23 18:53:08 <kaniini> i mean
2020-01-23 18:53:10 <kaniini> don't get me wrong
2020-01-23 18:53:12 <fabled> have some sort of integration for that
2020-01-23 18:53:15 <kaniini> if we are doing a massive overhaul
2020-01-23 18:53:21 <kaniini> i would love to get rid of tar
2020-01-23 18:53:42 <kaniini> my question is
2020-01-23 18:53:50 <kaniini> whether a massive overhaul is a good idea or not
2020-01-23 18:53:58 <ddevault> it's not
2020-01-23 18:54:12 <kaniini> because a massive overhaul greatly increases the odds of a "4 AM phone call"
2020-01-23 18:54:13 <ddevault> but imo there's an incremental approach to improvements which can be shaken out of reidrankin's ideas
2020-01-23 18:54:17 <kaniini> and i get enough of those already
2020-01-23 18:55:13 <fabled> ddevault, please submit alternative design that supports post-mortem security audit using asymmetric crypto
2020-01-23 18:55:45 <ddevault> can you write up a succinct list of requirements any design ought to fulfill
2020-01-23 18:55:46 <fabled> and improves performance to scale to 100k packages
2020-01-23 18:55:50 <reidrankin> yeah, that was poorly put, but what I was trying to say was that all that stuff can be done with incremental, probably backwards-compatible changes
2020-01-23 18:55:56 <ddevault> rather than scattered throughout mailing list archives and IRC logs
2020-01-23 18:56:20 <ddevault> and gitlab issues!
2020-01-23 18:57:11 <ddevault> such requirements will be good for (1) demonstrating that apk today does not meet them and (2) proving your own design protocol does
2020-01-23 18:59:02 <reidrankin> fabled is right IMHO that we need individual file checksums stored in a manifest that can be easily added to the local database, probably verbatim
2020-01-23 18:59:26 <reidrankin> then the whole DB can be signed over
2020-01-23 19:00:46 <reidrankin> (presumably, the DB would be signed over by a per-host key, and the manifests it contains would be signed by the package author)
2020-01-23 19:01:28 <fabled> reidrankin, i'd like the DB to be just concatenation of signed-PKG manifests
2020-01-23 19:01:40 <reidrankin> that would be ideal
2020-01-23 19:02:12 <fabled> but it is true that most of the issues are solved by just fixing the index format
2020-01-23 19:02:37 <fabled> the package format changes are to reduce attack surface
2020-01-23 19:02:46 <fabled> and to reduce duplicate information inside it
2020-01-23 19:02:52 <reidrankin> I envision a largely-similar APK format, with the PKGINFO file (or alternative v3 thing) being a binary magical thingimabob
2020-01-23 19:03:57 <fabled> the .tar.gz concatenation has following issues for me:
2020-01-23 19:04:03 <fabled>  1. parsing it is fragile
2020-01-23 19:04:18 <fabled>  2. signature checking is done late and lot of code needs to be run before signature is checked
2020-01-23 19:04:42 <fabled>  3. tar headers duplicate manifest data
2020-01-23 19:04:57 <fabled>  4. tar format for certain constructs is complicated (e.g. long file names)
2020-01-23 19:05:21 <fabled> all of the above have caused major issues in the past
2020-01-23 19:05:30 <fabled> and the code that handles that is fragile
2020-01-23 19:06:20 <fabled> ddevault, is the only reason you want tar format for the reason that you want to examine the package with tar?
2020-01-23 19:06:30 <fabled> what kind of things you look in it?
2020-01-23 19:06:36 <kaniini> the concern isn't the tar format
2020-01-23 19:06:44 <kaniini> the concern is that we are doing too much at one time
2020-01-23 19:06:47 <ddevault> ^
2020-01-23 19:07:01 <kaniini> why not have a release where we have the new index format with current APKv2 packages
2020-01-23 19:07:07 <ddevault> and more specifically, I think that NIH has to be well justified
2020-01-23 19:07:12 <ddevault> if tar is suitable, tar should be used
2020-01-23 19:07:32 <fabled> ddevault, it's not a tar. it's a "clever hack" that looks like tar currently
2020-01-23 19:07:33 <kaniini> and yes, fabled, sure, you've written most of apk-tools, but i think i have done some good work in apk-tools as well
2020-01-23 19:07:36 <reidrankin> for point 3 there, i'd argue that the tar shouldn't contain the data the manifest does
2020-01-23 19:07:59 <kaniini> and yes, fabled is right, apks are not really tars
2020-01-23 19:08:01 <reidrankin> s/data the/data if the/
2020-01-23 19:08:01 <alpine-meetbot> reidrankin meant to say: for point 3 there, i'd argue that the tar shouldn't contain the data if the manifest does
2020-01-23 19:08:15 <kaniini> they just happen to be kind of readable by tar utility
2020-01-23 19:08:26 <fabled> reidrankin, manifest needs to have all the meta data. so does the tar-header. otherwise tar will not read it properly.
2020-01-23 19:08:27 <ddevault> aye, I understand the current format
2020-01-23 19:09:17 <kaniini> all i am saying is this
2020-01-23 19:09:21 <ddevault> are there any distros who aren't using tar or cpio for their packages? out of curiosity
2020-01-23 19:09:24 <ddevault> is there prior art we can look at
2020-01-23 19:09:28 <reidrankin> are you talking about the pax block specifically? or are you saying that the manifest should contain xattrs and such?
2020-01-23 19:09:34 <reidrankin> I love CPIO honestly
2020-01-23 19:09:45 <kaniini> ddevault: yes.  the proposed format is quite similar to Conary's changeset format
2020-01-23 19:10:02 <kaniini> it is a good format
2020-01-23 19:10:07 <kaniini> i just think
2020-01-23 19:10:14 <kaniini> we have to support APKv2 packages anyway for upgrade
2020-01-23 19:10:20 <kaniini> like, period
2020-01-23 19:10:38 <ddevault> and therefore reusing the code if possible is wise?
2020-01-23 19:10:50 <fabled> yes, APKv2 backwards compatibility for a release or two is something I hope to do
2020-01-23 19:11:13 <kaniini> it's not "something i hope to do", it's "alpine cannot even use apk3 if it cannot upgrade to apk3 in a clean way"
2020-01-23 19:11:24 <kaniini> there are millions of installs out there
2020-01-23 19:11:36 <kaniini> possibly billions
2020-01-23 19:11:43 <kaniini> with docker, who honestly knows
2020-01-23 19:12:04 <fabled> let me rephrase
2020-01-23 19:12:05 <kaniini> what we do know is alpine is one of the widest installed linux distributions in some way or another
2020-01-23 19:12:06 <ddevault> at a minimum we should maintian backwards compatibility to support upgrades from $last_supported_release -1
2020-01-23 19:12:33 <kaniini> and really the concern is
2020-01-23 19:12:37 <kaniini> okay, we're talking about a new format
2020-01-23 19:12:43 <kaniini> but we're not talking about logistics
2020-01-23 19:12:44 <fabled> my plan is that APKv2 package format would be readable, indexable and installable; but with certain limitations
2020-01-23 19:13:03 <kaniini> how do we upgrade from apk to apk3, what are the risks, how do we mitigate the risks
2020-01-23 19:13:21 <fabled> APKv2 index format I'm not sure if it can be supported or not. perhaps it could be supported also to some extent
2020-01-23 19:17:55 <kaniini> i don't think APKv2 index needs to be supported
2020-01-23 19:18:07 <kaniini> but we need to be able to have APKv2 packages described with an APKv3 index
2020-01-23 19:18:20 <kaniini> then we have an APKv2 index beside it that describes the APKv2 packages
2020-01-23 19:18:30 <kaniini> then, later, we move to APKv3 packages
2020-01-23 19:18:30 <reidrankin> I gotta go eat something. I'd love to take the time to think this all out more thoroughly in an email, but should I prioritize that or #10670/#10671 fixes I'm almost done with?
2020-01-23 19:19:00 <reidrankin> (...i must not be using the right synax)
2020-01-23 19:19:32 <fabled> !10670
2020-01-23 19:19:45 <reidrankin> they're in apk-tools
2020-01-23 19:20:00 <fabled> ah
2020-01-23 19:20:05 <kaniini> and my concern is largely this: you rolled out a good email explaining why apk3 needs to happen.  nobody disagrees with the fact that apk3 needs to happen.  the concern is that we haven't done any real discussion about getting from where we are now to where we are in the future
2020-01-23 19:20:18 <kaniini> and by the way, thank you for writing those emails
2020-01-23 19:20:36 <ddevault> aye, these problems are important and I'm grateful that fabled is working on them
2020-01-23 19:21:14 <fabled> i'm happy i finally have the opportunity. this has been ~5 yrs on the table
2020-01-23 19:21:26 <fabled> and i'm very happy to talk more about it and adjust design as needed
2020-01-23 19:21:31 <fabled> but i'd really like to reason it
2020-01-23 19:21:52 <fabled> i'm happy to explain every suggestion i made if needed
2020-01-23 19:22:07 <kaniini> well, really, the problem isn't the design
2020-01-23 19:22:09 <fabled> i just hope that if you have suggestions you also argument it
2020-01-23 19:22:12 <reidrankin> me too; also I want to add that I only got into the alpine-devel scene like Monday, but I'm sorry I haven't engaged on this earlier
2020-01-23 19:22:18 <kaniini> the problem is the lack of a migration plan :p
2020-01-23 19:22:25 <reidrankin> wasn't really on my radar at all
2020-01-23 19:22:37 <fabled> i sort of have migration plan. i just have gotten publishing it :P
2020-01-23 19:22:38 <ddevault> my primary concerns are (1) a conservative, low-risk changes which can be achieved incrementally, and (2) a plan to get there
2020-01-23 19:22:44 <fabled> not sure if it's perfect, or good enough
2020-01-23 19:22:44 <kaniini> you want to aim for apk3 in next release, but we have to figure out how to actually make apk upgrade -Ua work
2020-01-23 19:22:45 <kaniini> :P
2020-01-23 19:23:04 <ddevault> right now it's structured like it'll be a big major change all in one lump sum, which is high-risk/liberal
2020-01-23 19:23:35 <fabled> i've been currently trying to describe where i want to end up
2020-01-23 19:23:48 <ddevault> and, it also raises the bar for proving the new design
2020-01-23 19:23:58 <fabled> it's multiple commits. but not sure how many releases
2020-01-23 19:24:06 <ddevault> if the upgrade can be described as small changes, we can prove each small change out and adjust course at any step
2020-01-23 19:24:28 <ddevault> if it's one lump sum, the whole house of cards could fall apart if anything proves to be wrong
2020-01-23 19:24:42 <ddevault> and obtaining proof of the design requires the crucible of production
2020-01-23 19:25:12 <fabled> but i'm also trying to avoid interim file formats
2020-01-23 19:25:18 <kaniini> fabled: anyway, i did ask for an apk-tools list to be made for apk-tools a while ago, so that apk-tools development could be discussed amongst apk-tools stakeholders (e.g. the distributions using apk-tools)
2020-01-23 19:25:19 <fabled> supporting X+1 fileformats is not good either
2020-01-23 19:25:34 <kaniini> i think we need to support X+1 file formats for package, but not index
2020-01-23 19:25:55 <kaniini> because in an upgrade
2020-01-23 19:25:56 <fabled> supporting 2 is ok: APKv2 and APKv3. not sure if doing more than that is good
2020-01-23 19:26:05 <kaniini> that's all we need
2020-01-23 19:26:14 <kaniini> if anyone wants to go from APKv1 to APKv3, they are already doomed
2020-01-23 19:26:50 <kaniini> there's a few ways we can do it
2020-01-23 19:27:02 <kaniini> i can write another email covering those approaches and their  pros/cons
2020-01-23 19:27:09 <kaniini> i have given it some thought
2020-01-23 19:27:19 <fabled> me too
2020-01-23 19:27:20 <ddevault> do you want me to provision an apk-tools list?
2020-01-23 19:27:48 <kaniini> we have one already
2020-01-23 19:28:01 <ddevault> oh, and there it is
2020-01-23 19:28:01 <kaniini> we just don't use it because most users are also on alpine-devel
2020-01-23 19:28:14 <kaniini> because, adelie while not directly related to alpine, does share some APKBUILDs
2020-01-23 19:28:22 <kaniini> and some other things
2020-01-23 19:28:33 <kaniini> same with abyss
2020-01-23 19:28:57 <kaniini> the real question mark is yocto (who want to replace opkg with apk, i guess)
2020-01-23 19:29:07 <ddevault> we could Cc both
2020-01-23 19:29:18 <fabled> look at that. maybe i should subscribe too
2020-01-23 19:29:38 <kaniini> i think i told you about it, but maybe i forgot to
2020-01-23 19:30:13 <fabled> maybe i was. i was pretty distracted most of last year
2020-01-23 19:30:16 <kaniini> one of my goals was to ensure apk was a top-level project that could have contributions from all distros using it
2020-01-23 19:31:42 <fabled> reidrankin, up to you to prioritize. but I think the fix for using sha1 overall might need a bit of discussion. as said earlier, i don't want to put sha256 to the current index
2020-01-23 19:32:42 <kaniini> i think
2020-01-23 19:32:49 <kaniini> we should just let the current index be as it is
2020-01-23 19:32:52 <fabled> reidrankin, and whatever we do with that is going to have some user facing changes. so i'm not sure how fast it can be pushed
2020-01-23 19:32:54 <kaniini> and focus on APKv3 index first
2020-01-23 19:33:46 <kaniini> s/first/instad/
2020-01-23 19:33:46 <alpine-meetbot> kaniini meant to say: and focus on APKv3 index instad
2020-01-23 19:33:51 <kaniini> s/instad/instead/
2020-01-23 19:33:51 <alpine-meetbot> kaniini meant to say: and focus on APKv3 index instead
2020-01-23 19:36:54 <fabled> maybe that's better approach. i was planning to do new pkg format first. but doing the indexing + updating codebase for the new index might be better approach. and give a lesson what needs to be in the package format
2020-01-23 19:37:43 <kaniini> yes, i think so
2020-01-23 19:37:51 <fabled> and the changes to use the new index internally are somewhat extensive. even if mostly mechanical.
2020-01-23 19:37:55 <kaniini> because what we can do
2020-01-23 19:38:01 <kaniini> is run both index formats parallel
2020-01-23 19:38:13 <kaniini> and that gives us a safe escape hatch
2020-01-23 19:38:17 <kaniini> if something goes south :)
2020-01-23 19:39:28 <fabled> system DB needs to be converted too
2020-01-23 19:40:05 <fabled> ok
2020-01-23 19:40:08 <fabled> i need to go sleep
2020-01-23 19:40:12 <kaniini> yes, but in a revert situation we just write a tool to convert it back
2020-01-23 19:40:21 <fabled> true
2020-01-23 19:40:29 <fabled> ok. let's follow up on mailing list
2020-01-23 19:41:00 <fabled> maybe even summarize what was discussed here
2020-01-23 19:41:14 <fabled> i will also write something tomorrow
2020-01-23 19:41:22 <fabled> perhaps try to formulate a bit of roadmap
2020-01-23 19:42:21 <fabled> thanks for this discussion!
2020-01-23 19:42:55 <fabled> reidrankin, if you have fix for the manifest issue, I'd be happy to look at it tm
2020-01-23 19:46:33 <kaniini> fabled: i am writing an email about it already
2020-01-23 19:46:42 <kaniini> fabled: feel free to chime in tomorrow with your thoughts
2020-01-23 19:47:03 <kaniini> and thanks for the conversation, i think we have fleshed out a lot
2020-01-23 19:47:57 <Cogitri> Sorry to break into a discussion about the file format with this, but what how's the status for people wanting to use libapk?
2020-01-23 19:48:27 <Cogitri> There's interest to use it to integrate APK into frontends such a GNOME Software and KDE Discover for devices like the PinePhone
2020-01-23 19:48:43 <kaniini> please write to ~alpine/apk-tools@lists.alpjnelinux.org and we can look into that
2020-01-23 19:48:55 <Cogitri> But most of the convenience functions like apk_repository_update are in apk and not libapk
2020-01-23 19:49:23 <Cogitri> Hmmm, sure, but I'm not a great email writer so I suppose a "Hey, I wanna use libapk, how about that?" is about the content of the email
2020-01-23 20:06:01 <_ikke_> kaniini: is there a reason the thread is broken for the "Let's talk.." topic?
2020-01-23 20:06:12 <kaniini> i sent a new one
2020-01-23 20:06:16 <kaniini> to apk-tools list as well
2020-01-23 20:06:57 <_ikke_> hmm, I just subscribed to the apk-tools list, but did not receive that one
2020-01-23 20:08:05 <kaniini> https://lists.alpinelinux.org/~alpine/apk-tools/%3C43397dfce7287c7ea51d04ba0d47d81c%40dereferenced.org%3E
2020-01-23 20:08:06 <kaniini> its there
2020-01-23 20:08:08 <kaniini> :p
2020-01-23 20:08:11 <_ikke_> yes, I saw it
2020-01-23 20:08:23 <_ikke_> just wondering why I did not receive it
2020-01-23 20:19:09 <ddevault> for my part I received that email 4 times
2020-01-23 20:20:12 <mps> and I two times though I'm subscribed only to alpine-devel
2020-01-23 20:21:00 <_ikke_> I *did* receive it 3 times
2020-01-23 20:21:22 <mps> ah, looks like two version is sent
2020-01-23 20:21:34 <_ikke_> so I did receive it, just in the wrong folder
2020-01-23 20:21:36 <mps> s/is/are/
2020-01-23 20:21:36 <alpine-meetbot> mps meant to say: ah, looks like two version are sent
2020-01-23 20:41:38 <Cogitri> ddevault: I don't really know mail servers but are you sure yours is setup correctly? All of your mail goes into spam for me while the rest of the thread goes into my inbox
2020-01-23 20:41:50 <ddevault> who is your email provider, Cogitri?
2020-01-23 20:41:57 <ddevault> and can you forward to me one of the emails which ended up in spam?
2020-01-23 20:42:07 <Cogitri> I use ProtonMail
2020-01-23 20:42:42 <_ikke_> I've never found alpines mailing list posts in my spam folder
2020-01-23 20:43:39 <kaniini> I find them in there occasionally.  I use migadu
2020-01-23 20:45:14 <Cogitri> Ah, nevermind, I was once mailbombed and ProtonMail switched my account into save mode (tagging everything that came in as spam so I could use my email somewhat) and it seems like I got an email from ddevault during that time
2020-01-23 20:45:17 <Cogitri> Sorry about that
2020-01-23 20:45:34 <Cogitri> Thought I had dealt with the fallout of that by now
2020-01-23 20:45:37 <kaniini> yeah I originally sent email to user list
2020-01-23 20:45:43 <kaniini> by mistake
2020-01-23 20:45:51 <kaniini> because trying to juggle different tasks today
2020-01-23 20:48:43 <_ikke_> ah, you sent the mail to both lists
2020-01-23 20:49:33 <_ikke_> I should look at list-id to filter these
2020-01-23 20:54:58 <_ikke_> rnalrd: fyi, the upcoming zabbix 4.4.5 fixed the issue with zabbix agent2
2020-01-23 21:42:21 <clandmeter> did i miss something?
2020-01-23 21:43:53 <_ikke_> regarding what?
2020-01-23 21:44:06 <clandmeter> half k backlog :)
2020-01-23 21:44:43 <_ikke_> hehe
2020-01-23 21:44:54 <_ikke_> big discussion about apk-3
2020-01-23 21:45:08 <clandmeter> yeah
2020-01-23 21:46:09 <_ikke_> conclusion: some are wary about big changes, but changes are needed to make it future proof. Plan forward is to make sure both old and new versions of apk can be used side-by-side for a while
2020-01-23 21:47:39 <clandmeter> looks like the biggest difference is that its now planned to first do the index.
2020-01-23 21:48:46 <clandmeter> compared to fabled initial email
2020-01-23 22:10:38 <reidrankin> ok, apk-tools MRs !12, !13, and !14 are up for your perusal, fixing #10670 and #10671. I just upgraded my alpine dev box from system from 3.11.2 to 3.11.3 with this build and it worked fine, but more testing would be appreciated.
2020-01-23 22:11:44 <reidrankin> (anybody know how to set the repo for algitbot references?)
2020-01-23 22:11:57 <clandmeter> i dont think its possible
2020-01-23 22:12:39 <reidrankin> that's it then, we gotta change over to a monorepo
2020-01-23 22:15:31 <clandmeter> or just fix the bot
2020-01-23 22:15:51 <clandmeter> in redmine all issues were global
2020-01-23 22:21:28 <reidrankin> same in VSTS
2020-01-23 22:44:02 <PureTryOut[m]> Could somebody please review !2125?
2020-01-23 22:48:56 <Cogitri> Oh huh, somehow I missed that one completely
2020-01-23 22:49:00 <Cogitri> Sorry about that
2020-01-23 22:49:05 <Cogitri> Gonna look into it tomorrow
2020-01-24 06:19:09 <russkel> is openBLAS/blas-dev compiled/packaged correctly? I can't seem to get passed the tests on opencv that use openblas
2020-01-24 06:19:10 <russkel> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2973#note_64649
2020-01-24 06:21:58 <russkel> That looks to be an issue from within openblas?
2020-01-24 07:27:22 <_ikke_> russkel: Maybe best to contact the maintainer of openblas
2020-01-24 08:26:20 <russkel> yeah will do, lemme see who that is
2020-01-24 08:26:36 <_ikke_> https://pkgs.alpinelinux.org/package/edge/community/x86_64/openblas
2020-01-24 08:27:09 <russkel> Isaac Dunham
2020-01-24 08:27:20 <_ikke_> https://git.alpinelinux.org/aports/tree/community/openblas/APKBUILD#n3
2020-01-24 08:34:43 <russkel> description says "with LAPACK" but uses NO_LAPACK=1 flag
2020-01-24 08:34:51 <russkel> hmm
2020-01-24 08:35:46 <_ikke_> https://git.alpinelinux.org/aports/commit/community/openblas/APKBUILD?id=bea9248fa117b5b95eb28040d66d8f068876548e
2020-01-24 08:36:32 <_ikke_> So apparently there is a separate lapack package
2020-01-24 08:37:17 <russkel> yeah I have found that, but I don't understand
2020-01-24 08:37:29 <_ikke_> Me neither :)
2020-01-24 08:38:53 <russkel> sigh, stupid fortran libraries
2020-01-24 08:40:42 <russkel> and after disabling LAPACK it looks like I am now getting fails in the MatricesAccuracyTest
2020-01-24 08:40:45 <russkel> can't win
2020-01-24 09:17:37 <rnalrd> _ikke_ nice!
2020-01-24 09:19:43 <_ikke_> I pushed 4.4.4 with agen2 disabled in 32bits arches (earlier). For 4.4.5 they can be enabled again
2020-01-24 09:31:07 <russkel> any reason why gstreamer would be having issues opening videos on the CI?
2020-01-24 09:31:57 <Cogitri> Maybe it needs a DISPLAY for that?
2020-01-24 09:32:23 <mps> anyone have objection #11158 to remove xchat
2020-01-24 09:32:23 <Cogitri> I don't have the log but maybe xvfb-run does the trick?
2020-01-24 09:34:38 <russkel> Cogitri, interesting idea, logs don't mention anything about DISPLAY hmm
2020-01-24 09:35:44 <Cogitri> It's just my best guess without logs :)
2020-01-24 09:35:49 <mps> north1: ncopa: can the #11026 be closed
2020-01-24 09:38:54 <russkel> GLib-ERROR **: 06:57:54.095: ../glib/gmem.c:105: failed to allocate 921683 bytes
2020-01-24 09:39:01 <russkel> :/
2020-01-24 09:39:38 <Cogitri> So it's OOM?
2020-01-24 09:40:55 <russkel> it could be
2020-01-24 09:41:04 <russkel> https://gitlab.alpinelinux.org/russkel/aports/-/jobs/39977
2020-01-24 09:41:56 <russkel> how much RAM does the CI have?
2020-01-24 09:42:03 <_ikke_> hmm, sigtrap
2020-01-24 09:42:46 <_ikke_> russkel: 64G :+
2020-01-24 09:42:52 <russkel> x86_64 passed this particular one
2020-01-24 09:43:18 <russkel> or at least didn't error at this point, that log is for x86
2020-01-24 09:43:20 <_ikke_> the x86_64 and x86 runner run on the same hardware
2020-01-24 09:43:35 <russkel> that's very weird
2020-01-24 09:44:28 <russkel> this is the x86_64 run: https://gitlab.alpinelinux.org/russkel/aports/-/jobs/39976
2020-01-24 09:44:41 <russkel> errors due to an error I made with packaging order
2020-01-24 09:48:22 <russkel> having said that, there's tons of errors in x86_64 WRT to gstreamer, but not enough to cause it to fail the test, oddly
2020-01-24 11:59:24 <MY-R> mps, no, xchat should be removed long time ago, in past I used xchat only because I didnt know about hexchat which working great
2020-01-24 12:04:54 <mps> MY-R: yes, also I used it long long time ago and some time used hexchat, till switched to irssi
2020-01-24 12:07:45 <MY-R> I dont care much about irc client since got znc bnc and prefer weechat from irssi if want console one :P
2020-01-24 13:09:45 <russkel> looks like gstreamer isn't finding the plugins
2020-01-24 13:20:12 <russkel> nevermind, it needed gst-libav *facepalm*
2020-01-24 14:11:16 <ncopa> russkel: been there....
2020-01-24 14:18:56 <reidrankin_> fabled: you mentioned that empty packages will ship a '.dummy' file in the root; did you mean that that's already happening, or that that's the new way of doing things?
2020-01-24 14:19:22 <reidrankin_> (I haven't seen any packages like that, but I haven't been looking...)
2020-01-24 14:20:10 <reidrankin_> also, I'm pretty sure you don't need that for sig checks to work; I assume it's triggering something else?
2020-01-24 14:28:37 <kaniini> for all intents and purpose, hexchat replaced xchat years ago :p
2020-01-24 14:32:20 <mps> kaniini: yes. but distro inertia keeps it (and not only it)
2020-01-24 14:32:44 <kaniini> i wonder if we should organize a sprint this weekend to "take out the trash" so to speak
2020-01-24 14:33:06 <kaniini> procmail, xchat, what else is in the same boat that needs to go?
2020-01-24 14:33:23 <kaniini> especially procmail.  people have literally had 19 years to switch to something else.  no sympathy.
2020-01-24 14:33:50 <mps> isn't procmail removed already?
2020-01-24 14:33:59 <kaniini> yes
2020-01-24 14:34:06 <mps> xchat is removed about 1-2 hours ago
2020-01-24 14:34:10 <kaniini> i am just saying, since there seems to be some inertia for removing crap
2020-01-24 14:34:17 <kaniini> we should identify other crap and remove it
2020-01-24 14:34:18 <mps> aha
2020-01-24 14:34:36 <kaniini> hmm
2020-01-24 14:34:49 <kaniini> gitlab MRs are not closed when imported into the repo?
2020-01-24 14:35:00 <kaniini> or am i doing it wrong
2020-01-24 14:35:03 <mps> no
2020-01-24 14:36:34 <kaniini> please tell me something is working on that :D
2020-01-24 14:36:48 <mps> yesterday I learned that it closes MR only if create MR on top of master and not creating branch
2020-01-24 14:37:29 <mps> i.e. same hash in MR and when push to aports
2020-01-24 14:38:14 <mps> but, yes, some people work hard to make this to work
2020-01-24 14:41:33 <Cogitri> Well, I suppose there's work being done for making gitlab the upstream for git so we can properly merge stuff via the UI or via the Gitlab API
2020-01-24 14:43:26 <Cogitri> Also, the sprint idea sounds good, kaniini, I'll try to find time to close more old issues which are resolved by now
2020-01-24 14:51:50 <mps> except I like outdated pkgs, of course if they don't have bugs :)
2020-01-24 14:54:06 <kaniini> unmaintained software is a significant liability
2020-01-24 14:55:17 <mps> unmaintained doesn't mean bad automatically
2020-01-24 14:55:42 <kaniini> no, but it is a potential liability
2020-01-24 14:55:59 <mps> yes
2020-01-24 14:56:13 <kaniini> procmail and xchat were liabilities, for example
2020-01-24 14:56:41 <kaniini> what i want to identify is unmaintained software which have had security incidents since last maintained
2020-01-24 14:56:49 <kaniini> so we can conclude what to do with them
2020-01-24 14:57:10 <mps> but if someone do care about it and keep in good 'shape', test it and the software doesn't have potential sec flaws then it could be kept
2020-01-24 14:57:30 <kaniini> if someone does care about it to keep it in good shape, then they should become the new upstream
2020-01-24 14:57:56 <mps> ofc, if it have non fixed sec flaws then it should be removed or moved to unmaintained
2020-01-24 14:58:29 <mps> ok, looks like we have similar POV on subject
2020-01-24 14:58:56 <kaniini> (but not python 2)
2020-01-24 14:59:02 <kaniini> (let us please just kill python 2)
2020-01-24 15:00:48 <mps> well, north1 work a lot on this, and he is not only one
2020-01-24 15:03:49 <kaniini> yes
2020-01-24 15:03:56 <kaniini> what can i do to help that along
2020-01-24 15:05:49 <mps> ask him, I don't know much about python
2020-01-24 15:06:27 <ddevault> I was working on this a lot too
2020-01-24 15:06:35 <ddevault> I drafted up a wiki page with some of the specifics
2020-01-24 15:06:44 <mps> ah, sorry I forgot your work
2020-01-24 15:06:46 <ddevault> https://wiki.alpinelinux.org/wiki/Python_package_policies
2020-01-24 15:07:23 <ddevault> lemme update this to drop the interim 2 & 3 packages policies
2020-01-24 15:07:36 <kaniini> how about this.
2020-01-24 15:07:49 <kaniini> lets try to kill python 2 this weekend
2020-01-24 15:07:51 <kaniini> :D
2020-01-24 15:08:20 <mps> I've seen a lot MRs about that but don't dare to push them because I'm not sure I can fix them if something goes wrong
2020-01-24 15:08:29 <ddevault> updated wiki page to get rid of python 2 guidelines
2020-01-24 15:08:40 <ddevault> so all packages should just follow these guidelines going forward imo
2020-01-24 15:11:22 <kaniini> Makefile:43: /src/pl/plpython/regress-python3-mangle.mk: No such file or directory
2020-01-24 15:11:24 <kaniini> hmmmmm
2020-01-24 15:23:47 <mps> looks like s390x CI is stuck again
2020-01-24 15:32:55 <kaniini> wow
2020-01-24 15:33:01 <kaniini> telegram-desktop makes gcc segfault
2020-01-24 15:33:02 <kaniini> :D
2020-01-24 15:35:09 <north1> Yep
2020-01-24 15:35:14 <north1> I have an Mr to update it
2020-01-24 15:35:20 <north1> That is stuck there
2020-01-24 15:35:39 <north1> I just don't have the willpower too do it, specially since I'm visiting Cogitri
2020-01-24 15:35:52 <north1> Too->to
2020-01-24 15:46:54 <markand> ddevault, great page! I think some content can be merge with https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python
2020-01-24 15:47:01 <ddevault> agreed
2020-01-24 15:47:14 <ddevault> but I'd prefer to merge in the other direction
2020-01-24 15:47:23 <ddevault> I think a "policies" namespace is more versatile than an examples namespace
2020-01-24 15:47:34 <markand> good idea
2020-01-24 15:52:15 <dalias> ncopa, do you want to c&p time64 discussion here for reference for others?
2020-01-24 15:52:29 <ncopa> hi dalias! i finally manage to lure you in here :)
2020-01-24 15:53:14 <ncopa> me and dalias talked about the time64 switch in #alpine-linux channel, so people interested in background can check there :)
2020-01-24 15:53:41 <ncopa> but basically, musl is fixing the y2038 problem
2020-01-24 15:53:51 <ncopa> this means that there are some breaking changes for 32 bit arches
2020-01-24 15:54:03 <ncopa> once we implement those, we may need to rebuild world
2020-01-24 15:54:41 <ncopa> and there is a number of open/unresolved issues identified by adelie (awilfox) and yocto/oe (khem)
2020-01-24 15:55:03 <ncopa> much of it is here https://wiki.adelielinux.org/wiki/Project:Time64
2020-01-24 15:55:22 <dalias> adelie has resolved enough to build everything now
2020-01-24 15:55:32 <dalias> there might be some bugs found still
2020-01-24 15:56:31 <ncopa> i wonder if we should coordinate this with the apk format change
2020-01-24 15:56:44 <ncopa> we may want rebuild everything in new format at some point
2020-01-24 15:57:56 <ncopa> hum
2020-01-24 15:58:09 <ncopa> musl 1.2 is scheduled for late january
2020-01-24 15:58:11 <mps> I follow this on #musl
2020-01-24 15:58:52 <ncopa> we need a plan how to deal with the upgrade in alpine
2020-01-24 15:59:11 <mps> I think rebuild world (offline) maybe is good idea
2020-01-24 15:59:20 <ncopa> yes, i think so too
2020-01-24 15:59:29 <ncopa> the challenge is that edge is a moving target
2020-01-24 15:59:56 <mps> true
2020-01-24 16:00:02 <ncopa> i think we will need to have a separate builder which builds it all from scratch
2020-01-24 16:00:23 <ncopa> maybe even builders for multiple arches
2020-01-24 16:00:54 <mps> what i didn't asked on musl, will we need never kernel with musl-1.2
2020-01-24 16:01:40 <ncopa> also things like xfs and ext3/4 is scary
2020-01-24 16:01:51 <mps> yes, noticed them
2020-01-24 16:04:42 <dalias> whats scary about filesystem?
2020-01-24 16:05:12 <dalias> mps, s/never/newer/ ?
2020-01-24 16:05:12 <alpine-meetbot> dalias thinks mps meant to say: what i didn't asked on musl, will we need newer kernel with musl-1.2
2020-01-24 16:05:36 <ncopa> im afraid of rebuild of fsck tools and when running it it eats up the filesystem
2020-01-24 16:05:53 <dalias> ncopa, :)
2020-01-24 16:06:45 <dalias> logically it shouldn't -- any types used in fs data structures need to be decoupled from host types anyway since they work on both 32-bit and 64-bit archs and in theory even if run on non-linux hosts
2020-01-24 16:07:07 <mps> dalias: newer, ofc :)
2020-01-24 16:07:21 <dalias> mps, ok, then no, you don't need newer kernel
2020-01-24 16:07:35 <dalias> but 5.4 lts is already in edge
2020-01-24 16:10:07 <ncopa> ok, its mostly fear, uncertainity and doubt from my side :)
2020-01-24 16:10:08 <mps> ah, yes, musl-1.2 will not be backported to older releases
2020-01-24 16:10:19 <ncopa> mps: its a challenge even for edge
2020-01-24 16:10:28 <mps> alpine releseas, I mean
2020-01-24 16:10:35 <dalias> indeed i don't see why you'd want to backport
2020-01-24 16:10:49 <dalias> you could backport bugfixes of course
2020-01-24 16:10:54 <ncopa> once its pushed to edge, we may need to rebuild world
2020-01-24 16:10:59 <ncopa> at least on 32 bit arches
2020-01-24 16:11:01 <mps> some people keep old kernels even on 3.11
2020-01-24 16:11:12 <dalias> and in theory (i mentioned this on #alpine-linux) you could even backport the binary musl package as long as musl-dev is still the old headers
2020-01-24 16:11:27 <dalias> mps, *nod*. that's fine, it will work
2020-01-24 16:11:41 <dalias> there's no change in kernel requirements with musl 1.2
2020-01-24 16:13:15 <mps> then it is better than I thought
2020-01-24 16:13:54 <ncopa> so i think the only thing we need to do is rebuild world on armv7 and x86
2020-01-24 16:14:14 <mps> I thought to start with current musl from git, but don't have much time, and will wait for official release
2020-01-24 16:14:24 <ncopa> i suppose we should set up builders for those soonish and start build from scratch
2020-01-24 16:14:40 <ncopa> maybe we should set up a builder like we do for new stable releases
2020-01-24 16:15:08 <mps> if we have resources could be good idea
2020-01-24 16:15:36 <dalias> i think it'd be useful to have an aports branch and non-production builder to do tests before switching anything over
2020-01-24 16:15:53 <dalias> altho the aports branch might not actually be needed -- the time64 fixes are pure fixes that shouldn't break non-time64
2020-01-24 16:15:54 <ncopa> the only practical (and important) difference from official builders is that it need to upload the packages to different location
2020-01-24 16:16:16 <dalias> i guess maybe there could be an aports branch just for musl package to be different
2020-01-24 16:16:20 <dalias> but that's about it
2020-01-24 16:17:56 <ncopa> i suppose we may want apply some of the patches from adeile to our git master before we start
2020-01-24 16:18:00 <ncopa> like the patch for gcc
2020-01-24 16:18:30 <mps> sure, this is first one
2020-01-24 16:18:55 <dalias> btw there's another important gcc patch you need to apply
2020-01-24 16:18:58 <dalias> wrong-codegen
2020-01-24 16:19:18 <dalias> https://wiki.adelielinux.org/wiki/Project:Time64
2020-01-24 16:19:19 <dalias> oops
2020-01-24 16:19:21 <dalias> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93402
2020-01-24 16:19:37 <dalias> mcm has the patch from the bz; final in gcc git master is same
2020-01-24 16:19:37 <mps> dalias: iiuc, this is not related to musl?
2020-01-24 16:19:42 <dalias> it's not related to musl
2020-01-24 16:19:58 <dalias> just a gcc regression since 6.x resulting in wrong codegen for struct returns
2020-01-24 16:20:10 <mps> yes, I saw it
2020-01-24 16:28:41 <ncopa> i filed https://gitlab.alpinelinux.org/alpine/aports/issues/11161 so i dont forget. Thanks!
2020-01-24 16:34:39 <mps> I'm preparing this gcc codegen patch and will test it this night
2020-01-24 17:43:43 <mps> nice, adelie linux have time64 for some packages
2020-01-24 18:39:01 <dalias> mps, "have time64" in what sense? you mean patches for the bugs found?
2020-01-24 18:39:25 <dalias> btw re: gcc codegen patch, i've tested it with mcm and it fixes the bug
2020-01-24 18:39:42 <dalias> i didn't test for any other unwanted behaviors but i trust that the gcc folks know what they're doing ;-)
2020-01-24 19:01:41 <fabled> reidrankin, the .dummy files do exists, and they are needed.
2020-01-24 19:20:37 <mps> dalias: yes, patches which fixes time64 'bugs' in packages
2020-01-24 19:22:59 <mps> dalias: I put my x86_64 builder lxc to build gcc with codegen patch, when it finish will test it
2020-01-24 19:24:57 <mps> dalias: would you mind to post your patch to some paste service (tpaste.us for example) to compare with one I made, I had to edit/trim upstream to remove two hunks about changelog
2020-01-24 20:06:18 <dalias> mps, mine in mcm is the one from the tracker rather than the final commit, so it lacks the changelog spam
2020-01-24 20:13:52 <mps> please, can you paste or post to me. I just finished build and run test but it still fails
2020-01-24 20:14:02 <dalias> what fails?
2020-01-24 20:14:15 <mps> test example.c
2020-01-24 20:14:30 <mps> build gcc 9.2 went fine
2020-01-24 20:14:48 <dalias> i posted the link on https://gitlab.alpinelinux.org/alpine/aports/issues/11161
2020-01-24 20:14:55 <dalias> the patch
2020-01-24 20:15:00 <dalias> oh sorry no
2020-01-24 20:15:04 <dalias> that was the time64 one
2020-01-24 20:15:07 <dalias> just a sec
2020-01-24 20:15:27 <mps> ok
2020-01-24 20:15:52 <dalias> https://github.com/richfelker/musl-cross-make/blob/master/patches/gcc-9.2.0/0017-pr93402.diff
2020-01-24 20:16:26 <mps> example.c from bug report fails when built with -fno-inline in my test
2020-01-24 20:19:19 <dalias> here's what i get with the patch applied: http://ix.io/28er
2020-01-24 20:19:23 <dalias> notice the addq
2020-01-24 20:20:09 <mps> aha
2020-01-24 20:20:22 <dalias> i'm not even running it or caring about inlining
2020-01-24 20:20:29 <mps> ok, looks like I 'overworked' patch
2020-01-24 20:20:31 <dalias> i was just looking at the extern function definition's asm
2020-01-24 20:20:37 <dalias> what did you do to it? :)
2020-01-24 20:20:42 <dalias> remove the actual patch body? :-p
2020-01-24 20:20:49 <dalias> and just keep the testcase?  :-p
2020-01-24 20:21:00 <mps> forgot to remove some parts
2020-01-24 20:21:49 <mps> here is it http://tpaste.us/gkjy
2020-01-24 20:23:57 <dalias> fixed ver?
2020-01-24 20:26:12 <mps> ?
2020-01-24 20:26:26 <mps> sorry, don't understand
2020-01-24 20:28:06 <reidrankin> fabled: am I wrong about the dummies being needed for sig checks, or are they there for something else?
2020-01-24 20:30:02 <mps> if I build example.c without -fno-inline it works
2020-01-24 20:30:49 <reidrankin> s/needed/not needed/
2020-01-24 20:30:49 <alpine-meetbot> reidrankin meant to say: fabled: am I wrong about the dummies being not needed for sig checks, or are they there for something else?
2020-01-24 20:33:05 <dalias> mps, what goes wrong with -fno-inline ?
2020-01-24 20:35:14 <mps> here is generated asm http://tpaste.us/evKp
2020-01-24 20:36:06 <mps> and I get: Assertion failed: output.b == 122222222222 (example.c: main: 23) \n Abort
2020-01-24 20:41:34 <mps> hm, pr93402.c is different, it works compiled with -fno-inline but fails if built with any -O tried, -Os, -O2 or -O3
2020-01-24 20:43:05 <mps> btw, I'm building it native
2020-01-24 20:43:13 <mps> x86_64
2020-01-24 20:53:36 <mps> hmm, ok going from scratch again
2020-01-24 20:58:39 <mps> huh, why the asm output from gcc doesn't have alpine gcc pkgrel :)
2020-01-24 20:59:00 <mps> I need some walk
2020-01-24 21:03:09 <ddevault> https://sr.ht/q_g8.jpg
2020-01-24 21:03:11 <ddevault> braille terminal I picked up
2020-01-24 21:07:58 <kaniini> i have one of those
2020-01-24 21:08:06 <kaniini> it belonged to my dad
2020-01-24 21:11:00 <dalias> mps, that looks like it was compiled without the patch
2020-01-24 21:11:03 <dalias> are you sure you used the new gcc?
2020-01-24 21:11:30 <mps> dalias: that is
2020-01-24 21:12:06 <mps> i wrote '21:58 ............. mps| huh, why the asm output from gcc doesn't have alpine gcc pkgrel :)'
2020-01-24 21:12:38 <mps> when I noticed that
2020-01-24 21:13:57 <mps> multitasking at work
2020-01-24 21:16:51 <dalias> mps, <mps> here is generated asm http://tpaste.us/evKp
2020-01-24 21:17:13 <dalias> so i guess you were using the wrong gcc? :)
2020-01-24 21:17:53 <mps> you are right
2020-01-24 21:18:47 <mps> but build box works again, because I deleted previous patched version, huh :)
2020-01-24 21:18:57 <mps> that's a life
2020-01-24 21:31:15 <russkel> am I doing something stupid here in the APKBUILD:
2020-01-24 21:31:17 <russkel> mv: cannot stat '/home/builder/package/pkg/opencv/usr/lib/libopencv_video*.so.*': No such file or directory
2020-01-24 21:31:32 <russkel> mv "$pkgdir/usr/lib/libopencv_video*.so.*" "$subpkgdir/usr/lib"
2020-01-24 21:33:30 <[[sroracle]]> you have to unquote the globbed part in order for it to expand
2020-01-24 21:33:39 <[[sroracle]]> otherwise it's a literal *
2020-01-24 21:38:02 <russkel> I thought that only applied for '
2020-01-24 21:38:05 <russkel> 
ACTION facepalms

2020-01-24 21:38:07 <russkel> thanks mate
2020-01-24 22:14:48 <mps> dalias: works fine
2020-01-24 22:15:19 <mps> next time I have to check did I really upgraded gcc
2020-01-24 22:15:31 <dalias> :)
2020-01-24 22:15:55 <mps> all test passed
2020-01-24 22:16:30 <mps> good thing in my mistake is that I'm sure it doesn't work with current gcc 9.2 :)
2020-01-24 22:16:33 <dalias> btw is there any way alpine could auto-check lib deps? i'm *always* hitting broken upgrades where a new version of one of the dependency libraries is needed because of silent change in symbol refs, but not recorded in the deps
2020-01-24 22:16:54 <russkel> woo opencv is compiling on x86_64 and aarch64
2020-01-24 22:17:01 <dalias> opencolorio is broken right now because of some stupid abi break in yaml-cpp
2020-01-24 22:17:11 <mps> dalias: not that I know how to do this
2020-01-24 22:17:13 <dalias> but this kind of thing happens *all the time* :(
2020-01-24 22:17:34 <russkel> and passing tests =)
2020-01-24 22:17:43 <dalias> it seems like a system with all packages present could rdep-list and ldd all of the things that depend on a package
2020-01-24 22:17:50 <dalias> and tell you if any of them broke
2020-01-24 22:18:27 <mps> so, scanelf can't find needed deps?
2020-01-24 22:18:27 <dalias> and in the other direction, i'm not sure how it would work without keeping around old libs
2020-01-24 22:19:58 <russkel> probably something that could be implemented into CI
2020-01-24 22:20:24 <dalias> mps, there are 2 problems that can happen
2020-01-24 22:20:25 <mps> we usually rebuild pkgs 'by hand' if we know for abi breaks
2020-01-24 22:20:40 <dalias> 1. B depends on A, and after upgrade of A, A no longer has symbols B needs
2020-01-24 22:20:48 <dalias> this usually happens for idiotic C++ template reasons
2020-01-24 22:21:27 <dalias> 2. B depends on A, and when upgrading B, the dependency on A is recorded, but there's a silent dependency on some minimum version of A that's not recorded
2020-01-24 22:21:41 <mps> yes
2020-01-24 22:21:43 <dalias> so when you upgrade B, B no longer works without tracking down which A it is that also needs to be manually force-upgraded
2020-01-24 22:22:13 <dalias> and then the world file gets filled up with forced installations of libraries you only needed as indirect deps
2020-01-24 22:22:20 <dalias> just to force their version bumps
2020-01-24 22:22:28 <mps> that is
2020-01-24 22:23:08 <mps> well, advice is 'upgrade all to latest version in current repo'
2020-01-24 22:23:32 <mps> though this sounds as not quite 'fine' advice
2020-01-24 22:24:44 <mps> we are trying to find abi breaks when we upgrade some important libs and pkgs but sometimes something 'slips'
2020-01-24 22:24:47 <dalias> if only there were an apk command to "upgrade B and recursively all its dependencies" without "upgrade whole dist"
2020-01-24 22:25:03 <mps> apk add -u -d
2020-01-24 22:25:06 <dalias> because the servers are so slow the latter takes forever
2020-01-24 22:25:18 <dalias> does it work? i can't even get apk add -u to work
2020-01-24 22:25:25 <dalias> if i have libfoo and libfoo-dev installed
2020-01-24 22:25:30 <dalias> apk add -u libfoo does *nothing*
2020-01-24 22:25:30 <mps> actually 'fix -d'
2020-01-24 22:25:39 <dalias> because libfoo-dev holds it back to the matching version
2020-01-24 22:25:49 <dalias> and the upgrade of libfoo doesn't push an upgrade of the libfoo-dev
2020-01-24 22:26:21 <mps> well, in most cases 'apk add -u pkgname' works
2020-01-24 22:26:37 <dalias> basically having any -dev packages installed hoses the whole apk upgrade system
2020-01-24 22:27:09 <mps> yes, in such cases i do 'apk add -u $pkgname-dev'
2020-01-24 22:28:38 <dalias> yes but then i have to find which package in the dep chain has a -dev package holding it back
2020-01-24 22:28:51 <dalias> suppose i want apk add -u appfoo
2020-01-24 22:28:59 <mps> right
2020-01-24 22:29:02 <dalias> and appfoo depends through some giant dep chain on libbar
2020-01-24 22:29:06 <dalias> and i have libbar-dev installed
2020-01-24 22:29:16 <dalias> now i have to figure out that libbar-dev is why i can't apk add -u appfoo
2020-01-24 22:29:19 <asac> o/ ... looking for instructions how to spin my own alpine port (armel without vfp basically) ... who would know best about that topic?
2020-01-24 22:29:36 <mps> 'apk info -R pkgname' could help
2020-01-24 22:30:20 <dalias> i just wish it just worked
2020-01-24 22:31:00 <mps> understand
2020-01-24 22:31:00 <dalias> i do want to stick with alpine because it looks like adelie takes more of a typical desktop-dist approach of building packages with lots of heavy deps i have no interest in having installed or consuming memory
2020-01-24 22:31:19 <mps> maybe new apk version will be better at this
2020-01-24 22:31:24 <dalias> i might try void at some point tho and see if it does better because this has just been a huge productivity killed :(
2020-01-24 22:31:32 <dalias> killer*
2020-01-24 22:31:50 <dalias> like i'll be in the middle of getting something done, need to upgrade something, then spend the rest of the day figuring out why it's not working
2020-01-24 22:32:34 <mps> you have to apply for 'Alpine developer' position :)
2020-01-24 22:32:40 <dalias> :-p
2020-01-24 22:33:04 <mps> that's how I learned some hard parts and corner cases
2020-01-24 22:34:07 <russkel> wait what, ffmpeg on 32b systems is limited to 2GB RAM?
2020-01-24 22:34:09 <mps> but back to serious, new apk will try to solve some issues
2020-01-24 22:34:47 <dalias> russkel, in what sense?
2020-01-24 22:35:12 <russkel> dalias, opencv FFMPEG tests are failing on x86 due to running out of RAM errors
2020-01-24 22:35:20 <dalias> a 32-bit process is inherently limited to at most 4gb of virtual memory space, and if the kernel is also 32-bit it's likely going to be limited to 3gb or 2gb depending on the arch
2020-01-24 22:35:22 <mps> maybe because of memory split 2/2gb
2020-01-24 22:35:29 <russkel> despite the CI has 60gb
2020-01-24 22:36:04 <mps> I thought to change kernel config to 3G/1G
2020-01-24 22:36:23 <dalias> any single allocation is also going to be limited to 2gb, even if more is available total
2020-01-24 22:37:01 <dalias> (1) because PTRDIFF_MAX is 2GB (signed), and (2) because any fragmentation of virtual address space is going to prevent making huge objects anyway
2020-01-24 22:38:11 <russkel> I see
2020-01-24 22:39:16 <mps> _ikke_: are you around?
2020-01-24 22:39:37 <russkel> ahh the test is called "videoio_ffmpeg.write_big"
2020-01-24 22:39:53 <russkel> it should really be skipping this test then
2020-01-24 22:40:05 <_ikke_> mps: yes
2020-01-24 22:40:37 <mps> sorry for disturb, how gcc-gnat can be put in CI builders
2020-01-24 22:41:21 <_ikke_> mps: can you give context? Why is it an issue?
2020-01-24 22:41:25 <mps> gcc doesn't makedepends on it but it must be installed for gcc to build
2020-01-24 22:41:31 <_ikke_> ah
2020-01-24 22:42:23 <_ikke_> I can't think right away for a good solution, would need to think about it a bit
2020-01-24 22:42:28 <mps> but I'm not in a hurry
2020-01-24 22:42:54 <mps> np, just to have this in 'back mind'
2020-01-24 22:43:12 <_ikke_> One option would be to add it to the build script, like detect that gcc is being built and install gcc-gnat
2020-01-24 22:43:53 <_ikke_> Do you know the reason it does not makedepends on gcc-gnat? Circular dependency?
2020-01-24 22:44:27 <mps> I think so
2020-01-24 22:44:39 <mps> but not sure
2020-01-24 22:45:10 <mps> gcc-gnat depends on gcc
2020-01-24 22:45:30 <_ikke_> yeah, just noticed
2020-01-24 22:46:19 <russkel> https://gitlab.alpinelinux.org/russkel/aports/-/jobs/40124#L4278
2020-01-24 22:47:14 <russkel> my instincts, while fairly untrained in these matters, is telling me the test fails, doesn't free the memory and then goes onto the next test?
2020-01-24 22:47:26 <mps> it would be wrong to add 'apk add gcc-gnat' in gcc prepare function, I think
2020-01-24 22:47:39 <russkel> well doesn't fail, but skips after hitting an exception
2020-01-24 22:47:42 <mps> but only solution I can think now
2020-01-24 22:48:15 <_ikke_> mps: yeah, I don't think that's the right solution
2020-01-24 22:49:07 <_ikke_> There would be no automatic clean-up as is with the other dependencies
2020-01-24 22:49:09 <mps> ok, maybe we will tomorrow come to some ideas about this
2020-01-24 22:49:57 <_ikke_> maybe some dedicated variable
2020-01-24 22:50:48 <mps> or create one complicated cleanup() in APKBUILD
2020-01-24 22:52:13 <_ikke_> Probably better to add it to the correct virtual package, then it would automatically be cleaned up
2020-01-24 22:52:21 <_ikke_> but still not sure that's the right way to go
2020-01-24 22:54:10 <mps> maybe ncopa have experience with this
2020-01-24 22:54:29 <_ikke_> on the builders we would manually fix this
2020-01-24 22:54:34 <_ikke_> not ideal, but it work
2020-01-24 22:54:36 <_ikke_> works
2020-01-24 22:55:17 <mps> hmm, maybe alpine-sdk should depend on gcc-gnat
2020-01-24 22:56:28 <_ikke_> That would mean it's always installed, as well for everyone who is developing for Alpine
2020-01-24 22:56:43 <mps> yes
2020-01-24 23:00:01 <mps> ok, thanks for help, going to try to fix fonts for awesome wm on one box
2020-01-24 23:00:37 <_ikke_> success!
2020-01-24 23:05:36 <russkel> Ada hmm
2020-01-24 23:07:19 <Cogitri> Let's not :P
2020-01-24 23:07:31 <_ikke_> Cogitri: I'd agree
2020-01-24 23:10:25 <russkel> is it quite often that s390x tests fail?
2020-01-24 23:10:35 <_ikke_> russkel: you mean builds?
2020-01-24 23:11:01 <russkel> build worked fine, test are failing in this case
2020-01-24 23:11:10 <_ikke_> ah, yeah, that might happen
2020-01-24 23:11:57 <russkel> ahhh common denominator is tiff on s390x
2020-01-24 23:12:20 <russkel> is it a common architecture? I don't think I heard of it before using alpine haha
2020-01-24 23:12:47 <_ikke_> It's an IBM mainframe arch
2020-01-24 23:12:57 <_ikke_> I didn't hear about it either
2020-01-24 23:12:59 <_ikke_> before
2020-01-24 23:32:19 <russkel> aww man, libtiff test failures on s390x, video io noise test failures on ppc64le, out of memory issues on x86&arm7
2020-01-24 23:32:31 <russkel> why can't we all just use x86_64 ;)
2020-01-25 01:37:44 <ddevault> just sent my first set of accessibility patches to the aports list, blindfolded :D
2020-01-25 01:42:08 <mps> ddevault: http://tpaste.us/ky77
2020-01-25 01:43:48 <ddevault> mps: can you phrase that in the form of a reply on the list
2020-01-25 01:44:12 <mps> to late, already pushed :)
2020-01-25 01:44:22 <ddevault> 
ACTION shrugs

2020-01-25 01:44:52 <ddevault> I also sent a patch for mkinitfs which turns on the braille reader during early boot
2020-01-25 01:45:02 <ddevault> https://lists.alpinelinux.org/~alpine/devel/patches/3236
2020-01-25 01:45:12 <mps> yes, I see it
2020-01-25 01:45:55 <mps> but liblouis fails on builder, fails on test
2020-01-25 01:47:50 <mps> and it passed on my local machine, strange
2020-01-25 01:48:58 <mps> some deps that i have installed probably missing in APKBUILD
2020-01-25 01:56:33 <ddevault> ack
2020-01-25 01:59:03 <mps> help2man and python
2020-01-25 01:59:33 <ddevault> eating dinner now, will send a fixup patch after that
2020-01-25 01:59:55 <mps> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/liblouis
2020-01-25 02:00:13 <mps> buon appetito
2020-01-25 02:23:21 <mps> hm, can't find why it worked on my local box and not on builders, option for now is disable check
2020-01-25 02:25:37 <ddevault> I sent a patch that adds the missing makedepends
2020-01-25 02:26:19 <mps> I see
2020-01-25 02:28:06 <mps> also fail on check
2020-01-25 02:28:15 <ddevault> bah
2020-01-25 02:28:32 <mps> I wonder why it worked on my local box
2020-01-25 02:28:45 <ddevault> let's just disable the check, then
2020-01-25 02:28:46 <ddevault> we know the package works fine
2020-01-25 02:29:13 <mps> agree
2020-01-25 02:29:30 <ddevault> patch sent
2020-01-25 02:30:02 <mps> oh, license is not SPDX compliant
2020-01-25 02:30:39 <ddevault> oh, I thought newapkbuild linted that for you
2020-01-25 02:31:16 <mps> it didn't but abuild give me warning
2020-01-25 02:32:32 <ddevault> yet another patch is out
2020-01-25 02:32:38 <ddevault> thanks for your patience and help
2020-01-25 02:36:41 <mps> np
2020-01-25 02:36:50 <mps> lets try on clean box
2020-01-25 02:37:31 <mps> btw, you don't need to bump pkgrel if it not passed official builders
2020-01-25 02:37:46 <ddevault> oh, was unsure
2020-01-25 02:39:06 <mps> np
2020-01-25 02:39:24 <mps> also I sometimes make similar mistakes
2020-01-25 02:40:13 <mps> pushed as one commit and 'amended' msg somewhat
2020-01-25 02:40:38 <ddevault> oh god that brltty issue, how did I miss that
2020-01-25 02:40:56 <ddevault> I mean, probably because I was literally blind
2020-01-25 02:41:11 <mps> really? didn't know
2020-01-25 02:41:48 <ddevault> yeah the two original commits were written blindfolded
2020-01-25 02:41:52 <mps> iirc, you told me that you are astronomer
2020-01-25 02:42:07 <ddevault> amateur astronomer
2020-01-25 02:42:16 <mps> yes, I remember
2020-01-25 02:42:37 <mps> so you are not blind, I think
2020-01-25 02:42:47 <ddevault> I was blind_folded_ while working on these packages
2020-01-25 02:43:06 <mps> ah, ok
2020-01-25 02:44:07 <ddevault> I usually dogfood things to prove that they're correct
2020-01-25 02:44:32 <ddevault> so in this case when packaging a braille display driver, I learned to read braille and then authored the commits while blindfolded and using the driver to do the work
2020-01-25 02:44:52 <ddevault> at the end of this accessibility sprint I hope to be able to do a complete alpine install blindfolded
2020-01-25 02:46:18 <mps> heh, understand now
2020-01-25 02:46:39 <mps> for someone new to 'blind world' not bad :)
2020-01-25 02:52:12 <mps> today, when you sent image of BR terminal I thought maybe I could buy one and work with closed eyes. could be good for eyes to rest them
2020-01-25 02:52:23 <ddevault> they're very expensive
2020-01-25 02:52:39 <ddevault> I got this one used, in mediocre condition, for $200, and it was a steal
2020-01-25 02:52:53 <mps> oh
2020-01-25 02:53:03 <ddevault> they'll usually run closer to 2 grand
2020-01-25 02:53:35 <mps> hm, much to dear to be blind
2020-01-25 02:54:00 <mps> s/to/too/
2020-01-25 02:54:00 <alpine-meetbot> mps meant to say: hm, much too dear to be blind
2020-01-25 03:02:13 <ddevault> there are free screen readers
2020-01-25 03:09:10 <mps> tested  locally and pushed your fixes for brltty
2020-01-25 03:10:09 <ddevault> thank you mps
2020-01-25 03:10:38 <mps> hm, ppc64le don't have 'outb'
2020-01-25 03:11:33 <mps> 'in function `readPort1': undefined reference to `inb''
2020-01-25 03:11:48 <mps> ddevault: np
2020-01-25 03:12:11 <mps> it passed all other arches
2020-01-25 03:58:31 <russkel> how long does it take to get used to reading braille?
2020-01-25 07:05:54 <_ikke_> russkel: It's almost impossible to learn at an older age, especially when you learned to write. Your fingers are no longer sensitive enough.
2020-01-25 07:08:13 <_ikke_> at least, that's what I've heard
2020-01-25 07:40:43 <_ikke_> So drew actually used the brail reader? wow
2020-01-25 07:41:47 <_ikke_> ddevault: nice commitment
2020-01-25 08:35:43 <AinNero> ddevault: does that hook into the linux vt device to read it out loud?
2020-01-25 08:37:26 <AinNero> ah, the braille outputter someone posted yesterday
2020-01-25 08:57:18 <russkel> _ikke_, interesting. I wonder what happens if you go blind at an older age
2020-01-25 08:58:45 <_ikke_> russkel: What I've heard is that not a lot of people learn to read brail. Most would use screen readers nowadays
2020-01-25 08:59:44 <russkel> window, hexchat, underscore ikke russkel what ive heard
2020-01-25 08:59:56 <_ikke_> ?
2020-01-25 09:00:15 <russkel> my impersonation of a screen reader
2020-01-25 09:00:22 <_ikke_> haha :D
2020-01-25 09:00:56 <russkel> always wondered how that works
2020-01-25 09:01:26 <russkel> I mean I understand reading text on UI, but actually making it an efficient way to use a computer
2020-01-25 09:03:11 <russkel> tons of applications for ML/AI in this space then
2020-01-25 09:03:50 <_ikke_> russkel: trained screen reader users use a very high speed
2020-01-25 09:05:02 <russkel> imagine trying to look through a 5mb CI build log to find out which test failed :/
2020-01-25 09:06:00 <_ikke_> I guess you would grep-likes a lot
2020-01-25 09:06:09 <_ikke_> s/would/would use/
2020-01-25 09:06:09 <alpine-meetbot> _ikke_ meant to say: I guess you would use grep-likes a lot
2020-01-25 10:37:35 <mps> what a long one line commit msg https://lists.alpinelinux.org/~alpine/aports/patches/3244
2020-01-25 10:42:59 <^7heo> https://pkgs.alpinelinux.org/contents?file=abuild*&path=%2Fusr%2Fshare%2Fman%2F*&name=&branch=v3.11&repo=main
2020-01-25 10:43:05 <^7heo> Is there no man for abuild at all? =/
2020-01-25 10:44:53 <^7heo> I am searching for a way to cross compile an apk
2020-01-25 10:45:13 <^7heo> not sure if it is even supported
2020-01-25 10:46:22 <mps> ^7heo: your conclusion is right
2020-01-25 10:46:41 <mps> it isn't supported
2020-01-25 10:47:01 <^7heo> mps: okay. but still, it would be great to have a man...
2020-01-25 10:47:14 <^7heo> you know, to be able to read it :P
2020-01-25 10:47:32 <mps> 'use source Luke'
2020-01-25 10:47:37 <mps> :)
2020-01-25 10:48:44 <^7heo> yeah no.
2020-01-25 10:48:50 <^7heo> if I wanted to, I'd be using gentoo.
2020-01-25 11:00:04 <_ikke_> mps: Would be nice if you could respond on the aports posts that you applied :)
2020-01-25 11:00:43 <_ikke_> mps: I noticed that as well. Same for their previous submission
2020-01-25 11:04:58 <mps> mps: would be nice if you don't 'touch' aports ML :)
2020-01-25 11:07:51 <mps> _ikke_: I would, but whenever I post anything to alpine MLs I feel irritated (you know why)
2020-01-25 11:08:29 <mps> and I want to be calm as much as possible
2020-01-25 11:09:28 <mps> btw, checking brltty build I noticed that ppc64le is missing 'inb' and 'outb'
2020-01-25 11:09:47 <_ikke_> I see
2020-01-25 11:09:56 <_ikke_> I'll reply that
2020-01-25 11:10:47 <mps> and brltty use direct I/O, i.e. inb and outb
2020-01-25 11:12:22 <nmeum> the mkinitramfs repository isn't available on gitlab, is it?
2020-01-25 11:12:53 <mps> nmeum: it is, I think, mkinitfs
2020-01-25 11:13:11 <_ikke_> I cannot find it
2020-01-25 11:13:11 <mps> yes, it is there
2020-01-25 11:13:40 <nmeum> I am too stupid to find it
2020-01-25 11:13:44 <nmeum> would you mind sharing a link?
2020-01-25 11:13:58 <_ikke_> https://gitlab.alpinelinux.org/alpine
2020-01-25 11:14:03 <_ikke_> I don't see it listed there
2020-01-25 11:14:26 <mps> hm, how I found it, can't remember
2020-01-25 11:14:40 <mps> maybe you must be logged in
2020-01-25 11:15:07 <_ikke_> You don't mean this one, right? https://gitlab.alpinelinux.org/alpine/aports/tree/master/main/mkinitfs
2020-01-25 11:15:10 <_ikke_> I'm logged in
2020-01-25 11:15:13 <mps> oh, maybe I fetched it from git.a.o
2020-01-25 11:15:23 <_ikke_> yeah, that would make sense
2020-01-25 11:15:26 <^7heo> is there a script to federate a build on multiple machines at once?
2020-01-25 11:15:35 <_ikke_> https://git.alpinelinux.org/mkinitfs/
2020-01-25 11:15:52 <_ikke_> ^7heo: distcc?
2020-01-25 11:16:11 <^7heo> i.e. distribuild $package --host x86:vmx86 --host x64:vmx64 ...
2020-01-25 11:16:28 <^7heo> _ikke_: not in that way
2020-01-25 11:16:36 <_ikke_> ^7heo: There is a desire to build something like that
2020-01-25 11:16:53 <^7heo> I dunno, how do you guys build packages for different archs?
2020-01-25 11:17:05 <^7heo> you trigger multiple abuilds and rsync the results?
2020-01-25 11:17:14 <nmeum> since mkinitfs isn't on gitlab: could anybody else take a quick look at https://tpaste.us/ObaZ ? I would push it directly if someones else takes a quick look at it
2020-01-25 11:17:26 <nmeum> minor change really...
2020-01-25 11:17:48 <_ikke_> ^7heo: we use mqtt to trigger builds, and each builder uploads the package for that arch seperately
2020-01-25 11:18:05 <^7heo> ah the builder uploads
2020-01-25 11:18:06 <_ikke_> ^7heo: we also have CI on gitlab
2020-01-25 11:18:12 <^7heo> so it's pushing, not pulling
2020-01-25 11:18:17 <_ikke_> which has runners for all the different arches
2020-01-25 11:18:22 <^7heo> yeah gotcha
2020-01-25 11:18:37 <mps> nmeum: pigz as default for gzip
2020-01-25 11:19:26 <nmeum> mps: that's what the change does, yeah. if pigz is installed it is prefered over gzip
2020-01-25 11:19:39 <nmeum> we have something similar in abuild already
2020-01-25 11:19:55 <mps> yes, nice fix
2020-01-25 11:20:40 <nmeum> really has a huge "performance" impact on my system
2020-01-25 11:20:51 <_ikke_> yes, can imagine
2020-01-25 11:20:56 <_ikke_> single core vs multicore
2020-01-25 11:20:57 <nmeum> so you are ok with me pushing it?
2020-01-25 11:21:19 <mps> if you tested it I trust you
2020-01-25 11:21:26 <_ikke_> So this is just for generating the initramfs, right?
2020-01-25 11:21:30 <nmeum> yep
2020-01-25 11:21:38 <_ikke_> So impact should be minimal
2020-01-25 11:21:47 <nmeum> yep
2020-01-25 11:21:53 <nmeum> and it's totally optional
2020-01-25 11:22:15 <_ikke_> Should be fine then, I guess
2020-01-25 11:22:19 <nmeum> ok
2020-01-25 11:22:30 <nmeum> will just do a quick reboot to ensure that it's decompressed correctly
2020-01-25 11:22:43 <nmeum> if so, I will just push it
2020-01-25 11:32:42 <nmeum> seems to work, pushed the change
2020-01-25 11:37:22 <clandmeter> ^7heo: docker-abuild can support multiple arches
2020-01-25 11:37:30 <^7heo> clandmeter: noted.
2020-01-25 11:37:35 <clandmeter> via qemu-user
2020-01-25 11:37:38 <^7heo> ok
2020-01-25 11:37:52 <clandmeter> its okish if you dont want to build world
2020-01-25 11:38:15 <clandmeter> i think there is also alpine chroot which support similar
2020-01-25 11:39:06 <^7heo> honestly
2020-01-25 11:39:13 <^7heo> I have a couple of vms in virtualbox
2020-01-25 11:39:18 <^7heo> they start headless
2020-01-25 11:39:53 <^7heo> all I have to do is provider their names to a very simple script I wrote, and it builds the stuff, and then rsync the logs and the artefacts
2020-01-25 11:40:14 <^7heo> it's very simple, very efficient, and uses parallelization (which does not do much since it's vms on a single machine - but theorically it's better)
2020-01-25 11:40:33 <^7heo> if I had better hardware it would make a diff.
2020-01-25 11:41:25 <clandmeter> have you looked at  sr.ht ci?
2020-01-25 11:41:57 <^7heo> no.
2020-01-25 11:42:01 <clandmeter> im not sure how many arches they support now, i think you can send jobs to it and even login after via ssh
2020-01-25 11:42:10 <^7heo> yeah well
2020-01-25 11:48:45 <nmeum> qemu-static really is magic, especially in combination with binfmt_misc
2020-01-25 11:53:20 <clandmeter> yes its pretty decent
2020-01-25 11:53:52 <clandmeter> i was surprised about the performance compared to system qemu
2020-01-25 12:27:39 <russkel> wait, what's the difference between system qemu and qemu-static?
2020-01-25 12:30:05 <mps> qemu-static is good to run in chroots
2020-01-25 12:32:50 <russkel> ah so it's exactly what it says on the box
2020-01-25 12:33:07 <russkel> qemu with everything statically linked
2020-01-25 12:33:30 <mps> except libc
2020-01-25 12:34:32 <mps> it doesn't emulate hardware and I presume because that it is faster
2020-01-25 12:35:07 <mps> didn't used it for few years so I forgot details
2020-01-25 12:35:21 <russkel> by hardware you mean things like ethernet etc?
2020-01-25 12:35:29 <mps> yes
2020-01-25 12:35:44 <russkel> indeed
2020-01-25 12:36:07 <russkel> I was quite impressed I was able to cross compile by running a slightly different docker command
2020-01-25 12:36:20 <mps> you can run 'qemu-arm program' on other archs for example
2020-01-25 12:37:18 <mps> again, I forgot details
2020-01-25 12:38:42 <clandmeter> qemu static as in qemu-user context, qemu-user-static
2020-01-25 12:42:23 <mps> debian have debootstrap-qemu package which can be used to create chroot for different arch
2020-01-25 12:58:05 <mps> _ikke_: did you come to idea about adding gcc-gnat to CI boxes
2020-01-25 13:02:57 <ddevault> AinNero: not yet, but that's one of my next steps
2020-01-25 13:16:04 <clandmeter> mps: you need it for gcc?
2020-01-25 13:21:11 <mps> clandmeter: yes
2020-01-25 13:22:25 <mps> I tested it locally in lxc but would like create MR to see will it pass all archs in CIs
2020-01-25 13:23:25 <clandmeter> Understand
2020-01-25 13:24:44 <^7heo> damn, alpine isn't POSIX... =/
2020-01-25 13:24:57 <^7heo> what do I have to use to have a POSIX system these days?
2020-01-25 13:25:19 <north1> Sacrifice your loved one to a volcano god
2020-01-25 13:25:34 <^7heo> I'll start with your love one as a test.
2020-01-25 13:25:39 <^7heo> loved*
2020-01-25 13:26:09 <^7heo> just fyi: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
2020-01-25 13:26:18 <^7heo> that ought to be there.
2020-01-25 13:26:26 <north1> I'm not particularly interested in posix
2020-01-25 13:26:31 <north1> Unless it suits my needs
2020-01-25 13:26:39 <^7heo> yeah I know
2020-01-25 13:26:49 <ddevault> iirc adelie is aiming for POSIX compatibility
2020-01-25 13:26:52 <^7heo> I don't expect anyone here to care about anything but "it works on my machine"
2020-01-25 13:27:03 <^7heo> ddevault: yeah I shall switch eventually.
2020-01-25 13:27:16 <ddevault> and I care about more than that :<
2020-01-25 13:27:57 <^7heo> ddevault: I dunno then, maybe you're in the same situation as me? Maybe you will temporarily contribute and leave after?
2020-01-25 13:29:24 <^7heo> https://pics.me.me/it-works-on-my-machine-then-well-ship-your-machine-62072263.png
2020-01-25 13:51:59 <^7heo> note that there is a manual for it: https://pkgs.alpinelinux.org/contents?file=pax.*&path=%2Fusr%2Fshare%2Fman%2F*&name=&branch=edge
2020-01-25 13:52:04 <^7heo> there's a manual, but no binary.
2020-01-25 13:53:35 <^7heo> and it's not compiled in busybox
2020-01-25 14:01:15 <mps> it is from man-pages pkg
2020-01-25 14:03:02 <^7heo> yeah indeed
2020-01-25 14:03:13 <^7heo> turns out this is a busybox overlook
2020-01-25 15:03:01 <_ikke_> Anyone knows how amove should be used? https://git.alpinelinux.org/abuild/tree/abuild.in#n69
2020-01-25 15:05:06 <_ikke_> It takes one or more patterns
2020-01-25 15:10:42 <_ikke_> apparently just `amove path/to/file path/to/file2`
2020-01-25 15:15:03 <north1> amove path
2020-01-25 15:15:09 <_ikke_> yeah, I figured it out
2020-01-25 15:15:18 <north1> Will move path from pkgdir to subpkgdir
2020-01-25 15:15:30 <_ikke_> was reviewing a patch on aports which could use exactly that
2020-01-25 15:15:35 <north1> It is very early so some stuff might chance
2020-01-25 15:16:02 <north1> I have an MR to provide default functions for the shell completion
2020-01-25 15:16:10 <ddevault> fabled: I don't want to send people cross-referencing other man pages just to find the supported options
2020-01-25 15:16:23 <ddevault> and I don't yet have a good design in mind for include directives in scdoc
2020-01-25 15:16:30 <fabled> ddevault, it's done already for the global options
2020-01-25 15:17:07 <ddevault> meh
2020-01-25 15:17:10 <ddevault> alright, w/e
2020-01-25 15:18:18 <_ikke_> fabled: I think the apk-tools pipelines could use some care I guess
2020-01-25 15:18:40 <fabled> i fixed gitlab one earlier, seems github one is broken somehow
2020-01-25 15:18:44 <_ikke_> ok
2020-01-25 15:19:22 <fabled> maybe just remove the github CI?
2020-01-25 15:20:23 <_ikke_> If you don't intend to accept PRs from github anymore that might make sense
2020-01-25 15:27:46 <mps> I pushed !3344 but it will fail
2020-01-25 15:28:27 <mps> it is there for review, and maybe someone will build it locally to test it more
2020-01-25 15:29:14 <bl4ckb0ne> can i have a review on https://lists.alpinelinux.org/~alpine/aports/patches/3243 and https://lists.alpinelinux.org/~alpine/aports/patches/3242 please?
2020-01-25 15:31:38 <_ikke_> bl4ckb0ne: I'll do it in a moment
2020-01-25 15:31:46 <_ikke_> was just busy reviewing some aports patches
2020-01-25 15:32:12 <bl4ckb0ne> thanks!
2020-01-25 15:33:17 <mps> do we have CI labels descriptions somewhere
2020-01-25 15:33:42 <_ikke_> Nope
2020-01-25 15:35:55 <mps> S-CI-Issue is for CI problems?
2020-01-25 15:36:06 <_ikke_> Yes
2020-01-25 15:36:26 <mps> in particular case, it don't have gcc-gnat installed
2020-01-25 15:36:43 <mps> s/it/they/
2020-01-25 15:36:43 <alpine-meetbot> mps meant to say: in particular case, they don't have gcc-gnat installed
2020-01-25 20:28:54 <ddevault> I ran into a problem with the brltty work
2020-01-25 20:29:27 <ddevault> I was reporting the ppc64le build issue upstream, and checked out the maintainer's website when I found the URL in his email signature
2020-01-25 20:30:09 <ddevault> I am no longer interested in working with this person, nor do I think that anyone who uses alpine who might be subject to brltty issues should have to work with this person
2020-01-25 20:30:20 <ddevault> I'm looking into what would be required to fork the project
2020-01-25 20:34:02 <mps> hmmm
2020-01-25 20:34:50 <mps> don't agree, as pkg maintainers we have to communicate with a 'different' persons
2020-01-25 20:35:17 <ddevault> I'm not going to link his website, but if you don't take my word for it then I encourage you to go find it and decide for yourself
2020-01-25 20:35:19 <mps> but, ofc, you are free to not
2020-01-25 20:35:54 <mps> yes, I know there are some not 'fine' people :)
2020-01-25 20:35:55 <ddevault> I mean, heck, we could just cite the code of conduct
2020-01-25 20:36:26 <mps> please post me a link
2020-01-25 20:36:36 <ddevault> sent PM
2020-01-25 20:37:29 <mps> ah, I see :) thanks
2020-01-25 20:38:02 <mps> actually I saw it earlier, can't remember exact time when
2020-01-25 21:02:26 <north1> Yes i am aware that i merged 5 or 6 commits about the same thing, forgot to check again
2020-01-26 03:59:43 <russkel> ddevault, make the fork name... ittybitty
2020-01-26 09:24:04 <mps> hmm, just read that llvm built Debug is not ABI compatible with Release build.
2020-01-26 09:24:54 <mps> brave new world^Wtools
2020-01-26 10:36:40 <nmeum> ddevault: thanks for adding man pages to apk! was on my own personal todo list for a while but I always was to lazy to start working on it
2020-01-26 10:39:28 <kmaxwell> does anyone have advice about the s390x CI job?
2020-01-26 10:39:50 <kmaxwell> it has timed out for me twice, without getting started: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3341
2020-01-26 10:50:13 <AinNero> ScrumpyJack: do you use arandr on edge?
2020-01-26 10:50:38 <AinNero> it seems to have a problem with py3-gobject3
2020-01-26 11:01:34 <AinNero> ah got it fixed, patch incoming
2020-01-26 11:03:03 <Cogitri> kmaxwell: I guess tmhoang would be the one to ask about that since he provides the machines for that
2020-01-26 11:03:50 <kmaxwell> Cogitri: thanks!
2020-01-26 11:04:43 <AinNero> uhm, arandr had a unspecified depencendy on py-cairo
2020-01-26 11:05:04 <AinNero> arandr has a runtime dep on py-gobject, which has py-cairo as build-time dependency
2020-01-26 11:05:29 <AinNero> i dont know if py-cairo is needed as runtime dependency of py-gobject
2020-01-26 11:08:29 <AinNero> ping Cogitri ^
2020-01-26 11:19:18 <Cogitri> Hm, not sure either, haven't used the Python GTK bindings yet. I'll look into it later today
2020-01-26 11:20:22 <AinNero> otherwise i'll make a MR on adding it as dependency on arandr
2020-01-26 11:20:42 <AinNero> that will make it work
2020-01-26 11:50:14 <nmeum> north1: re c536001053c6576976c99285d8c9a5a867aabeb0, I am currently working on adjusting aports which use sphinx-build-3 (et cetera) explicitly. imho we can remove the sphinx binaries postfixed with -3 soonish then   here any other reason to keep those?
2020-01-26 11:50:19 <nmeum> *or
2020-01-26 11:53:33 <north1> I believe I just made that since lot of stuff hardcoded -3 on their scripts
2020-01-26 11:55:39 <nmeum> yep, that's what I am fixing currently
2020-01-26 11:58:03 <north1> Feel free then
2020-01-26 12:06:02 <AinNero> Cogitri: sorry for the double notification
2020-01-26 12:06:26 <AinNero> this was my first MR with gitlab, and i promptly mis-targeted it into my own staging tree
2020-01-26 12:07:08 <nmeum> north1: pushed my changes, added a comment to py3-sphinx. would remove the -3 binaries with the next upgrade then
2020-01-26 12:07:28 <north1> Nice
2020-01-26 12:07:55 <north1> Currently travelling in Kiel with Cogitri, will check when I get home.
2020-01-26 12:11:36 <nmeum> are you guys actually from germany or just visting?
2020-01-26 12:11:56 <north1> I'm just visiting, Cogitri is German
2020-01-26 12:12:30 <nmeum> ah, I also live in northern germany
2020-01-26 12:12:44 <nmeum> anyway: have fun :)
2020-01-26 12:13:13 <Cogitri> Thanks :)
2020-01-26 12:13:21 <north1> Ty
2020-01-26 12:25:15 <alexeymin> Cogitri: Hi! Is https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/11 still WIP or I can try it again?
2020-01-26 12:26:49 <Cogitri> I suppose you can give it another try
2020-01-26 13:20:45 <ddevault> cheers nmeum
2020-01-26 13:30:44 <_ikke_> kmaxwell: there is a known issue with the s390x ci builder.
2020-01-26 13:47:09 <kmaxwell> ikke: thank you, that explains it
2020-01-26 13:47:26 <kmaxwell> long story short, community/py3-google-auth, which I try to maintain, and packages that depend on it are broken in edge
2020-01-26 13:48:06 <kmaxwell> I was trying to make sure my MR fixing this breakage is ready to go: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3341
2020-01-26 13:49:02 <kmaxwell> s390x was the only thing flagged in CI
2020-01-26 13:49:26 <_ikke_> yeah, should not be a big deal
2020-01-26 15:36:05 <telmich> would you mind if I bridge alpine-linux and alpine-devel via matterbridge into the matrix world? It would mean a fake user in here that proxies messages both ways
2020-01-26 15:36:29 <kaniini> yes, we would mind
2020-01-26 15:36:51 <kaniini> this channel is already exposed  to matrix
2020-01-26 15:38:07 <telmich> kaniini: where?
2020-01-26 15:38:13 <telmich> that's even better
2020-01-26 15:38:20 <kaniini> the usual way freenode is bridged to matrix
2020-01-26 15:39:40 <north1> As long as it is seamless
2020-01-26 15:40:07 <north1> The irc bridge im using is mostly seamless (at least for me, I don't know how I appear to others)
2020-01-26 15:40:12 <Cogitri> Yup, Maxice8 and me are bridged via my own IRC<->Matrix bridge too
2020-01-26 15:40:36 <_ikke_> No fake user at least, that would be very anoying
2020-01-26 15:40:49 <telmich> kaniini: are you referring to https://matrix.org/blog/2015/06/22/the-matrix-org-irc-bridge-now-bridges-all-of-freenode/ ?
2020-01-26 15:41:01 <kaniini> yes
2020-01-26 15:42:11 <telmich> *testing*
2020-01-26 15:42:36 <telmich> hmm... seems to either not working at all or not at the moment
2020-01-26 15:42:56 <Cogitri> The matrix.org bridge is down at times, yes
2020-01-26 15:43:07 <Cogitri> And usually kinda slow
2020-01-26 15:43:33 <Cogitri> I packaged matrix-appservice-irc for Alpine though so you can use that if you bridge over your own Homeserver
2020-01-26 17:43:05 <mps> nmeum: what is status of !4
2020-01-26 17:43:40 <mps> algitbot: ?
2020-01-26 17:44:08 <mps> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4   RFC: Alternative codestyle document
2020-01-26 18:17:42 <nmeum> mps: idk, I think it's superior to the current codestyle document but I don't want to be a dick and replace it
2020-01-26 18:18:51 <mps> ah, ok. I agree that is superior and want sometimes to cite it
2020-01-26 18:19:23 <mps> maybe I should add comment and ask you to push it :)
2020-01-26 18:19:59 <north1> There are a few things to change
2020-01-26 18:20:04 <nmeum> this kind of change probably requires more than one ack though
2020-01-26 18:20:08 <nmeum> and even my version could need some updates
2020-01-26 18:20:10 <north1> But overall I agree it is better
2020-01-26 18:20:10 <_ikke_> yup
2020-01-26 18:20:32 <mps> nice
2020-01-26 18:21:02 <mps> everything could be better, ofc, but perfect is enemy of good
2020-01-26 18:21:27 <nmeum> north1: if you have something specific you want to change I can give you push access to the branch
2020-01-26 18:21:55 <north1> I'll just comment on it when I have the time
2020-01-26 18:22:06 <nmeum> sure
2020-01-26 18:22:14 <north1> Currently in Hbf waiting for bus
2020-01-26 18:23:27 <mps> north1: while you wait, https://gitlab.alpinelinux.org/mps/aports/-/jobs/40656/artifacts/raw/packages/main/x86_64/linux-lts-5.4.15-r0.apk
2020-01-26 18:23:38 <mps> kernel 5.4.15
2020-01-26 18:24:06 <north1> mps: yeah I think I'm going to miss the 9 hour deadline
2020-01-26 18:24:39 <mps> ah, probably will be tomorrow in repo
2020-01-26 18:25:07 <north1> Alright but I didn't have the locks anymore
2020-01-26 18:25:14 <north1> So I guess the backport worked
2020-01-26 18:26:22 <mps> not sure it works fine and the bug is fixed
2020-01-26 18:27:00 <mps> I think bug is not fixed in just released 5.4.15 even, but it looks more responsive
2020-01-26 18:27:22 <mps> now I will reboot and see
2020-01-26 18:40:51 <Cogitri> nmeum: Gave !4 it a look, I definitely much prefer it to what we currently have
2020-01-26 18:47:32 <nmeum> great, hopefully it can be merged at some point
2020-01-26 19:50:48 <andypost[m]> Is it ok for testing to downgrade version? I'm using rename to prevent issues in !3362 any suggestions are welcome
2020-01-26 19:53:33 <Cogitri> Well, users won't be downgraded by default, only if they do `apk upgrade -a`
2020-01-26 20:03:18 <MY-R> 
ACTION using that flag everytime when upgrade...

2020-01-26 20:04:13 <MY-R> I think it is right thing to do when on EDGE :D
2020-01-26 20:04:55 <_ikke_> https://michael.stapelberg.ch/posts/2020-01-21-initramfs-from-scratch-golang/
2020-01-26 20:06:17 <MY-R> after that article I enabled pigz in mkinitfs :D
2020-01-26 20:07:17 <mps> andypost[m]: I don't have strong opinion, but I think downgrade version shouldn't be done
2020-01-26 20:08:12 <mps> MY-R: how much seconds you save
2020-01-26 20:08:39 <andypost[m]> mps: yep, but thought that after 9 years there will be 1.1)
2020-01-26 20:09:23 <MY-R> mps, didnt even measure it but for sure it used all cores of cpu, will check now
2020-01-26 20:09:26 <mps> well, I was not clear, I'm not against especially in this corner case
2020-01-26 20:09:38 <mps> andypost[m]: ^
2020-01-26 20:11:57 <mps> and, in that case I would probably downgrade it, I don't see other solution
2020-01-26 20:13:26 <mps> except to make special alpine version and keep it and care for it looooong in future, and always be ambigious
2020-01-26 20:16:43 <MY-R> mps, from 1 minute to 25 seconds, measured twice and dropped cache before every test
2020-01-26 20:17:58 <mps> and how often you make initfs
2020-01-26 20:18:18 <MY-R> lately prety often, playing with kernels...
2020-01-26 20:18:42 <mps> ok
2020-01-26 20:19:03 <MY-R> but it is already added to mkinitfs in this commit: https://git.alpinelinux.org/mkinitfs/commit/?id=59204d36985de5ba2444d5f3e0d50a119287ec51
2020-01-26 20:19:56 <mps> I also play with kernels on slow and small devices and though mkinitfs is not fast I don't see it as bottleneck
2020-01-26 20:20:44 <mps> yes, I remember MR, someone asked for review and I acked it
2020-01-26 20:25:05 <MY-R> didnt notice it before too (until start testing/checking kernel stuff) but also dont see the reason why not using more cores (not necessarily all of them)
2020-01-26 20:27:30 <mps> it is not problem (to repeat I acked it after review), but don't see it as big feature for most users
2020-01-26 20:27:58 <mps> and I'm not against this
2020-01-26 20:28:29 <mps> just wanted to hear your experience and use cases
2020-01-26 20:29:13 <mps> maybe not in quite clear and polite words
2020-01-26 20:30:06 <MY-R> I have got some dual core machine which is even slower so there I could notice that too and since it is fully encrypted I had to wait until image will be done :P
2020-01-26 20:31:18 <mps> ofc, we want alpine to be fast
2020-01-26 20:32:10 <MY-R> so in general Im glad! :>
2020-01-26 22:46:57 <mps> 
ACTION wonder how many times package something and after that find it in aports, huh :)

2020-01-27 00:51:58 <north1> @ollieparanoid I'll check the pmbootstrap MR tomorrow
2020-01-27 07:58:27 <markand> hello guys
2020-01-27 07:58:50 <markand> I wanted to add consolefont support into mkinitfs so started patching the initramfs-init script
2020-01-27 07:59:13 <markand> however, even though tty is working (as cryptsetup ask passwords), setfont complains that /dev/tty does not exist
2020-01-27 07:59:41 <markand> so I wonder how can I fix that, consolefont at early boot is important to me since I have high dpi displays
2020-01-27 16:34:06 <_ikke_> https://www.qt.io/blog/qt-offering-changes-2020
2020-01-27 16:37:35 <_ikke_> LTS becomes commercial only apparerntly
2020-01-27 16:38:19 <PureTryOut[m]> Interesting
2020-01-27 16:39:00 <mps> hah?
2020-01-27 16:39:30 <mps> 
ACTION always had aversion to qt

2020-01-27 16:41:05 <ddevault> fabled: would you be open to merging my download-then-install patch ahead of the major overhauls
2020-01-27 16:41:36 <_ikke_> "Installing binaries requires a Qt account"
2020-01-27 16:41:44 <_ikke_> not sure if that's about pre-built binaries
2020-01-27 16:41:59 <mps> looks like it is
2020-01-27 16:42:32 <mps> though, I'm never sure when read marketing speak
2020-01-27 16:42:48 <_ikke_> https://news.ycombinator.com/item?id=22160928
2020-01-27 16:44:09 <mps> huh, who knows
2020-01-27 16:45:55 <mps> maybe we have to prepare $499/year :)
2020-01-27 16:55:27 <mps> more about this https://www.phoronix.com/scan.php?page=news_item&px=Qt-Going-More-Commercial
2020-01-27 17:04:29 <[[sroracle]]> what a disaster
2020-01-27 19:52:00 <north1> I'm back
2020-01-27 19:52:09 <north1> Is there anything that needs my attention ?
2020-01-27 19:52:21 <north1> @ollieparanoid checking pmbootstrap in a few minutes
2020-01-27 19:53:32 <mps> north1: \o
2020-01-27 19:56:00 <north1> o/
2020-01-27 19:59:24 <north1> @ollieparanoid merged pmbootstrap, left a few comments of stuff that are worth paying attention to but are not important enough to block the merge as-is
2020-01-27 20:28:57 <ollieparanoid[m]> north1: thanks! \o/
2020-01-27 20:30:24 <north1> welcome
2020-01-27 20:49:57 <north1> @ikke made new release of atools which ignores ninja when checking for upper repo packages
2020-01-27 20:51:42 <_ikke_> Just curious, why is that necessary?
2020-01-27 20:52:21 <north1> otherwise all packages that depend on ninja instead of samurai will get aports-lint warnings that ninja is in upper repo 'unmaintained'
2020-01-27 20:52:46 <_ikke_> ah right, because it does not know about provides
2020-01-27 20:52:52 <north1> which is bogus because ninja is actually being provided by samurai via replaces= provides= but i don't want to slowdown aports-lint a lot by calling apk
2020-01-27 20:53:11 <north1> i actually have an old path in the code that is accessed via the EXPENSIVE_FIND_REPO variable
2020-01-27 20:57:37 <_ikke_> pushed
2020-01-27 21:40:59 <PureTryOut[m]> Cogitri and/or north1: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3381
2020-01-27 22:17:47 <_ikke_> PureTryOut[m]: pushed
2020-01-27 22:19:29 <_ikke_> PureTryOut[m]: kio is apparently still failing in CI
2020-01-27 22:19:40 <_ikke_> audiocd-kio
2020-01-27 22:35:15 <PureTryOut[m]> _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3382
2020-01-27 22:37:12 <_ikke_> I'll push when CI is finished
2020-01-27 22:38:36 <PureTryOut[m]> I have to go for now. Most stuff broken will be either missing checksums or missing depends on armhf (in which case the package should be disabled for that arch)
2020-01-27 22:41:08 <_ikke_> ok
2020-01-27 22:53:07 <north1> Can we have a package that provides /var/lib/machine-id ?
2020-01-27 22:53:18 <north1> ever since the dbus post-install was changed to not generate it a lot of tests are failing
2020-01-27 23:20:42 <north1> @ncopa https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/16
2020-01-28 05:57:24 <_ikke_> north1: PureTryOut[m]: I think these still need to be disabled for armhf (at least)
2020-01-28 05:57:26 <_ikke_> https://tpaste.us/lY1L
2020-01-28 08:09:43 <PureTryOut[m]> Probably
2020-01-28 08:10:38 <_ikke_> I used ap revdep on the dependencies that were missing and excluded anything that contained !armhf
2020-01-28 08:10:58 <_ikke_> This is only community btw
2020-01-28 08:21:40 <PureTryOut[m]> ap revdep?
2020-01-28 08:22:14 <_ikke_> lua-aports
2020-01-28 09:17:01 <markand> hello, mkinitfs don't have a repository in gitlab yet?
2020-01-28 09:17:43 <clandmeter> nope
2020-01-28 09:17:44 <mps> markand: git.a.o
2020-01-28 09:17:55 <clandmeter> we should add it
2020-01-28 09:18:25 <mps> clandmeter: +1
2020-01-28 09:18:53 <clandmeter> we can run an import from github
2020-01-28 09:19:48 <mps> from github? not from git.a.o?
2020-01-28 09:24:01 <_ikke_> mps: if you import if from github, you will get issues and the like as well
2020-01-28 09:24:34 <mps> aha, understand
2020-01-28 09:25:03 <mps> and github is still in sync with git.a.o?
2020-01-28 09:33:59 <ncopa> north1: there are some drama going on, on the mailing list, due to the removal of gtkglext (a783b166c89892e91bff2e0d3d76eb2fed7c67b0)
2020-01-28 09:34:57 <ncopa> this thread: https://lists.alpinelinux.org/~alpine/users/%3CCALci+FROkq+i0OjFycgUdtKO-tNt_w%3D_rmEUb2cfPz+0Mw+74w%40mail.gmail.com%3E
2020-01-28 09:35:11 <north1> ah good
2020-01-28 09:35:12 <north1> i was searching for it
2020-01-28 09:35:18 <Cogitri> That sure is a nice mail :^)
2020-01-28 09:35:20 <markand> epic
2020-01-28 09:37:27 <markand> gtkglext is deprecated anyway
2020-01-28 09:40:56 <Cogitri> Yup, at this point I'd just let the user maintain the thing themselve...
2020-01-28 09:41:06 <north1> well we can add to community
2020-01-28 09:41:36 <clandmeter> i think user should be addressed for his attitude.
2020-01-28 09:41:40 <_ikke_> In any case someone should let PICCORO know that this kind of behaviour is not acceptabel
2020-01-28 09:41:42 <_ikke_> heh
2020-01-28 09:41:44 <clandmeter> starting to become a thing
2020-01-28 09:41:52 <north1> I just find it nice that i made that "breaking" change in November and nobody complained
2020-01-28 09:42:42 <north1> at least somebody complained right after i merged xorg-server that possibly broke something due to the meson switching (reverted and tracking this down in a different MR)
2020-01-28 09:42:45 <markand> already told him when I asked about my wayland+x question
2020-01-28 09:43:26 <_ikke_> And edge is expected to break from time to time
2020-01-28 09:44:06 <markand> he then answered “oh you prefer silence? wait forever!”
2020-01-28 10:04:53 <telmich_> is anyone in here at fosdem this weekend?
2020-01-28 10:06:14 <north1> i think @Cogitri will be
2020-01-28 10:06:21 <north1> also, i'm hesitant to answer him on the mailing list
2020-01-28 10:06:56 <markand> you can tell him that gtkglext is deprecated
2020-01-28 10:07:05 <markand> in Arch Linux over all pacakges, only 7 require it
2020-01-28 10:07:12 <north1> Do you have a link for it ?
2020-01-28 10:07:19 <north1> would be nice to provide a source in-hand
2020-01-28 10:10:30 <markand> https://www.archlinux.org/packages/extra/x86_64/gtkglext/ here's the list of consumers
2020-01-28 10:10:47 <markand> homepage is self explanatory : https://projects.gnome.org/gtkglext
2020-01-28 10:11:13 <ncopa> north1: i responded. removing it was the right thing to do
2020-01-28 10:11:27 <ncopa> he has absolutely no right to demand anything from us
2020-01-28 10:11:57 <ncopa> its gtk2 only so getting rid of it is progress
2020-01-28 10:12:05 <markand> yep
2020-01-28 10:12:06 <north1> oh
2020-01-28 10:12:08 <north1> thank you
2020-01-28 10:12:19 <markand> gimp is still my last app running in gtk 2 :(
2020-01-28 10:12:36 <ncopa> north1: thank you for helping us clean up the aports tree. It is appreciated
2020-01-28 10:12:46 <Cogitri> telmich: Yup, I'll be at FOSDEM
2020-01-28 10:13:13 <telmich_> Cogitri: nice! I'm a bit sick at the moment, but if I recover I plan to travel on Friday, maybe we can say hello in person
2020-01-28 10:13:14 <ncopa> i wish i could go to FOSDM as well, but I can't :-(
2020-01-28 10:13:33 <AinNero> same
2020-01-28 10:13:43 <AinNero> two other family things on the same day..
2020-01-28 10:13:46 <AinNero> maybe next year
2020-01-28 10:14:07 <markand> I wish too :(
2020-01-28 10:14:14 <markand> then we will open a very big alpine stand
2020-01-28 10:14:50 <north1> Couldn't go, will go watch basketball game in Ludwigsburg instead :D
2020-01-28 10:15:23 <ncopa> response to PICCORO: https://lists.alpinelinux.org/~alpine/users/%3CCALci+FRSzYo-zZkBKAOv+y13_oEMK8zb2UXHf%3DkU4CGzc5FwyA%40mail.gmail.com%3E
2020-01-28 10:17:01 <markand> thanks ncopa
2020-01-28 10:17:25 <Cogitri> Thanks for dealing with that, ncopa
2020-01-28 10:18:34 <Cogitri> telmich: Ah, I'll be at the FOSDEM on all days, so sure :)
2020-01-28 10:19:10 <Cogitri> ncopa: Could you maybe also take a look at the abuild MRs? Those have been sitting for some time now
2020-01-28 10:21:31 <mps> I don't understand why you don't like piccoro :) he can be boring, true, but never noticed any personal attack from him
2020-01-28 10:22:32 <Cogitri> Well, if you read that mail I'm somewhat certain that you'll notice one :)
2020-01-28 10:22:38 <markand> punctuating every phrases with sh*t is not correct
2020-01-28 10:23:07 <mps> markand: why not is correct?
2020-01-28 10:23:14 <markand> https://lists.alpinelinux.org/~alpine/users/%3C2e88c29eb1dcbab2d0f3e1fda8f1929e06d6f1ac.camel%40malikania.fr%3E#%3CCALci+FToLT-KFBjVgsXtaB6d3dpz8r8VhLTTLyaoUCtf4Y_76w@mail.gmail.com%3E
2020-01-28 10:23:39 <markand> here spreading that wayland is stupid and shit of redhat isn't productive and quite annoying for the OP
2020-01-28 10:23:56 <mps> that is his vocabulary and who are we to judge
2020-01-28 10:24:08 <markand> mps, so you'd be happy if each time I answer you I add sh*t in my answers?
2020-01-28 10:24:33 <mps> well, I will simple ignore this words
2020-01-28 10:24:44 <markand> it's not judging, it's acting professionally, those kind of repeatitive words are annoying for the reader
2020-01-28 10:25:22 <ncopa> he is insulting the developers, which is demotivating and destructive
2020-01-28 10:25:30 <mps> could we understand that different people are, well different
2020-01-28 10:25:38 <danieli> you may ignore it but it doesn't make it any less rude or unacceptable
2020-01-28 10:25:48 <ncopa> he is demanding and drains resources from us
2020-01-28 10:25:54 <ncopa> both time and emotional
2020-01-28 10:26:05 <ncopa> it is damaging for the project
2020-01-28 10:26:12 <mps> danieli: agree, it is rude but again, simply ignore
2020-01-28 10:26:35 <danieli> why? it's destructive and demoralizing
2020-01-28 10:26:48 <danieli> there's no good reason to allow it to continue happening
2020-01-28 10:26:50 <markand> look the whole thread mps, it's totally insane how non-constructive answers were
2020-01-28 10:27:13 <mps> yes, I agree, it is not good
2020-01-28 10:27:35 <ncopa> mps: and he has been asked several times to change behavior
2020-01-28 10:27:45 <mps> but I don't see any personal attack or rude words to any person
2020-01-28 10:28:13 <danieli> oh well.
2020-01-28 10:28:20 <mps> maybe I have too much thick skin
2020-01-28 10:28:30 <ncopa> everyone is different
2020-01-28 10:28:50 <ncopa> and apparently people are reacting negative to it
2020-01-28 10:28:57 <mps> ncopa: that is what I agree
2020-01-28 10:29:49 <ncopa> the other option is complete ignore him and freeze him out
2020-01-28 10:29:55 <mps> and, he is not only one who uses rude words, especially on irc
2020-01-28 10:31:13 <ncopa> but i dont think freezing him out is nice either, because in case it could be unintentional, and then it is better to let him know what he needs to do to change, rather than to just freeze him out
2020-01-28 10:31:47 <mps> (Jon Postel, robustnes principle (IP Networking), be liberal in what you receice and be conservative in what you send)
2020-01-28 10:32:14 <mps> ncopa: that sounds nice
2020-01-28 10:33:43 <mps> we should tell people that their words or behaviors not nice, but we shouldn't react to harsh
2020-01-28 10:34:14 <mps> I like _ikke_ reactions in similar situations
2020-01-28 10:34:59 <mps> and clandmeter humor :)
2020-01-28 10:35:32 <ncopa> +1
2020-01-28 10:35:43 <ncopa> mps: do you think my response was too harsh?
2020-01-28 10:35:59 <mps> no, sure no
2020-01-28 10:37:03 <mps> and, I would sometimes tell someone something similar, but cease because I'm not alpine leader
2020-01-28 10:37:21 <ncopa> feel free to ping men when you think it is needed
2020-01-28 10:37:36 <ncopa> s/men/me/
2020-01-28 10:37:36 <alpine-meetbot> ncopa meant to say: feel free to ping me when you think it is needed
2020-01-28 10:37:49 <clandmeter> i will ping you next time mps is rude
2020-01-28 10:37:57 <mps> :)
2020-01-28 10:38:30 <ncopa> clandmeter: you are a big guy. you should be able to spank him yourself :)
2020-01-28 10:38:35 <mps> I told I like your humor
2020-01-28 10:38:55 <clandmeter> he is too far away ;-)
2020-01-28 10:39:12 <clandmeter> but we have ways to communicate :)
2020-01-28 10:39:31 <mps> ncopa: yes, but first he is my 'friend' and second I'm all my life martial artist
2020-01-28 10:40:54 <mps> ok, ncopa did you looked at gcc fix in MRs
2020-01-28 10:41:02 <mps> back to work
2020-01-28 10:42:02 <kpcyrd> btw, does somebody have time to look at https://github.com/alpinelinux/abuild/pull/110?
2020-01-28 10:45:21 <ncopa> mps: no i havent had time for that yet. will try do it this week
2020-01-28 10:46:00 <mps> ok
2020-01-28 10:46:04 <ncopa> kpcyrd: thanks for working on that! sorry that i havent had time to look at it yet
2020-01-28 10:46:12 <ncopa> will try do it this week too
2020-01-28 10:46:26 <kpcyrd> awesome :)
2020-01-28 11:18:27 <mps> this patch looks too big and not sure should it be applied https://lists.alpinelinux.org/~alpine/aports/patches/3253
2020-01-28 11:19:21 <mps> how many people use PCI on arm 32bit and how many boards are around
2020-01-28 11:19:53 <mps> and IDE disk/devices
2020-01-28 12:31:25 <ncopa> looks like it is mainly to enable 9p filesystem over virtio
2020-01-28 12:38:09 <mps> not only, a lot of network adapters are enabled which I doubt is used on arm SBC boards
2020-01-28 12:38:26 <mps> and a lot of PCI options
2020-01-28 12:38:58 <mps> at least, too big number changes for one commit
2020-01-28 12:39:33 <mps> IDE interface is example
2020-01-28 12:41:22 <mps> if we want such big changes it would be better to take it from Arch linux alarm and merge what is needed, they tested it at least
2020-01-28 12:44:02 <clandmeter> Cogitri: can you followup on https://gitlab.alpinelinux.org/alpine/docker-abuild/issues/55 ?
2020-01-28 12:55:47 <Cogitri> Oh huh, missed that somehow. Will look into it
2020-01-28 13:43:43 <_ikke_> https://github.com/slashbeast/better-initramfs (devel branch basis it on Alpine Linux)
2020-01-28 14:02:18 <clandmeter> im importing mkinitfs from github to gitlab
2020-01-28 14:03:53 <clandmeter> https://gitlab.alpinelinux.org/alpine/mkinitfs
2020-01-28 14:04:52 <clandmeter> markand: ^
2020-01-28 14:05:00 <markand> nice !
2020-01-28 14:05:02 <markand> thanks <3
2020-01-28 15:11:58 <ncopa> clandmeter: thanks!
2020-01-28 16:02:07 <clandmeter> ncopa: is there a reason we ship mariadb-tests with mariadb?
2020-01-28 16:02:16 <clandmeter> is it a needed dependency?
2020-01-28 16:18:08 <mps> clandmeter: line 291 in APKBUILd, ln -s ....
2020-01-28 16:18:56 <mps> I don't know how mariadb works but this looks strange
2020-01-28 16:19:51 <mps> I talked about this with person who create bug report
2020-01-28 16:44:00 <ncopa> clandmeter: there is an issue about that
2020-01-28 16:44:26 <ncopa> iirc there are symlinks that should be moved to proper subpackage
2020-01-28 16:49:13 <clandmeter> I created a docker image but the size is huge for Alpine standards
2020-01-28 16:50:16 <mps> #11131
2020-01-28 16:51:08 <clandmeter> Thanks my friends
2020-01-28 16:51:13 <clandmeter> I will look into it
2020-01-28 16:51:40 <mps> :)
2020-01-28 16:53:26 <juhzuri> Today I learned: envars are the backbone of abuild and bootstrap.sh, and those scripts basically need *different* values for the same envars. (Order of events sort of thing.))
2020-01-28 16:54:28 <clandmeter> This gitlab popup is pissing me off
2020-01-28 16:54:48 <mps> :D
2020-01-28 16:54:51 <clandmeter> I know the freaking menu has moved
2020-01-28 16:55:39 <clandmeter> They should never make that developer developer of the month ;)
2020-01-28 16:55:41 <mps> it don't know that you (and I) know that menu is moved
2020-01-28 16:56:53 <clandmeter> I'm also getting multiple errors in ui
2020-01-28 16:57:27 <clandmeter> Something went wrong on our end
2020-01-28 16:57:50 <clandmeter> So that's my end?
2020-01-28 16:58:04 <mps> no
2020-01-28 16:58:20 <mps> you are not logged in gitlab.a.o
2020-01-28 16:58:46 <clandmeter> And that should give an error?
2020-01-28 16:58:55 <mps> it is there only for not logged in users
2020-01-28 16:59:35 <clandmeter> The error or the popup?
2020-01-28 16:59:41 <mps> popup
2020-01-28 16:59:49 <mps> what error you have
2020-01-28 17:00:12 <clandmeter> 17:57 <@clandmeter> Something went wrong on our end
2020-01-28 17:00:44 <mps> ah, didn't noticed any error on my browser
2020-01-28 17:03:02 <mps> main/pciutils: upgrade to 3.6.4, is it officially released?
2020-01-28 17:06:18 <clandmeter> It's only in the changes tab
2020-01-28 17:07:47 <mps> hmm, I got popup (not logged in now) but no errors
2020-01-28 17:10:01 <clandmeter> I'm on mobile
2020-01-28 17:10:49 <mps> could be browser issue
2020-01-28 17:13:39 <clandmeter> Happens on ff and chrome
2020-01-28 17:14:53 <mps> looks like ff on alpine works better
2020-01-28 17:15:22 <mps> both, tried on esr and current in testing
2020-01-28 17:46:23 <clandmeter> interesting this symlink behaviour
2020-01-28 18:53:24 <clandmeter> looks like there are more symlinks not moved to the right subpkg
2020-01-28 18:53:45 <clandmeter> wonder if we could do that automatically or add a check.
2020-01-28 19:02:46 <mps> after two days of uptime with linux-lts 5.4.15 on x86_64 didn't noticed any lock or slowdown, and looks like it 'eats' less RAM
2020-01-28 19:07:27 <clandmeter> hmm
2020-01-28 19:08:03 <clandmeter> i think this "fix" will break things
2020-01-28 19:08:32 <clandmeter> its a similar fix as the clamav thingy
2020-01-28 19:09:40 <mps> you mean mariadb fix?
2020-01-28 19:09:49 <clandmeter> yes
2020-01-28 19:10:10 <clandmeter> moving symlinks to its correct position will undep things that are not really a dep
2020-01-28 19:10:14 <mps> aha, that is reason I didn't dare to make MR
2020-01-28 19:10:19 <clandmeter> but people could depend on them
2020-01-28 19:10:41 <clandmeter> most notable is mariadb-client
2020-01-28 19:11:01 <clandmeter> currently it is pulled in when you install mariadb
2020-01-28 19:11:13 <clandmeter> due to the faulty symlink locations
2020-01-28 19:11:58 <clandmeter> and i think there is a way around it
2020-01-28 19:11:58 <mps> don't see why mariadb-client have to be pulled when mariadb installed, but who knows
2020-01-28 19:12:31 <clandmeter> example: you create a docker image for mariadb
2020-01-28 19:12:52 <clandmeter> but on initial start you need to run some commands, so you need the mysql utility.
2020-01-28 19:12:53 <mps> ok
2020-01-28 19:13:13 <clandmeter> now it would suffice to apk add mariadb
2020-01-28 19:13:17 <mps> ah, it needs it on installation setup?
2020-01-28 19:13:26 <clandmeter> depends on your usecase
2020-01-28 19:13:50 <clandmeter> but yes its used on dockerized mysql/mariadb
2020-01-28 19:14:19 <clandmeter> but there are more places that users would think mariadb would pull in both server and client.
2020-01-28 19:14:57 <clandmeter> so the better work around would be to introduce mariadb-server
2020-01-28 19:15:17 <clandmeter> and make mariadb a metapkg to pull in both client and server
2020-01-28 19:15:50 <clandmeter> and maybe even mariadb-server-utils
2020-01-28 19:15:53 <mps> 'apk info -r postgresql-client' => postgresql-client-11.5-r0 is required by: postgresql-11.5-r0
2020-01-28 19:16:02 <mps> so, similar
2020-01-28 19:16:34 <clandmeter> i have not checked postgresql
2020-01-28 19:16:52 <clandmeter> but i dont think you explicitly need the client to run the db.
2020-01-28 19:17:49 <clandmeter> im not sure if this symlink dependency has always been included
2020-01-28 19:17:52 <mps> well, also I think but packagers don't agree
2020-01-28 19:18:02 <mps> let me look on debian
2020-01-28 19:18:16 <clandmeter> better example maybe is openssh
2020-01-28 19:18:24 <clandmeter> it has server and client split
2020-01-28 19:20:57 <mps> yes, but for ssh server client is not needed for initial setup
2020-01-28 19:21:18 <clandmeter> also not for db's
2020-01-28 19:21:27 <clandmeter> but if your usecase changes it could be.
2020-01-28 19:22:51 <mps> I didn't worked with mariadb/mysql nothing serious so forgot, but setting postgresql without having client looks like very hard
2020-01-28 19:23:27 <mps> s/ nothing serious/ nothing serious for more 15 years/
2020-01-28 19:23:27 <alpine-meetbot> mps meant to say: I didn't worked with mariadb/mysql nothing serious for more 15 years so forgot, but setting postgresql without having client looks like very hard
2020-01-28 19:23:44 <mps> ime, at least
2020-01-28 19:24:11 <clandmeter> for postgres it sets it as a hard dependency
2020-01-28 19:26:25 <mps> iirc, postgres 'initdb' command requires 'psql'
2020-01-28 19:28:02 <mps> hmm, 'strings' result is against my thoughts
2020-01-28 19:33:11 <clandmeter> i know why its added :)
2020-01-28 19:33:21 <clandmeter> git blame to the rescue
2020-01-28 19:33:42 <clandmeter> 64bce71141d9562664c0a852dd096978579ea5f8
2020-01-28 19:36:16 <clandmeter> this is a weird place to implement such feature
2020-01-28 19:36:51 <clandmeter> oh thats for tmpfs
2020-01-28 19:37:30 <clandmeter> running a db in tmpfs...
2020-01-28 19:38:58 <ddevault> ncopa: I have a keyutils patch stuck on the aports list, can you take a look at it when you have a chance?
2020-01-28 19:39:22 <mps> for short lived DBs
2020-01-28 19:39:22 <ddevault> ncopa: https://lists.alpinelinux.org/~alpine/aports/patches/3194
2020-01-28 19:40:31 <mps> but again, i don't think it is big issue to install client if the server isntalled (for DBs, ofc)
2020-01-28 19:41:59 <mps> the issue with mariadb is the test data pkg is installed
2020-01-28 19:51:41 <clandmeter> mps: https://gitlab.alpinelinux.org/alpine/aports/issues/11131
2020-01-28 19:54:06 <mps> yes, I talked with him about that issue, but not sure how to remove this test data
2020-01-28 19:54:29 <mps> ah, you added fix
2020-01-28 19:54:40 <clandmeter> i think his commit is good to go
2020-01-28 19:57:29 <mps> yes, from your description I understand all
2020-01-28 20:00:11 <clandmeter> removing server-utils also removes perl.
2020-01-28 20:00:16 <clandmeter> thats a win anyways :)
2020-01-28 20:01:25 <mps> eh, by this I see my hope for alpine to stay small is not vanished :)
2020-01-28 23:22:48 <north1>  community/plymouth/plymouth-git-master-20170123.patch                         | 5399 -----------------------------------
2020-01-28 23:22:56 <north1> oh wow
2020-01-28 23:23:15 <north1> I made a small script for detecting .patch files that are not in source and i found... that
2020-01-28 23:23:30 <mps> I noticed, good work
2020-01-28 23:33:08 <north1> It has false-positives due to not being smart enough to detect conditionals
2020-01-28 23:33:23 <north1> so if you have
2020-01-28 23:33:26 <north1> if "$FOO"; then source="$source patch.patch"; fi
2020-01-28 23:33:43 <north1> it will declare it stale even though it is used when FOO Is true
2020-01-28 23:33:48 <north1> see ghc/0000-bootstrap
2020-01-28 23:34:38 <mps> maybe it will be safer to detect by your script and then check by 'eyes'
2020-01-28 23:34:53 <north1> yes i do that for cases i find suspcious
2020-01-28 23:34:58 <north1> 0000-bootstrap
2020-01-28 23:35:12 <north1> anything regarding the linux kernel like linux-amlogic and anything gcc like community/gcc6
2020-01-28 23:38:00 <mps> this reminds me that linux-amlogic is outdated, and gcc6 probably need fix as gcc 9.2 for which I created MR
2020-01-28 23:38:19 <mps> but will look tomorrow, preparing for bed now
2020-01-29 00:33:05 <north1> oof
2020-01-29 00:33:22 <north1> I update telegram-desktop to 1.9.8 and they release 1.9.9
2020-01-29 06:29:18 <vkrishn> is bin/tipc being pkg'd in iproute2, in edge ?
2020-01-29 06:29:22 <vkrishn> #2361 , ncopa, Cogitri ^
2020-01-29 06:30:34 <vkrishn> project seems active, http://tipc.sourceforge.net/
2020-01-29 06:30:56 <vkrishn> I can see kernel modules, but no tools in v3.10.x
2020-01-29 07:28:10 <Cogitri> https://pkgs.alpinelinux.org/contents?file=&path=*bin*&name=iproute2&branch=edge&repo=main&arch=x86_64 seems like it isn't in the iproute2 pkg, yes
2020-01-29 07:29:04 <_ikke_> wireguard now merged into Linux: https://lists.zx2c4.com/pipermail/wireguard/2020-January/004906.html
2020-01-29 07:31:52 <Cogitri> Neat
2020-01-29 07:32:42 <mps> yes, who will backport it LTS? I hope someone will
2020-01-29 07:35:37 <vkrishn> Cogitri: any chance of bin/tipc getting added in iproute2 pkg ?
2020-01-29 07:35:53 <Cogitri> I don't think it'll be backported to LTS since that's not what LTS is about, mps
2020-01-29 07:36:17 <Cogitri> If they backported features to LTS kernels LTS would be pointless
2020-01-29 07:36:37 <mps> yes, I know, but this is long awaited 'feature'
2020-01-29 07:36:39 <vkrishn> nope, kernel module is there, only the tool
2020-01-29 07:36:53 <mps> and, it is not complicated to backport
2020-01-29 07:38:15 <mps> and, 5.4 is still not declared LTS
2020-01-29 07:39:15 <mps> it have a lot issues and problems, maybe they will skip it and declare 5.5 (which is a lot better) or 5.6
2020-01-29 09:52:06 <mps> x86 and x86_64 CI are stuck
2020-01-29 11:45:05 <kunkku> we had a discussion with clandmeter on how to avoid issues like https://gitlab.alpinelinux.org/alpine/aports/issues/11131
2020-01-29 11:46:04 <kunkku> there mariadb ended up depending on mariadb-test because upstream added a new symlink which was not handled properly by the old split function
2020-01-29 11:47:17 <kunkku> we came up with an idea that the maintainer could declare unwanted dependencies in APKBUILD
2020-01-29 11:47:31 <kunkku> e.g. nodeps="mariadb-test"
2020-01-29 11:48:05 <_ikke_> depends="!mariadb-test" would be more inline with existing functionality
2020-01-29 11:48:08 <_ikke_> oh, no
2020-01-29 11:48:13 <_ikke_> that's conflicts
2020-01-29 11:48:18 <kunkku> right
2020-01-29 11:48:49 <kunkku> we don't want to prevent installing them simultaneously but just detect accidental autodeps
2020-01-29 11:48:57 <_ikke_> yeah, was more about syntax
2020-01-29 11:49:01 <_ikke_> but forgot that it was already used
2020-01-29 11:49:41 <mps> why not loose deps
2020-01-29 11:49:46 <kunkku> is this a sensible approach, or is there a better way?
2020-01-29 11:50:02 <mps> s/why not//
2020-01-29 11:50:02 <alpine-meetbot> mps meant to say:  loose deps
2020-01-29 11:50:17 <_ikke_> :)
2020-01-29 11:50:26 <_ikke_> You mean to ask why this is an issue?
2020-01-29 11:50:38 <mps> no
2020-01-29 11:50:40 <_ikke_> ok
2020-01-29 11:51:30 <mps> want to tell that this is some kind of 'lose dependencies' but keyboard is not obedient enough :)
2020-01-29 11:51:44 <mps> s/lose/loose/
2020-01-29 11:51:44 <alpine-meetbot> mps meant to say: want to tell that this is some kind of 'loose dependencies' but keyboard is not obedient enough :)
2020-01-29 11:53:14 <kunkku> the same could of course happen with shared libs
2020-01-29 11:55:18 <mps> hmm, why then to add this if package doesn't actually depends on those listed in 'nodeps'
2020-01-29 11:57:12 <kunkku> it's basically a test case
2020-01-29 11:57:36 <kunkku> they are added to detect bugs (even though they are not supposed to be there)
2020-01-29 11:58:44 <kunkku> so we know that mariadb should not depend on mariadb-test
2020-01-29 11:59:18 <kunkku> we want at least a warning printed if such a dependency is detected by abuild
2020-01-29 11:59:41 <mps> ah, now understand
2020-01-29 12:00:13 <mps> maybe even abuild error
2020-01-29 12:00:57 <mps> or flag to abuild to fail or just write warning in such case
2020-01-29 12:01:28 <kunkku> IMO failing would be the correct action
2020-01-29 12:02:22 <kunkku> the maintainer should either remove the dep or the nodeps clause
2020-01-29 12:02:48 <mps> yes, makes sense
2020-01-29 15:19:12 <mps> ncopa: I would push gcc6 fix, !3425 do you agree
2020-01-29 15:20:30 <clandmeter> north1: f12f2b778ee936808ce7577efd837e62d877c67a this adds a patch which is not in src, later you remove the patch again (guess found by script)?
2020-01-29 15:21:19 <north1> Yes
2020-01-29 15:21:50 <north1> I'll upload the script to my dotfiles but it is super simple and requires manual checking
2020-01-29 15:22:26 <clandmeter> so guess this is wrong?
2020-01-29 15:27:00 <clandmeter> north1: ?
2020-01-29 15:31:57 <north1> Well it wasn't in the source, as far as I could see it wasn't being applied
2020-01-29 15:34:32 <clandmeter> north1: yes but you applied the patch that introduced it ;-)
2020-01-29 15:51:42 <PureTryOut[m]> _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3436
2020-01-29 16:01:24 <ncopa> mps: ok with me
2020-01-29 16:16:19 <north1> @clandmeter must have been a massive oversight by me then
2020-01-29 16:17:10 <clandmeter> it has happened to me before as well so no worries.
2020-01-29 16:17:53 <north1> @ddevault are you or anyone else working updating wlroots/sway and stuff ?
2020-01-29 16:18:05 <ddevault> oh, I totally forgot
2020-01-29 16:18:15 <ddevault> working on it now
2020-01-29 16:18:30 <north1> ah nice, i'll wait then
2020-01-29 16:18:51 <clandmeter> north1: do you know if that mariadb patch is still needed?
2020-01-29 16:19:12 <north1> @clandmeter no idea, i'd have to ask the author
2020-01-29 16:19:33 <clandmeter> ok i backported a few fixes to stable
2020-01-29 16:19:42 <clandmeter> not sure that should be included
2020-01-29 16:20:27 <north1> @ddevault i also packaged xcb-util-errors if that is of any use for wlroots
2020-01-29 16:38:09 <north1> @ddevault your patches didn't appear on the patches section
2020-01-29 16:38:57 <ddevault> north1: weird, noted
2020-01-29 16:40:39 <north1> They have been applied
2020-01-29 16:41:13 <ddevault> thanks!
2020-01-29 16:46:56 <north1> Also updated swayidle and swaylock and moved sway-fish-completion to /usr/share/fish/completion instead of /usr/share/fish/vendor_completion.d
2020-01-29 16:54:52 <ddevault> thanks!
2020-01-29 18:35:55 <AinNero> how does this kind of warning come into existence?
2020-01-29 18:35:57 <AinNero> > WARNING: babl-dev*: package providing /usr/lib/pkgconfig/lcms2.pc needs to be rebuilt
2020-01-29 18:47:30 <AinNero> nvm got it
2020-01-29 23:37:10 <vivi> i
2020-01-29 23:39:04 <vivi> Any Alpine developers available for hire for brief consulting ?
2020-01-29 23:40:24 <vivi> If so PM rate / availability - I have an interesting problem I'd love to not have and it likely requires > documentation.
2020-01-29 23:41:48 <mps> vivi: why not ask on #alpine-linux first, channel for user help
2020-01-29 23:42:42 <mps> maybe your problem is interesting in general
2020-01-29 23:43:02 <vivi> mps, it is in terms of application, not so much in terms of OS level
2020-01-29 23:43:52 <mps> and most developers are in CET so probably not many of them online now
2020-01-29 23:44:29 <vivi> I'll post in #alpine as well then. Thank you mps.
2020-01-29 23:45:30 <vivi> ahem.. #alpine-linux
2020-01-30 05:47:56 <_ikke_> Cogitri: squeekboard is failing
2020-01-30 05:48:27 <Cogitri> Yup, gonna look into it in a bit
2020-01-30 05:48:33 <_ikke_> ok
2020-01-30 05:48:47 <Cogitri> Just boarded train to Brussels :)
2020-01-30 05:49:21 <_ikke_> nice
2020-01-30 05:49:34 <_ikke_> "ninja: open build.ninja: No such file or directory"
2020-01-30 05:49:44 <_ikke_> I think that's the error
2020-01-30 06:09:09 <Cogitri> Huh
2020-01-30 06:11:23 <_ikke_> It's at the end of the tests
2020-01-30 06:27:36 <mforney> `ninja test -C output` should be `ninja -C output test`
2020-01-30 06:28:42 <mforney> (same with install)
2020-01-30 06:30:13 <Cogitri> That makes a difference?
2020-01-30 06:31:14 <mforney> yes, samurai follows the POSIX Utility Syntax Guidelines, and doesn't do GNU-style argument permutation
2020-01-30 06:31:30 <Cogitri> Ah, alrighty then
2020-01-30 06:31:31 <mforney> so all operands must come after options
2020-01-30 06:33:06 <Cogitri> Time to change all the APKBUILDs which do that :^)
2020-01-30 06:33:19 <Cogitri> (Without WiFi, thanks Deutsche Bahn)
2020-01-30 06:34:27 <mforney> i don't think there are many. the only one i ran into when i did test builds of all ninja-using aports packages was community/knot-resolver
2020-01-30 06:35:08 <mforney> (this was mid-december)
2020-01-30 06:35:38 <Cogitri> There are some 40 or so
2020-01-30 06:36:36 <Cogitri> Alright nevermind, it's 11 apparently
2020-01-30 06:40:29 <Cogitri> !3463
2020-01-30 06:44:29 <kaniini> Cogitri: looks ok to me
2020-01-30 06:44:37 <mforney> all new packages it looks like
2020-01-30 06:46:13 <Cogitri> All packages which haven't been generated with newapkbuild
2020-01-30 06:46:41 <Cogitri> We should really make that a requirement for packages where newapkbuild fits the bill (or adopt void-style build-styles)
2020-01-30 06:46:53 <kaniini> Cogitri: do you have the ability to push?  i can do so otherwise.
2020-01-30 06:47:47 <Cogitri> I have push permissions for community and testing, yes
2020-01-30 06:47:51 <Cogitri> But thanks :)
2020-01-30 06:48:19 <Cogitri> Gonna see if CI can run over them (minus the rust stuff because that'll probably SIGSEGV again)
2020-01-30 06:53:05 <mforney> i believe chromium will run into the same problem, since https://chromium.googlesource.com/chromium/src/+/53b414cba10bc3c38fca88c330d2146722b4e54c%5E%21/ hasn't yet made it into a release
2020-01-30 06:59:14 <mforney> the only other package i ran into an issue with (that hasn't already been fixed in a new release) is weston, but that should be fixed when it gets updated to 8.0.0, released just a few days ago
2020-01-30 07:10:13 <kaniini> mforney: we provide /usr/bin/ninja
2020-01-30 07:10:51 <mforney> yes, but the argument order is still a problem
2020-01-30 08:05:07 <AinNero> yay \o/ mkinitfs migrated to gitlab
2020-01-30 08:38:32 <tboerger[m]> w00t? is the mirror for edge broken? http://nl.alpinelinux.org/alpine/edge/main/x86_64/ is empty for me
2020-01-30 08:40:16 <_ikke_> clandmeter: ^
2020-01-30 08:40:36 <_ikke_> it's not just nl
2020-01-30 08:42:09 <tboerger[m]> dl-cdn brings me at least to another mirror which got files
2020-01-30 08:42:43 <_ikke_> dl-cdn caches things
2020-01-30 08:46:12 <tboerger[m]> is nl.al.org official at all? i can't remember why i have added this and it's not listed at http://dl-cdn.alpinelinux.org/alpine/MIRRORS.txt
2020-01-30 08:46:22 <tboerger[m]> was this the mirror that get all updates first?
2020-01-30 08:46:33 <_ikke_> tboerger[m]: it's decommisioned, but we redirect it to another mirror
2020-01-30 08:47:07 <tboerger[m]> ok, so it would make sense to use dl-cdn for my base docker image.
2020-01-30 08:47:27 <_ikke_> The alpine docker image already uses dl-cdn
2020-01-30 08:47:49 <tboerger[m]> i got my own base image :)
2020-01-30 13:03:01 <tboerger[m]> awesome... there are no alpine package for adoptopenjdk, right?
2020-01-30 13:07:23 <fabled> hmmm... pango has depends_dev="pango-tools=$pkgname-r$pkgrel", should be "pango-tools=$pkgver-r$pkgrel" ?
2020-01-30 13:07:29 <^7heo> is the rpi image still a read-only image using lbu?
2020-01-30 13:08:21 <_ikke_> yes
2020-01-30 13:08:50 <_ikke_> fabled: yes, $pkgname there doesn't make a lot of sense
2020-01-30 13:11:44 <tboerger[m]> or does somebody know about third party repos which provide adoptopenjdk8 packages? damn minecraft forge :(
2020-01-30 13:14:08 <tboerger[m]> https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/8/jdk/alpine/Dockerfile.hotspot.releases.full the available alpine docker images are looking really evil :(
2020-01-30 13:14:19 <^7heo> man the alpine wiki is in a bad shape...
2020-01-30 13:49:41 <ncopa> fabled: yes
2020-01-30 13:51:25 <fabled> ncopa, yes, fixed in https://gitlab.alpinelinux.org/alpine/aports/commit/d24f40bce4b68f7e9bdaa49c2a5be762ddaaa9c6
2020-01-30 13:53:40 <tboerger[m]> hum.... should i really start building a thirdparty repo for this damn other jvm? :(
2020-01-30 13:54:19 <ncopa> tboerger[m]: what is the difference of adoptopenjdk8 vs openjdk8?
2020-01-30 13:55:53 <tboerger[m]> the one available on alpine is icedtea, which is unsupported for minecraft forge. only oracle and adoptopenjdk are supported. i got problems with installing minecraft forge and upstream rejects to help because icedtea seems to be known to make trouble for minecraft generally :(
2020-01-30 13:59:33 <tboerger[m]> before i spend any time on getting adoptopenjdk packaged or better useable on alpine i should really try this ugly available alpine docker image if i got the same issues on that
2020-01-30 14:00:20 <ncopa> and minecraft does not run with openjdk11?
2020-01-30 14:01:01 <ncopa> they ship a precompiled openjdk8 binary linked to glibc toghether with a copy of glibc
2020-01-30 14:01:05 <ncopa> ugly indeed
2020-01-30 14:01:22 <tboerger[m]> minecraft itself recommends jdk8
2020-01-30 14:01:50 <tboerger[m]> using a more current java version leads to different issues
2020-01-30 14:02:01 <AinNero> ncopa: i wonder why they are using alpine in the first place then
2020-01-30 14:02:19 <tboerger[m]> if i wouldn't enjoy playing minecraft together with my son so much i would just ditch it because of these ugly deps
2020-01-30 14:02:20 <ncopa> i guess because its small and users are asking for it
2020-01-30 14:02:42 <ncopa> cant you use a glibc based docker image?
2020-01-30 14:03:02 <AinNero> there are surely some minimalistic glibc distros out there
2020-01-30 14:03:27 <tboerger[m]> AinNero: where? i haven't found anything comparable to alpine
2020-01-30 14:04:06 <tboerger[m]> nearly all my images are alpine based, and the older versions of minecraft forge always worked like a charm on alpine, it's only an issue with recent versions.
2020-01-30 14:04:47 <AinNero> i think i would use debian containers just to avoid the hassle with compatibility
2020-01-30 14:05:43 <ncopa> would be nice to have a proper build with musl
2020-01-30 14:06:37 <ncopa> so whats the difference with icedtea and adopt?
2020-01-30 14:14:00 <AinNero> vivi in #alpine-linux also has the issue with the missing files on the repo
2020-01-30 14:14:11 <AinNero> their mirror is in the mirror list
2020-01-30 14:17:01 <tboerger[m]> looks like adoptopenjdk only provides tarballs for glibc. maybe i should just install https://wiki.alpinelinux.org/wiki/Installing_Oracle_Java into my docker image -.-
2020-01-30 14:21:05 <tboerger[m]> ncopa: looks like adoptopenjdk is only available in a prebuilt format, so i can not see a way to build it properly for musl.
2020-01-30 14:21:29 <Thermi> On a range from 0 to 10, how happy are you to read about new bootstrap.sh fails?
2020-01-30 14:21:50 <Thermi> assorted build failures: gcc, binutils, musl, ...
2020-01-30 14:21:52 <Thermi> All very fun.
2020-01-30 14:22:04 <Thermi> cross building from x86_64 to aarch64
2020-01-30 14:22:16 <Thermi> 3.11 docker image to 3.11-stable
2020-01-30 14:35:54 <ncopa> hum
2020-01-30 14:36:09 <ncopa> would be good to have nighly runs of bootstrap.sh or similar
2020-01-30 14:37:00 <ncopa> and i wonder if we should include go, rust and openjdk in the bootstrap.sh
2020-01-30 14:37:54 <ncopa> tboerger[m]: the idea is to help adoptopenjdk to make rebuilt binaries using musl
2020-01-30 14:41:48 <tboerger[m]> ncopa: i asked the minecraft forge guys if there is a website which compares adoptopenjdk and icedtea, that was their answer: https://cl.ly/f8697bb9028b
2020-01-30 14:42:15 <tboerger[m]> maybe it could be interesting to reach out to adoptopenjdk to get it built on musl/alpine
2020-01-30 14:42:52 <tboerger[m]> since it's gpl licensed it could be easily added to alpine
2020-01-30 14:43:12 <tboerger[m]> (if it's building on musl)
2020-01-30 14:48:40 <ncopa> tboerger[m]: yes, thats what i thought. i think we coudl at least start by creating an issue or feature request
2020-01-30 14:48:57 <ncopa> i dont have time to help with that though :-(
2020-01-30 14:49:34 <ncopa> i guess that if they set up a builder with musl, the official build would fail
2020-01-30 14:50:05 <ncopa> and then we upstream our patches or help upstream to solve all the issues til the official build works with musl
2020-01-30 14:50:55 <ncopa> oracle has put some effort to make openjdk on alpine
2020-01-30 14:59:30 <tboerger[m]> would be great if this can be integrated!
2020-01-30 14:59:53 <tboerger[m]> not sure if i would be a big help beside a tester, i'm not really in java :D
2020-01-30 15:21:48 <clandmeter> ncopa: can aports tree with abuild be readonly?
2020-01-30 15:22:13 <ncopa> i think no
2020-01-30 15:22:21 <ncopa> abuild needs patching for that
2020-01-30 15:22:38 <clandmeter> thee is SRCDEST
2020-01-30 15:22:41 <clandmeter> there...
2020-01-30 15:22:57 <clandmeter> but i dont see similar for pkg
2020-01-30 15:23:14 <ncopa> we need a WORKDIR or similar
2020-01-30 15:23:36 <ncopa> currently it creates src and pkg in same dir as APKBUILD
2020-01-30 15:23:46 <ncopa> should be in /var/ soemwhere
2020-01-30 15:23:57 <ncopa> maybe /var/lib/abuild/ or similar
2020-01-30 15:24:03 <mps> I played a little with setting env vars for that
2020-01-30 15:24:24 <mps> for 'src' and 'pkg' I mean
2020-01-30 15:24:36 <clandmeter> currently workdir is startdir
2020-01-30 15:24:48 <clandmeter> SRCDEST=${SRCDEST:-$startdir}
2020-01-30 15:25:44 <clandmeter> hmm
2020-01-30 15:25:55 <clandmeter> pkgbasedir=${pkgbasedir:-"$startdir/pkg"}
2020-01-30 15:26:13 <clandmeter> what if i override both of them?
2020-01-30 15:28:37 <clandmeter> ah that is actually distfiles location
2020-01-30 15:32:07 <mps> I forgot what i did exactly, but remember that looked in abuild and found 'src' and 'pkg' and set appropriate env variables, and it worked
2020-01-30 15:32:18 <clandmeter> yes i think it can work
2020-01-30 15:32:23 <clandmeter> but its not optimal
2020-01-30 15:32:41 <clandmeter> its more like a hack then a feature
2020-01-30 15:32:43 <ncopa> there was some PR with related patch
2020-01-30 15:32:44 <mps> (didn't wrote anywhere exact setup or notes :( )
2020-01-30 15:33:10 <mps> clandmeter: yes, hack
2020-01-30 15:33:50 <mps> it would be nice if that can be set in ~/.abuild/abuild.conf
2020-01-30 15:37:36 <clandmeter> hmm that does not really work without patching.
2020-01-30 15:38:30 <clandmeter> ncopa: was it on gitlab/github/ml?
2020-01-30 15:40:37 <ncopa> github
2020-01-30 15:40:55 <ncopa> i didnt merge his patch due to i want move src and pkg to /var
2020-01-30 15:41:22 <ncopa> i think it was something with symlinks
2020-01-30 15:42:30 <clandmeter> you would prefer var/lib or var/cache?
2020-01-30 15:44:42 <ncopa> yeah, /var/lib probably
2020-01-30 16:02:20 <clandmeter> hmm, i guess this could be tricky depending on how the APKBUILDS are stored
2020-01-30 16:43:20 <Thermi> ncopa: cross compiling gcc 9.2.0 from 3.11 doesn't work because it fails testing the cross compiler when using -V -qversion and so on. It was supposed to have been fixed in GCC +5.0. Any idea?
2020-01-30 16:43:39 <Thermi> Also, this is kind of required to bootstrap alpine for aarch64
2020-01-30 16:43:40 <Thermi> :(
2020-01-30 16:56:53 <wsinatra> Is it acceptable to use a case statement to define source/patches in an APKBUILD?
2020-01-30 16:59:13 <mps> wsinatra: how the checksum then be calculated? manually?
2020-01-30 17:00:06 <north1> ghc does it for 0000-bootstrap
2020-01-30 17:00:06 <north1> and i have no clue how it works or even if it works
2020-01-30 17:01:02 <wsinatra> mps: maybe, but I'm not positive. SBCL is a headache to build on musl and on non x86_64 platforms
2020-01-30 17:02:12 <wsinatra> north1: thanks for teh suggestion I'm looking at that now
2020-01-30 17:03:04 <mps> north1: yes, and it doesn't have checksum
2020-01-30 17:03:29 <wsinatra> Looks like they define an all arch applicable source, then append to it as necessary based on the build target, but mps is right, it just has a sha512sum at the end, nothing else
2020-01-30 17:04:12 <mps> I think all they should go to 'source' and then in prepare() apply patches which are needed, using if-else or 'case'
2020-01-30 17:05:26 <wsinatra> That sounds like a more secure way to do it, not checksumming each file sounds like asking for maleficence
2020-01-30 18:38:36 <mps> looking all about new (not yet released) musl 1.2 I think we should also upgrade kernel to 5.6 together with musl
2020-01-30 18:39:10 <mps> oh, dalias left this channel
2020-01-30 18:39:21 <_ikke_> mps: why is that?
2020-01-30 18:39:54 <mps> _ikke_: fixes to time64 will be in 5.6 kernel
2020-01-30 18:40:45 <mps> XFS (for example) got time64 fixes in 5.6
2020-01-30 18:41:19 <mps> _ikke_: look here https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame
2020-01-30 18:41:34 <_ikke_> heh, endgame
2020-01-30 18:42:05 <mps> :)
2020-01-30 18:44:13 <mps> and switching to 5.6 we will get wireguard in kernel, as a bonus :)
2020-01-30 18:45:49 <minecrell> Can someone clarify the "Contributor" comment in APKBUILDs? Is it only intended for the person who originally contributed the APKBUILD or as attribution for everyone who made larger changes? I.e. is it fine to have multiple Contributor comments?
2020-01-30 18:47:21 <Cogitri> It's fine to have multiple ones
2020-01-30 18:47:34 <Cogitri> It's basically a collection of people who made notable changes to the APKBUILD
2020-01-30 18:47:41 <mps> minecrell: Contributor officially even is not needed
2020-01-30 18:47:49 <minecrell> PureTryOut[m]: ^
2020-01-30 18:48:33 <Cogitri> No, it's not a requirement
2020-01-30 18:48:38 <mps> and there can be multiple Contributor lines
2020-01-30 18:49:39 <mps> for small changes or fixes it doesn't make sense to add/delete/change Contribor lines
2020-01-30 18:50:29 <_ikke_> There are ideas to even drop it completely
2020-01-30 18:51:06 <minecrell> Isn't Git history a better source for it anyway?
2020-01-30 18:51:17 <_ikke_> yes
2020-01-30 18:51:19 <_ikke_> exactly
2020-01-30 18:53:57 <Cogitri> fcolista: I don't think the license on volatility3 is correct, seems like it uses its own license and not a SPDX one
2020-01-30 18:56:44 <fcolista> Cogitri, you are right
2020-01-30 18:58:04 <fcolista> I'm going to update it. Thanks a lot!
2020-01-30 19:00:12 <mps> hmmm, forgot to add with 5.6 we will get RPi4 support in mainline
2020-01-30 19:00:25 <Cogitri> Thanks :)
2020-01-30 19:05:28 <wsinatra> I like it, there are people working on larger projects like SBCL that don't want to contribute directly to the packages, but who create patches that enable us to build for our platform
2020-01-30 19:05:40 <wsinatra> it's a nice little note to give them credit I think
2020-01-30 19:07:15 <mps> wsinatra: I see it as address where people can complain if something does not work as people expect
2020-01-30 19:07:38 <mps> besides maintainer, ofc
2020-01-30 19:08:59 <wsinatra> That's a fair argument too, in my example we wouldn't be building SBCL if it wasn't for Eric Timmon's musl patches, since the SBCL devs haven't commented on making any changes to help build outside of glibc
2020-01-30 19:09:21 <wsinatra> so I suppose, if something breaks, he's as good, if not a better, technical resource than I am as teh maintainer :)
2020-01-30 19:09:59 <_ikke_> but that's just a very specific case
2020-01-30 19:10:32 <wsinatra> Absolutely, it probably doesn't help to have a massive list of people on most of the packages
2020-01-30 19:11:52 <_ikke_> 81a0830067230d261045fe4854b5abcdbf34f9b6
2020-01-30 19:12:08 <_ikke_> just an abump
2020-01-30 19:15:04 <mps> eh, some people like their names in project (even if anonymous in that case
2020-01-30 19:15:05 <kaniini> mps: i am not comfortable in shipping kernel 5.6 since it wont be LTS
2020-01-30 19:15:38 <mps> kaniini: other option is backport all fixes
2020-01-30 19:15:54 <wsinatra> mps: that's how I personally feel, I enjoy contributing to FOSS projects, and take a lot of pride when I do.
2020-01-30 19:16:02 <kaniini> there is a third option: postpone shipping musl 1.2 until next cycle.
2020-01-30 19:16:13 <kaniini> i'll write an email outlining all 3 options and we can go from there
2020-01-30 19:16:35 <mps> kaniini: and lost dalias as alpine user ;P
2020-01-30 19:16:47 <kaniini> who cares
2020-01-30 19:17:02 <kaniini> i wasn't aware that we were making decisions to make single individual users happy
2020-01-30 19:17:11 <mps> hmmm, hope you are not serious
2020-01-30 19:17:17 <kaniini> i am quite serious
2020-01-30 19:18:07 <mps> I prefer to keep knowledgeable people with us
2020-01-30 19:18:26 <kaniini> you assume he will not be 'with us', as the, by far, primary consumer of musl
2020-01-30 19:19:42 <mps> no, I have impression that he is more irritated with latest kernel issue
2020-01-30 19:20:47 <kaniini> at any rate, we have to make decisions that support stable, reliable releases
2020-01-30 19:21:01 <kaniini> jumping to time64 when it is not ready in the kernel and there is no LTS time64 kernel is not a good decision
2020-01-30 19:21:37 <mps> wsinatra: I put my full name in maintainer or contributor fields because I stand behind work I do and all can have address to complain, not because of pride
2020-01-30 19:22:10 <mps> wsinatra: else, I will be anonymous here
2020-01-30 19:22:31 <mps> kaniini: yes, not easy decision I know
2020-01-30 19:23:55 <mps> kaniini: because that I wrote about kernel upgrade so we can start thinking about that in advance
2020-01-30 19:24:22 <kaniini> well, write to alpine-devel about it not irc
2020-01-30 19:24:47 <kaniini> or i can :)
2020-01-30 19:25:03 <kaniini> but i am not personally convinced time64 is a good goal for this release
2020-01-30 19:25:04 <mps> you were left us when I expressed my problem with ML switch to new system
2020-01-30 19:25:34 <mps> I read MLs but don't post there
2020-01-30 19:26:31 <mps> so, please write there, if you have time and will ofc
2020-01-30 19:26:48 <kaniini> and why can you not post there, exactly?
2020-01-30 19:27:08 <kaniini> because having a mailing list that people cannot use is not very useful
2020-01-30 19:27:09 <mps> can we about this on PM
2020-01-30 19:27:13 <kaniini> sure
2020-01-30 19:33:16 <wsinatra> mps: I can definitely see that, you're one of the more active people here too
2020-01-30 19:35:37 <kaniini> i really do not give a rats ass if people dislike the software running the ML, it exists for a reason and boycotting the ML over something petty like that harms the project's ability to make coherent decisions, as people will have to go dig through 3 years of IRC logs in the future to find out why some decision was made
2020-01-30 19:37:21 <kaniini> if you dislike the sr.ht software, the correct procedure is to engage with the infra team to deploy an alternative that has the same or less resource impact for the infra team
2020-01-30 19:38:16 <kaniini> and that is to everyone who chooses to not participate correctly because they dislike the software
2020-01-30 19:38:50 <kaniini> if you dislike it to the point that you boycott using the MLs, actively work to get it replaced with something else.
2020-01-30 19:40:13 <Cogitri> Well, we have a GitLab
2020-01-30 19:40:20 <kaniini> no
2020-01-30 19:40:32 <mps> kaniini: this is discussed few times here and I think we shouldn't again
2020-01-30 19:40:45 <Cogitri> But IMHO the ML is ok-ish for discussions, I just feel that it's not the right tool for patches, but that depends on your workflow
2020-01-30 19:40:52 <kaniini> you are right.  there will be no further discussion.
2020-01-30 19:41:18 <Cogitri> I try to participate in discussions on alpine-devel but reviewing patches is just too much of a pain
2020-01-30 19:41:39 <kaniini> that's not what we are talking about
2020-01-30 19:42:25 <kaniini> gitlab is fine for reviews, but the ML exists for policy discussion.
2020-01-30 19:42:30 <kaniini> so, here's the bottom line
2020-01-30 19:42:46 <kaniini> if you guys want to boycott using the ML, great, you do you.
2020-01-30 19:42:52 <_ikke_> And some people still prefer mailing lists for patches
2020-01-30 19:43:09 <_ikke_> And we still cater for them
2020-01-30 19:43:16 <kaniini> if you guys boycott the ML and policy discussion involving your package occurs, then you may wish to reconsider that decision
2020-01-30 19:43:26 <kaniini> because if you don't, we will just make the decision without you
2020-01-30 19:44:21 <kaniini> because we are not going to do this whole "dig through years of IRC logs to find discussions about policy decisions" thing.  we cannot operate like that
2020-01-30 19:45:06 <Cogitri> Yes, IRC isn't a suitable tool for that
2020-01-30 19:45:35 <Cogitri> _ikke_: Yup, we still allow patches via the ML, it's just that there aren't *that* many people actually looking at those patches
2020-01-30 19:46:10 <_ikke_> Mostly Leo an me
2020-01-30 19:46:12 <kaniini> and this isn't about patches.  if you like the aports list, use it, if you don't, use gitlab
2020-01-30 19:46:29 <kaniini> this is about important decisions like "do we use a time64 kernel or do we use an LTS kernel"
2020-01-30 19:47:12 <mps> more problem are solved over irc than ML and/or issue/bug reports
2020-01-30 19:47:15 <kaniini> "do we upgrade to GCC 10 or do we stay with GCC 9.2"
2020-01-30 19:47:32 <kaniini> mps: yes, but i am talking about *big* decisions, we have always used the ML for those
2020-01-30 19:47:39 <Cogitri> mps: More *small* problems are solved over IRC :l
2020-01-30 19:47:43 <kaniini> so we can search it and know why we did something
2020-01-30 19:47:54 <_ikke_> and more people have the opportunity to chime in
2020-01-30 19:47:55 <mps> even big decision are solved over irc
2020-01-30 19:48:01 <_ikke_> rather than the people online right now
2020-01-30 19:48:11 <Cogitri> Yup
2020-01-30 19:48:22 <Cogitri> And it's easy to miss something on IRC
2020-01-30 19:48:25 <kaniini> mps: yes, that has ticked upward.  what i am saying is that we need to stick to what we have historically done.
2020-01-30 19:48:35 <wsinatra> Could issues not be discussed in real time on the IRC and then communicated for further discussion via the ML?
2020-01-30 19:48:38 <Cogitri> (Both due to being offline or just by not paying attention for a little)
2020-01-30 19:49:07 <kaniini> wsinatra: sure, but "i don't wish to post to the ML about something i want to drive because i hate the software" is not acceptable
2020-01-30 19:49:20 <mps> well, we have a good muscle to adapt
2020-01-30 19:49:23 <_ikke_> wsinatra: that's often what happens
2020-01-30 19:50:31 <kaniini> when there were like 10 people using alpine (including me), this was actually one of the bad habits we didn't pick up
2020-01-30 19:50:33 <wsinatra> _ikke_: that's kind of what I've noticed, it feels like the issue is artificial and the people naturally discuss here, and later bring issues to the ML when they're developed enough for global discussion
2020-01-30 19:50:59 <_ikke_> wsinatra: the issue is that some people are unhappy about the ML atm
2020-01-30 19:51:04 <kaniini> wsinatra: it is not artificial, but thankfully involves a limited number of people who refuse to use the ML
2020-01-30 19:51:35 <kaniini> and if these people dislike the ML as it currently is, they should work with infra to fix it
2020-01-30 19:51:39 <kaniini> not boycott it
2020-01-30 19:51:52 <kaniini> nothing is set in stone
2020-01-30 19:52:16 <kaniini> we do not have to use the sr.ht software as it is maintained by ddevault, we really can modify it to suit our needs
2020-01-30 19:52:17 <wsinatra> hmm that makes more sense, I'm obviously outside that circle, but would like to see things run smoothly.
2020-01-30 19:52:21 <kaniini> or we can use a different software
2020-01-30 19:52:30 <kaniini> in the grand scheme of things, it really does not matter
2020-01-30 19:52:33 <mps> kaniini: I agree
2020-01-30 19:52:51 <kaniini> so do it?
2020-01-30 19:52:53 <mps> but I don't have enough nerves to go for that
2020-01-30 19:53:19 <mps> I prefer other works, fixes mostly
2020-01-30 19:54:17 <kaniini> the fact that we have the capability to modify the software in question is the beauty of software freedom
2020-01-30 19:54:51 <kaniini> refusing to follow best practice for driving issues in alpine simply because you dislike the ML though just harms alpine
2020-01-30 19:55:02 <kaniini> it does not cause the software to be changed
2020-01-30 19:55:10 <kaniini> (either through replacement or modification)
2020-01-30 19:55:27 <mps> well, I hope I can be useful to alpine even if I don't post to ML
2020-01-30 19:56:08 <kaniini> obviously you can, but time64 is an issue that absolutely needs to be discussed on ML and decided upon
2020-01-30 19:56:33 <kaniini> so if you do not wish to post to ML, maybe you should not participate in the maintenance of packages that require ML discussion for changes
2020-01-30 19:56:47 <mps> now I'm with Cogitri, we can open issue on gitlab.a.o about this
2020-01-30 19:57:23 <kaniini> 
ACTION eyerolls

2020-01-30 19:57:32 <_ikke_> gitlab issues have no visibility to be honest
2020-01-30 19:57:50 <kaniini> yes, which means the gitlab issue still has to be forwarded to the ML
2020-01-30 19:58:30 <Cogitri> Fair point
2020-01-30 19:58:59 <Cogitri> We could have an repo for RFCs and just have people who are interested in decision making subscribe to that repo tho
2020-01-30 19:59:19 <wsinatra> is sr.ht that bad to work with? It's just an email starting teh discussion isn't it? Even if you include snippets of IRC chat/links to issues, it's just an email after a point?
2020-01-30 19:59:29 <mps> kaniini: personally I prefer MLs for decision and serious issues discussions
2020-01-30 20:00:09 <mps> and on most other 'works' I use them
2020-01-30 20:00:14 <kaniini> then perhaps you should deal with the fact that you dislike the ML software
2020-01-30 20:00:30 <Cogitri> wsinatra: it's not sr.ht's fault, IMHO emails are just a bit clunky (but I don't mind it _that_ much, the ML works for me somewhat well)
2020-01-30 20:01:07 <mps> already told all what I had to told
2020-01-30 20:01:15 <mps> going to coffee :)
2020-01-30 20:01:35 <kaniini> mps: and if infra team makes the requested change, will you use the ML?
2020-01-30 20:02:10 <mps> sure
2020-01-30 20:02:43 <kaniini> okay
2020-01-30 20:02:56 <mps> but I don't want to put burden on infra team because of my personal preferences
2020-01-30 20:04:44 <mps> if all other members fine with current situation I don't want to ask for any change
2020-01-30 20:09:17 <kaniini> according to the lists.sr.ht source, you should be receiving a copy of your mails sent there
2020-01-30 20:09:19 <kaniini>     recipients = set([a[1] for a in getaddresses(froms + tos + ccs)])
2020-01-30 20:09:59 <mps> yes, author told me that, but it is not active afaik
2020-01-30 20:10:05 <kaniini> it is hardcoded
2020-01-30 20:10:27 <mps> do you receive your posts?
2020-01-30 20:10:32 <kaniini> yes
2020-01-30 20:10:47 <mps> ah, maybe it is changed in meantime
2020-01-30 20:10:50 <kaniini> however, i think i have a duplicate subscription
2020-01-30 20:11:01 <mps> ahm
2020-01-30 20:11:16 <mps> the solution is simple :D
2020-01-30 20:12:22 <kaniini> oh i see
2020-01-30 20:12:44 <kaniini> https://git.sr.ht/~sircmpwn/lists.sr.ht/tree/master/listssrht/process.py#L64
2020-01-30 20:12:53 <kaniini> [...] if to in recipients: continue
2020-01-30 20:13:27 <kaniini> so we add config option to change how recipients is composed
2020-01-30 20:13:34 <kaniini> and we enable it on our stuff
2020-01-30 20:13:37 <kaniini> i will deal with this
2020-01-30 20:13:56 <_ikke_> kaniini: +1
2020-01-30 20:13:57 <mps> thanks, really reallu thanks
2020-01-30 20:14:06 <mps> uh
2020-01-30 20:14:17 <kaniini> well
2020-01-30 20:14:21 <kaniini> i will not deal with the sysadmin side of it
2020-01-30 20:14:24 <kaniini> but i will write the patch
2020-01-30 20:14:32 <mps> s/reallu/really/
2020-01-30 20:14:32 <alpine-meetbot> mps meant to say: thanks, really really thanks
2020-01-30 20:14:34 <kaniini> and ddevault can accept it or not
2020-01-30 20:14:39 <_ikke_> yup
2020-01-30 20:14:53 <kaniini> i am sure the infra team would not mind carrying a trivial patch to fix this issue
2020-01-30 20:15:19 <kaniini> i mean, we have already deviated from sr.ht code anyway by allowing html
2020-01-30 20:16:43 <_ikke_> That's something ddevault added themselves
2020-01-30 20:19:26 <kaniini> anyway, i doubt ddevault would reject a patch adding a config option
2020-01-30 20:31:12 <kaniini> _ikke_: https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/9681
2020-01-30 20:31:23 <kaniini> _ikke_: pls do the needful so we cna get this email drama behind us :D
2020-01-30 20:32:52 <_ikke_> Let's first wait on ddevault
2020-01-30 20:33:42 <kaniini> ddevault: i will literally *pay you* to merge this
2020-01-30 21:47:45 <mps> did I made mess in 3.11-stable by pushing community/gcc6 fix?
2020-01-30 21:51:09 <_ikke_> mps: Why would you think so?
2020-01-30 21:51:49 <mps> well, looking at web interface all looks fine, but my local clone is messed
2020-01-30 21:52:21 <mps> maybe I should remove local 3.11-stable branch and checkout it again
2020-01-30 21:53:18 <Cogitri> I'd recommend you to not work directly on the 3.11-branch
2020-01-30 21:54:02 <Cogitri> But to instead made a 3.11-$pkgname branch, do your changes on that and then push to 3.11-stable when you feel like it
2020-01-30 21:54:20 <mps> usually I do that
2020-01-30 21:54:33 <Cogitri> (Also, instead of deleting and checking out you should probably just `git reset --hard origin/3.11-stable`)
2020-01-30 21:55:29 <mps> also this, but didn't helped to fix mess
2020-01-30 21:56:33 <mps> I made something bad this time, luck is it is local
2020-01-31 04:16:48 <ToBeLinux> Hello! Does anyone have any idea how to install LXDE on Alpine? I have been searching left and right and got nowhere, unfortunately.
2020-01-31 06:48:31 <ncopa> morning. did you see https://pythonspeed.com/articles/alpine-docker-python/
2020-01-31 06:55:59 <Cogitri> Yup
2020-01-31 06:56:16 <Cogitri> The only valid thing is the musl allocator being slower, I suppose
2020-01-31 06:56:49 <Cogitri> We can't really do something about people being unable to install wheels when they don't support musl
2020-01-31 06:58:30 <ncopa> is there anything we can do to get musl built wheels?
2020-01-31 06:58:43 <ncopa> what would it take?
2020-01-31 06:58:48 <Cogitri> (Other than packaging the thing of course, the author could have just done `apk add` for that package...)
2020-01-31 07:08:00 <mps> I read some comments about article (when it announced on phoronix) and see that most people thinks that is not well written and misleading
2020-01-31 07:14:00 <Cogitri> ncopa: Get Python upstream to build them, I suppose
2020-01-31 07:14:22 <Cogitri> I don't know Python too well but wheels are basically binary packages
2020-01-31 07:18:57 <ncopa> https://stackoverflow.com/questions/57217763/how-to-maintain-glibc-and-libmusl-python-wheels-in-the-same-pip-repository
2020-01-31 08:57:07 <_ikke_> ncopa: what I read is that pypi package maintainers are responsible themselves for providing wheels
2020-01-31 08:58:08 <_ikke_> ie, the problem is that they don't provide any wheels that are compatible with musl
2020-01-31 08:58:15 <minecrell> You build them locally usually, then upload them
2020-01-31 08:58:22 <_ikke_> https://news.ycombinator.com/item?id=22185320
2020-01-31 08:58:40 <_ikke_> which means that most users will only upload wheels built against glibc
2020-01-31 09:00:21 <ncopa> the stackoverflow article above asks how to build it with musl
2020-01-31 09:00:30 <ncopa> but i think it is not possible at the moment
2020-01-31 09:00:57 <ncopa> i think we should fix our python and fix python so python devs can build their wheels with alpine
2020-01-31 09:01:13 <ncopa> and i'd like it to be simpler to build it with alpine than to build it with glibc for them
2020-01-31 09:01:18 <ncopa> :)
2020-01-31 09:01:42 <_ikke_> heh
2020-01-31 09:02:02 <ncopa> currently it is difficul or maybe not even possible
2020-01-31 09:02:10 <ncopa> so no wonder there are noone doing it
2020-01-31 09:02:29 <ncopa> i believe we may need to replace linux-gnu with linux-musl
2020-01-31 09:03:08 <ncopa> i think needs to be fixed: https://github.com/python/cpython/blob/master/configure.ac#L718
2020-01-31 09:04:38 <_ikke_> <arch>-linux-musl?
2020-01-31 09:40:11 <ncopa> yes, i think that would be good
2020-01-31 09:45:03 <Cogitri> Another importanting thing if we want to support that is that we start upstreaming more of our patches, right now lots of stuff to fix projects w/ musl stays downstream
2020-01-31 09:52:27 <fcolista> Cogitri:  aports:master |Francesco Colista| testing/volatility3: fix correct license | http://dup.pw/aports/155c1b82
2020-01-31 09:52:57 <Cogitri> Thanks :)
2020-01-31 09:53:16 <fcolista> ;)
2020-01-31 11:12:38 <clandmeter> ncopa: would an introduction for ABUILD_WORKDIR be ok, or you really want to change the default behaviour?
2020-01-31 11:18:43 <ncopa> dont know
2020-01-31 11:21:07 <clandmeter> i guess for a developer it is nice to have pkg and src inside the startdir
2020-01-31 12:33:23 <Thermi> I've opened an issue about my gcc cross compile problem here: https://gitlab.alpinelinux.org/alpine/aports/issues/11174
2020-01-31 12:33:23 <Thermi> Any help is greatly appreciated. :)
2020-01-31 12:34:38 <mps> Thermi: what are you trying? to cross compile gcc?
2020-01-31 12:35:03 <Thermi> mps: Generally bootstrap Alpine for aarch64. It fails when trying to build gcc for the first time
2020-01-31 12:35:09 <mps> #11174
2020-01-31 12:35:52 <mps> do you use scripts/bootstrap.sh
2020-01-31 12:36:10 <Thermi> Yes
2020-01-31 12:36:20 <Thermi> Only that.
2020-01-31 12:37:01 <mps> looks strange, but I couldn't conclude what are cause
2020-01-31 12:43:00 <mps> only what can do, I can try locally to build, but not now (no time) maybe later this night, to see will it work here
2020-01-31 12:48:11 <nmeum> mps: just reading through the commit backlog today: shouldn't 89c323e648ed3e68b57790d8e25e35b1e9920242 require a bunch of rebuilds?
2020-01-31 12:48:29 <nmeum> e.g. of wireguard-lts, drdb-lts, xtables-addons-lts, …
2020-01-31 12:50:06 <mps> nmeum: isn't ncopa rebuilt all this?
2020-01-31 12:50:10 <Thermi> mps: If it's any help, I built in a new alpine:3.11 docker container
2020-01-31 12:50:29 <nmeum> mps: oh, indeed, the commit are just located a bit later in the commit log
2020-01-31 12:50:39 <nmeum> *commits
2020-01-31 12:50:42 <nmeum> sorry for the noise
2020-01-31 12:50:51 <mps> nmeum: np :)
2020-01-31 12:51:27 <mps> Thermi: it shouldn't matter if you build in docker or 'native'
2020-01-31 12:51:42 <Thermi> mps: Yes, it "shouldn't" :)
2020-01-31 12:51:50 <mps> :)
2020-01-31 13:52:25 <fabled> ncopa, something is broke in abuild when trying to cross-compile (run bootstrap.sh)
2020-01-31 13:55:07 <fabled> oh wait, i think it's something on me
2020-01-31 13:58:37 <mps> fabled: is it similar to this #11174
2020-01-31 14:02:51 <daemon> hey all what would I have to do if I had a docker running alpine minirootfs, and I wanted to build the alpine sources and target a /mnt/target for later use as a base image - but I did not want there to be any statically linked binaries (busy box etc)
2020-01-31 14:03:49 <mps> busybox is not statically linked
2020-01-31 14:04:04 <daemon> oh I thought all the core utils apk etc was
2020-01-31 14:04:07 <daemon> including busybox
2020-01-31 14:04:13 <daemon> my fault
2020-01-31 14:04:28 <mps> there is separate busybox-static apk
2020-01-31 14:04:37 <mps> it is not installed by default
2020-01-31 14:04:55 <daemon> when I start a system with: ADD assets/ospkg/alpine-minirootfs-3.11.3-x86_64.tar.gz /
2020-01-31 14:05:06 <daemon> it seemed to be
2020-01-31 14:05:22 <clandmeter> to be what? static?
2020-01-31 14:05:27 <daemon> yes
2020-01-31 14:05:35 <clandmeter> which ones? apk?
2020-01-31 14:05:38 <daemon> let me run tat container
2020-01-31 14:05:56 <clandmeter> why would you create a container like that anyway?
2020-01-31 14:06:06 <clandmeter> thats same as doing FROM alpine
2020-01-31 14:06:17 <daemon> because where this is built has 0 internet connectivity
2020-01-31 14:06:21 <daemon> all sources have to be local
2020-01-31 14:06:35 <clandmeter> how do you get the minirootfs without uinternet?
2020-01-31 14:06:39 <clandmeter> :p
2020-01-31 14:06:53 <daemon> phone + laptop + usb
2020-01-31 14:06:55 <daemon> ;)
2020-01-31 14:07:09 <daemon> and yeah
2020-01-31 14:07:17 <clandmeter> if its in your registry it needs no internet
2020-01-31 14:07:24 <daemon> https://i.itsosticky.com/u1j0yi.png
2020-01-31 14:07:28 <clandmeter> and you could also dump the image
2020-01-31 14:07:42 <clandmeter> but hey, its your life :)
2020-01-31 14:08:03 <clandmeter> this means its static?
2020-01-31 14:08:06 <fabled> mps, no, i had dirty system so "apk add" was reporting errors. i was thinking to try if bootstrap.sh works still on clean system. so far so good. i suspect #11174 is due to broken system or build (e.g. binutils-aarch64 built wrong earlier)
2020-01-31 14:08:08 <daemon> I thought so
2020-01-31 14:08:13 <clandmeter> no
2020-01-31 14:08:22 <clandmeter> it means all utils are in a single binary
2020-01-31 14:08:38 <daemon> I thought that is what static meant
2020-01-31 14:08:43 <daemon> how do I get it to not do that
2020-01-31 14:08:44 <clandmeter> if you use the static one it will include musl
2020-01-31 14:09:12 <clandmeter> you cannot
2020-01-31 14:09:15 <daemon> I basically just want each binary to be its own
2020-01-31 14:09:25 <clandmeter> maybe busybox has a build option for it, i dont know.
2020-01-31 14:09:36 <clandmeter> but that would increase the size
2020-01-31 14:09:55 <clandmeter> you could technically copy all of the applets to its own file :)
2020-01-31 14:09:55 <daemon> can't I simply cmopile each of these and target /mnt/target then copy from that to the base of a scratch image?
2020-01-31 14:10:33 <clandmeter> can you explain what you are t rying to accomplish?
2020-01-31 14:10:43 <clandmeter> you dont want to include some of those tools?
2020-01-31 14:10:47 <daemon> all of them
2020-01-31 14:10:51 <daemon> in that form
2020-01-31 14:10:58 <mps> fabled: I started it on my clean lxc to see does it works now './bootstrap.sh aarch64' is ok for test?
2020-01-31 14:11:16 <clandmeter> daemon: i dont follow
2020-01-31 14:11:18 <daemon> basically I want a linux image that has a /bin/su and the rest of a very base system
2020-01-31 14:11:30 <daemon> and that is all, I do not want them to be part of busy box
2020-01-31 14:11:44 <daemon> I want them to be as if they was compiled and installed there
2020-01-31 14:11:50 <daemon> almost like base install of gentoo goes
2020-01-31 14:12:16 <daemon> so in the end I would have a linux base image, with no busy box but a selection of common biniaries
2020-01-31 14:12:33 <clandmeter> if you dont want busybox use coreutils
2020-01-31 14:12:49 <clandmeter> or anything that is remotly similar and does not blow up your system
2020-01-31 14:13:23 <daemon> can I just compile coreutils/binutils/gcc on my current alpine image use -sysroot or -prefix and then copy the resultant binaries to scratch
2020-01-31 14:13:27 <daemon> and it *should* work?
2020-01-31 14:13:40 <clandmeter> well you will also need a shell
2020-01-31 14:13:40 <_ikke_> why compile? most tools are available via apk
2020-01-31 14:13:59 <daemon> _ikke_, won't be helpful in 10 years time when this thing needs rebuilding
2020-01-31 14:14:03 <daemon> or 50 years
2020-01-31 14:14:06 <daemon> or 1000 years
2020-01-31 14:14:16 <daemon> the ticket is basically it should be rebuildable without internet
2020-01-31 14:14:21 <daemon> anywhere at anytime
2020-01-31 14:14:22 <daemon> with no restraint
2020-01-31 14:14:27 <daemon> all sources MUST be kept with hte dockerfile
2020-01-31 14:14:30 <clandmeter> i dont think its easy to replace busybox in alpine, but its doable for sure.
2020-01-31 14:14:48 <daemon> clandmeter, yeah I would grab a copy of bourneshell for sure
2020-01-31 14:15:00 <AinNero> daemon: alpine is shipping precompiled binaries. if from source is your requirement, you might be wrong here
2020-01-31 14:15:34 <daemon> AinNero, from what I can gather, the correct thing to do is use a linux (any you like) to build the appropriate things and then install it onto a blank image
2020-01-31 14:15:38 <AinNero> if you go that way, you will understand later why people use busybox in the furst place
2020-01-31 14:15:46 <daemon> I thought alpine was as good a thing as any to start with
2020-01-31 14:15:49 <AinNero> s/furst/first/
2020-01-31 14:15:49 <alpine-meetbot> AinNero meant to say: if you go that way, you will understand later why people use busybox in the first place
2020-01-31 14:15:54 <daemon> as I have got a system with no external resources with it
2020-01-31 14:16:05 <AinNero> check musl-cross-make
2020-01-31 14:16:18 <daemon> alpine-meetbot, well I meant to survive LFS so I presumed it would not be so bad
2020-01-31 14:16:18 <AinNero> sabotage linux had similar efforts
2020-01-31 14:16:31 <daemon> but I have pretty much zero experience with musl
2020-01-31 14:16:35 <_ikke_> daemon: alpine-meetbot is as its name says, a bot
2020-01-31 14:16:37 <_ikke_> .bot
2020-01-31 14:16:41 <_ikke_> .uptime
2020-01-31 14:16:41 <alpine-meetbot> I've been sitting here for 70 days, 17:04:19 and I keep going!
2020-01-31 14:16:47 <daemon> _ikke_, ah
2020-01-31 14:16:57 <daemon> it reacted to the regex
2020-01-31 14:17:02 <daemon> :)
2020-01-31 14:17:11 <_ikke_> hehe
2020-01-31 14:17:32 <AinNero> sometimes algitbot also reacts to users
2020-01-31 14:17:38 <AinNero> algitbot: nice that you are here!
2020-01-31 14:17:44 <_ikke_> w00t
2020-01-31 14:17:54 <daemon> hmmm
2020-01-31 14:17:56 <daemon> interesting idea
2020-01-31 14:17:56 <clandmeter> some languages don't even have regex ;-)
2020-01-31 14:18:18 <daemon> hey guys what would happen if I compiled 'file' 'zcat' etc and unlinked the /bin/zcat type things
2020-01-31 14:18:22 <daemon> and installed the source build version
2020-01-31 14:18:44 <AinNero> nothing bad i guess
2020-01-31 14:18:54 <daemon> might be a way to get around it
2020-01-31 14:19:07 <AinNero> what was your problem with busybox?
2020-01-31 14:19:24 <daemon> AinNero, its not in the spec for the project
2020-01-31 14:19:30 <daemon> and that means I have to explain its presence
2020-01-31 14:19:32 <clandmeter> Crap
2020-01-31 14:19:46 <clandmeter> This Intel driver issue...
2020-01-31 14:19:48 <AinNero> just say its a lightweight coreutils replacement
2020-01-31 14:20:15 <daemon> AinNero, I will also need to explain what coreutils is and then write a report about the exact differences between them
2020-01-31 14:20:23 <daemon> and I really do not want to
2020-01-31 14:20:43 <mps> clandmeter: yes, 30 mins ago again had firefox OOM :(
2020-01-31 14:20:51 <AinNero> if you use coreutils, you are gonna have to explain that to them
2020-01-31 14:21:00 <mps> with linux-lts 5.4.16
2020-01-31 14:21:18 <daemon> AinNero, coreutils is already ok'd as its in place on almsot all current projects
2020-01-31 14:22:50 <AinNero> if being 'already ok' is an requirement, you are wrong in this place
2020-01-31 14:23:08 <AinNero> both musl and busybox are quite uncommon/new
2020-01-31 14:23:23 <daemon> the issue is not so much musl more busybox
2020-01-31 14:23:35 <daemon> all the postgres containers are alpine based
2020-01-31 14:23:35 <AinNero> how would you explain musl to them?
2020-01-31 14:23:36 <mps> busybox is not new
2020-01-31 14:24:21 <daemon> indeed I think I remember using busybox ages ago on some debian rescue shell or something
2020-01-31 14:24:29 <AinNero> mps: newer than i am
2020-01-31 14:24:51 <mps> AinNero: :)
2020-01-31 14:25:37 <mps> daemon: all software have bugs, new or old
2020-01-31 14:26:12 <AinNero> daemon: the postgres containers also have both musl and busybox
2020-01-31 14:29:56 <daemon> AinNero, indeed but this particular base image is for perl/odoo/mono and a few other's that until now have been running on .. let me get this bit right I think debian 7?
2020-01-31 14:29:57 <daemon> maybe
2020-01-31 14:29:59 <daemon> something like that
2020-01-31 14:30:10 <daemon> and are now utterly unbuildable
2020-01-31 14:30:41 <daemon> so ... the requirement / want is to have a base linux image (well 2 technically, 1 with gcc one without)
2020-01-31 14:30:52 <daemon> so that all future projects can be built on it and also be rebuildable at any point going forwards
2020-01-31 14:31:03 <daemon> quite how to pull this off ... is what I am trying to figure out
2020-01-31 14:32:01 <AinNero> try to self-compile gcc plus dependencies, and then you might understand
2020-01-31 14:32:16 <daemon> I have done for glibc quite a few times but never musl
2020-01-31 14:32:27 <daemon> cannot be that bad surely
2020-01-31 14:32:31 <AinNero> and it worked on first attempt?
2020-01-31 14:32:38 <daemon> the glibc one? yes
2020-01-31 14:33:16 <daemon> the musl one seems to have an issue with mpc and the target platform being unknown
2020-01-31 14:33:50 <AinNero> so you should be able to bootstrap from there
2020-01-31 14:33:59 <daemon> indeed I could
2020-01-31 14:34:13 <daemon> but I thought I would at least try do it with musl
2020-01-31 14:35:36 <Thermi> fabled: I'm building the whole thing again now
2020-01-31 14:40:06 <_ikke_> north1: inotify-tools fails on armv7
2020-01-31 14:40:11 <_ikke_> and armhf
2020-01-31 14:42:11 <mps> _ikke_: I looked but can't build log
2020-01-31 14:43:21 <_ikke_> mps: https://tpaste.us/9N9Z
2020-01-31 14:43:32 <north1> _ikke_ (IRC): Yeah, i thought it was just a flaky test, because CI failed on x86 and x86_64 and worked in the builders
2020-01-31 14:43:59 <mps> yes, got for armhf '>>> ERROR: inotify-tools: check failed'
2020-01-31 14:46:03 <north1> Can the test-suite.log be extracted from the builder ?
2020-01-31 14:49:14 <_ikke_> for libnotifytools?
2020-01-31 14:49:28 <north1> yes
2020-01-31 14:49:31 <_ikke_> https://tpaste.us/naQ9
2020-01-31 14:50:13 <north1> inotifytools_error() returns 28 (No space left on device)
2020-01-31 14:50:16 <mps> hehe
2020-01-31 14:50:47 <mps> I like simple to fix bugs
2020-01-31 14:51:11 <_ikke_> that builder has 50G free
2020-01-31 14:51:14 <_ikke_> 60G
2020-01-31 14:52:11 <_ikke_> so no clue why it gets that error
2020-01-31 14:53:00 <mps> is it usa4?
2020-01-31 14:53:06 <_ikke_> yes
2020-01-31 14:53:29 <mps> I can try in lxc there
2020-01-31 14:53:43 <_ikke_> fine wih me
2020-01-31 14:54:23 <mps> will be at workstation in about 10-15 minutes
2020-01-31 15:02:39 <kaey> daemon: take a look at buildroot
2020-01-31 15:02:57 <kaey> https://buildroot.org/
2020-01-31 15:05:18 <daemon> kaey, that looks hand for this, cheers
2020-01-31 15:07:18 <mps> _ikke_: north1: main/inotify-tools build in armv7 on usa4 worked cleanly
2020-01-31 15:07:36 <mps> test passed
2020-01-31 15:07:40 <Thermi> Build fails
2020-01-31 15:07:57 <mps> Thermi: ?
2020-01-31 15:08:16 <Thermi> mps: bootstrap.sh build fails at gcc in clean, new docker container alpine:3.11
2020-01-31 15:08:26 <Thermi> Will provide logs shortly
2020-01-31 15:09:00 <mps> Thermi: yes, also failed in my clean lxc
2020-01-31 15:09:19 <mps> it is dependency issue, I think
2020-01-31 15:09:26 <Thermi> No, fails during building
2020-01-31 15:09:52 <north1> mps (IRC): problably a configuration on the builder ? the error is related to the number of inotify watches created
2020-01-31 15:10:12 <Thermi> libtool: link: cannot find the library `../../libatomic/libatomic_convenience.la' or unhandled argument `../../libatomic/libatomic_convenience.la'
2020-01-31 15:10:40 <mps> here is end of my build log http://tpaste.us/za91
2020-01-31 15:11:02 <Thermi> My log here contains all commands and their outputs, too
2020-01-31 15:11:04 <Thermi> It's 5 MB
2020-01-31 15:11:10 <Thermi> Give me a second
2020-01-31 15:11:11 <mps> uh, I have gcc6
2020-01-31 15:11:19 <Thermi> gcc9
2020-01-31 15:12:36 <mps> gcc6, tested yesterday bugs, and forgot to deinstall
2020-01-31 15:14:22 <mps> hmm, we need these gcc 9.2 fixes pushed
2020-01-31 17:11:33 <_ikke_> north1: any idea why sassc would take 24G (arc-theme)
2020-01-31 17:11:48 <north1> no
2020-01-31 17:11:55 <north1> well, most likely a bug
2020-01-31 17:12:08 <_ikke_> yeah, clandmeter just linked to an issue on github
2020-01-31 17:12:10 <_ikke_> https://github.com/sass/libsass/issues/3033\
2020-01-31 17:12:44 <clandmeter> i think it was using double before
2020-01-31 17:12:49 <clandmeter> or it was the other builder
2020-01-31 17:13:09 <_ikke_> someone mentioned it managed to exhaust 64G
2020-01-31 17:15:35 <clandmeter> can we downgrade it for now?
2020-01-31 17:17:24 <_ikke_> apparently more than 1 sass implementations that suffer from this
2020-01-31 17:19:03 <clandmeter> the other dist mentioned is void
2020-01-31 17:19:11 <clandmeter> could it be musl related or did you see others?
2020-01-31 17:24:32 <PureTryOut[m]> Hmm I'd like to package a python package called "pyls". How should that be named in Alpine? `py3-ls`?
2020-01-31 17:25:34 <PureTryOut[m]> Actually nvm, that is the wrong package I'm looking at lol
2020-01-31 17:26:51 <north1> py3-pyls i think
2020-01-31 17:27:01 <north1> i had problems with py3-favicon and py3-pyfavicon
2020-01-31 17:37:29 <Cogitri> I'd do py3-pyls
2020-01-31 17:54:04 <north1> Anyone wants to test !3511 ?
2020-01-31 18:15:43 <wsinatra> systemd for alpine?
2020-01-31 18:16:04 <AinNero> this seems like a bootloader, not a userspace thing
2020-01-31 18:16:48 <wsinatra> That makes sense. Would be interesting if someone ported all of systemd over, would make it possible to get things like JuJu or snapd
2020-01-31 18:17:14 <AinNero> why are you using alpine if you want systemd?
2020-01-31 18:17:40 <_ikke_> systemd-boot != systemd necessarily
2020-01-31 18:17:57 <_ikke_> systemd does not work without glibc
2020-01-31 18:18:17 <wsinatra> I use Alpine because I don't want systemd :)
2020-01-31 18:18:42 <mps> every 'systemd' word in alpine will ruin alpine reputation
2020-01-31 18:19:35 <wsinatra> I'm pretty sure if they grep through logs they'll see these comments pretty consistently
2020-01-31 18:20:15 <AinNero> ye, fork it and rebrand id
2020-01-31 18:20:17 <AinNero> *it
2020-01-31 18:20:28 <_ikke_> Who will maintain it :)
2020-01-31 18:20:36 <wsinatra> by fork it, do you mean take out all of the systemd parts?
2020-01-31 18:20:46 <wsinatra> because that might be a solution ;)
2020-01-31 18:20:53 <mps> well, I know one person with nick _ikke_ :)
2020-01-31 18:21:19 <AinNero> north1 is already volunteered
2020-01-31 18:21:53 <mps> don't worry, musl will not work systemd
2020-01-31 18:22:15 <mps> oh, vice versa
2020-01-31 18:23:45 <north1> None of the provided solutions are good solutions
2020-01-31 18:23:57 <north1> i just like systemd-bootd
2020-01-31 18:26:27 <mps> heh, maybe I should enable u-boot for x86_64 :)
2020-01-31 20:05:20 <LucasRamage[m]> mps: Yes!
2020-01-31 20:25:33 <mps> LucasRamage[m]: I have it in my 'back brain' for long time but didn't made because I'm (wasting time?) trying to make it for some arm64 chromebooks
2020-01-31 21:19:03 <north1> https://wiki.alpinelinux.org/wiki/Bootloaders#systemd-boot