*** ash has quit IRC | 05:42 | |
*** traveltissues has quit IRC | 05:42 | |
*** benschubert has joined #buildstream | 07:25 | |
juergbi | bwh: 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 IRC | 08:06 | |
*** traveltissues has joined #buildstream | 08:24 | |
*** WSalmon has joined #buildstream | 08:35 | |
*** santi has joined #buildstream | 08:51 | |
douglaswinship | jjardon: '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 |
douglaswinship | is that enough to close https://gitlab.com/BuildStream/buildstream/-/issues/1334#note_370299371 | 12:36 |
douglaswinship | ? | 12:36 |
bwh | juergbi: Main repo, core git plugin | 13:31 |
douglaswinship | Does 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 |
douglaswinship | I'm running "tox -e docs" from the top level directory, which is invoking "make -C docs", which is invoking sphinx | 14:18 |
douglaswinship | And sphinx gets as far as "reading sources", reads them all (reached 100%), then gives a warning and fails. | 14:19 |
douglaswinship | ``` | 14:19 |
douglaswinship | autodoc: failed to import module 'cmake' from module 'elements'; the following exception was raised: | 14:19 |
douglaswinship | No module named 'elements.cmake' | 14:19 |
douglaswinship | ``` | 14:19 |
douglaswinship | And 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 |
douglaswinship | In 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 |
WSalmon | douglaswinship: have you ever built the doc's in the past? | 14:27 |
douglaswinship | nope. This is my first time trying. | 14:28 |
WSalmon | ah, i was wondering if your cmake stuff was left over from a old build | 14:28 |
WSalmon | and a good clean would sort it but probs not if this is your first build | 14:28 |
douglaswinship | clean as in running "make clean"? | 14:29 |
douglaswinship | it's worth a shot | 14:29 |
WSalmon | i was gona go with git clean -fXd or something like that but that will wipe your tox etc so anythign you do will be slow | 14:29 |
douglaswinship | actually "make clean" ws good enough. It built! | 14:30 |
douglaswinship | thanks | 14:30 |
WSalmon | well that a thing | 14:31 |
WSalmon | bwh: i would highly recommend using the git_tag plugin rather than the build in git plugin in core | 14:32 |
bwh | WSalmon: I am using it for building things that are tagged | 14:33 |
WSalmon | bwh: 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_tag | 14:35 |
WSalmon | they called it that cos the first extra feature they added was todo with tags but they behave very similar by default | 14:35 |
coldtom | they behave identically by default only git_tag has had a bunch of bugs fixed | 14:37 |
douglaswinship | I assume there are non-default behaviours that make them different in other situations? | 14:38 |
bwh | This seems very strange to me. Why not replace the core git plugin, or at least apply the fixes? | 14:38 |
douglaswinship | bwh: 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 |
douglaswinship | That's just my guess though. Would be interested to learn more. | 14:40 |
coldtom | bwh: 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 core | 14:40 |
coldtom | as a result the git_tag plugin was born, and nobody ported any later bug fixes back onto the core git plugin | 14:41 |
douglaswinship | But... 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 |
WSalmon | douglaswinship: many plugins are being removed from core in master | 14:43 |
WSalmon | but this will not happen in the stable branches | 14:43 |
douglaswinship | ah, I see. | 14:43 |
douglaswinship | So 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 |
douglaswinship | s/distant/hopefully not too distant/ | 14:44 |
WSalmon | douglaswinship: maybe, probably not tho | 14:45 |
coldtom | i doubt it, the plan is to keep both i believe | 14:51 |
douglaswinship | which brings us back to the original question then. Does git do tings that git_tag doesn't? | 14:51 |
douglaswinship | s/tings/things | 14:51 |
coldtom | on 1.4, not afaik | 14:53 |
coldtom | on 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 date | 14:57 |
*** santi has quit IRC | 16:26 | |
*** santi has joined #buildstream | 16:26 | |
*** cphang has joined #buildstream | 16:31 | |
*** santi has quit IRC | 17:17 | |
*** santi has joined #buildstream | 17:20 | |
*** pointswaves has joined #buildstream | 18:10 | |
*** santi has quit IRC | 18:31 | |
*** benschubert has quit IRC | 20:08 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!