<    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 _2_9  
00:00 cyteen joined
00:21 <TemptorSent> Okay, so who do I have to know to edit my own issues in Redmine?
00:24 <TemptorSent> I want to change the target version for Issue #7104 to 3.6.
00:24 <algitbot> Feature #7104: [subset of #7103] Extract manifest of pax checksum headers vs. files for apks to stdout. - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7104
00:26 <jirutka> done
00:27 <TemptorSent> jirutka: GitLab migration done?
00:27 <jirutka> you can’t edit your own issues on Redmine; I don’t know if it’s Redmine’s limitation or just current setting, but I agree that it sucks
00:27 <TemptorSent> jirutka: It can definitely be configured to allow it for logged in users, I've used it somewhat extensively for other projects in the past.
00:28 <jirutka> clandmeter: ^
00:29 <TemptorSent> It's just a matter of setting the roles up and having the right permissisions assigned.
00:35 ^7heo joined
00:35 <jirutka> Shiz: static stripped without jemalloc: 186 kiB, with jemalloc: 358 kiB
00:35 <Shiz> right
00:35 <Shiz> that makes some amount of sense
00:35 <Shiz> what about unstripped?
00:35 <jirutka> Shiz: => I’m gonna kill jemalloc with fire! :)
00:35 <* Shiz> shrugs
00:35 <jirutka> Shiz: unstripped 2.2 MiB
00:36 <jirutka> why it’s so bigger with jemalloc?
00:36 <Shiz> because it embeds jemalloc
00:36 <Shiz> :P
00:36 <jirutka> I’m really not sure if it’s worth it
00:36 <Shiz> probably not
00:36 <jirutka> isn’t that just some mistake in configuration?
00:37 <jirutka> or it really makes binary so bigger and we can’t do anything about it?
00:38 <jirutka> it’d be probably useful if we can enable/disable jemalloc with some option for rustc
00:38 <jirutka> btw Fedora disabled jemalloc too, but don’t know the reason
00:39 <jirutka> tired, sleep, good night :)
00:40 <Shiz> jirutka │ it’d be probably useful if we can enable/disable jemalloc with some option for rustc
00:40 <Shiz> i... think you can
00:41 <TemptorSent> FFS, they STILL haven't closed the feature request in the mainline of redmine? WTF? The patch has been there 7 years!
00:58 <tmh1999> kaniini : do you have know is there any reason why we should make the return value of update_config_sub as false (thus forcing fail with set -e), when there is no such config.sub file exists ?
00:59 <tmh1999> kaniini : I thought the idea is : do the ./config.sub command when it exists in the source code, if it doesn't just peacefully quit : https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n537
00:59 <kaniini> that is why it should fail
00:59 <tmh1999> not every source package comes with config.sub
00:59 <tmh1999> only some come with
01:01 <tmh1999> so not having config.sub in the source code is a bad thing ?
01:04 <kaniini> if we are calling update_config_sub it could be
01:07 <tmh1999> Okay I guess I just strip out update_config_sub in APKBUILD ...
01:28 s33se_ joined
03:02 madsa joined
03:08 <tmh1999> fcolista : Hi. It looks like v4l-utils is broken at dvbv5(). Would you mind give it a look ?
03:09 <tmh1999> fcolista : It failed for both s390x and x86_64 : http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/v4l-utils/v4l-utils-1.12.3-r0.log
03:31 Emperor_Earth joined
03:46 blueness joined
04:11 blueness joined
06:15 rokf joined
07:31 blueness joined
07:33 tty` joined
07:43 rokf joined
08:03 tmh1999 joined
09:27 <jirutka> Shiz: how? :)
09:46 tmh1999 joined
10:04 cyteen joined
10:57 tmh1999 joined
11:34 blueness joined
11:44 leo-unglaub joined
12:15 fekepp joined
12:41 tmh1999 joined
12:41 czart_ joined
13:27 tmh1999 joined
14:07 <Shiz> jirutka: hmm?
15:08 <Shiz> jirutka: oh
15:12 tmh1999 joined
15:14 andypost joined
15:51 <^7heo> is it normal that setup-bootable doesn't work with ext4 and vfat?
15:51 <^7heo> (I'm currently trying ntfs but mkfs.ntfs takes AGES)
16:06 madsa joined
17:41 <TemptorSent> ^7heo: I'd have to take a look at how setup-bootable works, but it didn't appear to have much flexability in terms of layout.
17:46 <TemptorSent> ^7heo: I'm not sure what exactly it is intended to work reliably for, but at the end it looks like it's doing a blind copy of an mbr for syslinux to the device, so expect problems on anythin other than expected setup.
17:49 <TemptorSent> ^7heo: How is it failing?
18:07 <mitchty> curious what the new labels in github indicate
18:08 <mitchty> also T-new doesn't appear to be in the list https://github.com/alpinelinux/aports/labels
18:10 <Shiz> A = PR action
18:10 <Shiz> C = category
18:10 <Shiz> P = priority
18:10 <Shiz> R = repository
18:10 <Shiz> S = status
18:11 <mitchty> T = testing?
18:11 <Shiz> T is just... a special label right now
18:11 <Shiz> not sure, ask jirutka
18:12 <_ikke_> there is also R-Testing
18:12 <mitchty> ah, k, was curious as T-new was added to my idris pr but not in the labels list https://github.com/alpinelinux/aports/pull/684
18:12 <mitchty> not a big deal just trying to understand, thanks Shiz!
18:12 <jirutka> mitchty: I’ve renamed T-new to A-add
18:12 <Shiz> :)
18:12 <Shiz> yeah it says A-add to the right now
18:12 <Shiz> the github message below is just pre-label-rename
18:12 <mitchty> cool beans
18:13 <jirutka> there are currently no T-* labels
18:13 <mitchty> looks very rust inspired
18:13 <jirutka> mitchty: yes :)
18:13 <Shiz> jirutka: there's T-security
18:13 <Shiz> :p
18:13 <jirutka> Shiz: ah, right
18:19 <mitchty> also a note on ghc size, as everyone was wondering why, short answer, is ghc by default in effect builds 4 versions of itself, the default, which uses shared libraries for things, threaded, self explanatory, profiled, and the fourth (slightly hidden) is for the repl ghci, which basically is the same as profiled
18:19 <mitchty> fixing it is... not a simple task, but that is the general why
18:19 <mitchty> in effect you build 4 versions of ghc
18:19 <Shiz> :p
18:20 <mitchty> short answer to why its never been fixed: nobody has put in the effort, and its all volunteer, and the build system is 27 years old
18:21 <mitchty> i might try if i get a bug up my butt
18:25 <skarnet> a bug up the cloud? o.O
18:25 minimalism joined
18:25 <Shiz> no response from the rust guys yet :(
19:35 <jirutka> Shiz: we have a problem with statically linked exec :/ fatal runtime error: failed to initiate panic, error 5
19:36 <Shiz> that's an interesting one
19:36 <Shiz> jirutka: we have more failures actually
19:36 <jirutka> Shiz: simple test: fn main() { panic!("Whoaa!"); }
19:36 <Shiz> i ran into a miscompiled cargo
19:37 <jirutka> Shiz: it works when dynamically linked, but not statically
19:37 <jirutka> Shiz: what do you mean with miscompiled?
19:38 <Shiz> it's static PIE with DT_NEEDED entries
19:38 <^7heo> TemptorSent: Don't remember don't care, it worked in the end.
19:39 <Shiz> jirutka: btw that code is _URC_END_OF_STACK = 5,
19:39 <^7heo> TemptorSent: just use vfat and reformat every time you use setup-bootable
19:40 <Shiz> from _Unwind_RaiseException: Debug (1, "no handler found\n");
19:40 <Shiz> return _URC_END_OF_STACK;
19:41 trfl joined
19:41 <jirutka> Shiz: have you compiled it with -C target-feature=-crt-static ?
19:41 <Shiz> no...
19:41 <jirutka> ;)
19:41 <Shiz> i don't think you get the point
19:41 <jirutka> probably not…?
19:42 <Shiz> it's supposed be either a proper dynamic binary or a static PIE one
19:42 <Shiz> i don't care either way
19:42 <Shiz> but this is neither
19:42 <Shiz> so it's a bug in rustc
19:42 <jirutka> huh
19:42 <jirutka> wtf
19:42 <Shiz> :p
19:42 <Shiz> jirutka: rustc passes the final deps as -l ... after -Wl,-Bdynamic
19:42 <Shiz> which is the reason
19:42 <Shiz> it shouldn't do that...
19:43 <Shiz> jirutka: re: your own error...
19:44 <Shiz> i suggest rolling your own libunwind with debug enabled and retrying
19:46 <jirutka> Shiz: how do you identify that a binary is static PIE? currently I test if it contain NEEDED entries or INTERP, as you told me, if it does not contain these, then I assumed that it’s static
19:47 <Shiz> that is correct
19:47 <Shiz> and the PIE flag
19:47 <jirutka> yes
19:47 <jirutka> you said that you get “static PIE” with NEEDED entries…
19:48 <Shiz> well
19:48 <Shiz> static PIE *except* for the NEEDED entries
19:48 <Shiz> :p
19:49 <jirutka> then it’s not static…
19:49 <Shiz> you know what i mean...
19:49 <jirutka> actually I don’t :(
19:49 <jirutka> how it’s different from “proper dynamic binary”?
19:50 <Shiz> it has no INTERP
19:50 <Shiz> and libc statically linked in
19:50 <jirutka> aha, this is mandatory?
19:50 <Shiz> yeah
19:50 <jirutka> INTERP?
19:50 <jirutka> hmm… should fix my test
19:50 <Shiz> interp points to the dynamic loader
19:50 <Shiz> /lib/ld-musl-$(arch).so.1
19:50 <Shiz> :)
19:50 <jirutka> cargo tests when compiled dynamically: https://hastebin.com/nevulocejo
19:51 <Shiz> nice
19:52 <jirutka> btw interesting thing: when I compiled tests statically (actually by accident), then the test was killed by grsec… when I paxmarked it, then it segfaulted
19:54 <Shiz> it segfaulted in both cases for me
19:54 <Shiz> no need for paxmark
20:28 <jirutka> oh crap, there are two libunwind projects… from GNU and from LLVM
20:31 <Shiz> :p
20:31 <Shiz> the other one is not gnu
20:31 <kaniini> i think they are api compatible
20:31 <jirutka> kaniini: what is the difference between them?
20:31 <Shiz> https://github.com/libunwind/libunwind/blob/master/AUTHORS
20:31 <Shiz> ;p
20:32 <jirutka> I don’t know this guy, should I?
20:32 <kaniini> one is BSD licensed and depends on kk men
20:32 <kaniini> er
20:32 <Shiz> no, but he's not gnu
20:32 <kaniini> llvm
20:32 <kaniini> stupid autocorrect
20:32 <Shiz> the other libunwind is MIT
20:32 <Shiz> :P
20:32 <kaniini> yeah so
20:32 <Shiz> >Copyright (c) 2002 Hewlett-Packard Co
20:32 <kaniini> idk
20:32 <jirutka> well, rustc apparently doesn’t work with our libunwind, so should I try to enable some more flags to our libunwind or just add llvm-libunwind?
20:32 <Shiz> ;p
20:32 <Shiz> i think you should just debug it first
20:33 <kaniini> they do the same thing
20:33 <Shiz> compile libunwind in debug mode
20:33 <Shiz> :P
20:33 <kaniini> one just uses llvm to do it
20:33 <jirutka> and rustc uses LLVM to compile code… so?
20:33 <kaniini> the llvm one is probably better but it depends on llvm
20:34 <jirutka> Shiz: I don’t have much experience with debugging C stuff :/
20:35 <Shiz> jirutka: in debug mode it will print messages to stdout...
20:35 <Shiz> that's the nice part
20:35 <Shiz> :p
20:37 <jirutka> Shiz: what about these additional flags? https://hastebin.com/raw/ibewojutoc
20:37 <Shiz> just --enable-debug should be fine
20:37 <jirutka> also when I run libunwind tests, some of them fails… but at least some of them clearly tests disabled features
20:39 <jirutka> hm, no, the docs are probably wrong, b/c it currently builds even coredump, ptrace,etc.
20:40 <jirutka> but it’s also quite possible that some tests fail due to grsec or that I run it in restricted lxc container
20:40 <Shiz> jirutka: meanwhile i'm writing a decoder for rustc's metadata format to try to see what's going on
20:40 <Shiz> :p
20:40 <jirutka> you’re doing WHAT?!
20:40 <Shiz> https://txt.shiz.me/OTY1MDQzMT
20:40 <jirutka> O.O
20:41 <Shiz> it's pretty easy luckily
20:41 <Shiz> i've written my own binary decoder library before
20:41 <Shiz> so it's mostly declarative structure definitions
20:46 <jirutka> okay :) this is too low-level for me :)
20:48 <Shiz> https://txt.shiz.me/M2E0ODIyZT
20:48 <Shiz> ;)
20:53 <TemptorSent> ^7heo: That sounds about right :P I'm not sure I even want to get into that.
21:35 <jirutka> Shiz: I’ve built unstripped rust with unstripped libunwind, but https://hastebin.com/raw/daxezobane
21:35 <Shiz> built libunwind with --enable-debug?
21:35 <jirutka> Shiz: there’s strace https://hastebin.com/utokubupeb
21:35 <jirutka> Shiz: yes
21:37 <Shiz> oh jeez
21:37 <Shiz> it has an additional layer
21:38 <Shiz> jirutka: right
21:38 <Shiz> jirutka: run with
21:38 <Shiz> UNW_DEBUG_LEVEL=100
21:38 <Shiz> in env
21:39 <jirutka> https://hastebin.com/raw/qeyuhidiyu
21:40 <Shiz> see, isn't that far more useful
21:41 <jirutka> you’re joking now, right? XD
21:41 <Shiz> well, it is
21:41 <Shiz> just not to have the relevant people read it
21:41 <Shiz> maybe dalias cna help you there
21:41 <Shiz> :P
21:41 <jirutka> you can’t read it?
21:42 <Shiz> not well enough to be able to deal with it while doing the other stuff i'm doing right now
21:42 <Shiz> :p
21:42 <Shiz> to me it looks like the cursor it's given is wrongi n the first place
21:42 <Shiz> 0x3afa3d81068 seems like a weird addr
21:43 <jirutka> I see a lot of weird stuff, right under "stack backtrace:" till the EOF :P
21:44 <Shiz> i think the #musl peeps can help you with this :)
21:45 <jirutka> nah, I’m trying to build rustc against llvm-libunwind now :)
21:48 <kaniini> i dont think it will help
21:49 <jirutka> kaniini: hmm, why?
21:50 <kaniini> libunwind and the llvm one implements the same API and should have the same behaviour
21:50 <kaniini> also, if libunwind is being invoked to begin with, it means the failure has already occured
21:50 <jirutka> there’s no such problem when you compile statically linked binary with musl on gnu system, so why it happens on native musl?
21:50 <jirutka> I’ve panicked it intentionally
21:51 <jirutka> to test unwind
21:51 <kaniini> ah
21:51 <kaniini> is the statically linked binary with musl static-PIE?
21:51 <kaniini> because on native it would be
21:51 <kaniini> this smells of a PIE issue
21:51 <jirutka> ahaa
21:51 <jirutka> yeah, this is different
21:51 <jirutka> I’ve almost forgot about it
21:58 <kaniini> also llvm-libunwind does not build on aarch64 :P
22:01 <jirutka> kaniini: I’m working on it now
22:02 <jirutka> kaniini: it’d be really helpful if other builds will not be stuck again :(
22:02 <jirutka> kaniini: I don’t know if it’s gonna work on x86 and armhf
22:03 <kaniini> x86 is MIA
22:03 <jirutka> kaniini: aah, x86 builder is gone
22:04 <kaniini> yes, i think need to poke ncopa about that cause he maintains it iirc
22:04 <jirutka> oh crap, I forgot to recompute checksum :(
22:04 <jirutka> aha, no, forgot to actually add the patch
22:05 <jirutka> i need to write some checking script for this, it’s quite embarrasing mistake
22:06 <jirutka> yeah, it works!
22:06 <jirutka> i mean, lua-libunwind on aarch64
22:07 <jirutka> rustc still building >_<
22:08 <Shiz> https://txt.shiz.me/NGEzNTUxMW
22:08 <Shiz> progress
22:08 <Shiz> :p
22:09 <jirutka> what’s that? :)
22:10 <Shiz> partial decoding of rust's metadata files
22:10 <jirutka> from rust binaries?
22:10 <Shiz> from .rlib files yeah
22:10 <jirutka> aha
22:15 <jirutka> hm, okay, you were right
22:16 <jirutka> *but* it does not behave identically
22:16 <jirutka> but still segfaults
22:16 cyteen joined
22:45 <Shiz> :p
23:01 <jirutka> Shiz: without your static-pie.patch rustc produces binary dynamically linked against libc >_<
23:01 <Shiz> yep
23:01 <jirutka> (and it does not segfault)
23:01 <Shiz> that patch includes stuff to make static work in the first place
23:01 <Shiz> for musl
23:01 <jirutka> I see
23:02 <Shiz> mostly the addition of the -static flag to the command line
23:02 <jirutka> what is -MT ?
23:02 <Shiz> msvc's -static equivalent
23:02 <jirutka> aha
23:02 <Shiz> jirutka: you can try patching linux_musl_base.rs to disable PIE
23:02 <Shiz> and see what it does
23:02 <jirutka> how the heck it works on gnu with musl target?
23:02 <Shiz> barely.
23:03 <jirutka> barely?
23:05 <jirutka> Shiz: so this http://tpaste.us/je1o ?
23:06 <Shiz> yeah
23:06 <Shiz> and then re-add target.position_independent_executables = false;
23:06 <Shiz> to linux_musl_base.rs
23:06 <Shiz> or
23:07 <Shiz> no nvm
23:07 <Shiz> that's not necessary
23:07 <Shiz> actually, it may be anyway
23:07 <Shiz> do it to be sure
23:28 <Shiz> jirutka: https://txt.shiz.me/M2MyMTE2MW
23:28 <Shiz> :)
23:29 <jirutka> nice :)
23:29 <jirutka> but how is this gonna help you?
23:36 <Shiz> gonna figure out how it encodes the native library dependencies
23:37 <Shiz> rust's metadata system is how it passes the native library deps of the crate dependencies to the final linker
23:43 <jirutka> Shiz: shit, you were right, I haven’t re-added that stuff, b/c I’ve already started compiling, and it still builds dyn PIE
23:43 <jirutka> need to go sleep now
23:43 <Shiz> :) g'night