| *** tristan has joined #buildstream | 07:01 | |
| *** semanticdesign has joined #buildstream | 07:42 | |
| *** tiagogomes has joined #buildstream | 08:47 | |
| *** tiagogomes has quit IRC | 08:49 | |
| *** tiagogomes has joined #buildstream | 08:51 | |
| *** bochecha has joined #buildstream | 09:15 | |
| *** tlater has joined #buildstream | 09:17 | |
| gitlab-br-bot | buildstream: merge request (102-run-ci-as-non-root-user->master: Resolve "Run CI as non-root user") #104 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/104 | 09:25 |
|---|---|---|
| tlater | I keep trying and failing to run this integration test: https://gitlab.com/BuildStream/buildstream/pipelines/12407354 | 09:27 |
| tlater | It just always goes over the 1 hour mark | 09:27 |
| tlater | I had to clear the cache, since its permissions changed, but that means that it has fetch now... | 09:27 |
| gitlab-br-bot | buildstream: merge request (102-run-ci-as-non-root-user->master: WIP: Resolve "Run CI as non-root user") #104 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/104 | 09:28 |
| *** ssam2 has joined #buildstream | 09:34 | |
| *** semanticdesign has quit IRC | 09:54 | |
| *** semanticdesign has joined #buildstream | 09:57 | |
| gitlab-br-bot | push on buildstream@48-incorrect-pipeline-total-element-count-for-bst-track (by Tristan Maat): 20 commits (last: setup.py: Make setup.py work on non-linux) https://gitlab.com/BuildStream/buildstream/commit/e8beece45b7de0ee0de4db2254a4e40b44bc8b58 | 10:08 |
| tlater | Hm, is it normal for buildstream to take ~2 hours to do 'checking'? | 10:26 |
| paulsherwood | absolutely not | 10:26 |
| tlater | Running `bst build --track` works round it, it's something about calling `element._cached()` on my specific project. | 10:46 |
| gitlab-br-bot | buildstream: issue #109 ("Add 'flatpak' element to allow generating flatpak apps and runtimes") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/109 | 11:26 |
| tristan | tlater, that has to be a regression | 11:35 |
| tristan | tlater, and is most certainly some kind of network related hang | 11:35 |
| tlater | That's possible, given that the gnome modulesets repository seems to be gone | 11:35 |
| tristan | that's a point, if you depend on gnome7 | 11:36 |
| tristan | maybe we need a general tracking bug for various source implementations to ensure they dont hang | 11:37 |
| tristan | although I'm not sure how exactly, that you tell git what timeout it should employ for network activity (for example) | 11:37 |
| tristan | tlater, however of course; that has to be completely unrelated to element._cached() | 11:38 |
| tristan | (because _cached() checks for presence in local artifact cache, nothing to do with sources on gnome7) | 11:39 |
| tlater | Buildstream does run with 99.9% CPU usage while trying to compute *something* | 11:39 |
| tristan | also, it's marginally possible that you think it has to do with _cached() while it has more to do with that initial check for connectivity | 11:39 |
| tristan | and the download of the summary | 11:39 |
| tlater | I doubt network connections could push this to that high. | 11:40 |
| tristan | tlater, anything variants related in whatever project you are building ? | 11:40 |
| * tristan expects not | 11:40 | |
| tlater | tristan: I don't *think* so, I'm not using them at least... | 11:40 |
| tristan | yeah they dont appear in any project I know of except the guadec demo | 11:41 |
| tristan | and they will disappear tomorrow | 11:41 |
| tristan | (and that's the only computationally difficult part I can think of) | 11:41 |
| tristan | anyway | 11:41 |
| tristan | tlater, assuming you've used the profiling stuff, you probably already know which function call is taking 90% of that time | 11:42 |
| * tlater forgot about python profiling | 11:42 | |
| tlater | That looks like a plan x) | 11:42 |
| tristan | so you shouldnt have to know about python specifically | 11:42 |
| tristan | you should just know about what is in buildstream/_profile.py | 11:43 |
| tristan | set an env var, reproduce, read report | 11:43 |
| tlater | Hm, this only works if it completes, right? | 11:51 |
| * tlater has not successfully completed a run yet, as it seems to take exponentially more time. Hopefully 6-8 hours. | 11:54 | |
| tristan | tlater, you sure it's doing something ? | 11:57 |
| tristan | if so, run it on a one, two, three element pipeline | 11:57 |
| tlater | top thinks it is... But this only seems to happen in this specific project. | 11:57 |
| tristan | so reduce until it's small enough to reproduce ? | 11:58 |
| tlater | It's a little very big, but I'll try. | 11:59 |
| tristan | Or alternaltively hack around the profile stuff, add a new domain; make dumps for a more granular subject | 11:59 |
| tristan | yeah well, the question is just running `bst build` with lower level elements until you have something that is A.) small and B.) still reproduces the problem | 12:00 |
| tristan | if the situation cannot be reproduced without the hundreds of elements, that would be unfortunate | 12:00 |
| tristan | harder to profile and figure out | 12:00 |
| tristan | of course you can also sprinkle tracing here and there to find out exactly where you're locking up / what loop is taking time | 12:01 |
| *** tristan has quit IRC | 12:05 | |
| *** tristan has joined #buildstream | 12:28 | |
| gitlab-br-bot | push on buildstream@sam/ci-update-docker-image (by Sam Thursfield): 1 commit (last: Removing ostree was taking fuse-libs with it) https://gitlab.com/BuildStream/buildstream/commit/b53ca14e5dd626d6010a58a4127128050259977b | 14:27 |
| gitlab-br-bot | push on buildstream@sam/ci-update-docker-image (by Sam Thursfield): 1 commit (last: I am dumb) https://gitlab.com/BuildStream/buildstream/commit/b69db57243118aef695ee0ee70af7eaf58cc905c | 14:36 |
| tlater | ssam2: How did the CI ever succeed without fuse? | 14:38 |
| tlater | *fuse-libs ;P | 14:38 |
| ssam2 | it was based on an older fedora image | 14:38 |
| ssam2 | having loads of faff with dnf in this new one | 14:38 |
| *** tlater has quit IRC | 14:47 | |
| *** tlater has joined #buildstream | 14:53 | |
| *** jude has quit IRC | 15:30 | |
| gitlab-br-bot | push on buildstream@sam/ci-update-docker-image (by Sam Thursfield): 4 commits (last: Remove Dockerfile) https://gitlab.com/BuildStream/buildstream/commit/2a9f4d7daa07ff217bfba3ef3580260e0862ae2b | 15:47 |
| gitlab-br-bot | buildstream: merge request (sam/ci-update-docker-image->master: .gitlab-ci.yml: Follow latest BuildStream Docker image) #105 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/105 | 15:50 |
| *** tlater has quit IRC | 15:52 | |
| *** tlater has joined #buildstream | 15:54 | |
| *** laurenceurhegyi is now known as ltu | 16:37 | |
| *** ssam2 has quit IRC | 17:04 | |
| *** tlater has quit IRC | 17:31 | |
| *** jude has joined #buildstream | 20:07 | |
| *** jude has quit IRC | 21:31 | |
| *** semanticdesign has quit IRC | 22:06 | |
| *** semanticdesign has joined #buildstream | 22:06 | |
| *** semanticdesign has quit IRC | 23:06 | |
| *** semanticdesign has joined #buildstream | 23:06 | |
| *** semanticdesign has quit IRC | 23:16 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!