IRC logs for #buildstream for Friday, 2018-05-11

gitlab-br-botbuildstream: merge request (chandan/dead-code-removal->master: _project.py: Remove unused internal function _extract_plugin_paths()) #460 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/46001:04
gitlab-br-botbuildstream: merge request (chandan/dead-code-removal->master: _project.py: Remove unused internal function _extract_plugin_paths()) #460 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/46001:04
*** ohithere has joined #buildstream01:33
ohithere THIS NETWORK IS BLOWJOBS! GET ON SUPERNETS FOR COLD HARD CHATS NOW01:36
ohithere                                                                   01:36
ohithere                                                               01:36
ohithere                                                                   01:36
*** ohithere has quit IRC01:36
*** Sina has joined #buildstream02:01
Sina THIS NETWORK IS BLOWJOBS! GET ON SUPERNETS FOR COLD HARD CHATS NOW02:04
Sina                                                                   02:04
Sina                                                               02:04
*** Sina has quit IRC02:04
gitlab-br-botbuildstream: merge request (chandan/dead-code-removal->master: _project.py: Remove unused internal function _extract_plugin_paths()) #460 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/46002:46
*** tristan has joined #buildstream04:56
gitlab-br-botbuildstream: merge request (juerg/no-remote-summaries->master: WIP: Drop use of OSTree summary files and dynamically plan build dependencies) #446 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/44606:07
gitlab-br-botbuildstream: merge request (juerg/no-remote-summaries->master: Drop use of OSTree summary files and dynamically plan build dependencies) #446 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/44606:12
tristanjuergbi, ok so, basically we use clean return values to indicate failure which should not retry, and errors cause retries ?06:26
tristanI think that's what we have, we should be careful of that06:26
tristanI'm also not entirely sure if it should be true06:27
tristanright, when we successfully download a file, with _downloadablefilesource.py06:32
tristanwe *quite appropriately* raise a SourceError informing that the sha256sum is wrong06:33
tristanthe Job() goes ahead and retries06:33
tristanwhich is also wrong, downloading the file successfully 3 times will likely not change it's sha06:33
gitlab-br-botbuildstream: issue #397 ("Should not retry successfully downloaded files with bad checksums") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/39706:36
juergbimaybe we need something like fatal and non-fatal errors06:39
juergbior permanent vs. temporary as they are called in SMTP06:39
tristanpermanent vs temporary sounds better indeed06:41
juergbibtw: !446 is hopefully ready now06:41
tristanI suggested in the issue we could have a `retry` parameter06:41
tristanjuergbi, I noticed lack of WIP status yeah, will have to take a deep breath and dive in :)06:41
juergbiit's actually simpler than before06:42
juergbithere could be some bike shedding on names but other than that I think it all makes sense06:42
albfan[m]Any tips to build doc? Using only make on doc dir co.plains about some (generated on fly) rust files06:56
tristanalbfan[m], make -C doc, but it requires some deps... see the HACKING.rst file07:18
tristanit should work, we build the docs in CI so...07:18
tristanohhhh07:18
tristanalbfan[m], I think we still dont support the latest breakage introduced by fast-moving sphinx07:18
tristanalbfan[m], pip3 install sphinx==1.7.107:19
tristanalong with the other doc requirements07:19
tristanthere is an MR to "fix it", but the result is an ugly autogenerated ToC in some section07:20
gitlab-br-botbuildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45407:25
albfan[m]tristan: ok07:25
*** toscalix has joined #buildstream07:29
*** toscalix has quit IRC07:30
juergbitristan: hm, don't we still need to setup remotes after loading the elements as otherwise we don't have the subprojects yet07:48
tristanEh ?07:54
tristanHmmm07:54
tristanOhhhh07:54
tristanjuergbi, snap !07:55
tristantoo bad07:55
tristanjuergbi, we could call it *completely* after Stream._load() ?07:55
tristanI mean, the tight coupling of that with the load is undesirable isn't it ?07:56
tristanthe new comment is more interesting, though :)07:56
juergbihave to think about that07:56
juergbiin general, avoiding the tight coupling would be nice, however, we still change behavior in some places depending on whether we have remotes configures07:57
juergbi*configured07:57
tristanWhile resolving element state07:57
juergbie.g., without remotes configured elements never have 'pull pending'07:58
juergbiwhich means that a locally cached artifact is final, even in non-strict mode07:58
juergbiwhile with 'pull pending' it's not07:58
tristanAh right, it has to happen there07:59
tristanand we can't easily remove the element resolving out of there either, because in the case of 'plan', we need resolved elements to calculate the selection08:00
tristanOriginally I had no _load() function, and wanted the convenience helpers from Pipeline() to make it easy enough08:00
tristanbut then there was a lot of lines of code and opportunity to "get it wrong"08:00
tristanI guess we stick with "shove all that stuff in _load()"08:01
tristanwhich has it's own ugly side, but seems the lesser evil08:01
juergbioh, strange gitlab ux. pressing `r` with text selected in an open discussion creates a quote in the comment field outside the discussion :/08:03
tristansome weird things they do are intentional, even, have been surprised a few times08:05
tristanI was sure that "task lists" was actually a markdown bug08:05
*** bethw has joined #buildstream08:06
*** ernestask has joined #buildstream08:11
gitlab-br-botbuildstream: merge request (juerg/no-remote-summaries->master: Drop use of OSTree summary files and dynamically plan build dependencies) #446 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/44608:20
*** solid_black has joined #buildstream08:24
*** finn has joined #buildstream08:25
*** toscalix has joined #buildstream08:27
tristanjuergbi, lets resolve that discussion and merge then ?08:28
juergbiSounds good to me :)08:29
tristanI think I'm going to go ahead with the mtime cache keys for workspaces08:30
tristanI was not able to think of a convincing reason why mtimes would not be sufficient for the use case so far08:30
juergbiOk, I can't think of any real issues with it, although I still have an uneasy feeling about it08:31
tristanHeh08:31
tristanI have a more uneasy feeling about the heuristics and guesswork involved in other approaches08:31
*** dominic has joined #buildstream08:34
juergbi 16 files changed, 193 insertions(+), 277 deletions(-)08:35
juergbialways nice when the MR removes more lines than it adds :)08:35
tristanyeah, I managed that for a few other refactors, but missed the mark by a long shot with Stream() :-S08:36
tristanMostly boiler plate was added, though08:36
tristanjuergbi, in this case, we legitimately eliminated a lot of things which need not be done anymore, that is gratifying indeed :)08:37
*** noisecell has joined #buildstream08:43
gitlab-br-botbuildstream: merge request (juerg/no-remote-summaries->master: Drop use of OSTree summary files and dynamically plan build dependencies) #446 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/44608:45
gitlab-br-botbuildstream: merge request (tristan/optimize-workspace-keys->master: _workspaces.py: Use file mtime for workspace cache keys instead of checksumming) #455 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45508:46
tristanjuergbi, grrr, we dont get to see the codequality report !08:47
tristanI think it's because it failed for the target master commit08:47
tristanso there is no report to compare :-S08:48
tristancoverage increased by a good 0.1% :)08:48
*** jonathanmaw has joined #buildstream08:56
Nexusi like the bst.build twittername08:59
Nexusor bst-build or bst_build09:01
toscalixNexus: only underscore allowed09:02
toscalixbst says nothing to non-contributors. I would like to include the full name in the twitter ID09:03
Nexuswhy? mqny tagnames have no relation to the account. call it @banana and just pub buildstream as the name,it will still turn up on search09:04
*** solid_black has quit IRC09:04
Nexusit needs to be short, bst_build has a nice sound to it09:04
toscalixthere are many times that you need to reference and link the twitter name in docs and apps09:04
finnbuildstream build is a bit of a mouthful though09:04
tristantoscalix, I tend to agree that bst_build, or bstbuild even... is much nicer than trying to append something which doesnt fit to buildstream09:05
tristanespecially _prj09:05
toscalixand webs plus all helps when using fancy twitter apps will show the user when writting buildstream if that is the ID09:05
toscalixtristan: the fact you do not like my suggestion, which is not ideal, does not make bst better09:05
tristantoscalix, @bstbuild sounds really fine to me, and I agree with sander that with the right linkage and chitchat they will connect well09:06
tristantoscalix, except that bst is pretty much "the" nick name for shortening "buildstream"09:06
toscalixwith buildtream_x you have the name so you enjoy many little advantages09:06
tristantoscalix, so it is certainly much better than @bannana, while @buildstream_x just looks like "oh they came second"09:06
toscalixtristan: I do not agree, we need the name09:06
toscalixon the ID as preferred09:06
tristan_prj is really unattractive, there is no ring to it09:07
tristanit looks like a corporate database entry that nobody cared about09:07
toscalixletÅ› see if I can get @buildstream and we finish this debate about branding09:07
toscalixI a sure we can find another option that includes buildstream on the ID09:07
toscalixput bst and your project will be named bst09:08
tristanI would note that the majority of the web domains you mentioned are claimed, are indeed claimed, but obnoxiously unused09:08
toscalixyou are shouting for it09:08
toscalixtristan: have you read my mail about the domain?09:08
toscalixbuildstream.build is not taken09:09
tristanI did, and two out of three domains, like .io and .org, are not used by anyone09:09
tristanexcept they are claimed09:09
tristanso someone wants a million bucks09:09
tristan:-S09:09
tristanbuildstream.build would be alright as a domain indeed09:10
toscalixyep, the name is popular. This is whay usually you take the domain decision at the same time that the project name09:10
toscalixfor digital brands09:10
tristantoscalix, I honestly do think you are exaggerating by saying that people will call the project bst just because of a mere twitter handle09:11
toscalixbut now we will carry on and we will get a good one. It is just a matter of dedicating time to it09:11
tristanof course, I am someone who never owned a twitter account, nor care to read any tweet09:11
*** finn has quit IRC09:12
*** finn has joined #buildstream09:13
toscalixthere that people out there that earn good money whith these things so I assume they have an impact09:13
toscalixs/that/are09:14
tristanI here people even win elections with twitter campaigns these days :)09:14
finntwitter campaigns backed up with big data09:16
finnand bot accounts09:16
toscalix@buildstreambot I like it :-)09:16
finnwhich could be trained to spread the good word09:17
toscalixit is a shame we cannot add blockchain to the name. We would be sooo popular09:17
tristanjust a huge crpytographic blockchain in ascii... @YYs94kcps09LskK3j....09:19
gitlab-br-botbuildstream: merge request (tristan/optimize-workspace-keys->master: _workspaces.py: Use file mtime for workspace cache keys instead of checksumming) #455 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/45509:19
tristanNobody will forget how to find it09:19
tristanit will be like trying to find a google doc :)09:19
toscalix:-)09:19
Nexus@bstbst? :)09:22
Nexus@gnomebst ?09:22
skullmanhey bst, wanna build some software?09:22
finnwhen I see bst, I keep thinking British Summer Time09:22
gitlab-br-botbuildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45409:24
toscalixfinn: among other acronyms, different in each country, so people from different places will think about different things. A battle nobody can win09:25
finntbf, BST is the superior one of the timezones we keep here in Britain09:25
finnSo it can only be a good link to make09:26
jmacI'd append a noun describing what it is, e.g. @buildstreamtool09:26
finnI like that09:26
toscalixbuildstream have 5 consonants in a row, 5. It is so hard to pronounce already for many non-english speakers that it is already calling for a shortage. Give them bst and they will use it. And then... we are in hell.09:26
*** aday has joined #buildstream09:28
toscalixjmac: that is better than _prj09:28
gitlab-br-botbuildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45409:31
*** bethw has quit IRC09:51
*** cs_shadow has joined #buildstream09:58
tristantoscalix, imagine we came up with some kind of crazy name with many syllables, we'd be doomed !10:06
tristanlike: koo ber knee tees10:07
tristanactually I like jmac's @buildstreamtool as a second choice to @buildstream10:07
tristanit doesnt have that underscore and prj, which I somehow dislike a lot10:08
toscalixjmac: can you propose the @buildstreamtool name on the ML ? Maybe we have a winner if we cannot get @buildstream10:09
*** toscalix has quit IRC10:12
*** toscalix has joined #buildstream10:13
jmactoscalix: OK10:14
toscalixgreat, thanks10:14
tristanHrrrrm, so the remote cache expiration will calculate the entire size of the cache... every time10:15
tristanThat sounds expensive10:15
*** toscalix has quit IRC10:15
jmactoscalix: In a bit, I'm reinstalling my laptop right now10:15
tristanjuergbi, I wonder if we can reasonably apply this after all :-S10:17
finntristan, do you have any high level block diagrams of how this remote execution API is supposed to fit together?10:17
juergbiI think I was asking for performance impact on artifact expiry (local and/or remote) a while ago10:18
juergbibecause I'm worried about it as well10:18
tristanjuergbi, our case is... we have like 8 parallel build sessions pushing to the same cache, and we usually push these small artifacts, while the cache size should be fairly large, at least 100GB10:18
juergbithis was the reason why I thought we should initially just go for a free disk space approach to at least have something that doesn't have a big overhead10:18
tristanalso, jjardon already complained about performance and needed to add CPUs10:18
tristanjuergbi, that is indeed better10:18
tristanfree disk space would be snappy10:19
valentindIt would be nice to be able to configure the number of pulls independently to number of fetches in the scheduler. The same for the retries. For pulls we want lower number of simultaneous pulls, but a higher number of retries.10:21
valentindIs there already a way to do it that I cannot see?10:21
*** bethw has joined #buildstream10:24
tristanvalentind, no we have activities grouped together as "network activities" or "cpu/disk activities (builds)" basically10:25
tristanIt could be enhanced I guess, but I would first hesitate and wonder if we're working around other problems by providing configuration API10:25
valentind10 ostree pull goes crazy for the freedesktop SDK. While nginx follow without problem, the network gets connections delays of more than 30 seconds. Which is the non-configurable connection timeout for ostree with curl.10:26
valentind(When you have several builds in the same time)10:26
valentindI think it would be nice to group the ostree pulls together to one call to ostree at a time.10:27
valentindBecause now, ostree cannot reuse connections.10:27
tristanIs the problem actually that ostree does too many simultaneous requests ?10:29
tristanvalentind, taking a step back here... I see no problem fetching from many gits at once, downloading many tarballs at once... "why should I have to treat ostree specially" ?10:29
valentindI think it is part of the problem.10:29
tristanthat is a valid question I think10:29
valentindIt is from the same server.10:30
valentindThis is the difference.10:30
tristanWe also have `ostree` sources, which behave much the same way as pull10:30
tristanSo then we will have the same problem with source mirroring10:30
tristanIs that actually true ?10:30
valentindAnd ostree has this 30 seconds timeout, which other things do not have.10:30
valentindYes, if you have 100 different elements useing ostree as source and it is the same server.10:31
tristanSo then we dont *really* solve the problem this way10:31
tristanAlso, we will be very soon replacing ostree with CAS for artifact storage, locally and remotely10:31
valentindThat is fine. I wanted to know if there was another way to limit pulling artifacts.10:32
valentindBecause freedesktop-sdk is really struggling now.10:32
tristanBut were it not the case, I think we have to consider: We're adding irreversible configuration API which we need to live with forever, because of some inadequacy in a dependency10:32
tristanSo, if we're going to argue that we should have more configuration, we need to inform that decision with more than "ostree is causing problems"10:33
valentindWhat we should have is a way to provide our own HTTP client to ostree.10:34
tristanand see if the proposed additional configuration is relevant in every setup/underlying protocol10:34
valentindSo we have control on that.10:34
tristanI'm quite sure that ostree will be amenable to fixing issues we identify there, too10:35
tristanthey are not a distant community :)10:35
valentindtristan, something we should consider is HTTP download across plugins should share client. So that we can reuse connections. This would be nice for mirrors.10:35
tristanThat is a good point, I'll note also that networking is my area of least expertise :)10:36
tristanI have some kind of allergy to the stuff, it never sticks10:36
tristanAnyway from what I'm reading, it's the socket()/accept() part which is expensive, and doing that handshake very many times for small transfers is very inefficient10:38
valentindSpecially because we use HTTPS10:39
valentindAnd with HTTP2, always reusing connections is important. Because this is the only way to ensure correct priorities.10:39
tristanAh so there is a certificate exchange which happens for each initialization (perhaps, grabbing at straws, you'd think they'd have sorted it out better)10:39
tristanvalentind, do you think it's plausible to share connections for fetch() when downloading from a mirror ?10:41
tristanI mean, of course considering that a url alias is abstract, and might use any uri scheme10:41
valentindFor fetch yes.10:41
valentindIn Python you have to use the same http client.10:41
tristanAh so you could only do it for downloading tarballs ?10:42
valentindI am not sure of the details. But it should be possible.10:42
tristannot for git, bzr, cvs, whatever ?10:42
valentindWell there I do not know.10:42
valentindUnless we make a proxy.10:43
* tristan is thinking rather to have an in-between entity, and force anything that our subprocess does to go through a virtual network we setup10:43
tristanmaybe something like that is what the network people call a "proxy" :D10:43
valentindWell then we have to recognize what is HTTP, what is not. And we cannot do HTTPS connections.10:44
* tristan is going to meet for dinner10:48
tristanaaaaand it still happens with the bwrap version check patch reverted: https://gitlab.com/BuildStream/buildstream/-/jobs/6770886710:50
tristandamn10:50
*** tristan has quit IRC10:53
*** jennis has joined #buildstream11:14
gitlab-br-botbuildstream: issue #398 ("bst init does not respect --element-path option") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/39811:17
*** aday has quit IRC11:22
*** aday has joined #buildstream11:28
NexusIs there a function or variable stored that i can access which says whether or not a remote cache is being used?11:35
gitlab-br-botbuildstream: merge request (chandan/fix-bst-init-element-path->master: bst-init: Ensure --element-path is respected by the command) #461 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/46111:36
*** jennis has quit IRC11:37
*** jennis has joined #buildstream12:00
*** jennis_ has joined #buildstream12:00
*** aday has quit IRC12:17
*** aday has joined #buildstream12:22
*** toscalix has joined #buildstream12:34
*** bochecha_ has joined #buildstream12:42
*** xjuan has joined #buildstream12:48
*** aday has quit IRC12:51
*** aday has joined #buildstream13:22
finnhey, just quickly reading issue #288, for some context, this just just asking for element.normal_name to be removed in favour of element.name?13:47
finnhttps://gitlab.com/BuildStream/buildstream/issues/28813:49
jmacYes, I think so13:49
finnSo since normal_name removes separators in favour of '-', does this mean you want self.name to have separators removed?13:52
jmacYou'll need to ask tristan that when he's next online13:54
tlaterI'm pretty sure your interpretation is correct, finn13:56
tlaterOh, no13:56
tlaterWe want path separators instead of '-'13:56
finnso you'd want the element: hello/world to still be called hello/world? instead of hello-world13:57
tlaterHaving recently had a look at the separators I don't think that's an issue at all; in fact, it should make the logs more browsable.13:57
tlaterYep, I think that's the intention13:57
finnstops you from getting confused with an element: hello-world/foo13:57
finncool13:57
finnthanks13:57
tlaterIf not, should be quick to fix if tristan does complain ;)13:57
jmacBut the issue says "It is also used to create log file names, these are also better off without the normal_name substitutions."13:57
jmacYou can't call the log file hello/world13:58
tlaterjmac: Hm, not sure if a call to os.makedirs is required13:58
finnYou could call it hello\/world.txt ?13:58
finn:P13:58
tlaterI think the atomic file creation function does that for you13:59
jmacI don't think you can escape directory separators13:59
tlaterIt'll be an experiment! ;p13:59
jmacWell, I can't on my ext4 system13:59
jmacWhat if your element is called "/"?14:00
tlaterjmac: Can you name your element that?14:00
tlaterI suppose you could if you'd first used a different file system14:00
jmacI don't know. Last time I looked we didn't have any formal element names14:00
jmacformal element name rules, I mean14:00
jmacThis came up when we had spaces in the project name14:01
tlaterWe might need to define this, then14:01
tlaterIn either case, I think the intention is to - -> / for now14:02
jmacAh, wait, I thought element names were specified in YAML, but they're just pathnames14:04
jmacIn which case having a logfile called hello/world for an element called hello/world is more acceptable14:05
tlaterYour point still stands, you could define a weird file system that breaks everything and then copy over your buildstream project14:05
paulsherwoodiirc there was a philosophical debate about names in the files vs names of the files14:05
jmactlater: But if you've got element names called "/" you can't import them into your (ext4-based) buildstream host at all14:08
tlaterAlso a point14:08
jmacThere might be corner cases, but if we're trying to guess the intent of #288, I'd say it means elements with path separators produce log files with path separators14:09
*** bethwhite_ has joined #buildstream14:48
*** bethw has quit IRC14:49
*** jonathanmaw has quit IRC15:03
*** slaf has joined #buildstream15:04
*** slaf has joined #buildstream15:04
*** slaf has joined #buildstream15:04
*** slaf has joined #buildstream15:05
*** slaf has joined #buildstream15:05
*** jonathanmaw has joined #buildstream15:19
*** slaf has quit IRC15:24
*** slaf has joined #buildstream15:39
*** slaf has joined #buildstream15:39
*** slaf has joined #buildstream15:39
*** slaf has joined #buildstream15:39
gitlab-br-botbuildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45415:43
gitlab-br-botbuildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45415:47
*** toscalix has quit IRC15:56
albfan[m]tristan: how a user is supposed to know what to check if want to use ostree repo as an element. I try this commands on my host https://pastebin.com/EtVb2qak15:59
gitlab-br-botbuildstream: merge request (chandan/368-bst-from-project-subdir->master: WIP: _project.py: Allow running bst commands from subdirectories of project root) #428 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/42816:01
gitlab-br-botbuildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/31716:02
*** ernestask has quit IRC16:02
gitlab-br-botbuildstream: merge request (chandan/368-bst-from-project-subdir->master: WIP: _project.py: Allow running bst commands from subdirectories of project root) #428 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/42816:04
gitlab-br-botbuildstream: merge request (valentindavid/359_cross_junction_elements->master: WIP: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45416:10
gitlab-br-botbuildstream: merge request (valentindavid/359_cross_junction_elements->master: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/45416:12
*** bethwhite_ has quit IRC16:12
albfan[m]tristan: downgrade sphinx from 1.7.3 to 1.7.1 does the trick. Hope to write something and contribute to https://gitlab.com/BuildStream/buildstream/issues/10316:19
*** jonathanmaw has quit IRC16:30
*** bethwhite_ has joined #buildstream16:36
*** tiago has quit IRC16:38
*** bethwhite_ has quit IRC16:39
*** tiago has joined #buildstream16:41
*** finn has quit IRC16:43
*** tiago has quit IRC16:45
*** tiago has joined #buildstream16:45
*** tiago has quit IRC16:45
gitlab-br-botbuildstream: merge request (chandan/393-fix-workspace-no-reference->master: element.py: Fix consistency of workspaced elements when ref is missing) #462 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/46217:23
*** dominic has quit IRC18:34
*** awacheux has quit IRC18:55
*** bochecha_ has quit IRC19:40
*** bochecha_ has joined #buildstream19:41
*** tristan has joined #buildstream20:27
*** bochecha_ has quit IRC20:47
*** xjuan has quit IRC21:14
*** cs_shadow has quit IRC22:03
*** tristan has quit IRC22:46
*** aday has quit IRC23:04
*** jennis_ has quit IRC23:10
*** jennis has quit IRC23:10

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