| *** juergbi has quit IRC | 01:19 | |
| *** semanticdesign has quit IRC | 01:35 | |
| *** semanticdesign_ has quit IRC | 01:35 | |
| *** juergbi has joined #buildstream | 03:45 | |
| *** tristan has joined #buildstream | 04:37 | |
| *** tristan has quit IRC | 06:52 | |
| *** jude has joined #buildstream | 06:55 | |
| *** jude has quit IRC | 07:18 | |
| *** jude has joined #buildstream | 07:20 | |
| *** tristan has joined #buildstream | 07:30 | |
| *** semanticdesign has joined #buildstream | 08:01 | |
| *** semanticdesign_ has joined #buildstream | 08:01 | |
| *** tiagogomes has joined #buildstream | 08:07 | |
| *** bochecha has quit IRC | 08:45 | |
| *** bochecha has joined #buildstream | 08:49 | |
| *** valentind has joined #buildstream | 08:58 | |
| *** tiagogomes has quit IRC | 09:08 | |
| *** ssam2 has joined #buildstream | 09:10 | |
| *** tiagogomes has joined #buildstream | 09:16 | |
| *** jude has quit IRC | 09:19 | |
| *** jude has joined #buildstream | 09:19 | |
| *** tiagogomes has quit IRC | 09:20 | |
| *** tiagogomes has joined #buildstream | 09:20 | |
| *** tlater has joined #buildstream | 09:52 | |
| *** tiagogomes has quit IRC | 10:04 | |
| *** tiagogomes has joined #buildstream | 10:19 | |
| *** valentind has quit IRC | 10:50 | |
| tlater | Hm, not sure if this is another bug related to the child watcher, but when I run `bst build --track` the status area doesn't update by itself (i.e. the times don't change unless a message is printed). | 12:00 |
|---|---|---|
| tristan | that's driven by a ticker in _scheduler/scheduler.py | 12:06 |
| tristan | It could be related | 12:06 |
| tristan | tlater, And if you revert your local work, the ticker continues to work right ? | 12:06 |
| tristan | (In which case, you *do* know it's related :)) | 12:07 |
| tlater | tristan: It doesn't, no :/ | 12:07 |
| tristan | ohhh, that would be bad | 12:07 |
| tristan | it's something possible to go unnoticed | 12:07 |
| * tlater will check again | 12:08 | |
| tlater | It's possible I'm not reverting properly, though resetting to something old doesn't change anything. | 12:08 |
| tristan | since usually there is a lot of activity, it could have gone unnoticed for a while | 12:08 |
| tristan | tlater, if you confirm that it's not a regression from your change, and that your fix works, then we can treat it as a separate issue (and it probably is, if that is the case) | 12:10 |
| tristan | tlater, I can confirm that is *not* happening with buildstream master | 12:11 |
| tlater | tristan: I'll try buildstream master, it's possible this happens only after a track fails | 12:11 |
| tristan | I did `mv ~/.cache/buildstream ~/.cache/buildstream.backup && bst track core/gnome-backgrounds.bst` | 12:11 |
| tristan | the gnome-backgrounds.bst is heavy graphics, big download... so only one thing happening, and ticker works | 12:12 |
| * tlater waits for base-platform to track, can't see with the download going on | 12:16 | |
| tlater | tristan: Unless python weirdly caches files for something installed with `pip -e`, this happens in master after something fails to track and lets me choose 'continue' - I thought this was the same issue in #107 and reported them together. | 12:21 |
| *** tiagogomes has quit IRC | 12:21 | |
| tlater | Also seeing the annoying waitpid errors again, so I'm fairly sure this is unrelated. | 12:21 |
| tristan | So this only happens *after* continue ? | 12:42 |
| tristan | Could be that we've suspended something in that context and forget to wake it back up ? | 12:43 |
| *** xjuan has joined #buildstream | 12:43 | |
| tristan | anyway, tlater - as I mentioned; if it's not caused by your patch, and it's a bug in master, then it's a separate bug | 12:43 |
| tristan | if you could file it even, that would be great | 12:44 |
| tristan | Alright: https://gitlab.com/BuildStream/cargo-fetcher that's a start | 12:47 |
| tristan | Just needs a launcher script and a setup.sh to schedule the cron jobs, and we have an ever accumulating, self updating vendor directory to import, and use for building rusty things like librsvg | 12:48 |
| ssam2 | is that source or binaries ? | 12:49 |
| tristan | If librsvg grows a new rusty dependency, just commit to the Cargo.toml in that repo, and in say 5 or 10 minutes, it will be available for the next `bst track rust/vendor.bst` (or whatever we call that element in the GNOME project) | 12:49 |
| tristan | it's all source | 12:49 |
| ssam2 | why OSTree rather than Git ? | 12:50 |
| tristan | No reason | 12:50 |
| tristan | Could be git | 12:51 |
| tristan | Or rather, one good reason: Allowed me to reuse a lot of stuff from debootstrap-ostree :) | 12:51 |
| ssam2 | fair enough | 12:51 |
| tristan | Anyway, it's hopefully a stop gap for until such a day that we might create a `cargo` Source (which has the downside of requiring users to have cargo on their host) | 12:52 |
| tristan | I'm thinking a cargo source will not be too bad | 12:52 |
| tristan | But yeah, we need to think on this more | 12:52 |
| ssam2 | seems like we could have an import tool to undo whatever wacky stuff cargo is doing to hide the real source code | 12:53 |
| tristan | yeah like generating .bst files you mean right ? | 12:54 |
| tristan | maybe yeah | 12:54 |
| tristan | to think about another day... in the day time :D | 12:54 |
| tristan | Interestingly, I'll make librsvg.bst only build-depend on that rusty thingy | 12:55 |
| tristan | cause it's all static source stuff, anything rusty just needs to build-depend on it | 12:55 |
| tristan | tomorrow I should have automation and tests | 12:56 |
| tristan | err, tests/test a build of GNOME with it/ :) | 12:56 |
| *** tristan has quit IRC | 13:01 | |
| *** tiagogomes has joined #buildstream | 13:08 | |
| * tlater had a confusing mess of different versions of buildstream due to running `./setup.py develop` once, which seems to have been the cause of the issue earlier | 13:40 | |
| tlater | Or maybe not... | 13:40 |
| *** tristan has joined #buildstream | 14:03 | |
| *** anahuelamo has quit IRC | 14:51 | |
| *** anahuelamo has joined #buildstream | 15:07 | |
| *** valentind has joined #buildstream | 15:56 | |
| *** xjuan has quit IRC | 16:11 | |
| *** xjuan has joined #buildstream | 16:16 | |
| *** jude has quit IRC | 16:27 | |
| *** ssam2 has quit IRC | 17:07 | |
| *** cs_shadow_ has quit IRC | 17:11 | |
| *** tristan has quit IRC | 17:21 | |
| *** gitlab-br-bot has joined #buildstream | 17:27 | |
| *** gitlab-br-bot has quit IRC | 17:28 | |
| *** gitlab-br-bot has joined #buildstream | 17:29 | |
| *** tlater has quit IRC | 17:41 | |
| *** jude has joined #buildstream | 18:34 | |
| *** tristan has joined #buildstream | 18:35 | |
| *** cs_shadow_ has joined #buildstream | 18:40 | |
| tristan | jjardon[m], weird, I got a moderator email for buildstream-list, and was able to login... moderation queue is empty - and I did not receive the mail on the list | 18:50 |
| tristan | jjardon[m], did you handle that ? | 18:50 |
| cs_shadow_ | ah! that was me. I accidentally sent a message from incorrect email address so I cancelled the moderation request and resent it from the correct account. Sorry about the confusion :) | 18:51 |
| tristan | cs_shadow_, ah that's you ! :D | 18:52 |
| tristan | it's very late here - but glossing briefly over it, there are a couple of related issues I think which set some ideas about how to get there for incremental builds | 18:53 |
| tristan | I think a first step will be supporting that for workspaces | 18:53 |
| tristan | cs_shadow_, there is another old bug report, which is interesting but a bit far from grasp, which is about caching the build directories | 18:54 |
| tristan | that would block on the ability to even store mtime in artifacts, which is another complex task, which goes hand in hand with handling xattrs and setuid binaries safely within the build sandbox | 18:55 |
| *** jude has quit IRC | 18:55 | |
| tristan | still, incremental builds for workspaces will probably cover the majority of interesting cases, caching and sharing build directories via artifacts is really a limousine | 18:57 |
| cs_shadow_ | yeah, workspaces makes sense. I have a 3-liner patch that makes it work by reusing same build directories but that doesn't handle all various cases. I haven't yet thought about how to store this as an artifact but it does let you do dirty builds | 18:57 |
| cs_shadow_ | storing mtime for the artifacts might be tricky, as you point out | 18:57 |
| tristan | yes, there are some good arguments for serializing attributes as YAML metadata, which would make some interesting things easier (like implementing `bst diff` to check repeatability, and perhaps GPG signing), and also alleviate the difficulty in the artifact backend | 18:58 |
| tristan | that would still need a new fuse layer for actually handling the xattrs and setuid properly, though | 18:59 |
| cs_shadow_ | `bst diff` would be great. Although I'm hoping that we can make progress on this in steps. First step being supporting this locally with workspaces perhaps | 19:02 |
| tristan | oh yeah, only mentioning that because it's a good excuse for storing the attributes in our metadata | 19:02 |
| cs_shadow_ | definitely | 19:03 |
| tristan | If we can have the workspaces logically take ownership of the build directory in the sandbox, and have that pretty clean... | 19:03 |
| tristan | then we should land that asap :) | 19:03 |
| tristan | Probably we need to make sure that closing a workspace and deleting it also nukes it's build directory | 19:04 |
| tristan | and we want to make sure it's *only* the build directory, not the whole staging area | 19:04 |
| cs_shadow_ | yes, handling the dirty build areas might also become a thing soon after adding support for incremental builds | 19:04 |
| tristan | because we'll want to use incremental builds with --no-strict, replacing the base separately from the build dir, etc | 19:04 |
| tristan | cs_shadow_, random thought before I drop off the planet... maybe this is what your patch does anyway... | 19:14 |
| tristan | it seems to me that we get everything we need by simply mounting the workspace into the sandbox directly, instead of staging it there | 19:15 |
| tristan | and then the edge cases are just... `bst shell --sysroot <buildroot>` not sure theres anything else that needs handling | 19:15 |
| cs_shadow_ | At this point, my patch still copies files but doesn’t overwrite mtimes. And it re-uses the same build area for builds thereby preserving its contents | 19:17 |
| cs_shadow_ | It shouldn’t be too hard (I think) to change it to just use the workspace directory directly | 19:18 |
| cs_shadow_ | I’ll see if can hack that up quickly | 19:18 |
| tristan | it'll be a bit tricky, sandbox internals have this tricky mount map thing | 19:19 |
| tristan | but the overall logic seems sane and non disruptive | 19:19 |
| tristan | leaving build areas around is disruptive | 19:20 |
| tristan | and limiting when you want to incremental build something against a sysroot which has changed (opening up a whole vector of edge cases) | 19:20 |
| cs_shadow_ | Agreed. That was easy to hack as a poc though ;) | 19:21 |
| tristan | :) | 19:21 |
| cs_shadow_ | Thanks for the quick tips. I’ll work on it a bit and reply on that thread once I’ve got something working. | 19:22 |
| *** semanticdesign has quit IRC | 19:24 | |
| *** semanticdesign_ has quit IRC | 19:24 | |
| *** xjuan has quit IRC | 20:51 | |
| *** valentind has quit IRC | 23:06 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!