| *** narispo has quit IRC | 03:06 | |
| *** narispo has joined #buildstream | 03:06 | |
| *** narispo has quit IRC | 04:53 | |
| *** narispo has joined #buildstream | 04:53 | |
| gitlab-br-bot | juergbi opened (was WIP) MR !1571 (juerg/tox-home->master: tests: Set HOME environment variable and work around bzr race condition) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1571 | 05:34 |
|---|---|---|
| juergbi | benschubert: does !1571 look good to you? I *think* this fixes the issue | 05:57 |
| juergbi | setting HOME wasn't sufficient as {envtmpdir} is per environment, not per test, so the race condition was still an issue with parallel tests | 05:57 |
| juergbi | the issue was actually triggered by bzr creating mock repositories, not by the bzr source plugin itself | 05:58 |
| juergbi | so I also added ~/.bazaar directory creation there to work around the bzr race condition | 05:59 |
| *** rdale has joined #buildstream | 08:01 | |
| juergbi | there is also an issue with hanging tests again. I think I know why that's happening but a complete solution is not trivial | 08:09 |
| juergbi | hopefully not too much trouble in CI until that's properly fixed | 08:09 |
| benschubert | juergbi: Oo is it me or all tests share the same config directory? -_-' | 08:11 |
| benschubert | Yeah, seems an acceptable patch, haven't realized those things where hardcoded like that | 08:11 |
| juergbi | yes, HOME/XDG_CONFIG_HOME are (still) shared among tests | 08:13 |
| juergbi | at least it avoids host HOME contamination now, and works around the bzr issue | 08:13 |
| benschubert | correct | 08:13 |
| benschubert | That also explains for some reasons I had tests failing when mounting my host in docker... -_-' | 08:14 |
| gitlab-br-bot | BenjaminSchubert approved MR !1571 (juerg/tox-home->master: tests: Set HOME environment variable and work around bzr race condition) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1571 | 08:15 |
| gitlab-br-bot | marge-bot123 merged MR !1571 (juerg/tox-home->master: tests: Set HOME environment variable and work around bzr race condition) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1571 | 08:15 |
| jennis | nice catch | 08:26 |
| *** tme5 has joined #buildstream | 08:50 | |
| *** jonathanmaw has joined #buildstream | 08:58 | |
| tme5 | do I have the OK to merge !1557 ? | 09:01 |
| gitlab-br-bot | MR !1557: Add in_subprocess pytest mark and modify tests which run in another process to use it https://gitlab.com/BuildStream/buildstream/merge_requests/1557 | 09:01 |
| jennis | tme5, I've given it to marge | 09:05 |
| jennis | I see that tlater[m] and benschubert approved it | 09:05 |
| jennis | juergbi, do you think your cache quota MR can close https://gitlab.com/BuildStream/buildstream/issues/996 ? | 09:05 |
| benschubert | tme5: thanks a lot for this MR, it will help a lot when debugging those tests | 09:06 |
| jennis | +1 | 09:06 |
| tme5 | thank you, hope so :) | 09:07 |
| juergbi | jennis: I don't think that MR solves #996. however, it might actually already have been solved by the casd MR | 09:07 |
| gitlab-br-bot | Issue #996: Cache quota shouldn't be computed until we know we need to write to the cache https://gitlab.com/BuildStream/buildstream/issues/996 | 09:07 |
| juergbi | casd always calculates disk usage on startup | 09:08 |
| juergbi | however, it does this in a separate process and is terminated when bst terminates | 09:08 |
| juergbi | so if I'm not missing anything, it's essentially solved from the user point of view | 09:08 |
| juergbi | but we'll have to verify it | 09:08 |
| jennis | Cool, perhaps benschubert could confirm? | 09:08 |
| benschubert | jennis, juergbi I can't try this now, on my work machine, however, I think we can indeed close it since it's done out of band | 09:10 |
| gitlab-br-bot | jennis opened (was WIP) MR !1565 (jennis/update_checkout->master: Update artifact checkout to handle artifact refs) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1565 | 09:18 |
| gitlab-br-bot | marge-bot123 merged MR !1566 (juerg/cache-quota->master: Cache quota configuration fixes) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1566 | 09:27 |
| *** lachlan has joined #buildstream | 09:30 | |
| *** tpollard has joined #buildstream | 09:47 | |
| *** lachlan has quit IRC | 09:48 | |
| *** tpollard has quit IRC | 09:51 | |
| *** lachlan has joined #buildstream | 10:06 | |
| *** cs-shadow has joined #buildstream | 10:10 | |
| gitlab-br-bot | Qinusty opened issue #1114 (Improve compatibility of Buildstream with Buildbarn and Buildfarm) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1114 | 10:13 |
| *** lachlan has quit IRC | 10:29 | |
| *** lachlan has joined #buildstream | 10:31 | |
| gitlab-br-bot | marge-bot123 closed issue #1108 (Consolidate helpers to run tests in subprocess) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1108 | 10:51 |
| gitlab-br-bot | marge-bot123 merged MR !1557 (tmewett/test-in-subprocess->master: Add in_subprocess pytest mark and modify tests which run in another process to use it) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1557 | 10:51 |
| *** tpollard has joined #buildstream | 10:54 | |
| *** tpollard has quit IRC | 11:03 | |
| *** lachlan has quit IRC | 11:10 | |
| qinusty | Is ReferenceStorage required for remote execution? Buildgrid configures it https://buildgrid.gitlab.io/buildgrid/reference_server_config.html#reference-configuration and it is defined in buildstream protos https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/_protos/buildstream/v2/buildstream.proto#L22 | 11:11 |
| juergbi | qinusty: no, ReferenceStorage is obsolete for bst master/2.x | 11:15 |
| juergbi | related to this, I wanted to clarify on the issue you filed that also bst-artifact-server is not a requirement for remote execution | 11:15 |
| juergbi | it's required to store artifacts but for remote execution itself it's not strictly required | 11:16 |
| jjardon | abderrahim[m]: tristan any idea when buildstream 1.4 is going to be released? gnome freeze is on Monday and it would be nice to have it by then | 11:51 |
| *** phoenix has joined #buildstream | 12:00 | |
| abderrahim[m] | jjardon: Sorry I didn't have much time to work on it. tristan did a good job of packporting the uncontroversial things. I'm using the bst-1 branch exclusively now, and it's stable. I think it's releasable, although I'd like to have some more features there | 12:59 |
| *** phoenix has quit IRC | 13:02 | |
| *** ChanServ sets mode: +o tristan | 13:06 | |
| tristan | abderrahim[m], jjardon Feature wise, I had picked up !1542 for master because it's been long unsolved and I thought it would be a good thing to have in 1.4 | 13:06 |
| gitlab-br-bot | MR !1542: Support strict build dependencies https://gitlab.com/BuildStream/buildstream/merge_requests/1542 | 13:06 |
| tristan | Other than this though, jjardon has found something which needs a bisection, that is the tougher part I suppose | 13:07 |
| jjardon | abderrahim[m]: have you seen https://gitlab.com/BuildStream/buildstream/issues/1098 I'm bit worried that only happen on the bst-1 branch but not in the bst-1.2 one | 13:07 |
| tristan | that's the one | 13:07 |
| tristan | jjardon, there are not many patches really, I think it would be sane to just (A) Create a patch which makes the overnight tests run as regular pipelines... (B) Apply it at the tip of a new branch for every merged branch on bst-1 | 13:08 |
| tristan | just run it all at once as a bisection via CI ? | 13:08 |
| * tristan could try to cook that up | 13:08 | |
| jjardon | that would work indeed | 13:09 |
| tristan | jjardon, as I'll be going on vacation after tomorrows flight, probably you or juergbi will have to do the *actual* release dance | 13:11 |
| tristan | although that is mostly a mindless ritual :) | 13:12 |
| tristan | jjardon, Why do we have this "Test" and "Revert test" noise sitting directly on the bst-1 branch ? | 13:15 |
| tristan | since we've not tagged anything since, shall we just remove that ? | 13:15 |
| *** julien has quit IRC | 13:35 | |
| jjardon | tristan: that was a mistake. I tend to not modify history on public branches even if they are mistakes but your choice | 13:37 |
| *** lachlan has joined #buildstream | 13:37 | |
| tristan | jjardon, yeah I got it... I mean you are totally right in general, this just happens to be a lucky case where nothing was ever published from the branch so, could be done | 13:52 |
| gitlab-br-bot | tmewett opened MR !1572 (tmewett/cli-defaults->master: cli.py: Use Click's show_default for defaults in help text) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1572 | 13:52 |
| tristan | but I'm ambivalent, just noticed that when observing the history to bisect hehe | 13:52 |
| *** lachlan has quit IRC | 14:05 | |
| *** jonathanmaw has quit IRC | 14:09 | |
| tme5 | hi tristan, I wondered if you had any more thought on my reply to your email about DownloadableFileSource and local files | 14:12 |
| tristan | jjardon, Whats with https://gitlab.com/BuildStream/buildstream/-/jobs/284284407 ? Did a valid commit of bst-external really disappear ? | 14:17 |
| tristan | jjardon, I ask because some of your commits from august 5th seem to update this... I didn't backport *that* for the bisect as it should work still how it used to right ? | 14:18 |
| tristan | tme5, ummm, yeah I guess I do | 14:20 |
| tristan | tme5, You say "Without abstracting track/fetch, the behaviour in (2) would have to be implemented manually again", I'm not sure what you mean by that | 14:21 |
| jjardon | tristan: seems something is missing in https://files.pythonhosted.org ? | 14:21 |
| tristan | tme5, Looking back at your original mail, (2) seems to indicate that you want an implicit behavioural change to occur, depending on whether someone specified a URL which begins with the text "file://" | 14:21 |
| *** lachlan has joined #buildstream | 14:21 | |
| qinusty | juergbi, RE artifact cache not being required. How would user experience and performance differ if we weren't storing artifacts during remote execution? And what about running RE services with buildstream 1.3+x? Is a reference store required? | 14:21 |
| tristan | tme5, I think that would be a really bad idea, I originally read the mail (as you noticed), to mean that "file:" was going to be a separate key right ? | 14:22 |
| tristan | Well | 14:22 |
| jjardon | tristan: we only know bst-1 works when it was == to bst-1.2, after that it never have CI so not sure if it ever work | 14:22 |
| tristan | tme5, I don't know honestly it's a bit far and I'm foggy on this... lemme try to decrypt this whole subject a bit further | 14:23 |
| tristan | jjardon, It had CI sure... nightlies we dont know if they passed | 14:23 |
| jjardon | tristan: yeah sorry, I meant that | 14:24 |
| tristan | jjardon, but we never changed the ref we were using to bst-external, there's no excuse for it to break with the same ref we were using right ? | 14:24 |
| jjardon | tristan: only if you change the ref of freedesktop-sdk you use | 14:24 |
| tristan | Or do we have a change in there which changes the gitlab-ci to use a non-existing ref ? | 14:24 |
| tristan | Right but why would we change the ref of freedesktop-sdk we're using ? | 14:25 |
| tristan | This job is failing when cloning bst-external afaics | 14:25 |
| jjardon | tristan: because some upstream of older freedesktop-sdk dissapear, for example | 14:26 |
| tristan | jjardon, What does that mean, how can something disappear ? | 14:26 |
| jjardon | tristan: some refs can go away | 14:27 |
| tristan | jjardon, this is doing `pip3 install --user -e ${bst_ext_url}@${bst_ext_ref}#egg=bst_ext` | 14:27 |
| tristan | and it fails | 14:27 |
| *** lachlan has quit IRC | 14:27 | |
| jjardon | yeah, I mean some upstream refs from freedesktop-sdk | 14:27 |
| jjardon | not sure why that is failing | 14:28 |
| tristan | ok but this is besides the point right ? | 14:28 |
| tristan | jjardon, How can bst-1.2 CI possibly work then ? | 14:28 |
| tristan | Or, I see you updated bst-1.2 to make that work too ? | 14:28 |
| tristan | that is not very nice :-/ | 14:28 |
| jjardon | what is not very nice? | 14:28 |
| tristan | jjardon, I mean that the ref disappear at all | 14:29 |
| abderrahim[m] | Hi | 14:29 |
| tristan | not nice at all, we have to trust that the refs we make to external components in CI can be relied upon | 14:29 |
| jjardon | yeah :( | 14:29 |
| * abderrahim[m] is back | 14:29 | |
| tristan | We use refs to branches sometimes, but only in side branches | 14:29 |
| tristan | jjardon, Technically this means I cannot truly conduct this bisection | 14:30 |
| abderrahim[m] | Oh, yeah I noticed #1098 once | 14:30 |
| gitlab-br-bot | Issue #1098: bst 1.x overnigth tests are failing: Message handling out of sync https://gitlab.com/BuildStream/buildstream/issues/1098 | 14:30 |
| tristan | well, I can do it but there is this vector of uncertainty that is impossible to trace :-/ | 14:30 |
| tristan | abderrahim[m], apparently that race condition is happening consistently with bst-1 | 14:30 |
| *** phoenix has joined #buildstream | 14:31 | |
| tristan | ok well, I'll backport the change to all the branches and run it all again | 14:31 |
| jjardon | tristan: upgrade bst-external to the latest, then start to bisect? | 14:31 |
| tristan | jjardon, Right, but then we are based on a changed bst-external, so we don't know if a change in that ref has an effect on why this happens | 14:31 |
| tristan | anyway | 14:31 |
| tristan | it should still be helpful, but it's not the test I intended to run :-/ | 14:31 |
| abderrahim[m] | Not really consistently, I've only seen it once | 14:31 |
| tristan | abderrahim[m], I believe the issue is about consistent failure... yeah I've seen that message rarely too :) | 14:32 |
| abderrahim[m] | Using e48a03b2b226f1748edf5c2d5e28093da7ca6a1a, I don't know more things were added later | 14:32 |
| jjardon | abderrahim[m]: It's 100% reproducible in CI, but only in the bst-1 branch, bst-1.2 is fine | 14:32 |
| abderrahim[m] | I'm using bst-1 | 14:33 |
| jjardon | abderrahim[m]: note it fails when downloading the first image, probably you already have that cached | 14:33 |
| tristan | tme5, Ok so right... looking back at this email thread, remembering a bit more clearly.... my thoughts are indeed still that the value of a specified "url" should *definitely* not change how the file is handled | 14:34 |
| abderrahim[m] | The failure I had was with building webkit, so I guess it has to do with long operations | 14:34 |
| tristan | tme5, This means that I would expect that if you used a "file://" as a url, and automated a relative path expansion... BuildStream would *STILL* fetch it and cache it into it's sources directory, and calculate the refs and everything as normal | 14:34 |
| tristan | tme5, The user did not "specify a project path", the user has specified a URL, and the magic in Source.translate_url() makes it magically work for everyone | 14:35 |
| abderrahim[m] | tristan: tme5 I'd say it's better to have either url or path | 14:35 |
| abderrahim[m] | rather than the file url | 14:35 |
| tristan | abderrahim[m], I rather think so, but if there is a {project_dir} kind of automatic expansion in URLs automatically, it would allow relocation of data to a local disk easily for any kind of Source | 14:36 |
| tristan | One could even define a local "mirror" for it | 14:36 |
| tristan | And since the refs are all in place, they'd still pretty much work the same way | 14:37 |
| tristan | (you'd still perform a checksum check on a file downloaded from "file://..." that you would on a file downloaded from "https://...", so I think it would just be an overall convenience) | 14:38 |
| tme5 | tristan, I see your point. I too would expect file: URLs to be handled no different to network schemes | 14:47 |
| tme5 | what about changing the different behaviour to not be on file: URLs but instead only when project-relative paths are given? I think then a user would expect different behaviour | 14:49 |
| tristan | tme5, I think it's important that this decision is made depending on the *key* which the user provided, and not depending on the *value* provided to an existing key | 14:49 |
| tristan | tme5, especially considering source aliases exist, and if we have different behaviours for the same source depending on which alias is in use (depending on mirroring and fallbacks), very strange things could happen | 14:50 |
| tristan | if we behaved differently depending on the *value* | 14:51 |
| tme5 | so, for example, one of either a) 'url' and 'ref', or b) 'path' keys? | 14:51 |
| tme5 | yes that's understandable | 14:52 |
| tristan | tme5, yeah exactly that | 14:53 |
| tristan | lets see what the pipelines are doing | 14:53 |
| tme5 | I was clearly idealising some amazing unification of specifying location when I wrote the proposal :P | 14:53 |
| tlater[m] | :o I just discovered `tox -e py37-nocover` | 14:55 |
| tlater[m] | And here I was just running `tox -e py37 -- --no-cov` and accepting that my tests will always fail locally. | 14:56 |
| * tlater[m] wonders why CONTRIBUTING.rst doesn't mention tox factorization | 14:56 | |
| *** phoenix has quit IRC | 14:59 | |
| gitlab-br-bot | jennis opened MR !1573 (jennis/tasks->master: Improve long-running task reporting) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1573 | 15:02 |
| tristan | jjardon, Have you noticed an issue installing recently in the overnight tests ? After backporting your new refs and stuff to all the branches, there seems to be an ignored error installing PyGObject (it fails to install cairo, no idea why we'd want cairo but PyGObject somehow complains at install time ?) | 15:03 |
| *** phoenix has joined #buildstream | 15:04 | |
| coldtom | PyGObject has a dependency on pycairo iirc | 15:05 |
| gitlab-br-bot | jennis approved MR !1572 (tmewett/cli-defaults->master: cli.py: Use Click's show_default for defaults in help text) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1572 | 15:09 |
| jennis | ah, nice tme5 | 15:09 |
| tristan | coldtom, yeah that rings a bell indeed | 15:09 |
| tristan | coldtom, jennis ... careful with "show_default" | 15:12 |
| tristan | oops | 15:12 |
| tristan | I mean jennis, tme5 :) | 15:12 |
| jennis | how comes? | 15:12 |
| tristan | So... a huge portion of the `bst` main options are all explicitly None by default as far as click knows | 15:13 |
| tristan | jennis, This would mean that we would be showing None explicitly as a default value wherever the default value is derived from "BuildStream defaults + user config file" ? | 15:13 |
| gitlab-br-bot | Qinusty approvaled MR !1540 (tlater/cache-endpoints->master: Support separate end points for artifact caches) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1540 | 15:13 |
| tristan | If so, that is a bit weird | 15:13 |
| juergbi | qinusty: sorry, missed your message before. if an action cache is used, reusing a previously built element that is not in the local cache will be a bit slower (dependencies have to be virtually staged/integrated) but reuse should still be possible | 15:13 |
| gitlab-br-bot | Qinusty unapprovaled MR !1540 (tlater/cache-endpoints->master: Support separate end points for artifact caches) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1540 | 15:13 |
| tme5 | of course, i haven't changed any of those options tristan | 15:14 |
| jennis | I see this has been changed for checkout: https://gitlab.com/BuildStream/buildstream/merge_requests/1572/diffs#48a5425791d6d9d502dfdb9fad1e14e38ec05629_1038_1038 | 15:14 |
| juergbi | qinusty: without action cache, remote execution will still work but it will never reuse a previously built artifact, unless it's in the local cache | 15:14 |
| tristan | tme5, Sure... I'm just saying "careful" :) | 15:14 |
| jennis | but I have an MR that also changes this, I don't see why that should be None | 15:14 |
| tme5 | ah ok, thanks haha | 15:14 |
| tristan | tme5, if you've verified this... I just wanted to point it out :) | 15:14 |
| tme5 | appreciated | 15:15 |
| tlater[m] | tme5: Have your test suite changes landed btw? | 15:16 |
| tme5 | they have | 15:16 |
| tlater[m] | \o/ | 15:17 |
| tme5 | a week later than i told you... sorry lol | 15:17 |
| qinusty | Ah okay, so performance will be slightly hindered whilst using an action cache but in bst master/2.x we shouldn't see these slow downs? (Or is the slow down just accepted with the deprecation of ReferenceStorage?) juergbi | 15:17 |
| juergbi | qinusty: RE support is only in master/2.x | 15:18 |
| juergbi | ReferenceStorage was replaced by the Artifact/Source service but is equivalent in this regard | 15:19 |
| qinusty | Okay, so maybe I am misunderstanding the whole master/2.x versioning. Is buildstream:nightly 2.x? --version provides 1.3.0+<ref> | 15:21 |
| * tristan finds it a little bit unfortunate that ReferenceStorage sounds a lot like ref-storage (assuming that the former is completely unrelated to the latter) | 15:21 | |
| tristan | jjardon, Still around ? I have an interesting observation... | 15:23 |
| jjardon | tristan: sorry I was in a meeting; I do not see any issues with the latest nigtlhy from yesterday on the bst-1.2 branch | 15:23 |
| tristan | jjardon, My question to you is... have you ever seen this out-of-sync message bug happen with a source other than the OSTree source ? | 15:23 |
| tristan | jjardon, I think it is related to this failure to get the PyGObject deps installed (cairo) which seems to be consistently ignored | 15:24 |
| jjardon | tristan: I actually think that out-of-sync is not the cause of the problem; I have seen that error in succesful builds | 15:24 |
| tristan | jjardon, I.e. OSTree is borked if PyGObject doesnt install, and we only really find out at fetch time, is a new theory | 15:24 |
| jjardon | tristan: and to answer your question: no, I think only see that when importing ostree repos | 15:25 |
| jjardon | tristan: interesting | 15:25 |
| qinusty | I'm working from the buildgrid docs really https://buildgrid.gitlab.io/buildgrid/reference_server_config.html#reference-configuration. Would I be correct in assuming that as of master/2.x, buildstream is REAPI compatible aside from the bst-artifact-server requirement for remote caching? (Obviously we have issues with specific server implementations | 15:25 |
| qinusty | ) | 15:25 |
| tristan | jjardon, I have a new failure anyway which supports this theory... I'll see if I can fix the install to both install properly and fail the CI properly if it fails, and hope that fixes it | 15:26 |
| ironfoot | I keep having this issue, does anybody know what can be causing it? https://paste.gnome.org/papsyni5s | 15:28 |
| ironfoot | the element I'm trying to build (compose) includes a stack element. This stack element has 2 elements inside. | 15:29 |
| ironfoot | The failure has happened when adding the second element in the stack, wich literally copies a file from build-root to install-root/lib/firmware/ | 15:29 |
| ironfoot | Building and checking out the stack element works fine and looks correct | 15:32 |
| tristan | ironfoot, looks suspicious, trying to link / -> /install/lib/firmware ? | 15:35 |
| tristan | or rather to /buildstream/install | 15:36 |
| ironfoot | I've looked into the cache/buildstream/build dir, and at that point /lib is a broken symlink | 15:37 |
| ironfoot | but yes, it's odd | 15:37 |
| tristan | a test case would be very helpful of course... | 15:37 |
| ironfoot | maybe I shouldn't be doing this? https://paste.gnome.org/pmjek4ndh | 15:38 |
| tristan | that doesnt look wrong to me | 15:38 |
| tristan | well, weird maybe a bit | 15:38 |
| tristan | ironfoot, remember this is a usr merge system | 15:39 |
| tristan | ironfoot, so you are essentially calling `cp -r` on a symlink to lib -> usr/lib ? | 15:39 |
| ironfoot | will try changing that | 15:40 |
| *** lachlan has joined #buildstream | 15:41 | |
| ironfoot | creating the usr/lib/firmware and copying the files inside worked | 16:00 |
| ironfoot | probably it unpacks this in the staging area before usr/lib is present | 16:01 |
| ironfoot | nvm, it's working now | 16:01 |
| *** raoul has quit IRC | 16:08 | |
| tristan | ironfoot, conceptually there should be more efficient ways to do this but we lack features to tell elements like compose/filter to *relocate* certain files | 16:10 |
| tristan | ironfoot, just pointing out that we shouldnt really need a real disk copy to happen in order to say "Take this set of files from the input, and include it in the output under this new location" | 16:11 |
| tristan | jjardon, :) | 16:13 |
| tristan | jjardon, it's fixed by reverting 08ead05bbe24a6de94e26b1121e5aa8dd341f691 ... and it appears that reverting that move to a fedora 30 docker does not reintroduce #1097 | 16:14 |
| gitlab-br-bot | Issue #1097: bst 1.x overnigth tests are failing: SyntaxError: invalid syntax https://gitlab.com/BuildStream/buildstream/issues/1097 | 16:14 |
| tristan | oh not even ? this is very strange | 16:14 |
| tristan | https://gitlab.com/BuildStream/buildstream/-/jobs/284398830 | 16:15 |
| tristan | jjardon, With the revert of the docker image change... we end up successfully pulling the base image with ostree... BUT we still have the stack trace while installing PyGObject (same problem error with cairo) | 16:16 |
| tristan | Who knows how long that stack trace has been silently raising without actually causing anything to break | 16:16 |
| *** lachlan has quit IRC | 16:33 | |
| *** tiagogomes has quit IRC | 16:36 | |
| *** tme5 has quit IRC | 16:38 | |
| gitlab-br-bot | tristanvb closed issue #1098 (bst 1.x overnigth tests are failing: Message handling out of sync) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1098 | 16:40 |
| *** lachlan has joined #buildstream | 16:55 | |
| *** rdale has quit IRC | 19:09 | |
| *** lachlan has quit IRC | 19:16 | |
| *** lachlan has joined #buildstream | 19:23 | |
| *** lachlan has quit IRC | 19:34 | |
| *** lachlan has joined #buildstream | 19:46 | |
| *** lachlan has quit IRC | 19:53 | |
| *** bochecha has joined #buildstream | 19:58 | |
| *** cs-shadow has quit IRC | 20:09 | |
| *** phoenix has quit IRC | 22:31 | |
| *** bochecha has quit IRC | 22:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!