| gitlab-br-bot | buildstream: merge request (chandan/close-all-workspaces->master: WIP: _frontend/cli.py: Add option to close multiple workspaces) #357 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/357 | 00:09 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (chandan/close-all-workspaces->master: WIP: _frontend/cli.py: Add option to close multiple workspaces) #357 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/357 | 00:23 |
| gitlab-br-bot | buildstream: merge request (chandan/close-all-workspaces->master: WIP: _frontend/cli.py: Add option to close multiple workspaces) #357 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/357 | 00:49 |
| gitlab-br-bot | buildstream: merge request (chandan/close-all-workspaces->master: WIP: _frontend/cli.py: Add option to close multiple workspaces) #357 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/357 | 01:15 |
| gitlab-br-bot | buildstream: merge request (chandan/close-all-workspaces->master: WIP: _frontend/cli.py: Add option to close multiple workspaces) #357 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/357 | 01:51 |
| gitlab-br-bot | buildstream: merge request (chandan/close-all-workspaces->master: _frontend/cli.py: Add option to close multiple workspaces) #357 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/357 | 01:52 |
| *** tristan has joined #buildstream | 04:58 | |
| gitlab-br-bot | buildstream: merge request (tristan/fix-workspace-build-assertions->master: Fix workspace build assertions) #358 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/358 | 06:04 |
| tristan | juergbi, please check https://gitlab.com/BuildStream/buildstream/merge_requests/358 asap | 06:05 |
| tristan | juergbi, that fixes the infamous assertion :) | 06:05 |
| tristan | While I'm at it... maybe I should also remove that pointless `if ...: return` statement which is at the very end of Element._update_state()... | 06:06 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-workspace-build-assertions->master: Fix workspace build assertions) #358 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/358 | 06:16 |
| juergbi | tristan: the change looks sane, calculate_cache_key() will already return None if the cache key of one of the dependencies is still missing | 06:23 |
| juergbi | tristan: the updated test reproduces the issue? does this mean that all non-strict workspace builds hit this? | 06:26 |
| tristan | juergbi, I suppose it means that, I can confirm though that the updated test indeed hits the assertion | 06:29 |
| tristan | definitely tried that | 06:29 |
| juergbi | the pointless return at the end is to keep the code structure in line with the other cache keys. you can remove it if you prefer | 06:29 |
| juergbi | I thought it was something much harder to hit, oh well, thanks for the fix | 06:29 |
| tristan | and tried a build of glade from gnome-build-meta as well as the tests for good measure | 06:29 |
| tristan | I'll leave the return at the end :) | 06:29 |
| * tristan thought it was much harder to hit too | 06:30 | |
| tristan | but I suppose it's proof that our coverage is not all that great | 06:30 |
| tristan | I've hit some other bugs along the way while trying to reproduce | 06:30 |
| juergbi | or that we have too many code paths ;) | 06:30 |
| tristan | looks like tracking on workspaces is breaking | 06:31 |
| tristan | yes, I've been trying to reduce codepaths too, we're not churning enough with addition of features | 06:31 |
| tristan | increasing technical debt as we go along | 06:31 |
| tristan | I've cleaned up some redundant things last weekend at least... have to keep refactoring thing | 06:32 |
| tristan | Also, I would like to have debug flags, similar to GTK_NOTE() | 06:33 |
| gitlab-br-bot | buildstream: issue #316 ("Assertion error when building in non-strict mode") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/316 | 06:34 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-workspace-build-assertions->master: Fix workspace build assertions) #358 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/358 | 06:34 |
| tristan | that could help us collect information when users are able to reproduce something that we cannot easily reproduce | 06:34 |
| tristan | but, maybe overkill for now | 06:34 |
| juergbi | sounds generally useful. yes, depends on how often we have cases that are not obvious to reproduce | 06:35 |
| juergbi | tristan: btw: have you seen my latest FUSE test result? | 06:35 |
| tristan | I saw a message roll by ! | 06:35 |
| tristan | Sounds exciting ! | 06:35 |
| tristan | 6% is... non negligible but... still great ! | 06:35 |
| juergbi | yes but if you can cut down staging time instead, it may be very close | 06:36 |
| tristan | Ahhhh of course ! | 06:36 |
| tristan | We need fuse to be able to do that stage on demand stuff anyway | 06:36 |
| tristan | (or similar solution) | 06:36 |
| tristan | so it could even be a net profit :) | 06:37 |
| tristan | well, depending | 06:37 |
| juergbi | indeed | 06:37 |
| tristan | not for webkit :) | 06:37 |
| tristan | then again, I wonder how much this impacts webkit, which is very CPU intensive | 06:38 |
| tristan | I expect that the performance loss is possibly less | 06:38 |
| tristan | more CPU less I/O... maybe ? | 06:38 |
| juergbi | the impact is larger for heavy parallel build | 06:38 |
| tristan | ...heavy parallel builds which write a lot of small object files, I would think | 06:39 |
| tristan | ...heavy parallel builds which spend more time processing than writing... different ? | 06:39 |
| juergbi | well, as is right now I've only tested FUSE for the rootfs | 06:39 |
| juergbi | so the object file writing would be irrelevant | 06:39 |
| tristan | Ahh right I see | 06:39 |
| tristan | so this is performance loss due to reading through fuse | 06:40 |
| juergbi | however, I would actually like to see FUSE used for workspace builds to keep the object files (and co.) separate from the pristine workspace sources | 06:40 |
| juergbi | this would allow us to simplify some workspace build aspects | 06:40 |
| tristan | interesting idea | 06:40 |
| juergbi | such as the one we hit in this bug | 06:40 |
| juergbi | btw: this was still with single-threaded FUSE layer | 06:41 |
| juergbi | just making use of all FUSE optimizations | 06:41 |
| juergbi | so we could possibly even further lower the overhead | 06:42 |
| juergbi | and the integration part was still using pyfuse, so that might get slightly faster with the optimized FUSE as well | 06:42 |
| tristan | juergbi, is this still using the python thing ? | 06:42 |
| tristan | or separate C library ? | 06:42 |
| juergbi | no, this is a separate C binary that uses the lower level FUSE interface | 06:42 |
| tristan | The low level C interface is still available in python | 06:43 |
| tristan | Well, C is probably better in this case, but distribution story with that is complicated by this | 06:43 |
| tristan | with pure python we reach all users immediately without pain | 06:44 |
| juergbi | yes, that's indeed an issue. however, one reason for C was also that it will be needed by remote workers which will theoretically be independent of BuildStream | 06:44 |
| juergbi | not sure about the overall distribution story at this point | 06:44 |
| tristan | anyway it sounds promising, technically it doesnt add onerous dependencies either, just the technique is complicated | 06:45 |
| juergbi | btw: did you mean the FUSE class with lower level interface? | 06:46 |
| juergbi | that still corresponds to the higher level C interface (path-based) | 06:46 |
| juergbi | I've also used libfuse 3, not sure how much this makes a difference or whether this would be a dependency issue | 06:46 |
| juergbi | anyway, was just a proof of concept due to the impact on remote execution architecture | 06:47 |
| tristan | juergbi, that is one possibility, but with the fuse.py which we've copied into our repo (the upstream we needed to fork for some multiplatform reason, bsd ? I forget...)... that uses the C library directly from python | 06:48 |
| juergbi | ah, upstream has two modules, fuse.py and fusell.py, the latter is the low level interface that we don't have | 06:49 |
| juergbi | SafeHardlinks was already much slower than bindfs in earlier tests, though, both using the high level interface | 06:51 |
| tristan | right, see buildstream/_fuse/fuse.py | 06:54 |
| tristan | it uses python ctypes | 06:54 |
| tristan | but yeah, it will inevitably be slower | 06:55 |
| tristan | juergbi, from what I recall from reading the underlying C code, there was some problems with how the API is designed wrt syncrhonizing the unmounting, and we need to send it a signal and "trust" | 06:56 |
| tristan | if libfuse 3 fixes that API, that would also be nice :) | 06:57 |
| juergbi | not sure whether anything changed in this regard | 06:57 |
| juergbi | for this test I simply called fusermount -u and let that deal with it | 06:57 |
| tristan | so for now I have to fix tracking on junctions... | 06:59 |
| tristan | looks like we're not saving the result of tracking junctions; I had to actually write the ref into the junction element, even though the project uses project.refs :-S | 06:59 |
| tristan | (talking about too many code paths) | 07:00 |
| *** noisecell has joined #buildstream | 07:05 | |
| gitlab-br-bot | buildstream: merge request (tristan/private-refactor-3->master: More fixes for private symbol policy and code consistency) #359 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/359 | 07:44 |
| *** toscalix has joined #buildstream | 08:07 | |
| *** jonathanmaw has joined #buildstream | 08:09 | |
| gitlab-br-bot | buildstream: merge request (tristan/private-refactor-3->master: More fixes for private symbol policy and code consistency) #359 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/359 | 08:09 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-workspace-printing->master: fix workspace printing) #360 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/360 | 08:36 |
| *** bethw has joined #buildstream | 08:55 | |
| *** dominic has joined #buildstream | 08:56 | |
| gitlab-br-bot | buildstream: merge request (tristan/fix-workspace-printing->master: fix workspace printing) #360 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/360 | 08:59 |
| tristan | tlater, if you're around, after sleeping on it, I think we should retract some of what we discussed yesterday | 09:01 |
| tristan | tlater, while it seems a good idea to stamp out the artifacts at build initialization time such that they are "used now" right away, I fear that this will introduce too much complexity, considering that in some build planning modes, we dont know which artifacts we're going to use *yet* | 09:02 |
| tristan | tlater, unless you have an approach that is very simple... lets not go down that path | 09:02 |
| tlater | tristan: We need to know which elements will be used anyway to ensure we don't remove the artifacts for a single pipeline | 09:16 |
| tlater | Two running instances of buildstream doesn't really change that | 09:17 |
| tristan | tlater, as I understand, that is much more easily discovered along the way, though right ? | 09:17 |
| tlater | That's the question - I wasn't actually aware that the build pipeline might change during the build | 09:17 |
| tristan | I.e. we dont know what artifact cache key we're going to use in the case of non-strict | 09:17 |
| tlater | I went with simply marking both the strong and weak cache keys as "in use" | 09:18 |
| tristan | if we download the weak cache key, we dont know the strong key it contains until it's pulled | 09:18 |
| tristan | hmm | 09:18 |
| tristan | How do you mark the ref as used when you dont yet have the artifact ? | 09:19 |
| tlater | tristan: As juergbi pointed out to me, there's no value in treating them differently anyway | 09:19 |
| tristan | I guess that's just a non-issue | 09:19 |
| tristan | because you dont have it, so it cant be deleted, once you get it and extract it, it will be used | 09:20 |
| tristan | also, I presume you consider that a downloaded artifact might have a ref dating last week | 09:20 |
| tlater | tristan: But it will be created during the build, so the first element that is built might get deleted eventually | 09:20 |
| tlater | tristan: That case I do consider, all artifacts are marked with a new mtime when they're contributed to the cache | 09:20 |
| tristan | alright, if bumping mtime at initialization time is not too complicated, lets keep it in | 09:21 |
| tlater | It's actually really simple :) | 09:21 |
| tlater | I'm just concerned I'm missing a few edge cases now.... | 09:21 |
| tristan | but if we can; lets try to keep artifact cache stuff related things in _artifactcache/ | 09:22 |
| tristan | turning all that hectic stuff that goes on in _pipeline.py at initialization time into a single ArtifactCache.init() call is a general goal | 09:22 |
| tlater | tristan: Most of it is, though perhaps I should include a bit of a refactor in this branch. | 09:25 |
| tristan | if it's not too onerous / dangerous, cleanup of pipeline is a pain point I think | 09:26 |
| tristan | I made a stab at separating all the code which plots out the actual element lists from being tangled with the pipeline commands | 09:27 |
| tristan | but I got side tracked and it's dead now | 09:27 |
| tristan | the way except elements works in there is pretty confusing | 09:28 |
| tlater | Yeah, I think except should really be integrated in the original computation | 09:28 |
| tlater | Scheduling algorithms don't tend to have except clauses though, so it's a bit of a unique case | 09:29 |
| tristan | We need a strong set of clear tools for calculating the lists and except intersections; that is probably suitable for Pipeline.py | 09:29 |
| tristan | Then we probably need the "main" stuff that pipeline.py does separately, and fed clear lists; maybe the deps_elements() + except elements stuff could all be worked out using core helpers from cli.py or app.py, before feeding it to the machine which processes them | 09:30 |
| * tristan had something called a PipelineSelection() object, from which another could be created using except elements | 09:31 | |
| tristan | not sure it's the sanest approach, though | 09:31 |
| tristan | jmac, mind if I just push a quick one line fix for benchmarks issue 4 to buildstream master ? | 09:53 |
| tristan | covering it in CI is difficult for now | 09:54 |
| adds68 | Hi, we have encountered an error during a build stage for glib-network | 09:55 |
| adds68 | I'm wondering if this has been seen before by anyone here | 09:55 |
| adds68 | " _lzma.LZMAError: Corrupt input data" | 09:55 |
| adds68 | Build log for more context: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/60932982 | 09:55 |
| gitlab-br-bot | buildstream: merge request (jmac/performance-ci->master: Add benchmark to CI test and document CI.) #341 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/341 | 09:57 |
| tristan | adds68, what is the tarball name ? | 09:58 |
| tristan | adds68, and is this a duplicate of https://gitlab.com/BuildStream/buildstream/issues/338 ? | 09:59 |
| adds68 | tristan, url: https://download.gnome.org/sources/glib-networking/2.54/glib-networking-2.54.1.tar.xz | 09:59 |
| tristan | ok, so it's not an lzip, it looks like dup of 338 | 09:59 |
| tristan | adds68, check the file size in your cache, I suspect it is unreasonably small | 10:00 |
| jmac | tristan: No objections (if it's not already done) | 10:00 |
| tristan | jmac, done, commented on benchmarks issue :) | 10:00 |
| adds68 | tristan, why would it being small, cause such an error? | 10:02 |
| tristan | adds68, did you read 338 ? | 10:02 |
| adds68 | tristan, yes, but it isn't clear as to why the size is important | 10:03 |
| tristan | jmac, I should just point out, that running buildstream on a system without user namespaces is only marginally supported; artifacts from such systems are untrusted and should not be shared as I understand | 10:03 |
| adds68 | Unless it relates to the failure to download the complete file? | 10:04 |
| tristan | jmac, which means, it's probably not ideal to be running benchmarks without proper support | 10:04 |
| tristan | adds68, right | 10:04 |
| jmac | tristan: OK, good to know - I don't know why we run without namespace support tbh | 10:04 |
| adds68 | tristan, ack, cheers | 10:04 |
| tristan | adds68, what I suspect is that, the file was first downloaded and then cached in your source cache, and then tracking it a second time downloaded just the response that the etag was correct and there was no need to redownload, then we serialize that response into a file and call it a tarball | 10:05 |
| tristan | palmface! | 10:05 |
| tristan | anyway, needs investigation, I am only aware of it since this morning | 10:05 |
| adds68 | tristan, haha, brilliant, at least it's been made aware | 10:06 |
| tristan | we could really use a local http server like I think we do for the artifact push/pull tests, to test our source fetching/tracking :-/ | 10:08 |
| tristan | currently we use file:// urls across the board | 10:08 |
| adds68 | tristan, could you not use something like SimpleHTTPServer? | 10:12 |
| adds68 | tristan, to server those files currently behind those file:// urls? | 10:13 |
| skullman | depends on how conformant you need it to be | 10:13 |
| * skullman has had issues with it in the past | 10:13 | |
| skullman | though it was way more pleasant to hack it up a little to start on an ephemeral port and add a way to report that, than try to get any of the more featureful HTTP servers to start on an ephemeral port | 10:14 |
| tristan | whatever it is, it should probably be the same thing we use for testing the artifact push/pull | 10:20 |
| tristan | but, in this particular case, would be nice to have etag support | 10:20 |
| *** aday has joined #buildstream | 10:22 | |
| * tlater finds this bug unreasonably amusing | 10:30 | |
| tristan | tlater, the tarball thing ? | 10:31 |
| tlater | Yep | 10:31 |
| tristan | I know, I'm rotf | 10:31 |
| tristan | except for the fact that I'm probably going to be the one who has to fix it... | 10:32 |
| tristan | and probably needs to be fixed last week... | 10:32 |
| tlater | Still worth the giggle imo | 10:32 |
| tristan | :) | 10:32 |
| tristan | juergbi, bst show: Error loading pipeline: Subproject fetch needed for junction.bst | 10:32 |
| tristan | juergbi, while reproducing the last thing, I ran into some hurdles reproducing the artifact assertion thing to initially setup the subproject... | 10:33 |
| tristan | now I'm adding test cases for junctioned pipelines to all the frontend tests | 10:33 |
| tristan | juergbi, so I'm thinking maybe it's a good time to consider what are the correct behaviors for all of this... | 10:34 |
| juergbi | ok, sure | 10:34 |
| tristan | I guess this one is sane... but feels a bit weird, maybe we can improve that message with something more helpful ? | 10:34 |
| juergbi | i.e., mention how to explicitly fetch? makes sense | 10:35 |
| tristan | for bst show, we have --downloadable for refreshing the downloadable state | 10:35 |
| gitlab-br-bot | buildstream: merge request (jjardon/getting_started->master: Add getting started section) #323 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/323 | 10:36 |
| tristan | so I'll add a suggested command there, and we probably also want to distinguish between whether the junction also is missing a ref | 10:37 |
| tristan | juergbi, while refactoring initialization, I notice some commands do automatically fetch the subprojects as a part of initialization... that would be build I guess ? perhaps also fetch and track ? | 10:37 |
| tristan | juergbi, I'll just go over the whole thing and lets take another look together in review | 10:38 |
| juergbi | yes, Context has fetch_subprojects parameter | 10:38 |
| juergbi | we discussed this initially | 10:38 |
| juergbi | so we didn't want to do implicit fetching for commands that are normally expected to complete quickly / the user is waiting on | 10:39 |
| juergbi | but anything that spins up a pipeline should just implicitly fetch | 10:39 |
| tristan | that sounds reasonable to me indeed | 10:40 |
| tristan | we might still want to change it | 10:41 |
| tlater | skullman: I think your hanging tests fail because of this: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/sandbox/_mounter.py#L101 | 10:41 |
| tlater | Specifically, I think that because _signals.terminator will only catch a certain set of exceptions, and the function executed under it is a context manager and therefore can practically throw any python exception, we can end up never calling cls._unmount. This is makes debugging hard, because instead of an exception you end up with a stuck child process. | 10:41 |
| tristan | i.e. if the user git clones a project with subprojects and starts with `bst show`, the first time - it might be more generous to do things automatically | 10:41 |
| * tlater just hasn't been able to prove that that is the problem for lack of priority :| | 10:42 | |
| juergbi | yes, the current behavior may not be ideal | 10:48 |
| juergbi | maybe we should rather make it easy to abort the fetching if it takes a while? not sure | 10:48 |
| tristan | interesting | 11:08 |
| tristan | juergbi, looks like the source(s) for a junction are never added to the junction element ? | 11:09 |
| tristan | hmmm, I'll find these things out as I go along, seems though that we have a lot of separate code paths here | 11:09 |
| tristan | probably the root cause for workspaced junctions not working | 11:10 |
| juergbi | as they are already used as part of the loader, there are definitely some differences to regular elements | 11:13 |
| juergbi | maybe we can streamline it a bit | 11:14 |
| *** tiago has quit IRC | 11:56 | |
| *** tiago has joined #buildstream | 12:06 | |
| skullman | tlater: ah, I see what you meant now. I'll have a prod at that. | 12:13 |
| tlater | tristan: About our node get function: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_yaml.py#L328 | 12:26 |
| tlater | It's definition means that setting default_value to 'None' means that buildstream will error out, which is annoying to call into | 12:26 |
| tlater | Apparently the default way of handling this sort of case is to use a "sentinel": https://stackoverflow.com/questions/13287887/using-none-as-parameter-to-keyword-argument | 12:27 |
| tlater | Could we do that? It's annoying me to work around this every time I need a default value to be None | 12:27 |
| tristan | None is None | 12:40 |
| tristan | Explicitly setting things to None is normally meaningless | 12:40 |
| * tristan looks | 12:41 | |
| tlater | tristan: The point is that sometimes you want to use None as a meaningful value, and unfortunately our node_get doesn't allow that atm | 12:41 |
| tristan | Right | 12:42 |
| tlater | My current predicament is that I want a cache-quota, but that cache-quota might be unset | 12:42 |
| tlater | So now I have to try except and work with LoadError to get that | 12:42 |
| tristan | So we use self.node_get(... default='') or None | 12:42 |
| tlater | That's ugly in cases where you want a string... | 12:42 |
| tristan | tlater, it looks like an API compatible change to me | 12:42 |
| tristan | tlater, if you want to do it, I want you to give me a branch which changes our usage of it across the code base. | 12:43 |
| tlater | Yep, that makes sense | 12:43 |
| * tlater considers spending a few minutes searching through the codebase while waiting for tests | 12:43 | |
| tristan | there are probably not too many cases to update in upstream; I'd hazard a guess of well under 50 lines, limited to about 5 or 10 files | 12:47 |
| gitlab-br-bot | buildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/317 | 12:47 |
| tristan | you'd want to catch them at both levels, where project & context use _yaml internal API directly, and plugins use the public Plugin.node_get() accessor | 12:48 |
| tristan | and maybe Element.node_subst() also | 12:48 |
| tristan | sounds like a generally nice improvement though | 12:48 |
| tristan | tlater, there might be a docstring with an example sitting around in element.py and/or plugin.py to update for that too | 12:49 |
| gitlab-br-bot | buildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/317 | 12:49 |
| tlater | Ah, that would explain how it caught on | 12:49 |
| tlater | I'll keep an eye out for it | 12:49 |
| tristan | Not sure if anyone has been looking at those docs :) | 13:02 |
| tristan | It caught on mostly from looking at the code for examples I would expect | 13:02 |
| *** xjuan has joined #buildstream | 13:07 | |
| paulsherwood | if i want to setup a new ci pipeline for a buildstream project, is there a recommended default docker image to use? | 13:11 |
| *** aiden has quit IRC | 13:12 | |
| *** aiden has joined #buildstream | 13:13 | |
| tlater | paulsherwood: The recommendation will be the flatpak-sdk as soon as that becomes available - for the time being, if you're aiming to build a project that wants to use the x86image, there's buildstream/image-tools | 13:14 |
| paulsherwood | tlater: ok i'll try that, thanks | 13:15 |
| tlater | paulsherwood: As a word of warning, that image uses alpine and hence busybox/musl, so it might not work with all projects | 13:16 |
| tristan | tlater, I dont think you and paulsherwood are talking about the same things | 13:17 |
| tristan | apples and oranges | 13:17 |
| tlater | Oh, whoops | 13:17 |
| tlater | Yeah, you're right tristan | 13:17 |
| tristan | tlater, I suspect we are talking about a docker image to run buildstream on, like for gitlab | 13:17 |
| * tlater misread, nevermind me | 13:17 | |
| tristan | paulsherwood, buildstream/buildstream-fedora:master-56-5d7ee17 is probably good, or buildstream/buildstream-fedora:latest | 13:21 |
| tristan | paulsherwood, the former is the last specific version we were using in CI before downgrading python, the later is a "latest" tag which is automatically updated | 13:22 |
| tristan | paulsherwood, they are both generated from: https://gitlab.com/BuildStream/buildstream-docker-images | 13:22 |
| tristan | a separate project whos' purpose in life is to generate such supporting docker images | 13:22 |
| tristan | a separate repo, rather | 13:22 |
| tristan | note, those above strings I mentioned are both appropriate for "image: " in a .gitlab-ci.yml file | 13:24 |
| paulsherwood | tristan: correct, thanks | 13:28 |
| tlater | tristan: Hm, I think the node_get change is going to be a bit harder, some of the plugins seem to rely on something treating '' as None and I can't find it | 13:30 |
| gitlab-br-bot | buildstream: merge request (tristan/junction-fixes-and-tests->master: junction fixes and tests) #361 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/361 | 13:30 |
| paulsherwood | hmmm.... https://paste.baserock.org/amapapihox | 13:30 |
| paulsherwood | that's not a good thing | 13:31 |
| tristan | paulsherwood, that was fixed this morning, and broken yesterday | 13:31 |
| paulsherwood | heh | 13:31 |
| tristan | paulsherwood, it is also an indicator that you are on a host which does not support real user namespaces | 13:31 |
| paulsherwood | so which image do i need? | 13:31 |
| tristan | Hmmm, I wonder if this is a problem with the runner, not the image | 13:31 |
| paulsherwood | in the real world i don't get to control which kernel runs on my ci environment | 13:32 |
| tristan | user namespaces need to be in the kernel | 13:32 |
| paulsherwood | that's a bug, then | 13:32 |
| tristan | I would not agree, it's simply a requirement to provide proper isolation without being root | 13:33 |
| tristan | the real world needs to catch up, then, we have it for our CI, I'm not 100% sure how it's being ensured, though. | 13:33 |
| paulsherwood | so i'm defeated at this point. i'll have to use something else | 13:34 |
| tristan | fwiw, we added that hack specifically for arch linux | 13:34 |
| tristan | We support it, but we cannot say it's trustable without user namespaces on host kernel, I think one of the driving reasons to taint the artifacts (avoid pushing them), is that we can't guarantee build user UID = 0 | 13:35 |
| tristan | which can mean that artifacts can differ depending on what random UID is in use | 13:36 |
| paulsherwood | add a warning, then. | 13:36 |
| paulsherwood | don't crash. | 13:37 |
| jmac | That's what we fixed this morning | 13:37 |
| jmac | It would normally show the warning and continue | 13:37 |
| paulsherwood | ah, ok. so i need to update buildstream/buildstream-fedora:latest ? or get a different image? | 13:38 |
| jmac | I know little about the images, unfortuntaely | 13:40 |
| tlater | paulsherwood: The images are rebuilt every night, I think, it's possible the image hasn't been updated yet. | 13:41 |
| tlater | 8 hours ago is the last one, apparently | 13:41 |
| tlater | paulsherwood: I can trigger the CI for you and rebuild the image, if you like | 13:42 |
| tlater | Might take a little bit to get an updated image though | 13:42 |
| tristan | tlater, does the image include buildstream itself ? (I know next to nothing about the image and docker) | 13:42 |
| tlater | tristan: The fedora one does, yes | 13:42 |
| tristan | I see | 13:42 |
| tlater | It's also used for bst-here | 13:42 |
| tristan | paulsherwood, indeed, that crash is happening *while printing a warning* :) | 13:43 |
| tristan | tlater, so I guess it also has all deps we want for existing plugins (git, bzr, tar...) ? | 13:43 |
| tristan | anyway, I expect it would | 13:44 |
| tlater | tristan: Pretty sure it does, yes | 13:44 |
| tlater | It's why we needed to update all of them when we added that dpkg dependency | 13:44 |
| tlater | Arpy I think? | 13:44 |
| tristan | paulsherwood, jjardon[m] is the whiz kid when it comes to gitlab, I might rather follow his example here: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/blob/master/.gitlab-ci.yml | 13:45 |
| * tlater just double checks that this didn't change since he last looked at the repo and runs the builds again so we have a fresh bst for paulsherwood :) | 13:45 | |
| tristan | Which uses explicit tags and shas to be in control of exactly what is in use | 13:45 |
| tristan | (rather than using "latest" of anything) | 13:46 |
| gitlab-br-bot | buildstream: merge request (tristan/junction-fixes-and-tests->master: junction fixes and tests) #361 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/361 | 13:47 |
| tristan | juergbi, I just merged some fixes for corner cases and a large amount of junction related frontend tests with that above MR, didn't get to streamlining anything regarding loading of elements yet | 13:48 |
| tristan | and I dont think it fixes the workspace issue, but it does fix some other things, specifically project.refs (my fault for having missed some of that) | 13:48 |
| tlater | tristan: This dependency that I want to add for parsing data sizes also happens to have a is_tty() call like blessings | 13:50 |
| tlater | Perhaps we could replace that? I think you mentioned you wanted to get rid of blessings at some point | 13:50 |
| jjardon[m] | paulsherwood: my ArchLinux doesn't have namespaces enabled and bst works fine (tristan fixed that some time ago); if you are using runners with docker you have to run then in privilege mode, but that's a separate problem | 13:51 |
| *** tristan has quit IRC | 13:51 | |
| jjardon[m] | paulsherwood: Is this in a public repo so I can take a look? | 13:51 |
| juergbi | jjardon[m]: It seems Arch kernels have user namespaces enabled these days. They are disabled for non-root by default but if bwrap is installed setuid-root, buildstream can still use them | 13:55 |
| jjardon[m] | juergbi: oh, ok. I alwasy get the "bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'." warning when I try to build | 13:56 |
| paulsherwood | https://paste.baserock.org/aruqowixec | 13:56 |
| paulsherwood | jjardon[m]: i'm on a private ci envonment, that i don't control | 13:56 |
| paulsherwood | that traceback is much longer than my bst file | 13:57 |
| juergbi | jjardon[m]: ah ok, so I guess bwrap is not installed setuid-root on Arch | 13:57 |
| *** jjardon has joined #buildstream | 13:58 | |
| juergbi | paulsherwood: issue with project name with space? | 13:58 |
| juergbi | I thought we added at least detection for this at some point but maybe this slipped | 13:59 |
| *** tristan has joined #buildstream | 13:59 | |
| paulsherwood | really? | 13:59 |
| * paulsherwood is speechless :) | 13:59 | |
| juergbi | just a guess. at least there used to be an issue. don't know whether that's still the case | 14:00 |
| paulsherwood | yes. that 'fixed' it. | 14:01 |
| juergbi | jmac: iirc, you noticed the project or element name with space issue at some point. Did you file an issue? | 14:02 |
| paulsherwood | while we're on, can we properly fix this so that i don't even need to create a project.conf? | 14:02 |
| paulsherwood | just use the name of the bst file if no name found? | 14:03 |
| paulsherwood | fwiw i did try "name with quotes" | 14:04 |
| juergbi | The name of the .bst file would be bad as then you'd get different project names when building different targets | 14:04 |
| juergbi | We could default to the basename of the project directory | 14:04 |
| paulsherwood | ok, that then :) | 14:04 |
| jmac | juergbi: I did, let me check | 14:05 |
| tlater | Is the project name really the only required key? | 14:05 |
| paulsherwood | according to my hello-world experiments, yes | 14:05 |
| juergbi | paulsherwood: It's not a parsing issue. It might be OSTree not supporting spaces in refs at all and we don't do any name mangling (or validation, apparently) | 14:05 |
| juergbi | yes, that's indeed the only one that is really required | 14:05 |
| tristan | juergbi, what is the basename of the project directory, you can git clone or (whatever you used to store your project) to any directory you want, and then move it over to a temporary directory | 14:06 |
| juergbi | In practice I'm not sure how far you'll typically get without anything else | 14:06 |
| paulsherwood | basename of project directory might include spaces... | 14:06 |
| tristan | sounds like just really bad idea and error prone | 14:06 |
| juergbi | tristan: Yes, if you rename it, you have to deal with not being able to reuse the cached artifacts etc. | 14:06 |
| paulsherwood | just put a default name for all unnamed projects? | 14:06 |
| juergbi | Also wouldn't allow per-project user config | 14:07 |
| tlater | tristan: Isn't that equivalent to changing the project name in project.conf? | 14:07 |
| tristan | I rename checkouts of stuff all the time | 14:07 |
| tristan | I wouldnt want that to effect the content of what it was | 14:07 |
| jmac | juergbi: Hmm, no, there doesn't appear to be an issue for it | 14:07 |
| juergbi | We could possibly support unnamed projects | 14:08 |
| *** dominicb has joined #buildstream | 14:08 | |
| paulsherwood | just warn: please name your project, we'll call it "Trevor" for now.... or similar? | 14:08 |
| *** dominicb has quit IRC | 14:08 | |
| juergbi | Not sure whether it'd be worth it | 14:08 |
| tristan | it's a possibility, and an invitation to namespace clashing | 14:08 |
| paulsherwood | juergbi: it's worth it to remove this friction for new driveby user | 14:08 |
| juergbi | With a persistent warning, it seems fine with me | 14:09 |
| juergbi | Would be easy to add and reduce the starting hurdle | 14:09 |
| paulsherwood | +1 | 14:09 |
| tristan | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_artifactcache/artifactcache.py#L142 <-- should really be avoiding the space causing a crash | 14:10 |
| tristan | space is not a letter or a digit | 14:10 |
| juergbi | tristan: it only does that for element name, not project name... | 14:11 |
| tristan | ahhh | 14:11 |
| gitlab-br-bot | buildstream: merge request (cmake-ninja->master: WIP: plugins/elements/cmake.yaml: allow using ninja instead of make (#279)) #362 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/362 | 14:11 |
| * tristan is at end of day and last time I hung out, chicken place was sadly closed | 14:11 | |
| tristan | I'll fix it later unless tlater or juergbi or someone beats me to the punch... | 14:12 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 14:13 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 14:14 |
| gitlab-br-bot | buildstream: issue #339 ("Can't use project names with spaces in") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/339 | 14:18 |
| jmac | Raised https://gitlab.com/BuildStream/buildstream/issues/339 to cover the project name with spaces issue | 14:19 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 14:21 |
| gitlab-br-bot | buildstream: issue #340 ("If no project name found (eg because no project.conf) set it to a default, with a warning") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/340 | 14:26 |
| gitlab-br-bot | buildstream: merge request (unused-workspaces->master: _pipeline.py: correct reporting of unused workspace) #363 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/363 | 14:29 |
| gitlab-br-bot | buildstream: merge request (unused-workspaces->master: _pipeline.py: correct reporting of unused workspace) #363 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/363 | 14:44 |
| *** ernestask has joined #buildstream | 14:50 | |
| tristan | thanks jmac | 14:51 |
| tristan | while walking to the chicken place and back, I had a thought that, a nicer way to deal with absent project.conf, is an interactive session which is triggered when bst is invoked which creates one if it is absent | 14:52 |
| tristan | then we ask only a few questions with sane defaults, and at least get the user to decide on a name (sane default for required format version would be the current format version, and recommend storing elements in an elements/ subdirectory) | 14:53 |
| tristan | seems like an easy user friendly way of handling lack of project.conf | 14:53 |
| tlater | Ah, going the npm route | 15:04 |
| tristan | there are a few tools I've seen do that, some of them more pleasant to use than others | 15:07 |
| tristan | but I think if we keep it down to 3 questions, with only project name asking for a specific value, it will be more pleasant than annoying | 15:08 |
| tristan | along with an initial question of course "BuildStream has not detected a project in the directory: ... Would you like to create one here ?" | 15:08 |
| * tlater agrees, this is a neat way to get new users bootstrapped too - it's actually one of the few features about npm I somewhat like :) | 15:08 | |
| tlater | Though npm does go way too far with the initial bootstrapping. | 15:09 |
| tristan | I've on the other hand witnessed some very long sessions which made me want to give up | 15:09 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 15:19 |
| paulsherwood | tristan: what if user is CI ???? | 15:19 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 15:20 |
| * paulsherwood doesn't like the 'interactive session' idea **at all** | 15:21 | |
| tlater | paulsherwood: We already have a bit of interactiveness buildstream - there's a --no-interactive flag, and buildstream automatically disables interactiveness when appropriate. | 15:22 |
| tlater | I'm guessing we'd still go with a default name in that case? | 15:22 |
| *** noisecell has quit IRC | 15:24 | |
| * paulsherwood hopes so | 15:24 | |
| paulsherwood | what is --no-interactive set to by default? | 15:24 |
| persia | --no-interactive is not set by default | 15:25 |
| paulsherwood | :/ | 15:25 |
| persia | The idea being that it isn't hard to add to a script for non-interactive stuff, but humans would get annoyed having to type --interactive all the time. | 15:25 |
| jmac | It will also set no-interactive if stdout is not a terminal, which is common to a lot of unix utilities | 15:25 |
| juergbi | yes, so it should typically do the right thing by default | 15:26 |
| paulsherwood | oh, ok. | 15:26 |
| tlater | Does that get set in paulsherwood's CI case though? I suppose it depends on what the CI tool does. | 15:27 |
| juergbi | if no stdin is connected, we should do the right thing | 15:27 |
| juergbi | and I don't expect CI to connect stdin | 15:27 |
| juergbi | otherwise I consider this a bug | 15:28 |
| juergbi | I like the interactive setup, as long as it's kept really short. Maybe not even ask about the format version, just set it (+ print a message). | 15:28 |
| persia | Most CI systems I've seen do connect stdin: they just never send anything over it. | 15:28 |
| juergbi | sounds odd, but whatever the details, I believe BuildStream's autodetection works so far | 15:29 |
| persia | (there are too many things that break trying to open stdin, even if they don't need any content from it) | 15:29 |
| juergbi | I would have expected /dev/null | 15:29 |
| persia | That might be true at the origination point, but once you get into orchestration, often there are needs for "interactive" articulation points. | 15:31 |
| persia | For example, if I have a CI tool that instantiates a system, makes an ssh connection to the system, and runs some commands, <stdin> is defined from the perspective of the commands being run, even if the CI tool has /dev/null as <stdin> | 15:32 |
| juergbi | right but you should still immediately get EOF when trying to read from stdin, afaict | 15:35 |
| *** bethw has quit IRC | 15:47 | |
| tristan | How would you be a fly by user creating a project for the first time, ... in CI ? | 15:57 |
| tristan | paulsherwood, the great part of the solution, is that it *forces* the user to choose a project name, without them hitting the problem of not having a project.conf | 15:58 |
| persia | tristan: Generally a first-time-project in CI would indicate a bug :) | 16:04 |
| tristan | To be clear: Defaulting to a hard coded project name is undesirable becuase the whole point of a project name is to distinguish multiple projects from eachother | 16:08 |
| tristan | Having a default project name is an invitation for users to ignore that, which will be a cause for greater headaches down the road | 16:09 |
| tristan | So, I'm trying to get to the bottom of this dislike of project names and project.conf in general; project.conf is an essential part of the source code of a buildstream project; as it stands, you dont have a project if you dont have a project.conf, even if the only _mandatory_ thing you must declare there is a name, it's very undesirable to not have one | 16:11 |
| tristan | so we would do better to educate the user of it's usefulness early on, than to invite the user to ignore it | 16:11 |
| tristan | for instance, the default for the format-version is always 0, it's quite undesirable to not set that to a number, unless you *really* only use features available in format 0 | 16:12 |
| tristan | not setting format-version, but using features not available in format 0, means people who build your project, will not get a helpful abort at startup, but instead an error that such-and-such is an invalid YAML key | 16:13 |
| * paulsherwood will wait and see :) | 16:13 | |
| gitlab-br-bot | buildstream: merge request (jennis/136-expire-remote-cache-artifacts->master: WIP:136 expire remote cache artifacts) #364 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/364 | 16:22 |
| jmac | I have a bit of a mystery with the artifact cache here | 16:23 |
| jmac | I've populated a remote cache by doing one build, then wiped the local ostree and ran the build again | 16:24 |
| jmac | buildstream says it's downloaded all the artifacts and finished the build in 30 seconds | 16:24 |
| jmac | But there's nothing in the https-server logs saying anything has been requested | 16:24 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 16:24 |
| jmac | Everything is 404s, e.g. 10.24.4.120 - - [05/Apr/2018 17:07:29] "GET /artifacts/objects/d2/b65a78c4ab97ae6e6d625e09e634b4105f2f5304765dee59a84ab70304c62c.commitmeta HTTP/1.1" 404 | 16:25 |
| jmac | So where is my local BuildStream instance getting the artifacts from? | 16:25 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 16:25 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 16:29 |
| tristan | jmac, good question: https://gitlab.com/BuildStream/buildstream/issues/275 | 16:31 |
| tristan | jmac, I might guess that you might have one configured in your ~/.config/buildstream.conf | 16:32 |
| jmac | Nope, no ~/.config/buildstream.conf. It's a new server I set up today so very unlikley to be in any old configuration files. | 16:34 |
| tristan | so the project declaring the elements is the one who defines it, but if you have junctions going on, then it can be downloading from multiple places | 16:36 |
| tristan | we really need easy to fix 275 fixed | 16:36 |
| tristan | then we could look at it and clearly see: Does what we did here really make sense ? | 16:36 |
| jmac | Well I'm about to do that locally so I'll make it into a merge request if I find out | 16:37 |
| tristan | thanks :) | 16:37 |
| jmac | The URL is ultimately composed by OSTree itself though, not by BuildStream | 16:38 |
| tristan | there is also multiple artifact caches configured for a single project as a possibility, I clearly recall the use case for it, but cannot vouch for it having been implemented exactly that way | 16:38 |
| tristan | Oh *that*, is annoying, but on the BuildStream side of things... I would say that it's sensible to trust the artifact server and just print the ssh url if an ssh url is configured | 16:39 |
| *** toscalix has quit IRC | 16:39 | |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 16:39 |
| tristan | jmac, I think the usual case is that a project is configured with https URLs (because everyone has read access), and ssh URLs usually only go into a buildstream.conf file (the few who have push access) | 16:40 |
| tristan | but not every case is usual | 16:40 |
| *** dominic has quit IRC | 16:41 | |
| jmac | That's the case I have, anyway | 16:42 |
| tristan | I supposed its sensible for a concentrated work group or proprietary project indeed (to have all users use the ssh protocol and manage their access rights centrally) | 16:49 |
| tristan | not really designed for security though | 16:50 |
| tristan | (no prevention of a user using an https url if that one is available on the internet) | 16:50 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 17:07 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 17:09 |
| *** jonathanmaw has quit IRC | 17:19 | |
| * paulsherwood wonders if anyone has used bst to create cloud-style things yet? e.g. kubernetes infra | 17:24 | |
| tristan | paulsherwood, possibly that guy brejoc who wanted a solution for building web frameworks on docker many months ago; we should probably have a docker image creating element for that sort of thing | 18:00 |
| paulsherwood | tristan: ack | 18:01 |
| paulsherwood | i'm guessing i could start from a baserock system if i want to roll my own? | 18:02 |
| paulsherwood | (i.e. using buildstream) | 18:02 |
| tristan | I dont see what would be complicated about rolling out images, it's just a question of understanding the delivery/distribution format of the thing | 18:02 |
| tristan | similarly to flatpaks, I presume it might involve adding some special metadata files | 18:03 |
| gitlab-br-bot | buildstream: issue #341 ("argument path resolution is illogical") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/341 | 18:13 |
| gitlab-br-bot | buildstream: issue #342 ("Provide a way to initialize a new project") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/342 | 18:14 |
| jjardon[m] | docker images are now defined in a open spec, so other tools can create them: https://github.com/opencontainers/image-spec | 18:24 |
| jjardon[m] | probably better to tell bst to call external tools though, intead reimplement everything | 18:25 |
| jjardon[m] | similar to what packer does: https://www.packer.io/docs/builders/docker.html | 18:26 |
| gitlab-br-bot | buildstream: issue #343 ("initial cache-key resolution should display whole key, not just a short SHA") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/343 | 18:50 |
| jjardon[m] | Is anyone here aware of any change from 1.0.x to 1.1.x that could make the conversion scripts to break? https://gitlab.com/BuildStream/defs2bst/issues/2 | 18:52 |
| *** Prince781 has joined #buildstream | 18:58 | |
| *** Prince781 has quit IRC | 19:00 | |
| tristan | jjardon[m], we should be compatible with 1.0.x, if anything has broken, it may have been user configuration about artifact caches, which I think was communicated pretty clearly at the time of the 1.0 release | 19:06 |
| jjardon[m] | tristan: we are using 1.0.x; it breaks when we try to use 1.1.2 | 19:08 |
| tristan | maaaybe we screwed up, but lets see what those incompatibilities are, and see if we should address them in bst rather than the conversion | 19:08 |
| tristan | jjardon[m], exactly, 1.0.x is supposed to be stable; so if 1.1.x doesnt work with 1.0.x, that is a failure | 19:08 |
| tristan | there may be some failure, but lets see what they are before deciding to call it a problem with the conversion script | 19:09 |
| jjardon[m] | yeah sure: there is a full log of the failure in the issue I opened above | 19:10 |
| tristan | I only saw a successful conversion log | 19:10 |
| tristan | not a build log where bst fails on the converted result | 19:10 |
| jjardon[m] | tristan: oh sorry, copied the wrong link | 19:13 |
| jjardon[m] | fixed now | 19:13 |
| tristan | oh that is weird, it looks like it's the defs2bst that's breaking | 19:23 |
| tristan | jjardon[m], maybe it tries to use buildstream internals | 19:24 |
| tristan | then it would be defs2bst indeed which would have to be fixed | 19:24 |
| tristan | I dont see buildstream in the stack trace though | 19:24 |
| tristan | jjardon[m], maybe something besides buildstream changed ? ruamel.yaml ? | 19:25 |
| tristan | or maybe the stuff being converted changed near the same time, and you hit something not well supported | 19:25 |
| jjardon[m] | I have just run exactly the same commit but with bst 1.0.1 and the conversion works | 19:27 |
| * jjardon[m] goes for dinner, will dig more later | 19:27 | |
| tristan | strange, I dont see how buildstream version can effect that off the bat, but requires investigation | 19:28 |
| tristan | and not at 4:30am :) | 19:28 |
| paulsherwood | :) | 19:28 |
| *** Prince781 has joined #buildstream | 19:52 | |
| *** ernestask has quit IRC | 20:35 | |
| *** aday has quit IRC | 20:38 | |
| *** valentind has quit IRC | 20:39 | |
| *** valentind has joined #buildstream | 20:40 | |
| *** valentind has quit IRC | 20:45 | |
| *** valentind has joined #buildstream | 20:45 | |
| *** Prince781 has quit IRC | 20:46 | |
| *** valentind has quit IRC | 20:49 | |
| *** valentind has joined #buildstream | 20:49 | |
| *** Prince781 has joined #buildstream | 20:51 | |
| *** Prince781 has quit IRC | 20:55 | |
| *** valentind has quit IRC | 21:00 | |
| *** valentind has joined #buildstream | 21:00 | |
| *** valentind has quit IRC | 21:05 | |
| *** valentind has joined #buildstream | 21:06 | |
| *** jsgrant has joined #buildstream | 21:18 | |
| *** jsgrant has quit IRC | 21:20 | |
| *** xjuan has quit IRC | 22:33 | |
| *** mohan43u has quit IRC | 22:47 | |
| *** mohan43u has joined #buildstream | 22:51 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!