| *** mcatanzaro has quit IRC | 00:00 | |
| *** tristan has joined #buildstream | 01:37 | |
| hergertme | are there any plans to make something like `mkosi'? | 01:44 |
|---|---|---|
| tristan | hergertme, there is so far only the x86image plugin http://buildstream.gitlab.io/bst-external/bst_external.elements.x86image.html#module-bst_external.elements.x86image | 01:47 |
| tristan | which draws some inspiration from wic (yocto's thing, similar to mic) | 01:48 |
| hergertme | tristan, cool, that looks interesting | 03:55 |
| *** jude has joined #buildstream | 08:48 | |
| *** bethw has joined #buildstream | 08:57 | |
| *** adds68_ has quit IRC | 09:21 | |
| *** adds68 has joined #buildstream | 09:26 | |
| *** adds68 has quit IRC | 09:28 | |
| *** adds68 has joined #buildstream | 09:28 | |
| *** bochecha has quit IRC | 09:43 | |
| *** bochecha has joined #buildstream | 09:43 | |
| *** bochecha_ has joined #buildstream | 09:44 | |
| *** bochecha has quit IRC | 09:47 | |
| *** bochecha_ is now known as bochecha | 09:47 | |
| gitlab-br-bot | buildstream: merge request (workspaces-yml-version-1->master: WIP: Add support for version 1 workspaces.yml format) #176 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/176 | 09:55 |
| *** ssam2 has joined #buildstream | 10:09 | |
| gitlab-br-bot | buildstream: merge request (unused-vars-refactor->master: Refactor, removing unused variables) #177 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/177 | 10:56 |
| ssam2 | i'm really overjoyed that the multiple cache support tests pass locally but fail in CI | 12:11 |
| ssam2 | oh, haha maybe it's my uncommited changes that are to blame :-) | 12:11 |
| gitlab-br-bot | buildstream: merge request (sam/multiple-caches->master: WIP: multiple remote cache support) #166 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/166 | 12:11 |
| *** bochecha has quit IRC | 12:17 | |
| *** bochecha has joined #buildstream | 12:19 | |
| *** tristan has quit IRC | 12:32 | |
| *** bochecha has quit IRC | 12:43 | |
| *** bochecha has joined #buildstream | 12:44 | |
| *** bochecha has quit IRC | 12:48 | |
| *** bochecha has joined #buildstream | 12:49 | |
| bochecha | is there a way to tell BuildStream to ignore some files in a source tree? | 14:03 |
| bochecha | I'm using the following to build an app from its git tree: | 14:04 |
| bochecha | sources: | 14:04 |
| bochecha | - kind: local | 14:04 |
| bochecha | path: . | 14:04 |
| bochecha | but then if I just open a source file in vim, that creates a .swp file, bst sees the new file and thinks I need to rebuild the app | 14:04 |
| ssam2 | using the workspaces feature ? | 14:05 |
| ssam2 | currently not, I think ... | 14:05 |
| tlater | ssam2: Would have the same result, because vim would create a file in the workspace, which buildstream would then find. | 14:05 |
| ssam2 | i think i wasn't clear :-) | 14:06 |
| ssam2 | i'm guessing bochecha is using workspaces, and saying if so, there's no way to tell buildstream to ignore certain files when deciding whether a rebuild is needed | 14:06 |
| ssam2 | a specific workaround would be to configure vim not to put its swap files in the current directory | 14:07 |
| ssam2 | i have vim configured to put things in ~/tmp, because i've had other issues in the past from it dumping files in places i didn't want it to | 14:07 |
| ssam2 | https://stackoverflow.com/questions/1636297/how-to-change-the-folder-path-for-swp-files-in-vim#21026618 for example | 14:08 |
| ssam2 | for a general fix, we have been debating involving source plugins in workspaces | 14:09 |
| ssam2 | which would be an optimisation only | 14:09 |
| gitlab-br-bot | buildstream: merge request (tracking-changes->master: Tracking changes) #119 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/119 | 14:09 |
| gitlab-br-bot | buildstream: merge request (tracking-changes->master: Tracking changes) #119 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/119 | 14:09 |
| ssam2 | but if we did this, and we delegated the decision on whether to rebuild to Git, and required that the user `git add` any new files that they cared about ... then we could reuse .gitignore for this | 14:09 |
| ssam2 | assuming your workspace is for a project stored in Git, which i'm 90% sure it will be | 14:09 |
| ssam2 | but anyway, i think short answer is: no | 14:10 |
| gitlab-br-bot | buildstream: merge request (tracking-changes->master: Tracking changes) #119 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/119 | 14:12 |
| bochecha | ssam2: I'm not using workspaces, no | 14:13 |
| ssam2 | ah, right yeah I didn't read you properly | 14:14 |
| ssam2 | same answer, though | 14:15 |
| bochecha | I haven't had time to look into workspaces yet though, maybe I should | 14:15 |
| ssam2 | yes, i think the "right" way to do this is workspaces | 14:15 |
| ssam2 | in practice, i think you don't gain anything at present | 14:15 |
| bochecha | I wish there as a .bstignore, with a similar syntax to .gitignore :P | 14:15 |
| ssam2 | but there is ongoing work on making incremental builds work from a workspace | 14:15 |
| ssam2 | so in future there will be a benefit to switching :-) | 14:15 |
| ssam2 | it's pretty simple too; you just do `bst workspace open ./my-element.bst ./workspace-dir` | 14:16 |
| ssam2 | all the app code ends up in workspace-dir and you can hack on it there | 14:16 |
| ssam2 | and assuming it's a git repo, it'll be a proper git clone | 14:16 |
| tlater | ssam2: You would have to adjust the bst element to load from a local git repo though, would that be as simple as setting the url to a local directory? | 14:16 |
| persia | My worry about the potential for .bstignore is that folk might want to put things in it that change often, but end up being important to build (as is often done with git). Files in .gitignore just end up getting rebuilt on clone (or people get fussy), but files in ,.bstignore would break the link between "this is changed" and "this is not changed". | 14:16 |
| ssam2 | tlater, ?? | 14:17 |
| * tlater assumes bochecha is building from a local project | 14:17 | |
| ssam2 | ah I see what you mean | 14:17 |
| bochecha | ssam2: and I can git push in that repo, the remote will be the right one? (i.e not the one inside the bst cache) | 14:17 |
| ssam2 | good question :-) | 14:17 |
| ssam2 | that *should* be the case, but not sure if it *is* yet | 14:17 |
| tlater | ssam2: Currently workspaces are detached from their versioning system | 14:18 |
| ssam2 | ah, ok | 14:18 |
| bochecha | tlater: it's not a local repo, it's pushed to the net somewhere, but I clone it, inside there's the bst stuff, one of which has the `path: .` sources | 14:18 |
| ssam2 | so actually, it's probably not worth switching to workspaces yet | 14:18 |
| bochecha | my goal was to keep it easy: clone the repo for the app, then build your modifications | 14:18 |
| ssam2 | this is definitely the use case that the feature is intended to support, though | 14:18 |
| tlater | Yeah, it's probably better done with a workspace; that way you don't need a .bst file in the repo | 14:19 |
| ssam2 | actually, i just opened a workspace and got a working Git clone | 14:19 |
| bochecha | so I'd have one repo with the app code, and one with the bst files? | 14:19 |
| ssam2 | with the correct remote URL | 14:19 |
| tlater | bochecha: That's how buildstream is intended to be used, I think | 14:19 |
| ssam2 | bochecha, ah, i guess again it depends on your case | 14:19 |
| ssam2 | i was picturing a 'lots of projects' integration workflow | 14:20 |
| ssam2 | if this is rather doing packaging for your project... then local source is probably correct | 14:20 |
| ssam2 | which brings us back full circle ... | 14:20 |
| ssam2 | maybe self-referential workspaces would be OK though | 14:20 |
| ssam2 | this is something i never quite figured out with flatpak-builder | 14:20 |
| bochecha | I don't mind separating the bst stuff to its own repo, I just didn't think about it before | 14:21 |
| ssam2 | do you import the app from its "upstream" repo, or as a local source | 14:21 |
| bochecha | ssam2: with flatpak-builder, from the upstream repo | 14:21 |
| ssam2 | ok; so perhaps best practice for bst in the flatpak usecase should be the same | 14:21 |
| bochecha | which is a huge pain, because `flatpak-builder --from-git...` will clone the repo to get the .json file, then start building that .json file which will clone the upstream repo again :) | 14:21 |
| bochecha | (the same repo for gnome apps shipping their manifest in their source tree) | 14:22 |
| ssam2 | yeah, I ended up doing an ugly sed hack in an app's CI system to replace the upstream URL with the local directory | 14:22 |
| bochecha | :) | 14:22 |
| * tlater wonders if a .bstignore file would make sense with local sources | 14:24 | |
| * ssam2 testing if self-referential workspaces | 14:24 | |
| ssam2 | ...works | 14:24 |
| tlater | ;P | 14:24 |
| bochecha | tlater: even with non-local sources, inside a workspace the same problem happens | 14:24 |
| bochecha | ssam2: what's a self-referential workspace? | 14:24 |
| bochecha | (sorry, gotta afk) | 14:24 |
| ssam2 | the idea that you have application and buildstream project in the same repo | 14:25 |
| ssam2 | and you open a workspace on that repo | 14:25 |
| ssam2 | no reason it shouldn't work really | 14:25 |
| tlater | Yeah, this may be worth considering, despite persia's protest - it may be a huge pain for developers | 14:25 |
| ssam2 | in workspaces we could really integrate with the VCS though | 14:25 |
| ssam2 | and avoid the need to have a .bstignore and a .gitignore that duplicate each other | 14:25 |
| persia | VCS integration is the preferable way to go, I think. | 14:26 |
| tlater | ssam2: Yeah, but that would require a `git add`, which makes workspaces a lot less useful for testing | 14:26 |
| ssam2 | "a lot" ? | 14:26 |
| tlater | Perhaps we could parse the workspace's .gitignore instead? | 14:26 |
| persia | The use case of bst and code in the same repo is the case where it matters, although I remain unconvinced this is best practice for anything. | 14:26 |
| ssam2 | tlater, possibly ... note that we have been discussing VCS integration with workspaces for other reasons | 14:26 |
| persia | To my mind, there is vast difference between "this code does things", and "this system consumes that code". | 14:27 |
| tlater | persia: I think it matters for workspaces in general, not just this odd case | 14:27 |
| ssam2 | tlater, notably as a performance optimisation to avoid having to hash the entire source dir (which may be enourmous) each time we need to know the cache key | 14:27 |
| ssam2 | persia, the use case I can see is packaging an app in multiple ways | 14:27 |
| persia | tlater: Why? What file would belong in .bstignore in the separate-repos case? | 14:27 |
| ssam2 | persia, the common use case of flatpak-builder is building an app, where you keep the flatpak-builder .json file in the same repo as the app | 14:27 |
| tlater | persia: If you check out a workspace some files don't belong in the workspace, but are created by editors etc. | 14:28 |
| ssam2 | persia, so if we aim to replace flatpak-builder, we should really support that :-) | 14:28 |
| tlater | You probably don't want to rebuild every time | 14:28 |
| persia | ssam2: I think doing that in mainline is the wrong way to do it, as it requires more effort to consume downstream if different defaults are chosen. | 14:28 |
| persia | I do appreciate that many flatpak people disagree with me :) | 14:28 |
| ssam2 | i'm not sure the term "mainline" or "downstream" makes much sense when talking about making simple flatpak apps | 14:29 |
| persia | tlater: If I have an editor open in a workspace, and it updates a e.g. swap file, that likely indicates I edited a file, yes? In which case I want to rebuild, don't I? | 14:29 |
| persia | ssam2: Right. I think "making a flatpak app" is inherently antisocial. I think people should make software and make systems (or components). | 14:30 |
| persia | But this isn't necessarily the right forum for that debate, and I do appreciate that others feel differently. | 14:30 |
| ssam2 | yes | 14:30 |
| tlater | I suppose it might be rare enough not to matter in practice. I certainly dislike the idea of a .bstignore file. | 14:31 |
| bochecha | tlater: why does that require a `git add`? | 14:31 |
| persia | Well, for this use case, I think it's really important. Whenever we mix contexts, there is benefit to having some means of hinting about our context, so that we can e.g. edit the .bst file without that causing buildstream to think the source was changed. | 14:32 |
| tlater | bochecha: If we implemented VCS integration for workspaces you would have to `git add` every time you make a change to rebuild | 14:32 |
| bochecha | tlater: but why? | 14:32 |
| bochecha | bst could just ignore the files from .gitignore, and take everything else, no? | 14:32 |
| persia | bochecha: Because bst would ask git "what changed", so git would have to know to answer. | 14:32 |
| tlater | bochecha: That's my idea :) | 14:32 |
| tlater | bochecha: On the other hand, we also want to minimize the number of source files we have to check - atm we hash the entire source tree, which may take forever | 14:33 |
| tlater | For that you *would* need `git add` | 14:33 |
| bochecha | that seems annoying :-/ | 14:33 |
| persia | tlater: One potential issue with the `git add` issue: is buildstream building from the current git working area or from the filesystem? | 14:33 |
| bochecha | right now I don't need to `git add` when I create a new source file in my project | 14:33 |
| persia | s/add`issue/add` model/ | 14:34 |
| tlater | persia: If it is a workspace, I assume yes? | 14:34 |
| persia | Indeed, the answer to nearly every well-formed question involving "or" is yes. Any idea which? | 14:34 |
| tlater | persia: From the filesystem, sorry | 14:35 |
| persia | That significantly reduces the utility of using `git add`, as buildstream will buikld from the modified content whether the user remembers to type that or not. | 14:36 |
| ssam2 | besides .gitignore, one motivation of using Git to discover what has changed is to avoid hashing every file in the source dir every time we build | 14:37 |
| ssam2 | but if we're going to automatically include uncommited files, we still need to scan | 14:37 |
| persia | The speed improvement would be welcome. The trick is making sure that this doesn't break things. | 14:37 |
| ssam2 | also, incremental build support complicates this further, as that involves knowing what is build output and what is source | 14:38 |
| ssam2 | (actually, it might not, my point is just that there's a bunch of considerations here) | 14:38 |
| persia | OOh, that is very complicated in the case where the user might edit files. | 14:38 |
| persia | Especially with something like `make`, where a user can hand-edit a generated file and run a partial rebuild with the hand-edited generated file changing from output to source as a result of the edit. | 14:38 |
| * tlater wonders if there is a better heuristic that doesn't require VCS | 14:43 | |
| *** mcatanzaro has joined #buildstream | 15:00 | |
| tlater | ssam2: Can the docker source plugin create an image from a local Dockerfile? | 15:11 |
| ssam2 | no | 15:12 |
| ssam2 | and i don't think we want that | 15:13 |
| ssam2 | dockerfile should die in a fire and be replaced with buildstream | 15:13 |
| tlater | Heh, maybe, but it *is* very useful for import elements | 15:15 |
| gitlab-br-bot | buildstream: merge request (flakes-refactor->master: Remove unused imports) #178 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/178 | 15:16 |
| ssam2 | yes, having it for import elements is crucial for killing dockerfiles :-) | 15:16 |
| tlater | It also means I can't actually test my docker image before I push it | 15:16 |
| tlater | Hm | 15:16 |
| ssam2 | why not ? | 15:16 |
| ssam2 | you can run `docker build` to build a docker file | 15:16 |
| ssam2 | oh, i guess then you need to set up a registry | 15:17 |
| ssam2 | which is not so much fun | 15:17 |
| tlater | Yup | 15:17 |
| ssam2 | `docker export` | 15:17 |
| ssam2 | then import it as a tarball | 15:17 |
| tlater | That works? Huh | 15:17 |
| tlater | Ta :) | 15:17 |
| gitlab-br-bot | buildstream: merge request (sam/multiple-caches->master: WIP: multiple remote cache support) #166 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/166 | 15:32 |
| gitlab-br-bot | buildstream: merge request (sam/multiple-caches->master: Multiple remote cache support) #166 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/166 | 15:33 |
| ssam2 | juergbi, multiple caches finally ready for review | 15:34 |
| juergbi | \o/ great | 15:34 |
| nexus | \o/ | 15:34 |
| bochecha | is the project name automatically exposed as a %{...} variable which can be used in elements? if so, what's the name of the variable? | 15:48 |
| ssam2 | i don't think it is | 15:48 |
| bochecha | it would be useful :) | 15:49 |
| ssam2 | what for, out of interest ? | 15:50 |
| ssam2 | should be fairly simple to do | 15:50 |
| bochecha | as an install-commands, I want the configuration file to end up in /etc/%{project-name}/ | 15:52 |
| bochecha | it's not too terrible to have to type the project name explicitly, but it would be even nicer if I could use a variable | 15:53 |
| ssam2 | you could also have a 'project-name' variable in your project.conf | 15:53 |
| ssam2 | variables: | 15:53 |
| bochecha | sure | 15:53 |
| ssam2 | project-name: foo | 15:53 |
| bochecha | which is what I'm doing right now :) | 15:53 |
| ssam2 | ah right | 15:54 |
| bochecha | but since the name is defined a few lines above in the same file... :-P | 15:54 |
| ssam2 | yeah... i guess it's probably 1 one line patch to the buildstream core, so i wouldn't block a patch to fix it | 15:56 |
| bochecha | I'll try and send a MR after I'm done with what I'm doing | 15:57 |
| ssam2 | we don't have an existing utility function in the core to save to a temporary file, then rename in place when fully written, right ? | 16:10 |
| ssam2 | thinking we should have something like https://gitlab.com/baserock/morph/blob/master/morphlib/savefile.py | 16:10 |
| ssam2 | i need something like that for https://gitlab.com/BuildStream/bst-external/merge_requests/9 (docker source plugin), but seems silly not to share it | 16:11 |
| bochecha | so I'm looking at the workspaces and having separate repos for the code and the bst stuff... opening a workspace does get me a full git clone which is neat, but it checks out a detached head :-/ | 16:12 |
| bochecha | also, having those separated repo, what would be the workflow for having a CI which runs `bst build` of the app whenever someone sends a merge request to the code repo... the Ci would have to clone the repo with the bst recipes, then have it track the submitted branch, then build the app (which clones again the source code repo from which the CI started) | 16:15 |
| bochecha | that seems so much more cumbersome than having the bst recipes in the source code repo, where the CI can just `bst build app.bst` (with app.bst using the `path: .` source) | 16:15 |
| tlater | bochecha: I think the CI could use the local path as a workspace | 16:18 |
| tlater | IIRC workspaces don't have to be empty, you can use any directory with the correct magical invocation | 16:18 |
| *** noah has joined #buildstream | 16:18 | |
| bochecha | sure, but the CI definitions are in the source code repo | 16:18 |
| ssam2 | i do see your point on it being more cumbersome | 16:18 |
| bochecha | since that's the one people are working on | 16:18 |
| bochecha | the workspace is created from the source code repo, but in the bst recipes repo | 16:19 |
| ssam2 | maybe there's some way we could extend the 'local' source to ignore files | 16:19 |
| *** noah has quit IRC | 16:19 | |
| *** noah has joined #buildstream | 16:21 | |
| tlater | bochecha: You could clone the bst files repo in the source code repo, that way you don't have to move CI definitions | 16:21 |
| tlater | It's a little more cumbersome, but I think having to clone the bst files in the dev repo is to be expected? | 16:21 |
| bochecha | tlater: I didn't expect it | 16:22 |
| bochecha | I thought workspaces meant I wouldn't clone the source code repo manually any more :) | 16:22 |
| tlater | bochecha: You can :) | 16:22 |
| bochecha | I'd just clone the bst recipes repo, do `bst workspace open app.bst` and I'd have the source code repo cloned for me | 16:22 |
| tlater | bst workspace open --no-checkout -f | 16:22 |
| tlater | You *can* still do it, but cloning it with the workspace command is more convenient in development | 16:23 |
| bochecha | yes | 16:23 |
| tlater | For CI obviously you'd use the obscure flags to ensure that you don't have to clone through bst | 16:23 |
| bochecha | which gets me back to my question: why would I clone the bst recipes repo from the source code repo? | 16:23 |
| tlater | Ah, fair enough | 16:23 |
| * tlater misread that | 16:24 | |
| bochecha | basically, so far the only workflow that makes sense to me is having the bst recipes in the source code repo, because then everything (both dev and CI) is simple and elegant | 16:24 |
| bochecha | (except those pesky .swp files of course :P) | 16:24 |
| ssam2 | perhaps we could prototype this with a special kind of 'local' source plugin | 16:25 |
| ssam2 | maybe 'git-local' | 16:25 |
| ssam2 | which would be like 'local', except require it to be git, and honour .gitignore | 16:25 |
| tlater | ssam2: That seems a bit overly specific, but alright for a prototype | 16:26 |
| * tlater observes some gcc breakage using alpine linux | 16:27 | |
| tlater | ssam2: Any chance this might happen because I'm using `docker export`? | 16:27 |
| ssam2 | what's the breakage ? | 16:28 |
| bochecha | ssam2: interesting idea | 16:28 |
| bochecha | I'll try and make a git-local plugin then :) | 16:28 |
| tlater | ssam2: <long path>/ld: cannot find Scrt1.o: No such file or directory | 16:28 |
| *** noah has quit IRC | 16:28 | |
| ssam2 | bochecha, cool :-) | 16:28 |
| ssam2 | tlater, when doing what ? | 16:28 |
| tlater | ssam2: Running ./configure on nasm | 16:29 |
| ssam2 | and does that work inside a container started with `docker run `? | 16:29 |
| tlater | It's the very first, basic thing gcc tries to compile to see if gcc works | 16:29 |
| * tlater hasn't tried, but assumed so because it's installed through a package manager. | 16:29 | |
| * tlater attempts | 16:29 | |
| *** noah has joined #buildstream | 16:30 | |
| tlater | Ah, nvm, it doesn't work | 16:31 |
| * tlater checks alpine linux' notes on gcc | 16:31 | |
| ssam2 | packaging there is very minimal, you're probably just missing some package | 16:32 |
| gitlab-br-bot | buildstream: merge request (sam/savefile-utility->master: utils.py: Add SaveFile utility class) #179 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/179 | 16:39 |
| * tlater needed g++ -.- | 16:50 | |
| bochecha | or instead of a git-local plugin, how about making the git plugin aware of local sources? | 16:51 |
| bochecha | as in, if the url is not a remote one (https://, git://, ...) but a local folder, then that does what we were discussing for a git-local plugin? | 16:51 |
| tlater | bochecha: I think technically that's already possible if you specify a local url with file:// | 16:51 |
| bochecha | tlater: right, but then it will still clone the local url, and uncommitted changes won't be taken into account for the build | 16:52 |
| *** noah has quit IRC | 16:54 | |
| *** mcatanzaro has quit IRC | 16:55 | |
| *** noah has joined #buildstream | 16:56 | |
| *** mcatanzaro has joined #buildstream | 16:57 | |
| *** noah has quit IRC | 16:58 | |
| *** noah has joined #buildstream | 17:00 | |
| ssam2 | file:/// urls also can't be relative | 17:03 |
| ssam2 | so would need some special casing | 17:03 |
| ssam2 | i can see advantages and disadvantages to both ways | 17:03 |
| bochecha | it's possible, but it's a pain | 17:03 |
| bochecha | I'll look at a git-local plugin, it seems safer as a first draft anyway | 17:04 |
| bochecha | should I add that to bst-external? | 17:04 |
| ssam2 | makes sense, yeah | 17:05 |
| *** bethw has quit IRC | 17:29 | |
| *** ssam2 has quit IRC | 17:33 | |
| *** jude has quit IRC | 17:38 | |
| *** tristan has joined #buildstream | 17:45 | |
| *** tpollard has quit IRC | 17:46 | |
| *** noah has quit IRC | 17:46 | |
| bochecha | so I made a new source plugin in bst-external, I ran `python3 setup.py install --user` for bst-external, then my project can't use the source plugin: | 17:52 |
| bochecha | Error loading pipeline: No Source type registered for kind 'git-local' | 17:52 |
| bochecha | I did add the new source plugin entry point to bst-external/setup.py | 17:53 |
| *** noah has joined #buildstream | 18:00 | |
| *** noah has quit IRC | 18:39 | |
| *** noah has joined #buildstream | 18:45 | |
| *** noah has quit IRC | 18:53 | |
| *** valentind has joined #buildstream | 19:43 | |
| bochecha | I don't understand how to load external plugins | 20:19 |
| *** mcatanzaro has quit IRC | 20:22 | |
| bochecha | digging into the code with pdb, I find this: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_plugincontext.py#L133 | 20:24 |
| bochecha | stepping into it, it tries to import the buildstream.plugins.git_local module | 20:25 |
| bochecha | which of course doesn't exist, it should be bst_external.sources.git_local | 20:27 |
| bochecha | I'm probably missing something here, because I don't see how external plugins can ever be loaded :-/ | 20:27 |
| *** valentind has quit IRC | 23:19 | |
| *** mcatanzaro has joined #buildstream | 23:49 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!