*** narispo has quit IRC | 01:39 | |
*** narispo has joined #buildstream | 01:40 | |
*** kapip has quit IRC | 03:40 | |
*** aevri has quit IRC | 03:41 | |
*** aevri has joined #buildstream | 03:45 | |
*** kapip has joined #buildstream | 03:46 | |
gitlab-br-bot | juergbi opened issue #1132 (Batch CAS writes to reduce round trips between bst and casd) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1132 | 05:22 |
---|---|---|
*** slaf has quit IRC | 07:01 | |
*** slaf has joined #buildstream | 07:03 | |
*** slaf has joined #buildstream | 07:03 | |
*** slaf has joined #buildstream | 07:03 | |
*** slaf has joined #buildstream | 07:04 | |
*** slaf has joined #buildstream | 07:04 | |
*** slaf has joined #buildstream | 07:04 | |
*** slaf has joined #buildstream | 07:04 | |
*** slaf has joined #buildstream | 07:05 | |
*** slaf has joined #buildstream | 07:05 | |
*** slaf has joined #buildstream | 07:05 | |
*** slaf has joined #buildstream | 07:06 | |
*** slaf has joined #buildstream | 07:06 | |
*** slaf has joined #buildstream | 07:06 | |
*** slaf has joined #buildstream | 07:06 | |
*** slaf has joined #buildstream | 07:07 | |
*** slaf has joined #buildstream | 07:07 | |
*** slaf has joined #buildstream | 07:07 | |
*** slaf has joined #buildstream | 07:07 | |
*** slaf has joined #buildstream | 07:08 | |
*** slaf has joined #buildstream | 07:08 | |
*** slaf has joined #buildstream | 07:08 | |
*** slaf has joined #buildstream | 07:08 | |
*** lantw44 has quit IRC | 07:46 | |
*** lantw44 has joined #buildstream | 07:46 | |
*** lantw44 has quit IRC | 07:47 | |
*** lantw44 has joined #buildstream | 07:47 | |
*** rdale has joined #buildstream | 08:21 | |
gitlab-br-bot | juergbi opened (was WIP) MR !1469 (build-all-option->master: Add 'dependencies' option to 'build' user config) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1469 | 08:23 |
*** phil has joined #buildstream | 09:12 | |
*** traveltissues has joined #buildstream | 09:26 | |
*** jonathanmaw has joined #buildstream | 09:39 | |
*** toscalix has joined #buildstream | 10:11 | |
coldtom | i've just noticed that the defaults for `include-orphans` are inconsistent between `compose` and `filter` elements, which seems a bit unintuitive to me | 11:06 |
*** toscalix has quit IRC | 12:57 | |
*** toscalix has joined #buildstream | 12:57 | |
tlater[m] | cs-shadow: regarding https://gitlab.com/BuildStream/buildstream/merge_requests/1590/#note_214862032 | 13:00 |
tlater[m] | Why do we have a `source checkout --deps`? | 13:00 |
* tlater[m] doesn't really see the use case for it | 13:00 | |
*** narispo has quit IRC | 13:12 | |
*** narispo has joined #buildstream | 13:13 | |
juergbi | tlater[m]: isn't this a replacement for the former source bundle command? | 13:18 |
tlater[m] | Hm, I suppose | 13:19 |
* tlater[m] wonders if doing the same for `artifact checkout` would result in confusio | 13:20 | |
tlater[m] | *confusion | 13:20 |
juergbi | that already has --deps support, doesn't it? | 13:21 |
tlater[m] | Not atm | 13:21 |
juergbi | hm, --help claims it does | 13:21 |
tlater[m] | That discussion there is about adding it | 13:21 |
* tlater[m] thought removing it from `source checkout` would perhaps be better | 13:21 | |
juergbi | artifact checkout with deps certainly makes sense to me | 13:22 |
juergbi | like bst shell without the shell ;) | 13:22 |
tlater[m] | Hm, yeah, but the intention is to set up stacks to create that kind of output | 13:24 |
tlater[m] | It's a nice shortcut I suppose | 13:24 |
juergbi | stack is essentially just a dependency list | 13:26 |
juergbi | if you dropped dependencies from bst artifact checkout, checkout of a stack would be an empty directory, right? | 13:26 |
juergbi | compose would work, of course | 13:26 |
jennis | The discussion was about adding --deps *all* specifically to artifact checkout | 13:27 |
jennis | For the sake of consistency. source checkout supports --deps all|none|run|build, so should we do the same for artifact checkout? | 13:28 |
jennis | Even though artifact checkout --deps all may seem like quite a weird thing to do | 13:28 |
juergbi | I don't think it's too weird | 13:28 |
juergbi | not sure whether it will be used a lot but it's practically no effort, right? | 13:29 |
jennis | It's easy enough to support | 13:29 |
jennis | yeah, I have a patch for it | 13:29 |
juergbi | it would mean that you have all build dependencies in a potential chroot | 13:29 |
jennis | I'll create an MR soon then | 13:29 |
juergbi | so you could rebuild any component | 13:29 |
juergbi | at least as long as there are no conflicts due to bootstrap elements | 13:29 |
tlater[m] | Oh, master pipeline failed | 13:57 |
* tlater[m] checks if the docs still work | 13:57 | |
tlater[m] | Yes! | 13:57 |
coldtom | tlater[m]: thanks for that docs patch, that bug was incredibly frustrating | 14:00 |
benschubert | Any practical reason why we resolve the state of the cache before doing a 'source checkout' 'source track' and such? | 14:00 |
benschubert | I back/forward ported updates to bst-external to the bst-plugins-experimental repo: https://gitlab.com/BuildStream/bst-plugins-experimental/merge_requests/32 is someone wants to have a look | 14:01 |
benschubert | I'd like to get this in to be able to build the latest freedesktop sdk with buildstream master, which would allow me to fix our nightly tests (We can't really use the previous version, some sources have disappeared) | 14:03 |
* coldtom takes a look | 14:05 | |
benschubert | https://gitlab.com/snippets/1894045 Can someone help me make sense of this message? 'resolved key summary' is marked as failed, the rest is marked as success... | 14:06 |
tlater[m] | benschubert: Have you looked at the tracking log? | 14:12 |
* tlater[m] hasn't seen this before, but can imagine that it's a bad error message for a failed cache operation. | 14:12 | |
benschubert | tlater[m]: my current guess is the artifact for this source was already cached and 'failed', hence shown like this | 14:14 |
tpollard | it's tracked, but the state of the artifact that is cached locally is failed | 14:14 |
tlater[m] | Oh, right | 14:14 |
benschubert | makes more sense, thanks :) | 14:14 |
tpollard | I don't think it's a nice message though | 14:15 |
benschubert | I build an artifact, it fails, it gets pushed to remote artifact server. I 'bst artifact delete' it, because it should not have happened (temporary failure) I rebuild. It gets pulled? How can I force rebuild except by --fetchers=0 ? | 14:30 |
tpollard | erm | 14:31 |
tpollard | you could also --remote to a dummy url | 14:32 |
benschubert | oh... also --fetchers=0 doesn't work for this | 14:33 |
benschubert | tpollard: '--remote' is not available ofr builds | 14:33 |
tpollard | it should be | 14:33 |
tpollard | I merged it a while ago | 14:33 |
benschubert | oh | 14:33 |
benschubert | it's on 'build' not bst ok fair | 14:34 |
tpollard | I think it could be a bst main option | 14:34 |
tlater[m] | tpollard: Not in the spirit of the question, I'd say | 14:34 |
tpollard | and i also started work on something along the lines of (Don't interact with any remotes option) | 14:34 |
tpollard | tlater[m]? | 14:35 |
tlater[m] | benschubert: We've been talking about a `bst build --force` for ages | 14:35 |
benschubert | Mmh my problem seems to come from a mis-downloaded tarball | 14:35 |
benschubert | my ref is correct (downloaded the zip file, sha256sum it, it matches my ref). Trying to source checkout with bst gives me a different content than the tarball I downloaded manually | 14:36 |
tlater[m] | tpollard? | 14:37 |
tpollard | tlater[m]: I didn't really understand what you mean by that, that's all | 14:38 |
tlater[m] | bst main option makes sense, if that's what you mean. I'm constructing an email as we speak that will touch on that. | 14:38 |
* tlater[m] is worried that may cause some confusion, but leaves discussion to the ML | 14:39 | |
* tpollard nods | 14:39 | |
tlater[m] | Oh, you mean `build --force`? That's specifically for when you built something and a temporary failure broke the build and screwed up your artifact. | 14:41 |
tlater[m] | We should be able to override remote artifacts without disabling the remote, otherwise we end up... | 14:42 |
tlater[m] | Poisoning the cache I suppose? | 14:42 |
benschubert | ^ correct | 14:42 |
benschubert | my source cache is currently poisoned it seems... | 14:42 |
* tlater[m] didn't think he'd ever come up with that phrase to describe a build problem | 14:43 | |
tpollard | tainted maybe | 14:43 |
benschubert | Well, my source checkout or build shell definitely doesn't contain the data from the zip file | 14:44 |
tlater[m] | "Poisoning" is typically what people use to describe this vulnerability for DNS servers. It's a good fit for our case. | 14:45 |
tlater[m] | benschubert: But how did you get matching keys between a broken zip and an unbroken one? | 14:46 |
tlater[m] | Is this a sha collision? | 14:46 |
benschubert | I would hope not | 14:47 |
tlater[m] | I can see it for an artifact cache with failed builds, but not a source cache. | 14:47 |
benschubert | the sources give me 3 files, which I cant even find in the original zip file | 14:47 |
benschubert | but that do seem 'familiar' | 14:48 |
tlater[m] | Can you try to manually create cache keys for the two? | 14:49 |
tlater[m] | I wonder if your server delivers different zipfiles depending on the client's browser string | 14:50 |
tlater[m] | Because that seems more likely than a cache collision on a network error :) | 14:51 |
benschubert | Ok, I've answered part of the question: it's only giving me the data from one subdirectory of my zip file | 14:52 |
benschubert | the first in alphabetical order | 14:52 |
tlater[m] | ... Or a deliberate attack | 14:52 |
benschubert | I wish, at least I could blame it on someone else :'D | 14:53 |
benschubert | the question is, why do I only get one subdirectory of the zip file? | 14:53 |
juergbi | benschubert: check 'base-dir' config | 14:56 |
juergbi | the default is not ideal | 14:56 |
benschubert | juergbi: setting to '' worked | 14:56 |
benschubert | but why '*' matches only the first directory? | 14:56 |
benschubert | that seems like a bug to me, or am I missing something? | 14:56 |
juergbi | I think the idea is that it works out of the box for archives that have a single directory. which is very common, at least for tarballs | 14:57 |
juergbi | however, I think we should error out if '*' is specified and there are multiple entries | 14:57 |
benschubert | agreed | 14:58 |
*** cs-shadow has quit IRC | 15:08 | |
gitlab-br-bot | jennis opened MR !1598 (jennis/add_deps_all_to_checkout->master: Support `--deps all` in `artifact checkout`) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1598 | 15:13 |
benschubert | juergbi: I was thinking about cascache, should we throw an exception in `release_resources` if the process already had terminated? Or if the process doesn't terminate with 0 ? | 15:13 |
juergbi | benschubert: if the process is dead before we explicitly terminate it, it's an error | 15:14 |
juergbi | even if it terminates with 0 | 15:14 |
juergbi | although I don't expect that to happen in practice | 15:14 |
juergbi | (unless someone manually sends SIGTERM or similar) | 15:15 |
benschubert | unless.. segfault? :) | 15:15 |
juergbi | that would be exit code -11 | 15:15 |
benschubert | And yes, I meant 1) check if already stopped -> if yes error, otherwise stop -> if not stopped correctly (0) -> error | 15:16 |
juergbi | ah ok | 15:16 |
juergbi | yes, should probably also be an error or at least a warning | 15:16 |
juergbi | we have to be careful, though. if we send SIGKILL (after timeout), exit code will always be -9, not 0 | 15:17 |
juergbi | so non-0 exit is only unexpected for the regular SIGTERM case, not for the SIGKILL fallback | 15:17 |
benschubert | correct | 15:25 |
benschubert | I'll add a MR for that | 15:25 |
*** narispo has quit IRC | 15:58 | |
*** narispo has joined #buildstream | 15:58 | |
*** toscalix has quit IRC | 16:04 | |
benschubert | coldtom: is https://gitlab.com/BuildStream/bst-plugins-experimental/merge_requests/32 fine with you with an issue to tackle the fixmes? :) | 16:05 |
coldtom | benschubert: looks good to me, should be fine to merge | 16:08 |
benschubert | thanks a lot! | 16:08 |
*** cs-shadow has joined #buildstream | 16:14 | |
*** phil has quit IRC | 16:51 | |
*** phildawson_ has joined #buildstream | 16:51 | |
*** jonathanmaw has quit IRC | 16:53 | |
*** paulsherwood has quit IRC | 17:14 | |
*** valentind has quit IRC | 17:21 | |
*** jennis has quit IRC | 17:21 | |
*** jward has quit IRC | 17:21 | |
*** WSalmon has quit IRC | 17:21 | |
*** bethw has quit IRC | 17:21 | |
*** laurence has quit IRC | 17:21 | |
*** laurence has joined #buildstream | 17:23 | |
*** valentind has joined #buildstream | 17:24 | |
*** bethw has joined #buildstream | 17:24 | |
*** jennis has joined #buildstream | 17:25 | |
*** jward has joined #buildstream | 17:25 | |
*** WSalmon has joined #buildstream | 17:26 | |
gitlab-br-bot | jennis opened MR !1599 (jennis/load_deps_consistently->master: Load deps in checkout like we do everywhere else) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1599 | 17:30 |
*** adds68 has quit IRC | 17:33 | |
*** qinusty has quit IRC | 17:33 | |
*** samkirkham has quit IRC | 17:33 | |
*** ikerperez has quit IRC | 17:33 | |
*** Becky has quit IRC | 17:33 | |
*** jennis has quit IRC | 17:44 | |
*** bethw has quit IRC | 17:44 | |
*** jward has quit IRC | 17:44 | |
*** jward has joined #buildstream | 17:46 | |
*** bethw has joined #buildstream | 17:48 | |
*** jennis has joined #buildstream | 17:48 | |
*** phildawson_ has quit IRC | 17:50 | |
*** phildawson_ has joined #buildstream | 17:52 | |
*** traveltissues has quit IRC | 18:07 | |
*** phildawson_ has quit IRC | 18:35 | |
gitlab-br-bot | jjardon opened MR !1600 (jjardon/distutils->master: Use distutils plugin from bst-plugins-experimental) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1600 | 20:09 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!