| *** tristan_ has quit IRC | 04:28 | |
| *** tristan_ has joined #buildstream | 04:54 | |
| *** ChanServ sets mode: +o tristan_ | 06:14 | |
| tristan_ | Fun: AttributeError: 'google.protobuf.pyext._message.RepeatedCompositeCo' object has no attribute 'append' | 06:14 |
|---|---|---|
| tristan_ | This is after `sudo pip3 install -e .` | 06:14 |
| tristan_ | Since `pip3 install --user -e .` fails, apparently a recent regression: https://github.com/pypa/pip/issues/7953 | 06:15 |
| tristan_ | After deleting my old artifact cache, my integration command fails with: Internal job process unexpectedly died with exit code -6 | 06:18 |
| tristan_ | Hrrrrrm a little bit more detail could be nice there | 06:18 |
| tristan_ | Stack trace if this is a bug; clear instructions to fix my installation if this is my fault, would be good | 06:19 |
| tristan_ | eeesh very buggy here, what happened :-S | 06:22 |
| tristan_ | BUG: Message handling out of sync, unable to retrieve failure message for element libhello.bs | 06:22 |
| tristan_ | t | 06:22 |
| tristan_ | python3: ../nptl/pthread_mutex_lock.c:433: __pthread_mutex_lock_full: Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robust' failed. | 06:22 |
| * tristan_ expects this is an installation problem, because bst appears to be working alright in the example docs generation | 06:24 | |
| juergbi | tristan_: the recommendation for development is venv and when you're in a venv you can use `pip3 install -e .` as regular user | 08:38 |
| juergbi | exit code -6 means SIGABRT. that might be an assertion failure in a C library, possibly protobuf/grpc. hence no python stack trace | 08:38 |
| juergbi | what distro version are you on? and what python version? | 08:39 |
| juergbi | valentind has seen an issue with debian sid due to the system-provided protobuf/grpc. however, the latest stable releases of common distros work fine according to CI | 08:40 |
| tristan_ | I've got python 3.7 on debian 9 | 08:53 |
| tristan_ | juergbi, I worked around it with `tox -e venv /bin/bash` | 08:53 |
| tristan_ | But I'd much rather have a user installed buildstream than wrestle with a venv :-S | 08:54 |
| juergbi | venv shouldn't really be much less convenient than user installation. the only extra thing you need is to activate the venv in each shell (and I guess you can do this implicitly if you only/mainly work with a single venv) | 08:59 |
| juergbi | i.e., venv doesn't have to involve tox | 08:59 |
| *** phoenix has joined #buildstream | 08:59 | |
| juergbi | tristan_: btw: as debian 9 comes with python 3.5, we've recently dropped it from CI. I'd suggest upgrading to debian 10, which is tested in CI and already comes with python 3.7 | 09:01 |
| tristan_ | Yeah, activating the venv in each shell, plus the overhead of figuring out how to set it up in the first place | 09:02 |
| * tristan_ finds this really annoying | 09:02 | |
| juergbi | we should definitely write or at least point to some good venv documentation for buildstream | 09:02 |
| * tristan_ was hoping he could still get away with `pip3 install --user -e .`, so long as I don't need 2 buildstreams installed | 09:03 | |
| tristan_ | Or to at least only have *one* of my BuildStreams in a venv | 09:03 |
| juergbi | I was just going to mention, if you still want bst 1.x around, you anyway need a venv | 09:03 |
| juergbi | maybe someone here knows a website with some best practice around python venv | 09:03 |
| * tristan_ recalls being very annoyed with venvs, particularly the aspect that ^D doesnt exit the venv, it kills your terminal (I think it sources a script instead of launching a subshell) | 09:04 | |
| juergbi | you can do either | 09:05 |
| tristan_ | On top of having to you know, actually know how to use the thing, which is a burden too | 09:05 |
| * tristan_ thinks so far that `tox -e venv /bin/bash` so far is going to be the easiest hack | 09:05 | |
| tristan_ | minimal burden of knowledge | 09:06 |
| juergbi | it's not really suitable to multiple shells/terminals, though, right? | 09:06 |
| juergbi | I'm mainly using a non-tox venv | 09:06 |
| juergbi | as that is very quick to enter | 09:07 |
| tristan_ | I think that it will only setup the .tox/ subdir once right ? so once you do it once, the second time is snappy | 09:07 |
| tristan_ | or we have that disabled tox.ini-wide | 09:07 |
| juergbi | it should definitely be faster the second time. however, I think it still takes a couple of seconds or so, far from instant | 09:08 |
| tristan_ | They could be valuable seconds though | 09:08 |
| juergbi | and I'm not sure whether you can keep the tox shell open, modify buildstream and have it owrk | 09:08 |
| tristan_ | I.e. sacrificing those seconds could save you from giving a damn about updated requirements.txt | 09:08 |
| juergbi | yes, that's definitely helpful | 09:09 |
| tristan_ | Yeah that's another aspect, I believe it's possible though | 09:09 |
| tristan_ | to use the develop install mode | 09:09 |
| juergbi | on the other hand, I also occasionally (not often, though) have to call tox --recreate. i.e., it's not completely foolproof either | 09:09 |
| juergbi | btw: the pip3 install --user -e . issue appeared last summer, it's not that recent | 09:11 |
| tristan_ | I suppose the 12 day old report https://github.com/pypa/pip/issues/7953 must be a duplicate | 09:12 |
| * tristan_ was assuming recent regression due to age of the report he found | 09:12 | |
| tristan_ | juergbi, you know oddly, I did work around this first with `sudo` and decided, I'd rather have to just re-install on the system every time than use a venv | 09:14 |
| tristan_ | That's when I got slapped with the grpc stuff though :-/ | 09:15 |
| tristan_ | I think I have a custom 3.7 here, well not custom but manually built | 09:15 |
| juergbi | maybe just setup a single main venv and automatically enter it in your bashrc/profile | 09:15 |
| * tristan_ needed to have every version of python installed to do all his tests locally | 09:15 | |
| tristan_ | I'm surprised I cannot just install on the system though, even if the `--user -e` thing doesnt work, I should at least be able to do that | 09:16 |
| juergbi | right. as test differences across Python versions because of code changes is rare enough in my experience, I only test one Python version locally and leave the rest to CI | 09:16 |
| juergbi | my suspicion is that there is an incompatibility/issue with a system-installed Python package | 09:17 |
| tristan_ | Yeah, I started doing that because I was fixing bugs in the testing itself (parallelism of testing in multiple python versions etc) | 09:17 |
| juergbi | installing in a fresh venv avoids this issue (you can have the venv ignore the system packages) | 09:17 |
| tristan_ | But then it just stuck with me | 09:17 |
| * tristan_ thinks there may be bugs with the "dimming" of cache keys for strict/non-strict artifacts | 09:43 | |
| tristan_ | Anyway, I'll finish writing up this example first and then investigate later... | 09:43 |
| *** tristan_ has quit IRC | 10:00 | |
| *** tristan_ has joined #buildstream | 11:15 | |
| *** ChanServ sets mode: +o tristan_ | 11:16 | |
| tristan_ | juergbi, don't know if you're around anymore but... do you have any idea why a workspaced element would have a different cache key when running `bst --no-strict show` vs `bst --strict show`, given the same set of dependencies that are all unmodified and cached ? | 11:18 |
| tristan_ | my expectation would be for cache keys to only deviate in reverse dependencies of a modified workspaced element | 11:19 |
| juergbi | tristan_: no, can't think of a reason off the top of my head | 11:22 |
| juergbi | unless it shows the weak key in the non-strict case for some reason | 11:23 |
| juergbi | (it shouldn't, though) | 11:24 |
| tristan_ | juergbi, in master, we no longer have that trick where we need to build in order to derive the key of a workspace correct ? | 11:26 |
| * tristan_ confused with this | 11:26 | |
| tristan_ | hmmm | 11:26 |
| * tristan_ is writing an example in the user guide about using non-strict mode, but cannot explain why the workspaced libhello.bst shows up dimmed out in `bst --no-strict show`, and with a different cache key than with --strict | 11:27 | |
| tristan_ | The code does not show the weak key afaics | 11:28 |
| juergbi | tristan_: have you verified that all the build dependencies have the same cache key between the two modes, i.e., is the only cache key difference in the workspace element itself? | 11:32 |
| *** rdale has joined #buildstream | 11:33 | |
| tristan_ | juergbi, yes | 11:34 |
| tristan_ | The dependencies of the workspace are the same with strict or no-strict, the workspace and reverse dependencies are changed | 11:34 |
| juergbi | I'd add a debug print for the cache key dict to find the difference | 11:35 |
| * tristan_ does | 11:38 | |
| *** phoenix has quit IRC | 11:51 | |
| tristan_ | Weird | 11:51 |
| tristan_ | juergbi, in strict mode, the cache key dict of the workspace has: 'dependencies': [['strict-mode', 'base/alpine.bst', 'b795a72d92c05ed0810723f5c3ad40c53bba6e8b568a9d5da22a450a11e03659'], ['strict-mode', 'base.bst', 'e4a4926893ce660306ca9c812fd8018fa41571c27f37fff4a9e6ab592d0333fe']] | 11:52 |
| tristan_ | In non-strict mode, it has: 'dependencies': ['b795a72d92c05ed0810723f5c3ad40c53bba6e8b568a9d5da22a450a11e03659', 'e4a4926893ce660306ca9c812fd8018fa41571c27f37fff4a9e6ab592d0333fe'] | 11:52 |
| tristan_ | but 'grep -r "strict-mode" src/buildstream' yields no results :-S | 11:55 |
| juergbi | strict-mode is the name of the project? | 11:55 |
| juergbi | this looks like a bug | 11:56 |
| tristan_ | Aha yes it is that would explain | 11:56 |
| juergbi | it seems like we have a discrepancy between strong cache key calculations in strict and non-strict mode | 11:56 |
| tristan_ | Ok, I'll first complete the docs I'm working on under the assumption that this get's fixed, then I'll file the issue with the docs as evidence | 11:57 |
| juergbi | dependencies in __update_cache_key_non_strict are missing project name + element name, while __update_cache_keys has it | 11:57 |
| tristan_ | Yeah it's more subtle than that, because the keys are indeed the same for the dependencies of the workspaced element | 11:57 |
| juergbi | in non-strict mode if it finds a dependency matching the strict cache key, we always use that | 11:58 |
| juergbi | the issue only arises if that doesn't exist | 11:58 |
| * tristan_ thinks we don't have very good test coverage for cache keys in non-strict mode + workspaces | 12:04 | |
| tristan_ | only good coverage for regular strong keys | 12:04 |
| juergbi | yes, should add tests with the fix | 12:06 |
| juergbi | tristan_: this untested branch might fix it: https://gitlab.com/BuildStream/buildstream/commits/juerg/cache-key | 12:09 |
| tristan_ | :) | 12:10 |
| *** ikerperez has quit IRC | 12:10 | |
| *** tristan has quit IRC | 12:10 | |
| *** cphang has quit IRC | 12:10 | |
| juergbi | pending test + p ossibly tiny refactoring | 12:10 |
| * tristan_ grabs his nick | 12:10 | |
| *** tristan_ is now known as tristan | 12:10 | |
| tristan | mtimes are still used in workspaces right ? | 12:11 |
| juergbi | yes | 12:11 |
| * tristan got confused for a moment, second time building his example caused workspace cache key to change ;-) | 12:11 | |
| juergbi | yes, an unexpected bug | 12:14 |
| juergbi | we apparently still don't have sufficient non-strict tests | 12:14 |
| *** cphang has joined #buildstream | 12:14 | |
| tristan | So tests for workspace cache keys would have to be in terms of "did it differ" rather than "does it match" | 12:14 |
| juergbi | not quite sure what you mean | 12:15 |
| tristan | mtimes | 12:15 |
| tristan | grrr, /me was hoping that your branch would have warmed up the runners... | 12:15 |
| juergbi | buildstream can't know whether an mtime-only difference has an impact or not | 12:16 |
| juergbi | so mtime differences affect the cache key the same as content changes | 12:16 |
| juergbi | but no other special handling should be needed for workspaces in core code | 12:16 |
| juergbi | ah, sorry, misread your message | 12:17 |
| juergbi | for tests, yes, I think the simplest approach would be to set a specific mtime such that all test invocations are identical | 12:17 |
| juergbi | for cache key checks | 12:18 |
| tristan | That could work, but if you instead open a workspace and then capture it's cache key, you can can later check if strict mode has an effect on that key | 12:18 |
| juergbi | in many other workspace tests the exact cache key is not relevant for the test itself | 12:18 |
| tristan | without adding special hooks in the code | 12:18 |
| tristan | not sure if it covers enough but would cover this case | 12:19 |
| juergbi | btw: this bug is not workspace-specific | 12:19 |
| tristan | I see | 12:19 |
| tristan | Wasn't sure :) | 12:19 |
| juergbi | fortunately, we no longer need special handling of workspaces in cache key code | 12:20 |
| juergbi | but non-strict cache key handling is still not completely trivial | 12:20 |
| tristan | So I've been pondering that old mail thread in the background, about element names and project names having an effect on keys | 12:21 |
| tristan | Wouldn't it be rather "okay" if it still only had an effect on weak keys ? | 12:21 |
| * tristan wonders if there are other side effects of that he didn't consider | 12:22 | |
| juergbi | tristan: the weak cache key is stored in the artifact proto and thus, the strong cache key dict must be a superset of the weak cache key dict | 12:27 |
| juergbi | if the weak cache key could change without the strong cache key changing (when a dependency is renamed), I think there would be odd issues | 12:28 |
| juergbi | and it would definitely also be surprising to me as a user | 12:29 |
| juergbi | (no longer finding artifact in cache in non-strict mode but still finding it in strict mode) | 12:29 |
| tristan | Right | 12:33 |
| tristan | juergbi, I was thinking that last part was an okay tradeoff in order to allow reuse of strong artifacts after a rename | 12:34 |
| tristan | However, I would hope that existing strong artifacts would still be found in non-strict mode | 12:34 |
| juergbi | I'd be worried about exposing such an odd behavior | 12:34 |
| tristan | I'm not sure however why the strong key *must* be a superset of the weak key, this sounds like an implementation detail | 12:34 |
| juergbi | e.g., a CI building latest elements in strict mode wouldn't trigger a rebuild on rename | 12:35 |
| tristan | Currently the mere fact that renaming elements can incur rebuilds is also a worry, though | 12:35 |
| juergbi | which means that as long as that element and dependencies are not modified, non-strict clients wouldn't have it cached anymore | 12:35 |
| tristan | Right, I feel like non-strict mode being unable to find strong artifacts after a rename could be avoided | 12:36 |
| tristan | This appears more to do with addressing of artifacts than their keys | 12:36 |
| juergbi | I don't see how the not finding can be avoided with non-superset strong key | 12:37 |
| juergbi | although we could possibly improve things for the strict CI case such that it would push the new weak key references | 12:38 |
| tristan | Well, if the artifact lookups are done by key only, then the strong keys are always nameless | 12:38 |
| tristan | even in non-strict mode, I think we first search for a strong (strict) key | 12:38 |
| tristan | In the case that you fallback on one which doesnt match your strict key, then you get something with names, and only that breaks (and eventually gets purged/expired from a shared cache) | 12:39 |
| juergbi | right, it would still find by strict key | 12:39 |
| tristan | Right, even if you're in non-strict mode, your strong artifact cache keys will still remain useful, you only lose the weak keys | 12:39 |
| juergbi | we would definitely have to rip out weak cache key and dependency names from the artifact proto | 12:39 |
| juergbi | I don't know right now what issues this might cause | 12:39 |
| tristan | Right I'm not sure about implementation details, I'm just thinking that the tradeoff appears to be worthwhile | 12:40 |
| juergbi | e.g., downloading a strict key would no longer allow creating a weak key link using artifact proto | 12:40 |
| juergbi | in some cases we can use the calculated weak key instead but there might be important cases where that's not possible | 12:41 |
| juergbi | have to check each place where we currently use that artifact proto info | 12:41 |
| juergbi | i.e., I can't say off the top of my head whether these would only be implementation details or whether this would cause fundamental issues | 12:42 |
| tristan | :) | 12:43 |
| tristan | BTW: https://buildstream.gitlab.io/-/buildstream/-/jobs/508555828/artifacts/public/main_using.html | 12:43 |
| tristan | I've got two new sections in there; Directives and Strict mode (also Junctions with includes but that's still WIP) | 12:43 |
| tristan | And a bit of a renaming of sections job, also split up the "Junctions" part into two pages, not to confound the already complex material about creating junctions with the aspect of workspaces | 12:45 |
| tristan | Looking better I think | 12:45 |
| tristan | More like a user manual :) | 12:45 |
| juergbi | nice, will try to take a closer look later | 12:46 |
| * tristan thinks he'd like to see a new whole section about "Manipulating files", where we could discuss overlaps, split rules, and usage of filter and compose elements | 12:46 | |
| * tristan originally thought that could go into the first chapter but I think it's a bit too much for "Getting started" | 12:46 | |
| juergbi | yes, a separate section for file handling seems reasonable | 12:48 |
| tristan | bwaaaahahaha | 12:51 |
| tristan | when viewing $@ (in the context of Makefile example in the docs at least when viewed there on gitlab).... they get replaced with "[email protected]" | 12:52 |
| tristan | e.g.: https://buildstream.gitlab.io/-/buildstream/-/jobs/508555828/artifacts/public/developing/strict-mode.html#files-libhello-makefile | 12:52 |
| tristan | I suspect it wont do that on the website though | 12:52 |
| juergbi | hm, it's a job artifact. I wouldn't expect gitlab to mangle it | 12:57 |
| juergbi | but seems to be the case indeed | 12:58 |
| tristan | Browsing the locally built stuff in file://... does not do that for me | 12:58 |
| *** d55c749a has joined #buildstream | 12:58 | |
| juergbi | yes, really seems to be gitlab censoring | 12:58 |
| *** d55c749a has quit IRC | 13:04 | |
| tristan | ... some cache keys are ephemeral ... | 13:06 |
| *** tristan has quit IRC | 13:17 | |
| valentind | between 1.4.1 and the current tip of bst-1, there is a difference in cache key. The file https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/076fe9d30f37224a1bd756a177e33399dad37e8d/elements/components/jpeg.bst gets 1975408718d400d75839763116b1ce6b50562aca5a78fc06e853e0189c87b241 in 1.4.1 but 23bb7315065cf2bd92b120dd9513e9dd841a4ef135a828c67750fbac02dc84ee in bst-1 | 14:38 |
| abderrahim[m] | valentind: it's !1549 | 14:40 |
| gitlab-br-bot | MR !1549: plugins/elements/cmake.yaml: always specify variable types https://gitlab.com/BuildStream/buildstream/-/merge_requests/1549 | 14:40 |
| valentind | OK, good it is known. | 14:40 |
| *** tristan has joined #buildstream | 14:46 | |
| *** ChanServ sets mode: +o tristan | 15:26 | |
| *** phoenix has joined #buildstream | 17:38 | |
| *** keisha has joined #buildstream | 18:08 | |
| *** keisha has quit IRC | 18:36 | |
| *** keisha has joined #buildstream | 18:44 | |
| *** toscalix has joined #buildstream | 18:49 | |
| *** keisha has quit IRC | 19:02 | |
| *** keisha has joined #buildstream | 19:10 | |
| *** keisha has quit IRC | 19:24 | |
| *** rdale has quit IRC | 19:49 | |
| *** toscalix has quit IRC | 21:23 | |
| jjardon | Is there no tests to detect changes in the cache key? | 21:57 |
| jjardon | I'd assume this should have been detected in the MR CI? | 21:58 |
| *** phoenix has quit IRC | 22:02 | |
| *** lachlan has joined #buildstream | 22:11 | |
| *** lachlan has quit IRC | 22:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!