| *** benbrown has quit IRC | 00:16 | |
| *** nexus has quit IRC | 00:16 | |
| *** paulsherwood has quit IRC | 00:16 | |
| *** nexus has joined #buildstream | 00:17 | |
| *** benbrown has joined #buildstream | 00:17 | |
| *** paulsherwood has joined #buildstream | 00:18 | |
| *** mcatanzaro has quit IRC | 01:31 | |
| *** saxa has quit IRC | 01:55 | |
| *** saxa has joined #buildstream | 01:58 | |
| *** mcatanzaro has joined #buildstream | 02:01 | |
| *** mcatanzaro has quit IRC | 02:34 | |
| *** el has joined #buildstream | 05:19 | |
| el | ARE YOU MAD THOSE NIGGERS ARE TRYING TO STOP TRUMP?? | 05:19 |
|---|---|---|
| el | EMERGENCY KKK AND NAZI COALITION MEETING IN #/JOIN | 05:19 |
| el | ON FREENODE IRC SERVER --IRC.FREENODE.NET-- | 05:19 |
| el | FREENODE IS AWARE OF THE GROUP AND SUPPORTIVE BUT PLEASE | 05:19 |
| el | DON'T COMPLAIN ON #FREENODE. | 05:19 |
| el | saxa paulsherwood benbrown nexus bochecha tiago WSalmon tpollard tristan juergbi ironfoot laurenceurhegyi tlater mattiasb jjardon[m] waltervargas[m] kailueke[m] cgmcintyre[m] pro[m] mrmcq2u[m] inigomartinez hergertme gitlab-br-bot adds68_ csoriano ptomato[m] persia brlogger | 05:19 |
| *** el has left #buildstream | 05:19 | |
| *** bochecha has quit IRC | 05:51 | |
| paulsherwood | hmmm | 07:23 |
| persia | ? | 07:28 |
| paulsherwood | the overnight spam | 07:42 |
| paulsherwood | i'd rather we didn't keep that kind of thing for posterity | 07:42 |
| paulsherwood | but once folks start tampering with historical records all bets are off :/ | 07:43 |
| persia | Indeed. There are no good choices for that sort of thing. I suppose the part I find strangest is the content of this one: this isn't freenode. | 07:45 |
| paulsherwood | heh :) | 07:47 |
| *** jude has joined #buildstream | 08:22 | |
| *** bochecha has joined #buildstream | 08:57 | |
| nexus | hmm...odd | 09:15 |
| *** ppp has joined #buildstream | 09:16 | |
| ppp | ARE YOU MAD THOSE NIGGERS ARE TRYING TO STOP TRUMP?? | 09:16 |
| ppp | EMERGENCY KKK AND NAZI COALITION MEETING IN #/JOIN | 09:16 |
| ppp | ON FREENODE IRC SERVER --IRC.FREENODE.NET-- | 09:16 |
| ppp | FREENODE IS AWARE OF THE GROUP AND SUPPORTIVE BUT PLEASE | 09:16 |
| ppp | DON'T COMPLAIN ON #FREENODE. | 09:17 |
| ppp | bochecha jude saxa paulsherwood benbrown nexus tiago WSalmon tpollard tristan juergbi | 09:17 |
| *** ppp has left #buildstream | 09:17 | |
| nexus | hmm | 09:22 |
| *** bethw has joined #buildstream | 09:35 | |
| *** ppp_ has joined #buildstream | 09:38 | |
| ppp_ | ARE YOU MAD THOSE NIGGERS ARE TRYING TO STOP TRUMP?? | 09:38 |
| ppp_ | EMERGENCY KKK AND NAZI COALITION MEETING IN #/JOIN | 09:38 |
| ppp_ | ON FREENODE IRC SERVER --IRC.FREENODE.NET-- | 09:38 |
| ppp_ | FREENODE IS AWARE OF THE GROUP AND SUPPORTIVE BUT PLEASE | 09:38 |
| ppp_ | DON'T COMPLAIN ON #FREENODE. | 09:38 |
| ppp_ | bethw bochecha jude saxa paulsherwood benbrown nexus tiago WSal | 09:39 |
| *** ppp_ has left #buildstream | 09:39 | |
| *** bochecha has quit IRC | 09:58 | |
| *** bochecha has joined #buildstream | 09:58 | |
| *** bochecha has quit IRC | 10:03 | |
| *** ssam2 has joined #buildstream | 10:07 | |
| ssam2 | i am still pretty confused by why my subprocesses are dying | 10:49 |
| ssam2 | it seems to be genuinely unrelated to the actual code that runs in the subprocesses | 10:50 |
| ssam2 | like, if the first thing I do is raise an exception, sometimes i don't see the exeption (but sometimes I do) | 10:50 |
| ssam2 | ah, no it's me being dumb again | 10:51 |
| ssam2 | argh, no it still doesn't make sense. it's so hard to debug this stuff | 10:53 |
| ssam2 | juergbi, out of interest what version of Python are you using when you see the tests passing ? | 10:54 |
| ssam2 | on the sam/multiple-caches branch | 10:55 |
| tlater | ssam2: Not sure how much this helps/if you already have it enabled, but there's an asyncio debug mode: https://docs.python.org/3/library/asyncio-dev.html#asyncio-debug-mode | 10:58 |
| ssam2 | this is multiprocessing, not asyncio | 10:58 |
| tlater | Ah, fair enough | 10:59 |
| ssam2 | not sure if asyncio would be a better choice in the long term... it'd require us to stop supporting python 3.4 though were we to use it | 10:59 |
| tlater | I don't think we *can* use it for anything but the schedulers, it seems that only one object can run at any time | 11:00 |
| ssam2 | that's my impression, it seems like it only supports single-threaded "async" behaviour | 11:01 |
| ssam2 | although i haven't got my head around it at all | 11:01 |
| tlater | When I ran into abruptly ending multiprocessing processes it turned out that python simply stopped before it finished running them - any chance this is happening to you? | 11:02 |
| ssam2 | i don't *think* so ... | 11:03 |
| ssam2 | no because the main process reports that they all died | 11:03 |
| *** tristan has quit IRC | 11:04 | |
| juergbi | ssam2: i'm on 3.6.3 | 11:06 |
| ssam2 | bah, same as me | 11:06 |
| juergbi | however, i've tested only your older branch (with my changes on top), not your latest branch yet | 11:06 |
| ssam2 | ah ok | 11:06 |
| juergbi | i can test your latest branch, if that helps | 11:06 |
| ssam2 | worth a try | 11:07 |
| gitlab-br-bot | buildstream: merge request (sam/multiple-caches->master: WIP: multiple remote cache support) #166 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/166 | 11:07 |
| ssam2 | i've just pushed my current version (which is hideously messy) | 11:07 |
| ssam2 | if you try: `python3 ./setup.py test --addopts '--capture=no -x tests/frontend/pull.py '` | 11:07 |
| ssam2 | it should fail in the test_push_pull[user-config] test, and with the following errors from the `bst push` invocation | 11:08 |
| ssam2 | Fetching artifact list from /home/shared/src/buildstream/tmp/test_push_pull_user_config_0/artifactshare/repo | 11:08 |
| ssam2 | Fetching artifact list from /tmp/share/user | 11:08 |
| ssam2 | Error loading pipeline: All processes died! | 11:08 |
| juergbi | it's hanging there right now | 11:09 |
| juergbi | that was without the latest push | 11:09 |
| ssam2 | ah right | 11:09 |
| ssam2 | with the latest version it wakes up from queue.get() once per second to check if all the subprocesses died while we were waiting | 11:10 |
| juergbi | yes, now they don't hang but fail. let me check the errors. | 11:12 |
| ssam2 | ah, i might have spotted the issue | 11:12 |
| ssam2 | the exception handler in the subprocess was only handling 2 kinds of exception | 11:12 |
| ssam2 | if I change it to catch all, I see: | 11:12 |
| ssam2 | Logging exception: g-io-error-quark: Invalid remote name file:///home/shared/src/buildstream/tmp/test_push_pull_user_config_0/artifactshare/repo (0) | 11:12 |
| ssam2 | although it still seems to fail to actually return that exception to the main process | 11:13 |
| juergbi | ah | 11:13 |
| tlater | Perhaps it doesn't because it's a glib error? I've seen warnings that they don't extend the default python exception objects. | 11:14 |
| ssam2 | it could be triggering some pygobject related issue, indeed | 11:15 |
| ssam2 | seems that errors from pygobject can't be pickled | 11:21 |
| ssam2 | that's probably why they aren't returned from the subprocesses | 11:21 |
| ssam2 | ok, it all starts to make sense | 11:21 |
| nexus | i've added the change to the OSTree README, as discussed yesterday https://github.com/knownexus/ostree | 11:21 |
| nexus | what should i say in my PR? | 11:22 |
| juergbi | ssam2: ah ok, we should probably catch them and convert them to something pickable then? | 11:24 |
| nexus | te change is here btw: https://github.com/knownexus/ostree#building let me know if you have suggestions on ways i should change it | 11:25 |
| ssam2 | looks OK, I could suggest changes but i can only speculate about what the actual ostree maintainers will want | 11:36 |
| ssam2 | the issue with the current instructions is that they can't actually be copied and pasted as-is, right ? | 11:37 |
| ssam2 | saying "building is the same as almost every autotools project" isn't enough for folk who don't know autotools | 11:37 |
| nexus | that's what was already there | 11:37 |
| ssam2 | whereas your change is something that can be done | 11:37 |
| ssam2 | exactlyu | 11:37 |
| ssam2 | *exactly | 11:37 |
| ssam2 | one issue is that you give environment variable settings, but you don't say what to do with them | 11:38 |
| ssam2 | so the reader already needs to know about what .profile or .bashrc is | 11:38 |
| ssam2 | which again, we shouldn't assume if we want these to be widely usable | 11:38 |
| nexus | true, but how do i cover every option in that case? | 11:38 |
| nexus | e.g. i use zsh | 11:38 |
| nexus | so the instructions wouldnt work | 11:39 |
| ssam2 | i don't know | 11:39 |
| nexus | :/ | 11:39 |
| ssam2 | perhaps just give an example for bash | 11:39 |
| tlater | Assume bash, anyone who uses zsh has to make these changes all the time anyway | 11:39 |
| ssam2 | if someone chooses to use zsh, we can assume they are fairly advanced | 11:39 |
| nexus | and mention that others might differ? | 11:39 |
| ssam2 | yeah | 11:39 |
| nexus | kk | 11:39 |
| ssam2 | https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local an "interesting" discussion of /opt vs /usr/local | 11:44 |
| * tlater wonders where the "interesting" part kicks in; people seem to generally agree for once | 11:47 | |
| nexus | tlater: isn't that interesting enough? xD | 11:47 |
| tlater | I suppose, but it isn't as fun to read ;P | 11:48 |
| * persia isn't sure how such a conversation can be complete without inclusion of NFS and reminding folk that in the old days, it was difficult to fit enough disks into a computer to hold what we might consider a full install today. | 11:49 | |
| *** cs_shadow has joined #buildstream | 12:02 | |
| * ssam2 reports https://bugzilla.gnome.org/show_bug.cgi?id=791265 | 12:53 | |
| jjardon[m] | Hi, can someone take a look at https://gitlab.com/BuildStream/buildstream/merge_requests/173 , please? | 13:07 |
| juergbi | jjardon[m]: commented. following the approach of the meson plugin, i would also go with make -C in the variables instead of inserting 'cd' commands, where possible | 13:22 |
| ssam2 | ugh, seems that the click CliRunner merges stdout and stderr together when getting the output of running bst .. | 13:24 |
| juergbi | oh, for output analysis that sounds wrong | 13:25 |
| ssam2 | yeah | 13:25 |
| ssam2 | the Result object just has an 'output' attribute | 13:26 |
| jjardon[m] | juergbi: thanks; seems cmake doesnt officially support what meson does, but happy to change the patch if we are ok with that | 13:26 |
| juergbi | jjardon[m]: can you elaborate? would we need to use functionality that is not officially supported? | 13:26 |
| juergbi | make -C should be equivalent to cd followed by make, no matter what kind of makefile cmake generates | 13:27 |
| juergbi | don't know whether there is an equivalent for the cmake command itself, but we could also use cd in the variable there, if necessary | 13:28 |
| jjardon[m] | sure, I meant the cmake part: seems cmake supports "cmake -BBuilddir -Hbuildsrc" but is not documented | 13:28 |
| juergbi | hm | 13:29 |
| ssam2 | https://github.com/pallets/click/issues/737 -- "Enable CliRunner to echo output to stdout/stderr" | 13:33 |
| ssam2 | no movement on this of course as Click is abandoned | 13:33 |
| ssam2 | wait, that's not the one I meant | 13:33 |
| ssam2 | https://github.com/pallets/click/issues/371 | 13:33 |
| ssam2 | 'Result object should have .stdout and .stderr in addition to .output' | 13:33 |
| tlater | My integration commands for an element including a linux element fail because it lacks /bin/sh, but I also include busybox which is supposed to provide that... Running bst checkout --no-integrate on it gives me a directory with a working /bin/sh, as expected. Any ideas? | 13:34 |
| ssam2 | note that an error like 'Not found: /bin/sh' can also mean that the ld.so that it requires was not found | 13:35 |
| tlater | Eugh. Well, that will probably be it then. | 13:36 |
| ssam2 | try: readelf -a /bin/sh|grep 'interpreter' | 13:37 |
| ssam2 | you should see something like: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] | 13:37 |
| ssam2 | if that file doesn't exist in the checkout, then there is your issue | 13:37 |
| tlater | Actually, no, the error is: bwrap: execvp sh: No such file or directory | 13:37 |
| ssam2 | might still be ld.so, not sure | 13:38 |
| tlater | Problem is I can't shell into the sysroot, so I can't check for that... | 13:38 |
| tlater | Hmm | 13:38 |
| ssam2 | readelf from your host will work on binaries inside the sysroot | 13:38 |
| ssam2 | unless it's a cross build | 13:38 |
| tlater | Alright, that seems to be the issue, ta ssam2... I'm guessing I'm missing that in some split rule | 13:41 |
| *** mcatanzaro has joined #buildstream | 14:01 | |
| gitlab-br-bot | buildstream: merge request (jjardon/cmake_build->master: buildstream/plugins/elements/cmake.yaml: Always create build folder) #173 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/173 | 14:19 |
| juergbi | jjardon[m]: thanks. given that the tests passed, i take it mkdir is not necessary with -B? | 15:36 |
| jjardon[m] | juergbi: it seems to be automatically generated, yes (I have tested myself here and everything seems to build fine) | 15:37 |
| juergbi | great, let's merge this | 15:37 |
| gitlab-br-bot | buildstream: merge request (jjardon/cmake_build->master: buildstream/plugins/elements/cmake.yaml: Always create build folder) #173 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/173 | 15:38 |
| jjardon[m] | juergbi: thanks! | 15:39 |
| *** bochecha has joined #buildstream | 15:56 | |
| *** tristan has joined #buildstream | 16:09 | |
| ssam2 | i'm /still/ having trouble with this concurrent repo initialization ... now ostree is claiming a remote doesn't exist when it does | 16:33 |
| ssam2 | it seems to cache them in memory in a hash table, so perhaps doing that is breaking something | 16:34 |
| ssam2 | i'm really strongly tempted to just do everything in the same process here; the code is just too fragile for me to be confident merging it or maintaining it | 16:34 |
| tlater | Why should this be done in multiple processes in the first place? | 16:35 |
| ssam2 | it was already done that way | 16:36 |
| ssam2 | i presume because fetching the list of refs is network-IO bound | 16:36 |
| tlater | Right, yeah, that makes sense | 16:36 |
| ssam2 | actually that doesn't make sense | 16:36 |
| ssam2 | because this dates from when there was only one cache, and we block waiting for the result | 16:36 |
| tlater | Why not? | 16:36 |
| tlater | It's probably still better not to block on network IO | 16:37 |
| tlater | Regardless of whether that made sense originally | 16:37 |
| ssam2 | unless it makes the code impossible to work with ... | 16:38 |
| ssam2 | also, i didn't profile this properly yet, but it seems to take us a while to marshall the list of refs between processes | 16:38 |
| ssam2 | I think that multiprocessing.Queue pickles everything it transfers, which is not actually very efficient | 16:38 |
| tlater | It does, that bit me at some point | 16:39 |
| ssam2 | so this optimisation only benefits folk who use multiple large caches across slow networks | 16:39 |
| juergbi | ssam2: might you actually be running into a ostree-level concurrency issue? | 16:39 |
| ssam2 | juergbi, yes I think so | 16:39 |
| juergbi | subprocess is required due to the (possibly) implicit libostree threading as discussed | 16:39 |
| ssam2 | as the remote definitely exists on disk, but in-process the OSTree code doesn't find it | 16:39 |
| juergbi | however, we could do everything in a single subprocess | 16:39 |
| ssam2 | surely initializing the remotes in the main process would be fine ? | 16:40 |
| juergbi | if it's a libostree operation, how can you be sure it doesn't use a background thread? | 16:40 |
| ssam2 | and seems less dangerous than mutating them concurrently in subprocesseses | 16:40 |
| ssam2 | true but this is all done during frontend init | 16:40 |
| ssam2 | so the task scheduler isn't running yet | 16:41 |
| juergbi | if the background thread properly terminates afterwards, it would probably not be an issue. but if it might hang around, fork is a bad idea | 16:41 |
| juergbi | which might be the case with thread pools | 16:41 |
| juergbi | i don't know too much about libostree internals, but they could do arbitrary things there. and might even add such potential issues in future versions | 16:41 |
| juergbi | i'd play it safe and serially spawn a separate subprocess for each remote | 16:42 |
| juergbi | or rather, multiprocessing process | 16:42 |
| ssam2 | hmm, ok | 16:42 |
| ssam2 | that seems like we get the worst of both worlds, but I'll see if it fixes this issue | 16:43 |
| juergbi | fork is very fast on Linux, so it shouldn't be a huge issue | 16:43 |
| ssam2 | yes, but returning a 10MB dict via pickle isn't fast | 16:44 |
| juergbi | you can also use a single subprocess if that doesn't make the code more complex | 16:44 |
| *** valentind has joined #buildstream | 16:44 | |
| ssam2 | the cache can contain a huge number of refs, and we query *all* of them | 16:44 |
| juergbi | true | 16:44 |
| juergbi | i don't really see another safe option, though | 16:45 |
| ssam2 | fair enough | 16:45 |
| juergbi | spawning ostree binary is safe even from the main process but i doubt this would help here | 16:45 |
| ssam2 | might be faster to json encode the dict and return that ... would need some proper profiling to see though | 16:46 |
| ssam2 | and profiling infra is still an (important) TODO | 16:46 |
| juergbi | i'm wondering whether we could somehow catch libraries that attempt to create a background thread in the main process | 16:46 |
| juergbi | so we could immediately abort | 16:47 |
| juergbi | that way we could also test for such issues, at least for a fixed libostree version | 16:47 |
| tristan | Is there a reason we dont use the cache key for ostree artifact extract directories ? | 16:48 |
| juergbi | could probably be done manually with gdb but not sure whether there is something reasonable we can do from within Python | 16:48 |
| juergbi | tristan: multiple cache keys can point to the same artifact | 16:49 |
| juergbi | (especially with non-strict mode) | 16:49 |
| tristan | juergbi, when there is a weak cache key in use, there is still a strong cache key, though | 16:49 |
| tristan | are we also showing weak cache key in the UI ? | 16:50 |
| juergbi | yes, they could still share the extract dir, though | 16:50 |
| * tristan wonders if that would make sense or not | 16:50 | |
| juergbi | i don't think we show that in the UI but not 100% sure | 16:51 |
| tristan | I dont understand, short of a cache key collision, how they can share the same dir; if the strong key is always used :-/ | 16:51 |
| juergbi | don't we use the commit ID for the extract dir? | 16:51 |
| tristan | I think that the actual weak key can (and should) remain opaque | 16:51 |
| tristan | (i.e. not in the UI) | 16:51 |
| tristan | we do something like that yes | 16:52 |
| tristan | we parse_rev() and use that | 16:52 |
| tristan | _ostree.checksum() | 16:52 |
| juergbi | right | 16:53 |
| tristan | it's just really confusing I guess | 16:53 |
| tristan | maybe I should add checkout --hardlinks | 16:53 |
| juergbi | if i'm not mistaken, we don't have the strict cache key during a non-strict build before we actually extract the artifact | 16:53 |
| juergbi | so we have to go by ostree rev | 16:53 |
| juergbi | as we don't want to create an extract directory with the weak cache key (as that doesn't uniquely point to an artifact) | 16:54 |
| tristan | If we dont have a strict cache key, they we know we dont yet have a strict cache key | 16:54 |
| tristan | so we simply cannot extract an artifact in that case | 16:55 |
| juergbi | if we're in non-strict mode and the artifact was already built, there is a strict cache key inside that artifact | 16:55 |
| juergbi | but we have to extract it to retrieve it | 16:55 |
| juergbi | the only unique id we can use for this extraction is the ostree rev | 16:55 |
| juergbi | we could also use a temp directory, of course, but that would result in re-extracting everything every time | 16:56 |
| juergbi | ssam2: btw: https://gitlab.com/BuildStream/buildstream/commit/21f546fa35eaefef2048918afa83b1f222d6839c | 16:56 |
| ssam2 | ah, thanks | 16:58 |
| ssam2 | starting subprocesses one after the other doesn't seem to fix this issue of disappearing remotes | 17:01 |
| ssam2 | i have somehow introduced yet another hang, too | 17:02 |
| ssam2 | or maybe its the same issue and its just random | 17:03 |
| tristan | If we add something for optimized checkout, which gives you files hardlinked to the local artifact cache; what would we call it ? | 17:05 |
| ssam2 | `checkout --hardlinks` ? would be nice if it contained the word 'unsafe' or 'readonly' somewhere, though | 17:07 |
| tristan | `bst checkout --hardlinks ...` ? | 17:07 |
| tristan | exactly what I was thinking | 17:07 |
| tristan | also, I was thinking that technically, it would be better to try os.rename() on the root directory | 17:07 |
| tristan | and then fall back to the regular hardlink-or-copy codepath | 17:08 |
| tristan | (but still in either case, it has hardlinks to the internal cache) | 17:08 |
| ssam2 | `bst checkout --internal-cache-links` ? | 17:08 |
| ssam2 | that sounds a bit more scary | 17:09 |
| juergbi | the (inverse) git clone option is called --no-hardlinks. however, there hardlinks are less dangerous | 17:09 |
| juergbi | it's really unfortunate that linux doesn't support immutable files (proper support, not the unusable chattr kind) | 17:10 |
| tristan | --impatient ? | 17:12 |
| tristan | `bst checkout --reckless ...` | 17:13 |
| juergbi | --no-warranty | 17:13 |
| paulsherwood | bst checkout --before-i-go-to-the-pub | 17:13 |
| bochecha | why is `OrderedDict()` printed when I `bst build`? | 17:16 |
| bochecha | that seems like a debug output someone forgot to remove before pushing? :P | 17:17 |
| tristan | oh ?? | 17:17 |
| tristan | bochecha, I'm not seeing that | 17:19 |
| tristan | any any particular time ? have a log ? | 17:19 |
| tristan | maybe it's plugin specific ? | 17:19 |
| bochecha | tristan: at the very beginning: https://paste.gnome.org/phqqukxf5 | 17:19 |
| bochecha | it's an autotools element | 17:20 |
| * tlater sees the same thing | 17:20 | |
| bochecha | I see it with pip elements as well | 17:20 |
| tlater | On the current docker image, at least | 17:20 |
| bochecha | I'm running BuildStream from fc96ff0 (I see there's one newer commit in master) | 17:21 |
| tristan | aha | 17:21 |
| * tlater will check his commit in a sec | 17:21 | |
| tristan | tlater, it will be the recent changes on making overlaps pretty | 17:21 |
| tristan | maybe it goes bonkers when there is no overlaps or something | 17:22 |
| tlater | On that note, they *are* pretty - helped me debug my image quite quickly | 17:22 |
| tlater | It prints that regardless of how many overlaps there are, btw | 17:22 |
| tristan | Also I think that should be warning, not info | 17:22 |
| bochecha | what are overlaps? | 17:23 |
| * bochecha hasn't looked into BuildStream for some time, coming back now | 17:23 | |
| tristan | haha ok I see it now | 17:23 |
| tlater | One of my elements prints: OrderedDict([(usr/bin/awk, [base/base-configure.bst, base/gawk.bst]), (usr/bin/ninja, [base/base-configure.bst, base/ninja.bst])]) | 17:23 |
| tlater | bochecha: Two elements might contain the same files - you could, for example, try to overwrite /usr/bin/ninja on your base system with one you freshly build as part of your pipeline. | 17:25 |
| * tristan is removing the .info() line | 17:25 | |
| tlater | buildstream figures out when you do that and tells you so you don't do it on accident | 17:25 |
| bochecha | tlater: neat | 17:26 |
| *** valentind has quit IRC | 17:29 | |
| *** valentind has joined #buildstream | 17:29 | |
| ssam2 | doing all the repo init in the main process definitely fixes this issue of the list of repos being wrong | 17:36 |
| ssam2 | list of remotes, ratherh | 17:36 |
| ssam2 | *rather | 17:36 |
| ssam2 | of course, maybe it reintroduces hangs somewhere else | 17:36 |
| ssam2 | ok, alternatively if I call _ostree.configure_remote() both in the subprocess, and in the main process, then the issue goes away | 17:57 |
| ssam2 | that seems like the best option I guess | 17:57 |
| juergbi | hm | 18:00 |
| *** bethw has quit IRC | 18:33 | |
| *** ssam2 has quit IRC | 18:34 | |
| *** jude has quit IRC | 18:59 | |
| gitlab-br-bot | buildstream: merge request (sam/multiple-caches->master: WIP: multiple remote cache support) #166 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/166 | 19:04 |
| gitlab-br-bot | buildstream: merge request (sam/multiple-caches->master: WIP: multiple remote cache support) #166 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/166 | 19:08 |
| *** tiago has quit IRC | 19:15 | |
| *** xjuan has joined #buildstream | 19:21 | |
| *** bethw has joined #buildstream | 19:25 | |
| gitlab-br-bot | buildstream: merge request (checkout-hardlinks->master: Checkout hardlinks) #174 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/174 | 19:46 |
| gitlab-br-bot | buildstream: merge request (checkout-hardlinks->master: Checkout hardlinks) #174 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/174 | 19:49 |
| *** bethw has quit IRC | 19:51 | |
| *** tristan has quit IRC | 19:59 | |
| gitlab-br-bot | buildstream: issue #162 ("Add --unsafe option to bst checkout") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/162 | 21:00 |
| gitlab-br-bot | buildstream: merge request (checkout-hardlinks->master: Checkout hardlinks) #174 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/174 | 21:00 |
| *** xjuan has quit IRC | 21:33 | |
| *** valentind has quit IRC | 22:52 | |
| *** bochecha has quit IRC | 23:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!