<    April 2017    >
Su Mo Tu We Th Fr Sa  
 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  
00:00 <jirutka> MS wants to support Alpine?
00:00 <kaniini> yes, alpine is a primary goal for them for .net core
00:01 <Shiz> docker docker docker docker
00:01 <jirutka> hmm
00:01 <Shiz> still compiling rust...
00:01 <Shiz> my patch had a small error
00:03 <tmh1999> kaniini : can I ask you a favor :D
00:03 <kaniini> ?
00:04 <kaniini> Shiz: amongst other reasons, yes :)
00:04 <tmh1999> these 2 are marked Accepted http://patchwork.alpinelinux.org/patch/3286/, http://patchwork.alpinelinux.org/patch/3291/, but only the first one is merged in aports tree. The first one is v1, the second one is v2 I submitted.
00:04 <tmh1999> kaniini : ^
00:05 <tmh1999> kaniini : https://git.alpinelinux.org/cgit/aports/commit/?id=ca4896137afab172462b49af6719d3f1a4a4f249
00:05 <kaniini> tmh1999: patch fails to apply
00:06 <kaniini> tmh1999: please rebase and send me a .mbox
00:06 <tmh1999> kaniini : yes because the 1st one is not supposed to be applied ... OKay I'll send another one
00:07 <jirutka> tmh1999: or just open pull request on GitHub to avoid such stupid problems…
00:07 <Shiz> :P
00:12 <tmh1999> kaniini : http://tpaste.us/kqnb
00:14 <kaniini> tmh1999: ok give me 15 min and it will be done
00:14 <tmh1999> kaniini : thank you :)
00:14 <jirutka> kaniini: btw can’t be simply update config/guess automatically when outdated?
00:15 <jirutka> s/be/we/
00:15 <kaniini> yes
00:15 <kaniini> i thought of that earlier doing it in prepare
00:16 <jirutka> abuild is already able to find config/guess file and has own copy of them, so it should be just a matter of ~2 lines to automatically update when old
00:21 <jirutka> hmm, maybe I’ve already ported these llvm patches, when creating emscripten-fastcomp
00:22 <jirutka> I’m not sure on which version it’s based
00:23 <jirutka> kaniini: not sure if you know, we have even more llvm pkgs, emscripten-fastcomp is emscripten’s fork of LLVM… yeah, everyone has it’s own fork of LLVM… unfortunatelly Emscripten does not work with vanilla LLVM yet :(
00:23 <jirutka> this world is insane…
00:24 <Shiz> jirutka: testing my patch now
00:24 <Shiz> :)
00:24 <Shiz> jirutka: also i remember the times rustllvm wasn't upstream-compatible either
00:24 <Shiz> fun times
00:24 <jirutka> yeah and they still have own fork of LLVM…
00:25 <kaniini> tmh1999: done
00:25 <Shiz> jirutka: at least they support mainline now
00:25 <Shiz> they didn't back in the day
00:25 <jirutka> yeah
00:25 <tmh1999> kaniini : I appreciate it
00:25 <Shiz> what's actually different in their fork?
00:25 <Shiz> do you happen to know?
00:25 <jirutka> Shiz: that’s the billion dollar question!
00:26 <Shiz> jirutka: apparently it's because some platforms don't have a system LLVM
00:26 <Shiz> like osx
00:27 <Shiz> and an optional patch: https://github.com/rust-lang/llvm/commit/ed0d1402540eeb8c9ac610234c581c9612542b28
00:27 <Shiz> even their travis buildbot uses system llvm
00:30 <Shiz> jirutka: good news :)
00:30 <jirutka> Shiz: it works?
00:31 <Shiz> well, it fails because we have no libgit2.a
00:31 <Shiz> or libcurl.a
00:31 <Shiz> but... yes
00:31 <Shiz> :p
00:31 <jirutka> yay!
00:31 <jirutka> I’ll add libgit2.a
00:32 <Shiz> = note: /usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lgit2
00:32 <Shiz> /usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lcurl
00:32 <Shiz> collect2: error: ld returned 1 exit status
00:32 <Shiz> slightly weird since libcurl.a is right there under curl-dev
00:32 <Shiz> hmmm
00:33 <jirutka> Shiz: btw I’m impressed by your skills! :)
00:33 <Shiz> of what? :P
00:33 <Shiz> (thanks for the compliment though!)
00:33 <jirutka> skills… is that correct word for it?
00:34 <Shiz> you're rather pleasant to work with yourself :)
00:34 <Shiz> we're doing well in tackling this thing together i feel ;p
00:37 <jirutka> yeah, but currently it’s more your merit than mine, I don’t have enough experience with analyzing ELF binaries etc. to solve this and also not enough patience for it anymore
00:38 <Shiz> nonsense
00:38 <Shiz> we're just doing different things :)
00:38 <Shiz> also
00:39 <Shiz> it seems we do not in fact ship libcurl.a
00:39 <Shiz> https://git.alpinelinux.org/cgit/aports/tree/main/curl/APKBUILD?h=3.4-stable#n70
00:39 <Shiz> :(
00:39 <Shiz> https://git.alpinelinux.org/cgit/aports/tree/main/curl/APKBUILD?h=master#n62 even
00:39 <jirutka> I’ll fix it asap
00:39 <jirutka> is there some “standard” flag for CMake to force it install .a archive?
00:40 <Shiz> i'll compile locally
00:40 <Shiz> i presume it's
00:40 <Shiz> -DBUILD_STATIC_LIBS=True
00:41 <jirutka> I’ve tried that with another lib and it didn’t work, so not sure how “standard” it really is
00:44 <Shiz> hmm
00:44 <Shiz> jirutka: ugh
00:45 <Shiz> jirutka: you need to set -DBUILD_SHARED_LIBS=False
00:45 <Shiz> build
00:45 <Shiz> and then rebuild with that to =True
00:45 <jirutka> ’kay, I’ll solve it in same way as with llvm-libunwind
00:45 <Shiz> :P
00:45 <jirutka> i.e. build twice
00:45 <jirutka> but it’s silly :/
00:46 <jirutka> or I’ll try to patch this CMakeLists.txt
00:54 <Shiz> jirutka: want an updated static-pie.patch?
01:03 <Shiz> jirutka: https://txt.shiz.me/MDQ5NjE4Yz
01:26 s33se_ joined
01:41 <Shiz> jirutka: \o/ static pie works
01:41 <algitbot> \o/
01:41 <Shiz> we may need to add -Wl,-( and -Wl,-) back to the linker command line, though
01:52 <jirutka> Shiz: excellent! \o/
01:52 <algitbot> \o/
01:52 <Shiz> we do need to add -Wl,-( and -Wl,-) back
01:52 <Shiz> do you remember what that broke/why we deleted it in the first place?
01:52 <jirutka> Shiz: I’ve added static lib to libgit2 and curl and pushed
01:52 <Shiz> :)
01:53 <jirutka> Shiz: it didn’t break anything IIRC, just thought that it’s not needed
01:53 <Shiz> ah
01:53 <jirutka> I need to go sleep, gn
01:53 <Shiz> it is needed for static linking
01:53 <Shiz> good night!
02:14 cyteen joined
02:54 <tmh1999> leitao : have you tried to build on x86/x86_64 ? This commit breaks newsbeuter : https://git.alpinelinux.org/cgit/aports/commit/main/newsbeuter?id=eb4f085009a73d1f2bd65abe5a8c86894155be23
03:25 <tmh1999> kaniini : reading your previous conversation, looks like there's a plan to move to llvm3.9 soon?
03:26 <tmh1999> s/move/add/
04:23 <kaniini> yes
04:23 <kaniini> and then drop llvm (which is 3.8.1)
04:23 <kaniini> so that rust and julia are built against a versioned llvm
05:14 fabled joined
05:27 terra joined
05:37 <TemptorSent> Good evening fabled.
06:06 t0mmy joined
07:01 royger joined
07:17 t0mmy joined
07:19 faffolter joined
07:19 faffolter joined
07:24 blahdodo joined
07:55 fekepp joined
07:58 stwa joined
07:59 fekepp1 joined
08:08 t0mmy joined
08:10 fabian_a joined
08:11 stwa joined
08:22 stwa joined
08:31 <xsteadfastx> for python packages pkgs... shouldnt be python in the "depends"?
08:31 <xsteadfastx> i ask for the py-gst1 package
08:32 tmh1999 joined
08:34 <clandmeter> xsteadfastx: https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python
08:35 <clandmeter> but this does not include a makefile variant
08:35 <clandmeter> but the idea is the same.
08:36 <xsteadfastx> i just dont know... i mean py-gst1 doesnt work without gstreamer1 installed... shouldnt be all this deps if its not working else?
08:36 <clandmeter> yes it should
08:36 <clandmeter> gst1 is in testing for a reason
08:37 <xsteadfastx> i will add it and do a PR and wait for some reactions :)
08:37 <xsteadfastx> btw did you saw already the changes on snapcast i added?
08:37 <clandmeter> yes that would be best
08:37 <clandmeter> no i didnt look yet
08:39 <clandmeter> xsteadfastx, did you try the snapcast-server.conf?
08:39 <xsteadfastx> yes
08:39 <xsteadfastx> doesnt it work?
08:40 <clandmeter> it looks more like an confd file then a config file.
08:40 <xsteadfastx> thats how snapcast is doing that
08:41 <xsteadfastx> dont ask me why
08:41 <xsteadfastx> you mean to add this to /etc/conf.d/?
08:41 <clandmeter> im looking
08:42 czart_ joined
08:42 <clandmeter> yes
08:42 <clandmeter> this is not how it should work
08:43 <xsteadfastx> mh ok... i rework it
08:43 <clandmeter> you should make that a confd file and adjust your initd to use the variables
08:43 <clandmeter> you should also remove the start_pre
08:44 <clandmeter> openrc will automatically source confd file
08:44 <xsteadfastx> when its the same name?
08:44 <clandmeter> correct
08:45 <xsteadfastx> so its /etc/conf.d/snapserver
08:45 <clandmeter> i guess you didnt try this initd yet, cause it wont work like this :)
08:45 vakartel joined
08:47 <jirutka> Shiz: I’ve built rustc with your updated patch for static-pie and with "-Wl,-(" / "-Wl,-)", but static binary still fails on panic
08:48 <clandmeter> the readme makes assumptions you are using it on an debian like system.
08:49 <xsteadfastx> maybe i will ditch the initd file... i tried it just running it. but i have no env to test it right now
08:49 <clandmeter> leave it.
08:49 <clandmeter> ill test it for you
08:50 <xsteadfastx> is a "snapserver.confd" that gets a /etc/conf.d/snapserver allright?
08:50 <clandmeter> yes its alright
08:51 <clandmeter> it introduces USER_OPTS and SNAPSERVER_OPTS which you can or should use in the initd
08:51 <xsteadfastx> and its get sourced by openrc?
08:52 <clandmeter> yes, names matching init.d and in conf.d
08:53 consus joined
08:53 <consus> Folks
08:53 <xsteadfastx> ok
08:53 <consus> https://git.alpinelinux.org/cgit/apk-tools/tree/src/add.c
08:54 <consus> At add.c:95 we have an apk_error() function a bad format
08:54 blueness joined
08:54 <consus> *with a bad format string
08:54 <consus> %s is given but no string is following
09:10 leo-unglaub joined
09:10 <xsteadfastx> clandmeter: updated my PR... but the stupid thing is... my py-gst1 changes are also in there
09:11 <clandmeter> you put them in the same branch?
09:11 <clandmeter> ah you are using master branch on your local repo
09:12 <clandmeter> you should use a feature branch
09:12 <xsteadfastx> ok maybe i will change that... sorry
09:12 <xsteadfastx> true... i forgot. usually i do this
09:13 <clandmeter> :)
09:14 <xsteadfastx> should be good not
09:14 <xsteadfastx> now
09:14 <clandmeter> create 2 features branches and move the specific commits to those branches
09:14 <clandmeter> ill check
09:15 <clandmeter> i see a single commit, so i guess that part is ok.
09:15 <clandmeter> i see you also changed to confd style
09:16 <clandmeter> but you are not using the conf options in confd
09:16 <clandmeter> SNAPSERVER_OPTS should be similar like command_args
09:17 <clandmeter> command_args="$SNAPSERVER_OPTS"
09:18 <clandmeter> actually like its desinged now it should be something like command_args="$USER_OPTS $SNAPSERVER_OPTS"
09:18 <xsteadfastx> where is the facepalm emoticon? ;-)
09:19 <clandmeter> what we mostly use is shells parameter expansion to set default values.
09:20 <clandmeter> similar like http://wiki.bash-hackers.org/syntax/pe#use_a_default_value
09:22 <xsteadfastx> so you mean i should do this for the USER_OPTS?
09:22 stwa joined
09:24 <clandmeter> yes, so without the confd it would still work.
09:26 <xsteadfastx> command_args="${USER_OPTS:-snapcast:snapcast} $SNAPSERVER_OPTS"
09:26 <xsteadfastx> like this?
09:27 <clandmeter> almost
09:27 <clandmeter> i think you are missing the --user when its not set
09:29 <xsteadfastx> almost mand_args="${USER_OPTS:---user snapcast:snapcast} $SNAPSERVER_OPTS"
09:29 <xsteadfastx> sorry
09:30 <clandmeter> i think that should work :)
09:32 <xsteadfastx> updated the PR
09:32 stwa joined
09:34 <clandmeter> ok ill check it
09:35 <consus> Where can I send a pull request?
09:35 <consus> Github? Mailing list?
09:35 <clandmeter> consus, github is ok, but ml also. whichever you prefer.
09:35 <consus> okay
09:35 blueness joined
09:37 <consus> Is it okay to use common compiler extensions?
09:37 czart joined
09:38 <clandmeter> what do you mean?
09:38 <xsteadfastx> clandmeter: thanks for all your help... im learning alot
09:38 <clandmeter> xsteadfastx, that was the idea :)
09:38 <xsteadfastx> yeah :)
09:39 <consus> I want to mark apk_error and other functions so gcc/clang/whatever will check the printf-like arguments
09:39 <clandmeter> you will have to talk to fabled
09:39 <clandmeter> or leave a msg in the pr/patch
09:40 <consus> Ok
09:41 leo-unglaub joined
10:01 <clandmeter> xsteadfastx, did you try snapserver?
10:05 qrwteyrutiyoup joined
10:18 <clandmeter> xsteadfastx, updated pr.
10:22 fabian_a joined
10:23 <xsteadfastx> yes... it worked for me
10:23 <clandmeter> yes, it didnt for me (was still running in bg)...
10:23 <xsteadfastx> snapclient also worked fine... even through docker
10:24 leo-unglaub joined
10:38 blueness joined
10:41 leo-unglaub joined
10:54 <xsteadfastx> any idea why its not working?
10:54 <xsteadfastx> the initd or the command itself?
11:06 leo-unglaub joined
11:07 <clandmeter> like it said, my mistake, it was still running in the background...
11:08 <xsteadfastx> ah ok :)
11:08 <xsteadfastx> good
11:08 xfix_ joined
11:21 <clandmeter> xsteadfastx, are you looking at py-gst1?
11:32 <consus> I want to find out who maintains a package. Can I do so with CLI apk tool?
11:33 <clandmeter> no i dont think so
11:33 <consus> :(
11:33 <clandmeter> you can use pkgs.a.o
11:33 <clandmeter> or grep aports
11:33 <consus> Also is there a way to froce apk to install e.g. foo-doc package when I install foo?
11:33 <clandmeter> yes
11:33 <consus> How?
11:34 <clandmeter> its a secret
11:34 <consus> =/
11:34 <consus> =\
11:34 <clandmeter> i forgot which metapkg its is :)
11:34 <consus> eh?
11:35 <consus> I have to install some metakpg in order to ask apk to install additional packages? P_P
11:35 <clandmeter> the meta pkg has an install if
11:35 <consus> Oh
11:35 <clandmeter> so if you add any pkg, it will pull also the doc pkg
11:35 <consus> Nice one
11:35 <clandmeter> if it has one
11:35 <consus> I was thinking about writing the exact same thing
11:35 <clandmeter> but i keep forgetting hwich one it is
11:36 <consus> And started diving into apk
11:36 <consus> And found a bug :D
11:36 <clandmeter> alpine-doc?
11:36 <clandmeter> if that even exists
11:36 <consus> Seems likely
11:36 <consus> Nah =/
11:36 <clandmeter> heh
11:37 <consus> > Text-based email client, friendly for novices but powerful (documentation)
11:37 <consus> :D
11:37 <consus> Guess what
11:37 <consus> I think we should find out it right now
11:37 <consus> And add it to the FAQ
11:37 <clandmeter> _ikke_, do youi remember which one it is?
11:38 <clandmeter> docs
11:38 <clandmeter> apk add docs :D
11:38 <consus> YAY
11:38 <consus> But for some reason it installs man
11:38 <consus> Ah
11:38 <consus> I got it
11:38 <consus> It's a virtual
11:38 <clandmeter> you shoudl remove the smiley else you will pull in all smileys ;-)
11:39 <consus> You made my day
11:40 <consus> Alpine looks the right choice for me now :D
11:40 <consus> I want to migrate a bunch of my internal services like cgit, smtp server and stuff like that
11:40 <consus> From my Gentoo servers
11:40 <clandmeter> sounds like a fit
11:40 <consus> Yep
11:41 <consus> Alpine is much easier to maintain via ansible
11:41 leo-unglaub joined
11:42 <consus> Though openstmpd still crashes :D
11:42 <consus> When there will be the next release?
11:42 <clandmeter> from edge?
11:42 <consus> Nah, from stable (I guess)
11:42 <consus> 3.5.2
11:42 <clandmeter> try edge
11:42 <consus> Sounds like it
11:42 <consus> Is it safe to seat on edge?
11:42 <clandmeter> i think it could be fixed but not applied to stable
11:42 <consus> It was fixed, yes
11:42 <clandmeter> you can pin it
11:43 <clandmeter> check wiki for repo pinning
11:43 <consus> Yeah already
11:43 <consus> Sounds like a plan
11:43 <clandmeter> if its broken on stable it needs to be fixed
11:43 <clandmeter> Shiz, is it broken on stable?
11:43 <consus> Oh yeah
11:44 <consus> Let my try it one more time
11:46 terra joined
11:48 rdutra joined
11:48 <consus> Oh
11:48 <consus> Nah
11:48 <consus> It fixed now
11:51 <consus> Hm... Gentoo has a very badly written script, that installs webapps to /var/www. Do alpine have something like it or should I copy the files myself?
11:52 <consus> The reason I want to do it is that cgit.cgi is not marked executable in the package (on purpose?) so I have to chmod +x it because fcgispawn will not have it any other way
11:53 <consus> And of course chmod'ing a file owned by a package manager is pretty dumb idea
11:53 <terra> if a program can be compiled for both gtk2 and gtk3, which one should I choose for packaging?
11:54 <consus> Err
11:54 <consus> Also why do I have user squid in my /etc/passwd?
11:54 <consus> I don't have squid installed
11:55 <consus> Or cyrus
11:55 <consus> Or vpopmail
11:55 <consus> Or xfs
11:58 <terra> cat /etc/shadow
11:58 <consus> Hm?
11:59 <terra> oops
12:09 <consus> clandmeter: So how about expanding FAQ?
12:10 <clandmeter> ?
12:11 <consus> I think that docs is worth mentioning in the wiki
12:11 <clandmeter> oh that part
12:11 farosas joined
12:11 <clandmeter> yes please add it.
12:11 <consus> Ok
12:19 <consus> Hmmm
12:20 <consus> I can add a package to the virtual via apk add -t foo one two
12:20 <consus> But how do I remove e.g. one?
12:28 leitao joined
12:46 leo-unglaub joined
12:52 leo-unglaub joined
13:18 <jirutka> Shiz: r u here? :)
13:19 <tmh1999> leitao : Hi, have you tried to build on x86/x86_64 ? This commit breaks newsbeuter on s390x and x86_64 for me: https://git.alpinelinux.org/cgit/aports/commit/main/newsbeuter?id=eb4f085009a73d1f2bd65abe5a8c86894155be23
13:21 <leitao> tmh1999, hum, let me check
13:21 <tmh1999> leitao : thanks
13:25 <xsteadfastx> clandmeter: i will add a PR
13:25 <clandmeter> xsteadfastx, i fixed it locally
13:25 <clandmeter> im cleaning up gobject now
13:25 <clandmeter> will push soon
13:29 <xsteadfastx> and what about the depends?
13:34 <clandmeter> its fixed
13:35 <clandmeter> was my mistake...
13:35 <xsteadfastx> ok... i just pushed my changes
13:35 <clandmeter> but now im in dependeny hell
13:38 <clandmeter> py-gst1 -> py-gobject3 -> py-cairo.... all of them dont have py3 support in aports.
13:40 BitL0G1c joined
13:42 <leitao> tmh1999, it seems I broke newsbeuter. Working to fix it.
13:42 <tmh1999> leitao : thank you
13:42 <consus> clandmeter: Can I sent emails to the mailing list without subscription?
13:43 <clandmeter> idk
13:43 <consus> :(
13:43 <clandmeter> but you can try
13:43 <consus> I did
13:43 <consus> Nothing happened
13:43 <consus> So either it is being moderated
13:43 <consus> Or was dumped to the /dev/null on your spam server
13:43 <consus> xD
13:44 <xsteadfastx> clandmeter: oh noes
13:45 <consus> Anyway, everything works fine. I was able to setup all my services on Alpine Linux. PostgreSQL configuration lives in a strange place though, but nevermind.
13:49 <xsteadfastx> i wish i had more time... else i would look into the python2 python3 stuff
13:49 <xsteadfastx> thats on the top of my list
13:54 <jirutka> I’ve upgraded one of my VMs from 3.4.5 to 3.4.6 and it does not boot; I’ve reproduced it three times, checked configs, haven’t found anything wrong
13:55 <jirutka> I get into syslinux menu, but right when it should start booting, it starts counting again… and again… in a loop
13:55 <jirutka> anyone have a clue what may be wrong?
14:08 <consus> Hmmm
14:08 <consus> Is there a way to define my domain name without manually editing hosts file?
14:24 royger_ joined
14:24 czart_ joined
14:31 <Shiz> jirutka: yeah
14:32 <Shiz> clandmeter: is what broken?
14:58 <jirutka> Shiz: <Shiz>: I’ve built rustc with your updated patch for static-pie and with "-Wl,-(" / "-Wl,-)", but static binary still fails on panic
14:58 <Shiz> correct, it doesn't fix THAT issue
14:58 <Shiz> it does fix however cargo working
14:58 <Shiz> :)
14:58 <Shiz> i've got a static-PIE cargo now that works, for instance
14:58 <jirutka> Shiz: btw I’ve extended check-rustc to test panic http://tpaste.us/VbYz
14:59 <Shiz> :)
14:59 <Shiz> i'll give you my latest patch that includes -Wl,-)
14:59 <jirutka> Shiz: aha :) I haven’t tried static cargo with that
14:59 <jirutka> Shiz: I’ve already updated it :)
14:59 <jirutka> http://tpaste.us/mMeV
14:59 <Shiz> well i structured it a bit differently
14:59 <jirutka> aha
14:59 <Shiz> yeah i didn't do that :P
15:00 <Shiz> https://txt.shiz.me/MTRhMjg0ND
15:15 <jirutka> ncopa: I’ve upgraded one of my VMs from 3.4.5 to 3.4.6 and it does not boot; I’ve reproduced it three times, checked configs, haven’t found anything wrong; I get into syslinux menu, but right when it should start booting, it starts counting again… and again… in a loop… any idea what may be wrong?
15:15 BitL0G1c joined
15:15 <jirutka> ncopa: it’s not the first time I hit such issue, so it looks like some bug on our side /
15:15 <jirutka> ncopa: I mean in Alpine
15:16 <ncopa> huh
15:16 <ncopa> from 3.4.5 to 3.4.6?
15:16 <jirutka> yes
15:16 <clandmeter> Shiz, opensmtpd
15:16 <ncopa> we need to look at that :-/
15:17 <ncopa> does it help to re-run syslinux?
15:17 <tdtrask> ncopa: I just pushed acf-nsd repo to git.a.o. Can you please publish it?
15:17 <jirutka> ncopa: I’ve copied old vmlinuz and initramfs back to /boot as .old and added that into syslinux, it boots without problem when i select the old kernel in syslinux menu
15:17 <jirutka> ncopa: so it doesn’t look like a problem with syslinux itself
15:18 <ncopa> sounds like kernel issu
15:18 <jirutka> ncopa: maybe some unintentionally removed module?
15:18 <jirutka> ncopa: it’s virtgrsec btw
15:18 <ncopa> ok
15:19 <ncopa> i dont have time right now
15:19 <ncopa> but we should fix that
15:19 <jirutka> yeah
15:20 <clandmeter> jirutka, why not 3.5?
15:21 <ncopa> this kind of breakage should not happen anyways
15:21 <clandmeter> didnt we change some kernel settings at that point?
15:22 <clandmeter> related to efi
15:22 <jirutka> clandmeter: b/c it’s a production app and I didn’t want to upgrade it to v3.5 right now, but later
15:23 <ncopa> tdtrask: where did you publish it?
15:23 <ncopa> in your $HOME?
15:24 <ncopa> brb
15:24 BitL0G1c joined
15:47 BitL0G1c joined
15:52 <tdtrask> ncopa: I followed the instructions: scp -r myrepo.git git.alpinelinux.org:cgit/
15:52 stateless joined
15:53 stateless joined
15:53 fabled joined
16:00 <consus> ncopa: Oh hi!
16:00 <consus> ncopa: I think you're the one I need :D
16:01 <tdtrask> ncopa: renamed /home/tdtrask/cgit/ to /home/tdtrask/acf-nsd.git/
16:01 <ncopa> tdtrask: ok
16:01 <ncopa> i'll move it
16:01 <ncopa> actually
16:01 <ncopa> what happens if you git push git@git.alpinelinux.org:acf/acf-nsd.git ?
16:02 <ncopa> consus: hi. how can i help you?
16:02 <consus> ncopa: What is the intended way to configure ownership on /run/uwsgi?
16:02 <consus> ncopa: It's root:root by default
16:03 <ncopa> sounds liek a bug
16:03 <consus> ncopa: Which means I'm not able to drop privs
16:03 <tdtrask> ncopa: from within the local non-bare repo?
16:03 <ncopa> tdtrask: yes
16:03 <tdtrask> fatal: The remote end hung up unexpectedly
16:04 <ncopa> ok, i'll move it
16:04 <tdtrask> ncopa: thanks
16:04 <ncopa> consus: i think changing permissions in /run needs to be done from the startup script
16:04 <ncopa> eg from the /etc/init.d/* script
16:04 <consus> /etc/conf.d/then?
16:04 <* tdtrask> thinks a post hook to create the snapshot needed too
16:04 <ncopa> if it doesnt, then its probably a bug
16:04 <consus> /etc/conf.d/uwsgi
16:04 <consus> Well
16:05 <consus> Gentoo has root:uwsgi
16:05 <consus> AFAIR
16:07 <consus> Err
16:07 <consus> Seems like you cannot affect it via /etc/conf.d/uwsgi
16:07 <consus> And patching /etc/init.d/uwsgi is wrong
16:07 <consus> So...
16:08 <consus> Ah
16:08 <consus> You can
16:08 <consus> It uses lowercase for some reason
16:10 stateless joined
16:10 <consus> The problem is that mode is hardcoded
16:10 <consus> 0755
16:10 <consus> So changing group doesn't help much
16:11 <ncopa> consus: i think the init.d needs to be fixed
16:11 <consus> +1
16:12 <consus> AFAIR I was asking gentoo guys to do the same
16:12 <ncopa> i'll help you in a bit
16:12 <ncopa> need help tdtrask first
16:12 <consus> mode 0775 should be pretty okay
16:12 <ncopa> tdtrask: afaics, the proper way to create new git repo is via git push
16:13 gromero joined
16:14 <ncopa> yeah
16:15 <ncopa> tdtrask: http://tpaste.us/9yX4
16:17 <ncopa> tdtrask: can you from your local checkout try: git push git@git.alpinelinux.org:acf/acf-nsd master
16:23 <TemptorSent> ncopa: FWIW, 'kerneltool' can now stage kernel, modules, firmware, dtbs, and headers from a list of packages. It creates a manifest for each subset and checks the modules vermagic matches the kernel release so we shouldn't have any more problems with installing mis-matched modules.
16:24 <TemptorSent> Finishing up some rearranging before pushing.
16:24 <ncopa> ok
16:24 <ncopa> soudns good
16:24 <ncopa> i am still worried about how to start using it
16:25 <ncopa> consus: cannot you override the user too?
16:25 stwa joined
16:26 <consus> ncopa: The Emperror will not be able to create a process with another privs
16:26 <consus> ncopa: If I'll change it's user from root to anything else
16:26 <ncopa> ok
16:26 <ncopa> so you need it to run as root
16:26 <consus> ncopa: Well
16:26 <consus> ncopa: It kinda works
16:27 <TemptorSent> ncopa: Nothing else needs to be modified outside update-kernel & mkinitfs AFAIK.
16:27 <consus> ncopa: I just want to store all sockets/logs in /run/uwsgi and /var/log/uwsgi
16:27 <ncopa> but you need group settings of the /run/uwsgi
16:27 <ncopa> makes sense
16:28 <ncopa> consus: does this solve it for you? http://tpaste.us/nZNv
16:28 rdutra joined
16:28 <consus> It will make /var/log/uwsgi group writable
16:28 <consus> Is it okay?
16:28 <consus> (it works, already tested it)
16:29 <consus> /run/uwsgi : (root:uwsgi) - 0775
16:29 <consus> /var/log/uwsgi : (root:uwsgi) - 0755
16:29 <consus> I suggest this
16:29 <consus> Split checkpath in two
16:29 <ncopa> do we even need the second checkpath?
16:29 <consus> Good point
16:31 <ncopa> is /var/log/uwsgi included in the apk?
16:31 <ncopa> no its not
16:31 <ncopa> ok
16:31 <ncopa> we need it then
16:31 <consus> Why?
16:31 <consus> I'm not familiar with apk much
16:31 <ncopa> either that or we ship the empty dir with the apk
16:32 <consus> Aha
16:32 <ncopa> i suppose we could ship an empty //var/log/uwsgi with the right permissions
16:32 <consus> And let the user handle it
16:32 <ncopa> or have it created from init.d
16:32 <ncopa> the problem with shiping it with apk is that it will be reset every apk upgrade
16:33 <ncopa> but i suppose group owner "uwsgi" is a good option
16:33 <ncopa> isnt it?
16:34 fekepp joined
16:34 <consus> Yep
16:35 <consus> Also it's funny
16:35 <consus> drwxr-x--- 2 root uwsgi 464 Apr 9 03:10 /var/log/uwsgi
16:35 <consus> That's my Gentoo's uwsgi log directory
16:35 <consus> It works fine
16:36 <consus> uwsgi child is able to create a logfile there
16:36 <consus> In Alpine it's not with the exactly the same permissions
16:36 <ncopa> huh
16:36 <consus> Maybe it's the cgi plugin
16:36 <consus> Or maybe it's the user/group settings through the vassals's owner/group
16:37 <consus> uid = reviewboard
16:37 <consus> gid = reviewboard
16:37 <consus> uwsgi-socket = /run/uwsgi-reviewboard.sock
16:37 <consus> chown-socket = root:nginx
16:37 <consus> chmod-socket = 660
16:37 <consus> I have this kind of configuration options in my gentoo box
16:37 <consus> In alpine things handled differently
16:38 <consus> So it's either rwxrwxr-x root:uwsgi
16:38 <consus> Or no logs for vassals in /var/log/uwsgi =/
16:39 <ncopa> im going for this: http://tpaste.us/zbgW
16:39 <consus> Let me check one more thing
16:39 <consus> Maybe I will be able to find what's different
16:42 <consus> Yeah
16:42 <consus> Right
16:42 <consus> It's the tyrant mode
16:43 <ncopa> so 775 for /var/log/uwsgi is ok?
16:43 <consus> In tyrant mode uwsgi drops privs to uwsgi:uwsgi
16:43 <consus> So it's children cannot write there
16:43 <consus> Well I guess 0775 it is
16:44 <consus> Let me test it
16:47 <consus> Okay
16:47 <consus> Works
16:48 <ncopa> thanks. pushed
16:48 <consus> We could probably write it as pid_dir_mode and log_dir_mode
16:49 <consus> But I think it's fine
16:49 BitL0G1c joined
16:52 BitL0G1c1 joined
17:12 BitL0G1c joined
17:18 BitL0G1c joined
17:21 <TemptorSent> Hmm, running awk over a 42mb kernel apk takes forever :/
17:27 <TemptorSent> fabled: When you pop on, I could really use a few minutes of your time to straighten out apk. - Thanks!
17:34 <TemptorSent> Currently, I'm burning nearly 3 minutes extracting the SHA1 checksums from the kernel apk to a manifest using zcat $apk | awk with a fairly simple awk script to parse the tar file and extract the headers.
17:35 <TemptorSent> That should be a few seconds work for apk.
17:36 <consus> ncopa: I wonder why the tyrant mode was chosen
18:01 <mosez> damn, php7-memcached@testing seems to be broken :(
18:03 <mosez> memcached.so gets placed into /usr/lib/php7/memcached.so instead of /usr/lib/php7/modules/memcached.so and even if i change the pathin within the 20_memcached.ini i still get PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php7/memcached.so' - Error relocating /usr/lib/php7/memcached.so: php_var_unserialize_init: symbol not found in Unknown on line 0
18:11 vakartel joined
18:13 <ncopa> mosez: i think you php7 from teting too
18:13 <ncopa> testing*
18:16 ic3cdr joined
18:17 t0mmy joined
18:19 <jirutka> mosez: yes, php is completely broken now :/
18:21 <leitao> tmh1999, I fixed the newsbeuter issue. The PR is https://github.com/alpinelinux/aports/pull/1233
18:25 blahdodo joined
18:34 Emperor_Earth joined
18:40 <tmh1999> leitao : I appreciate it
18:51 tty` joined
18:59 <jirutka> kaniini: r u here?
19:07 vakartel joined
19:08 <tdtrask> ncopa: I created the repo using git push. Not sure how to add description and hook for creating snapshots.
20:48 <mosez> ncopa: oh nos :D
21:01 terra joined
21:06 minimalism joined
21:12 consus joined
21:17 <consus> $ echo 123 | sendmail root
21:17 <consus> zsh: done echo 123 |
21:17 <consus> zsh: segmentation fault sendmail root
21:17 <consus> :(
21:19 <Shiz> clandmeter: dunno aboutstable, but not in edge
21:57 <jirutka> ncopa: have you somehow solved the second error (print_context.c)? https://gist.github.com/ncopa/2e97b2b545cf9e5511ff
21:59 <Shiz> jirutka: hi
21:59 <Shiz> im back :P
21:59 <jirutka> Shiz: hi
22:00 <Shiz> i need to find someone who knows about unwinding i guess
22:00 <jirutka> Shiz: btw currently building llvm3.9, gonna switch rust from 3.8 to 3.9
22:00 <Shiz> :)
22:00 <Shiz> jirutka: want my cargo APKBUILD?
22:00 <Shiz> i don't think it's quite ready for primetime yet, but it builds a mostly working cargo
22:00 <jirutka> Shiz: the only one I know that _may_ now something about that is skarnet :/
22:01 <Shiz> i don't think skarnet is heavily into C++ runtimes, but I'll check with him
22:01 <jirutka> Shiz: I’ve already updated cargo locally, but send me your apkbuld :)
22:01 <jirutka> Shiz: aha, no, he’s not into C++
22:02 <Shiz> unwinding is very much a low-level C++ runtime thing
22:02 <Shiz> :P
22:03 <Shiz> jirutka: https://txt.shiz.me/MjY1MDhkMz
22:10 <jirutka> Shiz: what about the failures in dynamically linked cargo, have any idea what may be the cause?
22:10 <Shiz> vaguely
22:10 <Shiz> i talked to dalias about it before
22:12 <jirutka> who’s dalias?
22:13 <Shiz> musl author
22:13 <jirutka> aha, THAT dalias
22:14 <jirutka> that failure is even more urgent, we can live without static PIE, but barely without dynamic linking :(
22:16 <Shiz> :P
22:18 <Shiz> jirutka: http://git.musl-libc.org/cgit/musl/commit/?id=5bf7eba213cacc4c1220627c91c28deff2ffecda
22:20 rnalrd joined
22:20 fcolista joined
22:21 <Shiz> jirutka: looks like it may be a musl bug
22:21 <Shiz> re:static PIE
22:21 <jirutka> aha
22:21 <Shiz> not sure about the dynamic linking thing
22:21 <Shiz> i know what causes it, but not entirely sure WHY
22:21 <Shiz> :p
22:23 <Shiz> jirutka: http://git.musl-libc.org/cgit/musl/commit/?id=5bf7eba213cacc4c1220627c91c28deff2ffecda
22:24 <Shiz> i wanted to recompile musl anyway for that dynamic link issue
22:24 <Shiz> so i'm happy
22:29 <jirutka> Shiz: do you wanna backport http://git.musl-libc.org/cgit/musl/commit/?id=5bf7eba213cacc4c1220627c91c28deff2ffecda to our musl pkg?
22:29 <Shiz> i think it's already in there
22:30 <jirutka> okay
22:30 <Shiz> it's another thing i think dalias is prepping
22:30 <Shiz> 00:19:04 dalias │ also even if AT_PHDR were set i think the code is wrong
22:30 <Shiz> ..
22:30 <Shiz> 00:19:44 dalias │ in practice i think PT_PHDR is first so it works
22:30 <Shiz> 00:19:45 dalias │ but it's wrong
22:30 <Shiz> 00:20:11 dalias │ do you want to test a fix matching the above commit?
22:30 <Shiz> 00:20:24 dalias │ i think it will solve your problem
22:31 <Shiz> jirutka: aha
22:31 <Shiz> jirutka: i found something
22:31 <Shiz> jirutka: https://github.com/rust-lang/rust/pull/40113#issuecomment-293354149
22:32 <Shiz> jirutka: that should fix the dynlink issue
22:32 <Shiz> i was JUST looking around liblibc trying to fix that
22:32 <Shiz> :D
22:33 <consus> I need some help debugging smtpctl segfault
22:33 <consus> realloc(NULL, 8) produces very strange address
22:34 <consus> I tend to think that it may be somehow related to musl
22:35 <jirutka> Shiz: \o/
22:35 <algitbot> \o/
22:36 <Shiz> consus: testing locally, the addresses look correct to me?
22:36 <consus> Heh
22:36 <consus> That's the thing
22:36 <Shiz> https://txt.shiz.me/ZWM4NmFjNW
22:36 <Shiz> and i can write to them
22:36 <Shiz> as the .c file tests
22:36 <consus> $27 = (void *) 0xfffffffff75ceca0
22:36 <consus> That's what realloc produces in smtpctl
22:37 <consus> When I'm trying to reproduce it with simple realloc(NULL, 8) in my test.c everything works ok
22:37 <Shiz> that looks like zero-extension
22:37 <Shiz> consus: do you have the surrounding code/types?
22:37 <consus> I do
22:38 <Shiz> (just a link to the source code is fine too)
22:38 <consus> Sec
22:38 <consus> https://paste.pound-python.org/show/n7Dc4blOVCYFZH1xSTcy/
22:38 <consus> That's the high level code
22:38 <consus> The line in question is 23
22:39 <Shiz> hmm
22:39 <consus> https://paste.pound-python.org/show/QAAskOdxgp8Ioj2tESOM/
22:39 <consus> reallocarray()
22:40 <Shiz> is that value you posted directly returned from realloc()?
22:40 <consus> Yes
22:40 <consus> I traced arguments to realloc()
22:40 <consus> It's 0x0 and 8
22:40 <consus> size = 1, nmemb = 8
22:40 <Shiz> so an address with the high bit set in x86_64 linux is a kernel address
22:40 <Shiz> so it's very obviously wrong
22:40 <consus> Yes
22:40 <Shiz> but it can also be type fuckery
22:40 <consus> It's void *
22:40 <Shiz> since it matches the pattern of a typical sign extension
22:40 <consus> As you can see
22:41 <Shiz> yeah.
22:41 <consus> okay, putting a debug printf("%p\n")
22:41 <consus> Just to be sure that there is no some obscure gdb bug
22:41 <Shiz> :P
22:43 <consus> size = 8, nmemb = 1, optr = 0, p = 0x7ffff75ceca0
22:43 <consus> :D
22:43 <consus> Riight
22:43 <consus> So there is some obscure gdb stuff
22:44 <Shiz> hehehe
22:44 blueness joined
22:44 <consus> Still, this memory cannot be accessed
22:44 <consus> And I get SIGSEGV
22:47 <consus> Stupid me
22:47 <consus> Wait, no
22:47 <consus> Not stupid me
22:48 <Shiz> pictured: the cycle of debugging
22:48 <consus> xD
22:49 <consus> Well this is kinda nuts
22:49 <consus> To be frank
22:53 <consus> Okay, clang to the rescue
22:53 <Shiz> oh?
22:53 <Shiz> jirutka: care to try that patch? :)
22:54 <jirutka> Shiz: yes!
22:54 <Shiz> the one on github i mean btw
22:56 <consus> Funny, it's the same address every goddamn time
22:57 <jirutka> Shiz: yeah, gonna build it
22:57 <Shiz> :)
22:57 <Shiz> consus: that seems... odd
22:57 <consus> Yes
22:57 <consus> Clang not helping
22:57 <consus> So it's not some obscure gcc bug
22:58 <Shiz> and the musl source defines realloc(NULL, n) as malloc(n)
22:58 <Shiz> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n386
22:58 <Shiz> so it seems like possibly corrupted malloc state
22:58 <Shiz> somehow
22:58 <consus> How?
22:58 <consus> Any ideas?
22:59 <consus> ok adding musl-dbg
22:59 <consus> Let's dive into it
22:59 <Shiz> :P
23:00 <Shiz> i'm honestly not entirely sure, musl's malloc code is kinda black magic to me
23:00 <consus> No sleep for me tonight
23:00 <Shiz> but this
23:00 <Shiz> to me
23:00 <Shiz> screams "delayed result of earlier corruption"
23:00 <consus> Likely
23:00 <consus> Since gcc is out of the question
23:00 <Shiz> in other words, the realloc() call is not the right castle you're looking for the princess for
23:00 <Shiz> :P
23:00 <consus> :D
23:01 <consus> Someone's being naughty and ruining our heap?
23:01 <Shiz> sounds like it! or something like that
23:01 <Shiz> either way, the malloc state at least
23:01 <consus> heaptrace should be my guide then
23:02 <Shiz> consus: might be useful to figure out if there's a system call happening during the realloc()
23:02 <Shiz> mmap() specifically
23:02 <consus> Well first I have to understand what's going on in realloc() itself
23:02 <consus> Maybe it's stack corruption that I can't see at this level
23:02 <Shiz> right
23:04 <consus> okay
23:04 <consus> that's weird
23:04 <consus> i'm in __malloc0 with size 3
23:06 <Shiz> just send a signal when you want me to send down the rescue workers
23:06 <consus> Breakpoint 2, realloc (p=0x0, n=8) at src/malloc/malloc.c:371
23:06 <consus> Pretty much okay at this point
23:06 <Shiz> right, so
23:07 <consus> Breakpoint 3, malloc (n=8) at src/malloc/malloc.c:311
23:07 <consus> And at this too
23:07 <consus> So... It's heap-based corruption I guess
23:07 <Shiz> it's fine to be in __malloc0
23:07 <Shiz> remember
23:07 <consus> My bad, that was some other malloc() call
23:07 <Shiz> realloc() calls malloc(), not __malloc()
23:07 <Shiz> malloc() is alised to __simple_malloc() is aliased to __malloc0()
23:08 <Shiz> or, wait
23:08 <Shiz> no, nvm
23:08 <Shiz> im reading stuff wrong
23:08 <Shiz> :P
23:09 <Shiz> disregard that
23:10 <consus> :D
23:10 <consus> Well that's kinda odd
23:10 <consus> This very code works in my productions Gentoo machines
23:10 <consus> In openbsd
23:11 <consus> In debian
23:11 <consus> But gives my SIGSEGV only in Alpine
23:11 <Shiz> of note is that i recently upgraded opensmtpd in edge to an actual somewhat recent version
23:11 <consus> The test is simple
23:11 <consus> echo 123 | sendmail root
23:12 <Shiz> does that crash smtpd or sendmail?
23:12 <consus> smtpctl that mimics sendmail
23:13 <Shiz> right
23:13 <Shiz> immunity:~# echo 123 | sendmail root
23:13 <Shiz> Segmentation fault
23:13 <Shiz> wee
23:13 <consus> :D
23:13 <consus> Told ya
23:13 <consus> That's bad
23:13 <Shiz> that's with the latest version in edge
23:13 <consus> That's very very bad
23:13 <Shiz> 6.0.2
23:14 <Shiz> yes, i agree
23:15 <consus> So the main questions is
23:15 <consus> How the hell musl got so fucked up it gives us the wrong address
23:16 <consus> Okay, no mmap
23:16 <Shiz> my first action would be breaking on http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n340
23:17 <Shiz> and see the value of maks
23:17 <Shiz> mask
23:17 <consus> I'm downloading musl source code
23:17 <consus> As -dbg package does not include it for some reason
23:18 <Shiz> -db includes debug symbols afaik
23:18 <Shiz> not the source code
23:18 <consus> Yep
23:18 <consus> But e.g. on centos -debug packages include source code
23:19 <consus> Which makes sense
23:19 <consus> Because how else I would debug the troubles?
23:19 <consus> In Alpine musl have about 30 patches
23:19 <consus> *has
23:20 <Shiz> we typically expect the source code to be available easier online
23:20 <consus> You have to apply all those patches
23:20 <consus> In order to get 1:1 source <-> binary mapping
23:21 <consus> So it's easier to just run abuild on musl lol
23:23 blueness joined
23:28 <jirutka> Shiz: I’ve pushed llvm3.9 to testing, currently building
23:29 <Shiz> :)
23:29 <consus> Dammit, it's all optimized out
23:29 <consus> Okay, I'm building my own musl now
23:30 <consus> With CFLAGS='-O0 -ggdb'
23:30 <consus> Let's party
23:38 <consus> Shiz: So what was your idea about mask?
23:49 <consus> Oka
23:49 <consus> Okay
23:49 <consus> Fucking
23:49 <consus> Weird
23:50 <consus> Shit
23:50 <consus> I print the value that malloc returns
23:50 <consus> It's okay
23:50 <consus> I copied it
23:50 <consus> And put it to the corrupted variable
23:50 <consus> Guess what
23:50 <consus> Everything works great
23:50 <consus> So it's not heap corruption
23:51 <Shiz> hmm
23:51 <consus> https://paste.pound-python.org/show/U4FghbEGfwB3M2zHWBVp/
23:51 <consus> Boom, like that
23:52 <consus> So what, stack corruption now?
23:52 cyteen joined
23:52 <Shiz> you sure that's right?
23:52 <Shiz> i don't see it actually executing the line that access msg.rcpts
23:52 <consus> Well it's not crashing anymore
23:53 <consus> 788 msg.rcpts[msg.rcpt_cnt++] = qualify_addr(addr);
23:53 <consus> This one
23:54 <Shiz> it shows the statement it's about to execute, afaik?
23:54 <consus> next line
23:54 <consus> (gdb)
23:54 <consus> It was executed
23:54 <consus> I'm waiting for input now :D
23:54 <Shiz> i mean, after you enter n on that line
23:54 <Shiz> it shows
23:54 <consus> I have more
23:55 <consus> Later
23:55 <consus> I just didn't copy it
23:55 <consus> 788 msg.rcpts[msg.rcpt_cnt++] = qualify_addr(addr);
23:55 <consus> (gdb)
23:55 <consus> Breakpoint 2, malloc (n=0) at src/malloc/malloc.c:311
23:55 <consus> 311 {
23:55 <consus> (gdb) c
23:55 <consus> Continuing.
23:55 <consus> Breakpoint 2, malloc (n=4294962681) at src/malloc/malloc.c:311
23:55 <consus> 311 {
23:55 <consus> (gdb) c
23:55 <consus> Continuing.
23:55 <consus> Breakpoint 2, malloc (n=8589934592) at src/malloc/malloc.c:311
23:55 <consus> 311 {
23:55 <consus> (gdb) c
23:55 <consus> Continuing.
23:57 <Shiz> ah
23:58 <Shiz> yeah it seems like somehow the ret val gets sign extended...
23:59 <consus> AHha
23:59 <consus> But how?
23:59 <consus> It's void *
23:59 <consus> The max possible value in stock
23:59 <consus> What bothers me is this
23:59 <consus> return CHUNK_TO_MEM(c);
23:59 <consus> #define CHUNK_TO_MEM(c) (void *)((char *)(c) + OVERHEAD)