2017-11-01 02:32:14 <foxkit> ncopa: you had pasted a broken packagae list some time ago, and I said I could make a PR to fix some of them.  do you have an updated list?  I have the time now
2017-11-01 08:04:34 <ncopa> foxkit: http://tpaste.us/BeR4
2017-11-01 08:05:11 <ncopa> those in main has prio
2017-11-01 08:05:45 <ncopa> buildlogs here: http://build.alpinelinux.org/buildlogs/build-3-7-armhf/main/
2017-11-01 11:01:14 <scadu> Anyone installed Alpine from standard-3.6.2 image on x86_64? It fails on creating partitions (checked sys and lvmsys).
2017-11-01 11:02:33 <scadu> 
ACTION uploaded an image: file1509534083595.jpg (91KB) <https://matrix.org/_matrix/media/v1/download/disroot.org/rAENlnaSbMlCzJWdYThAemUZ>

2017-11-01 11:25:52 <ncopa> scadu: i cannot reproduce wiht qemu
2017-11-01 11:26:08 <ncopa> can you see if dmesg give any hints?
2017-11-01 11:40:15 <scadu> > can you see if dmesg give any hints?
2017-11-01 11:40:16 <scadu> http://tpaste.us/xWEl and that's all. I'll wipe the disk manually and see if it helps. Have you tried with two disks available? Not sure if it affects the process
2017-11-01 11:47:43 <scadu> Mkay, zeroing few blocks on sdb and running setup-disk once again seems to fix the issue, so I'm not able to reproduce this issue either. I just picked some old HDD and who knows what it actually contained. Sorry for the noise.
2017-11-01 13:36:50 <vkrishn> aha.. found a dbms that uses berkely db 6.1.x, https://github.com/rehartmann/durodbms/tree/master/duro ;)
2017-11-01 13:39:03 <vkrishn> has jirutka changed his nick ?
2017-11-01 13:39:24 <ncopa> no
2017-11-01 13:39:33 <ncopa> he just disconnected IRC
2017-11-01 13:39:46 <vkrishn> seems he is making commits but not online
2017-11-01 13:39:48 <vkrishn> ok
2017-11-01 13:40:05 <ncopa> he told me he is all or nothing
2017-11-01 13:40:20 <ncopa> so if he participates in irc he wants read it all
2017-11-01 13:40:23 <ncopa> which is too much
2017-11-01 13:40:30 <ncopa> so he is all off
2017-11-01 13:40:46 <vkrishn> but logs are still available, he can grep ;)
2017-11-01 13:40:59 <ncopa> yeah
2017-11-01 13:41:16 <ncopa> i suppose email is better if you need something from him
2017-11-01 13:41:37 <vkrishn> testing/tarantool has a stable release, just wanted to say
2017-11-01 13:43:03 <vkrishn> and found no discussion on postgres 10.x
2017-11-01 13:46:14 <vkrishn> which is kinda huge update release
2017-11-01 14:00:55 <rdutra> ncopa: perf-text-quoted build is failing on ppc64le 3.7 builder (http://build.alpinelinux.org/buildlogs/build-3-7-ppc64le/main/perl-text-quoted/perl-text-quoted-2.08-r0.log)
2017-11-01 14:00:55 <rdutra> I sent a PR to fix itbut I'm not a perl expert. If you can take a look at it please https://github.com/alpinelinux/aports/pull/2626
2017-11-01 14:07:21 <rnalrd> rdutra, looks good, altough check() now is mandatory unless unsupported from upstream
2017-11-01 14:08:08 <rdutra> rnalrd: ah yes, I forgout about it
2017-11-01 14:08:10 <rdutra> let me see
2017-11-01 14:12:51 <rdutra> rnalrd: done > https://github.com/alpinelinux/aports/pull/2626
2017-11-01 14:13:02 <rdutra> rnalrd: it already run tests but was not in check
2017-11-01 14:13:23 <rnalrd> yeah, many perl APKBUILDs are like this
2017-11-01 14:14:15 <rdutra> rnalrd: guess it is correct now
2017-11-01 14:16:52 <rnalrd> yup, pushed
2017-11-01 14:17:45 <rnalrd> mm
2017-11-01 14:18:00 <rdutra> thanks!
2017-11-01 14:18:17 <rnalrd> now armhf complains
2017-11-01 14:19:16 <rdutra> umm weird
2017-11-01 14:20:28 <rnalrd> my bad, didn't realized that we have broken depends due to main->community
2017-11-01 14:20:40 <rnalrd> perl-module-install needs to be in main
2017-11-01 14:20:52 <rnalrd> i can move it and its dependencies
2017-11-01 14:22:01 <rdutra> rnalrd: umm seems it built in ppc64le builder?
2017-11-01 14:22:13 <rdutra> rnalrd: even with the dependency been in community?
2017-11-01 14:23:04 <rnalrd> it did not
2017-11-01 14:23:10 <rnalrd> can't see it here http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/
2017-11-01 14:23:29 <rdutra> ah yeah
2017-11-01 14:23:42 <rdutra> failed in s390x too
2017-11-01 14:23:44 <rnalrd> ok, I'm going to move perl-text-quoted to community,
2017-11-01 14:23:54 <rdutra> ok
2017-11-01 14:23:57 <rnalrd> it seems it's not a dependency of anything in main
2017-11-01 14:25:46 <rnalrd> all builder's happy now
2017-11-01 14:25:55 <rnalrd> builders are*
2017-11-01 14:26:56 <rdutra> great, thanks!
2017-11-01 14:26:57 <scadu> Not related with the current topic, but maybe do you know what might be the reason that mkimage throws 'unable to select package (or its dependencies)' while trying to fetch apks? The missing package is chrony is this case.
2017-11-01 14:27:34 <ncopa> scadu: i have no clue, but i noticed the same
2017-11-01 14:27:45 <ncopa> and missing package was chrony
2017-11-01 14:27:50 <ncopa> might be a regression in apk
2017-11-01 14:30:50 <scadu> Tested on both 3.6 and edge but they contains different versions of apk (2.7.4 vs 2.8.1)
2017-11-01 14:32:30 <ncopa> does it happen with both?
2017-11-01 14:34:53 <scadu> ncopa: unfortunately. Tried with different mirrors (dl-cdn and nl) on edge suspecting some mirror issue, but it's not the case I think.
2017-11-01 14:43:57 <ncopa> i dont think its mirror
2017-11-01 14:44:46 <scadu> ncopa: surprisingly it works for building 3.6
2017-11-01 14:46:22 <scadu> If it was broken APKINDEX I wouldn't be able to install chrony on local machine, hm...
2017-11-01 14:46:33 <ncopa> so i think its something else that broke
2017-11-01 14:46:38 <ncopa> might be apk
2017-11-01 19:24:08 <andypost> How to get why x86_64 stuck http://pkgs.alpinelinux.org/packages?name=php7&branch=v3.5
2017-11-01 21:17:24 <_ikke_> andypost: I've heard there was a build error with php
2017-11-01 21:17:45 <_ikke_> Due to litespeed rename
2017-11-01 21:18:08 <_ikke_> Not sure if that's still the case
2017-11-02 03:18:24 <kaniini> scadu: try http://turtle.dereferenced.org/~kaniini/apk-tools-provider_priority.patch
2017-11-02 03:18:58 <kaniini> scadu: this allows apk to properly handle pure virtuals
2017-11-02 05:01:27 <scadu> kaniini: thanks. Will try later today.
2017-11-02 05:02:11 <kaniini> scadu:  i pushed that patch to git after doing some smoke testing
2017-11-02 05:02:25 <kaniini> scadu: i will probably push it to edge later today, which will fix the busybox problem
2017-11-02 05:05:59 <scadu> kaniini: great! Hope I finally will be able to build an image and check UEFI installation support
2017-11-02 13:19:45 <rdutra> rnalrd: ncopa: yesterday the 3.7 ppc64le builder got stuck in gtk-doc. I reproduced the build failure in my container and opened a PR: https://github.com/alpinelinux/aports/pull/2629
2017-11-02 13:21:39 <rnalrd> tnx!
2017-11-02 13:23:32 <fcolista> http://dup.pw/aports/9a81aed1 wow
2017-11-02 13:24:12 <rdutra> rnalrd: yw
2017-11-02 13:28:47 <rdutra> seems the perl-term-table source url is not available (http://build.alpinelinux.org/buildlogs/build-3-7-ppc64le/main/perl-term-table/perl-term-table-0.008-r0.log)
2017-11-02 13:28:48 <rdutra> not sure if it is temporary or not
2017-11-02 13:53:50 <ashb> rdutra: 0.008 isn't available anymore it looks like. Either update the version, or change the source URL to point to backpan
2017-11-02 13:54:11 <rdutra> ashb: yeah, will open a PR now upgrading it
2017-11-02 13:54:20 <ashb> http://backpan.perl.org/authors/id/E/EX/EXODIST/ for all history
2017-11-02 13:56:13 <rdutra> ashb: thanks
2017-11-02 13:57:23 <rdutra> rnalrd: more one https://github.com/alpinelinux/aports/pull/2630 :)
2017-11-02 14:16:28 <ncopa> rdutra: huh... i file a bug here:  https://bugzilla.gnome.org/show_bug.cgi?id=789813
2017-11-02 14:16:36 <ncopa> never figured out what was wrong
2017-11-02 14:17:16 <rdutra> ncopa: the autoreconf fixed the problem :)
2017-11-02 14:17:33 <rdutra> ncopa: but took me some time to try that
2017-11-02 14:18:08 <ncopa> wow, thats great
2017-11-02 14:43:32 <AG> Hey guys. Anyone here using a yubikey neo as a smart card with a 3.6 install?
2017-11-02 14:43:54 <AG> I assume I'm doing something wrong here, but pscd can't init the neo. it's in CCID mode and.. i'm stumped
2017-11-02 14:44:01 <AG> I don't think I'm missing any packages
2017-11-02 14:44:12 <AG> also, I realize I'm in -devel; if the main channel is better, I'll ask over there
2017-11-02 15:11:55 <andypost> ncopa, why x86_64 missing for 3.5 in http://build.alpinelinux.org/
2017-11-02 15:12:51 <andypost> maybe because of that php still not build for 3.5?
2017-11-02 16:14:44 <ncopa> andypost: i dont know. may have lost connection for some reason
2017-11-02 16:15:44 <ncopa> build service died for some reason
2017-11-02 16:24:17 <scadu> kaniini: have you already pushed changes to apk in edge?
2017-11-02 17:48:20 <kaniini> i have not yet
2017-11-02 19:23:02 <andypost> anyone can accept https://github.com/alpinelinux/aports/pull/2634 3.5 & 3.4 still not get update
2017-11-02 23:30:26 <Unode> Hi all, can someone confirm if you can reproduce the issue in https://bugs.alpinelinux.org/issues/8098 and if indeed bash-4.4.12 was packaged or bash-4.4.0 was used by accident?
2017-11-02 23:42:49 <andypost> Unode, confirm that it hangs
2017-11-02 23:43:58 <Unode> andypost: I can't reproduce locally (not alpine) but "bash --version" gives "GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)"
2017-11-02 23:44:06 <Unode> and thanks
2017-11-02 23:49:00 <andypost> Unode, 3.6 reports 4.3.48(1)-release & tested on ubuntu machine 4.3.48(1)-release - no hangs
2017-11-02 23:49:38 <andypost> openssl needs upgrade https://github.com/alpinelinux/aports/pull/2635
2017-11-03 02:09:28 <xentec> anyone from the dev-team here keen on finally bringing llvm5 to alpine-edge? https://github.com/alpinelinux/aports/pull/2393
2017-11-03 02:10:28 <kaniini> not before 3.7 release is cut
2017-11-03 08:52:45 <ncopa> xentec: how much will need to be rebuilt if we would merge llvm5?
2017-11-03 09:01:42 <xentec> ncopa: I'd hoped you would keep lists for this kind of reverse deps ;). other than the whole llvm family there is only mesa. rust and ghc seem to rely on an older llvm version
2017-11-03 09:02:22 <ncopa> and as i see your PR, you keep the llvm4, in case something requires it
2017-11-03 09:02:34 <ncopa> so worst case, we could ping mesa to llvm4
2017-11-03 09:02:42 <ncopa> pin*
2017-11-03 09:03:31 <ncopa> my biggest worry is if there 1.5 years in the future show up a CVE for LLVM
2017-11-03 09:04:01 <ncopa> then we may need to patch llvm3.7, llvm3.9, llvm4 and llvm5
2017-11-03 09:04:10 <ncopa> which is fairly time consuming
2017-11-03 09:04:15 <ncopa> * 4 branches
2017-11-03 09:04:24 <ncopa> 16 patches
2017-11-03 09:04:36 <xentec> 1 day building
2017-11-03 09:05:35 <ncopa> probably 2 for armhf
2017-11-03 09:05:48 <ncopa> + manual work of cherry-picking, and test compile
2017-11-03 09:06:26 <ncopa> but i think it would be really nice to have llvm5 included in v3.7
2017-11-03 09:06:35 <ncopa> i wonder if some of the other arches breaks?
2017-11-03 09:08:01 <xentec> I kinda hoped for llvm5 to make into 3.7 or edge because then alpine will finally have at least one c++17 compliant compiler
2017-11-03 09:08:12 <xentec> would*
2017-11-03 09:08:50 <ncopa> i agree it would be really nice to have llvm3 included in v3.7
2017-11-03 09:08:54 <ncopa> llvm5*
2017-11-03 09:09:03 <ncopa> xentec: do you have it built locally?
2017-11-03 09:09:10 <xentec> of course
2017-11-03 09:09:19 <ncopa> can you testbuild mesa?
2017-11-03 09:09:36 <ncopa> also: grep clang */*/APKBUILD
2017-11-03 09:09:47 <ncopa> looks like there are some packages that uses clang in community repo
2017-11-03 09:09:58 <ncopa> can you please test atleast one or two of those too
2017-11-03 09:10:16 <xentec> sure
2017-11-03 09:11:41 <ncopa> i think we should move llvm4 to community too
2017-11-03 09:12:18 <xentec> btw mesa is already pinned to llvm4
2017-11-03 09:12:27 <xentec> so no breakings there
2017-11-03 09:12:30 <ncopa> can you try test build it with llvm5?
2017-11-03 09:12:38 <ncopa> so we can move llvm4 to community
2017-11-03 09:12:45 <xentec> yeah, just mentioning
2017-11-03 09:22:37 <xentec> ncopa: without much analysis: mesa build fails
2017-11-03 09:26:21 <xentec> and I recall having linking issues with llvm5 but didn't have time to look further into it. clang and lld work, because they are statically linked
2017-11-03 09:28:29 <ncopa> :-(
2017-11-03 09:28:36 <ncopa> linking issues?
2017-11-03 09:28:56 <xentec> dynamic linking with libLLVM.so failed
2017-11-03 09:29:08 <ncopa> what is the exact error?
2017-11-03 09:41:29 <xentec> e.g. lld is built broken, exiting with ": CommandLine Error: Option 'disable-symbolication' registered more than once!" on each invokation
2017-11-03 09:41:36 <xentec> (https://bugs.llvm.org/show_bug.cgi?id=27685)
2017-11-03 09:42:33 <xentec> Someone will more insight into llvm will have to look over my patches, that's sure
2017-11-03 09:43:30 <xentec> *with
2017-11-03 09:43:46 <ncopa> can you mention that in the PR?
2017-11-03 09:44:03 <ncopa> i dont think we have time to debug that kind of issues before v3.7 release :-(
2017-11-03 09:44:15 <ncopa> llvm5 builds on ppc64le
2017-11-03 09:44:37 <xentec> it is mentioned in the OP of the pr ;)
2017-11-03 10:37:43 <ncopa> i think i know what the problem with llvm5 is
2017-11-03 10:37:52 <ncopa> atleast when it comes to mesa
2017-11-03 10:38:21 <ncopa>         LLVM_SO_NAME=LLVM-`$LLVM_CONFIG --version`
2017-11-03 10:38:21 <ncopa>         AS_IF([test -f "$LLVM_LIBDIR/lib$LLVM_SO_NAME.$IMP_LIB_EXT"], [llvm_have_one_so=yes])
2017-11-03 10:39:06 <ncopa> it will check if libLLVM$(lvm5-conf --version).so exists
2017-11-03 10:39:21 <ncopa> llvm5-config --version adds a git-$hash suffix
2017-11-03 10:51:39 <ncopa> xentec: i know what is wrong
2017-11-03 10:52:02 <ncopa> the cmake file will run git rev-parse --short HEAD
2017-11-03 10:52:12 <ncopa> it it returns something it will append that to llvm version number
2017-11-03 10:52:37 <ncopa> the intention is to add git has to version number when llvm is built from llvm git repo
2017-11-03 10:52:49 <ncopa> but in this case, they pick up the git hash from aports git repo
2017-11-03 10:53:59 <ncopa> the solution is to fix the cmake file to check if the git top level corresponds with llvm toplevel dir
2017-11-03 10:54:02 <ncopa> git rev-parse --show-toplevel
2017-11-03 10:58:21 <xentec> ncopa: thanks for looking! but sadly I'm out of time now (work is pressing). if you want, you can add commits to my PR to have them in one place
2017-11-03 11:00:03 <xentec> also I suspect building in aports will probably bring more related for problems, so consider prioritizing out-of-aports building support for abuild ie in /tmp
2017-11-03 11:05:42 <ncopa> yeah
2017-11-03 11:05:45 <ncopa> we should do that
2017-11-03 13:58:19 <rdutra> ncopa: "bsm-simple-themes" package is failing to download source tar.gz. It is pointing to http://distfiles.alpinelinux.org/distfiles/ but the tar.gz is not there. Is it a place where Alpine add some tarballs that do not want to get from upstream (or maybe some other reason)?
2017-11-03 14:42:19 <ncopa> that needs to be fixed
2017-11-03 14:42:32 <ncopa> i suppose we could move bsm-simple-themes to unmaintained
2017-11-03 14:42:39 <ncopa> iirc its kind of dead upstream
2017-11-03 15:28:28 <ncopa> i am supposed to be able to push commits to someone elses PR?
2017-11-03 15:28:57 <ncopa> i'd like to push 3 commits to https://github.com/alpinelinux/aports/pull/2393
2017-11-03 15:29:20 <ncopa> but i get permission denied
2017-11-03 15:29:23 <ncopa> To github.com:xentec/aports
2017-11-03 15:29:23 <ncopa>  ! [remote rejected]       xentec-pr-llvm-5 -> xentec-pr-llvm-5 (permission denied)
2017-11-03 15:29:23 <ncopa> error: failed to push some refs to 'git@github.com:xentec/aports'
2017-11-03 15:57:39 <Shiz> you cant
2017-11-03 15:57:44 <Shiz> that would be pushing to their repo
2017-11-03 16:44:42 <ashb> When you open a PR there is an option of "allow maintainers to push" but it's not checked by default
2017-11-03 16:59:21 <xentec> ashb, ncopa: I've allowed pushing from maintainers from the beginning
2017-11-03 17:01:34 <xentec> ncopa: I think you need to checkout the pr in aports as local branch, commit to it, and push it back. https://help.github.com/articles/checking-out-pull-requests-locally/
2017-11-03 17:25:03 <scadu> > scadu: try http://turtle.dereferenced.org/~kaniini/apk-tools-provider_priority.patch
2017-11-03 17:25:04 <scadu> kaniini: the patch works. Finally I was able to create an iso \o/
2017-11-04 01:33:23 <kaniini> anyone offering decent alpine vps anywhere
2017-11-04 01:33:25 <kaniini> scv?
2017-11-04 02:36:51 <scadu> kaniini: well, I use Vultr.
2017-11-04 03:28:27 <kaniini> yes, that is a possibility
2017-11-04 03:28:39 <kaniini> i want to set up a prototyping environment for my builder software
2017-11-04 04:13:18 <Xe> vultr is the least painful in my experience
2017-11-04 09:33:20 <scadu> I cannot complain. I didn't have any issues with them and possibility to install your own ISO is really useful. And... they do not play with kernels like Scaleway ;)
2017-11-04 11:28:45 <danieli> ncopa: whereabouts are you? I'm down south, and I'll buy you a beer or coffee (or drink of your choice) if you're in the Oslo area
2017-11-04 11:30:04 <danieli> also, think a lightning talk on alpine would be good? alpine is FOSS after all
2017-11-04 12:17:42 <BitL0G1c> what happened to php5-suhosin ?
2017-11-04 12:19:38 <BitL0G1c> & php5-acpu
2017-11-04 12:25:12 <_ikke_> BitL0G1c: https://github.com/alpinelinux/aports/commit/71d024f91830436d4007f82ec37a25da282dbca9
2017-11-04 12:25:54 <BitL0G1c> I use suhosin & apcu
2017-11-04 12:27:13 <_ikke_> You can ask kaniini why they were removed, but I think it would not be a problem to add them as separate packages again
2017-11-04 12:27:16 <_ikke_> note that this is still testing
2017-11-04 12:28:03 <BitL0G1c> ok
2017-11-04 21:23:00 <BitL0G1c> what happened to phpize in php5 ?
2017-11-05 17:27:16 <craftyguy[m]> ncopa: hey! Any reason you removed the directfb flag from your update to SDL2 2.0.7? Was that unintentional? https://git.alpinelinux.org/cgit/aports/commit/main/sdl2/APKBUILD?id=f073c5e4b86d969e50d087cb708be0b2064eefe3
2017-11-05 17:44:32 <craftyguy[m]> ncopa: here's a PR to resolve this: https://github.com/alpinelinux/aports/pull/2654
2017-11-05 17:45:20 <craftyguy[m]> hopefully y'all can review/merge this one relatively quickly. not having directfb support in sdl2 means that we can no longer use the app we built for unlocking rootfs/LUKS on boot in pmOS. That's bad for us.
2017-11-05 19:41:29 <nmeum> craftyguy[m]: there is usually not much going on here during the weekend, but ncoap might look at it or at least reply on monday
2017-11-05 21:34:51 <craftyguy[m]> nmeum: thanks. I also replied to your comment on the check..
2017-11-05 21:35:59 <craftyguy[m]> I'm guessing the maintainer for SDL2 doesn't have to go through Travis CI when submitting updates, because the check for 'check' fails immediately
2017-11-06 00:33:10 <kaniini> travis is a review tool for us
2017-11-06 00:33:15 <kaniini> a developer can push whatever they want :p
2017-11-06 01:31:25 <m4chm4n> Is there a way to get krita on alpine?
2017-11-06 06:32:13 <danieli> m4chm4n: if it's a package, make it -or- suggest it and wait for someone else to do it
2017-11-06 13:46:31 <knoppix> someone was cursing thunderbird for git patch issue, git has thunderbird-patch-inline in contrib folder
2017-11-06 13:46:53 <knoppix> but don't know how use it
2017-11-06 13:47:28 <knoppix> there are other code/utils that seems nice
2017-11-06 20:19:53 <mck> I would need an older version of a compiler (ghc) to provide another package (elm-platform); is it possible to have a package added to the repository when a newer version of the package already exists?
2017-11-06 20:44:56 <mitchty> forewarning on ghc 7.10 on musl, its... extremely buggy
2017-11-06 20:45:27 <mitchty> 7.10.1 never worked 7.10.2 had some weird llvm bugs 7.10.3 mostly worked, just not on anything but x86_64
2017-11-06 20:48:48 <mitchty> all i remember about porting ghc at the 7.10.3 timeframe was hitting really weird edge cases, i managed to pin it down to llvm ir before 8.0 came out and I just washed my hands of debugging it, I do have some apk's lying around somewhere for it
2017-11-06 21:04:07 <mck> mitcty: forewarning VERY much appreciated
2017-11-06 21:06:17 <mck> mitchty: if you have some of those 7.10.3 apks still around I'd definitely take a look at them; unfortunately I think providing an older version of ghc and building this package (elm-platform) would be more likely than updating elm-platform to use a newer version of ghc
2017-11-06 21:13:14 <mitchty> mck: sure, so its rsyncing to here http://mitchty.net/ghc/7.10/x86_64/
2017-11-06 21:13:52 <mitchty> and the signing public part of the apk signed keys should be in the old repo i used for porting here https://github.com/mitchty/alpine-linux-ghc-bootstrap
2017-11-06 21:14:29 <mitchty> off the top of my head, and it might be in the git repo somewhere I can't remember, you'd need to not only get ghc 7.10.3 running but also get an llvm35 apkbuild
2017-11-06 21:15:09 <mitchty> you could probably ignore that if you used the ncg, assuming only intel at that point, which is probably safe as arm had hella bugs
2017-11-06 21:15:41 <mitchty> i've not tried building 7.10.3 with 8.0.2 at all, it might work too no idea
2017-11-06 21:16:16 <mitchty> but presuming llvm is a model of how it could work, theoretically ghc could become ghc710, ghc80, and ghc82
2017-11-06 21:16:47 <mitchty> i've got 8.2.1 working with x86_64 and 8.2.2 rc2 but arm stage 2 compiler keeps segfaulting and not yet tracked it down
2017-11-06 21:17:21 <mitchty> so in some ways it might pay off, or if ghc just became latest and greatest that might work too
2017-11-06 21:18:55 <mitchty> i'm a bit surprised elm is so wedded to 7.10 to be honest
2017-11-06 21:26:32 <mitchty> err that link should be https, it should redirect you :)
2017-11-06 21:28:51 <mck> mitchty: I have not initiated a conversation as to the possibility of an upgrade, TBH. I did find this question that simply stated dependencies in the project aren't compatible with 8: https://github.com/elm-lang/elm-platform/issues/214
2017-11-06 21:35:39 <mck> mitchty: much appreciated! I am still in the process of determining which route I should take; it seems the most responisible at this point would be to simply change a part of an image I'm building to cross-build and inherit from an image with glibc (Debian)
2017-11-06 21:38:16 <mck> mitchty: it would be a benefit to have this available to the community, though, so I might still try and undertake the task. In any case, would you take any issue with me updating an open bug (https://github.com/elm-lang/elm-platform/issues/216) with my findings, including your points on how buggy you found 7.10.1 & 7.10.2 to be, as well as pointing to your example apks for 7.10.3?
2017-11-06 21:48:34 <mitchty> mck: sure, its been a while so I might be getting forgetful with age but 7.10.3 might work but all I remember is being happy to wash my hands of llvm3.5, it wouldn't be too hard an effort to get working but I don't know if it bitrotted at all or not
2017-11-06 21:49:45 <mitchty> i'll just note that cross building with ghc can be a beware of dragons afair
2017-11-06 21:49:52 <mitchty> affair even
2017-11-06 21:53:56 <mitchty> quick squiz at that bug if those elm binaries are built with glibc that would explain a lot
2017-11-07 03:12:09 <tmh1999> I am looking to buy a router to separate my network from my housemates' (I just had an incident recently when the semester started). Any Alpinist currently running Alpine on household/consumer routers ? If so, what is your hardware?
2017-11-07 03:26:36 <tmh1999> Humm running a Raspberry pi with Alpine seems way cheaper than a router !
2017-11-07 08:52:41 <MartijnBraam> You also have the Alix firewall, those usually run pfsense but should boot alpine
2017-11-07 09:08:33 <clandmeter> tmh1999: https://pcengines.ch/apu2.htm
2017-11-07 13:14:08 <tyng> apk-tools g20ae27c src/archive.c:85:13: error: field 'mdctx' has incomplete type
2017-11-07 13:42:19 <tyng> my bad it just needs libressl
2017-11-07 14:44:26 <tmh1999> clandmeter: Thanks! That seems to be a viable option for me.
2017-11-07 14:46:59 <ncopa> tmh1999: i have one of those
2017-11-07 14:47:32 <tmh1999> ncopa : pretty good config for the price.
2017-11-07 14:48:09 <ncopa> its very nice for firewall/router
2017-11-07 14:48:21 <clandmeter> i have a few of them :)
2017-11-07 14:48:28 <tmh1999> I bet so :)
2017-11-07 14:56:51 <fruitpi> Hi - I tried to run pre-built kubernetes binaries on raspberry pi. Interestingly some binaries run OK but for some I get not found
2017-11-07 14:57:08 <fruitpi> for example "-ash: kubelet: not found"
2017-11-07 14:57:14 <fruitpi> does anyone know why?
2017-11-07 14:58:04 <ncopa> sounds like some missing library
2017-11-07 14:58:35 <ncopa> what do you get with:  ldd /path/to/kubelet
2017-11-07 15:16:45 <fruitpi> my apologies - i was disconnected
2017-11-07 15:17:34 <fruitpi> ldd /path/to/kubelet returns "ldd: cannot load kueblet: No such file or directory"
2017-11-07 15:18:33 <fruitpi> sorry, there was a typo
2017-11-07 15:18:39 <fruitpi> here is the output: 	/lib/ld-linux-armhf.so.3 (0x74ac3000) 	libpthread.so.0 => /lib/ld-linux-armhf.so.3 (0x74ac3000) 	libdl.so.2 => /lib/ld-linux-armhf.so.3 (0x74ac3000) 	libc.so.6 => /lib/ld-linux-armhf.so.3 (0x74ac3000) Error loading shared library ld-linux-armhf.so.3: No such file or directory (needed by kubelet) Error relocating kubelet: __vfprintf_chk: symbol not found Error relocating kubelet: __fprintf_chk: symbol not f
2017-11-07 15:19:21 <ncopa> looks like the precompiled binary is linked to glibc
2017-11-07 15:19:49 <ncopa> you can either try build it yourself or ask upstream for a precompile binary linked against musl
2017-11-07 15:21:08 <fruitpi> noted, thanks.
2017-11-07 15:40:30 <fruitpi> I installed glib but when i do ldd /path/to/kubelet it shows
2017-11-07 15:41:00 <fruitpi> Error loading shared library ld-linux-armhf.so.3: No such file or directory (needed by kubelet)
2017-11-07 15:41:18 <fruitpi> 	libpthread.so.0 => /lib/ld-linux-armhf.so.3 (0x74b1b000)
2017-11-07 15:41:30 <fruitpi> libdl.so.2 => /lib/ld-linux-armhf.so.3 (0x74b1b000)
2017-11-07 15:41:37 <fruitpi> libc.so.6 => /lib/ld-linux-armhf.so.3 (0x74b1b000)
2017-11-07 15:44:49 <ncopa> glibc not glib
2017-11-07 15:44:55 <ncopa> its a different C library
2017-11-07 15:45:24 <fruitpi> sorry
2017-11-07 15:45:26 <fruitpi> apk --allow-untrusted --force add glibc-2.23-r3.apk
2017-11-07 15:45:36 <fruitpi> i did that already
2017-11-07 15:46:12 <ncopa> i think its hackish...
2017-11-07 15:46:17 <ncopa> isnt kubernetes open source?
2017-11-07 15:46:29 <ncopa> we should rebuild it properly
2017-11-07 15:46:56 <fruitpi> yes it is
2017-11-07 15:46:59 <fruitpi> open source
2017-11-07 15:47:25 <ncopa> so we should build a package for it
2017-11-07 15:47:45 <ncopa> you may make it work with the precompiled binary but it will be non-optimal
2017-11-07 15:47:53 <fruitpi> that's will be great
2017-11-07 15:49:07 <fruitpi> so you suggest to rebuild kubernetes
2017-11-07 15:52:03 <fruitpi> there's a package lib6compat should this help?
2017-11-07 15:54:52 <fruitpi> after installing libc6-compat package it shows different error message
2017-11-07 15:54:58 <fruitpi> Error relocating /data/kubernetes/server/bin//kubelet: __vfprintf_chk: symbol not found Error relocating /data/kubernetes/server/bin//kubelet: __fprintf_chk: symbol not found
2017-11-07 16:09:01 <leo-unglaub> good evening
2017-11-07 16:10:42 <_ikke_> hey
2017-11-07 16:12:34 <^7heo> Btw, will we have multithreaded firefox one day? :)
2017-11-07 16:12:43 <^7heo> Or are we stuck with single-threaded?
2017-11-07 16:12:58 <leo-unglaub> for the next 6 hours i have access to an AMD RYZEN Threadripper with 32 GB of RAM and NVME as storage. i am installing alpine currently and then i am gpoing to give the entire build a go
2017-11-07 16:13:13 <^7heo> leo-unglaub: are you planning to save on your heating bill? :)
2017-11-07 16:13:52 <leo-unglaub> it's not that bad ... during a kernel compile it only got to 51 celsius
2017-11-07 16:14:06 <leo-unglaub> make -j 32 :)
2017-11-07 16:14:42 <^7heo> I would only get a threadripper if I can get a diamond-based CPU waterblock.
2017-11-07 16:14:48 <^7heo> otherwise I don't see the point.
2017-11-07 16:15:08 <^7heo> And I have no idea how expensive it gets to make a diamond of that size for a waterblock
2017-11-07 16:15:22 <^7heo> it might possibly be affordable; but probably not.
2017-11-07 16:15:33 <ncopa> leo-unglaub: awesome!
2017-11-07 16:17:08 <ncopa> the machine we got from packet.net has 256G ram
2017-11-07 16:17:13 <ncopa> ssd disks
2017-11-07 16:17:31 <kaniini> fruitpi: try gcompat in testing
2017-11-07 16:17:34 <ncopa> xeon cpu with 16 cores
2017-11-07 16:18:31 <leo-unglaub> nice, how long does a full build take on that?
2017-11-07 16:18:47 <ncopa> a week? soemthing
2017-11-07 16:19:03 <ncopa> due to lots of manual work needed to fix things that fails ;)
2017-11-07 16:19:26 <^7heo> I have a machine at work that can support 1.5TB of ram
2017-11-07 16:19:29 <^7heo> ofc we don't have that yet ;)
2017-11-07 16:19:47 <ncopa> i am currently rebuilding *alot* of packages against libressl 2.6
2017-11-07 16:19:48 <^7heo> but potentially, we could run alpine in big VMs there
2017-11-07 16:20:10 <^7heo> leo-unglaub: I assume that if it's 32GB of ram, it's because it's ECC ram?
2017-11-07 16:20:36 <^7heo> leo-unglaub: also I hope you don't get your electricity via NaturStrom
2017-11-07 16:20:38 <^7heo> :D
2017-11-07 16:20:40 <leo-unglaub> i see. well, the entire threadripper thing is very interresting. i already did openbsd on it and there you dont see any difference at all because it only uses 4 cores out of the 32 ... and the nvme storage is as slow as a normal ssd
2017-11-07 16:21:06 <ncopa> leo-unglaub: i am very curious to hear how it performs
2017-11-07 16:21:11 <^7heo> yeah BSDs don't usually have support for the latest features...
2017-11-07 16:21:35 <ncopa> from what i read threadripper is pretty good at parallel workloads
2017-11-07 16:21:38 <leo-unglaub> ^7heo: the 32 is because i took it out of my gaming PC becase my testhardware did not contain more ram
2017-11-07 16:21:40 <ncopa> eg compiles etc
2017-11-07 16:21:45 <^7heo> leo-unglaub: oh ok.
2017-11-07 16:22:06 <^7heo> leo-unglaub: I did some research for a server, and it turned out that 32GB was the maximum of supported ECC ram for Ryzen
2017-11-07 16:22:19 <^7heo> leo-unglaub: but maybe with the Threadripper it actually is 64, since it has two CPUs.
2017-11-07 16:22:44 <^7heo> at any rate, it's a little low per core/thread.
2017-11-07 16:25:00 <ncopa> alpine is pretty memory efficient
2017-11-07 16:25:09 <ncopa> specially multithread
2017-11-07 16:25:27 <leo-unglaub> to be hornest, i never really cared about ECC. i run alpine servers for years and before that debian and in the 11 years i run server i never had 1 problem that was causes by a ram missfunction. i was always bad written software
2017-11-07 16:26:03 <kaniini> talking about ECC ram
2017-11-07 16:26:10 <leo-unglaub> ncopa: yeah, getting alpine to use even 10 gb of ran as a normal server is nearly impossible. it strikes out way before on other bottlenects
2017-11-07 16:26:14 <kaniini> the EDAC support somehow got disabled
2017-11-07 16:26:36 <kaniini> so if you’re on alpine and you have ECC ram you won’t get any warnings
2017-11-07 16:54:12 <fcolista> ncopa, I did a mistake with this commit:  http://dup.pw/aports/c42f65a3
2017-11-07 16:54:23 <fcolista> I've the correct one ready
2017-11-07 16:54:28 <fcolista> should i bump pkgrel?
2017-11-07 16:54:39 <fcolista> ping_command is repeated x 2 and it's wrong
2017-11-07 16:55:26 <leo-unglaub> top
2017-11-07 16:55:31 <leo-unglaub> sry, wrong window
2017-11-07 16:56:01 <_ikke_> htop ftw :P
2017-11-07 16:56:07 <kaniini> fcolista: yes a rebuild is needed
2017-11-07 16:56:25 <fcolista> kaniini, ok..yeah i was thinkg that but i wanted to avoid it..
2017-11-07 16:56:48 <fcolista> I should revert actually
2017-11-07 16:57:19 <fcolista> in order to not have a -r3 missing
2017-11-07 16:57:38 <kaniini> nah
2017-11-07 16:57:41 <kaniini> just bump
2017-11-07 16:58:35 <fcolista> thx kaniini
2017-11-07 19:22:26 <ncopa> libeexecinfo is broken
2017-11-07 19:22:50 <ncopa> the test program here segfaults: http://man7.org/linux/man-pages/man3/backtrace.3.html
2017-11-07 19:26:53 <ncopa> even the test.c program that is shipped with the lib segfaults
2017-11-07 19:27:23 <foxkit> what arch?
2017-11-07 19:27:29 <ncopa> x86_64
2017-11-07 19:27:43 <foxkit> hm, you would think someone would have caught that by now then..
2017-11-07 19:27:48 <ncopa> exactly
2017-11-07 19:28:03 <ncopa> i think i noticed some app segfault
2017-11-07 19:28:14 <ncopa> and while debugging it i ended up in libexecinfo
2017-11-07 19:28:44 <ncopa> i think ended up disabling libexecinfo and get a proper core dump to be able debug it
2017-11-07 19:29:44 <foxkit> my box is chewing on the 'big merge'... three weeks of alpine git commits merged in, like 830 commits, so lots of packages to build.
2017-11-07 19:29:48 <foxkit> after it finishes I will take a look
2017-11-07 19:29:56 <kaniini> stuff like execinfo is developer hostile
2017-11-07 19:30:08 <ncopa> it actually is
2017-11-07 19:30:12 <kaniini> but also useful for putting in release versions
2017-11-07 19:30:28 <kaniini> because then some idiot can just give you some log output
2017-11-07 19:30:43 <ncopa> and you'll have a clue where to start looking
2017-11-07 19:30:44 <kaniini> but having proper assertions is even better
2017-11-07 19:30:52 <kaniini> because they give better clues
2017-11-07 19:31:14 <kaniini> so in general i dislike execinfo (but audacious will use it if available)
2017-11-07 19:32:21 <ncopa> i am working on libressl 2.6 upgrade
2017-11-07 19:32:26 <foxkit> when I was working commercial C development, what we did was a fatal_error, critical_error, and warn_error set of methods.  fatal would always log the error condition and then quit.  critical would SIGTRAP in developer builds, and log the error condition and pop a message box in release.  warning would just silently log in release, but still SIGTRAP in developer build.
2017-11-07 19:32:29 <ncopa> a lot of stuff needs to be rebuilt
2017-11-07 19:34:34 <foxkit> ncopa, are PRs still being accepted for things like adding test suites and crash-fix patches, or is 3.7 frozen?
2017-11-07 19:35:00 <ncopa> fixes are always ok
2017-11-07 19:35:11 <ncopa> test suites are ok too i think
2017-11-07 19:35:24 <ncopa> specially if you have tested it on various arches
2017-11-07 19:35:49 <foxkit> all of my test PRs are run on x86_64 and ppc32.. trying very hard to get an x86 and arm thingy figured out as well..
2017-11-07 19:36:27 <ncopa> two arches are good enough for merge a PR
2017-11-07 19:36:34 <ncopa> specially since its both 64 and 32 bit
2017-11-07 19:36:44 <foxkit> it's also big/little endian :)
2017-11-07 19:36:53 <foxkit> that's why I picked ppc32 as arch #2, it is different in every way from x86_64
2017-11-07 19:36:53 <ncopa> even better
2017-11-07 19:52:53 <przemoc> if I'll find some time, maybe I could try adding memdisk support (phram and co.) for x86/amd64 ISOs, so they could be simply loaded from pxelinux (super convenient), supported only when some special append is given (to not waste memory otherwise).  would such thing be possible to include in 3.7?
2017-11-07 20:00:20 <przemoc> ok, forgot that you cannot append stuff when doing memdisk.  so it would be always activated when memdiskfind detects memdisk present.
2017-11-07 20:00:36 <przemoc> s/present/presence/
2017-11-07 20:06:44 <przemoc> 
ACTION was once unpleasantly surprised (quite recently), when he wanted to quickly boot AL iso over network via pxelinux's memdisk and realized it isn't supported, that's why there is this idea to fix that

2017-11-07 20:45:37 <kunkku> AL works pretty well with PXE boot. The main issue is the lack of network drivers in the default initramfs
2017-11-07 20:47:02 <wWrAR07vpPZ1> huh. is it known that upon apk upgrade 'Executing bash-4.4.12-r1.post-upgrade'segfaults?
2017-11-07 20:49:26 <danieli> wat, segfault?
2017-11-07 20:49:57 <kaniini> that seems bad
2017-11-07 20:50:04 <danieli> that seems odd, it's news to me
2017-11-07 20:51:48 <wWrAR07vpPZ1> Upgrading bash (4.3.48-r2 -> 4.4.12-r1)
2017-11-07 20:53:17 <TBB> someone else mentioned other bash problems just the other day
2017-11-07 20:53:54 <danieli> then again i've been *mostly*gone for like a week or two
2017-11-07 20:53:58 <TBB> something like "cat <(ls)" hanging
2017-11-07 20:54:03 <danieli> oh that
2017-11-07 21:01:51 <wWrAR07vpPZ1> add-shell[11200]: segfault at 1 ip 0000679c5c0a8599 sp 0000704b042d98a8 error 4 in ld-musl-x86_64.so.1[679c5c059000+89000]
2017-11-07 21:02:07 <wWrAR07vpPZ1> Segmentation fault occurred at 0000000000000001 in /bin/busybox[add-shell:11200] uid/euid:0/0 gid/egid:0/0, parent /var/cache/misc/bash-4.4.12-r1.post-upgrade[bash-4.4.12-r1.:11199] uid/euid:0/0 gid/egid:0
2017-11-07 21:07:25 <przemoc> kunkku: it doesn't work straight from the iso, though.  you have to extract iso yourself, provide some nfs or other thing, etc.  it is inconvenient when you don't want to serve other things just to be able to PXE AL.
2017-11-08 01:20:18 <foxkit> so we (Adélie platform team) just held a vote and have agreed that moving forward, the best thing to do is contribute all that we can directly to alpine instead of forking and fermenting
2017-11-08 01:21:11 <foxkit> our position is that this will be less work for us to deal with merging constantly, and will be better quality packages for alpine, at the cost of increased/more frequent patches sent
2017-11-08 01:38:27 <craftyguy[m]> foxkit (IRC): \o/
2017-11-08 01:46:37 <kaniini> wWrAR07vpPZ1: that seems like a problem with busybox.  i'll try to reproduce
2017-11-08 05:48:20 <kaniini> ncopa: hmm, what was the rationale for $PKGDEST removal from abuild ?
2017-11-08 05:48:36 <kaniini> ncopa: it is an annoyance when it comes to incremental builds
2017-11-08 05:49:00 <kaniini> if i have 8 builders building the repos for a single arch, i want to collect their .apks and then compose them into a new repository
2017-11-08 05:49:10 <kaniini> so $REPODEST just complicates this
2017-11-08 05:51:13 <kaniini> nmeum: rootbld breaks if an aports-style repo is checked out to /tmp
2017-11-08 09:40:57 <wWrAR07vpPZ1> kaniini: thx!
2017-11-08 09:42:08 <kaniini> yeah it’s just annoying to gather it up :p
2017-11-08 10:43:36 <skarnet> oh groovy, lists.alpinelinux.org rejected my mail again... this time with "service unavailable".
2017-11-08 10:43:47 <skarnet> going to send it again today or tomorrow >.>
2017-11-08 12:24:11 <fruitpi> Hi, I want to run kubelet binary on raspberry pi using alpine, it shows __vfprintf_chk: symbol not found
2017-11-08 12:25:20 <fruitpi> I tried to make gcompat but the error raised Error relocating /usr/libexec/gcc/armv6-alpine-linux-musleabihf/6.3.0/cc1: __gmp_version: symbol not found
2017-11-08 12:47:42 <danieli> broken ABI?
2017-11-08 13:13:18 <Shiz> that looks like a glibc-compiled binary
2017-11-08 13:14:55 <^7heo> typical.
2017-11-08 16:02:43 <danieli>  
2017-11-09 03:13:55 <foxkit> woah, NightKhaos.. if that's the same one... we worked on linux stuff like a decade ago
2017-11-09 06:48:40 <jammers> are the setup scripts missing in "alpine-minirootfs-3.6.2" ARMHF tarball on purpose?
2017-11-09 07:08:03 <jammers> ok, what is the purpose of that tarball? It has no init scripts at all, ,and  the root login does not work....confused
2017-11-09 07:12:33 <_ikke_> jammers: It's not meant as a full OS, it's more for chroots and docker container
2017-11-09 07:12:36 <_ikke_> containers*
2017-11-09 07:15:31 <jammers> thanks for the reply ikka. Even in those contexts, shouldn't it have the setup-alpine stuff so you can move fdw?
2017-11-09 07:15:38 <jammers> fwd
2017-11-09 07:16:32 <jammers>  Trying to install apline on my arm based chromebook.
2017-11-09 07:16:41 <_ikke_> Then you should not use miniroot
2017-11-09 07:16:53 <_ikke_> It's not for installing alpine
2017-11-09 07:17:26 <jammers> which image then?
2017-11-09 07:17:28 <_ikke_> It's a stripped version that only contains the things necessary for chroots / docker
2017-11-09 07:17:46 <_ikke_> There is a generic ARM image
2017-11-09 07:17:50 <_ikke_> see https://alpinelinux.org/downloads/
2017-11-09 07:17:52 <_ikke_> at the botto
2017-11-09 07:17:55 <_ikke_> bottom
2017-11-09 07:20:42 <jammers> not a uboot device tho. Which rootfs would I use?
2017-11-09 07:24:12 <jammers> initramfs-hardened does not look complete enough to use as is
2017-11-09 07:49:59 <_ikke_> Not sure if there is a pre-built image then, but others might know
2017-11-09 07:51:24 <jammers> maybe the better question is what needs to be added to the miniroot to use it for a setup (all arch) ?
2017-11-09 08:15:44 <_ikke_> Isn't it easier to use a different bootloader on the generic arm image?
2017-11-09 08:29:23 <jammers> well the issue with the generic image is missing proprietary drivers in the kernel, so need  factory kernel and modules.
2017-11-09 08:31:15 <jammers> seems to be mostly working after adding just 3 apks: openrc, alpine-conf, busybox initscripts
2017-11-09 08:32:18 <jammers> at only 369k, I'm not sure that having those already in the mini-rootfs  would be a bad thing...would it?
2017-11-09 08:40:01 <_ikke_> Well, for the purpose of the miniroot, they are just plainly unneeded
2017-11-09 08:42:58 <jammers> the openrc and busybox stuff yes, but the apline-conf is needed to setup a more complete chroot
2017-11-09 08:45:47 <jammers> alpine-conf requires openrc right now, maybe that could change
2017-11-09 08:59:13 <jammers> I digress...certainly can setup chroot mods all manually, but apline-conf scripts make things much faster :)
2017-11-09 09:01:43 <kaniini> minirootfs is for stuff like docker
2017-11-09 09:03:22 <jammers> akn, maybe another std-rootfs target then?
2017-11-09 09:04:31 <kaniini> seems reasonable; write to alpine-devel mailing list requesting it
2017-11-09 09:09:26 <jammers> I think that would be highly useful. Just plug in your OEM kernel and modules from any device + "std-rootfs", and presto ..instant alpine !  :D
2017-11-09 19:56:23 <ncopa> im gonna push libressl-2.6 i think
2017-11-09 19:56:29 <ncopa> and a bunch of rebuilds
2017-11-09 19:59:02 <ncopa> ok, here comes libressl-2.6
2017-11-09 20:02:54 <Xe> TIL alpine ships alpine
2017-11-09 20:03:19 <ncopa> we do! :)
2017-11-09 20:04:36 <danieli> lololol
2017-11-09 21:22:42 <vkrishn> bump fossil to v2.4 pls
2017-11-09 21:23:55 <vkrishn> its got ssh releated bug fix
2017-11-09 21:33:50 <danieli> you could bump it yourself? :)
2017-11-09 21:34:01 <danieli> or notify the maintainer
2017-11-09 21:39:01 <fcolista> does anyone remember why chdir does not work in old alpine containers?
2017-11-09 21:39:20 <fcolista> I need postgresql on alpine 2.5
2017-11-09 21:39:46 <fcolista> postgresql setup fails when invokes sh "initdb"  as postgresql user
2017-11-09 21:39:59 <fcolista> i cannot do it by hand too
2017-11-09 21:40:18 <fcolista> fs:/var/run# su postgres
2017-11-09 21:40:18 <fcolista> su: can't chdir to home directory '/var/lib/postgresql'
2017-11-09 21:40:18 <fcolista> su: can't execute '/bin/sh': Permission denied
2017-11-09 21:40:30 <fcolista> /var/lib/postgresql exists
2017-11-09 21:40:42 <fcolista> and has the right permissions
2017-11-09 21:40:45 <danieli> in docker?
2017-11-09 21:40:46 <fcolista> as well as /bin/sh
2017-11-09 21:40:48 <fcolista> no
2017-11-09 21:40:49 <fcolista> lx
2017-11-09 21:40:50 <fcolista> lxc
2017-11-09 21:40:51 <fcolista> container
2017-11-09 21:41:20 <danieli> does `su - postgres` make a difference?
2017-11-09 21:41:27 <danieli> it *shouldn't*
2017-11-09 21:42:25 <fcolista> nope
2017-11-09 21:43:45 <fcolista> same problem
2017-11-09 21:43:50 <danieli> no idea
2017-11-09 21:56:53 <foxkit> fcolista: check perms of /etc, check perms of the home dir
2017-11-09 21:57:41 <foxkit> now /etc seems strange but if it can't read /etc/ld.so.comf it will fail to exec any binary
2017-11-09 21:57:48 <foxkit> ld.so.conf*
2017-11-10 10:41:59 <rdutra> hi. I opened some PR to fix packages that are failing to build in 3.7 builders. If someone can take a look at them please
2017-11-10 10:43:46 <clandmeter> rdutra: im also fixing them, not sure if we are doing double work?
2017-11-10 10:44:40 <rdutra> clandmeter: In the case of package main/xf86-input-libinput, yes
2017-11-10 10:44:50 <rdutra> clandmeter: I had a PR opened 2 days ago
2017-11-10 10:45:10 <clandmeter> ah ok sorry
2017-11-10 10:45:15 <clandmeter> difficult to keep up on all places...
2017-11-10 10:45:31 <rdutra> clandmeter: no problem, I dont have push rights to main. So I need to open the PR
2017-11-10 10:46:02 <rdutra> clandmeter: Can you review the PR I opened to fix packages for Alpine 3.7?
2017-11-10 10:46:13 <clandmeter> which pr is that?
2017-11-10 10:47:12 <rdutra> clandmeter:
2017-11-10 10:47:12 <rdutra> https://github.com/alpinelinux/aports/pull/2672
2017-11-10 10:47:12 <rdutra> https://github.com/alpinelinux/aports/pull/2678
2017-11-10 10:47:12 <rdutra> https://github.com/alpinelinux/aports/pull/2688
2017-11-10 10:47:12 <rdutra> https://github.com/alpinelinux/aports/pull/2680
2017-11-10 10:47:36 <clandmeter> ok on it.
2017-11-10 10:48:30 <rdutra> clandmeter: there is also: https://github.com/alpinelinux/aports/pull/2692  (not sure why failed on travis. I moved the dependency to main and it is not finding)
2017-11-10 10:53:30 <clandmeter> rdutra: I wonder if it makes sense to bundle them in the future into a single PR.
2017-11-10 10:54:09 <rdutra> clandmeter: you mean the PR that I opened?
2017-11-10 10:54:28 <clandmeter> i mean fix 3.7 issues
2017-11-10 10:55:06 <rdutra> clandmeter: oh ok. guess make senses. The "problem" is that patches was done not sequentially in my day
2017-11-10 10:55:21 <clandmeter> right
2017-11-10 10:55:23 <rdutra> so when I had it working, I opened the PR
2017-11-10 10:55:40 <clandmeter> and i just started on ncopas list which makes us do double work :|
2017-11-10 10:56:21 <clandmeter> i should have looked on github first.
2017-11-10 10:56:29 <rdutra> clandmeter: shame on ncopa :P
2017-11-10 10:56:32 <rdutra> kidding
2017-11-10 10:56:47 <clandmeter> but fixing the 3.7 builders it lots of stupid work...
2017-11-10 11:00:56 <clandmeter> rdutra: regarding testsuites, did you think about adding "stupid" --version/--help checks?
2017-11-10 11:02:15 <rdutra> clandmeter: hm, in some packages before I did, guess in this recently pull request I just checked if upstream provides tests
2017-11-10 11:02:39 <clandmeter> hmm
2017-11-10 11:02:51 <clandmeter> xfsprogs is also really behind
2017-11-10 11:02:55 <clandmeter> is there a reason for it?
2017-11-10 11:04:00 <rdutra> clandmeter: I'm not sure. think I never upgrade this package. For now I just fixed the source url
2017-11-10 11:04:38 <clandmeter> ok understand. would be nice when you fix them to bump if possible.
2017-11-10 11:05:38 <rdutra> clandmeter: regarding https://github.com/alpinelinux/aports/pull/2692 package perl-module-install requires 3 packages of community. will take a look on them
2017-11-10 11:10:03 <clandmeter> ah i pushed that one.
2017-11-10 11:10:45 <clandmeter> rdutra: why did you move it to main?
2017-11-10 11:15:52 <rdutra> clandmeter: because some perl-* from main requires it
2017-11-10 11:16:10 <rdutra> clandmeter for example perl-authen-sasl
2017-11-10 11:17:13 <clandmeter> ah ok, its required by git
2017-11-10 11:17:46 <clandmeter> ok i have to go, its weekend. ttyl.
2017-11-10 11:18:00 <rdutra> nice weekend
2017-11-10 11:18:08 <rdutra> and thanks for reviewing the PRs
2017-11-10 11:26:13 <wWrAR07vpPZ1> i remember berkeleydb v6+ being mentioned as problematic, why?
2017-11-10 11:27:52 <_ikke_> "As of Berkeley DB release 6.0.20, the Oracle Corporation has relicensed Berkeley DB under the GNU AGPL."?
2017-11-10 11:33:08 <wWrAR07vpPZ1> hmmm. thx!
2017-11-10 11:33:30 <_ikke_> Not sure it that's the actual reason
2017-11-10 11:33:44 <_ikke_> THat just looked like a relevant change around that version
2017-11-10 15:59:52 <kaniini> that is the reason
2017-11-10 16:15:24 <ncopa> i think i have pushed all libressl 2.6 rebuilds now
2017-11-10 16:30:59 <xentec> ncopa: sorry for bugging, but are you going to merge llvm 5.0? https://github.com/alpinelinux/aports/pull/2393
2017-11-10 23:52:51 <ollieparanoid[m]> so when a soname bump happens, all aports that depend on it need to have the pkgrel increased manually?
2017-11-11 00:19:58 <foxkit> ollieparanoid[m]: yep, welcome to the only thing humanity can devise worse than revdep-rebuild
2017-11-11 00:20:03 <foxkit> lol
2017-11-11 00:20:19 <foxkit> I think ncopa/fabled were talking about making a tool to automatically do it eventually
2017-11-11 00:23:47 <ollieparanoid[m]> ok :p
2017-11-11 00:30:39 <ollieparanoid[m]> would it make sense to keep the package with the old soname around, until all packages have been rebuilt in the future? (right now we can't build weston for armhf, because some dependency is not rebuilt yet. I'm not complaining or making demands, just explaining the situation :) )
2017-11-11 01:54:15 <ollieparanoid[m]> something else: newapkbuild always creates a "src" folder inside the new aport folder. is that a bug? and if not, what is the purpose?
2017-11-11 02:02:22 <Shiz> thats the default srcdir
2017-11-11 02:03:58 <Shiz> if you supply source urls they get extracted there and a default builddir= is figured out
2017-11-11 02:04:16 <Shiz> but $srcdir for apkbuilds is, by default, $(dir of APKBUILD)/src afaik
2017-11-11 02:05:04 <ollieparanoid[m]> Shiz, ah okay. so this is not for the stuff that should be versioned in the aports git repository, but only for building/analyzing the source files
2017-11-11 02:05:46 <Shiz> yea
2017-11-11 02:06:30 <Shiz> see also aports' .gitignore:
2017-11-11 02:06:36 <Shiz> https://github.com/alpinelinux/aports/blob/master/.gitignore
2017-11-11 02:06:56 <Shiz> src and pkg folders are created/accessed during building
2017-11-11 02:07:36 <ollieparanoid[m]> makes sense, thanks a lot!
2017-11-11 02:11:02 <Shiz> np :)
2017-11-11 13:00:13 <rdutra> I just opened a PR that fix a bunch of perl-* packages (from main) that are failing to build in 3.7 builders. If someone can review it please > https://github.com/alpinelinux/aports/pull/2699
2017-11-11 14:03:20 <leo-unglaub> good evening
2017-11-11 14:25:40 <leo-unglaub> ncopa: my tests with alpine and the new threadripper where so awesome. i beleave that i could build everything in under one day if all downloads where already on the local drive. building with 32 threads at once is unbeatable, nothing comes close!
2017-11-11 14:26:50 <leo-unglaub> the biggest limiting factor is IO, i tryed putting the entire aports folder in a ram disc, but the linux ramdisc code is sooo bad and slow that i was slower than from and SSD ... so sadly no speed gain there
2017-11-11 14:27:14 <leo-unglaub> if ram disc got optimize i would asume you could build a full alpine release on x64 in under 8 hours
2017-11-12 15:12:47 <^7heo> I know I already asked
2017-11-12 15:12:53 <^7heo> but I didn't get an answer, so:
2017-11-12 15:13:06 <^7heo> Will we get a multi-thread firefox one day?
2017-11-12 15:13:14 <^7heo> or are we bound to single-thread firefox in alpine?
2017-11-12 20:45:00 <foxkit> I see no movement with the CoC lately, should I reply to the last message (which contained the most recent version) and +1 for support or would that be noise?
2017-11-12 21:43:56 <joinalpinelinux> 	Hi!  There is an error message appearing when trying to log into Alpine linux's wiki:  "413 - Request Entity Too Large".  Tried to log in a few times today.  Could someone fix that?
2017-11-13 09:45:29 <ncopa> foxkit: i think you can reply to the last version of CoC with a +1
2017-11-13 09:46:00 <kaniini> fabled suggested seeking out a neutral party for mediation as an addition to the CoC
2017-11-13 10:01:26 <_ikke_> Who could / would act as a neutral party?
2017-11-13 10:11:18 <marble_visions> _ikke_: neutral party for what?
2017-11-13 10:13:00 <_ikke_> marble_visions: ncopa and kaniini were talking about the code of conduct
2017-11-13 10:27:46 <marble_visions> _ikke_: is there a public log? seems like my client hasn't been connected to the channel as I've thought
2017-11-13 10:35:12 <_ikke_> there is irclogger.com, but it looks broken right now
2017-11-13 10:38:31 <scadu> marble_visions: https://dev.alpinelinux.org/irclogs/
2017-11-13 10:59:11 <marble_visions> scadu: thanks
2017-11-13 12:21:10 <leo-unglaub> is there a command to download all files needed to build aports before actually starting to download them?
2017-11-13 12:21:39 <leo-unglaub> so for example it downloads all archives and stores them locally and then starts building the entire tree
2017-11-13 12:21:52 <ncopa> abuild fetch?
2017-11-13 12:22:19 <ncopa> for i in */; do (cd $i && abuild fetch); done
2017-11-13 12:25:27 <leo-unglaub> i am such an idiot ... i had $SRCDEST set to /tmp .... no wonder it was al gone after starting the laptop back up ...
2017-11-13 12:25:28 <leo-unglaub> sorry
2017-11-13 12:25:47 <ncopa> :-D
2017-11-13 12:26:01 <ncopa> use /var/tmp/
2017-11-13 12:26:20 <leo-unglaub> i should use /brain  before asking *g*
2017-11-13 15:57:11 <^7heo> I fucking swear
2017-11-13 15:57:22 <^7heo> firefox being single-threaded is going to be the only reason I stop using Alpine
2017-11-13 15:57:27 <^7heo> this is stupid AF.
2017-11-13 15:58:08 <^7heo> ncopa: is there a way we can get firefox to be multi-threaded?
2017-11-13 15:58:52 <ncopa> dunno
2017-11-13 15:58:56 <ncopa> i hafent looked at it
2017-11-13 15:59:03 <ncopa> how do you make ff multithread?
2017-11-13 15:59:09 <ncopa> is it a configure opt?
2017-11-13 15:59:09 <^7heo> no idea
2017-11-13 15:59:16 <^7heo> I just know that I have 4 cores, 8 threads
2017-11-13 15:59:19 <^7heo> and that it lags AF
2017-11-13 15:59:42 <ncopa> how do you know that it does not already use multiple threads?
2017-11-13 15:59:47 <^7heo> and that the performance optimizing dev tool complains that it's single threaded
2017-11-13 15:59:51 <^7heo> that ^
2017-11-13 16:00:31 <^7heo> "Realtime recording data disabled on non-multiprocess Firefox."
2017-11-13 16:02:10 <wWrAR07vpPZ1> chromium seems to work lately, not quite a replacement for ff but at least multiprocess
2017-11-13 16:02:27 <^7heo> yeah but chromium isn't an option for me.
2017-11-13 16:02:37 <^7heo> ncopa: I sent you a query with more details
2017-11-13 16:02:53 <wWrAR07vpPZ1> isn't the new multiprocess ff mostly equivalent to chromium?
2017-11-13 16:03:16 <^7heo> if by "mostly equivalent" you mean "does more or less the same with a completely different codebase"
2017-11-13 16:03:27 <^7heo> then I can say that "systemd" is equivalent to "openrc"
2017-11-13 16:03:48 <wWrAR07vpPZ1> most distinguishing features have been eliminated from ff
2017-11-13 16:03:58 <^7heo> yeah, not the plugins.
2017-11-13 16:04:06 <^7heo> also it's not all about features
2017-11-13 16:04:27 <wWrAR07vpPZ1> only in the old versions, in the new versions the plugins have been neutered to chromium levels
2017-11-13 16:04:54 <wWrAR07vpPZ1> that's why i'm sticking/holding on to ff-esr
2017-11-13 16:08:40 <MY_R> ^7heo: do you have in firefox setting/performance set more content process limit?
2017-11-13 16:09:08 <^7heo> MY_R: u w0t m8?
2017-11-13 16:09:16 <MY_R> and in about:config layers.acceleration.force-enabled set on true?
2017-11-13 16:09:27 <MY_R> ^7heo: in firefox you can set it up how many threads can use
2017-11-13 16:09:59 <^7heo> I didn't check that.
2017-11-13 16:10:03 <^7heo> I assumed it was a build setting.
2017-11-13 16:10:09 <MY_R> ...
2017-11-13 16:10:15 <^7heo> what? How come it's not?
2017-11-13 16:11:08 <^7heo> okay so
2017-11-13 16:11:15 <^7heo> should I restart it for the changes to take effect?
2017-11-13 16:11:38 <MY_R> ye
2017-11-13 16:11:42 <^7heo> ok
2017-11-13 16:11:57 <MY_R> fount that with content process limit?
2017-11-13 16:12:00 <MY_R> found
2017-11-13 16:12:12 <^7heo> ?
2017-11-13 16:13:12 <^7heo> again, what?
2017-11-13 16:13:13 <MY_R> so probably dont have it in browser, should be in alpine version in edge
2017-11-13 16:13:28 <^7heo> I have no idea what you're trying to tell me.
2017-11-13 16:13:40 <MY_R> 1s ...
2017-11-13 16:14:11 <^7heo> Oh you got time.
2017-11-13 16:14:17 <^7heo> I restarted firefox, you got a few minutes.
2017-11-13 16:14:23 <^7heo> it's faster to start windows millenium.
2017-11-13 16:15:31 <^7heo> MY_R: anyway your setting didn't change a thing.
2017-11-13 16:15:39 <^7heo> so I stand by my assumption: it's a build time setting.
2017-11-13 16:17:57 <MY_R> that was for gpu, it should speed up render the sites
2017-11-13 16:19:24 <MY_R> ^7heo: https://i.imgur.com/LWT3Jk1.png dont you have that?
2017-11-13 16:21:01 <^7heo> MY_R: ah, it's not a GPU problem...
2017-11-13 16:21:16 <^7heo> MY_R: I'll check it, one sec
2017-11-13 16:21:51 <^7heo> I have "content process limit"
2017-11-13 16:21:52 <^7heo> it's grayed
2017-11-13 16:21:55 <^7heo> and it's set to 1.
2017-11-13 16:21:58 <^7heo> so yeah...
2017-11-13 16:22:19 <^7heo> and as I said, disabled.
2017-11-13 16:22:29 <^7heo> are you running alpine?
2017-11-13 16:22:36 <MY_R> nah
2017-11-13 16:22:45 <^7heo> yeah so that's why.
2017-11-13 16:22:48 <MY_R> https://wiki.mozilla.org/Electrolysis/Multiple_content_processes
2017-11-13 16:23:13 <^7heo> MY_R: if you're not using alpine, it's not relevant.
2017-11-13 16:23:21 <^7heo> on other OSes too, firefox works much better.
2017-11-13 16:23:26 <^7heo> (for me)
2017-11-13 16:23:28 <MY_R> so musl or some missing dependency during build cus firefox since few version is damn fast, faster from chromium which had to use it....
2017-11-13 16:24:04 <MY_R> too bad cant access to firefox build log so that could tell us more
2017-11-13 16:24:24 <^7heo> I dunno if you can, ask ncopa for that
2017-11-13 16:24:36 <MY_R> I mean here: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/firefox
2017-11-13 16:24:44 <MY_R> all are just 404
2017-11-13 16:25:04 <^7heo> yeah so it's gone.
2017-11-13 16:46:01 <MY_R> ps ^7heo did you try with clean firefox? without any extension, new config? some extension can block that too
2017-11-13 16:46:34 <MY_R> another thing that can try enforce it and in some cases even should
2017-11-14 06:45:48 <foxkit> python3 printed "WARNING: unknown option --disable-rpath" while configure was running, just fwiw
2017-11-14 09:45:17 <ncopa> i'm looking at python3 stack size issue: https://github.com/docker-library/python/issues/211#issuecomment-341382592
2017-11-14 09:45:38 <ncopa> and i have a backtrace
2017-11-14 09:54:25 <danieli> ncopa: what does strace say on this manner?
2017-11-14 09:54:30 <danieli> has upstream changed the default stack size or something?
2017-11-14 09:54:54 <ncopa> no
2017-11-14 09:54:58 <ncopa> http://tpaste.us/nZzr
2017-11-14 09:55:01 <ncopa> thats the backtrace
2017-11-14 09:55:02 <ncopa> so
2017-11-14 09:55:09 <ncopa> the problem is default stack size is too small
2017-11-14 09:55:18 <danieli> did they change how it's detected?
2017-11-14 09:55:28 <ncopa> who?
2017-11-14 09:55:28 <danieli> do you know what exact version bump caused this?
2017-11-14 09:55:33 <danieli> python upstream
2017-11-14 09:55:33 <ncopa> no
2017-11-14 09:55:36 <danieli> i see
2017-11-14 09:56:00 <ncopa> i know that some python modules puts huge buffers on stack
2017-11-14 09:56:03 <ncopa> eg ujson
2017-11-14 09:56:12 <ncopa> they allocate 128k buffer on stack
2017-11-14 09:56:14 <ncopa> for no good reason
2017-11-14 09:56:17 <danieli> jeez
2017-11-14 09:56:20 <danieli> yeah there's some messy libs
2017-11-14 09:56:30 <ncopa> "it should be faster"
2017-11-14 09:56:32 <ncopa> they said
2017-11-14 09:56:40 <ncopa> i gave them numbers that it isnt
2017-11-14 09:56:48 <ncopa> and they still dont care
2017-11-14 09:57:01 <ncopa> so i thought that it would be better to fix those cases
2017-11-14 09:57:20 <ncopa> however, it looks like it is a recursive call that runs out of stack space
2017-11-14 09:58:02 <ncopa> he works around it by explicitly setting the stack size
2017-11-14 09:58:05 <ncopa> https://github.com/frol/flask-restplus-server-example/commit/ce37c281289910e3969b266be16350ddaac3168b
2017-11-14 09:58:13 <danieli> i saw
2017-11-14 09:58:25 <ncopa> but i think we cannot expect every python user do that in every python module...
2017-11-14 09:58:39 <ncopa> so i think we need fix this in python itself
2017-11-14 09:58:41 <ncopa> somehow
2017-11-14 09:59:30 <ncopa> from the backtrace it does not look like insane big buffers on stack
2017-11-14 10:03:36 <ncopa> but I dont really think there are any insane big buffers on stack
2017-11-14 10:03:48 <ncopa> it looks like its a recursive function in python
2017-11-14 10:03:52 <ncopa> http://tpaste.us/nZzr
2017-11-14 10:06:01 <ncopa> with a 530 calls deep trace, you only need 150 bytes on stack on each call to run out of stack space
2017-11-14 10:06:12 <danieli> that's a lot of calls, jeez
2017-11-14 10:06:26 <ncopa> looks recursive
2017-11-14 10:06:46 <danieli> if it looks recursive, walks recursive, and talks recursive...
2017-11-14 10:07:23 <^7heo> and with a stack trace of over 9000 calls; you need a super sayen
2017-11-14 10:07:33 <ncopa> it means its non-trivial to fix it "properly" if possible at all
2017-11-14 10:08:03 <danieli> how come it fails just on alpine?
2017-11-14 10:08:03 <^7heo> it would require fixing python
2017-11-14 10:08:14 <^7heo> danieli: glibc
2017-11-14 10:08:18 <ncopa> danieli: musl libc default stack size is only 80k
2017-11-14 10:08:21 <ncopa> glibc is 8MB
2017-11-14 10:08:28 <danieli> that's along the lines of what i was guessing
2017-11-14 10:08:33 <danieli> god damn glibc
2017-11-14 10:08:40 <^7heo> indeed
2017-11-14 10:08:49 <danieli> musl is like "use strict";
2017-11-14 10:08:59 <danieli> won't allow you to make many glibc-only idiot mistakes
2017-11-14 10:09:46 <ncopa> the musl reasoning is that you cannot expect to have 8MB default stack size, so if you need it you should explicitly request bigger stack
2017-11-14 10:09:56 <danieli> 8MB stack size is not a reasonable expection
2017-11-14 10:10:00 <^7heo> which 99% of software ues as features
2017-11-14 10:10:07 <danieli> well, we know the culprit, just need to figure out how to fix python
2017-11-14 10:10:11 <danieli> sigh
2017-11-14 10:10:13 <ncopa> 8MB is insane
2017-11-14 10:10:15 <^7heo>  < danieli> won't allow you to make many glibc-only idiot mistakes
2017-11-14 10:10:17 <^7heo> which 99% of software ues as features
2017-11-14 10:10:22 <^7heo> that
2017-11-14 10:10:34 <danieli> ncopa: agreed
2017-11-14 10:10:45 <ncopa> 80kb is tight. very tight
2017-11-14 10:10:51 <ncopa> specially on 64bit platforms
2017-11-14 10:11:40 <ncopa> we have patches for a handful packages in alpine, to explicitly set thread stack size
2017-11-14 10:12:11 <ncopa> oh whoops... i thought i was talking in #musl
2017-11-14 10:12:23 <ncopa> we need fix python, but the question is how
2017-11-14 10:12:44 <^7heo> ncopa: f it's big; it should go on the heap
2017-11-14 10:13:13 <ncopa> you cannot puth recursive calls on heap
2017-11-14 10:13:42 <ncopa> i looked for big buffers to put on heap, but it looks like problem is many small allocations
2017-11-14 10:13:45 <^7heo> not on this instance
2017-11-14 10:14:03 <ncopa> looks like python only have pointers allocated on stack
2017-11-14 10:14:06 <ncopa> not buffers
2017-11-14 10:14:08 <^7heo> the solution is to loop instead?
2017-11-14 10:15:01 <ncopa> well, i dont know if it is possible, but refactoring python to be iterative instead of recursive would solve it.
2017-11-14 10:15:12 <^7heo> indeed
2017-11-14 10:15:19 <ncopa> but that would likely require major refactoring
2017-11-14 10:15:22 <ncopa> if possible at all
2017-11-14 10:15:34 <^7heo> and could use the heap
2017-11-14 10:16:12 <^7heo> but yeah could be lots of work
2017-11-14 10:16:20 <^7heo> or not
2017-11-14 10:16:34 <^7heo> but probably wil be
2017-11-14 10:16:42 <^7heo> will*
2017-11-14 15:17:02 <ncopa> any objection that i set thread stack size to 1MB for python? http://tpaste.us/XEDZ
2017-11-14 15:17:17 <ncopa> we currently segfault before we hit the sys.getrecursionlimit()
2017-11-14 16:06:20 <przemoc> it sounds slightly hammerish, but if there is no better workaround for now, then having working python apps is better than non-working ones.
2017-11-14 16:07:00 <przemoc> problem with such bandaids is that they often last forever ;)
2017-11-14 16:23:55 <ncopa> they set stak size to 4MB on freebsd and 5MB on osx
2017-11-14 16:32:20 <przemoc> do they have any tests behind these settings?  I mean why exactly these values are used there, what's the reasoning behind them?
2017-11-14 16:32:33 <ncopa> no clue
2017-11-14 16:32:49 <ncopa> i think freebsd used to have 256k stack size
2017-11-14 16:32:51 <ncopa> or 512
2017-11-14 16:32:54 <ncopa> and apple too
2017-11-14 16:33:05 <ncopa> so i suspect its an old setting
2017-11-14 16:33:09 <ncopa> windows has 1MB iirc
2017-11-14 16:34:30 <ncopa> i tested where the limit is for musl on x86_64
2017-11-14 16:34:42 <ncopa> it segfaults on 452k stack
2017-11-14 16:35:06 <ncopa> and hits sys.getrecurslimit() with 453k stack
2017-11-14 16:35:59 <ncopa> it should be reported upstream
2017-11-14 16:38:31 <przemoc> so 512K should be enough?  or you want some greater margin for some reason?
2017-11-14 16:38:47 <ncopa> i want greater margin
2017-11-14 16:38:51 <ncopa> this was on x86_64
2017-11-14 16:38:57 <ncopa> i havent tested on s390x and ppc64le
2017-11-14 16:39:02 <ncopa> which i think has more registers
2017-11-14 16:45:40 <przemoc> amd64 has only 16 gp registers, ppc has 32 gp registers.  when you have more registers, you can do more in them and often use of the stack can be less actually.
2017-11-14 16:45:45 <przemoc> no idea about s390x, though
2017-11-14 16:53:02 <ncopa> but you also need more stack to do context switches
2017-11-14 18:25:24 <chrisb> any alpine able to boot broadcom or atheros SOC in WRT?
2017-11-14 19:52:59 <jirutka> kaniini: can we continue here?
2017-11-14 19:53:14 <kaniini> yes
2017-11-14 19:53:26 <kaniini> so your certificate is in pen
2017-11-14 19:53:28 <jirutka> kaniini: it’s standard self-signed PEM cert I’ve just generated, symlinked to /usr/local/share/ca-certificates, update-ca-certificates ignores it :/
2017-11-14 19:53:31 <kaniini> grr pem
2017-11-14 19:53:46 <kaniini> what happens if you copy it instead of symlink
2017-11-14 19:53:53 <jirutka> hm, cert store masked as a pen, interesting idea :P
2017-11-14 19:54:27 <jirutka> hmm, that helped
2017-11-14 19:54:31 <jirutka> why it does not like symlinks?
2017-11-14 19:54:51 <kaniini> dunno
2017-11-14 19:54:57 <kaniini> i will look once back at a computer
2017-11-14 19:54:59 <jirutka> this is something i want to have in /etc and under git, not somewhere in /usr/local when i forgot about it in a minute
2017-11-14 19:55:01 <jirutka> ok
2017-11-14 19:55:24 <kaniini> probably a stat(2) call that is too specific
2017-11-14 19:55:45 <jirutka> so that warning is totally unrelated
2017-11-14 19:56:21 <kaniini> the text yes
2017-11-14 19:58:09 <jirutka> ok, thx for help
2017-11-14 19:59:05 <jirutka> i’m a bit anxious now ’cause wanted to finish this setup an hour ago and instead i’m still in the office
2017-11-14 20:00:07 <kaniini> hmm
2017-11-14 20:01:48 <kaniini>         dir_readfiles(calinks, LOCALCERTSDIR, FILE_REGULAR, &proc_localglobaldir, fd);
2017-11-14 20:02:14 <kaniini> it ignores symlink
2017-11-14 20:02:21 <kaniini> i'm not a believer in this
2017-11-14 20:02:24 <kaniini> i'm going to rip it out :)
2017-11-14 20:04:50 <kaniini> jirutka: https://git.alpinelinux.org/cgit/ca-certificates/
2017-11-14 20:04:52 <kaniini> er
2017-11-14 20:05:02 <kaniini> jirutka: https://git.alpinelinux.org/cgit/ca-certificates/commit/?id=69215d7020d4c0346163644cd6669f01a5e6bb7c
2017-11-14 20:05:51 <jirutka> looks like git.a.o is down
2017-11-14 20:06:15 <_ikke_> nope, up here
2017-11-14 20:07:15 <jirutka> hm, right, http://downforeveryoneorjustme.com/git.alpinelinux.org says it’s up to, but i can’t even ping it, probably some local issue
2017-11-14 20:08:24 <_ikke_> and zabbix.a.o says it's up too (from uk)
2017-11-14 20:13:58 <kaniini> jirutka: ca-certificates-20171114-r0 in edge resolves this problem
2017-11-14 20:17:40 <jirutka> kaniini: thanks!
2017-11-14 20:19:29 <kaniini> some people have strange views on security, i suspect that "feature" was such a misguided security view
2017-11-14 20:19:50 <kaniini> "but somehow they can take over your ca-certificates store with symlinks!!!!"
2017-11-14 20:24:23 <danieli> chrisb: those are usually MIPS
2017-11-14 20:25:46 <danieli> kaniini: magic
2017-11-14 20:28:53 <foxkit> chrisb, if the CPU architecture starts with "mips" on the ddwrt/openwrt wiki, it won't work yet (but me and a few others are working on it!); if it starts with "arm", it's probably possible but I don't think anyone's tried it yet
2017-11-14 20:29:20 <danieli> foxkit: do you have a mips effort going already?
2017-11-14 20:29:33 <danieli> if so, i was not aware, and will back off from whatever i was doing regarding alpine on mips
2017-11-14 20:35:51 <foxkit> danieli, you are one of the few others working on it :P
2017-11-14 20:36:03 <foxkit> danieli, please do not stop.  I am mainly getting things ready while waiting for a working gcc.
2017-11-14 20:36:24 <foxkit> I have acquired some hardware, readied firmware, and so on
2017-11-14 20:36:57 <foxkit> I have a Linksys wrt54g v6, an imgtec Creator CI20, and an SGI Indy
2017-11-14 20:36:58 <danieli> foxkit: efforts are not synchronized at all
2017-11-14 20:37:03 <danieli> that is an issue
2017-11-14 20:37:27 <danieli> i am planning to talk with someone who most likely will sponsor build hardware and help with cc toolkits
2017-11-14 21:28:52 <kaniini> well, you could ask for #alpine-mips, and alpine-mips@lists.alpinelinux.org as a start :P
2017-11-14 21:49:02 <danieli> kaniini: that could be a good idea
2017-11-15 00:41:07 <foxkit> if alpine-mips becomes a thing let me know I will subscribe to it
2017-11-15 01:03:17 <danieli> foxkit: i'll ask ncopa tomorrow
2017-11-15 11:24:51 <ncopa> tmh1999_: i have a feeling that openmp is broken on s390x
2017-11-15 11:44:47 <ncopa> imagemagick tests hangs
2017-11-15 11:44:55 <ncopa> but if i disable openmp things seems to be ok
2017-11-15 16:16:17 <dj32> HI guys, quick question, I'd like to contribute to the https://git.alpinelinux.org/cgit/mkinitfs/ repo. I wonder that's the right way to submit PRs there
2017-11-15 16:17:23 <_ikke_> dj32: You can submit PRs on githuh
2017-11-15 16:17:37 <_ikke_> https://github.com/alpinelinux/aports
2017-11-15 16:18:07 <dj32> so the equivalent for mkinitfs is https://github.com/alpinelinux/mkinitfs
2017-11-15 16:18:42 <dj32> am i right _ikke_ ?
2017-11-15 16:23:06 <jirutka> yes
2017-11-15 16:24:43 <dj32> perfect! thanks guys. I'm going to cleanup and extend this https://github.com/alpinelinux/mkinitfs/pull/16
2017-11-15 16:25:55 <dj32> I would love to know if you guys have any opinion about that, like .. is it something you would like to add or that's crazyness and we will never support it?
2017-11-15 16:28:42 <jirutka> tbh i can’t imagine specific use case when it may be useful
2017-11-15 16:34:51 <dj32> mine, for example.
2017-11-15 16:35:09 <dj32> I need to create a self contained vm
2017-11-15 16:35:49 <dj32> that can support updates without having to deal with updating individual files
2017-11-15 16:36:42 <dj32> this allows me to use an iso or a raw image without having to connect an external drive and do updates seamlessy
2017-11-15 16:36:59 <dj32> (my customer doesn't have to touch the vm)
2017-11-15 16:37:39 <dj32> and OS on ramdisk helps in security and repeatability
2017-11-15 16:41:40 <dj32> It's an hard blocker that I'm trying to fix for a project and I will be happy to contribute, it will also help alpine in supporting a use case that other distros support (Ubuntu, Centos, Debian, etc)
2017-11-15 16:46:16 <dj32> jirutka: I can go into details if necessary
2017-11-15 17:34:22 <tmh1999_> ncopa : can you check if /proc/cpuinfo had vx instructions ? that's for SIMD, which from z13 starts support
2017-11-15 17:37:16 <tmh1999_> such a shame only starting at z13, they start support SIMD, SMT. well eventually these machines are more on IO side, rather than CPU side
2017-11-15 18:37:51 <ncopa> tmh1999_: the /proc/cpuinfo: http://tpaste.us/yaQd
2017-11-15 18:38:14 <ncopa> whoops. wrong machine
2017-11-15 18:39:01 <tmh1999_> i just checked, it seems the linuxone community server has vx
2017-11-15 18:39:04 <ncopa> http://tpaste.us/YnB6
2017-11-15 18:39:05 <tmh1999_> idk why but im building too
2017-11-15 18:39:07 <ncopa> thats the cpuinfo
2017-11-15 18:39:45 <tmh1999_> wow wow
2017-11-15 18:40:08 <tmh1999_> so, I am on the docker image s390x/alpine:3.6, upgrade to edge, build with openmp good
2017-11-15 18:40:46 <tmh1999_> i just commented the 3 lines disabling openmp on s390x arch
2017-11-15 18:40:50 <tmh1999_> in APKBUILD
2017-11-15 18:41:33 <tmh1999_> well i guess another thing related to container env
2017-11-15 18:43:27 <shreyansh_k> guys, when is the next release coming? It will be nice to avoid rebasing a new project in it's early development to new version if it is coming soon.
2017-11-15 18:45:03 <ncopa> a couple of weeks
2017-11-15 18:45:10 <ncopa> before 1 dec
2017-11-15 18:46:13 <shreyansh_k> ncopa: guess I'll wait for the release then. Thanks.
2017-11-16 01:02:52 <foxkit> jirutka (or anyone else): does pcre2 pass test suite on ppc64le with --enable-jit?  the jit core is falling to pieces in ppc64 BE..
2017-11-16 01:03:29 <jirutka> foxkit: I don’t know, let’s ask rnalrd
2017-11-16 01:03:42 <foxkit> it seems to work okay on ppc which is 32-bit BE, but 64-bit BE is throwing sigill and when I disassemble the JIT'd code it is not even ppc insns, it looks almost like x86 or arm..
2017-11-16 01:35:17 <leo-unglaub> good evening
2017-11-16 02:08:59 <jirutka> let me introduce you esh, simple template system based on shell, implemented in ~160 lines of shell and awk :) https://github.com/jirutka/esh
2017-11-16 02:09:36 <jirutka> leo-unglaub: evening :)
2017-11-16 02:12:31 <leo-unglaub> what is your goal with esh?
2017-11-16 02:12:39 <leo-unglaub> and is there an aport for it? ;)
2017-11-16 02:12:39 <danieli> ^
2017-11-16 02:13:18 <jirutka> leo-unglaub: to use it for templating configs, e.g. nginx
2017-11-16 02:14:03 <jirutka> I haven’t released 0.1.0 yet, I’ll create abuild for it after first release, probably tomorrow
2017-11-16 02:15:49 <leo-unglaub> the code looks nice
2017-11-16 02:15:58 <jirutka> thanks :)
2017-11-16 02:16:58 <jirutka> a week ago i’ve released https://github.com/jirutka/sloci-image, also shell + awk
2017-11-16 02:18:57 <jirutka> but i realized that docker still does not support OCI images :( my intention is to have a lightweight solution for creating images for ppl who wants container images
2017-11-16 02:19:32 <jirutka> btw OCI “standard” is really ridiculous…
2017-11-16 02:20:07 <leo-unglaub> well, with ncopa we have an inside source to docker. maybe he knows if they want to add that soon
2017-11-16 02:20:45 <leo-unglaub> https://github.com/jirutka/sloci-image/blob/master/sloci-image#L152 uff, have fun debugging this later on *g*
2017-11-16 02:21:20 <leo-unglaub> 
ACTION would have used the match statement from rust for this *g*

2017-11-16 02:21:21 <jirutka> yeah, this was the hardest part…
2017-11-16 02:24:04 <jirutka> i wanted to make it behave correctly even when user provide some strange input with spaces, quotes etc.
2017-11-16 02:24:53 <leo-unglaub> hahaha, you could have written a state machine in shell to parse this to *g*
2017-11-16 02:25:06 <leo-unglaub> oh boy, i need to get to sleep before i get more crazy ideas *g*
2017-11-16 02:25:08 <leo-unglaub> see you laster
2017-11-16 02:26:27 <jirutka> me too, good night :)
2017-11-16 06:39:14 <Xe> jirutka: doesn't near every PL these days come with some kind of templating support built-in?
2017-11-16 06:39:49 <Xe> also, isn't shell basically designed to template strings?
2017-11-16 11:21:14 <jirutka> Xe: yes, but not shell
2017-11-16 11:21:58 <jirutka> Xe: ehm, write a template for config file or something similar just in shell ;)
2017-11-16 13:37:11 <xentec> jirutka: in case you didn't notice I've updated my mkinitfs PR: https://github.com/alpinelinux/mkinitfs/pull/17#discussion-diff-151101843L103. a merge would help me to work with static kernels
2017-11-16 13:37:43 <jirutka> xentec: yeah, i will look at it later and respond to your comments
2017-11-16 13:37:55 <xentec> thanks
2017-11-16 16:03:42 <marble_visions> 
ACTION has successfully solved the wiki capcha on the third attempt

