| gitlab-br-bot | buildstream: merge request (chandan/bst-checkout-build->master: Add `--deps build` option to `bst checkout`) #819 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/819 | 00:08 |
|---|---|---|
| *** abderrahim has quit IRC | 00:12 | |
| *** abderrahim has joined #buildstream | 00:12 | |
| *** abderrahim has quit IRC | 00:39 | |
| *** abderrahim has joined #buildstream | 00:40 | |
| gitlab-br-bot | buildstream: merge request (chandan/source-checkout->master: Add `bst source-checkout` command) #820 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/820 | 00:46 |
| gitlab-br-bot | buildstream: merge request (chandan/source-checkout->master: Add `bst source-checkout` command) #820 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/820 | 01:06 |
| *** WSalmon_ has quit IRC | 04:09 | |
| *** bochecha has joined #buildstream | 06:09 | |
| *** iker has joined #buildstream | 06:56 | |
| *** iker has quit IRC | 07:04 | |
| *** iker has joined #buildstream | 07:06 | |
| *** toscalix has joined #buildstream | 07:37 | |
| gitlab-br-bot | buildstream: issue #226 ("Document incompatibilities between bst releases") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/226 | 07:43 |
| *** tiagogomes has joined #buildstream | 07:51 | |
| *** finn has quit IRC | 08:22 | |
| *** finn has joined #buildstream | 08:27 | |
| *** finn has quit IRC | 08:35 | |
| gitlab-br-bot | buildstream: issue #675 ("Batch commands for remote execution") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/675 | 08:39 |
| *** finn has joined #buildstream | 08:42 | |
| gitlab-br-bot | buildstream: issue #676 ("CAS Server: Implement BatchUpdateBlobs") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/676 | 08:44 |
| gitlab-br-bot | buildstream: issue #677 ("CAS Client: Use BatchUpdateBlobs") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/677 | 08:45 |
| gitlab-br-bot | buildstream: merge request (juerg/cas-batch->master: _artifactcache/cascache.py: Use BatchReadBlobs) #813 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/813 | 08:48 |
| gitlab-br-bot | buildstream: merge request (chandan/bst-checkout-build->master: Add `--deps build` option to `bst checkout`) #819 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/819 | 08:52 |
| gitlab-br-bot | buildstream: merge request (juerg/cas-batch->master: _artifactcache/cascache.py: Use BatchReadBlobs) #813 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/813 | 08:55 |
| gitlab-br-bot | buildstream: issue #678 ("CAS: Avoid double write for received blobs") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/678 | 08:58 |
| *** jonathanmaw has joined #buildstream | 09:01 | |
| gitlab-br-bot | buildstream: merge request (juerg/cas-batch->master: _artifactcache/cascache.py: Use BatchReadBlobs) #813 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/813 | 09:02 |
| gitlab-br-bot | buildstream: issue #653 ("bst checkout fails due to artifact cache error when remote execution is enabled") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/653 | 09:07 |
| tiagogomes | juergbi no tests for !813 ? | 09:20 |
| jonathanmaw | adds68: Would you be interested in becoming a co-maintainer for bst-external? I'm having trouble finding time to support bst-external at the moment, and Kinnison suggested you might be able to help with the freedesktop-sdk-related issues and MRs | 09:21 |
| gitlab-br-bot | buildstream: merge request (mablanch/668-remote-build-failure->master: WIP: Better handle remote build failures) #825 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/825 | 09:22 |
| juergbi | tiagogomes: the existing tests will use batching. it's not a user option | 09:25 |
| adds68 | jonathanmaw, as much as i'd love to help, i've got quite a bit on my plate at the moment also :( | 09:26 |
| *** lachlan has joined #buildstream | 09:26 | |
| jonathanmaw | :( | 09:27 |
| gitlab-br-bot | buildstream: issue #554 ("Pulling artifacts is very slow with high latency connections") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/554 | 09:31 |
| gitlab-br-bot | buildstream: merge request (juerg/cas-batch->master: _artifactcache/cascache.py: Use BatchReadBlobs) #813 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/813 | 09:31 |
| adds68 | Is it possible to depend on a junction that is inside a project you are junctioning from? | 09:33 |
| skullman | adds68: I think freedesktop-sdk has a junction in itself, might be worth looking at that. | 09:39 |
| toscalix | adds68: who from freedesktop-sdk should do it then? | 09:40 |
| adds68 | skullman, that is only a straight junction though, i am wondering if it's possible for a project to depend on a freedesktop-sdk junction for example that inside gnome-build-meta ? | 09:40 |
| * tlater[m] wonders if it would be acceptable to place the artifact server's to-be-processed artifacts in /tmp | 09:40 | |
| tlater[m] | Since that would use memory instead of potentially-about-to-explode disk space | 09:40 |
| adds68 | toscalix, it's a buldstream project, so i am not sure what you mean, jonathanmaw i assume was asking me directly, which at the moment isn't feasible | 09:41 |
| tlater[m] | But I suppose we would still run out of memory, except that in that case we would slow down the system |: | 09:41 |
| tiagogomes | tlater[m] probably not. If it is a tempfs you won't be able to use it for large artifacts | 09:41 |
| skullman | tlater[m]: plus you can't atomically move it into place if it's on another filesystem | 09:42 |
| tlater[m] | Ah, right | 09:42 |
| tiagogomes | jmac can https://gitlab.com/BuildStream/buildstream/merge_requests/818 be merged? | 09:42 |
| jmac | I'm trying to figure that out | 09:43 |
| jmac | The new CONTRIBUTING.rst doesn't say much about what approvals are needed | 09:43 |
| jmac | If the policy is still "eh, whatevs" then yes, I'll merge it | 09:44 |
| tlater[m] | jmac: iirc the email asked you to get approval from someone proficient in the specific code area | 09:45 |
| * tlater[m] isn't sure who that is at present | 09:46 | |
| jmac | Well, that would be Jürg (who has reviewed it). I'm just trying to find the email. | 09:46 |
| jonathanmaw | toscalix: I'd be happy if someone from freedesktop-sdk could have time allocated to be a co-maintainer for bst-external | 09:46 |
| jonathanmaw | if not I can't guarantee I'll have time to make changes other than review MRs and occasionally push new tags | 09:47 |
| jonathanmaw | (well, whether I have the time is independent of whether someone from freedesktop-sdk can be co-maintainer) | 09:47 |
| toscalix | jonathanmaw: bst-external will gain relevance. It will require more attention. We need more effort. I get it | 09:47 |
| gitlab-br-bot | buildstream: issue #679 ("Checkout gives an empty directory when using --deps none") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/679 | 09:48 |
| tlater[m] | jmac: Hrm, looks like it's technically still just a proposal | 09:50 |
| tlater[m] | It's an email from tristan titled "Proposal for commiter policy update" | 09:51 |
| jjardon | toscalix: maybe we can move the relevant plugins to buildstream/ instead, so the maintenance is shared by everyone? | 09:52 |
| *** finn has quit IRC | 09:52 | |
| jmac | Yeah, I've read that; it's not a policy though, it just tells people where to look for reviewers, rather than saying what's required | 09:52 |
| * jjardon still doesnt know the criteria to have some plugin in buildstream and others in bst-external | 09:53 | |
| *** gitlab-br-bot has quit IRC | 09:53 | |
| *** finn has joined #buildstream | 09:53 | |
| juergbi | one reason is that we guarantee stability / backward compatibility for plugins in buildstream core | 09:54 |
| juergbi | i.e., it's not suitable to move plugins there before stabilization | 09:55 |
| *** finn has quit IRC | 09:56 | |
| jjardon | ok, so the idea is that bst-external is a temporal place, until plugins are stable; the final objective is move relevant plugin to buildstream. Or are plugins mean to be forever in bst-external? | 09:57 |
| *** finn has joined #buildstream | 09:57 | |
| toscalix | jjardon: juergbi I would like to discuss that in more detail | 09:58 |
| juergbi | jjardon: afaik, the former | 09:58 |
| toscalix | having a plugin strategy where the criteria for "adopting as official" plugin is maturity..... is questionable | 09:59 |
| juergbi | it's not the only criterion | 09:59 |
| juergbi | but I don't see an issue with this being a criterion | 09:59 |
| toscalix | juergbi: what are the other criterion | 10:00 |
| toscalix | ? | 10:00 |
| toscalix | work with master? work with the latest stable release? | 10:00 |
| juergbi | I'd say being useful for more than just a corner case and at least someone, better multiple devs willing to maintain it upstream | 10:01 |
| juergbi | it obviously needs to work with the version it's merged into and from that point forward keep working | 10:01 |
| juergbi | and have test cases | 10:01 |
| toscalix | those are process and tech criterion. Now we are talking | 10:01 |
| toscalix | tech policy | 10:02 |
| juergbi | and I wouldn't typically accept new plugins into stable branches | 10:02 |
| *** lachlan has quit IRC | 10:02 | |
| toscalix | as I said, we should discuss them as guide. Not set them in stone, but have a couple of clear paragraphs that describes the conditions | 10:02 |
| juergbi | this is how I see it and I expect tristan to have a similar view but we'll have to clarify this with him | 10:03 |
| toscalix | I would like to see the maintainers/devs of the plugins providing input | 10:03 |
| tiagogomes | How do you handle a plugin being moved to buildstream but an older version of bst-external being installed | 10:04 |
| *** gitlab-br-bot has joined #buildstream | 10:04 | |
| toscalix | tiagogomes: let's not digg in :-) Let's leave it as open question we need to clarify. I find it very interesting for our gathering | 10:04 |
| bochecha | cs-shadow: about #670… it is fixed by !819, but that also introduces a new feature | 10:05 |
| toscalix | the model might have a huge impact in future business models around the tool | 10:05 |
| bochecha | cs-shadow: will both be applied to the 1.2 branch? or does it make sense to split the commit in two, so that the fix for #670 can be cherry-picked without the new feature? | 10:05 |
| toscalix | do you guys remember the PHP framework catarsis ? | 10:05 |
| toscalix | this topic became crutial for the survival of some of them | 10:06 |
| toscalix | it can become a huge differentiator factor for us | 10:06 |
| toscalix | if instead of considering it a downstream topic we consider it business model topic | 10:07 |
| tlater[m] | tiagogomes: Note that BuildStream already has features to specify from *where* you use a plugin | 10:09 |
| tlater[m] | In that case, if your project.conf specifies "use the plugin from x" it will override any default plugins. | 10:10 |
| toscalix | added the topic to the list for the gathering https://wiki.gnome.org/Projects/BuildStream/Events#Proposed_topics | 10:11 |
| *** gitlab-br-bot has quit IRC | 10:14 | |
| *** gitlab-br-bot has joined #buildstream | 10:14 | |
| *** lachlan has joined #buildstream | 10:17 | |
| *** solid_black has joined #buildstream | 10:18 | |
| juergbi | any takers for !291 (git 'ref' improvement) review? jjardon: maybe you want to verify that this works for your purposes | 10:19 |
| * tlater[m] managed to reproduce his first artifact server error :) | 10:26 | |
| tlater[m] | Also running two buildstream instances concurrently is freezing up my laptop | 10:26 |
| * tlater[m] needs a better laptop | 10:27 | |
| * jjardon will check later | 10:28 | |
| *** gitlab-br-bot has quit IRC | 10:30 | |
| *** gitlab-br-bot has joined #buildstream | 10:30 | |
| gitlab-br-bot | buildstream: issue #680 ("FileBasedDirectory can contain stale cached information") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/680 | 10:33 |
| tpollard | juergbi: with mr813 is it expected that a user would upgrade their bst-artifact-server instance to utilise the batching by default? | 10:33 |
| tpollard | I ask because I'm adding to cascache.py, and I'm not 100% sure if that's the assumed environment to work against | 10:34 |
| toscalix | tlater[m]: maybe the solution is to provide a testing environment since I assume we will have to do many tests. I believe it is the intention. Can anybody confirm? | 10:34 |
| tlater[m] | toscalix: A testing environment for performance-intensive testing might be useful long term | 10:36 |
| gitlab-br-bot | buildstream: merge request (jmac/stop-caching-vdirs->master: Stop caching virtual directories if get_directory is used.) #818 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/818 | 10:36 |
| gitlab-br-bot | buildstream: merge request (mablanch/668-remote-build-failure->master: Better handle remote build failures) #825 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/825 | 10:37 |
| juergbi | tpollard: while !813 requires an updated CAS server for batching, it supports fallback for old CAS servers | 10:37 |
| juergbi | also, 1.2.1/1.2.2 already include the server side | 10:37 |
| tlater[m] | If it's just this branch I don't think it will pay off, though. This is also the very first issue for which I've lacked performance, and it works just about. I'm not sure it's worth spending much effort on. | 10:37 |
| juergbi | tpollard: for your changes to cascache.py: everything should keep working with servers that don't support batch downloads, but optimizations can be skipped in that case, if necessary | 10:38 |
| tpollard | juergbi: thanks :) | 10:38 |
| jmac | tiagogomes: !818 is now set to merge if & when the CI pipeline succeeds. | 10:39 |
| jmac | Thanks juergbi & Kinnison for the reviews. | 10:39 |
| *** lachlan has quit IRC | 10:40 | |
| mablanch | If anyone feels like looking at a remote-execution path, !825 needs a review. jmac, finn, if you have some time, comments are welcome :) What's the build failure handling patch. | 10:41 |
| jmac | I will take a look, mablanch | 10:42 |
| mablanch | jmac, Thanks! Notes on how to test it are on the related issue btw. | 10:43 |
| tiagogomes | jmac thanks | 10:44 |
| juergbi | tlater[m]: have you seen yesterday's discussion between valentind and me with regards to expiry? | 10:47 |
| tlater[m] | juergbi: Not much of it, no, is there a mailing list thread about that? | 10:48 |
| *** finn has quit IRC | 10:48 | |
| valentind | tlater[m], I found 3 issues. | 10:49 |
| valentind | Not sure if this will help the bug reported. But I did get another bug when filling up the cache. | 10:49 |
| tlater[m] | valentind: Is this the one you commented about on the issue, where we set refs to nonexistent objects? | 10:50 |
| valentind | One issue is that we remove objects that have no reference yet. | 10:50 |
| valentind | So at the end of an upload we are in a bad state were a ref is incomplete. | 10:51 |
| valentind | Yes I commented about the first issue. | 10:51 |
| juergbi | tlater[m]: it started here: https://irclogs.baserock.org/buildstream/%23buildstream.2018-09-24.log.html#t2018-09-24T11:55:10 | 10:52 |
| valentind | Then there are other issues. We check we have enough space for an object, but we store it then step by step without allocating the space. So concurrent upload could go over the limit. | 10:52 |
| valentind | Third issue was that we duplicate data by copying temporary files. So we need twice the size than we actually check for. | 10:53 |
| juergbi | the third one is now #678 | 10:53 |
| * tlater[m] thinks the second one is the issue actually causing #609 | 10:54 | |
| tlater[m] | I also think we can concurrently add and remove artifacts at the same time | 10:54 |
| valentind | One problem with the third one is that this is where we actually get the error in the case of the ticket. It is possible we would get it somewhere else once fixed. But this is the copy that triggers the ENOSPC. | 10:54 |
| juergbi | I could look into solving that third issue now | 10:55 |
| *** finn has joined #buildstream | 10:55 | |
| tlater[m] | juergbi: Does grpc have any protections against concurrency issues? | 10:56 |
| valentind | I have a patch for the 3 issues. But it is intended to try to reproduce. Not that clean. Go ahead and fix things if you want. | 10:56 |
| *** lachlan has joined #buildstream | 10:57 | |
| gitlab-br-bot | buildstream: merge request (jmac/stop-caching-vdirs->master: Stop caching virtual directories if get_directory is used.) #818 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/818 | 10:58 |
| juergbi | tlater[m]: grpc server runs multi-threaded, so it's all up to the implementation | 10:59 |
| tlater[m] | Hrm, I wonder if we'll need more than allocating space to solve issue 2 then | 10:59 |
| *** finn has quit IRC | 10:59 | |
| tlater[m] | Because two concurrent instances will have different ideas of how much space is available/allocated | 11:00 |
| juergbi | try fallocate and handle error case by cleaning cache? | 11:00 |
| juergbi | possibly in a loop | 11:00 |
| tlater[m] | juergbi: What if one process is removing? | 11:01 |
| tlater[m] | I.e., cache cleanup/addition concurrency, like on the client end | 11:01 |
| juergbi | for that we need to solve issue 1 but I don't see how it affects issue 2 on its own | 11:01 |
| *** lachlan has quit IRC | 11:02 | |
| cs-shadow | bochecha: that's a good point, if we want the bug fix to be ported to 1.2, I can split it into two separate commits | 11:02 |
| juergbi | valentind: pushed somewhere? or are these workarounds that don't help with the proper fix at all? | 11:02 |
| bochecha | cs-shadow: I'd really like it backported into 1.2, personally | 11:02 |
| cs-shadow | bochecha: okay, I'll do that. No problem | 11:03 |
| juergbi | sounds sensible | 11:03 |
| cs-shadow | It'll have to wait for 1.2.3 though I guess :) | 11:03 |
| bochecha | I'm reporting bugs to libabigail (ABI checker) regularly for the freedesktop sdk, and right now I always have to `bst checkout` a full element, then remove everything from the tree that is irrelevant | 11:03 |
| bochecha | with --deps=none I'd directly get the tree I want | 11:03 |
| valentind | juergbi, not yet. I want to do some testing to understand. | 11:03 |
| bochecha | then I put that in a tarball and attach it to the libabigail bug report :) | 11:03 |
| tlater[m] | juergbi: Is issue 1 related to this case at all? I thought the problem was that we remove artifacts before setting their ref, and *then* set a ref to nonexistent objects. | 11:04 |
| bochecha | cs-shadow: thanks! | 11:04 |
| valentind | juergbi, I think we really need to manually test well filling up a cache server. | 11:04 |
| tlater[m] | valentind: If you like, I have a little script that starts a really small cache server in a docker container | 11:05 |
| valentind | tlater[m], I set up a cache on a mounted fs from a loop file. | 11:05 |
| tlater[m] | Fair enough | 11:05 |
| juergbi | tlater[m]: yes, so that's concurrent remove/add, which we need to fix, e.g., with my suggestion of not purging recent blobs | 11:07 |
| tlater[m] | Ah, that would solve that too | 11:08 |
| juergbi | valentind: agreed, however, some improvements will make sense independent of whether they already fully fix all symptoms | 11:08 |
| juergbi | valentind: so is your solution to issue 3 something that could be useful as (base for) upstream fix? in that case i'll leave it for now. otherwise I'll look into a fix for that part | 11:09 |
| tlater[m] | valentind: I think it will be easiest if you just push those branches without MRs, we can help reproduce then, too :) | 11:11 |
| valentind | juergbi, tlater[m], OK let me push a branch today. You can both look at it tomorrow and comment on it. | 11:17 |
| valentind | I am going to test it. | 11:18 |
| juergbi | ta | 11:18 |
| Nexus | I'm getting this error when running a test, does anyone recognise it/know a fix? | 11:37 |
| Nexus | https://pastebin.com/rdjju9s5 | 11:37 |
| Nexus | i can run the commands manually, it only fails when run as part of the test | 11:37 |
| tlater[m] | Nexus: Are you still playing with cross-platform support? | 11:39 |
| Nexus | yeeees? | 11:39 |
| Nexus | ¬.¬ | 11:39 |
| tlater[m] | Make sure you don't normally run as root | 11:40 |
| tlater[m] | Because that could a) screw up your cache on some platforms and b) hide errors like that | 11:40 |
| Nexus | you have to on mac and WSL | 11:40 |
| tlater[m] | Nexus: In which case, make sure that CI is configured to run as root. | 11:40 |
| juergbi | Nexus: why would root be required on either of those? | 11:41 |
| Nexus | these are just local tests atm, ther is no CI | 11:41 |
| juergbi | for remote execution? | 11:41 |
| Nexus | juergbi: no bubblwrap | 11:41 |
| juergbi | (or local non-sandbox tests) | 11:41 |
| juergbi | there is no sandbox run | 11:41 |
| juergbi | the dummy sandbox should not require this | 11:41 |
| tlater[m] | Ah, that's right. | 11:41 |
| *** iker has quit IRC | 11:41 | |
| tlater[m] | Nexus: In this particular case, it looks like you ran the test suite as root once and then as a normal user | 11:42 |
| tlater[m] | I'd remove the test temporary directories and try again | 11:42 |
| Nexus | tlater[m]: i ran as root both times, and i have done, same issue | 11:42 |
| *** lachlan has joined #buildstream | 11:43 | |
| *** iker has joined #buildstream | 11:43 | |
| Nexus | juergbi: i get `E py.error.EACCES: [Permission denied]: rmtree('/Users/codething/buildstream/tmp',) | 11:43 |
| Nexus | when not running as root | 11:43 |
| tlater[m] | Nexus: That's a Windows path, no? Perhaps some setting of the host OS? | 11:44 |
| Nexus | MacOS | 11:44 |
| tlater[m] | In any case, that's not related to sandboxing. It should run as non-root. | 11:46 |
| juergbi | Nexus: something in tmp still has root permissions from earlier runs? | 11:48 |
| juergbi | have you tried tlater[m]'s suggestion of manually removing this first? | 11:48 |
| juergbi | s/root permissions/root ownership/ | 11:48 |
| Nexus | juergbi: not that i can see | 11:49 |
| *** finn has joined #buildstream | 11:52 | |
| tlater[m] | toscalix: One note about the website - known issues that are fixed will show up as (closed), but may still need to be backported to the latest stable version. Is this intended? | 11:54 |
| Nexus | juergbi: it seems to be a concurrency issue | 12:00 |
| jmac | I've got `bst` executing the wrong version of buildstream again... clearly executing an installed version which doesn't match the checked out code, despite installing with `pip3 install --user -e .` | 12:01 |
| Nexus | jmac: is it possible yu have 2 buildstreams installed? | 12:01 |
| Nexus | i have had that problem before | 12:01 |
| skullman | jmac: long shot, have you run `hash -d bst`? | 12:02 |
| jmac | Yes, but where? I've cleared out ~/.local/lib/python3.6 | 12:02 |
| tlater[m] | jmac: /usr/local/lib/python3.6 might also contain one | 12:03 |
| jmac | skullman: Yep - good advice, but it's not that this time | 12:03 |
| toscalix | yes, we only remove them when the fixes are released | 12:03 |
| tlater[m] | jmac: *also*, pip creates egg link cruft, so you may just have a symlink to a nonexistent binary lying around now | 12:03 |
| Nexus | jmac: i also have bst installed at ~/.local/bin/bst | 12:03 |
| jmac | bst --version returns 1.3.0+530.g662c729f which is the exact hash I'm on | 12:04 |
| toscalix | since the target audience are users that consume releases, not contributors nor testers | 12:04 |
| jmac | but it shows error messages which clearly don't exist anywhere in the source tree | 12:04 |
| tlater[m] | jmac: You definitely have leftover modules. Have you tried `pip remove buildstream; sudo pip remove buildstream`? | 12:04 |
| jmac | tlater[m]: It's 'uninstall' rather than remove, but yes, done that | 12:06 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: Out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 12:06 |
| tlater[m] | jmac: Best way to get rid of the issue is to use `pdb` to figure out where the actual files for your modules are then. | 12:07 |
| jmac | Can I just set fire to my laptop and get a new one instead | 12:07 |
| Nexus | reinstall os | 12:07 |
| jmac | snap | 12:07 |
| *** lachlan has quit IRC | 12:08 | |
| tlater[m] | jmac: Alas, usually when I accidentally screw up my python that's what I resort to... | 12:08 |
| Nexus | this is why everyone should use VMs | 12:08 |
| skullman | chroots normally enough | 12:09 |
| jmac | That's somewhat artifical, unless we're recommending all users do that | 12:09 |
| tlater[m] | jmac: This is a problem that only crops up during dev though, and something that is caused by pip. | 12:09 |
| Nexus | i need to reinstall my OS at some point, i bricked my python about 2 months ago | 12:10 |
| tlater[m] | virtualenv can also help without masking the issue. | 12:10 |
| Nexus | but that's effort | 12:10 |
| *** solid_black has quit IRC | 12:10 | |
| Nexus | i'm at the point where my Mac test system is more stable than my local one, so i run tests on there instead | 12:11 |
| tlater[m] | Does this warrant a known_issues entry? https://gitlab.com/BuildStream/buildstream/issues/665 | 12:21 |
| tlater[m] | The stacktrace might creep up on and confuse new users, although it's technically not harmful in that BuildStream wouldn't continue doing anything anyway | 12:22 |
| * tlater[m] is going through the issues list and distilling a number of issues that seem likely to cause problems for users | 12:23 | |
| Nexus | that's on my todo list i think | 12:24 |
| Nexus | 665 | 12:24 |
| * tlater[m] would be happy to have a look at it after finishing the known issues page, too | 12:26 | |
| tlater[m] | Just wondering if it's high enough impact to list, so that I can get a feel for what to include :) | 12:26 |
| jonathanmaw | juergbi: do you know the specific use-case behind https://gitlab.com/BuildStream/buildstream/issues/666? I've been trying to implement the tests for https://gitlab.com/BuildStream/buildstream/issues/667, but I don't think I understand it properly | 12:39 |
| jonathanmaw | since when I revert the fix to 666, the tests I did still pass | 12:39 |
| Kinnison | jonathanmaw: and nothing since that fix could be masking the thing that 666 was about? | 12:43 |
| adds68 | Was there any update on why the search functionality has stopped working on the documentation page? | 12:44 |
| jonathanmaw | Kinnison: hrm, possibly. I tried testing by rolling back to before that commit and trying a real repo instead of tests | 12:44 |
| jonathanmaw | I'll give it a try | 12:45 |
| tlater[m] | valentind: Should known issues include a description of when the issue occurs that's less technical? | 12:47 |
| tlater[m] | Currently we only describe who is affected... | 12:47 |
| gitlab-br-bot | buildstream: issue #681 ("Search functionality in the Documentation has stopped working") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/681 | 12:48 |
| jonathanmaw | Kinnison: correct, when I roll back to before and cherry-pick my tests back in, they pass :-/ | 12:49 |
| * jonathanmaw still doesn't understand the failure case | 12:49 | |
| Kinnison | Oh dear | 12:49 |
| Kinnison | juergbi: ^^^ | 12:49 |
| juergbi | will take a look | 12:52 |
| gitlab-br-bot | buildstream: issue #605 ("linux.py uses context message API before initialization") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/605 | 12:52 |
| adds68 | There is nothing in the buildstream documentation that states the limit of junctions: https://buildstream.gitlab.io/buildstream/advanced-features/junction-elements.html | 12:53 |
| adds68 | Would anyone know if nested junctions possible? | 12:53 |
| skullman | adds68: I junction in stuff from freedesktop-sdk and that has a junction to something, which suggests it works to some degree. | 13:00 |
| adds68 | skullman, ah yes sorry i understand your point now, however i'm still not sure how to tell buildstream to look to that element inside the junction | 13:01 |
| skullman | ah, so it's a matter of how you would specify syntax for following the junction, hmm, I don't know that | 13:03 |
| adds68 | skullman, any idea who would? | 13:04 |
| adds68 | Who worked on junctions? | 13:04 |
| adds68 | I guess maybe having 2 separate junction files would also solve this though | 13:04 |
| adds68 | But it would be nice to know either way | 13:04 |
| coldtom | adds68: you can solve using two junctions for sure | 13:09 |
| tlater[m] | adds68: For reference, juergbi implemented junctions. | 13:09 |
| tlater[m] | I think he's by far the most knowledgeable. | 13:09 |
| *** lachlan has joined #buildstream | 13:11 | |
| gitlab-br-bot | buildstream: issue #429 ("BuildStream refuses to cache artifacts with files that have very strict permissions") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/429 | 13:11 |
| tlater[m] | Our issues need a cleanup... | 13:14 |
| * tlater[m] is unintentionally doing so by trying to reproduce old bugs | 13:14 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/push-failed-build-regression->master: tests: Add regression test for pushing failed builds) #824 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/824 | 13:22 |
| tlater[m] | Hmm... Should I detail know issues for which we don't really have a clue what's causing them yet? | 13:35 |
| tlater[m] | s/know/known/ | 13:35 |
| tlater[m] | Things such as: https://gitlab.com/BuildStream/buildstream/issues/615 - we have no idea under which circumstances this occurs, and it clearly isn't every build. | 13:36 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: Out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 13:46 |
| *** ikerperez has joined #buildstream | 13:56 | |
| *** finn_ has joined #buildstream | 13:56 | |
| *** iker has quit IRC | 13:57 | |
| *** finn has quit IRC | 13:57 | |
| *** ikerperez has quit IRC | 14:04 | |
| *** iker has joined #buildstream | 14:04 | |
| tlater[m] | I'd appreciate it if someone could have a look at this: https://gitlab.com/BuildStream/website/merge_requests/93 | 14:14 |
| * tlater[m] hopes this matches what people had imagined the known_issues page to look like | 14:14 | |
| tlater[m] | I'm also starting to wonder if we should include issues that have been fixed since (i.e. in the 1.2.x releases) | 14:15 |
| toscalix | Reminder: please add yourself to the participants list if you are attending to the Gathering on week 42 https://wiki.gnome.org/Projects/BuildStream/Events | 14:24 |
| *** catonano has joined #buildstream | 14:25 | |
| tlater[m] | toscalix: That page presents itself as "immutable" to me | 14:28 |
| toscalix | tlater[m]: I mentioned in the ML that you need to have an account in GNOIME and be on a whitelist. jjardon can you add tlater[m] ? | 14:31 |
| toscalix | tlater[m]: nice job with the known issues | 14:32 |
| *** solid_black has joined #buildstream | 14:39 | |
| *** raoul has joined #buildstream | 14:40 | |
| juergbi | jonathanmaw: I don't have any more information about #666. however, it's possible it was discovered on 1.2. have you tried the revert on 1.2 instead of master? | 14:48 |
| juergbi | i.e., maybe it was avoided in master due to some other commits | 14:49 |
| *** abderrahim has quit IRC | 14:49 | |
| *** abderrahim has joined #buildstream | 14:50 | |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 14:55 |
| *** iker has quit IRC | 14:58 | |
| jjardon | toscalix: sure, but anyone already in the whitelis can add more people | 15:03 |
| jjardon | tlater[m]: what is your username in gnome wiki? | 15:03 |
| toscalix | jjardon: did not know that. Checking how | 15:03 |
| *** alatiera_ has joined #buildstream | 15:05 | |
| toscalix | jjardon: do not see where | 15:05 |
| jjardon | toscalix: https://wiki.gnome.org/TrustedEditorGroup | 15:06 |
| toscalix | ah, it is general for the wiki | 15:06 |
| toscalix | thought it was "per page" | 15:07 |
| jmac | Looks like my earlier problem which I thought was bst executing the wrong version was actually bst caching a build failure in CAS | 15:10 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 15:10 |
| raoul | Trying to import freedesktop-sdk with a junction but get a complaint about ostree namespace when build anything that depends on the junctions elements. As far as I'm aware I shouldn't be using ostree, but I have it installed anyway so not sure what's going wrong. Files and traceback: https://pastebin.com/JGpBGP8K | 15:11 |
| jonathanmaw | juergbi: I've just tried rolling back to before the commit "source.py: Fix re-instantiation" and trying my tests. They still pass :-/ | 15:11 |
| tpollard | juergbi: would you expect an older bst artifact server to be throwing exception errors for bath not to be implemented (whilst still seemingly behaving as before?) | 15:11 |
| tpollard | *batch | 15:12 |
| juergbi | jonathanmaw: odd. unfortunately, I don't know any more than what tristan wrote on gitlab | 15:13 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 15:13 |
| jonathanmaw | juergbi: okay. It's not massively urgent, so I can wait until he gets back to explain what I did wrong | 15:14 |
| juergbi | tpollard: hm, it's possible that the check whether batch is implemented will produce a server side exception that is logged but not otherwise harmful | 15:14 |
| tpollard | juergbi: that seems to be the case | 15:15 |
| tpollard | juergbi: I'm simply running it in a screen session, it's logging this constantly but not falling over https://paste.gnome.org/pql59loej | 15:16 |
| juergbi | not ideal but it's backported to 1.2, so shouldn't be a long term concern | 15:19 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 15:22 |
| jjardon | raoul: you probably need the python bindings for ostree | 15:23 |
| jjardon | raoul: what distro you use? | 15:23 |
| tpollard | juergbi: agreed | 15:23 |
| raoul | jjardon, on debian. I installed ostree with pip3, is that the bindings and I'm missing the actually library? | 15:24 |
| jjardon | raoul: if It's debian stable, check you have installed gir1.2-ostree-1.0 from backports | 15:24 |
| Kinnison | There used to be docs about that | 15:25 |
| jjardon | raoul: ostree can not be installed with pip, so probably you actually dont have ostree installed, but only the bindings | 15:25 |
| Kinnison | raoul: http://buildstream.gitlab.io/buildstream/install_source.html#stretch | 15:25 |
| toscalix | jjardon: in theory, we have a table on the feature page to reflect dependencies. I wonder if this is too specific to go there | 15:25 |
| jjardon | toscalix: don't know how raoul have setup buildstream or what guide is being used | 15:26 |
| raoul | ah, I clearly missed that section, I'll do that now and see if that fixes it | 15:26 |
| jjardon | toscalix: but is certainly documented in the ling Kinnison just posted | 15:27 |
| toscalix | ok then | 15:27 |
| jjardon | raoul: ostree is not used anymore in buildstream insternally, but It's used in freedesktop-sdk because we are using the ostree source plugin | 15:27 |
| Kinnison | raoul: If any of that isn't clear, do let us know so we can improve the section | 15:27 |
| raoul | I did the debian section and then ignored stretch and bust and sid sections, apparently just need to read more carefully | 15:29 |
| Kinnison | :-) | 15:29 |
| juergbi | Nexus: oh, I forgot to 'start discussion' for one comment: https://gitlab.com/BuildStream/buildstream/merge_requests/726#note_104191872 | 15:36 |
| juergbi | Nexus: also recheck your branches. right now workspace_list_error_message does NOT contain the workspace list change, but mac_fixes still contains that | 15:37 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 15:38 |
| Nexus | juergbi: yup just noticed that xD | 15:38 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 15:41 |
| Nexus | juergbi: resolved the commit message tweak | 15:41 |
| juergbi | ta | 15:47 |
| *** lachlan has quit IRC | 15:47 | |
| *** jonathanmaw has quit IRC | 15:56 | |
| *** lachlan has joined #buildstream | 15:56 | |
| juergbi | jjardon: not urgent but it would be great if you (or anyone else with access) could upgrade the fdo/gnome artifact server to 1.2.2. this enables faster (batch) pulling of artifacts with bst master clients (the client side I'll backport to 1.2 after this real life testing) | 16:09 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 16:10 |
| jjardon | juergbi: ack, I will do the freedesktop-sdk one, for the GNOME one abderrahim if you have some time ^ (although I'd wait after the release maybe) | 16:11 |
| gitlab-br-bot | buildstream: merge request (mablanch/668-remote-build-failure->master: Better handle remote build failures) #825 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/825 | 16:13 |
| abderrahim | I already updated to 1.2.1, I think it has the fix | 16:13 |
| * abderrahim hopes this bug is the reason why the aarch64 runner is slow | 16:14 | |
| *** toscalix has quit IRC | 16:14 | |
| juergbi | jjardon: thanks | 16:17 |
| juergbi | abderrahim: yes, 1.2.1 already has the fix. 1.2.2 is not needed on the server | 16:17 |
| juergbi | Nexus: I'm seeing local test errors with mac_fixes branch, checking | 16:17 |
| Nexus | weird | 16:18 |
| *** lachlan has quit IRC | 16:19 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-514->master: CI: test building freedesktop-sdk overnight) #826 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/826 | 16:24 |
| *** catonano has quit IRC | 16:31 | |
| *** catonano has joined #buildstream | 16:31 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-514->master: CI: test building freedesktop-sdk overnight) #826 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/826 | 16:38 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-514-backport->bst-1.2: CI: test building freedesktop-sdk overnight) #827 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/827 | 16:41 |
| *** lachlan has joined #buildstream | 16:42 | |
| adds68 | When junctioning from a project, i am seeing inconsistent pipeline errors, which is suggesting i track for a version | 16:48 |
| adds68 | But when i track the junction element this does not resolve it | 16:48 |
| adds68 | Any idea if i need to pass a flag to "bst track" in order to track the junction elements? | 16:48 |
| valentind | adds68, you can pass the name of that junction element. | 16:50 |
| adds68 | valentind, it does not fix the issue | 16:50 |
| valentind | Strange. Is it really the junction or an element in that junction? | 16:50 |
| tpollard | adds68: have you tried the deps & cross junction flags? | 16:50 |
| adds68 | valentind, an element inside that junction | 16:50 |
| mablanch | jmac: Thanks for the review on !825. I don't have write access, would you mid merging it if your still ok with it? | 16:50 |
| valentind | Yes, then there is a cross junction option. | 16:50 |
| jmac | mablanch: Sure. | 16:51 |
| valentind | But you have to track something that depends on it. | 16:51 |
| valentind | Or you can always do "bst track junction.bst:element.bst" | 16:51 |
| adds68 | tpollard, just --deps? | 16:51 |
| valentind | adds68, no, there is one more option. | 16:52 |
| adds68 | I want a way to resolve all deps at once, there are several errors | 16:52 |
| adds68 | All missing ref errors | 16:52 |
| jmac | mablanch: Can you rebase mablanch/668-remote-build-failure onto current master? | 16:52 |
| tpollard | adds68: --deps all | 16:52 |
| valentind | adds68, --cross-junctions | 16:52 |
| valentind | Both options. | 16:52 |
| adds68 | haha good timing | 16:53 |
| gitlab-br-bot | buildstream: merge request (mablanch/668-remote-build-failure->master: Better handle remote build failures) #825 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/825 | 16:53 |
| mablanch | jmac: Done. | 16:54 |
| adds68 | valentind, tpollard "bst track --deps all --cross-junctions" | 16:54 |
| adds68 | Did not fix the error | 16:54 |
| valentind | adds68, what element did you pass as parameter? | 16:54 |
| adds68 | Also passing the name of the junction file did not work | 16:55 |
| valentind | Do not pass the junction. Pass something using the junction. | 16:55 |
| jmac | mablanch: Thanks. I've set it to merge when the CI succeeds. | 16:55 |
| adds68 | valentind, ok | 16:56 |
| adds68 | Untrackable sources | 16:56 |
| adds68 | Requested to track sources across junction boundaries | 16:56 |
| adds68 | in a project which does not use project.refs ref-storage. | 16:56 |
| valentind | adds68, is the subproject using project.refs? | 16:56 |
| adds68 | I guess not? | 16:56 |
| valentind | So you cannot do that, YOu need to track manually in the source of the subproject. | 16:57 |
| valentind | Or convert it project.refs | 16:57 |
| mablanch | jmac: Cheers! | 16:57 |
| adds68 | What is project.refs? Why is this optional? | 16:57 |
| valentind | adds68, what source type is the junction using? | 16:57 |
| adds68 | git | 16:57 |
| valentind | adds68, project.refs is a file containing all the refs. Instead of having them in the elements. | 16:58 |
| adds68 | valentind, why is this not automated by BuildStream? | 16:58 |
| valentind | The problem in tracking non project.refs is that the files need to be modified. But buildstream is not going to commit changes to remote git repository for you. | 16:58 |
| valentind | But project.refs however has one top file with all refs for all projects. So you do not need to modify any file. | 16:59 |
| adds68 | valentind, yes i get that, but surely keeping an extra file containing all the refs isn't practical, or am i missing something here? | 16:59 |
| valentind | Well, in this case you have to track separately and commit your track in the subproject. | 17:00 |
| adds68 | valentind, so this file can be generated by bst? | 17:02 |
| adds68 | it just needs to be run once and the file committed to the project? | 17:02 |
| valentind | adds68, Checkout your sub project separately. Then track it. Commit. Then next track your junction to get that coomit. | 17:03 |
| gitlab-br-bot | buildstream: issue #514 ("BuildStream CI is not configured to perform any system level testing") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/514 | 17:03 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-514->master: CI: test building freedesktop-sdk overnight) #826 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/826 | 17:03 |
| adds68 | valentind, so i need to bst track the project locally and push the file generated back to that project? | 17:08 |
| valentind | adds68, yes. Then you understand why project.refs can be useful. | 17:08 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 17:08 |
| adds68 | valentind, i am unsure if you mean my project, or the junction project | 17:09 |
| valentind | adds68, the subproject. | 17:09 |
| adds68 | I have pulled the junction project and run bst track, but nothing was produced | 17:09 |
| valentind | Maybe there is nothing to track then. | 17:09 |
| valentind | adds68, why are you tracking? | 17:10 |
| *** tpollard has quit IRC | 17:10 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-514-backport->bst-1.2: CI: test building freedesktop-sdk overnight) #827 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/827 | 17:10 |
| adds68 | valentind, because i am trying to junction the project, but bst is complaining about refs | 17:10 |
| adds68 | Untrackable sources | 17:11 |
| adds68 | Requested to track sources across junction boundaries | 17:11 |
| adds68 | in a project which does not use project.refs ref-storage. | 17:11 |
| valentind | What command gives you this error? | 17:11 |
| adds68 | valentind, bst track giggle.bst --deps all --cross-junctio | 17:12 |
| adds68 | ns | 17:12 |
| adds68 | giggle.bst is juntioning gnome-build-meta | 17:12 |
| valentind | And gnome-build-meta uses project.refs, right? | 17:12 |
| adds68 | valentind, i am not sure | 17:13 |
| adds68 | this project also junctions freedesktop-sdk | 17:13 |
| *** phildawson has quit IRC | 17:13 | |
| adds68 | But the error is giving me nothing to suggest what is the issue | 17:13 |
| valentind | adds68, You mean giggle.bst is depends on the junction element to gnome-build-meta? Or you mean that it is the junction element to gnome-build-meta? | 17:14 |
| adds68 | valentind, the first point | 17:14 |
| valentind | adds, --except freedesktop-sdk/all.bst | 17:16 |
| valentind | adds, --except freedesktop-sdk.bst:all.bst | 17:16 |
| valentind | The second one. | 17:17 |
| valentind | Given freedesktop-sdk.bst is the junction freedesktop-sdk | 17:17 |
| valentind | adds68, I missed the "68" | 17:17 |
| *** solid_black has quit IRC | 17:18 | |
| adds68 | valentind, ok that fixed the error, but now i see: Failed to load Element plugin 'collect-integration': No module named 'pluginbase._internalspace._sp25013cb2b5486823f1a1b94f9752f747.collect-integration' | 17:20 |
| adds68 | valentind, do we need to add project.refs to freedesktop also? | 17:20 |
| adds68 | valentind, i also have bst-external installed | 17:21 |
| valentind | adds68, you need bst-external. | 17:21 |
| valentind | It is collect_integration. | 17:22 |
| valentind | I think you have an old version of freedesktop-sdk. | 17:22 |
| valentind | You want to track the junction. | 17:22 |
| adds68 | valentind, i am junctioning 18.08 | 17:22 |
| adds68 | valentind, so after tracking the freedesktop-sdk junction, i now see the Untrackable sources error again haha | 17:23 |
| juergbi | Kinnison: I've pushed mac_fixes with two new commits at the bottom but it probably will require some further tweaks | 17:26 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 17:27 |
| valentind | adds68, do you have a repository ready to test? | 17:31 |
| valentind | adds68, it sounds to me like there is a bug. But I am to lazy to reproduce your project. | 17:31 |
| *** lachlan has quit IRC | 17:43 | |
| Kinnison | juergbi: I shall look at those commits | 17:48 |
| Kinnison | juergbi: I'm currently eating my dinner, so it won't be quick | 17:48 |
| *** lachlan has joined #buildstream | 17:55 | |
| *** lachlan has quit IRC | 17:57 | |
| *** finn_ has quit IRC | 18:00 | |
| Kinnison | juergbi: Looks good to me | 18:08 |
| Kinnison | juergbi: do you want me to say so on-MR ? | 18:08 |
| Kinnison | juergbi: Interestingly some of the tests are failing, and it doesn't seem to be proceeding. You may need to reinvestigate :( | 18:33 |
| *** catonano has quit IRC | 18:40 | |
| *** catonano has joined #buildstream | 18:50 | |
| *** finn has joined #buildstream | 19:08 | |
| *** finn has quit IRC | 19:43 | |
| *** catonano has quit IRC | 21:19 | |
| *** bochecha has quit IRC | 21:32 | |
| *** alatiera__ has joined #buildstream | 23:29 | |
| *** alatiera_ has quit IRC | 23:31 | |
| gitlab-br-bot | buildstream: merge request (chandan/bst-checkout-build->master: Add `--deps build` option to `bst checkout`) #819 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/819 | 23:48 |
| gitlab-br-bot | buildstream: merge request (chandan/fix-checkout-none-1.2->bst-1.2: Ensure `--deps=none` option works for `bst checkout`) #828 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/828 | 23:57 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!