| *** bochecha has quit IRC | 00:11 | |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 00:12 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 00:16 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 00:19 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 00:41 |
| *** tristan has joined #buildstream | 04:58 | |
| *** jsgrant has joined #buildstream | 05:00 | |
| *** cs_shadow has quit IRC | 05:26 | |
| *** jsgrant has quit IRC | 06:08 | |
| *** ernestask has joined #buildstream | 06:14 | |
| *** paulsherwood has joined #buildstream | 06:34 | |
| *** paulsherwood has joined #buildstream | 06:34 | |
| * laurence wonders if anyone has strong opinions on automating gitlab to send patches to the ML | 07:57 | |
| tristan | laurence, I feel strongly against it to be frank | 07:59 |
| tristan | I think we discussed setting up gitlab to ensure the email notifications it *does* send (if you decided to subscribe), do contain the patches | 07:59 |
| tristan | laurence, If we want emails for everything which lands in master, there is precedence for that in other projects, and it involves using a separate list | 08:00 |
| tristan | if we want people to subscribe and participate in the mailing list discussions, we should not spam the main list with patches | 08:01 |
| *** finn has joined #buildstream | 08:01 | |
| laurence | tristan, have you seen the ML post from Agustin? | 08:04 |
| tristan | laurence, I dont have time for the mailing list honestly today | 08:04 |
| tristan | I've seen some headlines which worry me about that | 08:04 |
| laurence | tristan, leave with me then | 08:05 |
| laurence | i'll make time | 08:05 |
| tristan | thanks a lot ! | 08:05 |
| *** bochecha has joined #buildstream | 08:13 | |
| *** jonathanmaw has joined #buildstream | 08:19 | |
| *** Nexus has joined #buildstream | 08:37 | |
| Phil | Anyone know of a python library that can be used to apply patches to files (as per the patch command line utility)? | 08:46 |
| Phil | It would make testing the workspaces walkthrough much neater | 08:47 |
| Kinnison | Phil: Are you allowed to depend on the patch cmdline tool? | 08:47 |
| Kinnison | Phil: If so, writing a class which wrappers it up with subprocess should be fairly easy | 08:47 |
| Kinnison | Phil: If not, then https://github.com/techtonik/python-patch comes up in a first cut search | 08:48 |
| Phil | Ok, I'm not really sure how to do that so I thought I'd check first. I saw that library but it came with an unstable api warning so is probably not something we want to depend on. | 08:50 |
| noisecell | does someone has some spare time to look at https://gitlab.com/BuildStream/buildstream/merge_requests/537 ? | 08:52 |
| Kinnison | If this is just for tests, then you could submodule a specific release? | 08:52 |
| Kinnison | Phil: ^ | 08:52 |
| Kinnison | Phil: though the most recent commits failed on python 3 | 08:53 |
| Kinnison | blech | 08:53 |
| Kinnison | Phil: If you're okay doing so, I'd suggest the wrapper of the patch cmdline tool :-) | 08:53 |
| Kinnison | Has anyone done work into building Rust software in Buildstream? | 08:55 |
| Phil | Kinnison, That looks like the better option i think. Is the "right" way to do this to write a class which uses subprocess.call to run the command line utility? | 08:56 |
| Kinnison | Phil: I'd say that's a good starting point, yes. Whether it's right or not for this project I don't know because I've not yet reached the point of learning how the test suites work in Buildstream :-) | 08:57 |
| Kinnison | Phil: It's worth ensuring that early in the test cycle if patch is unavailable the test is either flagged as unable to be run, or the suite is stopped *cleanly* | 08:58 |
| * Kinnison has had no end of problems with software whose test suite dependencies are not clear and not checked | 08:58 | |
| tristan | Kinnison, we have plans for rust, and I had a nasty workaround for it... I'm unfortunately too swamped today to walk through it though :-S | 08:58 |
| Kinnison | tristan: s'okay, I was just wondering :-) | 08:58 |
| * Kinnison has no immediate plans to need it | 08:59 | |
| tristan | Kinnison, this is part of the workaround: https://gitlab.com/BuildStream/cargo-fetcher | 08:59 |
| Kinnison | tristan: thanks | 08:59 |
| Phil | thanks Kinnison :) | 09:00 |
| tristan | it involved a continuous process of "vendoring" dependencies into a repo which could be used in the build environment | 09:00 |
| * Kinnison nods | 09:00 | |
| tristan | Kinnison, check the mailing list for talk about SourceTransform for future plans for rust/go/python/js,... languages which like to fetch their deps from the internets | 09:00 |
| * Kinnison makes a note | 09:01 | |
| *** Nexus has quit IRC | 09:05 | |
| *** Nexus has joined #buildstream | 09:08 | |
| jonathanmaw | noisecell: I'll have a look at it now | 09:14 |
| noisecell | jonathanmaw, thank you | 09:14 |
| jonathanmaw | code seems fine, just running through the way to reproduce the bug now | 09:14 |
| tiagogomes | https://gitlab.com/BuildStream/buildstream/merge_requests/546 needs reviewing as well if it is wanted on the incoming release | 09:15 |
| *** bethw has joined #buildstream | 09:17 | |
| tristan | tiagogomes, it wont be in 1.1.4, but I expect to cherry pick it into the bst-1.2 branch before feature freeze | 09:20 |
| tristan | I know it's unusual, but I have to end up branching like, today | 09:21 |
| coldtom | is it possible to disable looking at the cache for a single element? i.e. for all dependencies pull from cache but rebuild the element itself | 09:21 |
| tristan | so there are a few of the less complicated things which will have to land in bst-1.2 separately | 09:21 |
| tristan | coldtom, currently no; sounds like a reasonable request though, would be nice to file an issue stating the reason why you would need that (I can think of a good reason...) | 09:22 |
| tristan | coldtom, i.e. the solution might not come in the form of a way to specify exactly that, we should focus on what the user needs to do | 09:23 |
| tlater | tristan: Did you manage to make time for artifact expiry? | 09:40 |
| tlater | Ah, I just noticed the comment | 09:41 |
| tlater | Eugh | 09:41 |
| * tlater checks to see if he can figure out why that happens | 09:41 | |
| tristan | tlater, I'm hot on the trail, and will have a couple questions for you... | 09:42 |
| tristan | tlater, since you turned up... where did the matching MessageType.START messages go ? | 09:42 |
| tristan | it looks like you have ElementJob doing that separately, I don't see how the timers are coherent anymore, and where the matching START messages are for the other jobs | 09:43 |
| gitlab-br-bot | buildstream: issue #477 ("Allow rebuilding of a single element") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/477 | 09:43 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/tarball_checkout->master: Add support for creating artifact tarballs) #546 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/546 | 09:43 |
| tlater | tristan: When we discussed the other jobs we said that they would not display START messages | 09:44 |
| tlater | And generally be very minimal in logging | 09:44 |
| tristan | Eeek | 09:44 |
| tristan | Hmm | 09:44 |
| tristan | Yeah, esthetically that is fine... having "things being done differently" is not... especially having the corresponding START message in another area of the code completely, I think is pretty intolerable | 09:45 |
| tristan | tlater, that would have to be a feature that the Job abstract class exposes to the subclasses, i.e. if there are different ways to log the overall task, the subclass should politely tell the parent how it would like it to be done | 09:45 |
| tlater | Hm, alright - it's a lot harder to centralize that if half of the jobs aren't supposed to display them. Maybe have a do_logging thing? | 09:46 |
| tristan | Right now I'm going to make sure they come back overall, at the cost of more verbose logging | 09:46 |
| tristan | To enhance that, it needs to be a contract between the Job and it's subclasses | 09:47 |
| tristan | but we dont have time for that today... | 09:47 |
| tlater | Yep, that seems fine - I'll have a look at making that optional in a separate MR. | 09:47 |
| *** qinusty has joined #buildstream | 09:59 | |
| tristan | tlater, alright... can you please take a look at the tristan/local-cache-expiry branch and see if you think I've broken anything ? | 10:00 |
| tristan | tlater, I think I'm at the point where tests are passing again, and am currently building freedesktop-sdk | 10:00 |
| *** jonathanmaw has quit IRC | 10:00 | |
| *** Phil has quit IRC | 10:01 | |
| tristan | tlater, also, I'd like it if you look at the last two commits and understand what I did, and why I did it | 10:01 |
| *** Phil has joined #buildstream | 10:01 | |
| tristan | Asides from the obvious: | 10:03 |
| tristan | 9 files changed, 193 insertions(+), 319 deletions(-) | 10:03 |
| *** jonathanmaw has joined #buildstream | 10:16 | |
| tristan | tiagogomes, took a look while things build and test... patch is very nice... added just a couple comments | 10:25 |
| tiagogomes | tristan I should have probably added something to the commit message, but the stdout test is disabled | 10:28 |
| tiagogomes | Capturing binary data is not working for some reason, even If I changed to use FDCaptureBinary | 10:29 |
| tlater | tristan: Sorry, got caught by a meeting | 10:32 |
| tlater | Hmm, maybe I can sort of peek at it on my phone... | 10:33 |
| gitlab-br-bot | buildstream: merge request (relative_workspaces->master: WIP: Patch for issue #191 support relative workspaces) #504 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/504 | 10:33 |
| valentind | tristan, I am trying to cleanup the composition of includes. I was wondering. Should we have an order of composition when we have several includes in a list? Or should we merge without composition before compositing into the main node? | 10:35 |
| valentind | For example if we have: "(@): ['a.yml', 'b.yml']" | 10:35 |
| * paulsherwood notices this discussion, and wonders if this is the time to remind bst folks that if the schema is changed, bst should continue to support the old schema(s) | 10:37 | |
| valentind | paulsherwood, There is no include yet. It is a new feature. Older project.conf file will work the same way. | 10:38 |
| valentind | And .bst file too. | 10:39 |
| paulsherwood | ok cool. i was a user of a previous project which kept bumping its data format, then forcing users to upgrade by only supporting current + current -1 | 10:42 |
| paulsherwood | some users went elsewhere, rather than suffer the upgrades | 10:42 |
| tristan | tiagogomes, yesterday I noticed a comment on IRC and ended up at https://docs.pytest.org/en/latest/_modules/_pytest/capture.html | 10:45 |
| tristan | tiagogomes, not sure if that helps, you probably ended up there too... looks like the gist of it is in the snap() method | 10:45 |
| tristan | which our default one does some unicode decoding on | 10:46 |
| tristan | valentind, I believe the strict order of composition is also discussed in the email thread, isn't it ? | 10:46 |
| tristan | valentind, it may be a part of juergbi's concerns in his reply | 10:47 |
| tlater | tristan: were the last two commits the only thing you changed? | 10:47 |
| valentind | OK. let me check | 10:47 |
| tristan | tlater, no, the other things I changed were part of my nitpick comments I left for you yesterday and I just squashed those into yours | 10:48 |
| tristan | tlater, those include A.) Fixing the NEWS entries so they are a part of 1.1.4, and keep consistent empty lines between features | 10:48 |
| tristan | tlater, and B.) Fixing Job class to not use the underscore prefix for public methods (public because those are shared with subclasses) | 10:49 |
| tristan | I started with that, and then did the two commit | 10:49 |
| tlater | Ah, alright - were those first two comments on the MR? I must have missed them. | 10:49 |
| tristan | yeah, no worry, I can see you and juergbi had a bit of a struggle | 10:50 |
| tristan | really appreciate it :) | 10:50 |
| tlater | Thanks for fixing this... | 10:51 |
| tlater | I'll land an MR on which you have nothing to fix one day ;) | 10:51 |
| tristan | I'm sure you have | 10:51 |
| valentind | tristan, Ok I found it. "the effect is that every subsequent include overrides the result of the previous include" | 10:55 |
| tristan | valentind, that sounds like what I would expect yes... followed by the main including fragment overriding the said composition of includes | 10:56 |
| *** Phil has quit IRC | 10:57 | |
| *** Phil has joined #buildstream | 10:57 | |
| gitlab-br-bot | buildstream: issue #478 ("Buildstream's Confusing Terminal Output") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/478 | 11:11 |
| tristan | tlater, ok so tests are passing and I'm about ~160 builds into a full build of epiphany (still in freedesktop-sdk) | 11:12 |
| tristan | tlater, however I have yet to see any cachesize job show up | 11:12 |
| tlater | tristan: Is it *just* builds? | 11:13 |
| tristan | tlater, I'm not connected to an artifact server, so there are no pull attempts... as such I'm not sure if I was *supposed* to see any cachesize calculation jobs | 11:13 |
| tlater | tristan: Cache size calculation jobs are avoided as much as possible - if you have a lot of disk space it might take a long time before you see any | 11:13 |
| tristan | Right | 11:14 |
| tlater | Essentially, cache calculation only happens if the total size of built artifacts (before adding them to the cache) exceeds the cache quota | 11:14 |
| tristan | I expected as much, just that since I was pulling yesterday (before the rebase), I wasn't sure if there was some regression | 11:14 |
| tristan | seems like there is no regression | 11:14 |
| tristan | tlater, in any case I suppose you are confident in your test cases passing for this ? | 11:15 |
| tristan | I guess this should be pretty much covered, if they werent spawning then tests would certainly break | 11:15 |
| tlater | Yes, I am :) Just not quite as confident about concurrency, but that seems to be working too. | 11:15 |
| tristan | yeah I have a feeling that the resources.py API contract could be improved/simplified too, but this is not too worrisome | 11:17 |
| tristan | it's nice and self contained | 11:17 |
| tristan | alright, I suppose it's about time to trigger | 11:17 |
| * tlater isn't sure if he's glad or scared | 11:18 | |
| tristan | tlater, are you still in a meeting ? it would be better if you could look through the final copy | 11:18 |
| tlater | Out of the meeting, just had a look at your branch | 11:18 |
| tlater | Want me to take a look at the MR as well? | 11:18 |
| tristan | I didnt post an MR for the branch yet | 11:19 |
| tristan | but not sure what that buys you | 11:19 |
| tristan | if you want to "see the diffs on gitlab", I would recommend against it... it will take all week | 11:19 |
| tlater | Haha, fair enough | 11:19 |
| tristan | with the current gitlab JS payload ;-) | 11:19 |
| tlater | Yes, I've seen the final package in a nice emacs buffer ;) | 11:19 |
| * tristan opens an MR for the bookkeeping | 11:22 | |
| tristan | weird, it looks like with the sluggishness, a second click on the "Comment" button perhaps on my part resulted in the eventual double posting of the same comment :-S | 11:24 |
| tristan | tlater, there is another regression, which seems to be a good one | 11:24 |
| tristan | tlater, I suppose you have a much different OS and dependencies than I do... since you are most certainly running tests | 11:25 |
| tristan | (not sure if this is a regression from this or CAS yesterday actually) | 11:25 |
| tristan | But... at least on my computer, it is now impossible to run the full tests | 11:25 |
| tlater | tristan: I think that's a regression from CAS | 11:25 |
| tlater | Same thing happened to me after I'd rebased. | 11:25 |
| tristan | The infamous spuriously failing "tests/artifactcache/junctions.py::test_push_pull" test now hangs every single time | 11:25 |
| tlater | It's something with the CAS server, right? | 11:25 |
| tlater | Yep, that breaks for me, too... | 11:26 |
| tlater | It seems to be happy in CI though, so I didn't dig deeper. | 11:26 |
| tristan | Well, somehow this passes on gitlab... but at least we have something reproducible to chase | 11:26 |
| tristan | (hence, this is in fact a happy regression) | 11:26 |
| tristan | worse than this actually... the test_push_pull now fails with SIGINT blocked it seems | 11:27 |
| tristan | juergbi, ^^^ | 11:27 |
| tlater | tristan: I tend to debug that by running it once and then manually running buildstream in the debris | 11:28 |
| tristan | yup, it is nice though when you can hit ^C and see the failure | 11:29 |
| tristan | the test will at least show you the exact bst invocation it failed/hung on | 11:29 |
| tristan | now it just blocks and you have to do the detective work | 11:29 |
| tlater | Yeah... I found a pytest plugin that might help with this: https://gitlab.com/BuildStream/buildstream/issues/420 | 11:29 |
| tlater | Since hangs are actually rather frequent, I think it might be handy to actually get that into our test suite. | 11:30 |
| gitlab-br-bot | buildstream: merge request (tristan/local-cache-expiry->master: Expire artifacts in the local cache) #548 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/548 | 11:32 |
| juergbi | tristan: hm, it fails for you locally, i.e., outside Docker? it works fine here | 11:33 |
| juergbi | tlater mentioned an issue but that seemed to be Docker-specific | 11:34 |
| tristan | I've still never used docker | 11:34 |
| * tristan considers himself one of the lucky ones | 11:34 | |
| gitlab-br-bot | buildstream: merge request (franred/fix-except-argument-in-source-bundle->master: source-bundle: Enable --except option) #537 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/537 | 11:35 |
| tristan | juergbi, well I expect then I'll end up spending time debugging that, it shouldn't be hard now that it hangs like 100% of the time | 11:35 |
| juergbi | I'm also not using Docker. It works fine here with native Python 3.6 | 11:35 |
| gitlab-br-bot | buildstream: merge request (franred/fix-except-argument-in-source-bundle->master: source-bundle: Enable --except option) #537 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/537 | 11:35 |
| tristan | and *must* have something to do with some dependency... at least some dependency is causing it to be frequent or not | 11:36 |
| tristan | juergbi, ah 3.6 is something I don't have :) | 11:36 |
| * tristan is with 3.5.3 | 11:36 | |
| juergbi | have you installed grpcio via pip? | 11:37 |
| juergbi | setup.py has a relatively recent grpcio as minimum version, so we shouldn't have to deal with outdated distro packages | 11:38 |
| * juergbi has grpcio 1.13.0 in ~/.local/lib/python3.6/site-packages/ (installed via pip) | 11:38 | |
| juergbi | CI tests pass with Python 3.4 and 3.5, so it shouldn't be a Python version issue | 11:39 |
| tristan | I had to reinstall this morning so yes | 11:39 |
| tristan | juergbi, i.e. it's installed by `pip3 install --user -e .` in the buildstream checkout | 11:40 |
| juergbi | yes, that's how I install it as well (well, -U to force upgrades) | 11:40 |
| tristan | in the *buildstream* checkout | 11:41 |
| tristan | just to make sure :) | 11:41 |
| tristan | I.e. I am not putting it in a user-wide or system-wide location, BuildStream's install will yank it from the internets and shove it into .eggs/ or such as a result of it not being installed already | 11:41 |
| juergbi | hm, here pip3 install --user -e . puts dependencies in ~/.local/lib/python3.6. or maybe I'm mixing something up | 11:42 |
| * juergbi reinstalls | 11:42 | |
| tristan | juergbi, oh scratch that... I didnt expect it to do that | 11:42 |
| tristan | but it seems I have the grpc stuff in ~/.local/lib/python3.5/site-packages now | 11:43 |
| juergbi | ok, what version? just to verify | 11:43 |
| tristan | grpcio-1.13.0 | 11:45 |
| juergbi | ok, so that's fine | 11:46 |
| gitlab-br-bot | buildstream: merge request (tristan/local-cache-expiry->master: Expire artifacts in the local cache) #548 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/548 | 11:49 |
| tristan | tlater, I pulled the trigger | 11:50 |
| tristan | And will post merge land a fix to your FIXME comment in _stream.py... | 11:50 |
| tristan | hmmm, llvm does take a long time to build when you keep building ~3 other modules at the same time... | 11:51 |
| tlater | \o/ I'll take a look at reducing the verbosity | 11:52 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 11:53 |
| tristan | tlater, I'd like you to add the necessary API description comment blocks which are missing in resources.py, though | 11:55 |
| tristan | and fix the regression would also be good | 11:56 |
| * tristan opens an issue for it | 11:56 | |
| gitlab-br-bot | buildstream: issue #479 ("Incorrect summary when terminating builds") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/479 | 12:01 |
| * tristan hands tlater https://gitlab.com/BuildStream/buildstream/issues/479 | 12:02 | |
| tlater | Thanks! | 12:02 |
| noisecell | jonathanmaw, thanks for looking into the MR | 12:02 |
| *** bethw has quit IRC | 12:06 | |
| gitlab-br-bot | buildstream: merge request (dp0/453/import-order->master: Reorder app.py imports) #526 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/526 | 12:08 |
| tristan | juergbi, minor logistic point with branching... I have a choice here... | 12:09 |
| tristan | I should release 1.1.4 from the bst-1.2 branch, that much is clear | 12:09 |
| tristan | But I'd rather not release 1.3.0 at the same time | 12:09 |
| tristan | *however*, we need there to be a tag | 12:09 |
| tristan | Which would make the first 1.3.x release be 1.3.1, if we tag 1.3.0 (so that `bst --version` shows people the right thing) | 12:10 |
| juergbi | the other side of git describe? ;) | 12:10 |
| tristan | the dark side | 12:10 |
| juergbi | if we do this, we need to make sure that the commit that we tag with 1.3.0 is not on the 1.2 branch | 12:11 |
| juergbi | i.e., there needs to be at least one non-1.2 change already | 12:12 |
| juergbi | creating a 1.3.0 tag without spinning a tarball etc. is fine with me, although a bit unusual | 12:12 |
| tristan | Oh interesting... does it ? | 12:14 |
| juergbi | well, otherwise going along the 1.2 branch will jump from 1.1 to 1.3 and then back to 1.2 | 12:14 |
| tristan | I feel like semantically that shouldnt be | 12:15 |
| tristan | but the implementation might have that effect indeed | 12:15 |
| juergbi | the other option would be to lead by example and no longer use git describe ;) | 12:16 |
| tristan | juergbi, how about this... while doing the 1.1.4 release, I will anyway have to update the man pages | 12:16 |
| tristan | that will only be on the bst-1.2 branch | 12:16 |
| tristan | then I tag 1.3.0 on master | 12:16 |
| juergbi | master still being at the branch point? | 12:17 |
| Nexus | /wc | 12:17 |
| Nexus | :I | 12:17 |
| *** Nexus has left #buildstream | 12:17 | |
| juergbi | it might work in practice but to me it still feels odd to have 1.3.x tag on the bst-1.2 branch | 12:17 |
| *** Nexus has joined #buildstream | 12:17 | |
| tristan | juergbi, no no, 1.3.0 tag would be on master | 12:17 |
| tristan | not on the bst-1.2 branch | 12:17 |
| tristan | of course | 12:17 |
| juergbi | right but if there have been no merges to master since the bst-1.2 branch point, master HEAD will be on the bst-1.2 branch as well | 12:18 |
| tristan | A.) create bst-1.2 branch... B.) add release related commit... C.) tag 1.1.4 there | 12:18 |
| tristan | D.) Tag *master* with 1.3.0 | 12:18 |
| juergbi | if there has been no merge to master between A and D, master will still point to a commit that is also in the bst-1.2 branch | 12:18 |
| tristan | juergbi, semantically my gut disagrees with you... without knowing the internals of git... I think a tag on master is a tag on master, not a tag on bst-1.2 just because the tree shas may happen to match | 12:19 |
| juergbi | a tag applies to a commit, not to a branch | 12:19 |
| tristan | I see what you mean | 12:19 |
| juergbi | a tag is just a name for a commit | 12:19 |
| tristan | So, it's not such a bad thing | 12:20 |
| tristan | actually, 1.3.0 will point to a commit in bst-1.2's history | 12:20 |
| juergbi | exactly, that's what I would like to avoid | 12:20 |
| juergbi | as this could be confusing | 12:20 |
| juergbi | we could just wait until master gets at least one commit and then tag it | 12:20 |
| tristan | Sure | 12:21 |
| Kinnison | Surely there's no point tagging 1.3.0 until there's a material difference between it and the basis of 1.2 anyway? | 12:21 |
| juergbi | git describe is used to create a version number | 12:21 |
| tristan | Kinnison, the point is strictly for git describe | 12:21 |
| tristan | yeah | 12:21 |
| * Kinnison is still not entirely sure how no material difference should result in a different version number, but hey :-) | 12:22 | |
| tristan | so devs and users are aware they are using 1.3.x | 12:22 |
| juergbi | branches will be merged to master before the first 1.3.x dev release | 12:22 |
| tristan | Technically, they need not know that until there *is* a material difference | 12:22 |
| juergbi | if we don't tag 1.3.0 early on, the generated version number will be misleading with these new features | 12:22 |
| tristan | It's just one more thing to remember to do, outside of the scope of this branching activity | 12:22 |
| *** bochecha has quit IRC | 12:28 | |
| tristan | juergbi, ignoring for now, but click_man barfs when trying to generate man pages for bst-artifact-server, probably a bad docstring or such | 12:30 |
| juergbi | oh, maybe I can take a look at this later today | 12:30 |
| valentind | tristan, However something is not clear. Let's say I include in a list a.yml and b.yml. a.yml has "test: {'(>)': ["second"]}" and b.yml has "test: ["first"]". Should the "second" in a.yml be ignored? Or should it be composed into the result? | 12:32 |
| gitlab-br-bot | buildstream: merge request (coldtom/275->master: Indicate where artifacts are going to and coming from in the log) #518 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/518 | 12:37 |
| *** toscalix has joined #buildstream | 12:44 | |
| tristan | valentind, I don't have the head for this today, sending out two emails and going to dinner | 12:45 |
| valentind | tristan, OK. | 12:45 |
| tristan | valentind, the list append/prepend directives should really be handled transparently by composition | 12:45 |
| valentind | tristan, I will try to make something sensible and make it ready for review for tomorrow. | 12:45 |
| tristan | and a final pass ensures there is nothing left uncomposited | 12:46 |
| valentind | I will add tests so it is obvious. | 12:46 |
| tristan | ok 1.1.4 is out ! | 12:47 |
| *** ChanServ sets mode: +o tristan | 12:47 | |
| *** tristan changes topic to "/BuildStream 1.1.4 is out ! | https://gitlab.com/BuildStream/buildstream | Docs: https://buildstream.gitlab.io/buildstream | IRC logs: https://irclogs.baserock.org/buildstream | Roadmap: https://wiki.gnome.org/Projects/BuildStream/Roadmap" | 12:47 | |
| tristan | bst-1.2 branch is up, and in protected state like bst-1.0 and master | 12:48 |
| tristan | master is now open for 1.3 material | 12:48 |
| laurence | ace :) | 12:52 |
| laurence | just seen the mail | 12:52 |
| *** laurence has left #buildstream | 12:55 | |
| *** laurence has joined #buildstream | 12:55 | |
| gitlab-br-bot | buildstream: issue #453 ("Testing locally fails due to wrong import order") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/453 | 12:58 |
| gitlab-br-bot | buildstream: merge request (dp0/453/import-order->master: Reorder app.py imports) #526 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/526 | 12:58 |
| *** bethw has joined #buildstream | 13:00 | |
| *** jennis__ has joined #buildstream | 13:00 | |
| *** jennis2 has quit IRC | 13:01 | |
| tristan | Alright all emails sent :) | 13:01 |
| laurence | enjoy the dinner :) | 13:02 |
| tristan | That leaves us with includes and the integration commands thing I have to bang out... and then whichever minor/safe things we can backport from master before feature freeze | 13:02 |
| tristan | laurence, I will ! | 13:03 |
| laurence | I emailed Agustin privately to delay any implementation of automating gitlab to sent patches to the ML, btw | 13:04 |
| *** jonathanmaw has quit IRC | 13:04 | |
| laurence | didn't do so on the public list since i personally have no strong feelings myself | 13:04 |
| tristan | thanks laurence | 13:12 |
| tristan | If everybody wants specifically *that* instead of a separate mailing list or separate channel of communication, I wont push back, but I don't think this decision was well thought out | 13:12 |
| tristan | Our public facing infrastructure should be optimized for low barrier of entry and occasional participants, such that we are a pleasant place to participate in | 13:13 |
| tristan | and I think that spaming the public discussion mailing list, even if "people can setup filters", is counter productive in that sense | 13:14 |
| tristan | given that level of traffic of a mailing list is often the deciding factor in whether someone decides to remain subscribed to a mailing list | 13:14 |
| Nexus | tristan: do you have a few minutes, i 'm try to fix a bug and would like your input | 13:16 |
| *** toscalix has quit IRC | 13:18 | |
| *** tristan has quit IRC | 13:19 | |
| qinusty | I'm looking to pickup https://gitlab.com/BuildStream/buildstream/issues/275 after the CAS cache changes. I'm unable to self assign the issue though (permissions I assume). | 13:35 |
| juergbi | tristan: fyi, I've merged a first tiny MR to master, in case you want to tag 1.3.0 | 13:37 |
| Nexus | tristan re: #449, workspace open force functionality, i looked in the _stream.py workspace open function, force is never actually used, like the functionality just doesn't exist. Do you happen to know A) how this happened, and B) what it was originally intended to do? | 13:42 |
| jjardon | qinusty: what is you id in gitlab | 13:43 |
| qinusty | Qinusty | 13:43 |
| Nexus | qinusty: | 13:43 |
| jjardon | qinusty: done | 13:45 |
| jjardon | Is there a way to indicate bst to not take in account a element for the overlaps | 13:49 |
| jjardon | ? | 13:49 |
| jjardon | if not everything is going to overlap with our base element: /usr/bin/file: files-stage1.bst is not permitted to overlap other elements, order files-stage1.bst above dependencies/base-sdk-image.bst | 13:50 |
| jjardon | /usr/share/misc/magic.mgc: files-stage1.bst is not permitted to overlap other elements, order files-stage1.bst above dependencies/base-sdk-image.bst | 13:50 |
| juergbi | jjardon: there is https://buildstream.gitlab.io/buildstream/format_public.html#overlap-whitelist | 13:51 |
| jjardon | yup, but what we want here is to say to bst that "base-sdk-image can be overlapped", not patch all the other elements (as I do not want them to overlap between them). I know is a corner case but not sure how to solve it | 13:53 |
| qinusty | Cheers jjardon, Also submitting an issue for a failing example? I can't seem to find any issues which match the problem I'm seeing. | 13:55 |
| gitlab-br-bot | buildstream: issue #480 ("doc/examples/flatpak-autotools Unhandled exception") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/480 | 13:56 |
| juergbi | jjardon: this might not be possible. maybe jonathanmaw could answer this better when he's back as he implemented it | 13:57 |
| juergbi | in my bootstrap tests, I completely avoided any overlaps, so I didn't need any exceptions | 13:58 |
| juergbi | (i.e., I didn't mix binaries from different bootstrapping stages in a single hierarchy) | 13:58 |
| jjardon | ok, thanks juergbi | 14:00 |
| *** jonathanmaw has joined #buildstream | 14:50 | |
| *** bochecha has joined #buildstream | 14:52 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/tarball_checkout->master: Add support for creating artifact tarballs) #546 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/546 | 14:54 |
| qinusty | Hi guys, does anyone have any bst projects which push/pull artifacts so I can reproduce https://gitlab.com/BuildStream/buildstream/issues/275 locally? | 14:57 |
| juergbi | qinusty: for pushing you need write/push access to a artifact server. this is often only granted to CI systems / limited set of users | 14:59 |
| juergbi | the pull part should be easier. however, the switch to CAS is extremely recent, so projects likely haven't migrated yet | 14:59 |
| juergbi | (freedesktop-sdk has a CAS test server, though) | 14:59 |
| tlater | qinusty: "extremely recent" means two days ago ;) | 15:00 |
| juergbi | it is possible to set up your own CAS server (locally), though: https://buildstream.gitlab.io/buildstream/install_artifacts.html | 15:00 |
| juergbi | and if you set it up locally without public access, you can skip the authorization/key generation part, making it pretty simple | 15:02 |
| qinusty | Alright, I was just wondering what the current state of that issue is. Since the CAS change, I wonder what the current output information displayed is. | 15:02 |
| qinusty | I'll set up my own instance and see what we're currently showing and update the issue appropriately | 15:03 |
| coldtom | could I get this reviewed please https://gitlab.com/BuildStream/bst-external/merge_requests/35 | 15:04 |
| gitlab-br-bot | buildstream: merge request (bst_workspace_open_force_does_nothing->master: _stream.py: Added functionality for workspace open -f) #549 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/549 | 15:08 |
| gitlab-br-bot | buildstream: merge request (franred/fix-except-argument-in-source-bundle->master: source-bundle: Enable --except option) #537 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/537 | 15:15 |
| gitlab-br-bot | buildstream: merge request (chandan/use-testsuite-fedora->master: .gitlab-ci.yml: Use testsuite images for running tests) #531 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/531 | 15:18 |
| gitlab-br-bot | buildstream: merge request (chandan/use-testsuite-fedora->master: WIP: .gitlab-ci.yml: Use testsuite images for running tests) #531 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/531 | 15:20 |
| *** ernestask has quit IRC | 15:21 | |
| gitlab-br-bot | buildstream: merge request (chandan/use-testsuite-fedora->master: WIP: .gitlab-ci.yml: Use testsuite images for running tests) #531 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/531 | 15:22 |
| gitlab-br-bot | buildstream: merge request (chandan/use-testsuite-fedora->master: WIP: .gitlab-ci.yml: Use testsuite images for running tests) #531 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/531 | 15:23 |
| *** jennis__ has quit IRC | 15:29 | |
| *** jennis__ has joined #buildstream | 15:29 | |
| *** jennis__ is now known as jennis | 15:38 | |
| laurence | tpollard, Kinnison, qinusty, are you guys members of the BuildStream group on gitlab? | 16:18 |
| laurence | Here's the link to request it if not - https://gitlab.com/groups/BuildStream/-/group_members | 16:18 |
| * Kinnison is not, but doesn't see how that link helps him request access | 16:19 | |
| bethw | https://gitlab.com/BuildStream --> "Request Access" button | 16:20 |
| *** jonathanmaw has quit IRC | 16:21 | |
| tpollard | done | 16:22 |
| gitlab-br-bot | buildstream: issue #480 ("doc/examples/flatpak-autotools Unhandled exception") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/480 | 16:30 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: WIP: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 16:38 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 16:41 |
| gitlab-br-bot | buildstream: merge request (phil/437-junction-tutorial->master: WIP Phil/437 junction tutorial) #550 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/550 | 16:42 |
| gitlab-br-bot | buildstream: merge request (bst_workspace_open_force_does_nothing->master: _stream.py: Added functionality for workspace open -f) #549 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/549 | 16:43 |
| gitlab-br-bot | buildstream: issue #481 ("Misleading SUCCESS status when artifact push is skipped") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/481 | 16:45 |
| *** thomascoldrick has joined #buildstream | 16:49 | |
| *** coldtom has quit IRC | 16:49 | |
| *** leopi has joined #buildstream | 16:50 | |
| *** thomascoldrick has quit IRC | 16:53 | |
| *** finn_ has joined #buildstream | 16:54 | |
| *** qinusty has quit IRC | 16:56 | |
| *** bethw has quit IRC | 17:11 | |
| *** Prince781 has joined #buildstream | 17:12 | |
| *** leopi has quit IRC | 17:26 | |
| gitlab-br-bot | buildstream: merge request (chandan/use-testsuite-fedora->master: WIP: .gitlab-ci.yml: Use testsuite images for running tests) #531 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/531 | 17:47 |
| *** tristan has joined #buildstream | 17:54 | |
| gitlab-br-bot | buildstream: merge request (chandan/use-testsuite-fedora->master: WIP: .gitlab-ci.yml: Use testsuite images for running tests) #531 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/531 | 17:56 |
| gitlab-br-bot | buildstream: merge request (chandan/use-testsuite-fedora->master: .gitlab-ci.yml: Use testsuite images for running tests) #531 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/531 | 18:01 |
| gitlab-br-bot | buildstream: merge request (chandan/use-testsuite-fedora->master: .gitlab-ci.yml: Use testsuite images for running tests) #531 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/531 | 18:03 |
| *** cs_shadow has joined #buildstream | 18:10 | |
| *** leopi has joined #buildstream | 18:30 | |
| *** leopi has quit IRC | 19:09 | |
| *** tristan has quit IRC | 20:27 | |
| *** bochecha has quit IRC | 23:14 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!