| *** richard_maw has quit IRC | 02:45 | |
| *** richard_maw has joined #baserock | 02:45 | |
| *** ChanServ sets mode: +v richard_maw | 02:45 | |
| *** richard_maw has quit IRC | 02:50 | |
| *** richard_maw has joined #baserock | 02:51 | |
| *** ChanServ sets mode: +v richard_maw | 02:51 | |
| *** locallycompact has joined #baserock | 06:25 | |
| *** ctbruce has joined #baserock | 07:31 | |
| *** mwilliams_ct has joined #baserock | 07:33 | |
| *** toscalix has joined #baserock | 07:42 | |
| *** CTtpollard has quit IRC | 08:27 | |
| *** franred has quit IRC | 08:33 | |
| *** tiagogomes has joined #baserock | 08:41 | |
| *** jonathanmaw has joined #baserock | 08:46 | |
| anahuelamo | paulsherwood, it works for me too. I can build the system, deploy it and boot the image. But depends on which system I use the files in /usr/src/MPC remain in the system or not | 08:52 |
|---|---|---|
| *** CTtpollard has joined #baserock | 08:53 | |
| *** toscalix has quit IRC | 08:56 | |
| *** toscalix_ has joined #baserock | 08:56 | |
| paulsherwood | anahuelamo: both systems worked for me | 08:57 |
| paulsherwood | ie both systems don't have /usr/src/MPC | 08:57 |
| anahuelamo | paulsherwood, Ok, I'll test again, I'm not sure what is happening then | 08:58 |
| *** ssam2 has joined #baserock | 09:00 | |
| *** ChanServ sets mode: +v ssam2 | 09:00 | |
| *** CTtpollard has quit IRC | 09:05 | |
| *** CTtpollard has joined #baserock | 09:05 | |
| *** edcragg has joined #baserock | 09:10 | |
| paulsherwood | ssam2: i'm occasionally tripping over http://paste.baserock.org/wozuzomusu | 09:27 |
| paulsherwood | any idea what that traceback signifies, please? | 09:27 |
| ssam2 | possibly that the output of the command that ran contains non-ascii characters | 09:28 |
| ssam2 | is this with python 2 or python 3 ? | 09:28 |
| paulsherwood | python 2 | 09:28 |
| ssam2 | right | 09:29 |
| ssam2 | probably a bug in sandboxlib code needs | 09:29 |
| ssam2 | -code needs | 09:29 |
| ssam2 | i don't have time to dig in further right now, sorry | 09:29 |
| paulsherwood | what do you mean by needs? | 09:30 |
| paulsherwood | the command is 'if which depmod; then (cd /lib/modules && for version in *; do depmod -a "$version"; done) fi ' which seems to be ascii to me :) | 09:30 |
| ssam2 | i was going to write that it needs to handle non-ascii characters better | 09:30 |
| ssam2 | no, I mean the output of the command | 09:30 |
| paulsherwood | ah, ok | 09:30 |
| ssam2 | that's a guess, but it seems most likely | 09:30 |
| richard_maw | python in general needs to handle non-ascii characters better, and python3 gets it wrong for file paths | 09:31 |
| * richard_maw grumbles about string types | 09:31 | |
| paulsherwood | hence locallycompact is thinkinng of starting in rust. trouble is rust is mostly incomprehensible :-) | 09:31 |
| ssam2 | hmm, maybe it's something else | 09:32 |
| ssam2 | http://python.6.x6.nabble.com/Can-t-use-subprocess-Popen-after-os-chroot-why-td1417932.html | 09:32 |
| locallycompact | paulsherwood, what part of rust are you finding troubling? :) | 09:32 |
| ssam2 | is there a way to get the full traceback, rather than just the exception ? | 09:32 |
| ssam2 | hmm, that is the full traceback | 09:32 |
| edcragg | paulsherwood: incomprehensible if you don't understand it, clearly ;) | 09:33 |
| richard_maw | paulsherwood: If you're going to rewrite everything from scratch, then Rust might be good for the bits you need to reinvent, but I would strongly recommend working out exactly what functionality the tool needs, and satisfy that with as many existing tools as are feasible. | 09:33 |
| ssam2 | ok, seems sandboxlib itself is eating the traceback | 09:34 |
| locallycompact | richard_maw, that's sort of missing the point of this exercise, I'll be happy to explain after I head into work. | 09:34 |
| richard_maw | paulsherwood: My take from both morph and ybd is that the problem is inherently complex, and the best way to manage that complexity is to break it down, so while there is more total complexity, the abstractions mean you can avoid needing to know the details. | 09:34 |
| jmacs | edcragg: That's pretty much the definition of incomprehensible | 09:34 |
| * richard_maw raises eyebrow at locallycompact's comment | 09:34 | |
| rjek | Rust fails my "vaguely understandable at a glance to somebody who has programmed in other languages" test | 09:35 |
| locallycompact | c fails that test for me | 09:35 |
| locallycompact | rust is kind of just obvious | 09:35 |
| locallycompact | to me | 09:35 |
| locallycompact | anyway, back in a bit | 09:36 |
| jmacs | Any language you've already programmed in looks obvious | 09:36 |
| *** toscalix_ is now known as toscalix | 09:36 | |
| paulsherwood | only while you remember how to program in it :) | 09:37 |
| paulsherwood | richard_maw: i'm not going to write everything from scratch... i didn't even do that for ybd :) | 09:38 |
| paulsherwood | i agree this is complex, though | 09:39 |
| *** locallycompact has quit IRC | 09:40 | |
| richard_maw | paulsherwood: a proposed Rust rewrite would require writing much more code, YBD could pinch code from morph to handle bits. | 09:40 |
| paulsherwood | ybd already did pinch code from morph | 09:41 |
| richard_maw | I know, I just said it did. | 09:41 |
| paulsherwood | ah, sorry, i misunderstood | 09:41 |
| * richard_maw also wasn't unambiguous about his meaning, so appologieses there | 09:41 | |
| paulsherwood | i originally suggested improving on aboriginal, or xdg-app-builder... locallycompact, being young, bright eyed and of purist ideals, suggested starting in rust instead :) | 09:42 |
| * paulsherwood has learned that sometimes the young can achieve miracles... | 09:43 | |
| rdale | has rust got a good web framework? | 09:44 |
| mwilliams_ct | you once told me that the job of the old is to demand the impossible of the young, and the job of the young is to do it because they don't realise it's impossible | 09:44 |
| paulsherwood | mwilliams_ct: yup. well remembered, young man :-) | 09:45 |
| mwilliams_ct | paulsherwood: dementia won't set in for a while yet :) | 09:45 |
| paulsherwood | maybe not for you :-) | 09:45 |
| rjek | Dementia in whom? | 09:45 |
| mwilliams_ct | it's a good line though, I've been careful to ignore everything older people have told me ever since | 09:45 |
| rdale | cheers | 09:45 |
| mwilliams_ct | :) | 09:46 |
| rjek | tbh, most people are older than mwilliams_ct | 09:47 |
| rdale | i prefer to collaborate on things that no one single person could pull off by themselves - including the strengths of the older and the younger people | 09:48 |
| mwilliams_ct | rdale: to be quite clear, if I ever ignored anything you told me I'd be a fool. I was very much kidding! | 09:48 |
| paulsherwood | back on topic... | 09:49 |
| rdale | no problem - knowing who to ignore is always an important skill though | 09:49 |
| paulsherwood | what provides 'which' in baserock systems, please? | 09:50 |
| edcragg | busybox? | 09:50 |
| richard_maw | it used to be busybox | 09:50 |
| ssam2 | try this in a br system: grep 'which' /baserock/*.meta | 09:51 |
| paulsherwood | ok, thanks. i'm trying to regularise ybd's system artifacts so it includes -runtime and -devel | 09:51 |
| paulsherwood | when i do that, it seems 'which' has disappeared | 09:51 |
| *** locallycompact has joined #baserock | 10:11 | |
| paulsherwood | ah, so busybox is specified in build-essential-minimal... | 10:26 |
| locallycompact | so the stage0 rust builds and installs fine, then I try to use it to compile the next one and I get this | 10:27 |
| paulsherwood | richard_maw: so the idea is that if we want to create (say) a -runtime system, we'd add *-minimal + *-runtime ? | 10:27 |
| locallycompact | /tools/bin/rustc: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /tools/bin/../lib/librustc_llvm-db5a760f.so) | 10:27 |
| * paulsherwood also wonders if a sensible *default* behaviour for ybd would be to create -runtime systems (smaller) rather than -devel systems | 10:29 | |
| jjardon | locallycompact: does rust depend on llvm ? | 10:29 |
| richard_maw | jjardon: yes | 10:29 |
| richard_maw | paulsherwood: yes | 10:30 |
| paulsherwood | ok great | 10:30 |
| paulsherwood | richard_maw: i think i finally understand splitting! :-) | 10:30 |
| jjardon | locallycompact: only checking but, are you including the strata/llvm-common dep in your rust stratum? | 10:30 |
| jjardon | paulsherwood: havinf -runtime and -devel system is a _major_ achievement, congrats | 10:31 |
| locallycompact | jjardon, no, I thought it was using the submodule | 10:31 |
| locallycompact | since stage0 works | 10:32 |
| * richard_maw wishes that had happened before paulsherwood declared it to be too complicated and unnecessary | 10:32 | |
| *** richard_maw has left #baserock | 10:32 | |
| * paulsherwood notices richard_maw seems to have left the building | 10:34 | |
| paulsherwood | fwiw i 'declared' it to be too complicated. i don't remember ever saying it was unnecessary | 10:34 |
| *** cosm has joined #baserock | 10:34 | |
| paulsherwood | jjardon: i've pushed it to master. let's hope i haven't broken anything | 10:37 |
| * jjardon starts a gazilion of builds | 10:40 | |
| paulsherwood | jjardon: you'll get -runtime by default now | 10:41 |
| jjardon | cool | 10:41 |
| paulsherwood | hah! ybd ci actually works... i changed the system cache-keys and broke the cache-key test :-) | 11:22 |
| paulsherwood | can anyone give me a clue on http://paste.baserock.org/tixarigere please? | 11:33 |
| *** ssam2 has quit IRC | 11:46 | |
| locallycompact | jjardon, that didn't help any | 11:53 |
| paulsherwood | win 35 | 11:57 |
| paulsherwood | bah | 11:57 |
| *** ssam2 has joined #baserock | 11:58 | |
| *** ChanServ sets mode: +v ssam2 | 11:58 | |
| rdale | paulsherwood: i'm not undstanding the discussion about -runtime and -devel - they are default splitting rules and ybd will already have them if you want to specify them in a system | 12:09 |
| paulsherwood | rdale: it wasn't working - afaict there was no logic to apply the default rules for systems, so it only worked for systems (eg minimal) where the splits were specified | 12:12 |
| paulsherwood | maybe i broke it... but you did say you hadn't tested on anything other than minimal :) | 12:13 |
| rdale | yes, you need to specify 'foo-runtime' or 'foo-devel' in a system otherwise you get everything - that is what it is supposed to do | 12:13 |
| paulsherwood | ack - so i've now made it that ybd does runtime systems by default | 12:14 |
| paulsherwood | and that can be changed without editing the definitions themselves | 12:14 |
| SotK | I thought we wanted things to be fully deterministic based just on the definitions? | 12:14 |
| rdale | i don't think that is a fix, it is an enhancement - it worked as defined by the behaviour of morph doing the same thing | 12:15 |
| paulsherwood | SotK: good point. but at the moment there's nothing in definitions saying which default rules apply, iiuc? | 12:16 |
| paulsherwood | rdale: you may be right, but afaict morph's base-system defaults to stripping, and ybd's didn't | 12:17 |
| paulsherwood | s/stripping/splitting/ | 12:17 |
| paulsherwood | i got lost in a maze on this... the splitting code was using foo['strata'] info which i believed i had expunged from ybd from the start | 12:18 |
| SotK | I've always assumed that morph's implementation is the de-facto default behaviour of definitions (at least for behaviour from before ybd existed) | 12:20 |
| rdale | the morph splitting didn't work properly when i tried it, and so i was basing the ybd spec on the intention behind the code - but i never noticed anyone say that if no splits were specified you just got '-runtime' | 12:20 |
| SotK | that may not be written down anywhere though | 12:20 |
| paulsherwood | ack | 12:20 |
| paulsherwood | SotK: my compromise for the moment is that -runtime systems generate a different cache-key from -devel systems | 12:21 |
| rdale | how do you define -runtime system and -devel systems without specifying any splits in the system definition? | 12:22 |
| paulsherwood | by specifying them as a default-splits config | 12:22 |
| paulsherwood | https://github.com/devcurmudgeon/ybd/blob/master/ybd/config/ybd.conf#L72 | 12:23 |
| rdale | is that a new ybd only thing? | 12:23 |
| paulsherwood | yes | 12:23 |
| paulsherwood | i was getting pressed to reduce system artifact sizes | 12:23 |
| rdale | what is the difference betwen minimal and runtime then? | 12:24 |
| paulsherwood | i don't know. most strata don't have a minimal | 12:24 |
| paulsherwood | i guess i can try it to find out :) | 12:24 |
| rdale | i don't think you can have a default splitting rule to do that as it is stratum specify what can be removed to make it 'minimal' | 12:25 |
| rdale | ^specify^specific | 12:25 |
| paulsherwood | ack | 12:26 |
| paulsherwood | http://paste.baserock.org/texuyasire | 12:27 |
| paulsherwood | doesn't work :) | 12:27 |
| paulsherwood | however just specifying runtime doesn't work either... since build-essential-runtime doesn't include busybox or fhs-dirs | 12:28 |
| rdale | well that is why we have 'build-essential-minimal' then | 12:29 |
| *** tiagogomes has quit IRC | 12:29 | |
| paulsherwood | seems so | 12:29 |
| *** franred has joined #baserock | 12:43 | |
| *** tiagogomes has joined #baserock | 12:44 | |
| *** edcragg has quit IRC | 13:01 | |
| *** edcragg has joined #baserock | 13:03 | |
| *** edcragg has quit IRC | 13:14 | |
| *** edcragg has joined #baserock | 13:14 | |
| ssam2 | might be easier if you can choose which artifacts to *exclude* from a system | 13:15 |
| locallycompact | I'm very stuck with this glibc thing, is this a problem encountered by build-essential? | 13:16 |
| *** tiagogomes has quit IRC | 13:17 | |
| ssam2 | at a random guess, looks like a libc version mismatch | 13:17 |
| ssam2 | not sure how that would happen, i've never looked at how Rust bootstraps itself | 13:17 |
| locallycompact | is there something I can do to diagnose? All I'm doing is this twice: once with bootstrap on and then once off :CFG_ENABLE_LOCAL_RUST=1 ./configure --prefix=$PREFIX, make, make install | 13:21 |
| locallycompact | and it gives that GLIBCXX thing the second time | 13:21 |
| *** tiagogomes has joined #baserock | 13:30 | |
| ssam2 | I think this issue is specific to Rust, i've never seen it before | 13:34 |
| ssam2 | i don't really know how to go about debugging it | 13:35 |
| ssam2 | I guess comparing the symbols and their versions in /tools/bin/../lib/librustc_llvm-db5a760f.so and /usr/lib64/libstdc++.so.6 will tell you if it is indeed a version mismatch | 13:35 |
| ssam2 | does Rust bootstrap itself by downloading a prebuilt binary? if so, maybe it expects a different version of GCC & GLIBC to what we have in the Baserock reference systems? | 13:36 |
| ssam2 | although you'd think if it downloads a prebuilt binary it would be statically linked | 13:36 |
| ssam2 | but you'd think the same about our stage1 and stage2 chunks, and actually they aren't and are completely fragile to glibc version mismatches on the host system :( | 13:36 |
| locallycompact | it's not downloading a prebuilt, I turned that off | 13:37 |
| locallycompact | it's building one from the host tools with bootstrap on | 13:38 |
| locallycompact | and prefix: /tools | 13:38 |
| locallycompact | and then one depending on that | 13:38 |
| locallycompact | I'm running this on ubuntu if that matters | 13:39 |
| ssam2 | hmm, hang on | 13:40 |
| ssam2 | is it building in a chroot or is this in bootstrap mode? | 13:40 |
| ssam2 | must be chroot I guess or /tools would be /src/tmpxa7864/tools | 13:40 |
| locallycompact | It's in bootstrap mode | 13:41 |
| locallycompact | I dunno anything about a chroot | 13:41 |
| ssam2 | ah, right | 13:41 |
| ssam2 | how can it be building stuff in /tools then ?? | 13:41 |
| ssam2 | is it actually putting stuff in your host system in the /tools directory? | 13:42 |
| locallycompact | I thought that was $DESTDIR/tools | 13:42 |
| locallycompact | or something | 13:42 |
| locallycompact | this is the stratum https://github.com/locallycompact/definitions/blob/lc/rust/strata/rust.morph | 13:43 |
| ssam2 | $DESTDIR/tools is where stuff gets copied when its build, yeah | 13:43 |
| ssam2 | which should definitely not be /tools in your host system!!! | 13:43 |
| locallycompact | there's def not a /tools in my host systems | 13:44 |
| ssam2 | ok, good. It seemed like there was based on the error you posted earlier | 13:44 |
| locallycompact | that's the second one | 13:44 |
| ssam2 | i see stage1-rust is build in 'staging' mode | 13:45 |
| ssam2 | so that makes sense | 13:45 |
| ssam2 | ok, so maybe the 1st rust is linking against your host libstdc++ instead of the Baserock one | 13:45 |
| ssam2 | you probably have to pass various paths into the stage0 configure script to make it use one in a nonstandard location | 13:46 |
| locallycompact | ah | 13:46 |
| ssam2 | the Baserock libstdc++ will be installed in the staging area of the stage0 chunk, and the stage0 chunks .build dir will be the cwd | 13:46 |
| ssam2 | so something like LDPATH='../lib/' | 13:47 |
| ssam2 | that's a guess, i've not looked at how Rust's configure script works | 13:47 |
| locallycompact | hmm, there's something in here that says | 13:52 |
| locallycompact | opt llvm-static-stdcpp 0 "statically link to libstdc++ for LLVM" | 13:52 |
| *** gtristan has quit IRC | 13:57 | |
| ssam2 | with gcc you can pass --with-build-sysroot to the configure script | 13:57 |
| ssam2 | which means "link against libraries from here" | 13:57 |
| ssam2 | can't find anything similar in Rust | 13:57 |
| locallycompact | nop | 13:57 |
| ssam2 | is there any docs on how to cross-compile rust? | 13:58 |
| ssam2 | or you could build stage0 not in bootstrap mode? | 13:58 |
| ssam2 | the reason for bootstrap mode is basically so that you can use the compiler & shell from the host system | 13:59 |
| ssam2 | but i don't think you actually need that here? | 13:59 |
| locallycompact | how do I get the compiler in then? | 13:59 |
| locallycompact | It normally calls out to the internet for its stage0 | 14:00 |
| locallycompact | that turns off with CFG_ENABLE_LOCAL_RUST | 14:00 |
| locallycompact | then I need a host compiler | 14:00 |
| *** paulwaters_ has joined #baserock | 14:00 | |
| *** fay__ has joined #baserock | 14:03 | |
| *** fay_ has quit IRC | 14:03 | |
| ssam2 | what sort of compiler? | 14:04 |
| ssam2 | a host Rust compiler? | 14:04 |
| ssam2 | right, in that case you do need bootstrap mode | 14:04 |
| ssam2 | and then you have to figure out how to get the stage0 Rust to link against a sysroot | 14:05 |
| locallycompact | right | 14:05 |
| *** astrophys has joined #baserock | 14:17 | |
| *** gtristan has joined #baserock | 14:23 | |
| *** fay_ has joined #baserock | 14:36 | |
| *** fay__ has quit IRC | 14:38 | |
| locallycompact | I can't find anything about this, other than the configure seems to advocate clang in generla | 15:08 |
| jjardon | AFAIK, we do not have clang in baserock | 15:11 |
| jjardon | neither go, paulsherwood | 15:13 |
| ssam2 | it's possible nobody has tried to do this yet | 15:17 |
| ssam2 | I think building with sysroots is generally only something embedded developers want to do | 15:18 |
| paulsherwood | http://git.baserock.org/cgit/baserock/baserock/definitions.git/commit/?h=baserock/ps/docker&id=2047757886509d4b2530a6f1d0c32be4a6758ca0 | 15:19 |
| paulsherwood | jjardon: ^^ | 15:20 |
| ssam2 | an alternative approach would be download the thing it wants to download, commit that to a repo somewhere, and install it into the chroot | 15:20 |
| paulsherwood | eek :) | 15:21 |
| paulsherwood | if folks want go, i'm happy to update it and submit | 15:25 |
| jjardon | paulsherwood: I want everything :) if you dont have time, submit with WIP in the tittle, so at least we know a | 15:28 |
| jjardon | someone already work in it | 15:28 |
| locallycompact | ssam2, I may try that just for good vibes atm | 15:44 |
| paulsherwood | benbrown_: are you around? | 15:49 |
| *** ctbruce has quit IRC | 15:54 | |
| *** astrophys has quit IRC | 15:55 | |
| benbrown_ | paulsherwood: hello | 15:57 |
| locallycompact | mozilla #rust-internals has recommended I link against this thing https://www.musl-libc.org/ | 16:05 |
| locallycompact | and presumably that's static by default | 16:06 |
| rjek | static :( | 16:07 |
| ssam2 | static is good when bootstrapping | 16:07 |
| ssam2 | I'm not sure using musl instead of glibc will solve the problem you posted earlier | 16:08 |
| ssam2 | because that was a link error against libstdc++, which is part of GCC | 16:08 |
| *** fay_ has quit IRC | 16:08 | |
| locallycompact | The guy said | 16:08 |
| ssam2 | actually, if you could get the stage0 compiler to link itself statically then you would probably be fine, regardless of what exactly it linked against | 16:08 |
| locallycompact | regarding stage0 compiler: | 16:09 |
| locallycompact | <mbrubeck> locallycompact: For glibc, you need to build on a system with a glibc that's the same or older than the system you'll run on. | 16:09 |
| locallycompact | <mbrubeck> locallycompact: This is why the official binaries are build on CentOS 5, which is from 2007 | 16:09 |
| locallycompact | but that seems to be the case for me anyway | 16:09 |
| locallycompact | ldd (Ubuntu GLIBC 2.21-0ubuntu4) 2.21 | 16:09 |
| locallycompact | ^host | 16:09 |
| locallycompact | and baserock is 2.22? | 16:09 |
| ssam2 | that seems to imply that Rust can't build against a sysroot :-) | 16:09 |
| ssam2 | and they work around that by requiring the actual host machine has a really old glibc that they can link dynamically against, without breaking things for people with newer glibc | 16:10 |
| ssam2 | breaking things for people with older glibc, I mean | 16:10 |
| rjek | That sounds like a bit of a hack | 16:11 |
| locallycompact | why is my error version `GLIBCXX_3.4.21' not found, what version number is that | 16:11 |
| ssam2 | the error you posted earlier was libstdc++, not glibc | 16:11 |
| *** gtristan has quit IRC | 16:11 | |
| ssam2 | at least, that's what the error message appeared to say | 16:11 |
| ssam2 | I've no idea how to interpret that version string | 16:11 |
| locallycompact | right | 16:12 |
| locallycompact | I guess I'm confused as to what the things are still | 16:12 |
| paulsherwood | benbrown_: i was wondering, given you've been working on lorry-controller etc... | 16:13 |
| ssam2 | is https://github.com/japaric/rust-cross useful ? | 16:14 |
| paulsherwood | would you mind reading up on what Christoph has been discovering, and fix things up based on his work? | 16:14 |
| ssam2 | the Baserock bootstrap is effectively a cross-compile, even if it's x86_64 to x86_64 | 16:14 |
| locallycompact | that looks like compiling crates | 16:14 |
| benbrown_ | paulsherwood: Can do :) | 16:16 |
| paulsherwood | tvm | 16:16 |
| paulsherwood | we also need some reviewers for your gitlab work | 16:16 |
| ssam2 | "If you want to set up your Rust toolchain as a cross compiler, you have come to the right place!" | 16:17 |
| benbrown_ | paulsherwood: Aye, just cheekily asked ssam2 if he could go through and re+1 everything | 16:17 |
| paulsherwood | :-) | 16:17 |
| ssam2 | I see, and in the "How do I compile a fully statically linked Rust binaries?" section, it suggests using 'linux-musl' OS instead of 'linux-gnu' | 16:20 |
| ssam2 | which is slightly weird, but I guess that's why your man suggested using musl | 16:20 |
| ssam2 | so you could try building musl on the host, building stage0 rust on the host statically linked against musl, then building stage1 rust inside Baserock | 16:22 |
| ssam2 | the stage0 rust should work anywhere because it's statically linked | 16:22 |
| locallycompact | I will try that, ace, tyvm | 16:22 |
| *** gtristan has joined #baserock | 16:25 | |
| benbrown_ | ssam2: tyvm! | 16:27 |
| paulsherwood | benbrown_: is there any easy way to demonstrate that you've tested your lc stuff? | 16:28 |
| locallycompact | actually I don't think this will work | 16:29 |
| locallycompact | this is still for cargo calls : cargo build --target x86_64-unknown-linux-musl | 16:29 |
| locallycompact | The actual compiler just says "build a musl-enabled rust" | 16:30 |
| locallycompact | https://doc.rust-lang.org/book/advanced-linking.html#linux | 16:30 |
| locallycompact | ./configure --target=x86_64-unknown-linux-musl --musl-root=$PREFIX --prefix=$PREFIX | 16:30 |
| locallycompact | I don't think that's the same thing? | 16:30 |
| locallycompact | we'll see anyway | 16:30 |
| benbrown_ | paulsherwood: I've been ansiblising lorry-controller installation on a Ubuntu VM with GitLab | 16:31 |
| ssam2 | i presume both cargo and the ./configure script are ultimately using the rust compiler | 16:31 |
| benbrown_ | Almost done | 16:31 |
| ssam2 | so if it's possible to do it with cargo, it should hopefully be possible to do it in the compiler bootstrap, even if the code isn't there right now | 16:32 |
| ssam2 | see also the "Cross compiling with rustc" section of that doc | 16:32 |
| *** toscalix has quit IRC | 16:42 | |
| *** mwilliams_ct has quit IRC | 16:45 | |
| *** franred has quit IRC | 16:58 | |
| *** jonathanmaw has quit IRC | 17:02 | |
| *** edcragg has quit IRC | 17:11 | |
| *** ssam2 has quit IRC | 17:19 | |
| *** locallycompact has quit IRC | 17:26 | |
| *** anahuelamo has quit IRC | 17:38 | |
| paulsherwood | benbrown_: cool! | 18:03 |
| *** locallycompact has joined #baserock | 19:10 | |
| *** gtristan has quit IRC | 19:32 | |
| *** cosm has quit IRC | 19:34 | |
| *** cosm has joined #baserock | 19:49 | |
| paulsherwood | "Docker's build environment itself is a Docker container, so the first step is to install Docker on your system. | 20:23 |
| paulsherwood | wtf | 20:23 |
| paulsherwood | oh, joy... https://github.com/docker/docker/blob/master/Dockerfile | 20:48 |
| locallycompact | I'm shocked -> -_- | 20:50 |
| paulsherwood | me too | 20:57 |
| *** gtristan has joined #baserock | 21:33 | |
| *** gtristan has quit IRC | 22:35 | |
| *** edcragg has joined #baserock | 23:24 | |
| *** cosm has quit IRC | 23:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!