*** mohan43u has quit IRC | 00:02 | |
*** federico has joined #buildstream | 00:11 | |
*** alatiera__ has quit IRC | 00:44 | |
*** mohan43u has joined #buildstream | 01:12 | |
*** federico has quit IRC | 01:41 | |
*** murph has joined #buildstream | 04:39 | |
*** CTtpollard has joined #buildstream | 06:21 | |
*** ctolentino has joined #buildstream | 06:21 | |
*** benschubert has joined #buildstream | 06:21 | |
*** slaf has joined #buildstream | 06:21 | |
*** gitlab-br-bot has joined #buildstream | 06:21 | |
*** lchlan has joined #buildstream | 06:21 | |
*** laurence has joined #buildstream | 06:21 | |
*** paulsherwood has joined #buildstream | 06:21 | |
*** jmac has joined #buildstream | 06:21 | |
*** skullman has joined #buildstream | 06:21 | |
*** dineshdb[m] has joined #buildstream | 06:21 | |
*** Demos[m] has joined #buildstream | 06:21 | |
*** waltervargas[m] has joined #buildstream | 06:21 | |
*** doras[m] has joined #buildstream | 06:21 | |
*** inigomartinez has joined #buildstream | 06:21 | |
*** connorshea[m] has joined #buildstream | 06:21 | |
*** oknf[m] has joined #buildstream | 06:21 | |
*** segfault3[m] has joined #buildstream | 06:21 | |
*** jjardon[m] has joined #buildstream | 06:21 | |
*** asingh_[m] has joined #buildstream | 06:21 | |
*** awacheux[m] has joined #buildstream | 06:21 | |
*** tlater[m] has joined #buildstream | 06:21 | |
*** kailueke[m] has joined #buildstream | 06:21 | |
*** krichter[m] has joined #buildstream | 06:21 | |
*** alatiera has joined #buildstream | 06:21 | |
*** cgmcintyre[m] has joined #buildstream | 06:21 | |
*** rafaelff[m] has joined #buildstream | 06:21 | |
*** mattiasb has joined #buildstream | 06:21 | |
*** ssssam[m] has joined #buildstream | 06:21 | |
*** albfan[m] has joined #buildstream | 06:21 | |
*** m_22[m] has joined #buildstream | 06:21 | |
*** abderrahim[m] has joined #buildstream | 06:21 | |
*** pro[m] has joined #buildstream | 06:21 | |
*** theawless[m] has joined #buildstream | 06:21 | |
*** tintou has joined #buildstream | 06:21 | |
*** ironfoot has joined #buildstream | 06:21 | |
*** hergertme has joined #buildstream | 06:21 | |
*** jjardon has joined #buildstream | 06:21 | |
*** juergbi has joined #buildstream | 06:21 | |
*** persia has joined #buildstream | 06:21 | |
*** irc.poop.nl sets mode: +oo ironfoot jjardon | 06:21 | |
*** ctolentino has quit IRC | 06:44 | |
*** mohan43u has quit IRC | 07:26 | |
*** mohan43u has joined #buildstream | 07:26 | |
*** tristan has joined #buildstream | 08:34 | |
*** toscalix has joined #buildstream | 08:47 | |
*** u63 has joined #buildstream | 09:27 | |
*** solid_black has joined #buildstream | 09:35 | |
gitlab-br-bot | BenjaminSchubert merged MR !958 (bschubert/mr938-comments->master: Followup on MR 938, addressing additional comments) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/958 | 09:52 |
---|---|---|
*** raoul has joined #buildstream | 10:14 | |
*** jonathanmaw has joined #buildstream | 10:19 | |
*** lachlan has joined #buildstream | 10:25 | |
*** yashsriv has joined #buildstream | 10:25 | |
*** lachlan has quit IRC | 10:45 | |
*** alatiera_ has joined #buildstream | 10:49 | |
*** lachlan has joined #buildstream | 10:50 | |
laurence | test | 11:13 |
laurence | woo, sorry, had to remember how to register... | 11:13 |
laurence | phildawson, hi, you recently raised an MR to retire the source bundle command - https://gitlab.com/BuildStream/buildstream/merge_requests/959 | 11:13 |
laurence | just wondering if you need to poke people for review? | 11:13 |
laurence | (I'm going through some MRs that are non-WIP) | 11:13 |
phildawson | laurence, yes, reviews would be appreciated. Kinnison has had a brief look but more would be great :) | 11:15 |
benschubert | Can'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-bot | tpollard opened MR !961 (tpollard/pipelinehostconfig->master: tests/plugin/pipeline.py: Avoid using host user conf) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/961 | 11:52 |
juergbi | benschubert: 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 stack | 11:52 |
*** CTtpollard is now known as tpollard | 11:53 | |
juergbi | However, maybe there is a use case where workarounds would be painful enough to motivate support in BuildStream core | 11:53 |
benschubert | True, unless elements are autogenerated :) I'll look more into that | 11:53 |
valentind | juergbi, I did some profiling of the freedesktop-sdk cache server. | 12:15 |
valentind | Half the time is used in openssl. Which explains why CPU usage follows bandwidth | 12:16 |
valentind | However, to me it uses more than it should do. Running "openssl speed aes-128-gcm" gives me better results on that machine. | 12:16 |
valentind | I would expect openssl in grpcio to go 25 times faster. | 12:17 |
valentind | The issue is https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/474 | 12:18 |
valentind | juergbi, if you have any idea on what to do to improve the situation, that would be nice. | 12:19 |
benschubert | valentind: 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 well | 12:21 |
valentind | benschubert, 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 |
benschubert | opensssl speed might also not use enough, but thousands of simultaneous connections might right? | 12:23 |
benschubert | it's a wild guess and I have no idea about your setup though so I might be completely wrong :D | 12:23 |
valentind | benschubert, the CPU usage follows very well the bandwidth. In that case I would expect CPU usage to be delayed. | 12:24 |
valentind | benschubert, It is still an interesting idea. I doubt it is it, but I will still have a look at that. | 12:24 |
benschubert | depends on the granularity of the cpu/bandwidth measurements, but yeah I would also expect a slit (ms wise) delay :) | 12:25 |
valentind | benschubert, in profiling I do not see any big calls to random generation. | 12:30 |
benschubert | Too bad, it would have been a clue :/ I have no other ideas though :/ | 12:30 |
juergbi | valentind: https://github.com/grpc/grpc/blob/master/doc/ssl-performance.md | 12:46 |
juergbi | seems like the Python builds do not use ASM optimizations | 12:47 |
juergbi | also see https://github.com/grpc/grpc/issues/9440 | 12:47 |
valentind | juergbi, thank you! | 12:47 |
juergbi | maybe we could create our own builds, at least for the server | 12:48 |
valentind | juergbi, yes we will try that. | 12:48 |
*** federico has joined #buildstream | 12:57 | |
valentind | I suppose it should be a known issue on the website. | 12:58 |
*** solid_black has quit IRC | 13:10 | |
jmac | test_pull_tree is consistently hanging today, I need to kill the process to stop it | 13:50 |
valentind | jmac, this happens when the cache server that the test spawn crashes. | 14:08 |
valentind | jmac, if your run with "-s" in the test options, you will probably see a stack trace from the server. | 14:09 |
raoul | juergbi, 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 something | 14:10 |
juergbi | raoul: 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 |
juergbi | raoul: e.g., you might want to cross bootstrap an AArch64 system from a x86-64 bootstrap | 14:12 |
juergbi | or 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 |
juergbi | or 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 |
raoul | Ah 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 platform | 14:16 |
juergbi | you'd probably want to use junctions for that case | 14:19 |
juergbi | with different junctions to the same multi-platform project, you can specify separate options and thus platforms | 14:19 |
raoul | ah that makes sense. Cheers juergbi! | 14:22 |
gitlab-br-bot | juergbi merged MR !961 (tpollard/pipelinehostconfig->master: tests/plugin/pipeline.py: Avoid using host user conf) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/961 | 14:30 |
*** lachlan has quit IRC | 14:49 | |
benschubert | Question about the artifact server cache: is cache eviction configurable? if so, how, if not, what is used currently? | 14:55 |
*** lachlan has joined #buildstream | 14:58 | |
adds68 | benschubert, by eviction, do you mean expiration of artifacts, which in turn frees up space? | 15:08 |
benschubert | Yes | 15:09 |
tpollard | you 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 that | 15:12 |
adds68 | benschubert, yes buildstream does support this, however it is not documented, https://gitlab.com/BuildStream/buildstream/issues/769 | 15:12 |
benschubert | adds68: that's for the quota, I'd be more interested in the algorithm used for eviction sorry | 15:14 |
benschubert | I forgot a word, meant "cache eviction strategy" | 15:14 |
WSalmon | test | 15:15 |
tpollard | adds68: that is documented https://docs.buildstream.build/using_config.html?highlight=expiry#local-cache-expiry | 15:16 |
benschubert | tpollard: that is for local cache, my question was about the remote caching | 15:17 |
tlater[m] | benschubert: eviction strategy is currently not configurable | 15:18 |
tlater[m] | We always evict the LRU artifact | 15: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, btw | 15:19 |
benschubert | oh 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 |
jmac | Yep | 15:21 |
benschubert | So 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 |
benschubert | I would prefer the least recently written, not read x') Ok, too bad, guess I'll just need a big enough cache | 15:22 |
tlater[m] | Yeah, changing that is unfortunately really difficult at the moment. | 15:23 |
benschubert | too bad, thanks! | 15:25 |
adds68 | tpollard, 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 more | 15:26 |
adds68 | tlater[m],, cool thnaks | 15:31 |
adds68 | thanks* | 15:31 |
adds68 | After 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 |
adds68 | hmm, currently my artifact has a bootstrap dependency, which allows me to shell in and view a file that is being generated | 15:32 |
adds68 | I know want to be able to export that file which was generated in the artifact | 15: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 out | 15: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 |
adds68 | Ooo compose, i think that is what i was looking for :) | 15:35 |
adds68 | So the compose will depend on the build element? | 15:35 |
tlater[m] | Yes | 15:35 |
tlater[m] | Hmm, I think I broke gitlab :| | 16:10 |
tlater[m] | Oh, it fixed itself! | 16:10 |
*** bochecha has joined #buildstream | 16:17 | |
gitlab-br-bot | willsalmon closed issue #399 (Fails to create build directory for elements with workspaces) on buildstream https://gitlab.com/BuildStream/buildstream/issues/399 | 16:17 |
*** lachlan has quit IRC | 16:18 | |
gitlab-br-bot | willsalmon merged MR !897 (willsalmon/defaultWorkspaces->master: Updated Workspace CLI) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/897 | 16:20 |
laurence | woo! | 16:20 |
laurence | toscalix, 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 |
toscalix | I have not touched anything | 16:33 |
laurence | toscalix, no, I was asking in general, you know gitlab better than me :) | 16:34 |
toscalix | for those who are not interested in receiving notifications from changes of metadata only, you can define filters based on how the body starts | 16:34 |
laurence | toscalix, this also happened on buildgrid, come to think of it. might be a gitlab change | 16:34 |
toscalix | laurence: I really do not know why now | 16:35 |
toscalix | might be | 16:35 |
laurence | nor me, I am perplexed | 16:35 |
toscalix | define filters = define e-mail filters in your e-mail client | 16:36 |
toscalix | for instance, when changed a label, the notification body starts with.... Label added: | 16:37 |
toscalix | when the milestone is changed the body starts with... Milestone changed to and so on | 16:37 |
toscalix | you will see the number of notifications reduced to changes in the description or changes of the tickets, not the labels or the milestones | 16:39 |
laurence | Yes, i understand, thanks | 16:42 |
* tlater[m] wished his email providers actually implemented SIEVE or suchlike, it's really hard to use filters with mobile clients | 16:42 | |
toscalix | tlater[m]: I learnt the other day that you can us in gitlab one mail for the general subscription and a different one for git | 16:44 |
toscalix | you 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 filtered | 16: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 |
toscalix | together with the use in the mobile of LabCoat.... helps a lot | 16:47 |
*** lachlan has joined #buildstream | 16:48 | |
toscalix | laurence: do you use LabCoat? or any other mobile client for gitlab ? | 16:50 |
tlater[m] | Oh, that's kinda cute | 16:53 |
tlater[m] | And here I am fiddling with the web UI | 16:53 |
tlater[m] | I could be doing code review with a proper, fast app! | 16:54 |
gitlab-br-bot | jmacarthur 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/946 | 17:15 |
laurence | toscalix, I have not heard of it - will investigate, thanks :) | 17:18 |
*** jonathanmaw has quit IRC | 17:20 | |
*** toscalix has quit IRC | 17:21 | |
*** xjuan has joined #buildstream | 17:22 | |
*** abderrahim has quit IRC | 17:36 | |
*** raoul has quit IRC | 18:40 | |
*** shinanyenzo has joined #buildstream | 20:29 | |
*** tristan has quit IRC | 20:45 | |
*** lachlan has quit IRC | 20:45 | |
*** bochecha has quit IRC | 21:36 | |
*** alatiera_ has quit IRC | 23:40 | |
*** alatiera_ has joined #buildstream | 23:41 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!