| *** tristan has joined #buildstream | 00:08 | |
| *** ChanServ sets mode: +o tristan | 00:25 | |
| tristan | jjardon, Personally my preference would be to put everything into 'experimental' without prejudice, even for plugins which have been 'stable' for a long time | 00:25 |
|---|---|---|
| tristan | The main reason for this is that it would cause us to create a process/story, eventually, for how plugins stablize and then graduate to stable repositories (regardless of how those end up being grouped) | 00:26 |
| tristan | But I think what has been happening is a bit more arbitrary, and I don't have objections... this was my recommendation though some time ago | 00:27 |
| persia | If we're not doing one-plugin-per-repo, I think mixing status and name is correct (consider gstreamer's "good", "bad", and "ugly") | 00:57 |
| persia | But we do have to think about a policy to cause things to move out of experimental (and what to call them if/when they do) | 00:57 |
| tristan | and if we're doing the former, then we need to think about maintaining an index to those which have stability guarantees | 01:04 |
| tristan | anyway it's been discussed to death :) | 01:05 |
| persia | Yes :) | 01:11 |
| jjardon | persia: good bad ugly is not related with API stability | 02:26 |
| jjardon | For example ugly is for plugins with problematic because licensing or patents | 02:31 |
| persia | Sure, but bad is a mix of the unmaintained, the bitrotted, and the experimental | 02:33 |
| persia | Whereas good is license-safe (or broadly so, at least), working, and maintained. | 02:34 |
| * persia thinks gstreamer's semantics are clear, unambiguous, and accessible | 02:34 | |
| * jjardon wishes we could have the same | 02:35 | |
| persia | Then let's do that. | 02:35 |
| persia | I assert -experimental is equivalent to -bad | 02:36 |
| persia | So to sort things into good and ugly, we need some guidelines on what makes something compliance-safe, and what is required to be blessed. | 02:36 |
| persia | gstreamer requires a maintainer, a working test suite, independent code review, proper documentation, and evidence of wide use to promote from -bad to -good. | 02:37 |
| persia | (note, this discussion has to actually happen on the mailing list to mean anything: consensus here isn't binding by current buildstream governance) | 02:38 |
| persia | But I don't think *any* of the BuildStream plugins achieve gstreamer-good level at this point. Some begin to be close, but others less so. | 02:39 |
| persia | And I don't think any of the code in -experimental would qualify as -ghly at this point. | 02:40 |
| jjardon | Sounds like a plan! | 02:50 |
| *** jswagner has joined #buildstream | 03:21 | |
| *** jswagner has joined #buildstream | 03:26 | |
| *** narispo has quit IRC | 04:12 | |
| *** narispo has joined #buildstream | 04:12 | |
| *** bochecha has quit IRC | 07:43 | |
| *** traveltissues has joined #buildstream | 07:46 | |
| juergbi | jjardon: have you seen my comment on #1165? | 07:47 |
| gitlab-br-bot | Issue #1165: Architecture support should not be hardcoded in the tool https://gitlab.com/BuildStream/buildstream/issues/1165 | 07:47 |
| benschubert | persia: the problem with 'good' and 'bad', is that what if one 'good' plugin looses its maintainer and nobody comes up? do we move it to bad? If so, does that mean users will have to suddenly install 'bad' in addition because they were relying on this plugin? A theme-related or per-plugin repo still seems easier in that matter | 07:51 |
| *** bochecha has joined #buildstream | 07:54 | |
| juergbi | I also prefer per topic or individual plugin repositories. -experimental as incubator could be ok | 07:55 |
| juergbi | however, I don't really see an advantage of a single -good repo compared to just keeping all good plugins in the core repo | 07:55 |
| juergbi | i.e., it has all the downsides of keeping the plugins in the core repo but is slightly less convenient | 07:57 |
| benschubert | ^ I concur, seems like all the inconvenients for no advantages | 07:59 |
| *** toscalix has joined #buildstream | 08:01 | |
| coldtom | would it not be possible to have all the plugins in a single repo, but distributed as different python packages? | 08:04 |
| coldtom | surely there's some setuptools magic for that | 08:04 |
| benschubert | the problem with that is maintainership. Some plugins might not hav emaintainers, and that would add burden to people that do not care/know anything about the said plugin :) So it wouldn't make is easier to maintain either | 08:06 |
| benschubert | -the problem +one problem | 08:06 |
| juergbi | coldtom: what would the advantage be compared to a single repo per package? | 08:14 |
| coldtom | juergbi: migration of plugins between packages is easier, distro packagers only have to care about a single git repo for plugins, it's easier to upstream plugins because it's obvious where they need to go, maintenance cost of a single repo is less than the maintenance cost of half a dozen repos (at least afaict) | 08:18 |
| juergbi | it depends on who maintains which plugin, I suppose | 08:20 |
| juergbi | if different plugins are maintained by different (sets of) maintainers, I would definitely go for multiple repos | 08:20 |
| juergbi | if they are all co-maintained by the same group of BuildStream (core) developers, a single repo could make sense | 08:21 |
| juergbi | but in that case it could also be in the core repo | 08:21 |
| coldtom | i think there is still a benefit to being outside of the core repo, for example the ostree plugin was moved out of core for dependency reasons | 08:24 |
| juergbi | if the plugins are individually installable (which would also have to be the case for a single external repo), I don't see a real difference | 08:26 |
| *** mohan43u has joined #buildstream | 08:31 | |
| *** tpollard has joined #buildstream | 08:33 | |
| *** tiagogomes has joined #buildstream | 08:38 | |
| *** sistex has joined #buildstream | 08:43 | |
| traveltissues | coldtom, you can do that afair but it's messy | 08:46 |
| traveltissues | i tried it once and decided it was easier just to have separate repos | 08:47 |
| *** sistex is now known as ColdBoys | 08:47 | |
| *** santix has joined #buildstream | 08:56 | |
| *** lachlan has joined #buildstream | 09:09 | |
| *** jonathanmaw has joined #buildstream | 09:10 | |
| milloni | how does one set a http header when fetching the sources? | 09:21 |
| juergbi | milloni: I don't think we support setting arbitrary headers. what header do you need to set? | 09:22 |
| juergbi | depending on the use case a proxy or mirror could make sense | 09:22 |
| milloni | it's a header for authenticating with artifactory | 09:23 |
| milloni | jfrog artifactory | 09:24 |
| milloni | i assume i should push it to git instead | 09:24 |
| milloni | or maybe there's an artifactory plugin? | 09:25 |
| juergbi | not to my knowledger | 09:25 |
| juergbi | -r | 09:25 |
| benschubert | the source has support for netrc, would that be usable? | 09:27 |
| benschubert | *most supports have support for netrc | 09:27 |
| benschubert | *most sources, gosh I don't know how to type today | 09:28 |
| *** tristan has quit IRC | 09:34 | |
| *** lachlan has quit IRC | 10:03 | |
| *** ColdBoys has quit IRC | 10:13 | |
| *** lachlan has joined #buildstream | 10:14 | |
| milloni | actually does the "http" source have support for basic auth? | 10:16 |
| milloni | as in https://tools.ietf.org/html/rfc7617 | 10:16 |
| tpollard | basic enough where you can just put the auth in the uri string? | 10:17 |
| milloni | i dont know if that's what it does | 10:20 |
| milloni | basic auth is what happens when you go to a web page and there's a popup in the browser asking your for username and password | 10:20 |
| juergbi | milloni: I'd expect basic auth to be supported via netrc. is it not working or have you not tried yet? | 10:25 |
| milloni | noo, i just didnt know artifactory supported basic auth (of course it does!), i'll try that now | 10:26 |
| juergbi | milloni: I just checked, we have a test case that uses basic auth, afaict | 10:27 |
| milloni | ok, thanks | 10:28 |
| milloni | can you share a link to the test case? | 10:28 |
| milloni | i'm going to base my code on this | 10:28 |
| *** narispo has quit IRC | 10:28 | |
| *** narispo has joined #buildstream | 10:28 | |
| juergbi | milloni: https://gitlab.com/BuildStream/buildstream/blob/master/tests/sources/remote.py | 10:29 |
| milloni | thanks | 10:30 |
| *** lachlan has quit IRC | 10:31 | |
| milloni | juergbi: hm, so how do i pass my netrc to buildstream? is it just reading the host one? | 10:32 |
| juergbi | milloni: yes | 10:34 |
| juergbi | you normally don't want passwords in your project git | 10:34 |
| juergbi | it might make sense to support specifying an alternative path, though | 10:35 |
| milloni | yeah, this is just a quick experiment, i'm not doing anything for production (yet) | 10:36 |
| milloni | i dont even have a buildstream ci yet, its all loal | 10:36 |
| milloni | local | 10:36 |
| *** lachlan has joined #buildstream | 10:42 | |
| *** narispo has quit IRC | 10:43 | |
| *** lantw44 has quit IRC | 10:46 | |
| *** narispo has joined #buildstream | 10:46 | |
| *** lantw44 has joined #buildstream | 10:47 | |
| gitlab-br-bot | marge-bot123 merged MR !1635 (bschubert/partial-source-cache->master: Gracefully fallback to fetching source if remote doesn't have every blob cached) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1635 | 10:50 |
| gitlab-br-bot | cs-shadow closed issue #39 (Enhancement: `bst shell --builddir` automatically picking the newest available builddir) on buildstream https://gitlab.com/BuildStream/buildstream/issues/39 | 12:03 |
| gitlab-br-bot | cs-shadow closed issue #53 (Source support for workspaces) on buildstream https://gitlab.com/BuildStream/buildstream/issues/53 | 12:04 |
| *** lachlan has quit IRC | 12:10 | |
| gitlab-br-bot | cs-shadow closed issue #116 (BuildStream usually requires fusermount) on buildstream https://gitlab.com/BuildStream/buildstream/issues/116 | 12:11 |
| *** lachlan has joined #buildstream | 12:12 | |
| gitlab-br-bot | cs-shadow closed issue #123 (Dealing with rust) on buildstream https://gitlab.com/BuildStream/buildstream/issues/123 | 12:13 |
| gitlab-br-bot | cs-shadow closed issue #176 (CI runners timeout prematurely, losing time at startup) on buildstream https://gitlab.com/BuildStream/buildstream/issues/176 | 12:16 |
| gitlab-br-bot | cs-shadow closed issue #178 (Publish documentation for each stable branch + current development (master)) on buildstream https://gitlab.com/BuildStream/buildstream/issues/178 | 12:17 |
| gitlab-br-bot | cs-shadow closed issue #179 (Be smarter about querying summaries from remote caches) on buildstream https://gitlab.com/BuildStream/buildstream/issues/179 | 12:19 |
| tlater[m] | juergbi: Doesn't look like there's any existing way to do grpc proxying unfortunately | 12:22 |
| tlater[m] | I could use a generic handler and switch on the rpc name, but I might as well just do it per-rpc at that point | 12:23 |
| *** lachlan has quit IRC | 12:23 | |
| *** narispo has quit IRC | 12:23 | |
| *** narispo has joined #buildstream | 12:24 | |
| juergbi | tlater[m]: yes, it's probably anyway just a single line per method, right? | 12:24 |
| tlater[m] | Don't think it'll be much more than that, no :) | 12:24 |
| juergbi | ok, let's just go for that, then | 12:24 |
| *** tristan has joined #buildstream | 12:26 | |
| gitlab-br-bot | cs-shadow closed issue #199 (Test suite buildstream imports may be ambiguous) on buildstream https://gitlab.com/BuildStream/buildstream/issues/199 | 12:26 |
| gitlab-br-bot | cs-shadow closed issue #218 (Allow specifying the chroot binary to use for sandboxes on unix platforms) on buildstream https://gitlab.com/BuildStream/buildstream/issues/218 | 12:32 |
| tlater[m] | juergbi: I assume we want to bundle buildbox-casd with this artifact server, so that we don't *need* a third party server? | 12:37 |
| gitlab-br-bot | cs-shadow closed issue #222 (Allow running bst commands from workspace directory) on buildstream https://gitlab.com/BuildStream/buildstream/issues/222 | 12:38 |
| juergbi | tlater[m]: for now it should remain as is, keep depending on buildbox-casd, same as bst | 12:39 |
| juergbi | we could support making it a proxy for alternative CAS servers but I would hold off on that | 12:39 |
| juergbi | not sure whether there is really a need for it | 12:39 |
| tlater[m] | I suppose it's not much different anyway | 12:40 |
| tlater[m] | In either case, we need to send our RPCs to a server, all that changes is how we set up the client | 12:41 |
| juergbi | not in the proxying code itself | 12:41 |
| juergbi | just would require configuration for URL and possibly required authentication bits | 12:41 |
| * tlater[m] will keep it flexible in case we want to do proxying in the future | 12:41 | |
| juergbi | and then disabling casd launch | 12:41 |
| tlater[m] | I guess we have this implemented in buildstream itself now anyway | 12:41 |
| juergbi | switching to different CAS for storage? | 12:42 |
| juergbi | if that's what you mean, yes, that's why I'm not sure whether there is really a need for proxying to other servers | 12:42 |
| juergbi | and we need to finish discussing plans for a scalable server before further work | 12:43 |
| tlater[m] | Yup, that makes sense | 12:45 |
| gitlab-br-bot | marge-bot123 closed issue #1094 (Check whether progress reporting could be incorrect in certain cases (technical debt)) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1094 | 12:45 |
| gitlab-br-bot | marge-bot123 merged MR !1608 (tlater/progress-tests->master: Improve assertions around element loading progress reporting) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1608 | 12:45 |
| tlater[m] | I was reading through https://mail.gnome.org/archives/buildstream-list/2019-September/msg00006.html, which made me muddle proxying into this | 12:45 |
| tpollard | benschubert: I've just come to rebasing my multiprocess branch against master, and i've hit where you've added the childwatchers in the scheduler async for casd | 12:46 |
| gitlab-br-bot | cs-shadow closed issue #284 (Source distribution cannot include symlinks) on buildstream https://gitlab.com/BuildStream/buildstream/issues/284 | 12:46 |
| benschubert | tpollard: is it causing problems? | 12:46 |
| tpollard | from what I understand this is troublesome, as that pid is no longer a child of the forked process | 12:47 |
| benschubert | why? Is the frontend starting casd now? That would seem wrong to me :) | 12:47 |
| tpollard | calling the childwatchers _do_waitpid before / after forking seems to prove this | 12:47 |
| tpollard | I've not altered how casd is launched, I'd have to track that down | 12:48 |
| benschubert | yeah i think it's better that the backend would start casd | 12:48 |
| tpollard | I currently fork when build is called | 12:48 |
| benschubert | I'm not sure why we would ever need it in the frontend | 12:48 |
| benschubert | unless we don't fork for 'show' ? Then we might need to have this split | 12:49 |
| tpollard | currently I'm not forking for 'show', I don't think it's worth it either | 12:50 |
| tpollard | I'll look where CASCache() is created | 12:51 |
| gitlab-br-bot | cs-shadow closed issue #310 (`bst source-bundle` should get better documentation and receive test cases) on buildstream https://gitlab.com/BuildStream/buildstream/issues/310 | 12:52 |
| tpollard | I *think* the status widget is what first causes us to initialise the cas object, in turn the subprocess | 12:56 |
| *** santix has quit IRC | 12:56 | |
| gitlab-br-bot | cs-shadow closed issue #322 (Pylint should probably complain about our ostree imports in CI) on buildstream https://gitlab.com/BuildStream/buildstream/issues/322 | 12:58 |
| tpollard | which is very much the frontend | 13:00 |
| *** akvilebirgelyte_ has joined #buildstream | 13:03 | |
| *** santix has joined #buildstream | 13:11 | |
| *** akvilebirgelyte_ has quit IRC | 13:12 | |
| gitlab-br-bot | tlater opened issue #1167 (Make the bst-artifact-server proxy CAS storage calls to buildbox-casd) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1167 | 13:13 |
| *** akvilebirgelyte_ has joined #buildstream | 13:17 | |
| *** lachlan has joined #buildstream | 13:31 | |
| *** lachlan has quit IRC | 13:37 | |
| *** lachlan has joined #buildstream | 13:40 | |
| gitlab-br-bot | cs-shadow closed issue #326 (undocumented behaviour when Buildstream rebuilds all elements locally) on buildstream https://gitlab.com/BuildStream/buildstream/issues/326 | 13:45 |
| benschubert | tpollard: why does the status widget needs cas? Oo | 13:50 |
| benschubert | oh the cache size? | 13:51 |
| tpollard | yes | 13:51 |
| tpollard | calls get_cascache(), which will in-turn init the cas if it's not already done so | 13:52 |
| benschubert | I see 3 ways then: 1) forward that from the backend, 2) start cas in backend, send socket to frontend, 3) start in frontend, and attach a watcher in the frontend | 13:52 |
| gitlab-br-bot | cs-shadow closed issue #365 (gir1-ostree version is wrong on Debian stable) on buildstream https://gitlab.com/BuildStream/buildstream/issues/365 | 13:52 |
| tpollard | benschubert: as we'll eventually need a loop in the part of stream which exists in the front process, I think option 3 is the likely final outcome | 13:55 |
| tpollard | which is only needed when we're running in a multiprocess, existing paths are fine as is | 13:56 |
| tpollard | (although I do agree that on a more broad point the launch the casd process should be a 'back end' task) | 13:58 |
| *** lachlan has quit IRC | 14:25 | |
| *** lachlan has joined #buildstream | 14:27 | |
| *** narispo has quit IRC | 14:41 | |
| *** narispo has joined #buildstream | 14:41 | |
| *** akvilebirgelyte_ has quit IRC | 14:42 | |
| *** akvilebirgelyte_ has joined #buildstream | 14:43 | |
| milloni | can buildstream (by default) access the network from inside the sandbox? | 14:51 |
| juergbi | milloni: no, not from the build sandbox | 14:53 |
| milloni | cool, i like it | 14:55 |
| *** narispo has quit IRC | 14:59 | |
| *** narispo has joined #buildstream | 14:59 | |
| tlater[m] | juergbi: Hrm, I guess when the other services interact with casd they'll need to send requests to casd as well, right? | 15:10 |
| juergbi | tlater[m]: as in timestamp updates / checking whether the blobs are there? | 15:11 |
| tlater[m] | That's interesting, because some of these methods rely on accessing the files directly | 15:11 |
| tlater[m] | i.e. CASCache.objpath | 15:11 |
| juergbi | yes, we should probably replace that. although, we could theoretically also just do the proxy thing for the CAS protocol itself and leave the rest for now | 15:14 |
| juergbi | if it's easy enough to do everything via casd, that's probably best, though | 15:14 |
| tlater[m] | juergbi: yup | 15:17 |
| tlater[m] | ByteStream seems to be fond of doing these things | 15:17 |
| juergbi | ah, yes, but ByteStream should be a straight proxy | 15:19 |
| juergbi | I thought you were talking about Artifact/Source service | 15:19 |
| *** traveltissues has quit IRC | 15:27 | |
| gitlab-br-bot | TheRealMichaelCatanzaro closed issue #221 (Allow custom user specified URL for upstream inside workspaces) on buildstream https://gitlab.com/BuildStream/buildstream/issues/221 | 15:31 |
| *** lachlan has quit IRC | 15:32 | |
| *** santix has quit IRC | 15:42 | |
| *** lachlan has joined #buildstream | 15:46 | |
| *** tpollard has quit IRC | 15:47 | |
| *** santix has joined #buildstream | 15:57 | |
| *** lachlan has quit IRC | 16:30 | |
| gitlab-br-bot | cs-shadow closed issue #497 (Document cache quota 2GB headroom restriction) on buildstream https://gitlab.com/BuildStream/buildstream/issues/497 | 16:35 |
| *** phildawson_ has quit IRC | 16:42 | |
| *** lachlan has joined #buildstream | 16:43 | |
| *** santix has quit IRC | 17:00 | |
| *** jonathanmaw has quit IRC | 17:04 | |
| *** tiagogomes has quit IRC | 17:19 | |
| *** lachlan has quit IRC | 17:27 | |
| *** phoenix has joined #buildstream | 18:04 | |
| gitlab-br-bot | cs-shadow closed issue #903 (buildstream should inmediatelly fail if ostree < v2017.8 is installed) on buildstream https://gitlab.com/BuildStream/buildstream/issues/903 | 18:05 |
| *** bochecha_ has joined #buildstream | 18:13 | |
| gitlab-br-bot | cs-shadow closed issue #907 (Pipelines are taking a lot of time to finish (~140 min)) on buildstream https://gitlab.com/BuildStream/buildstream/issues/907 | 18:15 |
| gitlab-br-bot | cs-shadow closed issue #934 (Support incremental builds with workspaces + remote execution) on buildstream https://gitlab.com/BuildStream/buildstream/issues/934 | 18:17 |
| *** narispo has quit IRC | 18:44 | |
| *** narispo has joined #buildstream | 18:47 | |
| *** phoenix has quit IRC | 19:17 | |
| *** lachlan has joined #buildstream | 19:36 | |
| *** phoenix has joined #buildstream | 20:26 | |
| *** lachlan has quit IRC | 20:48 | |
| *** narispo has quit IRC | 21:01 | |
| *** narispo has joined #buildstream | 21:01 | |
| *** phoenix has quit IRC | 21:27 | |
| *** phoenix has joined #buildstream | 21:32 | |
| *** phoenix has quit IRC | 22:29 | |
| *** bochecha_ has quit IRC | 22:39 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!