<     May 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 _2_7  
28 29 30 31
00:07 <Shiz> jirutka: thanks for the comments, updated
00:07 <Shiz> note that the travis build will fail regardless because of llvm time limit
00:07 <Shiz> :P
00:10 <jirutka> I said short note XD
00:10 <jirutka> but okay :)
00:11 <Shiz> eh, i think this explains the situation a bit better
00:11 <Shiz> also why we don't package libc++abi :)
00:11 <Shiz> because someone may wonder that as well
00:11 <jirutka> aha
00:14 <jirutka> Shiz: look what I found https://pypi.python.org/pypi/lit/ ;)
00:15 <Shiz> that's outdated though
00:15 <Shiz> 0.5.0 :p
00:15 <jirutka> unfortunately there’s no 0.6.0, so they apparently don’t care about it :(
00:15 <jirutka> LLVM upstream is horrible :(
00:19 <Shiz> yeah
00:19 <Shiz> well at least now we know separate pkgver is fine
00:19 <Shiz> ;p
00:31 tty` joined
00:32 rdutra joined
00:38 tty` joined
00:41 <jirutka> Shiz: I’m curious how have you managed to build it
00:41 <jirutka> ’cause we don’t have llvm-libunwind 4.0.0…
00:42 <Shiz> oh?
00:42 <jirutka> it’s 3.9
00:42 <jirutka> we have added this pkg for rust
00:42 <jirutka> and rust builds with llvm3.9
00:42 <jirutka> I’m not entirely sure if we can mix llvm3.9 and llvm-libunwind 4.0
00:42 <Shiz> how curious...
00:42 <Shiz> should be able to
00:42 <Shiz> llvm libunwind is standalone
00:42 <Shiz> it doesn't hook into llvm or anything
00:43 <Shiz> afaik
00:43 <Shiz> jirutka: thanks for notifying
00:43 <Shiz> it looks like my builder had a llvm-libunwind*.apk left over from when i tested upgrading it
00:43 <jirutka> but srsly, how have you built it? :)
00:43 <jirutka> aha
00:44 <Shiz> i'll upgrade it and add the commit...
00:44 <Shiz> sorry about that
00:45 <jirutka> I’ve pushed you something :P
00:47 <Shiz> jirutka: i can do you better
00:47 <Shiz> :P
00:47 <jirutka> ?
00:48 <jirutka> hm, setup.py commands
00:48 <Shiz> jirutka: $ python2 utils/lit/setup.py --version 2>/dev/null | sed -e 's/\.dev.*$//'
00:48 <Shiz> 0.6.0
00:48 <Shiz> :)
00:49 <jirutka> well, that’s how it looks when your faviourite hummer is sed…
00:49 <jirutka> but then I realized that it’ll be easier to evaluate it in python then replacing ", " with dots etc.
00:49 <jirutka> and forgot to reevaluate my approach
00:50 <jirutka> fell free to replace it with your simpler solution ;) just remove redundant "-e"
00:50 <jirutka> s/hummer/hammer/
00:50 <jirutka> I should go sleep:)
00:52 <Shiz> naito
00:52 <Shiz> jirutka: upgraded llvm libunwind to 4.0.0
00:52 <Shiz> it rmeoves a bunch of our old hacks :)
00:53 <jirutka> now we have to rebuild rust
00:53 <Shiz> yeah
00:53 <Shiz> i'll add a rebuild rust to that PR too
00:53 <Shiz> :P
00:53 <jirutka> what hacks?
00:54 blueness joined
00:54 <jirutka> that one for building both static and shared lib?
00:54 rdutra joined
00:54 <Shiz> yes
00:55 <jirutka> they finally provide some option to build both?
00:56 <Shiz> yes it's just enable_shared=on
00:56 <Shiz> it will also built static :)
00:56 <jirutka> great!
00:57 <jirutka> i didn’t like that ugly hack I made
00:57 <Shiz> :P
00:57 <jirutka> sleep, gn :)
00:58 <Shiz> jirutka: ok to build libunwind with clang?
00:58 <Shiz> sure gn
00:58 <jirutka> mitchty: please take a look at https://github.com/alpinelinux/aports/pull/684#commits-pushed-22e4594
00:58 <jirutka> Shiz: hmm… there’s some problem in clang on x86
00:58 <Shiz> oh okay
00:58 <Shiz> i'll omit that then
00:58 <Shiz> libc++ does need to be built with clang
00:58 <jirutka> Shiz: I’ve probably somehow screwed it when updating patches
00:58 <Shiz> you get nasty stuff otherwise
01:00 <Shiz> jirutka: btw i don't think there's an soname bump in libunwind
01:00 <Shiz> so a rust rebuild won't be needed
01:00 <Shiz> or did it statically embed libuwnind...
01:00 <jirutka> probably both…
01:00 <jirutka> cause it depends on libunwind-dev in runtime
01:01 <jirutka> have you verified if the ABI is the same?
01:01 <jirutka> tbh I’d not trust sonames in the case of LLVM…
01:01 <Shiz> yeah i think itembeds stuff anyway
01:01 <Shiz> i'll bump it
01:42 s33se_ joined
02:39 tmh1999 joined
05:28 fabled joined
06:41 fabled joined
06:53 jlyo joined
06:59 vakartel joined
07:08 fabled_ joined
07:28 t0mmy joined
07:30 royger joined
07:31 Bureaucat joined
08:04 raiz joined
08:14 fekepp joined
08:21 fabled_ joined
08:33 D630 joined
09:00 ^7heo joined
09:21 czart__ joined
09:31 czart joined
10:05 jomatv6 joined
10:10 jomat joined
10:27 <ncopa> ^7heo seems you are maintainer of community/gogs, there is new version available, 0.11.4. care to bump it?
10:27 <ncopa> apkbuild might need refactor...
10:29 <^7heo> ncopa: it's been taken care since the abump
10:29 <^7heo> not comitted tho
10:29 <^7heo> because I have unanswered questions
10:30 <^7heo> also I have big issues with my VPS atm; so no time for that now
10:30 <ncopa> ok
10:30 <^7heo> I'll ask the questions again later
10:44 vakartel joined
11:00 <ncopa> seems like go 1.8.1 fails on aarch64
11:57 rdutra joined
12:05 fabled joined
12:05 gromero joined
12:06 leitao joined
12:10 gromero joined
12:27 <Shiz> jirutka: it lies?
12:27 <jirutka> Shiz: yes
12:28 <Shiz> no, it seems correct
12:28 <Shiz> what it does use is LLVM_CONFIG_PATH
12:28 <Shiz> :)
12:28 <jirutka> Shiz: every LLVM project that links with LLVM accepts configuration option LLVM_CONFIG
12:28 <jirutka> hm, so they renamed it just for libunwind? that’s strange…
12:28 <Shiz> https://github.com/llvm-mirror/libunwind/blob/master/CMakeLists.txt#L21
12:28 <jirutka> hm, aha
12:29 <jirutka> LLVM team doesn’t respect consistency…
12:29 <Shiz> I'll change it
12:29 <jirutka> okay, then please rename it
12:30 blueness joined
12:31 <Shiz> -DLLVM_CONFIG_PATH="/usr/lib/llvm$_llvmver/bin/llvm-config" \
12:31 <Shiz> :)
12:32 <Shiz> jirutka: hmm
12:32 <Shiz> we may want to require clang for compilation either way
12:32 <Shiz> so libunwind can be linked against compiler-rt...
12:32 <Shiz> well, optimisation for later
12:33 <Shiz> pushed the changes
12:36 <Shiz> jirutka: also gonna push an extra patch for non-exec stack
12:36 <jirutka> Shiz: https://github.com/alpinelinux/aports/commit/6245e20b52907a0efb44bf38c97e52d0bfe6ffc3
12:36 <Shiz> jirutka: i already fixed that
12:36 <Shiz> in the latest push
12:36 <Shiz> :P
12:36 <jirutka> okay
12:37 <Shiz> it seems libunwind relies on __GNU__ | __APPLE__ | __FreeBSD__ | ... to set a nonexecstack
12:37 <jirutka> Shiz: "so libunwind can be linked against compiler-rt" – what’s the benefit?
12:37 <Shiz> :/
12:37 <Shiz> jirutka: gcc/gnu-less llvm stack
12:37 <Shiz> else it would link against -lgcc_s
12:39 <jirutka> compare size of the resulting static binary when compiled with clang and gcc; IIRC i’ve tried to compile it with clang, but for some reason switched it back, maybe it increased binary size; I really don’t remember and I haven’t dropped any comment about it, so probably just mixed memories, but pls check it out when switching to clang ;)
12:40 <jirutka> maybe it was just difference between size of libunwind and llvm-libunwind
12:44 <Shiz> https://github.com/alpinelinux/aports/pull/1511/commits/5f3da378ae06103f8d37b58decc6a854824d7911
12:44 <Shiz> there
12:44 <Shiz> now libunwind has a proper noexecstack
12:48 farosas joined
13:06 fcolista joined
13:14 blueness joined
13:23 raiz left
13:26 blueness joined
13:38 xentec joined
14:17 blueness joined
14:31 fekepp joined
14:32 Emperor_Earth_ joined
14:35 fabled joined
14:52 cyteen joined
15:03 t0mmy joined
15:32 mmlb joined
15:35 coredumb joined
16:05 t0mmy joined
16:07 blueness joined
16:36 <^7heo> Damn
16:36 <^7heo> Some bs script kiddie on #alpine-linux
16:37 <_ikke_> I see
16:37 <^7heo> I got some DCC pen attempts
16:37 <_ikke_> right
16:42 minimalism joined
17:03 ingo___ joined
17:03 blueness_ joined
17:09 tg joined
17:10 blueness_ joined
17:11 blueness_ joined
17:13 blueness_ joined
17:28 mihnea joined
17:39 blueness joined
17:43 black_ant joined
17:43 blueness left
17:44 blueness joined
17:47 asonge joined
17:47 black_ant joined
17:48 blueness joined
17:54 blueness joined
18:11 blueness joined
18:14 blueness joined
18:17 skrzyp joined
18:18 <skrzyp> https://a.doko.moe/bwcvwh.jpg - alpine team, reading latest CVE announcements
18:19 <_ikke_> lol
18:21 <jirutka> ?
18:21 <jirutka> what specifically?
18:21 <scadu> lel
18:21 <skrzyp> kek
18:21 <skrzyp> https://a.doko.moe/koqoqv.jpg - jirutka at github PR review
18:22 <jirutka> btw this is funny: “Elastic is now a CNA, assigning CVE IDs for its own products. Read the complete announcement at…” … so their products are so vulnerable, that they need their own CNA? XD
18:22 <skrzyp> that Elastic from ElasticSearch?
18:22 <scadu> yis
18:22 <jirutka> I know Krteček, but what’s about latest CVE announcements? o.O
18:23 <scadu> jirutka: it seems that skrzyp is creating Alpine memes :p
18:23 <jirutka> aha
18:25 <jirutka> it’s very sad that when I see Krteček in international context, the first thing that come to my mind is our fucking president pushing us to the China’s ass… :(
18:25 <scadu> XD
18:25 <jirutka> http://cdn.i0.cz/src/public-data/f8/5c/917c8c183ab191d20224f15b654f_base_optimal.jpg :(
18:26 <jirutka> he ruins our culture
18:26 <scadu> for me Krtecek is just Krtecek -- first known badass in my life, before Rambo XD
18:26 <skrzyp> https://a.doko.moe/dusjgy.jpg - #alpine-* irc when ^7heo rants about everything xD
18:26 <scadu> http://www.lisa-prosch.de/wp-content/uploads/2010/04/krtek13.jpg
18:26 <scadu> let's move to -offtopic maybe :x
18:26 <clandmeter> can we keep this stuff for offtopic?
18:27 <scadu> jirutka: can we merge pr 1430?
18:30 <jirutka> scadu: I’m not sure… has Krteček approved it? :P
18:30 <jirutka> btw m4 is quite surely also unused
18:32 <scadu> jirutka: it didn't build without m4, but I might check once again if needed
18:32 <scadu> I also prepare i3-gaps, but probably would be best to merge i3 first
18:32 <skrzyp> cool m4 m8
18:33 <scadu> I saw that skrzyp was working on -gaps, but it wasn't merged yet
18:42 <skrzyp> yeah, I stopped using tatra linux in favor or nothing linux
18:42 <skrzyp> so the i3 wasn't needed
18:44 <jirutka> lol
18:44 <jirutka> but not surprised, Nad Tatrou sa blýská! XD
18:45 <skrzyp> yeah
18:45 <skrzyp> even in Cracow we had some thunderstrikes today
18:46 <jirutka> it’s sunny in Prague now :)
18:46 <skrzyp> get your clouds back
18:46 <jirutka> I’d like to…
18:46 <scadu> ding ding ding, we are on -devel. let's try to stick the topic :<
18:47 <scadu> or just spam on -offtopic :P
18:47 <skrzyp> > scadu
18:47 <skrzyp> > keeping on topic
18:59 cyteen joined
19:11 BitL0G1c1 joined
19:12 vkrishn joined
19:12 <vkrishn> skrzyp, no compelling but would it be possible to have a look at
19:12 <vkrishn> https://wiki.alpinelinux.org/wiki/Aports_what_is_edge
19:12 <vkrishn> and see if some interesting can be cooked for illustrations.
19:12 <vkrishn> Feel free to make changes in the page, eg like banana with any other fruit... etc
19:13 <vkrishn> been wating for a an artists to complete it.
19:14 <scadu> Krtecek and mushrooms
19:15 <vkrishn> kinda got inspired by openbsd
19:16 <scadu> Krtecek would be a nice mascott :P
19:16 <skrzyp> http://bajkionline.com/wp-content/uploads/2015/07/krecik-i-grzyby.jpg
19:16 <skrzyp> alpine edge
19:16 <skrzyp> xD
19:16 <vkrishn> would be nice to have it done before v3.6
19:17 <vkrishn> if they grow on alpines, better
19:19 <jirutka> I’m banging my head on the table what the hell is happening on the damn builders and you’re discussing illustrations, lol
19:20 <scadu> b-b-b-ut it's almost Friday, sir
19:20 <vkrishn> this is another part of development of AlpineLinux, its called marketting
19:20 <vkrishn> ;)
19:20 <vkrishn> sorry to be same room
19:21 <scadu> we're cool, Alpine's cool
19:23 <vkrishn> hmm... still unable to locate the curtain
19:27 black_ant joined
19:58 <martanne> jirutka: what is your opinion on the pkg-config related inconveniences I reported? For now I'm using the following hacks in a Dockerfile to build a static vis binary: http://sprunge.us/YOZj
20:04 <jirutka> martanne: I asked kaniini about it (he’s author of pkgconf) and he was in doubts if that static lib should be in pkgconf file, so I decided to wait until you come and explain if and why you really need it here
20:04 <jirutka> martanne: I don’t know how it should be correctly handled
20:09 <martanne> jirutka: ok I see, I'm not that familiar with pkg-config conventions either. From a user point of view I just want to use something along the lines of: ./configure CC='cc --static' && make and have it work.
20:18 <TemptorSent> jirutka: Building static binaries seems to be the obvious use case for static libs, but that also requires installing them sanely.
20:19 <TemptorSent> shared libs are usually conveniently versioned, while the static libs are a guessing game.
20:20 <TemptorSent> Ditching LFS is the sane fix long term I guess :)
21:04 <jirutka> TemptorSent: this is totally out-of-topic
21:05 <jirutka> TemptorSent: we need to know how to record static lib into pkgconf file
21:08 capcap joined
21:20 <kaniini> --static isn't for that
21:20 <kaniini> it is a badly named parameter
21:24 <jirutka> kaniini: could you please propose some solution?
21:25 <kaniini> yeah
21:26 <kaniini> https://paste2.org/dtCwDGnO
21:26 <kaniini> like so
21:26 <kaniini> but --static isnt for that, really
21:29 <jirutka> kaniini: so pkgconf can disquish between static and shared libs? based on file extension?
21:32 <jirutka> kaniini: btw it seems that you were wrong about that pkgver in split function is okay… I don’t know why, but it doesn’t work on build infra
21:32 <jirutka> kaniini: I have no clue what has happened here, b/c it work on my machine, but obviously something is very wrong :(
21:33 <kaniini> jirutka: no, pkgconf just leaves the fragment alone
21:34 <kaniini> jirutka: --static just brings in Libs.private & CFLAGS.private
21:34 <kaniini> jirutka: it should really be --private
21:35 <jirutka> kaniini: well, I’m afraid of this: we add static libs into foo.pc and then wen some program asks for flags to dynamically link foo, it’ll also get /lib/foo.a and it will be messed;
21:35 <jirutka> kaniini: is this real problem or it should be okay?
21:36 <kaniini> jirutka: pkg-config does not support actual 'static linking'
21:36 <jirutka> and pkgconf?
21:36 <kaniini> jirutka: pkgconf is obligated for the moment to do the same as pkg-config
21:37 <kaniini> jirutka: the good news is redhat has killed off its support of the former, so maybe we can actually fix this shit someday
21:37 <jirutka> :)
21:37 <kaniini> --static isn't what people think it is
21:37 <kaniini> really
21:37 <kaniini> it's not
21:39 <jirutka> so what would you recommend, not using pkgconf for it and just specify the paths manually?
21:39 BitL0G1c joined
21:44 <kaniini> i would have two .pc files
21:44 <kaniini> one for shared, and one for static that explicitly references the .a files
21:45 <kaniini> if you do
21:45 <kaniini> pkgconf --static --libs gtk+-3.0
21:45 <kaniini> for example
21:45 <kaniini> you'll see what i mean
21:46 <jirutka> how to name them? foo-static.pc?
21:46 <kaniini> --static is in some very limited usecases useful for static linking, but it wont give you .a's and pkgconf cannot filter out .a's
21:46 <kaniini> yes
21:47 <jirutka> I’m not sure if it’s really worth it, Lua C modules are typically very simple and has predictable names, so what is benefit of using pkconf instead of just passing /usr/lib/foo.a to the linker, martanne?
21:53 <martanne> jirutka: the problem is that their location is not really standardized. On Alpine they are in /usr/lib/lua/5.x/lpeg.a, but for example in Debian they are in /usr/lib/x86_64-linux-gnu/liblua5.x-lpeg.a ...
21:54 <jirutka> well, blame Debian…
21:54 <jirutka> does Debian add static libs to pkgconf for these Lua libs?
21:55 <jirutka> actually… you can ask Lua for these paths, give me a sec
21:55 mmlb joined
21:56 <martanne> I don't really want to mess with package.cpath ...
21:56 <martanne> And yes I can work around it, but ideally I would like to do it 'correctly'
21:56 <jirutka> martanne: lua -e 'print(package.cpath)', you will get something like `./?.so;/usr/local/lib/lua/5.1/?.so;/usr/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so`
21:56 <jirutka> the problem is that there’s no correct solution now
21:57 <jirutka> but the important question is, does Debian add static libs to pkgconf for Lua libs? if not, then it’s not really a solution for you
22:00 <jirutka> martanne: hmm, there’s anotjher way and imo the most correct and portable: `pkg-config --variable=INSTALL_CMOD lua` → `/usr/lib/lua/5.1`
22:01 <jirutka> martanne: you must just take care of lua name, "lua" on Alpine is still 5.1, if you want 5.3, then it’s called "lua5.3"
22:04 <jirutka> kaniini: do you have access to x86_64 builder? I’d like to move testing/ghc to community, but it depends on ghc, so if I understood it correctly, someone must manually install ghc on the builder to get it built the first time; and fabled is not responding
22:05 <jirutka> there’s already testing/ghc pkg, so it must be just installed, not really bootstrapped
22:13 <kaniini> ncopa maintains that builder.
22:13 <martanne> jirutka: $INSTALL_CMOD isn't standardized either ;) Anyway thanks for adding the static library versions to the repo. There is probably no really portable solution available at this time :/ I will just use an alpine based docker environment to build static binaries. In general users will have to manually override some make variables.
22:14 <jirutka> martanne: really? IIRC it’s standard variable defined by Lua
22:15 <jirutka> martanne: there should be the best chance to be the same across distros
22:16 <jirutka> martanne: well, it’s very easy to bootstrap Alpine, so you can use e.g. https://github.com/alpinelinux/alpine-chroot-install and tell users to just run script that install Alpine in chroot and build vis inside it
22:16 <jirutka> martanne: and maybe prepare docker image for lazy ones who don’t care about insane complexity for simple stuff :P
22:18 <jirutka> martanne: and you can use this script even to simply compile binaries for other arches ;) it has built-in support, I use it on Travis
22:18 <martanne> jirutka: do you have a link to a project which uses it?
22:19 <jirutka> martanne: sure, for example https://github.com/bigclownlabs/bc-bridge/blob/master/script/ci-install
22:19 <martanne> ok, I will consider that
22:20 mmlb joined
22:20 <jirutka> martanne: we use the same principle, but not exactly this script, in alpinelinux/aports for testing pull requests and I use it also in jirutka/user-aports for building my personalpackages
22:21 <jirutka> martanne: https://github.com/search?q=alpine-chroot-install&type=Code&utf8=%E2%9C%93
22:26 cyteen joined
22:57 rdutra joined
23:02 rdutra joined