| *** Prince781 has joined #buildstream | 02:28 | |
| *** Prince781 has quit IRC | 03:39 | |
| *** tristan has joined #buildstream | 04:42 | |
| *** mohan43u has joined #buildstream | 06:43 | |
| *** jonathanmaw has joined #buildstream | 07:46 | |
| *** toscalix has joined #buildstream | 07:53 | |
| *** tristan has quit IRC | 08:02 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/workspacedir_config->master: Add 'workspacedir' configuration.) #444 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/444 | 08:16 |
|---|---|---|
| *** bethw has joined #buildstream | 08:51 | |
| gitlab-br-bot | buildstream: merge request (juerg/no-remote-summaries->master: WIP: Drop use of OSTree summary files and dynamically plan build dependencies) #446 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/446 | 09:11 |
| *** tiago has quit IRC | 09:17 | |
| *** tiago has joined #buildstream | 09:40 | |
| *** aday has joined #buildstream | 09:46 | |
| jmac | juergbi: With regard to BST_VIRTUAL_DIRECTORY: anyone writing a new plugin without knowing about the virtual directory changes will be unaffected, right? They can still use get_directory | 10:03 |
| juergbi | jmac: yes. I'd rather have it the other way round but that's not really an option for compatibility reasons | 10:03 |
| jmac | and if they are aware of the changes, and choose to just use get_virtual_directory, that's fine, so I don't see what BST_VIRTUAL_DIRECTORY adds in that case | 10:03 |
| juergbi | the issue is when we no longer have a regular FS directory as backend of the virtual directory | 10:04 |
| juergbi | or are you suggesting to create that on demand? | 10:04 |
| jmac | No | 10:05 |
| juergbi | the old plugins can't be used for remote execution, e.g. | 10:05 |
| jmac | But if you use get_virtual_directory you shouldn't be able to see the underlying directory being used in any case | 10:05 |
| juergbi | right but the point of BST_VIRTUAL_DIRECTORY is that BuildStream core knows whether your plugin is compatible with purely virtual directories | 10:05 |
| juergbi | BuildStream core can't easily know at the start whether the plugins use get_directory() or get_virtual_directory() (or both) | 10:06 |
| juergbi | without that flag | 10:06 |
| jmac | Right, but does it need to? We can still provide a useful error message if you use get_directory and only have a CAS backend | 10:06 |
| jmac | The only thing I can think of that being useful for is providing a list of which plugins use get_directory | 10:07 |
| juergbi | an error message is not always sufficient, though | 10:08 |
| juergbi | the plan is that we'll always use the CAS backend, and prefer FUSE even for local execution | 10:08 |
| juergbi | however, we can't use CAS-backed FUSE with get_directory() plugins | 10:08 |
| juergbi | to avoid breaking existing projects/plugins, we have to fall back to non-FUSE for that | 10:08 |
| jmac | So you want to dynamically choose to use the CAS backend for some elements? | 10:08 |
| juergbi | I think we have to | 10:09 |
| jmac | Right, that was the bit I was missing. Thanks! | 10:09 |
| juergbi | How else can we cover backward compatibility? | 10:09 |
| juergbi | Unless we require opt-in on the project level | 10:09 |
| jmac | I thought it'd be set per-project | 10:09 |
| tlater | juergbi: Will we continue to support the TarCache for this purpose then? | 10:09 |
| juergbi | jmac: For remote execution it will be opt-in, however, I wasn't planning on requiring opt-in for local execution with CAS-backed FUSE | 10:10 |
| juergbi | tlater: no, CAS artifact cache can still be used with old plugins without FUSE | 10:10 |
| juergbi | they just can't profit from the FUSE on-demand staging | 10:10 |
| tlater | Alright, that makes more sense then :) | 10:10 |
| jmac | juergbi: Right, this makes sense now. | 10:11 |
| juergbi | Ok. If anyone can come up with a better compatibility story, I'm all ears, of course :) | 10:11 |
| juergbi | Instead of BST_VIRTUAL_DIRECTORY we could consider a more generic BST_PLUGIN_API_VERSION or something like that | 10:12 |
| juergbi | Don't know whether that would be better long term | 10:13 |
| jmac | No, I'm absolutely fine with BST_VIRTUAL_DIRECTORY | 10:14 |
| juergbi | jennis: You asked about the scheduling changes a few days ago, they are now in !446 | 10:14 |
| jennis | juergbi, thank you | 10:19 |
| gitlab-br-bot | buildstream: merge request (valentindavid/385_vte_notification->master: buildstream/_frontend/app.py: Notify VTE on failure in interactive mode.) #447 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/447 | 10:24 |
| gitlab-br-bot | buildstream: merge request (valentindavid/385_vte_notification->master: buildstream/_frontend/app.py: Notify VTE on failure in interactive mode.) #447 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/447 | 10:46 |
| *** persia has joined #buildstream | 11:06 | |
| *** awacheux has joined #buildstream | 11:16 | |
| *** bethw has quit IRC | 11:32 | |
| *** finn has quit IRC | 12:01 | |
| *** finn has joined #buildstream | 12:03 | |
| *** tristan has joined #buildstream | 12:24 | |
| juergbi | tristan: fyi: I've opened !446 which includes the dynamic planning. As expected it conflicts with your pipeline refactor branch, so I'd appreciate comments on the changes and then we'll have to decide how exactly to merge the two branches | 12:36 |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 12:41 |
| tristan | juergbi, ok so I ran into a wall... which maybe tlater can help me with | 12:46 |
| tristan | tlater, --except logic is broken, especially for tests/frontend/buildtrack.py | 12:47 |
| tristan | tlater, notice that Pipeline.remove_elements() accesses self.dependencies() and self.targets directly: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_pipeline.py#L504 | 12:47 |
| tristan | tlater, that means that... when you run `bst track --except baz.bst foo.bst bar.bst` ... the constructed tracking list is completely different than when you run `bst build --track foo.bst --track bar.bst --track-except baz.bst target.bst` | 12:49 |
| *** bethw has joined #buildstream | 12:49 | |
| tristan | I currently have a function: https://bpaste.net/show/090603dd3fc2 which doesnt pretend that "targets" is meaningful when I do the except algo, but I'm not sure the results are correct anymore | 12:50 |
| tlater | Alright, taking a look | 12:52 |
| * tlater has a meeting in a bit, might not have enough time :| | 12:54 | |
| tristan | juergbi, I'm taking a look now... made a comment but it's unrelated, lemme just look at the pipeline changes | 12:56 |
| juergbi | ta | 12:56 |
| tristan | woosh | 12:57 |
| tristan | self._first_non_track_queue is first thing I'm seeing | 12:57 |
| tristan | juergbi, I did something similar to your _run() function to remove the redundant scheduler runs... | 12:59 |
| tristan | still not a pushed change in my branch I know | 12:59 |
| juergbi | ah, I actually checked your branch whether you already fixed that... | 12:59 |
| tristan | Yeah I got stuck :-S | 13:00 |
| tristan | self._first_non_track_queue goes kind of against what I wanted to achieve, while I can see how that lets you reduce lines of code | 13:01 |
| *** finn_ has joined #buildstream | 13:01 | |
| tristan | I am kind of shooting for... a bit more verbose Stream.build(), Stream.fetch(), Stream.track() etc... the main session running things | 13:02 |
| *** finn has quit IRC | 13:02 | |
| *** finn_ is now known as finn | 13:02 | |
| tristan | Ummm, lemme push a hint at where this is going... although it's stuck in a state of flux | 13:02 |
| juergbi | tristan: it's not just to reduce lines of code, though, needed to know where to queue dynamically planned elements (build dependencies) | 13:07 |
| tristan | juergbi, I thought it was for how we separate where we add the track elements in bst build --track | 13:08 |
| juergbi | it makes things easier there as well, yes, but for dynamic planning it's essential (or something like it) | 13:09 |
| tristan | Hmmm | 13:09 |
| tristan | juergbi, so this is where I was going: https://gitlab.com/BuildStream/buildstream/blob/tristan/pipeline-refactor/buildstream/_stream.py#L263 | 13:10 |
| tristan | I only have `bst show` and `bst track` using the new pipeline loading stuff... notice in _pipeline.py I have some methods I've prefixed new_ ... so once I convert the higher level stuff, I will remove the old ones and then s/new_// | 13:11 |
| tristan | it's a process | 13:11 |
| tristan | juergbi, it *looks* however like what you have done there... lands fairly easily in my refactor before this change... i.e. I've separated Stream/Pipeline completely by that point but havent untangled the weird shit that pipeline is actually doing yet | 13:12 |
| tristan | like pretending that "there is only one list of targets", and that "except" means something different depending on the command | 13:13 |
| tristan | however, it's a bit of an ugly state of flux | 13:13 |
| tristan | Maybe I can clean it up, so that the only ugly part is that Stream.py still has init_pipeline()... then you could rebase on top of that... and I could continue with the hard part of making pipeline.py make sense after that | 13:14 |
| tristan | not sure, sounds ugly still | 13:15 |
| juergbi | (meeting) | 13:16 |
| Nexus | juergbi: How long is it looking for CAS caching to go through? | 13:22 |
| tristan | juergbi, I think that I can rebase on top of your patch instead btw, but I need to have a closer look at how it works | 13:22 |
| tristan | I dont think I can sort it out tonight | 13:22 |
| tristan | juergbi, fwiw, I was wondering also (asides from your dynamic scheduling), since the calling/queueing layer needs to explicitly schedule tracking... whether it should also have to explicitly schedule assembly | 13:24 |
| tristan | I wonder if that would be an equivalent but opposite approach than what you took for marking the elements as "queued" | 13:24 |
| tristan | (but havent looked deep enough, so I could totally be spewing nonsense here) | 13:25 |
| tristan | tlater, note that something I think is clearly wrong is this: https://gitlab.com/BuildStream/buildstream/blob/master/tests/frontend/buildtrack.py#L39 | 13:26 |
| tristan | tlater, here you say that "If we except 2.bst recursively, it should result in excepting 2.bst and 7.bst" | 13:26 |
| juergbi | tristan: with assembly you mean BuildQueue? or the combination of all non-track queues or...? | 13:26 |
| juergbi | I'm not very happy with 'first_non_track_queue' but at least it's descriptive ;) | 13:27 |
| tristan | tlater, looking at the graph you've constructed: https://gitlab.com/BuildStream/buildstream/blob/master/tests/frontend/buildtrack.py#L79 ... 2.bst clearly excepts 2.bst, 3.bst, 4.bst, 5.bst, 6.bst and 7.bst | 13:27 |
| juergbi | I'm wondering whether we should move a bit closer to two subpipelines, one for tracking, one for the rest | 13:27 |
| *** finn_ has joined #buildstream | 13:29 | |
| *** finn has quit IRC | 13:31 | |
| *** finn_ is now known as finn | 13:31 | |
| *** finn has quit IRC | 13:32 | |
| *** finn has joined #buildstream | 13:32 | |
| *** bethw has quit IRC | 13:36 | |
| tristan | juergbi, I'm not sure what that means... i.e. elements need to pass through tracking before pull & build etc | 13:40 |
| juergbi | tristan: they need to pass through tracking before pull and build, if they are tracked, yes | 13:41 |
| tristan | juergbi, maybe what you mean by "pipelines" on the other hand is "lists of elements" | 13:41 |
| tlater | tristan: It's not quite that clear | 13:41 |
| juergbi | however, besides supporting tracking of elements that we then don't build | 13:41 |
| *** finn has quit IRC | 13:41 | |
| tlater | Because you're building 0.bst | 13:41 |
| tlater | So, because you're not explicitly excepting 3.bst, it's still included | 13:42 |
| *** finn has joined #buildstream | 13:42 | |
| tlater | Because 0.bst depends on it | 13:42 |
| tristan | tlater, yes but you are saying "build 0.bst ... and track 2.bst except for 3.bst" | 13:42 |
| tristan | tlater, it seems to me entirely incorrect that the --except algorithm takes the build target(s) into consideration when calculating which elements to *track* | 13:42 |
| juergbi | tristan: I meant, besides supporting building of elements that we don't track, we may also want to support tracking of elements that we don't build (because they are unused build-only dependencies) | 13:42 |
| tristan | tlater, these are two entirely different selections happening | 13:43 |
| tristan | tlater, I refer/repeat the above for scrutiny: | 13:43 |
| tristan | <tristan> tlater, that means that... when you run `bst track --except baz.bst foo.bst bar.bst` ... the constructed tracking list is completely different than when you run `bst build --track foo.bst --track bar.bst --track-except baz.bst target.bst` | 13:43 |
| tristan | tlater, why should those two differ ? | 13:44 |
| tristan | juergbi, *yes* agree ... one might say: bst build foo.bst --track bar.bst --track baz.bst --track-except pony.bst | 13:44 |
| *** finn has quit IRC | 13:45 | |
| *** finn has joined #buildstream | 13:45 | |
| tristan | juergbi, now bar and pony might be dependencies of foo... but baz might be completely unrelated | 13:45 |
| *** finn has quit IRC | 13:45 | |
| *** finn has joined #buildstream | 13:45 | |
| tristan | juergbi, my refactor would allow that accidentally, which is why I wondered if we should explicitly be calling Element._schedule_assemble() like we do for Element._schedule_tracking() | 13:46 |
| tristan | (otherwise, I would filter out unrelated tracking targets to conform to current behavior, as that isn't a big deal) | 13:46 |
| tlater | tristan: I agree, that inconsistency annoys me now. | 13:46 |
| tlater | I don't quite remember why it was there in the first place | 13:46 |
| tlater | But it may just have been an accidental result of using 'Pipeline.target' | 13:47 |
| tlater | Perhaps that happened when we started allowing multiple targets? | 13:47 |
| tristan | tlater, yes, so I am in a predicament where it seems that instead of the test cases representing the desired behavior, and the code being made to conform, the test cases represent the ad-hoc behavior at the time | 13:47 |
| tristan | which is worrisome | 13:48 |
| juergbi | tristan: that could make sense, yes. although please note we already have _schedule_assemble() which is specifically for the build job (i.e., Element.assemble()) while we'd need a new method to cover the combination of pull+fetch+build | 13:48 |
| tristan | juergbi, indeed | 13:49 |
| tristan | juergbi, it might be more verbose, but consistency would be more valuable (if we find that it makes more sense) | 13:49 |
| tlater | I remember spending a lot of time thinking about what that tree should look like, but I certainly only considered it for `bst build` | 13:49 |
| tristan | juergbi, not convinced it's the right avenue, just throwing the idea out there | 13:49 |
| tristan | juergbi, note https://gitlab.com/BuildStream/buildstream/blob/tristan/pipeline-refactor/buildstream/_pipeline.py#L84 | 13:49 |
| gitlab-br-bot | buildstream: merge request (jmac/virtual_directories->master: WIP: Abstract directory class and filesystem-backed implementation) #445 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/445 | 13:49 |
| tristan | juergbi, with Pipeline.new_load(), I just load/resolve the groups of targets, and return groups of elements (redundancy allowed)... this allows Stream.build() to say: elements, track_elements, track_except_elements = Pipeline.new_load(targets, track_targets, track_except_targets) | 13:50 |
| tristan | Then we have 3 lists of elements which all point into the same loaded build graph | 13:51 |
| tristan | from where we go ahead and use planning features, except features, and other list manipulation features provided by Pipeline to decide what to do with elements and feed them into queues | 13:51 |
| tristan | *from there | 13:51 |
| *** finn has quit IRC | 13:52 | |
| tristan | tlater, that is very unfortunate | 13:52 |
| *** finn has joined #buildstream | 13:52 | |
| tristan | tlater, because right now, I currently need `bst track` to be correct, and make `bst build` behave the correct way | 13:52 |
| tlater | tristan: I *do* think that in that particular test case excluding "3.bst" would be an annoyance for the user | 13:53 |
| tlater | Because the user would only think about 0.bst, which clearly *includes* 3.bst | 13:53 |
| tristan | tlater, bst track does not have the potential to confound stuff, so it is the prime example... in fact this same test should be run with @pytest.parameterize() an extra time, such that we test the same tracking plans with both `bst track` and `bst build` | 13:53 |
| tristan | tlater, you are not excepting from the activity of building, you are only excepting from the activity of tracking | 13:54 |
| tlater | Even in that case - why would excluding 2.bst exclude 3.bst, which is clearly depended on by 0.bst? | 13:54 |
| tristan | tlater, lemme look again | 13:55 |
| tlater | I think the immediate dependencies by the target(s) should always be explicitly excluded. | 13:55 |
| tristan | tlater, ok so we're talking different things here... | 13:55 |
| tristan | tlater, *if* you did --track 0.bst --track-except 2.bst... I should agree with you | 13:56 |
| tristan | tlater, the way your test is constructed however... you are saying that "excepting 2.bst excepts only 2.bst and 7.bst" | 13:56 |
| tristan | later on in the test you do a subtraction of sorts | 13:56 |
| tristan | to derive what you actually expect to see in the test case | 13:57 |
| tlater | tristan: Which exact combination are we looking at, then? | 14:00 |
| tristan | that is a good question, if I fix one, a different one breaks | 14:01 |
| tristan | because I go ahead and separate them | 14:01 |
| tristan | so that tracking element selection is entirely cleanly separated from build target selection | 14:01 |
| tristan | tlater, I am trying to figure out what to do | 14:01 |
| tristan | tlater, are you telling me I am reading the test incorrectly ? | 14:02 |
| tlater | tristan: You seem to be interpreting what it does correctly | 14:02 |
| tristan | tlater, I am expecting that on line 162, where you say that "The result of excepting 2.bst is that 2.bst and 7.bst", is true regardless of what main target has been selected for tracking | 14:02 |
| tristan | maybe I need to change that so that it is more clear, and squash both parameterization into a single one with 4 parameters | 14:03 |
| tlater | Yeah, that might be better | 14:03 |
| tlater | The test case says "the result of excepting 2.bst is that 2.bst and 7.bst are not tracked" | 14:04 |
| tlater | I.e., if they weren't tracked in the first place, they still wouldn't be. But I don't think you'd expect anything else. | 14:04 |
| tristan | right, but that implies context | 14:04 |
| *** finn has quit IRC | 14:04 | |
| tristan | tlater, it implies that you have tracked 0.bst I think | 14:05 |
| *** finn has joined #buildstream | 14:05 | |
| tristan | I guess in that particular case, there is not much choice | 14:05 |
| *** finn has quit IRC | 14:05 | |
| tlater | tristan: Not necessarily. If you track 3.bst, for example, 2.bst and 7.bst are still not in the resulting set | 14:05 |
| *** finn has joined #buildstream | 14:05 | |
| tlater | If you track 3.bst and 2.bst simultaneously, 2.bst and 7.bst are not in the result | 14:05 |
| *** finn has quit IRC | 14:06 | |
| *** finn has joined #buildstream | 14:06 | |
| tlater | I'd expect that if I wrote another test case which just tracks 7.bst, that would actually break - but I'm not sure about that | 14:06 |
| tristan | if you track another element which depends on 2.bst and on 8.bst... and --track-except 2.bst, then 2-7.bst will not be tracked | 14:07 |
| tristan | even though the other element would otherwise track 2-8.bst without the except statement | 14:07 |
| tlater | Yeah, I think that's what is expected here | 14:08 |
| tlater | If there is inconsistency with `bst track`, I think `bst track` should be changed to follow this, instead | 14:08 |
| tristan | tlater, I prefer to change this to one parameterize... with (track_elements, except_elements, expected_tracked_element) | 14:08 |
| tlater | Definitely, the double parameterization makes this hard to think about | 14:09 |
| tristan | tlater, then I might put the whole thing into a separate parameterize... which does the whole thing with, or without build | 14:09 |
| * tlater thought it was nice to be able to test a lot without writing much, but this seems too unclear. | 14:09 | |
| tristan | i.e. one mode of testing is with build, the other is with plain track | 14:09 |
| tristan | ensuring that the semantics of tracking selection are the same | 14:09 |
| tlater | Yep, that sounds better - is there still a question about what the result of an exception should be? | 14:10 |
| tristan | tlater, what I'd like though; is for you to take a look at my interpretation of Pipeline.remove_elements() closely: https://bpaste.net/show/090603dd3fc2 | 14:10 |
| tristan | tlater, is there a question ? | 14:10 |
| tristan | tlater, I agree with 2.bst and 7.bst, *if* --track 0.bst was provided, or the other examples you provided | 14:11 |
| tlater | Ok :) | 14:11 |
| tlater | Hrm, I really would like to run that function to see its output | 14:12 |
| tlater | But I'll have a look through it for now | 14:12 |
| tristan | yeah I understand | 14:12 |
| tristan | tlater, I didnt modify any content, only removed the implicit relations to self.targets and self.dependencies() | 14:12 |
| tristan | tlater, note that self.new_dependencies() is the same as the old one, except takes a list of targets instead of assuming that a single list of targets exist | 14:13 |
| tristan | i.e. Pipeline becomes rather stateless | 14:13 |
| tlater | Yup, that makes sense | 14:14 |
| gitlab-br-bot | buildstream: merge request (juerg/non-strict-buildable->master: element.py: Fix buildable check in non-strict mode) #448 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/448 | 14:14 |
| *** finn has quit IRC | 14:15 | |
| tristan | tlater, pipeline-refactor has the function in case you want to get your hands dirty and try it out, but I didnt include my broken implementation of Stream.build() in it | 14:17 |
| tristan | https://bpaste.net/show/dde6fc02e9b1 that is my broken Stream.build() | 14:17 |
| tlater | Well, if I just except in the right spot I won't have to worry about that ;p | 14:18 |
| tristan | tlater, I expect you're too busy with other things anyway to get too deep, you've provided me with some thoughts of how to proceed with the test | 14:18 |
| * tlater probably shouldn't, yeah, I'll try and assert that the algorithm matches what the other one does in my mind | 14:19 | |
| tristan | note line 31 in the above paste, where I call Pipeline.except_elements() with 3 parameters | 14:19 |
| tristan | tlater, yeah that's just sort of what I was hoping for, some verification that... what I am trying to do makes sense :) | 14:19 |
| tristan | juergbi, I think what we're going to do is that we're going to land your changes ahead of my branch, to expedite remote cache expiry, and I will just deal with the nightmare on my side :) | 14:21 |
| tristan | juergbi, but give me some time tomorrow to look it over just a bit ;-) | 14:22 |
| juergbi | thanks | 14:22 |
| *** bethw has joined #buildstream | 14:22 | |
| gitlab-br-bot | buildstream: merge request (juerg/no-remote-summaries->master: Drop use of OSTree summary files and dynamically plan build dependencies) #446 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/446 | 14:23 |
| tlater | tristan: As far as I can tell there should be no difference between those two implementations | 14:34 |
| tlater | It also still matches what I had in my mind of what this looked like, so there should be no regressions | 14:34 |
| tlater | Unit tests would be really nice for this sort of thing, especially now that the pipeline is becoming stateless... | 14:35 |
| *** bochecha_ has joined #buildstream | 14:38 | |
| juergbi | Nexus: Sorry, forgot to answer your question. The goal is to have a full-featured/ready MR for CAS by mid of May | 14:44 |
| Nexus | ok thanks | 14:46 |
| gitlab-br-bot | buildstream: merge request (jmac/virtual_directories->master: WIP: Abstract directory class and filesystem-backed implementation) #445 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/445 | 15:06 |
| toscalix | is it the next planned release 1.1.4 or 1.2 ? | 15:09 |
| *** finn has joined #buildstream | 15:12 | |
| juergbi | toscalix: next development release is 1.1.4, next stable release is 1.2.0 (in September) | 15:14 |
| *** bochecha_ has quit IRC | 15:15 | |
| toscalix | thanks | 15:18 |
| jmac | juergbi: Do you know where I could find some better docs on Google CAS? I'm looking at https://github.com/googleapis/googleapis/blob/master/google/devtools/remoteexecution/v1test/remote_execution.proto, but it doesn't seem to be complete | 16:21 |
| *** dominic has quit IRC | 16:28 | |
| *** bochecha_ has joined #buildstream | 16:29 | |
| jmac | On closer inspection maybe the missing things are features you've proposed like symlinks | 16:40 |
| jmac | I'm not sure what directory.ParseFromString is meant to do, though | 16:40 |
| *** Prince781 has joined #buildstream | 16:40 | |
| *** bethw has quit IRC | 17:05 | |
| *** xjuan has joined #buildstream | 17:05 | |
| *** jonathanmaw has quit IRC | 17:05 | |
| *** toscalix has quit IRC | 17:33 | |
| *** bochecha_ has quit IRC | 17:52 | |
| *** aday has quit IRC | 17:53 | |
| *** Prince781 has quit IRC | 17:54 | |
| *** Prince781 has joined #buildstream | 18:02 | |
| *** tristan has quit IRC | 18:48 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/253_better_missing_variable_errors->master: Fix provenance in error message for undefined variables.) #449 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/449 | 18:48 |
| juergbi | jmac: for the symlink proposal, see https://docs.google.com/document/d/1gnOYszitgrLVet3sQk-TKGqIcpkkDsc6aw-izoo-d64/edit | 18:50 |
| juergbi | also mentioned here: https://docs.google.com/document/d/12c3oAPgedckLpue2yj0xGgJTEOyUm4mXWWBJ157J-8I/edit#heading=h.nhgmkgkf44t2 | 18:51 |
| juergbi | ParseFromString is a generic grpc method, see https://developers.google.com/protocol-buffers/docs/pythontutorial | 18:52 |
| juergbi | please note that `String` refers to a binary string, not a text/unicode string | 18:53 |
| juergbi | i.e., ParseFromString simply deserializes a protobuf message | 18:53 |
| *** xjuan has quit IRC | 20:11 | |
| *** Prince781 has quit IRC | 21:36 | |
| *** Prince781 has joined #buildstream | 22:21 | |
| *** Prince781 has quit IRC | 22:47 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!