2017-11-16 16:04:00 <ncopa> w00t! congrats!
2017-11-16 16:04:19 <marble_visions> i had to open up a text pad to enter the whole number and count digits :D
2017-11-16 16:04:25 <marble_visions> ncopa: thanks :)
2017-11-16 16:05:29 <_ikke_> appending a * by default if non is available would be nice
2017-11-16 16:05:34 <_ikke_> non is present
2017-11-16 16:11:44 <Xe> jirutka: honestly if you want portable containers, make a chroot in a tarball
2017-11-16 16:11:56 <Xe> that's portable between docker, rocket and all of the other big memes
2017-11-16 16:12:54 <jirutka> Xe: I know, the point is to provide it in some format that uneducated docker users can directly use
2017-11-16 16:13:42 <jirutka> what I do _is_ just a tarball of chroot, with OCI boilerplate around
2017-11-16 16:14:56 <Xe> jirutka: or just tell people to do: `$ curl https://hostname.domain.tld/path/to/stuff.tar.gz | gunzip | docker import - organzation/name:tag`
2017-11-16 16:15:30 <jirutka> and then they must set up entrypoint and other metadata…
2017-11-16 16:15:30 <Xe> which literally just lets you import any tarball you could otherwise chroot into
2017-11-16 16:16:06 <Xe> jirutka: what's wrong with `/entrypoint.sh` for things that have one?
2017-11-16 16:16:16 <jirutka> *and other metadata*
2017-11-16 16:17:57 <Xe> why not codegen dockerfiles based on the OCI metadata?
2017-11-16 16:18:14 <jirutka> sigh
2017-11-16 16:19:05 <jirutka> i want to produce an image that can be imported to various container runners, not a description for building an image
2017-11-16 16:20:09 <Xe> jirutka: see how `docker save` and `docker load` work? i think you might be able to take a tarball of an oci image and make it fit into that format
2017-11-16 16:20:25 <jirutka> and i wanted to avoid generating some proprietary docker-only format; actually i wanna avoid docker at all, that’s why I used OCI; unfortunately I haven’t checked if docker already supports it before writing it, I naively expected that it is already supported since this OCI “standard” for images is already stable
2017-11-16 16:20:48 <Xe> docker doesn't support it AFAICT from the documentation i've read
2017-11-16 16:21:03 <jirutka> yes, that’s the problem; they don’t support it yet
2017-11-16 16:21:14 <Xe> that's why i'm guiding you towards using things in the docker ecosystem, dockerfiles can import tarballs to an image
2017-11-16 16:21:18 <kaniini> containerd supports OCI
2017-11-16 16:21:41 <kaniini> docker is not really for running containers anymore, it just wraps containerd for that now
2017-11-16 16:21:52 <jirutka> yes, but not docker… and most ppl who wants images are brainless docker users
2017-11-16 16:22:08 <Xe> there's no need to call people brainless
2017-11-16 16:22:58 <jirutka> I’m just trying to explain you that the whole point of this is to provide something in standard format what can any BFU, who has no idea how things work (which is majority of docker users IMO), use
2017-11-16 16:23:01 <Xe> iirc docker only uses OCI metadata when dockerd wants to set up a container for containerd to run
2017-11-16 16:23:27 <jirutka> yes, there’s OCI image and OCI runtime format, OCI image is converted to OCI runtime before running
2017-11-16 16:23:50 <Xe> jirutka: i'm just trying to say that there's no reason to be rude to people whom you want to install software you package
2017-11-16 16:24:57 <Xe> go ask #docker?
2017-11-16 16:25:04 <Xe> they probably know better
2017-11-16 16:25:20 <jirutka> I’m not rude, instead of saying them GTFO when they start screaming about docker image, I’m trying to provide them a solution that will work for them without me resigning on my principles
2017-11-16 16:25:51 <Xe> i didn't say you were rude, i said you were _being_ rude
2017-11-16 16:26:09 <jirutka> what should I ask? I know that there’s an unfinished PR for OCI image import
2017-11-16 16:26:19 <jirutka> I know that rkt and some others already support it
2017-11-16 16:26:29 <Xe> well
2017-11-16 16:26:31 <Xe> the status
2017-11-16 16:26:34 <jirutka> and that docker actually doesn’t have much motivation for it…
2017-11-16 16:26:35 <Xe> if a PM can get it prioritized
2017-11-16 16:26:42 <Xe> or if there is actually any upstream want for this
2017-11-16 16:27:49 <jirutka> it was a mistake from me to mention sloci-image here, ’cause I don’t like talking about docker
2017-11-16 16:28:21 <jirutka> and I haven’t write project goals and idea behind to the readme yet, so it apparently caused some misunderstanding
2017-11-16 16:28:37 <Xe> it's not, i think the mistake was labeling docker users `brainless`, which is a really great image to have as a chop
2017-11-16 16:29:12 <jirutka> it’s based on my experience…
2017-11-16 16:29:29 <jirutka> I follow [alpine] on StackOverflow
2017-11-16 16:29:41 <Xe> that doesn't mean it's nessecarily right to say it
2017-11-16 16:30:34 <jirutka> I’d rather end this discussion now, I don’t wanna someone slap me with CoC
2017-11-16 16:32:52 <jirutka> btw https://github.com/moby/moby/issues/25779
2017-11-16 16:33:11 <jirutka> and https://github.com/moby/moby/pull/33355
2017-11-16 16:33:28 <leo-unglaub> jirutka: i acidently commited both in the same pull request: https://github.com/alpinelinux/aports/pull/2735
2017-11-16 16:33:45 <leo-unglaub> should i delete it and do it again or can you merge it like that anyway?
2017-11-16 16:34:13 <jirutka> leo-unglaub: no, just remove the last commit and force push, and create a separate branch/PR to the second one
2017-11-16 16:34:44 <leo-unglaub> jirutka: how can i tell github to not automatically add everything to the same pull request? by putting it into branches?
2017-11-16 16:34:55 <jirutka> leo-unglaub: of course…
2017-11-16 16:35:05 <jirutka> leo-unglaub: pull request is based on a branch
2017-11-16 16:35:05 <leo-unglaub> okay, will do
2017-11-16 16:35:25 <jirutka> aha, I see, you’ve pushed it into your master
2017-11-16 16:35:27 <leo-unglaub> i hate pull requests ... i never have to do them *g* i normally always have direct commit access *g*
2017-11-16 16:35:39 <jirutka> you’ve never created a branch…?
2017-11-16 16:35:47 <jirutka> b/c PR is just a branch from git PoV
2017-11-16 16:35:53 <leo-unglaub> usually i work in the master
2017-11-16 16:35:59 <jirutka> well…
2017-11-16 16:36:08 <leo-unglaub> old cvs tradition *g*
2017-11-16 16:38:30 <jirutka> understand
2017-11-16 16:38:48 <jirutka> CVS is so bad that it’s basically unusable as VCS :)
2017-11-16 16:39:00 <leo-unglaub> it's awesome *g*
2017-11-16 16:39:16 <leo-unglaub> but i am older than you, i grew up with that shit *g*
2017-11-16 16:39:42 <leo-unglaub> this new "use your browser to create a pr stuff" is hard to learn for me ... but i try
2017-11-16 16:41:30 <jirutka> I really like what Linus said about CVS :)
2017-11-16 16:42:02 <jirutka> i’d understand that, but your problem now is pure-git, how to create a branch, not PR ;)
2017-11-16 16:42:13 <jirutka> about PR, you can do it from CLI, with some GitHub client
2017-11-16 16:42:36 <jirutka> i should finally write some simple tool for that, I don’t like any of existing I found :/
2017-11-16 16:42:59 <Xe> jirutka: yeah that PR looks solid, i don't like a few ways they do testing (they don't take advantage of testing.T New, but that might be in order to be compatible with older versions of go?) but overall it should do the job well.
2017-11-16 20:15:21 <clandmeter> jirutka: looks like the lld tests on build-edge-armhf are failing
2017-11-16 20:15:38 <clandmeter> failing as in they hang
2017-11-16 20:16:21 <clandmeter> http://tpaste.us/K6LB
2017-11-17 00:18:23 <leo-unglaub> jirutka: so, i spend the last hours reading up on this github stuff and i hope now i got it right
2017-11-17 00:21:04 <jirutka> leo-unglaub: hours? that looks more like learning git in decent detail :)
2017-11-17 00:21:41 <leo-unglaub> jirutka: yes, i did. read all about git. even those rebasing stuff
2017-11-17 00:22:06 <jirutka> leo-unglaub: that’s great! you’ve surely appreciate this knowledge :)
2017-11-17 00:22:20 <jirutka> git is very powerful and awesome :)
2017-11-17 00:22:23 <leo-unglaub> i hope so, i want to becme more active in aports
2017-11-17 00:22:32 <leo-unglaub> now that i have this awesome cpu, i want to compile stuff
2017-11-17 00:23:06 <jirutka> what CPU do you have?
2017-11-17 00:23:43 <leo-unglaub> and threadripper 16 cores, 32 hyperthreaded :)
2017-11-17 00:24:07 <jirutka> that’s quite good
2017-11-17 00:24:17 <jirutka> what model?
2017-11-17 00:25:01 <leo-unglaub> the fastest
2017-11-17 00:25:16 <leo-unglaub> 1900x
2017-11-17 00:25:28 <jirutka> and vendor?
2017-11-17 00:25:38 <leo-unglaub> amd
2017-11-17 00:26:06 <jirutka> so hopefully without embedded spying co-system running on MINIX :)
2017-11-17 00:26:11 <leo-unglaub> yes
2017-11-17 00:26:15 <leo-unglaub> no management engine
2017-11-17 00:26:36 <danieli> i have a prototype 12-core amd cpu laying around, i used to do some number crunching on it
2017-11-17 00:26:52 <danieli> no ME or AMT
2017-11-17 00:27:01 <danieli> i'm on an older fx-9590 atm
2017-11-17 00:27:21 <jirutka> actually even AMD has something like that, from what I read :( but it seems that not so dreadfully capable as the thing in Intel
2017-11-17 00:28:08 <danieli> and not fully as common, depends on the series and models
2017-11-17 00:28:17 <jirutka> aha
2017-11-17 00:33:02 <sh4rm4> anyone seen this error with firefox on ARM? Assertion failure: !joinable(), at firefox-52.4.0esr/js/src/threading/Thread.h:122
2017-11-17 00:46:37 <Xe> sh4rm4: which website does that come up on?
2017-11-17 00:48:31 <sh4rm4> it comes up when starting firefox
2017-11-17 00:49:02 <sh4rm4> then it segfaults
2017-11-17 00:49:12 <sh4rm4> i.e. i cant get firefox working at all due to this
2017-11-17 00:49:56 <Xe> sh4rm4: does running firefox through strace tell you anything useful?
2017-11-17 00:50:09 <sh4rm4>  i merged basically all alpine patches (even the arm grsec patch) but it doesnt help either...
2017-11-17 00:50:32 <sh4rm4> so i thought you guys may have increased musl's pthread stack limit or something, but nope
2017-11-17 00:51:41 <sh4rm4> hmm, that was actually a good tip, Xe
2017-11-17 00:51:46 <sh4rm4> [pid 26422] mremap(0x7efd6000, 4096, 8192, 0) = -1 ENOMEM (Out of memory)
2017-11-17 00:51:47 <sh4rm4> [pid 26422] mremap(0x7efd5000, 4096, 8192, 0) = -1 EFAULT (Bad address)
2017-11-17 00:52:34 <sh4rm4> so it seems the 400 MB RAM in this netbook is too little to even start firefox ^_^
2017-11-17 00:52:48 <Xe> ouch
2017-11-17 00:53:23 <Xe> sh4rm4: midori or other similar small browsers might work?
2017-11-17 00:53:35 <danieli> lynx
2017-11-17 00:54:05 <sh4rm4> i was running firefox 29 so far without issues (well, apart from that i couldnt open more than like 3-4 tabs and it was really sluggish)
2017-11-17 00:55:03 <sh4rm4> but since i had mistakenly compiled my entire sys with softfloat, i recompiled everything with new X libs... so no dice using the old firefox again
2017-11-17 00:55:32 <sh4rm4> well, anyway ... thanks for help
2017-11-17 00:55:42 <Xe> no problem sh4rm4
2017-11-17 02:31:12 <dj32> Hello
2017-11-17 02:31:14 <dj32> question
2017-11-17 02:31:28 <dj32> is it possible to create an initramfs from docker?
2017-11-17 02:32:24 <dj32> I'm using mkinitfs but when I test it out it goes in kernel panic
2017-11-17 11:15:34 <nmeum> jirutka: is there any particular reason why community/llvm4 doesn't conflict with main/llvm5?
2017-11-17 11:16:08 <danieli> nmeum: why would it conflict?
2017-11-17 11:20:44 <nmeum> huh, strange during an upgrade I got a message that a file contained in llvm5 was already shipped by llvm4, however, that doesn't seem to be the case anymore
2017-11-17 11:20:57 <nmeum> nevermind I guess
2017-11-17 12:31:54 <ncopa> looks like everythin for v3.7 built in 'main' now
2017-11-17 12:32:32 <ncopa> i will make the builders halt on errors and report build errors
2017-11-17 12:53:23 <jirutka> nmeum: yes, it does not conflict ;) it’s made in a way to allow installing multiple llvm versions in parallel (but not their -dev IIRC)
2017-11-17 13:25:18 <rdutra> ncopa: good!
2017-11-17 13:27:23 <rdutra> guess we can have the rc1 today
2017-11-17 13:28:46 <ncopa> im bootstrapping ghc now
2017-11-17 13:28:57 <ncopa> ghc is painful
2017-11-17 13:32:20 <ncopa> would be nice to have new kernel too
2017-11-17 13:32:22 <ncopa> 4.9.62
2017-11-17 15:29:05 <leo-unglaub> good evening my friends !
2017-11-17 15:29:24 <leo-unglaub> good evening my friends!
2017-11-17 15:44:07 <ncopa> hi
2017-11-17 15:44:23 <ncopa> jirutka: any clue what goes wrong here: http://build.alpinelinux.org/buildlogs/build-3-7-ppc64le/community/lua-mpack/lua-mpack-1.0.7-r0.log
2017-11-17 17:20:52 <jirutka> ncopa: I have a proposal: remove lua5.2, keep just lua5.3 as the latest version, plus lua5.1 purely for LuaJIT… WDYT?
2017-11-17 17:21:42 <jirutka> i don’t see any value in supporting lua5.2
2017-11-17 17:22:30 <jirutka> with purely for LuaJIT I mean changing also install_if to pull luajit, don’t build lua5.1 pkgs for platforms that don’t support LuaJIT etc.
2017-11-17 17:22:42 <ncopa> probably a good idea to reduce number of supported lua
2017-11-17 17:22:50 <ncopa> we can look at it after v3.7 release
2017-11-17 17:23:10 <Xe> ACF would probably need to be ported to 5.3, it currently depends on 5.2
2017-11-17 17:23:18 <jirutka> and maybe even renaming lua5.1-* to luajit-* ?
2017-11-17 17:23:21 <Xe> also prosody
2017-11-17 17:24:00 <jirutka> there should not be any problem, lua5.3 is mostly backward compatible with lua5.2
2017-11-17 17:24:40 <jirutka> i hope that there’s no software supporting only lua5.2, i.e. not 5.3 or 5.1
2017-11-17 20:52:04 <ollieparanoid[m]> build-edge-armhf is still stuck as clandmeter noted above: http://build.alpinelinux.org/ - is there anything I can do to help with resolving this?
2017-11-17 20:54:23 <_ikke_> uncrustify is the last package I see that is failing
2017-11-17 20:54:25 <_ikke_> http://build.alpinelinux.org/buildlogs/build-edge-armhf/community/uncrustify/uncrustify-0.66-r0.log
2017-11-17 20:58:21 <_ikke_> 557/798 Test #557: cpp_33057 ........................***Failed    0.21 sec
2017-11-17 21:08:23 <ollieparanoid[m]> _ikke_: here's the commit that added the testcase for the 0.66 release:
2017-11-17 21:08:24 <ollieparanoid[m]> https://github.com/uncrustify/uncrustify/commit/4f60ddd1ea70bfc59b83fc3a308a35cfc0d5646e
2017-11-17 21:10:42 <ollieparanoid[m]> _ikke_: wait, does this mean it is currently failing at this package and not ldd?
2017-11-17 21:11:18 <clandmeter> i can disable the tests for armhf and restart it
2017-11-17 21:11:41 <_ikke_> ollieparanoid[m]: I don't know :-)
2017-11-17 21:13:09 <_ikke_> I just look at the log of #alpine-commits
2017-11-17 21:14:04 <ollieparanoid[m]> ah right, I really need to join that channel :D
2017-11-17 21:14:15 <ollieparanoid[m]> clandmeter: thanks!
2017-11-17 21:15:12 <clandmeter> ollieparanoid: what about aarch64?
2017-11-17 21:15:56 <ollieparanoid[m]> the aarch64 buildbot does not seem to be stuck from that status page (build.archlinux.org) or is that out of date?
2017-11-17 21:16:27 <_ikke_> ollieparanoid[m]: wrong distro :P
2017-11-17 21:17:06 <ollieparanoid[m]> err... sorry :D build.alpinelinux.org of course
2017-11-17 21:17:59 <_ikke_> How do you see if it's stuck? By seeing it's on the same package for a long time?
2017-11-17 21:18:38 <ollieparanoid[m]> yes
2017-11-17 21:18:47 <ollieparanoid[m]> right now it says "idle"
2017-11-17 21:21:03 <_ikke_> I cannot find lld in the build logs: http://build.alpinelinux.org/buildlogs/build-edge-armhf/community/
2017-11-17 21:23:23 <ollieparanoid[m]> yeah it seems to be missing, also the link it points to is broken
2017-11-17 21:23:23 <ollieparanoid[m]> but thanks for looking at it!
2017-11-17 21:24:11 <_ikke_> That's about all I can do :D
2017-11-17 21:46:53 <_ikke_> ollieparanoid[m]: just noticed that edge-armhf is running again
2017-11-17 21:47:15 <_ikke_> build/build-edge-armhf pulling git
2017-11-17 21:47:17 <clandmeter> yes she is back to work
2017-11-17 21:47:33 <_ikke_> Was just looking at the page, and it just started to change
2017-11-17 21:47:56 <clandmeter> protobuf
2017-11-17 21:48:13 <_ikke_> That's what's behind it?
2017-11-17 21:48:49 <_ikke_> Oh, that's what's it building
2017-11-17 21:49:46 <ollieparanoid[m]> _ikke_: yeah, clandmeter disabled the tesuite (thanks!) now and kicked it off again :)
2017-11-17 21:50:37 <clandmeter> i asked jirutka to fix it, but i guess he didnt find the time.
2017-11-17 21:50:45 <clandmeter> so for now just disable tests on armhf
2017-11-17 21:50:48 <ollieparanoid[m]> btw: could someone explain me, what the graphs mean exactly on build.alpinelinux.org? aport built and aport total
2017-11-17 21:50:52 <jirutka> clandmeter: fix what?
2017-11-17 21:51:23 <_ikke_> clandmeter: was it lld that was stuck?
2017-11-17 21:51:37 <jirutka> ollieparanoid[m]: heh, these graphs are super-confusing, it should not be showed as progress bar
2017-11-17 21:51:38 <clandmeter> yes lld on armhf
2017-11-17 21:51:47 <_ikke_> ok
2017-11-17 21:52:55 <jirutka> clandmeter: how can i fix it? i don’t have access to any armhf machine
2017-11-17 21:53:21 <clandmeter> i think i gave you before?
2017-11-17 21:53:46 <jirutka> it doesn’t work anymore, for quite long time
2017-11-17 21:53:49 <jirutka> after some outage
2017-11-17 21:54:34 <clandmeter> hmm
2017-11-17 21:54:38 <clandmeter> i dont see it in the list
2017-11-17 21:54:41 <clandmeter> i can give you one
2017-11-17 22:28:18 <leo-unglaub> can someone please explain to me what happened here? https://travis-ci.org/alpinelinux/aports/jobs/303759506
2017-11-17 22:28:23 <leo-unglaub> to me that is a travis error
2017-11-17 22:28:55 <Xe> leo-unglaub: https://travis-ci.org/alpinelinux/aports/jobs/303759506#L635
2017-11-17 22:28:59 <Xe> no tests defined
2017-11-17 22:29:26 <clandmeter> its mandatory on travis now
2017-11-17 22:29:28 <Xe> in your apkbuild set `options="!check"` or define shell function check that will run tests
2017-11-17 22:30:25 <clandmeter> only set !check if you cannot run any tests.
2017-11-17 22:30:46 <leo-unglaub> okay, i disable the tests there as well because there are no usefull tests in the package
2017-11-17 22:30:48 <leo-unglaub> thanks to you both
2017-11-17 22:33:28 <_ikke_> leo-unglaub: someone suggested to check if the program runs
2017-11-17 22:34:02 <leo-unglaub> _ikke_: i read that but i strongly disagree with it. program --version is NOT a usefull test. if thats my kind of test, i can skip it alltogether
2017-11-17 22:36:38 <clandmeter> it can be useful when the buildtools are broken and doesnt exit correctly.
2017-11-17 23:02:09 <leo-unglaub> i have to go, but there are currently 16 builds running (1 on every CPUI core *g*) ... expect more pull requests soon
2017-11-17 23:03:14 <jirutka> leo-unglaub: better program --version than no test at all… this at least verifies that the binary is not totally broken
2017-11-17 23:19:57 <shafire> hi
2017-11-18 00:44:52 <foxkit> while I agree, that doesn't help lib packages.  really don't know what to do with those.
2017-11-18 09:53:40 <jirutka> foxkit: well, if upstream doesn’t provide any tests (shame on them!), then `options="!check"  # no tests available`
2017-11-18 11:11:37 <ollieparanoid[m]> if someone has time to look at it, build-edge-armhf is failing at the silver surfer now: http://build.alpinelinux.org/buildlogs/build-edge-armhf/main/the_silver_searcher/the_silver_searcher-2.1.0-r2.log
2017-11-18 16:22:11 <BitL0G1c> anyone noticed fail2ban segfaulting on 4.9.60-0-virthardened
2017-11-18 16:22:11 <BitL0G1c>  but not on 4.9.32-0-virthardened ?
2017-11-18 17:38:14 <ollieparanoid[m]> clandmeter: as I understand, build-edge-armhf needs to build musl first, so the silver searcher compilation works. kaniini added GNU typedefs for fopencookie in musl here: https://github.com/alpinelinux/aports/commit/bf0205104ba520e7d2fea17704a1cc131551c3d3#diff-3a7db20d065741ab43ab3d1faa1ba929 which is required by the_silver_searcher (see its failing log)
2017-11-18 19:30:19 <_ikke_> Should abuild automatically detect that firefox depends on mesa-gl? It seems to be missing
2017-11-18 19:38:42 <_ikke_> (libGL.so)
2017-11-18 20:11:16 <jirutka> _ikke_: yeah, if it is dynamically linked, then abuild should detect it
2017-11-18 20:11:46 <_ikke_> On testing, someone had issues running firefox, saying it was missing
2017-11-18 20:12:07 <jirutka> hm, maybe because of mesa upgrade?
2017-11-18 20:12:25 <_ikke_> just installing mesa-gl it was fixed
2017-11-18 20:12:38 <jirutka> yeah, it’s really missing in firefox dependencies
2017-11-18 20:12:43 <jirutka> so we need to add it
2017-11-18 20:12:45 <_ikke_> ok
2017-11-18 20:13:08 <_ikke_> what
2017-11-18 20:13:24 <_ikke_> When do you need to add it manually, and when does it get autodetected?
2017-11-18 20:43:31 <foxkit> it likely uses dlopen
2017-11-18 20:43:43 <foxkit> abuild detects libraries that are declared with DT_NEEDED in the binary itself
2017-11-18 20:43:49 <foxkit> i.e. -lFOO passed to ld
2017-11-18 20:43:55 <_ikke_> ah, ok
2017-11-18 20:43:56 <foxkit> but dlopen("foo") won't show up
2017-11-18 20:44:10 <_ikke_> static dependencies, not dynamic dependencies
2017-11-18 20:48:35 <jirutka> yeah, exactly
2017-11-18 20:48:50 <jirutka> aha, static dependencies are not tracked as well
2017-11-18 20:49:40 <jirutka> foxkit: just curious, is there even some way how to track static deps in arbitrary binaries?
2017-11-18 20:50:27 <foxkit> static dependencies?  do you mean like a binary that is linked to a libfoo.a file?
2017-11-18 20:50:42 <foxkit> there's really no way to track what .a files a binary is linked to once ld has been run
2017-11-18 20:51:09 <jirutka> foxkit: yes
2017-11-18 20:51:13 <foxkit> my best guess for a way of doing that would be replacing 'ld' with a shim that looked at the invocation.. but that'd be messy and error-prone.
2017-11-18 20:52:18 <jirutka> why it’d error prone?
2017-11-18 20:52:48 <jirutka> . /it’d/would it be/
2017-11-18 20:57:25 <foxkit> you would have to figure out yourself whether the linker would prefer .so or .a in libpath
2017-11-18 20:57:29 <foxkit> and resolve libpath yourself
2017-11-18 20:57:38 <jirutka> aha
2017-11-18 20:57:48 <foxkit> and misc other oddities... esp per-arch
2017-11-18 20:57:52 <foxkit> each arch has its own rules
2017-11-18 20:58:06 <jirutka> and patching linker would be even more messy
2017-11-18 20:59:36 <foxkit> yeah
2017-11-18 21:05:55 <jirutka> foxkit: btw do you have some experience with Rust? to be more specific, with rust build system
2017-11-18 21:07:46 <foxkit> jirutka: I have never touched Rust, the language nor its build system
2017-11-18 21:08:08 <foxkit> jirutka: well that is kind of untrue... I investigated it in detail, and found I didn't /want/ to touch it.
2017-11-18 21:08:15 <_ikke_> lol
2017-11-18 21:08:42 <jirutka> foxkit: that’s pity; we need someone to set up cross-compilation of rustc for other arches
2017-11-18 21:08:53 <foxkit> I have some scripts from a kind soul and some instruction on how to build it from first principles (that is, taking the original rust ocaml source, so that I don't have to touch mozilla's potentially-trojaned binaries)
2017-11-18 21:09:07 <foxkit> but I've never tried it, it would have to build rust a full 53 times, crossing from glibc to musl and back 3 or 4 times
2017-11-18 21:09:58 <jirutka> compiling from ocaml source would be insane
2017-11-18 21:10:37 <foxkit> it's the only way to be sure :(
2017-11-18 21:11:21 <foxkit> unfortunately it is not like go where you could trust gcc and get to a point where you wouldn't need google binary
2017-11-18 21:11:26 <jirutka> I also don’t like that you must trust some prebuilt binary, but isn’t that the same with C and other self-hosted langs?
2017-11-18 21:11:29 <foxkit> there is no bootstrap from another trusted thing
2017-11-18 21:12:02 <foxkit> jirutka, not entirely; you can build gcc with clang (and even msvc on windows) and 'prove' that it is not bugged by checking sha512 hash (the binary should be identical)
2017-11-18 21:12:04 <jirutka> Go is totally different thing, it’s not a low level lang as Rust, I don’t understand why ppl still compare them…
2017-11-18 21:12:39 <jirutka> hm, is it really identical when you build it with different compiler that use different optimization methods?
2017-11-18 21:12:41 <foxkit> jirutka: the only other self-hosted lang I can think of would be go and that's why I compared it.
2017-11-18 21:13:29 <foxkit> jirutka, gcc compiles itself with itself to ensure that doesn't matter.  that is why gcc build takes some minutes: it builds 'xgcc' which is built with system compiler (suncc, clang, msvc) and uses xgcc to build real gcc.
2017-11-18 21:13:39 <foxkit> jirutka, but if you can confirm xgcc has no bugs, you can trust it to create a gcc that has no bugs
2017-11-18 21:13:49 <foxkit> so the code only needs to be audited once
2017-11-18 21:14:27 <jirutka> aha
2017-11-18 21:14:52 <jirutka> foxkit: but there’s a hope in https://github.com/thepowersgang/mrustc
2017-11-18 21:16:58 <Xe> foxkit: as long as you can build go 1.4.x, you can build go 1.(>4).x, so you don't need to download compiler binaries
2017-11-18 21:18:48 <jirutka> why is discussion turning to go again?! :(
2017-11-18 21:20:53 <foxkit> Xe, that is correct
2017-11-18 21:21:17 <foxkit> jirutka: because it is a better situation than rust and we can't understand why moz, who is supposed to be a friend of open-source, would require us to trust binaries
2017-11-18 21:22:29 <jirutka> foxkit: yes, it’s better situation in that sense, but otherwise it’s like comparing apples and oranges
2017-11-18 21:22:47 <Xe> jirutka: why does the fact that it's go matter?
2017-11-18 21:23:13 <jirutka> foxkit: I’m also quite disappointed by Rust direction, especially with Cargo
2017-11-18 21:24:02 <foxkit> jirutka: our position in adelie is that we are likely going to just ship otter or midori as default browser and drop firefox once -esr is using rust.  we don't plan to ever support or package rust.
2017-11-18 21:24:22 <jirutka> Xe: tl;dr because I really dislike Go for many reasons and don’t wanna talk about it
2017-11-18 21:24:38 <foxkit> jirutka: specifically because of 1 trusting binaries 2 the cargo requiring cargo thing 3 the difficulty porting it to not-x86_64
2017-11-18 21:25:03 <jirutka> foxkit: that’s very unfortunate decision; have you looked at https://github.com/thepowersgang/mrustc ? this may be a solution, someday
2017-11-18 21:25:06 <foxkit> jirutka: I realise and appreciate that alpine cannot take the same position, but this is why I don't know anything about rust
2017-11-18 21:26:00 <jirutka> foxkit: that said, it’s actually quite good that we can point to some distro and say that their approach is problematic
2017-11-18 21:26:12 <jirutka> foxkit: with “their” I mean Rust devs
2017-11-18 21:26:40 <foxkit> jirutka: mrustc is interesting and I hope they can succeed, but it will be long and difficult road for them, not the least because rust is a constantly churning language
2017-11-18 21:26:52 <foxkit> moz only knows web stuff, so they think standards are mutable, but a programming language can't be so mutable
2017-11-18 21:26:56 <foxkit> and they have not figured that out yet
2017-11-18 21:27:20 <jirutka> foxkit: I’d understand depending on binary for bootstrap, at least in short-term, but the situation with Cargo is really uterly stupid (and you probably even don’t know about other problems with Cargo)
2017-11-18 21:27:45 <foxkit> I only know that it requires itself
2017-11-18 21:27:47 <foxkit> which is silly
2017-11-18 21:27:50 <jirutka> yes
2017-11-18 21:28:51 <jirutka> so we need to create a pressure on them to finally start thinking about outer world
2017-11-18 21:33:10 <jirutka> tbh I wish someone take great ideas from Rust (especially memory management and FP features in low-level lang) and create new lang with minimalism in mind, something like Lua in high-level langs
2017-11-18 22:12:40 <foxkit> jirutka: https://adeliedev.blogspot.com/2017/11/official-stance-on-rust.html
2017-11-18 22:12:51 <foxkit> I am not sure if this helps, but it is something that can be linked.
2017-11-18 22:13:14 <_ikke_> foxkit: Did you just wrote that up?
2017-11-18 22:13:20 <foxkit> yes
2017-11-18 22:14:08 <jirutka> foxkit: thanks you!
2017-11-18 22:14:21 <foxkit> :)
2017-11-19 02:57:50 <foxkit> for further discussions with me, use email
2017-11-19 18:47:56 <andypost> any idea why `shift` could give "Permission denied" or I messing lines in abuild? https://github.com/alpinelinux/aports/pull/2765
2017-11-19 18:48:44 <_ikke_> andypost: shift?
2017-11-19 18:49:13 <jirutka> andypost: missing `cd` https://github.com/alpinelinux/aports/pull/2765/files#diff-e5787886fffc24de397d34fa35ae6655R46
2017-11-19 18:49:56 <jirutka> also pls remove prepare(), applying patches is already in the default prepare
2017-11-19 18:53:56 <andypost> jirutka, thanx a lot, I thought I missread abuild source
2017-11-19 18:54:24 <jirutka> andypost: np :)
2017-11-19 18:54:40 <andypost> 
ACTION hates this kind of bugs(

2017-11-20 04:20:17 <jml2> hi
2017-11-20 11:07:21 <przemoc> https://lwn.net/SubscriberLink/739183/9f9a3fead5c5a159/  it seems that SPDX is also being adopted in Linux kernel
2017-11-20 11:13:11 <jirutka> good, I wanted to unify license= in APKBUILDs after v3.7
2017-11-20 11:13:18 <jirutka> currently it’s chaos
2017-11-20 11:13:51 <ncopa> that would be a good idea
2017-11-20 11:13:59 <ncopa> i think the way to do it is to add a check in abuild
2017-11-20 11:14:11 <ncopa> so it fails if the license is "wrong"
2017-11-20 11:14:31 <jirutka> fix currently abuilds in mass and add check, yes
2017-11-20 11:14:53 <ncopa> add check and and fix in mass
2017-11-20 11:15:19 <ncopa> i wonder if we should have a licenses package
2017-11-20 11:15:22 <ncopa> or similar
2017-11-20 11:15:31 <jirutka> licenses package?
2017-11-20 11:15:38 <ncopa> so packages chould only provide a symlink to the license file
2017-11-20 11:15:50 <ncopa> for example
2017-11-20 11:16:03 <jirutka> hm, isn’t it sufficient to just specify license in metadata, when it’s a standard license?
2017-11-20 11:16:04 <ncopa> we have /usr/share/licenses/GPLv2
2017-11-20 11:16:25 <ncopa> lots of packages ship a copy of the text
2017-11-20 11:16:27 <jirutka> instead of copying whole license file or creating symlinks for something nobody actually want? :)
2017-11-20 11:16:37 <jirutka> yes, ’cause we currently don’t have any rule for it
2017-11-20 11:17:01 <ncopa> then the abuild check could verify that the  license exisis in /usr/share/licenses
2017-11-20 11:17:18 <ncopa> if it doesnt, then you have misspelled GPLv2 or however we want it to be written
2017-11-20 11:17:24 <jirutka> it’s needed to copy license file in case of custom licenses, but I’m not sure about software that use one of standard licenses…
2017-11-20 11:17:27 <przemoc> we agreed some time ago to use SPDX, but no one back then stepped in to fix it and it's no wonder as it's very unforgiving and invisible work.  IIRC awilfox/foxkit said that he'll try to fix that to some extent, but I haven't tracked his attempts in that regards (or anyone else, to be honest)
2017-11-20 11:17:45 <jirutka> s/he/she/
2017-11-20 11:18:03 <ncopa> alternatively we have a file with the SPDX list
2017-11-20 11:18:09 <jirutka> i didn’t know that we’ve agreed about SPDX, IIRC there’s still outdated info on wiki
2017-11-20 11:18:11 <ncopa> and check the license against that
2017-11-20 11:18:20 <ncopa> we talked about it some time ago
2017-11-20 11:18:32 <ncopa> and at the time nobody complained
2017-11-20 11:18:49 <jirutka> okay, let’s do it after v3.7
2017-11-20 11:19:10 <ncopa> https://spdx.org/licenses/
2017-11-20 11:19:13 <ncopa> yeah
2017-11-20 12:10:29 <duncan^> I have a program that makes use of the libintl. It's supposedly provided by gettext (and libelf-dev, as is gettext-dev and all that is installed), but I get some awful errors "undefined reference to libintl_gettext". Any pointers?
2017-11-20 12:16:45 <ncopa> duncan^: i think you need add -lintl to linker flags
2017-11-20 12:38:52 <duncan^> ncopa: cheers. I'll try that.
2017-11-20 12:52:29 <danieli> ncopa: thoughts on an #alpine-mips and alpine-mips@lists.a.o?
2017-11-20 13:39:50 <przemoc> damn, forgot to add same comment to my second mkinitfs patch, nokernel-related one, as was in my first one: "I think it should be applied in aports too, stable included."
2017-11-20 16:55:49 <jirutka> ncopa: could you please release new version of mkinitfs ?
2017-11-20 16:56:24 <jirutka> ncopa: changes: https://github.com/alpinelinux/mkinitfs/compare/v3.1.0...HEAD
2017-11-20 17:01:18 <jirutka> ncopa: please don’t merge apkbuild updates disabling check() without reason (written as a short comment after options=, more detail in commit message if needed)
2017-11-20 18:29:56 <mitchty> can i just say i hate linkers, think i'm hitting a bug in ld.gold, so I switched to ld.bfd, but that generates other broken links on arm
2017-11-20 18:38:42 <przemoc> I don't get it, jirutka.  5 hours ago I sent 2 patches for mkinitfs to -devel ML.  yet few hours later you pushed flattened change, which was committed apparently 5 days ago.
2017-11-20 18:39:29 <jirutka> przemoc: xentec was faster https://github.com/alpinelinux/mkinitfs/pull/17
2017-11-20 18:39:34 <jirutka> przemoc: I just forgot to merge it
2017-11-20 20:01:23 <_ikke_> Somehow openjdk7 keeps failing to build on x86
2017-11-20 20:24:59 <jammers> what is the path in alpine for auto hardware detection? Installed alpine on ARMHF device using chroot method (cant mod uboot or kernel on this board) ) It boots fine, but no hardware is detected or modules loaded.
2017-11-20 20:25:26 <_ikke_> jammers: Not necessary to ask the same question twice in different channels
2017-11-20 20:25:36 <jammers> sorry
2017-11-20 20:27:33 <jammers> ikkie, looked thru most of the alp wiki with no luck on that topic
2017-11-20 20:27:47 <_ikke_> --> #alpine-linux
2017-11-20 20:27:48 <jammers> even google fell flat
2017-11-21 07:06:32 <ncopa> jirutka: ok, i'll have a look at mkinitfs and make a release
2017-11-21 07:07:47 <ncopa> jirutka: do you think you could take care of the PR reviewing for a while, since you seem to have strong opinion on how it should be done
2017-11-21 07:08:11 <ncopa> i can work on getting the builders completed meanwhile, so we can get the rc1 out
2017-11-21 07:08:45 <ncopa> i didn't want the PR queue grow too big
2017-11-21 10:03:28 <jirutka> ncopa: PR reviewing in mkinitfs?
2017-11-21 10:41:32 <ncopa> jirutka: no, i was thinking aports
2017-11-21 11:19:30 <fabled> i wonder what's up with the builders
2017-11-21 11:19:58 <fabled> https://github.com/alpinelinux/aports/pull/2782
2017-11-21 11:19:58 <fabled> http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/gnumeric/gnumeric-1.12.35-r1.log -> failure due to itstool not finding python3 but it got installed
2017-11-21 11:19:58 <fabled> http://build.alpinelinux.org/buildlogs/build-edge-armhf/main/linux-rpi/linux-rpi-4.9.63-r0.log -> bc not found, but it's in makedepends
2017-11-21 11:21:12 <fabled> i wonder if it's kernel bug, disk corruption or apk issue
2017-11-21 11:22:35 <^7heo> it doesn't have to be xor.
2017-11-21 11:23:10 <fabled> ncopa, any ideas?
2017-11-21 11:25:55 <ncopa> i'll have a look
2017-11-21 11:28:15 <ncopa> build-edge-armhf is currently busy
2017-11-21 11:28:24 <ncopa> will have to look when it has stopped
2017-11-21 11:30:32 <ncopa> bc is there and seems o be working
2017-11-21 11:30:40 <fabled> shell issue then?
2017-11-21 11:30:43 <fabled> or musl?
2017-11-21 11:31:49 <ncopa> it can happen if there is a missing SO
2017-11-21 11:31:57 <ncopa> musl is unlikely
2017-11-21 11:32:06 <ncopa> and so is libreadline.so.7 too
2017-11-21 11:32:12 <ncopa> i have no clue what happened there
2017-11-21 11:32:28 <ncopa> its building kernel now
2017-11-21 11:33:31 <fabled> how about gnumeric on ppc64le ?
2017-11-21 11:34:27 <fabled> ncopa, btw. look at http://build.alpinelinux.org/buildlogs/build-edge-armhf/main/linux-rpi/linux-rpi-4.9.63-r0.log
2017-11-21 11:34:36 <fabled> it's executing split function before build
2017-11-21 11:34:44 <ncopa> i'll have a look at ppc64le
2017-11-21 11:54:44 <fabled> ncopa, seems openjdk7 got built. the 'abort' seems to be sporadic/random
2017-11-21 11:56:41 <ncopa> hum
2017-11-21 11:56:42 <ncopa> not good
2017-11-21 11:57:30 <ncopa> i suspect the gnumeric issue was that itstool autodetected python2 while the explicit depends was set to py3-libxml2
2017-11-21 11:57:42 <ncopa> itstool build
2017-11-21 11:58:04 <fabled> yes
2017-11-21 11:58:51 <fabled> girara fails still
2017-11-21 11:58:57 <fabled> test suite catches something
2017-11-21 13:15:08 <ncopa> i have no clue why girara fails
2017-11-21 13:15:21 <ncopa> im fixing python3/tkinter
2017-11-21 13:17:15 <ncopa> i wonder if we can do a rc1 release even if not everything in main builds yet
2017-11-21 14:22:50 <fabled> we changed to virtual /bin/sh dependency?
2017-11-21 14:22:52 <fabled> ncopa, ^
2017-11-21 14:25:21 <fabled> seem sso
2017-11-21 14:25:57 <ncopa> yes, some time ago
2017-11-21 14:30:47 <ncopa> was adeilie devs who wanted that
2017-11-21 14:32:35 <fabled> ok. no worries. i just somehow missed that.
2017-11-21 19:41:57 <fcolista> skarnet, you around?
2017-11-21 19:50:53 <skarnet> fcolista: what's up? busyish, but I'll be around-ish all evening
2017-11-21 19:54:38 <_ikke_> munin is missing MasterBuilder.pm
2017-11-21 19:59:38 <jirutka> skarnet: when you’re here, can I bring your attention to https://github.com/alpinelinux/aports/pull/2783 ? :)
2017-11-21 20:20:03 <jirutka> skarnet: hm, it’d be really beneficial to make execline as single multi-call binary as busybox, the execline pkg is huge just b/c it contains many supertiny binaries :/
2017-11-21 20:21:04 <jirutka> skarnet: anyway, what I wonder is if execline pipeline provides some guarantees that `sh -c 'x | y'` does not
2017-11-21 20:30:56 <skarnet> multi-call binary wouldn't help much if you're already linking the binaries against shared libskarnet
2017-11-21 20:31:08 <skarnet> there's not that much duplicated code
2017-11-21 20:31:32 <skarnet> also, multicall helps a bit with disk usage, but is bad for RAM and CPU usage
2017-11-21 20:32:14 <skarnet> sh -c 'x | y' leaves the original shell around, execline's pipeline doesn't. That's the only difference.
2017-11-21 20:32:59 <skarnet> you can use a shell if you don't mind keeping it around, but even OpenRC needs to actually kill the daemon and not the shell when it brings the service down, so you'll need to find something to make it work.
2017-11-21 20:33:43 <skarnet> jirutka ^
2017-11-21 21:48:21 <jirutka> skarnet: thx
2017-11-21 21:52:13 <jirutka> skarnet: tiny note, README.macosx is outdated, it’s called just macOS now, so README.macos
2017-11-21 22:05:40 <jirutka> ncopa: would you mind if I take over maintainership of PostgreSQL?
2017-11-22 04:28:50 <lizzzy> Busybox cve https://www.twistlock.com/2017/11/20/cve-2017-16544-busybox-autocompletion-vulnerability/
2017-11-22 05:18:45 <Xe> seems upstream patch https://git.busybox.net/busybox/commit/?id=c3797d40a1c57352192c6106cc0f435e7d9c11e8 fixes it
2017-11-22 05:31:52 <Xe> i am testing the sploit
2017-11-22 05:31:58 <Xe> and then testing if the patch fixes it
2017-11-22 05:34:15 <Xe> i wasn't able to replicate the failure when doing `ls ./<tab>`, but i was able to replicate it by trying to execute the file the POC creates
2017-11-22 05:35:49 <Xe> after that patch is applied, i cannot tab-complete the name of the file
2017-11-22 05:37:02 <Xe> pasting the name of the file as tab-completed earlier, when i try to run the file it still shows the blank and colored text
2017-11-22 05:37:42 <Xe> cool
2017-11-22 06:16:44 <Xe> I have made an automated tester image here: https://github.com/Xe/cve-2017-16544, i am submitting a PR that includes the fix for the aforementioned CVE, but i will need to do more testing for the other one
2017-11-22 06:23:25 <Xe> https://github.com/alpinelinux/aports/pull/2788
2017-11-22 06:29:06 <dsabogal> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=busybox
2017-11-22 06:29:25 <dsabogal> it seems theres 3 CVEs in busybox 1.27.2
2017-11-22 06:31:28 <Xe> the other ones are CVE-2017-15874 and CVE-2017-15873, i'll add patches for them to that PR and amend the title
2017-11-22 06:53:52 <fabled> ncopa, i take a look at girare test suite
2017-11-22 07:09:50 <fabled> looks like glib changed behaviour for an api call and broke the girara test suite
2017-11-22 07:14:45 <fabled> ncopa, filed https://git.pwmt.org/pwmt/girara/issues/1
2017-11-22 09:45:39 <ncopa> fabled: so we disable that specific test for now?
2017-11-22 09:48:28 <fabled> perhaps
2017-11-22 09:48:35 <ncopa> we have a circular dep
2017-11-22 09:48:36 <fabled> it's two tests related $home
2017-11-22 09:48:57 <ncopa> perl-datetime and perl-datetime-timezone
2017-11-22 09:49:38 <fabled> it's checkdepends
2017-11-22 09:49:50 <ncopa> perl-datetime depends on perl-datetime-timezone
2017-11-22 09:49:57 <fabled> perl-datetime-timezone checkdepends on the other
2017-11-22 09:50:06 <ncopa> and perl-datetime-timezone checkdepends on  perl-datetime
2017-11-22 09:50:10 <ncopa> yeah
2017-11-22 09:50:18 <fabled> i thought checkdepends circularity is allowed
2017-11-22 09:50:39 <fabled> i added it just few days ago
2017-11-22 09:50:39 <ncopa> that would require that we built the full repo without tests
2017-11-22 09:50:49 <ncopa> and then re-build it again with tests enabled
2017-11-22 09:50:57 <fabled> hmmh
2017-11-22 09:51:18 <fabled> but we have other check circularities there too
2017-11-22 09:51:37 <fabled> are you just saying that this was the wrong time to add it?
2017-11-22 09:51:46 <ncopa> not sure
2017-11-22 09:51:56 <ncopa> i can manually do it too
2017-11-22 09:52:03 <ncopa> build it witout tests
2017-11-22 09:52:06 <ncopa> and the rebuild it with tests
2017-11-22 09:52:44 <ncopa> but i dont know if we want to deal with all those manually
2017-11-22 09:52:52 <ncopa> so im not sure what to do
2017-11-22 09:53:03 <ncopa> i'd prefer not allow circular deps even with checkdepends
2017-11-22 09:53:28 <ncopa> basically
2017-11-22 09:53:31 <ncopa> those are the options:
2017-11-22 09:53:42 <ncopa> - disallow circular deps in checkdepends
2017-11-22 09:54:10 <ncopa> - build world without checks (checks are only built locally by developer)
2017-11-22 09:54:30 <ncopa> - build world twice, once without tests and another time with tests
2017-11-22 09:55:29 <ncopa> - deal with circular deps manually - someone logs in to build server and build the packages failing twice (without and with checks)
2017-11-22 09:56:17 <ncopa> the "build world twice" option can be optimized
2017-11-22 09:57:18 <ncopa> the build order resolver would need to detect all the circual checkdepends, and only disable checks for those first run
2017-11-22 09:57:31 <ncopa> and rebuild those second run
2017-11-22 09:57:52 <ncopa> but that would require some major changes in the build scripts
2017-11-22 09:59:48 <xentec> ncopa: is there a todo/wish list of breaking changes for abuild?
2017-11-22 10:00:17 <ncopa> xentec: not that i know
2017-11-22 12:46:17 <ncopa> Xe: thanks for the fix for busybox CVEs!
2017-11-22 13:19:11 <ncopa> ollieparanoid[m]: directfb is causing problems for us: https://github.com/alpinelinux/aports/pull/2654#issuecomment-346329731
2017-11-22 13:19:31 <ncopa> that was the reason why i removed it in first place
2017-11-22 15:31:38 <ncopa> any volunter to fix tomahawk, sword, geany-plugins and coturn?
2017-11-22 15:45:02 <clandmeter> coturn still broken?
2017-11-22 15:54:36 <fcolista> working on tomahawk
2017-11-22 17:03:46 <Xe> ncopa: no problem, always fun to test patches
2017-11-23 07:43:49 <ncopa> we only have aarch64 builder left now for v3.7
2017-11-23 07:44:01 <ncopa> we should try fix as many of the bugs as possible now
2017-11-23 13:36:44 <andypost> ncopa, how to deal with ones that have no check()? https://github.com/alpinelinux/aports/pull/2765
2017-11-23 13:37:37 <rdutra> andypost: if upstream does no provide test you can try something like  ./binary --help > /dev/null
2017-11-23 13:37:48 <rdutra> andypost: or add options="!check"
2017-11-23 13:38:47 <andypost> rdutra, basically some tests fail, actually the same amount as before, so ~check looks compromise, thanx
2017-11-23 13:39:26 <rdutra> andypost: if some tests fails you can also try to open a bug upstream (maybe they can help)
2017-11-23 13:40:33 <jirutka> andypost: rdutra: disabling check completely should be the last option, in the case of applications ./binary --version or something like that is still better than noting
2017-11-23 13:40:47 <rdutra> 
ACTION agrres

