IRC logs for #buildstream for Monday, 2019-12-16

*** traveltissues has joined #buildstream07:46
*** bochecha has joined #buildstream09:30
*** rdale has joined #buildstream09:32
benschubertIs anyone awaiting on reviews?09:36
*** santi has joined #buildstream09:44
*** mohan43u has quit IRC09:57
*** tpollard has joined #buildstream10:00
*** phildawson_ has joined #buildstream10:10
*** lachlan has joined #buildstream10:28
*** phildawson_ has quit IRC10:32
*** toscalix has joined #buildstream10:33
*** phildawson_ has joined #buildstream10:34
*** phildawson_ has quit IRC10:37
*** phildawson_ has joined #buildstream10:37
*** lachlan has quit IRC10:46
*** tiagogomes has joined #buildstream10:52
*** tiagogomes has quit IRC10:54
*** lachlan has joined #buildstream10:54
*** tiagogomes has joined #buildstream10:58
*** toscalix has quit IRC10:58
*** phildawson_ has quit IRC11:00
*** lachlan has quit IRC11:07
*** phildawson_ has joined #buildstream11:17
*** tme5 has joined #buildstream11:24
tme5does marge work?11:26
tlater[m]tme5: Marge has been a little out of it lately11:27
tlater[m]I've still not had the time to sit down and talk to her about it11:28
tme5then could someone with the powers please merge !1765 when they get a moment11:30
gitlab-br-botMR !1765: Make Git source plugin clone submodules recursively https://gitlab.com/BuildStream/buildstream/merge_requests/176511:30
benschubertSure I'll do this, thanks tme5 !11:32
gitlab-br-botBenjaminSchubert closed issue #1162 (Git source doesn't support recursive submodules) on buildstream https://gitlab.com/BuildStream/buildstream/issues/116211:33
gitlab-br-botBenjaminSchubert merged MR !1765 (tmewett/recursive-git->master: Make Git source plugin clone submodules recursively) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/176511:33
tme5thanks ben11:33
tpollardbenschubert: I've been prodding your 3.8 branch. Turning coverage off for now & adding a timeout/newer container for buildbox I've got it to output some tests errors12:04
tpollardThey seem to be repeatable12:04
benschuberttpollard: yep there should be 5 of them. I'm more concerned about the coverage failure :/12:05
tpollardI'm currently getting 4, all from shutil12:05
benschubertah right, that seems correct12:05
tpollardhttps://gitlab.com/BuildStream/buildstream/-/jobs/380395708/raw12:06
tpollardon the release notes for 3.8 it mentions changes to copytree api12:06
benschubertOk that should not be too hard to fix12:09
benschubertdo you have any idea around the coverage problem though? :/12:10
*** narispo has quit IRC12:13
*** narispo has joined #buildstream12:13
benschubertHas someone tried to use buildstream master for anything recently? I'm getting loads of errors in the usbprocesses12:22
* tlater[m] did last Friday12:22
benschuberthandle: <Handle Job._parent_child_completed(4278, 0)>12:22
benschubertTraceback (most recent call last):12:22
benschubert  File "/usr/lib/python3.6/asyncio/events.py", line 145, in _run12:22
benschubert    self._callback(*self._args)12:22
benschubert  File "/home/bschubert15/gitlab/buildstream/src/buildstream/_scheduler/jobs/job.py", line 455, in _parent_child_completed12:22
benschubert    self._process.close()12:22
benschubertAttributeError: '_AsyncioSafeForkAwareProcess' object has no attribute 'close'12:22
benschubertException in callback Job._parent_child_completed(4279, 0)12:22
benschuberthandle: <Handle Job._parent_child_completed(4279, 0)>12:22
benschubertTraceback (most recent call last):12:22
benschubertWould seem like something I would have caused previously?12:22
tlater[m]Didn't see anything in particular, but I was just working on the integration project12:22
tlater[m]Odd, I'd expect mypy to see that kind of problem12:23
benschubertIt's untyped at that place12:25
tlater[m]:|12:25
*** lachlan has joined #buildstream12:26
benschubertah no got it. I't `self._process.close()` that was added when replacing the queue by a pipe12:26
*** narispo has quit IRC12:27
*** narispo has joined #buildstream12:27
tpollard& that's 3.7+ specific?12:28
tpollardseems to be :/12:28
tlater[m]Wait, but that means someone has succeeded in running buildstream on 3.812:28
tpollardnew to 3.712:28
tlater[m]Oh12:28
tlater[m]Right12:29
benschubertah you can now clsoe on 3.7?12:29
tpollardhttps://docs.python.org/3.7/library/multiprocessing.html#multiprocessing.Process.close12:29
tlater[m]I guess the test suite just never hits that then?12:29
benschubertoh wow12:29
benschubertAh no it went unnoticed since it's jsut printed on the screen, and nothing catches that12:30
tlater[m]Oh, right12:30
benschubertjuergbi: ^ also :)12:30
benschubertDo we want to monkeypatch a 'close' method on python 3.5 and 3.6 or not close at all?12:30
tpollardI should have spotted that, I remember hitting it with the separate process work12:30
benschubertoh well :)12:31
tpollardbenschubert: in terms of coverage, not found a solution yet. although 5.0 came out of beta on saturday so I'll try that....12:32
tlater[m]benschubert: If monkeypatching is simple enough, I think that would be ok12:32
tlater[m]But we should have some sort of a collection ground for patches like that12:32
juergbioops12:32
tlater[m]So that we can remove them as we get rid of support for old versions12:33
*** lachlan has quit IRC12:33
*** mohan43u has joined #buildstream12:41
*** lachlan has joined #buildstream12:46
tme5is it valid to use variables an element sources configuration?12:46
tme5i can't seem to get them to expand in a URL12:47
tlater[m]tme5: I think the reason I didn't just implement a patch for my issue when I came up with that was precisely that variables aren't expanded there12:49
tlater[m]But I don't know off the top of my head where to check for that12:49
*** lachlan has quit IRC12:50
tme5why not 😭12:51
tlater[m]tme5: That's been lost to the annals, I'm sure if you searched the chat history long enough you could find me and tristan talking about that12:52
tme5i would say, maybe we can just add a project: alias12:52
coldtomthere was an issue for it i think? https://gitlab.com/BuildStream/buildstream/issues/1127 perhaps?12:53
*** lachlan has joined #buildstream12:53
tlater[m]tme5: I don't know if I like a default alias12:53
tlater[m]I'd rather figure out why we don't have expanding variables, since that's something we want anyway12:54
tlater[m]At which point this feature becomes trivial :)12:54
tme5"Not exposing the variables in sources is mostly just an oversight, I don't see anything dangerous about this especially due to the relationship between the Element and Source"12:55
tme5from van berkom12:56
*** lachlan has quit IRC12:57
*** narispo has quit IRC12:57
*** narispo has joined #buildstream12:59
tme5i'll probably reopen and assign myself to #1127 then13:04
gitlab-br-botIssue #1127: Allow sources to access their element's variables https://gitlab.com/BuildStream/buildstream/issues/112713:04
*** narispo has quit IRC13:19
*** narispo has joined #buildstream13:19
gitlab-br-bottmewett reopened issue #1127 (Allow sources to access their element's variables) on buildstream https://gitlab.com/BuildStream/buildstream/issues/112713:20
benschuberttpollard: I've tried too and have even more problems. However I'd agree that moving to coverage 5.0 first is a good idea!13:24
benschuberttme5: right, I was planning onworking on this but never managed to get a satisfactory solution in terms of performance :( Good luck with that!13:25
*** toscalix has joined #buildstream13:44
*** santi has quit IRC13:45
*** santi has joined #buildstream13:49
*** toscalix has quit IRC13:52
tpollardbenschubert: same failures13:59
*** toscalix has joined #buildstream14:00
* tpollard keeps trying14:02
*** phildawson-ct has joined #buildstream14:03
tpollardI think it's coming from them switching from json to sql14:05
*** phildawson_ has quit IRC14:05
valentindjjardon, benschubert, could you tell me about the issue you are having with collect_manifest? Is there merge request or branch that fails to build?14:07
jjardonvalentind: https://gitlab.com/BuildStream/buildstream/issues/124114:09
jjardonvalentind: the schedule to build fdsdk with bst master is failing14:09
*** phildawson-ct has quit IRC14:10
coldtomjust need to update the bst-plugins-experimental commit used i think14:10
valentindThis is a weird error14:10
valentindAh no, it is  "Format version 1 is too old for requested version 2"14:11
valentindRight, it does not use the right version of bst-plugins-experimental14:11
benschubertvalentind: my issue was that both PRs have quite different code and was wondering how come :)14:13
valentindbe5ac19 is too old.14:13
valentindbenschubert, Yes, but this is because the code was already different.14:13
benschubertvalentind: gotcha, thanks14:14
valentindSomeone else has submitted the plugin to bst-plugins-experimental, then during the review process, lots of changes were done, and they did not backport it to bst-external.14:14
*** tme5 has quit IRC14:15
valentindIn my merge request it is really the same feature. I just also fixed formatting in the documentation that was wrong. The rest should be the same.14:15
benschubertDo you expect it to become a problem? As in, should we open an issue and fix it or just keep it like that?14:15
valentindLet's fix that if it really becomes a problem.14:16
valentindIt is not like I expect we will add new features in that plugin every month.14:16
valentindBut maybe next time we push something from bst-external to bst-plugins-experimental, we should fix first things in bst-external before we put it in bst-plugins-experimental.14:17
*** phildawson-ct has joined #buildstream14:17
valentindAnd the only differences should be API related.14:17
benschubertOk, so bst-plugins-experimental is the 'canonical' version and we should update the other instead of the reverse? (That is if we ever need to do it)14:18
valentindNo. bst-plugins-experimental is not canonical. It is not well tested enough.14:19
*** tme5 has joined #buildstream14:19
tme5benschubert, performance? interesting, i wouldn't have imagined this would be that bad? seeing as variable substitution happens everywhere else already?14:19
valentindIf a plugin is in one repo, no matter which one, when adding it in the other one, if we find things to fix that are not related to API, then the repo source of that plugin should be fixed first.14:20
benschuberttme5: it required me to change a bit how we instantiate all plugins and that was what killed me. A nicer implementation might not have problems at all :)14:21
valentindBecause what ever repo it comes from, it is probably the repo from which it is more tested.14:21
tme5ahh ok14:22
*** toscalix has quit IRC14:24
*** lachlan has joined #buildstream14:31
*** lachlan has quit IRC14:37
*** lachlan has joined #buildstream14:38
*** lachlan has quit IRC14:41
*** lachlan has joined #buildstream14:48
*** lachlan has quit IRC14:58
benschuberttlater[m]: around those problems with python3.5/3.6 What about a '_compat.py' that we import in __init__ that adds all our monkeypatches? And we would ensure each patch specifies which versions it targets?15:06
tlater[m]benschubert: Yep, that's what I was thinking15:07
tlater[m]I wonder if there are generic dependencies that do such a thing15:07
benschubertwell, I'd rather handle this ourselves :)15:08
tlater[m]Yeah, probably best15:08
tlater[m]It probably won't be too common.15:09
benschubertI sure hope so :'D15:09
*** lachlan has joined #buildstream15:09
tlater[m]Famous last words ;p15:09
*** lachlan has quit IRC15:12
tlater[m]Are we 3.6 yet?15:17
tlater[m]No :(15:17
tlater[m]No NamedTuple for me :(15:17
tlater[m]Let alone the nice default type syntax15:17
tlater[m]Oh, wait, no, NamedTuple is ok, just not the version syntax15:19
tlater[m]\o/15:19
KinnisonNamedTuple is SLOW15:20
Kinnisonjust to warn you15:20
tlater[m]Kinnison: oh, boo15:23
KinnisonWe tried them back when we were rewriting the yaml handling15:23
Kinnisonturns out they're super-slow15:23
tlater[m]Probably not a good idea to handle all references into CAS through them, then15:23
KinnisonProbably not :-(15:24
benschubertCython in the worst case ;)15:24
* tlater[m] once again is disappointed that python isn't rust15:24
tlater[m]I mean, at this point I'm even annotating my types exactly the same way15:25
*** lachlan has joined #buildstream15:27
bochechatlater[m]: and then you're disappointed that mypy doesn't catch so many issues because the libraries you use don't have type hints?15:29
bochechaand you spend way too long writing stubs?15:29
tlater[m]bochecha: Hah, I don't even trust mypy to begin with because my codebase is old and we've only just started using type hints, so 99% of the time they're just useless15:29
bochechaand you still have to add a bunch of "# type: ignore" comments here and there because mypy is still a work in progress?15:29
bochechaoh wait no, that's me 😭️15:30
bochechato be fair, mypy did find a few bugs in my code which otherwise might have just crashed the app in production15:30
tlater[m]Optional[x] is probably my favorite so far15:30
tlater[m]So many Nones15:31
tlater[m]That said, I'd appreciate a Tython fork15:31
bochechaheh, Optional[x] is in fact the first thing mypy told me15:31
tlater[m]It's what it took to get javascript manageable15:31
*** lachlan has quit IRC15:31
bochechawho knew os.cpu_count() could return None in some cases15:32
bochechaI didn't, but mypy did :)15:32
*** phildawson_ has joined #buildstream15:48
*** phildawson-ct has quit IRC15:49
*** lachlan has joined #buildstream15:52
*** lachlan has quit IRC15:56
*** lachlan has joined #buildstream16:01
*** lachlan has quit IRC16:05
*** lachlan has joined #buildstream16:12
*** lachlan has quit IRC16:19
gitlab-br-botBenjaminSchubert opened MR !1773 (bschubert/fix-resource-deletion->master: _compat.py: Add module to handle version compatibility in python) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/177316:24
benschuberttlater[m]: ^16:24
tlater[m]ta benschubert16:24
tlater[m]benschubert: Just a small nit, otherwise LGTM16:27
benschubertfair point :)16:30
*** santi has quit IRC16:48
*** santi has joined #buildstream17:03
*** lachlan has joined #buildstream17:15
*** lachlan has quit IRC17:22
*** phildawson_ has quit IRC17:28
*** phildawson_ has joined #buildstream17:34
benschuberttme5: also we don't have variables everywhere: e.g. build/runtime-depends are missing17:37
tme5i've been looking at it more and i don't think i'm qualified to make this change17:39
tme5there's this whole thhing of MetaSource which seems to in some way decouple Sources and Elements17:40
*** lachlan has joined #buildstream17:48
*** lachlan has quit IRC17:52
tlater[m]Is there a bug here? If we call .get_digest() before .get_directory() we'll get a None here, no? https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/storage/_casbaseddirectory.py#L7617:53
* tlater[m] wonders if there's any reason we don't just compute the digest at initialization17:54
juergbitlater[m]: the invariant is that always exactly one of digest or buildstream_object is set18:03
juergbiwhen performing modifications, we don't want to recalculate the digest on every change, that would be a lot of overhead18:03
tlater[m]juergbi: It doesn't look like it's guaranteed that one of the two is set just looking at the class18:04
tlater[m]Is that upheld everywhere else?18:04
juergbiit should be. well, both are allowed to be None in case of an empty directory18:05
tlater[m]Looks like a lot of how these entries are created lives in CasBasedDirectory, not in the actual class18:07
tlater[m]Fair enough18:07
tlater[m]This does make it difficult to pass around an immutable sub-portion of it though18:07
tlater[m]Because the digest must be part of it18:07
tlater[m]But it's not actually immutable18:07
*** santi has quit IRC18:08
juergbihm, yes, sounds tricky as we also need to make sure we don't add unnecessary overhead18:08
juergbithe immutable object makes sense for the case where the digest field is valid, but not when the (mutable) buildstream_object is populated18:09
tlater[m]Yup, but that duality can't be avoided18:09
juergbimaybe it would be better to have two separate classes with a shared interface18:10
tlater[m]FrozenIndexEntry?18:11
juergbihowever, that wouldn't allow the `get_directory()` approach to convert between the two18:11
juergbiso it might require changes in multiple places18:11
tlater[m]It would still allow it, you'd just need to call `get_directory()` when you make the entry "frozen"18:11
juergbiget_directory() returns a mutable object. which wouldn't make sense to call on a frozen index entry18:12
tlater[m]Ah, right18:12
tlater[m]But when it's a directory that's inherently frozen, right? Even if we had a second class with the same interface, we wouldn't be able to have directories in it.18:13
tlater[m]s/frozen/mutable/18:13
juergbiright18:14
juergbitlater[m]: a completely different approach might be possible18:14
juergbiI think we only need the diff to apply it exactly once to another directory18:14
juergbiwe could provide this as a single operation in the (internal) API18:14
juergbithat way we wouldn't have to care about potential mutations between diff and apply18:15
tlater[m]i.e., not compute a diff at all but simply move the directory on top of the other?18:15
juergbiit would still have to apply file-based changes. and actually, we could still create a diff internally18:15
tlater[m]Well, yes18:16
juergbithe main point would be to not expose the diff / IndexEntry objects at all outside this file18:16
juergbiwhich would make the mutability aspect much less of an issue18:16
tlater[m]Hm, are you sure we don't need the diff?18:16
juergbinot 100%18:17
tlater[m]I recall traveltissues' algorithm specifying that it would need to look at the diff18:17
tlater[m]Let me double check...18:17
tlater[m]juergbi: https://mail.gnome.org/archives/buildstream-list/2019-October/msg00000.html, btw18:17
tlater[m]I don't think we ever actually use the delta there18:19
juergbiexcept to apply it18:19
tlater[m]Yeah18:19
tlater[m]Ok, in that case that can work18:20
tlater[m]Shame about that immutable internal class though, it made the code a lot neater18:20
juergbiyes18:22
*** tme5 has quit IRC18:26
*** lachlan has joined #buildstream18:28
*** rdale has quit IRC18:34
*** traveltissues has quit IRC18:42
*** phildawson_ has quit IRC18:54
*** lachlan has quit IRC18:58
*** lachlan has joined #buildstream19:09
*** lachlan has quit IRC19:15
*** lachlan has joined #buildstream19:40
*** lachlan has quit IRC19:49
*** lachlan has joined #buildstream19:55
*** lachlan has quit IRC20:09
*** narispo has quit IRC20:26
*** narispo has joined #buildstream20:26
*** lachlan has joined #buildstream20:56
*** lachlan has quit IRC21:03

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!