| *** benschubert has quit IRC | 00:10 | |
| *** hasebastian has joined #buildstream | 04:00 | |
| *** tristan has quit IRC | 05:54 | |
| *** tristan has joined #buildstream | 05:58 | |
| *** ChanServ sets mode: +o tristan | 05:58 | |
| *** hasebastian has quit IRC | 06:57 | |
| *** hasebastian has joined #buildstream | 07:06 | |
| *** hasebastian has quit IRC | 07:11 | |
| *** hasebastian has joined #buildstream | 07:11 | |
| *** benschubert has joined #buildstream | 07:15 | |
| benschubert | juergbi: if ever I'm looking into the coverage update. Interestingly, py38 works flawlessly for coverage 5.1+ | 07:18 |
|---|---|---|
| juergbi | benschubert: oh, it's not affected by the cython-related internal error seen with py37? | 07:19 |
| benschubert | nope.... | 07:19 |
| benschubert | only py36 and 37 are affected | 07:19 |
| juergbi | interesting | 07:19 |
| juergbi | benschubert: could we easily have different coverage versions for py37 and py38? | 07:19 |
| benschubert | not easily | 07:19 |
| benschubert | and given the workaround, I think it's not too bad :) | 07:20 |
| juergbi | sure, if all it takes is a dummy inline function | 07:20 |
| juergbi | pip might actually even understand something like | 07:21 |
| juergbi | coverage == 4.4.0; python_version < '3.8' | 07:21 |
| juergbi | but better to move to coverage 5 for all python versions | 07:22 |
| benschubert | yeah, I'm not sure it's worth :) | 07:22 |
| benschubert | because we might want to combine the results | 07:22 |
| juergbi | good point | 07:22 |
| benschubert | oh wait, more interesting: it passes on my laptop but not on CI for py38 | 07:23 |
| benschubert | So.... my fedora docker image is actually what makes it pass? wut | 07:23 |
| benschubert | https://gitlab.com/BuildStream/buildstream/-/jobs/608520605 for the CI job | 07:23 |
| juergbi | that's a slightly different error message, isn't it? | 07:25 |
| benschubert | mmh true, I definitely remember having the other one before, what did I do for this.... | 07:26 |
| benschubert | https://github.com/cython/cython/issues/3515#issuecomment-613671329 though | 07:27 |
| juergbi | benschubert: I'm seeing the same error as in CI, also only at the end | 07:33 |
| juergbi | that's with a pristine build of Python 3.8.3 | 07:33 |
| benschubert | Debian? | 07:33 |
| juergbi | no, my own build | 07:34 |
| benschubert | I'm also python3.8.3 from Fedora | 07:34 |
| benschubert | and no error | 07:34 |
| * benschubert wipes his venvs | 07:34 | |
| juergbi | coverage 5.1, fresh tox venv | 07:34 |
| juergbi | and with parallel testing | 07:34 |
| juergbi | was your run with `-n` as well or without? | 07:35 |
| benschubert | oh without! | 07:39 |
| benschubert | ok let me try with | 07:39 |
| benschubert | I forgot that we need to explicitely add the -n | 07:40 |
| juergbi | without -n tests are taking ages | 07:41 |
| benschubert | right, I've added it, let's see how long it takes :) | 07:41 |
| benschubert | and if I can reproduce | 07:42 |
| tristan | Can we simply not support coverage for python versions < 3.8 ? | 07:47 |
| tristan | We don't really have python version specific code blocks, so we only need a report for every possible 3.8 CI run | 07:48 |
| benschubert | tristan: seems like it's the "-n" that triggers the bug, so py38 working on my machine was a read hearing | 07:48 |
| tristan | Ah | 07:48 |
| benschubert | *herring | 07:48 |
| juergbi | benschubert: I even get the error with py38 and non-parallel testing | 07:49 |
| juergbi | however, in that case I get the old 'Can't add file tracer data for unmeasured file' | 07:49 |
| benschubert | -_-' | 07:49 |
| juergbi | so there the inline workaround would probably help | 07:49 |
| benschubert | yeah I'll look more in details | 07:50 |
| benschubert | juergbi: I think you are right we have yet another error there | 08:19 |
| benschubert | However it seems to me related to multiprocessing | 08:20 |
| benschubert | I'll park that or now | 08:20 |
| tristan | Ok, the eagle has landed ! | 08:23 |
| tristan | If a branch lands in the middle of the juncle and noone is around to hear it... ? | 08:24 |
| tristan | I think this one makes a sound ;-) | 08:24 |
| *** santi has joined #buildstream | 08:25 | |
| *** hasebastian has quit IRC | 09:00 | |
| tristan | So I have this failing pipeline on master | 09:43 |
| tristan | jjardon, https://gitlab.com/BuildStream/buildstream/-/jobs/609047103 | 09:43 |
| tristan | jjardon, "mesg: ttyname failed: Inappropriate ioctl for device" <-- is that possibly because of this new lack of "permanent runners" (whatever those are) ? | 09:43 |
| jjardon | tristan: that is a windows machine ... | 09:44 |
| tristan | I've retried that job once and it yields the same error, I guess that device really doesn't find that ioctl to be appropriate :-S | 09:44 |
| jjardon | no related with permanent runners, but a misconfiguration of that runner, probably | 09:44 |
| tristan | So... the windows machine is permanent ? | 09:44 |
| tristan | Hmmm | 09:44 |
| tristan | Who can fix that ? | 09:44 |
| * tristan wonders if his pipeline is the first one to fail there | 09:45 | |
| jjardon | I think we should put the runner as "not run untagged jobs" | 09:45 |
| tristan | Is it that we don't block pipelines in CI for the wsl job but we make it mandatory in master ? That would be bad... | 09:45 |
| tristan | Maybe it's not failing for that reason too | 09:46 |
| jjardon | I'd say job that need a windows machine should use a explicit "win" tag | 09:46 |
| tristan | fatal: unable to access 'https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@gitlab.com/BuildStream/buildstream.git/': Failed to connect to gitlab.com port 443: Connection refused | 09:46 |
| tristan | That seems to be the reason it fails | 09:46 |
| jjardon | mmm, seems like a glitch of that specific runner | 09:47 |
| jjardon | any idea who is maintaining that windows runner nowadays? | 09:48 |
| juergbi | I've asked benbrown to give a kick to the WSL runner | 09:48 |
| tristan | It looks like indeed, the wsl thing doesnt run on MRs | 09:49 |
| tristan | https://gitlab.com/BuildStream/buildstream/-/pipelines/159483864 | 09:49 |
| tristan | It shows them as manually launchable | 09:49 |
| *** benbrown has joined #buildstream | 09:49 | |
| juergbi | yes. I think the reason was that we only have one or two WSL runners | 09:49 |
| juergbi | it would hold up our pipelines | 09:50 |
| tristan | This essentially means: (A) We land branches without running WSL tests, adding important documentation updates... (B) Docs don't get updated because deployment of docs is gated on WSL passing | 09:50 |
| tristan | I see :-S | 09:50 |
| juergbi | it may make sense to mark the job as allow_failure in master as well | 09:51 |
| juergbi | until we have a more scalable WSL runner story | 09:51 |
| tristan | Mmmm, I'd be fine with that, or fix the WSL runner, not necessarily to be fancy or anything, but to not "stop working" | 09:51 |
| juergbi | it's a Windows client machine... | 09:52 |
| tristan | So we can't guarantee that it works... cause it's windows, fair point ;-P | 09:52 |
| juergbi | maybe we could run it on azure with a managed Windows system. don't know whether they might even offer free access for open source projects | 09:53 |
| juergbi | benbrown has restarted the WSL machine, so let's retry | 09:53 |
| tristan | thanks benbrown :) | 09:54 |
| tristan | Yeah that seems to have done it | 09:54 |
| juergbi | looking better now | 09:54 |
| tristan | maybe the CI should start with a clean boot ;-) | 09:54 |
| juergbi | hehe | 09:54 |
| juergbi | or maybe nightly reboot or so | 09:54 |
| juergbi | using a Windows server container would probably be the best option | 09:55 |
| juergbi | but we need Windows Server for that | 09:55 |
| juergbi | and someone that maintains it (or handled by azure or similar) | 09:56 |
| tristan | I'm guessing "mesg: ttyname failed: Inappropriate ioctl for device" is from ncurses | 09:56 |
| tristan | And will be fixed in a WSL update | 09:57 |
| juergbi | I don't know how extensively WSL1 will be updated given that WSL2 is now available | 10:02 |
| juergbi | WSL1 will remain supported for the time being, afaik, however, I wouldn't expect lots of feature additions anymore | 10:02 |
| tristan | Ah, I'm not familiar with what the difference is | 10:06 |
| tristan | Just thinking that as WSL evolves, it will handle the syscall table better (more completely) | 10:07 |
| tristan | This seems like just a case of WSL calling out BuildStream for it's foul language (calling our ioctl's "inappropriate") | 10:07 |
| juergbi | tristan: WSL1 is Microsoft's reimplementation of the Linux kernel (syscall) ABI. a bit like reverse wine except operating at the kernel/syscall level | 10:10 |
| juergbi | WSL2 is a real Linux kernel transparently running in a VM | 10:11 |
| tristan | Ahhhh | 10:12 |
| tristan | hmmm, https://gitlab.com/BuildStream/buildstream/-/issues/1296 looks ambitious | 10:14 |
| *** tristan has quit IRC | 10:47 | |
| *** cs-shadow has joined #buildstream | 11:50 | |
| *** tristan has joined #buildstream | 12:16 | |
| *** ChanServ sets mode: +o tristan | 12:16 | |
| *** tomaz has joined #buildstream | 13:50 | |
| tomaz | jjardon: ping | 13:51 |
| tomaz | https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/work/qt5.14-buildstream-test | 13:51 |
| tomaz | done. | 13:51 |
| *** cs-shadow has quit IRC | 14:00 | |
| *** santi has quit IRC | 14:09 | |
| *** santi has joined #buildstream | 14:11 | |
| jjardon | nice one tomaz | 14:21 |
| *** phildawson has quit IRC | 14:50 | |
| douglaswinship | There's a design pattern that I'm sure I've seen for plugins, where you specify elements as build-dependencies, and then you specify some of the same elements by name, in the config section, to say "use _this_ element for this aspect of the build process, and use _that_ element for that aspect of the build process", so you treat the elements in different ways. | 15:18 |
| douglaswinship | But I can't remember where I saw it used. | 15:18 |
| douglaswinship | I suppose a script element works that way, in a sense. | 15:19 |
| douglaswinship | But can you only do it with script elements? Or can I write a user-defined plugin that would do it? | 15:19 |
| coldtom | oci and flatpak-repo do this iirc | 15:19 |
| douglaswinship | coldtom: thanks! | 15:19 |
| WSalmon | douglaswinship, a script element lets you place diffrent artifacts in to diffrent locations insted of just placing all the dependencies in to the root of the sand box, its called `layout` if you wite your own plugin you can customise this in the python | 15:27 |
| WSalmon | dose anyone know anything about htis over night tests, dose this image need renaming? or is there more going on? this error seems to be in master and my branchhttps://gitlab.com/BuildStream/buildstream/-/jobs/609420900 | 15:28 |
| WSalmon | dose anyone know anything about htis over night tests, dose this image need renaming? or is there more going on? this error seems to be in master and my branch https://gitlab.com/BuildStream/buildstream/-/jobs/609420900 | 15:28 |
| abderrahim[m] | I guess so | 15:34 |
| abderrahim[m] | you can try the latest image while you're at it | 15:34 |
| abderrahim[m] | https://gitlab.com/BuildStream/buildstream-docker-images/container_registry/ | 15:35 |
| WSalmon | so as far as i can tell, we dont make any no x86_64 docker images? | 15:52 |
| WSalmon | as part of https://gitlab.com/BuildStream/buildstream-docker-images/-/pipelines/159459029 | 15:52 |
| WSalmon | etc | 15:52 |
| WSalmon | ? | 15:52 |
| *** santi has quit IRC | 17:14 | |
| *** tomaz has quit IRC | 19:05 | |
| *** benschubert has quit IRC | 23:41 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!