2017-11-23 13:40:50 <rdutra> agrees*
2017-11-23 13:41:03 <rdutra> jirutka: that's what I meant there, not sure if was clear, thanks
2017-11-23 13:41:26 <jirutka> andypost: rdutra: and when you disable check, *always* write reason as comment (e.g. `options="!check"  # no tests available`) and more detailed description into commit message if needed
2017-11-23 13:41:47 <andypost> jirutka, great idea! https://github.com/alpinelinux/aports/blob/master/main/rsync/APKBUILD#L9 at leas a comment
2017-11-23 13:41:50 <ncopa> andypost: would be nice to find out why the test fails
2017-11-23 13:42:00 <ncopa> if its a bug in test suite or in the lib/app
2017-11-23 13:42:39 <ncopa> we have found previously unknown security vulnerabilities thanks to those tests
2017-11-23 13:42:41 <andypost> yes, but it may depend on arch so not possible to get results for all envs
2017-11-23 13:42:42 <jirutka> if just few tests from the test suite fail and you don’t know why, then it’s preferred to disable just failing tests
2017-11-23 13:43:41 <andypost> oh that better!
2017-11-23 13:43:41 <jirutka> and of course try to find out why it fail; sometimes the problem is that tests are broken, sometimes that it really doesn’t work and software must be fixed
2017-11-23 13:44:41 <jirutka> yes, we sometimes disable test for specific architectures when they hang for example; when there are test failures for specific arches, it’s better to let them run and just don’t fail the build when they fail
2017-11-23 13:45:53 <jirutka> example: https://github.com/alpinelinux/aports/blob/master/main/llvm5/APKBUILD#L122-L131
2017-11-23 13:55:45 <andypost> jirutka, thanx a lot, that very helpful
2017-11-23 13:55:53 <jirutka> andypost: you’re welcome!
2017-11-23 17:08:54 <n3mur1t0r> hello, I have a question: how can I set a dependecy that is in the community repo for a package that is in the main repo?
2017-11-23 17:09:18 <_ikke_> n3mur1t0r: That's against policy
2017-11-23 17:11:41 <n3mur1t0r> oh, I see
2017-11-23 17:11:44 <n3mur1t0r> thanks
2017-11-23 17:13:40 <n3mur1t0r> maybe the package is mistakenly put in the community repo?
2017-11-23 17:13:44 <n3mur1t0r> the thing is
2017-11-23 17:14:06 <_ikke_> usually it depends on how long the support for a specific version is
2017-11-23 17:14:16 <n3mur1t0r> py-twisted requires, among other things, py-service_identity, which is in the community repo
2017-11-23 17:14:28 <n3mur1t0r> but that doesn't really make sense, as the other dependencies are all in the main one
2017-11-23 17:14:45 <_ikke_> n3mur1t0r: you have to check with the maintainer of that package
2017-11-23 17:48:40 <jirutka> n3mur1t0r: if package A, that is already in main, requires a new dependency B, that is currently in the community, then we should decide if A should be really in main, or move B to A
2017-11-23 17:49:06 <jirutka> n3mur1t0r: if there are more packages depending on A in the main repo, than move B to the community
2017-11-23 18:07:11 <n3mur1t0r> yes, there are more packages
2017-11-23 18:07:27 <n3mur1t0r> I already have a PR on github with one of them, and will update it with the others
2017-11-23 18:08:20 <jirutka> then move the pkg to main as part of this PR
2017-11-23 18:08:37 <jirutka> and add comment to the commit moving the pkg that it’s a dependency of another package from main
2017-11-23 18:09:43 <n3mur1t0r> ok, sure thing
2017-11-23 18:09:46 <n3mur1t0r> thank you
2017-11-23 18:09:51 <jirutka> yw
2017-11-23 21:00:14 <ncopa> wow...
2017-11-23 21:00:18 <ncopa> looks like its all done!
2017-11-23 21:02:23 <_ikke_> build.a.o shows minetest still being built?
2017-11-23 21:03:10 <ncopa> it was all done right before i re-enabled minetest
2017-11-23 21:03:19 <_ikke_> ah ok
2017-11-23 21:03:39 <_ikke_> yeah, now it's done
2017-11-23 21:04:05 <ncopa> \o/
2017-11-23 21:04:13 <ncopa> this is fantastic!
2017-11-23 21:04:24 <_ikke_> So it's now possible to tag rc1?
2017-11-23 21:06:41 <ncopa> exactly!
2017-11-23 21:08:00 <ncopa> can you please hold the breath while i tag rc1
2017-11-23 21:08:06 <ncopa> or at least hold git push...
2017-11-23 21:08:07 <_ikke_> 
ACTION holds breath

