gitlab-br-bot | marge-bot123 merged MR !1249 (chandan/remove-manifest-conftest->master: MANIFEST.in: Remove conftest.py include) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1249 | 00:00 |
---|---|---|
gitlab-br-bot | cs-shadow approved MR !1247 (bschubert/better-pytest-report->master: tests: when comparing lists/dicts, compare all at once) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1247 | 00:01 |
*** swick has joined #buildstream | 02:04 | |
*** tristan has joined #buildstream | 02:57 | |
*** kaiz has joined #buildstream | 05:06 | |
*** mohan43u has joined #buildstream | 05:54 | |
*** nimish2711 has quit IRC | 06:07 | |
*** nimish2711 has joined #buildstream | 06:11 | |
*** nimish2711 has quit IRC | 06:26 | |
*** nimish2711 has joined #buildstream | 06:49 | |
*** mohan43u has quit IRC | 06:55 | |
*** mohan43u has joined #buildstream | 06:58 | |
*** mohan43u has quit IRC | 07:05 | |
*** mohan43u has joined #buildstream | 07:09 | |
*** mohan43u has quit IRC | 07:23 | |
*** mohan43u has joined #buildstream | 07:27 | |
*** mohan43u has quit IRC | 07:31 | |
*** nimish2711 has quit IRC | 07:32 | |
*** mohan43u has joined #buildstream | 07:34 | |
*** mohan43u has quit IRC | 07:38 | |
*** mohan43u has joined #buildstream | 07:40 | |
*** nimish2711 has joined #buildstream | 07:46 | |
*** toscalix has joined #buildstream | 08:35 | |
*** mohan43u has quit IRC | 08:39 | |
*** mohan43u has joined #buildstream | 08:40 | |
*** nimish2711 has quit IRC | 08:54 | |
gitlab-br-bot | juergbi approved MR !1248 (bschubert/lint/logging-format->master: casserver.py: fix logging-format-interpolation error and enable) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1248 | 09:00 |
*** nimish2711 has joined #buildstream | 09:00 | |
*** mohan43u has quit IRC | 09:02 | |
*** mohan43u has joined #buildstream | 09:05 | |
*** mohan43u has quit IRC | 09:10 | |
*** nimish2711 has quit IRC | 09:11 | |
benschubert | Hey tristan , juergbi would you have time to look at https://gitlab.com/BuildStream/buildstream/merge_requests/1070#note_152634508 ? I'll have some time today to finish it, so we could have it go thtough | 09:12 |
juergbi | benschubert: I already gave my 👍️ | 09:13 |
benschubert | juergbi: oh, my bad, thanks! | 09:13 |
benschubert | I'll wait for tristan before finalizing then, thanks a lot! | 09:13 |
juergbi | gitlab doesn't notify about that, so might not have been ieal | 09:13 |
*** mohan43u has joined #buildstream | 09:13 | |
benschubert | juergbi: oh by the way, I'm have a system that takes roughly 10 times more time to push than to pull + build. I'm pushing to 4 caches. Any rough idea where I should look to start diagnosing the slowness? | 09:24 |
juergbi | benschubert: hm, the CAS server supports batch upload, right? | 09:25 |
juergbi | bst-artifact-server does, but would have to check for buildgrid CAS server | 09:25 |
benschubert | juergbi: the cas server is the server bundled in the buildstream codebase | 09:26 |
juergbi | ok, that should be fine, then, assuming it's not ancient | 09:26 |
benschubert | it's from two weeks ago roughly | 09:26 |
benschubert | btw I like the new numbers on https://gitlab.com/BuildStream/buildstream/merge_requests/1070 :) | 09:27 |
gitlab-br-bot | juergbi approved MR !1247 (bschubert/better-pytest-report->master: tests: when comparing lists/dicts, compare all at once) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1247 | 09:28 |
juergbi | benschubert: yes, noticed them as well. so the simpler version is actually faster, at least in the (strict) test case? | 09:28 |
benschubert | juergbi: it is! | 09:28 |
juergbi | hooray for simplicity :) | 09:29 |
mablanch | juergbi: Any chance you could have a look at this (and merge if it looks good for you) when you'll have time: https://gitlab.com/BuildStream/buildstream/merge_requests/1239? | 09:30 |
juergbi | sure, will take a look | 09:32 |
*** raoul has joined #buildstream | 09:32 | |
benschubert | mablanch: does that mean we can easily spawn runners with docker-compose and get a full RE running? | 09:32 |
benschubert | The biggest publicly available project using BuildStream is Gnome right? I'd be interested in running some benchmarks more realistic than what we have in bst-benchmarks :) | 09:33 |
mablanch | benschubert: Compose greatly help yes. If you want to run some tests manually and scale the number of runners/workers, there is a Compose manifest for BuildStream and usage instructions here: https://gitlab.com/BuildGrid/buildgrid.hub.docker.com | 09:35 |
benschubert | mablanch: great thanks! Do you know if it's possible to have a remote cache just by changing the url, or is there gotchas? | 09:36 |
mablanch | benschubert: You mean a separate artifact cache server, or a totally separate CAS server for the remote execution service? | 09:38 |
benschubert | mablanch: I mean the action cache and the cas server (using the buildgrid ones, but just on another machine :) ) | 09:39 |
*** tristan has quit IRC | 09:43 | |
*** mohan43u has quit IRC | 09:46 | |
mablanch | benschubert: You'd have to change the worker configuration: they need access to that server. Guess we could provide a separate Compose manifest relying on a remote CAS+AC, that shouldn't be difficult. Feel free to open an issue against that repo. | 09:47 |
gitlab-br-bot | tpollard approved MR !1246 (pointswaves/softreset->master: Added doc's for workspace reset --soft) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1246 | 09:47 |
benschubert | mablanch: sure I'll have a play with this and see what I can do or not. Thanks! | 09:48 |
*** mohan43u has joined #buildstream | 09:50 | |
*** jonathanmaw has joined #buildstream | 09:51 | |
*** mohan43u has quit IRC | 09:53 | |
*** mohan43u has joined #buildstream | 09:57 | |
*** tristan has joined #buildstream | 09:59 | |
gitlab-br-bot | marge-bot123 merged MR !1248 (bschubert/lint/logging-format->master: casserver.py: fix logging-format-interpolation error and enable) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1248 | 10:03 |
gitlab-br-bot | aevri approved MR !1247 (bschubert/better-pytest-report->master: tests: when comparing lists/dicts, compare all at once) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1247 | 10:13 |
gitlab-br-bot | BenjaminSchubert opened MR !1250 (bschubert/lint/cyclic-import->master: lint: Fix or silence 'cyclic-import' errors and enable pylint for it) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1250 | 10:18 |
*** nimish2711 has joined #buildstream | 10:20 | |
*** ChanServ sets mode: +o tristan | 10:25 | |
tristan | benschubert, I started resolving discussions but then unresolved them, they said the lines changed in a recent diff but as you might be holding on to the discussions as a todo list I unresolved them | 10:25 |
benschubert | tristan: ok, I'll go through them at the end, thanks! It's indeed a nice todo, given how many things are in there | 10:26 |
tristan | I like the class method instead of _plugin_lookup() :) | 10:27 |
benschubert | tristan: great! I wasn't sure you would like it, but it does make things cleaner :) | 10:28 |
tristan | Hmmm | 10:29 |
benschubert | ? | 10:30 |
tristan | I do dislike exposing the _unique_id directly as an instance variable | 10:30 |
benschubert | why? | 10:30 |
tristan | generally having _get_foo() accessors both makes it clear that you are going through a properly policed accessor (as opposed to @property things), and basically also guarantees (as much as possible) that no externals will ever muck about with the Plugin owned variable | 10:31 |
tristan | We had incidents too, with the artifact cache size variable being exposed and then external modules poking around and actually modifying it without even a mutator | 10:32 |
tristan | If we can get to a place where nothing is exposed directly on instances, would be nice even | 10:32 |
benschubert | For the accessor, that's true for other languages, the style guides in python are pretty much against that, especially since it has a runtime cost | 10:33 |
benschubert | The second part is more worrying, but we have tests and code reviews | 10:33 |
tristan | Our style guide pretty intentionally goes against pythons in this regard | 10:33 |
tristan | Cant python optimize this away ? | 10:33 |
tristan | when doing it's .pyc files ? | 10:34 |
benschubert | No, I could well be modifying this function and do something else instead at runtime. So you can't change that | 10:34 |
tristan | Thats something that we should be able to disallow as well | 10:34 |
tristan | We only allow overriding methods which are specifically advertised to be abstract/overridable | 10:35 |
benschubert | tristan: we can disallow this in the styleguide, the interpreter doesn't has this knowledge | 10:35 |
benschubert | And if the choice is between going through the get() method or having Element have their own unique_id, I'd rather go for the memory hit and have two different ids :) | 10:35 |
tristan | We need that guarantee that people wont go haphazardly overriding methods that the parent class doesnt expect | 10:35 |
tristan | I did go looking for a way to disallow it, it can be possible but would require some custom decorator | 10:36 |
benschubert | tristan: agreed, as we need the guarantee that people go through a modifier function to modify anything on an another class :) | 10:36 |
juergbi | I guess pylint can't help us here? | 10:36 |
benschubert | juergbi: it could, would require writing our own plugin | 10:36 |
tristan | (i.e. a way for disallowing methods being overridden where they are not advertized to be abstract/overridable) | 10:37 |
benschubert | juergbi: we could have two linter configuration, one for not changing another class attribute, one for not overriding a method | 10:37 |
tristan | Right linting in both cases would be preferable | 10:37 |
benschubert | tristan: if you are happy with having custom linter plugins for this, I'm happy to try something (not doing it for nothing since it's kinda annoying to work with) | 10:38 |
*** lachlan has joined #buildstream | 10:39 | |
tristan | I would, I would love to go through all the classes and decorate only the ones which are intended to be overridable | 10:39 |
tristan | (only the methods) | 10:40 |
* tristan not typing very well today | 10:40 | |
tristan | english broken | 10:40 |
benschubert | tristan: let's discuss this afterwards then, I think that would be nice indeed. And let's focus on 1070 for now ok? That way we could be able to finish it today | 10:40 |
tristan | benschubert, Alright, lets keep it the way it is with exposed _plugin_id variable then | 10:42 |
benschubert | ok great | 10:42 |
benschubert | I'll move the PQ in types, update its doc to make it private, and add the doc to the new _lookup method. Then cleanup the history | 10:43 |
*** mohan43u has quit IRC | 10:43 | |
tristan | When doing the other linting things, we can rethink our style guide around these parts https://docs.buildstream.build/CONTRIBUTING.html#instance-variables, and then we'll want to make things consistent as much as possible | 10:43 |
benschubert | tristan: btw this new version is already a tad faster on 88 builders | 10:43 |
benschubert | *8 not 88 | 10:43 |
tristan | https://docs.buildstream.build/CONTRIBUTING.html#abstract-methods also mentions about abstract method policy, we can update that pointing to a new decorator | 10:44 |
benschubert | tristan: so access through variable, mutation through method, correct? (with a linter that makes sure that it works) | 10:44 |
tristan | I dont think we can really have that policy | 10:45 |
tristan | across the board | 10:45 |
tristan | it makes sense for some things, but in other cases it makes sense to trigger code in response to accessing something | 10:45 |
tristan | lazy resolution of things, etc | 10:45 |
benschubert | absolutely, but that is where properties are great :) | 10:45 |
tristan | What I dont like about properties is that we dont know on the caller side that a method is being invoked or not | 10:46 |
tristan | benschubert, anyway I think this is a conversation for another day | 10:46 |
benschubert | sure! | 10:47 |
benschubert | I'll start with the abstract method first :) | 10:47 |
tristan | lets start by wrapping up !1070 :) | 10:47 |
gitlab-br-bot | MR !1070: WIP: Refactor _update_state() to be called only when needed https://gitlab.com/BuildStream/buildstream/merge_requests/1070 | 10:47 |
* tristan will backport that and csoriano's checkouts should work again | 10:48 | |
tristan | valentind, is there anything else that needs fixing in 1.2.5, asides from #919 ? | 10:50 |
gitlab-br-bot | Issue #919: 'bst build <elem>' does not assemble all required elements in some circumstances https://gitlab.com/BuildStream/buildstream/issues/919 | 10:50 |
tristan | adds68, jjardon same ^^^ ? | 10:50 |
valentind | tristan, not to my knowledge | 10:50 |
* tristan doesnt think so either | 10:50 | |
valentind | Something unrelated, tristan, is there a way to tell buildstream what shell interpreter to use to run build commands? I do not think there is. But I might have missed something. | 10:51 |
valentind | Because not being able to use extglob in bash for example is annoying. | 10:52 |
valentind | Or subshell redirections. | 10:52 |
tristan | valentind, Not really unfortunately | 10:53 |
tristan | valentind, That is decided by BuildElement at least; not in the base classes | 10:53 |
valentind | I thought it was hardcoded in the sanbox. | 10:54 |
tristan | commands listed in build elements are hard coded to be executed with 'sh', -c command | 10:54 |
tristan | gah | 10:54 |
tristan | 'sh', '-c', 'command' + '\n' | 10:55 |
tristan | valentind, no at least not that | 10:55 |
valentind | I see it. | 10:55 |
tristan | valentind, We can run whatever program with, e.g. `bst shell`, I think that is well regression tested too :) | 10:55 |
valentind | scriptelement also has it. | 10:55 |
tristan | yep, that's what they're doing | 10:55 |
tristan | valentind, You could workaround with a custom `sh` and adjusting PATH I suppose | 10:56 |
tristan | but seems like good material to file an issue about | 10:56 |
valentind | When bash is called as sh it disables a lot of things. | 10:56 |
valentind | So we cannot use symlinks for that. | 10:57 |
tristan | maybe something openended without a specific solution, just 'currently with build elements there is no way to control what shell to use' | 10:57 |
benschubert | For that I would even go further and say "we need a shell to build, we should be able to specify what to call", because some programs don't need to be in a shell :) | 10:58 |
valentind | Yes. | 10:58 |
tristan | valentind, I think it's the sane default, though - ideally we want to coerce people into writing valid posix shell that'll still work with most interpretors | 10:58 |
abderrahim[m] | Jjj | 10:58 |
valentind | And who knows. Maybe masochists want to use powershell. They should be able to. | 10:58 |
tristan | Yeah, rpm for instance allows specifying the interpretor for it's pre/post things | 10:59 |
tristan | And if we have similar support in BuildStream, it makes the job of automating conversions of rpm based build stack into .bst files easier | 10:59 |
tristan | *stacks | 11:00 |
tristan | seems like also a masochistic thing to do, but we've seen it before ;-) | 11:00 |
benschubert | valentind: or python, python is a very nice shell to use :) | 11:00 |
*** lachlan has quit IRC | 11:02 | |
valentind | node.js XD | 11:02 |
valentind | tristan, should it be a variable which value we split with shlex.split? | 11:06 |
valentind | It is also in element.py for integration commands. | 11:09 |
tristan | err shlex, I recall not being happy about using shlex | 11:09 |
tristan | valentind, ah yes, but specifically for integration commands at least, it's intentionally not *too* deeply entrenched | 11:09 |
valentind | We need somehow to transform a string to an argv | 11:10 |
*** lachlan has joined #buildstream | 11:10 | |
tristan | valentind, I don't like that idea | 11:10 |
tristan | I would rather not presume to know how it's done for a given string and quoting style, or to trust a library to know how | 11:10 |
tristan | better to never know | 11:10 |
valentind | Well, if we put shlex.quote(cmd) in the command, we know for sure that shlex.split will know how to get back the right string. | 11:14 |
*** alatiera has joined #buildstream | 11:14 | |
valentind | We could also have our own quote and unquote algorithm. | 11:16 |
valentind | And document it. | 11:17 |
tristan | Ugh, that snuck back in grep reveals :-S | 11:19 |
tristan | valentind, Better to just use explicit yaml | 11:19 |
tristan | and not mess with the strings the user feeds to the shells | 11:19 |
*** lachlan has quit IRC | 11:20 | |
*** lachlan has joined #buildstream | 11:21 | |
gitlab-br-bot | marge-bot123 merged MR !1246 (pointswaves/softreset->master: Added doc's for workspace reset --soft) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1246 | 11:24 |
benschubert | juergbi, tristan !1070 has been pushed. I think we are good to go, mind having a last look? | 11:24 |
gitlab-br-bot | MR !1070: WIP: Refactor _update_state() to be called only when needed https://gitlab.com/BuildStream/buildstream/merge_requests/1070 | 11:24 |
gitlab-br-bot | BenjaminSchubert opened (was WIP) MR !1070 (bschubert/pipeline->master: Refactor _update_state() to be called only when needed) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1070 | 11:24 |
*** lachlan has quit IRC | 11:28 | |
gitlab-br-bot | juergbi approved MR !1070 (bschubert/pipeline->master: Refactor _update_state() to be called only when needed) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1070 | 11:28 |
benschubert | tristan: about https://gitlab.com/BuildStream/buildstream/merge_requests/1070/diffs#note_152850346, is this really an assert statement we want? Or a real concrete exception (asserts can be disabled at runtime, exception not) | 11:36 |
*** mohan43u has joined #buildstream | 11:44 | |
*** lachlan has joined #buildstream | 11:47 | |
*** lachlan has quit IRC | 11:54 | |
*** lachlan has joined #buildstream | 12:06 | |
*** lachlan has quit IRC | 12:14 | |
gitlab-br-bot | martinblanchard opened issue #968 (Use GitLab CI services instead of Compose for rexec testing) on buildstream https://gitlab.com/BuildStream/buildstream/issues/968 | 12:33 |
*** raoul has quit IRC | 12:34 | |
*** lachlan has joined #buildstream | 12:42 | |
*** nimish2711 has quit IRC | 12:51 | |
tristan | benschubert, Hmmm, this is an interesting distinction | 12:52 |
tristan | one I was not really aware of | 12:52 |
tristan | benschubert, Right now we only have 2 categories of error; (A) Fatal errors which get reported to the user (B) Programming errors which are caught with exceptions | 12:53 |
tristan | (A) is all of the exceptions which derive from BstError | 12:54 |
tristan | benschubert, that particular assert definitely is a programming error / bug if it hits, so we definitely want a stack trace if it ever hits | 12:54 |
tristan | oh sorry, correction to the above: (B) Programming errors which are caught with assertions | 12:55 |
tristan | So we usually use assert statements for anything that is not a fatal error that should be reported intelligibly to the user | 12:55 |
tristan | Now the question is, should we instead use exceptions in some cases, splitting (B) into two separate categories | 12:56 |
tristan | benschubert, For right now, we definitely want an assert; if we want to change that policy I think we should think about that and possibly change the codebase if we do decide on changing that | 12:57 |
tristan | I suppose that if you disable asserts at runtime, that means you are very confident that your code has no bugs | 12:58 |
tristan | in which case I think the current policy is okay right ? | 12:58 |
tristan | benschubert, for the specific line, I would have raised AssertionError() because it's just nicer than doing `assert False, "message"` | 12:59 |
*** nimish2711 has joined #buildstream | 13:01 | |
benschubert | tristan: in order to keep the exact same behavior, it would be: if __debug__: raise AssertionError(message). Would that be ok? | 13:04 |
tristan | Eh, I think I prefer assert False :) | 13:05 |
tristan | heh | 13:05 |
benschubert | and the reason to remove the assertion is that in "python world" they are often used for debugging purposes, and thus removing them at runtime should still work (Like when you compile with gcc -O{2,3}) | 13:05 |
benschubert | So not necessarily that you are confident ;) | 13:06 |
benschubert | ok I will change this, thanks | 13:06 |
tristan | benschubert, I think that right now we dont use it like this anyway - but it might an interesting distinction to make if for example; we were to assert valid arguments in all function entry points | 13:07 |
benschubert | agreed | 13:08 |
tristan | then we might introduce a raw Bug() exception to use instead of the currently existing assertions | 13:08 |
*** alatiera_ has joined #buildstream | 13:08 | |
*** alatiera has quit IRC | 13:08 | |
*** alatiera_ is now known as alatiera | 13:09 | |
gitlab-br-bot | juergbi approved MR !1238 (raoul/source-key-fix->master: Source key fix) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1238 | 13:21 |
csoriano | hey, for the soc projects at https://wiki.gnome.org/Outreach/SummerOfCode/2019/Ideas have you decided who are going to be the mentors? We would need that relatively soon | 13:31 |
csoriano | also, for the idea of Buildstream integration with Builder, have you checked with Christian Hergert? | 13:31 |
tristan | csoriano, We had a few talks yes, but it's still a bit hazy to me | 13:35 |
*** raoul has joined #buildstream | 13:35 | |
tristan | We had a long discussion at GUADEC which mostly covered implementation details but I think I'm missing a big picture here | 13:35 |
tristan | also, note that adds68 is working on a BuildStream plugin for Builder right now | 13:35 |
csoriano | that is for Builder? | 13:35 |
tristan | Right, we had discussion at GUADEC in a Builder hackfest about how to integrate BuildStream as a plugin | 13:36 |
csoriano | ok, we would just need an ack from Christian that the gsoc project for that is okay | 13:36 |
csoriano | could you (or the potential mentor) contact him and let me know? | 13:36 |
benschubert | tristan: also is !1250 in line with what you had in mind about cyclic imports? | 13:52 |
gitlab-br-bot | MR !1250: lint: Fix or silence 'cyclic-import' errors and enable pylint for it https://gitlab.com/BuildStream/buildstream/merge_requests/1250 | 13:52 |
tristan | csoriano, Ok I'll put it on my list... I don't know if we have a mentor | 13:53 |
tristan | csoriano, i.e. any discussions we ever had were about the actual work, not about a gsoc project | 13:54 |
csoriano | tristan: ah I see... well now there are two gsoc projects (which is nice), iirc it was added by jjardon after I proposed to him the idea of doing gsoc from the Buildstream team | 13:55 |
tristan | Ah, there are certainly conversations which happen that I'm not privy to | 13:56 |
tristan | Which is nice :) | 13:56 |
tristan | jjardon, any idea about the above ? have an idea for a mentor for a gsoc project ? | 13:57 |
* tristan wonders just how time consuming mentoring is, and wouldnt want to volunteer unless he was really certain that he could provide enough attention | 13:58 | |
csoriano | tristan: 5h per week min | 14:16 |
csoriano | it's not a small commitment, but also it becomes part of the work once they start doing MR etc. After all, reviewing MRs and such is something we do every day... | 14:16 |
tristan | Right, but I would certainly want to be able to spend enough 1:1 time | 14:23 |
*** lachlan has quit IRC | 14:52 | |
gitlab-br-bot | marge-bot123 closed issue #703 (Queues do too much work during scheduling) on buildstream https://gitlab.com/BuildStream/buildstream/issues/703 | 14:55 |
gitlab-br-bot | marge-bot123 merged MR !1070 (bschubert/pipeline->master: Refactor _update_state() to be called only when needed) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1070 | 14:55 |
*** lachlan has joined #buildstream | 14:56 | |
*** tristan has quit IRC | 14:57 | |
*** lachlan has quit IRC | 15:03 | |
*** lachlan has joined #buildstream | 15:06 | |
*** lachlan has quit IRC | 15:22 | |
*** lachlan has joined #buildstream | 15:30 | |
*** tristan has joined #buildstream | 15:39 | |
jjardon | tristan: those ideas were put there in a hurry (you were pinged in IRC before I put them); we need to decide if we go ahead with them, change them or not do them at all because lack of mentor time | 15:48 |
*** ChanServ sets mode: +o tristan | 15:49 | |
tristan | jjardon, yup, was quite a while back I think... still it would be nice if someone wants to mentor and has the time :) | 15:49 |
*** lachlan has quit IRC | 15:55 | |
gitlab-br-bot | marge-bot123 merged MR !1245 (aevri/dirname_basename->master: tests: str(datafiles) instead of a longer thing) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1245 | 15:56 |
*** alatiera has quit IRC | 16:05 | |
benschubert | tristan: !1177 can be closed now correct? | 16:11 |
gitlab-br-bot | MR !1177: WIP: tests/frontend/workspace.py: Test that all elements build with workspace in play https://gitlab.com/BuildStream/buildstream/merge_requests/1177 | 16:11 |
*** lachlan has joined #buildstream | 16:14 | |
*** lachlan has quit IRC | 16:20 | |
*** lachlan has joined #buildstream | 16:34 | |
gitlab-br-bot | marge-bot123 merged MR !1227 (aevri/you_only_write_once->master: cleanupjob, cascache: don't write cache size twice) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1227 | 16:37 |
gitlab-br-bot | aevri closed issue #957 (Race on temporary file in .cache/buildstream/cas/) on buildstream https://gitlab.com/BuildStream/buildstream/issues/957 | 16:39 |
benschubert | \Is gnome the biggest public project using BuildStream? Is there anything bigger (I'm speaking junctions included) | 16:44 |
adds68 | benschubert, if what you mean by junctions included, is that they include freedesktop-sdk, then yes it is | 16:47 |
benschubert | adds68: Great, thanks! I'll be able to do some benchmarking then :) | 16:48 |
gitlab-br-bot | BenjaminSchubert opened MR !1253 (bschubert/fix-double-lookup->master: plugin.py: Don't make a double lookup in the plugin table to get one) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1253 | 16:50 |
benschubert | tristan: ^ what you had noticed on the previous MR | 16:50 |
*** mohan43u has quit IRC | 17:14 | |
gitlab-br-bot | jonathanmaw opened (was WIP) MR !1251 (jonathan/skip_schedule_attempt->master: Skip scheduling assembly when calculating cache key for staging junctions) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1251 | 17:23 |
gitlab-br-bot | marge-bot123 merged MR !1247 (bschubert/better-pytest-report->master: tests: when comparing lists/dicts, compare all at once) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1247 | 17:40 |
gitlab-br-bot | aevri opened issue #970 (bst artifact pull: 'artifact not found' is success) on buildstream https://gitlab.com/BuildStream/buildstream/issues/970 | 17:50 |
*** jonathanmaw has quit IRC | 17:54 | |
*** lachlan has quit IRC | 17:58 | |
*** toscalix has quit IRC | 17:58 | |
*** lachlan has joined #buildstream | 18:02 | |
*** tpollard has quit IRC | 18:05 | |
gitlab-br-bot | aevri approved MR !1253 (bschubert/fix-double-lookup->master: plugin.py: Don't make a double lookup in the plugin table to get one) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1253 | 18:31 |
*** alatiera has joined #buildstream | 18:32 | |
*** lachlan has quit IRC | 18:37 | |
*** raoul has quit IRC | 18:40 | |
*** nimish2711 has quit IRC | 19:07 | |
*** nimish2711 has joined #buildstream | 19:07 | |
gitlab-br-bot | marge-bot123 merged MR !1238 (raoul/source-key-fix->master: Source key fix) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1238 | 19:11 |
*** rdale has quit IRC | 19:40 | |
*** nimish2711 has quit IRC | 19:59 | |
*** alatiera has quit IRC | 22:52 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!