| *** ssssam[m] has joined #buildstream | 00:11 | |
| *** mattiasb has joined #buildstream | 00:20 | |
| *** waltervargas[m] has joined #buildstream | 00:52 | |
| *** ptomato[m] has joined #buildstream | 01:39 | |
| *** m_22[m] has joined #buildstream | 01:42 | |
| *** inigomartinez has joined #buildstream | 01:47 | |
| *** albfan[m] has joined #buildstream | 01:47 | |
| *** kailueke[m] has joined #buildstream | 02:07 | |
| *** jjardon[m] has joined #buildstream | 02:15 | |
| *** theawless[m] has joined #buildstream | 02:59 | |
| *** asingh_[m] has joined #buildstream | 03:08 | |
| *** rafaelff[m] has joined #buildstream | 03:50 | |
| *** awacheux[m] has joined #buildstream | 04:30 | |
| *** alatiera has joined #buildstream | 04:34 | |
| *** segfault3[m] has joined #buildstream | 04:35 | |
| *** oknf[m] has joined #buildstream | 05:36 | |
| *** tristan has joined #buildstream | 06:05 | |
| *** connorshea[m] has joined #buildstream | 06:17 | |
| *** pro[m] has joined #buildstream | 06:20 | |
| albfan[m] | tristan: cannot open a bst shell using flatpak runtimes as deps, any trick for that? | 06:49 |
|---|---|---|
| tristan | albfan[m], can you show me the project in question ? | 07:16 |
| tristan | if you push a git repo somewhere I can probably tell you right away what's up | 07:16 |
| *** tristan has quit IRC | 07:18 | |
| *** tristan has joined #buildstream | 07:18 | |
| tristan | albfan[m], sorry lost network... minute... | 07:18 |
| tristan | albfan[m], yeah so buildstream-tests are definitely outdated... can I see what it is you "tried" ? | 07:20 |
| tristan | albfan[m], as I remember, for a while we were doing something dumb, like staging the platform AND the sdk | 07:20 |
| tristan | but only the sdk is needed | 07:20 |
| albfan[m] | tristan: I found it updated in https://gitlab.com/BuildStream/buildstream/commit/963098df8170185d367c8c7f3edceba5fc4c6e78 | 07:25 |
| albfan[m] | Just expected to be able to get into a shell and see how things are deployed, but lack of sh or bash (which I didn't understand) | 07:26 |
| tristan | hmmm | 07:39 |
| tristan | How can I see the tree at that commit :-S | 07:39 |
| tristan | "Browse Files" | 07:40 |
| tristan | Ok, so I know why | 07:41 |
| tristan | albfan[m], basically that is the dumb thing we were doing | 07:41 |
| tristan | albfan[m], in here https://gitlab.com/BuildStream/buildstream/tree/963098df8170185d367c8c7f3edceba5fc4c6e78/integration-tests/autotools-test/elements/dependencies | 07:41 |
| tristan | albfan[m], in there we are staging the platform at / and the sdk at /usr, that's wrong | 07:42 |
| tristan | albfan[m], there are a couple of reasons why this cannot work | 07:44 |
| tristan | One is, you dont have an element which runtime depends on those | 07:44 |
| tristan | albfan[m], if you create a simple 'stack' element which just depends on base-platform.bst and base-sdk.bst, that can work, but you wont have a /bin/sh | 07:45 |
| tristan | So you could do for instance: bst shell stack.bst -- /usr/bin/sh | 07:45 |
| tristan | that would work | 07:45 |
| tristan | albfan[m], the amhello.bst and amhello-run.bst in that directory intentionally only build depend on the runtimes | 07:45 |
| tristan | because in those tests, we wanted the output of a `bst checkout` to not include the huge runtimes | 07:46 |
| tristan | albfan[m], the *correct* way to do it though, is only with base-sdk.bst, and another element which creates symlinks /bin -> /usr/bin, /lib -> /usr/lib, /etc -> /usr/etc, and maybe /var -> /usr/var | 07:47 |
| tristan | albfan[m], note that in Flatpak, the SDK is a "superset" of the Platform, they are not "both" needed, you only need one or the other | 07:48 |
| tristan | also they only contain the content of /usr in the /files directory of the OSTree repo | 07:49 |
| tristan | albfan[m], notice we stage files/ content into usr/ this way: https://gitlab.com/BuildStream/buildstream/blob/963098df8170185d367c8c7f3edceba5fc4c6e78/integration-tests/autotools-test/elements/dependencies/base-sdk.bst#L14 | 07:49 |
| tristan | with the "import" element's configurations | 07:49 |
| tristan | source: files, target: usr | 07:50 |
| *** toscalix has joined #buildstream | 07:50 | |
| *** jonathanmaw has joined #buildstream | 08:09 | |
| albfan[m] | tristan: I see. Happy to be finally trying this. Afk now, will check as soon as possible | 08:09 |
| *** finn has joined #buildstream | 08:10 | |
| *** noisecell has joined #buildstream | 08:25 | |
| toscalix | tristan: available | 08:32 |
| toscalix | ? | 08:32 |
| tristan | yup | 08:34 |
| tlater | Argh, my scheduler reworking will need some changes to the frontend as well - we currently can't handle failed jobs that *don't* use the fancy prompt :| | 08:49 |
| *** bethw has joined #buildstream | 08:53 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 08:59 |
| finn | For the example, do we want the official alpine docker image, or the BST prepared Alpine image? | 09:03 |
| tlater | finn: Probably the official image, but would you remind me what the bst one is? | 09:04 |
| tlater | The one for the x86image plugin? | 09:04 |
| finn | aye | 09:04 |
| finn | just installs some dependencies | 09:05 |
| finn | https://gitlab.com/BuildStream/buildstream-docker-images/tree/master/image-tools | 09:05 |
| tlater | Yeah, I made that image specifically for another sample project, we thought it might end up useful for a handful of things, but it will probably be superseded by the freedesktop SDK. | 09:05 |
| *** jennis has joined #buildstream | 09:05 | |
| tlater | It's better to stick to the official image for a generic example :) | 09:06 |
| *** dominic has joined #buildstream | 09:19 | |
| tristan | juergbi, alright, I want to drop the bomb, are you ready ? | 10:01 |
| tristan | need help ? | 10:01 |
| * juergbi ducks | 10:01 | |
| juergbi | with rebasing and moving to the discussed approach? | 10:02 |
| tristan | juergbi, basically rebasing is not going to work | 10:03 |
| tristan | the dynamic queuing thing flies kind of directly in the face of what I wanted to do | 10:03 |
| juergbi | yes, I'll change the implementation to what we discussed | 10:03 |
| juergbi | should be fine | 10:03 |
| juergbi | first wanted to get CAS with push/pull in better shape, that shouldn't really conflict | 10:04 |
| tristan | I was thinking of a few things, one was that maybe the Queues themselves could be making the decisions, but then again having the Element tell it's dependencies they will need to be pulled-or-built sounds similar, and probably has a performance benefit | 10:05 |
| juergbi | the Queues don't know about dependencies, so I don't think that option would make sense at all | 10:06 |
| tristan | Well, the elements are essentially given to the scheduler/queues, so the Queues can call Element.dependencies(), but in any case that's not necessarily better (and involves more looping than necessary) | 10:08 |
| tristan | The other thing I was thinking was that if we really wanted dynamic Queueing, it would sit better if we had something to take ownership of all the build graph for the session, and have that register to events which occur, and then decide to requeue things | 10:10 |
| tristan | rather than having elements themselves actually call directly into their owners | 10:10 |
| tristan | that would require some kind of event callback notification boilerplate | 10:11 |
| tristan | I'm personally happy with an approach which has everything queued at once though | 10:11 |
| tristan | tlater, I have a question related to incremental workspace builds | 10:12 |
| tristan | tlater, Do we force the mtimes of files in the actual workspace ? and if we do, do you think there is a way we can avoid that ? | 10:13 |
| juergbi | tristan: the callback approach would be closer to what I have in my branch now, just avoiding that Element has to know about the pipeline | 10:14 |
| juergbi | however, I was planning to switch to the just queue everything and suspend possibly unneeded elements | 10:14 |
| tristan | juergbi, right, I was mentioning the callback approach as a possibility as you might prefer it, still I'm not sure what it would look like | 10:15 |
| tristan | i.e. it would be nice if we had something else do that work than Stream itself, I was thinking a decent candidate for handling those callbacks might be the potential QueueManager object tlater and I were discussion in relation to his changes | 10:16 |
| tristan | but again, I dont really have a huge preference, what I want is to keep roles clearly separated | 10:17 |
| tristan | Ok... lets drop the bomb then | 10:19 |
| tristan | in 3 | 10:21 |
| tristan | 2 | 10:21 |
| tristan | 1 | 10:21 |
| gitlab-br-bot | buildstream: merge request (tristan/pipeline-refactor->master: The mega pipeline refactor) #453 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/453 | 10:21 |
| jennis | haha "The mega pipeline refactor" | 10:23 |
| tristan | Yeah, that is very disruptive | 10:23 |
| tristan | but the world will be a better place | 10:23 |
| tlater | tristan: We change the mtimes of files in staged artifacts, not workspaces | 10:23 |
| tristan | tlater, excellent | 10:23 |
| tristan | tlater, I am thinking of changing workspace cache key calculation to use mtimes rather than checksums | 10:24 |
| tristan | juergbi, any thoughts about that ^^^ ? | 10:24 |
| 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 | 10:24 |
| juergbi | only mtime? | 10:24 |
| tristan | filename & mtime | 10:24 |
| tristan | s/checksum/mtime | 10:25 |
| juergbi | hm, that would be an extremely weak key, not sure what problems could arise | 10:25 |
| tristan | If we think about it practically, we dont share workspace builds, they are always local... when we open one... it is initially there | 10:25 |
| tristan | then, if something changes, the mtime should change | 10:25 |
| jmac | Why the change? Is it just for performance? | 10:26 |
| tristan | jmac, "just" is putting it very lightly I think | 10:26 |
| juergbi | I still think we should have VCS-optimized workspace checksums, in which case the other optimization would no longer be relevant | 10:26 |
| jmac | OK, is it only for performance? | 10:27 |
| * tlater wonders if it's worth the trade-off, considering there will only ever be a handful of open workspaces at a time | 10:27 | |
| tristan | jmac, yes it is... basically, it takes about 7 or 8 minutes currently to calculate the cache key of a workspace | 10:27 |
| jmac | That is a lot | 10:28 |
| tristan | when you consider a moderately sized workspace, like say webkit | 10:28 |
| tristan | So the question is more... if the rules of the game fit... why not use the mtime ? | 10:28 |
| tristan | That is the important part, "Do the rules of the game fit" ? | 10:28 |
| tristan | juergbi, any VCS-optimized approach is heuristics, that is the problem | 10:29 |
| tristan | juergbi, for instance... gnome-build-meta has WebKit as a tarball, but the user would want to open a workspace for WebKit using a git checkout | 10:29 |
| tristan | juergbi, BuildStream has no way of knowing that, yet the activity is a perfectly reasonable thing to do | 10:30 |
| jmac | It seems unlikely, but anyone using an odd file system which doesn't use mtimes properly | 10:30 |
| jmac | oops | 10:30 |
| jmac | ... an odd file system which doesn't use mtimes properly, or an automated process that modifies things quickly will have problems | 10:30 |
| tristan | So workspaces are really strictly local things... the question of the workspace cache key is mostly about identifying changed-ness | 10:31 |
| juergbi | tristan: ah, I didn't think of users using VCS workspaces with tarball sources. I understand the use case but that's pretty odd | 10:31 |
| tristan | juergbi, except it's not odd, it's actually a really natural choice | 10:32 |
| juergbi | in a way, yes, a workspace is essentially a replacement source | 10:33 |
| tristan | My preference is not to stray into heuristics | 10:33 |
| jmac | mtimes are also the way we currently determine which files have changed after a build; I don't really like that, but there is precedent | 10:33 |
| tristan | So yes, mtimes is weak, and it might not even be enough by itself, I will have to try it out and see honestly; but it seems to me a reasonable thing | 10:35 |
| tristan | filesystems acting weirdly is weird... if the file changes and the mtime doesnt, is also weird | 10:35 |
| jmac | Files can easily change without updating the mtime | 10:35 |
| tristan | Except it's a very regular contract | 10:36 |
| tristan | I.e. if you edit a .c file and fail to update it's mtime... you do *not* expect the .o file to be updated at `make` time | 10:36 |
| tristan | Which is *exactly* the use case here, coincidentally | 10:36 |
| jmac | Actually I do, I'd consider that a bug in make. | 10:37 |
| tristan | Hah | 10:37 |
| jmac | I regularly work on personal projects on which the edit->compile->test cycle can be less than a second | 10:38 |
| juergbi | we do have much finer precision these days, though | 10:38 |
| juergbi | that said, I also prefer the checksum approach | 10:38 |
| jmac | Ah, if you have sub-second precision on mtimes, than I have far less concern | 10:39 |
| juergbi | I assume that's accessible from Python and would definitively use that | 10:39 |
| tristan | sub-second precision should be a thing certainly | 10:40 |
| tristan | that said, if I can get the edit/compile/test cycle for a webkit workspace to be sub-second, I will be VERY happy about it :) | 10:40 |
| tristan | for anything buildstream, actually | 10:40 |
| tristan | I remain doubtful that it will be enough on it's own, though | 10:42 |
| tristan | Oh note: https://gitlab.com/BuildStream/buildstream/issues/392 | 10:42 |
| jmac | juergbi: It's possible to get subsecond precision with python's standard library, yes. Whether you will get them or not, I don't know | 10:42 |
| tristan | This is basically... we are checksumming the workspace of a failed build... because we want to print the cache keys which were discovered during the build | 10:43 |
| tristan | that is in fact wrong, but it is the same bug | 10:43 |
| * tlater wonders if there's any point trying to optimize things like pipeline aggregation in C | 10:44 | |
| tristan | https://gitlab.com/BuildStream/buildstream/issues/295 and https://gitlab.com/BuildStream/buildstream/issues/294 are all essentially the same bug | 10:44 |
| tlater | Seeing as buildstream is already difficult to install, the only trade-off would be having a little bit of ugly C code around. | 10:45 |
| * tristan clones https://github.com/WebKit/webkit to observe performance | 10:51 | |
| laurence | is there an official maintainer for the examples repo? jennis ? | 10:51 |
| laurence | and do we have the maintainers documented anywhere? | 10:51 |
| * tlater has sort of been acting as such, laurence | 10:52 | |
| tlater | We don't have a list yet | 10:52 |
| tristan | laurence, we do not, maintainers should be documented in their respective repos in the normal way in fact | 10:52 |
| tristan | i.e. in a doap file or just the old school MAINTAINERS file | 10:52 |
| laurence | tristan, ok, i'll get onto said maintainers then, make sure that's the case | 10:53 |
| laurence | tlater, thanks for the info | 10:53 |
| tristan | What is buildstream-examples for ? | 10:53 |
| tlater | tristan: It's the repository of not-quite-documentation example projects whose fate has been sort of afloat for a while now | 10:54 |
| jennis | tristan, currently it contains two projects | 10:54 |
| tristan | I see | 10:55 |
| tlater | jennis: I assume you've been working with it to see if it can fit in the documentation somehow? | 10:55 |
| tlater | It's possible we should just add a link to it in the documentation, warning that it may not be up-to-date | 10:55 |
| jennis | However, for finn's spin up on BuildStream, he's created an example that imports a fresh alpine image | 10:55 |
| tristan | I made a misguided comment about it a week or two ago, because I had confused it with buildstream-tests | 10:55 |
| jennis | So yes, the plan is to have our own examples integrated into the getting started section | 10:56 |
| jennis | Rather than use, say, a gnome-build-meta element as an example | 10:56 |
| * tlater will let tristan handle the discussion, but well, the problem is keeping the repository in lock-step with buildstream core | 10:56 | |
| tlater | So it's not suitable for including in docs. | 10:57 |
| tristan | Right, examples and getting started was different parts of the docs new world order as I recall | 10:57 |
| jennis | well, finn's example is definitely at the "getting started" level | 10:57 |
| tristan | Right, but we're confounding words here I think | 10:58 |
| jennis | However, other examples will be differnet parts, yes | 10:58 |
| jennis | different* | 10:58 |
| tristan | the view was to have a very short tutorial which teaches a few things, after reading that the user should be proficient at using the reference manual, while examples are stand alone things which outline specific use cases | 10:59 |
| tristan | former was what we called "Getting started" | 10:59 |
| jennis | yes this is the plan | 11:01 |
| jennis | We are yet to come up with any examples for specific use cases | 11:01 |
| tristan | One was raised by jjardon, which was "How do I override how an element is built in a subproject I depend on ?" | 11:02 |
| tristan | as a random example of an edge case | 11:02 |
| jennis | Ok yes, this will be in the latter section | 11:02 |
| finn | Is there any other basic functionality of bst you'd want to showcase in a simple example? | 11:07 |
| tlater | finn: I believe the simplest of examples should only bootstrap you into writing a building project. | 11:10 |
| tlater | Because that's sort of the first step at which you can say "hm, neat, this works, let's see what else I can do" | 11:11 |
| *** bethw has quit IRC | 11:45 | |
| gitlab-br-bot | buildstream: issue #393 ("Inconsistent "no reference" state shown for workspaced elements") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/393 | 12:19 |
| tristan | Well, using stat.st_mtime_ns instead of checksumming file content... brings the time to resolve the cache key for an 11GB webkit checkout down from 1:06 to 5 seconds | 12:32 |
| tristan | I guess that could be considered an improvement | 12:32 |
| tristan | second round was 0:54 seconds | 12:32 |
| tristan | I guess that is linux caching files in memory or smth | 12:33 |
| gitlab-br-bot | buildstream: merge request (tristan/optimize-workspace-keys->master: _workspaces.py: Use file mtime for workspace cache keys instead of checksumming) #455 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/455 | 12:39 |
| gitlab-br-bot | buildstream: merge request (benchmark->master: WIP: Benchmark) #136 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/136 | 12:41 |
| gitlab-br-bot | buildstream: merge request (debuggable->master: WIP: Make plugins debuggable with pdb etc.) #185 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/185 | 12:45 |
| tristan | juergbi, I wont push that just yet ^^^ want to marinate it and give it some thought... mcatanzaro will also give it a shot and test performance | 12:45 |
| tristan | i.e. tristan/optimize-workspace-keys | 12:45 |
| *** tristan has quit IRC | 12:51 | |
| *** bethw has joined #buildstream | 12:51 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 12:55 |
| *** xjuan has joined #buildstream | 13:14 | |
| gitlab-br-bot | buildstream: merge request (jennis/nest_workspaces_commands->master: Nest workspace commands in ToC) #456 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/456 | 13:23 |
| gitlab-br-bot | buildstream: merge request (jennis/nest_workspaces_commands->master: Nest workspace commands in ToC) #456 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/456 | 13:31 |
| *** xjuan has quit IRC | 13:45 | |
| *** sstriker has joined #buildstream | 13:59 | |
| *** sstriker has quit IRC | 14:10 | |
| *** xjuan has joined #buildstream | 14:40 | |
| jennis | tlater, upon reviewing finn's example, I've realised that we need the user to install bst-external for the docker plugin | 15:01 |
| tlater | jennis: Yes, that's probably not a good thing | 15:01 |
| tlater | Eventually we'll want to move to the freedesktop-sdk | 15:01 |
| jennis | However, installing bst-external to support this doesn't seem to be documented anywhere, I guess I expected it in the bst-docker repo | 15:02 |
| tlater | Which will hopefully be available as an ostree repo/tarball | 15:02 |
| jennis | So we are against documenting this? | 15:02 |
| tlater | I believe that it's going to be a while before freedesktop sdk is released. | 15:03 |
| tlater | And I certainly don't think we can introduce the docker plugin into buildstream core | 15:03 |
| tlater | Although it might not be a bad thing... | 15:03 |
| jennis | That sounds like we should mention this somewhere then | 15:03 |
| tlater | I think for the time being we'll need to do an installation of bst-external as part of finn's example, yes | 15:04 |
| tlater | Hrm, I dislike this | 15:04 |
| jennis | me too | 15:04 |
| jennis | but for the time being, it's relatively harmless, no? | 15:04 |
| finn | is there any other way around this? | 15:04 |
| tlater | The only alternative seems to be using the gnome sdk | 15:04 |
| finn | which is huge right? | 15:04 |
| tlater | Which we used to use, but it's huge | 15:04 |
| tlater | Yea | 15:04 |
| finn | nah | 15:04 |
| jennis | yeah, that defeats the point of our quick example | 15:05 |
| jennis | *quick-to-use | 15:05 |
| finn | tarball method? | 15:05 |
| tlater | Well, the sdk is ~2GB I believe | 15:05 |
| finn | though that would mean we'd need a local variabke | 15:05 |
| tlater | finn: I'm very against that | 15:05 |
| tlater | We can try to host alpine as a tarball | 15:05 |
| tlater | Perhaps they already host tarballs? Worth checking the details of their distro | 15:05 |
| tlater | If they don't, well, more thinking is required | 15:06 |
| tlater | Hrm, I think I actually like the idea of the docker plugin going into buildstream core | 15:07 |
| finn | I thought one of the problems with us hosting was license | 15:07 |
| tlater | The main problem is that I really don't know what licensing they use. I suspect it might be incompatible with buildstream because they do not use GPL code, but I can be wrong. | 15:08 |
| tlater | We could still host that externally, though | 15:08 |
| tlater | Certainly not a nice solution, but perhaps a stopgap | 15:08 |
| tlater | Alternatively we could try to promote the docker plugin, or accept the slightly more convoluted example for now. | 15:09 |
| tlater | finn: Check this https://alpinelinux.org/downloads/ | 15:10 |
| tlater | Looks like they *do* host sysroots | 15:10 |
| finn | currently looking | 15:10 |
| tlater | We can simply import one of those for the time being | 15:10 |
| tlater | You'll want to grab a "mini root filesystem" :) | 15:11 |
| tlater | I *think* there is no issue with including a link to that in a .bst file | 15:11 |
| tlater | But IANAL | 15:11 |
| finn | So you support .isos? | 15:11 |
| finn | Ah, mini is a tarball | 15:12 |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 15:12 |
| tlater | finn: For the record, we don't currently support isos | 15:13 |
| tlater | Might be interesting to write a plugin for that, though | 15:13 |
| finn | I didn't think so | 15:13 |
| finn | I'd clicked one of the others, didn't see mini at first | 15:13 |
| tlater | I suspect some distros won't release tarballs, so for those it could be handy to have an iso plugin | 15:14 |
| tlater | Might be quite hard to use/implement though | 15:14 |
| * tlater is thinking aloud beyond this particular example | 15:14 | |
| tlater | finn: Do you have a way to deal with people not using x86? | 15:15 |
| tlater | I guess for the tutorial you'll have to mention the alpine download page, telling the reader to grab the appropriate tarball. | 15:16 |
| tlater | Then link to the section of the docs that explains how to supply multiple architectures. | 15:16 |
| finn | I'll just get the user to replace the URL in the project | 15:24 |
| finn | I guess there isn't some kind of switch statement I can use for different architectures | 15:24 |
| tlater | finn: Yup, but I'd leave that out for the simple example project | 15:26 |
| finn | can you point me to an example of this? | 15:29 |
| finn | even if I don't add it | 15:29 |
| tlater | finn: I can do better than that and link you to the doc: https://buildstream.gitlab.io/buildstream/projectconf.html#architecture | 15:30 |
| tlater | :) | 15:30 |
| * tlater notes that there is a comprehensive list of built-in variables, too | 15:31 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 15:35 |
| finn | Are you sure I can't use this switch than get the person to manually edit? | 15:49 |
| tlater | You could, but I think that might be confusing for a very first time user | 15:50 |
| tlater | I don't have a particularly strong opinion though, if you think it's fine I don't mind. | 15:50 |
| tlater | Again though "Do I *need* to specify the arch when I used buildstream?" | 15:51 |
| 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:53 |
| finn | point taken | 15:54 |
| tlater | jennis: When you document the above issue, make sure you mention that buildstream does have a way to fix this, and that you can look it up <here> in a note or something | 16:04 |
| tlater | Just so that the user doesn't view it as a shortcoming :) | 16:05 |
| finn | Will do | 16:05 |
| * tlater still isn't sure who of you two works on documenting this | 16:05 | |
| finn | I'll update the README | 16:06 |
| finn | jennis will probably do the proper writeup which points to the gitlab | 16:06 |
| jennis | Sounds good to me | 16:06 |
| *** toscalix has quit IRC | 16:13 | |
| *** WSalmon has quit IRC | 16:14 | |
| 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 | 16:19 |
| *** bethw has quit IRC | 16:31 | |
| *** dominic has quit IRC | 16:49 | |
| *** jonathanmaw has quit IRC | 16:49 | |
| *** aday has joined #buildstream | 16:55 | |
| *** jennis has quit IRC | 16:55 | |
| 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 | 16:57 |
| *** bochecha_ has joined #buildstream | 17:34 | |
| *** xjuan has quit IRC | 18:03 | |
| *** bochecha_ has quit IRC | 18:26 | |
| *** xjuan has joined #buildstream | 18:47 | |
| gitlab-br-bot | buildstream: merge request (chandan/workspace-soft-reset->master: Add soft reset functionality for workspaces) #457 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/457 | 19:36 |
| *** bethw has joined #buildstream | 19:36 | |
| *** bethw has quit IRC | 19:52 | |
| *** jennis has joined #buildstream | 20:26 | |
| *** aday has quit IRC | 20:36 | |
| *** bethw has joined #buildstream | 20:51 | |
| *** bethw has quit IRC | 20:56 | |
| *** xjuan has quit IRC | 21:08 | |
| *** slaf has quit IRC | 22:28 | |
| *** slaf has joined #buildstream | 22:30 | |
| *** slaf has joined #buildstream | 22:30 | |
| *** slaf has joined #buildstream | 22:31 | |
| *** slaf has joined #buildstream | 22:31 | |
| *** slaf has joined #buildstream | 22:31 | |
| *** slaf has joined #buildstream | 22:31 | |
| *** slaf has joined #buildstream | 22:32 | |
| *** slaf has joined #buildstream | 22:32 | |
| *** slaf has joined #buildstream | 22:32 | |
| *** slaf has joined #buildstream | 22:32 | |
| *** slaf has joined #buildstream | 22:33 | |
| *** slaf has joined #buildstream | 22:33 | |
| *** slaf has joined #buildstream | 22:33 | |
| *** slaf has joined #buildstream | 22:33 | |
| *** slaf has joined #buildstream | 22:34 | |
| *** slaf has joined #buildstream | 22:34 | |
| *** slaf has joined #buildstream | 22:34 | |
| *** slaf has joined #buildstream | 22:35 | |
| *** slaf has joined #buildstream | 22:35 | |
| *** slaf has joined #buildstream | 22:35 | |
| *** slaf has joined #buildstream | 22:36 | |
| *** slaf has joined #buildstream | 22:36 | |
| *** slaf has joined #buildstream | 22:36 | |
| *** slaf has joined #buildstream | 22:36 | |
| *** slaf has joined #buildstream | 22:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!