| *** tristan has joined #buildstream | 03:55 | |
| *** mcatanzaro has quit IRC | 03:56 | |
| *** noisecell has joined #buildstream | 07:10 | |
| *** valentind has joined #buildstream | 09:00 | |
| * tristan now discovered how to make pulseaudio work | 09:40 | |
| * tristan just had to ask valentind, would have saved time :) | 09:40 | |
| *** ernestask has joined #buildstream | 09:41 | |
| valentind | What about pulseaudio? | 09:42 |
|---|---|---|
| tristan | valentind, I've been trying to make `bst shell` more friendly for testing out programs, which is possible mostly only where your host system marginally resembles the stack/runtime you are building | 09:44 |
| tristan | which is a typical case for e.g. GNOME devs | 09:44 |
| tristan | So I found I need to find the pulse server socket, mount it into the sandbox for testing shells, and resolve PULSE_SERVER | 09:45 |
| * tristan noticed that valentind enhanced this in flatpak recently | 09:45 | |
| tristan | valentind, did you consider running `pactl info` on the host rather than all that intimate knowledge of pulse's config files ? | 09:46 |
| valentind | The point was to limit dependencies. | 09:47 |
| tristan | yeah, I guess it's sensible to assume that, if the host has pulseaudio at all, it might have a utility that tells you where the socket is | 09:47 |
| tristan | but, maybe not :) | 09:47 |
| valentind | The question is can you have a pulseaudio server running without pactl installed. | 09:49 |
| tristan | True, I presume you can; a different question is whether you should expect apps to discover the socket without it; the answer is yes I guess since I suppose the expectation is to go through libpulse | 09:51 |
| tristan | valentind, Then again, a flatpak recommended dependency to distros might be another sane approach | 09:52 |
| tristan | i.e. flatpak has implicit knowledge of pulse already (with build-finish --socket="pulseaudio") | 09:53 |
| tristan | So telling distros that flatpak should imply `pactl info` might also be reasonable | 09:53 |
| tristan | frankly, I'm just happy that after a day I have audio in `bst shell`, though :) | 09:54 |
| tristan | Well, I'll have to figure out how to make it possible to achieve from a project.conf, but that's all just implementation details | 09:54 |
| tristan | juergbi, any thoughts on that ? I've already been thinking of allowing project.conf to run host-side shell scripts... | 09:57 |
| tristan | in the case of pulse, a host side shell script would have to A.) discover the location of the socket on the host... B.) set the PULSE_SERVER var in the shell's env | 09:58 |
| tristan | for GNOME purposes, I suppose that just automated %{uid} expansion in the `host-files`, plus a way to explicitly set env vars allowing %{uid} expansion would "work" | 09:59 |
| tristan | the assumption that the socket is in /run/user/%{uid}/pulse is not entirely horrible for this purpose | 09:59 |
| juergbi | wouldn't it be better to allow expansion of host XDG_RUNTIME_DIR? | 10:00 |
| tristan | I dont know if that is always set, though | 10:00 |
| juergbi | there might be a default, have to check the spec | 10:01 |
| tristan | flatpak checks it, and I followed the g_get_foo..() API path and... says that defaults to the cache dir | 10:01 |
| juergbi | If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message | 10:01 |
| juergbi | quote from the spec | 10:01 |
| tristan | g_get_user_cache_dir() | 10:01 |
| juergbi | given that a warning is specified in the spec, all reasonably set up systems should have it set | 10:01 |
| tristan | The above is from the g_get_user_runtime_dir() docs | 10:02 |
| juergbi | and there is no clear default | 10:02 |
| juergbi | maybe we should allow a host script to generate env variables | 10:02 |
| juergbi | could be sensible | 10:03 |
| tristan | yeah, I guess just supporting $ENV var expansion in `host-files`, and also addition of explicit env var assignments, also with env var expansion support, would work | 10:03 |
| tristan | allowing host scripts to run for customizing `bst shell` behavior I think is a good idea too | 10:03 |
| tristan | but maybe as a further step | 10:04 |
| tristan | i.e. I can mostly say "Hey, GNOME apps run with audio and video in the `bst shell`" with not too much work | 10:05 |
| tristan | which would be nice to say... like tomorrow :D | 10:05 |
| juergbi | :) | 10:07 |
| *** tristan has quit IRC | 10:10 | |
| *** tiago has joined #buildstream | 10:13 | |
| juergbi | jmac: is it just not clear that the discussion maps to the examples or are the examples themselves still unclear? | 10:18 |
| juergbi | and yes, in each file the added 'build:' node is a toplevel node in the file | 10:19 |
| jmac | The example is clear, the discussion is not | 10:19 |
| * juergbi wonders what's so unclear in the discussion | 10:20 | |
| jmac | When you say 'toplevel' I imagine project.conf at the top and element files underneath that | 10:20 |
| juergbi | ah ok, with toplevel i mean with respect to a particular yaml file | 10:20 |
| jmac | Now I think you mean a key in each file | 10:20 |
| juergbi | yes | 10:20 |
| jmac | Also the decisions (e.g. why this needs to be a new tree, rather than v | 10:22 |
| jmac | ariables or config) | 10:22 |
| jmac | I'm sure you and tristan have a clear model of this in your head, but it's not getting through to me | 10:22 |
| juergbi | 'config' is completely in the hands of Element subclasses. the buildstream core doesn't define the structure of it | 10:23 |
| juergbi | while some Element subclasses (BuildElement and ScriptElement) aren't plugins, we still maintain a separation between the core (Element itself, Project, Context, etc) and the different Element kinds (subclasses) | 10:24 |
| juergbi | this is a policy decision and it's not obvious purely from the name 'config:', of course | 10:25 |
| juergbi | but i hope it's starting to make a bit more sense to you | 10:26 |
| juergbi | as the uid of the sandbox should be affected for all sandbox invocations (incl. integration handled by core Element), this can't be implemented solely in Element subclasses | 10:27 |
| juergbi | and thus the configuration also needs to be placed appropriately | 10:28 |
| juergbi | however, i think it anyway fits well with the future expected execution environment configuration, as hinted in the example | 10:28 |
| juergbi | so it anyway makes sense to be core config, imo | 10:28 |
| jmac | Definitely don't call something 'config' if it's not allowed to be in a yaml key called 'config' | 10:29 |
| juergbi | well, whole project.conf is a config file... | 10:29 |
| juergbi | the name of the 'config:` key may not be ideal | 10:30 |
| jmac | Why are Buildelement and Scriptelement not plugins, btw? | 10:34 |
| *** valentind has quit IRC | 10:37 | |
| jmac | Perhaps calling 'config' something like 'element-config' would make it clearer, I can understand why you wouldn't want to change it now though | 10:39 |
| juergbi | actually not sure anymore. we shouldn't really be poking internals. there was an issue with subclassing across plugins, iirc. don't remember whether this was the reason | 10:39 |
| juergbi | yes, i can understand the confusion but i think it's indeed too late to change now | 10:39 |
| jmac | I don't really see why you should not have a config in project.conf and have elements override it; that doesn't require any element to take any notice of the project-wide config unless it wants to | 10:40 |
| juergbi | would also have been a possibility but adding core 'config' to 'config:' now would lead to inconsistency | 10:41 |
| juergbi | we should follow existing core 'config' such as the 'environment:' dict | 10:41 |
| juergbi | doesn't make sense to increase the confusion | 10:41 |
| jmac | Well, that's another possibility - we could use 'environment' or 'variables' and save having another top-level key | 10:43 |
| juergbi | if we couldn't think of any future uses of the new top-level key, we could consider it. however, | 10:45 |
| juergbi | a) pretending for uid/gid to be env. variables wouldn't be ideal | 10:45 |
| juergbi | b) as per my example, i expect we will need further configuration possibilities that fit in there (execution environment such as os and arch) | 10:45 |
| juergbi | this will allow building freebsd packages from a linux bst client using a VM or remote worker that runs freebsd | 10:46 |
| juergbi | and that's why i think a new top-level key is sensible | 10:47 |
| jmac | I'll wait and see if tristan has any opinions | 10:51 |
| tlater | Hrm, still struggling with glib/ostree :| | 11:32 |
| tlater | I think I finally managed to figure out how the diff_dirs interface is supposed to work | 11:33 |
| tlater | But it doesn't do what I expect it to | 11:33 |
| tlater | I have this: https://pastebin.com/fs2icm2D | 11:33 |
| tlater | Now, as far as I understand, if I give this two refs that point to different trees, I should get some values in modified, removed and added | 11:33 |
| tlater | I try that, and despite them having different checksums, I get nothing in the arrays :( | 11:34 |
| * tlater suspects he needs something fancier than lists, but can't find what that would be in the pygobject docs | 11:38 | |
| jmac | Does anyone have any thoughts on how continuous benchmarking should work when we have two repositories? Can we have the main BuildStream repository use the benchmark repo, for example? | 11:43 |
| tlater | Hm, when we did that for tests it got quite messy. Might be more appropriate here though. | 11:44 |
| juergbi | jmac: not sure. if the idea is to benchmark the older buildstream versions with newer benchmark repo versions as well, shouldn't it be the other way around? | 11:45 |
| juergbi | although we would still want to trigger it on main repo updates, of course, hm | 11:46 |
| jmac | Yeah, triggering is the main thing | 11:46 |
| aiden | tlater, looks like you have to pass different argument types to diff_dirs | 11:46 |
| juergbi | tlater: it's also possible that the ostree introspection annotations are incomplete/incorrect | 11:46 |
| aiden | https://lazka.github.io/pgi-docs/OSTree-1.0/functions.html#OSTree.diff_dirs | 11:46 |
| juergbi | the question is whether pygobject properly handles the mutation of the lists | 11:47 |
| tlater | aiden: Well, three different types of lists, unfortunately that doesn't map to python typing | 11:48 |
| tlater | Unless I misunderstand you | 11:49 |
| juergbi | i suspect it's only marshalling (empty) python list to GPtrArray but not the other way round with this binding | 11:49 |
| tlater | I honestly have no idea how I'd get around that | 11:49 |
| *** jennis_ has quit IRC | 11:50 | |
| tlater | Hrm, I suppose I should read into the pygobject source :| | 11:50 |
| juergbi | i can try and take a look | 11:50 |
| juergbi | but feel free if you like :) | 11:50 |
| tlater | Heh, would you mind *also* taking a look, juergbi? I suspect it will take me quite a while to find an answer on my own here. | 11:52 |
| juergbi | sure, i'm already familiar with g-i. or rather, i was, it's been a while | 11:52 |
| aiden | ok, excuse ignorance, i guess that you're not using this Gio thing | 11:55 |
| tlater | aiden: I am for the other parameters - well, kind of. The root_{a,b} variables contain OSTree.RepoFiles, which are subclasses of Gio.File | 11:58 |
| aiden | but OSTree.DiffItem and Gio.File seem to be python types | 11:58 |
| tlater | And from the c code I'm pretty sure OSTree.RepoFile is supported | 11:58 |
| tlater | The only types I'm not sure about are those lists - as juergbi says there's probably a gotcha to be found in the source code somewhere | 11:59 |
| juergbi | the gobject-introspection test cases don't seem to cover that usage | 12:00 |
| *** mcatanzaro has joined #buildstream | 12:00 | |
| juergbi | also see no other examples where mutable arrays are used as arguments | 12:04 |
| juergbi | it might not be supported by gobject-introspection. wondering whether we could work around it | 12:04 |
| * tlater recalls python actually creating a copy of lists in arguments | 12:05 | |
| tlater | Maybe I should ask on their IRC channel | 12:05 |
| juergbi | not sure whether pygobject has a lower level API that would allow this or whether the only choices are direct ffi usage or writing a bit of C code | 12:05 |
| tlater | juergbi: I think if we're going that far it's best just to roll our own | 12:06 |
| tlater | There are enough methods to help traverse these trees | 12:06 |
| juergbi | yes, if this is all exposed (and usable from python) and not a performance issue, sure | 12:07 |
| juergbi | might be worth filing a bug in any case, though | 12:07 |
| juergbi | either for ostree to provide a introspectable API or gobject-introspection to support this API style (if it doesn't yet) | 12:08 |
| tlater | I'll see what #python says first, I suppose | 12:08 |
| juergbi | yes, or possibly #introspection | 12:08 |
| aiden | tlater, at risk of exposing my ignorance further; why can't you just pass arguments of the types in that docs link? | 12:13 |
| tlater | aiden: Python doesn't have typed lists | 12:14 |
| aiden | ? | 12:14 |
| tlater | The three latter arguments all want mutable lists, into which it writes its results | 12:14 |
| tlater | Fairly common thing in C, iirc | 12:14 |
| tlater | But C lists have types | 12:14 |
| tlater | Python lists don't | 12:14 |
| tlater | So, in C, you'd have a [Gio.GFile], in python you'd have a [] that happens to contain a Gio.GFile | 12:15 |
| tlater | I *can't* supply a typed list | 12:15 |
| juergbi | the C list doesn't have types either | 12:16 |
| aiden | why can't you just instantiate one OSTree.DiffItem and two Gio.Files and then pass them as `modified, removed, added` respectively? | 12:16 |
| tlater | aiden: Ah, you're missing the arrays ;) | 12:17 |
| juergbi | GPtrArray simply stores pointers (well, it does have an optional element free func) | 12:17 |
| tlater | aiden: If you have a close look at this: https://lazka.github.io/pgi-docs/OSTree-1.0/functions.html#OSTree.diff_dirs | 12:17 |
| tlater | You'll see that the modified, removed and added arguments are lists | 12:17 |
| aiden | aff | 12:17 |
| tlater | Not OSTree.DiffItem/Gio.File | 12:17 |
| aiden | sorry | 12:17 |
| aiden | _o_ | 12:17 |
| * tlater really needs to look into gobject for C code - the library seems to make a whole lot of things a lot nicer :) | 12:18 | |
| * juergbi won't mention Vala ;) | 12:19 | |
| *** jennis has joined #buildstream | 12:35 | |
| *** xjuan has joined #buildstream | 13:00 | |
| jennis | Hi guys, I can't seem to get the new style tests to pass for dpkg-build | 13:10 |
| jennis | I'm getting this error: https://paste.gnome.org/p3nquma8w | 13:11 |
| jennis | Has anyone got any ideas? | 13:11 |
| tlater | jennis: Looks like you need to add the gnome gpg key | 13:13 |
| tlater | That is, this file: https://gitlab.com/BuildStream/buildstream/blob/master/tests/integration/project/keys/gnome-sdk.gpg | 13:14 |
| tlater | juergbi: Looks like gi plain doesn't support mutable lists as arguments | 13:16 |
| juergbi | :/ | 13:17 |
| * tlater already started on rolling his own function though, it seems possible enough | 13:18 | |
| *** xjuan_ has joined #buildstream | 13:33 | |
| *** xjuan has quit IRC | 13:34 | |
| *** xjuan_ is now known as xjuan | 13:34 | |
| *** xjuan_ has joined #buildstream | 13:37 | |
| *** xjuan has quit IRC | 13:39 | |
| *** xjuan_ is now known as xjuan | 13:39 | |
| *** anymous has joined #buildstream | 14:02 | |
| *** anymous has left #buildstream | 14:03 | |
| jennis | thanks tlater | 14:11 |
| jennis | Temporary work around is to just cp that into a keys/ dir in bst-external | 14:11 |
| jennis | ^ not as big of an issue as copying testutils/ but still should be avoided? | 14:12 |
| nexus | for the test, i think it's fine to have that there, but i'm not sure | 14:16 |
| tlater | jennis: definitely not an issue | 14:20 |
| tlater | Testutils is special because it *can* be avoided, since it's a python module in Buildstream, which is installed in bst-external's runner anyway. | 14:21 |
| *** jennis has quit IRC | 14:33 | |
| *** noisecell has quit IRC | 14:33 | |
| *** tiago has quit IRC | 14:34 | |
| *** jennis has joined #buildstream | 14:34 | |
| *** noisecell has joined #buildstream | 14:34 | |
| *** tiago has joined #buildstream | 14:35 | |
| *** jennis_ has joined #buildstream | 14:59 | |
| *** tiagogomes has joined #buildstream | 15:00 | |
| *** tiago has quit IRC | 15:00 | |
| *** jennis has quit IRC | 15:00 | |
| jmac | Having some weird problems with docker in the benchmarks repository | 15:06 |
| jmac | It seems to think 'client.images' is a function rather than an object | 15:06 |
| jmac | Probably a docker thing but wondered if anyone involved in the benchmarks repo had seen that | 15:06 |
| jmac | Changed between 1.9.0 and 3.1.0 apparently, I'll add that to the docs | 15:23 |
| tlater | Do I actually have to clean up Gobject variables in python? | 15:43 |
| * tlater can see this make sense, but still feels weird calling fre() | 15:43 | |
| tlater | free()* | 15:43 |
| jmac | I just removed bst-external from the benchmarking setup, and it still seems to build baserock without any problems. Does anyone know why it's there? | 16:38 |
| juergbi | tlater: no, i don't think this should normally be necessary, but there may be exceptions | 16:59 |
| *** xjuan_ has joined #buildstream | 18:19 | |
| *** xjuan has quit IRC | 18:19 | |
| *** xjuan_ is now known as xjuan | 18:22 | |
| *** toscalix has joined #buildstream | 18:42 | |
| *** valentind has joined #buildstream | 19:26 | |
| *** toscalix has quit IRC | 19:30 | |
| *** toscalix has joined #buildstream | 19:30 | |
| *** Prince781 has joined #buildstream | 19:40 | |
| *** Prince781 has quit IRC | 20:15 | |
| *** toscalix has quit IRC | 20:30 | |
| *** xjuan has quit IRC | 21:46 | |
| *** valentind has quit IRC | 22:21 | |
| *** ernestask has quit IRC | 22:35 | |
| ssssam[m] | jmac: it's needed to build the systems/minimal-system-image-x86_64.bst target | 22:41 |
| ssssam[m] | jmac: originally I wanted to benchmark building that target instead of just stage1-binutils, but I hit https://gitlab.com/BuildStream/buildstream/issues/270 | 22:42 |
| *** toscalix has joined #buildstream | 23:13 | |
| *** toscalix has quit IRC | 23:35 | |
| *** toscalix has joined #buildstream | 23:39 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!