| *** narispo has quit IRC | 04:44 | |
| *** narispo has joined #buildstream | 04:44 | |
| benschubert | 3482 of 3481 subtasks processed ... I knew Buildstream did too much work but that... :D | 08:01 |
|---|---|---|
| Kinnison | Oh dear :D | 08:02 |
| *** tpollard has joined #buildstream | 08:26 | |
| gitlab-br-bot | aevri opened (was WIP) MR !1652 (aevri/enable_spawn_ci_2->master: jobpickler: also pickle Digest protos) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1652 | 08:29 |
| *** traveltissues has joined #buildstream | 08:34 | |
| *** tiagogomes has joined #buildstream | 08:42 | |
| *** santi has joined #buildstream | 08:47 | |
| *** jonathanmaw has joined #buildstream | 09:01 | |
| *** bochecha has joined #buildstream | 09:30 | |
| *** lachlan has joined #buildstream | 09:35 | |
| *** bochecha has quit IRC | 09:42 | |
| *** bochecha has joined #buildstream | 09:42 | |
| *** narispo has quit IRC | 09:55 | |
| gitlab-br-bot | traveltissues opened MR !1659 (traveltissues/1176->master: workspace.py: close open GRPC channels after import) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1659 | 09:56 |
| traveltissues | will you please check this juergbi | 09:56 |
| *** narispo has joined #buildstream | 09:56 | |
| juergbi | will do | 09:56 |
| traveltissues | ty | 09:56 |
| benschubert | o/ thanks traveltissues ! | 10:07 |
| juergbi | traveltissues: I'll take a quick stab at the CASCacheUsageMonitor fix, or do you want to? | 10:16 |
| traveltissues | i can do that | 10:16 |
| juergbi | ok, ta, I'll leave it then. let me know if anything is unclear | 10:16 |
| ikerperez | Hey, someone knows why buildstream might be struggling to clone the buildstream-abi-checker for a freedesktop-sdk junction? what could be causing that? https://paste.gnome.org/pc5bosuct | 10:16 |
| juergbi | ikerperez: can you paste the .bst file? | 10:17 |
| cs-shadow | the `../buildstream-abi-checker` seem suspect | 10:19 |
| juergbi | indeed | 10:20 |
| benschubert | git relative submodules? | 10:20 |
| coldtom | yes, relative submodules don't play well with the git plugin | 10:20 |
| benschubert | https://gitlab.com/BuildStream/buildstream/issues/1138 | 10:21 |
| coldtom | i think there was recently a patch to git_tag that fixes it | 10:21 |
| coldtom | so try updating bst-external | 10:21 |
| *** bochecha has quit IRC | 10:46 | |
| *** bochecha has joined #buildstream | 10:47 | |
| ikerperez | Updating bst-external didn't work | 10:49 |
| tlater[m] | ikerperez: Usually when I run into these things it's the BuildStream version | 10:50 |
| ikerperez | juergbi https://paste.gnome.org/phff5aqze | 10:50 |
| tlater[m] | Are you building with master? Are you building freedesktop-sdk master? | 10:50 |
| ikerperez | I will try the builstream version | 10:50 |
| coldtom | i would have thought https://gitlab.com/BuildStream/bst-external/merge_requests/103 would have fixed it | 10:51 |
| tlater[m] | ikerperez: For reference, freedesktop-sdk should only be built with bst-1.4 | 10:52 |
| ikerperez | tlater[m] I am building freedesktop 19.08, I didn't know that it has to be build with bst-1.4. I will check if that is the error | 10:53 |
| tlater[m] | ikerperez: bst-1.4 is current stable, freedesktop-sdk to my knowledge is developed with stable. | 10:54 |
| ikerperez | I am on 1.4.1, I guest that version i wrong. I will try to roll back | 10:56 |
| coldtom | ikerperez: 1.4.1 is correct | 10:56 |
| ikerperez | mm | 10:56 |
| tlater[m] | ikerperez: When updating `bst-external`, did you update a pip package or somesuch? | 11:12 |
| ikerperez | no, as far as I know | 11:12 |
| ikerperez | I installed again bs-external, I used pip3 instead of pip, I don't know if that makes any difference | 11:13 |
| * tlater[m] is a bit lost then... Maybe check if the patch coldtom suggested is actually in your local files? | 11:13 | |
| tlater[m] | Hopefully should be in ~/.local/lib/python3.{something}/site-packages/bst-external | 11:14 |
| tlater[m] | If it's not, I'd recommend uninstalling your verison of bst-external and installing the git repository directly (can do something like `pip install git://gitlab.com/buildstream/bst-external.git`, I think) | 11:15 |
| tlater[m] | Oh, it was git+https://<that link> | 11:15 |
| ikerperez | I think it might have something to do with freedesktop, because it happens to be when I update the ref to the latest | 11:27 |
| ikerperez | indeed that is | 11:36 |
| gitlab-br-bot | juergbi opened issue #1177 (Support buildbox-run as sandboxing backend) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1177 | 11:42 |
| ikerperez | this patch is not included in 1.4.1 so I guess that master need to be used | 11:53 |
| cs-shadow | buildstream on python3.8 seems to be failing very consistently to do anything, and I always seem to get `RuntimeError: no running event loop`. Full traceback at: RuntimeError: no running event loop. Any ideas? | 11:57 |
| tpollard | something scheduler related | 12:00 |
| tpollard | does bst show work? | 12:01 |
| cs-shadow | yeah, show/init seems to work | 12:01 |
| tpollard | they don't require the scheduler | 12:01 |
| tpollard | which is where we set our global event loop | 12:02 |
| tlater[m] | cs-shadow: That's an asyncio error | 12:02 |
| tlater[m] | 3.8 introduced changes to that, so... | 12:02 |
| cs-shadow | yeah, I quickly grepped for asyncio in https://docs.python.org/3/whatsnew/changelog.html#id48, didn't see anything immediately obvious. Will continue looking | 12:04 |
| tpollard | something is happening before or after we start/close the loop in scheduler I would suspect | 12:05 |
| tlater[m] | I do remember some hacking around with multiple event loops, I wonder how much of that is still in place | 12:06 |
| gitlab-br-bot | traveltissues opened (was WIP) MR !1651 (traveltissues/1161->master: extend source api and remove private use from workspace plugin) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1651 | 12:13 |
| *** santi has quit IRC | 12:30 | |
| cs-shadow | ah! Seems like `asyncio.get_child_watcher()` is returning a `ThreadedChildWatcher` object in 3.8, whereas a `SafeChildWatcher` in 3.7. Seems like the difference between the two is what's kiiling bst | 12:31 |
| tlater[m] | That's interestingly subtle | 12:33 |
| tlater[m] | Any idea why we mind the exact class name? | 12:34 |
| juergbi | oh, is SafeChildWatcher still available? | 12:34 |
| juergbi | we generally don't want background threads as we use fork without exec | 12:34 |
| tlater[m] | (Assuming the classes didn't change significantly) | 12:34 |
| gitlab-br-bot | traveltissues opened (was WIP) MR !1659 (traveltissues/1176->master: create usage monitor early) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1659 | 12:34 |
| tlater[m] | Oh, right, they are completely different | 12:35 |
| tlater[m] | :| | 12:35 |
| cs-shadow | SafeChildWatcher is still available | 12:39 |
| gitlab-br-bot | traveltissues approved MR !1652 (aevri/enable_spawn_ci_2->master: jobpickler: also pickle Digest protos) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1652 | 12:46 |
| traveltissues | juergbi, will you please take a look at !1651 | 12:55 |
| *** santi has joined #buildstream | 12:59 | |
| gitlab-br-bot | marge-bot123 merged MR !1652 (aevri/enable_spawn_ci_2->master: jobpickler: also pickle Digest protos) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1652 | 13:15 |
| traveltissues | benschubert, i've responded to your requests | 13:16 |
| gitlab-br-bot | BenjaminSchubert approved MR !1659 (traveltissues/1176->master: create usage monitor early) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1659 | 13:22 |
| benschubert | traveltissues: awesome, thanks! | 13:22 |
| traveltissues | ty | 13:22 |
| * tpollard hopes to stop status() creating the cache just to render a worthless widget before execution | 13:25 | |
| benschubert | traveltissues: uh actually, shouldn't we remove the other part were the monitor is created? | 13:27 |
| benschubert | namely https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/_cas/cascache.py#L1047 | 13:27 |
| benschubert | we should not need the if-else anymore :) | 13:27 |
| traveltissues | we could remove it | 13:28 |
| gitlab-br-bot | BenjaminSchubert approved MR !1659 (traveltissues/1176->master: create usage monitor early) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1659 | 13:31 |
| *** akvilebirgelyte has joined #buildstream | 13:43 | |
| *** narispo has quit IRC | 14:05 | |
| *** narispo has joined #buildstream | 14:06 | |
| gitlab-br-bot | juergbi approved MR !1659 (traveltissues/1176->master: create usage monitor early) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1659 | 14:06 |
| juergbi | traveltissues: I've taken a look at !1651 but am still thinking about it. will comment in a bit | 14:08 |
| gitlab-br-bot | MR !1651: extend source api and remove private use from workspace plugin https://gitlab.com/BuildStream/buildstream/merge_requests/1651 | 14:08 |
| persia | Interesting use case I heard about today. Someone is working on a project that depends on projects A and B. Projects A and B both depend on project C, but the junctions are to *different* snapshots of C. For most stuff, it just works, but in the case where something needs be changed on the local project that depends on something in C, is there a good way to specify *which* snapshot of C is preferred? | 14:09 |
| * tpollard has mentioned wanting something similar to this before | 14:10 | |
| * coldtom has hit this before | 14:11 | |
| tpollard | in bitbake world, PREFERRED_PROVIDER/PREFERRED_VERSION can be used for similar scenarios | 14:11 |
| persia | Is there an issue open for it? | 14:12 |
| tpollard | but adding preferences kinda goes against declarative/repeatable to some extent | 14:13 |
| persia | tpollard: Right, but I think "preferred" as a term being assigned to "preferences" is tripping up your analogic brain :) | 14:13 |
| persia | We ought be able to declaratively select a particular resolution to a specific ref for a specific project even through junctions. | 14:14 |
| tpollard | persia: I was referencing it to yocto's implementation of the flag | 14:14 |
| tpollard | which provides a similar utility to what I think we want just not in same implementation | 14:15 |
| persia | tpollard: Yep. My point was that it the word was the issue. If the bitbake implementation were "selected_provider/selected_version", it would look more declarative without significantly affecting the implementation. | 14:15 |
| persia | Anyway, did anyone open an issue in gitlab for this already? | 14:16 |
| benschubert | persia: could you do it with a junction 'target' ? Targeting the version you want for your code? | 14:16 |
| benschubert | in your project have a 'junction-c.bst' that reaches the junction through either A or B | 14:17 |
| persia | benschubert: Not quite, because inheritance is confusing. In the local project, you can target specific refs for A and B, but that gives you duplicate refs for things in C (because A and B both junction into C at different refs). | 14:17 |
| persia | benschubert: So the trick is to identify, in the local project, which resolution for a repo/ref you want for a given element in C. | 14:17 |
| benschubert | for a given element or for all elements? | 14:17 |
| persia | Oh, hrm. Yes, I suppose you can directly junction C into the local project to define the answer. | 14:18 |
| persia | But if A and B selected different C because of some incompatibility that doesn't matter in your local project, it gets more complicated. | 14:18 |
| coldtom | that only really becomes an issue when A and B depend on incompatible versions of C | 14:18 |
| coldtom | snap | 14:18 |
| persia | coldtom: incompatible versions of C that generate artifacts that can be compatible in the local project even (e.g. lots of static compilation or strict adherence to specific ABIs in other ways). | 14:19 |
| coldtom | persia: i meant at element-resolution time | 14:19 |
| benschubert | what I would do in that case is have a 'patch' on one of them that allows me to choose exactlu what I want. Granted it's not an ideal way | 14:19 |
| * persia suspects that most wildly dynamic projects will end up being forced to have common C anyway | 14:19 | |
| persia | benschubert: That might work. I'll share that idea, but yeah, not ideal. | 14:20 |
| * coldtom would like a less hacky way to modify things cross junction | 14:21 | |
| benschubert | coldtom: it's not that hacky, it's like what debian does for source code. They have a series of patch they apply on sources. I see my junctions as sources and patch them when I'm not happy about it :) | 14:21 |
| juergbi | persia: buildstream doesn't allow such conflicting junctions (if they use the same name) | 14:22 |
| coldtom | benschubert: i agree that they should be viewed as sources, but I'd prefer some way to do this in the `junction` element | 14:22 |
| juergbi | persia: bst will error out and you have to resolve it by having a junction to project C in the top-level project | 14:22 |
| benschubert | coldtom: that's what I would do, is have the repo as the first source then a local 'quilt' as a second source :) | 14:23 |
| persia | juergbi: THat was my fear. Thanks for the clear statement. | 14:23 |
| juergbi | persia: if you really want different versions of project C, you can use unique junction names, so there isn't an actual conflict | 14:24 |
| coldtom | benschubert: ah, i've never worked with quilt, i suppose that might reduce the burden of a growing pile of patch files | 14:24 |
| persia | juergbi: How does that affect the junction declarations in A and B, which may not be unique? | 14:24 |
| juergbi | persia: this only works in cooperation with A and/or B | 14:25 |
| juergbi | (or by patching those) | 14:25 |
| juergbi | i.e., the C junctions in A and B need to have different names | 14:25 |
| juergbi | I have a long-standing item on my todo list: make name-based junction coalescing optional, support 'content-based' coalescing | 14:26 |
| juergbi | an idea I had to make this more flexible | 14:26 |
| persia | And that actually addresses everything. When this happens, either convince A and B to junction C with different names, or patch A and/or B to do that locally, and then C doesn't appear as common in the local project. | 14:26 |
| juergbi | but I haven't heard anyone else mention it before so far | 14:26 |
| benschubert | persia: correct! | 14:26 |
| persia | Conceptually simple, syntactically simple, tricky to document. | 14:26 |
| juergbi | patching could be somewhat painful, though | 14:27 |
| juergbi | as you'd have to update all references to the junction to its new name | 14:27 |
| persia | Yes, especially of A or B represents a particularly active development team. | 14:27 |
| juergbi | btw: it is documented, although it might not be clear enough: https://docs.buildstream.build/master/elements/junction.html#nested-junctions | 14:28 |
| persia | juergbi: The incompatible-C case isn't documented, but yes, the documentation is clear on how to do the regular thing, and highlights how to reach into nested juctions for the equivalent of PREFERRED_PROVIDER, which is probably about as far as it makes sense to take that doc. | 14:30 |
| juergbi | right, the possibility to use different junction names is not mentioned | 14:31 |
| *** narispo has quit IRC | 14:54 | |
| *** narispo has joined #buildstream | 14:55 | |
| gitlab-br-bot | aevri opened (was WIP) MR !1654 (aevri/enable_spawn_ci_3->master: pickle `first_pass_config` factories) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1654 | 15:00 |
| *** bochecha has quit IRC | 15:21 | |
| *** santi has quit IRC | 15:43 | |
| *** santi has joined #buildstream | 15:58 | |
| *** narispo has quit IRC | 16:08 | |
| *** narispo has joined #buildstream | 16:08 | |
| *** jonathanmaw has quit IRC | 16:24 | |
| *** jonathanmaw has joined #buildstream | 16:24 | |
| *** akvilebirgelyte has quit IRC | 16:27 | |
| *** narispo has quit IRC | 16:42 | |
| *** narispo has joined #buildstream | 16:44 | |
| *** traveltissues has quit IRC | 16:48 | |
| *** santi has quit IRC | 17:04 | |
| *** narispo has quit IRC | 17:14 | |
| *** narispo has joined #buildstream | 17:14 | |
| *** jonathanmaw has quit IRC | 17:19 | |
| *** tiagogomes has quit IRC | 17:28 | |
| *** narispo has quit IRC | 18:40 | |
| *** narispo has joined #buildstream | 18:40 | |
| *** lachlan has quit IRC | 19:03 | |
| *** lachlan has joined #buildstream | 19:04 | |
| *** lachlan has quit IRC | 19:42 | |
| *** narispo has quit IRC | 19:42 | |
| *** narispo has joined #buildstream | 19:42 | |
| *** lachlan has joined #buildstream | 19:48 | |
| *** lachlan has quit IRC | 20:07 | |
| *** benschubert has quit IRC | 23:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!