| *** Prince781 has quit IRC | 00:31 | |
| *** noisecell has joined #buildstream | 01:17 | |
| *** noisecell has quit IRC | 01:20 | |
| *** Prince781 has joined #buildstream | 03:16 | |
| *** mcatanzaro has quit IRC | 03:17 | |
| *** Prince781 has quit IRC | 05:18 | |
| *** tristan has joined #buildstream | 07:29 | |
| gitlab-br-bot | buildstream: issue #278 ("Filter documentation could be better") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/278 | 08:31 |
|---|---|---|
| *** jonathanmaw has joined #buildstream | 09:24 | |
| *** slaf has quit IRC | 09:45 | |
| *** slaf has joined #buildstream | 09:54 | |
| *** jonathanmaw has quit IRC | 09:58 | |
| *** noisecell has joined #buildstream | 10:00 | |
| *** jonathanmaw has joined #buildstream | 10:05 | |
| juergbi | tristan: i wasn't talking about the GNOME release (team) situation. that's quite special compared to bst projects tracking 3rd party upstreams | 10:23 |
| tristan | That makes an assumption about projects wanting to track 3rd party upstreams | 10:24 |
| tristan | The way one person is used to using buildstream doesnt really mean we know how it will be more popular | 10:25 |
| juergbi | indeed, i already acknowledged that there will definitely be different workflows | 10:25 |
| juergbi | however, building whole systems is an important use case i'd say, and for that you pretty much necessarily have to track 3rd party upstreams | 10:26 |
| tristan | I see tracking the latest commit on a branch and tracking the latest release tag as semantically different things | 10:26 |
| tristan | The avenue you suggest makes the project force that choice to be a project-wide one shot decision | 10:26 |
| tristan | Which, is a tempting shortcut to avoid having to care about the difference, and teach other source plugins to do it too | 10:27 |
| juergbi | there is a semantic difference, sure, but i think the bst project should make that decision (can be different from element to element, though) | 10:27 |
| juergbi | otherwise you essentially maintain two versions of your bst project, one that tracks the latest branches one that tracks the latest releases | 10:28 |
| tristan | This is sort of what tracking profiles are also for, we know it will be interesting to say "Track these sets of elements when I'm testing this; but that set of elements when I'm testing that" | 10:28 |
| tristan | That really depends | 10:29 |
| juergbi | not sure whether that will be worth it | 10:29 |
| tristan | You are assuming that ref is something that you revision | 10:29 |
| juergbi | no but i assume 'track' is | 10:29 |
| tristan | While that is IMO only a practice you want to employ closer to production | 10:29 |
| tristan | I mean you say "you essentially maintain two versions of your bst project"... that assumes revisioned refs | 10:30 |
| tristan | Otherwise, as usual, a bst project is something many things can be done with | 10:30 |
| tristan | you may track refs of release tags in a release branch | 10:30 |
| tristan | You may track refs of latest in your dev CI without revisioning, or even with revisioning in separate tags/snapshots | 10:31 |
| *** aday has joined #buildstream | 10:33 | |
| juergbi | i have to admit i don't see a huge point in non-revisioned refs | 10:34 |
| tristan | juergbi, to be clear; I dislike the feature overall because of the complexity it adds, but recognize the usefulness of it. If we must do it, it would be best not done with the quickest, easiest path to getting a feature in. | 10:34 |
| juergbi | i'm not trying to rush it, just trying to figure out how we can improve things | 10:34 |
| juergbi | the dependencies, patches, instructions apply to the chosen branch / release series and sometimes (mainly patches) depend on a particular commit range within the tracked branch | 10:35 |
| juergbi | it doesn't make sense to pretend that .bst files can be built with arbitrary upstream versions | 10:35 |
| tristan | I see an issue that is inherently complex and poses a serious question about buildstream having to learn about what a release is in tracking; I dont think this is something that is specific to VCS | 10:36 |
| tristan | And worry that there is already an MR for it | 10:36 |
| juergbi | as i mentioned, my main point is that some projects don't (always) have usable stable branches | 10:36 |
| juergbi | so even if i say i like the semantic policy of always tracking stable branches, it's not possible to use it for all elements right now | 10:37 |
| tristan | Elements are also not obligated to provide `track:` at all | 10:37 |
| juergbi | sure | 10:38 |
| tristan | I.e. if you want to ensure this element doesnt slip into an unsupported version, and recursively track | 10:38 |
| tristan | s/elements/sources | 10:38 |
| juergbi | in practice it just means that tracking is too limited for wide-spread use | 10:39 |
| juergbi | you still have to track tons of elements manually | 10:39 |
| juergbi | and i think fixing that situation is much more important than introducing fancy tracking profiles | 10:39 |
| juergbi | that's just my pov | 10:39 |
| juergbi | and i think the features are mostly orthogonal | 10:40 |
| tristan | Honestly, for freedesktop-sdk, this is not immensely pressing; the SDK has been manual with tarballs forever | 10:40 |
| tristan | Its nice to improve, yes - but we shouldnt hurry a feature into it and disregard that release tracking is a different activity from latest tracking | 10:41 |
| juergbi | agreed, it's no regression, no need to hurry | 10:41 |
| tristan | The reason tracking profiles comes up in discussion, is because it is an avenue to make it simpler for the user to use; when the distinction of release vs latest becomes important. | 10:41 |
| tristan | I.e. if BuildStream must learn to track releases, that should not be some crazy command line options a user needs to know how to use | 10:42 |
| tristan | It can be expressed once in the project | 10:42 |
| juergbi | i simply wanted to emphasize that tracking releases is even required with a single tracking profile (for upstreams without stable branches) | 10:55 |
| gitlab-br-bot | buildstream: merge request (juerg/git-track-tags->master: WIP: git.py: Support tracking annotated tags in a branch) #303 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/303 | 10:56 |
| juergbi | and per-element config is definitely required as buildstream can most likely not guess which sources have stable branches | 10:59 |
| juergbi | however, per-element config could well be just one part in the whole equation | 10:59 |
| tristan | juergbi, another thought is project conditionals and how they can possibly assist in the decision | 11:01 |
| juergbi | yes, i mentioned that in the gitlab issue. one possibility would be to use a project option as a form of tracking profile | 11:02 |
| tristan | unfortunately I think it's still a bit limiting, sources need to be entirely conditionalized when there was never a previous ref and a new one is needed | 11:02 |
| juergbi | yes, external .refs might help here | 11:02 |
| tristan | (ref appears outside of conditional statement) | 11:02 |
| juergbi | i guess it would be tricky to get track-save to always put ref in the same conditional as track | 11:03 |
| juergbi | and with project-wide track-tags even that would not be sufficient | 11:03 |
| *** aday has quit IRC | 11:07 | |
| *** tristan_ has joined #buildstream | 11:07 | |
| *** tristan has quit IRC | 11:08 | |
| *** slaf has quit IRC | 11:08 | |
| *** aday has joined #buildstream | 11:19 | |
| jennis_ | Is an error like this: Error loading pipeline: No Source type registered for kind 'docker' likely to be because I don't have docker installed? | 11:23 |
| jennis_ | if not, where are the source types registered? | 11:24 |
| tristan_ | jennis_, http://buildstream.gitlab.io/buildstream/projectconf.html#project-plugins | 11:34 |
| jennis_ | thanks tristan_ | 11:34 |
| *** tristan_ is now known as tristan | 11:34 | |
| jennis_ | ok yes, I get that, so you inform BuildStream of the of the plugins an the origin by adding `sources:` to the .bst | 11:40 |
| jennis_ | Which I have, yet still get this error? | 11:40 |
| jennis_ | and the origin* | 11:40 |
| *** ernestask has joined #buildstream | 11:46 | |
| tristan | jennis_, to the project.conf | 11:52 |
| tristan | that is in the project.conf documentation, specifying how a project declares which plugins to load and how | 11:53 |
| gitlab-br-bot | buildstream: merge request (tristan/shell-mounts->master: Adding new --mount option to bst shell.) #302 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/302 | 12:10 |
| *** xjuan has joined #buildstream | 12:22 | |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 12:23 |
| *** slaf has joined #buildstream | 13:36 | |
| *** i0d3l4y has joined #buildstream | 13:41 | |
| *** i0d3l4y has quit IRC | 13:59 | |
| *** mcatanzaro has joined #buildstream | 14:16 | |
| gitlab-br-bot | buildstream: merge request (278-filter-documentation-could-be-better->master: WIP: Resolve "Filter documentation could be better") #304 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/304 | 14:20 |
| *** aday has quit IRC | 14:54 | |
| gitlab-br-bot | buildstream: merge request (278-filter-documentation-could-be-better->master: WIP: Resolve "Filter documentation could be better") #304 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/304 | 14:59 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 15:13 |
| *** aday has joined #buildstream | 15:26 | |
| *** aday has quit IRC | 15:50 | |
| *** aday has joined #buildstream | 15:59 | |
| *** jonathanmaw has quit IRC | 16:32 | |
| tlater | I'm trying to learn how to use GLib by reverse-programming from this function: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_ostree.py#L123 | 16:44 |
| tlater | Unfortunately trying to commit to a test repository that I set up hackily using this results in an exception with 'Bad File Descriptor' | 16:45 |
| juergbi | tlater: do you mean OSTree or really GLib? | 16:47 |
| tlater | I'm trying to give that function an OSTree.Repo I create using `OSTree.Repo.new(Gio.File.new_for_path(args.repo))` | 16:47 |
| tlater | juergbi: Well, how to manipulate OSTree using the GLib gobject-introspection interface :) | 16:47 |
| juergbi | tlater: did you also call repo.create()? | 16:49 |
| tlater | juergbi: I first created the repo using the ostree cli | 16:49 |
| * tlater attempts repo.create() | 16:49 | |
| juergbi | ok, but you still need to call either repo.open() or repo.create() | 16:49 |
| juergbi | the former requires it to exist on disk already, the latter works either way | 16:49 |
| juergbi | there should probably be a better error message but that would be the fault of libostree... | 16:50 |
| tlater | Ah, ta juergbi | 16:50 |
| tlater | I assumed .new() would open it from the given dir | 16:51 |
| tlater | But I guess that's a stupid assumption | 16:51 |
| tlater | Why else would you call it .new()? x) | 16:51 |
| *** aday has quit IRC | 16:53 | |
| *** noisecell has quit IRC | 16:56 | |
| *** aday has joined #buildstream | 16:57 | |
| juergbi | hehe. some classes use two-stage construction as traditional _new() functions typically don't report errors | 16:58 |
| juergbi | GObject _new() functions are often just a wrapper around g_object_new() which doesn't support errors | 16:58 |
| juergbi | (the GInitable interface more or less solves that) | 16:59 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 18:02 |
| *** tiago has quit IRC | 18:32 | |
| *** aday has quit IRC | 19:02 | |
| *** aday has joined #buildstream | 19:03 | |
| *** noisecell has joined #buildstream | 19:38 | |
| *** xjuan has quit IRC | 19:50 | |
| *** valentind has joined #buildstream | 19:56 | |
| *** aday has quit IRC | 20:29 | |
| *** ernestask has quit IRC | 20:33 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!