| *** tristan has joined #buildstream | 03:22 | |
| *** ChanServ sets mode: +o tristan | 03:22 | |
| *** muelli has joined #buildstream | 04:33 | |
| *** muelli has quit IRC | 04:49 | |
| *** muelli has joined #buildstream | 06:42 | |
| tristan | juergbi, I've "fixed" the override / link element issue: https://gitlab.com/BuildStream/buildstream/-/merge_requests/2078 | 07:01 |
|---|---|---|
| tristan | Would be nice to get some feedback there | 07:01 |
| tristan | In quotes because, well... anyway it's certainly fixed, I wonder if it's a bit too large of a sledgehammer for the issue | 07:02 |
| tristan | I suppose complexity mileage will vary depending on (A) Number of links involved and (B) Number of overrides employed | 07:03 |
| tristan | With the loopiness, complexity will scale exponentially I suspect, but I'm not sure if it will in a very meaningful way | 07:03 |
| gitlab-br-bot | juergbi approved MR !2079 (bschubert/stricter-job-scheduler-separation->master: Ensure we are not calling methods with side effects on the element graph in jobs) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/2079 | 07:10 |
| juergbi | tristan: I'll try to get my head wrapped around this today | 07:12 |
| tristan | Thanks a lot | 07:13 |
| tristan | juergbi, it's possible that it can be expanded, e.g. the project declaring subprojects which are duplicate or internal might benefit too | 07:14 |
| tristan | ideally with the general approach of caching link resolution as much as possible, we should be able to really treat a link as interchangeable with an element in every scenario | 07:14 |
| * tristan has not completely [re]investigated the area of duplicates/internals and focused specifically on the overrides, but suspects we might have similar edge cases to handle there | 07:15 | |
| juergbi | will keep that in mind | 07:21 |
| *** tomaz has joined #buildstream | 08:00 | |
| *** benschubert has joined #buildstream | 08:31 | |
| *** tristan has quit IRC | 08:34 | |
| *** santi has joined #buildstream | 08:46 | |
| *** tristan has joined #buildstream | 09:04 | |
| *** ChanServ sets mode: +o tristan | 09:04 | |
| benschubert | tristan: hey! What's your plan around !2070? I'd like to have it in before I finish the tidying of the scheduler rewrite, as it will make it simpler to check for errors | 09:07 |
| gitlab-br-bot | MR !2070: Restore task element name / element name distinction in UI https://gitlab.com/BuildStream/buildstream/-/merge_requests/2070 | 09:07 |
| tristan | benschubert, I did !2078 in the meantime, whilst not being exactly sure what to do for testing it | 09:07 |
| gitlab-br-bot | MR !2078: Fix junction overrides to resolve links https://gitlab.com/BuildStream/buildstream/-/merge_requests/2078 | 09:07 |
| * benschubert adds 2078 to the review list | 09:08 | |
| tristan | benschubert, my conundrum about !2070, is that there is opportunity for plugins to issue messages in the master log where the "message issuing plugin" is not the "task plugin", but we don't have examples of this | 09:08 |
| tristan | actually, thanks for asking, that answers my question | 09:09 |
| tristan | to test it, I need only write a test plugin to do it | 09:09 |
| benschubert | for testing, I am leaning towards having a comparison with an 'expected' output and validating every log file ? if we can remove timestamps it should be repeatable :) | 09:09 |
| tristan | I noticed it can happen in other external plugins but not in the repo | 09:09 |
| benschubert | ah yeah :) that makes sense | 09:09 |
| tristan | So I would not go that far no, I am leaning towards a regex logline parser as is found in some other tests | 09:10 |
| tristan | i.e. logging is mostly UI, you don't want to have to update tests when UI changes | 09:10 |
| benschubert | Ok, if we manage to have solid regexes I'm happy with that too. I'd just like to be able to know for sure when I break the logs :0 | 09:11 |
| tristan | Basically we want to assert that "When a plugin logs a message, it is represented by the task element in the master log, and by the issuing element in the task specific log file" | 09:11 |
| tristan | benschubert, https://gitlab.com/BuildStream/buildstream/-/blob/master/tests/frontend/logging.py#L109 | 09:12 |
| tristan | for example | 09:12 |
| tristan | mine would ensure that at least the element name reflected for a given log line is the task element name in the master log, and the issuing element name in the task log | 09:13 |
| benschubert | that seems good | 09:13 |
| tristan | although the cache keys are also supposed to match, so it would be better to assert that too | 09:13 |
| tristan | I could do that I suppose by running a bst show first and collecting the expected cache key, without hard coding it (as it's not the cache key stability test in this case) | 09:14 |
| benschubert | yep that would work | 09:14 |
| tristan | Ok good, this gives me some crack fill... easy and fun work to fill the gaps for the week | 09:14 |
| benschubert | Once this is in, I'll rebase my branch and will be ready for an in depth review of the scheduler :) | 09:16 |
| tristan | I'll be ready :) | 09:16 |
| tristan | lets land this baby | 09:16 |
| benschubert | so that I can work on the second update of it x') | 09:17 |
| benschubert | but at least I should be able to make some more incremental changes after that | 09:18 |
| tristan | nope, so you can work on the plugin DX ! | 09:19 |
| benschubert | also, and catchup on the ML | 09:19 |
| benschubert | actually for the plugins DX, do you have a few minutes for me to bounce a workflow at you? :D | 09:19 |
| tristan | not now I'm afraid, my class starts in 10min | 09:20 |
| tristan | I mean, if it's really a few :) | 09:20 |
| tristan | then sure | 09:20 |
| benschubert | nah let's do that another time then :) | 09:20 |
| benschubert | Or I could shoot directly to the ML | 09:20 |
| * benschubert will try to squeeze that this week | 09:20 | |
| *** muelli has quit IRC | 10:24 | |
| *** muelli has joined #buildstream | 10:41 | |
| *** muelli has quit IRC | 11:07 | |
| benschubert | tristan: had a look at !2078. It seems good though I don't like the rampant complexity growing in the loader. No fix for that right now though | 11:34 |
| gitlab-br-bot | MR !2078: Fix junction overrides to resolve links https://gitlab.com/BuildStream/buildstream/-/merge_requests/2078 | 11:34 |
| gitlab-br-bot | BenjaminSchubert approved MR !2078 (tristan/fix-overriding-links->master: Fix junction overrides to resolve links) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/2078 | 11:34 |
| tristan | benschubert, any thoughts on the FIXME comment in Loader._expand_link() ? | 12:10 |
| tristan | it's a brain melter, I suspect I need to continue the loop for a safer bet, but I could leave the FIXME in and we'd have it there if we found corner cases which demanded that | 12:10 |
| benschubert | tristan: So, since the current version is correct, just (potentially) less efficient and less understandable, I'd keep the FIXME at least | 12:13 |
| benschubert | but we can probably think about a bigger loader rewrite later when we have more bandwidth and free brains? | 12:13 |
| tristan | I like this approach yes | 12:13 |
| benschubert | since I think it would anyways need a full on rethink when we've got some real time to dig in it | 12:14 |
| tristan | the complexity of the lookups looks intense to me, but only with the increase of link usage and override usage | 12:14 |
| benschubert | right | 12:15 |
| tristan | I may need to do similar for support of junction duplicates and internals, but that would be an extension that can reuse all of the same added code | 12:15 |
| gitlab-br-bot | marge-bot123 merged MR !2079 (bschubert/stricter-job-scheduler-separation->master: Ensure we are not calling methods with side effects on the element graph in jobs) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/2079 | 12:16 |
| benschubert | seems good | 12:17 |
| benschubert | ^^ is finally in, only the logging fix and tests left before my MR should be ready :D | 12:17 |
| *** tpollard has joined #buildstream | 12:20 | |
| tpollard | Hi, would it be possible for anyone (with required auth) to tell me how much storage we're using on the buildstream group container registry? | 12:21 |
| *** tristan has quit IRC | 12:22 | |
| tpollard | afaict there's no way to find it out from the public gui | 12:23 |
| gitlab-br-bot | tcanabrava opened issue #1402 (Buildstream should refuse to build if disk space is too low.) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1402 | 12:41 |
| tomaz | this is different from disk quota or artifact cache, my idea is that buildstream should tell me before the build process starts if I have enough space in disk for the run, instead of failing in the middle. | 12:47 |
| *** tristan has joined #buildstream | 12:52 | |
| *** ChanServ sets mode: +o tristan | 12:52 | |
| *** tristan has quit IRC | 12:53 | |
| *** tristan has joined #buildstream | 13:04 | |
| *** ChanServ sets mode: +o tristan | 13:04 | |
| *** tristan has quit IRC | 13:05 | |
| *** tristan has joined #buildstream | 13:05 | |
| *** ChanServ sets mode: +o tristan | 13:05 | |
| *** tristan has quit IRC | 13:06 | |
| tomaz | hm, tristan is having irc issues | 14:50 |
| tomaz | the `depends` list is also available on build time, or just `build-depends` ? | 16:02 |
| coldtom | depends: is both build and runtime dependencies | 16:04 |
| tomaz | coldtom: I'm having an issue on bst 1.6 then, I have a list of packages defined on `depends` but the configuration fails. if I move them to `build-depends`, configuration passes. | 16:05 |
| nanonyme | :o | 16:05 |
| juergbi | tomaz: how does the configuration fail? | 16:09 |
| tomaz | juergbi: "CMake: could not find SomethingConfig.cmake" - the Something is the element in depends: | 16:09 |
| tomaz | if I just move the element from depends to build depends, it passes. | 16:09 |
| juergbi | do you only have a single `depends:` list in that .bst file, not multiple? | 16:10 |
| tomaz | I have multiple, and on each run it complains about a different one. | 16:10 |
| tomaz | so I'm moving one by one to build depends | 16:11 |
| tomaz | (as soon as this thing builds I'll push to my branch and paste here the url) | 16:11 |
| * tomaz and the super hability to be hit by weird bugs. | 16:13 | |
| tomaz | this sed is bad: sed -i 's\/usr\/local/\%{install-root}/g' Makefile - any clever way to do this that I can't find? | 17:00 |
| tomaz | (ignore the missing / - if install-root contains `/` I don't know what to do to scape. | 17:02 |
| juergbi | tomaz: if we assume install-root doesn't contain any spaces, you could use sed -i 's /usr/local %{install-root} g' | 17:02 |
| juergbi | however, this seems like a fairly odd replacement. if this is an odd Makefile, no chance of fixing it upstream? | 17:03 |
| tomaz | juergbi: historycally they ignored patches for that. | 17:03 |
| juergbi | alternatively, patch Makefile via buildstream to support DESTDIR | 17:03 |
| juergbi | or use sed to replace it with $(DESTDIR) | 17:03 |
| tomaz | juergbi: you can see here: https://salsa.debian.org/debian/lmdb/-/tree/master/debian that debian patches it | 17:03 |
| tomaz | arch also patches | 17:03 |
| tomaz | KDE opened a patches for this I think around 5 times, all of them closed with NOTABUG | 17:04 |
| juergbi | tomaz: please note that prefix != install-root | 17:04 |
| juergbi | install-root is like DESTDIR | 17:04 |
| juergbi | so it should probably be %{prefix}, although this doesn't change anything else with regards to the sed issue | 17:05 |
| juergbi | tomaz: however, wouldn't prefix=%{prefix} as make flag work as well? | 17:06 |
| juergbi | or to be precise, as `make install` flag | 17:06 |
| tomaz | dunno, testing, sec. | 17:07 |
| tomaz | it did. | 17:14 |
| *** tpollard has quit IRC | 17:22 | |
| *** santi has quit IRC | 17:33 | |
| *** santi has joined #buildstream | 17:34 | |
| *** santi has quit IRC | 17:50 | |
| *** jward has joined #buildstream | 18:58 | |
| *** benschubert has quit IRC | 20:20 | |
| *** tomaz has quit IRC | 20:20 | |
| *** jjardon has quit IRC | 20:20 | |
| *** robjh has quit IRC | 20:20 | |
| *** dftxbs3e has quit IRC | 20:20 | |
| *** SotK has quit IRC | 20:20 | |
| *** hergertme has quit IRC | 20:20 | |
| *** mohan43u has quit IRC | 20:20 | |
| *** ironfoot has quit IRC | 20:20 | |
| *** coldtom has quit IRC | 20:20 | |
| *** milloni has quit IRC | 20:20 | |
| *** pointswaves has quit IRC | 20:20 | |
| *** douglaswinship has quit IRC | 20:20 | |
| *** WSalmon has quit IRC | 20:20 | |
| *** lantw44 has quit IRC | 20:20 | |
| *** nanonyme has quit IRC | 20:20 | |
| *** lchlan has quit IRC | 20:20 | |
| *** gitlab-br-bot has quit IRC | 20:20 | |
| *** juergbi has quit IRC | 20:20 | |
| *** bethw has quit IRC | 20:20 | |
| *** valentind has quit IRC | 20:20 | |
| *** philn has quit IRC | 20:20 | |
| *** benbrown_ has quit IRC | 20:20 | |
| *** douglaswinship has joined #buildstream | 20:21 | |
| *** coldtom has joined #buildstream | 20:21 | |
| *** WSalmon has joined #buildstream | 20:21 | |
| *** lantw44 has joined #buildstream | 20:21 | |
| *** nanonyme has joined #buildstream | 20:21 | |
| *** lchlan has joined #buildstream | 20:21 | |
| *** milloni has joined #buildstream | 20:21 | |
| *** gitlab-br-bot has joined #buildstream | 20:21 | |
| *** juergbi has joined #buildstream | 20:21 | |
| *** pointswaves has joined #buildstream | 20:21 | |
| *** bethw has joined #buildstream | 20:21 | |
| *** valentind has joined #buildstream | 20:21 | |
| *** philn has joined #buildstream | 20:21 | |
| *** benbrown_ has joined #buildstream | 20:21 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!