IRC logs for #buildstream for Wednesday, 2019-02-13

*** adds68 has joined #buildstream00:40
*** alatiera has quit IRC01:40
*** kapil___ has joined #buildstream02:46
*** nimish has quit IRC03:20
*** lantw44 has quit IRC07:01
*** lantw44 has joined #buildstream07:05
*** xjuan has joined #buildstream07:35
*** tristan has joined #buildstream07:57
*** xjuan has quit IRC08:28
*** xjuan has joined #buildstream08:29
*** xjuan has quit IRC08:38
nielsdgI don't know if this is the correct place to put this, but I just had a very weird bug: if I open a bst shell for a GTK+ application on a system that doesn't have icon-hicolor-theme installed, I get some really weird stuff (no characters being drawn/no icons found) when I run the application inside that shell08:55
nielsdgSo I don't know if it means GNOME should add a dependency for icon-hicolor-theme in its dependencies for any GTK+ app08:56
*** ChanServ sets mode: +o tristan09:03
tristannielsdg, It is surprising to me that the host system could have any effect on this09:03
tristannielsdg, If I run an app in a shell and the shell doesnt have the icon theme, then I equally get missing icons even if my host system has them09:04
nielsdgtristan: it seems to be something else though09:04
tristannielsdg, Here is an example of what I did to make glade work in the shell: https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/world/glade.bst09:05
juergbiis D-Bus passed through and the theme is taken from there somewhere?09:05
tristani.e. cantarell fonts and adwaita makes it work09:05
nielsdgtristan: Indeed, that might be it09:05
tristanjuergbi, hmmm have to look at the project.conf to see what it does now, but I doubt it09:06
juergbiwas just a wild guess09:06
tristanWe poke a hole for the pulseaudio socket and for the dri09:06
tristanI mean it is possible :)09:06
juergbiDBUS_SESSION_BUS_ADDRESS: '$DBUS_SESSION_BUS_ADDRESS'09:06
tristanright there :)09:06
* tristan forgets what precisely that was done for09:07
tristanbut surely it helps09:07
juergbithe theme issue might indeed just be due to the dependency09:09
*** alatiera has joined #buildstream09:16
benschubertCan soemone tell me where the yaml file for plugins is loaded? I couldn't find it :/09:23
tristanbenschubert, it's only for elements09:23
tristanbenschubert, it should be parsed in element.py09:24
benschubertok thanks! I'll look in there09:24
tristan__init_defaults()09:24
benschuberttristan: thanks a lot!09:27
*** jennis has joined #buildstream09:28
tristanjuergbi, now would be a good time to talk about symlinks :)09:32
juergbi:)09:32
juergbihave you already had a chance to read the description/comments of !1140 (and possibly !1139)?09:32
gitlab-br-botMR !1140: WIP: Do not resolve or mangle symlinks during staging https://gitlab.com/BuildStream/buildstream/merge_requests/114009:32
gitlab-br-botMR !1139: Return all directories in list_relative_paths() https://gitlab.com/BuildStream/buildstream/merge_requests/113909:33
tristanSomehow I think we're rehashing something that has been discussed so many times before09:33
tristanok lemme freshen up on those for a sec...09:33
juergbithere have been various issues in connection with symlinks over time, so there was certainly some discussion09:36
nielsdgtristan: Thanks, adding those as runtime dependencies solved it :)09:36
juergbiI've linked a few of them09:36
tristannielsdg, :)09:39
jjardonnielsdg: please remember to send a patch if this is using gnome-build-meta :)09:41
nielsdgjjardon: Already planned, after work :-)09:41
jjardontristan: hey, any chance to have a new bst-1.2.x release soonish?09:42
tristanjjardon, lets do it; I have a dinner at 8pm so I don't think I can do it today09:42
jjardonSure, let me know if you need any help releasing the tarball in gnome servers09:43
tristanjjardon, Ok I'll put on my TODO 2 things for tomorrow morning, both release the next 1.2.x, and add a section to CONTRIBUTING.rst about the release process09:43
tristanjjardon, you, juergbi and I all have that access so shouldnt be an issue :)09:44
*** raoul has joined #buildstream09:45
juergbitristan: I actually already removed the unused (and buggy) list_dirs=False support, !1138, hope you don't mind09:48
gitlab-br-botMR !1138: Symlink fixes https://gitlab.com/BuildStream/buildstream/merge_requests/113809:48
tristanjuergbi, Ok so put some comments down on the both...09:55
tristanjuergbi, nah, since it was unused it makes sense to remove deadcode09:56
tristanjuergbi, Ok so, I think that the majority of problems here are stemming from lack of absolute symlink support and more importantly, the assumption that it might be okay to apply split rules after initially staging an artifact09:57
tristansplit rules are parsed on the element and supported in the staging routines explicitly to stage portions of the artifact, but we are failing because we are expecting that those locations are unaffected by staging09:57
tristanjuergbi, Anyway, for all of those comments, it doesnt necessarily mean we should not change it of course09:59
tristanFrom a coding perspective, it would be nice to treat symlinks like anything else10:00
tristanFrom a user perspective, it would be nice to continue to use a %{prefix} of "/opt/foo" in all my elements, even if I later decide that /opt/foo is a symlink to /usr/local/foo10:01
tristanMaybe that is unnecessary10:02
tristanI'm pretty sure I've seen this setup used before, on rpm/mic based firmwares (where the software is compiled into prefix /opt/vendor, but the data for /opt/vendor is stored in a different real path)10:03
juergbitristan: regarding split rules, that might indeed make sense but current compose.py doesn't follow this approach10:04
juergbiright now compose stages all dependencies without splitting, then runs the integration commands and computes the split manifest after integration10:04
tristanRight, that definitely appears to be a grave mistake which went unnoticed until people started raising issues10:05
juergbiI was also thinking that it would be nice if we could simply stage respecting the split domains and then drop the more complex manifest calculation10:05
tristanjuergbi, Only if integration commands are supposed to be run10:05
juergbiwell, yes10:05
tristanOtherwise it should only stage the selected data, it is specifically for that reason too10:05
tristancause we can't expect integration to work on a subset10:05
juergbiyes, that's a potential concern10:06
juergbiregarding /opt/foo being a symlink: I think such system installations should indeed be valid, however, I don't think it's a concern inside BuildStream sandboxes10:07
juergbior rather, that will still work. e.g., freedesktop-sdk replaces /usr/shares/locale with a symlink to the localization extension point for flatpak images, or something along those lines10:07
juergbiand that seems to still work fine with my branch10:08
juergbias moving the directory and replacing it with a symlink is done in an integration command10:08
tristanWell10:08
tristanYou can always depend on an element which runs an integration command which does that kind of thing10:08
juergbiexactly, that's what fd-sdk does and that will continue to work in any case10:09
tristanBut, the philosophy behind the current approach is that we should avoid as much as possible any fragmentation of knowledge10:09
tristanEspecially, we should avoid any kind of master post processing hacky script which "runs at the end" where all the confusing unexplainable special sauce ends up10:09
tristanbecause not everybody comments perfectly about everything10:10
*** bochecha has joined #buildstream10:10
tristanThis symlink seems most appropriately done by the element which installs the libc locales thing right ?10:10
juergbiwell, the thing is that they only want the symlink for the flatpak image10:11
juergbimore regular system images wnat regular /usr/share/locales10:11
juergbithat's why it makes sense as an integration command there10:11
tristanThat is what project options are for10:11
juergbiwould also be a possibility but reduce build reuse10:11
tristanAnd no, I mean regardless of the the ultimate decision, I definitely do not think it makes more sense to have an element at the end "do stuff" just because we are building in flatpak mode10:12
juergbiI think it really depends on what 'stuff' is being done10:13
juergbispecial treatment for flatpak extension points is acceptable in dedicated integration packages, imo10:14
juergbithat's a bit like a deployment process10:14
juergbior rather, that is deployment. not just a bit like10:15
tristanI don't really agree with treating one filesystem permutation as special or different from another10:16
juergbiit's not special10:16
juergbibut doing that at the end is not bad per se, imo10:17
juergbiyou first build stuff and then you deploy the thing10:17
juergbi(or prepare deployment image, whatever you want to call it)\10:17
tristanSo, if you were "only ever building a flatpak runtime", you could just build glibc locales in the right place to begin with, and never have to understand it in some "do all hack and patch" element at the end10:18
tristanBut since we can build many different things, we instead build one way all the way up to a point, and start mashing up the output later on for reverse dependency branches which target different things10:19
tristanit feels disgusting10:19
juergbiit could be compared to someone wanting to install locales on a different filesystem10:19
juergbimaybe not something that useful for standard installations but who knows, root partition could be size limited10:19
tristanI mean, I think you probably have convinced me based on difficulty to order your dependencies correctly to produce the desired results, and weak messaging to the user to understand the consequences10:20
tristanBut I wont get behind the post processing of things at the end being a good/desirable thing10:20
juergbiI know where you're coming from, with some projects having huge badly maintained scripts of fixing up permissions etc10:21
tristanOf course the option always remains open to do so, but being able to abolish these things by providing an experience that is as lfs and seamless as possible is a goal10:22
tpollardin l579 of cli.py we check 'not _cached_success' to state we're mounting in a failed build, however if I switch that to '_cached_failure' it doesn't catch10:22
tpollardnow it is cached, else cached_success would return false straight away, so I'm not sure what the issue is10:22
* tpollard assumes something is astray in _get_build_result10:25
tristantpollard, sounds like anyway10:29
*** jonathanmaw has joined #buildstream10:29
tpollardyep, I wonder why not _cached_success was used in the first place tbh10:30
tristantpollard, oh btw, I send in a proposal for a paper at FOSSASIA, and considering going there anyway, if I recall you were interested in going10:30
tpollardtristan: I am indeed hoping to go :)10:30
tristanI might go anyway even if she can't squeeze me in10:30
tristanbut I'll let you know if I get a talk there it would be cool :)10:31
tristantpollard, git blame, I think you might ask skullman (?) about caching failed builds10:31
tristanjuergbi, Ok so anyway I do get the complication of symlinks and we've been struggling with them since the beginning10:32
tristanjuergbi, it seems that it might be the right tradeoff10:33
tristanjuergbi, if I understand, your branch will flatly disallow staging of files across existing symlink boundaries ?10:33
tristanI do think it is a shortcoming, but maybe we can safely say that there is no way to allow that while giving the user appropriate messaging when they make a mistake10:34
juergbiyes, if any parent path component from the file list is currently a non-directory, it will bail out10:34
juergbi(same for a directory in the file list)10:34
tristanjuergbi, alright then :)10:37
juergbi:)10:38
tristanjuergbi, On a similar topic, especially with everything that has been discussed at the gathering... I think it is paramount that we start on a porting guide immediately10:38
juergbiyou're also happy with the list_relative_paths() change or is there anything else I can check in that aspect?10:38
tristanAnd that we carefully update the porting guide with every breaking change10:38
juergbimakes sense10:39
tristanjuergbi, honestly regarding the list_relative_paths() API, I am happy if tests pass and existing projects build10:39
juergbithe list in NEWS is hopefully complete but at least some points will require explanation how to port10:39
juergbiok, great10:39
tristanjuergbi, And I am happy that is remains the *single* focal point for traversing directories10:40
tristanthat is sort of the point of list_relative_paths(), ensuring that nobody is calling os.walk() by themselves10:40
juergbiCASBasedDirectory has its own, of course, but that matches the behavior now10:40
tristanI suppose we will always need both, even if elements are only allowed to access sandbox paths through CASBasedDirectory10:41
tristanjuergbi, but maybe list_relative_paths() belongs on FileSystemBasedDirectory ?10:41
tristanAnyway, that is rather besides the point10:42
tristanI recall pulling my hair out when YBD had two different functions for traversing filesystems10:42
tristanand would like to keep the rest of my hair :D10:42
*** tristan has quit IRC10:43
*** tristan has joined #buildstream10:43
juergbiFileBasedDirectory simply calls utils.list_relative_paths() right now. we could consider removing the utils filesystem functions from the public API and only supporting the 'virtual' Directory API10:43
*** ChanServ sets mode: +o tristan10:43
juergbiI'm anyway planning on working towards moving everything to our Directory API starting next week, such that we can have the optimal pure CAS path in the future, where we can avoid real filesystem access for staging (for remote execution or local buildbox)10:44
tristanRight10:44
juergbibut one step at a time :)10:44
* tristan has to run to dinner...10:45
juergbienjoy, I may start merging, then10:45
gitlab-br-botjennis merged MR !1101 (jennis/refactor_artifact_log->master: Refactor artifact log command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/110110:48
*** tristan has quit IRC10:48
*** lachlan has joined #buildstream10:50
jmacIs there a list of built-in element types with a summary anywhere?11:15
benschubertjmac: ls plugins/elements | grep .py?11:18
benschubertbuildstream/plugins/elements11:18
juergbijmac: and there is https://docs.buildstream.build/core_plugins.html11:19
jmacYeah, I just thought it'd be useful to have a list with a summary in it11:20
jmacAlso it's confusing to refer to them as 'plugins' when they come supplied with Buildstream11:21
juergbiin a way, yes11:21
juergbimost of them are planned to move out of the core repository, though11:21
*** lachlan has quit IRC11:36
*** lachlan has joined #buildstream11:40
gitlab-br-botvalentindavid merged MR !1132 (valentindavid/pull-chmod-bug-1.2->bst-1.2: buildstream/_artifactcache/cascache.py: Set 0644 rights to pulled files) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/113211:41
*** bochecha has quit IRC11:46
*** lachlan has quit IRC11:47
gitlab-br-botjonathanmaw opened issue #911 (Buildstream's scheduler spends a long time creating subprocesses) on buildstream https://gitlab.com/BuildStream/buildstream/issues/91111:52
juergbijonathanmaw: was this on WSL or Linux?11:53
jonathanmawjuergbi: the profile I used was on Linux11:55
juergbioh, that's quite surprising to me11:55
jonathanmawon my WSL run, it took much longer, but was a dramatically smaller fraction of total time11:55
juergbiok, I guess I/O is the main issue on WSL11:55
jonathanmawon that one, definitely, it was a HDD over USB11:56
jonathanmawthough linux copes with that much latency much better than WSL does, too11:56
juergbiLinux's aggressive dentry caching might make a big difference11:57
* juergbi wonders why tests-wsl is running for my MR even though it's set to manual11:59
jonathanmawthat was my fault12:00
jonathanmawI started it manually so I could check that the new WSL runner I set up was working12:00
juergbiah ok, no problem12:02
*** lachlan has joined #buildstream12:02
*** solid_black has joined #buildstream12:22
*** eadnjunior has joined #buildstream12:23
*** raoul has quit IRC12:34
gitlab-br-botjuergbi merged MR !1139 (juerg/list-all-directories->master: Return all directories in list_relative_paths()) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/113912:42
gitlab-br-botjuergbi opened (was WIP) MR !1140 (juerg/symlinks2->master: Do not resolve or mangle symlinks during staging) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/114012:46
*** nimish has joined #buildstream12:54
*** nimish has quit IRC12:58
*** nimish has joined #buildstream12:59
*** nimish has quit IRC13:03
*** nimish has joined #buildstream13:06
*** solid_black has quit IRC13:07
*** nimish has quit IRC13:14
*** nimish has joined #buildstream13:14
juergbiif anyone wants to review !1140 before it's merged, please do so by tomorrow noon13:19
*** raoul has joined #buildstream13:30
tpollardjuergbi: I've changed it to the 'tristate', hopefully it's in an agreeable format now :) https://gitlab.com/BuildStream/buildstream/merge_requests/1135/13:36
juergbigreat, thanks, will take a look13:37
tpollardas per usual I've lost the CI/rebase race13:37
* tpollard rebases13:37
gitlab-br-botBenjaminSchubert opened MR !1147 (bschubert/cleanup-local-state->master: Cleanup MetaElement local state) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/114713:48
*** lachlan has quit IRC14:47
gitlab-br-botjuergbi closed issue #896 (Optional creation of buildtrees) on buildstream https://gitlab.com/BuildStream/buildstream/issues/89614:50
gitlab-br-botjuergbi merged MR !1135 (tpollard/896->master: Optional creation of buildtrees) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/113514:50
tpollardwoop14:51
gitlab-br-botphildawson approved MR !1147 (bschubert/cleanup-local-state->master: Cleanup MetaElement local state) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/114714:59
*** kapil___ has quit IRC15:06
*** lachlan has joined #buildstream15:19
jmacI'm trying to use the docker source plugin on OSX, and it's creating a cache directory which has 555 permissions, which it then fails to delete15:33
jmacAs per https://pastebin.com/WeWKiTVU15:33
*** lachlan has quit IRC15:35
*** lachlan has joined #buildstream15:52
gitlab-br-botcs-shadow opened MR !1148 (chandan/dot-graph->master: contrib/bst-graph: Add script to print graph in DOT format) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/114816:12
gitlab-br-botBenjaminSchubert merged MR !1147 (bschubert/cleanup-local-state->master: Cleanup MetaElement local state) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/114716:13
*** lachlan has quit IRC17:15
*** ipatch has left #buildstream17:21
jmac^ tarfile apparently. The tar contains permissions for '.'.17:22
*** lachlan has joined #buildstream17:32
*** raoul has quit IRC17:32
*** nimish has quit IRC17:33
gitlab-br-botjmacarthur opened issue #912 (Tar file extract can break our temporary directories) on buildstream https://gitlab.com/BuildStream/buildstream/issues/91217:37
*** tpollard has quit IRC17:48
*** slaf has quit IRC18:04
*** lachlan has quit IRC18:24
*** lachlan has joined #buildstream18:40
*** nimish has joined #buildstream18:49
*** jonathanmaw has quit IRC18:56
*** lachlan has quit IRC19:05
*** slaf has joined #buildstream19:10
*** nimish has quit IRC20:27
*** alatiera has quit IRC23:53

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!