| *** tristan has joined #buildstream | 04:48 | |
| *** ChanServ sets mode: +o tristan | 04:48 | |
| ironfoot | Morning | 09:08 |
|---|---|---|
| ironfoot | I'll leave this log here just in case is useful: https://paste.gnome.org/potdglye6 | 09:09 |
| ironfoot | Leaving the following status | 09:13 |
| ironfoot | https://paste.gnome.org/pqoq623vl | 09:14 |
| tristan | ironfoot, did you really get past ./setup.py ? | 09:24 |
| ironfoot | I.... I promise | 09:24 |
| ironfoot | I'll do it again just in case | 09:25 |
| tristan | the checkout_at error looks familiar | 09:25 |
| tristan | Like you dont have >= v2016.8 of ostree | 09:25 |
| tristan | oh wait no it's something else seems | 09:25 |
| ironfoot | ostree 2016.15 | 09:26 |
| tristan | checkout_at doesnt exist before that | 09:26 |
| tristan | so what you are seeing is in fact the artifact cache failing to fire a more useful error (or handling the situation well) .. I think... lemme double check | 09:26 |
| * tristan notes he had to change libstdc++ -> libstdcxx ... because ostree is picky about it's ref names | 09:27 | |
| tristan | although the proper fix would probably be to have the artifact cache normalize names it wants to use as refs | 09:27 |
| tristan | no, it's not that that is happening | 09:28 |
| tristan | hmm, well clearly I have to chase the exceptions down | 09:28 |
| tristan | ironfoot, ok I'll have to look deeper, there are 2 problems here, a.) the build is failing to detect an error (falling into artifact cache code when there is nothing to archive it seems), and b.) the ldconfig is carried over from a build time dependency *it seems* (not sure about that) | 09:30 |
| * tristan thinks if he nukes his artifact cache it will reproduce | 09:31 | |
| ironfoot | right, I was goint to start debuging the ldconfig case | 09:31 |
| * tristan moves cache out of the way and runs a build | 09:33 | |
| * tristan immediately adds bst entry point | 09:34 | |
| *** juergbi has quit IRC | 09:34 | |
| *** juergbi has joined #buildstream | 09:36 | |
| tristan | fwiw, in master you can use the `bst` command instead of the tab-completion-unfriendly `build-stream` | 09:39 |
| * tristan lets some time pass before yanking / removing the `build-stream` entry point | 09:39 | |
| ironfoot | tristan: would be checking for `bwrap --version` in setup.py a sensible thing to do to check that it's installed? | 09:40 |
| tristan | ironfoot, we currently just use shutil.which() for other host tools... not very elaborate but I think it's fine | 09:42 |
| ironfoot | right, will do that | 09:42 |
| ironfoot | (failed to spot that yesterday) | 09:43 |
| tristan | ok so I'm already building stage1-binutils | 09:43 |
| tristan | (that means the ostree import must have been pretty lightning fast !) | 09:44 |
| tristan | couple of gig download | 09:44 |
| * tristan wonders if ostree is bleeding outside of the artifact cache | 09:45 | |
| * tristan palmface | 09:48 | |
| tristan | of course ! it's not only the artifact cache I need to remove to reproduce well... well... lets try it that way | 09:49 |
| tristan | (it's the source caches which hold all those downloads though) | 09:49 |
| ironfoot | i think you can keep those | 09:50 |
| ironfoot | (for this test, I mean) | 09:50 |
| tristan | yeah I suspect so | 09:51 |
| *** ssam2 has joined #buildstream | 10:07 | |
| tristan | ironfoot, found the issue I think... | 10:08 |
| ironfoot | :) | 10:11 |
| tristan | ironfoot, I added the integration commands after I built it seems, and I still have to add those to the cache keys | 10:14 |
| tristan | that should be a good cut-off point for adding the cache key test | 10:14 |
| * tristan pushes fix | 10:15 | |
| ironfoot | great! | 10:16 |
| tristan | ironfoot, https://gitlab.com/tristanvb/buildstream-tests/commit/142b3d5a6d71d1b28674cb3c76c1328c9dc14ab9 | 10:18 |
| tristan | took a moment | 10:18 |
| tristan | ironfoot, ummm, that failed... please reapply without using buildstream from it's setup.py | 10:24 |
| tristan | just shutils.which() directly (at some point *after* the python >= 3.5 check) | 10:24 |
| ironfoot | yep, I wondered if that was a bad idea or not | 10:24 |
| tristan | its generally a bad idea, and somehow caused tests to fail | 10:25 |
| tristan | hmmm, ok that's damn weird, how did ruamel not exist I dont know | 10:26 |
| ironfoot | """Successfully built 1 elements in pipeline with target 'build-essential/linux-api-headers.bst'""" | 10:29 |
| ironfoot | fix worked | 10:29 |
| tristan | yep | 10:30 |
| tristan | There is still a hidden bst bug under that to investigate | 10:30 |
| ironfoot | tests fail locally for me for another reason: https://paste.gnome.org/paw0fcs3a | 10:54 |
| * ironfoot digs | 10:54 | |
| tristan | tests have a race currently... did you run it twice in a row ? | 10:58 |
| * tristan inspects log | 10:58 | |
| tristan | ironfoot, hmmm, perhaps you've stumbled on our lower bound bwrap dependency ? | 10:59 |
| ironfoot | yes, twice, some minutes in between. | 10:59 |
| tristan | no usually I think only one fails, why did the sandbox tests pass the previous round ?? | 11:00 |
| tristan | and fail on the second ? | 11:00 |
| * tristan also normally runs with --addopts -x | 11:01 | |
| tristan | so maybe I only get to see the first error | 11:01 |
| ironfoot | I'll forget about the tests issue right now. Just trying to finish building build-essential | 11:23 |
| ironfoot | So, there is an issue I think I have to raise. If you see this status, "build-essential" says "cached" even though "gcc" failed : https://paste.gnome.org/pgehahrnx | 11:27 |
| ironfoot | I could see the same thing before, when ldconfig was failing to run, but missed the last line in the paste | 11:27 |
| ironfoot | which was like this: https://paste.gnome.org/ptu9uygxt | 11:28 |
| tristan | oh ? | 11:36 |
| tristan | hmm | 11:36 |
| tristan | gcc ? | 11:37 |
| tristan | ah | 11:37 |
| tristan | build-essential stack looks cached | 11:37 |
| tristan | ironfoot, right, thats related to the above hehe :) | 11:37 |
| tristan | <tristan> ironfoot, I added the integration commands after I built it seems, and I still have to add those to the cache keys | 11:38 |
| tristan | <tristan> that should be a good cut-off point for adding the cache key test | 11:38 |
| tristan | ironfoot, that ^^^ | 11:38 |
| tristan | I think, or is it | 11:38 |
| tristan | hmmm | 11:38 |
| tristan | maybe not, am I missing environments ? I shouldnt be | 11:38 |
| tristan | ironfoot, in the middle of other things :-/ I'll have to investigate... how did this occur ? | 11:40 |
| ironfoot | so, what I'm saying right now, is that build-essential is cached when it shouldn't be | 11:40 |
| tristan | ironfoot, that was... "build failure of HEAD^1 in build-essential" + "bst show of HEAD" ? | 11:41 |
| tristan | Right, I got that, it shouldnt be if it depends on something which needs to be built | 11:41 |
| ironfoot | that was, "build failure of HEAD^1 + bst show of HEAD^1" | 11:42 |
| ironfoot | to get: https://paste.gnome.org/ptu9uygxt | 11:42 |
| tristan | Ah | 11:42 |
| tristan | ironfoot, Ok then that is related to the second problem we encountered... notice that things kept trying to build after ldconfig fails | 11:43 |
| tristan | ironfoot, that probably means that a build-essential stack was actually assembled and cached (Which cant really fail) | 11:43 |
| tristan | at least, that's a very good working theory | 11:44 |
| tristan | I'll have to retry / debug with HEAD^1 of build-essential to fix the other issue | 11:44 |
| *** csoriano____ has joined #buildstream | 12:39 | |
| *** csoriano____ is now known as csoriano | 12:44 | |
| *** tristan has quit IRC | 13:07 | |
| *** tristan has joined #buildstream | 14:11 | |
| *** ChanServ sets mode: +o tristan | 14:12 | |
| *** jjardon has quit IRC | 14:41 | |
| *** tristan has quit IRC | 14:44 | |
| *** tristan has joined #buildstream | 14:47 | |
| *** tristan has quit IRC | 14:47 | |
| *** tristan has joined #buildstream | 14:48 | |
| *** ChanServ sets mode: +o tristan | 14:48 | |
| *** jjardon has joined #buildstream | 14:49 | |
| ironfoot | so, this is the problem I was having before with gcc: https://paste.gnome.org/pdeakqjsi | 15:21 |
| *** csoriano has quit IRC | 15:40 | |
| tristan | ironfoot, wat ?! | 15:55 |
| tristan | ironfoot, you mean it DIDNT compile ? | 15:55 |
| * ironfoot looks up from a hole | 15:55 | |
| ironfoot | yes, compilation problems. Something is missing somewhre | 15:56 |
| tristan | heh, deep in a config.log hole ? | 15:56 |
| tristan | ok did you try zapping ~/buildstream/artifacts and rebuilding ? not sure it would make a difference but after that bug earlier on, maybe something stale and incorrect in the cache ? | 15:56 |
| tristan | ironfoot, what can you tell me about the environment, it's an x86_64 host I take it ? | 15:57 |
| ironfoot | yes, my laptop, inside a docker container | 15:57 |
| tristan | Oh | 15:57 |
| tristan | no wait | 15:57 |
| tristan | Ok something is up, and I really dont understand why, but I'm sure I've solved this before | 15:58 |
| ironfoot | right, will try cleaning the artifacts | 15:58 |
| tristan | ironfoot, I let the build run and didnt look at the result, I have the failure here too | 15:58 |
| tristan | no no | 15:58 |
| tristan | you have the exact thing I have, dont waste your breathe :) | 15:58 |
| ironfoot | oh, well | 15:59 |
| ironfoot | I'm somehow happy :) | 15:59 |
| ironfoot | I've seen in some places the mention of "LD_LIBRARY_PATH" to fix the error | 16:00 |
| tristan | -> /buildstream/build/o/./gcc/cc1: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory | 16:01 |
| * tristan originally did build essential one chunk at a time | 16:01 | |
| tristan | and then possibly I changes smth and ended up breaking it :-/ | 16:01 |
| tristan | so... ldconfig runs before building gcc | 16:02 |
| tristan | but | 16:02 |
| tristan | is libz.so there, and... is the ld.so.conf listing the right directories | 16:02 |
| tristan | oh and, it's ldconfig from stage two, in /tools/sbin | 16:02 |
| tristan | so *that* ldconfig might not be configured to even use the same ld.so.cache | 16:03 |
| ironfoot | so, PATH should put /tools at the end? | 16:03 |
| tristan | nah | 16:03 |
| tristan | hold on | 16:03 |
| tristan | ironfoot, maybe yeah :) | 16:05 |
| tristan | heh | 16:05 |
| tristan | ironfoot, yeah you're right it must be | 16:06 |
| * tristan just compared the baserock build-essential, it should be the same | 16:06 | |
| tristan | ironfoot, I think one difference is that ybd does '/sbin/ldconfig' while we trust PATH | 16:06 |
| tristan | ironfoot, of course a goal is that build-essential has as little differences from baserock as possible (just a goal to ensure migrations generally run smoothly) | 16:08 |
| * tristan is running another build with tools on the other end of the PATH | 16:08 | |
| * tristan thinks its a really bad time to be 'sleeping at the wheel' while working on another project for the week... but that project is important too :) | 16:09 | |
| ironfoot | I'm trying a build using LD_LIBRARY_PATH, to see what happens | 16:10 |
| ironfoot | but I think that makes sense to have /tools at the end in stage3 things | 16:11 |
| tristan | that might help but I'd rather it didnt, my build is also running... | 16:11 |
| * tristan hopes the path fixes it just cause it's same as baserock | 16:12 | |
| tristan | yep | 16:12 |
| tristan | ironfoot, that fixed | 16:12 |
| tristan | path | 16:12 |
| ironfoot | kewl | 16:12 |
| tristan | good catch :) | 16:12 |
| ironfoot | took me a while to see anything in that log | 16:13 |
| tristan | yeah well, it's gcc that has multi configures, and you dont get to see what happens without opening config.log in the build sandbox | 16:13 |
| * tristan also has to add that useful line pointing to the build directory | 16:13 | |
| tristan | but, had not added it yet, also; I wanted to automatically pause stuff and `bst shell` into the broken build dir | 16:14 |
| tristan | all easy stuff to do... that I didnt do yet :-S | 16:14 |
| ironfoot | yay, LD_LIBRARY_PATH works too. Meaning that I know something else today :) | 16:18 |
| ironfoot | s/know/learnt/ | 16:19 |
| tristan | yeah it would, however I'm uncertain about what the result is after that | 16:19 |
| tristan | i.e. the linked gcc binary, where will it expect to find libz.so | 16:19 |
| ironfoot | yeah, some errors in build-essential won't be visible until we try to build more things on top | 16:19 |
| tristan | probably works either way, so long as there is no -rpath actually | 16:19 |
| ironfoot | are you already working on a script to import from definitions.git? | 16:46 |
| tristan | ironfoot, I started it before yeah but got interrupted | 17:38 |
| tristan | ironfoot, let me push a work in progress, but it's really in progress heh | 17:39 |
| tristan | ironfoot, https://gitlab.com/tristanvb/defs2bst | 17:41 |
| tristan | it reads the output of ybd for a given target and walks that, but it's only got the flow basically, the meat needs to be filled in | 17:42 |
| *** ssam2 has quit IRC | 18:54 | |
| *** tristan has quit IRC | 20:50 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!