<    April 2017    >
Su Mo Tu We Th Fr Sa  
                   1  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 29  
30
00:06 <jirutka> i didn’t made any edit
00:06 <jirutka> or what do you mean?
00:09 <jirutka> gn
00:10 <Shiz> jirutka: the PR said 'edited by jirutka' in the first post
00:10 <Shiz> so not sure
00:13 <jirutka> hm, that’s probably caused by Octoroid (Android client for GitHub)
00:13 <Shiz> ah
00:13 <jirutka> I’ve updated labels, but Octodroid has single form for updating anything in issue…
00:15 <jirutka> that kinda sucks :/ I should probably finally switch GH client, Octodroid is abandoned :/
00:15 <jirutka> kay, but now really gn :)
00:16 <Shiz> nite \o
01:16 s33se joined
01:51 s33se joined
04:19 BitL0G1c joined
04:22 BitL0G1c1 joined
05:04 fabled joined
05:06 qrwteyrutiyoup joined
06:52 vakartel joined
08:04 t0mmy joined
08:07 blueness joined
08:08 royger joined
08:50 <tmh1999> fabled : Hi, are we abandoning patchwork.a.o and moving to github pr, or everyone's too busy this time ?
08:51 <skarnet> oh, it's this suggestion again! Hello my old friend, it's been a long time!
09:03 t0mmy joined
09:04 <scadu> XD
09:15 blueness joined
09:22 fekepp joined
09:42 <tmh1999> skarnet : I'm sorry ? :D
09:54 elroncio joined
10:02 leo-unglaub joined
10:20 cyteen joined
11:18 blueness joined
11:30 kaniini joined
12:14 leitao joined
12:44 czart__ joined
13:07 <jirutka> tmh1999: that would be great, but unfortunately it’s more the further option… anyway, you have greater chance to get your patches merged soon via GH
13:10 <^7heo> skarnet: I don't get why you're so uptight about github; forking is caring, isn't it? :D
13:11 <* ^7heo> runs to hide behing the biggest rock he can find
13:11 <jirutka> ^7heo: please don’t provoke him ;)
13:11 <^7heo> jirutka: it's a friendly provocation; implicitely agreeing with his point; can't you see?
13:12 <^7heo> jirutka: use sarcasm on it; it's very effective.
13:12 fekepp joined
13:43 pbr joined
13:50 <ncopa> kaniini: libuv test suite fails in fakeroot
13:51 <ncopa> due to setuid
13:51 <ncopa> i wonder if we should have an option to make the test run as non-fakeroot?
13:51 <jirutka> ncopa: definitely not
13:51 <ncopa> or always run the tests as non-fakeroot and have an option to run them as fakeroot for those who needs it
13:52 <jirutka> ncopa: it used to run as non-fakeroot, fabled fixed it after my report
13:52 <ncopa> are there many that requires to run as root/fakeroot?
13:53 <ncopa> im thinking: options="check-fakeroot"
13:53 <ncopa> or: options="check-as-normal-user"
13:53 <ncopa> alternatively i just disable the tests that fails
13:54 <jirutka> dunno, but running check without any isolation is not a good idea
13:54 <ncopa> is running check worse than running build?
13:54 <jirutka> the problem is that some tests may do bad things
13:54 <jirutka> no
13:54 <jirutka> but build runs in fakeroot, doesn’t it?
13:55 <ncopa> no
13:55 <jirutka> huh o.O
13:55 <ncopa> only make install
14:02 <jirutka> I’m trying to find where I wrote the issue with check after that fabled changed it to run in fakeroot, but cannot find it :(
14:03 <jirutka> but tbh I’m really surprised now that build does not run in fakeroot, I thought that everything run in fakeroot, except check (before it was changed)
14:04 t0mmy joined
14:06 <ncopa> building as normal user and not in fakeroot was done very early
14:07 <ncopa> and that was the reason that package() got its own function
14:07 <ncopa> because fakeroot woudl kill the parallelism of make -j
14:07 <jirutka> IIRC the problem I had was that script was able to created some files in /, so it run with root privileges or used sudo or something
14:07 <jirutka> (script run in check)
14:08 <ncopa> running sudu could make damage yes
14:08 <ncopa> sudo*
14:08 <jirutka> I wrote that to fabled and he come with idea to run check in fakeroot
14:08 <ncopa> yeah
14:08 <ncopa> its probably good to do so
14:08 <jirutka> I thought that, but not sure now
14:09 <ncopa> i disabled the tests in libuv
14:09 <ncopa> the setuid/setgid tests
14:09 serge joined
14:09 <serge> Hi
14:10 <jirutka> btw I’d like to propose the following change: run check _after_ package; to be sure that badly written `make check` will not rebuild binaries with different parameters
14:10 <ncopa> might be good idea yes
14:10 <ncopa> hum
14:10 <ncopa> might not work
14:10 <serge> Would anyone know how if there is any package providing kernel sources for alpine ?
14:10 <ncopa> well should work
14:11 <ncopa> i was thinking that we split the pkgs
14:11 <ncopa> but that does not matter
14:11 <Shiz> serge: not that i know of
14:11 <ncopa> serge: no
14:11 <serge> ok
14:11 <serge> Next question then
14:11 <serge> If I want to add scup kernel module to alpine, how am I supposed to do then ?
14:11 <serge> sctp*
14:12 <Shiz> clone aports, setup build env
14:12 <Shiz> change the kernel config to what you want, build with abuild and install
14:12 <Shiz> :P
14:12 <Shiz> https://wiki.alpinelinux.org/wiki/Setup_your_system_and_account_for_building_packages
14:13 <ncopa> looks like we already build sctp as module?
14:13 <ncopa> $ grep SCTP * | tpaste
14:13 <ncopa> http://tpaste.us/pQxk
14:13 <Shiz> yeah looks like it
14:13 <Shiz> just modprobe sctp
14:13 <Shiz> or add to /etc/modules
14:14 <serge> Well.. that must come from the specific version I use then :/
14:15 <serge> "Linux moby 4.9.13-moby #1 SMP Sat Mar 25 02:48:44 UTC 2017 x86_64 Linux"
14:15 <ncopa> ha!
14:15 <serge> I'm in the hyperkit vm used by docker (for Mac)
14:15 <Shiz> that doesn't look like an alpine kernel
14:15 <ncopa> thats not alpine kernel
14:15 <Shiz> :P
14:16 <serge> well... any clues to help me ? :/
14:16 <ncopa> i think they opensourced moby recently?
14:16 <ncopa> or was renamed to linuxkit
14:16 Emperor_Earth joined
14:17 <Shiz> moby is part of linuxkit
14:17 <Shiz> afaik
14:17 <Shiz> https://github.com/linuxkit/linuxkit/tree/master/src/cmd/moby
14:17 <Shiz> # CONFIG_IP_SCTP is not set
14:17 <ncopa> https://github.com/linuxkit/linuxkit
14:17 <Shiz> (from: https://github.com/linuxkit/linuxkit/blob/master/kernel/kernel_config )
14:17 <ncopa> yes
14:17 <ncopa> there is where you build it
14:18 <ncopa> clone that and build the kernel there
14:18 <Shiz> this kernel config is quite a mess...
14:18 <Shiz> it enables iptables tracking for SCTP but not SCTP itself
14:18 <Shiz> :P
14:18 <serge> Thanks Shiz :D
14:19 <ncopa> i suppose you could make PR to linuxkit
14:19 <Shiz> ncopa: unrelatedly: apparently alpine is the only linux distro supported by openbsd's new vm mechanism :P
14:20 <ncopa> thats cool :)
14:24 <^7heo> Did docker move to moby because of the bad connotation with the docker name?
14:24 <^7heo> much like ie -> edge?
14:24 <pbr> Hi! What version of GCC will ship with Alpine 3.6? As per https://gcc.gnu.org/ml/gcc/2017-04/msg00080.html, GCC 7.1 will be out by the end of the month.
14:24 <Shiz> moby doesnt replace anything about docker
14:25 <^7heo> Shiz: it does replace the docker name tho.
14:25 <Shiz> not really?
14:25 <^7heo> Shiz: https://github.com/docker/docker
14:25 <^7heo> Shiz: please check.
14:25 <Shiz> bleh
14:25 <Shiz> news that came out two days ago is cheating!
14:25 <^7heo> Bleh yourself.
14:25 <^7heo> :D
14:26 <ncopa> they have dockercon now
14:26 serge joined
14:26 <ncopa> and i know they were announcing this new stuff
14:27 <Shiz> hmm
14:27 <Shiz> 3.6 is due to release late may, right?
14:27 fabled joined
14:27 <Shiz> im a bit wary about a month's time to switch to a new version of the base system compiler
14:27 <Shiz> considering regressions
14:28 <Shiz> pbr: also, did they just skip gcc 7.0?
14:28 <pbr> i know, it's pretty close..
14:28 <ncopa> early may
14:28 <ncopa> we will not upgrade kernel for v3.6
14:28 <pbr> as per the new naming scheme 7.0, 8.0 etc are the pre-release versions. the first stable, actual release is N.1
14:28 <pbr> there was no 6.0 either
14:28 <Shiz> lol
14:29 <xentec> Shiz, they do it since 6.1, because .1 seems more stable for some
14:29 <Shiz> because it was, mostly
14:29 <ncopa> im have been setting up the builders for 3.6 today
14:29 <Shiz> x.0 releases of gcc were notoriously buggy
14:29 <Shiz> :P
14:29 <Shiz> ncopa: i hope we can fix the opensmtpd issues before release then...
14:29 <ncopa> yes
14:30 <ncopa> once the builders are up we should focus on fixing things
14:30 <pbr> alright, so alpine 3.6 will come with gcc 6.3?
14:30 <ncopa> and not introduce new stuff
14:30 <ncopa> and new breakages
14:30 <ncopa> pbr yes
14:30 <ncopa> gcc 6.3
14:30 <pbr> cool, thanks!
14:31 <jirutka> ncopa: have you reported that bug in nginx/libressl, or should I do it?
14:32 <Shiz> speaking of getting things in before the builders
14:32 <ncopa> jirutka i havent
14:32 <* Shiz> chases jirutka for the Rust PR
14:32 <ncopa> please do
14:32 <Shiz> :p
14:32 <jirutka> Shiz: I know, I know, at evening, I’m at work now
14:32 <Shiz> :)
14:33 <jirutka> Shiz: maybe you can report that bug with nginx/libressl meanwhile, instead of me? :)
14:33 <Shiz> do you have a reference?
14:33 <Shiz> im not sure what its about so
14:34 <xentec> since no one replied last time, I ask again: shouldn't pkgs, which depend on ncurses-terminfo, rather depend ncurses-terminfo-base since it's much smaller?
14:35 <Shiz> theyren ot identical though
14:35 <Shiz> -base is the stuff in /etc, normal terminfo is the stuff in /usr/share
14:35 <xentec> yes, but ncurses searches for both as indicated in APKBUILD
14:37 <xentec> it's just that ncurses-terminfo is really big and contains terminfo data nearly no one would use in these days
14:41 BitL0G1c joined
15:11 <kaniini> jirutka actually i fixed it
15:11 <kaniini> :p
15:11 <jirutka> kaniini: what?
15:11 <kaniini> jirutka: https://git.alpinelinux.org/cgit/abuild/commit/?id=1ddc910eb328b4534234bd2f97e631a075241abd
15:12 <jirutka> kaniini: I know about this
15:13 <jirutka> kaniini: the problem is that ncopa has some test that doesn’t work in fakeroot b/c it uses setuid
15:13 <kaniini> oh well
15:14 <kaniini> sounds like a defective test to me
15:14 <kaniini> unless it specifically is testing some behaviour under serious
15:14 <kaniini> err
15:14 <kaniini> setuid
15:15 <jirutka> agree with you
15:16 <ncopa> i disabled the tests involving setuid setgid
15:43 <serge> Thanks again
15:43 <serge> I just did the PR and solved my fuck** issue with scup support over containers \o/
15:43 <algitbot> \o/
15:46 minimalism joined
16:01 rdutra joined
17:23 <jirutka> Shiz: what does `fully_static` mean? static without PIE?
18:23 fekepp joined
18:31 leitao joined
18:32 tty joined
18:33 tty`_ joined
18:43 cyteen joined
19:10 fekepp joined
19:37 <ncopa> im starting up the 3.6 builders
19:39 <tmh1999> \o/
19:39 <algitbot> \o/
19:43 <ncopa> 3.6 builders are up
19:43 <ncopa> except ppc64le
19:44 <ncopa> will do that tm
19:44 <ncopa> i suspect the new ppc64le machine will easily catch up :)
19:53 <jirutka> what, already?!
19:54 <jirutka> we haven’t pushed rust and ghc into community yet
19:54 <jirutka> and I’d like to improve few things in abuild
20:02 blueness joined
20:33 <mitchty> ooh ooh idris too! lets get 3 languages into community >.<
20:34 <mitchty> i think i got all the comments fixed
20:34 <mitchty> idris being my new favorite "beat my head against the wall" thing to learn
20:59 blueness joined
21:05 <TemptorSent> Question: Does 'apk --print-arch' always give the arch of the host, even when a different root has a different arch in use?
21:07 <TemptorSent> If so, would it make sense to rename it to '--host-arch' and make '--print-arch' return the arch of the current apk root?
21:09 <tmh1999> TemptorSent : I think if it is apk.static, then it will print the arch of that apk
21:10 <tmh1999> if it is no static, then the arch it is running in.
21:11 dfs joined
21:12 <tmh1999> TemptorSent : https://git.alpinelinux.org/cgit/apk-tools/tree/src/apk.c#n52
21:20 <TemptorSent> tmh1999: Thanks. Talk about confusing behavior!
21:22 t0mmy joined
21:23 <Shiz> jirutka: just fully static :P
21:24 <jirutka> Shiz: how that different from crt-static?
21:24 <Shiz> in crt-static only the c runtime is static
21:24 <Shiz> instead of every library
21:25 dfs_ joined
21:28 stwa joined
21:43 <skarnet> how do you make the crt static when other libraries are dynamic ?...
21:43 <skarnet> how do those libraries resolve their deps to the crt ?
21:44 <skarnet> if A depends on B, I can see both A and B being static, both being dynamic, and A being static while B is dynamic, but certainly not the reverse
21:58 <Shiz> skarnet: on unix, you can't
21:58 <Shiz> that's why in our patches, crt_static implies fully_static for unices
21:58 <Shiz> on windows, you can
21:58 <Shiz> since dlls can carry their own C runtime
21:59 <skarnet> and people wonder why Windows is so heavy
21:59 <Shiz> can does not mean "they all do"
21:59 <skarnet> I very much hope they don't
21:59 <skarnet> and that basically mean no state in the crt
21:59 <skarnet> how do they even pull it off
21:59 <skarnet> means*
22:00 <Shiz> it doesn't
22:00 <Shiz> what makes you think that
22:00 <Shiz> :p
22:00 <skarnet> if you have several copies of the crt...
22:00 <Shiz> yes?
22:00 <skarnet> state is gonna desync fast
22:00 <Shiz> thats why you dont share CRT stuff of different versions between DLLs
22:00 <Shiz> like FILE*s
22:13 dfs joined
22:32 <jirutka> Shiz: so this logic was basically totally broken whole time, in Rust build system? o.O
22:33 <skarnet> you sound surprised
22:33 <jirutka> to be honest, I am
22:38 <jirutka> I thought that it was just buggy
22:41 <jirutka> Shiz: please restore my trust in Rust developers…
22:48 tmh1999 joined
22:52 <Shiz> jirutka: their static linking logic was kinda flaky at best, yes
22:52 <Shiz> (was traveling)
22:54 <Shiz> jirutka: is the missing patch desc all that is needed?
22:54 <jirutka> Shiz: yes
22:54 <Shiz> time for another rebase
22:54 <Shiz> :P
22:54 <jirutka> :)
22:54 <Shiz> gimme... 5 mins
23:05 <Shiz> jirutka: done
23:28 attractr joined