| *** Ariana9796 has joined #buildstream | 00:07 | |
| *** Ariana9796 has quit IRC | 00:09 | |
| *** Ariana9733 has joined #buildstream | 00:57 | |
| *** Ariana9733 has quit IRC | 00:59 | |
| *** Madeline5957 has joined #buildstream | 01:13 | |
| *** Madeline5957 has quit IRC | 01:15 | |
| *** Willow3043 has joined #buildstream | 01:18 | |
| *** Willow3043 has quit IRC | 01:20 | |
| *** Camila6711 has joined #buildstream | 01:46 | |
| *** Camila6711 has quit IRC | 01:47 | |
| *** rafaelff1[m] has left #buildstream | 02:45 | |
| *** Savannah5352 has joined #buildstream | 04:21 | |
| *** Savannah5352 has quit IRC | 04:23 | |
| *** Layla8024 has joined #buildstream | 04:47 | |
| *** Layla8024 has quit IRC | 04:48 | |
| *** tristan has quit IRC | 05:43 | |
| *** Eliana5892 has joined #buildstream | 05:44 | |
| *** Eliana5892 has quit IRC | 05:46 | |
| *** tristan has joined #buildstream | 05:50 | |
| *** mohan43u has joined #buildstream | 06:11 | |
| *** aminbegood has joined #buildstream | 06:36 | |
| *** aminbegood has quit IRC | 06:46 | |
| *** Elena5008 has joined #buildstream | 07:09 | |
| *** Elena5008 has quit IRC | 07:11 | |
| *** benschubert has joined #buildstream | 07:20 | |
| *** mohan43u_ has joined #buildstream | 07:31 | |
| *** mohan43u has quit IRC | 07:31 | |
| *** mohan43u_ has quit IRC | 07:33 | |
| *** mohan43u has joined #buildstream | 07:34 | |
| *** Madeline3736 has joined #buildstream | 07:36 | |
| *** Madeline3736 has quit IRC | 07:38 | |
| *** jude has joined #buildstream | 07:43 | |
| WSalmon | philn, i presume you have seen the cargo plugin? https://gitlab.com/BuildStream/bst-external/-/blob/master/bst_external/sources/cargo.py | 07:51 |
|---|---|---|
| philn | WSalmon: yep! | 07:57 |
| WSalmon | philn, cargo is nice as the lock file give you all the deps including the transitive ones, i dont know easy it would be to ask gem for similar info | 07:59 |
| *** ChanServ sets mode: +o tristan | 08:02 | |
| tristan | I'm confused about these two lines: | 08:02 |
| tristan | https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_pluginfactory/pluginfactory.py#L184 | 08:02 |
| tristan | https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_scheduler/jobs/jobpickler.py#L144 | 08:02 |
| tristan | Ahhh right | 08:03 |
| tristan | It's a dictionary of tuples | 08:03 |
| * tristan was hoping to reconcile this `all_loaded_plugins` with the manually kept list `loaded_dependencies` of the plugin factory, which appears to have been added so that the frontend can print this list of loaded plugins | 08:08 | |
| tristan | however, I can see that this reporting isn't very accurate; it only reports the loaded plugins for one project, I wonder how relevant that is | 08:08 |
| *** Melanie5773 has joined #buildstream | 08:16 | |
| *** Melanie5773 has quit IRC | 08:18 | |
| *** tpollard has joined #buildstream | 08:31 | |
| *** Natalie7256 has joined #buildstream | 08:40 | |
| *** Natalie7256 has quit IRC | 08:42 | |
| *** santi has joined #buildstream | 08:50 | |
| *** mohan43u has quit IRC | 09:23 | |
| *** mohan43u has joined #buildstream | 09:24 | |
| *** tpreston has joined #buildstream | 09:34 | |
| tpreston | what's the difference between a stack and a compose element? | 09:34 |
| tpreston | Stack elements are simply a symbolic element used for representing a logical group of elements. | 09:37 |
| tpreston | compose: This element creates a selective composition of its dependencies. | 09:37 |
| tpreston | That sounds like the same thing to me | 09:37 |
| valentind | tpreston, stack has an empty artifact and runtime dependencies. | 09:37 |
| valentind | compose has all files in artifact and no runtime dependencies. | 09:38 |
| tpreston | So if you `bst build stack.bst` you will get nothing? | 09:39 |
| valentind | It will be very quick. | 09:39 |
| valentind | If you do "bst checkout stack.bst --no-deps stack/" then you get no file. | 09:40 |
| valentind | a stack is more like a bunch of dependencies put together. | 09:40 |
| tpreston | ok thanks | 09:47 |
| *** lachlan has joined #buildstream | 09:48 | |
| *** lachlan has quit IRC | 09:58 | |
| *** Chloe7000 has joined #buildstream | 10:00 | |
| *** phildawson has quit IRC | 10:01 | |
| *** Chloe7000 has quit IRC | 10:02 | |
| *** tristan has quit IRC | 10:35 | |
| *** seanborg has joined #buildstream | 10:39 | |
| *** lachlan has joined #buildstream | 10:47 | |
| *** lachlan has quit IRC | 10:53 | |
| scottclarke | has anyone seen the error mentioned in point 2 of this issue before? https://gitlab.com/celduin/infrastructure/celduin-infra/-/issues/173 | 11:14 |
| *** tristan has joined #buildstream | 11:16 | |
| *** gitlab-br-bot has joined #buildstream | 11:21 | |
| *** narispo has quit IRC | 11:29 | |
| *** narispo has joined #buildstream | 11:29 | |
| *** ChanServ sets mode: +o tristan | 11:37 | |
| tristan | benschubert, are you familiar with the PluginSource and pip loading code, around here: https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_pluginfactory/pluginfactory.py#L198 ? | 11:37 |
| tristan | In my refactor, I have it setup such that we create one PluginSource for each plugin instead of doing it twice for the plugin package (once for sources and once for elements) | 11:38 |
| tristan | And I specifically wonder if that would be a concern | 11:38 |
| tristan | The practical tradeoff is that, that whole code block currently runs only once; but that code block *requires* the specific plugin "kind" | 11:39 |
| tristan | If we run it each time, then we get better and more consistent error reporting if a plugin fails to be loaded from pip | 11:40 |
| tristan | This error: https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_pluginfactory/pluginfactory.py#L231 | 11:40 |
| *** mohan43u_ has joined #buildstream | 11:40 | |
| *** mohan43u has quit IRC | 11:40 | |
| tristan | As it stands, if a plugin was already successfully loaded from the same pip origin, we would instead get: https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_pluginfactory/pluginfactory.py#L303 | 11:41 |
| tristan | Also, I'm not entirely sure I trust how we're using setuptools here, we currently assume at this line: https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_pluginfactory/pluginfactory.py#L243 that setuptools might "extract" a file on demand | 11:42 |
| tristan | We make the assumption that extracting one defaults file will cause adjacent defaults files for other plugins as a result, which is not very cool | 11:42 |
| tristan | But, we end up needing to talk to pkg_resources more often, maybe I can pin it to a module level variable and ensure that pkg_resources doesn't even go out of scope after being imported the first time | 11:43 |
| * tristan thinks that importing pkg_resources is the highest risk of performance impact here | 11:44 | |
| *** mohan43u has joined #buildstream | 11:47 | |
| *** mohan43u_ has quit IRC | 11:48 | |
| *** mohan43u has quit IRC | 11:53 | |
| *** mohan43u_ has joined #buildstream | 11:53 | |
| *** aminbegood has joined #buildstream | 12:02 | |
| benschubert | tristan: I'm not super familiar with that part of the code no | 12:03 |
| benschubert | however, are we running this code path once for every plugin or once per element? If for every plugin, I would assume the `pkg_resource` call should be fine | 12:03 |
| tristan | benschubert, once per plugin type | 12:04 |
| benschubert | tristan: that should be fine then I'd expect | 12:04 |
| tristan | once we load the type we're good to go, more elements doesnt cause it to get called more often | 12:04 |
| benschubert | I'm happy to benchmark if you have a branch | 12:04 |
| benschubert | but I expect it should be fine and better error reporting in that area is definitely a big plus | 12:05 |
| tristan | it's `tristan/junction-plugin-origin`, but I'm not 100% sure it's passing all the gates yet | 12:05 |
| benschubert | ok let me know if you need benchmarking of it and when :) | 12:06 |
| tristan | ah yes it is now passing the gates, I'll let you know, maybe better wait a bit | 12:06 |
| tristan | lets wait until adding the final actual junctions thing in | 12:06 |
| * tristan doesnt want to waste any ben cycles | 12:06 | |
| benschubert | haha, sure thanks! | 12:07 |
| tristan | fwiw, I've moved all the pip/local stuff from pluginfactory to pluginorigin, and plan on splitting that up into separate files | 12:08 |
| tristan | so we should have one file with all the knowledge needed about loading plugins from pip | 12:08 |
| tristan | (and the others respectively) | 12:08 |
| benschubert | that seems a good improvement | 12:09 |
| *** seanborg has quit IRC | 12:34 | |
| *** seanborg has joined #buildstream | 12:38 | |
| *** seanborg has quit IRC | 12:39 | |
| gitlab-br-bot | scott.clarke opened issue #1315 (Crash due to AttributeError when using remote execution) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1315 | 12:41 |
| tristan | oooo the bot came back :) | 12:42 |
| *** mohan43u_ has quit IRC | 13:01 | |
| *** mohan43u has joined #buildstream | 13:01 | |
| *** aminbegood has quit IRC | 13:32 | |
| *** mohan43u_ has joined #buildstream | 14:21 | |
| *** mohan43u has quit IRC | 14:21 | |
| *** douglaswinship has joined #buildstream | 14:40 | |
| robjh | are there any examples of the oci image in use? im only able to get it to make containers that dont work | 16:03 |
| jjardon | robjh: fdsdk uses its own OCI images generated with builstream for its CI | 16:07 |
| robjh | jjardon, okay, thanks. found one | 16:08 |
| *** jude has quit IRC | 16:26 | |
| *** misterwhatever has joined #buildstream | 17:04 | |
| *** misterwhatever has quit IRC | 17:05 | |
| *** traveltissues has quit IRC | 17:08 | |
| *** traveltissues has joined #buildstream | 17:08 | |
| *** mohan43u_ has quit IRC | 17:11 | |
| *** santi has quit IRC | 17:11 | |
| *** mohan43u has joined #buildstream | 17:12 | |
| *** santi has joined #buildstream | 17:13 | |
| *** santi has quit IRC | 17:14 | |
| *** xjuan has joined #buildstream | 17:20 | |
| *** cphang has quit IRC | 17:24 | |
| *** cphang has joined #buildstream | 17:25 | |
| tpreston | Is it possible to see how large a bst element is? I'm trying to create a bootable image from a filesystem element, but I need to set my images size to larger than 4G | 17:37 |
| tpreston | Something is too large and I want to find out what | 17:38 |
| tpreston | __populate_fs: Could not allocate block in ext2 filesystem while writing file "libvdpau_gallium.so.1.0.0.debug" | 17:39 |
| tpreston | Hm, debug libs... | 17:39 |
| tpreston | Why are they in there... | 17:39 |
| *** tristan has quit IRC | 17:48 | |
| *** tristan has joined #buildstream | 17:48 | |
| *** toscalix has joined #buildstream | 18:09 | |
| robjh | tpreston, you probably want config:\n exclude: \n - devel | 18:20 |
| tpreston | yep, I deleted it because I didn't know what it meant! | 18:21 |
| tpreston | robjh: in which element? Or all? | 18:21 |
| robjh | in the one defining the filesystem | 18:21 |
| tpreston | Thanks | 18:22 |
| tpreston | config: | 18:22 |
| tpreston | include: | 18:22 |
| tpreston | - runtime | 18:22 |
| tpreston | - locale | 18:22 |
| tpreston | - vm-only | 18:22 |
| tpreston | exclude: | 18:22 |
| tpreston | - devel | 18:22 |
| tpreston | Do I need to specify includes? | 18:22 |
| robjh | i dont think you do. but im unsure | 18:23 |
| robjh | actually, yes | 18:23 |
| tpreston | How do I know which domains to include | 18:26 |
| tpollard | is it that the devel split rule for mesa isn't covering the debug dir? | 18:28 |
| tpollard | https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/19.08/elements/extensions/mesa/mesa.bst#L49 | 18:28 |
| tpollard | ignore the line reference | 18:28 |
| tpreston | tpollard: no I don't have any split rule in my filesystem https://gitlab.com/celduin/bsps/bst-boardsupport/-/blob/tpreston/rpi4-features/sample/rpi4-features/elements/deploy/filesystem.bst | 18:29 |
| tpreston | so it just pulls in everything | 18:29 |
| tpollard | the elements define the split rules, then you can use filters/compose to exclude/include specific domains from the elements | 18:30 |
| tpollard | so you're pulling in everything that every element builds, afaict | 18:30 |
| tpreston | I think so | 18:31 |
| tpreston | So how do I know which domains to put in "include" | 18:31 |
| tpollard | depends on what you're trying to produce I guess | 18:37 |
| tpollard | probably start with what you explicitly want to exclude | 18:38 |
| tpollard | all other split rules will default to be included | 18:38 |
| *** tpollard has quit IRC | 18:54 | |
| *** benschubert has quit IRC | 19:38 | |
| *** narispo has quit IRC | 20:57 | |
| *** narispo has joined #buildstream | 20:57 | |
| *** xjuan has quit IRC | 21:24 | |
| *** tpreston has quit IRC | 21:27 | |
| *** narispo has quit IRC | 22:06 | |
| *** narispo has joined #buildstream | 22:07 | |
| *** mohan43u has quit IRC | 22:38 | |
| *** mohan43u_ has joined #buildstream | 22:38 | |
| *** toscalix has quit IRC | 22:52 | |
| *** toscalix has joined #buildstream | 22:54 | |
| gitlab-br-bot | pointswaves closed issue #1306 (Bad exit from log from RE) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1306 | 22:55 |
| gitlab-br-bot | pointswaves closed issue #1309 (Crash on remote failure try) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1309 | 22:56 |
| pointswaves | It can take a long time for jobs to start running on my remote workers, i presume there are lots of pushing and pulling to be done but i dont really think that should account for the 10-20min for some of the FD-SDK bootstrap elements to strat, the only feedback from bst is that the job is running, would people have apitite have more infomation as a job progresses? i dont know how much the info the remote api gives tho | 23:05 |
| *** aminbegood has joined #buildstream | 23:29 | |
| *** toscalix has quit IRC | 23:46 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!