IRC logs for #buildstream for Thursday, 2020-07-16

*** ash has quit IRC05:42
*** traveltissues has quit IRC05:42
*** benschubert has joined #buildstream07:25
juergbibwh: is this for a git submodule or for the main repo? with the core git plugin or git_tag from bst_external?07:50
*** WSalmon has quit IRC08:06
*** traveltissues has joined #buildstream08:24
*** WSalmon has joined #buildstream08:35
*** santi has joined #buildstream08:51
douglaswinshipjjardon: 'overnight-tests' and 'overnight-tests-no-cache' are passing on the latest overnight schedule job. for master. The fedora job and the overnight-random job are still failing.12:36
douglaswinshipis that enough to close https://gitlab.com/BuildStream/buildstream/-/issues/1334#note_37029937112:36
douglaswinship?12:36
bwhjuergbi: Main repo, core git plugin13:31
douglaswinshipDoes anyone know much about how the docs are built in buildstream? I've never worked with sphinx before, and I'm not getting enough from the error messages to figure out what to do.14:18
douglaswinshipI'm running "tox -e docs" from the top level directory, which is invoking "make -C docs", which is invoking sphinx14:18
douglaswinshipAnd sphinx gets as far as "reading sources", reads them all (reached 100%), then gives a warning and fails.14:19
douglaswinship```14:19
douglaswinshipautodoc: failed to import module 'cmake' from module 'elements'; the following exception was raised:14:19
douglaswinshipNo module named 'elements.cmake'14:19
douglaswinship```14:19
douglaswinshipAnd I can't tell if that means I need the module installed locally, or if that's sphinx trying to find the source code of elements.cmake, and read it for its docstrings.14:20
douglaswinshipIn any case, the cmake element code ought to be part of bst-plugins-experimental, not buildstream-proper, I'd have thought? So I don't know why it's coming up like that.14:21
WSalmondouglaswinship: have you ever built the doc's in the past?14:27
douglaswinshipnope. This is my first time trying.14:28
WSalmonah, i was wondering if your cmake stuff was left over from a old build14:28
WSalmonand a good clean would sort it but probs not if this is your first build14:28
douglaswinshipclean as in running "make clean"?14:29
douglaswinshipit's worth a shot14:29
WSalmoni was gona go with git clean -fXd or something like that but that will wipe your tox etc so anythign you do will be slow14:29
douglaswinshipactually "make clean" ws good enough. It built!14:30
douglaswinshipthanks14:30
WSalmonwell that a thing14:31
WSalmonbwh: i would highly recommend using the git_tag plugin rather than the build in git plugin in core14:32
bwhWSalmon: I am using it for building things that are tagged14:33
WSalmonbwh: the name, git_tag is a bit miss leading, its just that the git plugin in core is not loved but the one in https://gitlab.com/BuildStream/bst-external/ is loved and just happens to be called git_tag14:35
WSalmonthey called it that cos the first extra feature they added was todo with tags but they behave very similar by default14:35
coldtomthey behave identically by default only git_tag has had a bunch of bugs fixed14:37
douglaswinshipI assume there are non-default behaviours that make them different in other situations?14:38
bwhThis seems very strange to me. Why not replace the core git plugin, or at least apply the fixes?14:38
douglaswinshipbwh: I think it's the differences. Some people out there are still using the old plugin, (which behaves differently under non_default circumstances), and this would be a breaking change?14:39
douglaswinshipThat's just my guess though. Would be interested to learn more.14:40
coldtombwh: the initial difference was for `bst track` to optionally track to the latest tag on the tracking branch, which was decided wasn't fit for core14:40
coldtomas a result the git_tag plugin was born, and nobody ported any later bug fixes back onto the core git plugin14:41
douglaswinshipBut... if bug_fixes aren't being back-ported, then this becomes the new default one _anyway_. And if it's the new default one, then how can it not be suitable for core?14:42
douglaswinship(unless we just plain don't want a git plugin in core. But then... why keep the old one in?)14:42
WSalmondouglaswinship: many plugins are being removed from core  in master14:43
WSalmonbut this will not happen in the stable branches14:43
douglaswinshipah, I see.14:43
douglaswinshipSo in the distant future when we're all using buildstream 2, there just won't *be* a git plugin. And we'll all be using the (strangely named) git_tag plugin?14:44
douglaswinships/distant/hopefully not too distant/14:44
WSalmondouglaswinship: maybe, probably not tho14:45
coldtomi doubt it, the plan is to keep both i believe14:51
douglaswinshipwhich brings us back to the original question then. Does git do tings that git_tag doesn't?14:51
douglaswinships/tings/things14:51
coldtomon 1.4, not afaik14:53
coldtomon master there is stuff that git does that git_tag doesn't, but there's an abstract git base, which should allow git_tag to keep up to date14:57
*** santi has quit IRC16:26
*** santi has joined #buildstream16:26
*** cphang has joined #buildstream16:31
*** santi has quit IRC17:17
*** santi has joined #buildstream17:20
*** pointswaves has joined #buildstream18:10
*** santi has quit IRC18:31
*** benschubert has quit IRC20:08

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