IRC logs for #buildstream for Wednesday, 2018-11-21

*** mohan43u has quit IRC00:02
*** federico has joined #buildstream00:11
*** alatiera__ has quit IRC00:44
*** mohan43u has joined #buildstream01:12
*** federico has quit IRC01:41
*** murph has joined #buildstream04:39
*** CTtpollard has joined #buildstream06:21
*** ctolentino has joined #buildstream06:21
*** benschubert has joined #buildstream06:21
*** slaf has joined #buildstream06:21
*** gitlab-br-bot has joined #buildstream06:21
*** lchlan has joined #buildstream06:21
*** laurence has joined #buildstream06:21
*** paulsherwood has joined #buildstream06:21
*** jmac has joined #buildstream06:21
*** skullman has joined #buildstream06:21
*** dineshdb[m] has joined #buildstream06:21
*** Demos[m] has joined #buildstream06:21
*** waltervargas[m] has joined #buildstream06:21
*** doras[m] has joined #buildstream06:21
*** inigomartinez has joined #buildstream06:21
*** connorshea[m] has joined #buildstream06:21
*** oknf[m] has joined #buildstream06:21
*** segfault3[m] has joined #buildstream06:21
*** jjardon[m] has joined #buildstream06:21
*** asingh_[m] has joined #buildstream06:21
*** awacheux[m] has joined #buildstream06:21
*** tlater[m] has joined #buildstream06:21
*** kailueke[m] has joined #buildstream06:21
*** krichter[m] has joined #buildstream06:21
*** alatiera has joined #buildstream06:21
*** cgmcintyre[m] has joined #buildstream06:21
*** rafaelff[m] has joined #buildstream06:21
*** mattiasb has joined #buildstream06:21
*** ssssam[m] has joined #buildstream06:21
*** albfan[m] has joined #buildstream06:21
*** m_22[m] has joined #buildstream06:21
*** abderrahim[m] has joined #buildstream06:21
*** pro[m] has joined #buildstream06:21
*** theawless[m] has joined #buildstream06:21
*** tintou has joined #buildstream06:21
*** ironfoot has joined #buildstream06:21
*** hergertme has joined #buildstream06:21
*** jjardon has joined #buildstream06:21
*** juergbi has joined #buildstream06:21
*** persia has joined #buildstream06:21
*** irc.poop.nl sets mode: +oo ironfoot jjardon06:21
*** ctolentino has quit IRC06:44
*** mohan43u has quit IRC07:26
*** mohan43u has joined #buildstream07:26
*** tristan has joined #buildstream08:34
*** toscalix has joined #buildstream08:47
*** u63 has joined #buildstream09:27
*** solid_black has joined #buildstream09:35
gitlab-br-botBenjaminSchubert merged MR !958 (bschubert/mr938-comments->master: Followup on MR 938, addressing additional comments) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/95809:52
*** raoul has joined #buildstream10:14
*** jonathanmaw has joined #buildstream10:19
*** lachlan has joined #buildstream10:25
*** yashsriv has joined #buildstream10:25
*** lachlan has quit IRC10:45
*** alatiera_ has joined #buildstream10:49
*** lachlan has joined #buildstream10:50
laurencetest11:13
laurencewoo, sorry, had to remember how to register...11:13
laurencephildawson, hi, you recently raised an MR to retire the source bundle command - https://gitlab.com/BuildStream/buildstream/merge_requests/95911:13
laurencejust wondering if you need to poke people for review?11:13
laurence(I'm going through some MRs that are non-WIP)11:13
phildawsonlaurence, yes, reviews would be appreciated. Kinnison has had a brief look but more would be great :)11:15
benschubertCan't we have circular dependencies with elements for runtime_depends? Should just buildstream not care about and require that both are there?11:36
gitlab-br-bottpollard opened MR !961 (tpollard/pipelinehostconfig->master: tests/plugin/pipeline.py: Avoid using host user conf) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/96111:52
juergbibenschubert: I don't think there is a fundamental reason why we can't support this. It makes a few things in the code easier to completely reject all circular dependencies. And usually it's pretty simple to work around this limitation e.g. by adding the corresponding elements to a stack11:52
*** CTtpollard is now known as tpollard11:53
juergbiHowever, maybe there is a use case where workarounds would be painful enough to motivate support in BuildStream core11:53
benschubertTrue, unless elements are autogenerated :) I'll look more into that11:53
valentindjuergbi, I did some profiling of the freedesktop-sdk cache server.12:15
valentindHalf the time is used in openssl. Which explains why CPU usage follows bandwidth12:16
valentindHowever, to me it uses more than it should do. Running "openssl speed aes-128-gcm" gives me better results on that machine.12:16
valentindI would expect openssl in grpcio to go 25 times faster.12:17
valentindThe issue is https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/47412:18
valentindjuergbi, if you have any idea on what to do to improve the situation, that would be nice.12:19
benschubertvalentind: wild shot (but saw it happen before): is your random seed long enough (do you have enough entropy?) otherwise openssl might do funky things to get more if I remember well12:21
valentindbenschubert, is not it also used in "openssl speed"? I see that small data takes more time, I suppose it is because of padding which is probably using the random generator.12:22
benschubertopensssl speed might also not use enough, but thousands of simultaneous connections might right?12:23
benschubertit's a wild guess and I have no idea about your setup though so I might be completely wrong :D12:23
valentindbenschubert, the CPU usage follows very well the bandwidth. In that case I would expect CPU usage to be delayed.12:24
valentindbenschubert, It is still an interesting idea. I doubt it is it, but I will still have a look at that.12:24
benschubertdepends on the granularity of the cpu/bandwidth measurements, but yeah I would also expect a slit (ms wise) delay :)12:25
valentindbenschubert, in profiling I do not see any big calls to random generation.12:30
benschubertToo bad, it would have been a clue :/ I have no other ideas though :/12:30
juergbivalentind: https://github.com/grpc/grpc/blob/master/doc/ssl-performance.md12:46
juergbiseems like the Python builds do not use ASM optimizations12:47
juergbialso see https://github.com/grpc/grpc/issues/944012:47
valentindjuergbi, thank you!12:47
juergbimaybe we could create our own builds, at least for the server12:48
valentindjuergbi, yes we will try that.12:48
*** federico has joined #buildstream12:57
valentindI suppose it should be a known issue on the website.12:58
*** solid_black has quit IRC13:10
jmactest_pull_tree is consistently hanging today, I need to kill the process to stop it13:50
valentindjmac, this happens when the cache server that the test spawn crashes.14:08
valentindjmac, if your run with "-s" in the test options, you will probably see a stack trace from the server.14:09
raouljuergbi, thinking about the execution environment reqs, why would we want to be able to set OS and arch in elements? Surely the whole build should be for one platform or am I missing something14:10
juergbiraoul: this will be the common case, yes, however, there may be cases where this is useful and it matches the existing semantics for the `sandbox` dict (uid and gid support)14:12
juergbiraoul: e.g., you might want to cross bootstrap an AArch64 system from a x86-64 bootstrap14:12
juergbior you want to use buildstream to build your app for all platforms in a single project/session (possibly utilizing remote execution to cover the different platforms)14:13
juergbior build some x86-32 components in an otherwise x86-64 project (while this is anyway possible, setting x86-32 should make sure `uname -m` returns the right value, making things a bit simpler)14:14
raoulAh right, forgot about bootstrapping. For building for multiple platforms I guess we'll want a way of specifying a list of platforms to build for, rather than having a separate element for each platform14:16
juergbiyou'd probably want to use junctions for that case14:19
juergbiwith different junctions to the same multi-platform project, you can specify separate options and thus platforms14:19
raoulah that makes sense. Cheers juergbi!14:22
gitlab-br-botjuergbi merged MR !961 (tpollard/pipelinehostconfig->master: tests/plugin/pipeline.py: Avoid using host user conf) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/96114:30
*** lachlan has quit IRC14:49
benschubertQuestion about the artifact server cache: is cache eviction configurable? if so, how, if not, what is used currently?14:55
*** lachlan has joined #buildstream14:58
adds68benschubert, by eviction, do you mean expiration of artifacts, which in turn frees up space?15:08
benschubertYes15:09
tpollardyou can set a what value you want the expiry to kick in (in respect to storage size), but I don't think you can configure it kicking in outside of that15:12
adds68benschubert, yes buildstream does support this, however it is not documented, https://gitlab.com/BuildStream/buildstream/issues/76915:12
benschubertadds68: that's for the quota, I'd be more interested in the algorithm used for eviction sorry15:14
benschubertI forgot a word, meant "cache eviction strategy"15:14
WSalmontest15:15
tpollardadds68: that is documented https://docs.buildstream.build/using_config.html?highlight=expiry#local-cache-expiry15:16
benschuberttpollard: that is for local cache, my question was about the remote caching15:17
tlater[m]benschubert: eviction strategy is currently not configurable15:18
tlater[m]We always evict the LRU artifact15:18
tlater[m]Sorry, would have replied earlier, but my bouncer keeps signing me out and not telling me NickServ is complaining...15:19
tlater[m]This is true for both the local and remote cache, btw15:19
benschubertoh thanks, no worries :) mmh... I'm not entirely sure how cas works, but going through the cache directory and removing files older than X time would not break the cache right? (as a "manual" cache eviction)15:20
tlater[m]benschubert: It might do. iirc refs need to point to files in a semi-tree like structure, if any of the files are missing you get exceptions.15:21
jmacYep15:21
benschubertSo I would need more work than just that correct? I would break the entire cache with that, correct?15:21
tlater[m]benschubert: Besides, buildstream uses the mtime to determine what was least recently used.15:22
tlater[m]And yes, you'd break the cache ;)15:22
benschubertI would prefer the least recently written, not read x') Ok, too bad, guess I'll just need a big enough cache15:22
tlater[m]Yeah, changing that is unfortunately really difficult at the moment.15:23
benschuberttoo bad, thanks!15:25
adds68tpollard, is this the same for a remote cache configuration?15:26
tlater[m]adds68: I'm *fairly* sure, unless this has changed significantly over the past two months - jennis might also know more15:26
adds68tlater[m],, cool thnaks15:31
adds68thanks*15:31
adds68After an artifact is built, is there anyway to export just a single file from that artifact?15:31
tlater[m]adds68: Less sure about that, but I don't think there is currently.15:32
adds68hmm, currently my artifact has a bootstrap dependency, which allows me to shell in and view a file that is being generated15:32
adds68I know want to be able to export that file which was generated in the artifact15:33
tlater[m]adds68: The way this works is that it secretly puts the entire artifact in a hidden temporary directory.15:34
tlater[m]You can always export the full artifact and take a single file out15:34
tlater[m]Or if you want buildstream to do so, create a compose element that filters everything but the single file you want out.15:34
adds68Ooo compose, i think that is what i was looking for :)15:35
adds68So the compose will depend on the build element?15:35
tlater[m]Yes15:35
tlater[m]Hmm, I think I broke gitlab :|16:10
tlater[m]Oh, it fixed itself!16:10
*** bochecha has joined #buildstream16:17
gitlab-br-botwillsalmon closed issue #399 (Fails to create build directory for elements with workspaces) on buildstream https://gitlab.com/BuildStream/buildstream/issues/39916:17
*** lachlan has quit IRC16:18
gitlab-br-botwillsalmon merged MR !897 (willsalmon/defaultWorkspaces->master: Updated Workspace CLI) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/89716:20
laurencewoo!16:20
laurencetoscalix, can you think of any reason why we may have started to get email notifications for milestone changes? I *definitely* did not used to get them....and haven't changed my settings....16:33
toscalixI have not touched anything16:33
laurencetoscalix, no, I was asking in general, you know gitlab better than me :)16:34
toscalixfor those who are not interested in receiving notifications from changes of metadata only, you can define filters based on how the body starts16:34
laurencetoscalix, this also happened on buildgrid, come to think of it. might be a gitlab change16:34
toscalixlaurence: I really do not know why now16:35
toscalixmight be16:35
laurencenor me, I am perplexed16:35
toscalixdefine filters = define e-mail filters in your e-mail client16:36
toscalixfor instance, when changed a label, the notification body starts with.... Label added:16:37
toscalixwhen the milestone is changed the body starts with... Milestone changed to and so on16:37
toscalixyou will see the number of notifications reduced to changes in the description or changes of the tickets, not the labels or the milestones16:39
laurenceYes, i understand, thanks16:42
* tlater[m] wished his email providers actually implemented SIEVE or suchlike, it's really hard to use filters with mobile clients16:42
toscalixtlater[m]: I learnt the other day that you can us in gitlab one mail for the general subscription  and a different one for git16:44
toscalixyou can play then with getting the Codethink one for the BuildStream project so you can use filters in the webclient, which will then come to your mobile client already filtered16:45
tlater[m]Well, I don't use a mobile client for work email, because I don't have a work phone - just redirecting buildstream mail to my work mail might solve the issue though.16:47
tlater[m]Nice hint, thanks :)16:47
toscalixtogether with the use in the mobile of LabCoat.... helps a lot16:47
*** lachlan has joined #buildstream16:48
toscalixlaurence: do you use LabCoat? or any other mobile client for gitlab ?16:50
tlater[m]Oh, that's kinda cute16:53
tlater[m]And here I am fiddling with the web UI16:53
tlater[m]I could be doing code review with a proper, fast app!16:54
gitlab-br-botjmacarthur opened (was WIP) MR !946 (jmac/remote_execution_split->master: Split remote execution from artifact cache) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/94617:15
laurencetoscalix, I have not heard of it - will investigate, thanks :)17:18
*** jonathanmaw has quit IRC17:20
*** toscalix has quit IRC17:21
*** xjuan has joined #buildstream17:22
*** abderrahim has quit IRC17:36
*** raoul has quit IRC18:40
*** shinanyenzo has joined #buildstream20:29
*** tristan has quit IRC20:45
*** lachlan has quit IRC20:45
*** bochecha has quit IRC21:36
*** alatiera_ has quit IRC23:40
*** alatiera_ has joined #buildstream23:41

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