| *** bochecha has quit IRC | 00:11 | |
| *** jonathanmaw has joined #buildstream | 09:19 | |
| *** bochecha has joined #buildstream | 09:33 | |
| *** bethw has joined #buildstream | 09:55 | |
| *** noah has joined #buildstream | 10:19 | |
| *** noah has joined #buildstream | 10:22 | |
| *** noisecell has joined #buildstream | 10:32 | |
| *** noah has quit IRC | 10:54 | |
| *** noah has joined #buildstream | 11:27 | |
| *** jonathanmaw has quit IRC | 11:55 | |
| tlater | Having finally read into flatpak, I understand that their runtime has to be mounted under /usr of an existing rootfs? | 12:13 |
|---|---|---|
| * tlater isn't sure how this will reduce IO, given that we still need both the sdk and the runtime, as well as an independent rootfs. | 12:13 | |
| *** xjuan has joined #buildstream | 12:21 | |
| bochecha | tlater: I don't think there's an existing rootfs for flatpak | 12:25 |
| bochecha | it just starts a bubblewrap sandbox and mounts the runtime in /usr, the app in /app | 12:26 |
| *** noah has quit IRC | 12:30 | |
| tlater | We have been using a flatpak runtime as the rootfs for our integration tests | 12:37 |
| bochecha | what I meant is you were saying "their runtime has to be mounted under /usr of an existing rootfs" | 12:40 |
| bochecha | their runtime gets mounted on top of nothing, afaik | 12:40 |
| bochecha | it's basically just `bwrap --ro-bind /path/to/runtime /usr --ro-bind /path/to/app /app ...` | 12:41 |
| *** mcatanzaro has joined #buildstream | 12:42 | |
| tlater | I seem to be lacking /bin/sh when I do so, I guess that's down to buildstream to fix, though. | 12:44 |
| bochecha | right, so flatpak will mount the runtime in /usr AND set the symlinks /bin -> /usr/bin, etc... | 12:46 |
| tlater | Ah, right, I get it | 12:46 |
| tlater | ta bochecha :) | 12:47 |
| tlater | Although, tbf, I'm not sure that changes our IO rates much. | 12:47 |
| bochecha | I can't find it now, but back at GUADEC tristan had showed me a usermerge.bst element which would just drop the symlinks in place, so things would work with a flatpak-style sdk | 12:47 |
| bochecha | ha! https://gitlab.com/BuildStream/gnome-test-data/blob/flatpak-tests/elements/base/usrmerge.bst | 12:48 |
| bochecha | files/usrmerge contains the symlinks | 12:48 |
| bochecha | they just get dumped into the root of the bst sandbox for elements depending on it :) | 12:49 |
| tlater | Ah! | 12:49 |
| tlater | Now I understand! | 12:49 |
| tlater | The sdk also contains the runtime, then? | 12:49 |
| * tlater thinks it may be neater to create the symlinks using an integration command/staging element, but those are details | 12:50 | |
| tlater | s/staging/compose/ | 12:50 |
| bochecha | the sdk doesn't "contain" the runtime | 13:03 |
| bochecha | but flatpak-builder builds the sdk, then "removes" some files from it and calls the result "platform" | 13:04 |
| bochecha | (both sdk and platform are runtimes, the former is used for building and the latter for running) | 13:04 |
| bochecha | basically, you can think of the "platform" as a compose element which depends on the sdk element, copies the bits from / to %{install-root} then removes the files that are uninteresting at runtime | 13:05 |
| bochecha | (I meant a "manual" element) | 13:05 |
| bochecha | so the sdk contains all the files that are contained in the platform | 13:05 |
| bochecha | the files aren't rebuilt twice, they are build only once to make the sdk, then some are removed to make the platform | 13:06 |
| * tlater thought the sdk contained additional files required for building that weren't in the "runtime" | 13:06 | |
| tlater | I.e., it had to be staged on top of the "runtime" | 13:06 |
| persia | tlater: Other way: platform is constructed by reducing content of SDK | 13:06 |
| bochecha | "runtime" is the generic term in flatpak parlance, there are two kinds of runtimes: sdks and platforms | 13:06 |
| bochecha | tlater: the sdk is not staged on top of the platform, no | 13:06 |
| * tlater misunderstood the docs then | 13:07 | |
| bochecha | the sdk contains the build-only files, AND the files that are in the platform | 13:07 |
| tlater | tyvm, this makes so much more sense :) | 13:07 |
| bochecha | flatpak will always use a single runtime | 13:07 |
| tlater | Whoo, smaller testing runtimes! | 13:07 |
| bochecha | (I'm lying a bit here, it's slightly more complex, but it only concerns extensions, which by a historical implentation also happen to be runtimes, but not in the same way that the sdk/platform are) | 13:07 |
| bochecha | tlater: basically, I'm doing something a bit similat to what flatpak does here: https://framagit.org/bochecha/org.ideascube.Sdk/blob/devel/elements/sdk.bst | 13:08 |
| bochecha | I build an sdk with buildstream | 13:08 |
| bochecha | then I subsctract parts of it and call that the platform: https://framagit.org/bochecha/org.ideascube.Sdk/blob/devel/elements/platform.bst | 13:09 |
| bochecha | (the difference is that I'm generating a full /, not just /usr, and then the app uses the sdk/platform as a dependency so the final app compose actually contains the platform) | 13:09 |
| bochecha | (also, this is all work in progress to try to redo the way we build our application, it's nothing serious yet, but it's what I've been playing on with BuildStream since GUADEC) | 13:10 |
| bochecha | > tlater misunderstood the docs then | 13:10 |
| bochecha | the docs are being redone, maybe let them know what you misunderstood and they might improve it :) | 13:11 |
| tlater | I got a bit confused between "runtime" and "platform" | 13:11 |
| * bochecha has to afk temporarily | 13:11 | |
| bochecha | platform is a specific type of runtime | 13:11 |
| bochecha | sdk is another type of runtime | 13:11 |
| tlater | I think the "platform" was referred to as "runtime" a few times | 13:11 |
| bochecha | "platform" is not a great name... | 13:11 |
| bochecha | well, the platform is a runtime :) | 13:12 |
| tlater | Anyway, ta for clarifying that :) | 13:12 |
| bochecha | and say, if you want to use org.gnome.Calendar//3.26 which depends on the org.gnome.Platform//3.26 runtime | 13:12 |
| bochecha | that just means flatpak will **by default** use that runtime to launch the app | 13:12 |
| tlater | Oooh, that means I can frankenflatpak | 13:12 |
| bochecha | but you could do: flatpak run --runtime=ANOTHER_RUNTIME org.gnome.Calendar | 13:12 |
| bochecha | and flatpak will gladly use ANOTHER_RUNTIME instead of the normal one | 13:13 |
| bochecha | there is no guarantee the app will run, though :P | 13:13 |
| * tlater is happy flatpak still allows completely screwing over my system for minor performance benefits | 13:13 | |
| bochecha | but it's useful in one case: using the Sdk instead of the Platform | 13:13 |
| bochecha | this way you get access to strace, gdb, etc... to debug an app | 13:13 |
| bochecha | so in the example above where org.gnome.Calendar//3.26 depends on org.gnome.Platform//3.26 | 13:14 |
| bochecha | you would do: flatpak run --runtime=org.gnome.Sdk//3.26 org.gnome.Calendar | 13:14 |
| bochecha | (or `flatpak run -d org.gnome.Calendar` for shorts) | 13:14 |
| tlater | I'll have to take a good look at flatpak at some point, I've been avoiding it for years now | 13:14 |
| bochecha | there are some really great ideas in it | 13:14 |
| bochecha | it's pretty much a glue around bubblewrap and ostree to be honest, with a builder | 13:17 |
| bochecha | when I discovered buildstream, I instantly felt like it was just a more generic version of flatpak-builder: that is it does many things similarly, but allows more (and it's written in an language I'm comfortable with, so I can contribute, which has been very difficult for me with flatpak-builder :P) | 13:20 |
| tlater | Hm, maybe, but ostree feels more development-focused | 13:20 |
| bochecha | I had been thinking I wanted something like flatpak+flatpak-builder for my python web apps for a long time now, and at some point I was considering a light fork of flatpak that would just replace the desktop-specific parts by web-specific parts :P | 13:20 |
| bochecha | then came BuildStream :) | 13:21 |
| bochecha | nah, ostree is just a storage/transport mechanism | 13:21 |
| tlater | *s/ostree/buildstream) | 13:21 |
| tlater | Not sure what my fingers did there | 13:21 |
| bochecha | ah, yes, bst is definitely more for development | 13:21 |
| bochecha | but then it can build artifacts which can then be made public for users to consume :) | 13:21 |
| bochecha | my plan is to `bst checkout app.bst` then commit the tree to an ostree repo, and publish that ostree repo | 13:22 |
| bochecha | then install/update the apps from that repo | 13:22 |
| bochecha | bst's job stopped at building the artifacts, and that's fine :) | 13:22 |
| bochecha | when you think about it, so does flatpak-builder's job | 13:22 |
| bochecha | then flatpak takes over for install/update | 13:22 |
| tlater | Yeah, I think I'll start adopting it for some of my web services too :) | 13:22 |
| tlater | I might start using flatpak for applications I don't want to actually install on my desktop machine, though | 13:23 |
| * tlater is thoroughly annoyed by things creating dotfiles in $HOME | 13:24 | |
| bochecha | I'm also working on a flatpak-like mini tool which just pulls from ostree repos and runs apps in bwrap sandboxes, kind of like flatpak does; then I'll have my whole workflow (build with bst, install/run with that tool) redone and I'll be happy | 13:24 |
| bochecha | then I realize it's pretty much a new docker and I get scared ^_^ | 13:24 |
| * tlater wonders if we could export things as docker images with buildstream | 13:25 | |
| persia | Probably, yes. | 13:25 |
| paulsherwood | how hard can it be, really | 13:25 |
| persia | The only thing that might make it annoying is if there are special magic keys that change frequently, making it a game of catch-up. | 13:25 |
| tlater | There was that open alternative that rkt started | 13:26 |
| paulsherwood | https://www.opencontainers.org | 13:26 |
| paulsherwood | LF ran with the ball | 13:27 |
| tlater | Hm, I might have a peek at these things over Christmas, it would make maintaining my server so much easier. | 13:28 |
| *** noah has joined #buildstream | 14:11 | |
| *** noah has quit IRC | 15:32 | |
| *** noah has joined #buildstream | 15:34 | |
| *** noah has quit IRC | 15:37 | |
| *** noah has joined #buildstream | 15:39 | |
| *** noah has quit IRC | 16:17 | |
| *** mcatanzaro has quit IRC | 16:52 | |
| *** adds68_ has joined #buildstream | 16:54 | |
| *** adds68 has quit IRC | 16:55 | |
| *** tpollard has quit IRC | 17:02 | |
| *** noisecell has quit IRC | 18:09 | |
| *** bethw has quit IRC | 18:15 | |
| *** adds68_ has quit IRC | 18:16 | |
| *** jude has quit IRC | 18:24 | |
| *** jude has joined #buildstream | 18:38 | |
| *** jude has quit IRC | 18:42 | |
| *** jude has joined #buildstream | 18:45 | |
| *** jude has quit IRC | 18:50 | |
| *** xjuan_ has joined #buildstream | 19:02 | |
| *** xjuan has quit IRC | 19:03 | |
| *** xjuan__ has joined #buildstream | 19:43 | |
| *** xjuan_ has quit IRC | 19:44 | |
| *** xjuan_ has joined #buildstream | 20:29 | |
| *** xjuan__ has quit IRC | 20:31 | |
| *** xjuan__ has joined #buildstream | 20:46 | |
| *** xjuan_ has quit IRC | 20:48 | |
| *** xjuan_ has joined #buildstream | 21:08 | |
| *** xjuan__ has quit IRC | 21:09 | |
| *** xjuan_ has quit IRC | 21:11 | |
| *** xjuan_ has joined #buildstream | 21:13 | |
| *** xjuan_ has quit IRC | 21:15 | |
| *** bochecha has quit IRC | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!