| *** lannister has joined #buildstream | 03:30 | |
| *** leopi has joined #buildstream | 04:06 | |
| *** leopi has quit IRC | 04:28 | |
| *** leopi has joined #buildstream | 05:09 | |
| *** tristan has joined #buildstream | 05:54 | |
| *** mohan43u has quit IRC | 06:23 | |
| *** mohan43u has joined #buildstream | 06:23 | |
| *** WSalmon has quit IRC | 06:36 | |
| *** ernestask has joined #buildstream | 06:59 | |
| *** tristan has quit IRC | 07:14 | |
| *** leopi has quit IRC | 07:15 | |
| *** leopi has joined #buildstream | 07:16 | |
| *** toscalix has joined #buildstream | 07:25 | |
| *** bochecha has joined #buildstream | 07:26 | |
| *** qinusty has joined #buildstream | 08:07 | |
| *** WSalmon has joined #buildstream | 08:08 | |
| *** tristan has joined #buildstream | 08:17 | |
| *** Phil has joined #buildstream | 08:30 | |
| gitlab-br-bot | buildstream: merge request (Qinusty/397->master: Modify retry behaviour to be opt-in on exceptions during job processing) #559 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/559 | 08:33 |
|---|---|---|
| tiagogomes | tristan normally cli tools are that verbose by default… A system integrator is probably more interested in tracking progress than viewing the commands executed | 08:36 |
| tiagogomes | Also bear in mind that in case of necessity, one can view the commands executed at a particular step by checking bst files (and the defaults perhaps) | 08:37 |
| tristan | tiagogomes, you know... I'm a bit ambivalent on this point :) | 08:41 |
| tristan | Since it's UI, it's not an API break really to change the default of verbose, but to change it requires at least a proposal to the ML | 08:42 |
| tristan | tiagogomes, certainly though; we need to fix the UI to honor the setting, I think the STATUS messages after all the churn we had, do not honor the verbosity setting and print regardless | 08:42 |
| * qinusty always wonders what people mean when they say ML | 08:43 | |
| tristan | mailing list | 08:43 |
| qinusty | thanks :) | 08:43 |
| tristan | np :) | 08:44 |
| tiagogomes | The commands executed are also part of the artifact log. So there's more places check these | 08:45 |
| tristan | tiagogomes, I'm not disagreeing with you :) | 08:46 |
| tristan | really, I also enjoy having a mode where only the START/[SUCCESS/FAIL]/ERROR messages are printed | 08:46 |
| tiagogomes | ok :) | 08:47 |
| tristan | and am not particularly picky about whether it is default, I tend to agree with you it should not be, but iirc others disagreed at the time | 08:47 |
| tristan | but if we propose that change we could probably get the default changed too | 08:47 |
| tristan | tiagogomes, I feel that mode would be even more interesting if we had some progress sugar in the status too, e.g. see todays comment here: https://gitlab.com/BuildStream/buildstream/issues/499 | 08:49 |
| qinusty | tristan: do you have thoughts on https://gitlab.com/BuildStream/buildstream/issues/355? | 08:52 |
| tiagogomes | #499 would be nice. Back in the days or morph I think I was looking for doing some that for git, but it was not easily doable :( Things might have changed meanwhile though | 08:55 |
| tristan | qinusty, commented | 08:58 |
| tristan | tiagogomes, note, I just tested it out, the regression I was suspicious about did not happen | 09:00 |
| tristan | tiagogomes, I am however seeing this sad regression: https://gitlab.com/BuildStream/buildstream/issues/507 | 09:02 |
| tristan | ugh | 09:02 |
| tristan | i.e. the regression I suspected was STATUS messages printed regardless; confirmation: STATUS messages are NOT printed when verbosity is disabled, so this did not regress | 09:03 |
| tristan | START/[SUCCESS/FAIL]/INFO/WARNING/ERROR messages are still printed | 09:03 |
| tristan | And yeah, nod; definitely not every kind of task is going to be able to support progress; it would be great if we could do it for git | 09:05 |
| WSalmon | Kinnison, tpollard and myself have added notes to https://etherpad.gnome.org/p/BST__DS's_Documentation_notes and i am about to tidy up and submit a patch for the uncontroversial low hanging fruit as noted in the etherpad could a more experienced bst hand please add some notes to this etherpad for the bullet points without added notes. | 09:05 |
| *** jonathanmaw has joined #buildstream | 09:09 | |
| Kinnison | tristan: If you get a moment, !561 has been updated by tpollard and is waiting for you to double-check he's addressed your points. Nexus has reviewed and approved it, so it should hopefully be quick for you. | 09:12 |
| tristan | Kinnison, ah that one crossed my mind indeed, wanted to ping him and make sure that was well understood | 09:15 |
| tristan | I'll check it out now should be pretty quick | 09:15 |
| Kinnison | tristan: Cool, any feedback is useful as tpollard spools up on the project | 09:15 |
| Kinnison | tristan: thank you! | 09:15 |
| tpollard | tristan: cheers | 09:18 |
| tristan | Done ! | 09:20 |
| tristan | tpollard, do I understand your list comprehensions there as basically: "Remove any failure messages pertaining to that element, if that element is not tainted as a failure by the Queues" ? | 09:22 |
| tpollard | it's checking if any element with a stored failure messages exists in any of the failures queues, if it does print it | 09:26 |
| tpollard | so the comprehension will make the list exist if it finds a match | 09:26 |
| jonathanmaw | tristan: I've replied to your comment about Source.set_alias(), tl;dr we can get rid of it if it's fine to mandate Source.translate_url is called in configure even if you don't use the result | 09:27 |
| gitlab-br-bot | buildstream: merge request (willsalmon/documentation_form_notes->master: Documentation typos and fixes) #569 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/569 | 09:28 |
| tristan | jonathanmaw, I saw it, I need some time | 09:29 |
| tristan | tpollard, Ok so, semantically different but the same: construct a list of the failure messages based on the recorded failure messages, minus the failure messages which don't have a failing element on the queues | 09:30 |
| tristan | tpollard, correct ? | 09:30 |
| tpollard | tristan: that's what I expect, to be placed in values[] | 09:31 |
| tristan | tpollard, I'm happy to merge that (with comments addressed); but I'd like you to file an additional bug | 09:31 |
| tristan | Or, do I | 09:31 |
| tristan | yes I think so | 09:32 |
| tristan | tpollard, if something is retried a bunch of times and never succeeds, should we be seeing all the failures of all the attempts, or just the last one, in the failure summary ? | 09:32 |
| tristan | tpollard, I tend to think it should only be the last one | 09:32 |
| tristan | tpollard, since your patch does not catch that case, I would like a new issue for it | 09:33 |
| tpollard | tristan: I agree too, you mentioned that in a previous comment on the MR too | 09:33 |
| tpollard | my only point is that I guess the previous failures on a same element could be useful in some cases | 09:34 |
| gitlab-br-bot | buildstream: merge request (jmac/virtual_directories->master: Abstract directory class and filesystem-backed implementation) #445 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/445 | 09:35 |
| qinusty | tristan: I can't seem to get this spurious CI failure to happen when running locally :/ | 09:35 |
| qinusty | regardless: temporary error branch is ready for review https://gitlab.com/BuildStream/buildstream/merge_requests/559 Unix pipeline failed 3 times due to this move cloned repo issue. | 09:47 |
| qinusty | tlater: https://gitlab.com/BuildStream/buildstream/merge_requests/563 also has further discussion | 09:49 |
| *** flatmush has quit IRC | 09:58 | |
| tlater | qinusty: I commented on that | 10:11 |
| qinusty | yup, just replying tlater :P Some slight confusion on my part | 10:11 |
| tlater | Let's discuss here | 10:11 |
| tlater | :) | 10:11 |
| tlater | qinusty: Just to be clear; I'd like to *reduce* the amount of cache space buildstream internally thinks it has by the headroom | 10:12 |
| tlater | Instead of checking that there is more space available than what the user asks for | 10:12 |
| tlater | That way the detail of cache headroom stays entirely within buildstream, and no user will ever have to think about it. | 10:13 |
| qinusty | Okay, that clears it up a little. | 10:15 |
| tlater | Any remaining concerns? | 10:16 |
| qinusty | See comment* Just my current implementation allowing cache_quota to be > the current cache_size | 10:17 |
| tlater | I don't quite follow the comment - if we say `cache_quota = cache_quota_user - headroom`, surely there's nothing that could go wrong? | 10:18 |
| qinusty | My concern is regarding the current cache. So if you spin up an instance of the cache server with cache already in the folder. It could be 30GB | 10:19 |
| tlater | Ah, I see | 10:19 |
| qinusty | but you could say "Only allow 2GB", what does it do then? | 10:19 |
| tlater | qinusty: Buildstream will behave as if you have no cache quota assigned | 10:20 |
| jonathanmaw | qinusty: print "lol", I assume | 10:20 |
| tlater | This will mean that it can build and store one artifact at a time ;p | 10:20 |
| qinusty | if you desire jonathanmaw :D | 10:20 |
| tlater | Oh, *now* I see what you mean | 10:20 |
| tlater | Right | 10:20 |
| qinusty | In reality, should we flag this up? Suggest clearing the cache? | 10:21 |
| tlater | Perhaps a warning; buildstream will start clearing the cache the moment it notices there's too much data | 10:21 |
| qinusty | Oh okay, if that is implemented elsewhere that's fine | 10:21 |
| gitlab-br-bot | buildstream: issue #516 ("Buildstream can not build from non-numeric tags") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/516 | 10:33 |
| 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 | 10:53 |
| WSalmon | so i have been playing with https://gitlab.com/willsalmon/buildstream-kicad a bit more and depending if if i track the junctions or the main project first i get diffrent failures, is this expected or a bug? | 11:03 |
| *** jonathanmaw_ has joined #buildstream | 11:03 | |
| *** jonathanmaw has quit IRC | 11:03 | |
| WSalmon | I think jonathanmaw helped me with this but I cant remember exactly what we decided. | 11:04 |
| * tlater notes jonathanmaw_ has a different nick here these days, in case he comes back and misses WSalmon ;) | 11:05 | |
| gitlab-br-bot | buildstream: merge request (phil/436-add-ubuntu-install-intructions->master: Phil/436 Update install intructions) #525 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/525 | 11:15 |
| noisecell | WSalmon, I suggest you create an use case and open a bug with the logs that shows the behaviour which you think is a bug | 11:37 |
| noisecell | possibly you will get a more concrete feedback and it is tracked | 11:37 |
| gitlab-br-bot | buildstream: merge request (phil/437-workspaces-tutorial->master: Phil/437 workspaces tutorial) #519 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/519 | 11:39 |
| gitlab-br-bot | buildstream: merge request (phil/add-ubuntu-ci-job->master: .gitlab-ci-yml: Add ubuntu 18 test) #523 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/523 | 11:45 |
| tristan | jonathanmaw_, can we discuss set_alias() for a moment ? | 11:46 |
| tristan | I think I understand better, but think we should change that | 11:46 |
| jonathanmaw_ | tristan: okay, what do you have in mind? | 11:50 |
| tristan | jonathanmaw_, ok so first ... lemme see if I understand this correctly... | 11:50 |
| tristan | jonathanmaw_, Say I have a source implementation, and an instance of that source is configured with "url: farm:pony.git" | 11:51 |
| tristan | jonathanmaw_, your intention is to have the plugin call self.set_alias("farm"), instead of needing to call self.translate_url("farm:pony.git"), if the source doesnt care about the return value at that stage | 11:52 |
| tristan | jonathanmaw_, is that correct ? | 11:52 |
| jonathanmaw_ | correct | 11:52 |
| tristan | Ok good, I understand :) | 11:53 |
| tristan | So in that case, I think it can make sense to have the API appear both on the Source and the SourceFetcher... there is a "but" | 11:53 |
| tristan | jonathanmaw_, Until now, we have never given the plugin the responsibility of parsing a url with an alias string | 11:54 |
| tristan | And we would do better to avoid that | 11:54 |
| tristan | jonathanmaw_, if ever we need to change anything or enhance anything around that parsing (already, there is the possibility to mistakenly parse an alias such as "http"), then that should be possible without ever having to update any plugins | 11:55 |
| tristan | jonathanmaw_, So, I think we need to just change both "set_alias()" apis to be a function which provides the URL in it's full form to the core, conveying the Source's intention to use this string for downloading something, and allowing the core to check if the string contains an alias, and extract that alias | 11:56 |
| tristan | jonathanmaw_, Does that make good sense to you ? | 11:56 |
| jonathanmaw_ | tristan: yes | 11:57 |
| tristan | Great, I think code wise, functionality wise, we are pretty much "there" with your branch; the remaining problem is to choose a good name for this function and convey it's meaning clearly to plugin authors | 11:57 |
| tristan | possibly something like "mark_download_url()" ? | 11:58 |
| jonathanmaw_ | tristan: works for me | 11:58 |
| * tristan ^5s jonathanmaw_ :) | 11:58 | |
| jonathanmaw_ | o/*\o | 11:59 |
| tristan | haha nice | 11:59 |
| *** jennis2 has joined #buildstream | 12:00 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-500->master: Tiagogomes/issue 500) #570 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/570 | 12:00 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-500->master: Handle additional types on `_process_list`) #570 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/570 | 12:01 |
| *** jennis has quit IRC | 12:01 | |
| jonathanmaw_ | tristan: I'll remove the Source.split_aliased_url method as well, since it's no longer necessary | 12:06 |
| tristan | jonathanmaw_, that makes great sense, yes | 12:07 |
| gitlab-br-bot | buildstream: merge request (Qinusty/491->master: Cache size is now restricted to available disk space) #563 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/563 | 12:21 |
| qinusty | tristan: When you get a spare timeslot can you review https://gitlab.com/BuildStream/buildstream/merge_requests/559?commit_id=2ba0b156c84bc2392f98e9fc2b650c8dbed9c338? | 12:23 |
| tpollard | tristan: I replied to a comment of yours on https://gitlab.com/BuildStream/buildstream/merge_requests/561#note_90520003 if you get a chance to take a look :) | 12:48 |
| tpollard | I've reworked the previous suggestion so just waiting on that before rebasing | 12:49 |
| gitlab-br-bot | buildstream: merge request (Qinusty/397->master: Modify retry behaviour to be opt-in on exceptions during job processing) #559 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/559 | 12:53 |
| tristan | tpollard, qinusty ... done and done ! | 13:08 |
| tristan | :) | 13:08 |
| tpollard | cheers! | 13:08 |
| qinusty | Cheers :) | 13:08 |
| tristan | tpollard, I suppose my comment on the list comprehension will have a code change if you A.) Do the filtering first... B.) Check if errors remain to be printed | 13:10 |
| tristan | tpollard, the optimization is quite small but better practice, if you need to do a check of that kind, we should use any() on a generator expression, rather than using a full list comprehension | 13:11 |
| tpollard | tristan: I agree, I just defaulted to doing the list comp. I've switch it over to any() now & will push it up soon | 13:12 |
| tristan | I am intent on leaving soon... but will stop in and give it a late night check; I'm tempted to just say land it with the fix | 13:13 |
| tristan | tpollard, at this point, the patch approach is completely satisfactory, so you might just get anyone else to give it a lookover and land it | 13:14 |
| tristan | thanks for fixing that ! | 13:14 |
| tristan | :) | 13:14 |
| gitlab-br-bot | buildstream: merge request (tpollard/386->master: _frontend: Don't print failure summary on build success) #561 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/561 | 13:20 |
| tpollard | would help if I modded the message, sigh | 13:21 |
| tristan | tpollard, woops | 13:22 |
| tristan | tpollard, You did not change the filtering to come *before* the check if any failure messages need to be printed :) | 13:22 |
| tristan | tpollard, so you will have a "Failure Summary" with no failures, when all failures get filtered out | 13:23 |
| gitlab-br-bot | buildstream: merge request (Qinusty/397->master: Modify retry behaviour to be opt-in on exceptions during job processing) #559 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/559 | 13:23 |
| gitlab-br-bot | buildstream: merge request (edbaunton/remote-source->master: Add remote source plugin) #541 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/541 | 13:23 |
| gitlab-br-bot | buildstream: merge request (Qinusty/397->master: Modify retry behaviour to be opt-in on exceptions during job processing) #559 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/559 | 13:24 |
| tristan | tpollard, other than this which needs fixing... maybe you already filed one, but just make sure that you file an issue about the remaining shortcoming that we discussed earlier | 13:24 |
| qinusty | Sorry for the spam, forgot to rebase to master before pushing :/ | 13:24 |
| tristan | tpollard, please :) | 13:24 |
| tpollard | tristan: sure | 13:25 |
| qinusty | tlater: Changes made to https://gitlab.com/BuildStream/buildstream/merge_requests/563 | 13:32 |
| tlater | qinusty: Thanks, taking a look | 13:32 |
| tlater | Sorry that branch is taking so long | 13:32 |
| tlater | I should have put more time into that before landing expiry... | 13:33 |
| qinusty | No worries! I'm just juggling branches atm so I'm looking to close a few off :D | 13:37 |
| *** Phil has quit IRC | 13:40 | |
| *** Phil has joined #buildstream | 13:40 | |
| * tlater gives the behavior a test | 13:40 | |
| *** OvidiuS has joined #buildstream | 13:41 | |
| * qinusty tested a few cases but didn't manage to see the clearing behaviour | 13:43 | |
| tlater | qinusty: Yeah, I'm interested if that happens. | 13:45 |
| *** tristan has quit IRC | 13:45 | |
| gitlab-br-bot | buildstream: merge request (willsalmon/documentation_form_notes->master: Documentation typos and fixes) #569 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/569 | 13:48 |
| gitlab-br-bot | buildstream: merge request (328-support-for-downloading-sources-from-mirrors->master: Resolve "Support for downloading sources from mirrors") #404 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/404 | 13:52 |
| * qinusty wonders if he's the only one frustrated by the occasional test_build_track CI failures | 13:53 | |
| tlater | qinusty: Do you have a link to output of such? | 13:54 |
| * tlater may be able to explain | 13:54 | |
| *** edb has joined #buildstream | 13:54 | |
| qinusty | https://gitlab.com/BuildStream/buildstream/issues/503 | 13:54 |
| qinusty | I've been trying to figure it out off and on, haven't gotten too far but I'm not too familiar with how the sources manage files | 13:54 |
| qinusty | and how the tests allocate tmpdir | 13:55 |
| tlater | Ah | 13:56 |
| qinusty | I ran the test_build_track tests on my machine 5 times and it passes all 5 times :D | 13:56 |
| tlater | qinusty: I don't think anyone but tristan has actually reported seeing this | 13:56 |
| qinusty | I see it often | 13:56 |
| * tlater thought he did at first, but this seems to be unrelated | 13:56 | |
| *** xjuan has joined #buildstream | 13:56 | |
| qinusty | https://gitlab.com/BuildStream/buildstream/-/jobs/84599623 | 13:57 |
| tlater | qinusty: It's a tricky one, looking at tristan's issue here | 13:57 |
| qinusty | Just failed on one of my commits, on both debian and unix | 13:57 |
| Kinnison | Is there a way to run the test suite parallelised (I have 8 CPUs it'd be rude not to use them all) ? | 13:57 |
| tlater | Kinnison: Yes, hang, I'll figure out the magic invocation to make it do so | 13:58 |
| qinusty | It ends up adding about 30 minutes to my pipeline because I have to retry atleast one platform once or twice | 13:58 |
| tlater | But we currently don't guarantee it working parallelized | 13:58 |
| tlater | qinusty: :| | 13:58 |
| tlater | I suggest you run the simple test suite offline | 13:58 |
| Kinnison | tlater: what about the suite means parallelisation of it isn't reliable/guaranteeable? | 13:58 |
| tlater | Until you actually want someone to look at things | 13:58 |
| tlater | Kinnison: The fact that no dev currently runs it with parallelization | 13:59 |
| tlater | And we therefore don't really know if it is reliable ;p | 13:59 |
| Kinnison | tlater: Oh | 13:59 |
| * Kinnison is amazed | 13:59 | |
| * tlater thinks test runs by some of us have come out as "yeah, probably works" | 13:59 | |
| tiagogomes | won't there be conflicts at least in the integration-cache directory | 13:59 |
| Kinnison | I'd expect the devs to want to make the test runs as fast as possible | 13:59 |
| * Kinnison went to great effort to make Gitano's test suite run in parallel because it makes it so much easier to run | 13:59 | |
| tlater | Probably, but I suspect the parallelization actually doesn't do much for us | 13:59 |
| tlater | It's worth trying out, certainly | 14:00 |
| * tlater never found the time to ensure it works though | 14:00 | |
| Kinnison | tlater: I'd like to be able to spend > 16% of my system's resources on making it go faster :-) | 14:00 |
| * Kinnison has given his buildstream VM 16G of RAM and 4 cores. Plenty of room for test suite runs I thought | 14:00 | |
| Kinnison | I feel like I could have given it 4G and 1 core | 14:00 |
| tlater | Yep, I agree, happy for anyone to look into this in detail... For now I'll just supply the flag to you with a caveat of "it may turn out ot break horribly" | 14:01 |
| tlater | Kinnison: I also suggest you only run the default suite | 14:01 |
| tlater | I.e., don't go enabling "integration" tests | 14:01 |
| * Kinnison just ran 'setup.py test' | 14:01 | |
| tlater | Because I'm fairly certain those will break | 14:01 |
| tlater | Yep, that works :) | 14:01 |
| * Kinnison would be super-sad if the integration tests failed when invoked in parallel | 14:02 | |
| * Kinnison puts "look at the test suite" on his list | 14:02 | |
| Kinnison | tlater: so 'setup.py test' is that *just* unit tests? | 14:05 |
| tlater | Kinnison: Oof, that's also a big topic | 14:05 |
| qinusty | --integration turns integration tests on afaik | 14:05 |
| tlater | A slight pain topic for me | 14:06 |
| tlater | "Integration test" is used in a non-standard way in BuildStream | 14:06 |
| tlater | It means "A test that invokes a sandbox" | 14:06 |
| tlater | In reality, almost all buildstream's tests are integration tests | 14:06 |
| gitlab-br-bot | buildstream: merge request (tpollard/386->master: _frontend: Don't print failure summary on build success) #561 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/561 | 14:06 |
| gitlab-br-bot | buildstream: issue #163 ("Buildstream should support downloading blobs and patches from http") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/163 | 14:06 |
| gitlab-br-bot | buildstream: issue #163 ("Buildstream should support downloading blobs and patches from http") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/163 | 14:06 |
| Kinnison | Oh | 14:07 |
| tlater | We only have a small number of unit tests for the yaml parser | 14:07 |
| gitlab-br-bot | buildstream: merge request (edbaunton/remote-source->master: Add remote source plugin) #541 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/541 | 14:07 |
| * Kinnison did wonder how a unit test suite could take nearly half a kilosecond to run | 14:07 | |
| tlater | `./setup.py test` will by default run all tests that do not invoke sandboxes | 14:07 |
| *** tristan has joined #buildstream | 14:07 | |
| * tlater wants to rename these things in time | 14:07 | |
| * tlater should pay some attention to the test suite at some point, too | 14:07 | |
| Kinnison | tlater: so can I invoke those tests in parallel, and if so, how? | 14:08 |
| tlater | Kinnison: So, the command you're supposed to use is: `./setup.py test --addopts '-n <runners>'` | 14:08 |
| Kinnison | okay | 14:08 |
| * Kinnison tries | 14:08 | |
| tlater | Quickly trying that out seems to just break pytest for me | 14:08 |
| tlater | But that might depend on versions... | 14:08 |
| * Kinnison grumps that ^C doesn't seem to stop the tests | 14:08 | |
| * Kinnison presses it many times | 14:08 | |
| Kinnison | still no stop | 14:09 |
| * tlater agrees this is annoying | 14:09 | |
| Kinnison | what madness is this? | 14:09 |
| juergbi | I typically use -n auto for maximum parallelism | 14:09 |
| * Kinnison gives up for now | 14:09 | |
| tlater | juergbi: Oh, you actually run parallel tests? | 14:09 |
| tlater | Do they work consistently? | 14:09 |
| gitlab-br-bot | buildstream: merge request (tpollard/386->master: widget.py: Limit failure summary to currently failing elements) #561 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/561 | 14:09 |
| jonathanmaw_ | tristan: https://gitlab.com/BuildStream/buildstream/merge_requests/404 is ready for review again (assuming the remote CI passes) | 14:09 |
| tristan | parallelized tests never worked for me | 14:10 |
| juergbi | iirc, the 'integration' tests have issues but the regular ones normally work fine | 14:10 |
| tristan | I think ^C not working is a regression | 14:10 |
| tristan | It's worked in the past, a lot; I don't know what broke it | 14:10 |
| tlater | tristan: ^C has rarely instantly killed the test session for me. | 14:10 |
| tristan | Not instantly no | 14:10 |
| juergbi | yes, multiple ^C usually worked for me | 14:11 |
| * tlater thinks this is what Kinnison is complaining about | 14:11 | |
| tristan | but last week the regression which caused test_push_pull to fail consistently; was not interruptible | 14:11 |
| tristan | This was a crash *in the test code*, because juergbi had used a new feature from pytest-cov that I didnt happen to have in my version | 14:11 |
| tristan | So, it would seem that when the testing code itself hits an exception; the suite hangs; that's bad | 14:12 |
| juergbi | hm, yes | 14:12 |
| * tristan heads out to gym... | 14:12 | |
| tpollard | I think that should be ready to land now | 14:13 |
| juergbi | with -n auto: 1155 passed, 83 skipped in 167.12 seconds | 14:13 |
| gitlab-br-bot | buildstream: merge request (phil/add-ubuntu-ci-job->master: .gitlab-ci-yml: Add ubuntu 18 test) #523 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/523 | 14:13 |
| tlater | juergbi: With -n auto I get: INTERNALERROR> AttributeError: 'NoneType' object has no attribute 'configure_node' | 14:14 |
| juergbi | hm, without integration tests? | 14:14 |
| tlater | Yep | 14:14 |
| * tlater ponders if this is a pytest version issue | 14:14 | |
| tlater | But I'll have to take some time to figure that out... | 14:15 |
| juergbi | I'm on Python 3.6.6 and pytest 3.6.3 | 14:15 |
| tlater | juergbi: My container is apparently on 3.6.4 and 3.6.0 | 14:16 |
| tlater | Lemme see if updating pytest helps... | 14:16 |
| juergbi | there is also pytest-xdist 1.22.2, which may be relevant | 14:16 |
| tlater | Aha! | 14:16 |
| juergbi | pytest-runner 4.2 | 14:16 |
| tlater | Hm, no, didn't fix that |: | 14:17 |
| gitlab-br-bot | buildstream: merge request (tpollard/386->master: widget.py: Limit failure summary to currently failing elements) #561 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/561 | 14:18 |
| Kinnison | Hmm -n auto gave me 4 workers and ran the suite in 206s instead of 529s | 14:20 |
| Kinnison | that's a surprising amount of overhead considering it was pretty much parallel from the start | 14:20 |
| juergbi | yes, it doesn't scale that well. 167s with 32 workers | 14:22 |
| gitlab-br-bot | buildstream: merge request (Qinusty/397->master: Modify retry behaviour to be opt-in on exceptions during job processing) #559 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/559 | 14:23 |
| gitlab-br-bot | buildstream: merge request (Qinusty/397->master: Modify retry behaviour to be opt-in on exceptions during job processing) #559 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/559 | 14:24 |
| qinusty | Apologies D: | 14:25 |
| gitlab-br-bot | buildstream: merge request (willsalmon/documentation_form_notes->master: Documentation typos and fixes) #569 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/569 | 14:33 |
| gitlab-br-bot | buildstream: merge request (willsalmon/documentation_form_notes->master: Documentation typos and fixes) #569 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/569 | 14:33 |
| noisecell | what is format-version/ BST_FORMAT_VERSION is for? and where we get it from if format-version is not defined in project.conf? | 14:35 |
| noisecell | tristan, ^^ | 14:36 |
| Kinnison | juergbi: are there one or two really slow tests, or is it just that pytest's parallelisation is crap? | 14:38 |
| gitlab-br-bot | buildstream: merge request (phil/436-add-ubuntu-install-intructions->master: Add Ubuntu install intructions) #525 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/525 | 14:39 |
| juergbi | Kinnison: most of the workers seem to burn CPU cycles the whole time, so I don't think it's just a test or two | 14:40 |
| *** juergbi has quit IRC | 14:40 | |
| *** juergbi has joined #buildstream | 14:42 | |
| tlater | noisecell: BST_FORMAT_VERSION is there so that we can figure out which version of the yaml parsing we're supposed to use | 14:47 |
| tlater | Over time we've made breaking changes to the format, for various reasons, but we must support old versions for backwards compatibility | 14:47 |
| tlater | So BST_FORMAT_VERSION simply allows us to parse multiple different formats correctly | 14:48 |
| tlater | BST_FORMAT_VERSION is 0 if unset, I believe | 14:48 |
| * tlater can't quite recall where it actually applies though, if it is even supposed to be set in project.conf. | 14:48 | |
| noisecell | BST_FORMAT_VERSION is set to 9 I assume... | 14:49 |
| 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 | 14:49 |
| tlater | adds68: When building latest freedesktop master, I get a few failures when fetching - buildstream complains that it can't find commits for branches of a number of elements | 14:58 |
| tlater | Is this a known issue? | 14:58 |
| adds68 | tlater, hmm that is odd, we have not seen this issue | 14:58 |
| gitlab-br-bot | buildstream: merge request (466-optimize-bst-build-initialization-time->master: WIP: Resolve "Optimize `bst build` initialization time") #571 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/571 | 14:59 |
| * tlater digs a bit further | 14:59 | |
| adds68 | Could you paste some logs over at #freedesktop-sdk? | 14:59 |
| tlater | Yep, just covering my tracks to make absolutely sure I'm not making stupid mistakes here | 14:59 |
| noisecell | so in https://gitlab.com/BuildStream/buildstream/issues/516 either we work without numeric versions if we check the tag is good or we get the version from the previous tag to this one? how people think we should behave? | 14:59 |
| gitlab-br-bot | buildstream: merge request (466-optimize-bst-build-initialization-time->master: WIP: Resolve "Optimize `bst build` initialization time") #571 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/571 | 15:01 |
| gitlab-br-bot | buildstream: issue #517 ("Failure Summary should only contain failure messages from current run") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/517 | 15:01 |
| noisecell | tlater, https://gitlab.com/BuildStream/buildstream/blob/master/doc/examples/autotools/project.conf -- it is in the examples | 15:02 |
| tlater | noisecell: Ah, right. Yep, version 9 is the current one afaik | 15:03 |
| qinusty | tlater: I did fix that if btw. Just didn't push incase you find anything else for me to fix :P | 15:04 |
| tlater | qinusty: I started building freedesktop sdk to see how it behaves | 15:04 |
| qinusty | Exciting | 15:04 |
| qinusty | With a cache quota of? | 15:04 |
| tlater | 2GB | 15:04 |
| qinusty | :P | 15:04 |
| qinusty | so 0? | 15:04 |
| tlater | Should be enough to hit cleanup | 15:04 |
| tlater | ;p | 15:04 |
| tlater | Hm, actually, that might not be a great test | 15:05 |
| tlater | In either case, that build fails before I create any artifacts | 15:05 |
| noisecell | tlater, setting it just make https://gitlab.com/BuildStream/buildstream/issues/516 appears in a different place | 15:05 |
| tlater | So checking that now | 15:05 |
| qinusty | I reckon it'll pull it, and build one job, then go "Oh damn, no space sorry" | 15:05 |
| tlater | qinusty: Not if the definitions aren't working | 15:06 |
| Kinnison | juergbi: Oh dear | 15:06 |
| tlater | But yes, that's what I'd like to see | 15:06 |
| tlater | noisecell: Hrm, sorry, I've not been following that issue | 15:06 |
| tlater | I'm a bit split already, anyone else around who could help out with that? | 15:06 |
| noisecell | tlater, I know, don't worry, I was just linking that issue with the format-version | 15:07 |
| gitlab-br-bot | buildstream: issue #518 ("Backport solution for #163 (MR !541) to the bst-1.2 branch") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/518 | 15:07 |
| noisecell | I assume I will add notes to the issue and see what tristan thinks is the best way to solve it | 15:08 |
| qinusty | Is anyone free to merge https://gitlab.com/BuildStream/buildstream/merge_requests/559? Just one platform on the pipeline failed (silly test_build_track). | 15:10 |
| juergbi | Kinnison: real 2m50.292s - user 73m2.081s - sys 3m39.063s | 15:11 |
| Kinnison | juergbi: that's surprisingly high | 15:11 |
| juergbi | indeed | 15:11 |
| juergbi | as comparison, without parallelism it's 10m5s here | 15:12 |
| * Kinnison runs with time to see how it compares here | 15:12 | |
| gitlab-br-bot | buildstream: merge request (tpollard/483->master: plugins/git.py: Fail if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 15:14 |
| juergbi | Kinnison: oh my, it's actually faster with -n 16 than -n auto | 15:15 |
| Kinnison | juergbi: -n auto for me seems to pick nCPUs | 15:16 |
| juergbi | yes, here as well, but that's 32 | 15:16 |
| juergbi | with -n 16: real 2m16.573s - user 26m32.517s - sys 2m40.938s | 15:16 |
| Kinnison | -n auto here gives me real3m31.970s - user9m49.172s - sys1m54.296s | 15:16 |
| * Kinnison tries -n 2 (to halve like you did) | 15:17 | |
| qinusty | toscalix: You marked https://gitlab.com/BuildStream/buildstream/issues/496 with Buildstream v1.2, what does this mean for the implementation and the patch which contains the change? | 15:18 |
| toscalix | in theory that we want to include it in BuildStream v1.2. If we know for sure it will not make it for the coming stable version, we should add BuildStream v1.4 milestone | 15:19 |
| toscalix | I will need to go over many tickets that are in such situation | 15:20 |
| toscalix | in general, when a ticket is processed, it should have milestone assigned at least | 15:20 |
| toscalix | so no milestone=unprocessed | 15:20 |
| toscalix | in gitlab, every ticket goes automatically to backlog | 15:21 |
| toscalix | so we do not need any action to put it in the backlog | 15:21 |
| toscalix | so the backlog has tickets with and without milestones | 15:21 |
| toscalix | once we get more mature as a project, we can add a states that reflects that a ticket has been processed or analised | 15:22 |
| toscalix | but not for now | 15:22 |
| 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 | 15:23 |
| ironfoot | So, i've just noticed the following when using buildstream 1.1.3. I wonder if it's something that you are aware of. | 15:23 |
| ironfoot | In the following log you can see that an artifact is pushed after being pulled: https://paste.baserock.org/ujebatogok | 15:24 |
| ironfoot | Does that make sense? | 15:24 |
| ironfoot | Also, what is "Sending" and what is "Pushing" ? | 15:24 |
| Kinnison | juergbi: so 50% longer with only 2 CPUs (rather than 100% longer) | 15:25 |
| Kinnison | juergbi: real5m9.424s - user7m16.440s - sys2m7.988s | 15:25 |
| * Kinnison doesn't understand how it takes that much less time in user mode | 15:26 | |
| * juergbi neither | 15:26 | |
| * Kinnison is trying single-threaded to see what the numbers look like | 15:27 | |
| juergbi | -n 12 seems to be about as good as it gets here, 130 seconds instead of 605 | 15:27 |
| juergbi | ironfoot: pushing after pulling can sometimes make sense (multiple artifact cache servers) but there were some issues with some versions of buildstream (client and server side relevant) | 15:28 |
| ironfoot | ah, i've just seen https://gitlab.com/BuildStream/buildstream/issues/405 | 15:29 |
| toscalix | ironfoot: I was going to point you to it | 15:29 |
| juergbi | with the latest 1.2 or master, it should never push something that already exists on the server | 15:29 |
| 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 | 15:29 |
| toscalix | ironfoot: can you add there the request for those words? Or any other? | 15:29 |
| gitlab-br-bot | buildstream: merge request (phil/437-junction-tutorial->master: Phil/437 junction tutorial) #550 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/550 | 15:30 |
| qinusty | toscalix: I am only concerned due to the request from tristan to label the API in the docstrings as 1.4. If we want this as 1.2, it should be labelled 1.2. | 15:30 |
| juergbi | I don't think it really makes sense to backport anything like that to 1.0 | 15:30 |
| ironfoot | toscalix: my question is: what is BST doing in those 2 different steps, as they sound similar | 15:30 |
| ironfoot | juergbi: aha, ok, i'm using 1.1.3 here | 15:31 |
| juergbi | ironfoot: pushing is the overall job that includes compressing and sending. sending is the actual transmission | 15:31 |
| ironfoot | understood, that makes sense then | 15:31 |
| juergbi | this anyway changed with CAS, though (no compression step anymore) | 15:31 |
| juergbi | 1.1.4 should fix this all for you, however, it only works with CAS artifact servers, no longer with OSTree artifact servers | 15:32 |
| gitlab-br-bot | buildstream: merge request (willsalmon/documentation_form_notes->master: Documentation typos and fixes) #569 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/569 | 15:32 |
| gitlab-br-bot | buildstream: merge request (jjardon/remote-source-plugin-1.2->master: Jjardon/remote source plugin 1.2) #572 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/572 | 15:32 |
| tiagogomes | Does any opposes if I increase the job timeout limit in the CI to say 5 hours? Right now it is 3h | 15:32 |
| juergbi | we need more than 3h for CI? | 15:32 |
| gitlab-br-bot | buildstream: merge request (jjardon/remote-source-plugin-1.2->bst-1.2: Jjardon/remote source plugin 1.2) #572 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/572 | 15:33 |
| gitlab-br-bot | buildstream: merge request (jjardon/remote-source-plugin-1.2->bst-1.2: Backport remote source plugin to 1.2) #572 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/572 | 15:33 |
| tiagogomes | juergbi for the overnight tests, probably | 15:34 |
| juergbi | ah, if they share the timeout setting, sure, makes sense to me | 15:34 |
| gitlab-br-bot | buildstream: merge request (phil/add-ubuntu-ci-job->master: .gitlab-ci-yml: Add ubuntu 18 test) #523 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/523 | 15:36 |
| tiagogomes | Anyone to look at https://gitlab.com/BuildStream/buildstream/merge_requests/570/ ? It is breaking the build of freedesktop-sdk | 15:40 |
| persia | Phil: Would you mind renaming your message to use an actual version of Ubuntu? "18" doesn't mean anything in the Ubuntu lexicon. You might mean "18.04.0" or "18.04.1". Note that these have no clear relation with the expected future "18.10.x" series, hence the difficulties with bare "18". | 15:43 |
| toscalix | ironfoot: got you. | 15:48 |
| toscalix | qinusty: feel free to add then 1.4 as milestone | 15:48 |
| toscalix | otherwise I will put that in my todo | 15:48 |
| toscalix | qinusty: done | 15:49 |
| qinusty | todone, ty. | 15:49 |
| qinusty | noisecell: I've hunted down that regression of repeating "Running build-commands" problem | 15:50 |
| *** noisecell has quit IRC | 15:51 | |
| Phil | persia, thanks for pointing that out. I'd missed the commit message when fixing it elsewhere. | 15:52 |
| persia | Phil: Oh, heh. That's what I get for "pretend to review by randomly reading SCM messages on IRC": public demonstration that I'm not looking at the entire picture :) | 15:53 |
| Phil | :) | 15:53 |
| juergbi | Phil: the docker images also still have the wrong name | 15:54 |
| Phil | Ack, thanks juergbi | 15:57 |
| qinusty | Is the intention that when a command is ran the output will be thrown into the BuildStream UI? | 16:00 |
| tlater | qinusty: Mind explaining what you expect in a bit more detail? | 16:00 |
| tlater | I.e., are you expecting a gentoo-like line-for-line build output? | 16:01 |
| tlater | (I should say portage) | 16:02 |
| qinusty | https://paste.codethink.co.uk/?4760 | 16:02 |
| * qinusty now realises he should have used a public pastebin | 16:02 | |
| qinusty | What I mean is, is this meant to be there? | 16:02 |
| tlater | qinusty: Yep | 16:03 |
| tlater | BuildStream is expected to print the commands it will run... | 16:03 |
| qinusty | Alright, just wondering whether I could get away with silencing the nested messages for #507 | 16:03 |
| tlater | Frankly, I never second guessed why | 16:03 |
| qinusty | The reason we're seeing duplicate "Running strip-commands" etc | 16:04 |
| tlater | Ah | 16:04 |
| qinusty | is because theres two timed_activities with the same string, one for the commands (which loops through multiple commands) | 16:04 |
| tlater | It's worth checking if they were once silenced | 16:04 |
| tlater | Oh | 16:04 |
| qinusty | and one which does each one, they both print "strip-commands" when really, the inner one should print | 16:04 |
| tlater | I think that's a regression from my branch | 16:05 |
| tlater | :| | 16:05 |
| qinusty | [00:00:00][18b6e0d4][build:hello.bst ] SUCCESS Running find "/buildstream-install" -type f \ | 16:05 |
| *** toscalix has quit IRC | 16:05 | |
| * qinusty saw the commit you're describing in his git blame | 16:05 | |
| tlater | No, I think the solution here is probably removing the outer message | 16:05 |
| qinusty | definitely you who last touched it :P But I'm just wondering what the desired output is | 16:06 |
| qinusty | then I'll fix it | 16:06 |
| tlater | The desired output would be a single message containing the commands as their detail string | 16:06 |
| qinusty | My change produces this https://hastebin.com/raw/amaputilip | 16:06 |
| qinusty | In terms of BuildStream, what is the detail parameter on messages? | 16:07 |
| tlater | qinusty: Do you see colored output? | 16:07 |
| tlater | The detail parameter is what's printed in light gray | 16:07 |
| qinusty | yes | 16:07 |
| qinusty | Ahhh | 16:08 |
| tlater | qinusty: That said, your current output still looks duplicated | 16:08 |
| tlater | The reason we want the commands in the detail parameter is so that people can suppress them if they want | 16:08 |
| qinusty | It seems to be duplicating the output of the command | 16:08 |
| tlater | qinusty: It would be more accurate if you referred to it as duplicating the "command display" or something | 16:09 |
| tlater | Because the output of any of these commands is never shown :) | 16:09 |
| gitlab-br-bot | buildstream: merge request (jjardon/remote-source-plugin-1.2->bst-1.2: Backport remote source plugin to 1.2) #572 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/572 | 16:10 |
| qinusty | The problem is | 16:11 |
| qinusty | A timed activity is started with an activity name, then inside that there is a loop which starts timed_activities with identical activity names | 16:11 |
| qinusty | I'm not too sure where the command display is coming from if I'm honest, maybe within sandbox? | 16:12 |
| tlater | qinusty: Let me have a look at this, it's my regression after all :) | 16:12 |
| qinusty | Okay :P build_element.py, __run_command() and assemble() | 16:13 |
| tlater | Thanks - I'll ask you to review for a change | 16:13 |
| * tlater thinks there's simply too many activities here | 16:15 | |
| qinusty | Down the rabbit hole you go | 16:19 |
| qinusty | it is kind of cool that each command within the timed set of commands is timed | 16:20 |
| tristan | qinusty, my strategy is this: People merging things to master should right away assume 1.3 material; Whatever I manage to backport, I will (A) Mark as Since 1.2 in the bst-1.2 branch... (B) Come back and mark as Since 1.2 in master | 16:33 |
| tristan | qinusty, i.e. lets keep the activity of landing on master, and backporting work, separate | 16:34 |
| qinusty | That makes sense, cheers tristan! | 16:35 |
| tristan | well, assume 1.4 material (sorry if that was confusing; 1.3 is dev branch; APIs introduced there are "Since: 1.4") | 16:35 |
| qinusty | yup | 16:35 |
| qinusty | gotcha | 16:35 |
| tristan | tlater, you are wrong about BST_FORMAT_VERSION; if I understand what you were explaining | 16:36 |
| tlater | Oh? | 16:37 |
| tristan | tlater, Under no circumstances, *ever* will we behave differently depending on what format version a project.conf has requested | 16:37 |
| tristan | API must not break | 16:37 |
| tlater | Ah | 16:37 |
| tristan | tlater, the format-version is the project.conf's statement of the *minimum* required format version it needs in order to function | 16:37 |
| tlater | So, in that case, what is the purpose then? | 16:37 |
| tristan | So basically, I have been using it in gnome-build-meta such that, when I make it use a new feature, I *also* make it request a new version | 16:38 |
| tlater | tristan: I.e., newer versions may have *added* features? | 16:38 |
| tristan | Instead of weird incomprehensive errors being reported to users, they understand right away that they need a new version of BuildStream | 16:38 |
| tristan | That is all it does | 16:38 |
| qinusty | Why does the cache store multiple references to a single artifact? Different versions? | 16:38 |
| tlater | Right, I'll make sure to keep that in mind | 16:38 |
| tlater | qinusty: You have a strong and a weak key | 16:39 |
| tlater | Weak keys don't guarantee that if a dependency changes, the artifact also changes | 16:39 |
| tlater | I.e., libraries you depend on may have changed and could break your artifact | 16:39 |
| tristan | qinusty, interesting reading material http://buildstream.gitlab.io/buildstream/additional_cachekeys.html :) | 16:39 |
| tristan | Since we have it, somebody might as well read it :) | 16:39 |
| tlater | Probably gives a better explanation than my two sentences, too :) | 16:40 |
| qinusty | Cheers tristan, I'm just seeing duplicate messages on my skipped branch, mainly because of these multiple refs | 16:40 |
| qinusty | They arent distinguished by their get_brief_display_key() | 16:40 |
| qinusty | but I don't want to print the whole ref :/ | 16:40 |
| tristan | Sure, but if you're seeing duplicate lines, keep in mind we have this hot regression to fix: https://gitlab.com/BuildStream/buildstream/issues/507 | 16:41 |
| qinusty | Yeah, it's unrelated :P | 16:41 |
| qinusty | It's directly caused by the for ref in refs: strong/weak key | 16:41 |
| qinusty | always 2 | 16:42 |
| tristan | seems very strange that the abbreviated key happens to be a match | 16:42 |
| tristan | unlikely but possible | 16:42 |
| qinusty | who knows, I'm sure I'll figure out a solution tomorrow. | 16:43 |
| tristan | :) | 16:43 |
| qinusty | The test_build_track is still an issue tristan, I had no luck hunting it down | 16:43 |
| tlater | Aren't strong/weak keys the exact same if the project is not in weak mode? | 16:44 |
| qinusty | However it only reared its head on my local tests when I ran the whole test sequence rather than just test_build_track() tests | 16:44 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-500->master: Handle additional types on `_process_list`) #570 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/570 | 16:44 |
| *** qinusty has quit IRC | 16:45 | |
| tiagogomes | This IRC bot is faster than the update of the web page itself | 16:45 |
| *** noisecell has joined #buildstream | 16:46 | |
| tristan | hahahaha | 16:46 |
| tristan | that JS payload (starting from about a week or two ago ?) is one hell of a machine | 16:46 |
| tristan | half the time my browser proposes that I stop the offending script which is slowing down the whole browser | 16:47 |
| tristan | noisecell, for your benefit: https://irclogs.baserock.org/buildstream/%23buildstream.2018-07-26.log.html#t2018-07-26T16:36:39 | 16:49 |
| tristan | noisecell, about BST_FORMAT_VERSION, but you were not in the channel :) | 16:49 |
| noisecell | tristan, thanks :), I was reading it. I need to read with fresh mind what you wrote in the issue, as I need to re-read it tomorrow probably | 16:53 |
| noisecell | and see if I can find a solution as you described on it | 16:53 |
| * tlater is now also running into noisecell's issue | 16:57 | |
| tlater | Apparently running anything between when juergbi created his CAS tag and the 1.2 release will fail :) | 16:57 |
| noisecell | ooops | 16:59 |
| tlater | noisecell: Indeed | 16:59 |
| tlater | The most annoying part is that we can't really backport this or anything | 16:59 |
| tlater | We just have a range of commits that will never work, unless we mess with history | 16:59 |
| tlater | Or remove juergbi's pre-cas tag | 16:59 |
| noisecell | well, I think we need to solve the issue and then probably decide what is best | 17:00 |
| * tlater should have seen this coming when he fixed the no-tag issue | 17:01 | |
| tlater | I just thought "how would we ever get a non-integer number if there is one?" | 17:01 |
| tristan | tlater, an option for now is delete the tag | 17:01 |
| tristan | at least the commit would work | 17:01 |
| noisecell | tristan, I think there are 2 non numeric tags so probably remove both? | 17:02 |
| tristan | but surgery and force pushing the history is... really unpretty, we should rather live with the inconvenience for this short time | 17:02 |
| tlater | That works locally, yes | 17:02 |
| tristan | apparently this tag was only needed because people havent yet installed the new server | 17:02 |
| tlater | Do we want to remove the tag for good? | 17:02 |
| tristan | noisecell, I wouldnt remove the older one, it's not messing with anything that anyone is using, and it comes from a pre-versioneer time too | 17:03 |
| noisecell | oh, I see | 17:03 |
| noisecell | ok then | 17:03 |
| *** jonathanmaw_ has quit IRC | 17:04 | |
| gitlab-br-bot | buildstream: issue #519 ("Issue with refs accros junctions") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/519 | 17:04 |
| gitlab-br-bot | buildstream: merge request (507-some-log-lines-appear-to-be-duplicates->master: Resolve "Some log lines appear to be duplicates") #573 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/573 | 17:05 |
| WSalmon | i have written up the issue i was having in to a bug ticket https://gitlab.com/BuildStream/buildstream/issues/519 | 17:05 |
| tlater | qinusty: When you're back tomorrow, fix is up: https://gitlab.com/BuildStream/buildstream/merge_requests/573 | 17:06 |
| gitlab-br-bot | buildstream: merge request (507-some-log-lines-appear-to-be-duplicates->master: Resolve "Some log lines appear to be duplicates") #573 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/573 | 17:09 |
| *** noisecell has quit IRC | 17:10 | |
| * tiagogomes wonders if this directory structure is expected: ~/.cache/buildstream/build/base-gpgme-q5ns_fvw/scratch/_/ | 17:12 | |
| tristan | tiagogomes, yes, its a bit complicated but yeah | 17:14 |
| *** coldtom has quit IRC | 17:19 | |
| *** cs_shadow has quit IRC | 18:08 | |
| *** ernestask has quit IRC | 18:24 | |
| *** leopi has quit IRC | 20:45 | |
| *** tristan has quit IRC | 20:54 | |
| *** edb has quit IRC | 20:56 | |
| *** xjuan has quit IRC | 21:04 | |
| *** xjuan has joined #buildstream | 21:05 | |
| *** virtuanoise has joined #buildstream | 21:25 | |
| virtuanoise | hello | 21:26 |
| *** virtuanoise has left #buildstream | 21:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!