| *** ethanwinn has joined #buildstream | 00:11 | |
| *** kapil___ has joined #buildstream | 00:28 | |
| *** nimish has quit IRC | 00:33 | |
| *** nimish has joined #buildstream | 00:43 | |
| *** nimish has quit IRC | 01:32 | |
| *** nimish has joined #buildstream | 01:35 | |
| *** nimish has quit IRC | 01:44 | |
| *** nimish_ has joined #buildstream | 01:44 | |
| *** nimish_ is now known as nimish | 01:45 | |
| *** xjuan has quit IRC | 01:58 | |
| *** nimish has quit IRC | 02:17 | |
| *** nimish has joined #buildstream | 02:18 | |
| *** nimish has quit IRC | 03:20 | |
| *** tristan has quit IRC | 05:23 | |
| *** tristan has joined #buildstream | 05:44 | |
| *** tintou has quit IRC | 07:46 | |
| *** tintou has joined #buildstream | 07:46 | |
| *** oknf[m] has quit IRC | 07:46 | |
| *** mattiasb has quit IRC | 07:47 | |
| *** jjardon[m] has quit IRC | 07:47 | |
| *** pro[m] has quit IRC | 07:47 | |
| *** theawless[m] has quit IRC | 07:47 | |
| *** tristan has quit IRC | 07:58 | |
| *** toscalix has joined #buildstream | 07:59 | |
| *** nimish has joined #buildstream | 08:02 | |
| *** oknf[m] has joined #buildstream | 08:06 | |
| *** kapil___ has quit IRC | 08:08 | |
| *** mattiasb has joined #buildstream | 08:38 | |
| *** pro[m] has joined #buildstream | 08:45 | |
| *** jjardon[m] has joined #buildstream | 08:47 | |
| *** tristan has joined #buildstream | 08:59 | |
| *** theawless[m] has joined #buildstream | 09:00 | |
| *** finn has joined #buildstream | 09:24 | |
| *** ajibade has joined #buildstream | 09:40 | |
| *** alatiera has joined #buildstream | 09:40 | |
| *** raoul has joined #buildstream | 09:42 | |
| *** nimish has quit IRC | 09:43 | |
| *** ChanServ sets mode: +o tristan | 09:47 | |
| tristan | jjardon, I have interesting news | 09:47 |
|---|---|---|
| * paulsherwood wonders what it is | 09:47 | |
| tristan | jjardon, It seems that when you disable checking out of submodules by setting 'checkout-submodules: False'... it does exactly that; disables their being checked out | 09:47 |
| tristan | jjardon, In other words, we still waste time fetching them and everything - I will cover it though in the warnings we're adding | 09:48 |
| jjardon | tristan: why you would want to download but not checkout? seems like a bug? | 09:52 |
| jjardon | can we disable downloading them completely when 'checkout-submodules: False' ? | 09:53 |
| * paulsherwood wonders where the fd-sdk irc channel is | 09:54 | |
| coldtom | +1, i thought this was just due to git itself | 09:54 |
| * paulsherwood is wondering a lot today | 09:54 | |
| *** nimish has joined #buildstream | 09:55 | |
| tristan | jjardon, Probably just because someone said "we should be able to disable checking out submodules", and someone implemented it... and nobody gave it more thought than that | 09:57 |
| tristan | jjardon, i.e. yeah; I'd say it's a bug :) | 09:57 |
| tristan | paulsherwood, #freedesktop-sdk on freenode | 09:57 |
| tristan | requires registered nick to join | 09:58 |
| *** tpollard has joined #buildstream | 09:59 | |
| tristan | jjardon, anyway I'm trying to address both warnings, for which we already have an age old XXX comment in place: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/plugins/sources/git.py#L540 | 09:59 |
| tristan | To add to that, we should have the invalid-submodule warning raised when someone configures submodule urls explicitly, and also sets checkout-submodules to False | 10:00 |
| tristan | that one can be done right at Plugin.configure() time | 10:00 |
| tristan | or preflight() would also do | 10:01 |
| *** ajibade has quit IRC | 10:02 | |
| ikerperez | Hi, I am trying to build cracklib without autotools, manually. Inside cracklib there are two directories "src" and "words, so you need to go inside "src" and then start the configuring steps. Inside the "configure-commands" step I have added the "cd src/" command but for some reason it never goes inside "src", any reason for that? | 10:02 |
| ikerperez | The code: /msg NickServ IDENTIFY password. | 10:02 |
| ikerperez | damn | 10:02 |
| ikerperez | The code https://paste.gnome.org/pmulexz1b | 10:02 |
| ikerperez | The logs: https://paste.gnome.org/pqivxzxxh | 10:02 |
| tristan | ikerperez, every command is a separate shell | 10:02 |
| tristan | ikerperez, so environments and state is not carried forward, there are a couple ways to do this without too much hassle... | 10:03 |
| tristan | lemme check docs... | 10:03 |
| coldtom | ikerperez: you need to include the two commands in the same yaml list item, if that makes sense | 10:03 |
| ikerperez | using:" - | " I guess | 10:04 |
| tristan | Well, I think that you want configure and build in the separate steps | 10:04 |
| tristan | ikerperez, since forever, one can set 'command-subdir' to specify "where the commands should be run" https://docs.buildstream.build/buildstream.buildelement.html#location-for-running-commands | 10:05 |
| tristan | ikerperez, In 1.4 (not released yet), there is also conf-root: https://docs.buildstream.build/buildstream.buildelement.html#location-for-configuring-the-project | 10:05 |
| *** nimish has quit IRC | 10:06 | |
| *** nimish has joined #buildstream | 10:06 | |
| tristan | conf-root configurability is mostly part of an initiative for making it easier to define builds where the build dir sits somewhere outside of the source directory (subtly different from builddir != srcdir) | 10:06 |
| tristan | ikerperez, depending on how much commands you have to run, with 1.2 you might want to set `command-subdir: src` in your cracklib.bst, and run your configure script with `cd .. && ./configure`, or `../configure` | 10:08 |
| paulsherwood | tristan: thanks, i have recovered my identity :) | 10:08 |
| *** jonathanmaw has joined #buildstream | 10:09 | |
| ikerperez | thank you tristan, I will apply the "command-subdir" | 10:10 |
| *** nimish has quit IRC | 10:11 | |
| *** nimish has joined #buildstream | 10:16 | |
| gitlab-br-bot | finnball opened issue #801 (bst pull silently failed when there is a network timeout) on buildstream https://gitlab.com/BuildStream/buildstream/issues/801 | 10:20 |
| gitlab-br-bot | finnball closed issue #423 (bst pull silently failed when there is a network timeout) on buildstream https://gitlab.com/BuildStream/buildstream/issues/423 | 10:20 |
| gitlab-br-bot | devcurmudgeon approved MR !894 (valentindavid/sysroot_dependencies->master: Add support for importing build dependencies in sysroots.) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/894 | 10:28 |
| *** lachlan has joined #buildstream | 10:30 | |
| *** cs-shadow has joined #buildstream | 10:40 | |
| valentind | juergbi, for !906 I adapted you shell script to create a shallow git repository. One thing that is done is to copy the data for the annotated tag. It contains the tag message and I suppose probably the signature. I wondered, is that important for git describe to work? Or would it not work to create the tag since the hash is different? | 10:48 |
| gitlab-br-bot | MR !906: Track of git tags and save them to reproduce minimum shallow repository https://gitlab.com/BuildStream/buildstream/merge_requests/906 | 10:48 |
| *** nimish has quit IRC | 10:49 | |
| *** nimish has joined #buildstream | 10:49 | |
| juergbi | valentind: hm, I don't think the contents of the tag message matter for git describe, however, we at least need to distinguish between annotated and lightweight tags | 10:49 |
| valentind | juergbi, OK thank you. Let's try without first then. | 10:50 |
| gitlab-br-bot | tristanvb closed issue #483 (Buildstream should fail if ref: is not within the tag/branch specified in track: (git source plugin)) on buildstream https://gitlab.com/BuildStream/buildstream/issues/483 | 10:51 |
| Nexus | I just got a notification that apparently the sphinx-click issue "Documentation ignores the \b characters in docstrings" has been patched | 10:53 |
| Nexus | tristan, juergbi | 10:53 |
| * juergbi doesn't recall that issue | 10:54 | |
| *** nimish has quit IRC | 10:54 | |
| *** nimish has joined #buildstream | 10:54 | |
| Nexus | juergbi: i think it was something to do with preformatted text not working in the docs? | 10:55 |
| tristan | It aint perfect, but it's a bit better | 11:00 |
| *** finn_ has joined #buildstream | 11:01 | |
| *** finn has quit IRC | 11:02 | |
| gitlab-br-bot | raoul.hidalgocharman opened issue #802 (Refactor `_artifactcache` folder) on buildstream https://gitlab.com/BuildStream/buildstream/issues/802 | 11:03 |
| coldtom | tristan: on the `bst fmt` command: does using the plugin's yaml file as a default order seem like a reasonable/plausible solution? | 11:07 |
| tristan | coldtom, Maybe - it does sound like an interesting way to automate how the plugin can inform the core of the expected order; however there are two big problems with that idea | 11:12 |
| tristan | coldtom, One of them is that the plugin's YAML file indicates a default; looking at project.conf or user config defaults as an example, there are plenty of cases where a "thing" is optional, the default is nothing is set, and it can only be specified | 11:13 |
| tristan | so there is no "default" for every possible configuration | 11:13 |
| tristan | coldtom, the other problem is that sources do not have a defaults yaml file, only elements do | 11:13 |
| Nexus | tristan: please could you weigh in on mr ML thread? "bst show all and bst build all flags" | 11:14 |
| Nexus | on my* | 11:14 |
| tristan | Nexus, Done. | 11:19 |
| *** solid_black has joined #buildstream | 11:25 | |
| *** nimish has quit IRC | 11:34 | |
| *** nimish has joined #buildstream | 11:35 | |
| gitlab-br-bot | phildawson opened (was WIP) MR !959 (phil/source-checkout-options->master: Retire bst source bundle command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/959 | 11:40 |
| *** lachlan has quit IRC | 11:43 | |
| *** abderrahim has quit IRC | 11:49 | |
| *** abderrahim has joined #buildstream | 11:50 | |
| *** nimish has quit IRC | 11:55 | |
| *** nimish has joined #buildstream | 11:55 | |
| adds68 | jonathanmaw, hey could you give this one final glance to check i have covered your points? | 11:57 |
| adds68 | https://gitlab.com/BuildStream/bst-external/merge_requests/60 | 11:57 |
| *** nimish has quit IRC | 12:00 | |
| *** nimish has joined #buildstream | 12:00 | |
| *** nimish has quit IRC | 12:05 | |
| *** nimish has joined #buildstream | 12:06 | |
| *** nimish has joined #buildstream | 12:06 | |
| *** lachlan has joined #buildstream | 12:18 | |
| *** nimish_ has joined #buildstream | 12:22 | |
| *** nimish has quit IRC | 12:22 | |
| *** nimish_ is now known as nimish | 12:22 | |
| valentind | tristan, I have fixed what you asked on !906 | 12:23 |
| gitlab-br-bot | MR !906: Track of git tags and save them to reproduce minimum shallow repository https://gitlab.com/BuildStream/buildstream/merge_requests/906 | 12:23 |
| jonathanmaw | adds68: they're all covered, but upstream's moved ahead so the latest version isn't bst-external 0.6.3 any more. Just stick the note of what's new under the "Next Version" heading, and that'll be enough. | 12:28 |
| *** nimish has quit IRC | 12:32 | |
| *** nimish has joined #buildstream | 12:32 | |
| tristan | The hanging tests are a damn nightmare | 12:37 |
| tristan | Someone knows how to get us a stack trace ? | 12:37 |
| valentind | tristan, is it hanging on your machine or on a builder? | 12:39 |
| tristan | my machine | 12:40 |
| tristan | valentind, seems that since some months ago, when BuildStream crashes in a child process we get hanging tests instead of BUG messages | 12:40 |
| valentind | tristan, I have seen that when the cache server spawned by the tests crashes. | 12:41 |
| tristan | Weird thing... if I modify runcli.py to print the command in *advance* of running it, I can at least find the culprit command and run it independently | 12:41 |
| tristan | *but* in this case it's not causing a crash | 12:41 |
| tristan | very strange | 12:42 |
| tristan | Ok I'll have to figure it out | 12:42 |
| tristan | but wish I didnt have to wrestle tests in the process :-S | 12:42 |
| valentind | tristan, I have used faulthandler to print stack on SIGUSR1 | 12:45 |
| juergbi | jmac fixed the hang issue when the test cache server crashes, iirc. but there may be other related issues | 12:45 |
| tristan | valentind, on a side note, you have made the necessary cache key considerations with your patch right ? | 12:46 |
| jmac | Not quite. I made !964, but that only solves some hangs when buildstream crashes, not the cache server | 12:46 |
| gitlab-br-bot | MR !964: Avoid hanging artifact cache tests https://gitlab.com/BuildStream/buildstream/merge_requests/964 | 12:46 |
| tristan | valentind, like the fact that enabling/disabling the tags, or the value of the tags, should both cause rebuilds of the associated artifacts | 12:46 |
| valentind | tristan, the tags are added to the cache key. | 12:46 |
| valentind | if self.mirror.tags: | 12:46 |
| valentind | key.extend(self.mirror.tags) | 12:46 |
| *** nimish has quit IRC | 12:47 | |
| tristan | valentind, okay... and when you are not using the tags and have a built artifact with a bad version because the build scripts failed to use git describe... enabling the opt-in feature never does anything because there is no new artifact to build ? | 12:47 |
| *** nimish has joined #buildstream | 12:48 | |
| valentind | tristan, the opt-in changes only the tracking. | 12:48 |
| valentind | So you need to opt-in and then track. | 12:48 |
| tristan | Interesting | 12:48 |
| tristan | I guess you're right, only the value of the tags can change anything | 12:48 |
| valentind | And if you opt-out, you have to track again or remove manually the tags. | 12:48 |
| tristan | Right | 12:49 |
| tristan | that makes sense | 12:49 |
| valentind | And the name is "track-tags" so it should not be confusing. | 12:49 |
| * tristan is also swimming in git.py | 12:49 | |
| tristan | valentind, probably better to follow the pattern of naming the things you shove into the key | 12:50 |
| tristan | like: key.append({"submodule_checkout_overrides": self.submodule_checkout_overrides}) | 12:50 |
| tristan | and others do | 12:50 |
| valentind | tristan, OK | 12:50 |
| valentind | maybe I can actually transform the list of tuples into a hash map so that there is no ordering of the tags in the key. | 12:51 |
| tristan | valentind, finally, you should add a new git test to tests/cachekey/project/sources which exercises the new feature which can affect the key | 12:51 |
| tristan | which is mostly just a matter of adding a little bst file and depending on it from the target | 12:52 |
| tristan | well, not mostly, it is just a matter of that | 12:52 |
| tristan | valentind, I wanted that but we have followed a different pattern it seems, you cant make a transformation of that pattern without breaking the key, so let's just continue with this pattern | 12:52 |
| *** lachlan has quit IRC | 12:53 | |
| valentind | tristan, Ah right. | 12:53 |
| valentind | tristan, well, I can still add it only if there are tags. | 12:54 |
| valentind | That should work. | 12:54 |
| tristan | valentind, the line you pasted above seems to do that already yes | 12:54 |
| tristan | it's backwards compatible, only adds to the key if the new feature is used, which is correct | 12:54 |
| tristan | just for extra safety, it's good to name the things we add to the key | 12:54 |
| valentind | tristan, done | 13:07 |
| valentind | There is a useless line. Let me remove it. | 13:12 |
| valentind | It looks like that now: | 13:14 |
| valentind | if self.mirror.tags: | 13:14 |
| valentind | tags = {tag: (commit, annotated) for tag, commit, annotated in self.mirror.tags} | 13:14 |
| valentind | key.append({'tags': tags}) | 13:14 |
| Nexus | tristan & juergbi: I've been trying to follow your comments on the ML but got a bit lost. Where does this leave my work, and what do you think should be done? | 13:17 |
| juergbi | Nexus: tristan agreed with my suggestion of the default target approach, i.e., when no other targets are specified | 13:58 |
| *** alatiera_afk has left #buildstream | 13:58 | |
| juergbi | as a first step this would (attempt to) load/build all project elements, however, we definitely also want to make this configurable in project.conf | 13:59 |
| juergbi | i.e., it should be possible to specify an element name (typically a stack) for use as default target, instead of the default of all project elements | 14:00 |
| juergbi | if anyone has a strong opinion against this approach, they should speak up now | 14:00 |
| juergbi | (on the ML) | 14:00 |
| Nexus | if you're using something like a stack, why not just use the existing functionality to just do `bst build stack.bst` rather than doing `bst build` with stack.bst in the project.conf ? | 14:01 |
| tristan | Nexus, I would argue that in general, as an argument to just not do the feature at all - but I think people want it. If there is any difference I would say it is a question of cognitive effort | 14:02 |
| tristan | If you work with a lot of separate BuildStream projects, it's easier to remember `bst build --world`, than to have intimate knowledge of each project | 14:03 |
| juergbi | yes, if I want to build a new project, it's nice to have a default target | 14:03 |
| juergbi | similar to how you can run 'make' without needing to know a target/goal name | 14:03 |
| tristan | Right | 14:03 |
| juergbi | tristan: hm, syntax, you want to have a --world argument after all? maybe you overlooked that part of my suggestion | 14:04 |
| tristan | juergbi, please take over :) | 14:04 |
| tristan | I overlooked most of it indeed | 14:04 |
| tristan | I thought we were going with --world because of a conflict with the meaning of "no argument" from a workspace | 14:05 |
| juergbi | imo, --world is a confusing name if it's a configurable default target that doesn't necessarily build 'the whole world'. also, I don't think it's needed | 14:05 |
| tristan | also good point | 14:05 |
| juergbi | my argument was/is that building the workspace element when invoked from the workspace directory and building the project default target when invoked from the project directory should not be too surprising to users | 14:05 |
| juergbi | again similar to how `make` depends on the current directory | 14:06 |
| tristan | juergbi, I also prefer that to having to specify a flag indeed | 14:06 |
| tristan | it is much nicer if you can just write `bst build` | 14:06 |
| tristan | and that's all | 14:06 |
| * tristan obviously doesnt have very strong preferences feelings about this feature ;-) | 14:07 | |
| *** nimish has quit IRC | 14:08 | |
| *** nimish has joined #buildstream | 14:08 | |
| juergbi | cs-shadow: you've raised #640. your input on the above (here or ML) would be appreciated | 14:09 |
| gitlab-br-bot | Issue #640: RFE: Allow easy way of building all elements https://gitlab.com/BuildStream/buildstream/issues/640 | 14:09 |
| Nexus | tristan: i personally quite like --world, because we're "trying" to build everything in the project directory and down, so it effectively is that projects "world" | 14:09 |
| tpollard | I suggested world in the original ticket because that's what bitbake uses, and we already had -all meaning something else | 14:10 |
| Nexus | i think it's confusing to have `bst build` do different things depending on where you run it | 14:10 |
| tpollard | world in that case is a target though, not a flag | 14:10 |
| Nexus | and having a stack element goes against the original reason for some people wanting this feature | 14:10 |
| Nexus | i.e. not having to list everything | 14:10 |
| juergbi | Nexus: well, it will anyway be different depending on the current working directory. the question is just whether it should report an error in the project directory or build the default target, right? | 14:11 |
| tristan | My feeling is that `build` with no arguments is a target most of the time, and in the edge case where no default target has been set, it will try to build them all | 14:11 |
| Nexus | juergbi: it builds from the project root dir, not your cwd | 14:11 |
| Nexus | the currently implementation runs a walk from the root dir and tries to build everything ending in ".bst" | 14:12 |
| juergbi | Nexus: the default will be to build everything. however, as discussed on the ML, a project may have elements that can't be built on all platforms. so literally building all elements is not possible for all projects | 14:12 |
| juergbi | Nexus: right, so the build will not depend on whether you're in a subdir of the project/workspace or not. I don't see this as a big concern | 14:13 |
| Nexus | juergbi: could another option be then that we do a soft load of the elements and safely fail the ones that can't be loaded? | 14:13 |
| juergbi | hm, maybe this could be useful for the default case of building all elements. but might also hide issues (user doesn't realize that some elements were skipped), so I'm not sure we want that | 14:14 |
| tristan | It is difficult to implement | 14:15 |
| tristan | Also | 14:15 |
| tristan | I.e. you have to determine the *reason* why a LoadError was raised | 14:15 |
| Nexus | Don't most LoadErrors come with a breif anyway? | 14:15 |
| tristan | "Build everything that loads" seems weird, you'd still want to bail out on malformed YAML | 14:15 |
| Nexus | tristan: that's what the `bst show --world` is for. And that would fail in the normal build anyway | 14:16 |
| juergbi | yes, it should be restricted to explicit asserts, I suppose, but even that is questionable | 14:16 |
| tristan | Erroring out seems more desirable, just go ahead and specify a default target already and have an expected behavior | 14:16 |
| juergbi | we could theoretically consider a different configuration possibility in that you can list elements to include instead of having to write a full stack | 14:17 |
| juergbi | don't know whether that's worth it, though | 14:17 |
| juergbi | eh, exclude, not include | 14:17 |
| juergbi | I'd keep it simple and just allow configuration to point to a stack (or whatever element). however, maybe other people have other use cases | 14:18 |
| Nexus | i think exclude would be better | 14:19 |
| *** alatiera has quit IRC | 14:19 | |
| Nexus | if you have to list all elements to include, it defeats the point of having the build all functionality | 14:20 |
| tristan | A stack element which "excludes" things instead of depends on things seems also very weird to me, i.e. a direct invitation to unexpected/undefined behavior | 14:20 |
| *** lachlan has joined #buildstream | 14:20 | |
| Nexus | but if we require a stack element anyway, why not just do `bst build stack.bst`? I don't understand how the functionality would be changing beyond what already exists | 14:21 |
| juergbi | Nexus: two advantages | 14:22 |
| juergbi | 1) the user may not know the name of that element | 14:22 |
| * tristan didnt think he felt strongly about this subject, but now that he sees suggestions which encourage invocations which dont have very strictly explained outcomes, he starts to | 14:22 | |
| juergbi | 2) for smaller projects, the default of building all elements is suitable | 14:22 |
| tristan | I.e. if "build everything" actually works, that is not very controversial... otherwise, having anything non-explicit is undesirable | 14:23 |
| *** alatiera has joined #buildstream | 14:23 | |
| juergbi | yes. I think we should just implement the simple way that I think makes sense anyway, and potentially discuss further possibilities later | 14:23 |
| *** lachlan has quit IRC | 14:24 | |
| *** lachlan has joined #buildstream | 14:24 | |
| Nexus | juergbi: i can see the advantage of a "default element", but i don't think that should replace a build all command | 14:26 |
| Nexus | i'd see that as more of a hack than actual functionality | 14:26 |
| juergbi | you'd want to support both as separate CLI features/options? | 14:27 |
| Nexus | yes | 14:27 |
| juergbi | I don't think this makes sense | 14:27 |
| juergbi | at least for building | 14:27 |
| Nexus | a default element which can be configured. And also the option to build all with exceptions (also project.conf configurable imo) | 14:28 |
| juergbi | if a project explicitly specifies a default, this should normally mean that building literally everything doesn't make sense or is not possible | 14:28 |
| *** nimish has quit IRC | 14:28 | |
| juergbi | imo, that's too much | 14:28 |
| *** nimish has joined #buildstream | 14:28 | |
| juergbi | supporting a configuration of the default target via exceptions/excludes instead of a stack element could be discussed | 14:29 |
| juergbi | but it is problematic as tristan mentioned, and I don't think this should be in addition to the default target, it should just be an alternative way to configure it | 14:29 |
| Kinnison | My concern with 'default target' as an approach is that it doesn't really solve cs-shadow 's use-case as described in #638 and #640 | 14:32 |
| gitlab-br-bot | Issue #638: RFE: Add `bst validate` command https://gitlab.com/BuildStream/buildstream/issues/638 | 14:32 |
| gitlab-br-bot | Issue #640: RFE: Allow easy way of building all elements https://gitlab.com/BuildStream/buildstream/issues/640 | 14:32 |
| Nexus | i don't understand why it would cause issues to have exclusions. To do a build all, we just return a list of all elements to be build, as if they were individually listed in the build command. At the point of reading the yaml, you'd then remove all matching elements from the build list would you? Or am i missing a step that makes that impossible? | 14:33 |
| juergbi | Kinnison: well, for elements that are platform-specific the literal interpretation of #640 is simply impossible | 14:33 |
| juergbi | and that's why I'm also interested in his input | 14:33 |
| juergbi | Nexus: no, I'm not saying it's impossible and I mentioned that this could be discussed | 14:34 |
| juergbi | however, I don't think this should block the clearer parts, which makes sense anyway, imo | 14:36 |
| tristan | Kinnison, The "build everything" thing just doesnt make sense, not every element is compatible with every other, or can be built under every set of project options (as juergbi points out) | 14:36 |
| tristan | A validation of *everything* is more plausible, but also suffers from the fact that some fragments wont be reachable depending on project options enabled at validation time | 14:36 |
| *** lachlan has quit IRC | 14:37 | |
| tristan | juergbi, an eventual extension to this might be to consider project option selections as well in this default target, allow specifying multiple target/configuration tuples | 14:38 |
| *** nimish has quit IRC | 14:38 | |
| *** nimish has joined #buildstream | 14:39 | |
| tristan | For this to be practical and useful, one should consider that it should be possible for instance, to build both a Flatpak SDK *and* a bootable system image of GNOME from the gnome-build-meta repository, with a single invocation of `bst build` | 14:39 |
| tristan | That would mean multiple targets explicitly specified, along with differing project options; and one might want to also build it for every supported architecture | 14:39 |
| juergbi | tristan: this should actually already be possible using a local junction to . | 14:42 |
| *** tristan has quit IRC | 14:43 | |
| *** lachlan has joined #buildstream | 14:53 | |
| *** kapil___ has joined #buildstream | 15:01 | |
| *** tristan has joined #buildstream | 15:05 | |
| *** nimish has quit IRC | 15:09 | |
| *** nimish has joined #buildstream | 15:09 | |
| *** nimish has joined #buildstream | 15:10 | |
| *** ajibade has joined #buildstream | 15:35 | |
| phildawson | juergbi, benschubert. Any chance you could take one last look at !959 for me? I think it should be ready to merge now :) | 15:48 |
| gitlab-br-bot | MR !959: Retire bst source bundle command https://gitlab.com/BuildStream/buildstream/merge_requests/959 | 15:48 |
| *** ajibade has quit IRC | 15:51 | |
| juergbi | will take a look | 15:52 |
| phildawson | thanks | 15:55 |
| *** lachlan has quit IRC | 15:56 | |
| *** lachlan has joined #buildstream | 15:58 | |
| *** lachlan has quit IRC | 16:05 | |
| benschubert | tristan: phildawson still have a meeting, will do right after | 16:14 |
| *** lachlan has joined #buildstream | 16:20 | |
| *** lachlan has quit IRC | 16:30 | |
| *** nimish has quit IRC | 16:40 | |
| *** nimish has joined #buildstream | 16:40 | |
| *** lachlan has joined #buildstream | 16:48 | |
| *** lachlan has quit IRC | 16:52 | |
| cs-shadow | juergbi: Kinnison: I was afk earlier, will reply on the ML about the use-case after I sift through my inbox :) | 16:56 |
| Kinnison | cs-shadow: Cool, thanks | 16:56 |
| juergbi | thanks | 16:56 |
| *** solid_black has quit IRC | 16:59 | |
| *** lachlan has joined #buildstream | 17:10 | |
| lachlan | toscalix: I'm looking at how we are going to store benchmarking data long-term and what tools might be used to carry out analysis on what is produced. During our discussions you mentioned an analytical tool that you were using for bug tracking analysis, could you jog my memory as to what it was please. | 17:41 |
| toscalix | Elasticsearch Logstash and Kibana is becoming a very popular combination | 17:46 |
| *** finn_ has quit IRC | 17:47 | |
| toscalix | Bitergia has developed a tool to add to the above combination which is very interesting. It is called perceval | 17:48 |
| toscalix | lachlan: it gathers data from many sources, gitlab among them | 17:49 |
| *** kapil___ has quit IRC | 17:49 | |
| toscalix | creating a module for buildstream would save us a lot of plumbing in orchestration | 17:50 |
| *** nimish has quit IRC | 17:50 | |
| toscalix | perceval has been adopted by the CHAOSS project, from the linux foundation | 17:51 |
| *** nimish has joined #buildstream | 17:51 | |
| toscalix | https://github.com/chaoss/grimoirelab-perceval | 17:51 |
| lachlan | toscalix: At the minute I'm looking from the perspective of Benchmarking, but if a broader requirement exists then it makes sense to look at the bigger question. | 17:52 |
| toscalix | you can simply take a look at the input of perceval and get an idea of what is usually required from external tools for this purpose | 17:52 |
| lachlan | Has any thought been given to looking at and formalising perceval as an official tool for Buildstream | 17:53 |
| toscalix | mozilla, puppet, OPNFV and others have built perceval modules | 17:53 |
| *** kapil___ has joined #buildstream | 17:54 | |
| lachlan | It looks like Perceval is a good starting place. | 17:54 |
| toscalix | jenkins has a module | 17:54 |
| toscalix | agree | 17:54 |
| toscalix | https://perceval.readthedocs.io/en/latest/perceval.html | 17:55 |
| lachlan | Thanks will have a look | 17:55 |
| toscalix | the jenkins one seems like the best one to start with | 17:55 |
| toscalix | https://perceval.readthedocs.io/en/latest/perceval.backends.core.html#module-perceval.backends.core.jenkins | 17:55 |
| toscalix | lachlan: ^ | 17:55 |
| *** nimish has quit IRC | 17:56 | |
| *** nimish has joined #buildstream | 17:56 | |
| lachlan | toscalix: Thanks | 17:56 |
| *** jonathanmaw has quit IRC | 17:59 | |
| *** lachlan has quit IRC | 18:00 | |
| *** tpollard has quit IRC | 18:01 | |
| *** paulsherwood has quit IRC | 18:11 | |
| *** jmac has quit IRC | 18:11 | |
| *** benbrown has quit IRC | 18:11 | |
| *** Nexus has quit IRC | 18:11 | |
| *** benbrown has joined #buildstream | 18:12 | |
| *** lachlan has joined #buildstream | 18:16 | |
| *** lachlan has quit IRC | 18:30 | |
| *** xjuan has joined #buildstream | 18:37 | |
| *** raoul has quit IRC | 18:39 | |
| *** raoul has joined #buildstream | 19:15 | |
| *** toscalix has quit IRC | 19:26 | |
| *** nimish_ has joined #buildstream | 19:39 | |
| *** nimish has quit IRC | 19:40 | |
| *** nimish_ is now known as nimish | 19:40 | |
| *** bochecha has joined #buildstream | 20:00 | |
| *** kapil___ has quit IRC | 20:09 | |
| gitlab-br-bot | jjardon opened MR !987 (jjardon/strip-binaries-removal->master: Remove default strip-commands) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/987 | 20:23 |
| *** xjuan has quit IRC | 20:35 | |
| *** tristan has quit IRC | 20:41 | |
| *** nimish has quit IRC | 21:01 | |
| *** nimish has joined #buildstream | 21:02 | |
| *** nimish has quit IRC | 21:31 | |
| *** nimish has joined #buildstream | 21:32 | |
| *** xjuan has joined #buildstream | 21:33 | |
| *** nimish has quit IRC | 21:35 | |
| *** nimish has joined #buildstream | 21:56 | |
| *** nimish has quit IRC | 21:58 | |
| *** nimish has joined #buildstream | 22:00 | |
| *** nimish has quit IRC | 22:08 | |
| *** nimish has joined #buildstream | 22:15 | |
| *** nimish has quit IRC | 22:18 | |
| *** nimish has joined #buildstream | 22:24 | |
| *** nimish has quit IRC | 23:32 | |
| *** nimish has joined #buildstream | 23:53 | |
| *** kapil___ has joined #buildstream | 23:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!