| *** tristan has joined #buildstream | 05:00 | |
| *** tristan has quit IRC | 05:20 | |
| *** tristan has joined #buildstream | 05:20 | |
| *** ChanServ sets mode: +o tristan | 05:21 | |
| *** tristan has quit IRC | 06:23 | |
| *** toscalix has joined #buildstream | 06:23 | |
| *** toscalix has quit IRC | 06:53 | |
| *** toscalix has joined #buildstream | 06:56 | |
| *** tristan has joined #buildstream | 07:09 | |
| *** ChanServ sets mode: +o tristan | 07:17 | |
| *** finn_ is now known as finn | 07:19 | |
| valentind | tristan, I think an easy fix for the mirroring thing is provide the fetchers as a generator rather than a list. So that first fetcher, fetches main mirror, once it is done we refresh the submodules and provide the rest of the fetchers. | 07:52 |
|---|---|---|
| *** toscalix has quit IRC | 08:03 | |
| tristan | valentind, you are also requesting an API break ? | 08:04 |
| valentind | tristan, I think that the current way it is written we can use generators. | 08:05 |
| valentind | I still have to test. | 08:05 |
| valentind | Yes. It works. 3 lines change. | 08:06 |
| valentind | Running the full test suite now. | 08:07 |
| tristan | valentind, check https://irclogs.baserock.org/buildstream/%23buildstream.2018-08-08.log.html#t2018-08-08T12:34:39 | 08:07 |
| tristan | valentind, and my responses to those queries | 08:07 |
| tristan | and consider if your implementation would still work | 08:07 |
| valentind | tristan, It will work like before. I am not changing behavior. | 08:10 |
| valentind | What I do is only delaying scanning for submodules just a bit later. | 08:10 |
| valentind | For my case it does not matter if using aliases and mirrors or not. They will all behave the same. | 08:11 |
| qinusty | I have removed fatal-warnings: True and addressed all review points tristan, https://gitlab.com/BuildStream/buildstream/merge_requests/627/ is ready when you get some spare time. | 08:12 |
| tristan | qinusty, I know :) | 08:13 |
| qinusty | Okay :D | 08:14 |
| tristan | valentind, I'm a bit concerned mostly because I don't have the time to properly digest all the knowledge I need to evaluate that | 08:15 |
| tristan | valentind, could you harden the git tests for mirroring + submodules, to check the edge cases discussed in that IRC log ? | 08:15 |
| valentind | tristan, yes, I will do that. | 08:16 |
| tristan | valentind, thanks ! | 08:16 |
| valentind | All backported! | 08:19 |
| tristan | valentind, :) | 08:19 |
| tristan | yep, I babysat them this morning, I have my finger on the release trigger but was waiting for those to come through :) | 08:19 |
| valentind | Thanks for clicking on merge tristan. It took sometime for the queue to go through | 08:19 |
| tristan | Thanks for the backporting ! | 08:19 |
| tristan | yes, it's annoying that CI takes so long in the cloud :-S | 08:20 |
| tristan | at least I've seen no spurious errors since the last ones were fixed, so that's something | 08:20 |
| *** toscalix has joined #buildstream | 08:45 | |
| *** jonathanmaw has joined #buildstream | 08:47 | |
| *** rdale has joined #buildstream | 09:00 | |
| *** bethw has quit IRC | 09:11 | |
| *** bethw has joined #buildstream | 09:11 | |
| *** johnward has quit IRC | 09:11 | |
| *** milloni has quit IRC | 09:11 | |
| *** johnward has joined #buildstream | 09:11 | |
| *** milloni has joined #buildstream | 09:12 | |
| *** Nexus has quit IRC | 09:12 | |
| *** Nexus has joined #buildstream | 09:12 | |
| *** tristan changes topic to "/BuildStream 1.1.6 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" | 09:20 | |
| *** tristan changes topic to "BuildStream 1.1.6 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" | 09:20 | |
| tiagogomes | We should time the tests, check the ones that take longer and see what we can do to optimize them | 09:26 |
| tiagogomes | Improving the bst startup time would reduce the time for them to finish | 09:26 |
| tristan | tiagogomes, true; I still feel that the real bottleneck though is going to be I/O in the cloud | 09:31 |
| tristan | tiagogomes, what takes the longest time is staging runtimes in the integration tests; or worse, downloading those runtimes when the cache is not up to date and needs to be recreated (the gitlab cache) | 09:32 |
| tristan | what normally takes around 10min (or 12 ?) to run locally on my laptop, takes > 40min (or > 1hrs ?) to run on a much "more powerful" build server | 09:33 |
| *** bochecha has joined #buildstream | 09:37 | |
| paulsherwood | are we using ephemeral runners? | 09:40 |
| paulsherwood | would be better to have some permanent ones maintaining caches and gits | 09:40 |
| *** CTtpollard has joined #buildstream | 09:44 | |
| *** leopi has joined #buildstream | 09:45 | |
| *** tpollard has quit IRC | 09:46 | |
| *** leopi has quit IRC | 09:48 | |
| *** sergey_ has joined #buildstream | 09:49 | |
| *** sergey_ has joined #buildstream | 09:51 | |
| *** sergey_ has quit IRC | 09:52 | |
| *** solid_black has joined #buildstream | 09:52 | |
| tristan | paulsherwood, I think we do use caches, jjardon knows the config best | 10:00 |
| tristan | paulsherwood, what I am not 100% certain of, is if they have good SSD, and if the CPU and memory is guaranteed to be on the same machine as the SSD | 10:01 |
| tristan | I think so though, because apparently it's one "big" machine | 10:02 |
| jjardon | buildstream uses the ephemeral runners from baserock, as the ones from gitlab.com was not so good | 10:02 |
| tristan | oh | 10:02 |
| valentind | tristan, !656 for #537 will be ready for review when the CI has succeeded. There is no limitation on submodule discovery (mirroring or not). The fix is 3 lines. There are 4 new tests (2 from jonathanmaw, 2 from me). I will have some lunch, then I will look at the ostree mirroring issue. | 10:05 |
| tristan | valentind, awesome sauce... I have two other MRs in my queue and yet another email to consider; not sure I will get to review it today :) | 10:07 |
| jmac | juergbi, is there a more up-to-date branch of buildbox I should use than juerg/wip? | 10:08 |
| juergbi | no, that's up-to-date | 10:09 |
| jonathanmaw | valentind: ooh, that's clever! | 10:09 |
| juergbi | (latest change yesterday) | 10:09 |
| jmac | Ta juergbi | 10:11 |
| *** toscalix has quit IRC | 10:30 | |
| WSalmon | I was looking for more sources that might have the missing track/ref error as prompted by tristan in https://gitlab.com/BuildStream/buildstream/merge_requests/621#note_93616304 and the only place i could find a issue was in ostree but i cant see many tests mentioning ostree and there doesn't seem to be a set of ostree specific tests, is this, fine/know issue/should i make a issue? | 10:48 |
| qinusty | Does anyone recall the discussion surrounding buildstreams UI, what information is provided in different regions of the UI etc. Was there an issue raised? | 10:50 |
| tristan | WSalmon, I'm pretty sure it can happen for `bzr` as well as `ostree` | 10:57 |
| WSalmon | i had a look and it looked like track was mandatory so not a issue but i will relook now | 10:57 |
| tristan | WSalmon, iirc (ask jonathanmaw for more detail), with bzr we use both the track and ref to construct the full ref; where a ref is a sub-version of track (not sure I recall it properly), still there is an opportunity to specify a version in the ref which does not exist for the track specification | 10:58 |
| WSalmon | I thought there was a different ticket for ref not in track? It looked to me like the configure would go pop under most failure modes already but i am looking again | 11:00 |
| *** WSalmon has quit IRC | 11:04 | |
| phildawson | qinusty, I believe https://gitlab.com/BuildStream/buildstream/issues/552 is related to that discussion. I'm not sure it was a direct result though. | 11:05 |
| *** WSalmon has joined #buildstream | 11:05 | |
| *** CTtpollard is now known as tpollard | 11:13 | |
| WSalmon | tristan looking at bzr configure the lack of default will, if i understand correctly, cause a failure if track is not specified, and thus not alow our error condition. As for the ref not in track is this not a different issue? both in terms of failure mode and GL ticket, i think tpollard was looking at it. Or do you want me to suck more stuff in to this MR? I have a patch ready to go to add the no track or ref for ostree but i am not sure about | 11:18 |
| WSalmon | were to add the tests as ostree seems to be very lightly tested | 11:18 |
| jmac | juergbi: Is there any way to tell the difference between a command failing inside buildbox, or buildbox itself failing (e.g. due to bad arguments)? | 11:36 |
| juergbi | jmac: not yet but we should definitely add this | 11:37 |
| tpollard | WSalmon: yep, my MR was to cover the specified ref not existing in the specified track | 11:41 |
| WSalmon | tpollard, did you check that your issue was only in git, it looks like it might be a issue in bzr too | 11:45 |
| tpollard | I kept it to the scope of the issue which was for git, I can well believe it would apply to a bzr source too | 11:45 |
| jmac | Actually, I suppose a lack of a digest being printed on stdout by buildbox is enough to distinguish the cases | 11:46 |
| *** leopi has joined #buildstream | 11:47 | |
| juergbi | jmac: please note that the latest version only supports --input-digest= and --output-digest= instead of the original stdin/stdout | 11:48 |
| juergbi | to allow stdout (and stdin) to be passed through from the command | 11:49 |
| juergbi | an empty (or not existing) output digest file is indeed a possibility to check whether buildbox failed | 11:49 |
| jmac | Oh, interesting, I don't think the buildgrid plugin knows about that yet | 11:49 |
| finn | it won't do, I haven't touched that file since the demonstration at GUADEC | 11:51 |
| finn | it won't do, I haven't touched that file since the demonstration at GUADEC | 11:52 |
| jmac | np, looks like an easy fix | 11:52 |
| tristan | WSalmon, I have a feeling we've been talking about different issues indeed, my mistake | 12:08 |
| tristan | WSalmon, lemme take a look at the link you provided | 12:08 |
| tristan | WSalmon, ah right... ok this is a different issue indeed :) | 12:11 |
| tristan | WSalmon, so to answer one question; the majority of coverage we get for Source plugins is by virtue of implementing a `Repo` for the source in tests/testutils/repo | 12:12 |
| tristan | WSalmon, so while some ostree related edge cases might not be covered, there is still a lot of coverage by that avenue | 12:12 |
| tristan | WSalmon, indeed, bzr would not have this issue | 12:13 |
| tristan | WSalmon, it could make sense to add a little test for this, it would only need to run `bst show` (as it's a load time error) | 12:14 |
| tristan | cs-shadow, have a moment to chat about source transform / pip ? | 12:30 |
| WSalmon | tristan i will have ago at a test for ostree, thanks for the info | 12:33 |
| tristan | WSalmon, unfortunately I did not get a chance to look at your email regarding out of tree builds today, it's in my queue, though | 12:37 |
| tristan | cs-shadow, I'll have to run, but I've left some more comments on the `pip` plugin | 12:55 |
| tristan | cs-shadow, a couple of last things I think we overlooked; but the tests look good ! | 12:56 |
| *** TingPing has joined #buildstream | 12:56 | |
| cs-shadow | tristan: sorry, I was afk. Just got back. I'll go through your comments in a bit | 12:56 |
| *** edb has joined #buildstream | 13:00 | |
| TingPing | Hey, so I'm looking into the issue about generating a manifest as part of the output. One piece of information missing from that would be the version of each module, I imagine just adding a version property to everything is the only real solution to that, does that sound reasonable? | 13:02 |
| *** edb has quit IRC | 13:02 | |
| *** edb has joined #buildstream | 13:04 | |
| tristan | cs-shadow, mostly just (A) Lets be symmetric with `directory`, unless you think there is a good case to not do what I suggested there | 13:04 |
| tristan | cs-shadow, and (B), I think there is a side effect of inadvertent tracking, we should make sure | 13:05 |
| tristan | cs-shadow, sorry I was not able to pay more attention today :-S | 13:05 |
| tristan | I think it's mostly golden though, docs might get improved later but definitely good enough for landing | 13:06 |
| tristan | I didn't go through the `pip` implementation in minute detail, but found one issue with it; I think we've discussed it enough too for it to be ready | 13:06 |
| tpollard | with the talk around generating manifests, elements don't currently have a concept of licensing do they? | 13:09 |
| jmac | Nope | 13:10 |
| tpollard | jmac: cheers | 13:12 |
| jmac | My element's `build-root` is set to /buildstream/base-sdk-bootstrap/gcc-stage1.bst" - is it normal to have the element name on the end? | 13:12 |
| tristan | jmac, yes | 13:13 |
| qinusty | TingPing, We don't exactly have a version of sources. This issue has been discussed on the mailing list (see https://mail.gnome.org/archives/buildstream-list/2018-August/msg00045.html). | 13:13 |
| tpollard | projectconfig.yaml sets 'build-root: /buildstream/%{project-name}/%{element-name}' by default jmac | 13:13 |
| valentind | Look at ostree, I think we had a bug where if you changed the url after you had already fetched something in the cache. And then change the ref. It would still try to pull from the old url. | 13:13 |
| tristan | jmac, we did that mostly because we want to be able to stage all the sources optionally in a shell, and we want them built with distinct paths | 13:14 |
| valentind | s/Look at/Looking at/ | 13:14 |
| tristan | jmac, for debugability in the shell | 13:14 |
| jmac | tristan: Seems a bit surprising. I expected something called *-root to be a directory | 13:14 |
| jmac | Especially as it's passed into sandbox.set_work_directory | 13:14 |
| qinusty | The author of bst files could indicate the versions of their sources in a property similar to url: or ref: but that is not currently in place. | 13:14 |
| qinusty | TingPing ^ | 13:14 |
| qinusty | tiagogomes are you working on #561? | 13:15 |
| TingPing | qinusty, right, are unknown properties already just ignored? | 13:15 |
| qinusty | Properties are validated and loaded in to sources in their Configure() method | 13:15 |
| tristan | jmac, I think its rather inconsequential; alternatively the whole thing could be prefixed `/buildstream/build/%{project-name}/%{element-name}` | 13:15 |
| tristan | jmac, if we wanted that communicated more clearly; then we'd have every build staged into a shell under `/buildstream/build`, might be more discoverable | 13:16 |
| jmac | Oh wait, you're saying gcc-stage1.bst is the name of a directory | 13:17 |
| tristan | jmac, since we haven't implemented the feature yet which uses it, it might make sense in 1.3 to prettify the directory name; it would be another core artifact version bump | 13:17 |
| tristan | jmac, yes | 13:17 |
| jmac | OK, that makes more sense | 13:17 |
| qinusty | TingPing, What you're suggesting is a change to Source.py, probably adding a "version" tag to Source.COMMON_CONFIG_KEYS and loading it within source.py. | 13:17 |
| tiagogomes | qinusty not at the moment, but I plan to work on it when I finish some work I am doing | 13:18 |
| qinusty | Okay no worries tiagogomes | 13:18 |
| TingPing | qinusty, alright, and from what i'm reading tristan thinks the manifest generation belongs out of tree? | 13:18 |
| tristan | I think manifest generation needs to be supported by features that we need to add, but not added as a concept in BuildStream proper, right | 13:19 |
| qinusty | The way the discussion had progressed is that if buildstream can provide a formattable output with the necessary data, then a bash script can read and parse the necessary information | 13:19 |
| * tristan passed 10pm... gonna run now :) | 13:19 | |
| * TingPing just wrote this a few minutes ago: https://gist.github.com/TingPing/958554c5a8f82ef84fe6e5a4434d84fd | 13:19 | |
| qinusty | Later tristan | 13:19 |
| TingPing | qinusty, version probably belongs as part of the top level elements not sources, for my needs at least | 13:20 |
| *** tristan has quit IRC | 13:23 | |
| qinusty | Okay, I do think tristan is along the right lines with producing a parse-able output. The idea behind the manifest was originally to collate Elements and their source urls/refs from all bst files used. | 13:23 |
| TingPing | honestly what is there now is good enough, just a list of yaml files to read | 13:24 |
| qinusty | My problem there is that you're having to parse a directory tree of files which may not be loaded in a build | 13:25 |
| * skullman grumbles about having to patch ruamel 0.14.12 to compile for python 3.7 | 13:25 | |
| qinusty | The manifest produces a list of elements included within the build | 13:25 |
| TingPing | i assumed bst show knew which files are used | 13:25 |
| * qinusty thanks skullman for his suffering | 13:25 | |
| qinusty | It does | 13:26 |
| qinusty | So as long as we can get bst show to produce the necessary data we need, we're good | 13:26 |
| TingPing | well thats what i used | 13:26 |
| qinusty | Ahhhhhh, you're loading files from the elements shown in bst show. That'll do it | 13:27 |
| TingPing | qinusty, some of what it returns aren't file paths though: bootstrap-junction.bst:attr.bst | 13:28 |
| TingPing | ah thats a subproject? | 13:29 |
| qinusty | Yes it appears the colon seperates a junction | 13:29 |
| qinusty | You'd need the path to the junction for that | 13:29 |
| TingPing | so then i have to bst show each of those | 13:30 |
| * qinusty assumes it bst shows the junction too, just not the full path | 13:30 | |
| qinusty | it seems "bootstrap-junction.bst:" is effectively an alias for the junction project path | 13:30 |
| TingPing | but that path isn't known | 13:31 |
| qinusty | not in the current UI | 13:31 |
| qinusty | buildstream knows it | 13:31 |
| TingPing | ok, i guess ill see if i can improve that | 13:31 |
| *** edb has quit IRC | 13:32 | |
| TingPing | (import.py is a terrible python module name) | 13:46 |
| qinusty | import import | 13:49 |
| TingPing | from import import Import | 13:51 |
| qinusty | :/ | 13:51 |
| TingPing | invalid syntax | 13:51 |
| qinusty | from .import import Import? | 13:51 |
| qinusty | The word import is starting to look wrong | 13:51 |
| TingPing | no you simply can't use that keyword to import it, you need to import as a string with __import__ or implib, etc | 13:52 |
| qinusty | Not even with the .? | 13:52 |
| TingPing | not even | 13:52 |
| qinusty | rip, slight flaw there | 13:52 |
| TingPing | qinusty, you happen to know how to get a path from a junction - https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/plugin.py#L706-709 | 13:56 |
| qinusty | Ummmmm, Junction is an element, Element inherits from Plugin, Plugin has access to __project...... TingPing. | 14:14 |
| qinusty | Not sure what public channels there are | 14:14 |
| qinusty | hmm, but the Junction element __project is the main project. | 14:15 |
| qinusty | junction has self.path | 14:15 |
| TingPing | qinusty, junction.path is empty | 14:16 |
| qinusty | self.path = self.node_get_member(node, str, 'path', default='') | 14:17 |
| qinusty | If the junction is configured within the project, it should be loaded once the element is configure()'d | 14:17 |
| TingPing | maybe show never gest that far | 14:18 |
| qinusty | Perhaps | 14:19 |
| WSalmon | show will call configure on sources and there for presumably elements too | 14:20 |
| qinusty | Nope TingPing, configure is definitely called when bst show is ran | 14:21 |
| qinusty | ^ | 14:21 |
| tiagogomes | pytest is not showing stack traces. Is there a way of seeing those? | 14:30 |
| WSalmon | they are usually quite a long way up the terminals scroll back before the coverage report, your not just missing them there? other wise i dont know | 14:32 |
| qinusty | Did you run with -s? | 14:32 |
| *** tpollard has quit IRC | 14:35 | |
| *** WSalmon has quit IRC | 14:35 | |
| *** tpollard has joined #buildstream | 14:36 | |
| *** leopi has quit IRC | 14:37 | |
| tiagogomes | Yes I am running with -s | 14:41 |
| Nexus | I've come across a blocker, in that certain os commands don't work on Mac, do i raise an issue, or just fix it? | 14:43 |
| cs-shadow | thank the gods! Links in GitLab email notifications appear to be fixed now | 14:51 |
| laurence | cs-shadow, yes ! return of the 'view on gitlab' button in email notifications ! | 14:59 |
| laurence | Nexus, are you blocked on WSL side of things? | 15:01 |
| Nexus | laurence: not entirely | 15:02 |
| laurence | Nexus, ok cool, then raise it and move on is my advice :) | 15:09 |
| *** leopi has joined #buildstream | 15:32 | |
| qinusty | Can someone review https://gitlab.com/BuildStream/buildstream/merge_requests/662 for merge on pipeline succession? | 15:51 |
| Nexus | qinusty: commented | 15:55 |
| Nexus | qinusty: basically, tests? | 15:55 |
| *** solid_black has quit IRC | 16:08 | |
| *** adds68 is now known as ads68 | 16:11 | |
| *** ads68 is now known as adds68 | 16:11 | |
| qinusty | Nexus, good shout. Probably best for a regression. I'll take a look | 16:13 |
| *** edb has joined #buildstream | 16:17 | |
| *** xjuan has joined #buildstream | 16:19 | |
| Nexus | is there a reason we're using `IS_LINUX = os.getenv('BST_FORCE_BACKEND', sys.platform).startswith('linux')` rather than `IS_LINUX if "Linux" in os.uname().release` ? | 16:21 |
| Nexus | sorry, os.uname().sysname | 16:22 |
| juergbi | os.uname() may not be available on all platforms | 16:27 |
| juergbi | we should aim to keep direct OS conditionals to a minimum, though | 16:28 |
| juergbi | if it's about a particular feature that is currently only supported on Linux but might be supported on other systems later, we should define a separate condition for that feature, imo | 16:28 |
| Nexus | juergbi: it came up because i needed a way of differenciating WSL and true Linux | 16:29 |
| Nexus | os.uname().release tells me it's a Windows Kernel | 16:29 |
| Nexus | the rest returns Linux | 16:29 |
| juergbi | it might be better to detect the absence of FUSE if that's the reason for the conditional | 16:31 |
| *** mohan43u has quit IRC | 16:32 | |
| *** mohan43u has joined #buildstream | 16:32 | |
| Nexus | juergbi: there may be other things, and WSL intend to eventually support FUSE | 16:32 |
| Nexus | i think it's still best we have a flag for WSL | 16:33 |
| juergbi | the question is what do you use the flag for | 16:33 |
| Nexus | skipping tests mostly | 16:33 |
| juergbi | if you want to skip tests that require FUSE, it should be a FUSE conditional, not a WSL conditional | 16:33 |
| juergbi | otherwise 1) we have to update all these tests again when WSL finally supports FUSE | 16:33 |
| juergbi | 2) we'd have to add another conditional for other FUSE-less Linux cases | 16:33 |
| juergbi | that said, it could make sense to initialize the FUSE flag based on whether we're running on WSL - if there is no simple more direct check for FUSE | 16:34 |
| juergbi | or maybe the conditional should be even more generic: support for local builds | 16:35 |
| Nexus | how would i check that? | 16:36 |
| juergbi | this is mainly about the name of the conditional. as currently we expect FUSE available for local builds, we can set the 'local build' conditional based on FUSE availability | 16:36 |
| juergbi | however, if and when we support local builds with native WinAPI at some point, we most likely will not use FUSE for local builds | 16:37 |
| Nexus | true | 16:37 |
| Nexus | assuming we always require fuse to build locally | 16:37 |
| juergbi | strictly speaking, we only need it for integration commands and other read-write root cases, but not for simple builds | 16:38 |
| juergbi | don't know whether it's worth differentiating | 16:38 |
| juergbi | probably not | 16:39 |
| juergbi | btw: I think IS_LINUX should remain True on WSL. WSL should be considered an alternative implementation of the Linux API. can require extra quirks but it should still be considered IS_LINUX | 16:40 |
| Nexus | i was planning on keeping it true | 16:40 |
| juergbi | ok, good | 16:41 |
| *** tristan has joined #buildstream | 16:58 | |
| * tiagogomes shakes a fist to the artifact cache and parallel jobs | 16:59 | |
| *** jonathanmaw has quit IRC | 17:05 | |
| jmac | Remote execution is updated and running the alpine example again \o/ | 17:14 |
| jmac | Trying it on freedesktop-sdk/bootstrap overnight | 17:15 |
| *** phildawson has quit IRC | 17:16 | |
| juergbi | great | 17:24 |
| jjardon | Hi updateing from 1.1.5 to 1.1.6 our CI is rebuilding the workd: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/89204552 | 17:31 |
| jjardon | is this expected? there was a change in the cache key calculation? | 17:32 |
| edb | nice jmac | 17:45 |
| *** leopi has quit IRC | 17:46 | |
| *** leopi has joined #buildstream | 17:52 | |
| *** edb has quit IRC | 18:39 | |
| *** edb has joined #buildstream | 19:07 | |
| *** leopi has quit IRC | 19:25 | |
| *** edb has quit IRC | 19:52 | |
| adds68 | has anyone ever seen an "inconsistent pipeline"error when trying to build an element? | 20:08 |
| *** ChanServ sets mode: +o tristan | 20:10 | |
| tristan | adds68, that happens when you try to build, but some sources don't have a ref set; the error should mention which specific elements have sources that are in an inconsistent state; and need either to be tracked or have a ref set manually | 20:11 |
| adds68 | tristan, thanks it does give the element, which does have a ref and it has not been modified either, so i am not sure why it has started to fail | 20:11 |
| adds68 | This is seen on both 1.1.5 and 1.1.6 | 20:12 |
| adds68 | Running bst track also did not fix the issue | 20:12 |
| tristan | adds68, please file an issue with the steps to reproduce then, and we'll prioritize that for 1.2 | 20:13 |
| adds68 | tristan, will do, thanks :) | 20:13 |
| tristan | adds68, no, ... thank _you_ :) | 20:14 |
| *** leopi has joined #buildstream | 20:15 | |
| adds68 | tristan, i think i found the issue | 20:24 |
| adds68 | tristan, i opened a workspace for that element, then just rm -r the directory once i had finished, as i did not know you had to "close" the workspace | 20:25 |
| adds68 | Ever since i did that it would report that error | 20:25 |
| adds68 | Now i've actually closed the workspace it builds \o/ i'll open an issue with these steps though :) | 20:25 |
| tristan | adds68, yes please do; it would be helpful to improve the error for that case | 20:26 |
| jjardon | tristan: did you see my message about the cache key? | 20:37 |
| tristan | jjardon, nope | 20:39 |
| tristan | jjardon, it's mentioned in the release email for 1.1.6, though | 20:39 |
| jjardon | oh, I only checked the NEWS file | 20:40 |
| * jjardon looks | 20:41 | |
| jjardon | tristan: perfect, then it works as expected. Sorry for the noise | 20:42 |
| tristan | jjardon, yeah I didnt mention all the specific fixes in the NEWS, but indeed, sad rebuild of the world | 20:47 |
| tristan | it's for the sake of improved determinism at source staging time | 20:48 |
| *** tristan has quit IRC | 21:47 | |
| *** xjuan has quit IRC | 22:02 | |
| *** leopi has quit IRC | 22:09 | |
| *** bochecha has quit IRC | 23:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!