| *** anjii has joined #buildstream | 00:58 | |
| *** anjii has quit IRC | 01:00 | |
| *** bochecha has joined #buildstream | 02:40 | |
| *** bochecha has quit IRC | 02:57 | |
| *** noah has quit IRC | 02:58 | |
| *** bochecha has joined #buildstream | 03:36 | |
| *** bochecha has quit IRC | 03:38 | |
| *** bochecha has joined #buildstream | 03:38 | |
| *** bochecha has quit IRC | 03:43 | |
| *** bochecha has joined #buildstream | 04:25 | |
| *** tristan has joined #buildstream | 06:57 | |
| *** WSalmon has joined #buildstream | 07:56 | |
| *** WSalmon has quit IRC | 07:58 | |
| *** adds68 has joined #buildstream | 08:35 | |
| *** jude has joined #buildstream | 09:08 | |
| gitlab-br-bot | buildstream: issue #151 ("Link from https://people.gnome.org/~tvb/buildstreamdocs/ to https://buildstream.gitlab.io/buildstream/") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/151 | 09:29 |
|---|---|---|
| *** tiagogomes has joined #buildstream | 09:41 | |
| *** valentind has joined #buildstream | 09:42 | |
| *** jonathanmaw has joined #buildstream | 09:47 | |
| *** honza has joined #buildstream | 09:51 | |
| *** tiagogomes has quit IRC | 09:53 | |
| *** tiagogomes has joined #buildstream | 09:55 | |
| *** tpollard has joined #buildstream | 10:00 | |
| *** honza has quit IRC | 10:03 | |
| *** ssam2 has joined #buildstream | 10:08 | |
| gitlab-br-bot | buildstream: issue #153 ("Unhandled exception in utils._force_rmtree()") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/153 | 10:24 |
| *** bochecha has quit IRC | 10:25 | |
| *** jude has quit IRC | 10:32 | |
| *** semanticdesign has joined #buildstream | 10:34 | |
| *** inigomartinez has joined #buildstream | 10:41 | |
| *** jude has joined #buildstream | 10:48 | |
| *** WSalmon has joined #buildstream | 11:15 | |
| *** valentind has quit IRC | 11:32 | |
| tristan | jonathanmaw, what do you mean "args that switch between different behaviours in functions" ? | 11:33 |
| jonathanmaw | tristan: functions like Element.dependencies, and ts "recurse" arg | 11:34 |
| jonathanmaw | *its | 11:34 |
| *** bethw has joined #buildstream | 11:39 | |
| tristan | jonathanmaw, I'm so confused, what does "switch between different behaviours" mean here | 11:42 |
| tristan | you mean, the behavior changes depending on the argument value ? | 11:43 |
| tristan | recurse is going to be a mandatory keyword argument right ? | 11:43 |
| tristan | jonathanmaw, anyway it's not immensely important, as I mentioned in the comment, *how* the function is invoked; but if we're making something explicitly an optional argument; it seems nice to leverage that and use it as such (especially if we're going and changing the callers anyway) | 11:45 |
| tristan | the `default` parameter of Plugin.node_get_member() and Element.node_subst_member() is... very much like python's dict `.get()` method second argument | 11:46 |
| tristan | i.e. instead of raising hell of the member doesnt exist, return this instead | 11:46 |
| tristan | s/of/if | 11:46 |
| jonathanmaw | okay. I'll make the changes to node_{get,subst}_member, and see if I can see any other cases where that logic requires me to make changes. | 11:47 |
| tristan | I think you got Plugin.node_get_member() correctly, but for some reason didnt do Element.node_subst_member() in the same way | 11:48 |
| *** WSalmon_ has joined #buildstream | 11:58 | |
| *** WSalmon has quit IRC | 11:58 | |
| *** tristan has quit IRC | 12:02 | |
| *** bethw has quit IRC | 12:10 | |
| *** tristan has joined #buildstream | 12:20 | |
| tlater | It looks like our CI currently downloads two different versions of the gnome-sdk | 12:31 |
| tlater | That might explain why it takes so long | 12:31 |
| tlater | Perhaps we should run a `bst track` on the integration tests at some point? | 12:31 |
| tristan | tlater, there was a change which happened for some reason | 12:34 |
| tristan | tlater, and it does deeper than that | 12:34 |
| tristan | it installs the SDK twice (one runtime one sdk) | 12:34 |
| tristan | because we still didnt teach it how to properly do the symlink thin | 12:34 |
| tristan | g | 12:34 |
| tristan | anyway we have 2 different refs I think it's since the pip tests but dont recall, one of the tests needed a fresher version | 12:35 |
| tlater | Is that deliberate? I feel saving some time on the CI might be worth the slight inconsistency between what we tested on two months ago and now. | 12:36 |
| tristan | wat ?! | 12:39 |
| tristan | tlater, ah you mean separate versions ? | 12:39 |
| tlater | tristan: Yes | 12:39 |
| tristan | tlater, no, the person (I dont recall) who updated the new ref for the new reason, was not as anal as I am | 12:39 |
| tristan | and did not go ahead and update the ref for all the other tests, unfortunately | 12:40 |
| tristan | I noticed this while moving integration-tests in from buildstream-tests repo | 12:40 |
| tristan | What should be done: A.) Use the new ref all around, B.) dont stage *both* gnome-platform and gnome-sdk, only the sdk with the proper symlinks trick | 12:40 |
| tristan | which can be found in gnome-modulesets-base repo, there is the correct way to do it | 12:41 |
| tristan | Also, possibly updating the base causes binary output to be different, in which case, integration tests should be refactored as mentioned in a bug report I filed | 12:41 |
| * tlater Checks the issues for now, and adds one if we don't have one yet :) | 12:41 | |
| tristan | so that it doesnt test for bit for bit sameness causing tests upgrades to be a royal pain in the arse | 12:42 |
| *** cs_shadow has joined #buildstream | 12:45 | |
| *** bethw has joined #buildstream | 13:01 | |
| *** WSalmon_ has quit IRC | 13:03 | |
| gitlab-br-bot | push on buildstream@97-apply-pep-3102-to-all-public-api-surfaces (by Jonathan Maw): 18 commits (last: load.py: Migrate to new test style) https://gitlab.com/BuildStream/buildstream/commit/25f6bec66a742cf96e45ed4f2e16bbcde972174b | 13:07 |
| gitlab-br-bot | buildstream: merge request (97-apply-pep-3102-to-all-public-api-surfaces->master: WIP: Resolve "Apply pep 3102 to all public API surfaces") #127 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/127 | 13:07 |
| gitlab-br-bot | buildstream: merge request (fixupimports->master: Refactor, remove some unused imports) #149 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/149 | 13:15 |
| gitlab-br-bot | buildstream: merge request (fixup_internal->master: _variables: refactor, private 'subst_internal') #150 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/150 | 13:28 |
| *** tiagogomes has quit IRC | 13:31 | |
| *** tiagogomes has joined #buildstream | 13:37 | |
| *** adds68 has quit IRC | 13:48 | |
| *** adds68 has joined #buildstream | 13:48 | |
| *** WSalmon_ has joined #buildstream | 14:03 | |
| *** givascu has quit IRC | 14:16 | |
| gitlab-br-bot | buildstream: merge request (fixup_internal->master: _variables: refactor, private 'subst_internal') #150 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/150 | 15:15 |
| *** bochecha has joined #buildstream | 15:18 | |
| ssam2 | I think 'elements' wasn't a great name for the package that bst-external.git installs | 15:19 |
| ssam2 | as it will conflict with any other python project that installs a package named 'elements' | 15:19 |
| ssam2 | such as, another buildstream plugins repo | 15:19 |
| ssam2 | or https://pypi.python.org/pypi/Elements/0.2.0 | 15:20 |
| tlater | Oh, that's probably my fault, I just used 'elements' temporarily... It could technically be anything, it's not used in the actual code iirc. | 15:21 |
| ssam2 | makes sense | 15:21 |
| ssam2 | we should probably rename to bst_external | 15:21 |
| tlater | Hmm... I still can't reproduce what gitlab does here at all: https://gitlab.com/BuildStream/buildstream/-/jobs/40083920 | 15:24 |
| tlater | The test just succeeds fine for me | 15:24 |
| tlater | That is, after replicating the exact environment with docker. There is no way outside of running gitlab-runner locally to get that container, is there? | 15:26 |
| gitlab-br-bot | push on buildstream@tracking-changes (by Tristan Maat): 14 commits (last: doc/source/docker.rst: Fix formatting) https://gitlab.com/BuildStream/buildstream/commit/5530bab052c25fe2c16f8f2116ca468b6a895174 | 15:29 |
| gitlab-br-bot | buildstream: merge request (tracking-changes->master: WIP: Tracking changes) #119 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/119 | 15:29 |
| gitlab-br-bot | push on buildstream@except_intersections (by Tristan Maat): 8 commits (last: doc/source/docker.rst: Fix formatting) https://gitlab.com/BuildStream/buildstream/commit/5530bab052c25fe2c16f8f2116ca468b6a895174 | 15:29 |
| gitlab-br-bot | push on buildstream@131-behavior-of-except-argument-is-frustrating-and-confusing (by Tristan Maat): 8 commits (last: doc/source/docker.rst: Fix formatting) https://gitlab.com/BuildStream/buildstream/commit/5530bab052c25fe2c16f8f2116ca468b6a895174 | 15:30 |
| gitlab-br-bot | buildstream: merge request (131-behavior-of-except-argument-is-frustrating-and-confusing->master: WIP: Resolve "Behavior of --except argument is frustrating and confusing") #147 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/147 | 15:30 |
| gitlab-br-bot | buildstream: merge request (fixupimports->master: Refactor, remove some unused imports) #149 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/149 | 15:38 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 1 commit (last: Refactor, remove some unused imports) https://gitlab.com/BuildStream/buildstream/commit/cc6e09ce63c7576bd3f258515946e38a945903f4 | 15:38 |
| gitlab-br-bot | buildstream: Tristan Maat created branch 138-aborting-bst-push-command-causes-stack-trace | 15:53 |
| *** jude has quit IRC | 16:17 | |
| *** jude_ has joined #buildstream | 16:17 | |
| *** jude_ has quit IRC | 16:24 | |
| tlater | Do we host a docker container set up specifically to be an artifact share yet? I think that could be handy. | 16:38 |
| ssam2 | yes that would be handy | 16:42 |
| ssam2 | i do have ansible scripts that set one up | 16:42 |
| ssam2 | https://gitlab.com/baserock/infrastructure/tree/master/baserock_ostree | 16:42 |
| ssam2 | (first run image-config, then instance-config) | 16:43 |
| ssam2 | that assumes Fedora VM, and would need some modification for Docker, but it's a useful reference | 16:43 |
| ssam2 | also such a thing could reuse the existing CI infrastructure in our docker-images repo | 16:44 |
| * tlater is sort of building one for testing things right now, may set up a MR for that if I can work out how to make it configurable | 16:47 | |
| tlater | Main issue is https | 16:47 |
| tlater | I think it would be a poor idea to publish an image that makes it easy to serve with http | 16:47 |
| ssam2 | tricky though, the best we could do is generate a self-signed certificate on startup | 16:50 |
| ssam2 | getting a real cert requires a domain | 16:50 |
| tlater | ssam2: Yeah, that however makes the image only useful for testing. | 16:51 |
| ssam2 | or usage inside trusted networks | 16:52 |
| tlater | I have seen docker image setups that allow including certificates before. | 16:52 |
| tlater | Maybe it's worth putting in the effort to see how that works | 16:52 |
| tlater | That said, I've figured out how to reproduce the segfault \o/ It doesn't look to be a segfault though, and is a bit harder to debug because it's in a container :/ | 16:54 |
| ssam2 | good that you can reproduce it | 16:57 |
| tlater | Gah, buildstream really hates being run inside a docker volume | 17:08 |
| ssam2 | ? | 17:09 |
| tlater | 'WARNING Unable to create user namespaces with bubblewrap, resorting to fallback' | 17:10 |
| ssam2 | is that with --privileged ? | 17:12 |
| tlater | ssam2: Yup | 17:12 |
| ssam2 | hmm, maybe there's another thing needed | 17:12 |
| tlater | Oh, nevermind, looks like I forgot that | 17:12 |
| tlater | -.- | 17:12 |
| ssam2 | see https://gitlab.com/BuildStream/buildstream/blob/master/contrib/bst-here | 17:12 |
| ssam2 | we also pass `--security-opt seccomp=undefined` | 17:12 |
| *** xjuan has joined #buildstream | 17:16 | |
| *** valentind has joined #buildstream | 17:23 | |
| *** csoriano has joined #buildstream | 17:29 | |
| ssam2 | hi csoriano :-) | 17:29 |
| csoriano | hello, I was trying buildstream for building gtk+-3 | 17:29 |
| csoriano | now I did that because I'm developing a patch for gtk+3 that includes a new library | 17:30 |
| csoriano | I need two things: one is to include this library wherever gtk+ is built | 17:30 |
| csoriano | two, pass a parameter to meson configure | 17:30 |
| csoriano | I got stuck in the former, I didn't know where to put this library, since all is opaque | 17:30 |
| csoriano | ssam2: hi :) | 17:31 |
| tristan | csoriano, I need to understand "include this library wherever gtk+ is built" | 17:34 |
| tristan | is "depend on it" the same thing ? | 17:35 |
| csoriano | tristan: yes, it's an optional dependency | 17:35 |
| csoriano | yeah I used a bad wording :/ | 17:35 |
| tristan | okay, so the current GNOME modulesets is currently driven by jhbuild conversions, and builds against a debootstraped base runtime | 17:36 |
| tristan | The debootstrap base runtime will probably go away after freedesktop-sdk project materializes something we can use for both flatpak runtimes & GNOME system builds | 17:37 |
| tristan | so there is a bit of flux | 17:37 |
| tristan | csoriano, would you consider this optional dependency a "sysdep" basically ? | 17:37 |
| tristan | csoriano, sysdeps currently is just a list of packages coming from debian testing: https://gitlab.com/BuildStream/debootstrap-ostree/blob/master/data/multistrap.conf.in | 17:38 |
| csoriano | tristan: no, it probably needs to be like glib | 17:38 |
| tristan | a patch to that file, will make the dependency available | 17:38 |
| tristan | okay, so something you need to add to like, core-deps basically ? | 17:38 |
| csoriano | tristan: I think so, yeah | 17:39 |
| tristan | csoriano, until we make a hard switch; adding it to core-deps in the 3.28 modulesets will cause it to automatically get converted and magically appear | 17:39 |
| csoriano | tristan: it's not in Jhbuild yet. Can I use buildstream for that? And in an ideal world, how would it be the workflow for this? | 17:40 |
| tristan | I have been making changes to the jhbuild modulesets so that they effect the buildstream based builds | 17:40 |
| tristan | So in a world after doing the hard switch and not converting the modulesets anymore, you would add a new element in elements/core-deps... | 17:41 |
| * tristan gets url | 17:41 | |
| tristan | csoriano, http://gnome7.codethink.co.uk/cgit/gnome-modulesets/tree/ | 17:41 |
| csoriano | tristan: that means I would need to build Buildstream? No right? | 17:41 |
| tristan | e.g. here: http://gnome7.codethink.co.uk/cgit/gnome-modulesets/tree/elements/core-deps/glib.bst | 17:41 |
| tristan | BuildStream is python and doesnt really need to be "built" | 17:42 |
| csoriano | tristan: right | 17:42 |
| csoriano | tristan: reading that, I guess there is some "kind: local" then? | 17:42 |
| tristan | so BuildStream is the only thing you really need on your "host" | 17:42 |
| csoriano | because I'm modifying the library and gtk+ at the same time | 17:42 |
| tristan | now I'm not following.... | 17:42 |
| tristan | ah | 17:43 |
| tristan | ok so, no | 17:43 |
| csoriano | tristan: I'm creating a library that gtk+ depends on | 17:43 |
| csoriano | imagine gtksourceview | 17:43 |
| tristan | csoriano, for that you want a workspace | 17:43 |
| csoriano | that's probably a better example | 17:43 |
| tristan | https://wiki.gnome.org/Newcomers/BuildSystemComponentBst#Developing | 17:43 |
| csoriano | yeah I did that for gtk+ | 17:43 |
| csoriano | now how do I for putting my library inside this? | 17:43 |
| tristan | csoriano, so is there any upstream git yet ? it would help if it existed like, on github or anywhere | 17:44 |
| csoriano | yeah, but I need to test locally | 17:44 |
| csoriano | like what would you do with gtksourceview when testing from gtk+ right? | 17:44 |
| tristan | So, create an element in core-deps/myfancylib.bst | 17:44 |
| tristan | which points to your upstream, and create a workspace for it | 17:45 |
| tristan | once you do `bst track core-deps/myfancylib.bst`, then you can create a workspace for it | 17:45 |
| csoriano | and the changes in that workspace will be reflected in the gtk+ workspace? | 17:45 |
| tristan | If I was hacking on gtksourceview and gtk+, I'd open two workspaces | 17:46 |
| tristan | csoriano, opening a workspace will cause the workspace sources to be used in builds of that project, as long as the workspace is open | 17:46 |
| tristan | csoriano, so yes it will | 17:46 |
| tristan | csoriano, i.e. lets pretend you are only working on GTK+ | 17:47 |
| tristan | and you want to test epiphany | 17:47 |
| tristan | so you built everything once, you have your webkit and everything | 17:47 |
| tristan | you are setup with --no-strict | 17:47 |
| tristan | (there is a user config for that on the wiki page) | 17:47 |
| *** WSalmon_ has quit IRC | 17:48 | |
| tristan | csoriano, then, the changes you make to GTK+, after a build... will be effective in the sandbox of epiphany | 17:48 |
| tristan | same sort of thing | 17:48 |
| * tristan not sure if he explained that very clearly | 17:49 | |
| tristan | csoriano, maybe if I just explain the meaning if "strict", i.e. the config option I recommend for hacking, here: https://wiki.gnome.org/Newcomers/BuildSystemComponentBst#Configuring_BuildStream | 17:49 |
| csoriano | tristan: yeah I'm using no-strict, I'm just following that guide | 17:49 |
| csoriano | (btw, very bad there is no instructions for Fedora, cmon :P) | 17:50 |
| tristan | So "strict" means, rebuild reverse dependencies whenever something changes | 17:50 |
| csoriano | I think you explained well, let me chew... | 17:50 |
| tristan | csoriano, yeah you mean in BuildStream itself ? I just need a package list... | 17:50 |
| tristan | and I can add a section to the docs | 17:50 |
| tristan | I think jjardon[m] is the guy who uses arch, and he sent us a patch for the docs for arch (iirc) | 17:51 |
| csoriano | tristan: ok, so I have two different workspaces, whatever I build in there they are reflected in both | 17:52 |
| csoriano | so it's kinda like jhbuild | 17:52 |
| csoriano | they share the same "prefix" | 17:52 |
| csoriano | right? | 17:52 |
| tristan | There is no "prefix" in that sense | 17:52 |
| tristan | every time a build or a shell occurs, the output of every element is staged on demand using hardlinks | 17:53 |
| csoriano | yeah I imagined, that's what makes me a little confused | 17:53 |
| tristan | so prefix is actually /usr, in a chroot-like (bubblewrap actually) sandbox | 17:53 |
| *** ssam2 has quit IRC | 17:54 | |
| tristan | csoriano, so basically you need to *also* make the GTK+ depend on your new element | 17:54 |
| tristan | when you build GTK+, or anything that depends on GTK+, your new element's output will also be "staged" into the sandbox | 17:54 |
| *** bochecha has quit IRC | 17:54 | |
| tristan | (likewise, if you `bst shell` on any element that depends on GTK+, same thing) | 17:55 |
| csoriano | aha | 17:55 |
| csoriano | so.. when I open a shell, it will realize there are changes (even if no commited) and will pu that in a ostree fashion to be part of the build of gtk+, kinda right? | 17:56 |
| tristan | hehe kinda :) | 17:57 |
| csoriano | so if I don't want gtk+ to take into account my changes in this other library, I just need to close the shell/workspace of rhtat library right? | 17:57 |
| tristan | csoriano, anyway if you try to open a shell, it will complain if it's not already built | 17:57 |
| tristan | exactly yes | 17:57 |
| csoriano | perfect, I got it | 17:57 |
| tristan | you can close the workspace and then the original upstream will be used instead | 17:57 |
| csoriano | tristan: I don't we can expect much to understand the underlaying. Would be good to have these examples in a really easy way | 17:58 |
| csoriano | like how you said them | 17:58 |
| tristan | myeah... docs are tricky things... I am quite verbose in general, but trying to keep things bite sized | 17:59 |
| csoriano | and kudos for the work, it's definitely a big improvement versus jhbuild. I was happy to have latest gtk+ so fast | 17:59 |
| tristan | otherwise you look at the wiki page and it's huge :-S | 17:59 |
| csoriano | tristan: imho, you did really well in /Newcomers wiki | 18:00 |
| csoriano | so keep that spirit I guess :D | 18:00 |
| tristan | thanks :) ... we do have an ongoing project for documenting things in a howto guide kind of form | 18:00 |
| tristan | asides from the reference, which, I think the reference is really handy actually, but it's a bit terse | 18:01 |
| tristan | csoriano, especially this part can be handy once you get the feel for the basics: http://buildstream.gitlab.io/buildstream/pluginindex.html#plugins | 18:01 |
| tristan | shows how each plugin can be used whenever you need to know | 18:02 |
| tristan | (each element or source) | 18:02 |
| *** bethw has quit IRC | 18:03 | |
| csoriano | I see | 18:03 |
| tristan | Anyway I think jonathanmaw got started on that writing of a guide, but it was interrupted by blockers :-/ | 18:04 |
| csoriano | just some feedback for the wiki in Newcomers, I didn't get much the difference between shell and track , etc. At some point it says "now downloads the sources" but later on also downloads the sources since I can see in the output a regular git clone | 18:04 |
| tristan | I'll see if we can try to prioritize that again :) | 18:04 |
| csoriano | maybe it's a bug rather than bad docs though | 18:05 |
| csoriano | I think providing the basics for the GNOME devs it's enough | 18:05 |
| tristan | csoriano, that is intentional but I admit a little confusing | 18:05 |
| csoriano | for that we don't really need to know how it works or the plugins and what does it support | 18:05 |
| csoriano | but just like "do this to build two sources" and that's it | 18:06 |
| csoriano | ah ok | 18:06 |
| tristan | the point of `bst track` is to find the latest reference for a given branch, and the point of `bst fetch` (automatically part of `bst build`) is to actually obtain the sources | 18:06 |
| tristan | Currently though, most implementations do `fetch` as a side effect of `track` | 18:06 |
| tristan | We hope to improve that so that for instance, you dont need to checkout *all* the linux kernel history, if you're only interested in building a given stable branch | 18:07 |
| csoriano | tristan: then the docs saying "track downloads the sources" is wrong | 18:07 |
| csoriano | in the wiki | 18:07 |
| csoriano | I wouldn't worry much about it, seems it's fast and not requiring lot of space so far, compared to jhbuild | 18:07 |
| tristan | Indeed, however the effect is that, ok I'll try to clarify that | 18:07 |
| *** mcatanzaro has joined #buildstream | 18:08 | |
| tristan | csoriano, I was writing that with a perspective that, people will use this recommended workflow, and then learn the tooling later... | 18:08 |
| tristan | csoriano, however indeed, it's misleading in the sense that; people will take home the wrong thing from that sentence | 18:08 |
| tristan | csoriano, I'm surprised you say that it's not requiring a lot of space... technically; it should require *more* disk space haha | 18:09 |
| tristan | because no host tools | 18:09 |
| tristan | but if it's going well, I'm happy for that :D | 18:09 |
| csoriano | tristan: ah yeah. Yeah it's just a detail, it was just slightly confusing seeing things happenings multiple times (or that was the impression) | 18:10 |
| csoriano | idk, 4'1 GB here | 18:11 |
| csoriano | for jhbuild build gtk+ was definitely more | 18:11 |
| tristan | I'm trying to get at least the base always built on the artifact server, so that you dont need to have the base system *twice* on a developers machine, and then it only changes when sysdeps change | 18:11 |
| *** jonathanmaw has quit IRC | 18:11 | |
| csoriano | yeah, that's really helpfukl | 18:11 |
| tristan | yeah GTK+ is pretty low in the stack, when you run `bst build core/meta-gnome-core.bst apps/meta-gnome-apps-tested.bst` ... it takes a bunch more space | 18:12 |
| * tristan guesses sources cost more than build outputs in general, too | 18:13 | |
| tristan | or "artifacts" as we like to call them | 18:13 |
| *** givascu has joined #buildstream | 18:14 | |
| csoriano | yeah | 18:17 |
| *** valentind has quit IRC | 18:43 | |
| *** valentind has joined #buildstream | 18:45 | |
| *** bethw has joined #buildstream | 18:46 | |
| *** semanticdesign has quit IRC | 18:54 | |
| *** semanticdesign has joined #buildstream | 18:54 | |
| *** semanticdesign has quit IRC | 19:15 | |
| *** semanticdesign has joined #buildstream | 19:15 | |
| *** bethw has quit IRC | 19:23 | |
| *** bethw has joined #buildstream | 19:53 | |
| *** givascu has quit IRC | 20:27 | |
| *** tristan has quit IRC | 20:28 | |
| *** semanticdesign has quit IRC | 20:46 | |
| *** semanticdesign has joined #buildstream | 20:48 | |
| *** semanticdesign has quit IRC | 20:56 | |
| *** semanticdesign has joined #buildstream | 20:57 | |
| *** semanticdesign has quit IRC | 21:02 | |
| *** tristan has joined #buildstream | 21:02 | |
| *** jude has joined #buildstream | 21:15 | |
| *** jude has quit IRC | 21:27 | |
| *** noah has joined #buildstream | 21:38 | |
| *** noah has quit IRC | 21:48 | |
| *** noah has joined #buildstream | 21:54 | |
| *** noah has quit IRC | 22:22 | |
| *** xjuan has quit IRC | 22:33 | |
| *** tristan has quit IRC | 22:56 | |
| *** bethw has quit IRC | 23:18 | |
| *** valentind has quit IRC | 23:21 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!