gitlab-br-bot | buildstream: merge request (edbaunton/executable-remote-source->master: remote.py: Add support for marking downloaded files executable) #581 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/581 | 00:37 |
---|---|---|
gitlab-br-bot | buildstream: issue #551 ("Artifacts are being pushed just after being pulled from the CAS cache") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/551 | 01:30 |
gitlab-br-bot | buildstream: merge request (edbaunton/executable-remote-source->master: remote.py: Add support for marking downloaded files executable) #581 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/581 | 02:00 |
*** ErrantEgo has joined #buildstream | 03:05 | |
*** leopi has joined #buildstream | 08:18 | |
*** tristan has joined #buildstream | 08:48 | |
*** tristan_ has joined #buildstream | 08:48 | |
gitlab-br-bot | buildstream: merge request (edbaunton/doc-typo->master: element.py (docs): dashes not underscores for build and install root) #577 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/577 | 08:55 |
*** bochecha has joined #buildstream | 08:59 | |
tristan_ | bochecha, just wanted to say thanks for looking into packaging BuildStream in fedora ! | 09:49 |
bochecha | tristan_: no problem | 09:49 |
bochecha | I'm having trouble with grpcio at the moment, though | 09:49 |
tristan_ | ah, try to ping juergbi during the week about that; as I understand it there is some code generation, and committed results of code generation in order to easy the `pip install` case | 09:50 |
tristan_ | but I'm not familiar with all the details | 09:50 |
tristan_ | s/easy/ease | 09:50 |
bochecha | oh, the problem is not in BuildStream | 09:52 |
bochecha | grpcio isn't packaged at all in Fedora, so I need to package that first | 09:52 |
bochecha | and building grpcio fails on Rawhide | 09:52 |
bochecha | for some reason it doesn't find Python.h :-/ | 09:52 |
tristan_ | ah I see | 10:01 |
tristan_ | Python.h is probably from a cpython dev package ? | 10:02 |
bochecha | yes | 10:03 |
bochecha | which I have installed in the build root | 10:03 |
bochecha | the package builds fine on F28, but not on Rawhide | 10:03 |
bochecha | the only difference I can see is that Rawhide has python 3.7, which F28 has 3.6 | 10:04 |
bochecha | but that shouldn't cause any problem… | 10:04 |
gitlab-br-bot | buildstream: issue #331 ("Project configuration required is too much") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/331 | 10:06 |
gitlab-br-bot | buildstream: merge request (edbaunton/doc-typo->master: element.py (docs): dashes not underscores for build and install root) #577 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/577 | 10:08 |
gitlab-br-bot | buildstream: merge request (tiagogomes/issue-520->master: Fix race condition when calculating disk usage) #600 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/600 | 10:10 |
*** leopi has quit IRC | 11:04 | |
*** leopi has joined #buildstream | 11:08 | |
*** holodoc has joined #buildstream | 11:15 | |
gitlab-br-bot | buildstream: issue #552 ("Add documentation for the element states during a build") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/552 | 12:04 |
gitlab-br-bot | buildstream: merge request (adamjones/systemd-cas->master: Include systemd file examples for google-cas cache) #524 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/524 | 12:07 |
*** lantw44 has joined #buildstream | 12:21 | |
gitlab-br-bot | buildstream: merge request (jjardon/out-of-tree->master: WIP: buildstream/plugins/elements/autotools.yaml: Make builds out of tree by default) #175 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/175 | 12:28 |
*** mat has joined #buildstream | 12:33 | |
*** leopi has quit IRC | 13:31 | |
*** nurupo has joined #buildstream | 13:35 | |
*** leopi has joined #buildstream | 13:41 | |
*** NyanCat has joined #buildstream | 14:15 | |
bochecha | Traceback (most recent call last): | 14:41 |
bochecha | File "/builddir/build/BUILD/buildstream-1.1.4/doc/bst2html.py", line 38, in <module> | 14:41 |
bochecha | from buildstream import _yaml | 14:41 |
bochecha | ModuleNotFoundError: No module named 'buildstream' | 14:41 |
bochecha | I'm getting that when trying to build the docs in the rpm package | 14:42 |
bochecha | seems the build script requires buildstream to be installed… | 14:42 |
tristan_ | bochecha, the docs dont build without buildstream being installed, indeed | 14:42 |
bochecha | that's not great :-/ | 14:42 |
bochecha | it's pretty much a requirement for distro packages (or the docs could be pre-built in the tarball I guess) | 14:43 |
bochecha | I mean, I can do `PYTHONPATH=.. make all` for now in the package, that works | 14:43 |
bochecha | would be better if the Makefile did it, though? :P | 14:44 |
tristan_ | I agree it's not great, it hasnt been a requirement thus far so havent been correcting it | 14:44 |
tristan_ | bochecha, an option is to use a python venv | 14:44 |
tristan_ | I think that would work fine | 14:44 |
bochecha | not going to use a venv in a rpm package :) | 14:44 |
tristan_ | I mean, as a part of the process of building the docs for an rpm package ? | 14:44 |
tristan_ | not sure how straight forward that would be, though | 14:45 |
tristan_ | oh, PYTHONPATH works ? | 14:45 |
bochecha | like I said, setting PYTHONPATH=.. works | 14:45 |
tristan_ | that seems not too bad | 14:45 |
bochecha | it's just much simpler :) | 14:45 |
tristan_ | yeah | 14:45 |
bochecha | well, I think it works | 14:45 |
bochecha | haven't finished a full build yet | 14:45 |
bochecha | but at least it managed to import the buildstream module | 14:45 |
tristan_ | it has to "work", not sure if it will | 14:46 |
tristan_ | but if the deps are all in the build environment I guess it should | 14:46 |
tristan_ | note: it has to work because we run buildstream (the bst2html thing you mentioned) in order to generate some of the colorized output which goes into the examples | 14:46 |
tristan_ | but I guess it will work | 14:47 |
bochecha | well, the good thing is that it means if I manage to build the docs, then I'm sure I have all the dependencies :) | 14:48 |
bochecha | (as long as all of buildstream is documented, of course) | 14:49 |
tristan_ | if you pass setup.py you should have everything you need yes; however... you need additional things for docs building, than you need for BuildStream | 14:50 |
tristan_ | i.e. if you don't have ostree and python-gi, then BuildStream will work fine | 14:50 |
bochecha | setup.py doesn't check for fuse, ostree or gi | 14:51 |
bochecha | also, PYTHONPATH doesn't work | 14:51 |
tristan_ | it will correctly abort early, and tell you that you need to install ostree, if your project uses ostree | 14:51 |
bochecha | the Makefile sets PYTHONPATH already | 14:51 |
bochecha | so it overrides what I had set :( | 14:51 |
tristan_ | or, if it doesnt, that's a bug (since ostree dep disappeared from core recently, maybe we need to fix it) | 14:51 |
tristan_ | Also, you probably need git for docs building | 14:52 |
tristan_ | cause some of the examples will use the git plugin which requires host git | 14:52 |
tristan_ | bochecha, I'm perfectly amenable to including prebuilt docs in the release tarballs, but I'm not sure right now what is the easier fix (extending setuptools's sdist command can also be complicated) | 14:54 |
tristan_ | it would be ideally better, if building docs worked from git-or-tarball, of course | 14:54 |
*** leopi has quit IRC | 15:02 | |
bochecha | tristan_: yeah, docs should be able to build from git or tarball; and they shouldn't be built for the installed buildstream, but for the one in the source tree | 15:21 |
bochecha | I think I have a patch, testing it right now | 15:21 |
bochecha | tristan_: got it working I think | 15:35 |
bochecha | ModuleNotFoundError: No module named 'google' | 15:45 |
bochecha | I… huh… is there really a "google" python module? o_O | 15:45 |
bochecha | ah, that seems to be protobuf maybe | 15:46 |
tristan_ | yeah if we can get the docs to build without install that'd be idea | 16:01 |
tristan_ | l | 16:01 |
bochecha | almost got them :) | 16:08 |
bochecha | I'm still fishing for missing modules | 16:08 |
bochecha | arpy isn't in Fedora, so I have to package that first | 16:08 |
tristan_ | arpy is optional and only used for treating debian packages as if they were tarballs, iirc | 16:15 |
bochecha | the docs fail to build without it | 16:15 |
tristan_ | still good to have, but don't know if the BuildStream package itself should depend directly on it | 16:15 |
tristan_ | ah, probably it has an example which uses it, then | 16:15 |
bochecha | plus, I'd rather package bst with all its deps, so that it's not limited artificially | 16:16 |
tristan_ | of course | 16:16 |
bochecha | how would you see the packaging? | 16:16 |
bochecha | everything in one "buildstream" package? | 16:16 |
bochecha | or split the plugins into multiple buildstream-plugins-* packages? | 16:16 |
tristan_ | From what it installed from the buildstream repo, I think should go into one package | 16:17 |
bochecha | (I'd prefer everything in one, it's easier to maintain and less confusing for users) | 16:17 |
tristan_ | it really is core plugins, and there is a distinction | 16:17 |
bochecha | yeah, I'm thinking of doing a second bst-external package | 16:17 |
bochecha | or maybe calling it buildstream-plugins-external or something | 16:17 |
tristan_ | right, I was thinking of bst-external, that one contains stuff that is not really ready for prime time (API is not considered stable there for now) | 16:18 |
bochecha | and have the main buildstream package Recommends or Suggests it | 16:18 |
tristan_ | so, that is a bit ambiguous | 16:18 |
tristan_ | right now we suggest that people who use bst-external and need those things in a consistent/stable state, use it as a git submodule of their buildstream project repo, and use the plugins as local plugins | 16:19 |
tristan_ | but external plugin loading needs to be hardened in general I think | 16:19 |
bochecha | ok, so maybe I shouldn't package that then, if that's the upstream recommended way to use them | 16:20 |
tristan_ | I think it might be better not to, it could result in misguided expectations | 16:20 |
bochecha | again… less work for me :D | 16:21 |
bochecha | it builds! | 16:22 |
bochecha | should I send the MR against master? will that get it into the next release? | 16:23 |
tristan_ | nice ! | 16:23 |
tristan_ | bochecha, master always first; but yeah we will have to backport it to bst-1.2 branch | 16:24 |
bochecha | it applies with fuzz | 16:24 |
bochecha | well | 16:24 |
bochecha | I made it on master, but it applies with fuzz on 1.1.4 (which is what I packaged) | 16:25 |
tristan_ | bochecha, one thing though... our CI builds docs from an installed package | 16:25 |
tristan_ | you probably want to change that in the .gitlab-ci.yml, to ensure we never regress it | 16:25 |
bochecha | indeed | 16:25 |
gitlab-br-bot | buildstream: merge request (bochecha/build-docs->master: doc: Build the docs without Buildstream installed) #603 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/603 | 16:32 |
bochecha | tristan_: ---^ | 16:32 |
bochecha | running the tests in the package will be harder, there are quite a few modules which don't exist in Fedora, or in the wrong versions :( | 16:35 |
bochecha | I don't understand why the CI failed :-/ | 16:36 |
tristan_ | https://gitlab.com/BuildStream/buildstream/pipelines/27181796 ? | 16:36 |
tristan_ | did it fail ? | 16:36 |
bochecha | it did: https://gitlab.com/BuildStream/buildstream/pipelines/27181735 | 16:37 |
bochecha | oh, maybe that's the first one | 16:37 |
bochecha | I forced push very quickly, so maybe the CI couldn't find the previous git commit after I forced-push :) | 16:37 |
tristan_ | yeah, that happens | 16:38 |
tristan_ | oops | 16:41 |
tristan_ | aha | 16:41 |
tristan_ | yeah it's gonna be tougher than this | 16:41 |
bochecha | how come? | 16:41 |
bochecha | why did it need to run bst? o_O | 16:41 |
tristan_ | https://gitlab.com/BuildStream/buildstream/-/jobs/86843089 is because of bst2html I suppose... | 16:41 |
bochecha | but in my package bst2html is run | 16:42 |
bochecha | and the bst command doesn't exist there either | 16:42 |
tristan_ | bst2html.py:run_command() needs to import the cli and run it directly | 16:42 |
tristan_ | I guess | 16:42 |
tristan_ | weird | 16:42 |
bochecha | why wasn't that run in my package then? :-/ | 16:43 |
tristan_ | weird that it would work; the bst command itself is generated by setup.py | 16:43 |
bochecha | ah, --force | 16:43 |
bochecha | the CI sets BST_FORCE_SESSION_REBUILD | 16:43 |
bochecha | I don't | 16:43 |
bochecha | that's the difference | 16:43 |
bochecha | so in the package, I end up not rebuilding those "sessions" | 16:44 |
bochecha | what are sessions by the way? | 16:44 |
tristan_ | aha interesting | 16:44 |
tristan_ | bochecha, http://buildstream.gitlab.io/buildstream/tutorial/first-project.html#build-the-element | 16:45 |
tristan_ | for example | 16:45 |
bochecha | the page doesn't seem to talk about sessions :-/ | 16:45 |
tristan_ | bochecha, the examples in http://buildstream.gitlab.io/buildstream/main_using.html, use the output of a bst session to generate the docs | 16:45 |
bochecha | oooooh | 16:45 |
bochecha | it's a shell session! | 16:45 |
tristan_ | yeah, we force the colors, and then convert that to html for the docs :) | 16:46 |
bochecha | ah, and there are some stored in git/tarball | 16:47 |
bochecha | hmmm | 16:47 |
bochecha | so basically, the docs can't be fully built without bst being installed :( | 16:47 |
tristan_ | bochecha, as a hint... tests/testutils/runcli.py does something way above and beyond what we need to do in docs/bst2html.py | 16:47 |
bochecha | do you have to change those stored sessions every time someone makes a change which impacts the output? | 16:47 |
tristan_ | bochecha, not entirely... i.e. we render what the command was, the shell is not really real | 16:47 |
tristan_ | we only care about capturing the stdout/stderr together in the same stream | 16:48 |
tristan_ | we certainly want the CI to rebuild them every time, because any change we make in the UI, is automatically reflected and changed in the docs, which are automatically deployed from CI | 16:48 |
bochecha | sure, but not in the tarball/git? | 16:49 |
tristan_ | so the shell prompt is totally faked by bst2html.py, it just needs to invoke _frontend/cli.py and capture the output | 16:49 |
tristan_ | bochecha, the reason why we commit the session files to the repo... is so that a developer who wants to make a change to the docs can do it without having to wait to build everything | 16:50 |
bochecha | yeah, but are they kept up to date when developers change things? | 16:51 |
tristan_ | I suspect people who want to make some touch ups will want to build the docs locally, but not wait for the example sessions to build | 16:51 |
bochecha | if not, then in the package I have to force-rebuid them like in the CI | 16:51 |
tristan_ | Well, that is a bit ambiguous, ideally indeed they should be force rebuilt for a package; but that will require that building the package has internet access, which is errrm, not playing fair | 16:52 |
tristan_ | so, another approach would be to say, that like man pages, we should update them with every release | 16:52 |
tristan_ | in order to avoid the network requirement for a package build, which I suspect is not supposed to be allowed to connect to the internet | 16:53 |
* tristan_ not really sure how the packaging stuff works in practice, but presumes that distros use stable / sandboxed stuff like OBS | 16:53 | |
tristan_ | bochecha, at least for the bst2html.py stuff, we could have an easier approach of adding an `if bla bla == __main__` in _frontend/cli.py, and run that directly from bst2html.py | 16:56 |
tristan_ | (that is more straight forward than trying to replicate what we do for pytest) | 16:56 |
bochecha | right, the build will not have network access (Fedora build system enforces that) | 16:56 |
bochecha | (it builds in a chroot, populated exclusively of packages that are in Fedora, and network is blocked) | 16:57 |
tristan_ | so in that case, I'll make sure they are updated along with releases | 16:57 |
tristan_ | so at least from a release tag, you'll have up to date sessions | 16:57 |
bochecha | 👍 | 16:57 |
* tristan_ will have to add that to some docs about how we do releases | 16:58 | |
bochecha | huh | 16:59 |
bochecha | so tests/testutils/runcli.py eventually does buildstream._frontend.cli.main(…) | 16:59 |
bochecha | but there's no main() in buildstream/_frontend/cli.py ? | 17:00 |
bochecha | oh | 17:01 |
bochecha | click.BaseCommand.main = override_main | 17:01 |
bochecha | it's a click thing, ok | 17:02 |
tristan_ | bochecha, yeah forget testutils, lets add a clause and shebang to cli.py for this purpose | 17:04 |
tristan_ | http://click.pocoo.org/5/ | 17:05 |
tristan_ | shows that you should be able to just run cli() with no args, and click will take care of it | 17:05 |
bochecha | I got it to build | 17:07 |
bochecha | from buildstream._frontend import cli as bst_cli | 17:07 |
bochecha | args = ['--colors', '--config', config_file, '--directory', directory] + shlex.split(command) | 17:07 |
bochecha | bst_cli.main(args=args, prog_name=bst_cli.name) | 17:07 |
bochecha | the problem is capturing the output | 17:07 |
tristan_ | exactly :) | 17:07 |
bochecha | so… | 17:08 |
tristan_ | but if you add `if __name__ == '__main__': cli()` at the bottom of cli.py | 17:08 |
bochecha | want me to add the if __name__ stuff to cli.py, then subprocess.Popen(['python3', '../buildstream/_frontend/cli.py', … ? | 17:08 |
tristan_ | then you can have bst2html.py just run `python2 path/to/_frontend/cli.py` and it should work | 17:09 |
tristan_ | bochecha, yeah, with a comment on that clause that it's used for generating docs :) | 17:09 |
bochecha | python3 :P | 17:09 |
tristan_ | ooooops | 17:09 |
tristan_ | typo | 17:09 |
tristan_ | haha | 17:09 |
tristan_ | funny I dint land on 4 or 5 | 17:09 |
bochecha | let's see how it goes | 17:13 |
bochecha | /home/mathieu/Projects/buildstream/doc/source/tutorial/first-project.rst:32:Include file '/home/mathieu/Projects/buildstream/doc/examples/first-project/project.conf' not found or reading it failed | 17:14 |
*** leopi has joined #buildstream | 17:14 | |
bochecha | that file exists, but somehow it gets removed when I run `BST_FORCE_SESSION_REBUILD=1 make all` :-/ | 17:15 |
bochecha | hahahaha | 17:19 |
bochecha | now the sessions contain: | 17:19 |
bochecha | ../buildstream/_frontend/cli.py | 17:19 |
bochecha | python3: can't open file '../buildstream/_frontend/cli.py': [Errno 2] No such file or directory | 17:19 |
bochecha | because of course, the cwd is changed for those Popen | 17:19 |
bochecha | tristan_: I don't think we can make this work with the `if __name__` trick | 17:22 |
bochecha | +Traceback (most recent call last): | 17:22 |
bochecha | + File "/home/user/Projects/buildstream/doc/../buildstream/_frontend/cli.py", line 5, in <module> | 17:22 |
bochecha | + from .. import _yaml | 17:23 |
bochecha | +ValueError: attempted relative import beyond top-level package | 17:23 |
csoriano | is it possible to build gtk master? | 17:52 |
csoriano | it says: | 17:52 |
csoriano | /home/csoriano/.cache/buildstream/build/freedesktop-sdk-kck9o52f/sdk/project.conf [line 8 column 14]: Specified path 'elements' must not lead outside of the project directory | 17:52 |
csoriano | when doing bst build --track-all core-deps/gtk+.bst | 17:52 |
bochecha | csoriano: what exactly are you doing? | 17:57 |
csoriano | bst build --track-all core-deps/gtk+.bst | 17:57 |
bochecha | your current directory, etc… | 17:58 |
bochecha | the log file seems to indicate you're in the freedesktop-sdk | 17:58 |
bochecha | but the core-deps/gtk.bst filename suggests you're in gnome-build-meta | 17:58 |
csoriano | current directory..? Didn't know that matters | 17:58 |
csoriano | I followed https://wiki.gnome.org/Newcomers/BuildSystemComponent | 17:58 |
bochecha | well of course it does, bst finds the project.conf in your current dir :) | 17:58 |
bochecha | (unless you explicitly specify it, I think there's an option) | 17:59 |
csoriano | I'm in the gnome-build-meta source directory | 17:59 |
bochecha | why is it talking about freedesktop-sdk then… :-/ | 18:00 |
csoriano | no idea... | 18:00 |
tristan_ | gah | 18:03 |
* tristan_ palmface | 18:04 | |
tristan_ | csoriano, this is because of https://gitlab.com/BuildStream/buildstream/issues/195, I've been waiting on freedesktop-sdk to fix it before plugging up the problem in BuildStream | 18:05 |
tristan_ | jjardon, said I should fix it first, and they will adapt | 18:05 |
tristan_ | but now, disaster strikes /o\ | 18:06 |
csoriano | pity... | 18:06 |
csoriano | seems it's marked as a priotity though, I guess it will be fixed eventually :) | 18:06 |
tristan_ | 5171cb0ebc9f5d372820e33463b4192fbbc6ec64 | 18:06 |
csoriano | for now I set up a flatpak manifest for what I want to do, seems it works | 18:06 |
tristan_ | csoriano, for right now, until I guess next week when freedesktop is fixed, the above commit is before the breakage | 18:07 |
tristan_ | (i.e. that commit in the BuildStream repo) | 18:07 |
csoriano | oh cool, will try later on, thanks! | 18:07 |
tristan_ | I'll send some emails to the list with a release on monday, but fyi will be recommending bst-1.2 branch | 18:08 |
tristan_ | bochecha, aha, I didnt realize python couldnt discover it's being launched from a subpackage | 18:09 |
tristan_ | bochecha, I guess a solution for this would have to live in a private file in the toplevel ? | 18:10 |
csoriano | tristan_: maybe you want to put that info in that guide? | 18:10 |
tristan_ | if __name__ trick hmmm, not sure where, maybe even in toplevel __init__.py ? | 18:10 |
tristan_ | csoriano, yes, that is a hot topic as well, not having a website makes things a bit tricky | 18:11 |
csoriano | I mean there's the wiki | 18:11 |
tristan_ | but at least the install guide in the docs needs to say something | 18:11 |
csoriano | that should enough, isn't it? | 18:11 |
tristan_ | and I guess the wiki (I keep forgetting that anyone ever looks at the wiki...) | 18:11 |
csoriano | the install guide heps you isntall | 18:12 |
csoriano | but nothing more | 18:12 |
csoriano | then the wiki makes you to actually build | 18:12 |
csoriano | right? | 18:12 |
tristan_ | yeah, but currently the instructions from git leads one to believe that master branch is a decent choice | 18:12 |
tristan_ | csoriano, ohh, you mean the newcommers wiki page | 18:13 |
tristan_ | yes there too | 18:13 |
tristan_ | when I think wiki page, I think https://wiki.gnome.org/Projects/BuildStream | 18:13 |
csoriano | yeah, the guide where it says how to build GNOME stack | 18:14 |
tristan_ | https://gitlab.com/BuildStream/buildstream/issues/528 <-- discussion about communicating the intended release tag | 18:15 |
tristan_ | ideally, we should not have to update too many things with every version bump but refer to a download page or install page which says the right thing | 18:15 |
tristan_ | but indeed, that wiki page deserves an update in the short term | 18:16 |
*** leopi has quit IRC | 18:16 | |
csoriano | oh I see lot of things moving | 18:16 |
csoriano | I guess I'll wait a bit to settle down | 18:17 |
jjardon | tristan_: I said you will not break freedesktop-sdk, gnome-build-meta CI, not you will not break any other project / use case | 18:23 |
jjardon | tristan_: we already live in the limit using random versions from git (in the CI); as I said several times if you release tags more often it would be easier for us upstream document what exact version recommend to use for our users | 18:25 |
bochecha | tristan_: I think I got it working with cli.main(…) | 18:25 |
* jjardon updates https://wiki.gnome.org/Newcomers/BuildSystemComponent | 18:27 | |
jjardon | csoriano: ^ | 18:27 |
tristan_ | jjardon, it doesnt matter at this point what was said and how it was understood, the result is that now fixing freedesktop to not do this ../ stuff became a huge priority | 18:28 |
tristan_ | I overlooked that it would break `bst build` cases for GNOME on the latest of bst-1.2 branch | 18:29 |
tristan_ | that's my fault | 18:29 |
csoriano | jjardon: thanks \m/. Are you sure you pressed save though? The content didn't change | 18:31 |
jjardon | csoriano: I'm still editing | 18:31 |
csoriano | oh ok | 18:32 |
jjardon | csoriano: updated! | 18:33 |
jjardon | tristan_: you might want to tag that commit | 18:35 |
bochecha | those docs are a bit long to build :P | 18:40 |
tristan_ | jjardon, having CI use a sha or specific tag is alright, I'm not about to release 1.1.5 on monday and recommend that users use a sha or older tag | 19:11 |
tristan_ | jjardon, the only way out of the mess, is to fix freedesktop-sdk, or revert the patch until freedesktop-sdk is fixed | 19:11 |
jjardon | tristan_: ok, I'd say revert the patch in buildstream is the quickest solution then | 19:12 |
gitlab-br-bot | buildstream: merge request (bochecha/build-docs->master: doc: Build the docs without Buildstream installed) #603 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/603 | 19:16 |
tristan_ | I can do that, it's still a blocker to 1.2 though | 19:17 |
bochecha | if anyone is on Fedora and wants to try something new: https://copr.fedorainfracloud.org/coprs/bochecha/buildstream/ | 19:34 |
bochecha | I won't push the packages in Fedora proper for now, for 2 reasons | 19:34 |
bochecha | 1. I'd like to test them a bit first :) | 19:34 |
bochecha | 2. I can't use those packages yet, because in freedesktop-sdk we require a more recent version of buildstream than the latest release | 19:35 |
bochecha | but they should work | 19:35 |
jjardon | amazing! thanks bochecha | 19:41 |
*** leopi has joined #buildstream | 19:48 | |
gitlab-br-bot | buildstream: merge request (bochecha/fedora-packages->master: WIP: doc: Mention the Fedora packages) #604 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/604 | 20:08 |
tristan_ | oh | 20:18 |
tristan_ | bochecha, no joy on launching bst with an `if __name__ bla bla` hack ? | 20:19 |
tristan_ | bochecha, problem is, we need stdout/stderr, in sequence, not separate | 20:19 |
bochecha | huh? stderr is completely ignored isn't it? | 20:19 |
tristan_ | most of the UI goes through stderr, output from bst show and the like is parsable and scriptable, that goes to stdout | 20:20 |
bochecha | oh no! | 20:20 |
bochecha | Popen(…, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) | 20:20 |
bochecha | I misread that | 20:20 |
bochecha | I read stderr=subprocess.PIPE | 20:20 |
tristan_ | yeah :-S | 20:20 |
bochecha | ah yes, in this case I broke the docs :) | 20:20 |
tristan_ | it's also important that it's serialized, soooo... :-S | 20:21 |
bochecha | I wonder if it works if I use the same StringIO for both :x | 20:21 |
tristan_ | That might ! | 20:21 |
bochecha | wait, how did it even work? | 20:23 |
bochecha | out.decode() when out is a StringIO? | 20:23 |
bochecha | huh | 20:23 |
*** jackmcbarn0 has joined #buildstream | 20:25 | |
*** tristan_ has quit IRC | 20:40 | |
*** leopi has quit IRC | 20:42 | |
*** leopi has joined #buildstream | 20:45 | |
gitlab-br-bot | buildstream: merge request (bochecha/build-docs->master: doc: Build the docs without Buildstream installed) #603 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/603 | 21:02 |
*** leopi has quit IRC | 21:44 | |
*** noisecell has joined #buildstream | 23:16 | |
*** noisecell has quit IRC | 23:17 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!