<    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:34 <jirutka> Shiz: example: https://gist.github.com/jirutka/59be5141dd442abcbc183431e0cef8eb
00:35 <Shiz> jirutka: nice!
00:35 <Shiz> looking good
00:36 <jirutka> Shiz: this is NOT a final solution, just a draft; also note that acargo-dep-uris is basically a hack, parsing TOML file with sed is not very good approach…
00:36 <Shiz> :p
00:36 <jirutka> relevant source: https://github.com/rust-lang/cargo/pull/2857
00:38 <jirutka> the good thing is that Cargo already provides all what we need for sane packaging… not like… ehm… Go…
00:39 <jirutka> I have also prototype of acargo-dep-uris in Lua https://hastebin.com/raw/eticukuzay
00:40 <jirutka> should also note that this approach requires copying Cargo.lock into abuild’s directory, along with APKBUILD
00:40 <jirutka> b/c it uses it to fill $source with URIs for all crate dependencies
00:43 <jirutka> initially I wanted to fill these URIs directly to abuild’s $source and later provide some shortcut like cargo:<name>-<version>, but then there would be dozens of lines just with generated content :/
00:43 <jirutka> so maybe it’s better to just copy Cargo.lock
00:43 <Shiz> i think i'm more comfortable with acargo-dep-uris in sh :p
00:45 <jirutka> okay, need to go sleep, gn!
00:46 <Shiz> night!
00:46 <Shiz> good work :)
01:22 s33se joined
02:08 TemptorSent joined
02:42 czart_ joined
03:20 leprechau joined
04:08 terra joined
04:15 boingolo1 left
05:00 leprechau joined
05:11 fabled joined
05:26 <TemptorSent> Good evening.
05:35 minimalism joined
06:03 vakartel joined
06:31 t0mmy joined
07:04 <kaniini> skarnet: so i think for aconf, using tarballs makes more sense than just a bare directory tree (because we do not want to waste inodes in tmpfs setups)
07:07 <TemptorSent> kaniini: How would you store values and meta data? Just contents of files? tar headers as well?
07:08 <kaniini> contents of files for the values, extended tar headers for metadata (SCHILY.xattr)
07:09 <TemptorSent> kaniini: would it be as simple as 'tar -xvzf $aconf -O /path/to/information/you/want'
07:09 <TemptorSent> Do we have a tool that can actually read/write pax headers?
07:09 <TemptorSent> (Schilly tar, for instance :) )
07:09 <kaniini> sure, apk
07:09 <kaniini> there are ... ways
07:10 <TemptorSent> kaniini: It's pretty deep in apk, and not exposed without going through the database (I asked :( )
07:11 <TemptorSent> kaniini: I need something better than the fugly awk script I'm running to extract the SHA1 sums from the headers to make a manifest of the APKs I tear apart.
07:12 <TemptorSent> but anyway, a pax archive sounds like a good, sane, and flexible way of handling aconf, given a decent pax tool :)
07:13 <TemptorSent> It would probably be good to make apk a bit more pax-compliant anyway.
07:15 <TemptorSent> Anyway, let me know when you're ready for some testing.
07:16 blueness joined
07:17 rnalrd joined
07:39 rnalrd joined
07:41 consus joined
07:42 vakartel joined
07:44 rnalrd joined
08:15 rnalrd joined
08:17 <fabled> TemptorSent, maybe we should do apk applet for that; we are planning to change .apk format anyways...
08:18 royger joined
08:19 <TemptorSent> Hello fabled, long time no see!
08:21 <TemptorSent> Since you probably haven't caught up on your backlogs, please take a look at Issues #7100 #7101 #7102 #7103 #7104 and #7107 , which are in part related.
08:21 <algitbot> Feature #7100: apk should support the use of full &#39;$pkgname-$pkgver&#39; atom as returned by &#39;apk search -x $pkgname&#39; everywhere &#39;$pkgname&#39; is used - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7100
08:21 <algitbot> Feature #7101: Allow apk to operate on .apk FILE most places PACKAGE is specified - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7101
08:21 <algitbot> Feature #7102: Information available via &#39;apk info&#39; on a package is incomplete with respect to contents of .PKGINFO. - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7102
08:21 <algitbot> Feature #7103: Add ability for apk to extract files, extended headers, and metadata directly from .apks - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7103
08:21 <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
08:21 <algitbot> Bug #7107: APK prints warnings and errors to STDOUT not STDERR - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7107
08:25 t0mmy joined
08:25 <TemptorSent> fabled: What do you have in mind regarding changes to the format?
08:26 <fabled> we would like to rewrite apk's way to handle indexes and packages. both formats would be re-designed.
08:26 <fabled> i have some private code and notes ready
08:26 <fabled> but it's long term thing
08:26 <TemptorSent> fabled: The availability of checksummed manifests would be greatly helpful.
08:29 fekepp joined
08:31 <TemptorSent> When you have a moment, please take a look at the most recent work in my work branch (https://github.com/TemptorSent/tree/aports/mkimage-refactor-scripts/scripts/mkimage)
08:32 <TemptorSent> I'm using the manifests rather than the filesystem to do the lookups for modules/firmware, so we actually know when something is missing.
08:33 <TemptorSent> By far, the most painful part is using awk to extract the pax headers from the kernel and firmware packages -- several minutes on a fast machine!
08:37 <TemptorSent> Will the new format allow for better trust management on packages (Such as only install those packages directly signed by a whitelist of trusted people) and verification (Determine source/build information from checksum of file)
08:50 <clandmeter> morning
08:50 <TemptorSent> 'morning
08:50 <clandmeter> fabled, do we support rpi zero w?
08:50 <skarnet> kaniini: are inodes a scarce resource on a tmpfs? users won't write many things into the tmpfs, is the system in danger of almost exhausting inodes already?
08:51 <fabled> clandmeter, not sure if the kernel patch / bootloader are updated for that. but it should be matter of just bumping those two elements
08:51 <fabled> i'm off for lunch
08:51 <clandmeter> ok thx
08:53 <TemptorSent> clandmeter: The image builder should theoretically work for it with just those bumps as well.
08:54 <TemptorSent> although I suspect I may have broken some things in pi-land because I haven't sorted out it's odd directory layout yet for boot files and dtbs.
08:56 <TemptorSent> fabled: FWIW, we can now build modloops with any arbitrary set of modules and have ALL the module/firmware depends pulled in.
09:08 clandmeter joined
09:08 clandmeter joined
09:11 clandmeter joined
09:15 clandmeter joined
09:18 clandmeter joined
09:32 leo-unglaub joined
09:41 t0mmy joined
10:08 blahdodo joined
10:19 t0mmy joined
10:39 <jirutka> fabled: can you please explain me how cross-compiling support in abuild works? :)
10:40 <fabled> jirutka, it's supported only to the extent of running bootstrap.sh currently
10:40 <jirutka> fabled: ?
10:40 <fabled> but basically "CHOST=<target host> abuild" triggers the cross build
10:41 <fabled> you need to first build the cross-compiler yourself, since we don't ship cross compilers currently in the repositories
10:42 <jirutka> fabled: hm, does cross-compiling in https://github.com/alpinelinux/aports/blob/master/testing/ghc/APKBUILD actually work?
10:42 <fabled> it should, i bootstrapped armhf of ghc by cross-compiling it
10:43 <fabled> to bootstrap build new architecture, use aports/scripts/bootstrap.sh
10:43 <fabled> that's the script that cross-builds initial set of .apks for new arch
10:43 <jirutka> so it must be run manually?
10:44 <jirutka> I don’t need to build new arch, just cross compile rust from x86_64 to armhf for example
10:46 <jirutka> but actually not sure if it’s the best approach; alternatively we can bootstrap it from glibc binaries from armhf, we need to do that even for x86_64 anyway :/
10:47 <skarnet> yay native builds on armhf
10:47 <skarnet> or: how to wait a week for your build to eventually fail
10:47 <fabled> jirutka, the very first rust may need to be built from "foreign" system... however, we prefer that the APKBUILD supports cross-building so when we bootstrap new arch, an automated process can do it
10:47 <ncopa> skarnet: our armh xgene server isnt that bad actually
10:48 <ncopa> armhf
10:48 <fabled> gcc, rust and go already support this
10:48 <skarnet> fabled: how can I declare a cross-build in APKBUILD?
10:49 <jirutka> fabled: well, but I have still no idea what to do :( these CROSS_COMPILE, makedepends_host, … variables and the entire cross-compilation process in abuild is not documented at all :/
10:49 <fabled> it just needs to honor CHOST, CTARGET and few other environment variables set on cross-build. also need to distinguish which build dependencies go to build, host and target
10:50 <fabled> makedepends_* need to be set right
10:50 <fabled> but on self-hosting compiler it may be little bit trickier
10:50 <fabled> abuild tries to set all the common environment variables right for autoconf et al
10:50 <skarnet> CHOST = build arch and CTARGET = target arch?
10:50 <skarnet> are those gcc triplets?
10:51 <fabled> inside apkbuild those are gcc triplets, yes
10:51 <fabled> CBUILD="the computer we are running on"
10:51 <fabled> CHOST="the computer that will execute produced files"
10:51 <skarnet> ok, so you have CBUILD too
10:52 <fabled> CTARGET="on gcc, the computer for which the generated compiler will produce files for"
10:52 <fabled> normally CBUILD=CHOST _or_ CHOST=CTARGET
10:52 <skarnet> yeah, so unless you're packaging a compiler, CTARGET shouldn't be used
10:52 <fabled> yes
10:52 <skarnet> you build from CBUILD to CHOST
10:52 <fabled> yes, that the gcc / autoconf idom
10:52 <fabled> idiom*
10:56 <jirutka> fabled: is there some better way how to cross-compile from glibc on our infra than using docker like in ghc?
10:57 <fabled> depends on a lot of things
10:57 <jirutka> ?
10:58 <skarnet> why would you need docker? you just need a proper, non-leaky toolchain
10:58 <skarnet> if you can't avoid leaking, a chroot is enough, you don't need a full container
10:58 <jirutka> skarnet: +1
10:59 <jirutka> skarnet: that’s exactly what i was thinking about
10:59 <jirutka> skarnet: imo docker is totally unnecessary for this
10:59 <fabled> probably yes. it's matter of preference and ease of scripting for the one writing the bootstrap script
10:59 <skarnet> I have proper musl toolchains at http://skarnet.org/toolchains/ but they're not Alpine-branded
11:00 <fabled> the problem with compilers written on their own language is that you need binary compiler to get started with
11:00 <fabled> so as long as we have some compiler that runs on alpine, and can be used to build the initial .apk, we are good to go
11:01 <jirutka> fabled: we can download prebuilt binary linked against glibc from upstream
11:01 <fabled> if it works on musl, then great
11:01 <jirutka> fabled: it doesn’t
11:01 <jirutka> fabled: glibc
11:01 <jirutka> fabled: unfortunately they still don’t provide actually portable binary or binary linked against musl
11:01 <fabled> so then we need someone to build it against musl, make static build out of it, or fix musl's glibc compat so the glibc version works
11:02 <jirutka> currently I use rustc built against musl from VoidLinux
11:02 <jirutka> before that I cross-compiled one myself
11:03 <jirutka> actually the current binary in VoidLinux is probably initially built with mine
11:03 <jirutka> but as I understand, we don’t wanna rely on binary from VoidLinux; moreover they don’t have rustc for armhf etc.
11:03 <jirutka> (and rustc unfortunately cannot be statically linked)
11:06 <skarnet> ah, the joys of modern languages designed by people who don't understand bootstrap
11:09 <^7heo> ;)
11:09 <^7heo> moin alle
11:16 <jirutka> fabled: "or fix musl's glibc compat so the glibc version works" … not sure if it’s possible, https://hastebin.com/raw/eqajesewos
11:17 <fabled> jirutka, check on #musl
11:22 <skarnet> 10 bucks says rustc uses some dirty glibc ABI that kills binary compatibility with musl :P
11:24 <jirutka> imo not rustc itself, but llvm…
11:27 <jirutka> no, that’s probably nonsense
11:32 <jirutka> when binary uses __register_atfork symbol, it should appear somewhere in the source code, right?
11:32 <jirutka> b/c i can’t find "register_atfork" in rustc, liblibc or compiler-rt codebase
11:37 <jirutka> skarnet: ^ did I wrote total nonsense or not? :)
11:39 <skarnet> honestly I'm not sure. I don't know llvm or rustc, and how symbols are generated and appear in object files is still mysterious to me even with gcc.
11:39 <skarnet> I don't think you wrote nonsense because that's the exact kind of question I could ask: "where does that fkn symbol come from?"
11:39 <skarnet> but I don't have the answer. :P
11:44 <jirutka> okay :)
11:50 ncopa_ joined
12:06 cyteen joined
12:22 terra joined
12:39 <jirutka> I’m gonna use VoidLinux for bootstrapping rust for Alpine :) it can be easily installed into chroot in the same way as Alpine
12:57 <mitchty> i just used docker for the ghc-bootstrap port out of laziness, that and it did save a lot of time in not having to redo things like building cross compilers etc...
13:07 cyteen_ joined
13:24 rdutra joined
13:28 <jirutka> skarnet: do you know about some more secure way how to do chroot without needing to allow mount command, to bind /proc, /sys, /dev?
13:29 <jirutka> skarnet: or ideally some method that does not require root privileges, or just a minimum subset? some very minimal bare support for user “containers” :)
13:30 <skarnet> I don't, but that shouldn't be a problem: mount your filesystems in your chroot, perform the chroot, then drop privileges before getting back to the user.
13:31 <jirutka> skarnet: the second question is more an open question for discussion, it’s probably not possible, at least from what I know, but maybe you have some interesting ideas
13:31 <skarnet> if it's a program that must be called in an apkbuild, then I'm afraid you need a setuid helper for this
13:31 <skarnet> it's an open question really
13:32 <skarnet> work on user containers is under way
13:32 <jirutka> I remember that you have some interesting helper for sudo using sockets or something like that that allows better separation
13:32 <skarnet> some things work, others don't yet
13:32 <skarnet> yes, I do, but it requires running a server
13:34 <jirutka> the problem is that we don’t allow mount in LXC containers for security reasons, so doing mount and then dropping privileges can’t help there; my only idea is to prepare proc sys and dev in advance, when starting lxc container
13:35 <skarnet> i.e. if you want to run "foobar" as user foo, instead of making "foobar" suid foo, you run a daemon as user foo that does "s6-sudod foobar", and a client that wants to run foobar basically runs "s6-sudo socket-to-that-daemon", which runs foobar as user foo on the client's behalf
13:36 <skarnet> yeah, that's a real problem
13:36 <skarnet> you need root privileges at some point to mount the filesystems, so you kinda need to prepare your container in advance
13:36 <skarnet> I don't have a good solution for this
13:36 <skarnet> brb
13:37 <jirutka> but not whole rootfs, just these binds
13:46 cyteen_ joined
14:15 <Shiz> jirutka: ping
14:44 <ncopa> i have qt 5.8.0 in my queue
14:44 <ncopa> i also move qt5*, vlc and wireshark to community
14:45 <ncopa> i think im good to push, but i wonder if i should maybe wait til monday in case things break
14:47 <ncopa> armhf is arelady broke
14:47 <ncopa> so i push and hope it fixes things :)
14:48 <Shiz> :P
14:48 <Shiz> ncopa: i think we're almost done with rust to have it into a fully working state
14:48 <Shiz> i have 1 patch to present to jirutka and one more to write
14:48 <Shiz> and then it should be fully working...
14:52 <ncopa> wow
14:52 <ncopa> very nice
14:52 <ncopa> thats a nice thing to have in the 3.6 release notes :)
14:53 <Shiz> :)
14:56 <mitchty> get ghc and idris in too please :)
14:56 <mitchty> agda is a bit more involved but i'm working on it
15:22 BitL0G1c joined
15:40 fekepp joined
15:46 <jirutka> Shiz: I’m here, waiting for patch :)
15:46 <Shiz> :P
15:47 <Shiz> jirutka: https://txt.shiz.me/MDBkZjE1ND
15:56 Emperor_Earth joined
15:57 <jirutka> Shiz: perfect!
15:57 <Shiz> one more patch left..
15:57 <Shiz> with the rpath :P
16:20 <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?
16:23 <TemptorSent> xentec: Good question -- do all packages which currently depend on ncurses-terminfo work for all expected cases with only -base installed?
16:24 <xentec> I would think so, since the only thing -termbase provides is legacy
16:45 <Shiz> jirutka: building with hopefully the final patch :)
17:00 <BitL0G1c> on the 4.9 kernel has anyone noticed "net.c:592: sendmsg() failed: Operation not permitted" (for dns queries - even with everything outbound allowed in iptables / ip6tables) - doesn't happen on the stable kernel
17:16 terra joined
17:41 fekepp joined
18:10 <Shiz> jirutka: currently testing rustc with our build triple
18:10 <Shiz> :)
18:22 geekblogtv joined
18:23 <geekblogtv> sup fellas
18:29 <Shiz> hiya
18:33 <geekblogtv> hey there shiz
18:33 <geekblogtv> im curious, how many of you out there are building your own alpine iso's with your commonly installed apps on there
18:43 <kaniini> mitchty: question
18:43 <kaniini> mitchty: how do you bootstrap ghc onto a new architecture ?
18:46 fabled joined
18:50 <Shiz> geekblogtv: i mostly use lbus for that
18:50 <Shiz> no need for own alpine isos
18:55 <TemptorSent> geekblogtv: I'm working on mkimage, including autoconfiguration of services.
19:10 t0mmy joined
19:14 <nmeum_> kaniini: iirc you crosscompile it from a debian glibc host using docker (see testing/ghc-bootstrap)
19:35 <mitchty> kaniini: i was doing what nmeum_ was doing, but fabled setup the cross compile stuff so we should be able to use the x86_64 ghc and cross compile to the target arch
19:36 <mitchty> so ghc-bootstrap become/became more an historical artifact of this is how we got x86_64 from a debian glibc to alpine linux setup
19:37 <nmeum_> oh, that's nice didn't know about that
19:41 <mitchty> it should be somewhat easy to flesh out the rest of the architectures, but i don't have a ppc setup or armv8 (latter yet, working on getting one) or i'd port ghc to that too
19:42 <mitchty> but ghc does have what is called an unregisterised build which should work, it might not be as speedy, but ironically enough the arm cross port is probably the hardest due to it requiring llvm
19:43 <mitchty> that and i'm trying to use my ghc port to build other things to play with :) dependent types are... fun
19:46 <kaniini> got it
19:47 <mitchty> on that note, i have ghc 8.2 working as well its in rc status, but should I be keeping the ghc-bootstrap port up to date with what the ghc version is?
19:48 <mitchty> getting that working is a lot of busy work, but not sure if it matters to keep the glibc->musl bridge up to date
19:49 <mitchty> i wanted to work with the upstream to get musl libc to be more of a tier 1 platform
19:59 <Shiz> kaniini: btw, bootstrapping rust will be doable i think
19:59 <Shiz> from a glibc host
20:13 <Shiz> Building stage1 compiler artifacts (x86_64-unknown-linux-musl -> x86_64-alpine-linux-musl)
20:13 <Shiz> :)
20:22 <xentec> Shiz: you mean "x86_64-unknown-linux-gnu", don't you?
20:23 <mitchty> doesn't rust use an embedded musl for its compiler or am I misremembering
20:26 <Shiz> xentec: no?
20:26 <Shiz> mitchty: only for distributions
20:26 <xentec> nevermind then
20:28 <mitchty> Shiz: ok cool, i remember going through some of how rust worked and hit the embedded musl libc and decided the build process was complex and left it at that :)
20:28 <Shiz> xentec: i'm just doing a local bootstrap now, not a glibc bootstrap
20:28 <Shiz> :P
20:39 <xentec> ncopa, you there? I was wondering, why ncurses handles terminfo files the way it does (symlinking to /etc) and why everything ncurses related depends on the 6.5 MiB big ncurses-terminfo instead of much smaller ncurses-terminfo-base.
20:40 <skarnet> the detailed technical explanation is that ncurses is a steaming pile
20:41 <xentec> I know that since the moment I've tried to use ranger on alpine :P
20:42 cyteen joined
20:52 <jirutka> Shiz: this may help you: https://gist.github.com/japaric/52b8816a4c86f5a4699bcc50ebc3e020
20:53 <Shiz> jirutka: btw, we now have an x86_64-alpine-linux-musl rustc
20:53 <Shiz> :)
20:56 trn joined
21:23 boingolov joined
21:37 <jirutka> VoidLinux provides pkg cross-x86_64-linux-musl (also for arm and others), so we don’t even need to build own toolchain
21:38 <Shiz> jirutka: ping
21:38 <Shiz> :P
21:38 <jirutka> Shiz: well, I know that I’ve suggested x86_64-alpine-linux-musl, but then I’ve realized that it’s maybe a bad idea
21:39 <skarnet> jirutka: I provide better toolchains than Void does :P but aiui Alpine wants Alpine-branded toolchains
21:39 <skarnet> x86_64-alpine-linux-musl instead of x86_64-linux-musl
21:39 <Shiz> jirutka: actually, it's a very good idea
21:40 <Shiz> because it allows us to cleanly separate our toolchain changes into a separate target
21:40 <Shiz> static PIE support, mandatory rpath, etc
21:40 <jirutka> skarnet: I believe that, but how it can help us with cross-compiling rustc on glibc system…?
21:40 <Shiz> jirutka: i also reordered all patches kinda locally
21:40 <Shiz> i've got a huge diff against upstream aports now
21:40 <Shiz> D:
21:40 <skarnet> jirutka: my toolchains are fully static, they don't care what system they're running on
21:40 <Shiz> (but the patches are more cleanly separated now)
21:41 <jirutka> Shiz: and what about x86_64-unknown-linux-musl, would this be still usable?
21:41 <Shiz> jirutka: yes :)
21:41 <Shiz> jirutka: it would be static by default, as with upstream
21:41 <Shiz> and not support static pie
21:42 <jirutka> skarnet: okay, I believe that they are awesome, but still, we just need to somehow bootstrap Rust, we must use “foreign” system for it and since Void already provides cross-compiling toolchain, I don’t see a reason why not use it, if it will work
21:43 <skarnet> eh, not my problem if you want Alpine to be dependent on Void
21:43 <Shiz> jirutka: https://txt.shiz.me/MTMzYTczMT
21:44 <Shiz> this is what my APKBUILD looks like right now
21:44 luxio joined
21:44 <jirutka> Shiz: “# Make sure to use the bundled LLVM.” what?
21:44 <Shiz> jirutka: if build != host/target, it will attempt to recompile LLVM
21:45 <Shiz> --llvm-root only applies to --build=
21:45 <jirutka> but *bundled*?
21:45 <Shiz> oh
21:45 <Shiz> that should say 'not'
21:45 <jirutka> system-provided…
21:45 <Shiz> :)
21:45 <jirutka> aha :)
21:46 <Shiz> the only major difference is the re-organized patches and install() using make dist instead of make install
21:46 <Shiz> because make install doesn't work on xcompilations
21:47 <jirutka> why so?
21:47 <Shiz> it will attempt to install $build
21:47 <Shiz> instead of $host/$target...
21:47 <jirutka> and it can’t be changed?
21:47 <Shiz> believe me, I tried
21:48 <jirutka> okay
21:48 <Shiz> and turns out
21:48 <Shiz> make install is an alias for the exact thing we're doing in APKBUILD
21:48 <Shiz> :P
21:48 <Shiz> minus the fucky build/host/target checking
21:49 <jirutka> you don’t need _ctarget, just use CTARGET variable ;)
21:49 <jirutka> this will also work for cross-compilation
21:49 <Shiz> that is right
21:49 <Shiz> :)
21:51 <Shiz> jirutka: what do you think of the re-organized patches
21:51 <Shiz> i used the following naming:
21:51 <Shiz> musl-*: musl support patches that are intended to go upstream
21:51 <Shiz> prefixless: othe rpatches that may go upstream
21:51 <Shiz> alpine-*: patches that will likely never go upstream
21:53 <jirutka> looks good!
21:53 <jirutka> btw about filecheck, I’ve added it to llvm3.9-dev
21:53 <jirutka> it’s in /usr/lib/llvm3.9/bin/FileCheck
21:54 <Shiz> ah, so we don't need that anymore?
21:55 <jirutka> it’s needed for codegen tests
21:55 <jirutka> hm, I would keep that patch anyway
21:55 <Shiz> why's that
21:56 <jirutka> b/c it’s really not needed for build, only for tests
21:56 <Shiz> well, then there's also no reason to keep the patch, is there?
21:56 <Shiz> P
21:56 <Shiz> :P
21:56 <jirutka> we can add /usr/lib/llvm3.9/bin to PATH for tests, but I don’t feel like to add it even for build
21:57 <Shiz> jirutka: not needed
21:57 <jirutka> not needed in reality, but this build script still checks if it’s available
21:57 terra joined
21:57 <Shiz> yes but
21:57 <Shiz> you don't need to add /usr/lib/llvm3.9/bin to path
21:57 <Shiz> even if it did
21:57 <Shiz> it will find it there automatically
21:58 <jirutka> really?
21:58 <Shiz> yes
21:58 <jirutka> aha, didn’t know that!
21:58 <Shiz> because of --llvm-root/llvm_config=
21:58 <jirutka> then get rid of the patch :)
21:58 <Shiz> doing a final build now
21:59 <Shiz> before throwing my huge patch at you
21:59 <Shiz> :D
22:02 <Shiz> jirutka: btw what was the trouble you were getting with the tests?
22:12 <jirutka> Shiz: tests in rust?
22:12 <Shiz> yeah
22:12 <Shiz> the XXX'd out make test one
22:12 <jirutka> well… try yourself… ;)
22:12 <Shiz> or make check
22:13 <jirutka> also I can’t find a way how to tell them to not stop after first suite failure
22:13 <jirutka> and the order is random…
22:14 <jirutka> https://github.com/rust-lang/rust/issues/40219
22:31 al3hex joined
22:32 <Shiz> jirutka: build complete :)
22:33 <Shiz> https://txt.shiz.me/NWNiNTc4NW
22:35 <jirutka> have you tried to compile something with --target=x86_64-unknown-linux-musl ?
22:36 <Shiz> i'm running cargo tests rn
22:36 <Shiz> but yeah, gimme a sec
22:44 <Shiz> jirutka: down to 3 cargo test failures :)
22:45 <Shiz> jirutka: right, we don't install the stdlib for x86_64-unknown-linux-musl
22:45 <jirutka> and that’s what I was afraid about
22:45 <Shiz> do you want it added to rust-stdlib?
22:46 <jirutka> ?
22:46 <Shiz> the stdlib for x86_64-unknown-linux-musl
22:46 <jirutka> this should be the same as x86_64-alpine-linux-musl, no?
22:46 <Shiz> i wonder
22:46 <Shiz> but i think so, yes
22:47 <jirutka> maybe what if you just create symlink in /usr/lib/rustlib …?
22:47 <Shiz> just tried
22:47 <Shiz> doesn't work
22:47 <Shiz> it checks a triple in the metadata
22:47 <jirutka> hm :/
22:48 <jirutka> that’s why I eventually wrote that it’s maybe not a good idea to use different triplet
22:48 <jirutka> but still not sure…
22:48 <Shiz> well
22:48 <Shiz> the thing is
22:49 <Shiz> what do you want to achieve with using the same triplet as upstream?
22:49 <Shiz> our features are different
22:49 <Shiz> so i think it makes sense to have a different triplet
22:49 <jirutka> yes, I agree with that
22:50 <Shiz> and it's not too hard to add x86_64-unknon-linux-musl stdlib stuff if we want upstream compat
22:50 <jirutka> but it’s quite silly, the binaries would be the same, except metadata…
22:50 <Shiz> they might not be
22:50 <Shiz> nothing guarantees this, after all
22:51 <jirutka> how can they be different?
22:51 <jirutka> rlibs
22:51 <jirutka> PIE does not affect static libraries, right?
22:54 <Shiz> the llvm target is different
22:54 <Shiz> so it depends on to what extent we patch llvm too
23:04 <Shiz> jirutka: anyway
23:04 <Shiz> want my patches? :P
23:05 <jirutka> yeah!
23:11 <Shiz> jirutka: https://txt.shiz.me/ZGU2Nzk0Nz
23:24 <jirutka> Shiz: thanks! I’ll review it and apply tomorrow; I go to sleep now
23:24 <Shiz> :)
23:24 <Shiz> sleep well
23:36 <TemptorSent> jirutka: Goodnight. We should be ready to rearrange repos early next week for mkinitfs/mkimage & friends.