| gitlab-br-bot | buildstream: merge request (jjardon/cmake_build->master: buildstream/plugins/elements/cmake.yaml: Always create build folder) #173 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/173 | 00:03 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (jjardon/cmake_build->master: buildstream/plugins/elements/cmake.yaml: Always create build folder) #173 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/173 | 00:10 |
| *** tristan has joined #buildstream | 03:09 | |
| *** mcatanzaro has quit IRC | 04:29 | |
| *** tristan has quit IRC | 05:01 | |
| *** tristan has joined #buildstream | 05:03 | |
| gitlab-br-bot | buildstream: merge request (issue-159->master: update install instructions for Debian (fix #159)) #172 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/172 | 07:26 |
| *** tiago has quit IRC | 09:43 | |
| *** bethw has joined #buildstream | 09:55 | |
| *** tpollard has joined #buildstream | 09:55 | |
| *** ssam2 has joined #buildstream | 10:10 | |
| *** WSalmon has joined #buildstream | 10:27 | |
| *** bochecha has joined #buildstream | 12:32 | |
| *** mcatanzaro has joined #buildstream | 12:46 | |
| *** tiago has joined #buildstream | 12:56 | |
| *** cs_shadow has joined #buildstream | 13:28 | |
| gitlab-br-bot | buildstream: merge request (jjardon/cmake_build->master: buildstream/plugins/elements/cmake.yaml: Always create build folder) #173 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/173 | 13:31 |
| gitlab-br-bot | buildstream: merge request (jjardon/cmake_build->master: buildstream/plugins/elements/cmake.yaml: Always create build folder) #173 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/173 | 15:00 |
| *** bochecha has quit IRC | 15:50 | |
| *** bochecha has joined #buildstream | 15:54 | |
| *** bochecha has quit IRC | 15:57 | |
| gitlab-br-bot | buildstream: issue #159 (""BuildStream on your host" docs not accurate") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/159 | 16:11 |
| gitlab-br-bot | buildstream: issue #159 (""BuildStream on your host" docs not accurate") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/159 | 16:12 |
| gitlab-br-bot | buildstream: merge request (issue-159->master: update install instructions for Debian (fix #159)) #172 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/172 | 16:12 |
| gitlab-br-bot | buildstream: merge request (jjardon/cmake_build->master: buildstream/plugins/elements/cmake.yaml: Always create build folder) #173 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/173 | 16:13 |
| *** jude has quit IRC | 16:24 | |
| *** bethw has quit IRC | 16:35 | |
| ssam2 | i think i've figured out the hang i was seeing in the tests | 16:59 |
| ssam2 | was 2 things, first that I was reporting issues with the logging API, but logging wasn't set up yet as we're still in early init | 17:00 |
| ssam2 | and then also seemingly something going wrong with returning results through the queue, meaning it blocked there forever | 17:00 |
| ssam2 | this makes me want to implement early logging before we merge multiple caches though | 17:00 |
| ssam2 | the alternative is we abort if there's a problem with any cache, rather than just warning | 17:01 |
| ssam2 | that would be a regression i suppose since it's what we do now | 17:01 |
| ssam2 | would probably get annoying with multiple caches involved though | 17:01 |
| *** bethw has joined #buildstream | 17:06 | |
| juergbi | ssam2: that may make sense, assuming it can be implemented relatively quickly. although i don't like the increasing stack of interdependent merge requests (logging <- multi-cache <- recursive-pipelines) | 17:10 |
| ssam2 | me neither | 17:10 |
| ssam2 | i'll try just raising an exception if any cache fails | 17:10 |
| nexus | I think it would be better to update fix for https://gitlab.com/BuildStream/buildstream/issues/159 to be more like the solution i was discussing with ssam2, as i feel it would be better not to use backports if they arent needed | 17:15 |
| ssam2 | what's the issue with backports ? surely it's easier than making people build ostree themselves | 17:17 |
| jjardon[m] | nexus: what is that solution? Do you have a WIP: MR available somewhere so we can have a look? | 17:17 |
| ssam2 | which seems to go wrong every time somebody attempts it :-) | 17:17 |
| gitlab-br-bot | buildstream: merge request (invoking_page_changes->master: WIP: Separated :show-nested: into individual calls) #157 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/157 | 17:19 |
| juergbi | given that backports allow installation of individual packages and thus, shouldn't risk the stability of the rest of the system, i also don't see a real issue with them | 17:19 |
| nexus | jjardon[m]: that's my latest | 17:19 |
| juergbi | however, either solution sounds reasonable to me | 17:20 |
| juergbi | having ostree build instructions in the documentation may be useful in any case | 17:20 |
| nexus | hmm | 17:21 |
| nexus | odd | 17:21 |
| tlater | Keep both, linking to a page that describes the process if you don't want to mess with compilation/where debian fetches your software from? | 17:21 |
| tlater | We'd only have to decide on a 'default' then | 17:21 |
| nexus | if we want to have both thats fine with me | 17:24 |
| jjardon[m] | nexus: to be honest, I'd add the ostree compilation instruction here: https://ostree.readthedocs.io/en/latest/ (then we can link to that page if someone prefer to compile ostree instead use the package from backports) | 17:25 |
| * ssam2 doesn't really want to have both as it adds to the maintenance burden | 17:25 | |
| ssam2 | we already let the instructions for Debian stable become out of date, for example | 17:25 |
| ssam2 | what we want is distros to package us, of course | 17:26 |
| ssam2 | but supplying a "fat binary" style package that can be installed and perhaps contans an embedded version of ostree might be a decent stopgap solution too | 17:26 |
| tlater | That's kind of what bst-here is for, isn't it? | 17:27 |
| ssam2 | yes | 17:27 |
| ssam2 | but clearly not everyone wants to use that | 17:27 |
| ssam2 | although some definitely do | 17:27 |
| ssam2 | (e.g. MacOS X people :-) | 17:27 |
| nexus | ) | 17:27 |
| nexus | hmm, so whats the call then? | 17:28 |
| ssam2 | whatever is easiest ... so i would vote backports | 17:28 |
| ssam2 | unrelatedly, we should also send a patch for https://ostree.readthedocs.io/en/latest/ to note that BuildStream uses it | 17:29 |
| * tlater likes the idea of trying to improve ostree's build docs, if that's what the issue is | 17:29 | |
| tlater | Otherwise, backports seems simplest. | 17:29 |
| nexus | ssam2: which versions are we using to develop? is there concern that they may introduce something not available in a backport that could cause problems? | 17:29 |
| ssam2 | yeah. i don't like to duplicate them | 17:29 |
| ssam2 | nexus, yes there's a chance of that | 17:30 |
| * nexus is just thinking it could be advantagous to have the latest version available | 17:30 | |
| ssam2 | but still, https://ostree.readthedocs.io/en/latest/#building would be better than duplicating it ourselves | 17:31 |
| ssam2 | *improving that | 17:31 |
| ssam2 | those docs gloss over the use case where your distro packages ostree but too old a version | 17:31 |
| nexus | Does this way of building apply to more than our specific use case then? enough to make it standard for ostree | 17:32 |
| ssam2 | yes, there's nothing special about how I've suggested building it | 17:32 |
| nexus | kk | 17:32 |
| tlater | Any project that needs an up to-date-ostree will need this to work on debian :) | 17:32 |
| nexus | so just send a patch to ostree with lines 104->111 then? | 17:33 |
| nexus | and link the doc | 17:33 |
| ssam2 | lines 104 -> 111 of what ? | 17:33 |
| nexus | my patch | 17:33 |
| nexus | basically the instructions for building ostree | 17:34 |
| ssam2 | where's that ? | 17:34 |
| ssam2 | ah right | 17:34 |
| nexus | https://gitlab.com/BuildStream/buildstream/commit/23791eca71b0dc8e5e63285c5beb099875a339ea | 17:34 |
| nexus | oh and 118+119 | 17:34 |
| ssam2 | more or less ... might need a bit of rewording to fit in with the existing ostree docs | 17:35 |
| ssam2 | we need to explain what the problem is with their current docs | 17:35 |
| ssam2 | perhaps they'll be happy with a change that recommends installing into a prefix like we suggest | 17:35 |
| ssam2 | but yes, start off by sending them a PR with an explanation of why we want the change | 17:36 |
| ssam2 | https://github.com/ostreedev/ostree/pull/1360 :-) | 17:40 |
| tlater | \o/ | 17:42 |
| nexus | \o/ | 17:42 |
| *** cs_shadow has quit IRC | 17:42 | |
| jjardon[m] | Hi, do we have something like post-install-commands in the bst format? OR do I have to override install-commands? | 17:49 |
| ssam2 | you append to the install-commands with the (>) operator | 17:49 |
| ssam2 | something like | 17:49 |
| ssam2 | config: | 17:49 |
| ssam2 | install-commands: | 17:49 |
| ssam2 | (>): | 17:50 |
| ssam2 | - this will be run after the default install-commands | 17:50 |
| jjardon[m] | uh, nice; thanks! | 17:50 |
| ssam2 | its obviously a bit of a yaml hack, but very convenient :) | 17:51 |
| ssam2 | (it's not standard yaml, it's buildstream adding special meaning to certain dictionary keys) | 17:51 |
| tlater | It's prettier than post-x commands, and also prettier in code :3 | 17:51 |
| * tlater is a big fan of this notation | 17:52 | |
| gitlab-br-bot | buildstream: issue #168 ("Initialize logging early and use it in the frontend") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/168 | 17:57 |
| juergbi | ssam2: regarding early logging, it could make sense to do it in two steps, first the timed activity part and only later the removal of the tickers | 17:59 |
| juergbi | this might reduce branch conflicts | 17:59 |
| ssam2 | maybe so | 17:59 |
| ssam2 | i think my multiple cache branch can avoid depending on it if we allow it to write warnings directly to stderr | 18:00 |
| juergbi | unless splitting would significantly increase the effort | 18:00 |
| ssam2 | as a temporary workaround for lack of logging | 18:00 |
| juergbi | would also be an option | 18:00 |
| ssam2 | i've found that we can avoid the hang in the tests by waking up from queue.get() every now and again to see if all the subprocesses are already dead | 18:01 |
| ssam2 | still not sure why they're not correctly reporting exceptions, but that should be more straightforward to debug now | 18:02 |
| *** ssam2 has quit IRC | 18:03 | |
| *** bethw has quit IRC | 18:15 | |
| gitlab-br-bot | buildstream: merge request (jjardon/cmake_build->master: buildstream/plugins/elements/cmake.yaml: Always create build folder) #173 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/173 | 18:24 |
| *** jude has joined #buildstream | 20:33 | |
| *** bochecha has joined #buildstream | 21:13 | |
| *** jude has quit IRC | 22:57 | |
| *** jude has joined #buildstream | 23:00 | |
| *** jude has quit IRC | 23:23 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!