2020-01-01 04:56:45 phew 2020-01-01 04:56:48 almost done with telegram-desktop 2020-01-01 04:56:58 overall, needed a lot of adaptation 2020-01-01 04:57:07 it sets -Werror unconditionally and also in a way that overrides CMAKE_CXX_FLAGS 2020-01-01 04:57:12 so that was... annoying 2020-01-01 04:57:29 ran into 3 different errors due to gcc9, so apparently tdesktop doesn't use gcc9 2020-01-01 11:35:00 https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-ARM-Hardware 2020-01-01 11:35:16 Linux 5.5 Lands Broadcom BCM2711 / Raspberry Pi 4 Bits 2020-01-01 11:36:26 someone with RPi4 and kernel build experience could try to build it on alpine 2020-01-01 12:32:13 might as well do that tomorrow latest 2020-01-01 13:33:18 can someone have a look and eventually merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2652 ? 2020-01-01 13:34:33 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 +1 2020-01-01 18:20:05 <_ikke_> thanks 2020-01-01 20:18:02 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 Doubt it, runit doesn't have integration and features OpenRC has like one-shot services and dependency tracking 2020-01-01 20:18:40 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 and if you're going to runit might as well take s6 instead 2020-01-01 20:20:16 we discussed this few times 2020-01-01 20:20:16 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 imo, s6 is not best option for init 1 2020-01-01 20:21:48 _ikke_: I know, but I don't think that one-shot services are worth the slow boot 2020-01-01 20:21:54 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 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 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 the cmake is confusing, should have just used meson 2020-01-01 20:25:28 _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 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 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 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 qiu3344: alpine is not a 'ricer' distribution, who cares if we shave 1 second off boot 2020-01-01 20:48:21 qiu3344: systemd is fast. should we use systemd? 2020-01-01 20:48:52 yes :D 2020-01-01 20:48:54 my point here being that the init system choice has more to do with usability than speed 2020-01-01 20:49:14 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 same with s6 2020-01-01 20:50:00 I wouldn't say that openrc is easier to understand than runit 2020-01-01 20:50:03 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 qiu3344: openrc matches traditional UNIX way of managing services, basically. runit and s6 do things differently. 2020-01-01 20:50:47 qiu3344: openrc usage comes down to principle of least surprise 2020-01-01 20:51:24 and, as you note, it is possible to use other init systems with alpine already. 2020-01-01 20:51:48 if openrc with its pidfile tracking is the least surprise then it is failing 2020-01-01 20:52:09 north1: i mean in terms of CLI 2020-01-01 20:52:34 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 pmtr? https://troydhanson.github.io/pmtr/ 2020-01-01 20:53:26 yay another init system ;) 2020-01-01 20:53:40 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 long time ago I built debian router with runit as init 1, but now I wouldn't 2020-01-01 20:54:38 i'm slowly replacing start-stop-daemon with supervise-daemon on OpenRC 2020-01-01 20:54:52 so at least we get runit/s6 style supervision, actually daemontools' supervision by djb 2020-01-01 20:54:58 north1: yes, we should really just do a sprint some weekend to get that done 2020-01-01 20:55:30 north1: should I repeat my disagreement :) 2020-01-01 20:56:10 mps (IRC): yes, ncopa put limits where i can touch it (busybox daemons) 2020-01-01 20:56:23 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 kaniini (IRC): sure 2020-01-01 20:57:23 as for busybox daemons, i think it is ok to move them to supervise-daemon eventually 2020-01-01 20:57:31 but busybox daemons are... somewhat finnicky 2020-01-01 20:58:17 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 dbus + wpa_cli + wpa_supplicant + low-memory-monitor + dhcpcd 2020-01-01 20:58:55 i think 1MB is reasonable, but maybe we can cut it down a little more 2020-01-01 20:59:49 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 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 like basically every UBNT device ever 2020-01-01 21:01:15 i have a usecase for this ^ 2020-01-01 21:01:22 box with 5 ports 2020-01-01 21:01:23 kaniini: I would prefer kernel index for interface names 2020-01-01 21:01:27 and shitting ordering 2020-01-01 21:01:31 mps: i can add that as well 2020-01-01 21:02:02 mps: made a note to add it in v0.2 2020-01-01 21:02:42 thanks, but be careful, sometimes kernel indexing is not 'stable' :) 2020-01-01 21:04:04 anyway, i need to figure out how to make sure macifrename init script runs before networking 2020-01-01 21:04:16 i guess depend() { before net } 2020-01-01 21:04:48 think so 2020-01-01 21:04:54 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 _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 ah, now eth0 is eth0 :) 2020-01-01 22:02:54 AinNero: i'll commit it in upstream aports repo this evening :) 2020-01-01 22:13:57 is gnu coreutils bad? 2020-01-01 22:15:34 <_ikke_> imho, not necessarily 2020-01-01 22:32:49 dunno, been reading a lot of people saying gnu coreutils is bad or bloated/poorly designed 2020-01-01 22:32:54 wanna understand why 2020-01-01 22:34:37 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 @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 north1: heh, ok. you deserve rest. enjoy if like markets :) 2020-01-01 23:56:50 https://gitlab.alpinelinux.org/Leo/aports/-/jobs/29775 :D 2020-01-02 04:46:08 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 left comment 2020-01-02 04:50:46 replied, will push another commit in a bit 2020-01-02 04:51:14 sorry, been kind of distracted today 2020-01-02 04:51:19 could have caught that in the first one 2020-01-02 04:52:52 np :) just pushed the change 2020-01-02 04:53:05 thanks for creating the port in the first place 2020-01-02 07:01:31 phew 2020-01-02 07:01:36 finally got telegram-desktop to work 2020-01-02 07:07:27 @mps 5.4.7 seems to have fixed my issues with hangups 2020-01-02 07:51:30 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 clandmeter I joined 2020-01-02 08:56:53 what’s up? 2020-01-02 08:58:47 monado: this is devel 2020-01-02 08:59:01 Oh, didn’t read 2020-01-02 09:24:10 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 I'll give alpine a spin on AMD Zen 2 next week when I get the new chip 2020-01-02 09:27:29 same architecture as the new threadripper chips 2020-01-02 09:29:36 @PureTryOut approval on !2660 ? 2020-01-02 09:30:43 danieli: ok, and np, ncopa didn't pushed it yet anyway 2020-01-02 09:32:11 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 mps: what was that threadripper issue on gitlab? 2020-01-02 09:36:43 MCE issue which is fixed in 5.4.7 2020-01-02 09:37:40 let me look at issues 2020-01-02 09:38:55 hmm, looks like it is not on issues on GL, but reported over IRC 2020-01-02 09:39:18 sorry to misleading you 2020-01-02 09:41:31 north1: yeah definitely 2020-01-02 09:47:54 north1, good job with telegram! 2020-01-02 09:55:29 Btw PureTryOut , forgot to CC you for https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2660 2020-01-02 09:55:59 That fixes launching ktrip on pmOS 2020-01-02 10:55:48 Awesome 2020-01-02 11:27:50 north1: im pushing boost 1.72 update 2020-01-02 11:28:00 i managed to build all packages exceot blender 2020-01-02 11:28:12 Alright 2020-01-02 11:28:16 s/exceot/except/ 2020-01-02 11:28:16 ncopa meant to say: i managed to build all packages except blender 2020-01-02 11:28:18 I'm not available for action though 2020-01-02 11:28:26 Currently taking train to Stuttgart 2020-01-02 11:28:31 should not be neccesary 2020-01-02 11:28:38 i think it will all build 2020-01-02 11:28:55 i will ask the blender maintainer to try fix blender 2020-01-02 11:29:11 its in testing so i dont think it matters that much 2020-01-02 13:51:12 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 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 a lot of manual works, not hard but could lead to errors if something is overlooked 2020-01-02 14:45:31 mps: i have a script that runs oldconfig for me for all the arches 2020-01-02 14:45:52 https://tpaste.us/WRdL 2020-01-02 14:51:06 I see. does it works on one arch or you have to run it on every arch 2020-01-02 14:53:03 your script is just this what I do manually, and with sugar added 2020-01-02 14:53:36 will copy it and use next time 2020-01-02 15:15:05 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 np 2020-01-02 16:03:48 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 hi 2020-01-02 17:09:37 ncopa: should the 5.4.7 be backported to 3.11 2020-01-02 17:09:54 is 5.4.7 in already? 2020-01-02 17:10:01 if so, i need to rebase my mips64 crimes 2020-01-02 17:10:09 in edge, yes 2020-01-02 17:10:32 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 mips64 ? 2020-01-02 17:11:08 yes 2020-01-02 17:11:29 a more formal announcement later :) 2020-01-02 17:11:53 ah, nice :) 2020-01-02 17:13:00 we are still working on some of the legwork of doing the port 2020-01-02 17:15:39 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 kaniini: ok ill quit my job 2020-01-02 17:21:09 :) 2020-01-02 17:22:25 hi, what would be gitlab url for http://bugs.alpinelinux.org/ ? 2020-01-02 17:23:03 https://gitlab.alpinelinux.org/alpine/aports/issues 2020-01-02 17:23:18 thanks 2020-01-02 17:30:06 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 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 its been available since PHP 7.2.0 2020-01-02 17:38:33 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 no one cares about irc logs anymore :( ? 2020-01-02 17:39:41 uhm, forgot to set CONFIG_UEVENT_HELPER_PATH for armv7 2020-01-02 17:39:48 ACTION hides 2020-01-02 17:40:05 alpine-linux been not logged for over a month now 2020-01-02 17:41:13 vkrishn: I mentioned this this morning on infra, and also few days ago 2020-01-02 17:42:24 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 yes, same issue, only alpine-linux 2020-01-02 17:43:34 cannot recal, maybe 2-3yrs back 2020-01-02 17:45:19 any idea what does /usr/lib/preloadable_libiconv.so do in pkg, gnu-libiconv ? 2020-01-02 17:45:40 do I need to enable it to use iconv in php7 ? 2020-01-02 17:45:50 you LD_PRELOAD it and it replaces musl iconv with GNU libiconv 2020-01-02 17:48:41 LD_PRELOAD in docker, norwal web-install or cli ? 2020-01-02 17:49:03 normal* 2020-01-02 17:52:46 was trying to install, nette, https://doc.nette.org/en/3.0/requirements, checker shows iconv issue 2020-01-02 17:54:52 works in cli, with LD_PRELOAD 2020-01-02 17:58:14 oh, tpaste.us not working 2020-01-02 17:58:31 working now 2020-01-02 17:59:01 testing iconv in cli http://tpaste.us/gkXr 2020-01-02 18:00:07 vkrishn: wait 2020-01-02 18:00:34 ok 2020-01-02 18:00:52 could you paste the checker output? 2020-01-02 18:01:06 just want to make sure its not that the php extension is just not enabled 2020-01-02 18:02:13 before, http://tpaste.us/evrW 2020-01-02 18:02:18 usually, php has different *.ini files depending on the SAPI 2020-01-02 18:02:48 after, http://tpaste.us/kyr4 2020-01-02 18:04:21 yes, seems like LD_PRELOAD is the right way 2020-01-02 18:10:30 ICONV_IMPL can be unknown, right ? 2020-01-02 18:11:10 or should be patched to show musl or libiconv ? 2020-01-02 18:11:37 dont know if nette needs it 2020-01-02 18:12:25 https://github.com/nette/sandbox/pull/98 2020-01-02 18:16:05 test-iconv.php is working without pkg gnu-libiconv installed 2020-01-02 18:16:15 kinda confused 2020-01-02 18:16:43 <_ikke_> vkrishn: logs are created again 2020-01-02 18:17:16 thanks 2020-01-02 18:17:38 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 but cli needs it 2020-01-02 18:17:50 ah, ok 2020-01-02 18:20:37 improved the test file for both web/cli http://tpaste.us/ObEm 2020-01-02 18:23:31 cannot test in docker yet 2020-01-02 18:28:40 not an issue in nette only, https://github.com/lorisleiva/laravel-docker/pull/30 2020-01-02 19:11:21 improved the test file, http://tpaste.us/wno5 2020-01-02 19:12:13 is there a place where these tests can be organized, maybe, https://gitlab.alpinelinux.org/alpine/aports/snippets ? 2020-01-02 19:30:34 seems an issue in php7-opcache, http://tpaste.us/JxKv 2020-01-02 19:31:15 would try to change order in ini files 2020-01-02 19:38:18 current default ordering prefix in /etc/php7/conf.d/ is 00_, suggestion, to set base at 20_ 2020-01-02 20:04:27 ncopa: you had now rpi4 ? 2020-01-02 20:31:54 artok: i think he does 2020-01-02 20:34:15 artok: yes, he told he got one 2020-01-02 20:34:31 and I borrowed rpi zero w 2020-01-02 20:34:57 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 same issue with ini ordering, http://tpaste.us/JxKv <- php7-opcache 2020-01-02 20:49:49 re-ordering* 2020-01-02 20:59:35 well my rpi4 doesn't boot with the installer 2020-01-02 20:59:47 need to move boot/* to root folder of the sd as before 2020-01-02 21:05:50 iggy: https://gitlab.alpinelinux.org/alpine/aports/issues/11102 2020-01-02 21:08:44 artok: 3.11.2 tarball? 2020-01-02 21:12:36 yah 2020-01-02 21:13:35 armv7 or aarch64 tarball? 2020-01-02 21:13:59 aarch64 2020-01-02 21:14:27 hm 2020-01-02 21:14:38 as the bootloader is on rpi4 memory 2020-01-02 21:15:23 we can n_copa tomorrow how he booted it 2020-01-02 21:15:24 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 btw, I built u-boot for zero w, and can select different kernels from boot menu 2020-01-02 21:18:18 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 AinNero: https://pasteboard.co/IO9KQyS.png <- checker from nette install 2020-01-02 21:20:43 dtbs and so on are, but initramfs and kernel are under boot/ 2020-01-02 21:21:11 my pi4 doesn't boot until i move them to root and edit config.txt 2020-01-02 21:21:24 they should there, did you looked in config.txt 2020-01-02 21:21:41 be there* 2020-01-02 21:21:49 vkrishn: this looks expected as with musl iconv 2020-01-02 21:22:00 i dont think i can tell you more than you already know yourself 2020-01-02 21:22:23 config.txt s/boot\/// 2020-01-02 21:22:41 removing subdirectory from there, and it works 2020-01-02 21:23:47 in my case it works without touching config.txt 2020-01-02 21:24:15 which bootloader it has? 2020-01-02 21:24:20 AinNero: ok, would try to install in apache+php(normal, not fpm), see if that works 2020-01-02 21:24:48 from https://www.raspberrypi.org/downloads/ recovery to sd for update 2020-01-02 21:28:00 hm, strange, n_copa confirmed that it works on rpi4 2020-01-02 21:31:16 indeed 2020-01-02 21:31:35 hence the question, would it be older bootloader 2020-01-02 21:31:51 which runs hotter 2020-01-02 21:32:17 without cooling, it will start throttling fast 2020-01-02 21:32:39 also ncopa told that is hot 2020-01-02 21:32:51 it is hot* 2020-01-02 21:33:25 without fans, even that heatsink is really hot 2020-01-02 21:33:26 rpi zero is not too much hot 2020-01-02 21:34:29 btw, if you missed, rpi4 is merged in 5.5 kernel 2020-01-02 21:34:44 actually I did one build for 5.5 2020-01-02 21:35:31 heh, nice 2020-01-02 21:36:22 just haven't installed it, but seems that it has correct dtb, dts files 2020-01-02 21:37:40 no overlays dir, though 2020-01-02 21:44:01 iggy: another: https://gitlab.alpinelinux.org/alpine/aports/issues/11103 2020-01-02 23:03:45 iggy: https://gitlab.alpinelinux.org/alpine/aports/issues/11104 2020-01-02 23:03:56 iggy: (I intend to write some patches once I'm done flushing out all of the issues) 2020-01-02 23:08:02 Hey guys 2020-01-02 23:08:14 I'm trying to build an alpine nginx with a custom website/config 2020-01-02 23:09:38 should I do a Dockerfile with docker pull amd64/alpine, going on EC2 ECS AMI 2020-01-02 23:10:12 micro4lpha: this is not a support channel 2020-01-02 23:10:18 try #alpine-linux 2020-01-02 23:14:14 right, sorry 2020-01-02 23:36:48 Cogitri: thanks, you were right - it's resolved now :) 2020-01-03 08:24:11 @ncopa ping 2020-01-03 08:24:28 can you check on https://github.com/alpinelinux/aports/pull/12189 ? 2020-01-03 08:28:39 hi 2020-01-03 08:29:28 hey :D 2020-01-03 08:29:42 looks like jason didnt read the pr template 2020-01-03 08:29:59 i wouldn't either since i create PRs and MRs from the commandline 2020-01-03 08:30:12 im adding a note for him 2020-01-03 08:30:51 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 we can do that also 2020-01-03 08:31:23 this was the idea 2020-01-03 08:47:34 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 apk add lxc-templates-legacy-alpine ? 2020-01-03 09:02:54 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 hm, /etc/init.d/cgroups start ? 2020-01-03 09:29:11 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 zenny: I'm not sure you can load modules in lxc without some 'fine' tweaks 2020-01-03 09:32:36 and, on host do 'rc-update add cgroups' to be ready when you reboot host 2020-01-03 09:33:35 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 ah, then add it in /etc/modules 2020-01-03 09:35:07 /etc/moprobe.d/*.conf is for configuring modules and not for load 2020-01-03 09:36:13 or in '/etc/modules-load.d/*.conf' instead of '/etc/modules' (though I prefer later) 2020-01-03 10:02:00 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 ah we have aarch64 iso's now. nice 2020-01-03 10:07:27 zenny: please ask this on #alpine-linux, this channel is for development 2020-01-03 10:08:02 clandmeter: you didn't noticed it earlier :) iirc it is made on your request 2020-01-03 10:08:33 cant catch all things here :) 2020-01-03 10:08:48 it was on my todo 2020-01-03 10:08:53 somewhere deep down 2020-01-03 10:09:04 but somebody beat me to it, i guess it was ncopa 2020-01-03 10:09:10 yes 2020-01-03 10:09:50 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 wait some time till they wake up :) 2020-01-03 10:12:38 and finish coffee, breakfast etc... 2020-01-03 11:23:46 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 Is there anything preventing https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2230 from being merged? 2020-01-03 12:22:16 !2230 2020-01-03 12:31:04 I'll go through it this evening and merge then 2020-01-03 12:31:20 Kind of busy due to exams right now, sorry about the merge conflicts 2020-01-03 13:44:42 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 Sure :) 2020-01-03 14:01:03 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 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 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 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 anyone have issue with download patches from GL.a.o 2020-01-03 14:13:25 curl https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1582.patch 2020-01-03 14:13:34 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 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 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 _ikke_: could be because fail on CI 2020-01-03 14:15:42 hmm , no 2020-01-03 14:15:52 <_ikke_> no, very unlikely 2020-01-03 14:15:53 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 have no idea 2020-01-03 14:39:50 z3ntu: Fedora only packages the sources 2020-01-03 14:40:00 As such you still statically the entire thing together 2020-01-03 14:40:09 You just don't download it again every time 2020-01-03 14:40:52 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 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 And rebuilding some 200-350 deps per Rust application isn't fun 2020-01-03 14:42:23 hmm 2020-01-03 14:42:58 The golang-* packages in Arch Linux are also just packaged source files 2020-01-03 14:43:00 ( maybe D will supersede rust ) 2020-01-03 14:43:38 I doubt that 2020-01-03 14:43:43 sorry for OT comment 2020-01-03 14:47:27 I doubt it too, although I do very much like D right now :) 2020-01-03 14:47:37 They have different applications tho 2020-01-03 14:47:53 I don't really see the worth of packaging the source files other than generating work :) 2020-01-03 14:53:17 ACTION wonders when Rust will get a stable ABI 2020-01-03 14:54:42 PureTryOut[m]: lemme guess, never 2020-01-03 14:55:02 Let's hope that's incorrect 2020-01-03 14:55:29 i can't think of much that got better in terms of interface stability 2020-01-03 15:17:10 The trend towards language package managers being a necessity certainly is a bit worrying 2020-01-03 16:00:26 alpine's postgresql package is nice, nice work jakub 2020-01-03 16:00:39 psql version upgrades make my blood run cold 2020-01-03 16:25:51 ddevault: im not sure he reads IRC, maybe send him a thanks-email or on twitter 2020-01-03 16:26:28 few communities agree less than Alpine about how to work together, yet somehow manage to anyway 2020-01-03 16:27:18 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 similar to what fedora does 2020-01-03 16:28:02 heh, yeah, its amazing that we manage work together despite the different opinions :) 2020-01-03 16:28:47 having different opinions are good, not bad 2020-01-03 16:29:01 +1 2020-01-03 16:29:55 only important (imo) to not be personally agreesive 2020-01-03 16:30:02 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 'calm down, and wait some time' 2020-01-03 16:31:26 ncopa: I prefer the approach that doesn't use the old release binaries 2020-01-03 16:31:38 pgdumpall is a more elegant and failure resistant solution imo 2020-01-03 16:32:06 pgdumpall is safest, ime 2020-01-03 16:32:37 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 let's not emulate anyone else 2020-01-03 16:33:44 also, i don't dare to use pg_upgrade on production servers 2020-01-03 16:34:35 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 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 dump/restore is the safest, indeed 2020-01-03 16:36:53 i was thinking having a pg_upgrade as an option for those who dare :) 2020-01-03 16:38:20 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 though did that on backup server over network 2020-01-03 16:45:12 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 I shut off the server during upgrades 2020-01-03 16:46:41 you can't get around the downtime anyway 2020-01-03 16:46:50 the server process* 2020-01-03 16:47:27 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 also I do, but there are people who need 'small' downtime 2020-01-03 16:47:42 but honestly that feels fragile as fuck when I've tried it 2020-01-03 16:48:10 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 afaik, streaming replication works only with same major version 2020-01-03 16:48:22 err, I meant logical replication 2020-01-03 16:48:28 I use streaming replication today 2020-01-03 16:48:47 and when I researched logical replication, I felt totally uncomfortable relying on it for production use 2020-01-03 16:49:13 also I use streaming replication but as hot-standby option, for high availablity 2020-01-03 16:51:00 have you ever successfully cut over to the standby? 2020-01-03 16:51:20 I feel like it makes sense in theory but is difficult to do right in practice 2020-01-03 16:51:27 esp without risking some data loss 2020-01-03 16:51:35 you mean, change a role of servers? 2020-01-03 16:51:39 aye 2020-01-03 16:51:56 yes, and a lot of times 2020-01-03 16:52:17 fair enough 2020-01-03 16:52:33 maybe exaggerate, but not rarely 2020-01-03 16:53:34 when master fails for whatever reason, switch to slave works fine, except maybe few lost row updates 2020-01-03 16:54:07 and in such situations it is hard to find if something is lost 2020-01-03 17:41:40 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 iirc, you tested it on your board? 2020-01-03 17:42:31 url? 2020-01-03 17:42:56 i tested to boot aarch64 on my rpi4 2020-01-03 17:42:59 (i think) 2020-01-03 17:43:25 he asked here, I think, or #alpine-linux 2020-01-03 17:43:59 let me check it again 2020-01-03 17:44:38 chat log begins at 2020-01-02 21:04 2020-01-03 17:44:44 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 2020-01-02 21:59........... artok| well my rpi4 doesn't boot with the installer 2020-01-03 17:45:38 2020-01-02 21:59........... artok| need to move boot/* to root folder of the sd as before 2020-01-03 17:45:59 sorry for not using tpaste 2020-01-03 17:46:30 <_ikke_> 2 lines is acceptible :D 2020-01-03 17:47:22 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 I have this as shell script somewhere 2020-01-03 17:52:04 it boots for me 2020-01-03 17:52:24 ah 2020-01-03 17:52:26 the installer 2020-01-03 17:52:31 thanks for confirmation 2020-01-03 17:53:48 it is quite possible that the installer (sys install) does not work out of the box 2020-01-03 17:54:52 i guess thats something that could be fixed 2020-01-03 17:55:00 not sure how we want it to work though 2020-01-03 17:55:52 we actually only support the "diskless" install on rpi 2020-01-03 17:56:11 he told he can't boot, had to move files to / and edit config.txt 2020-01-03 17:56:27 yeah 2020-01-03 17:56:41 the setup-disk script is not tested with rpi 2020-01-03 17:56:44 look here https://dev.alpinelinux.org/irclogs/%23alpine-devel-2020-01.log 2020-01-02 20:04:27 2020-01-03 17:57:42 setup-disk never worked for me on any arm 2020-01-03 17:58:08 it doesn't handle mmcblk disks 2020-01-03 17:58:37 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 yes, why not 2020-01-03 18:01:42 but hum 2020-01-03 18:01:50 i'd like to rewrite setup-disk script 2020-01-03 18:01:55 in lua or something 2020-01-03 18:02:08 i'd like rewrite all the setup scripts in lua 2020-01-03 18:02:21 with linenoise and tab-autocomplete and stuff 2020-01-03 18:02:30 <_ikke_> linenoise? 2020-01-03 18:02:47 as far as i am aware 2020-01-03 18:02:47 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 editline replacement 2020-01-03 18:02:53 minimal replacement for GNU readline 2020-01-03 18:02:56 <_ikke_> right 2020-01-03 18:03:02 yeah 2020-01-03 18:03:21 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 maybe by pressing esc or similar 2020-01-03 18:03:36 yeah 2020-01-03 18:03:52 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 yeah 2020-01-03 18:04:16 <_ikke_> makes unattended installs easy as well 2020-01-03 18:04:17 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 and maybe we should have defaults for everything, so we could have a '--default' option or similar 2020-01-03 18:05:11 similar to --quick 2020-01-03 18:05:33 I'd also like to be able to provide an ssh pub key somehow 2020-01-03 18:05:57 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 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 im open to better alternatives 2020-01-03 18:15:34 i was experienting around with automatically provisioning alpine machines with hetzner, but didn't find an reliable way 2020-01-03 18:15:43 the idea is to use a commnly used config format 2020-01-03 18:15:46 they had support for cloud-init tho 2020-01-03 18:15:56 and i though cloud-init was a defacto standard 2020-01-03 18:16:11 if we get cloud-init support, we could provide hetzner with a base image 2020-01-03 18:16:37 this is surely in the interest of people that pay me 2020-01-03 18:23:21 AinNero: do you work for hetzner 2020-01-03 18:23:42 no 2020-01-03 18:26:39 hetzner customer tho 2020-01-03 18:28:26 for those people trying to connect the bits, i work for several companies 2020-01-03 18:29:40 but all of them don't want to do manual setup of machines over and over again 2020-01-03 18:35:21 I looked their site and wanted to create one test instance but docs are not clear 2020-01-03 18:42:25 the cloud UI is slow and laggy, and the cli interface is a buggy go blob 2020-01-03 18:42:31 but it works if you hit it with a wrench 2020-01-03 18:46:37 I prefer cli, actually most prefer ssh console 2020-01-03 18:47:04 linode ssh console is good 2020-01-03 18:57:29 I still provision my hosts manually, but I have a checklist 2020-01-03 18:57:47 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 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 Damm 2020-01-03 20:12:20 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 I'm not sure about hg.sr.ht, _ikke_ 2020-01-03 23:31:31 i disabled wofi for the time 2020-01-03 23:32:03 <_ikke_> thanks 2020-01-03 23:43:26 Got another lockup with intel 2020-01-03 23:43:35 on the bright side it took a few days rather than hours 2020-01-04 00:10:00 Could someone review https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2125? 2020-01-04 00:13:29 I can merge if someone give the ok 2020-01-04 00:18:54 north1: re lock on i915, we leave on the _edge_ :) 2020-01-04 00:46:34 mps: when you leave on the edge you are longer on it ;-) 2020-01-04 07:21:29 clandmeter: heh, writing in foreign language just before going to bed is error prone 2020-01-04 07:21:50 s/leave/live/ 2020-01-04 07:21:50 mps meant to say: north1: re lock on i915, we live on the _edge_ :) 2020-01-04 10:50:11 rofi-pass on s390x fails with: rofi (missing): required by: .makedepends-rofi-pass-20200104.104839[rofi] 2020-01-04 10:50:36 so, rofi-pass should be disabled 2020-01-04 10:51:57 oh, rofi have 'arch=""' 2020-01-04 10:54:14 Cogitri: why does gnome-shell depend on ibus? Seems you've put it in there manually 2020-01-04 10:56:46 It needs it to start IIRC 2020-01-04 10:57:36 !2125 2020-01-04 10:57:37 Pretty sure it needs the gtk3 im module 2020-01-04 10:58:10 what is 'hyperbola' 2020-01-04 11:00:25 Linux distro 2020-01-04 11:00:44 BSD distro in future 2020-01-04 11:02:50 :) 2020-01-04 11:02:57 thanks, will look 2020-01-04 11:08:58 if they use musl I could be interested 2020-01-04 11:15:15 I don't think musl is on BSD 2020-01-04 11:16:43 I know. Their mistake :) 2020-01-04 11:26:03 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 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 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 isn't (unwritten) alpine policy minimal dependencies 2020-01-04 12:26:30 mps: Minimal dependencies while retaining a functional package 2020-01-04 12:26:53 And tbh if you're installing GNOME I don't think you're onto the super minimal train 2020-01-04 12:30:56 functional package is broad definition 2020-01-04 12:32:27 s390x builder segfaulted building testing/gcc-cross-embedded 2020-01-04 14:52:54 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 (writing now because I will probably forgot on monday :) ) 2020-01-04 15:05:44 which bootloader ? =) 2020-01-04 15:08:05 artok: didn't asked, he told something like 'out of the box' 2020-01-04 15:15:07 time to do rpi-eeprom alpine package 2020-01-04 15:15:08 =) 2020-01-04 15:16:47 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 yeah 2020-01-04 15:18:48 does that mean it can use efi boot loader 2020-01-04 15:20:12 afaik, all arm64 should have option to use efi 2020-01-04 15:21:16 there is experimental uefi stuff.. 2020-01-04 16:20:00 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 something like this, it will be installed if the gnome-shell installed 2020-01-04 16:41:44 Yup, so it's equivalent, isn't it? 2020-01-04 16:42:31 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 s/strong/strict/ 2020-01-04 16:43:57 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 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 eh, if we have 'ignore_class_pkgs' :) 2020-01-04 16:51:01 one of reasons I switched from debian is their (so called) 'dependency hell' 2020-01-04 16:59:33 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 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 Huh, how did that work in my docker container 2020-01-04 17:59:45 Anyway, should be an easy fix, thanks for the ping. 2020-01-04 18:49:00 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 Will do in a sec, currently compiling ghc to test a change 2020-01-04 19:02:26 Cogitri: rebased 2020-01-04 19:03:32 Merged :) 2020-01-04 19:04:11 Thanks! 2020-01-04 19:04:58 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 Hm, should git-cola bee disabled too? 2020-01-04 19:05:20 Hm, have you pushed that to the MR accidentally? 2020-01-04 19:05:26 That package should be reverted, it's already in community with a higher version 2020-01-04 19:05:28 Not sure how this happened 2020-01-04 19:05:50 Rebasing can be weird :) 2020-01-04 19:06:01 Oh yeah guess git-cola has to be disabled too 2020-01-04 19:07:04 Done 2020-01-04 19:08:03 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 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 I don't know to be honest 2020-01-04 19:50:48 kernel 5.4.8 released, mostly net and scsi fixes 2020-01-05 00:12:58 is Konstantin Kulikov itc? 2020-01-05 00:15:01 'itc'? in the channel? 2020-01-05 00:17:21 aye 2020-01-05 00:17:41 not sure, but iirc nick is kaey 2020-01-05 00:18:07 kaey: is there some trick to building the grafana package? So far I've met with miserable failure 2020-01-05 00:18:08 north1: thanks (dialog) 2020-01-05 01:02:16 welcome 2020-01-05 01:14:04 kaey: nevermind, I got it working after some more finageling 2020-01-05 05:12:02 I packaged it for internal (infra) use at one point, it is indeed excruciating 2020-01-05 11:09:43 maintainers, inbound emails coming for out of date pkgs. 2020-01-05 11:22:09 ack 2020-01-05 11:22:12 i got it clandmeter 2020-01-05 11:52:59 clandmeter: Can we maybe not flag GNOME packages out of date for uneven releases? 2020-01-05 11:53:13 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 (Not sure how we'd match those other than with the source URL) 2020-01-05 11:53:41 So maybe I'll just have to deal with that 2020-01-05 11:58:12 Cogitri: its using https://release-monitoring.org/ 2020-01-05 12:01:33 Ah, okay 2020-01-05 12:02:23 i think there is some interface to it to adjust things 2020-01-05 12:02:31 jirutka set it up before 2020-01-05 12:02:41 i think there are also a lot of mismatches 2020-01-05 12:02:45 more than matches 2020-01-05 12:03:09 i think none of the py3 packages get matched 2020-01-05 12:17:32 Oh 2020-01-05 16:32:26 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 Ugh 2020-01-05 17:55:29 hm, I have an idea for this prometheus stuff I'm working on 2020-01-05 17:55:49 we could add -instrumentation subpackages for packages which support it, such as setting up redis-exporter for redis 2020-01-05 17:55:57 then install it if an instrumentation metapacakge is installed 2020-01-05 19:10:44 Hy guys! 2020-01-05 19:13:17 Heya 2020-01-05 19:14:25 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 true 2020-01-05 19:14:40 Wouldn't a -prometheus subpkg be more appropriate then? 2020-01-05 19:14:42 What's about my MR 2020-01-05 19:14:44 !2705 2020-01-05 19:14:44 aye 2020-01-05 19:14:46 !2705 2020-01-05 19:14:48 !2705 2020-01-05 19:14:50 !2705 2020-01-05 19:14:52 !2705 2020-01-05 19:14:54 !2705 2020-01-05 19:14:56 !2705 2020-01-05 19:14:56 wtf 2020-01-05 19:14:56 cut it out, kr0k0_1 2020-01-05 19:14:56 Uhh 2020-01-05 19:14:58 !2705 2020-01-05 19:14:59 _ikke_: clandmeter: cc 2020-01-05 19:15:00 What's about my MR !2705? 2020-01-05 19:15:00 someone mind banning him 2020-01-05 19:15:02 Sorry 2020-01-05 19:15:07 _ikke_: clandmeter 2020-01-05 19:15:14 Timed out? 2020-01-05 19:15:31 Seems so 2020-01-05 19:15:36 Sorry again 2020-01-05 19:16:28 Is there any reason to not merge this? 2020-01-05 19:17:05 ping the maintainer 2020-01-05 19:17:10 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 kr0k0_1: it will be merged when ncopa does a new kernel release. 2020-01-05 19:18:16 Ah ok, thanks guys. 2020-01-05 19:46:40 who put MR number with ! in branch name? algitbot? 2020-01-05 20:04:48 <_ikke_> ? 2020-01-05 20:06:31 MR about wireguard 2020-01-05 20:07:00 <_ikke_> I don't see a '!' in the branchname 2020-01-05 20:07:27 (! 2705) 2020-01-05 20:07:50 added 2 spaces to not trigger it again 2020-01-05 23:59:13 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 (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 XgF: i remember there was an issue related to that module previously 2020-01-06 00:11:05 I did find https://gitlab.alpinelinux.org/alpine/aports/issues/9124 though it seems only tangentially related 2020-01-06 00:11:15 (cant view links right now) 2020-01-06 00:11:31 the af_packet module is per default included into the mkinitfs 'network' feature 2020-01-06 00:12:08 otherwise you can load it via /etc/modules or /etc/modprobe.d 2020-01-06 01:04:40 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 what's the current state of the art for splitting subpackages into sub-subpackages for -openrc 2020-01-06 02:28:13 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 great 2020-01-06 02:47:54 I have broken apk 2020-01-06 03:11:16 I have made it impossible to uninstall my package 2020-01-06 03:11:18 woohoo 2020-01-06 03:11:22 ACTION goes to sleep 2020-01-06 05:34:18 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 Hello and Happy New Year 2020-01-06 05:41:27 I have a question. 2020-01-06 05:43:00 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 Because github is on lockdown, use gitlab.a.o instead 2020-01-06 05:43:33 Sodomon: the project has switched to using gitlab ( gitlab.alpinelinux.org ) 2020-01-06 05:45:18 Ah ok thank you or tell me 2020-01-06 12:20:48 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 btw, 5.4.8 have some fixes backported from 5.5-rc 2020-01-06 12:25:02 Please do tell 2020-01-06 12:25:11 I'm following every update zealously to get this annoyance fixed 2020-01-06 12:25:20 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 sorry, my mistake and it is pity that we cannot retrigger particular arch rebuild on CI 2020-01-06 12:26:21 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 _ikke_: yes, i mean other devs cannot 2020-01-06 12:28:52 or, if I'm wrong would be nice news to me 2020-01-06 12:28:59 No worries I just made my own MR, downloaded the artifacts and then deleted the branch 2020-01-06 12:30:54 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 iiuc, I can only do these for MRs I created 2020-01-06 12:35:59 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 understood 2020-01-06 13:19:14 iggy: no worries, thanks 2020-01-06 14:07:03 PureTryOut[m]: FYI: had to disable kmouth on armhf due to qtdeclarative 2020-01-06 14:34:01 Yeah no props. Same problem seems to be with kio-gdrive 2020-01-06 16:09:29 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 Or should the linter tool be modified to accept those? 2020-01-06 16:09:50 most likely not 2020-01-06 16:10:23 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 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 In this case it's for postmarketOS where we use the same linter since yesterday evening 2020-01-06 16:12:28 Tons of firmware packages 2020-01-06 16:12:36 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 "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 Not currently, there is for example https://pkgs.alpinelinux.org/package/edge/main/armv7/linux-firmware 2020-01-06 16:13:54 basically, yes. 2020-01-06 16:14:49 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 Yeah but can a "custom" or "proprietary" entry be added? 2020-01-06 16:15:39 PureTryOut[m] (IRC): having a non-descript "custom" doesn't help much 2020-01-06 16:16:23 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 custom and include the license sounds sane (if the license is sane to distribute it) 2020-01-06 16:17:45 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 fcolista: ^ 2020-01-06 16:18:33 clandmeter: ok, so I guess I'll have to modify abuild then to accept "custom"? 2020-01-06 16:19:20 PureTryOut[m]: probably best to send a PR and ask others opinion. 2020-01-06 16:19:30 MR sorry :) 2020-01-06 16:19:49 <_ikke_> perhaps along with some attributes about the specific license? 2020-01-06 16:20:18 this MR would be to add custom as allowed license? 2020-01-06 16:21:45 In my case yes 2020-01-06 16:40:18 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 That's good enough for me! 2020-01-06 17:35:21 In the alpinelinux/apkbuild-lint-tools Docker image, can changed-aports be made to skip a folder? 2020-01-06 17:41:14 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 qemu? 2020-01-06 17:41:51 yeah, but it's slow 2020-01-06 17:43:03 I would imagine any new system that needs to be bootstrapped would be too? 2020-01-06 17:46:53 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 I think some people have managed to hook cross-compilers into abuild as well 2020-01-06 18:29:31 But about all packages in alpine don't support crosscompiling 2020-01-06 18:29:42 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 Ugh, is the thing dynamically generated 2020-01-06 19:15:25 CI worked 2020-01-06 19:16:06 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 Huh, vpnc works locally too 2020-01-06 19:17:19 <_ikke_> strange 2020-01-06 19:18:02 a few minutes ago a cloudflare issue was corrupting my memes 2020-01-06 19:18:14 might be same issue 2020-01-06 19:19:48 Possibly 2020-01-06 19:20:29 re: checksum failure 2020-01-06 19:27:35 <_ikke_> Cogitri: looking at the 3.11 CI issue 2020-01-06 19:33:32 Thank you 2020-01-06 19:44:56 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 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 feel sorry! :\ 2020-01-06 19:53:42 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 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 "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 maybe time do some stress tests? memram test etc? 2020-01-06 19:57:00 few hours ago my firefox killed by oom 2020-01-06 19:57:11 mps lucky you! 2020-01-06 19:57:26 suspect is kernel 2020-01-06 19:58:37 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 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 exactly 2020-01-06 19:59:41 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 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 both boxes have 4GB ram 2020-01-06 20:00:41 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 that happens when I forget to add swap 2020-01-06 20:02:18 if I add swap, firefox sometimes crawl but don't locks or killed 2020-01-06 20:02:19 swap for sure on some ssd/flash memory, right mps? 2020-01-06 20:02:36 ssd 2020-01-06 20:02:49 ye in that case it helping a lot 2020-01-06 20:03:37 so, you are not only one with issues using firefox :( 2020-01-06 20:03:51 on chromium got same 2020-01-06 20:04:26 maybe we are victims of JS miners :) 2020-01-06 20:08:00 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 same here, I'm kidding about JS miners, I have blocking addons for JS 2020-01-06 20:10:22 ahh, so blocking JS wont help :\ 2020-01-06 20:10:55 no 2020-01-06 20:11:00 I tried tweak sysctl stuff but tbh better spend that time to get extra ram :D 2020-01-06 20:11:42 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 but still, cgroups memory limit was doing good job, firefox could freeze but at least not entire system 2020-01-06 20:12:27 but her box is still 3.10 and linux-vanilla 4.19.x 2020-01-06 20:12:52 for me "best" kernel was 4.9 :D 2020-01-06 20:13:17 but ye, :) 2020-01-06 20:29:49 4.4 has lts + cip support until 2030 2020-01-06 20:38:54 preferred place to send abuild patches? 2020-01-06 20:39:00 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 it looks like a lot of other people are using gitlab MRs 2020-01-06 20:43:56 I'm guessing my patch will be forwarded to /dev/null on the ML 2020-01-06 20:44:20 it'll be a cold day in hell before I send aports patches to gitlab, though :) 2020-01-06 22:01:33 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 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 showing the mount. Also the mount command is not throwing any error 2020-01-07 19:09:34 Thank you :)! 2020-01-07 22:02:16 <_ikke_> The builders are green again 2020-01-08 01:51:34 making good progress on man pages: https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/9 2020-01-08 01:51:38 (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 I'll take a look soon 2020-01-08 07:10:15 Am recharging my phone plan 2020-01-08 07:52:58 Hi 2020-01-08 07:53:33 I'm trying to download artifacts from Gitlab runners, but it seems the bandwidth is extremely low 2020-01-08 07:54:03 In the 40 to 50 KB/s range 2020-01-08 07:54:20 <_ikke_> Geod2474: link? 2020-01-08 07:55:10 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 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2841 2020-01-08 07:56:02 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 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 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 Wow 2020-01-08 08:10:11 It's bad 2020-01-08 08:10:40 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 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 Yep. I don't see the same behavior with my server in Paris: 2020-01-08 08:11:43 --- 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 Perhaps the gitlab (or some other piece of infra) is configured with a very low timeout ? 2020-01-08 08:15:28 hmm, from last night I also see that the traffic is slower, and not only to Alpine server 2020-01-08 08:16:31 now it is better, probably net admins in some important node are wake up 2020-01-08 08:16:41 Looks like the packet loss is almost gone now. 2020-01-08 08:17:15 Throughput is still low but at least the download doesn't stop :) 2020-01-08 08:19:02 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 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 Great, thanks 2020-01-08 14:42:27 can we move the shadow package into main? 2020-01-08 14:44:27 rationale for that? 2020-01-08 14:45:14 useradd > adduser 2020-01-08 14:45:21 it's part of the base system for lots of other distros 2020-01-08 14:45:25 one of the first things I install on alpine 2020-01-08 14:47:08 when started to use alpine I though same, but nowadays current is fine with me 2020-01-08 14:47:17 thought* 2020-01-08 14:47:23 but why main? 2020-01-08 14:47:44 its currently in community? 2020-01-08 14:48:22 yes, http://dl-cdn.alpinelinux.org/alpine/v3.11/community 2020-01-08 15:12:45 +1 on that question, adduser wfm 2020-01-08 15:14:47 -1 2020-01-08 15:15:08 main should be small 2020-01-08 15:19:24 and removing '#' in /etc/apk/repositories + 'apk update' is not much work 2020-01-08 15:55:17 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 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 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 Yeah guess I'll do that 2020-01-08 16:19:24 to atools ? 2020-01-08 16:21:27 <_ikke_> no, alpine-lint-tools 2020-01-08 16:21:34 oh 2020-01-08 16:21:35 ok 2020-01-08 16:21:46 <_ikke_> apkbuild-lint-tools* 2020-01-08 16:27:29 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 (optionally) 2020-01-08 16:28:47 that's not why I want shadow 2020-01-08 16:28:50 PAM sucks 2020-01-08 16:29:18 maybe I'll write a shadow clone which only has the parts I like in it 2020-01-08 16:39:56 ddevault: what is the reason to move it to main? personal preference? 2020-01-08 16:47:50 (1) personal preference 2020-01-08 16:47:54 (2) it seems on-topic for main 2020-01-08 16:47:58 (3) main has support guarantees 2020-01-08 18:13:32 also: 2020-01-08 18:13:38 ninja vs samurai discussion bump 2020-01-08 18:40:59 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 kaniini had a good post on the mailing list about it 2020-01-08 18:43:59 https://lists.alpinelinux.org/~alpine/devel/%3CCAAOiGNwnzTomzOQ6YjH3t7VHmbfMRZUNXap8GM0Gy_mGS7aKhg%40mail.gmail.com%3E 2020-01-08 18:46:55 Yup, read it 2020-01-08 18:47:13 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 ACTION dislikes email 2020-01-08 21:26:49 ACTION likes email 2020-01-08 21:27:17 <_ikke_> ACTION is neutral about e-mail 2020-01-08 21:44:10 ACTION likes the concept, but hates the server-side mess 2020-01-08 21:44:24 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 anyone know how to download patch and not diff from https://phabricator.services.mozilla.com 2020-01-08 23:17:52 I think I found patch there for firefox 72.0 2020-01-08 23:18:20 want to try to build it before going to bed :) 2020-01-09 00:43:21 looks like this patch (https://phabricator.services.mozilla.com/D56873) is not needed, at least for aarch64 2020-01-09 00:43:45 builds fine in lxc 2020-01-09 01:51:15 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 added to my todo list 2020-01-09 01:51:31 but won't be tonight 2020-01-09 01:51:33 I'm off o/ 2020-01-09 01:51:49 ACTION waves 2020-01-09 08:01:30 north1: i see a lot of orphan commits? 2020-01-09 08:01:45 yes 2020-01-09 08:02:21 any specific reason? 2020-01-09 08:03:00 consolidating 2020-01-09 08:03:21 orphaning what i don't use, removing ones i think should be done better by someone else 2020-01-09 08:03:31 moving the stuff i use to community 2020-01-09 08:04:37 oh ok 2020-01-09 08:05:07 if you think its not useful you can also move it to unmaintained 2020-01-09 08:05:34 ah, good, I was surprised seeing a lot of orphans 2020-01-09 08:06:13 yeah, maybe it makes sense to bundle them into a single commit next time :) 2020-01-09 08:08:25 clandmeter: too late, he already orphaned them :) 2020-01-09 08:09:02 next time... its not a big issue though. 2020-01-09 08:09:23 PureTryOut[m] (IRC): kdecoration is failing on armhf due to qtDeclarative 2020-01-09 08:12:22 Well, disable it on that arch then 😉 2020-01-09 08:12:34 sweet 2020-01-09 08:12:38 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 @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 @ikke ty 2020-01-09 08:26:18 downgrading firefox becoming nightmare :( 2020-01-09 08:27:13 Should just be failures related to qtdeclarative not being on armhf 2020-01-09 08:27:20 72.0 faults on armv7 2020-01-09 08:27:22 How come you need to do that? 2020-01-09 08:27:24 Just disable those packages wherever it comes up 2020-01-09 08:27:31 Planned to merge 72.0.1 ASAP 2020-01-09 08:27:46 What goes wrong about it? 2020-01-09 08:28:08 ah, 72.0.1 released? didn't seen it 2020-01-09 08:28:24 Unhandled fault: alignment exception (0x011) at 0xbec84658 2020-01-09 08:41:55 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 something else* 2020-01-09 08:46:26 anyway, started build on armv7, hope will inform you in a hour or two if it works 2020-01-09 08:46:53 Ah, I think J0WI made a MR for that, didn't he? 2020-01-09 08:47:49 yes, but it fails on CI 2020-01-09 08:48:30 and is J0WI here? 2020-01-09 08:48:50 whoever is s/he 2020-01-09 08:53:07 I don't think they're on IRC 2020-01-09 08:53:10 But !2860 2020-01-09 08:54:15 yes, just seen when you mentioned it 2020-01-09 08:55:04 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 firefox-esr should also be upgraded asap, but the CI fails currently 2020-01-09 09:55:41 !5017 2020-01-09 09:55:49 !2859 (sorry) 2020-01-09 10:01:40 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 last night looked at patch on their site, not sure will it fix this 'Bus error' 2020-01-09 10:04:53 building and testing FF takes time, as you know 2020-01-09 10:22:18 yep 2020-01-09 10:22:52 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 good, I'm just started build on aarch64, hope it will finish in about hour 2020-01-09 10:27:23 I would honestly prefer being able to reproduce it, no clue why it fails on the CI tbh 2020-01-09 10:29:27 I found this https://phabricator.services.mozilla.com/rMOZILLACENTRAL8e71fa07fe004c2e4d04db6b9e77cdfbc7810d6a 2020-01-09 10:29:48 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 nmeum: FF 68.4.1 pass build in my lxc aarch64 2020-01-09 12:13:57 I mean, MR mentioned above 2020-01-09 12:14:10 !2859 2020-01-09 12:15:42 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 didn't get around to setting up a alpine-gitlab-ci docker yet 2020-01-09 12:17:51 I think it could be pushed 2020-01-09 13:01:39 #11118 should be mentioned in the commit for firefox-esr 2020-01-09 13:04:19 commiter should add this as 'fixes: ...' in commit msg 2020-01-09 13:23:23 👍 2020-01-09 13:28:14 FF 72.0 works on aarch64 about one hour (or better say, still not faulted ) 2020-01-09 13:29:19 ah, 5.4.10 is released :) 2020-01-09 13:31:19 day will be busy ;) 2020-01-09 13:33:57 should I just go ahead and push the firefox-esr upgrade, will modify the commit message accordingly… 2020-01-09 13:34:04 s/,/?/ 2020-01-09 13:34:04 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 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 if it goes well, then backport to 3.11 2020-01-09 13:38:55 but I think it will go fine on 3.11 2020-01-09 13:44:08 Sounds good 2020-01-09 13:45:53 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 have to catch a train in a second, let's see if the build finishes in the meantime 2020-01-09 13:53:39 north1: no, but if you join #alpine-commits you'll get highlighted 2020-01-09 13:54:22 it would be a cool feature to support sending those sorts of notifications, though 2020-01-09 13:54:30 Bummer, would be nice to know when your stuff gets Applied 2020-01-09 13:54:42 Otherwise I feel like I need to contact the person to let them know 2020-01-09 13:55:21 use irssi, Luke :) 2020-01-09 14:49:05 north1: it would be cool to subscribe to e.g. ~alpine/aports+patchupdates@lists.a.o 2020-01-09 14:49:19 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 doesn't scale well at aports volume 2020-01-09 14:51:39 My merge script for gitlab automatically comments, might do something like that for sourcehut 2020-01-09 14:52:15 well, automatically commenting would defeat the purpose 2020-01-09 14:52:21 I like to leave a personal thanks 2020-01-09 14:52:23 not a robot thanks 2020-01-09 14:52:38 but I still see value in having the software let you know what's up 2020-01-09 14:55:07 The purpose is to notify, the thank you is a formality 2020-01-09 17:55:37 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 what's wrong with alertmanager? 2020-01-09 17:58:56 It's failing to build on aarch64 2020-01-09 17:59:02 Pushed ff 72.0.1 btw 2020-01-09 18:00:06 ddevault: https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/alertmanager/alertmanager-0.20.0-r0.log 2020-01-09 18:00:17 hm, yeah, I don't know any better than you do about this 2020-01-09 18:00:42 heh, hope someone who know will do something 2020-01-09 18:01:12 looks like flag is missing or incorrect 2020-01-09 18:01:32 yeah, weird that it wouldn't happen on other arches 2020-01-09 18:01:50 yes, this is what wonders me 2020-01-09 18:02:30 Cogitri: are you sure this patch about cpu is needed for FF 72.0.1 2020-01-09 18:03:02 I built it without this patch for aarch64 and it works fine 2020-01-09 18:03:07 `this patch about cpu`? 2020-01-09 18:03:17 give me few secs 2020-01-09 18:05:10 8e71fa07fe00.patch 2020-01-09 18:06:44 did you took it from void linux, looks similar 2020-01-09 18:10:28 Yes 2020-01-09 18:11:02 I built 72.0.1 without it and it works on aarch64 2020-01-09 18:11:53 Well, it apparently works against SEGFAULTs on some machines 2020-01-09 18:12:54 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 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 yes, that I wan't to ask, just built it for armv7 with similar patch 2020-01-09 18:15:18 want to see will it work 2020-01-09 18:16:45 thanks for info 2020-01-09 18:56:38 Cogitri: what is value of LDFLAGS on aarch64? 2020-01-09 18:56:38 i think LDFLAGS should be escaped with printf %q and ldflags should be prefixed with "local" 2020-01-09 18:56:40 https://git.alpinelinux.org/aports/tree/community/alertmanager/APKBUILD 2020-01-09 18:56:41 ddevault: ^ 2020-01-09 18:56:43 would be nice to see output of "env" in build logs btw 2020-01-09 19:01:08 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 all of those things are non-POSIX GNUisms 2020-01-09 19:03:47 except for that last suggestion, that sounds good 2020-01-09 19:05:05 actually it seems go build doesn't grok that 2020-01-09 19:05:11 so I'm just gonna copypasta it 2020-01-09 19:05:16 Cogitri: firefox-72.0.1 fails on armv7 2020-01-09 19:07:02 building multiple packages at once should work. what does it say to you? 2020-01-09 19:07:12 hmm, something is fucky here 2020-01-09 19:07:37 also local is accepted by aports styleguide 2020-01-09 19:07:45 https://git.alpinelinux.org/aports/tree/CODINGSTYLE.md 2020-01-09 19:07:55 nevermind, it works 2020-01-09 19:08:00 I was misinterpreting things 2020-01-09 19:08:08 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 wait, no, it doesn't work. It doesn't print anything either, it just doesn't work 2020-01-09 19:08:52 then you should prefix vars with underscore, to avoid potential conflicts with vars defined by abuild 2020-01-09 19:09:08 that seems reasonable 2020-01-09 19:09:22 anyway, I have a patch 2020-01-09 19:09:24 sending to aports list 2020-01-09 19:10:02 mps: Fails as in explodes during runtime? 2020-01-09 19:10:25 Alignment trap: not handling instruction f9610aef at [] 2020-01-09 19:10:44 bus error 2020-01-09 19:13:05 full dmesg here http://tpaste.us/kyQZ 2020-01-09 19:14:05 same happened with my build last night 2020-01-09 19:19:21 So it's a runtime failure, got it 2020-01-09 19:27:43 Hm, I guess it's best to ask upstream about it 2020-01-09 19:29:32 Just for curiosity: Could you try w/ CLang? 2020-01-09 19:29:53 Since I don't have an armv7 machine I have a hard time debugging runtime bugs on it 2020-01-09 19:32:23 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 add "!strip" to it? 2020-01-09 19:36:45 More like adding -g to our C{,XX,PP}FLAGS and adding a -dbg subpkg 2020-01-09 19:37:26 https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/13 by the way :) 2020-01-09 19:37:47 Right now we either don't offer -dbg packages or they're kind of defunct usually 2020-01-09 19:41:36 Since we have -dbg packages I kind of assumed they are built with -g 2020-01-09 19:44:45 No, they're not as of now 2020-01-09 19:45:10 We just hope the build system does -g or we have a defunct -dbg packages right now AFAICS 2020-01-09 19:45:56 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 ddevault: I'll go ahead and disable alertmanager on aarch64 for now, okay? 2020-01-09 19:51:51 let's just get a better patch in 2020-01-09 19:51:55 i've replied on ml about alertmanager just now 2020-01-09 19:51:55 chillax my friend 2020-01-09 19:52:23 testing new patch now 2020-01-09 19:52:35 works, preparing for ML 2020-01-09 19:52:54 thanks kaey 2020-01-09 19:52:55 Alright, good 2020-01-09 20:08:33 Cogitri: sorry, I was AFK 2020-01-09 20:09:14 No worries :) 2020-01-09 20:09:22 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 and, also I think it is for upstream report 2020-01-10 11:22:24 sull 2020-01-10 11:45:25 PureTryOut[m]: re d33b26afd532c021810d466a6c1a229d6e187ca3 2020-01-10 11:45:43 do i understand it correctly that it does not work in any setup? 2020-01-10 11:45:58 why does not the `make check` capture it? 2020-01-10 12:27:02 do we build our armv7 with neon support? 2020-01-10 12:28:57 i guess not 2020-01-10 12:29:08 i think neon is armv8, right? 2020-01-10 12:30:47 kernel or userspace? 2020-01-10 12:32:18 I build my kernels for armv7 with neon always enabled 2020-01-10 12:32:54 userspace 2020-01-10 12:32:59 im looking at nss build 2020-01-10 12:33:14 apparently they assume armv8 for 32 bit arm 2020-01-10 12:33:35 then they explictly set -mfpu=neon 2020-01-10 12:34:01 but dont set it when compile gcm.c 2020-01-10 12:34:15 this commit breaks nss build on armv7: https://github.com/nss-dev/nss/commit/77924fef97a0f4c6a319db896cfc2b18f7d8a49b 2020-01-10 12:34:56 problem is here: https://github.com/nss-dev/nss/commit/77924fef97a0f4c6a319db896cfc2b18f7d8a49b#diff-eb06307b930d20d3df7c636bec101076R24 2020-01-10 12:35:25 they #define USE_ARM_GCM when __ARM_NEON is set 2020-01-10 12:35:53 which it is not on our armv7 2020-01-10 12:35:56 $ gcc -dM -E - < /dev/null| grep ARM_NEON 2020-01-10 12:36:24 hmm, not sure but looks like this could break 2020-01-10 12:36:41 problem is that they have NEON optimized functions 2020-01-10 12:36:53 which are enabled for all arm32 bit 2020-01-10 12:37:08 but they dont disable the unoptimized variants 2020-01-10 12:37:16 so both gets compiled 2020-01-10 12:37:43 but looking at that make file, they enable armv8 stuff on all 32 bit arm 2020-01-10 12:38:03 yes, I see 2020-01-10 12:38:05 i guess that works for things like rpi3 and rpi4 2020-01-10 12:38:12 which are armv8 2020-01-10 12:38:36 but i wonder if we want enable armv8 stuff for our ARCH=armv7 2020-01-10 12:38:56 NEON optimized could work for some armv7 cpus 2020-01-10 12:39:15 armv7 cpus with NEON 2020-01-10 12:39:21 i suppose 2020-01-10 12:39:26 but doubt it could work for all 2020-01-10 12:39:53 so my question is, do we want build nss with NEON or not 2020-01-10 12:39:57 for armv7 2020-01-10 12:39:58 yes, from the head, some armv7 have neon 'extension' 2020-01-10 12:40:26 personally, I would like your idea :) 2020-01-10 12:40:53 my idea? 2020-01-10 12:40:56 my exynos chromebook (armv7) works very fine 2020-01-10 12:41:08 ok, your doubt 2020-01-10 12:41:20 'so my question is, do we want build nss with NEON or not' 2020-01-10 12:41:27 Ideally there would be some runtime fallback 2020-01-10 12:43:27 ok, I think NEON can be enabled for armv7 (but not 100% sure, TBH) 2020-01-10 12:43:59 minecrell: agree 2020-01-10 12:44:39 they apparently already do that for nss 2020-01-10 12:45:59 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 then again, even the FPU seems optional for armv7, so you really can't cover everything :) 2020-01-10 12:46:58 yes, with armv7 making distro is not easy task 2020-01-10 12:47:38 with arm, to be more precise, though 64bit are better 2020-01-10 12:50:26 ok, lets keep neon enabled for nss 2020-01-10 12:51:21 :) 2020-01-10 13:25:29 What about armhf? 2020-01-10 13:26:03 Could a user without neon use that instead? 2020-01-10 13:30:08 as minecrell pointed, runtime fallback would be nice to have 2020-01-10 13:31:29 looks like a lot of upstream don't care much about older ARMs nowadays 2020-01-10 13:36:50 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 yes, sometimes I use term 'ARM jungle' 2020-01-10 13:46:10 nmeum: sorry to bothering you, did you worked on firefox-esr upgrade for 3.11 2020-01-10 13:46:46 I started to test it and looks like same patch for edge can be cleanly applied 2020-01-10 13:47:23 yeah, that's what I was thinking as well 2020-01-10 13:47:43 we could just cherry pick it 2020-01-10 13:47:51 I didn't get around to running a test build though 2020-01-10 13:47:51 if you don't have time I can try to build it in lxc 2020-01-10 13:48:12 if you don't mind, I think I won't manage to do it today 2020-01-10 13:48:25 ok, I will try now 2020-01-10 13:48:30 ok, thanks a lot 2020-01-10 13:48:38 if it builds fine let me know and I will cherry pick it to the stable branch 2020-01-10 13:49:14 ofc 2020-01-10 13:52:46 thanks! 2020-01-10 13:54:17 np :) 2020-01-10 14:15:32 is there already an issue with the sudo warnings? 2020-01-10 14:15:49 s/with/for 2020-01-10 14:15:49 clandmeter meant to say: is there already an issue for the sudo warnings? 2020-01-10 14:22:58 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 Why `make check` doesn't capture it, no clue 2020-01-10 14:23:37 You can read the Qt bug report I mentioned in the commit for more details 2020-01-10 14:34:47 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 https://paste.sr.ht/%7Emartijnbraam/45c94f6ad0da0571aab8fa7d716b91cbdb62164f 2020-01-10 14:37:27 Tip: if you don't already, use docker-abuild 2020-01-10 14:38:41 no 2020-01-10 14:38:51 I won't install docker 2020-01-10 14:42:53 install podman :) 2020-01-10 14:43:53 /b stew 2020-01-10 14:43:56 Well, that's your decision then, docker-abuild makes stuff a whole lot easier 2020-01-10 14:43:56 disregard last 2020-01-10 14:44:21 lol 2020-01-10 14:44:43 MartijnBraam: I hit this too 2020-01-10 14:44:51 chown -R abuild:abuild /var/cache/distfiles 2020-01-10 14:44:59 chmod -R g+rX /var/cache/distfiles 2020-01-10 14:45:00 see 2020-01-10 14:45:11 there must be a solution not using containers as a workaround 2020-01-10 14:45:14 err, use chgrp for that first command, not chown 2020-01-10 14:45:50 and make sure you are in abuild group 2020-01-10 14:45:55 that too 2020-01-10 14:46:02 and log out and back in to make group changes take effect 2020-01-10 14:46:29 you build using a seperate user? 2020-01-10 14:46:36 no 2020-01-10 14:46:39 just put your user in the abuild group 2020-01-10 14:46:47 on linux group membership changes require the affected user to relog 2020-01-10 14:47:00 abuild:abuild implies the abuild user exists :) 2020-01-10 14:47:10 which is why I corrected myself 2020-01-10 14:47:35 oh that group is already set up 2020-01-10 14:47:51 adduser user abuild, is enough, ime 2020-01-10 14:48:01 but docker-abuild is kind of nice, if you want to build cross arches. 2020-01-10 14:48:27 If I want to containerize builds for multiarch I just use pmbootstrap :) 2020-01-10 14:48:40 "docker-$anything is kind of nice" is a tautological falsehood 2020-01-10 14:48:41 s/container/chroot 2020-01-10 14:48:41 MartijnBraam meant to say: If I want to chrootize builds for multiarch I just use pmbootstrap :) 2020-01-10 14:48:54 lol 2020-01-10 14:52:02 it works now :) 2020-01-10 14:57:53 MartijnBraam: You van use rootbld instead of docket if you want 2020-01-10 14:58:19 s/van/can/ 2020-01-10 14:58:19 Cogitri meant to say: MartijnBraam: You can use rootbld instead of docket if you want 2020-01-10 14:59:00 hmm that looks interesting 2020-01-10 14:59:27 Yup, it's pretty nifty but I still use Docker since that's way faster for me 2020-01-10 15:04:15 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 it works and the result is correct. But the generation is way too slow 2020-01-10 15:04:58 any ideas on how to speed up this? 2020-01-10 15:10:45 clandmeter: yes non-neon could use armhf. good point 2020-01-10 15:11:50 (also added this as a stackoverflow https://stackoverflow.com/questions/59684341/alpine-linux-create-a-apk-package ) 2020-01-10 15:12:12 fredrigu_: you can use pigz instead of gzip to utilize more cpus during compression 2020-01-10 15:13:07 ncopa: thanks! 2020-01-10 15:15:25 fredrigu_: i think that fabled has a C version of package creation on the roadmap 2020-01-10 15:15:48 ncopa: good to know, perhaps helping him with that is the best way to go 2020-01-10 15:15:49 in addition to new apk format 2020-01-10 15:15:57 yeah 2020-01-10 15:16:41 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 not sure how you could get rid of the last cat-line 2020-01-10 15:27:36 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 i suppose you could keep it in memory, but then you could as well use tmpfs 2020-01-10 15:41:52 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 https://gitlab.alpinelinux.org/alpine/alpine-conf/commit/c2275905471687b0cf2470edc20d25f2192b8250 2020-01-10 15:55:43 this commit introduced issue with 'lbu commit -e' 2020-01-10 15:57:01 'enc -ciphers' should be 'list --cipher-commands' 2020-01-10 15:58:03 probably need more cleanup but I would left this for someone experienced in POSIX shell 2020-01-10 15:58:05 ncopa: thanks for answering on stackoverflow as well 2020-01-10 15:59:20 here is openssl issue https://github.com/elasticdog/transcrypt/pull/48 2020-01-10 16:05:15 hum 2020-01-10 16:05:30 nss on armhf also gets neon support 2020-01-10 16:05:40 which probably is not what we want 2020-01-10 16:05:56 i guess there are not many armv6 board with neon support 2020-01-10 16:12:50 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 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 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 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 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 long term solution is to fix it upstream, making it iterative instead of recursive 2020-01-10 16:26:17 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 ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/IYhaGgCGJjfmdhrUGfueiwDl > 2020-01-10 16:29:15 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 Could it be whitelisted then? 2020-01-10 16:30:45 <_ikke_> yes 2020-01-10 16:30:59 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 it also can't detect usage of cat <<- EOF 2020-01-10 16:31:27 very annoying when it hits one 2020-01-10 16:45:32 ncopa: Yup, I'll try looking into it after exams :) 2020-01-10 16:50:18 any opinions on !2816 ? @everyone 2020-01-10 17:07:57 north1: there is mentioned build mesa few times, I'm for that solution if someone would make this :) 2020-01-10 17:41:48 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 north1: was not aware of the mesa megadrivers 2020-01-10 17:43:29 Oh, oops 2020-01-10 17:43:40 That part was autogenerated by my git hooks 2020-01-10 17:43:42 yes we should definitively merge them 2020-01-10 17:43:48 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 Too late now, I suppose 2020-01-10 17:45:36 <_ikke_> not a big issue 2020-01-10 17:45:37 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 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 Thanks :) 2020-01-10 17:53:12 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 but the whole replaces/provides stuff is very confusing for me 2020-01-10 18:21:34 yes, provides should make apk replace the old package 2020-01-10 18:21:59 replaces give apk permissions for one package to take over ownership of files 2020-01-10 18:23:07 ^ this sentence should go to APKNUILD man page 2020-01-10 18:25:56 I need advice for !2212 2020-01-10 18:26:51 delete /etc/iwd/main.conf, try to rewrite it, or inform user on upgrade to fix it manually 2020-01-10 18:27:22 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 nmeum: ping 2020-01-10 21:12:56 looks like he is not online 2020-01-10 21:14:27 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 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 oh, sorry. but it is mentioned in edge push 2020-01-10 21:21:14 (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 cargo --features is weird 2020-01-11 08:36:04 mps: pong (sorry was afk yesterday evening). did firefox-esr pass on 3.11? 2020-01-11 08:48:23 nmeum: np 2020-01-11 08:48:39 yes, it pass and works fine 2020-01-11 08:49:13 I installed it on one notebook yesterday and it works without 2020-01-11 08:49:48 small note: only commit msg should be changed from 'See #11118' to 'fixes: #11118' 2020-01-11 08:50:42 I will be afk for about 5 hours 2020-01-11 08:50:57 mps: ok, thanks a lot will cherry pick it to 3.11-stable now 2020-01-11 08:52:43 yes, that it what I did, but 'cherry picked' by hand. time for me to relearn cherry picking :) 2020-01-11 08:52:59 pushed, thanks 2020-01-11 08:53:00 see you, have to go 2020-01-11 08:53:09 bye 2020-01-11 08:53:14 thanks a lot for testing the change :) 2020-01-11 08:53:26 np 2020-01-11 09:58:03 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 I removed the replaces from https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2816 2020-01-11 11:31:24 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 Yup 2020-01-11 12:15:43 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 Thanks 2020-01-11 15:39:56 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 :) 2020-01-11 16:46:11 why is alpine using EUI64 by default? even windows vista uses random IPv6 link-local addresses 2020-01-11 16:47:44 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 (only on a local network) 2020-01-11 16:59:04 ls 2020-01-11 17:07:08 paper_, https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/alpine-baselayout/APKBUILD#L180 2020-01-11 17:07:44 using but not on your current interface since nobody know what name the interface will have 2020-01-11 17:08:19 ex. net.ipv6.conf.eth0.use_tempaddr 2020-01-11 17:08:36 but not all devices got eth0 so somebody would have to write some script... 2020-01-11 17:11:30 paper_, and even here it is explained: https://wiki.alpinelinux.org/wiki/Sysctl.conf 2020-01-11 17:14:30 aha, it's per-interface 2020-01-11 17:17:58 hmm... on void there isn't anything like this and I still get random addresses 2020-01-11 17:18:16 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 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 well, it is for ppp but probably got something like that 2020-01-11 17:24:55 hmm... interesting, thanks 2020-01-11 18:45:36 how to make changes in alpine-conf repo over gl.a.o? same as with aports? 2020-01-11 18:46:10 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 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 yes 2020-01-11 18:51:31 <_ikke_> No, you have not 2020-01-11 18:52:12 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 tpaste* 2020-01-11 18:52:50 <_ikke_> a MR is easier to reply on 2020-01-11 18:53:52 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 true, forgot that 2020-01-11 18:55:39 but, anyway have make fork of repo alpine-conf? 2020-01-11 18:55:51 <_ikke_> yes 2020-01-11 18:56:20 hmm, will see 2020-01-11 18:56:38 _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 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 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 hm, a lot of work 2020-01-11 19:05:03 I would move to gitlab as cannonical and drop git.a.o, but I'm not you :) 2020-01-11 19:05:26 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 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 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 notebook? 2020-01-11 19:50:22 <_ikke_> yes 2020-01-11 19:52:07 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 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 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 hello 2020-01-12 08:59:19 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 because the new address seems to be ~alpine/aports@ instead 2020-01-12 09:14:17 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 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 I just verbatim copied the project description, should I send a v2? 2020-01-12 09:41:15 I thought so (about description) 2020-01-12 09:42:35 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 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 I have dozen of ports to package to complete my alpine desktop :-) 2020-01-12 09:47:12 sorry, meant to say 'change it and commit with amend option before push to aports' 2020-01-12 09:50:54 yes I agree with your suggestion :) 2020-01-12 09:51:20 ok, let me find url of your post :) 2020-01-12 09:54:33 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 (though, it would be easier to follow over gitlab.a.o) 2020-01-12 09:59:32 okay 2020-01-12 09:59:51 I'll do there instead then 2020-01-12 10:02:53 do what is easier for you 2020-01-12 10:03:11 I just expressed my preference :) 2020-01-12 10:04:35 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 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 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 okay thanks 2020-01-12 11:26:33 <_ikke_> This ofcourse only counts for sodeps 2020-01-12 11:26:57 what is the reason behind the -libs subpkg? 2020-01-12 11:47:47 mps, updated according to your comments and merge requests sent to gitlab 2020-01-12 11:53:42 markand: https://gitlab.alpinelinux.org/markand/aports/-/jobs/34904 2020-01-12 11:54:14 pkgver="20200102" 2020-01-12 12:00:13 looks like s390x CI is stuck 2020-01-12 12:03:12 markand: pushed with fixing pkgver 2020-01-12 12:06:00 thanks <3 2020-01-12 12:06:12 my first contrib \o/ 2020-01-12 12:06:31 next is wesnoth 2020-01-12 12:07:23 isn't next tiled 2020-01-12 12:07:56 yes but it's proposed, wesnoth has to be tested yet (and is much more complex) 2020-01-12 12:09:09 tiled failed on CI, make[1]: /usr/lib/qt5/bin/lrelease: Command not found 2020-01-12 12:10:12 qt5-qttools-dev should be added to makedepends 2020-01-12 12:11:58 and pkgver="1.3.1", num literal must be without quotes 2020-01-12 12:13:24 and small nitpcik, pkgdesc="A powerful tile map editor", s/^A\ // 2020-01-12 12:13:45 nitpick* 2020-01-12 12:14:58 this reminds me about George Bernard Show 'Fresh fish sold here' anecdote 2020-01-12 12:15:18 ? 2020-01-12 12:16:40 s/Show/Shaw/ 2020-01-12 12:16:40 mps meant to say: this reminds me about George Bernard Shaw 'Fresh fish sold here' anecdote 2020-01-12 12:41:58 so openblas-dev has no BLAS header files 2020-01-12 12:42:06 but blas-dev does? 2020-01-12 12:47:39 https://git.alpinelinux.org/aports/tree/community/openblas/APKBUILD 2020-01-12 12:48:10 and according to the git repo https://github.com/xianyi/OpenBLAS they are there in the root directory 2020-01-12 12:52:09 okay so apparently it's not installing those headers because NO_BLAS=1 2020-01-12 12:53:53 hm, why we have blas and openblas in repo 2020-01-12 12:57:06 there's no comments as to why it's disabled... 2020-01-12 12:57:22 isn't it kind of useless without the header files? 2020-01-12 12:58:38 ah, blas is subpg of lapack 2020-01-12 13:06:37 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 :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 what does testing all rust consumers mean? 2020-01-12 13:16:47 <_ikke_> No idea myself 2020-01-12 13:20:53 oh god opencv downloads something in its build process 2020-01-12 13:20:56 why are you like thissss 2020-01-12 13:23:01 russkel: I didn't know that the blas is subpackage of lapack package 2020-01-12 13:25:19 _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 yes, rust is nonsensical lang, as is everything from hipsters 2020-01-12 13:27:25 shake harder boy! 2020-01-12 13:32:45 https://github.com/opencv/opencv/issues/15020 2020-01-12 13:33:04 I'm getting the same issue as this, and I think it's some musl libc problem 2020-01-12 13:33:23 return __orig_read(__f, __s, __n); 2020-01-12 13:33:49 any one seen that before? 2020-01-12 13:50:04 russkel/ikke: Testing all rust consumers means making sure all packages depending on Rust still build with it 2020-01-12 13:51:30 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 ? 2020-01-12 13:52:16 Cogitri, ah right 2020-01-12 13:52:29 thanks 2020-01-12 13:52:44 <_ikke_> PureTryOut[m]: yes 2020-01-12 13:52:53 Cool thanks 2020-01-12 13:52:58 <_ikke_> PureTryOut[m]: there is also a test suite 2020-01-12 13:53:37 Cogitri: fyi, firefox 72.0.1 built with -mno-aligned-access still faults when run 2020-01-12 13:53:57 That's unfortunate :/ 2020-01-12 13:54:03 https://github.com/opencv/opencv/issues/15020#issuecomment-573417463 2020-01-12 13:54:11 can anyone offer a hint on this? 2020-01-12 13:54:46 Have you tried building it with --enable debug, adding a -dbg subpackage to get better debugging info, mps? 2020-01-12 13:55:28 no, but dmesg is quite informative 2020-01-12 13:56:04 Alignment error 2020-01-12 13:56:51 not sure is this a rust or musl issue, although imo, suspect is rust 2020-01-12 13:57:35 do you think it is worth some effort to try to build 68.4.1 on armv7? 2020-01-12 13:57:56 find rustc 'target' which could work 2020-01-12 13:59:06 but now when kernel 5.4.11 out I will be busy with it 2020-01-12 14:00:02 I think it finally have important fixes for exynos, allwiner, i915 and amd 2020-01-12 14:21:03 Well, if you had debug info you would know where it fails :) 2020-01-12 14:21:18 The rust target thingie should just work in ff 2020-01-12 14:21:48 unaligned access is not allowed on arm32, that's enough I think 2020-01-12 14:29:52 Yes, but without debugging info you only know that it's happening somewhere in the FF codebase :) 2020-01-12 14:30:13 true 2020-01-12 14:30:46 but I don't have time these days to hunt bug 2020-01-12 14:48:39 hm, just see more 'Alignment trap: AudioIP~ent RPC (30174)' on armv7 not related to firefox 2020-01-12 15:12:42 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 thanks I do this 2020-01-12 15:22:18 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 ah yes it does, it was just pending :) 2020-01-12 17:57:13 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 oh nice, thanks 2020-01-12 17:58:36 downloading it and will test in a few minutes 2020-01-12 17:59:08 hope it will be better (at least to some degree) 2020-01-12 18:03:58 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 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 for me it doesn't crash but sometimes is too much loaded that it become unresponsive 2020-01-12 18:10:28 found that adding some swap helps 2020-01-12 18:11:16 that is, on x86_64 with i915 video driver 2020-01-12 18:11:28 X, not wayland 2020-01-12 21:46:49 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 abuild -h doesn't show any obvious way to do this 2020-01-12 21:47:13 abuild rootpkg 2020-01-12 21:47:53 mps: where are the resulting apks? 2020-01-12 21:48:07 (they don't appear in pwd) 2020-01-12 21:48:15 REPODEST 2020-01-12 21:48:22 abuild -h shows 'rootpkg Run 'package', the split functions and create apks as fakeroot' 2020-01-12 21:48:36 ah 2020-01-12 21:48:43 clandmeter: thanks 2020-01-12 21:48:50 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 _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 _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 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 please i need help on this 2020-01-13 07:36:05 https://cloud.drone.io/alpinelinux/aports/13532/1/1 2020-01-13 07:36:31 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 rahmanshaber[m]: First off, use Gitlab 2020-01-13 08:17:36 yeah. 2020-01-13 08:19:54 mps, did you see my answer regarding autoconf -fi on id3lib? 2020-01-13 08:27:20 markand: no 2020-01-13 08:27:39 where? 2020-01-13 08:30:39 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2974#note_62173 2020-01-13 08:31:37 _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 the only downside : not available in busybox nor busybox's tar 2020-01-13 08:34:21 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 from the head 'autoreconf -vif' is enough 2020-01-13 08:56:08 yes, but not for id3lib 2020-01-13 09:44:50 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 _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 Oh my, that's pretty nice indeed 2020-01-13 10:18:28 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 Didn't test yet, will only be able to test it tonight 2020-01-13 10:19:20 just read 5.5-rc6 log, and looks like fix for i915 landed there 2020-01-13 10:20:55 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 ok, np. had a hope to hear good news :) 2020-01-13 10:22:22 markand: so 'autoreconf -vif' doesn't work for !2974 2020-01-13 10:26:55 mps, no, I think the project is too old 2020-01-13 10:27:28 void/arch use the same preparation 2020-01-13 10:32:17 does ./configure work? 2020-01-13 10:40:40 markand: looks like it doesn't work even with void sample 2020-01-13 10:51:05 markand: 'configure:10393: checking for iomanip.h' ^M configure:10410: error: Missing a vital header file for id3lib 2020-01-13 11:22:56 yes as said it's an old library 2020-01-13 11:23:01 there are lots of patches required 2020-01-13 11:23:18 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2974/diffs#61d246e49835de26bef61b910a71894e91bfca00 2020-01-13 12:09:25 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 pltrz: APKBUILD is shell script so it is possible to do a lot hacks 2020-01-13 12:25:45 ofc, if you build pkg for private repo 2020-01-13 12:27:59 We don't use git clone for the source though 2020-01-13 12:28:03 Always use tarballs if possible 2020-01-13 12:29:41 yes, I forgot to add that 'git clone' will not be accepted to alpine 2020-01-13 12:32:07 pltrz: you can use commit id as a tarball from github 2020-01-13 12:45:02 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 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 PureTryOut: `DABUILD_ARCH=x86|x86_64|aarch64|armhf|armv7. Specifies architecture for build container. Default: $(uname -m).` 2020-01-13 14:44:50 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 needs binfmt set up though 2020-01-13 14:45:01 <_ikke_> right ^ 2020-01-13 14:45:02 z3ntu: I know, that is what I mentioned 2020-01-13 14:45:13 That won't work though, z3ntu 2020-01-13 14:45:36 Ah, IRC bridge took a little to sync up, don't mind me 2020-01-13 14:45:45 But I guess it isn't supported then 2020-01-13 14:46:04 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 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 _ikke_: oh thanks! 2020-01-13 15:31:34 Is there a logo of Alpine Linux available in some package? 2020-01-13 15:36:42 PureTryOut[m]: Yeah, usually the lag isn't too bad though 2020-01-13 15:42:42 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 north1: you are kidding with me :) 2020-01-13 16:33:00 Uh? 2020-01-13 16:33:57 how did you manage to push mutt so fast 2020-01-13 16:34:36 I didn't noticed it finish on CI, and see it pushed 2020-01-13 16:36:10 It was green, commit changes looked alright 2020-01-13 16:36:21 Just happened to be at the right place at the right time 2020-01-13 16:36:39 I'm not criticizing you, just surprised (positive) with your speed 2020-01-13 16:40:09 there is another 'green' :) !3011 2020-01-13 16:41:55 <_ikke_> done :P 2020-01-13 16:42:37 heh, I see :) 2020-01-13 16:43:04 marathon started :) 2020-01-13 16:43:27 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 !2974 2020-01-13 16:44:12 ah, did you finished it 2020-01-13 16:45:53 did you read guide about using pkgname in source url, sorry for nitpick 2020-01-13 16:46:02 ttps://sourceforge.net/projects/$pkgname/files/$pkgname/$pkgver/$pkgname-$pkgver.tar.gz 2020-01-13 16:46:33 yes I've seen the Cogitri comment on the easytag MR, I'll change it 2020-01-13 16:46:36 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 not a big problem, but anyway 2020-01-13 16:48:41 - https://sourceforge.net/projects/$pkgname/files/$pkgname/$pkgver/$pkgname-$pkgver.tar.gz 2020-01-13 16:48:44 + http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz 2020-01-13 16:48:47 correct like this? 2020-01-13 16:48:50 (according to the wiki guide) 2020-01-13 16:49:12 <_ikke_> s/\$pkgname/id3lib 2020-01-13 16:49:25 http://downloads.sourceforge.net/id3lib/files/id3lib/ 2020-01-13 16:49:46 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 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 well, personally I don't care 2020-01-13 16:50:13 yeah newapkbuild generated APKBUILDs that are not lint compliant :P 2020-01-13 16:50:26 e.g. it still uses quotes under pkgver 2020-01-13 16:51:58 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 mps, pushed the source variable update 2020-01-13 16:58:38 I see, waiting for CI 2020-01-13 17:01:01 markand: pushed 2020-01-13 19:07:52 mkinitfs does not have a repo on gitlab 2020-01-13 19:15:59 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 (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 do i need to check anytihng here 2020-01-14 06:28:35 ACTION uploaded an image: image.png (29KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/xTzYLmDwafQZIntGSRuFVJBE > 2020-01-14 06:35:37 As of now, no 2020-01-14 06:36:57 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 Cogitri: thanks. 2020-01-14 06:43:41 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3030 2020-01-14 06:45:08 why this one failed , it is not related to my commit. but other builds fine 2020-01-14 06:45:08 https://gitlab.alpinelinux.org/rahmanshaber/aports/-/jobs/35715 2020-01-14 06:46:27 Cogitri: 2020-01-14 06:54:19 Ah yes, the s390x CI runner can be a bit funny at times 2020-01-14 06:58:01 Cogitri: ok, then please accept the MR. 2020-01-14 07:03:27 Maybe someone else will give it a look, currently busy learning for exams 2020-01-14 09:11:03 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 I've re-ran abuild-keygen -a -i and deleted ~/packages, worked 2020-01-14 09:31:39 FWIW deleting the APKINDEX and running `abuild index` probably would've done the trick too 2020-01-14 09:34:50 Would be nice if !2947 can be reviewed, fixes a boot failure. 2020-01-14 10:11:02 ncopa: Can you maybe take a look at 2841 later? Most of D blocks on it right now 2020-01-14 10:19:54 someone please accept the MR. All good . 2020-01-14 10:19:55 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3030 2020-01-14 10:22:14 does it solve any urgent issue? 2020-01-14 10:22:22 !3030 2020-01-14 10:22:44 hm, look like commit msg is wrong 2020-01-14 10:24:21 hmm, sorry, misslead by 'community/c suite:' 2020-01-14 10:25:42 anyway, could be better reworded 2020-01-14 10:28:39 mps: yes, for postmarketOS. 2020-01-14 10:29:30 Do yyou want me to change anything? 2020-01-14 10:31:12 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 I looked for pkg 'c suite' :) 2020-01-14 10:33:21 though particular commits looks fine 2020-01-14 10:45:26 Cogitri: re !2841 why does it fail? 2020-01-14 10:46:56 ah, "due to the ada thing" 2020-01-14 10:48:04 Yup 2020-01-14 10:48:25 I've used the resulting binaries for gdc for a few days now and they work pretty good 2020-01-14 10:48:42 Although long term we probably don't want to use gdc for anything but boostraping ldc/dmd 2020-01-14 10:48:54 So we don't have to patch it into shape all the time 2020-01-14 10:55:09 mps: all the apps in that MR is called C Suite 2020-01-14 10:56:13 I thought it is related to C lang, until looked 2020-01-14 10:57:06 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 how can we trigger MR to go to CI? 2020-01-14 11:05:52 C means CoreApps. and whole name is CoreApps Suite 2020-01-14 11:06:14 https://cubocore.gitlab.io/ 2020-01-14 11:06:18 mps: 2020-01-14 11:06:50 a lot of MR have 'Could not retrieve the pipeline status.' 2020-01-14 11:07:24 rahmanshaber[m]: 'CoreApps' looks fine to me :) 2020-01-14 11:08:08 done 2020-01-14 11:08:08 but I'm not one who should tell you how you will name your software 2020-01-14 11:09:42 problem is that it is not entered CI so not sure will it build on builders 2020-01-14 11:11:12 ohh, so i have to wait/ 2020-01-14 11:12:06 gitlab is upgraded few minutes ago, this can be reason 2020-01-14 12:13:59 rahmanshaber[m]: MR passed CI 2020-01-14 12:31:22 great. 2020-01-14 13:13:08 who use D? 2020-01-14 13:13:21 I mean, are there even packages written in D in the repository? 2020-01-14 13:14:39 There is corecollector and Tilix 2020-01-14 13:17:53 and GtkD 2020-01-14 13:24:27 im kinda frustrated of grub 2020-01-14 13:25:32 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 because you could put that in your grub config 2020-01-14 13:25:59 yes 2020-01-14 13:26:05 now you need to regenerate the grub config every time you do any change 2020-01-14 13:26:19 really? 2020-01-14 13:26:37 so instead of running lilo after a config chagne you now need to run grub-mkconfig 2020-01-14 13:26:40 yup 2020-01-14 13:26:47 the config is generated nowdays 2020-01-14 13:27:02 and is insanely complex 2020-01-14 13:27:09 its not technically required, but its the ease of use that drives this 2020-01-14 13:27:19 im confident a static grub config would work out for most usecases 2020-01-14 13:27:50 long time I used it by creating menu file by hand and had to change it rarely 2020-01-14 13:28:39 ncopa: iirc, you introduced grub from debian 2020-01-14 13:29:09 grub1 was kinda designed to have static menu.lst 2020-01-14 13:29:17 with grub2 things changed dramatically 2020-01-14 13:29:31 same can be done with grub2 2020-01-14 13:29:46 that is where i am going at 2020-01-14 13:30:03 i am considering write a grub-mkconfig-alpine 2020-01-14 13:30:16 which creates a simplified static grub config 2020-01-14 13:30:24 where I have grub I disabled auto update it 2020-01-14 13:31:06 the generated config file is so complex that its not even useful as starting point 2020-01-14 13:31:09 grub-mkconfig-alpine is good idea 2020-01-14 13:31:36 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 debina style 2020-01-14 13:31:57 ACTION likes rEFInd for dynamically generating that 2020-01-14 13:31:59 debian* 2020-01-14 13:32:31 the upstream grub-mkconfig does not even work with alpine 2020-01-14 13:32:40 it tries to work everywhere, but it doesnt 2020-01-14 13:33:20 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 i think we need some sort of gerenrator similar to our update-extlinux 2020-01-14 13:34:25 update-grub 2020-01-14 13:34:47 so you can `apk add linux-$someflavor` and have it added to your boot menu 2020-01-14 13:34:49 also 2020-01-14 13:35:20 figuring out how to set the default kernel to boot in config is overly complex 2020-01-14 13:35:40 https://unix.stackexchange.com/questions/198003/set-default-kernel-in-grub 2020-01-14 13:35:51 which is my current problem 2020-01-14 13:35:55 some file in etc, like /etc/grub-config? 2020-01-14 13:36:24 im just thinking that the upstream grub-mkconfig is overengineered 2020-01-14 13:37:08 it is, imo 2020-01-14 13:37:16 i wonder if we could drop it 2020-01-14 13:37:24 and use rEFInd only 2020-01-14 13:37:30 or similar 2020-01-14 13:37:44 the challenge is that there are not bootloader that works on all architectures 2020-01-14 13:37:56 it is made to cover as most possible corner cases, and because that it is complicated 2020-01-14 13:37:59 grub is the closest you get 2020-01-14 13:38:21 yeah, it tries to solve all cornercases and as a result it fails to solve the simple ones 2020-01-14 13:38:30 without patching it 2020-01-14 13:42:32 if you make grub-mkconfig for alpine I'm ready to test it 2020-01-14 13:44:26 Well, rEFInd works on all my machines that have EFI 2020-01-14 13:46:42 hum, i guess we could have an update-grub 2020-01-14 13:47:00 Cogitri: does it work with arm? 2020-01-14 13:47:17 the good thing with grub is that it works on all architectures (except s390x) 2020-01-14 13:51:04 afaik, grub doesn't work on arm32 2020-01-14 13:51:13 ah 2020-01-14 13:51:15 true 2020-01-14 13:51:17 uboot 2020-01-14 13:52:06 grub-set-default doesnt work? 2020-01-14 13:52:12 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 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 glibc? 2020-01-14 13:53:48 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 MY-R: let me try 2020-01-14 13:57:24 ncopa: Dunno, I only have x86_64 machines 2020-01-14 13:59:08 autoreconf: running: autopoint --force 2020-01-14 13:59:08 tar: This does not look like a tar archive 2020-01-14 13:59:14 pltrz: last time I built slstatus it worked, on alpine I mean 2020-01-14 13:59:50 argh.. i wanna throw grub out the window... 2020-01-14 14:00:22 :-) 2020-01-14 14:01:14 mps, how do you disable auto generation of grub configuration? 2020-01-14 14:02:06 MY-R: no, grub-set-default does not work for me 2020-01-14 14:03:11 pltrz: yes, tried again to build slstatus, it works fine 2020-01-14 14:04:29 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 mps: let me try with default config.h and isolate the problem more 2020-01-14 14:06:34 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 markand: add 'exit 0' in line 3, file /usr/sbin/grub-mkconfig :) 2020-01-14 14:06:42 the menu needs to be regenerated 2020-01-14 14:09:36 pltrz: can you please share your config.h? 2020-01-14 14:10:30 ncopa, ye need GRUB_DEFAULT=saved and after grub-mkconfig 2020-01-14 14:10:56 and then setting default one is done by that grub-set-default script without regenerating grub.cfg 2020-01-14 14:13:26 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 pltrz: that config compiles for me 2020-01-14 14:17:35 ah, its a runtime error 2020-01-14 14:17:58 ncopa: yeah exactly. sorry if I wasn't clear 2020-01-14 14:25:32 ok, i found it 2020-01-14 14:25:48 pltrz: seems like %l is not posix. use %I instead 2020-01-14 14:26:07 use this as reference: https://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html 2020-01-14 14:27:30 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 is my MR merged, i am confused 2020-01-14 14:30:30 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3030 2020-01-14 14:31:21 ncopa: ah I see. thanks so much, musl does not include non-posix extensions, correct? 2020-01-14 14:33:09 pltrz: musl implements some extensions but not all 2020-01-14 14:33:39 basically, the only thing you can expect to be implemented are what is defined in the standards 2020-01-14 14:40:43 rahmanshaber[m]: patience is one of most important developers virtue :) 2020-01-14 14:40:57 rahmanshaber[m]: seems like its not 2020-01-14 14:41:20 I wanted to push but would like to have you online here 2020-01-14 14:41:36 in case it fails on builders 2020-01-14 14:41:54 lets push it 2020-01-14 14:41:54 it is about 20 pkgs 2020-01-14 14:42:12 ncopa: ok 2020-01-14 14:42:24 ncopa: thanks for the valuable info :) 2020-01-14 14:43:03 rahmanshaber[m]: pushed 2020-01-14 14:44:37 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 thanks for the support 2020-01-14 14:46:18 rahmanshaber[m]: well, I joking a little, I understand you, don't worry :) 2020-01-14 14:46:57 I understand. thanks 2020-01-14 14:47:32 you are welcome 2020-01-14 14:54:03 wooohoo, back again, i missed you guys ;0 2020-01-14 14:58:28 rahmanshaber[m]: build-edge-armhf 2020-01-14 14:58:33 failed community/coretime 2020-01-14 15:11:48 I build in ci and others. 2020-01-14 15:11:48 mps 2020-01-14 15:12:21 yes, it passed but we don't have armhf CI 2020-01-14 15:12:40 it passed on others 2020-01-14 15:51:19 mps: any logs? 2020-01-14 15:52:47 ask _ikke_, he will know if log can be downoladed 2020-01-14 15:54:40 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 community/coretime on armhf 2020-01-14 15:55:50 Yes 2020-01-14 15:56:25 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 edge 2020-01-14 15:56:45 <_ikke_> community 2020-01-14 15:56:53 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 hmm, 2020-01-14 15:58:32 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 15:57 ..... algitbot| build-edge-armhf: failed to build coretime: 2020-01-14 15:59:46 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 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 _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 https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/coretime/coretime-2.8.0-r0.log 2020-01-14 16:26:55 qt5-qtmultimedia-dev (missing): 2020-01-14 16:27:16 Happens due to qtdeclarative getting disabled 2020-01-14 16:27:22 TL;DR disable 2020-01-14 16:27:26 yes 2020-01-14 16:33:44 but it builds fine in ci............... 2020-01-14 16:33:44 ok so should i add the qt5-multimedia now? 2020-01-14 16:34:18 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 ohh. 2020-01-14 16:35:15 i am now adding the missing depend. 2020-01-14 16:36:23 You can't do that 2020-01-14 16:36:29 Since it's not available on armhf 2020-01-14 16:36:30 Cogitri: see this. qt5-multimedia is already in the depend 2020-01-14 16:36:30 https://gitlab.alpinelinux.org/alpine/aports/blob/master/community/coretime/APKBUILD 2020-01-14 16:37:09 Qt5-multimedia? 2020-01-14 16:37:41 rahmanshaber[m]: qt5-multimedia doesn't build on armhf 2020-01-14 16:39:11 Because qtdeclarative is disabled armhf, which qtmultimedia needs 2020-01-14 16:42:32 corefm also failed . 2020-01-14 16:42:51 is that happened recently? 2020-01-14 16:43:56 PureTryOut disabled it a week ago or so 2020-01-14 16:44:06 git log knows better probably 2020-01-14 16:45:21 I see. 2020-01-14 16:48:29 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 https://git.alpinelinux.org/aports/tree/community/qt5-qtdeclarative/APKBUILD#n13 2020-01-14 16:49:03 https://git.alpinelinux.org/aports/commit/community/qt5-qtdeclarative?id=d33b26afd532c021810d466a6c1a229d6e187ca3 2020-01-14 16:49:42 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 so qt5.14 have any fix? 2020-01-14 17:05:03 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 I did. But I bug report only says qml. 2020-01-14 17:31:10 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 If it's the KDE stuff, I did make 2 MR's for those 2020-01-14 17:33:05 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 Ah, missed those, my bad 2020-01-14 17:35:12 ACTION is merging 2020-01-14 17:36:38 <_ikke_> kdnssd 2020-01-14 17:37:44 Np 2020-01-14 22:02:48 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 sh: write error: No space left on device 2020-01-15 07:22:57 ERROR: Job failed: exit code 1 2020-01-15 07:22:58 ow 2020-01-15 07:23:05 this is happening on the gitlab lint 2020-01-15 07:29:18 Oh, is that my runner? 2020-01-15 07:29:23 Can you send the job log in here? 2020-01-15 07:33:31 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3039 2020-01-15 07:33:32 on this one 2020-01-15 07:41:10 _ikke_: https://gitlab.alpinelinux.org/markand/aports/-/jobs/36154 2020-01-15 07:41:23 I suppose that's your runner 2020-01-15 08:42:49 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 ncopa, https://github.com/gliderlabs/docker-alpine/issues/476 2020-01-15 10:55:30 their problem werent with dns lookup but with resolving rev dns... 2020-01-15 10:55:34 s 2020-01-15 10:58:30 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 title says: Apparent DNS failure in Docker image alpine:3.8, nslookup: can't resolve '(null)' 2020-01-15 11:03:32 but it resolve correctly addresses 2020-01-15 11:03:39 so the isse was about the "nslookup: can't resolve '(null)'" 2020-01-15 11:03:53 correct. resolving works, but gives error message 2020-01-15 11:04:10 "I'm baffled that nslookup complains yet finds the IP address. In comparison, ping works perfectly." 2020-01-15 11:04:16 but error is about not resolving rev dns 2020-01-15 11:04:48 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 BIG version just disabled check that 2020-01-15 11:06:39 no, nobody gets revdns, because the busybox code does not work with musl 2020-01-15 11:06:45 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 no 2020-01-15 11:07:03 working reverse dens would not solve that 2020-01-15 11:07:10 s/dens/dns/ 2020-01-15 11:07:10 ncopa meant to say: working reverse dns would not solve that 2020-01-15 11:07:21 https://github.com/gliderlabs/docker-alpine/issues/476#issuecomment-457124840 2020-01-15 11:07:24 http://tpaste.us/0Pz6 look, before output got included revdns checks, after upgrade it doesnt even show it 2020-01-15 11:08:29 https://git.busybox.net/busybox/tree/networking/nslookup.c#n208 2020-01-15 11:09:24 the comment says that busybox expects res_init() to find what dns server was used 2020-01-15 11:09:32 but res_init() in musl does nothing 2020-01-15 11:10:33 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 "musl compatible nslookup" 2020-01-15 11:11:33 implying that the smaller variant is not compatible with musl 2020-01-15 11:11:52 and bigger doesnt show revdns :P 2020-01-15 11:14:17 http://tpaste.us/adWo 2020-01-15 11:14:20 if you need full featured nslookup: apk add cmd:nslooup 2020-01-15 11:14:43 and that is from openwrt.... so every output is little different already 2020-01-15 11:15:02 ye I know 2020-01-15 11:15:36 what this means 2020-01-15 11:15:36 https://gitlab.alpinelinux.org/rahmanshaber/aports/-/jobs/36299 2020-01-15 11:17:51 $ busybox nslookup alpinelinux.org 1.1.1.1 | tpaste 2020-01-15 11:17:51 http://tpaste.us/NmJ6 2020-01-15 11:18:55 rahmanshaber[m]: sounds like there are spaces instead of tabs 2020-01-15 11:19:09 MC:[AL29]:APKBUILD:12:$pkgname should not be used in the source url 2020-01-15 11:19:24 means that you shoudl expand the pkgname instead of use $pkgname 2020-01-15 11:30:22 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 so basically instead of having initramfs image + rootfs image, one would have 1 big fat initramfs image 2020-01-15 11:31:04 iirc I heard somebody did that before 2020-01-15 11:32:36 no. never done that 2020-01-15 11:32:47 so you mean that the squashfs root is embedded in initramfs? 2020-01-15 11:32:58 why not have the entire rootfs in initramfs then? 2020-01-15 11:33:13 yes, written to at some byte offset, etc. 2020-01-15 11:33:29 yeah that's be one way 2020-01-15 11:34:16 iirc there was some parameter like, root=0xabcdef12345 that point to an address in memory 2020-01-15 11:34:57 why do you want the root as squashfs? 2020-01-15 11:35:37 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 you could just tuff everything in the initramfs 2020-01-15 11:36:03 yeah 2020-01-15 11:36:30 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 that should be possible 2020-01-15 11:37:05 then you dont need to do any switch_root/pivot_root 2020-01-15 11:39:11 the reason that we did a switch_root was that we wanted keep the initramfs minimal 2020-01-15 11:39:37 and it also give us the possibility to configure the size of the tmpfs root 2020-01-15 11:39:48 right 2020-01-15 11:41:50 we also wanted be flexible with what the user has installed in the tmpfs root 2020-01-15 11:42:18 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 and then you could simply have it all in initramfs 2020-01-15 11:44:03 ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/ggYTgTMaebZehcrOzaxFPQsZ > 2020-01-15 11:44:15 sorry for spam. 2020-01-15 11:51:10 Submit a MR, reviewing something in IRC is a pain 2020-01-15 12:31:29 Cogitri: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3074 2020-01-15 13:13:05 ncopa: i have identified another software that needs the pkgconf treatment 2020-01-15 13:13:09 ncopa: PPP 2020-01-15 13:52:43 ok? 2020-01-15 13:59:37 what do you mean with "pkgconf treatment" and why PPP? 2020-01-15 14:05:29 ncopa: PPP needs a complete rewrite 2020-01-15 14:05:40 like, i had the "pleasure" of configuring it, and it is just awful 2020-01-15 14:05:56 it is the same kind of awful that made me want to write pkgconf :P 2020-01-15 14:06:26 oh, ha! that makes sense 2020-01-15 14:06:46 the ppp code is sort of old too 2020-01-15 14:08:41 yeah, well i have dozens more sites to config :( 2020-01-15 14:09:07 libreppp or pppnext or pppconf? :) 2020-01-15 14:10:10 the whole thing seems unnecessarily fragile 2020-01-15 14:14:36 clandmeter: i am thinking pppclient -t pppoe -i eth0 -u foo@ISP -s SECRET 2020-01-15 14:15:08 is this an artifact on how alpine packages it? 2020-01-15 14:15:38 AinNero: no, the software was originally written in the 1980s and hasn't left the 1980s 2020-01-15 14:16:07 let's AI it 2020-01-15 14:16:46 :D 2020-01-15 14:17:42 thats no surprise to me 2020-01-15 14:17:58 the modem in my laptop is still interfaces 80ies style 2020-01-15 14:18:05 *interfaced 2020-01-15 14:18:40 there is a newer interface, not sure how its called, afair it makes wwan[0-9] interfaces 2020-01-15 14:18:46 modemmanager has support for that 2020-01-15 14:19:10 thats not the same thing 2020-01-15 14:19:54 what kind of modem do you want to interface with? 2020-01-15 14:20:35 a DSL modem 2020-01-15 14:20:37 don't worry about it 2020-01-15 14:20:41 i know what i am doing (: 2020-01-15 14:21:30 im using ppp-daemon with reconnect like mobile data 2020-01-15 14:25:23 the LTE modem i have just exposes ethernet 2020-01-15 14:28:43 running abuild gives me an error code (1, no child process), any ideas? https://pastebin.com/6ZjF9pGX 2020-01-15 15:53:19 fedora has atleast 191 patches to grub 2020-01-15 15:53:28 https://src.fedoraproject.org/rpms/grub2/tree/master 2020-01-15 15:53:36 i am tempted to use a handful of them 2020-01-15 15:53:40 remove borders from menu 2020-01-15 15:53:52 remove GNU GRub title 2020-01-15 15:53:59 fix the help text 2020-01-15 15:54:21 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 Nice :^) 2020-01-15 15:59:25 Can't grub release an update? 2020-01-15 16:04:22 there is an update out 2020-01-15 16:04:24 2.04 2020-01-15 16:04:28 there is an update 2020-01-15 16:04:29 or 2 2020-01-15 16:04:29 which im working on 2020-01-15 16:04:52 i guess fedora is on the latest version? 2020-01-15 16:04:58 yes 2020-01-15 16:05:09 i'd love to remove those borders and stuff 2020-01-15 16:05:16 but im not sure its worth the time 2020-01-15 16:05:38 i dont really care 2020-01-15 16:05:51 removing the borders will require some related patches that fixes indent and margins and stuff 2020-01-15 16:06:07 i think i'll keep it as upstream for now 2020-01-15 16:06:09 i dont usually stare at my grub menu 2020-01-15 16:06:15 exactly 2020-01-15 16:13:43 And messing with grub sounds risky 2020-01-15 16:16:43 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 we have syslinux for x86 that is pretty nice 2020-01-15 16:18:15 another thing i wonder is if we actually need a bootloader with uefi 2020-01-15 16:18:22 ACTION waiting for grub 2.05 with LUKS2 support 2020-01-15 16:18:24 we could boot directly into kernel as i understand 2020-01-15 16:21:03 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 boot kernel directly is impractical 2020-01-15 16:21:59 ncopa: will you hack efibootmgr in your new install script? 2020-01-15 16:30:44 i guess i should 2020-01-15 16:35:43 while speaking of booting 2020-01-15 16:36:03 im thinking of if we should do disk images releases 2020-01-15 16:36:12 and if we do, how 2020-01-15 16:36:55 <_ikke_> You mean rather than iso? 2020-01-15 16:37:03 instead of iso yes 2020-01-15 16:37:12 or instead of rpi tarball 2020-01-15 16:37:58 im thinking that we could have 2 partitions, one /boot (vfat for uefi support) and one ext4 2020-01-15 16:38:42 the nice thing with ext4 is that it can be expanded 2020-01-15 16:39:03 but i dont know 2020-01-15 16:39:41 yes, and I talked here or #alpine-linux about img idea about 6 months ago 2020-01-15 16:40:09 that is how Armbian do for arm releases for different boards 2020-01-15 16:40:28 we should have a discussion on mailing list i suppose 2020-01-15 16:40:45 basically, i'd like to investigate what different distros do 2020-01-15 16:41:14 another option would be like Arch alarm, tarball with guide for every SBC/board variant 2020-01-15 16:41:14 ubuntu, arch linux, fedora, void linux, and maybe even bsds 2020-01-15 16:41:59 arch alarm method is what I would prefer 2020-01-15 16:44:19 (annoying to repeat, but I dislike new ML, sorry) 2020-01-15 16:45:14 we have understood that 2020-01-15 16:47:12 nvm, I can prepare script with short guide how to install alpine from tarball on few arm board 2020-01-15 16:47:47 but would like if someone is ready to proof read it and make/propose changes 2020-01-15 16:48:54 (this reminds me that I should update script and giude how to install arm under qemu) 2020-01-15 17:09:01 ncopa playing hard with grub, /me preparing usb drive with .iso Alpine just in case of boot recovery ;) 2020-01-15 17:10:15 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 not that grub releases often... 2020-01-15 17:11:09 better keep it "vanilla" as much possible imho 2020-01-15 17:13:11 true, fixing/removing patches after release would be nightmare 2020-01-15 18:32:27 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 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 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 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 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 Thx Cogitri i'll try that! keep up the good work... 2020-01-15 19:29:54 ncopa: grub doesn't seem to be comfy on the builders 2020-01-15 19:39:56 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 thats because protocol itself is complex 2020-01-15 19:40:50 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 Yes 2020-01-15 19:42:26 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 Let's see how that goes 2020-01-15 19:42:52 Autotools sure is fun :^) 2020-01-15 19:42:55 <_ikke_> heh 2020-01-15 19:43:20 Well, with that dep added autoreconf goes through so that's nice 2020-01-15 19:43:37 !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 Thank you :) 2020-01-15 19:48:41 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 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 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 Makes sense, it doesn't automatically upgrade your EFI file/bios boot thingie upon upgrading the package 2020-01-15 20:40:54 yep, true! 2020-01-15 20:52:48 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 turns out: our localmount services never invoked fuser https://git.alpinelinux.org/aports/commit/?id=6b49c2098d96f6ec7872e48c465cb5f9828da4b1 2020-01-15 21:05:54 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 well…it's been bothering me forever. finally got around to investigate it further and fix it 2020-01-15 21:07:44 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 something with mount/read dunno, is just too quick to notice... will try pay more attention "next" time 2020-01-16 04:22:01 do i need to put this in a single commit? 2020-01-16 04:22:02 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 _ikke_: i have no idea what i did. 2020-01-16 05:32:19 i really hate git. 2020-01-16 05:32:47 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 yes 2020-01-16 05:35:06 <_ikke_> does git status say your working tree is clean? 2020-01-16 05:35:46 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 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 <_ikke_ "I can fix it for you if you want"> please do. 2020-01-16 05:40:15 <_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 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 <_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 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 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 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 <_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 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 nice. 2020-01-16 06:01:27 <_ikke_> https://dev.alpinelinux.org/archive/aports.bundle 2020-01-16 06:03:16 Morning 2020-01-16 06:03:21 <_ikke_> hi 2020-01-16 07:04:30 morning 2020-01-16 07:05:11 do we want to backport the NFT_FIB_IPV* config changes to 3.11-stable? 2020-01-16 07:05:46 c1a44df21adc1008b4d6432e9c841bdabfcf8ba4, f2ca3420aaf2656a2bcdf30cbd7bac0a33d19ec6, and b521f901c522a1ada8deeeb5278b0e3fac333cf1 2020-01-16 07:06:52 mps: ^^^ 2020-01-16 08:22:11 ncopa: I think we should, they don't remove any 'capability' but add few functionalities 2020-01-16 08:22:56 only not sure about STACKPROTECTOR options for ppc64le 2020-01-16 08:24:23 also, I think we should look at #11135 and enable this 2020-01-16 08:34:22 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 cherry-pick 5.4.12 and enable serial_ir is what I think is ok 2020-01-16 08:39:30 ncopa: are you preparing new 3.11 release? 2020-01-16 08:39:40 yes, thats what I'd like to do 2020-01-16 08:40:14 good, there is a bug in lbu which I would like to fix before release 2020-01-16 08:42:23 #10451 2020-01-16 08:42:30 oh, no 2020-01-16 08:42:51 https://gitlab.alpinelinux.org/alpine/alpine-conf/issues/10451 , this 2020-01-16 08:43:59 and to look at this one https://gitlab.alpinelinux.org/alpine/alpine-conf/issues/10453 2020-01-16 09:07:01 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 i'd like to have it show up on the 3.11.3 todo-list 2020-01-16 09:08:05 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 which is empty anyway... 2020-01-16 09:08:25 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 so we dont miss issues 2020-01-16 09:10:37 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 #11135 2020-01-16 09:11:31 otherwise i need to rebuild the kernel for edge first, test it and then backport to 3.11 2020-01-16 09:12:04 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 so i figured we can just try to be consistent with the other arches and enable it 2020-01-16 09:13:02 _ikke_: problem is with other (sub) projects like alpine-conf in this case 2020-01-16 09:13:22 which is a different project than alpine/aports 2020-01-16 09:13:50 i guess we can create a proxy issue or tracker issue in alpine/aports 2020-01-16 09:21:02 todo-list and approximate time for sub release would be 'good thing' 2020-01-16 09:22:31 we have already 'CONFIG_USB_SERIAL_IR=m' for some arches 2020-01-16 09:27:34 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 Thanks 2020-01-16 09:50:38 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 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 ocin: no easy solution 2020-01-16 10:01:54 uhm, the correct modloop should still be found 2020-01-16 10:02:00 even if the other one causes an error 2020-01-16 10:03:11 it def says modloop verification failed and only when there is a alpine installed on disk 2020-01-16 10:04:53 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 maybe all that stuff is broken who knows 2020-01-16 10:05:50 in /etc/init.d/modloop, find_modloop, its a loop over all found modloops 2020-01-16 10:06:07 and it returns when it finds one with matching kernel version 2020-01-16 10:06:29 oh, i see 2020-01-16 10:06:35 the kernel versions differ huegly 2020-01-16 10:06:40 problem is not the matching kernel version, but the verification 2020-01-16 10:06:57 definitely needs some patches.. 2020-01-16 10:08:40 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 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 AinNero: do you have a link to the gitweb of the modloop script? 2020-01-16 10:12:38 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 tested it on rpi zero and it works 2020-01-16 10:13:31 ocin: https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/openrc/modloop.initd 2020-01-16 10:14:10 also noticed that you fixed linux-lts issue which I thought to work on :) 2020-01-16 10:15:13 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 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 I also considered backporting 6b49c2098d96f6ec7872e48c465cb5f9828da4b1 to the -stable branch maybe also for the 3.11.3 release? 2020-01-16 10:20:04 mps: initramfs has the same check and needs fix 2020-01-16 10:23:17 kaey: setup-disk ? 2020-01-16 10:24:10 mps: https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in#n46 2020-01-16 10:24:16 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 why should the modloop script look after the apkovl settings? 2020-01-16 10:25:14 but yes, thats correct 2020-01-16 10:25:42 alpine_dev isn't honoured at all, documentation referencing it should be updated... 2020-01-16 10:28:37 kaey: aha, I see 2020-01-16 10:28:40 true 2020-01-16 10:29:03 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 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 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 *stream of bytes 2020-01-16 10:30:09 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 ocin: which docs? 2020-01-16 10:30:27 "docs" idk, the wiki 2020-01-16 10:30:29 its not in the manpage for mkinitfs-bootparams 2020-01-16 10:30:46 but thats very outdated it also says cramfs instead of squashfs still lol 2020-01-16 10:31:00 link 2020-01-16 10:31:46 clandmeter: above ^ might be 1 fancy thinggy for netboot :D 2020-01-16 10:33:10 it sounds fun but I don't think I'm going into that direction 2020-01-16 10:33:27 aka. how to generate a canonical rootfs 2020-01-16 10:33:32 tmhoang: IMHO if you have your sysroot as cpio, you can skip the regular initramfs alltogether 2020-01-16 10:34:02 yeah agreed from yesterday 2020-01-16 10:34:02 and have the kernel start the sysroot directly instead 2020-01-16 10:46:45 kaey: ncopa: does this make sense http://tpaste.us/1Og9 2020-01-16 10:47:57 it does 2020-01-16 11:03:46 https://wiki.alpinelinux.org/wiki/Create_a_Bootable_USB @AinNero the troubleshooting section for example 2020-01-16 12:23:44 @PureTryOut re: pmbootstrap review. I'll review in a few hours, am in course 2020-01-16 12:33:17 nmeum: backporting 6b49c2098d96f6ec7872e48c465cb5f9828da4b1 sounds good 2020-01-16 12:34:33 should probably just build as is, let me do some quick tests… 2020-01-16 12:35:58 mps: i pushed lbu fix to edge, thanks 2020-01-16 12:36:14 i haven't tested it though (i'm trusting that you did) 2020-01-16 12:37:11 !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 AinNero: should I open a bug about the modloop issue? 2020-01-16 12:38:54 ocin: sounds like a good idea, i dont have capacity to follow all issues reported on IRC 2020-01-16 12:39:04 provide all details and how to reproduce 2020-01-16 12:43:05 ncopa: I tested it on rpi zero 3.11.2, it worked in my case 2020-01-16 12:43:42 mps: should we backport db41b322f2c3ac9e1007ce1f77d8784b9b80b455 to 3.11-stable? 2020-01-16 12:44:14 yes, my daughter needs that! :) 2020-01-16 12:46:26 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 and, please don't forget to look at initramfs openssl fix http://tpaste.us/1Og9 2020-01-16 12:48:18 oh it was already cherry-picked, with 3b1c5ee7c1c 2020-01-16 12:49:12 3b1c5ee7c1c63486a3e87aad63fab21e5e8f1998 2020-01-16 12:49:24 which also seems to include the FIB stuff 2020-01-16 12:49:31 or at least some of the FIB stuff 2020-01-16 12:49:46 ah, didn't seen it in #alpine-commits 2020-01-16 12:52:14 ah, you mean linux. yes most is backported already 2020-01-16 12:52:50 5.4.12 have another FIB modules enabled 2020-01-16 12:54:59 i think i have it under control now :) 2020-01-16 12:55:02 finally 2020-01-16 12:55:23 ok 2020-01-16 13:00:14 PureTryOut[m]: d33b26afd532c021810d466a6c1a229d6e187ca3 broke a lot of builds in armhf. can you try help clean that up? 2020-01-16 13:00:37 alternatively we could re-enable it on armhf and let all those packages be broken 2020-01-16 13:00:57 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 ? 2020-01-16 13:01:53 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 abuild is stupid and simple 2020-01-16 13:02:43 <_ikke_> which is good :) 2020-01-16 13:02:55 i tend to agree :) 2020-01-16 13:06:48 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 i need to do that mkinitfs openssl fix first 2020-01-16 14:55:22 just want make sure it does not break everything 2020-01-16 14:57:11 ACTION never finished the automatic testing setup for early boot stuff 2020-01-16 15:09:56 ncopa: yes, this is important 2020-01-16 15:11:15 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 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 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 does not happen in my dev env 2020-01-16 15:52:53 ok,i know why 2020-01-16 15:53:01 bmake parses MAKEFLAGS 2020-01-16 15:53:28 and the builders has MAKEFLAGS="-j$JOBS -l$JOBS" 2020-01-16 15:53:33 s/has/had/ 2020-01-16 15:53:33 ncopa meant to say: and the builders had MAKEFLAGS="-j$JOBS -l$JOBS" 2020-01-16 15:53:48 i guess bmake did not regocnize the -l$JOBS part 2020-01-16 15:53:50 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 ok 2020-01-16 15:54:52 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 mps: pre-release of armhf here: https://dev.alpinelinux.org/~ncopa/armhf/ 2020-01-16 16:33:05 i need to go out for a couple of hours, but will try tag the release later tonight 2020-01-16 16:33:05 https://dev.alpinelinux.org/~ncopa/armhf/alpine-rpi-20200116-armhf.tar.gz 2020-01-16 16:33:32 would be nice if i could get some help to have the edge builders pass 2020-01-16 16:33:48 lets search for free mmc card 2020-01-16 16:34:25 anyone else wants to test other arch? 2020-01-16 16:34:47 i have 5 mins to upload other test arch 2020-01-16 16:38:58 maybe I could try armv7 when finish with rpi armhf 2020-01-16 16:47:44 https://dev.alpinelinux.org/~ncopa/armv7/out/ 2020-01-16 16:48:24 would be nice if someone can help write/prepare release notes (excl git shortlog) 2020-01-16 16:48:35 would save me a few mins later 2020-01-16 16:48:42 gotta run. laters 2020-01-16 16:50:19 ok, will try also test this 2020-01-16 16:50:54 someone with better git experience should raise hand for rel notes 2020-01-16 16:52:46 hmm, you didn't added mkinitfs fix? 2020-01-16 16:58:17 I can do some rpi test now 2020-01-16 16:58:20 if needed 2020-01-16 16:59:19 artok: only rpi armhf is put for test 2020-01-16 16:59:41 oh 2020-01-16 17:00:13 if you have armhf board url is above 2020-01-16 17:00:44 or generic armv7, url is also above 2020-01-16 17:02:38 "just" rpi3b+ and rpi4 next to me 2020-01-16 17:07:19 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 yeah they work, if there is kernel configured for them 2020-01-16 17:11:06 aha, so not straightly from tarball release 2020-01-16 17:12:29 rpi3 and rpi2 have same kernel 2020-01-16 17:12:51 so armhf should be ok 2020-01-16 17:17:10 and again I say: 2020-01-16 17:17:28 if kernel and initramfs are in sd card boot/ folder, it doesn't boot 2020-01-16 17:17:38 they need to be in the root of the sd card 2020-01-16 17:17:53 armv7 package tested on rpi3b+ 2020-01-16 17:18:24 on sd card, mv boot/* . 2020-01-16 17:18:29 yes, I remember 2020-01-16 17:19:01 but in my case on rpi zero it boot fine though kernel and initramfs are under /boot 2020-01-16 17:19:58 and some people confirmed that it boots fine on their rpi3 or rpi4 boards 2020-01-16 17:22:13 and my both boards blink "kernel not found" 2020-01-16 17:22:27 7 green led flash 2020-01-16 17:25:59 I remember your issue, but have not idea why that happens 2020-01-16 17:26:40 same thing with both of the boards, armv7 and armhf 2020-01-16 17:28:28 generic armv7 wouldn't work on rpis, afaik 2020-01-16 17:28:45 generic, no 2020-01-16 17:28:46 they don't have kernels for rpi 2020-01-16 17:29:36 but armv7 has rpi packages 2020-01-16 17:29:47 yes 2020-01-16 17:32:07 ah, see n_copa created also rpi armv7 besides generic 2020-01-16 17:32:24 I see* 2020-01-16 17:32:36 =) 2020-01-16 17:33:00 could anyone disable coreapps on armhf 2020-01-16 17:36:18 could you run 'vcgencmd version' on your rpi zero 2020-01-16 17:37:09 what does this command 2020-01-16 17:38:28 gives firmware of the videocore 2020-01-16 17:39:23 ..and the command is under /opt/vc/bin/ , raspberrypi package 2020-01-16 17:53:00 artok: nothing under /opt dir on armhf 2020-01-16 17:53:21 apk add raspberrypi, as said ;) 2020-01-16 17:54:55 aha 2020-01-16 18:01:51 artok: /opt/vc/bin/vcgencmd 2020-01-16 18:02:34 run without any report, just get prompt again 2020-01-16 18:05:01 have parameter 'version' 2020-01-16 18:05:41 uh, why didn't tell me, have to reboot :) 2020-01-16 18:06:22 version 6820edeee4ef3891b95fc01cf02a7abd7ca52f17 (clean) (release) (start) 2020-01-16 18:10:10 well that is the same as on my rpi3 2020-01-16 18:11:37 so we can rule out videocore firmware 2020-01-16 18:11:45 "not being able to boot" 2020-01-16 18:12:59 ..or does 'vcgencmd vcos version' give same version hash? 2020-01-16 18:13:53 wait till reboot 2020-01-16 18:14:35 wifi is bad, dhcp timeout 2020-01-16 18:24:52 /opt/vc/bin/vcgencmd vcos version => version 6820edeee4ef3891b95fc01cf02a7abd7ca52f17 (clean) 2020-01-16 18:26:23 so we're running same firmware 1:1, but I don't get booting done.. 2020-01-16 18:26:34 unless... 2020-01-16 18:26:48 lemme fire up my poor old hp 2020-01-16 18:33:23 well no, was not about mac extracting the tar 2020-01-16 18:34:55 what filesystem id is your SD card first partition? 2020-01-16 18:35:13 VFAT? 2020-01-16 18:35:44 id c ? 2020-01-16 18:36:41 512M c Win95 FAT32 (LBA) 2020-01-16 18:37:21 so there is no difference at all, but my boards can't find the kernel =D 2020-01-16 18:38:17 you don't have big enough hammer? :) 2020-01-16 18:46:52 mc hammer 2020-01-16 19:56:21 ok, tested both release tarballs, armhf for RPi and generic armv7 on allwinner A20 board 2020-01-16 19:56:57 both works fine in diskless mode (lbu for saving changes) 2020-01-16 19:57:57 but both have issue when using 'lbu commit -e -d', i.e. this works fine for saving changes 2020-01-16 19:59:04 but on next boot both have problem to recognize openssl enc cipher and don't boot properly 2020-01-16 20:00:19 unpacking initramfs, change 'openssl list -1 -cipher-commands ...' and repack back initramfs solves this problem 2020-01-16 20:00:26 ncopa: ^ 2020-01-16 20:01:34 without this hack got 'initramfs emergency recovery shell launched. Type 'exit' to continue boot' on both boards 2020-01-16 20:02:09 mkinitfs changes should be added 2020-01-16 20:05:05 i.e. upgrade mkinitfs to 3.4.5 on 3.11-stable 2020-01-16 20:16:39 ah, i forgot that part. thanks! for testing 2020-01-16 20:16:43 will backport it 2020-01-16 20:20:12 ok 2020-01-16 20:57:52 what is the purpose of the setup-apkcache command 2020-01-16 20:57:54 ncopa? 2020-01-16 20:58:31 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 ddevault: ping me tomorrow about it 2020-01-16 21:18:15 can do 2020-01-16 21:18:15 i need tag 3.11.3 now 2020-01-16 21:24:35 ddevault: im not sure (i didnt look at the code) but it normally is used on tmpfs installs. 2020-01-16 21:24:40 / high 2020-01-16 21:24:42 disregard 2020-01-16 21:24:51 clandmeter: thanks 2020-01-16 21:25:02 another question: what's the difference between apk add -u and apk add -l 2020-01-16 21:26:44 so it probably has some logic to find the boot media like usb 2020-01-16 21:30:06 i have not played much with those switches, some of them are also vague to me. 2020-01-16 21:30:28 i think i never ever used -l 2020-01-16 21:33:18 reading the code and this is some arcane shit 2020-01-16 21:33:26 the solver might deserve its own manual page 2020-01-16 21:34:06 thank you for putting an effort in the docs 2020-01-16 21:34:13 np 2020-01-16 21:34:18 very needed and very valuable 2020-01-16 21:34:35 it sure is 2020-01-16 21:36:30 i am so stupid 2020-01-16 21:36:40 oh no 2020-01-16 21:37:01 we need a new release engineer 2020-01-16 21:37:20 im gonna fire myself 2020-01-16 21:37:24 current best effort summary of these flags: https://paste.sr.ht/~sircmpwn/59940138c58ece2e00eff18e574fb37006a1ce04 2020-01-16 21:37:31 ncopa: what happened? 2020-01-16 21:37:38 i did a bad tag *again* 2020-01-16 21:37:50 I use a script to prevent that, you can use it if you wish 2020-01-16 21:37:54 ping me when you have put out the fires 2020-01-16 21:38:16 im so tired of this 2020-01-16 21:38:25 i dont even know where to start with the fires 2020-01-16 21:38:33 so what i did 2020-01-16 21:38:54 i created a new milestone in gitlab for next release, 3.11.4 2020-01-16 21:39:02 i updated alpine-base to 3.11.3 2020-01-16 21:39:09 then i tagged v3.11.4 2020-01-16 21:39:27 so the generated release will be v3.11.4 2020-01-16 21:39:36 there is no v3.11.3 2020-01-16 21:39:54 is the milestone used as an input into anything? 2020-01-16 21:40:27 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 no, its just to organize the issues. i mentioned it only as an excuse for my mistake 2020-01-16 21:40:52 gitlab milestone is irrelevant 2020-01-16 21:41:04 the problem was that the "3.11.4" was in my head 2020-01-16 21:41:58 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 https://drewdevault.com/2019/10/12/how-to-fuck-up-releases.html 2020-01-16 21:42:18 whats more embarrasing is that i did similar mistake last release 2020-01-16 21:42:28 MY-R: i do have a checklist 2020-01-16 21:42:33 oh well 2020-01-16 21:42:35 :D 2020-01-16 21:42:54 the mistake is to do the work when im tired 2020-01-16 21:42:57 late evening 2020-01-16 21:43:00 late in the week 2020-01-16 21:43:08 shouldnt do release on fridays either 2020-01-16 21:43:35 but "at some point you need shoot your engineers and just ship the product" 2020-01-16 21:43:43 otherwise it never gets out 2020-01-16 21:44:08 note: today is thursday 2020-01-16 21:44:23 but its late and im tired 2020-01-16 21:44:31 :) 2020-01-16 21:44:36 ship when the sun is out 2020-01-16 21:44:37 and i dont want to ship it tomorrow becuase its not good to release on fridays... 2020-01-16 21:44:52 oh well 2020-01-16 21:45:13 wait, are you suggesting abort the release train and deal with it tomorrow? 2020-01-16 21:45:18 _next time_ don't release when it's last 2020-01-16 21:45:24 it'll probably get worse if you stop halfway there now 2020-01-16 21:46:15 hum 2020-01-16 21:46:21 i have two options 2020-01-16 21:46:27 when it's late* 2020-01-16 21:46:42 1) announce 3.11.4 and pretend nothing happened 2020-01-16 21:47:06 wait, so same mistake like with .1 version? :D 2020-01-16 21:47:13 people may notice that /etc/os-release and /etc/alpine-release says 3.11.3 2020-01-16 21:47:25 MY-R: almost same mistake 2020-01-16 21:47:32 I mentioned today about it so you can blame me :D 2020-01-16 21:47:44 i tagged before I did the commit 2020-01-16 21:48:08 second option is to tag v3.11.3 too 2020-01-16 21:48:26 "commit" - check! 2020-01-16 21:48:29 "tag" - check! 2020-01-16 21:48:31 :P 2020-01-16 21:48:34 and then delete the 3.11.4 files 2020-01-16 21:48:35 suggested resolution: https://paste.sr.ht/~sircmpwn/b83db49c38983cf2957519b01dbb2b9475c2aada 2020-01-16 21:49:06 yeah that is the cleanest thing to do 2020-01-16 21:49:33 i could also delete v3.11.4 and jump to v3.11.5 next time 2020-01-16 21:49:44 up to you 2020-01-16 21:49:52 jumping to 3.11.5 now is least likely to cause you annoyances in the future 2020-01-16 21:50:03 but 3.11.3 now and skip .4 later is probably possible 2020-01-16 21:53:19 hmm, tomorrow is also nice day for release 2020-01-16 21:55:14 i tagged 3.11.3 2020-01-16 21:55:21 i will skip 3.11.4 next time 2020-01-16 21:56:11 i need a githook for checking this 2020-01-16 21:56:14 before push 2020-01-16 21:57:33 https://git.sr.ht/~sircmpwn/dotfiles/tree/master/bin/semver 2020-01-16 22:04:46 im going to bed. will announce 3.11.3 tomorrow 2020-01-16 22:06:22 o/ 2020-01-16 22:06:27 very good idea, good night 2020-01-16 22:07:20 and, sleep well and don't think about alpine, please :) everything is ok 2020-01-16 22:16:35 :D 2020-01-16 22:39:26 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 This is what's being executed : https://git.riboflav.in/snippets/4 2020-01-16 22:40:40 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 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 https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/9 2020-01-16 22:43:54 all of the man pages are now written 2020-01-17 05:48:36 please accept this MR. i will enble "check" in next release. 2020-01-17 05:48:36 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 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 https://github.com/alpinelinux/aports/pull/9716 2020-01-17 05:53:16 <_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 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 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 <_ikke_ "so the comment from Cogitri mean"> please do. 2020-01-17 05:57:50 giiiiiiiitttt. what an innovation. 2020-01-17 05:58:06 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 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 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 waiting here to to see the MR as packages. Love this things. 2020-01-17 06:07:36 https://pkgs.alpinelinux.org/packages 2020-01-17 06:07:57 <_ikke_> that will take about 30 minutes 2020-01-17 06:35:00 morning 2020-01-17 06:35:06 im continuing with the 3.11.3 release now 2020-01-17 06:37:18 Morning :) 2020-01-17 06:53:47 does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.11.3-released.html 2020-01-17 07:03:40 Looks good to me, but I haven't followed 3.11 too closely 2020-01-17 07:13:39 drats 2020-01-17 07:13:50 armhf is still defunct 2020-01-17 07:13:53 and i did snapshot 2020-01-17 07:14:17 there are no snapshot for armhf in other words 2020-01-17 07:16:28 What's defunct about it? :o 2020-01-17 07:16:58 this d33b26afd532c021810d466a6c1a229d6e187ca3 2020-01-17 07:17:08 but there are a ton of packages that depends on it 2020-01-17 07:17:13 and those was not disabled 2020-01-17 07:17:37 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 im seriously considering nuking armhf of the orbit... 2020-01-17 07:19:14 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 Well, I certainly wouldn't veto dropping armhf 2020-01-17 07:20:13 Maybe a todo for 3.12 2020-01-17 07:43:14 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 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 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 i cannot do that without armhf 2020-01-17 08:02:06 as it would result in edge docker image for armhf would disappear 2020-01-17 08:02:29 unless i start track different versions of different arches manually... 2020-01-17 08:02:42 I can look into it, most of the difficult exams are done now fortunately 2020-01-17 08:02:56 Cogitri: i hope you did good in those 2020-01-17 08:03:05 that it went well 2020-01-17 08:05:12 anyone for https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2976 ? 2020-01-17 08:07:55 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 lat point on the checklist: celebrate.... 2020-01-17 08:08:58 <_ikke_> \o/\/o\/o4 2020-01-17 08:44:38 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 ncopa: I don't have the results yet, but I think they went OK 2020-01-17 08:48:25 Thanks :) 2020-01-17 08:48:50 <_ikke_> fredrigu: https://github.com/alpinelinux/aports-turbo 2020-01-17 09:23:38 _ikke_: thanks 2020-01-17 09:37:30 fredrigu: if you like using docker: https://gitlab.alpinelinux.org/alpine/infra/docker/aports-turbo 2020-01-17 10:13:33 clandmeter: thanks! 2020-01-17 11:05:17 so, what is current 3.11 subrelease? 3.11.3 or 3.11.4 2020-01-17 11:08:00 3.11.3 officially, but I see 3.11.4 tarballs also made 2020-01-17 11:09:13 on 3.11.3 lbu commit -e (encrypt) is still not fixed 2020-01-17 11:09:46 hmm, still isn't fixed* 2020-01-17 11:10:49 and I don't know is this important bug 2020-01-17 12:21:35 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 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 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 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 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 hmm, that's interesting 2020-01-17 12:31:34 seems as I need to investiga this some more 2020-01-17 12:38:01 Check fabled email about new apktools 2020-01-17 12:38:21 It mentions better support for multiple versions 2020-01-17 12:39:01 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 Could be only the build part he refers to 2020-01-17 12:58:17 clandmeter: _ikke_ thanks! That's more what I wanted 2020-01-17 14:06:02 gz on the release :) 2020-01-17 14:06:07 fraught as it may have been 2020-01-17 14:09:58 'gz' 2020-01-17 14:10:08 contrats 2020-01-17 14:10:14 congrats* 2020-01-17 14:10:18 aha, thanks 2020-01-17 14:10:28 thanks for explanation 2020-01-17 14:11:03 but encrypted lbu is not fixed, 'lbu commit -e' 2020-01-17 14:58:15 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 ddevault: looking at it now 2020-01-17 16:02:20 my desktop is freezing 2020-01-17 16:02:23 thanks :) 2020-01-17 16:02:25 oh :( 2020-01-17 16:02:59 make -j 2020-01-17 16:03:02 omg 49 pages of patches with some from 13 years ago Oo 2020-01-17 16:03:29 i think its the gpu that freezes 2020-01-17 16:04:18 [88278.571863] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0 2020-01-17 16:04:18 [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 [88280.705132] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0g rcs0 for hang on rcs0 2020-01-17 16:06:53 ncopa: uname -a 2020-01-17 16:08:56 maybe related to this https://lists.freedesktop.org/archives/dri-devel/2020-January/252142.html 2020-01-17 16:16:08 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 i think north1 had freezes on intel gpu as well some time ago 2020-01-17 16:16:45 not sure it was fixed upstream 2020-01-17 16:16:47 Still have 2020-01-17 16:16:56 ah, so they didnt backport it yet 2020-01-17 16:17:06 ok 2020-01-17 16:17:23 maybe i should try backport it myself 2020-01-17 16:17:54 I sometimes have that too on my laptop :c 2020-01-17 16:18:07 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 so i belive it should be possible to backport it 2020-01-17 16:18:22 and see what happens :) 2020-01-17 16:18:42 will try allocate time for it next week 2020-01-17 16:19:30 (im on my macbook right now...) 2020-01-17 16:19:54 ddevault: re that patch 1) awesome! would be great with crypt support out of the box 2020-01-17 16:20:12 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 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 so always encrypt? 2020-01-17 16:22:03 I feel like users need informed consent for encryption 2020-01-17 16:22:04 well, or we could have a "sys" "syscrypt" opt or similar 2020-01-17 16:22:28 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 hm, maybe 2020-01-17 16:22:46 can you say as much in the form of a reply to the thread on the ML? 2020-01-17 16:22:58 will do when i get my machine working 2020-01-17 16:23:05 thanks! 2020-01-17 16:23:35 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 how so? 2020-01-17 16:24:05 because you can manually create the partitions the way you want, and then run: setup-disk /mounted-root 2020-01-17 16:24:26 so it needs to figure out itself that it is encrypted or not 2020-01-17 16:24:34 actually, that may be the first step 2020-01-17 16:24:34 hm, understood 2020-01-17 16:25:07 so you can mount xfs or some other filesystem, have /home on different partition etc 2020-01-17 16:25:16 lvm or mdadm whatever 2020-01-17 16:25:22 in any crazy combo 2020-01-17 16:25:37 and setup-disk /mountpoint will figure it out 2020-01-17 16:25:53 that the idea at least 2020-01-17 16:26:10 I will address this use-case in the next patch 2020-01-17 16:26:28 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 i guess i shoudl have responded all this in an email, but my desktop is broke :-( 2020-01-17 16:26:55 yeah 2020-01-17 16:26:58 it's alright, I appreciate the feedback regardless 2020-01-17 16:27:18 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 or maybe even C 2020-01-17 16:27:41 eeeeeeh 2020-01-17 16:27:47 lua 2020-01-17 16:27:49 :) 2020-01-17 16:27:56 eeeeeeh 2020-01-17 16:28:05 honestly I like it as a shell script. Nothing beats shell scripts for stringing commands together 2020-01-17 16:28:21 I'm already uncomfortable with the present level of lua involvement in alpine 2020-01-17 16:28:31 lua is nice 2020-01-17 16:28:36 its small, its fast 2020-01-17 16:28:38 I think a better approach would be to maintain two installation paths 2020-01-17 16:28:41 on rails with setup-alpine 2020-01-17 16:28:51 and off rails with a nice wiki page detailing the manual instructions, using no setup-* scripts at all 2020-01-17 16:29:06 arch linux style 2020-01-17 16:29:07 the latter is how builds.sr.ht's alpine images are built, for example 2020-01-17 16:29:14 aye 2020-01-17 16:29:30 but I think setup-alpine is good for the easy path 2020-01-17 16:29:57 what i´d want is something similar to what we have. looks very simple on the front 2020-01-17 16:30:02 very few questions asked 2020-01-17 16:30:12 you can press enter N times and have a working system 2020-01-17 16:30:17 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 but i´d like to be able to go backwards in the "wizard" 2020-01-17 16:30:43 having dissected the alpine installation several times, I'm probably qualified to write those docs 2020-01-17 16:30:53 improving docs is something I'd like focus on in general for alpine 2020-01-17 16:31:04 im so happy that you are helping with that 2020-01-17 16:31:06 but only if the rest of the community is interested in supporting such an installation flow 2020-01-17 16:31:19 setup-alpine is nice, mostly pressing enter to the end works :) 2020-01-17 16:31:22 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 mps: thats the idea 2020-01-17 16:31:43 there is even a -q mode 2020-01-17 16:31:45 quick mode 2020-01-17 16:32:03 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 i also want autocomplete 2020-01-17 16:32:36 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 and i´d like to have support for fully automated or parital automated 2020-01-17 16:33:13 so you could feed it with a json or similar 2020-01-17 16:33:20 and it would set it all up for you 2020-01-17 16:33:22 my opinion is that there are two ways of installing the system 2020-01-17 16:33:28 the perscribed way, and the manual way 2020-01-17 16:33:28 no questions asked 2020-01-17 16:33:39 or you could have it ask only about the password 2020-01-17 16:33:44 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 the rest automatted 2020-01-17 16:34:25 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 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 sometimes I install it 'manual way', setup-* in correct order with some actions needed in between 2020-01-17 16:34:58 yeah, I do that sometimes too 2020-01-17 16:35:13 but it's error prone, various things can (and do) fail when you dissect the process like that 2020-01-17 16:35:40 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 that's true 2020-01-17 16:36:25 have a nice weekend 2020-01-17 16:36:34 o/ 2020-01-17 16:36:36 \o 2020-01-17 16:39:11 o/ 2020-01-17 16:40:32 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 north1: fcolista: what you think about backporting just upgraded acme.sh to 3.11 2020-01-17 17:01:11 I started to test it but you was faster 2020-01-17 17:01:13 I can do it Sunday if nobody does 2020-01-17 17:01:29 nice 2020-01-17 17:01:51 Going to dinner and Saturday I'll be visiting the Black forest 2020-01-17 17:02:10 'Black forest'? 2020-01-17 17:02:27 Schwartzwald? 2020-01-17 17:06:02 Yes 2020-01-17 17:07:11 nice, enjoy this beautiful mountain :) 2020-01-17 17:23:19 Thanks! 2020-01-17 17:29:15 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 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 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 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 Yup, apk just tells you to install one of them because it can't decide, doesn't it? 2020-01-17 17:31:52 (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 Ah, okay 2020-01-17 17:32:58 <_ikke_> Something worth to test I guess 2020-01-17 17:33:07 Yup, sounds good 2020-01-17 17:33:35 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 Hm, okay 2020-01-17 17:34:06 <_ikke_> Do they conflict? 2020-01-17 17:34:12 No 2020-01-17 17:34:13 <_ikke_> Ok 2020-01-17 17:34:50 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 But I guess that might be kinda unexpected as well 2020-01-17 17:35:08 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 I hope we don't want apt on alpine 2020-01-17 18:35:47 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 _ikke_: if you talking about my msg, then no. ML list posts is ok imo 2020-01-17 18:38:07 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 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 Does someone have plans to do a mass purge on issues? 2020-01-17 20:02:26 I feel like it might be time to close package requests that are some 8 years old 2020-01-17 20:12:51 kernel 5.4.13 is out. no mention about i915 CVE fix 2020-01-17 20:40:25 Cogitri: i would start by cleaning issues that make no sense anymore (and are overdue) 2020-01-17 20:40:39 and i guess the very old ones probably do 2020-01-17 20:40:45 do not make sense :) 2020-01-17 20:55:28 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 just in the half if the kernel build ;) 2020-01-17 21:30:17 s/if/in/ 2020-01-17 21:30:17 mps meant to say: just in the half in the kernel build ;) 2020-01-17 21:30:48 should not matter if _ikke_ hurries :) 2020-01-17 21:30:59 the runner will reconnect? 2020-01-17 21:31:08 maybe it will be offline too long though 2020-01-17 21:31:15 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 last time it timed out 2020-01-17 21:31:40 after x ttries 2020-01-17 21:31:45 maybe we can increase it a bit 2020-01-17 21:32:32 'An error occurred while fetching the pipeline.' 2020-01-17 21:32:51 <_ikke_> yes, that's logical 2020-01-17 21:32:53 oh it was failing lsat time due to artifacts 2020-01-17 21:33:45 maybe in build it will recoorect 2020-01-17 21:33:49 reconnect even 2020-01-17 21:33:57 no problem 2020-01-17 21:34:41 I'm not complaining 2020-01-17 21:34:57 <_ikke_> It's starting already 2020-01-17 21:34:59 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 Starting Gitlab.. 2020-01-17 21:35:52 <_ikke_> It's up 2020-01-17 21:35:52 \o/ 2020-01-17 21:36:16 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 yes, just looking at it 2020-01-17 21:38:51 <_ikke_> Do you like the new logs? 2020-01-17 21:39:40 logs? 2020-01-17 21:39:51 <_ikke_> log output from CI 2020-01-17 21:39:55 ah line numbers 2020-01-17 21:40:21 there is more 2020-01-17 21:40:27 its more clear for me 2020-01-17 21:40:31 bigger font 2020-01-17 21:40:47 not sure 2020-01-17 21:40:54 ikke is used to looking at it :) 2020-01-17 21:40:59 yes, fonts are more readable 2020-01-17 21:42:18 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 yes, noticed time in CI logs 2020-01-17 21:51:25 only some fonts are missing on my side, don't know which one 2020-01-17 21:52:16 probably ttf-font-awesome 2020-01-17 22:32:05 mps, try with noto fonts: font-noto font-noto-emoji 2020-01-17 22:32:43 I dislike it in terminals 2020-01-17 22:33:55 emoji? those will work only in few I think 2020-01-17 22:34:59 they are ugly in st term 2020-01-17 22:35:24 ye can imagine :P 2020-01-17 22:36:17 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 I use irssi for irc 2020-01-17 22:38:16 :< 2020-01-17 22:41:56 north1: you're Leo, right? 2020-01-17 22:42:02 north1: if so, those changes are fine 2020-01-17 22:42:30 _ikke_: this new pop up about tabs is annoying 2020-01-17 22:44:58 kaniini: can I PM you 2020-01-17 22:45:05 mps: yes 2020-01-17 22:49:54 oh 2020-01-17 22:50:43 kaniini: Leo is north1 here 2020-01-17 22:50:49 yeah 2020-01-17 22:50:51 i thought so 2020-01-17 22:51:07 but he went to visit some mountains 2020-01-17 22:51:12 kaniini (IRC): ok, good 2020-01-17 22:51:29 hah, he is here still 2020-01-17 22:51:35 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 i really should go sleep so i wake up in time to take the planned route 2020-01-17 22:52:09 good night and sleep well 2020-01-17 22:53:31 btw, there is 5.4.13 on CI 2020-01-17 22:53:46 I saw but i'll stick to 4.x until 5.5.x is out 2020-01-17 22:54:31 yes, 5.5 is better. I run it on exynos chromebook 2020-01-17 22:54:46 5.5-rc6 2020-01-17 22:55:59 Nice, hopefully the Intel-drm fixes are merged in 2020-01-17 22:56:32 some are but not sure about your issue 2020-01-17 22:57:22 but, good night again :) 2020-01-17 23:50:46 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 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 I don't understand what is going on 2020-01-18 01:59:10 https://gitlab.alpinelinux.org/russkel/aports/-/jobs/34962#L931 2020-01-18 02:00:34 that particular function uses some C++ template stuff 2020-01-18 02:05:13 https://github.com/opencv/opencv/blob/master/modules/core/src/system.cpp#L1939 ? 2020-01-18 02:08:10 I'm not so proficient in C++ to debug this 2020-01-18 02:08:24 likewise likewise 2020-01-18 02:10:26 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 russkel: Seems like opencv doesn't like D_FORTIFY_SOURCE 2020-01-18 08:00:15 Cogitri, yeah and I was wondering specifically why that is 2020-01-18 08:02:27 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 I checked and none of the includes in the chain seem to be from within the cv:: namespace 2020-01-18 08:03:13 although I could be missing something 2020-01-18 08:03:28 Yes, we force that with fortify source 2020-01-18 08:03:37 I'll give it a look in a bit 2020-01-18 08:04:35 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 Ah, on armhf? 2020-01-18 11:26:58 Gotta disable it too, I suppose 2020-01-18 11:32:26 <_ikke_> Cogitri: yes, indeed, armhf 2020-01-18 11:33:09 Yeah, armhf isn't having a goof couple of days 2020-01-18 14:37:44 north1: The x86_64 CI builder seems to be stuck in your telegram-desktop MR 2020-01-18 14:39:34 i see 2020-01-18 14:39:43 failed due to lack of memory, lets hope the builders have enough mem 2020-01-18 14:39:46 abuild!17 2020-01-18 14:39:54 algitbot (IRC): no 2020-01-18 14:40:55 390a2fe6e6f1eb07f1e018d00abc47c5f6eba6f4 <- beautiful 2020-01-18 14:47:52 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 Please help! :) 2020-01-18 14:48:18 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 @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 ok 2020-01-18 14:52:41 <_ikke_> nope, still the same :x 2020-01-18 14:53:34 _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 xrs: Maybe it's confused because you opened the MR on your own fork 2020-01-18 14:53:45 just a guess 2020-01-18 14:54:05 Oh. 2020-01-18 15:02:48 Seems like armhf is unblocked now. 2020-01-18 15:04:45 miecrell: I'm not sure how this happened. Any recommendation before I just restart the pipeline? 2020-01-18 15:04:51 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 !16 2020-01-18 15:05:58 ok, I'll try. 2020-01-18 15:06:35 _ikke_: Do I have to do a new one or can I change the old one? 2020-01-18 15:06:54 north1: 16 applied long time ago. anything new about it 2020-01-18 15:07:21 mps (IRC): alpine/abuild not alpine/aports 2020-01-18 15:07:42 oh, ok. sorry 2020-01-18 15:07:45 i put the full URL above since i don't know how to make algitbot distinguish 2020-01-18 15:07:59 alpine/abuild!17 ? 2020-01-18 15:08:04 yeah no 2020-01-18 15:08:12 right 2020-01-18 15:08:38 I was surprised because these two are mine MRs 2020-01-18 15:25:30 _ikke_: fixed, thanks for the hint. 2020-01-18 16:21:11 @PureTryOut what did you want to change on atools ? 2020-01-18 16:21:51 https://gitlab.alpinelinux.org/Leo/atools/merge_requests/24 2020-01-18 16:22:47 merged, i'm doing some other stuff as well and will make a release 2020-01-18 16:23:35 Awesome thanks! 2020-01-18 16:23:50 Should we ignore other variables like CFLAGS ? 2020-01-18 16:24:03 Probably makes sense yes 2020-01-18 16:59:37 !3156 2020-01-18 17:00:00 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 @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 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 they are referenced like depends="$cpandepends" 2020-01-18 17:02:14 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 If you want i can get apkbuild-fixer to transfer cpandepends into depends and rewrite the variable 2020-01-18 17:02:59 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 ACTION is in favour of removing 2020-01-18 17:09:14 ACTION these cpan* variables and fixing abuild-cpan to not generating them anymore 2020-01-18 17:10:23 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 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 :) 2020-01-18 17:22:10 I want to fix it a bit and rename to u-boot-tools 2020-01-18 17:22:50 or rename u-boot to uboot? 2020-01-18 17:23:14 There is also pydepends 2020-01-18 17:23:20 maybe for people that use apkbuild-pypi 2020-01-18 17:23:43 didn't even knew that existed 2020-01-18 17:24:17 Same here 2020-01-18 17:25:41 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 i think it's properly called uboot and not u-boot 2020-01-18 18:00:08 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 gu0tvuNHFV8o: from u-boot README 'This directory contains the source code for U-Boot,' 2020-01-18 18:04:16 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 Arch linux uses uboot 2020-01-18 18:05:58 name 'uboot' I mean 2020-01-18 18:07:18 debian use 'u-boot-tools' and 'u-boot-menu' 2020-01-18 18:28:24 apkbuild-pypi is so old it doesn't even have pycheckdepends= 2020-01-18 18:28:53 do people use it ? i never saw anything written about it. I used apkbuild-cpan once 2020-01-18 18:35:40 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 Yes, I used it all the times I had to make a Perl package (once) 2020-01-18 18:36:55 I mean apkbuild-pypi which doesn't have its own subpackage and doesn't bring the required deps 2020-01-18 18:37:22 ah, I don't make py pkgs 2020-01-18 18:40:50 I made quite a few but never with apkbuild-pypi 2020-01-18 19:02:31 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 _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 yes 2020-01-18 19:45:18 <_ikke_> I've only had it once 2020-01-18 19:45:21 but it repeats when I'm not logged in 2020-01-18 19:46:48 whenever click on some MR 2020-01-18 19:48:30 <_ikke_> I see 2020-01-18 19:49:40 ok 2020-01-18 19:50:28 <_ikke_> Not something we can do about 2020-01-18 19:51:15 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 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 Yup, saw the mail 2020-01-18 20:26:52 Ah, thanks :) 2020-01-18 20:30:18 mps, yes its annoying 2020-01-18 20:30:28 i had the same thing on gitlab.com 2020-01-18 20:30:56 i also dont see the added value 2020-01-18 20:35:21 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 so there is essentially a version mismatch now (not critical yet because it was just a re-build) 2020-01-18 20:36:15 (I used apk upgrade --available) 2020-01-18 20:48:44 maybe we need provides="mesa-dri-virtio==$pkgver"? 2020-01-18 20:48:54 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 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 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 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 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 _ikke_: is the syntax really provides="pkgname-$pkgver-r$pkgrel"), not provides="$pkgname==$pkgver-r$pkgrel")? 2020-01-18 20:57:27 uh 2020-01-18 20:57:29 just one = 2020-01-18 20:57:34 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 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 _ikke_: in the wiki? 2020-01-18 21:05:52 <_ikke_> yes 2020-01-18 21:06:19 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 (2/7) Purging mesa-dri-virtio (19.3.2-r0) 2020-01-18 21:11:38 (5/7) Installing mesa-dri-gallium (19.3.2-r2) 2020-01-18 21:11:38 🎉 2020-01-18 21:11:42 thanks _ikke_ 2020-01-18 21:15:16 Nice 2020-01-18 21:19:20 <_ikke_> :-) 2020-01-18 21:26:24 _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3167 2020-01-18 21:29:05 Thanks again :) 2020-01-18 22:04:18 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 @Clandmeter https://lists.alpinelinux.org/~alpine/aports/patches/3228 ok with transferring maintainership of riot-web ? 2020-01-19 04:46:14 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 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 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 Is there a reason for not having common folders like "Documents", "Videos" and "Pictures" in `/etc/skel`? 2020-01-19 10:26:10 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 PureTryOut[m]: why? to follow windows naming scheme? 2020-01-19 10:26:49 minecrell: I don't believe so 2020-01-19 10:27:08 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 https://wiki.archlinux.org/index.php/Xdg_user_directories 2020-01-19 10:27:35 other distros adopted it from windows 2020-01-19 10:27:36 Arch Linux doesn't have them in /etc/skel 2020-01-19 10:28:26 do we need to follow these non-senses 2020-01-19 10:28:41 I'm not saying we should, I was just asking why Alpine didn't have those... 2020-01-19 10:28:48 Chill guys lol 2020-01-19 10:28:54 :) 2020-01-19 10:28:55 lol indeed 2020-01-19 10:29:18 Imho they really shouldn't be in skel though 2020-01-19 10:29:40 PureTryOut[m]: please, keep in mind that I never attack anyone personally 2020-01-19 10:29:41 I'm probably just going to try and package `xdg-user-dirs` 2020-01-19 10:29:55 yeah, that's what seems to manage them 2020-01-19 10:30:00 including localization support, weird lol 2020-01-19 10:30:03 Either your DE creates them for you or you run xdg-user-dors-update 2020-01-19 10:30:09 Yes, we'd need that package for that 2020-01-19 10:30:24 minecrell: Why would that be weird? 2020-01-19 10:31:11 Cogitri: Idk, if you change your locale it starts moving all folders around or what? 2020-01-19 10:31:32 alpine is 'small, simple, secure' (still, I hope) 2020-01-19 10:32:37 Cogitri: it seems at least on Debian that the DE packages depend on `xdg-user-dirs` 2020-01-19 10:32:47 minecrell: No 2020-01-19 10:32:56 Yup, they should do that 2020-01-19 10:33:15 Wanted to introduce that package but forgot about it, so thanks for doing it now :) 2020-01-19 10:33:45 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 why don't have 'Images', 'Movies', 'Writings' ..... 2020-01-19 10:34:36 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 (And they also allow putting e.g. your Downloads folder wherever you want, so that's nice) 2020-01-19 10:44:47 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3173/diffs#ac783fd0311ccf6f79c9b57a0b3696158bacfb62 2020-01-19 10:45:14 there is variable in pkgdesc, I think this is not ok? 2020-01-19 10:45:46 i.e. `pkgdesc="Digium Asterisk Hardware Device Interface drivers $_ver"` 2020-01-19 10:49:50 I mean, '$_ver' should go in pkgdesc 2020-01-19 10:50:03 I don't think it should 2020-01-19 10:50:14 Seems pretty redundant when you have pkgver 2020-01-19 10:56:18 I'm not sure, maybe there are reason for this (different driver major version, for example) 2020-01-19 10:57:08 if so, I still think that the $_ver should be replaced by literal string 2020-01-19 12:22:47 are there spell check plugin or option for gitlab 2020-01-19 12:24:21 Your webbrowser should provide that 2020-01-19 12:25:05 iirc, redmine has it 2020-01-19 12:49:55 I don't think any website implements its own spellchecker 2020-01-19 12:50:18 Since webbrowsers highlight spelling errors already 2020-01-19 12:50:50 I'm pretty sure there is a stupid website out there that does it 2020-01-19 12:50:52 hm, not sure but I think I saw redmine plugin 2020-01-19 12:51:05 The web is full of garbage ;) 2020-01-19 12:51:19 heh :) 2020-01-19 12:51:20 Right, lemme fix that 2020-01-19 12:51:35 I don't think implementing a spellchecker for your website makes any sense usually 2020-01-19 12:51:44 agreed :p 2020-01-19 12:52:15 anyway, do you know for firefox spell check plugin which is light 2020-01-19 12:54:09 my Firefox does it without plugin 2020-01-19 12:54:34 Maybe missing some deps 2020-01-19 12:55:17 minecrell: are you run it on alpine 2020-01-19 12:55:32 nope 2020-01-19 12:58:25 You don't need any plugin for spellchecking 2020-01-19 12:58:57 really? how to enable it? 2020-01-19 12:59:21 mps: but just tested on Alpine 2020-01-19 12:59:23 works too 2020-01-19 12:59:31 just right click the input field and make sure check spelling is ticked 2020-01-19 13:01:21 hm, I was blind :) 2020-01-19 13:01:28 thanks 2020-01-19 13:17:32 north1: you are so fast :) thanks 2020-01-19 13:18:58 Welcome 2020-01-19 13:19:31 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 _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 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 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 oh, right, not beautifully worded, I agree 2020-01-19 13:26:47 (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 again, agree with you 2020-01-19 13:30:47 I would like to point all alpine packagers to look sometimes at kernel git log 2020-01-19 13:37:31 hmm, every week new ncurses release, !3180 2020-01-19 13:58:00 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 ./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 but this gives ERROR: http://dl-cdn.alpinelinux.org/alpine/edge/main: UNTRUSTED signature 2020-01-19 13:58:21 hrm 2020-01-19 13:59:02 the keys are copied into the temp root 2020-01-19 14:00:07 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 ah 2020-01-19 14:00:40 where can I find those keys 2020-01-19 14:01:15 ddevault: try with --extra-repository, maybe it could help 2020-01-19 14:01:27 nope 2020-01-19 14:01:34 hm 2020-01-19 14:01:35 <_ikke_> ddevault: alpine-keys 2020-01-19 14:01:58 I fought with this some time, but it started suddenly to work 2020-01-19 14:02:00 thanks _ikke_ 2020-01-19 14:02:10 <_ikke_> https://git.alpinelinux.org/aports/tree/main/alpine-keys 2020-01-19 14:02:14 that's it 2020-01-19 14:03:17 ahm, that explains why it suddenly started to work in case, thanks _ikke_ 2020-01-19 14:03:29 in my case* 2020-01-19 14:04:17 north1: thanks again 2020-01-19 14:10:28 dumb question: is there a way to install foreign packages with a tag 2020-01-19 14:12:00 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 foreign architecture 2020-01-19 14:13:48 <_ikke_> I don't think so 2020-01-19 14:13:52 apk add'ing the foreign package just werked 2020-01-19 14:13:56 <_ikke_> ah ok 2020-01-19 14:13:56 I'm sure there will be consequences later 2020-01-19 14:13:58 ¯\_(ツ)_/¯ 2020-01-19 14:14:15 that is, I curl -O'd it straight from the mirror and passed the file to apk add 2020-01-19 15:07:56 Why do some packages cause `ERROR: *: lib.so: path not found`? For example ghc has this, and another package I'm packaging atm as well 2020-01-19 15:08:43 I suppose because abuild can't automatically trace what package the shared library that package needs is in 2020-01-19 15:08:56 (This can happen if you forget to install a shared lib) 2020-01-19 15:09:43 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 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 Well, what lib is it complaining about? Did it install that lib into /usr/lib as it should? 2020-01-19 15:28:53 It's a lib from itself lol 2020-01-19 15:30:06 https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/37929#L2939 2020-01-19 15:30:13 Same for ghc 2020-01-19 15:50:03 And there's /usr/lib/libboca-1.0.so.2 in that package? 2020-01-19 15:51:52 So far I can only find a regular `libboca-1.0.so` (without the `.2`) 2020-01-19 15:52:00 Actually nvm that's a lie 2020-01-19 15:52:04 Yeah it's in there 2020-01-19 16:11:10 Hm, odd 2020-01-19 16:11:16 Not on PC right now so can't check 2020-01-19 17:49:43 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 I see 2020-01-19 17:51:12 he is too fast :) 2020-01-19 17:51:23 sorry 2020-01-19 17:52:02 np, I'm happy seeing it pushed 2020-01-19 17:52:12 why sorry? 2020-01-19 17:53:09 BTW Cogitri did a lot of work with old issue requests. awesome 2020-01-19 17:53:58 my impression is that gitlab.a.o helps us a lot 2020-01-19 18:22:08 mps: Gonna try working through the rest to close obsolete/already solved ones, thanks for helping :) 2020-01-19 19:23:38 PureTryOut[m]: FYI I just disabled picard on armhf due to qtdeclarative 2020-01-19 19:43:21 Yeah that's fine 2020-01-19 20:14:27 is there a reason we don't just use aarch64 defconfig for linux-lts 2020-01-19 20:38:54 probably cause it's bad, that explains it neatly 2020-01-19 20:39:00 or rather that it doesn't support much 2020-01-19 20:46:57 Ugh, can't I have Gitlab notify me on any comment on any issue on aports? 2020-01-19 20:47:39 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 Mailbombing it is then, I suppose :P 2020-01-19 21:16:05 Would be nice if I could choose a different email for aports 2020-01-19 21:16:17 But I guess I'll just go ahead and make a 2nd account just for these notifications 2020-01-19 21:16:57 or dunno, create some filters on your mail? :D 2020-01-19 21:21:47 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 in protonmail can define filters and select where move or what else to do with not wanted mails 2020-01-19 21:27:41 it even support that: https://protonmail.com/support/knowledge-base/sieve-advanced-custom-filters/ 2020-01-19 21:30:04 Ah right, I used that for when I was actually mailbombed once :^) 2020-01-19 21:30:19 But I'm not sure how to make the regex for that though 2020-01-19 21:31:35 good start is to enable all notifications and after you will be abble to create good patterns :D 2020-01-19 21:31:51 Fair enough :P 2020-01-19 22:32:33 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 Ah, no worries :) 2020-01-19 22:34:33 Thanks 2020-01-19 22:35:26 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 mps: aye, agreed 2020-01-19 22:36:34 last big config change was for armv7 when linux-lts introduced 2020-01-19 23:02:23 Cogitri: sorry, still here? I think 2020-01-19 23:02:23 #7325 2020-01-19 23:02:44 could be closed. do you agree ? 2020-01-19 23:10:13 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 MY-R: thanks for report 2020-01-19 23:12:44 :) 2020-01-19 23:52:43 #3238 2020-01-19 23:53:40 ^ 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 yes 2020-01-20 00:13:03 Closed, thanks 2020-01-20 00:45:05 #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 Cogitri, are you cleaning up issues? 2020-01-20 00:59:14 @MY-R yes 2020-01-20 07:46:05 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 what do i do here? 2020-01-20 07:46:49 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 but it will not 'work', afaik 2020-01-20 07:49:11 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 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 upgrade -a downgrades packages if they're not available in repo 2020-01-20 07:57:40 yes, ime 2020-01-20 07:57:54 <_ikke_> correct 2020-01-20 07:58:00 but 'apk add -u' doesn't 2020-01-20 08:02:06 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 but now it creates mr into my own fork 2020-01-20 08:04:33 not related to this in particular, but aren't we against pkgs beta releases 2020-01-20 08:05:00 yes, but this was neccessary because of nodejs upgrade 2020-01-20 08:05:36 yes, there are always exceptions 2020-01-20 08:05:52 i complained before, and somebody else was 2020-01-20 08:07:40 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 are this serious or kidding with us !3202 2020-01-20 08:58:24 I think it's serious since that user might not know the full reach of that 2020-01-20 09:07:05 kaey: yes, to apk 1.0.8b > 1.0.8, so it gets openssl versions correctly 2020-01-20 09:07:23 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 indeed 2020-01-20 09:08:58 sounds like a bug 2020-01-20 10:30:39 Cogitri, #8599 2020-01-20 10:34:23 Ah, thanks 2020-01-20 10:59:43 #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 if package working fine then can move it to community just like that? 2020-01-20 11:03:10 _ikke_: maintainer is Cogitri 2020-01-20 11:04:00 I looked few days ago to upgrade it, but seeing maintainer I didn't 2020-01-20 11:05:29 I'll assign this issue to him 2020-01-20 11:05:54 no, I will not 2020-01-20 11:06:20 MY-R already answered 2020-01-20 11:06:24 mps: I don't see a upgrade for it 🤔 2020-01-20 11:06:46 :D 2020-01-20 11:06:54 alsa-project.org only lists alsa-tools-1.1.7 2020-01-20 11:07:30 Cogitri: yes, sorry 2020-01-20 11:08:21 I looked at site and thought it follow alsa-utils release numbers, now I see I was wrong 2020-01-20 11:09:51 Only knew that since I fell for that twice already :) 2020-01-20 11:11:02 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 I only tested that thingie to set different pins for your soundcard 2020-01-20 11:12:02 Because HP did something weird for my laptop's speaker layout 2020-01-20 11:12:16 MY-R: looks like this tool is for sound freaks use cases 2020-01-20 11:12:24 mps, yep! 2020-01-20 11:52:16 north1: i pushed new kernel with backport of the intel gpu issue fix 2020-01-20 11:53:06 Nice 2020-01-20 11:53:14 Am in Kulturzentrum 2020-01-20 11:53:20 Will test in a few hours 2020-01-20 11:56:50 3f3e223c0b11885671d570a90fd820619e894945 2020-01-20 12:04:34 Neat 2020-01-20 12:07:29 ncopa: i think dalias was also having issues, not sure its the same problem. 2020-01-20 12:10:54 yes, a lot of people have this problem and on other distros, not anly alpine 2020-01-20 12:11:57 problem is introduced with kernel 5.4 and 'backported' to 5.3.12 (iirc) 2020-01-20 12:12:31 irony is that it is LTS 2020-01-20 12:14:09 and doesn't look it is fixed (at least not confirmed) in 5.5-rc7 2020-01-20 14:01:24 morning 2020-01-20 14:01:32 seeking reviews on the doc patch for apk https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/9 2020-01-20 14:03:42 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 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 !8874 can close, installing 'lua5.2-lyaml' package "fixing" it 2020-01-20 14:53:17 #8874 that! 2020-01-20 14:54:31 ahh, not aports but "awall" https://gitlab.alpinelinux.org/alpine/awall/issues/8874 2020-01-20 14:55:07 awall#8874 sorry for flood :< 2020-01-20 14:55:38 Heh 2020-01-20 14:56:33 algitbot, wrrr! 2020-01-20 15:10:47 Lol 2020-01-20 16:18:35 The documentation is rather fuzzy around the difference of /media/mmcblk0p1/apks/armhf and /media/mmcblk0p1/cache 2020-01-20 16:19:55 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 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 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 They are indeed. 2020-01-20 16:26:59 Relevant script (redacted, snipped) https://git.riboflav.in/snippets/5 2020-01-20 16:28:16 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 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 when can we move from python2 ? 2020-01-20 16:29:55 _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 can we move trac from main to unmaintained ? 2020-01-20 16:30:53 _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 kodi optionally depends on python2, can it be disabled ? 2020-01-20 16:32:15 _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 Will attempt now. 2020-01-20 16:44:18 _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 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 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 :D made some MRs to remove more python2 stuff 2020-01-20 16:56:29 _ikke_: so to clarify: /etc/apk/world are packages that are installed automatically on boot 2020-01-20 16:57:25 And /etc/apk/world should list all the packages in /media/mmcblk0/apks/armhf 2020-01-20 16:57:52 Lastly the additional APK's (suppoprting / dependencies) must live in /media/mmcblk0/cache ? 2020-01-20 20:14:40 @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 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 @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 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 Hooray 2020-01-20 20:34:36 Thanks for giving it another go already :) 2020-01-20 20:40:41 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 after upgrade to 5.4.6 it started to make mess with emmc again 2020-01-20 20:41:17 oh 2020-01-20 20:41:28 i was wondering how intel related to aarch64 2020-01-20 20:49:19 heh, bugs are not limited by arch borders :) 2020-01-20 20:57:10 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 ok, will be harsh on MR then :P 2020-01-20 21:10:13 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 MY-R: https://www.kernel.org/category/releases.html it is here 2020-01-20 21:12:03 I saw J0WI (she) few times on irc 2020-01-20 21:12:31 mps, ye I know it is there but still suspicious :P 2020-01-20 21:12:56 also I'm 2020-01-20 21:13:44 read yesterday somewhere that ubuntu will use 5.5 as their LTS kernel 2020-01-20 21:14:14 but we don't have enough man power for such task, I think 2020-01-20 21:14:32 did ever happen before that announced longterm kernel was dropped? 2020-01-20 21:15:56 I can't remember 2020-01-20 21:19:06 have to add that the 5.4.13 is very nice on armv7 exynos 2020-01-20 21:21:18 nice because not freezeing like on intel gpus? :D 2020-01-20 21:23:17 I don't see any issue on it, works fast and stable 2020-01-20 21:24:35 for now! :P 2020-01-20 21:24:51 knock, knock :) 2020-01-20 21:25:01 heh 2020-01-21 02:45:03 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 @^7heo see answer on #alpine-linux 2020-01-21 07:16:20 arch="all !x86 !s390x" # tests fails on x86 and s390x 2020-01-21 07:16:45 ^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 hi 2020-01-21 07:24:01 yes, i htink so 2020-01-21 07:26:55 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 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 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 yes 2020-01-21 07:30:47 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 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 shellcheck helped me find that (we use $png instead of $_png in a loop) 2020-01-21 11:31:58 north1, have you thought about moving 'telegram-desktop' to community repo? :> 2020-01-21 11:32:33 just see that some qt apps die with 'Illegal instruction' on armv7 when starting them 2020-01-21 11:32:46 Yes, it is an objective 2020-01-21 11:33:10 Have lots of stuff to iron out though 2020-01-21 11:33:53 that must in some qt lib 2020-01-21 11:36:27 I thought that armhf is trouble maker :D 2020-01-21 11:56:32 or upstream devs 2020-01-21 11:58:05 :\ 2020-01-21 12:01:11 <_ikke_> Cogitri: :-) 2020-01-21 12:09:36 Thanks for adding the CI stuff, ikke :) 2020-01-21 12:35:44 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 ACTION opens firefox 2020-01-21 12:36:51 dotnetcore :^) 2020-01-21 12:56:51 markand: systemd bootloader 2020-01-21 12:57:25 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 i want systemd bootloader 2020-01-21 13:27:57 mps: likely related to JIT i would think 2020-01-21 14:04:23 north1: isnt that just gummiboot? 2020-01-21 14:04:54 Yeah it is a maintained version 2020-01-21 14:05:09 i didnt know you could still decouple it 2020-01-21 14:05:40 To be fair, It is not something to expect 2020-01-21 14:06:12 we were looking for alternatives for grub (before we started using it) 2020-01-21 14:06:37 Caveat it uses systemd code and systemd does not support musl 2020-01-21 14:06:40 but there is no other suitable cross arch boot loader 2020-01-21 14:06:51 It will happily use gnu libc specific extensions 2020-01-21 14:08:09 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, . 2020-01-21 14:38:27 _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, . Thanks again! 2020-01-21 14:56:16 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 north1: Maybe I read that wrong, are you saying systemd boot uses glibc? 2020-01-21 16:58:14 No, I'm saying that it uses extensions that are specific to glibc and only test against glibc 2020-01-21 16:58:36 It will happily use something that musl / posix doesn't have if it makes their lifes easier 2020-01-21 17:00:49 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 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 is there any reason why the samurai transition is not yet done? 2020-01-21 18:38:01 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 oh 2020-01-21 18:40:44 that is because halfway through i was going to put the symlink in its own package 2020-01-21 18:41:05 but changed my mind 2020-01-21 18:41:46 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 kaniini: in which way doas ninja murder your box? 2020-01-21 19:14:21 super resource-intensive? 2020-01-21 19:15:40 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 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 ninja does as well, but not with an env variable. 2020-01-21 19:18:15 gotcha 2020-01-21 19:18:18 neat! 2020-01-21 19:19:33 so ninja defaults to -j192 on my box, and since most ninja projects are written in C++ 2020-01-21 19:19:56 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 even though i have in abuild.conf, export JOBS=64 2020-01-21 19:21:22 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 but so you can do multiple tasks at once 2020-01-21 19:25:11 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 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 and we can talk." 2020-01-21 19:35:21 yes 2020-01-21 19:35:38 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 yes, Copying-policy: GPL 2020-01-21 19:36:33 <_ikke_> but nothing else? 2020-01-21 19:36:36 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 mostly this sentence: This file may be redistributed under the GNU Public License 2020-01-21 19:39:34 _ikke_: also I come to GPL-2.0-only, thanks. will do that 2020-01-21 19:40:43 yes, original author is T. Ts'o and most his pkgs are GPL2 2020-01-21 19:44:08 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 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 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 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 yes, I think so 2020-01-21 19:53:15 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 yes, works fine 2020-01-21 19:57:03 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 :\ 2020-01-21 20:14:58 _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 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 _ikke_: thanks 1000x 2020-01-21 20:19:35 <_ikke_> np 2020-01-21 20:28:23 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 didn't know till few minutes ago, apkbuild-lint told me 2020-01-21 20:29:32 <_ikke_> :) 2020-01-21 22:46:06 Another thing for aports-lint 2020-01-21 22:46:30 should we warn when something from alpine-sdk is in makedepends= like make, gcc, musl-dev ? 2020-01-21 22:55:12 makes sense to me 2020-01-21 22:55:49 is there a way to get a recursive dependency list from a package ? 2020-01-21 22:56:27 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 Sounds good 2020-01-21 22:58:45 nice 2020-01-21 22:59:08 <_ikke_> 363 deps for alpine-sdk :D 2020-01-21 22:59:11 oh, i think it is the other way around 2020-01-22 03:24:45 Should we replace explicit dependencies on ninja with samurai ? i use CMake -G Ninja 2020-01-22 04:19:51 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 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 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 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 north1: care to bring hub to community? 2020-01-22 08:41:38 err i actually mean lab :) 2020-01-22 08:42:01 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 I'm also working and testing the moonjit on edge/3.12 2020-01-22 08:43:45 right 2020-01-22 08:43:48 hum 2020-01-22 08:44:12 where were the patches? 2020-01-22 08:44:32 so we could add a patch to current luajit for s390x support for 3.11 2020-01-22 08:44:39 what is the diff between moonjit and luajit? 2020-01-22 08:44:50 ncopa: patches for luajit ? J0WI or/and I had it in some PR a while ago, digging 2020-01-22 08:44:51 iirc moonjit is a maintained fork of luajit 2020-01-22 08:45:06 but luajit is also developed right? 2020-01-22 08:45:16 i think its stagnated 2020-01-22 08:45:23 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 luajit latest commit is ysterday? 2020-01-22 08:45:50 I think moonjit in 3.12/edge is the way to go, really 2020-01-22 08:46:03 they havent merged the s390x support 2020-01-22 08:46:46 and ppc64le 2020-01-22 08:46:53 "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 patches for ppc64le + s390x have been floating around so long 2020-01-22 08:48:20 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 basically same as ppc64le patches 2020-01-22 08:49:06 sounds nice, two active project achieve same goals and downstream needs to patch things locally... 2020-01-22 08:49:08 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 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 im reading about moonjit vs luajit 2020-01-22 09:01:14 its a bit messy 2020-01-22 09:01:16 re alpine 2020-01-22 09:01:25 we will not push moonjit for 3.11 2020-01-22 09:01:36 we may push it for edge, but we dont know that yet 2020-01-22 09:01:59 who is we? 2020-01-22 09:01:59 we want luajit with s390x support, and we want it backported to 3.11 2020-01-22 09:02:16 alpine community i suppose 2020-01-22 09:02:20 :) 2020-01-22 09:02:21 or "me" 2020-01-22 09:02:25 haha 2020-01-22 09:02:51 I mean, luajit + s390x patch for 3.11 is different from moonjit on 3.11 2020-01-22 09:02:53 well i thought maybe there is somebody with more luajit knowhow 2020-01-22 09:03:17 tmhoang: exactly, im just thining out loud how to get the s390x inn 2020-01-22 09:03:39 so im thinking, we should probably do the luajit + s390x patch in edge first 2020-01-22 09:03:42 test it a bit there 2020-01-22 09:03:52 ok sounds good 2020-01-22 09:03:55 and make sure that it does not break other stuff 2020-01-22 09:03:59 then backport it to 3.11 2020-01-22 09:04:05 agreed 2020-01-22 09:04:15 after that we can discuss if we want move to moonjit 2020-01-22 09:04:40 why are those arch patchend not merge upstream? 2020-01-22 09:05:00 clandmeter: upstream luajit is busy and not responsive 2020-01-22 09:05:07 they are pretty big 2020-01-22 09:05:17 i saw the pull request. its a zillion of commits 2020-01-22 09:05:28 so i guess its lack of resources to review properly 2020-01-22 09:05:39 but both dont merge right? 2020-01-22 09:05:41 and upstream may not be familiar with the s390x 2020-01-22 09:05:56 or moonjit did not get them? 2020-01-22 09:06:10 as i understand, moonjit has merged them already 2020-01-22 09:06:19 booth ppc64le and s390x 2020-01-22 09:06:26 ah, and thats why tmhoang prefers moonjit? 2020-01-22 09:06:26 but i havent verified that 2020-01-22 09:06:42 i think also other distros are switching to moonjit 2020-01-22 09:06:58 right 2020-01-22 09:07:09 well i bumped into this issue already ones or twice 2020-01-22 09:07:22 where luajit is not available 2020-01-22 09:07:23 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 let's forget moonjit for a moment then, sorry I brought that up 2020-01-22 09:08:10 im not against moonjit nor luajit 2020-01-22 09:08:21 i just dont want a second libressl 2020-01-22 09:10:02 tmhoang: looks like the simplest thing to do is !2720 2020-01-22 09:10:18 that can be backported 2020-01-22 09:10:22 its a huge patch 2020-01-22 09:10:25 yes, I'm verifying also 2020-01-22 09:10:49 I want to make as little change in our patch as little as possible as the original one 2020-01-22 09:19:14 agere 2020-01-22 09:19:25 im looking at the changes in luajit 2020-01-22 09:19:31 this is sort of interesting 2020-01-22 09:19:34 https://github.com/LuaJIT/LuaJIT/commit/981ec8d2aac5cac76bdedd4015b6d32447b29597 2020-01-22 09:19:41 he is removing ppc64 support 2020-01-22 09:19:56 :( 2020-01-22 09:20:14 is it ppc64 not ppc64le ? 2020-01-22 09:26:37 not sure 2020-01-22 09:26:50 seems like there are som ppc support left: https://github.com/LuaJIT/LuaJIT/tree/v2.1/dynasm 2020-01-22 09:27:00 im not sure what was removed 2020-01-22 09:56:58 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 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 Neat, passed all exams, so it's time to go through the remaining issues now, I suppose :P 2020-01-22 10:22:01 Also nice that we've migrated to samu now 2020-01-22 10:22:45 <_ikke_> Cogitri: congrats 2020-01-22 10:24:43 Thanks :) 2020-01-22 10:29:21 woot, mps is very fast :) 2020-01-22 10:34:30 Cogitri /o 2020-01-22 10:34:34 Cogitri o/ 2020-01-22 10:40:27 Cogitri: congrats! 2020-01-22 10:41:04 tmhoang: im looking at the lua5.1 tests: https://www.lua.org/tests/ 2020-01-22 10:41:13 but there are lots of things that does not work 2020-01-22 10:46:41 ncopa: it relates to luajit ? 2020-01-22 10:49:39 Cogitri: congrats for exams 2020-01-22 10:55:03 yeah 2020-01-22 12:02:59 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 ok 2020-01-22 12:10:13 lets take it one step at the time 2020-01-22 12:11:20 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 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 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 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 ^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 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 Thanks, mps, ncopa and tmhoang :) 2020-01-22 12:45:25 Finally time for fun stuff again 2020-01-22 12:45:37 <^7heo> same here, hugo is building. 2020-01-22 12:45:42 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 Cogitri: school is boring and life is beautiful to waste it in school :) 2020-01-22 12:49:02 Well, uni is way more interesting than school so I don't want to complain too much :P 2020-01-22 12:49:24 ^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 ^7heo: ah yeah i misremembered, 2017-11-20 22:47:12 in alpine-devel 2020-01-22 12:51:03 but whatev 2020-01-22 12:51:22 ^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 ^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 no clue whats wrong with the openjdk11 build system for s390x and ppc64le 2020-01-22 12:53:05 its like it completely lost all the build target dependencies or similar 2020-01-22 13:17:48 ncopa: roger doger, https://gitlab.alpinelinux.org/alpine/aports/issues/11151 2020-01-22 13:41:05 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 looks like make returns non-zero, but i can't make out why 2020-01-22 13:52:55 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 ^7heo, re: efi problems, I think the problem is the manufacturers 2020-01-22 14:01:46 no one should be able to brick a machine by accidentally removing a file 2020-01-22 14:02:44 so a good machine should simply restore a default efi config if user deleted by mistake 2020-01-22 14:02:46 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 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 no it's the problem of manufacturers to implement badly something 2020-01-22 14:05:33 ACTION looks at ACPI 2020-01-22 14:05:52 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 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 didnt they say that UEFI would be much better than the previous BIOS boot? 2020-01-22 14:11:21 AinNero, EFI simplify lots of things, aka you don't need a bootloader to start an OS now 2020-01-22 14:11:56 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 ncopa: i'll just write a mail about it 2020-01-22 14:23:53 kaniini: you don't need 'cd "$builddir"' anymore 2020-01-22 14:24:05 in APKBUID, I mean 2020-01-22 14:24:32 mps: fascinating 2020-01-22 14:25:00 Atools will warn about it 2020-01-22 14:25:07 With apkbuild-lint 2020-01-22 14:25:24 mps: i will make a note to lint all of my APKBUILDs at some later date 2020-01-22 14:25:33 yes, last night I learned that $builddir is automatic also, ofc for canonical named upstream packages 2020-01-22 14:26:57 so, we don't need even this 'builddir="$srcdir/pkgname-$pkgver"' for most packages 2020-01-22 14:26:59 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 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 is anybody working GCC 10 yet? 2020-01-22 14:28:21 actually I prefer easy and safe steps 2020-01-22 14:28:29 is the 10 released? 2020-01-22 14:28:47 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 ah, yes, I read, some new interesting 'things' (features) will be there 2020-01-22 14:29:42 ^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 ^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 mps: http://tpaste.us/yZ8x 2020-01-22 14:33:10 aha, will look 2020-01-22 14:33:30 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 (to build on mips64, that is) 2020-01-22 14:33:49 on the glance looks good 2020-01-22 14:34:20 and, I don't have any objection 2020-01-22 14:35:51 thx 2020-01-22 14:38:29 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 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 apk is GPLv2 2020-01-22 14:41:16 read the files themselves :) 2020-01-22 14:44:18 Oh, I only grep'ed for GPL, derp 2020-01-22 14:44:20 Thanks :) 2020-01-22 14:52:34 Huh, is my Makefile-fu just so dated or does apk-tools not install the headers and stuff? 2020-01-22 14:54:59 it does not 2020-01-22 14:55:53 sent a mail to alpine-devel about procmail 2020-01-22 14:55:59 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 yes 2020-01-22 14:59:14 but procmail has security problems, and an alternative is available with fdm 2020-01-22 15:00:41 I probably won't have many supporters for porting apk-tools to meson, right? :P 2020-01-22 15:01:54 lets see: that would require us to put python in the bootstrap path 2020-01-22 15:02:01 yeah, i don't think you will 2020-01-22 15:02:03 :P 2020-01-22 15:03:09 ACTION goes learn Makefiles 2020-01-22 15:04:47 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 i'm confused 2020-01-22 15:08:19 what are you doing exact 2020-01-22 15:08:21 ly 2020-01-22 15:08:53 <^7heo> kaniini: are you talking to me? 2020-01-22 15:08:58 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 ok 2020-01-22 15:09:55 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 QQ: does fabled ever hang out in here? 2020-01-22 15:18:19 :D :D :D :D :D :D :D :D :D 2020-01-22 15:18:24 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 reidrankin: he appears sometimes 2020-01-22 15:21:54 reidrankin: best bet would be to send him a mail 2020-01-22 15:23:14 why was abuild -R removed (to recursively _build_ dependencies, rather than fetch them) 2020-01-22 15:23:30 I relied on that a lot :( 2020-01-22 15:24:01 it did not work reliably 2020-01-22 15:24:12 ^7heo: wget will tell you length when start download :) 2020-01-22 15:24:58 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 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 :D 2020-01-22 15:28:16 kaniini: yeah, lets nuke it 2020-01-22 15:30:00 ncopa: what are your thoughts on trying to tackle the mess that is kernels in this dev cycle? 2020-01-22 15:30:45 bad time for such question. i feel a bit stressed atm :) 2020-01-22 15:30:50 okay 2020-01-22 15:30:57 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 kaniini: what you mean by 'mess' 2020-01-22 15:31:02 i have though a bit on how to solve it 2020-01-22 15:31:35 and i though of have some sort of alpine-defconfig or similar 2020-01-22 15:31:47 not sure whats the best approach 2020-01-22 15:31:48 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 this leads to some kernels having more coverage than others 2020-01-22 15:32:24 aha, yes, this is mess 2020-01-22 15:32:27 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 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 the linux-lts is a generic kernel 2020-01-22 15:33:08 one size, fits none 2020-01-22 15:33:12 :) 2020-01-22 15:33:34 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 the -rpi is highly specialized 2020-01-22 15:33:42 I planing to try make rpi zero to use linux-lts 2020-01-22 15:34:17 but we are locked to 5.4 now, not sure will that work 2020-01-22 15:34:42 and that's the other thing, we may want to offer a kernel that tracks linus's tree 2020-01-22 15:34:46 instead of just LTS 2020-01-22 15:34:47 5.5 got RPI4 support 2020-01-22 15:35:09 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 as ncopa wrote, 'one size, fits none' 2020-01-22 15:36:06 also I contemplated about proposal to split kernels by arches 2020-01-22 15:36:23 im open to suggestions how to do it 2020-01-22 15:36:39 but not sure, this will require a lot more work, I fear 2020-01-22 15:37:01 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 the current approach is bearable for me atm 2020-01-22 15:37:55 few months I'm tempted to create testing/linux-armv7-mp (multiplatform), but managed to resist self :) 2020-01-22 15:39:16 and, in my head 'someone' talking linux-srv (server optimized) and linux-ws (workstation optimized) 2020-01-22 15:40:04 i think splitting by arch may be a good idea 2020-01-22 15:40:33 a differnt aport for each arch? 2020-01-22 15:40:34 but we would still want to agree on a kernel version for a given dev cycle 2020-01-22 15:40:37 yes 2020-01-22 15:40:45 so you have 2020-01-22 15:40:49 linux-${arch}-generic 2020-01-22 15:40:52 for example 2020-01-22 15:41:28 we have testing/linux-amlogic already, for example 2020-01-22 15:41:30 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 the apkbuilds woudl be similar 2020-01-22 15:41:53 just a nightmare to maintain it 2020-01-22 15:42:05 i'm not sure 2020-01-22 15:42:16 currently i bump version one place and run a script to rebuild the 3rdparty mods 2020-01-22 15:42:28 i think we should discuss in email and figure out the best way to proceed 2020-01-22 15:42:32 yeah 2020-01-22 15:42:49 i suspect riscv is going to be another area where we get a lot of board-specific kernels 2020-01-22 15:43:01 current status is bearable for now, imo 2020-01-22 15:43:08 i dont mind if you add an linux-octeon that i never need to touch 2020-01-22 15:43:57 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 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 thats unsustainable imho 2020-01-22 15:45:50 so, risc-v would be bigger jungle than arm. nice 2020-01-22 15:46:20 I hoped for opposite 2020-01-22 15:46:26 yeah... 2020-01-22 15:46:52 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 what i am afraid of is that it can slow down relases 2020-01-22 15:47:40 or we end up with releases with different kernel versions 2020-01-22 15:48:18 true 2020-01-22 15:49:47 Arch linux alarm (ARM) tree http://tpaste.us/YpaP 2020-01-22 15:51:55 and those are all different versions 2020-01-22 15:52:35 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 no, they are not all different mainline versions, but some yes 2020-01-22 15:53:24 linux-oak is certainly different (3.18) 2020-01-22 15:53:25 most of them are different .config options 2020-01-22 15:53:53 oak is different for sure :) 2020-01-22 15:54:09 lol somebody emailed me offlist claiming that they have plans to "revive procmail" 2020-01-22 15:54:11 did you fixed your issues with it 2020-01-22 15:54:25 mps: yes, i just repacked it with the correct DTB 2020-01-22 15:54:31 good enough for now :D 2020-01-22 15:54:43 still 3.18 2020-01-22 15:54:53 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 but alpine is a great OS for a chromebook 2020-01-22 15:55:36 i tried few months ago but didn't managed 2020-01-22 15:55:51 well 2020-01-22 15:55:56 there is TTL serial on the board 2020-01-22 15:55:58 kaniini: I'm typing right now on one :) 2020-01-22 15:56:03 so i am hoping i can debug that way 2020-01-22 15:56:33 hello 2020-01-22 15:56:41 i might just buy a pinebook pro when they come out with an 11" version 2020-01-22 15:56:46 I noticed some MediaTek updates in last few kernel 2020-01-22 15:57:05 kernels* 2020-01-22 15:58:26 and, I agree, alpine is great everywhere where I tried 2020-01-22 16:10:27 Uhh...do you guys also get `ninja: unknown tool 'compdb'` since the migration to samu? 2020-01-22 16:10:37 Meson throws that every time I try to configure a builddir now 2020-01-22 16:23:04 no 2020-01-22 16:24:34 Hm, I'm getting that for every meson project now 2020-01-22 16:25:55 With a fully upgraded system, I can't recall that happening with ninja 2020-01-22 16:26:45 https://github.com/michaelforney/samurai/issues/19 2020-01-22 16:26:49 it is a harmless error 2020-01-22 16:26:50 oh dear 2020-01-22 16:27:10 Ah yes 2020-01-22 16:27:54 Somewhat certain that breaks GNOME Builder though 2020-01-22 16:28:43 > GNOME Builder 2020-01-22 16:28:47 this ain't windows 2020-01-22 16:30:37 but yes, that is not expected fallout 2020-01-22 16:30:47 let me see how hard it would be to add support for compdb 2020-01-22 16:31:03 I wouldn't call users choosing whatever IDE they like as being Windows-y :) 2020-01-22 16:31:05 Thank you 2020-01-22 16:31:50 Cogitri: if i cannot get an answer soon, we will revert the migration 2020-01-22 16:31:57 mforney: are you available? 2020-01-22 16:32:32 kaniini: Ah, no need for such extreme steps, I suppose 2020-01-22 16:33:30 It's only a minor thing breaking, so I don't think we need to rush reverting 2020-01-22 16:34:52 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 I was unaware that it was unimplemented, fwiw 2020-01-22 16:36:08 Cogitri: can you make an empty compile_commands.json and see if GNOME Builder still works 2020-01-22 16:36:12 Well, without trying to prove a point or anything, this almost always happens with such migrations 2020-01-22 16:36:27 I'm happy that only such a minor thing broke 2020-01-22 16:36:39 https://github.com/NixOS/nixpkgs/pull/77140#issuecomment-571334359 2020-01-22 16:36:50 I grepped gnome-builder for compdb, and came up dry - does it actually use it? 2020-01-22 16:36:55 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 It uses it for the "Build" button 2020-01-22 16:37:11 doesn't it invoke ninja for that 2020-01-22 16:37:48 And apparently to know include paths and stuff 2020-01-22 16:38:40 I guess I'm not understanding specifically how it breaks gnome builder 2020-01-22 16:39:43 okay 2020-01-22 16:39:46 who cares 2020-01-22 16:39:51 what does a compile_commands.json look like 2020-01-22 16:39:58 i will just fix it myself 2020-01-22 16:40:08 https://clang.llvm.org/docs/JSONCompilationDatabase.html 2020-01-22 16:40:25 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 it does seem fairly straightforward 2020-01-22 16:40:57 this is the ninja impl https://github.com/ninja-build/ninja/blob/d986e4db5630cf1c5547e69b5556f006f7d3444a/src/ninja.cc#L764 2020-01-22 16:41:07 and why does samurai not support it 2020-01-22 16:41:10 Here's how an actual one can look like: http://dpaste.com/2NWSZTX 2020-01-22 16:41:19 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 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 well we will soon find out if samurai can provide pkgconf-level SLA 2020-01-22 16:42:19 if it cannot, it will have to be reverted 2020-01-22 16:42:23 sorry 2020-01-22 16:42:49 the first step would be an issue 2020-01-22 16:42:51 filing the ticket now 2020-01-22 16:43:08 distributions do not file issues to have pkgconf issues fixed 2020-01-22 16:43:18 they ping me in IRC and everything gets dropped until it is fixed 2020-01-22 16:43:18 well, I'm doing it anyway 2020-01-22 16:45:17 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 https://github.com/michaelforney/samurai/issues/33 2020-01-22 16:45:40 kaniini: yes, I think that's understood 2020-01-22 16:45:47 i knew i should have just written my own ninja replacement 2020-01-22 16:45:54 please relax, kaniini 2020-01-22 16:46:11 people have to sleep 2020-01-22 16:46:15 michael will be around soon enough 2020-01-22 16:48:05 mps: looks like uboot-tools and u-boot has same upstream source package 2020-01-22 16:48:35 i think it make sense to let u-boot-tools be a subpackage of u-boot 2020-01-22 16:49:01 ncopa: that could be messy 2020-01-22 16:49:09 tools are built using sandbox config 2020-01-22 16:50:02 but they are built from same sources? 2020-01-22 16:50:13 yes 2020-01-22 16:50:20 i mean, we can merge the tools i guess 2020-01-22 16:51:13 openjdk11 and gnu make 4.3 is a mess 2020-01-22 16:51:34 need to be reported upstream to oracle that openjdk11 does not build with make 4.3 2020-01-22 16:51:52 GCC 10 is going to be another mess with -fno-common being in the default CFLAGS 2020-01-22 16:52:08 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 lets clean up the messes we have before we introduce new mess 2020-01-22 16:52:45 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 ncopa: u-boot is only for arm while tools are for other arches 2020-01-22 16:57:08 or arch's (what is correct term) 2020-01-22 16:57:09 kaniini: the answer to your question on github is yes 2020-01-22 16:57:10 there are several 2020-01-22 16:57:14 I support a rollback now 2020-01-22 16:57:54 well 2020-01-22 16:58:16 i don't think a lot of them are hard to implement 2020-01-22 16:59:02 of the tools, i think compdb and restat are the only ones that are likely needed 2020-01-22 16:59:06 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 and restat is new 2020-01-22 16:59:54 well, if the only problem we've run into is gnome builder's compdb stuff 2020-01-22 17:00:10 then just fixing that should be acceptable 2020-01-22 17:04:18 i think compdb and query are the ones we need 2020-01-22 17:08:30 ok 2020-01-22 17:08:34 well 2020-01-22 17:08:52 ncopa: what is going on with openjdk11 and gnu make 2020-01-22 17:19:12 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 i could manually do: make and it would build it 2020-01-22 17:20:04 and the build will continue with error on next dependency 2020-01-22 17:20:13 the error is "dependency is missing" 2020-01-22 17:20:20 and it does not know how to build it 2020-01-22 17:20:42 openjdk11 has some super advanced makefiles 2020-01-22 17:20:53 in the GNU Make 4.3 news i see something about comments 2020-01-22 17:20:58 yeah 2020-01-22 17:21:09 not sure if thats the problem 2020-01-22 17:21:11 could be 2020-01-22 17:22:29 could also be regression in make 2020-01-22 17:22:53 should report it upstream somewhere 2020-01-22 17:28:18 the question ultimately is where 2020-01-22 17:30:25 exactly 2020-01-22 17:30:28 and im tired 2020-01-22 17:31:24 oh well... i was this close to tag a snapshot release while builders were idle 2020-01-22 17:31:31 and now armhf fails again 2020-01-22 17:34:14 i wonder what to respond here https://github.com/alpinelinux/docker-alpine/issues/39#issuecomment-577220407 2020-01-22 17:36:35 i guess we need to create new 3.10, 3.9 and 3.8 releases 2020-01-22 17:43:35 ah yes, docker 2020-01-22 17:43:59 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 my response would be "run apk upgrade -U -a you morons" 2020-01-22 17:44:42 i was initially thinking of a variant of that 2020-01-22 17:44:51 heh, agree 2020-01-22 17:45:07 something like this 2020-01-22 17:47:03 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 updates are dependent on proper usage of the package manager to fetch and install those updates. 2020-01-22 17:47:40 that's "run apk upgrade -U -a you morons" in a nice tone 2020-01-22 17:47:46 alternatively, you could say 2020-01-22 17:48:14 "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 i think they expect the image to be maintained 2020-01-22 17:49:02 which i think is not an unreasonable expectation, given that it is that small 2020-01-22 17:49:02 wouldn't that break things though 2020-01-22 17:49:27 i wonder if we can have a script 2020-01-22 17:49:32 just automatically generate new images 2020-01-22 17:49:33 every day 2020-01-22 17:49:58 we could do somethinglike that 2020-01-22 17:50:01 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 yup it is 2020-01-22 17:50:23 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 you can make a tag point to another checksum 2020-01-22 17:51:00 nah, it needs to be manually merged into the official library 2020-01-22 17:51:02 the checksum 2020-01-22 17:51:34 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 and not every day 2020-01-22 17:51:58 apk ver ? 2020-01-22 17:52:10 the problem is that i link upstream release with the tags in docker 2020-01-22 17:52:26 but it would be good to separate those 2020-01-22 17:52:39 the docker image uses the minirootfs from releases 2020-01-22 17:53:04 makes sense 2020-01-22 17:53:08 well 2020-01-22 17:53:11 then there you go 2020-01-22 17:53:14 but basically, it would be nice if we could tag "light" releases 2020-01-22 17:53:25 just say that the tags correspond to physical releases 2020-01-22 17:53:42 which only builds the minirootfs 2020-01-22 17:54:00 ideally we should tag new relase of 3.10, 3.9 and 3.8 2020-01-22 17:54:00 ah 2020-01-22 17:54:03 so something like 2020-01-22 17:54:07 3.9.1.1 2020-01-22 17:54:10 3.9.1.2 2020-01-22 17:54:11 etc 2020-01-22 17:54:14 yup 2020-01-22 17:55:16 and do that every time something in minirootfs changes 2020-01-22 17:59:08 im looking over the kernel configs 2020-01-22 17:59:34 CONFIG_X86_INTEL_TSX_MODE_AUTO=y is on all x86 kernel configs except -virt.x86_64 2020-01-22 17:59:37 where it is OFF 2020-01-22 18:00:06 safest is OFF i suppose 2020-01-22 18:00:19 should we set all to OFF or all to AUTO 2020-01-22 18:04:23 i think OFF 2020-01-22 18:04:27 TSX is broken isnt it 2020-01-22 18:04:52 AUTO enables it on safe platforms it claims 2020-01-22 18:06:11 but are they actually safe :D 2020-01-22 18:06:26 thats the question at hand i guess 2020-01-22 18:07:23 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 kill it 2020-01-22 18:07:31 kill it now 2020-01-22 18:07:41 kaniini: just to check, you aren't middle of implementing compdb for samurai, right? 2020-01-22 18:07:50 mforney: i am not 2020-01-22 18:08:03 i have a few things i need to do ahead of time 2020-01-22 18:08:50 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 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 mforney: thank you for the quick response 2020-01-22 18:09:28 kaniini: ok will do. thanks! 2020-01-22 18:10:22 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 thanks mforney 2020-01-22 18:19:06 Thanks :) 2020-01-22 18:19:16 mforney: welcome to being the maintainer of critical build system infrastructure :D 2020-01-22 18:19:33 the first few months of pkgconf were like this 2020-01-22 18:19:48 some edge case would be missing and it was like "oh fuck we need to ship a release" 2020-01-22 18:19:55 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 public in what way 2020-01-22 18:20:09 I'm looking for the build scripts to generate the armhf image 2020-01-22 18:20:19 yes, its on gitlab 2020-01-22 18:20:36 Assuming this one - https://gitlab.alpinelinux.org/alpine 2020-01-22 18:21:05 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 see aports/scripts/mkimage.sh 2020-01-22 18:21:13 kaniini++ tyvm! 2020-01-22 18:28:53 i tagged new edge snapshot 2020-01-22 19:15:34 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 This is *extremely* hacky code now - caused by desperation :( 2020-01-22 19:18:17 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 vivi_: does /etc/apk/repositories contain a path to your repo ? 2020-01-22 19:20:51 kaniini, yes, it does. /media/mmcblk0/apks 2020-01-22 19:21:22 vivi_: are all the packages you want installed placed in /etc/apk/world *inside* the apkovl ? 2020-01-22 19:21:34 Yes, every one of them. 2020-01-22 19:22:44 do you have a boot log? 2020-01-22 19:23:52 I'll get one now - gotta dd this fresh image and I'll capture 2020-01-22 19:24:49 ERROR: busybox-initscripts package mentioned in index not found 2020-01-22 19:25:05 Including 8 others - all of which appear to be highly important. 2020-01-22 19:25:28 are they in the dir? 2020-01-22 19:26:05 ACTION mounts sd card 2020-01-22 19:26:39 -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 They're all there. 2020-01-22 19:28:25 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 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 is it `index` or `apk index` ? 2020-01-22 19:31:45 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 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 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 Going to break this out into it's own standalone script to attempt to simplify 2020-01-22 19:53:25 hi all. is alpine upgrading php to 7.4 anytime soon? 2020-01-22 20:02:34 dfnord, https://gitlab.alpinelinux.org/alpine/aports/commit/e045f093af466b4d7f159b9e6e4eb8c2834cb6fc 2020-01-22 20:02:51 Looks like it 2020-01-22 20:14:36 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 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 i mean this one here: https://gitlab.alpinelinux.org/alpine/aports/tree/master/community/php7 2020-01-22 20:38:51 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 Cogitri: ping 2020-01-22 21:02:14 kaniini: I believe he is unavailable atm 2020-01-22 21:03:24 mforney: based on testing, i believe your compdb is adequate 2020-01-22 21:05:29 mforney: will there be a 1.0.1 or should i just backport this myself 2020-01-22 21:08:54 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 okay 2020-01-22 21:09:25 cool 2020-01-22 21:09:57 j 2020-01-22 21:10:16 mforney: thanks for your work on this :) 2020-01-22 21:10:35 np 2020-01-22 21:34:40 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 maybe only those who will try paste something from half working system without certs or with wrong time? 2020-01-22 21:39:11 right, thats also what i thought 2020-01-22 21:39:33 ye :\ 2020-01-22 21:39:47 question is, do we want to support broken use cases :) 2020-01-22 21:41:16 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 thats architectural racisme :) 2020-01-22 21:42:14 or just missing rtc :D 2020-01-22 21:42:22 there are arm machines with rtc :) 2020-01-22 21:42:39 and x86 ones without :) 2020-01-22 21:42:52 true :P 2020-01-22 21:43:22 traefik is just stupid 2020-01-22 21:43:23 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 yes 2020-01-22 21:46:36 its maybe better 2020-01-22 21:46:48 but it also means you need to do it per container\ 2020-01-22 21:47:09 that wouldnt be that much work 2020-01-22 21:47:24 i played with v2 before 2020-01-22 21:47:28 not sure which hosts 2020-01-22 22:01:04 kaniini: pong, can test later 2020-01-22 22:01:21 Cogitri: looks like it is working to me :) 2020-01-22 22:13:26 Neat 2020-01-22 22:43:37 ERROR: udev-init-scripts-33-r0: package mentioned in index not found 2020-01-22 22:44:10 -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 Everything else from the directory / volume installed except for this and `hwids-*` 2020-01-22 22:47:22 etc/apk/world includes the udev-init-scripts, hwids-pci, hwids-usb, hwids-udev, hwids-net 2020-01-22 23:47:46 should the firefox-esr 68.4.2 be 'backported' to 3.11 2020-01-22 23:49:20 That fixed some CVEs, didn't it? 2020-01-22 23:51:38 didn't found yet, but probably 2020-01-23 00:33:15 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 kernel 5.4.14 is out 2020-01-23 08:28:58 and I don't see i915 fix there, maybe will see it after coffee :) 2020-01-23 08:51:07 mps: re firefox-esr #11118 2020-01-23 08:54:27 yes, I know for this one, but I thought it is fixed in 68.4.1 2020-01-23 08:54:56 am I the only one thinking GitLab UX pretty awful? 2020-01-23 08:55:09 I goes into alpine/aports, see that I can create a merge request from a recent commit 2020-01-23 08:55:24 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 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 markand: this is alpine development. please try #gitlab 2020-01-23 08:56:57 _ikke_, exactly 2020-01-23 08:57:16 because I think it worked fine few weeks ago 2020-01-23 08:58:42 ncopa: apk policy firefox-esr => http://dl-cdn.alpinelinux.org/alpine/v3.11/community 2020-01-23 08:58:43 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 atools-19.9.1-r0 2020-01-23 09:00:14 ok, I will create MR to test build before push 2020-01-23 09:00:41 if we found CVE for it we can add them later 2020-01-23 09:01:30 @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 yay 2020-01-23 09:01:47 <_ikke_> haven't had the time yet 2020-01-23 09:06:46 heh, Cogitri just updated his MR with firefox-esr 68.4.2 version. 2020-01-23 09:07:17 Yup 2020-01-23 09:07:30 Gonna merge once CI went through, I suppose 2020-01-23 09:08:08 ok, then I will not create new one 2020-01-23 09:08:12 And backport it to 3.11 after a little while so icon locations are fixed for that too 2020-01-23 09:08:40 Huh? 2020-01-23 09:08:45 ah, you made MR in master 2020-01-23 09:08:56 That MR only fixes linter nits and the icon install location 2020-01-23 09:09:38 I'm started to make plain upgrade for 3.11 2020-01-23 09:11:08 Ah, please do keep doing that then :) 2020-01-23 09:12:11 I'm watching your MR, will it pass 2020-01-23 09:13:06 im updating kernels in stable branches 2020-01-23 09:13:26 kind of annoyed that i spent an hour yesterday on it and now there is a new version... 2020-01-23 09:14:26 release often, release early (upstream devs mantra) :) 2020-01-23 09:15:18 hopefully you don't do that every vim version ;p 2020-01-23 09:16:06 which has literally dozens of versions per day 2020-01-23 09:16:56 ncurses releases nearly weekly 2020-01-23 09:17:17 and kernel LTS :) 2020-01-23 09:17:40 so, life is not boring ;) 2020-01-23 09:44:35 drats. i merged wrong luajit patch 2020-01-23 09:45:03 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 lol :P 2020-01-23 09:58:21 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 if life was that simple... 2020-01-23 09:58:54 ye 2020-01-23 09:59:18 <_ikke_> focus is a luxury 2020-01-23 09:59:50 algitbot: thanks for the support 2020-01-23 10:00:06 ... i'd be curious to see your code, algitbot 2020-01-23 10:00:25 ye but claiming that somebody is good in many things at once is very naive 2020-01-23 10:00:54 algitbot, AI :) 2020-01-23 10:01:27 algitbot: please behave! 2020-01-23 10:01:46 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 yeah, sounds like a good idea 2020-01-23 10:02:04 but first, let put some ppl on mars. 2020-01-23 10:02:08 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 algitbot, give me beer 2020-01-23 10:02:32 algitbot: give me beer 2020-01-23 10:02:34 :( 2020-01-23 10:04:56 algitbot: give me a beer 2020-01-23 10:05:16 _ikke_: yeah, thats algitbot! 2020-01-23 10:05:45 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 aah :-) 2020-01-23 10:06:11 🚱 2020-01-23 10:06:49 connect algitbot with alexa :D 2020-01-23 10:07:07 <_ikke_> ncopa: no potable watter? 2020-01-23 10:07:18 thelounge is stupid 2020-01-23 10:07:21 <_ikke_> heh 2020-01-23 10:07:24 :-p 2020-01-23 10:07:41 yeah blame it on something else :p 2020-01-23 10:08:30 #60000 :D 2020-01-23 10:08:48 eh :\ 2020-01-23 10:09:18 #6000 ! 2020-01-23 10:11:54 "This bug was mainly to celebrate the 6000th bug report :)" 2020-01-23 10:11:56 :) 2020-01-23 10:12:30 <_ikke_> heh :-) 2020-01-23 10:12:30 algitbot: give me advice about my dilemma with !2212 :) 2020-01-23 10:17:01 ps I think #8599 can be closed 2020-01-23 10:19:42 MY-R: I agree 2020-01-23 11:41:20 im backporting CVE fix to libjpeg turbo 2020-01-23 11:41:40 nasty fix, because they changed tabs to spaces 2020-01-23 11:41:53 and introduced som camelcase vars 2020-01-23 11:42:19 which makes it impossible to do a clean cherrypick and the diff is hard to spot 2020-01-23 11:50:45 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 TIMTOW to make distro maintainers to cry :) 2020-01-23 11:54:09 <^7heo> distro maintainer != package maintainer. 2020-01-23 11:54:33 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 never touched nodejs 2020-01-23 11:56:06 <^7heo> Good for you :) 2020-01-23 11:56:25 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 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 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 ^7heo: you have a point, instead of C I'm contemplating about go to assembly 2020-01-23 11:59:53 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 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 perl is readable, ofc, but agree is not for py programmers 2020-01-23 12:05:49 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 I will try now in lxc 2020-01-23 12:06:39 ^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 ^7heo: no, not problem for me, I told that I enjoy to read your 'writings' 2020-01-23 12:11:31 for years I have only one person in ignore list 2020-01-23 12:25:09 mps: i havent seen it 2020-01-23 12:32:33 finally managed to backport libjpeg-turbo fix 2020-01-23 12:37:38 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 mps: Probably due to running out of RAM 2020-01-23 12:45:00 _ikke_: X86_64 CI runner doesn't do stuff again, Jobs just time out 2020-01-23 12:47:08 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 Thank you :) 2020-01-23 12:49:39 but I see you pushed it already 2020-01-23 12:49:53 I pushed my pushes to master not 3.11 2020-01-23 12:50:03 ah, yes 2020-01-23 12:50:15 Also, I didn't do an upgrade or anything, I just fixed the icon install location 2020-01-23 12:50:52 didn't looked carefully to 'algitbot| aports:master' 2020-01-23 12:51:23 on master it is upgraded few days ago already 2020-01-23 13:00:56 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 mps' Firefox MR 2020-01-23 13:08:53 !3319 2020-01-23 13:33:48 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 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 reidrankin: index signs control section, control signs data 2020-01-23 13:54:40 right, but why? 2020-01-23 13:55:27 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 performance reasons 2020-01-23 13:57:08 it allows for deferring checking the data sign ature 2020-01-23 13:57:26 until the subtransaction is about to be committed to disk 2020-01-23 13:57:29 ah, so an invalid sig can be detected fast. 2020-01-23 13:57:34 got it. 2020-01-23 13:58:24 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 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 well 2020-01-23 13:58:44 the signature is only of the control part 2020-01-23 13:59:14 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 no it's not 2020-01-23 14:00:29 the data part only has a sha256 over the whole gzipped tar stream 2020-01-23 14:00:57 the individual file checksums are stored in the data section as pax attributes 2020-01-23 14:03:17 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 it would be really nice if there was a hash of the uncompressed data for that purpose 2020-01-23 14:07:26 so I might send up a PR for that in a day or two 2020-01-23 14:09:25 well, it has been a while since i looked at it 2020-01-23 14:09:45 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 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 I've been following Timo's thread regarding the switch to binary formats 2020-01-23 14:15:19 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 you should say so then 2020-01-23 14:17:36 it is not set in stone 2020-01-23 14:18:03 (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 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 i think it makes sense to use a common container format for both packages and the database 2020-01-23 14:19:43 but the benefits are really long term 2020-01-23 14:19:49 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 well, my point is this. 2020-01-23 14:21:12 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 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 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 I am in favor of more incremental improvements to apk 2020-01-23 14:22:47 well that is how things were going 2020-01-23 14:22:53 ok, let me ask a really bad question 2020-01-23 14:23:01 it seems like we're incrementally building up a spec for a big change 2020-01-23 14:23:06 I'd like to incrementally build up the change instead 2020-01-23 14:23:06 but some things went down, and it is not happening that way right now ;) 2020-01-23 14:23:18 why not totally rewrite apk-tools in Go 2020-01-23 14:23:57 reidrankin: well, i was expecting you to say rust 2020-01-23 14:24:00 :D 2020-01-23 14:24:08 i don't know rust yet :P{ 2020-01-23 14:24:17 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 in the general case, I agree with you 2020-01-23 14:24:57 also rewriting it in Go is undesirable. right now we can bootstrap apk-tools very early 2020-01-23 14:25:09 s/in Go// 2020-01-23 14:25:33 i dont think apk-tools needs a rewrite anyway 2020-01-23 14:25:43 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 agreed 2020-01-23 14:25:55 <_ikke_> s/work/worse 2020-01-23 14:25:55 _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 rewriting things can only make things worse 2020-01-23 14:26:37 <_ikke_> ddevault: agreed 2020-01-23 14:27:02 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 rewriting it in Go does not change the format 2020-01-23 14:28:11 well, not deliberately 2020-01-23 14:28:16 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 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 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 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 (I can't figure out if that's a bug or a feature) 2020-01-23 14:33:14 reidrankin: there is already static apk version ;p 2020-01-23 14:33:18 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 is the BCM4360 802.11ac Wireless supported in alpine? 2020-01-23 14:35:34 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 im tagging releases for 3.10, 3.9 and 3.8 now 2020-01-23 14:37:10 tomz-alpine: better ask on #alpine-linux, probably will get answer earlier than here 2020-01-23 14:37:32 thanks 2020-01-23 14:38:31 ncopa: might be worth looking at openjdk security updates on those releases 2020-01-23 14:38:38 J0w1 made MRs for them 2020-01-23 14:39:02 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 north1: i had a long look at it this week 2020-01-23 14:41:46 it does not build with gnu make 4.3 2020-01-23 14:41:59 not sure if its a bug in make or in openjdk makefiles 2020-01-23 14:45:23 As far as I remember make didn't make it into the older releases 2020-01-23 14:48:04 i like to test it in edge before i push to stable if possible 2020-01-23 14:48:22 it also makes sure that we dont forget it in next major release 2020-01-23 14:48:25 Alright 2020-01-23 14:48:41 but, may be worth push to stable first in this case 2020-01-23 14:50:25 kaniini: compile_commands.json is not a flatpak manifest, skipping: :6:67: Parse error: unexpected character `,', expected character `]' 2020-01-23 14:50:44 Seems like it's not really working still :/ 2020-01-23 14:51:03 mforney: looks like there are some escaping issues 2020-01-23 14:55:54 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 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 hmm, !3319 failed on CI but pass fine in local lxc, x86_64 2020-01-23 16:03:13 You can click on the buildjob to see why it failed 2020-01-23 16:03:27 It failed because no builder was available within the timeout limit 2020-01-23 16:04:16 'clickjob', where it is? 2020-01-23 16:04:23 no 2020-01-23 16:04:30 'buildjob' 2020-01-23 16:05:25 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 Clcik on "build-x86_64" for the log of the x86_64 runner 2020-01-23 16:06:23 ah, I see, right side 2020-01-23 16:07:40 always look on middle with log looking for bug :) 2020-01-23 16:07:52 tunnel vision 2020-01-23 16:09:24 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 Cogitri: btw, your image post is on (your?) localhost 2020-01-23 16:13:16 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 ye :D 2020-01-23 16:17:14 Oh huh 2020-01-23 16:17:16 That's not good 2020-01-23 16:17:49 and no problem, imo 2020-01-23 16:18:10 Probably forgot to change the hostname in some config 2020-01-23 16:26:11 Yup, should work now 2020-01-23 16:35:31 whats the current performance bottleneck with apk-tools? 2020-01-23 16:35:42 i'd hilight timo teras but i dont know their nick 2020-01-23 16:39:59 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 'git push origin 3.11-stable'? 2020-01-23 16:41:10 If origin is your git.a.o then yes 2020-01-23 16:41:23 I'd recommend you check out maxice8's tools, they're really nice for that 2020-01-23 16:42:52 I have his tools, what to look there 2020-01-23 16:42:58 quick apk-tools question: anyone have a strong opinion on the ternary operator? 2020-01-23 16:43:36 I don't like it lots but it can make stuff shorter I suppose 2020-01-23 16:44:40 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 my origin is git.a.o 2020-01-23 16:47:01 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 hm, 'git push origin HEAD', maybe 2020-01-23 16:51:53 _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 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 and current 'git branch' http://tpaste.us/b451 2020-01-23 16:55:05 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 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 ok, thanks 2020-01-23 16:56:07 <_ikke_> succeeded :) 2020-01-23 16:56:11 hah, yes 2020-01-23 16:56:23 _ikke_: 1000x thanks 2020-01-23 16:56:53 I have to save in notes this conversation 2020-01-23 17:02:13 fabled: is it security or is it performance? if it's both then the change is too big 2020-01-23 17:15:04 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 that, exactly same commit 2020-01-23 17:18:00 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 aha, I see 2020-01-23 17:57:57 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 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 bleh 2020-01-23 18:00:01 I know it's not constructive, but bleh is how I feel about all of this 2020-01-23 18:00:11 then you are not listening 2020-01-23 18:00:17 the current format is broken 2020-01-23 18:00:30 I am listening perfectly well 2020-01-23 18:00:41 I don't buy it 2020-01-23 18:01:14 https://gitlab.alpinelinux.org/alpine/apk-tools/issues/10670 2020-01-23 18:01:28 infact, look at https://gitlab.alpinelinux.org/alpine/apk-tools/issues 2020-01-23 18:01:40 and more specifically https://gitlab.alpinelinux.org/alpine/apk-tools/issues?milestone_title=v3.0 2020-01-23 18:01:41 use of sha-1 isn't a format issue, and fixing it does not necessitate an overhaul 2020-01-23 18:01:54 fabled: I have a MR to fix that just about ready to go 2020-01-23 18:02:21 reidrankin, fix what? 2020-01-23 18:02:32 #10670 2020-01-23 18:02:49 I'm not sure how the link to the issues list justifies your position 2020-01-23 18:02:50 the bad signature one, or the sha1 thing? 2020-01-23 18:03:04 very little of this has anything to do with package or index format 2020-01-23 18:03:06 both actually 2020-01-23 18:03:34 i think we should stick to e-mail instead of being defensive in IRC 2020-01-23 18:03:37 reidrankin, the sha1 change is probably format breaking 2020-01-23 18:04:07 nope, IDK if it was designed to be forwards-compatible on purpose but it is 2020-01-23 18:04:13 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 specifically, all the signatures prepended to the file are processed until one that is acceptable is matched 2020-01-23 18:04:37 kaniini, the package signature is upstreamed and works. i'm talking about the index having sha1 2020-01-23 18:05:15 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 so you can prepend any kind of new signature you want and it'll just be skipped 2020-01-23 18:06:29 reidrankin, it breaks the solver in subtle ways 2020-01-23 18:07:25 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 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 SHA-1 for package identity is not a big deal 2020-01-23 18:09:47 so long as it's not the basis of the signatures 2020-01-23 18:09:52 ddevault, it is also the signature 2020-01-23 18:10:02 I know, but from my reading of the gitlab issue the two can be solved separately 2020-01-23 18:10:07 the signature one being easier 2020-01-23 18:10:47 ddevault, if index is used, the index sha1 is used instead of the per-package signature 2020-01-23 18:11:05 though, it probably would make sense to change that 2020-01-23 18:12:19 ddevault, your comment is incorrect. it is used to verify authenticity currently 2020-01-23 18:12:29 which makes it even more broken 2020-01-23 18:12:46 please correct/clarify in the ticket 2020-01-23 18:14:31 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 no, that's not where I want to go. 2020-01-23 18:15:39 fabled: anyhow, I think part of the problem is that we're overloading the term "apk format" 2020-01-23 18:16:10 reidrankin, if we fix the current format, we should drop the "verify identity" and always check signature 2020-01-23 18:16:43 and make the identity hash a true unqiue id 2020-01-23 18:16:50 what happens if you install an unsigned apk? 2020-01-23 18:17:05 --allow-untrusted 2020-01-23 18:17:18 right, but what goes in the db for that 2020-01-23 18:17:33 db does not currently contain signatures 2020-01-23 18:17:46 or you mean index? 2020-01-23 18:17:53 we can still calculate an unique id for it 2020-01-23 18:18:22 ok, help me out here for a sec 2020-01-23 18:18:45 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 first there's the general container format: multiple .tar.gz chunks 2020-01-23 18:20:01 apk files have zero or more signature chunks, which are tarballs containing only files starting with '.SIGN.' 2020-01-23 18:20:53 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 and the data section is everything else 2020-01-23 18:21:09 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 reidrankin, yes 2020-01-23 18:21:31 yeah that's a dumb format 2020-01-23 18:21:38 but can be fixed without dropping tar 2020-01-23 18:21:52 one trivial fix is detaching the signature from the package file, like arch does 2020-01-23 18:21:55 but there are other options, too 2020-01-23 18:22:31 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 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 can you clarify what the "manifest" refers to 2020-01-23 18:23:04 I can guess, but it's better not to 2020-01-23 18:23:09 ddevault, manifest = list of files, their hashes, etc. everything except the file data contents 2020-01-23 18:23:36 signing the whole tarball signs those details too 2020-01-23 18:23:46 but I understand what you're getting at 2020-01-23 18:23:54 so you did not read my original mai 2020-01-23 18:23:55 we use that general container format for several things: apks themselves, APKINDEXes, and scripts.tar 2020-01-23 18:23:55 mail 2020-01-23 18:24:01 I did read your original mail 2020-01-23 18:24:08 and have re-read the entire thread twice today 2020-01-23 18:24:49 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 apks typically contain a signature, control section with datahash element, and data section 2020-01-23 18:25:23 you're going to have to checksum the file contents to do that, right 2020-01-23 18:25:32 unless you're just verifying that all of the files are where they're supposed to be 2020-01-23 18:25:38 ddevault, manifest contains individual file checksums 2020-01-23 18:25:49 aye, and to verify the manifest matches reality you'll have to read and checksum individual files 2020-01-23 18:25:51 correct? 2020-01-23 18:26:07 yes 2020-01-23 18:26:21 APKINDEXes contain a signature section and a data section only 2020-01-23 18:26:22 but i cannot regenerate the tarball from system 2020-01-23 18:26:27 why's that? 2020-01-23 18:26:36 ddevault: compression 2020-01-23 18:26:46 you should sign the uncompressed tarball, naturally 2020-01-23 18:27:13 it does not give me enough precision on what mismatched 2020-01-23 18:27:22 what information is missing? 2020-01-23 18:27:23 and i cannot then verify individual files 2020-01-23 18:27:38 the latter is a good point 2020-01-23 18:28:06 also, there are elements in the tar header that are specific to what tar implementation created it 2020-01-23 18:28:17 ACTION shrugs 2020-01-23 18:28:22 we can assume that implementation is always apk 2020-01-23 18:28:28 scripts.tar contains no signature or control section (essentially just a bare tarball) 2020-01-23 18:28:32 there are good points for all of it, but the question is how to proceed 2020-01-23 18:28:42 I don't think it's reasonable to suggest tar can be used to _create_ apks 2020-01-23 18:28:50 and this is a weak point about alpine in general 2020-01-23 18:28:51 fabled: I have a grand master plan (TM) I've been thinking about 2020-01-23 18:28:53 we just do things 2020-01-23 18:29:00 we don't sit down and think them through before executing 2020-01-23 18:29:22 while we have had some wins doing this, we have had a lot of lossage too 2020-01-23 18:29:27 I'm designing a high-assurance embedded system and have basically the same set of requirements 2020-01-23 18:29:49 with the caveat that the whole thing needs to be checked on boot 2020-01-23 18:30:04 reidrankin, i kinda have the same requirement 2020-01-23 18:30:14 (i have the same requirement as well) 2020-01-23 18:30:15 i want to do full system audit from initramfs 2020-01-23 18:30:35 step #1: we replace the PKGINFO file with something new 2020-01-23 18:30:39 (i also have the requirement that i do not break any production systems with a package management fumble) 2020-01-23 18:30:39 probably binary 2020-01-23 18:30:43 I have a half written email for the list 2020-01-23 18:30:56 but I'm tired of updating my draft during ongoing discussions here 2020-01-23 18:31:06 lemme just post the relevant bits here: 2020-01-23 18:31:16 something with a manifest embedded in it, instead of the checksums being inside the data tarball like today 2020-01-23 18:31:17 https://paste.sr.ht/~sircmpwn/57850c03604122a115ba54837fd952dbda47b885 2020-01-23 18:32:28 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 step #2: have the checksums be sha256 merkle hashes 2020-01-23 18:33:57 specifically, hashes compatible with fs-verity or dm-verity 2020-01-23 18:34:39 step #3: change the way APKs are stored in the cache 2020-01-23 18:35:28 decompressing the control block doesn't really add much overhead, so that part's fine 2020-01-23 18:36:02 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 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 step #4: add some logic to apk_tar_parse to handle "exploded" APK files 2020-01-23 18:38:35 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 step #5: use the exploded APKs as a hardlink farm 2020-01-23 18:41:39 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 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 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 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 Exploded APKs with merkle checksums will make that very, very fast 2020-01-23 18:47:32 you start with an overlayfs instance with metacopy=on,index=on,redirect_dir=on 2020-01-23 18:48:07 with the cache as the lower directory and a blank tmpfs as the upper 2020-01-23 18:49:07 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 ddevault: yeah, i really didn't realize how long this would go 2020-01-23 18:50:16 that sounds like a completely new feature to me 2020-01-23 18:50:36 it seems to me like an alternative approach to what is already a large redesign 2020-01-23 18:51:01 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 I would rather not involve overlayfs for the general (i.e. sys install to disk) case 2020-01-23 18:51:37 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 well, he lost me at that point too 2020-01-23 18:52:44 but leveraging fs-verify for authenticity checks seems like a good idea to me 2020-01-23 18:52:54 it's not global 2020-01-23 18:52:57 and it keeps tar! 2020-01-23 18:52:59 global in what sense 2020-01-23 18:53:02 it totally is a new feature. probably several, but that bit is just the motivation 2020-01-23 18:53:03 but yes, IMA is also something i've been looking at 2020-01-23 18:53:08 i mean 2020-01-23 18:53:10 don't get me wrong 2020-01-23 18:53:12 have some sort of integration for that 2020-01-23 18:53:15 if we are doing a massive overhaul 2020-01-23 18:53:21 i would love to get rid of tar 2020-01-23 18:53:42 my question is 2020-01-23 18:53:50 whether a massive overhaul is a good idea or not 2020-01-23 18:53:58 it's not 2020-01-23 18:54:12 because a massive overhaul greatly increases the odds of a "4 AM phone call" 2020-01-23 18:54:13 but imo there's an incremental approach to improvements which can be shaken out of reidrankin's ideas 2020-01-23 18:54:17 and i get enough of those already 2020-01-23 18:55:13 ddevault, please submit alternative design that supports post-mortem security audit using asymmetric crypto 2020-01-23 18:55:45 can you write up a succinct list of requirements any design ought to fulfill 2020-01-23 18:55:46 and improves performance to scale to 100k packages 2020-01-23 18:55:50 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 rather than scattered throughout mailing list archives and IRC logs 2020-01-23 18:56:20 and gitlab issues! 2020-01-23 18:57:11 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 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 then the whole DB can be signed over 2020-01-23 19:00:46 (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 reidrankin, i'd like the DB to be just concatenation of signed-PKG manifests 2020-01-23 19:01:40 that would be ideal 2020-01-23 19:02:12 but it is true that most of the issues are solved by just fixing the index format 2020-01-23 19:02:37 the package format changes are to reduce attack surface 2020-01-23 19:02:46 and to reduce duplicate information inside it 2020-01-23 19:02:52 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 the .tar.gz concatenation has following issues for me: 2020-01-23 19:04:03 1. parsing it is fragile 2020-01-23 19:04:18 2. signature checking is done late and lot of code needs to be run before signature is checked 2020-01-23 19:04:42 3. tar headers duplicate manifest data 2020-01-23 19:04:57 4. tar format for certain constructs is complicated (e.g. long file names) 2020-01-23 19:05:21 all of the above have caused major issues in the past 2020-01-23 19:05:30 and the code that handles that is fragile 2020-01-23 19:06:20 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 what kind of things you look in it? 2020-01-23 19:06:36 the concern isn't the tar format 2020-01-23 19:06:44 the concern is that we are doing too much at one time 2020-01-23 19:06:47 ^ 2020-01-23 19:07:01 why not have a release where we have the new index format with current APKv2 packages 2020-01-23 19:07:07 and more specifically, I think that NIH has to be well justified 2020-01-23 19:07:12 if tar is suitable, tar should be used 2020-01-23 19:07:32 ddevault, it's not a tar. it's a "clever hack" that looks like tar currently 2020-01-23 19:07:33 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 for point 3 there, i'd argue that the tar shouldn't contain the data the manifest does 2020-01-23 19:07:59 and yes, fabled is right, apks are not really tars 2020-01-23 19:08:01 s/data the/data if the/ 2020-01-23 19:08:01 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 they just happen to be kind of readable by tar utility 2020-01-23 19:08:26 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 aye, I understand the current format 2020-01-23 19:09:17 all i am saying is this 2020-01-23 19:09:21 are there any distros who aren't using tar or cpio for their packages? out of curiosity 2020-01-23 19:09:24 is there prior art we can look at 2020-01-23 19:09:28 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 I love CPIO honestly 2020-01-23 19:09:45 ddevault: yes. the proposed format is quite similar to Conary's changeset format 2020-01-23 19:10:02 it is a good format 2020-01-23 19:10:07 i just think 2020-01-23 19:10:14 we have to support APKv2 packages anyway for upgrade 2020-01-23 19:10:20 like, period 2020-01-23 19:10:38 and therefore reusing the code if possible is wise? 2020-01-23 19:10:50 yes, APKv2 backwards compatibility for a release or two is something I hope to do 2020-01-23 19:11:13 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 there are millions of installs out there 2020-01-23 19:11:36 possibly billions 2020-01-23 19:11:43 with docker, who honestly knows 2020-01-23 19:12:04 let me rephrase 2020-01-23 19:12:05 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 at a minimum we should maintian backwards compatibility to support upgrades from $last_supported_release -1 2020-01-23 19:12:33 and really the concern is 2020-01-23 19:12:37 okay, we're talking about a new format 2020-01-23 19:12:43 but we're not talking about logistics 2020-01-23 19:12:44 my plan is that APKv2 package format would be readable, indexable and installable; but with certain limitations 2020-01-23 19:13:03 how do we upgrade from apk to apk3, what are the risks, how do we mitigate the risks 2020-01-23 19:13:21 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 i don't think APKv2 index needs to be supported 2020-01-23 19:18:07 but we need to be able to have APKv2 packages described with an APKv3 index 2020-01-23 19:18:20 then we have an APKv2 index beside it that describes the APKv2 packages 2020-01-23 19:18:30 then, later, we move to APKv3 packages 2020-01-23 19:18:30 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 (...i must not be using the right synax) 2020-01-23 19:19:32 !10670 2020-01-23 19:19:45 they're in apk-tools 2020-01-23 19:20:00 ah 2020-01-23 19:20:05 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 and by the way, thank you for writing those emails 2020-01-23 19:20:36 aye, these problems are important and I'm grateful that fabled is working on them 2020-01-23 19:21:14 i'm happy i finally have the opportunity. this has been ~5 yrs on the table 2020-01-23 19:21:26 and i'm very happy to talk more about it and adjust design as needed 2020-01-23 19:21:31 but i'd really like to reason it 2020-01-23 19:21:52 i'm happy to explain every suggestion i made if needed 2020-01-23 19:22:07 well, really, the problem isn't the design 2020-01-23 19:22:09 i just hope that if you have suggestions you also argument it 2020-01-23 19:22:12 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 the problem is the lack of a migration plan :p 2020-01-23 19:22:25 wasn't really on my radar at all 2020-01-23 19:22:37 i sort of have migration plan. i just have gotten publishing it :P 2020-01-23 19:22:38 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 not sure if it's perfect, or good enough 2020-01-23 19:22:44 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 :P 2020-01-23 19:23:04 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 i've been currently trying to describe where i want to end up 2020-01-23 19:23:48 and, it also raises the bar for proving the new design 2020-01-23 19:23:58 it's multiple commits. but not sure how many releases 2020-01-23 19:24:06 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 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 and obtaining proof of the design requires the crucible of production 2020-01-23 19:25:12 but i'm also trying to avoid interim file formats 2020-01-23 19:25:18 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 supporting X+1 fileformats is not good either 2020-01-23 19:25:34 i think we need to support X+1 file formats for package, but not index 2020-01-23 19:25:55 because in an upgrade 2020-01-23 19:25:56 supporting 2 is ok: APKv2 and APKv3. not sure if doing more than that is good 2020-01-23 19:26:05 that's all we need 2020-01-23 19:26:14 if anyone wants to go from APKv1 to APKv3, they are already doomed 2020-01-23 19:26:50 there's a few ways we can do it 2020-01-23 19:27:02 i can write another email covering those approaches and their pros/cons 2020-01-23 19:27:09 i have given it some thought 2020-01-23 19:27:19 me too 2020-01-23 19:27:20 do you want me to provision an apk-tools list? 2020-01-23 19:27:48 we have one already 2020-01-23 19:28:01 oh, and there it is 2020-01-23 19:28:01 we just don't use it because most users are also on alpine-devel 2020-01-23 19:28:14 because, adelie while not directly related to alpine, does share some APKBUILDs 2020-01-23 19:28:22 and some other things 2020-01-23 19:28:33 same with abyss 2020-01-23 19:28:57 the real question mark is yocto (who want to replace opkg with apk, i guess) 2020-01-23 19:29:07 we could Cc both 2020-01-23 19:29:18 look at that. maybe i should subscribe too 2020-01-23 19:29:38 i think i told you about it, but maybe i forgot to 2020-01-23 19:30:13 maybe i was. i was pretty distracted most of last year 2020-01-23 19:30:16 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 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 i think 2020-01-23 19:32:49 we should just let the current index be as it is 2020-01-23 19:32:52 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 and focus on APKv3 index first 2020-01-23 19:33:46 s/first/instad/ 2020-01-23 19:33:46 kaniini meant to say: and focus on APKv3 index instad 2020-01-23 19:33:51 s/instad/instead/ 2020-01-23 19:33:51 kaniini meant to say: and focus on APKv3 index instead 2020-01-23 19:36:54 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 yes, i think so 2020-01-23 19:37:51 and the changes to use the new index internally are somewhat extensive. even if mostly mechanical. 2020-01-23 19:37:55 because what we can do 2020-01-23 19:38:01 is run both index formats parallel 2020-01-23 19:38:13 and that gives us a safe escape hatch 2020-01-23 19:38:17 if something goes south :) 2020-01-23 19:39:28 system DB needs to be converted too 2020-01-23 19:40:05 ok 2020-01-23 19:40:08 i need to go sleep 2020-01-23 19:40:12 yes, but in a revert situation we just write a tool to convert it back 2020-01-23 19:40:21 true 2020-01-23 19:40:29 ok. let's follow up on mailing list 2020-01-23 19:41:00 maybe even summarize what was discussed here 2020-01-23 19:41:14 i will also write something tomorrow 2020-01-23 19:41:22 perhaps try to formulate a bit of roadmap 2020-01-23 19:42:21 thanks for this discussion! 2020-01-23 19:42:55 reidrankin, if you have fix for the manifest issue, I'd be happy to look at it tm 2020-01-23 19:46:33 fabled: i am writing an email about it already 2020-01-23 19:46:42 fabled: feel free to chime in tomorrow with your thoughts 2020-01-23 19:47:03 and thanks for the conversation, i think we have fleshed out a lot 2020-01-23 19:47:57 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 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 please write to ~alpine/apk-tools@lists.alpjnelinux.org and we can look into that 2020-01-23 19:48:55 But most of the convenience functions like apk_repository_update are in apk and not libapk 2020-01-23 19:49:23 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 i sent a new one 2020-01-23 20:06:16 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 https://lists.alpinelinux.org/~alpine/apk-tools/%3C43397dfce7287c7ea51d04ba0d47d81c%40dereferenced.org%3E 2020-01-23 20:08:06 its there 2020-01-23 20:08:08 :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 for my part I received that email 4 times 2020-01-23 20:20:12 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 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 s/is/are/ 2020-01-23 20:21:36 mps meant to say: ah, looks like two version are sent 2020-01-23 20:41:38 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 who is your email provider, Cogitri? 2020-01-23 20:41:57 and can you forward to me one of the emails which ended up in spam? 2020-01-23 20:42:07 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 I find them in there occasionally. I use migadu 2020-01-23 20:45:14 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 Sorry about that 2020-01-23 20:45:34 Thought I had dealt with the fallout of that by now 2020-01-23 20:45:37 yeah I originally sent email to user list 2020-01-23 20:45:43 by mistake 2020-01-23 20:45:51 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 did i miss something? 2020-01-23 21:43:53 <_ikke_> regarding what? 2020-01-23 21:44:06 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 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 looks like the biggest difference is that its now planned to first do the index. 2020-01-23 21:48:46 compared to fabled initial email 2020-01-23 22:10:38 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 (anybody know how to set the repo for algitbot references?) 2020-01-23 22:11:57 i dont think its possible 2020-01-23 22:12:39 that's it then, we gotta change over to a monorepo 2020-01-23 22:15:31 or just fix the bot 2020-01-23 22:15:51 in redmine all issues were global 2020-01-23 22:21:28 same in VSTS 2020-01-23 22:44:02 Could somebody please review !2125? 2020-01-23 22:48:56 Oh huh, somehow I missed that one completely 2020-01-23 22:49:00 Sorry about that 2020-01-23 22:49:05 Gonna look into it tomorrow 2020-01-24 06:19:09 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 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/2973#note_64649 2020-01-24 06:21:58 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 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 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 description says "with LAPACK" but uses NO_LAPACK=1 flag 2020-01-24 08:34:51 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 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 sigh, stupid fortran libraries 2020-01-24 08:40:42 and after disabling LAPACK it looks like I am now getting fails in the MatricesAccuracyTest 2020-01-24 08:40:45 can't win 2020-01-24 09:17:37 _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 any reason why gstreamer would be having issues opening videos on the CI? 2020-01-24 09:31:57 Maybe it needs a DISPLAY for that? 2020-01-24 09:32:23 anyone have objection #11158 to remove xchat 2020-01-24 09:32:23 I don't have the log but maybe xvfb-run does the trick? 2020-01-24 09:34:38 Cogitri, interesting idea, logs don't mention anything about DISPLAY hmm 2020-01-24 09:35:44 It's just my best guess without logs :) 2020-01-24 09:35:49 north1: ncopa: can the #11026 be closed 2020-01-24 09:38:54 GLib-ERROR **: 06:57:54.095: ../glib/gmem.c:105: failed to allocate 921683 bytes 2020-01-24 09:39:01 :/ 2020-01-24 09:39:38 So it's OOM? 2020-01-24 09:40:55 it could be 2020-01-24 09:41:04 https://gitlab.alpinelinux.org/russkel/aports/-/jobs/39977 2020-01-24 09:41:56 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 x86_64 passed this particular one 2020-01-24 09:43:18 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 that's very weird 2020-01-24 09:44:28 this is the x86_64 run: https://gitlab.alpinelinux.org/russkel/aports/-/jobs/39976 2020-01-24 09:44:41 errors due to an error I made with packaging order 2020-01-24 09:48:22 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 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 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 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 looks like gstreamer isn't finding the plugins 2020-01-24 13:20:12 nevermind, it needed gst-libav *facepalm* 2020-01-24 14:11:16 russkel: been there.... 2020-01-24 14:18:56 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 (I haven't seen any packages like that, but I haven't been looking...) 2020-01-24 14:20:10 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 for all intents and purpose, hexchat replaced xchat years ago :p 2020-01-24 14:32:20 kaniini: yes. but distro inertia keeps it (and not only it) 2020-01-24 14:32:44 i wonder if we should organize a sprint this weekend to "take out the trash" so to speak 2020-01-24 14:33:06 procmail, xchat, what else is in the same boat that needs to go? 2020-01-24 14:33:23 especially procmail. people have literally had 19 years to switch to something else. no sympathy. 2020-01-24 14:33:50 isn't procmail removed already? 2020-01-24 14:33:59 yes 2020-01-24 14:34:06 xchat is removed about 1-2 hours ago 2020-01-24 14:34:10 i am just saying, since there seems to be some inertia for removing crap 2020-01-24 14:34:17 we should identify other crap and remove it 2020-01-24 14:34:18 aha 2020-01-24 14:34:36 hmm 2020-01-24 14:34:49 gitlab MRs are not closed when imported into the repo? 2020-01-24 14:35:00 or am i doing it wrong 2020-01-24 14:35:03 no 2020-01-24 14:36:34 please tell me something is working on that :D 2020-01-24 14:36:48 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 i.e. same hash in MR and when push to aports 2020-01-24 14:38:14 but, yes, some people work hard to make this to work 2020-01-24 14:41:33 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 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 except I like outdated pkgs, of course if they don't have bugs :) 2020-01-24 14:54:06 unmaintained software is a significant liability 2020-01-24 14:55:17 unmaintained doesn't mean bad automatically 2020-01-24 14:55:42 no, but it is a potential liability 2020-01-24 14:55:59 yes 2020-01-24 14:56:13 procmail and xchat were liabilities, for example 2020-01-24 14:56:41 what i want to identify is unmaintained software which have had security incidents since last maintained 2020-01-24 14:56:49 so we can conclude what to do with them 2020-01-24 14:57:10 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 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 ofc, if it have non fixed sec flaws then it should be removed or moved to unmaintained 2020-01-24 14:58:29 ok, looks like we have similar POV on subject 2020-01-24 14:58:56 (but not python 2) 2020-01-24 14:59:02 (let us please just kill python 2) 2020-01-24 15:00:48 well, north1 work a lot on this, and he is not only one 2020-01-24 15:03:49 yes 2020-01-24 15:03:56 what can i do to help that along 2020-01-24 15:05:49 ask him, I don't know much about python 2020-01-24 15:06:27 I was working on this a lot too 2020-01-24 15:06:35 I drafted up a wiki page with some of the specifics 2020-01-24 15:06:44 ah, sorry I forgot your work 2020-01-24 15:06:46 https://wiki.alpinelinux.org/wiki/Python_package_policies 2020-01-24 15:07:23 lemme update this to drop the interim 2 & 3 packages policies 2020-01-24 15:07:36 how about this. 2020-01-24 15:07:49 lets try to kill python 2 this weekend 2020-01-24 15:07:51 :D 2020-01-24 15:08:20 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 updated wiki page to get rid of python 2 guidelines 2020-01-24 15:08:40 so all packages should just follow these guidelines going forward imo 2020-01-24 15:11:22 Makefile:43: /src/pl/plpython/regress-python3-mangle.mk: No such file or directory 2020-01-24 15:11:24 hmmmmm 2020-01-24 15:23:47 looks like s390x CI is stuck again 2020-01-24 15:32:55 wow 2020-01-24 15:33:01 telegram-desktop makes gcc segfault 2020-01-24 15:33:02 :D 2020-01-24 15:35:09 Yep 2020-01-24 15:35:14 I have an Mr to update it 2020-01-24 15:35:20 That is stuck there 2020-01-24 15:35:39 I just don't have the willpower too do it, specially since I'm visiting Cogitri 2020-01-24 15:35:52 Too->to 2020-01-24 15:46:54 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 agreed 2020-01-24 15:47:14 but I'd prefer to merge in the other direction 2020-01-24 15:47:23 I think a "policies" namespace is more versatile than an examples namespace 2020-01-24 15:47:34 good idea 2020-01-24 15:52:15 ncopa, do you want to c&p time64 discussion here for reference for others? 2020-01-24 15:52:29 hi dalias! i finally manage to lure you in here :) 2020-01-24 15:53:14 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 but basically, musl is fixing the y2038 problem 2020-01-24 15:53:51 this means that there are some breaking changes for 32 bit arches 2020-01-24 15:54:03 once we implement those, we may need to rebuild world 2020-01-24 15:54:41 and there is a number of open/unresolved issues identified by adelie (awilfox) and yocto/oe (khem) 2020-01-24 15:55:03 much of it is here https://wiki.adelielinux.org/wiki/Project:Time64 2020-01-24 15:55:22 adelie has resolved enough to build everything now 2020-01-24 15:55:32 there might be some bugs found still 2020-01-24 15:56:31 i wonder if we should coordinate this with the apk format change 2020-01-24 15:56:44 we may want rebuild everything in new format at some point 2020-01-24 15:57:56 hum 2020-01-24 15:58:09 musl 1.2 is scheduled for late january 2020-01-24 15:58:11 I follow this on #musl 2020-01-24 15:58:52 we need a plan how to deal with the upgrade in alpine 2020-01-24 15:59:11 I think rebuild world (offline) maybe is good idea 2020-01-24 15:59:20 yes, i think so too 2020-01-24 15:59:29 the challenge is that edge is a moving target 2020-01-24 15:59:56 true 2020-01-24 16:00:02 i think we will need to have a separate builder which builds it all from scratch 2020-01-24 16:00:23 maybe even builders for multiple arches 2020-01-24 16:00:54 what i didn't asked on musl, will we need never kernel with musl-1.2 2020-01-24 16:01:40 also things like xfs and ext3/4 is scary 2020-01-24 16:01:51 yes, noticed them 2020-01-24 16:04:42 whats scary about filesystem? 2020-01-24 16:05:12 mps, s/never/newer/ ? 2020-01-24 16:05:12 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 im afraid of rebuild of fsck tools and when running it it eats up the filesystem 2020-01-24 16:05:53 ncopa, :) 2020-01-24 16:06:45 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 dalias: newer, ofc :) 2020-01-24 16:07:21 mps, ok, then no, you don't need newer kernel 2020-01-24 16:07:35 but 5.4 lts is already in edge 2020-01-24 16:10:07 ok, its mostly fear, uncertainity and doubt from my side :) 2020-01-24 16:10:08 ah, yes, musl-1.2 will not be backported to older releases 2020-01-24 16:10:19 mps: its a challenge even for edge 2020-01-24 16:10:28 alpine releseas, I mean 2020-01-24 16:10:35 indeed i don't see why you'd want to backport 2020-01-24 16:10:49 you could backport bugfixes of course 2020-01-24 16:10:54 once its pushed to edge, we may need to rebuild world 2020-01-24 16:10:59 at least on 32 bit arches 2020-01-24 16:11:01 some people keep old kernels even on 3.11 2020-01-24 16:11:12 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 mps, *nod*. that's fine, it will work 2020-01-24 16:11:41 there's no change in kernel requirements with musl 1.2 2020-01-24 16:13:15 then it is better than I thought 2020-01-24 16:13:54 so i think the only thing we need to do is rebuild world on armv7 and x86 2020-01-24 16:14:14 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 i suppose we should set up builders for those soonish and start build from scratch 2020-01-24 16:14:40 maybe we should set up a builder like we do for new stable releases 2020-01-24 16:15:08 if we have resources could be good idea 2020-01-24 16:15:36 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 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 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 i guess maybe there could be an aports branch just for musl package to be different 2020-01-24 16:16:20 but that's about it 2020-01-24 16:17:56 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 like the patch for gcc 2020-01-24 16:18:30 sure, this is first one 2020-01-24 16:18:55 btw there's another important gcc patch you need to apply 2020-01-24 16:18:58 wrong-codegen 2020-01-24 16:19:18 https://wiki.adelielinux.org/wiki/Project:Time64 2020-01-24 16:19:19 oops 2020-01-24 16:19:21 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93402 2020-01-24 16:19:37 mcm has the patch from the bz; final in gcc git master is same 2020-01-24 16:19:37 dalias: iiuc, this is not related to musl? 2020-01-24 16:19:42 it's not related to musl 2020-01-24 16:19:58 just a gcc regression since 6.x resulting in wrong codegen for struct returns 2020-01-24 16:20:10 yes, I saw it 2020-01-24 16:28:41 i filed https://gitlab.alpinelinux.org/alpine/aports/issues/11161 so i dont forget. Thanks! 2020-01-24 16:34:39 I'm preparing this gcc codegen patch and will test it this night 2020-01-24 17:43:43 nice, adelie linux have time64 for some packages 2020-01-24 18:39:01 mps, "have time64" in what sense? you mean patches for the bugs found? 2020-01-24 18:39:25 btw re: gcc codegen patch, i've tested it with mcm and it fixes the bug 2020-01-24 18:39:42 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 reidrankin, the .dummy files do exists, and they are needed. 2020-01-24 19:20:37 dalias: yes, patches which fixes time64 'bugs' in packages 2020-01-24 19:22:59 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 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 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 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 what fails? 2020-01-24 20:14:15 test example.c 2020-01-24 20:14:30 build gcc 9.2 went fine 2020-01-24 20:14:48 i posted the link on https://gitlab.alpinelinux.org/alpine/aports/issues/11161 2020-01-24 20:14:55 the patch 2020-01-24 20:15:00 oh sorry no 2020-01-24 20:15:04 that was the time64 one 2020-01-24 20:15:07 just a sec 2020-01-24 20:15:27 ok 2020-01-24 20:15:52 https://github.com/richfelker/musl-cross-make/blob/master/patches/gcc-9.2.0/0017-pr93402.diff 2020-01-24 20:16:26 example.c from bug report fails when built with -fno-inline in my test 2020-01-24 20:19:19 here's what i get with the patch applied: http://ix.io/28er 2020-01-24 20:19:23 notice the addq 2020-01-24 20:20:09 aha 2020-01-24 20:20:22 i'm not even running it or caring about inlining 2020-01-24 20:20:29 ok, looks like I 'overworked' patch 2020-01-24 20:20:31 i was just looking at the extern function definition's asm 2020-01-24 20:20:37 what did you do to it? :) 2020-01-24 20:20:42 remove the actual patch body? :-p 2020-01-24 20:20:49 and just keep the testcase? :-p 2020-01-24 20:21:00 forgot to remove some parts 2020-01-24 20:21:49 here is it http://tpaste.us/gkjy 2020-01-24 20:23:57 fixed ver? 2020-01-24 20:26:12 ? 2020-01-24 20:26:26 sorry, don't understand 2020-01-24 20:28:06 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 if I build example.c without -fno-inline it works 2020-01-24 20:30:49 s/needed/not needed/ 2020-01-24 20:30:49 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 mps, what goes wrong with -fno-inline ? 2020-01-24 20:35:14 here is generated asm http://tpaste.us/evKp 2020-01-24 20:36:06 and I get: Assertion failed: output.b == 122222222222 (example.c: main: 23) \n Abort 2020-01-24 20:41:34 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 btw, I'm building it native 2020-01-24 20:43:13 x86_64 2020-01-24 20:53:36 hmm, ok going from scratch again 2020-01-24 20:58:39 huh, why the asm output from gcc doesn't have alpine gcc pkgrel :) 2020-01-24 20:59:00 I need some walk 2020-01-24 21:03:09 https://sr.ht/q_g8.jpg 2020-01-24 21:03:11 braille terminal I picked up 2020-01-24 21:07:58 i have one of those 2020-01-24 21:08:06 it belonged to my dad 2020-01-24 21:11:00 mps, that looks like it was compiled without the patch 2020-01-24 21:11:03 are you sure you used the new gcc? 2020-01-24 21:11:30 dalias: that is 2020-01-24 21:12:06 i wrote '21:58 ............. mps| huh, why the asm output from gcc doesn't have alpine gcc pkgrel :)' 2020-01-24 21:12:38 when I noticed that 2020-01-24 21:13:57 multitasking at work 2020-01-24 21:16:51 mps, here is generated asm http://tpaste.us/evKp 2020-01-24 21:17:13 so i guess you were using the wrong gcc? :) 2020-01-24 21:17:53 you are right 2020-01-24 21:18:47 but build box works again, because I deleted previous patched version, huh :) 2020-01-24 21:18:57 that's a life 2020-01-24 21:31:15 am I doing something stupid here in the APKBUILD: 2020-01-24 21:31:17 mv: cannot stat '/home/builder/package/pkg/opencv/usr/lib/libopencv_video*.so.*': No such file or directory 2020-01-24 21:31:32 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 I thought that only applied for ' 2020-01-24 21:38:05 ACTION facepalms 2020-01-24 21:38:07 thanks mate 2020-01-24 22:14:48 dalias: works fine 2020-01-24 22:15:19 next time I have to check did I really upgraded gcc 2020-01-24 22:15:31 :) 2020-01-24 22:15:55 all test passed 2020-01-24 22:16:30 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 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 woo opencv is compiling on x86_64 and aarch64 2020-01-24 22:17:01 opencolorio is broken right now because of some stupid abi break in yaml-cpp 2020-01-24 22:17:11 dalias: not that I know how to do this 2020-01-24 22:17:13 but this kind of thing happens *all the time* :( 2020-01-24 22:17:34 and passing tests =) 2020-01-24 22:17:43 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 and tell you if any of them broke 2020-01-24 22:18:27 so, scanelf can't find needed deps? 2020-01-24 22:18:27 and in the other direction, i'm not sure how it would work without keeping around old libs 2020-01-24 22:19:58 probably something that could be implemented into CI 2020-01-24 22:20:24 mps, there are 2 problems that can happen 2020-01-24 22:20:25 we usually rebuild pkgs 'by hand' if we know for abi breaks 2020-01-24 22:20:40 1. B depends on A, and after upgrade of A, A no longer has symbols B needs 2020-01-24 22:20:48 this usually happens for idiotic C++ template reasons 2020-01-24 22:21:27 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 yes 2020-01-24 22:21:43 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 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 just to force their version bumps 2020-01-24 22:22:28 that is 2020-01-24 22:23:08 well, advice is 'upgrade all to latest version in current repo' 2020-01-24 22:23:32 though this sounds as not quite 'fine' advice 2020-01-24 22:24:44 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 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 apk add -u -d 2020-01-24 22:25:06 because the servers are so slow the latter takes forever 2020-01-24 22:25:18 does it work? i can't even get apk add -u to work 2020-01-24 22:25:25 if i have libfoo and libfoo-dev installed 2020-01-24 22:25:30 apk add -u libfoo does *nothing* 2020-01-24 22:25:30 actually 'fix -d' 2020-01-24 22:25:39 because libfoo-dev holds it back to the matching version 2020-01-24 22:25:49 and the upgrade of libfoo doesn't push an upgrade of the libfoo-dev 2020-01-24 22:26:21 well, in most cases 'apk add -u pkgname' works 2020-01-24 22:26:37 basically having any -dev packages installed hoses the whole apk upgrade system 2020-01-24 22:27:09 yes, in such cases i do 'apk add -u $pkgname-dev' 2020-01-24 22:28:38 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 suppose i want apk add -u appfoo 2020-01-24 22:28:59 right 2020-01-24 22:29:02 and appfoo depends through some giant dep chain on libbar 2020-01-24 22:29:06 and i have libbar-dev installed 2020-01-24 22:29:16 now i have to figure out that libbar-dev is why i can't apk add -u appfoo 2020-01-24 22:29:19 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 'apk info -R pkgname' could help 2020-01-24 22:30:20 i just wish it just worked 2020-01-24 22:31:00 understand 2020-01-24 22:31:00 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 maybe new apk version will be better at this 2020-01-24 22:31:24 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 killer* 2020-01-24 22:31:50 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 you have to apply for 'Alpine developer' position :) 2020-01-24 22:32:40 :-p 2020-01-24 22:33:04 that's how I learned some hard parts and corner cases 2020-01-24 22:34:07 wait what, ffmpeg on 32b systems is limited to 2GB RAM? 2020-01-24 22:34:09 but back to serious, new apk will try to solve some issues 2020-01-24 22:34:47 russkel, in what sense? 2020-01-24 22:35:12 dalias, opencv FFMPEG tests are failing on x86 due to running out of RAM errors 2020-01-24 22:35:20 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 maybe because of memory split 2/2gb 2020-01-24 22:35:29 despite the CI has 60gb 2020-01-24 22:36:04 I thought to change kernel config to 3G/1G 2020-01-24 22:36:23 any single allocation is also going to be limited to 2gb, even if more is available total 2020-01-24 22:37:01 (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 I see 2020-01-24 22:39:16 _ikke_: are you around? 2020-01-24 22:39:37 ahh the test is called "videoio_ffmpeg.write_big" 2020-01-24 22:39:53 it should really be skipping this test then 2020-01-24 22:40:05 <_ikke_> mps: yes 2020-01-24 22:40:37 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 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 but I'm not in a hurry 2020-01-24 22:42:54 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 I think so 2020-01-24 22:44:39 but not sure 2020-01-24 22:45:10 gcc-gnat depends on gcc 2020-01-24 22:45:30 <_ikke_> yeah, just noticed 2020-01-24 22:46:19 https://gitlab.alpinelinux.org/russkel/aports/-/jobs/40124#L4278 2020-01-24 22:47:14 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 it would be wrong to add 'apk add gcc-gnat' in gcc prepare function, I think 2020-01-24 22:47:39 well doesn't fail, but skips after hitting an exception 2020-01-24 22:47:42 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 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 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 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 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 yes 2020-01-24 23:00:01 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 Ada hmm 2020-01-24 23:07:19 Let's not :P 2020-01-24 23:07:31 <_ikke_> Cogitri: I'd agree 2020-01-24 23:10:25 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 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 ahhh common denominator is tiff on s390x 2020-01-24 23:12:20 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 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 why can't we all just use x86_64 ;) 2020-01-25 01:37:44 just sent my first set of accessibility patches to the aports list, blindfolded :D 2020-01-25 01:42:08 ddevault: http://tpaste.us/ky77 2020-01-25 01:43:48 mps: can you phrase that in the form of a reply on the list 2020-01-25 01:44:12 to late, already pushed :) 2020-01-25 01:44:22 ACTION shrugs 2020-01-25 01:44:52 I also sent a patch for mkinitfs which turns on the braille reader during early boot 2020-01-25 01:45:02 https://lists.alpinelinux.org/~alpine/devel/patches/3236 2020-01-25 01:45:12 yes, I see it 2020-01-25 01:45:55 but liblouis fails on builder, fails on test 2020-01-25 01:47:50 and it passed on my local machine, strange 2020-01-25 01:48:58 some deps that i have installed probably missing in APKBUILD 2020-01-25 01:56:33 ack 2020-01-25 01:59:03 help2man and python 2020-01-25 01:59:33 eating dinner now, will send a fixup patch after that 2020-01-25 01:59:55 https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/liblouis 2020-01-25 02:00:13 buon appetito 2020-01-25 02:23:21 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 I sent a patch that adds the missing makedepends 2020-01-25 02:26:19 I see 2020-01-25 02:28:06 also fail on check 2020-01-25 02:28:15 bah 2020-01-25 02:28:32 I wonder why it worked on my local box 2020-01-25 02:28:45 let's just disable the check, then 2020-01-25 02:28:46 we know the package works fine 2020-01-25 02:29:13 agree 2020-01-25 02:29:30 patch sent 2020-01-25 02:30:02 oh, license is not SPDX compliant 2020-01-25 02:30:39 oh, I thought newapkbuild linted that for you 2020-01-25 02:31:16 it didn't but abuild give me warning 2020-01-25 02:32:32 yet another patch is out 2020-01-25 02:32:38 thanks for your patience and help 2020-01-25 02:36:41 np 2020-01-25 02:36:50 lets try on clean box 2020-01-25 02:37:31 btw, you don't need to bump pkgrel if it not passed official builders 2020-01-25 02:37:46 oh, was unsure 2020-01-25 02:39:06 np 2020-01-25 02:39:24 also I sometimes make similar mistakes 2020-01-25 02:40:13 pushed as one commit and 'amended' msg somewhat 2020-01-25 02:40:38 oh god that brltty issue, how did I miss that 2020-01-25 02:40:56 I mean, probably because I was literally blind 2020-01-25 02:41:11 really? didn't know 2020-01-25 02:41:48 yeah the two original commits were written blindfolded 2020-01-25 02:41:52 iirc, you told me that you are astronomer 2020-01-25 02:42:07 amateur astronomer 2020-01-25 02:42:16 yes, I remember 2020-01-25 02:42:37 so you are not blind, I think 2020-01-25 02:42:47 I was blind_folded_ while working on these packages 2020-01-25 02:43:06 ah, ok 2020-01-25 02:44:07 I usually dogfood things to prove that they're correct 2020-01-25 02:44:32 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 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 heh, understand now 2020-01-25 02:46:39 for someone new to 'blind world' not bad :) 2020-01-25 02:52:12 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 they're very expensive 2020-01-25 02:52:39 I got this one used, in mediocre condition, for $200, and it was a steal 2020-01-25 02:52:53 oh 2020-01-25 02:53:03 they'll usually run closer to 2 grand 2020-01-25 02:53:35 hm, much to dear to be blind 2020-01-25 02:54:00 s/to/too/ 2020-01-25 02:54:00 mps meant to say: hm, much too dear to be blind 2020-01-25 03:02:13 there are free screen readers 2020-01-25 03:09:10 tested locally and pushed your fixes for brltty 2020-01-25 03:10:09 thank you mps 2020-01-25 03:10:38 hm, ppc64le don't have 'outb' 2020-01-25 03:11:33 'in function `readPort1': undefined reference to `inb'' 2020-01-25 03:11:48 ddevault: np 2020-01-25 03:12:11 it passed all other arches 2020-01-25 03:58:31 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 ddevault: does that hook into the linux vt device to read it out loud? 2020-01-25 08:37:26 ah, the braille outputter someone posted yesterday 2020-01-25 08:57:18 _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 window, hexchat, underscore ikke russkel what ive heard 2020-01-25 08:59:56 <_ikke_> ? 2020-01-25 09:00:15 my impersonation of a screen reader 2020-01-25 09:00:22 <_ikke_> haha :D 2020-01-25 09:00:56 always wondered how that works 2020-01-25 09:01:26 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 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 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 _ikke_ meant to say: I guess you would use grep-likes a lot 2020-01-25 10:37:35 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 ^7heo: your conclusion is right 2020-01-25 10:46:41 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 'use source Luke' 2020-01-25 10:47:37 :) 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: would be nice if you don't 'touch' aports ML :) 2020-01-25 11:07:51 _ikke_: I would, but whenever I post anything to alpine MLs I feel irritated (you know why) 2020-01-25 11:08:29 and I want to be calm as much as possible 2020-01-25 11:09:28 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 and brltty use direct I/O, i.e. inb and outb 2020-01-25 11:12:22 the mkinitramfs repository isn't available on gitlab, is it? 2020-01-25 11:12:53 nmeum: it is, I think, mkinitfs 2020-01-25 11:13:11 <_ikke_> I cannot find it 2020-01-25 11:13:11 yes, it is there 2020-01-25 11:13:40 I am too stupid to find it 2020-01-25 11:13:44 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 hm, how I found it, can't remember 2020-01-25 11:14:40 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 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 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 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 nmeum: pigz as default for gzip 2020-01-25 11:19:26 mps: that's what the change does, yeah. if pigz is installed it is prefered over gzip 2020-01-25 11:19:39 we have something similar in abuild already 2020-01-25 11:19:55 yes, nice fix 2020-01-25 11:20:40 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 so you are ok with me pushing it? 2020-01-25 11:21:19 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 yep 2020-01-25 11:21:38 <_ikke_> So impact should be minimal 2020-01-25 11:21:47 yep 2020-01-25 11:21:53 and it's totally optional 2020-01-25 11:22:15 <_ikke_> Should be fine then, I guess 2020-01-25 11:22:19 ok 2020-01-25 11:22:30 will just do a quick reboot to ensure that it's decompressed correctly 2020-01-25 11:22:43 if so, I will just push it 2020-01-25 11:32:42 seems to work, pushed the change 2020-01-25 11:37:22 ^7heo: docker-abuild can support multiple arches 2020-01-25 11:37:30 <^7heo> clandmeter: noted. 2020-01-25 11:37:35 via qemu-user 2020-01-25 11:37:38 <^7heo> ok 2020-01-25 11:37:52 its okish if you dont want to build world 2020-01-25 11:38:15 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 have you looked at sr.ht ci? 2020-01-25 11:41:57 <^7heo> no. 2020-01-25 11:42:01 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 qemu-static really is magic, especially in combination with binfmt_misc 2020-01-25 11:53:20 yes its pretty decent 2020-01-25 11:53:52 i was surprised about the performance compared to system qemu 2020-01-25 12:27:39 wait, what's the difference between system qemu and qemu-static? 2020-01-25 12:30:05 qemu-static is good to run in chroots 2020-01-25 12:32:50 ah so it's exactly what it says on the box 2020-01-25 12:33:07 qemu with everything statically linked 2020-01-25 12:33:30 except libc 2020-01-25 12:34:32 it doesn't emulate hardware and I presume because that it is faster 2020-01-25 12:35:07 didn't used it for few years so I forgot details 2020-01-25 12:35:21 by hardware you mean things like ethernet etc? 2020-01-25 12:35:29 yes 2020-01-25 12:35:44 indeed 2020-01-25 12:36:07 I was quite impressed I was able to cross compile by running a slightly different docker command 2020-01-25 12:36:20 you can run 'qemu-arm program' on other archs for example 2020-01-25 12:37:18 again, I forgot details 2020-01-25 12:38:42 qemu static as in qemu-user context, qemu-user-static 2020-01-25 12:42:23 debian have debootstrap-qemu package which can be used to create chroot for different arch 2020-01-25 12:58:05 _ikke_: did you come to idea about adding gcc-gnat to CI boxes 2020-01-25 13:02:57 AinNero: not yet, but that's one of my next steps 2020-01-25 13:16:04 mps: you need it for gcc? 2020-01-25 13:21:11 clandmeter: yes 2020-01-25 13:22:25 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 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 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 I'm not particularly interested in posix 2020-01-25 13:26:31 Unless it suits my needs 2020-01-25 13:26:39 <^7heo> yeah I know 2020-01-25 13:26:49 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 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 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 amove path 2020-01-25 15:15:09 <_ikke_> yeah, I figured it out 2020-01-25 15:15:18 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 It is very early so some stuff might chance 2020-01-25 15:16:02 I have an MR to provide default functions for the shell completion 2020-01-25 15:16:10 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 and I don't yet have a good design in mind for include directives in scdoc 2020-01-25 15:16:30 ddevault, it's done already for the global options 2020-01-25 15:17:07 meh 2020-01-25 15:17:10 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 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 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 I pushed !3344 but it will fail 2020-01-25 15:28:27 it is there for review, and maybe someone will build it locally to test it more 2020-01-25 15:29:14 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 thanks! 2020-01-25 15:33:17 do we have CI labels descriptions somewhere 2020-01-25 15:33:42 <_ikke_> Nope 2020-01-25 15:35:55 S-CI-Issue is for CI problems? 2020-01-25 15:36:06 <_ikke_> Yes 2020-01-25 15:36:26 in particular case, it don't have gcc-gnat installed 2020-01-25 15:36:43 s/it/they/ 2020-01-25 15:36:43 mps meant to say: in particular case, they don't have gcc-gnat installed 2020-01-25 20:28:54 I ran into a problem with the brltty work 2020-01-25 20:29:27 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 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 I'm looking into what would be required to fork the project 2020-01-25 20:34:02 hmmm 2020-01-25 20:34:50 don't agree, as pkg maintainers we have to communicate with a 'different' persons 2020-01-25 20:35:17 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 but, ofc, you are free to not 2020-01-25 20:35:54 yes, I know there are some not 'fine' people :) 2020-01-25 20:35:55 I mean, heck, we could just cite the code of conduct 2020-01-25 20:36:26 please post me a link 2020-01-25 20:36:36 sent PM 2020-01-25 20:37:29 ah, I see :) thanks 2020-01-25 20:38:02 actually I saw it earlier, can't remember exact time when 2020-01-25 21:02:26 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 ddevault, make the fork name... ittybitty 2020-01-26 09:24:04 hmm, just read that llvm built Debug is not ABI compatible with Release build. 2020-01-26 09:24:54 brave new world^Wtools 2020-01-26 10:36:40 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 does anyone have advice about the s390x CI job? 2020-01-26 10:39:50 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 ScrumpyJack: do you use arandr on edge? 2020-01-26 10:50:38 it seems to have a problem with py3-gobject3 2020-01-26 11:01:34 ah got it fixed, patch incoming 2020-01-26 11:03:03 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 Cogitri: thanks! 2020-01-26 11:04:43 uhm, arandr had a unspecified depencendy on py-cairo 2020-01-26 11:05:04 arandr has a runtime dep on py-gobject, which has py-cairo as build-time dependency 2020-01-26 11:05:29 i dont know if py-cairo is needed as runtime dependency of py-gobject 2020-01-26 11:08:29 ping Cogitri ^ 2020-01-26 11:19:18 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 otherwise i'll make a MR on adding it as dependency on arandr 2020-01-26 11:20:42 that will make it work 2020-01-26 11:50:14 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 *or 2020-01-26 11:53:33 I believe I just made that since lot of stuff hardcoded -3 on their scripts 2020-01-26 11:55:39 yep, that's what I am fixing currently 2020-01-26 11:58:03 Feel free then 2020-01-26 12:06:02 Cogitri: sorry for the double notification 2020-01-26 12:06:26 this was my first MR with gitlab, and i promptly mis-targeted it into my own staging tree 2020-01-26 12:07:08 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 Nice 2020-01-26 12:07:55 Currently travelling in Kiel with Cogitri, will check when I get home. 2020-01-26 12:11:36 are you guys actually from germany or just visting? 2020-01-26 12:11:56 I'm just visiting, Cogitri is German 2020-01-26 12:12:30 ah, I also live in northern germany 2020-01-26 12:12:44 anyway: have fun :) 2020-01-26 12:13:13 Thanks :) 2020-01-26 12:13:21 Ty 2020-01-26 12:25:15 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 I suppose you can give it another try 2020-01-26 13:20:45 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 ikke: thank you, that explains it 2020-01-26 13:47:26 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 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 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 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 yes, we would mind 2020-01-26 15:36:51 this channel is already exposed to matrix 2020-01-26 15:38:07 kaniini: where? 2020-01-26 15:38:13 that's even better 2020-01-26 15:38:20 the usual way freenode is bridged to matrix 2020-01-26 15:39:40 As long as it is seamless 2020-01-26 15:40:07 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 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 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 yes 2020-01-26 15:42:11 *testing* 2020-01-26 15:42:36 hmm... seems to either not working at all or not at the moment 2020-01-26 15:42:56 The matrix.org bridge is down at times, yes 2020-01-26 15:43:07 And usually kinda slow 2020-01-26 15:43:33 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 nmeum: what is status of !4 2020-01-26 17:43:40 algitbot: ? 2020-01-26 17:44:08 https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4 RFC: Alternative codestyle document 2020-01-26 18:17:42 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 ah, ok. I agree that is superior and want sometimes to cite it 2020-01-26 18:19:23 maybe I should add comment and ask you to push it :) 2020-01-26 18:19:59 There are a few things to change 2020-01-26 18:20:04 this kind of change probably requires more than one ack though 2020-01-26 18:20:08 and even my version could need some updates 2020-01-26 18:20:10 But overall I agree it is better 2020-01-26 18:20:10 <_ikke_> yup 2020-01-26 18:20:32 nice 2020-01-26 18:21:02 everything could be better, ofc, but perfect is enemy of good 2020-01-26 18:21:27 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 I'll just comment on it when I have the time 2020-01-26 18:22:06 sure 2020-01-26 18:22:14 Currently in Hbf waiting for bus 2020-01-26 18:23:27 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 kernel 5.4.15 2020-01-26 18:24:06 mps: yeah I think I'm going to miss the 9 hour deadline 2020-01-26 18:24:39 ah, probably will be tomorrow in repo 2020-01-26 18:25:07 Alright but I didn't have the locks anymore 2020-01-26 18:25:14 So I guess the backport worked 2020-01-26 18:26:22 not sure it works fine and the bug is fixed 2020-01-26 18:27:00 I think bug is not fixed in just released 5.4.15 even, but it looks more responsive 2020-01-26 18:27:22 now I will reboot and see 2020-01-26 18:40:51 nmeum: Gave !4 it a look, I definitely much prefer it to what we currently have 2020-01-26 18:47:32 great, hopefully it can be merged at some point 2020-01-26 19:50:48 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 Well, users won't be downgraded by default, only if they do `apk upgrade -a` 2020-01-26 20:03:18 ACTION using that flag everytime when upgrade... 2020-01-26 20:04:13 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 after that article I enabled pigz in mkinitfs :D 2020-01-26 20:07:17 andypost[m]: I don't have strong opinion, but I think downgrade version shouldn't be done 2020-01-26 20:08:12 MY-R: how much seconds you save 2020-01-26 20:08:39 mps: yep, but thought that after 9 years there will be 1.1) 2020-01-26 20:09:23 mps, didnt even measure it but for sure it used all cores of cpu, will check now 2020-01-26 20:09:26 well, I was not clear, I'm not against especially in this corner case 2020-01-26 20:09:38 andypost[m]: ^ 2020-01-26 20:11:57 and, in that case I would probably downgrade it, I don't see other solution 2020-01-26 20:13:26 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 mps, from 1 minute to 25 seconds, measured twice and dropped cache before every test 2020-01-26 20:17:58 and how often you make initfs 2020-01-26 20:18:18 lately prety often, playing with kernels... 2020-01-26 20:18:42 ok 2020-01-26 20:19:03 but it is already added to mkinitfs in this commit: https://git.alpinelinux.org/mkinitfs/commit/?id=59204d36985de5ba2444d5f3e0d50a119287ec51 2020-01-26 20:19:56 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 yes, I remember MR, someone asked for review and I acked it 2020-01-26 20:25:05 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 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 and I'm not against this 2020-01-26 20:28:29 just wanted to hear your experience and use cases 2020-01-26 20:29:13 maybe not in quite clear and polite words 2020-01-26 20:30:06 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 ofc, we want alpine to be fast 2020-01-26 20:32:10 so in general Im glad! :> 2020-01-26 22:46:57 ACTION wonder how many times package something and after that find it in aports, huh :) 2020-01-27 00:51:58 @ollieparanoid I'll check the pmbootstrap MR tomorrow 2020-01-27 07:58:27 hello guys 2020-01-27 07:58:50 I wanted to add consolefont support into mkinitfs so started patching the initramfs-init script 2020-01-27 07:59:13 however, even though tty is working (as cryptsetup ask passwords), setfont complains that /dev/tty does not exist 2020-01-27 07:59:41 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 Interesting 2020-01-27 16:39:00 hah? 2020-01-27 16:39:30 ACTION always had aversion to qt 2020-01-27 16:41:05 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 looks like it is 2020-01-27 16:42:32 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 huh, who knows 2020-01-27 16:45:55 maybe we have to prepare $499/year :) 2020-01-27 16:55:27 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 I'm back 2020-01-27 19:52:09 Is there anything that needs my attention ? 2020-01-27 19:52:21 @ollieparanoid checking pmbootstrap in a few minutes 2020-01-27 19:53:32 north1: \o 2020-01-27 19:56:00 o/ 2020-01-27 19:59:24 @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 north1: thanks! \o/ 2020-01-27 20:30:24 welcome 2020-01-27 20:49:57 @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 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 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 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 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 _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 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 Can we have a package that provides /var/lib/machine-id ? 2020-01-27 22:53:18 ever since the dbus post-install was changed to not generate it a lot of tests are failing 2020-01-27 23:20:42 @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 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 ap revdep? 2020-01-28 08:22:14 <_ikke_> lua-aports 2020-01-28 09:17:01 hello, mkinitfs don't have a repository in gitlab yet? 2020-01-28 09:17:43 nope 2020-01-28 09:17:44 markand: git.a.o 2020-01-28 09:17:55 we should add it 2020-01-28 09:18:25 clandmeter: +1 2020-01-28 09:18:53 we can run an import from github 2020-01-28 09:19:48 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 aha, understand 2020-01-28 09:25:03 and github is still in sync with git.a.o? 2020-01-28 09:33:59 north1: there are some drama going on, on the mailing list, due to the removal of gtkglext (a783b166c89892e91bff2e0d3d76eb2fed7c67b0) 2020-01-28 09:34:57 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 ah good 2020-01-28 09:35:12 i was searching for it 2020-01-28 09:35:18 That sure is a nice mail :^) 2020-01-28 09:35:20 epic 2020-01-28 09:37:27 gtkglext is deprecated anyway 2020-01-28 09:40:56 Yup, at this point I'd just let the user maintain the thing themselve... 2020-01-28 09:41:06 well we can add to community 2020-01-28 09:41:36 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 starting to become a thing 2020-01-28 09:41:52 I just find it nice that i made that "breaking" change in November and nobody complained 2020-01-28 09:42:42 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 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 he then answered “oh you prefer silence? wait forever!” 2020-01-28 10:04:53 is anyone in here at fosdem this weekend? 2020-01-28 10:06:14 i think @Cogitri will be 2020-01-28 10:06:21 also, i'm hesitant to answer him on the mailing list 2020-01-28 10:06:56 you can tell him that gtkglext is deprecated 2020-01-28 10:07:05 in Arch Linux over all pacakges, only 7 require it 2020-01-28 10:07:12 Do you have a link for it ? 2020-01-28 10:07:19 would be nice to provide a source in-hand 2020-01-28 10:10:30 https://www.archlinux.org/packages/extra/x86_64/gtkglext/ here's the list of consumers 2020-01-28 10:10:47 homepage is self explanatory : https://projects.gnome.org/gtkglext 2020-01-28 10:11:13 north1: i responded. removing it was the right thing to do 2020-01-28 10:11:27 he has absolutely no right to demand anything from us 2020-01-28 10:11:57 its gtk2 only so getting rid of it is progress 2020-01-28 10:12:05 yep 2020-01-28 10:12:06 oh 2020-01-28 10:12:08 thank you 2020-01-28 10:12:19 gimp is still my last app running in gtk 2 :( 2020-01-28 10:12:36 north1: thank you for helping us clean up the aports tree. It is appreciated 2020-01-28 10:12:46 telmich: Yup, I'll be at FOSDEM 2020-01-28 10:13:13 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 i wish i could go to FOSDM as well, but I can't :-( 2020-01-28 10:13:33 same 2020-01-28 10:13:43 two other family things on the same day.. 2020-01-28 10:13:46 maybe next year 2020-01-28 10:14:07 I wish too :( 2020-01-28 10:14:14 then we will open a very big alpine stand 2020-01-28 10:14:50 Couldn't go, will go watch basketball game in Ludwigsburg instead :D 2020-01-28 10:15:23 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 thanks ncopa 2020-01-28 10:17:25 Thanks for dealing with that, ncopa 2020-01-28 10:18:34 telmich: Ah, I'll be at the FOSDEM on all days, so sure :) 2020-01-28 10:19:10 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 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 Well, if you read that mail I'm somewhat certain that you'll notice one :) 2020-01-28 10:22:38 punctuating every phrases with sh*t is not correct 2020-01-28 10:23:07 markand: why not is correct? 2020-01-28 10:23:14 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 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 that is his vocabulary and who are we to judge 2020-01-28 10:24:08 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 well, I will simple ignore this words 2020-01-28 10:24:44 it's not judging, it's acting professionally, those kind of repeatitive words are annoying for the reader 2020-01-28 10:25:22 he is insulting the developers, which is demotivating and destructive 2020-01-28 10:25:30 could we understand that different people are, well different 2020-01-28 10:25:38 you may ignore it but it doesn't make it any less rude or unacceptable 2020-01-28 10:25:48 he is demanding and drains resources from us 2020-01-28 10:25:54 both time and emotional 2020-01-28 10:26:05 it is damaging for the project 2020-01-28 10:26:12 danieli: agree, it is rude but again, simply ignore 2020-01-28 10:26:35 why? it's destructive and demoralizing 2020-01-28 10:26:48 there's no good reason to allow it to continue happening 2020-01-28 10:26:50 look the whole thread mps, it's totally insane how non-constructive answers were 2020-01-28 10:27:13 yes, I agree, it is not good 2020-01-28 10:27:35 mps: and he has been asked several times to change behavior 2020-01-28 10:27:45 but I don't see any personal attack or rude words to any person 2020-01-28 10:28:13 oh well. 2020-01-28 10:28:20 maybe I have too much thick skin 2020-01-28 10:28:30 everyone is different 2020-01-28 10:28:50 and apparently people are reacting negative to it 2020-01-28 10:28:57 ncopa: that is what I agree 2020-01-28 10:29:49 the other option is complete ignore him and freeze him out 2020-01-28 10:29:55 and, he is not only one who uses rude words, especially on irc 2020-01-28 10:31:13 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 (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 ncopa: that sounds nice 2020-01-28 10:33:43 we should tell people that their words or behaviors not nice, but we shouldn't react to harsh 2020-01-28 10:34:14 I like _ikke_ reactions in similar situations 2020-01-28 10:34:59 and clandmeter humor :) 2020-01-28 10:35:32 +1 2020-01-28 10:35:43 mps: do you think my response was too harsh? 2020-01-28 10:35:59 no, sure no 2020-01-28 10:37:03 and, I would sometimes tell someone something similar, but cease because I'm not alpine leader 2020-01-28 10:37:21 feel free to ping men when you think it is needed 2020-01-28 10:37:36 s/men/me/ 2020-01-28 10:37:36 ncopa meant to say: feel free to ping me when you think it is needed 2020-01-28 10:37:49 i will ping you next time mps is rude 2020-01-28 10:37:57 :) 2020-01-28 10:38:30 clandmeter: you are a big guy. you should be able to spank him yourself :) 2020-01-28 10:38:35 I told I like your humor 2020-01-28 10:38:55 he is too far away ;-) 2020-01-28 10:39:12 but we have ways to communicate :) 2020-01-28 10:39:31 ncopa: yes, but first he is my 'friend' and second I'm all my life martial artist 2020-01-28 10:40:54 ok, ncopa did you looked at gcc fix in MRs 2020-01-28 10:41:02 back to work 2020-01-28 10:42:02 btw, does somebody have time to look at https://github.com/alpinelinux/abuild/pull/110? 2020-01-28 10:45:21 mps: no i havent had time for that yet. will try do it this week 2020-01-28 10:46:00 ok 2020-01-28 10:46:04 kpcyrd: thanks for working on that! sorry that i havent had time to look at it yet 2020-01-28 10:46:12 will try do it this week too 2020-01-28 10:46:26 awesome :) 2020-01-28 11:18:27 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 how many people use PCI on arm 32bit and how many boards are around 2020-01-28 11:19:53 and IDE disk/devices 2020-01-28 12:31:25 looks like it is mainly to enable 9p filesystem over virtio 2020-01-28 12:38:09 not only, a lot of network adapters are enabled which I doubt is used on arm SBC boards 2020-01-28 12:38:26 and a lot of PCI options 2020-01-28 12:38:58 at least, too big number changes for one commit 2020-01-28 12:39:33 IDE interface is example 2020-01-28 12:41:22 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 Cogitri: can you followup on https://gitlab.alpinelinux.org/alpine/docker-abuild/issues/55 ? 2020-01-28 12:55:47 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 im importing mkinitfs from github to gitlab 2020-01-28 14:03:53 https://gitlab.alpinelinux.org/alpine/mkinitfs 2020-01-28 14:04:52 markand: ^ 2020-01-28 14:05:00 nice ! 2020-01-28 14:05:02 thanks <3 2020-01-28 15:11:58 clandmeter: thanks! 2020-01-28 16:02:07 ncopa: is there a reason we ship mariadb-tests with mariadb? 2020-01-28 16:02:16 is it a needed dependency? 2020-01-28 16:18:08 clandmeter: line 291 in APKBUILd, ln -s .... 2020-01-28 16:18:56 I don't know how mariadb works but this looks strange 2020-01-28 16:19:51 I talked about this with person who create bug report 2020-01-28 16:44:00 clandmeter: there is an issue about that 2020-01-28 16:44:26 iirc there are symlinks that should be moved to proper subpackage 2020-01-28 16:49:13 I created a docker image but the size is huge for Alpine standards 2020-01-28 16:50:16 #11131 2020-01-28 16:51:08 Thanks my friends 2020-01-28 16:51:13 I will look into it 2020-01-28 16:51:40 :) 2020-01-28 16:53:26 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 This gitlab popup is pissing me off 2020-01-28 16:54:48 :D 2020-01-28 16:54:51 I know the freaking menu has moved 2020-01-28 16:55:39 They should never make that developer developer of the month ;) 2020-01-28 16:55:41 it don't know that you (and I) know that menu is moved 2020-01-28 16:56:53 I'm also getting multiple errors in ui 2020-01-28 16:57:27 Something went wrong on our end 2020-01-28 16:57:50 So that's my end? 2020-01-28 16:58:04 no 2020-01-28 16:58:20 you are not logged in gitlab.a.o 2020-01-28 16:58:46 And that should give an error? 2020-01-28 16:58:55 it is there only for not logged in users 2020-01-28 16:59:35 The error or the popup? 2020-01-28 16:59:41 popup 2020-01-28 16:59:49 what error you have 2020-01-28 17:00:12 17:57 <@clandmeter> Something went wrong on our end 2020-01-28 17:00:44 ah, didn't noticed any error on my browser 2020-01-28 17:03:02 main/pciutils: upgrade to 3.6.4, is it officially released? 2020-01-28 17:06:18 It's only in the changes tab 2020-01-28 17:07:47 hmm, I got popup (not logged in now) but no errors 2020-01-28 17:10:01 I'm on mobile 2020-01-28 17:10:49 could be browser issue 2020-01-28 17:13:39 Happens on ff and chrome 2020-01-28 17:14:53 looks like ff on alpine works better 2020-01-28 17:15:22 both, tried on esr and current in testing 2020-01-28 17:46:23 interesting this symlink behaviour 2020-01-28 18:53:24 looks like there are more symlinks not moved to the right subpkg 2020-01-28 18:53:45 wonder if we could do that automatically or add a check. 2020-01-28 19:02:46 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 hmm 2020-01-28 19:08:03 i think this "fix" will break things 2020-01-28 19:08:32 its a similar fix as the clamav thingy 2020-01-28 19:09:40 you mean mariadb fix? 2020-01-28 19:09:49 yes 2020-01-28 19:10:10 moving symlinks to its correct position will undep things that are not really a dep 2020-01-28 19:10:14 aha, that is reason I didn't dare to make MR 2020-01-28 19:10:19 but people could depend on them 2020-01-28 19:10:41 most notable is mariadb-client 2020-01-28 19:11:01 currently it is pulled in when you install mariadb 2020-01-28 19:11:13 due to the faulty symlink locations 2020-01-28 19:11:58 and i think there is a way around it 2020-01-28 19:11:58 don't see why mariadb-client have to be pulled when mariadb installed, but who knows 2020-01-28 19:12:31 example: you create a docker image for mariadb 2020-01-28 19:12:52 but on initial start you need to run some commands, so you need the mysql utility. 2020-01-28 19:12:53 ok 2020-01-28 19:13:13 now it would suffice to apk add mariadb 2020-01-28 19:13:17 ah, it needs it on installation setup? 2020-01-28 19:13:26 depends on your usecase 2020-01-28 19:13:50 but yes its used on dockerized mysql/mariadb 2020-01-28 19:14:19 but there are more places that users would think mariadb would pull in both server and client. 2020-01-28 19:14:57 so the better work around would be to introduce mariadb-server 2020-01-28 19:15:17 and make mariadb a metapkg to pull in both client and server 2020-01-28 19:15:50 and maybe even mariadb-server-utils 2020-01-28 19:15:53 'apk info -r postgresql-client' => postgresql-client-11.5-r0 is required by: postgresql-11.5-r0 2020-01-28 19:16:02 so, similar 2020-01-28 19:16:34 i have not checked postgresql 2020-01-28 19:16:52 but i dont think you explicitly need the client to run the db. 2020-01-28 19:17:49 im not sure if this symlink dependency has always been included 2020-01-28 19:17:52 well, also I think but packagers don't agree 2020-01-28 19:18:02 let me look on debian 2020-01-28 19:18:16 better example maybe is openssh 2020-01-28 19:18:24 it has server and client split 2020-01-28 19:20:57 yes, but for ssh server client is not needed for initial setup 2020-01-28 19:21:18 also not for db's 2020-01-28 19:21:27 but if your usecase changes it could be. 2020-01-28 19:22:51 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 s/ nothing serious/ nothing serious for more 15 years/ 2020-01-28 19:23:27 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 ime, at least 2020-01-28 19:24:11 for postgres it sets it as a hard dependency 2020-01-28 19:26:25 iirc, postgres 'initdb' command requires 'psql' 2020-01-28 19:28:02 hmm, 'strings' result is against my thoughts 2020-01-28 19:33:11 i know why its added :) 2020-01-28 19:33:21 git blame to the rescue 2020-01-28 19:33:42 64bce71141d9562664c0a852dd096978579ea5f8 2020-01-28 19:36:16 this is a weird place to implement such feature 2020-01-28 19:36:51 oh thats for tmpfs 2020-01-28 19:37:30 running a db in tmpfs... 2020-01-28 19:38:58 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 for short lived DBs 2020-01-28 19:39:22 ncopa: https://lists.alpinelinux.org/~alpine/aports/patches/3194 2020-01-28 19:40:31 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 the issue with mariadb is the test data pkg is installed 2020-01-28 19:51:41 mps: https://gitlab.alpinelinux.org/alpine/aports/issues/11131 2020-01-28 19:54:06 yes, I talked with him about that issue, but not sure how to remove this test data 2020-01-28 19:54:29 ah, you added fix 2020-01-28 19:54:40 i think his commit is good to go 2020-01-28 19:57:29 yes, from your description I understand all 2020-01-28 20:00:11 removing server-utils also removes perl. 2020-01-28 20:00:16 thats a win anyways :) 2020-01-28 20:01:25 eh, by this I see my hope for alpine to stay small is not vanished :) 2020-01-28 23:22:48 community/plymouth/plymouth-git-master-20170123.patch | 5399 ----------------------------------- 2020-01-28 23:22:56 oh wow 2020-01-28 23:23:15 I made a small script for detecting .patch files that are not in source and i found... that 2020-01-28 23:23:30 I noticed, good work 2020-01-28 23:33:08 It has false-positives due to not being smart enough to detect conditionals 2020-01-28 23:33:23 so if you have 2020-01-28 23:33:26 if "$FOO"; then source="$source patch.patch"; fi 2020-01-28 23:33:43 it will declare it stale even though it is used when FOO Is true 2020-01-28 23:33:48 see ghc/0000-bootstrap 2020-01-28 23:34:38 maybe it will be safer to detect by your script and then check by 'eyes' 2020-01-28 23:34:53 yes i do that for cases i find suspcious 2020-01-28 23:34:58 0000-bootstrap 2020-01-28 23:35:12 anything regarding the linux kernel like linux-amlogic and anything gcc like community/gcc6 2020-01-28 23:38:00 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 but will look tomorrow, preparing for bed now 2020-01-29 00:33:05 oof 2020-01-29 00:33:22 I update telegram-desktop to 1.9.8 and they release 1.9.9 2020-01-29 06:29:18 is bin/tipc being pkg'd in iproute2, in edge ? 2020-01-29 06:29:22 #2361 , ncopa, Cogitri ^ 2020-01-29 06:30:34 project seems active, http://tipc.sourceforge.net/ 2020-01-29 06:30:56 I can see kernel modules, but no tools in v3.10.x 2020-01-29 07:28:10 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 Neat 2020-01-29 07:32:42 yes, who will backport it LTS? I hope someone will 2020-01-29 07:35:37 Cogitri: any chance of bin/tipc getting added in iproute2 pkg ? 2020-01-29 07:35:53 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 If they backported features to LTS kernels LTS would be pointless 2020-01-29 07:36:37 yes, I know, but this is long awaited 'feature' 2020-01-29 07:36:39 nope, kernel module is there, only the tool 2020-01-29 07:36:53 and, it is not complicated to backport 2020-01-29 07:38:15 and, 5.4 is still not declared LTS 2020-01-29 07:39:15 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 x86 and x86_64 CI are stuck 2020-01-29 11:45:05 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 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 we came up with an idea that the maintainer could declare unwanted dependencies in APKBUILD 2020-01-29 11:47:31 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 right 2020-01-29 11:48:49 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 why not loose deps 2020-01-29 11:49:46 is this a sensible approach, or is there a better way? 2020-01-29 11:50:02 s/why not// 2020-01-29 11:50:02 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 no 2020-01-29 11:50:40 <_ikke_> ok 2020-01-29 11:51:30 want to tell that this is some kind of 'lose dependencies' but keyboard is not obedient enough :) 2020-01-29 11:51:44 s/lose/loose/ 2020-01-29 11:51:44 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 the same could of course happen with shared libs 2020-01-29 11:55:18 hmm, why then to add this if package doesn't actually depends on those listed in 'nodeps' 2020-01-29 11:57:12 it's basically a test case 2020-01-29 11:57:36 they are added to detect bugs (even though they are not supposed to be there) 2020-01-29 11:58:44 so we know that mariadb should not depend on mariadb-test 2020-01-29 11:59:18 we want at least a warning printed if such a dependency is detected by abuild 2020-01-29 11:59:41 ah, now understand 2020-01-29 12:00:13 maybe even abuild error 2020-01-29 12:00:57 or flag to abuild to fail or just write warning in such case 2020-01-29 12:01:28 IMO failing would be the correct action 2020-01-29 12:02:22 the maintainer should either remove the dep or the nodeps clause 2020-01-29 12:02:48 yes, makes sense 2020-01-29 15:19:12 ncopa: I would push gcc6 fix, !3425 do you agree 2020-01-29 15:20:30 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 Yes 2020-01-29 15:21:50 I'll upload the script to my dotfiles but it is super simple and requires manual checking 2020-01-29 15:22:26 so guess this is wrong? 2020-01-29 15:27:00 north1: ? 2020-01-29 15:31:57 Well it wasn't in the source, as far as I could see it wasn't being applied 2020-01-29 15:34:32 north1: yes but you applied the patch that introduced it ;-) 2020-01-29 15:51:42 _ikke_: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3436 2020-01-29 16:01:24 mps: ok with me 2020-01-29 16:16:19 @clandmeter must have been a massive oversight by me then 2020-01-29 16:17:10 it has happened to me before as well so no worries. 2020-01-29 16:17:53 @ddevault are you or anyone else working updating wlroots/sway and stuff ? 2020-01-29 16:18:05 oh, I totally forgot 2020-01-29 16:18:15 working on it now 2020-01-29 16:18:30 ah nice, i'll wait then 2020-01-29 16:18:51 north1: do you know if that mariadb patch is still needed? 2020-01-29 16:19:12 @clandmeter no idea, i'd have to ask the author 2020-01-29 16:19:33 ok i backported a few fixes to stable 2020-01-29 16:19:42 not sure that should be included 2020-01-29 16:20:27 @ddevault i also packaged xcb-util-errors if that is of any use for wlroots 2020-01-29 16:38:09 @ddevault your patches didn't appear on the patches section 2020-01-29 16:38:57 north1: weird, noted 2020-01-29 16:40:39 They have been applied 2020-01-29 16:41:13 thanks! 2020-01-29 16:46:56 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 thanks! 2020-01-29 18:35:55 how does this kind of warning come into existence? 2020-01-29 18:35:57 > WARNING: babl-dev*: package providing /usr/lib/pkgconfig/lcms2.pc needs to be rebuilt 2020-01-29 18:47:30 nvm got it 2020-01-29 23:37:10 i 2020-01-29 23:39:04 Any Alpine developers available for hire for brief consulting ? 2020-01-29 23:40:24 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 vivi: why not ask on #alpine-linux first, channel for user help 2020-01-29 23:42:42 maybe your problem is interesting in general 2020-01-29 23:43:02 mps, it is in terms of application, not so much in terms of OS level 2020-01-29 23:43:52 and most developers are in CET so probably not many of them online now 2020-01-29 23:44:29 I'll post in #alpine as well then. Thank you mps. 2020-01-29 23:45:30 ahem.. #alpine-linux 2020-01-30 05:47:56 <_ikke_> Cogitri: squeekboard is failing 2020-01-30 05:48:27 Yup, gonna look into it in a bit 2020-01-30 05:48:33 <_ikke_> ok 2020-01-30 05:48:47 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 Huh 2020-01-30 06:11:23 <_ikke_> It's at the end of the tests 2020-01-30 06:27:36 `ninja test -C output` should be `ninja -C output test` 2020-01-30 06:28:42 (same with install) 2020-01-30 06:30:13 That makes a difference? 2020-01-30 06:31:14 yes, samurai follows the POSIX Utility Syntax Guidelines, and doesn't do GNU-style argument permutation 2020-01-30 06:31:30 Ah, alrighty then 2020-01-30 06:31:31 so all operands must come after options 2020-01-30 06:33:06 Time to change all the APKBUILDs which do that :^) 2020-01-30 06:33:19 (Without WiFi, thanks Deutsche Bahn) 2020-01-30 06:34:27 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 (this was mid-december) 2020-01-30 06:35:38 There are some 40 or so 2020-01-30 06:36:36 Alright nevermind, it's 11 apparently 2020-01-30 06:40:29 !3463 2020-01-30 06:44:29 Cogitri: looks ok to me 2020-01-30 06:44:37 all new packages it looks like 2020-01-30 06:46:13 All packages which haven't been generated with newapkbuild 2020-01-30 06:46:41 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 Cogitri: do you have the ability to push? i can do so otherwise. 2020-01-30 06:47:47 I have push permissions for community and testing, yes 2020-01-30 06:47:51 But thanks :) 2020-01-30 06:48:19 Gonna see if CI can run over them (minus the rust stuff because that'll probably SIGSEGV again) 2020-01-30 06:53:05 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 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 mforney: we provide /usr/bin/ninja 2020-01-30 07:10:51 yes, but the argument order is still a problem 2020-01-30 08:05:07 yay \o/ mkinitfs migrated to gitlab 2020-01-30 08:38:32 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 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 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 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 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 i got my own base image :) 2020-01-30 13:03:01 awesome... there are no alpine package for adoptopenjdk, right? 2020-01-30 13:07:23 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 or does somebody know about third party repos which provide adoptopenjdk8 packages? damn minecraft forge :( 2020-01-30 13:14:08 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 fabled: yes 2020-01-30 13:51:25 ncopa, yes, fixed in https://gitlab.alpinelinux.org/alpine/aports/commit/d24f40bce4b68f7e9bdaa49c2a5be762ddaaa9c6 2020-01-30 13:53:40 hum.... should i really start building a thirdparty repo for this damn other jvm? :( 2020-01-30 13:54:19 tboerger[m]: what is the difference of adoptopenjdk8 vs openjdk8? 2020-01-30 13:55:53 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 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 and minecraft does not run with openjdk11? 2020-01-30 14:01:01 they ship a precompiled openjdk8 binary linked to glibc toghether with a copy of glibc 2020-01-30 14:01:05 ugly indeed 2020-01-30 14:01:22 minecraft itself recommends jdk8 2020-01-30 14:01:50 using a more current java version leads to different issues 2020-01-30 14:02:01 ncopa: i wonder why they are using alpine in the first place then 2020-01-30 14:02:19 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 i guess because its small and users are asking for it 2020-01-30 14:02:42 cant you use a glibc based docker image? 2020-01-30 14:03:02 there are surely some minimalistic glibc distros out there 2020-01-30 14:03:27 AinNero: where? i haven't found anything comparable to alpine 2020-01-30 14:04:06 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 i think i would use debian containers just to avoid the hassle with compatibility 2020-01-30 14:05:43 would be nice to have a proper build with musl 2020-01-30 14:06:37 so whats the difference with icedtea and adopt? 2020-01-30 14:14:00 vivi in #alpine-linux also has the issue with the missing files on the repo 2020-01-30 14:14:11 their mirror is in the mirror list 2020-01-30 14:17:01 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 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 On a range from 0 to 10, how happy are you to read about new bootstrap.sh fails? 2020-01-30 14:21:50 assorted build failures: gcc, binutils, musl, ... 2020-01-30 14:21:52 All very fun. 2020-01-30 14:22:04 cross building from x86_64 to aarch64 2020-01-30 14:22:16 3.11 docker image to 3.11-stable 2020-01-30 14:35:54 hum 2020-01-30 14:36:09 would be good to have nighly runs of bootstrap.sh or similar 2020-01-30 14:37:00 and i wonder if we should include go, rust and openjdk in the bootstrap.sh 2020-01-30 14:37:54 tboerger[m]: the idea is to help adoptopenjdk to make rebuilt binaries using musl 2020-01-30 14:41:48 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 maybe it could be interesting to reach out to adoptopenjdk to get it built on musl/alpine 2020-01-30 14:42:52 since it's gpl licensed it could be easily added to alpine 2020-01-30 14:43:12 (if it's building on musl) 2020-01-30 14:48:40 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 i dont have time to help with that though :-( 2020-01-30 14:49:34 i guess that if they set up a builder with musl, the official build would fail 2020-01-30 14:50:05 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 oracle has put some effort to make openjdk on alpine 2020-01-30 14:59:30 would be great if this can be integrated! 2020-01-30 14:59:53 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 ncopa: can aports tree with abuild be readonly? 2020-01-30 15:22:13 i think no 2020-01-30 15:22:21 abuild needs patching for that 2020-01-30 15:22:38 thee is SRCDEST 2020-01-30 15:22:41 there... 2020-01-30 15:22:57 but i dont see similar for pkg 2020-01-30 15:23:14 we need a WORKDIR or similar 2020-01-30 15:23:36 currently it creates src and pkg in same dir as APKBUILD 2020-01-30 15:23:46 should be in /var/ soemwhere 2020-01-30 15:23:57 maybe /var/lib/abuild/ or similar 2020-01-30 15:24:03 I played a little with setting env vars for that 2020-01-30 15:24:24 for 'src' and 'pkg' I mean 2020-01-30 15:24:36 currently workdir is startdir 2020-01-30 15:24:48 SRCDEST=${SRCDEST:-$startdir} 2020-01-30 15:25:44 hmm 2020-01-30 15:25:55 pkgbasedir=${pkgbasedir:-"$startdir/pkg"} 2020-01-30 15:26:13 what if i override both of them? 2020-01-30 15:28:37 ah that is actually distfiles location 2020-01-30 15:32:07 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 yes i think it can work 2020-01-30 15:32:23 but its not optimal 2020-01-30 15:32:41 its more like a hack then a feature 2020-01-30 15:32:43 there was some PR with related patch 2020-01-30 15:32:44 (didn't wrote anywhere exact setup or notes :( ) 2020-01-30 15:33:10 clandmeter: yes, hack 2020-01-30 15:33:50 it would be nice if that can be set in ~/.abuild/abuild.conf 2020-01-30 15:37:36 hmm that does not really work without patching. 2020-01-30 15:38:30 ncopa: was it on gitlab/github/ml? 2020-01-30 15:40:37 github 2020-01-30 15:40:55 i didnt merge his patch due to i want move src and pkg to /var 2020-01-30 15:41:22 i think it was something with symlinks 2020-01-30 15:42:30 you would prefer var/lib or var/cache? 2020-01-30 15:44:42 yeah, /var/lib probably 2020-01-30 16:02:20 hmm, i guess this could be tricky depending on how the APKBUILDS are stored 2020-01-30 16:43:20 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 Also, this is kind of required to bootstrap alpine for aarch64 2020-01-30 16:43:40 :( 2020-01-30 16:56:53 Is it acceptable to use a case statement to define source/patches in an APKBUILD? 2020-01-30 16:59:13 wsinatra: how the checksum then be calculated? manually? 2020-01-30 17:00:06 ghc does it for 0000-bootstrap 2020-01-30 17:00:06 and i have no clue how it works or even if it works 2020-01-30 17:01:02 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 north1: thanks for teh suggestion I'm looking at that now 2020-01-30 17:03:04 north1: yes, and it doesn't have checksum 2020-01-30 17:03:29 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 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 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 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 oh, dalias left this channel 2020-01-30 18:39:21 <_ikke_> mps: why is that? 2020-01-30 18:39:54 _ikke_: fixes to time64 will be in 5.6 kernel 2020-01-30 18:40:45 XFS (for example) got time64 fixes in 5.6 2020-01-30 18:41:19 _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 :) 2020-01-30 18:44:13 and switching to 5.6 we will get wireguard in kernel, as a bonus :) 2020-01-30 18:45:49 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 It's fine to have multiple ones 2020-01-30 18:47:34 It's basically a collection of people who made notable changes to the APKBUILD 2020-01-30 18:47:41 minecrell: Contributor officially even is not needed 2020-01-30 18:47:49 PureTryOut[m]: ^ 2020-01-30 18:48:33 No, it's not a requirement 2020-01-30 18:48:38 and there can be multiple Contributor lines 2020-01-30 18:49:39 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 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 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 Cogitri, you are right 2020-01-30 18:58:04 I'm going to update it. Thanks a lot! 2020-01-30 19:00:12 hmmm, forgot to add with 5.6 we will get RPi4 support in mainline 2020-01-30 19:00:25 Thanks :) 2020-01-30 19:05:28 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 it's a nice little note to give them credit I think 2020-01-30 19:07:15 wsinatra: I see it as address where people can complain if something does not work as people expect 2020-01-30 19:07:38 besides maintainer, ofc 2020-01-30 19:08:59 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 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 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 eh, some people like their names in project (even if anonymous in that case 2020-01-30 19:15:05 mps: i am not comfortable in shipping kernel 5.6 since it wont be LTS 2020-01-30 19:15:38 kaniini: other option is backport all fixes 2020-01-30 19:15:54 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 there is a third option: postpone shipping musl 1.2 until next cycle. 2020-01-30 19:16:13 i'll write an email outlining all 3 options and we can go from there 2020-01-30 19:16:35 kaniini: and lost dalias as alpine user ;P 2020-01-30 19:16:47 who cares 2020-01-30 19:17:02 i wasn't aware that we were making decisions to make single individual users happy 2020-01-30 19:17:11 hmmm, hope you are not serious 2020-01-30 19:17:17 i am quite serious 2020-01-30 19:18:07 I prefer to keep knowledgeable people with us 2020-01-30 19:18:26 you assume he will not be 'with us', as the, by far, primary consumer of musl 2020-01-30 19:19:42 no, I have impression that he is more irritated with latest kernel issue 2020-01-30 19:20:47 at any rate, we have to make decisions that support stable, reliable releases 2020-01-30 19:21:01 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 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 wsinatra: else, I will be anonymous here 2020-01-30 19:22:31 kaniini: yes, not easy decision I know 2020-01-30 19:23:55 kaniini: because that I wrote about kernel upgrade so we can start thinking about that in advance 2020-01-30 19:24:22 well, write to alpine-devel about it not irc 2020-01-30 19:24:47 or i can :) 2020-01-30 19:25:03 but i am not personally convinced time64 is a good goal for this release 2020-01-30 19:25:04 you were left us when I expressed my problem with ML switch to new system 2020-01-30 19:25:34 I read MLs but don't post there 2020-01-30 19:26:31 so, please write there, if you have time and will ofc 2020-01-30 19:26:48 and why can you not post there, exactly? 2020-01-30 19:27:08 because having a mailing list that people cannot use is not very useful 2020-01-30 19:27:09 can we about this on PM 2020-01-30 19:27:13 sure 2020-01-30 19:33:16 mps: I can definitely see that, you're one of the more active people here too 2020-01-30 19:35:37 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 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 and that is to everyone who chooses to not participate correctly because they dislike the software 2020-01-30 19:38:50 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 Well, we have a GitLab 2020-01-30 19:40:20 no 2020-01-30 19:40:32 kaniini: this is discussed few times here and I think we shouldn't again 2020-01-30 19:40:45 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 you are right. there will be no further discussion. 2020-01-30 19:41:18 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 that's not what we are talking about 2020-01-30 19:42:25 gitlab is fine for reviews, but the ML exists for policy discussion. 2020-01-30 19:42:30 so, here's the bottom line 2020-01-30 19:42:46 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 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 because if you don't, we will just make the decision without you 2020-01-30 19:44:21 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 Yes, IRC isn't a suitable tool for that 2020-01-30 19:45:35 _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 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 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 more problem are solved over irc than ML and/or issue/bug reports 2020-01-30 19:47:15 "do we upgrade to GCC 10 or do we stay with GCC 9.2" 2020-01-30 19:47:32 mps: yes, but i am talking about *big* decisions, we have always used the ML for those 2020-01-30 19:47:39 mps: More *small* problems are solved over IRC :l 2020-01-30 19:47:43 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 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 Yup 2020-01-30 19:48:22 And it's easy to miss something on IRC 2020-01-30 19:48:25 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 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 (Both due to being offline or just by not paying attention for a little) 2020-01-30 19:49:07 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 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 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 _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 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 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 not boycott it 2020-01-30 19:51:52 nothing is set in stone 2020-01-30 19:52:16 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 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 or we can use a different software 2020-01-30 19:52:30 in the grand scheme of things, it really does not matter 2020-01-30 19:52:33 kaniini: I agree 2020-01-30 19:52:51 so do it? 2020-01-30 19:52:53 but I don't have enough nerves to go for that 2020-01-30 19:53:19 I prefer other works, fixes mostly 2020-01-30 19:54:17 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 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 it does not cause the software to be changed 2020-01-30 19:55:10 (either through replacement or modification) 2020-01-30 19:55:27 well, I hope I can be useful to alpine even if I don't post to ML 2020-01-30 19:56:08 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 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 now I'm with Cogitri, we can open issue on gitlab.a.o about this 2020-01-30 19:57:23 ACTION eyerolls 2020-01-30 19:57:32 <_ikke_> gitlab issues have no visibility to be honest 2020-01-30 19:57:50 yes, which means the gitlab issue still has to be forwarded to the ML 2020-01-30 19:58:30 Fair point 2020-01-30 19:58:59 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 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 kaniini: personally I prefer MLs for decision and serious issues discussions 2020-01-30 20:00:09 and on most other 'works' I use them 2020-01-30 20:00:14 then perhaps you should deal with the fact that you dislike the ML software 2020-01-30 20:00:30 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 already told all what I had to told 2020-01-30 20:01:15 going to coffee :) 2020-01-30 20:01:35 mps: and if infra team makes the requested change, will you use the ML? 2020-01-30 20:02:10 sure 2020-01-30 20:02:43 okay 2020-01-30 20:02:56 but I don't want to put burden on infra team because of my personal preferences 2020-01-30 20:04:44 if all other members fine with current situation I don't want to ask for any change 2020-01-30 20:09:17 according to the lists.sr.ht source, you should be receiving a copy of your mails sent there 2020-01-30 20:09:19 recipients = set([a[1] for a in getaddresses(froms + tos + ccs)]) 2020-01-30 20:09:59 yes, author told me that, but it is not active afaik 2020-01-30 20:10:05 it is hardcoded 2020-01-30 20:10:27 do you receive your posts? 2020-01-30 20:10:32 yes 2020-01-30 20:10:47 ah, maybe it is changed in meantime 2020-01-30 20:10:50 however, i think i have a duplicate subscription 2020-01-30 20:11:01 ahm 2020-01-30 20:11:16 the solution is simple :D 2020-01-30 20:12:22 oh i see 2020-01-30 20:12:44 https://git.sr.ht/~sircmpwn/lists.sr.ht/tree/master/listssrht/process.py#L64 2020-01-30 20:12:53 [...] if to in recipients: continue 2020-01-30 20:13:27 so we add config option to change how recipients is composed 2020-01-30 20:13:34 and we enable it on our stuff 2020-01-30 20:13:37 i will deal with this 2020-01-30 20:13:56 <_ikke_> kaniini: +1 2020-01-30 20:13:57 thanks, really reallu thanks 2020-01-30 20:14:06 uh 2020-01-30 20:14:17 well 2020-01-30 20:14:21 i will not deal with the sysadmin side of it 2020-01-30 20:14:24 but i will write the patch 2020-01-30 20:14:32 s/reallu/really/ 2020-01-30 20:14:32 mps meant to say: thanks, really really thanks 2020-01-30 20:14:34 and ddevault can accept it or not 2020-01-30 20:14:39 <_ikke_> yup 2020-01-30 20:14:53 i am sure the infra team would not mind carrying a trivial patch to fix this issue 2020-01-30 20:15:19 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 anyway, i doubt ddevault would reject a patch adding a config option 2020-01-30 20:31:12 _ikke_: https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/9681 2020-01-30 20:31:23 _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 ddevault: i will literally *pay you* to merge this 2020-01-30 21:47:45 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 well, looking at web interface all looks fine, but my local clone is messed 2020-01-30 21:52:21 maybe I should remove local 3.11-stable branch and checkout it again 2020-01-30 21:53:18 I'd recommend you to not work directly on the 3.11-branch 2020-01-30 21:54:02 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 usually I do that 2020-01-30 21:54:33 (Also, instead of deleting and checking out you should probably just `git reset --hard origin/3.11-stable`) 2020-01-30 21:55:29 also this, but didn't helped to fix mess 2020-01-30 21:56:33 I made something bad this time, luck is it is local 2020-01-31 04:16:48 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 morning. did you see https://pythonspeed.com/articles/alpine-docker-python/ 2020-01-31 06:55:59 Yup 2020-01-31 06:56:16 The only valid thing is the musl allocator being slower, I suppose 2020-01-31 06:56:49 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 is there anything we can do to get musl built wheels? 2020-01-31 06:58:43 what would it take? 2020-01-31 06:58:48 (Other than packaging the thing of course, the author could have just done `apk add` for that package...) 2020-01-31 07:08:00 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 ncopa: Get Python upstream to build them, I suppose 2020-01-31 07:14:22 I don't know Python too well but wheels are basically binary packages 2020-01-31 07:18:57 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 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 the stackoverflow article above asks how to build it with musl 2020-01-31 09:00:30 but i think it is not possible at the moment 2020-01-31 09:00:57 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 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 :) 2020-01-31 09:01:42 <_ikke_> heh 2020-01-31 09:02:02 currently it is difficul or maybe not even possible 2020-01-31 09:02:10 so no wonder there are noone doing it 2020-01-31 09:02:29 i believe we may need to replace linux-gnu with linux-musl 2020-01-31 09:03:08 i think needs to be fixed: https://github.com/python/cpython/blob/master/configure.ac#L718 2020-01-31 09:04:38 <_ikke_> -linux-musl? 2020-01-31 09:40:11 yes, i think that would be good 2020-01-31 09:45:03 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 Cogitri: aports:master |Francesco Colista| testing/volatility3: fix correct license | http://dup.pw/aports/155c1b82 2020-01-31 09:52:57 Thanks :) 2020-01-31 09:53:16 ;) 2020-01-31 11:12:38 ncopa: would an introduction for ABUILD_WORKDIR be ok, or you really want to change the default behaviour? 2020-01-31 11:18:43 dont know 2020-01-31 11:21:07 i guess for a developer it is nice to have pkg and src inside the startdir 2020-01-31 12:33:23 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 Any help is greatly appreciated. :) 2020-01-31 12:34:38 Thermi: what are you trying? to cross compile gcc? 2020-01-31 12:35:03 mps: Generally bootstrap Alpine for aarch64. It fails when trying to build gcc for the first time 2020-01-31 12:35:09 #11174 2020-01-31 12:35:52 do you use scripts/bootstrap.sh 2020-01-31 12:36:10 Yes 2020-01-31 12:36:20 Only that. 2020-01-31 12:37:01 looks strange, but I couldn't conclude what are cause 2020-01-31 12:43:00 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 mps: just reading through the commit backlog today: shouldn't 89c323e648ed3e68b57790d8e25e35b1e9920242 require a bunch of rebuilds? 2020-01-31 12:48:29 e.g. of wireguard-lts, drdb-lts, xtables-addons-lts, … 2020-01-31 12:50:06 nmeum: isn't ncopa rebuilt all this? 2020-01-31 12:50:10 mps: If it's any help, I built in a new alpine:3.11 docker container 2020-01-31 12:50:29 mps: oh, indeed, the commit are just located a bit later in the commit log 2020-01-31 12:50:39 *commits 2020-01-31 12:50:42 sorry for the noise 2020-01-31 12:50:51 nmeum: np :) 2020-01-31 12:51:27 Thermi: it shouldn't matter if you build in docker or 'native' 2020-01-31 12:51:42 mps: Yes, it "shouldn't" :) 2020-01-31 12:51:50 :) 2020-01-31 13:52:25 ncopa, something is broke in abuild when trying to cross-compile (run bootstrap.sh) 2020-01-31 13:55:07 oh wait, i think it's something on me 2020-01-31 13:58:37 fabled: is it similar to this #11174 2020-01-31 14:02:51 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 busybox is not statically linked 2020-01-31 14:04:04 oh I thought all the core utils apk etc was 2020-01-31 14:04:07 including busybox 2020-01-31 14:04:13 my fault 2020-01-31 14:04:28 there is separate busybox-static apk 2020-01-31 14:04:37 it is not installed by default 2020-01-31 14:04:55 when I start a system with: ADD assets/ospkg/alpine-minirootfs-3.11.3-x86_64.tar.gz / 2020-01-31 14:05:06 it seemed to be 2020-01-31 14:05:22 to be what? static? 2020-01-31 14:05:27 yes 2020-01-31 14:05:35 which ones? apk? 2020-01-31 14:05:38 let me run tat container 2020-01-31 14:05:56 why would you create a container like that anyway? 2020-01-31 14:06:06 thats same as doing FROM alpine 2020-01-31 14:06:17 because where this is built has 0 internet connectivity 2020-01-31 14:06:21 all sources have to be local 2020-01-31 14:06:35 how do you get the minirootfs without uinternet? 2020-01-31 14:06:39 :p 2020-01-31 14:06:53 phone + laptop + usb 2020-01-31 14:06:55 ;) 2020-01-31 14:07:09 and yeah 2020-01-31 14:07:17 if its in your registry it needs no internet 2020-01-31 14:07:24 https://i.itsosticky.com/u1j0yi.png 2020-01-31 14:07:28 and you could also dump the image 2020-01-31 14:07:42 but hey, its your life :) 2020-01-31 14:08:03 this means its static? 2020-01-31 14:08:06 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 I thought so 2020-01-31 14:08:13 no 2020-01-31 14:08:22 it means all utils are in a single binary 2020-01-31 14:08:38 I thought that is what static meant 2020-01-31 14:08:43 how do I get it to not do that 2020-01-31 14:08:44 if you use the static one it will include musl 2020-01-31 14:09:12 you cannot 2020-01-31 14:09:15 I basically just want each binary to be its own 2020-01-31 14:09:25 maybe busybox has a build option for it, i dont know. 2020-01-31 14:09:36 but that would increase the size 2020-01-31 14:09:55 you could technically copy all of the applets to its own file :) 2020-01-31 14:09:55 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 can you explain what you are t rying to accomplish? 2020-01-31 14:10:43 you dont want to include some of those tools? 2020-01-31 14:10:47 all of them 2020-01-31 14:10:51 in that form 2020-01-31 14:10:58 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 daemon: i dont follow 2020-01-31 14:11:18 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 and that is all, I do not want them to be part of busy box 2020-01-31 14:11:44 I want them to be as if they was compiled and installed there 2020-01-31 14:11:50 almost like base install of gentoo goes 2020-01-31 14:12:16 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 if you dont want busybox use coreutils 2020-01-31 14:12:49 or anything that is remotly similar and does not blow up your system 2020-01-31 14:13:23 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 and it *should* work? 2020-01-31 14:13:40 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 _ikke_, won't be helpful in 10 years time when this thing needs rebuilding 2020-01-31 14:14:03 or 50 years 2020-01-31 14:14:06 or 1000 years 2020-01-31 14:14:16 the ticket is basically it should be rebuildable without internet 2020-01-31 14:14:21 anywhere at anytime 2020-01-31 14:14:22 with no restraint 2020-01-31 14:14:27 all sources MUST be kept with hte dockerfile 2020-01-31 14:14:30 i dont think its easy to replace busybox in alpine, but its doable for sure. 2020-01-31 14:14:48 clandmeter, yeah I would grab a copy of bourneshell for sure 2020-01-31 14:15:00 daemon: alpine is shipping precompiled binaries. if from source is your requirement, you might be wrong here 2020-01-31 14:15:34 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 if you go that way, you will understand later why people use busybox in the furst place 2020-01-31 14:15:46 I thought alpine was as good a thing as any to start with 2020-01-31 14:15:49 s/furst/first/ 2020-01-31 14:15:49 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 as I have got a system with no external resources with it 2020-01-31 14:16:05 check musl-cross-make 2020-01-31 14:16:18 alpine-meetbot, well I meant to survive LFS so I presumed it would not be so bad 2020-01-31 14:16:18 sabotage linux had similar efforts 2020-01-31 14:16:31 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 I've been sitting here for 70 days, 17:04:19 and I keep going! 2020-01-31 14:16:47 _ikke_, ah 2020-01-31 14:16:57 it reacted to the regex 2020-01-31 14:17:02 :) 2020-01-31 14:17:11 <_ikke_> hehe 2020-01-31 14:17:32 sometimes algitbot also reacts to users 2020-01-31 14:17:38 algitbot: nice that you are here! 2020-01-31 14:17:44 <_ikke_> w00t 2020-01-31 14:17:54 hmmm 2020-01-31 14:17:56 interesting idea 2020-01-31 14:17:56 some languages don't even have regex ;-) 2020-01-31 14:18:18 hey guys what would happen if I compiled 'file' 'zcat' etc and unlinked the /bin/zcat type things 2020-01-31 14:18:22 and installed the source build version 2020-01-31 14:18:44 nothing bad i guess 2020-01-31 14:18:54 might be a way to get around it 2020-01-31 14:19:07 what was your problem with busybox? 2020-01-31 14:19:24 AinNero, its not in the spec for the project 2020-01-31 14:19:30 and that means I have to explain its presence 2020-01-31 14:19:32 Crap 2020-01-31 14:19:46 This Intel driver issue... 2020-01-31 14:19:48 just say its a lightweight coreutils replacement 2020-01-31 14:20:15 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 and I really do not want to 2020-01-31 14:20:43 clandmeter: yes, 30 mins ago again had firefox OOM :( 2020-01-31 14:20:51 if you use coreutils, you are gonna have to explain that to them 2020-01-31 14:21:00 with linux-lts 5.4.16 2020-01-31 14:21:18 AinNero, coreutils is already ok'd as its in place on almsot all current projects 2020-01-31 14:22:50 if being 'already ok' is an requirement, you are wrong in this place 2020-01-31 14:23:08 both musl and busybox are quite uncommon/new 2020-01-31 14:23:23 the issue is not so much musl more busybox 2020-01-31 14:23:35 all the postgres containers are alpine based 2020-01-31 14:23:35 how would you explain musl to them? 2020-01-31 14:23:36 busybox is not new 2020-01-31 14:24:21 indeed I think I remember using busybox ages ago on some debian rescue shell or something 2020-01-31 14:24:29 mps: newer than i am 2020-01-31 14:24:51 AinNero: :) 2020-01-31 14:25:37 daemon: all software have bugs, new or old 2020-01-31 14:26:12 daemon: the postgres containers also have both musl and busybox 2020-01-31 14:29:56 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 maybe 2020-01-31 14:29:59 something like that 2020-01-31 14:30:10 and are now utterly unbuildable 2020-01-31 14:30:41 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 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 quite how to pull this off ... is what I am trying to figure out 2020-01-31 14:32:01 try to self-compile gcc plus dependencies, and then you might understand 2020-01-31 14:32:16 I have done for glibc quite a few times but never musl 2020-01-31 14:32:27 cannot be that bad surely 2020-01-31 14:32:31 and it worked on first attempt? 2020-01-31 14:32:38 the glibc one? yes 2020-01-31 14:33:16 the musl one seems to have an issue with mpc and the target platform being unknown 2020-01-31 14:33:50 so you should be able to bootstrap from there 2020-01-31 14:33:59 indeed I could 2020-01-31 14:34:13 but I thought I would at least try do it with musl 2020-01-31 14:35:36 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 _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 _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 yes, got for armhf '>>> ERROR: inotify-tools: check failed' 2020-01-31 14:46:03 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 yes 2020-01-31 14:49:31 <_ikke_> https://tpaste.us/naQ9 2020-01-31 14:50:13 inotifytools_error() returns 28 (No space left on device) 2020-01-31 14:50:16 hehe 2020-01-31 14:50:47 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 is it usa4? 2020-01-31 14:53:06 <_ikke_> yes 2020-01-31 14:53:29 I can try in lxc there 2020-01-31 14:53:43 <_ikke_> fine wih me 2020-01-31 14:54:23 will be at workstation in about 10-15 minutes 2020-01-31 15:02:39 daemon: take a look at buildroot 2020-01-31 15:02:57 https://buildroot.org/ 2020-01-31 15:05:18 kaey, that looks hand for this, cheers 2020-01-31 15:07:18 _ikke_: north1: main/inotify-tools build in armv7 on usa4 worked cleanly 2020-01-31 15:07:36 test passed 2020-01-31 15:07:40 Build fails 2020-01-31 15:07:57 Thermi: ? 2020-01-31 15:08:16 mps: bootstrap.sh build fails at gcc in clean, new docker container alpine:3.11 2020-01-31 15:08:26 Will provide logs shortly 2020-01-31 15:09:00 Thermi: yes, also failed in my clean lxc 2020-01-31 15:09:19 it is dependency issue, I think 2020-01-31 15:09:26 No, fails during building 2020-01-31 15:09:52 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 libtool: link: cannot find the library `../../libatomic/libatomic_convenience.la' or unhandled argument `../../libatomic/libatomic_convenience.la' 2020-01-31 15:10:40 here is end of my build log http://tpaste.us/za91 2020-01-31 15:11:02 My log here contains all commands and their outputs, too 2020-01-31 15:11:04 It's 5 MB 2020-01-31 15:11:10 Give me a second 2020-01-31 15:11:11 uh, I have gcc6 2020-01-31 15:11:19 gcc9 2020-01-31 15:12:36 gcc6, tested yesterday bugs, and forgot to deinstall 2020-01-31 15:14:22 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 no 2020-01-31 17:11:55 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 i think it was using double before 2020-01-31 17:12:49 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 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 the other dist mentioned is void 2020-01-31 17:19:11 could it be musl related or did you see others? 2020-01-31 17:24:32 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 Actually nvm, that is the wrong package I'm looking at lol 2020-01-31 17:26:51 py3-pyls i think 2020-01-31 17:27:01 i had problems with py3-favicon and py3-pyfavicon 2020-01-31 17:37:29 I'd do py3-pyls 2020-01-31 17:54:04 Anyone wants to test !3511 ? 2020-01-31 18:15:43 systemd for alpine? 2020-01-31 18:16:04 this seems like a bootloader, not a userspace thing 2020-01-31 18:16:48 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 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 I use Alpine because I don't want systemd :) 2020-01-31 18:18:42 every 'systemd' word in alpine will ruin alpine reputation 2020-01-31 18:19:35 I'm pretty sure if they grep through logs they'll see these comments pretty consistently 2020-01-31 18:20:15 ye, fork it and rebrand id 2020-01-31 18:20:17 *it 2020-01-31 18:20:28 <_ikke_> Who will maintain it :) 2020-01-31 18:20:36 by fork it, do you mean take out all of the systemd parts? 2020-01-31 18:20:46 because that might be a solution ;) 2020-01-31 18:20:53 well, I know one person with nick _ikke_ :) 2020-01-31 18:21:19 north1 is already volunteered 2020-01-31 18:21:53 don't worry, musl will not work systemd 2020-01-31 18:22:15 oh, vice versa 2020-01-31 18:23:45 None of the provided solutions are good solutions 2020-01-31 18:23:57 i just like systemd-bootd 2020-01-31 18:26:27 heh, maybe I should enable u-boot for x86_64 :) 2020-01-31 20:05:20 mps: Yes! 2020-01-31 20:25:33 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 https://wiki.alpinelinux.org/wiki/Bootloaders#systemd-boot