| *** rdale has quit IRC | 00:50 | |
| *** tristan has quit IRC | 01:17 | |
| *** aminbegood has joined #buildstream | 04:15 | |
| *** aminbegood has quit IRC | 05:15 | |
| *** narispo has joined #buildstream | 05:35 | |
| *** aminbegood has joined #buildstream | 06:06 | |
| *** aminbegood has quit IRC | 06:21 | |
| WSalmon | chipb, because freedestop build everything on top of the tar ball as a build only dependency, if you work on top of it (or your version) then your devs never tuch the base tar ball | 06:44 |
|---|---|---|
| *** pointswaves has joined #buildstream | 06:52 | |
| WSalmon | a nice developer experince thing is if you build your toolchain in to a element in ci and push it to a shared cache then so long as your devs want a cached version then they dont need to do anything but have bst installed to build on top of it | 07:16 |
| WSalmon | using somethink like buildbarn or buildgrid the cache servers can scale to meet the needs of hundreds of deves + CI + remote build etc | 07:17 |
| *** pointswaves has quit IRC | 07:18 | |
| *** benschubert has joined #buildstream | 07:20 | |
| juergbi | benschubert: thanks for the quick merge. I was confused why my benchmark builds were suddenly taking 3-4 times as long | 07:30 |
| juergbi | I had a global artifact server configured in my buildstream config | 07:31 |
| benschubert | juergbi: no problem, we'd also need to update the debian project to have a 'min-version' sometimes | 07:31 |
| juergbi | yes, I already pushed this to juerg/bst2 there | 07:31 |
| benschubert | ah awesome, should we merge that into master? | 07:32 |
| juergbi | wondering about the current branches we have there | 07:32 |
| juergbi | we currently don't use master in the benchmark | 07:32 |
| juergbi | still jennis/add_all_files | 07:32 |
| benschubert | ah right, I wonder, should we move your branch as master and delete all the others? | 07:32 |
| juergbi | yes, or was this intentional to separate the small branch with only the script from the generated files? | 07:33 |
| benschubert | I don't know | 07:33 |
| benschubert | ah maybe the automated benchmarks use master? | 07:34 |
| juergbi | there is also a local (jennis) path in the generated/modified project.conf | 07:34 |
| juergbi | btw: shall we also move bst-benchmarks from your personal gitlab area to the BuildStream/benchmarking group? | 07:35 |
| benschubert | Sure, that sounds good | 07:36 |
| benschubert | let me do that now | 07:36 |
| juergbi | ta | 07:36 |
| benschubert | it's probably official enough now :D | 07:36 |
| benschubert | uh ? I don't seem to have the rights to transfer to BuildStream | 07:37 |
| benschubert | ah I don't manage BuildStream | 07:37 |
| benschubert | juergbi: can you? https://gitlab.com/BenjaminSchubert/bst-benchmarks/edit | 07:38 |
| WSalmon | benschubert, you will need to make juergbi a owner of that if he is not already | 07:38 |
| juergbi | ah, right, moving is tricky privilege-wise | 07:38 |
| WSalmon | IIRC | 07:38 |
| juergbi | benschubert: I obviously don't have the rights on your side | 07:38 |
| juergbi | I can make you a benchmarking group owner | 07:38 |
| benschubert | I just added you as a maintainer | 07:39 |
| benschubert | But that would work too yep | 07:39 |
| juergbi | benschubert: maintainer is not enough for move. I've set you as owner for the benchmarking subgroup | 07:41 |
| benschubert | done :) thanks | 07:41 |
| benschubert | any idea for a better name though? | 07:41 |
| juergbi | not sure. the benchmarking repo list is already somewhat confusing | 07:42 |
| juergbi | naming is hard ;) | 07:42 |
| *** devcurmudgeon has joined #buildstream | 07:44 | |
| benschubert | juergbi: btw if you have time: https://gitlab.com/BuildStream/buildstream/-/merge_requests/1840 :) | 07:44 |
| juergbi | benschubert: right, I took a quick look already this morning. the changes look fine to me. I'm not sure whether that part is ever slow, especially if/when dynamic plan is working again | 07:46 |
| benschubert | I can see only one time: when your source cache doesn't have it, but they are in the plugin-specific cache | 07:47 |
| benschubert | which is sadly not that uncommon (disk filled with those sources) | 07:48 |
| juergbi | with dynamic plan it doesn't even call the status() methods | 07:48 |
| benschubert | true | 07:48 |
| juergbi | but right now this might indeed be the case | 07:48 |
| benschubert | ok then let's park this one until we have dynamic plans again? | 07:48 |
| benschubert | because if that's not needed, it's all the less handling in the scheduler | 07:48 |
| juergbi | ok. benchmark for the dynamic plan reverts should be finished soon | 07:49 |
| juergbi | but there is no test case yet | 07:49 |
| traveltissues | can i get some reviews please: https://gitlab.com/BuildGrid/buildbox/buildbox-common/-/merge_requests/267 https://gitlab.com/BuildGrid/buildbox/buildbox-common/-/merge_requests/268 | 07:54 |
| juergbi | benschubert: added benchmark result in comment of !1926. the timing differences seem minor to me. source fetch seems to be a tad slower | 07:56 |
| traveltissues | benschubert: i'm increasingly confused by the benchmarking subgroup, i know we were using the benchmark_debian project which used the debian-stretch-bst project at some point. I made the local benchmarks helper as a way for people to run that locally (which was just an adaptation of the jobs that published the results which were being sent to the mailing list) | 07:58 |
| traveltissues | there's also a bot and an 'official' tool in there which i have never used | 07:58 |
| traveltissues | has there been some discussion about cleaning this up and deciding what is the common group of benchmarks the buildstream world recognizes | 07:59 |
| *** seanborg_ has joined #buildstream | 07:59 | |
| benschubert | juergbi: Ok, sad to see this one back in, but I guess we'll need a bigger revamp at some point. Let's add tests this time | 08:01 |
| benschubert | traveltissues: good question, I don't think so and I know efforts have been rather scattered in that place | 08:01 |
| juergbi | benschubert: yes, definitely want to clean this up. but this shouldn't have been removed in the track-related MR. and it degraded UX | 08:02 |
| juergbi | traveltissues: !267 looks fine to me, approved | 08:02 |
| benschubert | correct | 08:02 |
| traveltissues | thanks juergbi | 08:06 |
| traveltissues | benschubert: we might like to consider benchmarks that also hit the caching at larger scales. i know that WSalmon and co have been having some issues recently | 08:07 |
| benschubert | traveltissues: that's a resource problem, we can't even have a fsdk build reliably at night, and that's a small project | 08:08 |
| benschubert | if we want to scale our benchmarks we need more resources there and people wanting to work more on benchmarks | 08:08 |
| traveltissues | yeah, good point | 08:09 |
| traveltissues | that we can't reliably build the overnights still troubles me | 08:09 |
| juergbi | maybe we should get some relatively cheap but powerful dedicated servers instead of flexible but expensive cloud instances | 08:11 |
| traveltissues | imo if the overnights are mostly failing then it's not really worth running them. i generally see they've failed and we probably all just ignore that | 08:11 |
| traveltissues | so it's a bit of a waste of time/resources unless we redefine them in some way to minimise the failure rate from resources | 08:12 |
| benschubert | traveltissues: yeah, same for the out of order tests, they've been failing for a while. I try to fix those when I have time, but hey | 08:12 |
| *** phildawson has joined #buildstream | 08:12 | |
| benschubert | juergbi: not sure it's worth it right now but yeah could be a solution | 08:13 |
| traveltissues | juergbi: i don't have permissions to hit the merge button on that mr, could you do that please or could i have the permissions | 08:13 |
| juergbi | traveltissues: I've merged it. I don't have an objection to granting you merge permission but you should ask that on slack in #buildbox to reach the right group | 08:16 |
| traveltissues | thanks | 08:17 |
| traveltissues | done | 08:24 |
| *** jude has joined #buildstream | 08:25 | |
| *** ikerperez has joined #buildstream | 08:37 | |
| *** tpollard has joined #buildstream | 08:43 | |
| *** santi has joined #buildstream | 08:44 | |
| *** seanborg_ has quit IRC | 08:46 | |
| *** seanborg_ has joined #buildstream | 08:46 | |
| *** tristan has joined #buildstream | 09:19 | |
| *** phoenix has joined #buildstream | 10:26 | |
| *** jward has quit IRC | 10:31 | |
| *** jswagner has quit IRC | 10:31 | |
| *** jward has joined #buildstream | 10:32 | |
| *** jswagner has joined #buildstream | 10:32 | |
| *** jswagner has joined #buildstream | 10:33 | |
| *** jswagner has joined #buildstream | 10:35 | |
| *** jswagner has joined #buildstream | 10:35 | |
| *** jswagner has joined #buildstream | 10:37 | |
| *** jswagner has joined #buildstream | 10:37 | |
| *** jswagner has joined #buildstream | 10:39 | |
| *** ChanServ sets mode: +o tristan | 10:42 | |
| *** tristan changes topic to "BuildStream 1.4.3 is out ! | https://gitlab.com/BuildStream/buildstream | Docs: https://docs.buildstream.build/ | IRC logs: https://irclogs.baserock.org/buildstream | Mailing List: https://mail.gnome.org/mailman/listinfo/buildstream-list | Roadmap: https://wiki.gnome.org/Projects/BuildStream/Roadmaps" | 10:42 | |
| jjardon | thanks tristan ! :) can you please upload it to pip as well? | 11:25 |
| jjardon | tristan: seems the ostree fixes are different in the bst-1 and bst-1.4 branches; is that intended? | 11:34 |
| tristan | jjardon, you got the password ? | 11:37 |
| jjardon | tristan: nope, I've never had aceess to that | 11:37 |
| tristan | jjardon, are they actually different ? | 11:37 |
| tristan | or just the commit shas are different so you think they are different ? | 11:38 |
| jjardon | tristan: seems the branch point is commit 62eee7be681c74c6b6aa679acac9d27bf1b871e9 | 11:38 |
| jjardon | tristan: the commit is different | 11:38 |
| tristan | just shas | 11:38 |
| tristan | the commit ? or the sha ? | 11:38 |
| jjardon | sha, sorry | 11:38 |
| tristan | The content of the commit should be the same | 11:38 |
| tristan | it's cherry picked back to the 1.4 branch | 11:38 |
| jjardon | ah rigth | 11:38 |
| tristan | jjardon, as I mentioned the other day, I branched 1.4 off so I could land the includes thing... and *then* I crashed face first into the CI brick wall | 11:39 |
| tristan | and had to fix ostree | 11:39 |
| jjardon | ok, sure ,I was only double checking | 11:39 |
| * persia finds comparison of tree SHAs useful as a way of avoiding confusion from different commit SHAs for the same content | 11:40 | |
| * jjardon tags "bst-1.4-branchpoint" for future reference | 11:41 | |
| jjardon | tristan: did you add all the checks to the bst-1.4 branch? (daily build, protections ..etc) (I can do it now if you are busy) | 11:42 |
| tristan | jjardon, what are those, I have no idea about those | 11:43 |
| tristan | honestly, there used to be this information in the CONTRIBUTING.rst, now it's been broken out into a page which our docs don't even link to | 11:43 |
| tristan | and I'll bet that this information of what you're supposed to do at this point didn't end up in that forgotten unreachable docs page :-S | 11:44 |
| *** seanborg_ has quit IRC | 11:52 | |
| *** seanborg_ has joined #buildstream | 11:52 | |
| jjardon | tristan: overnigth test is a simple check to verify the branch keep building a big bst project even without the cache enabled | 11:54 |
| jjardon | I have added the job now | 11:54 |
| tristan | jjardon, What are the "protections ..etc" part ? | 11:56 |
| jjardon | tristan: basically no one can directly force push, typical gitlab config for official branches | 11:56 |
| tristan | Ah that, nothing ever needs to be done for that | 11:57 |
| tristan | That would be a real pain if we had to do that every minor point | 11:58 |
| jjardon | ah, we have a wildcard bst-*, so all done automatically :) | 11:58 |
| jjardon | tristan: not minor point, every time we branch | 11:58 |
| tristan | We branch on minor points though | 11:58 |
| jjardon | which should not happen often | 11:58 |
| jjardon | tristan: only if needed | 11:58 |
| tristan | Well, happens every 6 months or so | 11:58 |
| tristan | not lately but probably again after 2.0 | 11:59 |
| tristan | Anyway as I recall, it's a huge list of manually entered committers in that thing | 11:59 |
| tristan | takes an hour to setup | 11:59 |
| jjardon | tristan: as I said, automatically done; we have a wildcard | 12:00 |
| * tristan 's hardware is getting all flaky :'( | 12:00 | |
| * tristan still has to take in his new laptop to the service center and maybe get it replaced (still a long time on warrenty, don't feel like going there and doing that chore) | 12:01 | |
| tristan | now my 4 year old laptop's screen is starting to flicker, which it only previously did when reaching low power :-/ | 12:01 |
| *** tristan has quit IRC | 12:06 | |
| *** tristan has joined #buildstream | 12:22 | |
| *** cs-shadow has joined #buildstream | 12:23 | |
| *** ChanServ sets mode: +o tristan | 12:27 | |
| tristan | Reboot to the rescue | 12:27 |
| tristan | Wow [00:00:35][][] SUCCESS Loading elements | 12:44 |
| tristan | oops | 12:44 |
| tristan | benschubert, tiny MR look see ? https://gitlab.com/BuildStream/buildstream/-/merge_requests/1928 | 12:58 |
| tristan | Also, not sure what to look at tomorrow... I think I'll leave the junction conflicts story fester a bit longer | 12:59 |
| tristan | benschubert, are you planning to pickup cross-junction plugin loading ? | 12:59 |
| * tristan thinks benschubert wanted to do that one | 13:00 | |
| tristan | Oh wait... shouldnt deprecation warnings be allowed to be fatal ? | 13:01 |
| benschubert | tristan: go for it if you want, my plate is currently pretty full :) | 13:01 |
| tristan | I think they should... however... it poses an interesting problem for cache keys | 13:01 |
| tristan | I think also there was a request to (optionally) consider plugin exact versions in the cache key, which seems worth visiting | 13:02 |
| tristan | Seems these low hanging fruit do still require a bit of thought though | 13:03 |
| tristan | benschubert, I don't think I'll have time to get started on that tomorrow, but if cross junction loading is still on the table I may start that on friday and aim to have a ready MR by early next week | 13:04 |
| benschubert | tristan: I don't htink I'll be able to focus on BuildStream until next week anyways, at least not for such a thing | 13:04 |
| tristan | Ok | 13:05 |
| tristan | Hopefully by next week we make more progress on what to do with double-loaded junctions | 13:05 |
| benschubert | happy to help if you want reviews/anything else then | 13:05 |
| * tristan wonders if we're just making too much fuss about that | 13:05 | |
| tristan | !1928, but I think that's really a nobrainer ;-) | 13:06 |
| tristan | I'll just land it if nobody reviews it | 13:06 |
| benschubert | reviewed :) https://gitlab.com/BuildStream/buildstream/-/merge_requests/1925 also if you have time, it's also a simple one | 13:10 |
| tristan | gitlab's a bit sluggish today | 13:19 |
| tristan | benschubert, while the page loads... does your patch ensure that we still test the pip source plugin in buildstream, possibly by requiring bst-plugins-experimental and testing it at a specific commit sha in our tests ? | 13:20 |
| tristan | or is that already there ? | 13:20 |
| tristan | As I recall, `pip` and `cargo` are the only source plugins which exercise the feature of requiring previous sources at fetch and track time | 13:21 |
| benschubert | tristan: this removes all the tests for the pip source in buildstream, as they were only 5-6 and they are duplicated in experimental already | 13:21 |
| tristan | Right, but do we run those tests from bst-plugins-experimental in the context of a BuildStream CI session ? | 13:21 |
| tristan | I think that's a hard requirement, and I think I saw we do something like that in tox.ini (we use a specific version of bst-plugins-experimental right ?) | 13:22 |
| * tristan thinks the `tox -e py{version}-plugins` cases cover those | 13:24 | |
| tristan | but worth verifying | 13:24 |
| *** aminbegood has joined #buildstream | 13:27 | |
| benschubert | tristan: no we only run the standardized source tests for this | 13:33 |
| benschubert | so all the specific ones are not run (basically, hte ones removed by the PR are not run) | 13:33 |
| benschubert | ah so track and fetch would still be run I think | 13:34 |
| benschubert | the only real change is the tests removed there | 13:34 |
| tristan | benschubert, Do we know that the tests which we do run in BuildStream CI actually test this functionality ? | 13:35 |
| tristan | I think the "standardized tests" are only source plugins which provide repo implementations | 13:35 |
| tristan | This is really an important and delicate part of plugin separation, we went though a lot of headache getting it "maybe right" a very long time ago :-S | 13:36 |
| tristan | Point is, we need to ensure we keep testing the aspects of the core (of course you get the point, I know) | 13:37 |
| *** aminbegood has quit IRC | 13:37 | |
| benschubert | tristan: if pip doesn't implement the 'repo', then we never tested that part | 13:37 |
| benschubert | aaaand https://gitlab.com/BuildStream/bst-plugins-experimental/-/tree/master/src/bst_plugins_experimental/testutils/repo it doesn't | 13:38 |
| * tristan feels like a lot of attention was spent on making something plug-and-play, but less attention to the actual requirements | 13:38 | |
| tristan | Right | 13:38 |
| tristan | benschubert, then probably we still have the `pip` source in BuildStream *because* this aspect was not considered yet ? | 13:38 |
| tristan | We probably need to have some custom entry points for testing from external plugin repos, this will also be important for git and maybe others | 13:39 |
| tristan | for instance git implements the mirrors | 13:39 |
| tristan | we need to keep all of this covered | 13:39 |
| benschubert | tristan: I'd rather have testing plugins that do test this part eexplicitely | 13:40 |
| benschubert | using other plugins to test it as a side effect is not great | 13:40 |
| tristan | That works too, but there is a danger with that: it may allow us to shift goal posts unfairly | 13:41 |
| tristan | from the core perspective I mean | 13:41 |
| benschubert | which is true for anything we would not be testing with external plugins | 13:41 |
| tristan | Honestly I don't mind, but I think moving plugins out of the core is not such a hurry, and we should ensure that while removing plugins, we don't lose coverage of features in the core by doing so | 13:42 |
| tristan | if that's the case, we can just drop all the work which was already done to test bst-plugins-experimental in BuildStream test runs itself too | 13:42 |
| tristan | We gotta choose a way and stick to it I guess | 13:42 |
| benschubert | tristan: agreed on that, my problem is the botched job that was done ending in having plugins duplicated, now we need to keep those in sync and it's a mess | 13:42 |
| * persia is a bit concerned by "moving plugins out of the core is not such a hurry", as that sort of phrasing has led to a very long transition so far | 13:43 | |
| benschubert | persia: agreed, however I think the problem was more of trying to move things out of core in a unsynchronized way without ensuring things could be removed cleanly, and thus leading to duplication | 13:43 |
| tristan | persia, I think there was some kind of misconception that they had to move fast, which may be affecting the optics | 13:43 |
| persia | benschubert: Absolutely agreed. I think the current plan is more likely to succeed than the last. | 13:44 |
| tristan | True, we would be better off if nobody had started pushing to move plugins in a hurry | 13:44 |
| tristan | Anyway here we are | 13:44 |
| persia | tristan: I think there was just confusion about what was "in" and what was "out" and when what moved, which blurred optics :) | 13:45 |
| tristan | I think we really should resolve coverage in advance of moving things out which remove important coverage - even if it looks messy in the meantime | 13:45 |
| benschubert | tristan: ok, I'll postpone this MR, it's the last of the duplicated plugins anyway, pip element was removed from core a few days ago and tar should be removed from experimental not core | 13:45 |
| persia | I think here is a good place to be, and we have a good plan. I just think we need to be careful not to let the plan get desynchronised by deferring some parts of it. Doing it synchronised later is better than doing it desynchronised *now*, but doing part later without defining "later" or the part to be done risks what we do. | 13:46 |
| * tristan gotta leave the closing coffee shop | 13:46 | |
| tristan | persia, I think we're on a roll for now anyway | 13:46 |
| tristan | there is a lot of things to do, but they're getting done | 13:47 |
| persia | Yes :) | 13:49 |
| *** tristan has quit IRC | 13:51 | |
| traveltissues | persia: for example: https://gitlab.com/BuildStream/bst-plugins-experimental/-/issues/29 so it seems like this has moved a few times and there are WIP for moving things again | 14:11 |
| *** cs-shadow has quit IRC | 14:43 | |
| *** cs-shadow has joined #buildstream | 14:53 | |
| *** hasebastian has joined #buildstream | 15:31 | |
| WSalmon | looks unlucky as a restart fixed it but has any one ever seen bst go bang like https://gitlab.com/celduin/bsps/example-app/-/jobs/550821717 | 15:32 |
| juergbi | WSalmon: eh, no. might be an issue with gRPC. pure Python shouldn't be able to trigger this and I don't think we use any mutexes in Cython code given our code is multi-process but single-threaded (GIL) | 15:49 |
| WSalmon | juergbi, im not convinced about your reverting patch https://gitlab.com/celduin/bsps/example-app/-/jobs/550859879 this seems to start builds | 15:51 |
| juergbi | WSalmon: the first thing it tries is pull deploy/image.bst | 15:51 |
| juergbi | but it seems that's not cached | 15:51 |
| juergbi | maybe you're hit by the cache key instability in master. there was a very recent cache key calculation fix | 15:52 |
| WSalmon | that may well be it | 15:53 |
| WSalmon | thanks juergbi loads of things changed recently and have had to fix loads of things | 15:54 |
| WSalmon | sorry i missed that | 15:54 |
| WSalmon | ill retry it with a clean cache once its all rebuilt | 15:54 |
| juergbi | ta | 15:55 |
| WSalmon | but the fact its pulling in the right order is a massive pluse! | 15:56 |
| WSalmon | thanks | 15:56 |
| WSalmon | juergbi, why dose it not try to pull deploy/image.bst's build deps next? it gose straight to the back of the que? `bst show --format "%{name} %{deps}" deploy/image.bst` gives `deploy/image.bst [components/genimage.bst, deploy/filesystem.bst, integration/mtab.bst, vm/prepare-image.bst]` | 16:06 |
| juergbi | WSalmon: at least some of these runtime-depend on freedesktop bootstrap-import.bst | 16:09 |
| juergbi | and that's a stack that indirectly depends on these bootstrap elements | 16:10 |
| juergbi | i.e., to build deploy/image.bst these bootstrap elements are all needed | 16:10 |
| juergbi | even if the direct build dependencies are already built | 16:10 |
| juergbi | BuildStream thus marks all of them as 'required' at the same time, and then attempts to pull them in parallel | 16:12 |
| juergbi | and it generally tries to pull elements at the bottom of the stack first (if they are required) as they are often needed by multiple jobs => improving parallelism | 16:13 |
| *** santi has quit IRC | 16:22 | |
| *** santi has joined #buildstream | 16:22 | |
| WSalmon | thanks | 16:32 |
| WSalmon | could we have `requires` as a format option? would that be tricky, im finding all this really tricky to be sure of | 16:33 |
| WSalmon | hence all my silly questions | 16:34 |
| WSalmon | something in buildstream ( juergbi's build order patch ) or bst-plugins-experimental, master in the last few days cause this https://gitlab.com/celduin/bsps/example-app/-/jobs/550906009 ? | 16:40 |
| *** pointswaves has joined #buildstream | 16:41 | |
| juergbi | WSalmon: `bst show --deps build` should show you build dependencies and indirect runtime dependencies, i.e., what's required for a build | 16:46 |
| *** narispo has quit IRC | 16:48 | |
| *** narispo has joined #buildstream | 16:48 | |
| juergbi | WSalmon: I can't think of anything that would affect staging/overlaps | 16:49 |
| *** santi has quit IRC | 17:07 | |
| *** santi has joined #buildstream | 17:08 | |
| *** jude has quit IRC | 17:09 | |
| *** tristan has joined #buildstream | 17:15 | |
| juergbi | WSalmon: I can reproduce the issue locally, also seeing it without my changes. hm | 17:33 |
| *** tpollard has quit IRC | 17:43 | |
| *** santi has quit IRC | 17:44 | |
| *** hasebastian has quit IRC | 17:50 | |
| juergbi | e5ed02da0b99c16481eac58963f4ebbdf0481590 is the first bad commit | 17:53 |
| juergbi | element.py: Always expand all variables at element creation | 17:53 |
| juergbi | benschubert: this appears to break freedesktop-sdk build | 17:53 |
| juergbi | not sure yet what exactly is happening | 17:53 |
| benschubert | ouch what? | 17:54 |
| benschubert | how can I reproduce? (which element in fsdk?) | 17:54 |
| *** pointswaves has quit IRC | 17:56 | |
| juergbi | possibly related to variables from includes | 17:56 |
| juergbi | i.e., maybe variables resolved before the includes have been processed | 17:56 |
| juergbi | I see build error in bootstrap/build/glibc-stage1.bst | 17:56 |
| juergbi | but have to recheck whether it happens when building that element alone or only as part of the full build | 17:57 |
| juergbi | in the failure case %{builddir} is resolved to empty string instead of bst_build_dir as set in the include | 17:57 |
| *** pointswaves has joined #buildstream | 17:59 | |
| benschubert | variable expansion is done after the compose | 18:00 |
| juergbi | benschubert: I can't reproduce it if I only build glibc, however, it seems reproducible as part of a full "make build" (happens after a couple of minutes here) | 18:01 |
| benschubert | I'm resetting my build and will retry | 18:01 |
| juergbi | bootstrap/build/debugedit-build.bst fails with overlap errors that shouldn't happen | 18:02 |
| juergbi | (presumably due to incorrect builds of dependencies due to the variable issue) | 18:02 |
| benschubert | juergbi: weird. Which branch of fsdk? My previous MR fails with ConfigParser errors? | 18:04 |
| juergbi | ah, I'm on juerg/bst2 + pip patch from WSalmon | 18:06 |
| juergbi | and without artifact cache | 18:06 |
| benschubert | still configparser issue? what | 18:06 |
| benschubert | there is an element that fails that is not in the sdk-image.bst cone | 18:07 |
| benschubert | (trying to build sdk-image.bst) | 18:07 |
| juergbi | I'm using 'make build' | 18:07 |
| benschubert | juergbi: https://gitlab.com/BuildStream/bst-plugins-experimental/-/blob/master/src/bst_plugins_experimental/elements/flatpak_image.py#L51 that can never work. are you not using bst-plugins-experimental master? | 18:11 |
| benschubert | (interesting bug found x') | 18:11 |
| juergbi | ah, no, I haven't updated bst-plugins-experimental for a few days | 18:11 |
| juergbi | on f77f5c4dfbe9e8d147fcd0500d76a68634e7f92e right now | 18:11 |
| benschubert | this has been here for two years? | 18:12 |
| benschubert | wait what | 18:12 |
| juergbi | what configparser error do you get exactly? | 18:13 |
| benschubert | that the configparser can't be converted into json | 18:14 |
| benschubert | when trying to build the cache key | 18:14 |
| *** seanborg_ has quit IRC | 18:14 | |
| juergbi | maybe different dependency versions, I haven't reinstalled my venv recently | 18:14 |
| benschubert | mine is latest | 18:15 |
| benschubert | ok make build is running | 18:17 |
| benschubert | however, that doens't happen with the sdk-image sub-cone, interesting | 18:19 |
| benschubert | https://paste.gnome.org/pehfmzf1x uh? | 18:28 |
| cs-shadow | benschubert: the paste.gnome link gives me a 404 :/ is there a typo somewhere? | 19:14 |
| benschubert | ah no, outdated | 19:14 |
| cs-shadow | or perhaps I need to authenticate ? | 19:14 |
| cs-shadow | ah ok | 19:15 |
| benschubert | it as a "proc is none" in the scheduler somewhere because of a problem with a remote cache | 19:15 |
| benschubert | cs-shadow: https://paste.gnome.org/plu3ebghu here it is again :'D | 19:21 |
| cs-shadow | thanks! | 19:21 |
| cs-shadow | interesting .. | 19:21 |
| *** phoenix has quit IRC | 20:38 | |
| pointswaves | fyi https://gitlab.com/BuildStream/buildstream/-/issues/1309 this completely killed my terminal and had to kill off the hole terminal | 22:57 |
| *** narispo has quit IRC | 23:17 | |
| *** narispo has joined #buildstream | 23:17 | |
| *** narispo has quit IRC | 23:29 | |
| *** narispo has joined #buildstream | 23:29 | |
| *** pointswaves has quit IRC | 23:36 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!