2017-11-23 21:08:28 <ncopa> wait
2017-11-23 21:08:52 <ncopa> i need test the image generator
2017-11-23 21:25:03 <ncopa> op
2017-11-23 21:25:04 <ncopa> ok
2017-11-23 21:25:08 <ncopa> hold your breath...
2017-11-23 21:25:32 <Xe> yay minetest
2017-11-23 21:26:41 <ncopa> minetest was the last stopper
2017-11-23 21:26:58 <ncopa> i considered just drop support for aarch64, but the fix was simple
2017-11-23 21:27:41 <ncopa> 3.7.0_rc1 is popping in the oven...
2017-11-23 21:28:11 <fcolista> \0/
2017-11-23 21:29:13 <clandmeter> _ikke_: start  breathing again!
2017-11-23 21:29:21 <_ikke_> 
ACTION fainted

2017-11-23 21:30:03 <ncopa> its done!
2017-11-23 21:30:04 <ncopa> wow
2017-11-23 21:30:07 <ncopa> rc1 is out!
2017-11-23 21:30:10 <ncopa> i cant believe it!
2017-11-23 21:30:36 <_ikke_> \o/
2017-11-23 21:32:47 <_ikke_> topic update time :P
2017-11-23 21:34:06 <fcolista> :)
2017-11-23 21:34:42 <ncopa> now we need write release notes
2017-11-23 21:34:44 <ncopa> and fix bugs
2017-11-23 21:34:48 <ncopa> and test
2017-11-23 21:35:12 <ncopa> one of the new things is support for uefi!
2017-11-23 21:35:31 <ncopa> i'd say UEFI is the biggest news in this release :)
2017-11-23 21:35:48 <Xe> okay, that means i can ditch centos on my home cluster
2017-11-23 21:35:50 <Xe> \o/
2017-11-23 21:36:04 <clandmeter> i can trash macos now :)
2017-11-23 21:38:22 <ncopa> we should try fix as many bugs as possible now
2017-11-23 21:38:47 <Xe> link to the ISO?
2017-11-23 21:41:37 <ncopa> http://dl-cdn.alpinelinux.org/alpine/v3.7/releases
2017-11-23 21:41:50 <Xe> thanks
2017-11-23 21:41:59 <ncopa> dunno which is the best https mirror
2017-11-23 21:42:06 <Xe> seems i'm too early lol
2017-11-23 21:42:21 <ncopa> should get the checksums or signatures via https at least
2017-11-23 21:42:30 <ncopa> need to sleep
2017-11-23 21:42:34 <Xe> http://dl-4.alpinelinux.org/alpine/v3.7/releases/x86_64/ <-- can't see anything
2017-11-23 21:42:58 <ncopa> wil probably sync in 20 mins
2017-11-23 21:45:51 <Xe> what bootloader are you using for efi?
2017-11-24 01:50:48 <jirutka> clandmeter: please respond to https://bugs.alpinelinux.org/projects/alpine/activity?from=2017-10-26
2017-11-24 01:56:08 <Shiz> you sure thats the corect link?
2017-11-24 01:57:33 <Shiz> Xe: afaik grub
2017-11-24 02:01:29 <jirutka> Shiz: no it’s not :(
2017-11-24 02:02:01 <jirutka> clandmeter: this one http://bugs.alpinelinux.org/issues/7986
2017-11-24 02:02:17 <jirutka> Shiz: I have something even for you! are you happy? :) http://bugs.alpinelinux.org/issues/8028
2017-11-24 02:03:02 <Shiz> oh yeah that one
2017-11-24 02:03:05 <Shiz> fuck it kept slipping my mind
2017-11-24 02:03:13 <Shiz> (sorry ncopa)
2017-11-24 02:05:17 <jirutka> okay, going to sleep, gn!
2017-11-24 02:05:32 <Shiz> i'll have my dev laptop back tomorrow
2017-11-24 02:05:34 <Shiz> after 3 weeks
2017-11-24 02:05:36 <Shiz> :)
2017-11-24 08:14:27 <clandmeter> jirutka: ok
2017-11-24 08:17:38 <clandmeter> jirutka: 3.5 to 3.6 upgrade  http://tpaste.us/oZeM looks like caused by https://github.com/alpinelinux/aports/commit/d6d624a149ca62af8679baf9cc99ce1354c190f0
2017-11-24 13:23:15 <ncopa> I have also bumped into the nginx upgrade issue. I think we need move the dir in a pre- upgrade script
2017-11-24 13:44:21 <Shiz> i wonder if it's an apk bug tbh
2017-11-24 13:46:29 <ncopa> Well, problem is that renaming .apk-new does not work if target is a directory
2017-11-24 13:46:59 <ncopa> It's a symlink and existing is a dir
2017-11-24 13:47:22 <ncopa> We should move the content anyways
2017-11-24 13:47:44 <_ikke_> I filed a bug for that
2017-11-24 13:48:03 <_ikke_> which was closed
2017-11-24 13:48:43 <_ikke_> no, not closed, resolved I meant
2017-11-24 13:48:45 <_ikke_> https://bugs.alpinelinux.org/issues/8057#change-21846
2017-11-24 14:06:29 <jirutka> clandmeter: I’ve already fixed this bug…
2017-11-24 14:07:46 <jirutka> but probably forgot to backport it to 3.6 :(
2017-11-24 14:12:40 <jirutka> https://github.com/alpinelinux/aports/commit/1b7a02dada936a48f24416fc7e1f4e1d9e059aea#diff-ec3b3bfb7978b51922c10a183e982dba
2017-11-24 15:19:47 <vkrishn> ncopa: did you forget #7178 ?
2017-11-24 15:20:52 <ncopa> vkrishn: yes
2017-11-24 15:21:05 <vkrishn> its been set for v3.7
2017-11-24 15:21:44 <jirutka> clandmeter: could you please respond to http://bugs.alpinelinux.org/issues/7986#note-2 ?
2017-11-24 15:41:37 <clandmeter> jirutka: done
2017-11-24 21:40:48 <dsabogal> ncopa: it seems that the recent 4.9.65 hardened patch changes the sublevel (i.e. 4.9.59)
2017-11-25 01:10:33 <m4chm4n> is it possible to mine cryptocoins on alpine?
2017-11-25 01:11:42 <Xe> if you use AMD, probably?
2017-11-25 12:22:42 <jirutka> omfg, i read more about IME and then about google’s NERF and I’d like to throw all x86_64 systems to trash; this is insane, both IME and NERF, so typical google, just replace one shit with another shit
2017-11-25 12:24:29 <jirutka> Richard Stallman was so right :(
2017-11-25 12:26:38 <jirutka> btw you know what’s interesting? Apple ships Intel in MacBooks, but with disabled IME!
2017-11-25 12:58:53 <wWrAR07vpPZ1> jirutka: what's wrong with nerf?
2017-11-25 12:59:41 <wWrAR07vpPZ1> i'm running heads(the basis for nerf) and i'm quite happy with it
2017-11-25 12:59:56 <scadu> 
ACTION awaits RISC-based laptops

2017-11-25 13:00:08 <scadu> But it can take a while :f
2017-11-25 13:00:12 <jirutka> 
ACTION also looking forward RISC-V

2017-11-25 13:02:06 <jirutka> wWrAR07vpPZ1: firmware with “userland” written in Go and compiled in runtime, so it includes full compiler… FIRMWARE…
2017-11-25 13:02:21 <jirutka> this is not even funny
2017-11-25 13:03:20 <jirutka> I’m thinking about convincing my boss on faculty to buy some ppc64le server
2017-11-25 13:03:51 <scadu> jirutka:  Yeah, that would be great. Actually ARM64 laptop would be nice, too. Microsoft will release Surface series based on ARM manufactured by Asus, Lenovo and someone else, but well...
2017-11-25 13:04:39 <jirutka> scadu: is ARM really better?
2017-11-25 13:05:03 <jirutka> scadu: even RPi requires to load some BLOBs into kernel
2017-11-25 13:07:08 <scadu> jirutka: a little bit better than Intel with its panopticon included, but still might need some magic. Thug life.
2017-11-25 14:15:58 <wWrAR07vpPZ1> jirutka: oh, the go aspect is what bothers you? ok, that is googlish, agreed.
2017-11-25 14:16:39 <skarnet> of _course_ the go aspect is what bothers jirutka ;)
2017-11-25 14:16:58 <skarnet> but I don't think it would be that much of a problem if it was just a compiled binary
2017-11-25 14:17:35 <skarnet> the fact that there's a _Go development environment_ in the firmware is what bothers him, and I agree: it's /headdesk-worthy insane
2017-11-25 14:19:56 <wWrAR07vpPZ1> they also provide a compiled version, where there is no compile env included
2017-11-25 14:20:18 <wWrAR07vpPZ1> but yeah, go i can understand the aversion
2017-11-25 14:37:39 <wWrAR07vpPZ1> i guess i have a cognitive blind spot (like with online ads, when not using an adblocker) with google using go
2017-11-25 14:45:07 <skarnet> I don't mind Go, but using it in a firmware is 100% Google
2017-11-25 14:46:07 <wWrAR07vpPZ1> well, mozilla would use rust, ms c#, and apple swift. all these business languages have their business sponsors
2017-11-25 14:47:27 <skarnet> and none of those choices would be the right one for something so low level
2017-11-25 14:48:22 <skarnet> this is typical of business priorities overriding technical priorities, and it's sad that Google falls to it
2017-11-25 14:52:46 <jirutka> Rust is language for low-level programming, Go is not
2017-11-25 14:53:13 <jirutka> but including Rust *compiler* in firmware would be the same wrong
2017-11-25 14:57:09 <jirutka> skarnet: do you have some time to look at https://github.com/pikhq/musl-nscd/issues/5 ? :)
2017-11-25 14:58:10 <skarnet> I did
2017-11-25 14:58:24 <skarnet> and the code's too messy for me to want to invest more time in it :P
2017-11-25 14:58:37 <skarnet> what is pikhq saying about it?
2017-11-25 14:58:52 <jirutka> aha :( he’s saying nothing, no response from him
2017-11-25 14:59:22 <skarnet> ping him on #musl, he's a regular
2017-11-25 14:59:34 <jirutka> aha
2017-11-25 14:59:58 <jirutka> but if you said that the code is messy, I’m not sure i want to use it anymore
2017-11-25 15:00:17 <skarnet> no, it's fine
2017-11-25 15:00:21 <jirutka> I’ve already solved the original problem in other way, without musl-nscd
2017-11-25 15:00:41 <jirutka> you’ve said it’s too messy for you and now that it’s fine…? XD
2017-11-25 15:00:46 <skarnet> when I say it's messy, it's just that it uses patterns I'm not used to and I don't like
2017-11-25 15:00:51 <jirutka> aha
2017-11-25 15:00:56 <skarnet> and it's difficult for me to wrap my head around it
2017-11-25 15:01:02 <skarnet> but pikhq is a good coder
2017-11-25 15:01:25 <skarnet> the thing overall works and is probably easily fixable by him
2017-11-25 15:01:39 <skarnet> I could certainly find the bug and fix it too if I spent more energy into it
2017-11-25 15:02:39 <skarnet> it's just that reading other people's code is exhausting to me - I'll do it for money, but not so much in my free time, unless the problem is obvious and I can diagnose and fix it in 10 minutes
2017-11-25 16:32:37 <Shiz> :)
2017-11-25 16:32:46 <Shiz> nothing wrong with using go in firmware, it's just a linux userspace
2017-11-25 16:32:53 <Shiz> but yeah the dynamic recompilation is 100% bonkers
2017-11-25 16:33:50 <jirutka> well, I’m not sure if using even linux in firmware is right…
2017-11-25 16:35:02 <jirutka> but HW vendors apparently don’t give a sh*t about reducing complexity, limiting amount of code (and so bugs) to minimum etc.
2017-11-25 16:39:43 <skarnet> now we just need a firmware to be able to boot the linux kernel running in the firmware
2017-11-25 16:40:08 <jirutka> :)
2017-11-25 18:08:48 <duncan^> Most elegant is Coreboot -> Linux [->kexec -> OS]
2017-11-25 18:08:54 <duncan^> Or... not.
2017-11-25 18:20:22 <wWrAR07vpPZ1> if you put your main kernel into a coreboot payload, you can skip the kexec phase
2017-11-25 21:19:19 <Xe> ncopa: https://github.com/alpinelinux/aports/commit/b14cd20c734f133f720b56cdfea32d449aba48da
2017-11-25 21:19:24 <Xe> see thread comments
2017-11-26 17:07:08 <leo-unglaub> good evening
2017-11-26 17:08:40 <leo-unglaub> i have a very nice PR ready but i cannot send it because networking in my vm is broken ... i hate vm's *g*
2017-11-26 17:18:08 <skarnet> would you prefer to have networking broken on a real machine? so you'd have to go to the actual console to fix it? :P
2017-11-26 18:03:19 <jirutka> XD
2017-11-26 18:04:42 <jirutka> leo-unglaub: you can take a photo of the screen using your phone, send it to your email, open on computer with working network, run it through OCR, fix mistakes, and finally commit it to git! XD
2017-11-26 18:06:18 <leo-unglaub> that soulds a lot like how gtk3 got deveoped ... and that would explain a lot *g*
2017-11-26 18:07:11 <jirutka> XD
2017-11-26 19:56:16 <Shiz> f/w 67
2017-11-26 19:56:36 <jirutka> ?
2017-11-26 19:59:14 <^7heo> jirutka: Shiz wanted to go to window 67, but had 'f' typed in the input
2017-11-26 19:59:29 <jirutka> aha
2017-11-26 19:59:44 <^7heo> at least that's my take on it
2017-11-26 20:21:22 <Shiz> yes
2017-11-27 18:33:04 <Meths> [A
2017-11-27 18:33:41 <_ikke_> ]
2017-11-27 18:43:30 <rfs613> sorry, neither of those is a valid CSI sequence...
2017-11-27 19:29:43 <ncopa> jirutka: question about qemu-openrc, is there some way to get a console via cli?
2017-11-27 19:29:52 <ncopa> similar to lxc-console
2017-11-27 19:30:35 <ncopa> and similar to xen's  `xl console`
2017-11-27 19:30:48 <ncopa> looks like you can do that with libvirt's virsh
2017-11-27 19:41:03 <jirutka> ncopa: you can get console with qemush and there’s some command to enter VM console
2017-11-27 19:41:24 <jirutka> ncopa: tbh VM console never worked for me anywhere, don’t know why, so I dunno
2017-11-27 19:53:04 <ncopa> i think you may need enable virtiocon
2017-11-27 19:53:24 <ncopa> and add hvc0 to /etc/inittab in guest
2017-11-27 20:01:18 <kaniini> i want to do ppc64 arch for alpine 3.8, i have some POWER5/POWER6 machines that can serve as builder
2017-11-27 20:01:22 <kaniini> will write about it later
2017-11-27 20:47:50 <ncopa> jirutka: i figured out how to connect stdio on host with /dev/hvc0 in guest
2017-11-27 20:48:08 <ncopa> but it does not really help with qemu-openrc case
2017-11-27 20:48:25 <ncopa> i think it should be possible to connect a char device with a unix socket too
2017-11-27 21:00:09 <fcolista> I've openconnect APKBUILD which builts
2017-11-27 21:00:09 <fcolista> https://dpaste.de/zNxi/raw
2017-11-27 21:00:44 <fcolista> we have a request since a while https://bugs.alpinelinux.org/issues/5100#change-22066
2017-11-27 21:01:19 <fcolista> it is in unmaintained, i just upgraded it, fixed some makedeps and added a patch
2017-11-27 21:01:29 <fcolista> would that makes sense to bring in testing?
2017-11-27 21:04:43 <fcolista> ncopa, ^
2017-11-27 21:05:23 <ncopa> yeah ,sure
2017-11-27 21:05:40 <fcolista> k
2017-11-27 21:05:46 <ncopa> woudl be nice if you also can test if it actually works
2017-11-27 21:05:50 <fcolista> I would like to use it with junos :)
2017-11-27 21:05:54 <ncopa> and then maybe move it to community
2017-11-27 21:05:59 <ncopa> great!
2017-11-27 21:07:23 <fcolista> actually juniper support is experimental
2017-11-28 12:20:14 <ncopa> number of open PRs are increasing
2017-11-28 12:20:25 <ncopa> i'd like to have it below 100 ...
2017-11-28 12:20:38 <ncopa> but for now i think we need to prio those who are in main and community
2017-11-28 12:20:48 <ncopa> at least til the 3.7.0 release
2017-11-28 12:22:00 <ncopa> would be nice with some help with that, im working on the fsck issue
2017-11-28 12:35:55 <_ikke_> ncopa: I'd like to help reviewing PRs
2017-11-28 12:37:37 <ncopa> woulde be awesome, thanks
2017-11-28 18:16:08 <batman1> hi
2017-11-28 18:29:14 <ncopa> hi batman1
2017-11-28 18:48:46 <batman1> it's me, leo ... i just have not configured weechat to use my real account :)
2017-11-28 19:02:07 <ncopa> does anybody have any clue how buildozer may have eneded up in the "racktables-lsm" group?
2017-11-28 19:32:24 <rdutra> ncopa: I dont
2017-11-28 19:32:39 <ncopa> remember now
2017-11-28 19:32:52 <ncopa> it was years ago while i was debuging an issue with long groups
2017-11-28 19:33:01 <ncopa> i have fixed the augeas test
2017-11-28 19:33:50 <ncopa> problem was that it did: groups | tr ' ' '\n' | tail -1
2017-11-28 19:34:03 <ncopa> eg the last group buildozer was in
2017-11-28 19:34:17 <ncopa> and compared with `ls -l ` output
2017-11-28 19:34:23 <ncopa> the group column
2017-11-28 19:34:33 <ncopa> but busybox ls truncates the groupname
2017-11-28 19:35:46 <rdutra> got it
2017-11-29 01:02:29 <duncan^> I've been playing with GnuPG and the Yubikey. I've managed to get it to work using GnuPG's internal CCID driver, and appended the --enable-usb, --enable-scdaemon, and --enable-ccid-driver to the APKBUILD.
2017-11-29 01:02:58 <duncan^> I am curious as to whether there is a reason that these are not default (dependency on libusb is a problem?).
2017-11-29 06:28:32 <dsabogal> ncopa: i've installed xen 4.9.1 with alpine dom0 and alpine PV domU on AMD hw without trouble. i'll try qemu tomorrow to see if i run into anything
2017-11-29 08:51:20 <ncopa> dsabogal: thank you!
2017-11-29 08:52:11 <ncopa> duncan^: probably nobody asked about it earlier and we try avoid adding dependencies to stuff nobody uses
2017-11-29 09:58:59 <Shiz> mhm
2017-11-29 09:59:05 <Shiz> libusb is quite a dependency tbh
2017-11-29 11:30:47 <duncan^> Well the question would be, are most people installing GnuPG to verify signatures during installation (in which case gpgv is entirely sufficient) or are they using it to do general cryptographic operations, in which case perhaps adding the dependency on libusb isn't *much* bigger
2017-11-29 11:31:20 <duncan^> and probably very useful, and smaller than pcsc-lite + ccid driver
2017-11-29 11:32:54 <duncan^> It doesn't strike me as necessary to install the whole gnupg package on a server/router just to verify package signatures and the like, for instance
2017-11-29 11:54:51 <Michcioperz> hello, I was thinking of adding a package for liferea to aports testing, but I'm confused by what's the right way to submit it between sending a patch and opening PR on github
2017-11-29 11:58:53 <ncopa> Michcioperz: both sending patch and open a PR is acceptable
2017-11-29 11:59:06 <ncopa> some devs prefer send patch other prefers github PR
2017-11-29 11:59:13 <ncopa> do whats most convenient for you
2017-11-29 11:59:52 <Michcioperz> there's the other issue: the latest release of liferea is v1.12-rc3 from half a year ago while the last "stable" is from 1.5 years ago
2017-11-29 12:00:36 <Michcioperz> Arch has the rc one in their repos
2017-11-29 12:01:15 <Michcioperz> but I'm not sure if that's the viable approach for Alpine
2017-11-29 12:08:07 <ncopa> if its realistic that they get a stable release within 6months, then i'd be ok with it
2017-11-29 12:10:05 <Michcioperz> I'm not too familiar with liferea, I'll look into it, but I guess I'll have to go with the stable
2017-11-29 12:10:07 <Michcioperz> thank you
2017-11-29 15:05:24 <vkrishn> ncopa: noticed that we already have some BPF related settings enabled in kernel, but not all as https://github.com/iovisor/bcc/blob/master/INSTALL.md
2017-11-29 15:06:05 <vkrishn> but I have not read in full, but seems nice to have them enabled, unless it is a security or bloats the kernel
2017-11-29 15:06:55 <vkrishn> rest seems optional except, CONFIG_BPF_SYSCALL=y
2017-11-29 16:23:45 <danieli> god it sucks to have an unstable ISP
2017-11-29 16:28:22 <duncan^> ebpf++
2017-11-29 17:15:30 <_ikke_> duncan^: hi
2017-11-29 17:20:36 <duncan^> Hi
2017-11-29 18:28:34 <jirutka> kaniini: when you don’t have APKINDEX for repos, e.g. user didn’t run apk update in fresh VM or container, apk search prints warnings; I think that these should not be printed by c-n-f
2017-11-29 18:34:40 <jirutka> kaniini: apk search may return a lot of results, e.g. when user accidentally type “d” and hit enter; maybe it’d be better to limit number of printed results to something like 16
2017-11-29 18:39:56 <jirutka> kaniini: we don’t generally use /usr/libexec, at least based on what ncopa told me some time ago
2017-11-29 18:40:17 <jirutka> kaniini: that we should prefer /usr/lib instead of /usr/libexec
2017-11-29 18:41:09 <ncopa> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
2017-11-29 18:42:19 <jirutka> ncopa: so…? we should use /usr/libexec?
2017-11-29 18:42:24 <ncopa> looks like its acceptable in FHS nowdays
2017-11-29 18:42:34 <jirutka> okay
2017-11-29 18:42:39 <ncopa> its says its acceptale so i guess either one is fine
2017-11-29 19:09:33 <ncopa> release notes for 3.7.0: http://tpaste.us/eDk5
2017-11-29 19:09:38 <ncopa> anything missing?
2017-11-29 19:09:57 <jirutka> pche
2017-11-29 19:10:03 <ncopa> whats that?
2017-11-29 19:10:04 <jirutka> you’ve mentioned Go and forgot to Rust
2017-11-29 19:10:15 <jirutka> I’m offended XD
2017-11-29 19:10:36 <ncopa> thats why im asking...
2017-11-29 19:10:42 <jirutka> I know, I’m just kidding :)
2017-11-29 19:11:00 <jirutka> there are more missing stuff, I’ll skim logs at the evening
2017-11-29 19:11:03 <ncopa> rust 1.22?
2017-11-29 19:11:11 <jirutka> yes
2017-11-29 19:11:59 <ncopa> php7 is stil oh 7.1 and python still on 3.6
2017-11-29 19:12:02 <ncopa> to not worth mention
2017-11-29 19:12:58 <jirutka> yeah
2017-11-29 19:13:22 <rdutra> ncopa: * Go 1.9 or * Go 1.9.2 ?
2017-11-29 19:13:29 <rdutra> not sure if make different in release notes  :)
2017-11-29 19:13:31 <ncopa> Go 1.9
2017-11-29 19:13:40 <ncopa> Go 1.9.x
2017-11-29 19:13:43 <rdutra> ncopa: ok
2017-11-29 19:13:46 <ncopa> vs Go 1.8.x
2017-11-29 19:15:00 <jirutka> commit stats are wrong, these are form v3.6
2017-11-29 19:15:47 <jirutka> nodejs 8.9 (LTS)
2017-11-29 19:19:10 <jirutka> ruby2.2 EOL date: scheduled for 2018-03-31, so I should probably remove ruby2.2 from community
2017-11-29 19:21:13 <ncopa> thats fairly close to the v3.8 release
2017-11-29 19:21:36 <jirutka> isn’t it *before* 3.8?
2017-11-29 19:22:14 <ncopa> it is
2017-11-29 19:22:44 <jirutka> so, remove it?
2017-11-29 19:22:48 <ncopa> its a month before
2017-11-29 19:23:11 <ncopa> so if there are serious security vulns in april we can likely backport?
2017-11-29 19:23:20 <ncopa> i dont mind to remove now though
2017-11-29 19:24:08 <ncopa> jirutka: youre the maintainer for it, so i let you decide that
2017-11-29 19:30:45 <jirutka> kaniini: https://github.com/kaniini/command-not-found/pull/1/commits
2017-11-29 21:03:36 <dsabogal> ncopa: xen on qemu (x86_64) checked out w/o trouble
2017-11-29 21:13:25 <jirutka> ncopa: why we’re stuck on older OpenRC version?
2017-11-29 22:55:59 <ollieparanoid[m]> ncopa: not sure if it's worth mentioning, but some binaries from busybox have been split into busybox-extras: https://git.alpinelinux.org/cgit/aports/tree/main/busybox/busybox.post-upgrade#n15
2017-11-30 04:57:28 <kaniini> jirutka: wow thank you for checking it over
2017-11-30 04:57:39 <kaniini> i wasn't expecting you to do it so quickly
2017-11-30 04:58:03 <kaniini> jirutka: largely we haven't gotten around to rebasing openrc btw
2017-11-30 05:13:38 <tmh1999> clandmeter : how do you boot alpine in apu2 via serial port ? I tried to unpack alpine.iso, add a couple of lines of serial to syslinux.cfg and everytime apu2 boots, it goes to memtest :/
2017-11-30 05:20:08 <tmh1999> basically just 'serial 0 115200' at the top, and append console=ttyS0,115200n8
2017-11-30 05:20:52 <tmh1999> i created a new iso with genisoimage, not really sure it is the way
2017-11-30 06:57:40 <ncopa> jirutka: just not payed attention to openrc development
2017-11-30 06:58:05 <ncopa> tmh1999: I have an apu2 too
2017-11-30 07:00:00 <ncopa> format the mmc as vfat
2017-11-30 07:00:17 <ncopa> mark the first partition bootable in fdisk
2017-11-30 07:00:34 <ncopa> and you may need install mbr.bin from syslinux
2017-11-30 07:00:49 <ncopa> then just extract all the files from iso
2017-11-30 07:01:57 <ncopa> this is my boot/syslinux/syslinux.cfg: http://tpaste.us/JMzV
2017-11-30 09:27:59 <ncopa> Are we ok with the release notes?
2017-11-30 09:28:40 <ncopa> I don't think we need mention the Busybox extras split
2017-11-30 09:40:32 <nmeum> what's the current policy on package upgrades? I assumed that we only do security upgrades as soon as a release candidate is tagged but that doesn't seem to be the case
2017-11-30 09:46:35 <_ikke_> bugfixes as well, right?
2017-11-30 09:49:50 <ncopa> Bugfixes are ok. Minor upgrades are ok too
2017-11-30 09:50:16 <ncopa> As long as nothing breaks upgrades are ok
2017-11-30 09:51:11 <ncopa> I am seriously considering upgrade webkit2gtk
2017-11-30 09:52:05 <clandmeter> Did we remove the post upgrade msg from BusyBox it are we keeping it?
2017-11-30 09:52:14 <ncopa> We need to provide security fixes for 6months and I dunno for how long the 2.16 will be supported
2017-11-30 09:52:31 <clandmeter> Or... Autocorrect...
2017-11-30 09:52:58 <ncopa> I think the post upgrade msg is still there
2017-11-30 09:53:43 <ncopa> I was talking about mention it in release notes
2017-11-30 09:55:45 <clandmeter> I know, but you reminded me about it via this way 😀
2017-11-30 11:02:43 <nmeum> ncopa: upgrading webkit is probably a good idea
2017-11-30 11:03:28 <ncopa> only problem is that it will keep the builders (armhf) busy for too long :-/
2017-11-30 11:03:34 <ncopa> should have stred the build yesterday
2017-11-30 11:03:58 <ncopa> current webkti2gtk has sec vuln
2017-11-30 11:04:00 <ncopa> so yeah
2017-11-30 11:04:03 <ncopa> i think we shoudl upgrade it
2017-11-30 11:04:11 <nmeum> yeah
2017-11-30 11:04:23 <ncopa> and im on it...
2017-11-30 11:04:35 <ncopa> i also enabled tests on dovecot
2017-11-30 11:04:38 <ncopa> and one test fails
2017-11-30 11:10:05 <ashb> dovecot test fails? Hmmm?
2017-11-30 11:10:30 <ncopa> it looks like the test is not doing proper error handling
2017-11-30 11:10:43 <ncopa> it tries do conversion of soemthing that is NULL
2017-11-30 11:11:02 <ashb> This is in `make check` for the dovecot apk build?
2017-11-30 11:11:05 <ashb> (or similar)
2017-11-30 11:11:11 <ncopa> yes
2017-11-30 11:12:29 <ashb> Huh oh yes, not sure i've actually run make check on Dovecot. But the Dovecot package does work as I'm using it
2017-11-30 11:12:48 <ncopa> it loosk like the test iteslf is doing something weird
2017-11-30 13:32:09 <ncopa> is this release notes ok for 3.7.0? http://wwwtest.alpinelinux.org/posts/Alpine-3.7.0-released.html
2017-11-30 13:50:26 <gromero> ncopa: no commit statistics?
2017-11-30 13:57:52 <ncopa> gromero: will add that after the last commit (which sets versino 3.7.0)
2017-11-30 13:58:19 <gromero> ncopa: got it :-)
2017-11-30 14:06:49 <tmh1999> ncopa : Thanks! I follow your instruction and also here : http://www.syslinux.org/wiki/index.php?title=HowTos. apu2 recognizes the media now but hangs at syslinux message line
2017-11-30 14:07:43 <tmh1999> I guess I should make prompt 0
2017-11-30 14:08:59 <tmh1999> http://tpaste.us/mMVL
2017-11-30 14:09:21 <tmh1999> console=tty0 doesn't matter
2017-11-30 14:10:58 <tmh1999> ah hold on, when I run install mbr.bin, I should change syslinux configuration in my host machine, should I ?
2017-11-30 14:11:01 <tmh1999> right let me try
2017-11-30 14:27:05 <tmh1999> yahhoooooooooo
2017-11-30 14:27:16 <tmh1999> thank you ncopa !!!
2017-11-30 14:38:42 <TBB> ncopa, just out of curiosity, since you have the release notes ready, I take it 3.7 final will be out in a day or three?
2017-11-30 14:38:45 <fcolista> ncopa, should we shil qt 5.9.2 before 3.7 ?
2017-11-30 14:38:50 <fcolista> *ship
2017-11-30 14:39:21 <fcolista> according with release notes, it closes more that 300 bugs
2017-11-30 14:39:29 <fcolista> http://blog.qt.io/blog/2017/10/06/qt-5-9-2-released/
2017-11-30 14:41:58 <ncopa> fcolista: i want release it today
2017-11-30 14:42:13 <ncopa> i thikn we can push 5.9.2 for 3.7.1
2017-11-30 14:42:24 <ncopa> we only need to push in two branches
2017-11-30 14:44:11 <fcolista> sounds good
2017-11-30 14:48:25 <fcolista> actually we should ship 5.9.3...
2017-11-30 14:48:59 <fcolista> 300 bug fixes from qt 5.9.1 > 5.9.2 and 100 from 5.9.2 > 5.9.3. So, pushing 5.9.3 would fixes 400 bugs..
2017-11-30 14:49:08 <ncopa> im just waiting for the builders to complete
2017-11-30 14:49:12 <ncopa> its armhf thats slow
2017-11-30 14:49:35 <ncopa> it will also build the rpi kernel
2017-11-30 15:07:39 <TBB> I would be interested in learning more about your internal build and release process; not sure if I can really be of much help at that front, but it would be interesting nevertheless
2017-11-30 15:26:18 <ncopa> TBB: we use mqtt for messaging
2017-11-30 15:26:35 <ncopa> a git hook will publish when there is a git push
2017-11-30 15:27:05 <ncopa> the build servers has mqtt subscribers (in package aports-build)
2017-11-30 15:27:13 <ncopa> which will run the aports-build script
2017-11-30 15:27:36 <ncopa> the builders publishes their status on mqtt too
2017-11-30 15:27:52 <ncopa> and can be observed here: http://build.alpinelinux.org/
2017-11-30 15:46:56 <rdutra> ncopa: Hi Natanel. mksully1 is also from IBM and he will help with the ppc64le too
2017-11-30 15:47:13 <rdutra> Natanael*
2017-11-30 15:47:15 <ncopa> hi
2017-11-30 15:47:16 <ncopa> nice!
2017-11-30 15:47:21 <mksully1> hi
2017-11-30 15:47:27 <ncopa> mksully1: welcome
2017-11-30 15:47:31 <mksully1> thanks
2017-11-30 15:48:13 <ncopa> you joined just in time for the 3.7.0 release champange :)
2017-11-30 15:48:49 <rdutra> ncopa: better time, isn't it?
2017-11-30 15:55:24 <leitao> ncopa: I heard it is not a cheap champagne, but a Veuve Clicquo.
2017-11-30 15:55:40 <ncopa> ha! I wish...
2017-11-30 15:55:56 <ncopa> unfortunally i have to drive later tonight...
2017-11-30 15:57:12 <leitao> :-)
2017-11-30 15:57:18 <rdutra> leitao: I guess ncopa is going to Caribbean to celebrate :)
2017-11-30 15:57:24 <rdutra> he will drink there
2017-11-30 15:59:37 <Shiz> :P
2017-11-30 16:00:09 <Shiz> i'm moderately interested in running alpine on my ps3 but that's ppc64be
2017-11-30 16:00:11 <Shiz> ;p
2017-11-30 16:24:45 <dsabogal> ncopa: binary committed to community/webkit2gtk/core
2017-11-30 16:24:57 <ncopa> ugh..
2017-11-30 16:26:29 <ncopa> i wonder if its possible to remove it from history without messing up everything
2017-11-30 16:26:31 <ncopa> i suppose not
2017-11-30 16:26:45 <_ikke_> probably not
2017-11-30 16:27:25 <_ikke_> lots of repositories probably already have this
2017-11-30 16:28:09 <ncopa> im adding core to .gitignore
2017-11-30 16:28:26 <ncopa> dsabogal: thank you
2017-11-30 16:29:52 <_ikke_> perhaps a pre-receive hook which rejects binary files might also be an idea
2017-11-30 16:30:05 <Shiz> ncopa: btw i saw the linux-hardened dir has an unused test.patch file
2017-11-30 16:30:09 <Shiz> is that intentional?
2017-11-30 16:30:19 <ncopa> nope
2017-11-30 16:31:00 <ncopa> we probably need a githook that can verify the patches
2017-11-30 16:31:15 <_ikke_> perhaps a pre-receive hook which rejects binary files might also be an idea/
2017-11-30 16:31:17 <_ikke_> sorry
2017-11-30 16:31:20 <_ikke_> what would you verify?
2017-11-30 16:31:38 <_ikke_> files that are not in sources?
2017-11-30 16:31:45 <ncopa> _ikke_: good idea
2017-11-30 16:31:56 <ncopa> with rejecting binaries on pre-receive
2017-11-30 16:32:16 <ncopa> yes, verify that all patches are in sources
2017-11-30 16:32:19 <ncopa> and that are none missing
2017-11-30 16:32:39 <ncopa> would be better if we could test that on pre-receive, but i dunno how easy that is
2017-11-30 16:32:41 <_ikke_> I can try to work on something like that
2017-11-30 16:32:47 <ncopa> since we need to check out the tree
2017-11-30 16:33:01 <_ikke_> not necessarily
2017-11-30 16:33:16 <ncopa> would be awesome if you could help us with those two things
2017-11-30 16:33:19 <_ikke_> You can look at the files that were touched
2017-11-30 16:34:15 <ncopa> how do you read $sources from APKBUILD without checking it out?
2017-11-30 16:34:49 <_ikke_> git show <commit>:<file> would get its contents
2017-11-30 16:34:58 <ncopa> aha
2017-11-30 16:34:59 <ncopa> nice
2017-11-30 16:35:25 <_ikke_> Question is, how to parse the sources array
2017-11-30 16:35:33 <Shiz> i wouldn't even try parsing it
2017-11-30 16:35:38 <Shiz> just grep the APKBUILD
2017-11-30 16:35:48 <Shiz> parsing shell on the git server is too dangerous
2017-11-30 16:35:57 <_ikke_> yes, I would imagine so
2017-11-30 16:36:11 <ncopa> *nod*
2017-11-30 16:36:14 <_ikke_> but ncopa also wanted to check if patches are still available
2017-11-30 16:36:21 <_ikke_> right?
2017-11-30 16:36:31 <ncopa> yes
2017-11-30 16:36:51 <_ikke_> So we still need to get each individual patch in $sources
2017-11-30 16:37:52 <_ikke_> would grepping on *.patch suffice?
2017-11-30 16:39:06 <ncopa> possibly
2017-11-30 16:39:09 <ncopa> i need to go
2017-11-30 16:39:11 <_ikke_> ok
2017-11-30 16:39:17 <przemoc> what's your opinion about adding *.diff to abuild for autopatching action?  I mean just like *.patch is handled there.  I think it should be done, as I mentioned on ML week ago.  (it's post-3.7 matter, obviously.)
2017-11-30 16:41:13 <_ikke_> przemoc: what is the advantage / need for that?
2017-11-30 16:41:29 <_ikke_> przemoc: is there a reason you cannot call it .patch/
2017-11-30 16:41:31 <_ikke_> ?
2017-11-30 16:41:38 <przemoc> preserving file names of existing patches out there in the wild
2017-11-30 16:41:50 <przemoc> I mean especially borrowed ones, like from debian, etc.
2017-11-30 16:43:56 <_ikke_> Shiz / ncopa: Statically reading for patch files is not going to work, some even have variables in them
2017-11-30 16:44:36 <_ikke_> some of them have variables in them
2017-11-30 16:44:39 <_ikke_> "$pkgname-4.13c-fnmatch-replacement.patch"
2017-11-30 16:45:03 <Shiz> well
2017-11-30 16:45:32 <Shiz> sed -e 's/\$[a-zA-Z_]*/*/g'
2017-11-30 16:45:34 <Shiz> and then glob it
2017-11-30 16:45:36 <Shiz> :P
2017-11-30 16:45:59 <przemoc> awful heuristic
2017-11-30 16:46:16 <jirutka> ncopa: _ikke_: instead of adding community/webkit2gtk/core to .gitignore, fix the abuild to not write any files into startdir, but srcdir
2017-11-30 16:47:34 <jirutka> ncopa: grr, do you have what does this https://github.com/alpinelinux/aports/blob/master/.gitignore#L15 actually mean?
2017-11-30 16:48:50 <jirutka> ncopa: it means that git will ignore any file or directory named “core”… so even e.g. testing/core/APKBUILD
2017-11-30 16:49:17 <_ikke_> jirutka: untill you add it
2017-11-30 16:49:35 <jirutka> ncopa: I really love when I don’t see something in git status b/c someone add arbitrary mess into gitignore
2017-11-30 16:49:48 <jirutka> _ikke_: yes, until you _force_ git to really add it, despite it’s in gitignore
2017-11-30 16:49:53 <_ikke_> yes
2017-11-30 16:50:03 <_ikke_> I agree that it's less than optimal
2017-11-30 16:50:29 <jirutka> so instead of fixing that damn abuild to not create any files under startdir or just being more careful what you commit…
2017-11-30 16:50:52 <jirutka> you just keep adding non-senses into .gitignore and creating confusiion and problems in future
2017-11-30 16:52:59 <jirutka> and even if you really wants to add it to gitignore, there’s a way how to do it right
2017-11-30 16:53:05 <_ikke_> */*/core
2017-11-30 16:53:08 <jirutka> yes
2017-11-30 16:53:25 <jirutka> or core\n!core/
2017-11-30 16:53:32 <jirutka> eh
2017-11-30 16:53:54 <_ikke_> yeah, that works
2017-11-30 16:54:03 <jirutka> no, it’s right… damn, I hate that nature of IRC that you cannot use newlines in message
2017-11-30 16:55:31 <_ikke_> jirutka: but do you think preventing binary files from being pushed is a good idea?
2017-11-30 16:56:11 <ncopa> i need to run
2017-11-30 16:56:16 <ncopa> maybe */*/core is better
2017-11-30 16:56:36 <ncopa> can someon purge unmaintained/* that is older than 6 months?
2017-11-30 16:56:56 <jirutka> grepping APKBUILD is… ufff… okay… not very clever…
2017-11-30 16:57:07 <_ikke_> jirutka: that is for the *.patch part
2017-11-30 16:57:11 <jirutka> instead you should source it and print $source
2017-11-30 16:57:18 <ncopa> and if someone can help me with moving all issues on bugs.a.o with target 3.7.0 to 3.8.0 or 3.7.1?
2017-11-30 16:57:25 <ncopa> when im back im gonna tag 3.7.0
2017-11-30 16:57:56 <_ikke_> jirutka: right, but do we deem that safe enough to do on the git server?
2017-11-30 16:58:30 <jirutka> I don’t see any reason for adding *.diff; please, use just .patch in unified format, keep it simple
2017-11-30 17:00:32 <jirutka> _ikke_: yeah, we already use this approach for pkgs.a.o, in build scripts etc. patches should be reviewed to not commit some crap like `rm -Rf /*` and we trust people with push rights to not do stupid things :P
2017-11-30 17:01:32 <_ikke_> jirutka: until they do :P
2017-11-30 17:01:35 <jirutka> ncopa: purge unmaintained? I thought that unmaintained is never deleted
2017-11-30 17:01:55 <_ikke_> jirutka: they're still in git history
2017-11-30 17:02:06 <jirutka> _ikke_: then we would remove push rights ;)
2017-11-30 17:02:26 <jirutka> _ikke_: i know that it’s in git history… just I don’t remember that someone purged unmaintained in last two years
2017-11-30 17:02:47 <_ikke_> ok
2017-11-30 17:03:34 <jirutka> I’m not saying we should not do that, I’m just surprised; and i’m neutral about this
2017-11-30 17:05:31 <jirutka> how can get “core” file into community/webkit2gtk? i don’t see anything suspicious in abuild
2017-11-30 17:06:50 <_ikke_> jirutka: might it be a result of ncopa executing something that resulted in a core dump?
2017-11-30 17:07:06 <_ikke_> outside of abuild
2017-11-30 17:07:59 <jirutka> hm, IIRC core dumps are not dumped into CWD… are they?
2017-11-30 17:08:28 <jirutka> it’s configurable in kernel, but don’t remember what is the default setting
2017-11-30 17:08:57 <_ikke_> kernel.core_pattern
2017-11-30 17:09:01 <_ikke_> sysctl
2017-11-30 17:09:08 <przemoc> it goes into CWD
2017-11-30 17:10:13 <jirutka> aha, i see
2017-11-30 17:10:36 <_ikke_> so ignoring them is not a bad idea
2017-11-30 17:10:37 <przemoc> I do think that abuild should not create any files in startdir (my aports tree is read-only in lxc builder).  core\n!core/ seems better indeed, because it will prevent adding core file at any level, but will work with dir, if there is any.
2017-11-30 17:10:54 <_ikke_> przemoc: right, I agree
2017-11-30 17:10:58 <jirutka> well, then what about changing core_pattern to some fixed path, e.g. /var/tmp
2017-11-30 17:13:37 <jirutka> this is wrong approach from principle, b/c what would be next? *~ b/c someone does not have this in his/her global .gitignore and use vim with default settings? .DS_Store b/c someone maybe work with aports on macOS and don’t have this in his/her global .gitignore? what about .sublime-project? or… I hope you got the idea
2017-11-30 18:01:42 <kunkku> ls
2017-11-30 18:01:52 <kunkku> hm.. wrong window :)
2017-11-30 20:18:55 <ncopa> jirutka: i did: git add . && git commit -v ...
2017-11-30 20:19:09 <ncopa> i didnt pay attention enough so i didnt notice that there was a `core` file
2017-11-30 20:20:22 <ncopa> its not uncommon for me to have core files, since i ofte do debugging of crashing apps
2017-11-30 20:20:43 <ncopa> it is not common that they end up in the aports tree though
2017-11-30 20:20:47 <ncopa> but apparently it happens
2017-11-30 20:25:38 <ncopa> if .DS_Store or *.swp or .sublime* ends up in git repo we'll deal with it then
2017-11-30 20:26:39 <ncopa> if you think testing/core/APKBUILD will become a problem then we can fix it, but i dont think it will (and i did check that it not is)
2017-11-30 20:28:27 <ncopa> in any case
2017-11-30 20:28:37 <ncopa> its time for release now
2017-11-30 20:37:39 <xentec_> yay
2017-11-30 20:45:31 <jirutka> wait, kaniini wanted to add command-not-found to ISO images
2017-11-30 20:45:43 <jirutka> but he didn’t release new version yet…
2017-11-30 20:47:03 <ncopa> re unmaintained
2017-11-30 20:47:15 <ncopa> we delete stuff tehre older than 6months
2017-11-30 20:47:29 <jirutka> ncopa: I wonder how you checked it… I know how gitignore works and to be sure, I verified that it really works as I assume before I wrote it here
2017-11-30 20:48:00 <jirutka> ncopa: I strongly prefer to do things right, not do it wrong and hope that it will not be a problem…
2017-11-30 20:48:11 <ncopa> so what do you suggest?
2017-11-30 20:48:18 <jirutka> I already wrote it
2017-11-30 20:48:37 <jirutka> core\n!core/
2017-11-30 20:48:48 <jirutka> or */*/core
2017-11-30 20:49:03 <ncopa> ok i misssed that
2017-11-30 20:49:07 <jirutka> if it really is so common…
2017-11-30 20:49:25 <jirutka> if it’s common only for you, then you should add it to your local ~/.gitignore or .git/info/exclude
2017-11-30 20:49:33 <ncopa> (its late and i have head ache and i cannot go to bed til 3.7.0 is out)
2017-11-30 20:50:06 <jirutka> what about that weird xen error?
2017-11-30 20:50:12 <ncopa> which?
2017-11-30 20:50:21 <jirutka> it looks like it tries to install something to ISO image
2017-11-30 20:50:21 <ncopa> url?
2017-11-30 20:50:28 <jirutka> do you read ML?
2017-11-30 20:50:31 <ncopa> yes
2017-11-30 20:50:42 <ncopa> there have been more than one xen errors
2017-11-30 20:50:58 <ncopa> one is that kernel crashes when you run it i qemu
2017-11-30 20:51:05 <jirutka> out of space
2017-11-30 20:51:23 <jirutka> from x9p
2017-11-30 20:51:42 <ncopa> yeah i know what you mean
2017-11-30 20:51:48 <jirutka> http://lists.alpinelinux.org/alpine-devel/5927.html
2017-11-30 20:51:50 <ncopa> sorry i didnt understood it immediately
2017-11-30 20:51:52 <ncopa> i know
2017-11-30 20:52:18 <ncopa> as i understand that, he tried to boot alpine-xen iso on a XenServer
2017-11-30 20:52:36 <ncopa> so he tried to boot a xen hypervisor on a xen server
2017-11-30 20:52:54 <ncopa> i dont know if nested xen is supported upstream
2017-11-30 20:53:01 <jirutka> aha
2017-11-30 20:53:16 <ncopa> and out-of-space didnt really make any sense
2017-11-30 20:53:28 <ncopa> dsabogal reported that xen works
2017-11-30 20:54:02 <ncopa> i tried xen in qemu myself
2017-11-30 20:54:07 <ncopa> but kernel crashes
2017-11-30 20:54:14 <ncopa> so i suppose its something with nested virt
2017-11-30 20:54:24 <ncopa> but as long as it works on the iron im happy
2017-11-30 20:54:30 <jirutka> what about command-not-found? kaniini ?
2017-11-30 20:54:47 <ncopa> if its not ready it will have to wait
2017-11-30 20:55:00 <ncopa> if it cannot wait then its very important
2017-11-30 20:55:05 <ncopa> and can be backported...
2017-11-30 20:55:17 <_ikke_> If I can help with anything, let me know
2017-11-30 20:55:33 <jirutka> depends on definition of ready; I think that the script is ready, kaniini just have to make a release and upgrade abuild
2017-11-30 20:56:13 <jirutka> but since he didn’t, he probably don’t need it into v3.7 ¯\_(ツ)_/¯
2017-11-30 20:58:37 <ncopa> _ikke_: do you have access to the bugs.a.o?
2017-11-30 20:58:45 <ncopa> so you can close or move tickets?
2017-11-30 20:59:24 <_ikke_> I have an account, but no special permissions
2017-11-30 21:03:13 <ncopa> trynow
2017-11-30 21:03:51 <_ikke_> Nope, cannot edit issues
2017-11-30 21:04:28 <_ikke_> oh, helps to actually login
2017-11-30 21:05:16 <_ikke_> Yeah, works
2017-11-30 21:06:44 <ncopa> can you look at issues, package requests can be moved to 3.8.0 target
2017-11-30 21:07:00 <_ikke_> ok
2017-11-30 21:07:05 <ncopa> things that looks complicated and timeconsuming (and not serious) can be moved to 3.8.0
2017-11-30 21:07:37 <ncopa> things that looks serious or minor bugs can be moved to 3.7.1 target
2017-11-30 21:08:11 <_ikke_> is that for everything that is targetted for 3.7.0?
2017-11-30 21:08:34 <ncopa> correct
2017-11-30 21:08:41 <ncopa> thank you very much
2017-11-30 21:09:28 <_ikke_> and not resolved I assume
2017-11-30 21:09:46 <ncopa> correct
2017-11-30 21:10:21 <jirutka> ncopa: about cleaning unmaintained… i checked history for last year and there’s no single commit deleting anything in unmaintained except moving things to other repos… to be clear, I’m not against cleaning unmatainted, but you said that it’s common practice to clean it, but clearly it’s not
2017-11-30 21:11:32 <jirutka> i don’t know how to easily filter out renaming of files, so cannot tell when the last deletion happened :/
2017-11-30 21:13:06 <jirutka> Wed May 11 16:43:52 2016 +0000 unmaintained/: Purge packages unmaintained since v3.0
2017-11-30 21:13:59 <jirutka> “…these packages have not been touched since at least 23 months.”
2017-11-30 21:15:09 <ncopa> i think we talked about it earlier release cycle
2017-11-30 21:15:34 <ncopa> and i got the impression that osmone was supposed to delete earlier
2017-11-30 21:15:47 <ncopa> but i never followed up if anybody actually did
2017-11-30 21:15:58 <jirutka> this is just another example why we should finally start *writing* such rules :/
2017-11-30 21:16:28 <jirutka> so, now the rule is to clean unmaintained before each release and remove stuff with last modification >6 months, right?
2017-11-30 21:17:05 <jirutka> btw we do we even have unmaintained? you can always rescue unmaintained abuild from git history, I don’t see any value in unmaintained/
2017-11-30 21:19:03 <ncopa> are you intentionally trying to stall the 3.7 release?
2017-11-30 21:19:17 <jirutka> eh, sorry, no
2017-11-30 21:19:46 <jirutka> ok, let’s postpone this after release
2017-11-30 21:19:47 <ncopa> can you please bring this up after 3.7 release then?
2017-11-30 21:20:09 <jirutka> yes
2017-11-30 21:20:20 <ncopa> you can help by looking over the unmaintained/* that is older than 6months an purge those
2017-11-30 21:20:37 <ncopa> or write a script that can be run from a cron job (even better)
2017-11-30 21:21:10 <jirutka> or remove unmaintained/ completely… ;)
2017-11-30 21:21:42 <jirutka> oh crap, I need to go, building is closing
2017-11-30 21:21:51 <_ikke_> There might be a bit value in having it in unmaintained first
2017-11-30 21:23:15 <_ikke_> Seems like this one can be closed? https://bugs.alpinelinux.org/issues/7917
2017-11-30 21:23:43 <ncopa> looks so
2017-11-30 21:23:52 <ncopa> please close if you think so
2017-11-30 21:23:57 <ncopa> (i didnt read the details)
2017-11-30 21:24:30 <_ikke_> I just wasn't sure if it was actually resolved, or there was still something that needed to be done
2017-11-30 21:27:49 <_ikke_> What about a bugfix that needs new packages?
2017-11-30 21:28:19 <_ikke_> I did saw pull requests already for it, but I think they didn't make 3.7.0
2017-11-30 21:30:55 <ncopa> which issue is that?
2017-11-30 21:31:04 <_ikke_> py-twisted not working
2017-11-30 21:31:17 <_ikke_> https://bugs.alpinelinux.org/issues/7883
2017-11-30 21:31:58 <ncopa> i think we shoudl try fix that for 3.7.1
2017-11-30 21:32:24 <_ikke_> ok
2017-11-30 21:33:47 <ncopa> i wonder if we shoudl bother this: https://bugs.alpinelinux.org/issues/7870
2017-11-30 21:33:52 <ncopa> its just cosmetical
2017-11-30 21:33:56 <ncopa> hm
2017-11-30 21:34:05 <ncopa> actually
2017-11-30 21:34:07 <ncopa> lets fix it
2017-11-30 21:34:17 <_ikke_> I was planning to move it to 3.7.1
2017-11-30 21:35:25 <_ikke_> Ah, you already moved a lot
2017-11-30 21:36:19 <_ikke_> done
2017-11-30 21:36:37 <ncopa> whee!
2017-11-30 21:36:42 <ncopa> thank you!
2017-11-30 21:36:47 <_ikke_> You too :)
2017-11-30 21:37:11 <dsabogal> regarding xen, i ran into an oom issue before (but this was early 2017). i resolved it by bumping dom0_mem in /boot/extlinux.conf
2017-11-30 21:37:27 <ncopa> aha
2017-11-30 21:37:32 <ncopa> that might be the issue then
2017-11-30 21:37:48 <ncopa> maybe we should bump the default?
2017-11-30 21:40:12 <ncopa> last time i ask: is this ok? http://wwwtest.alpinelinux.org/posts/Alpine-3.7.0-released.html
2017-11-30 21:40:31 <_ikke_> Let me check
2017-11-30 21:41:48 <dsabogal> it looks ok
2017-11-30 21:42:01 <ncopa> i will add a proper git stats after the tagging
2017-11-30 21:42:40 <dsabogal> except that 3.6.0 release notes capitalized certain packages differently
2017-11-30 21:42:59 <ncopa> was url to upstream?
2017-11-30 21:43:03 <ncopa> link i mean
2017-11-30 21:43:14 <ncopa> oh, now i understand
2017-11-30 21:43:31 <ncopa> dsabogal: any suggestion how to capitalize it?
2017-11-30 21:45:00 <ncopa> jirutka: the .gitignore issue: core\n!core/
2017-11-30 21:45:17 <ncopa> the \n is not a litteral '\n', right?
2017-11-30 21:46:50 <dsabogal> 3.5.0 used PostgreSQL, 3.6.0 used Go, Rust. it's not exactly consistent across all release notes either tho
2017-11-30 21:47:03 <Shiz> ncopa: it has some typos
2017-11-30 21:47:20 <Shiz> support for grub boot loader -> support for the GRUB boot loader
2017-11-30 21:47:28 <Shiz> nodejs -> node.js
2017-11-30 21:47:32 <Shiz> perl -> Perl
2017-11-30 21:47:36 <Shiz> postgresql -> PostgreSQL
2017-11-30 21:47:40 <Shiz> rust -> Rust
2017-11-30 21:47:49 <Shiz> go -> Go
2017-11-30 21:48:24 <Shiz> first bullet point under credits needs an exclamation mark
2017-11-30 21:48:32 <ncopa> Shiz and/or dsabogal: can you please tpaste a patch? git://git.alpinelinux.org/alpine-mksite
2017-11-30 21:48:47 <ncopa> im gonna do the tag now
2017-11-30 21:49:00 <ncopa> please hold you pushes to aports....
2017-11-30 21:50:43 <ncopa> its in the oven...
2017-11-30 21:51:33 <Shiz> ncopa: https://txt.shiz.me/MTk1ZjNhY2.txt
2017-11-30 21:52:34 <_ikke_> anyone got a clue how to test a stream of bytes for a NUL byte? Most methods I find all rely on non-posix / gnu toolset
2017-11-30 21:54:39 <danieli> _ikke_: \x00 in sed?
2017-11-30 21:55:09 <_ikke_> yes, but then?
2017-11-30 21:56:15 <danieli> hmm, stream, right
2017-11-30 21:56:29 <_ikke_> But I want a boolean output
2017-11-30 21:56:50 <danieli> perhaps you can pull the error code?
2017-11-30 21:57:37 <_ikke_> I don't think sed does set the error code
2017-11-30 21:58:20 <jirutka> ncopa: \n is not literal
2017-11-30 21:58:25 <_ikke_> there is q, but the exit code is a gnu extension
2017-11-30 21:58:28 <danieli> ah right, i'm thinking of q
2017-11-30 21:58:30 <danieli> let's see
2017-11-30 21:58:38 <danieli> https://unix.stackexchange.com/a/88126
2017-11-30 21:59:04 <jirutka> Shiz: actually it’s Node.js, not node.js
2017-11-30 21:59:23 <Shiz> good catch
2017-11-30 22:00:01 <jirutka> _ikke_: I coded that check (binary file) somewhere… I’ll try to remember where
2017-11-30 22:02:17 <_ikke_> right
2017-11-30 22:02:38 <dsabogal> Shiz: good catch on 'new and updated aports'
2017-11-30 22:02:59 <ncopa> jirutka: please feel free to fix the .gitignore
2017-11-30 22:03:23 <dsabogal> im not sure how i feel about articles/end-punctuations in bullets tho
2017-11-30 22:03:39 <ncopa> we can remove those
2017-11-30 22:07:19 <_ikke_> danieli: seems like busybox sed does not even recognize \x00
2017-11-30 22:07:51 <danieli> dammit
2017-11-30 22:10:55 <jirutka> I’d just use file, but it’s not in busybox, requires pkg
2017-11-30 22:11:00 <jirutka> i mean file(1)
2017-11-30 22:11:02 <_ikke_> right
2017-11-30 22:12:15 <ncopa> http://wwwtest.alpinelinux.org/posts/Alpine-3.7.0-released.html
2017-11-30 22:12:34 <ncopa> i wonder if I shuold remove the bullets under "credits"
2017-11-30 22:12:44 <ncopa> and add a "Changes" subtitle
2017-11-30 22:12:49 <_ikke_> same version?
2017-11-30 22:13:11 <_ikke_> ah, now it's updated
2017-11-30 22:13:14 <ncopa> refresh
2017-11-30 22:14:24 <ncopa> like this: http://tpaste.us/nZm4
2017-11-30 22:15:46 <ncopa> i wonder if I should remove the "commit statistics"
2017-11-30 22:16:02 <ncopa> and make it "contributors"
2017-11-30 22:16:08 <ncopa> sorted by name
2017-11-30 22:17:52 <jirutka> that would not make much sense
2017-11-30 22:18:15 <jirutka> these numbers are number of commits
2017-11-30 22:18:36 <_ikke_> that much is clear
2017-11-30 22:19:03 <ncopa> point would be to have a list of all contributors
2017-11-30 22:19:09 <ncopa> without any ranking
2017-11-30 22:19:13 <jirutka> aha
2017-11-30 22:19:25 <ncopa> there are some interesting ones though
2017-11-30 22:19:26 <jirutka> I dunno
2017-11-30 22:19:27 <ncopa> like null
2017-11-30 22:19:29 <ncopa> H
2017-11-30 22:19:44 <ncopa> some are dupes
2017-11-30 22:19:51 <jirutka> so clear it…? ;)
2017-11-30 22:19:53 <ncopa> due to used different email addresses
2017-11-30 22:19:59 <Shiz> i agree ncopa
2017-11-30 22:20:42 <dsabogal> we could split credits + commit-statistics into sponsors + contributors
2017-11-30 22:21:18 <jirutka> since I’m on the 2nd place I’m biased about removing ranking :P so it’s up to you
2017-11-30 22:21:52 <ncopa> :)
2017-11-30 22:22:21 <Shiz> i don't think i contributed at all this cycle so i don't think i'eve got a lot of bias
2017-11-30 22:22:22 <Shiz> :P
2017-11-30 22:22:44 <ncopa> jirutka you are still 2nd: https://git.alpinelinux.org/cgit/aports/stats/?period=q&ofs=10
2017-11-30 22:22:46 <Shiz> otoh, not sure
2017-11-30 22:23:07 <ncopa> i just thought that it would be nicer without ranking
2017-11-30 22:24:35 <ncopa> are there some other commit stats we could publish?
2017-11-30 22:24:48 <ncopa> number of total commits, number of adds/removes
2017-11-30 22:25:13 <jirutka> all have some issues
2017-11-30 22:25:35 <jirutka> I’d just let it be
2017-11-30 22:25:40 <jirutka> as it is know
2017-11-30 22:26:41 <ncopa> and my time is up...
2017-11-30 22:27:55 <_ikke_> ncopa: you know of .mailmap?
2017-11-30 22:28:16 <ncopa> no?
2017-11-30 22:28:31 <_ikke_> allows you to normalize contributors
2017-11-30 22:30:04 <_ikke_> You add entries in there where you specify the canonic name / email adress, together with a non-canonical version
2017-11-30 22:30:28 <ncopa> i think i used it when importing from svn
2017-11-30 22:30:37 <_ikke_> right
2017-11-30 22:30:53 <_ikke_> It does exist in the repo
2017-11-30 22:31:16 <_ikke_> :q
2017-11-30 22:31:46 <ncopa> heh
2017-11-30 22:32:54 <_ikke_> jirutka: Still testing, but file seems to be slow, even if I pass it very little data. ~3 seconds for 100 files
2017-11-30 22:42:31 <_ikke_> jirutka: http://tpaste.us/zbNZ
2017-11-30 22:43:35 <jirutka> okay, using file(1) was a bad idea
2017-11-30 22:45:00 <ncopa> thank you everyone for helping getting 3.7.0
2017-11-30 22:45:08 <ncopa> last point on my checklist is:
2017-11-30 22:45:14 <ncopa> celebrate! \o/
2017-11-30 22:45:24 <_ikke_> \o/
2017-11-30 22:45:33 <dsabogal> \o/
2017-11-30 22:45:38 <jirutka> _ikke_: GNU grep ignores binary files and so it detects them, but busybox grep does not :/
2017-11-30 22:45:42 <jirutka> \o/
2017-11-30 22:45:56 <_ikke_> jirutka: right
2017-11-30 22:46:09 <_ikke_> busybox seems to have very little that handles NUL bytes
2017-11-30 22:46:12 <Shiz> \o/
2017-11-30 22:46:50 <jirutka> ncopa: btw when writing on behalf of community/organization/whatever-group, use “we”, not “I” ;)
2017-11-30 22:47:54 <_ikke_> context: https://twitter.com/alpinelinux/status/936364858571927558
2017-11-30 22:47:58 <jirutka> so I’m gonna enable 3.7 on pkgs.a.o, update alpine-chroot-install etc.
2017-11-30 22:53:40 <ncopa> sorry
2017-11-30 22:53:43 <ncopa> im tired
2017-11-30 22:54:54 <skarnet> never cut a release late at night :P
2017-11-30 22:57:18 <jirutka> np, go to get some sleep ;)
2017-11-30 23:12:27 <xentec> \o/
2017-11-30 23:20:52 <danieli> \o/
2017-11-30 23:20:56 <danieli> dance for 3.7
2017-11-30 23:33:58 <PureTryOut[m]> congratz on the 3.7 release people!
2017-11-30 23:33:59 <PureTryOut[m]> \o/
2017-11-30 23:40:41 <Shiz> thanks :)