gitlab-br-bot | buildstream: 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/460 | 01:04 |
---|---|---|
gitlab-br-bot | buildstream: 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/460 | 01:04 |
*** ohithere has joined #buildstream | 01:33 | |
ohithere | THIS NETWORK IS BLOWJOBS! GET ON SUPERNETS FOR COLD HARD CHATS NOW | 01:36 |
ohithere | 01:36 | |
ohithere | 01:36 | |
ohithere | 01:36 | |
*** ohithere has quit IRC | 01:36 | |
*** Sina has joined #buildstream | 02:01 | |
Sina | THIS NETWORK IS BLOWJOBS! GET ON SUPERNETS FOR COLD HARD CHATS NOW | 02:04 |
Sina | 02:04 | |
Sina | 02:04 | |
*** Sina has quit IRC | 02:04 | |
gitlab-br-bot | buildstream: 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/460 | 02:46 |
*** tristan has joined #buildstream | 04:56 | |
gitlab-br-bot | buildstream: 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/446 | 06:07 |
gitlab-br-bot | buildstream: 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/446 | 06:12 |
tristan | juergbi, ok so, basically we use clean return values to indicate failure which should not retry, and errors cause retries ? | 06:26 |
tristan | I think that's what we have, we should be careful of that | 06:26 |
tristan | I'm also not entirely sure if it should be true | 06:27 |
tristan | right, when we successfully download a file, with _downloadablefilesource.py | 06:32 |
tristan | we *quite appropriately* raise a SourceError informing that the sha256sum is wrong | 06:33 |
tristan | the Job() goes ahead and retries | 06:33 |
tristan | which is also wrong, downloading the file successfully 3 times will likely not change it's sha | 06:33 |
gitlab-br-bot | buildstream: issue #397 ("Should not retry successfully downloaded files with bad checksums") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/397 | 06:36 |
juergbi | maybe we need something like fatal and non-fatal errors | 06:39 |
juergbi | or permanent vs. temporary as they are called in SMTP | 06:39 |
tristan | permanent vs temporary sounds better indeed | 06:41 |
juergbi | btw: !446 is hopefully ready now | 06:41 |
tristan | I suggested in the issue we could have a `retry` parameter | 06:41 |
tristan | juergbi, I noticed lack of WIP status yeah, will have to take a deep breath and dive in :) | 06:41 |
juergbi | it's actually simpler than before | 06:42 |
juergbi | there could be some bike shedding on names but other than that I think it all makes sense | 06:42 |
albfan[m] | Any tips to build doc? Using only make on doc dir co.plains about some (generated on fly) rust files | 06:56 |
tristan | albfan[m], make -C doc, but it requires some deps... see the HACKING.rst file | 07:18 |
tristan | it should work, we build the docs in CI so... | 07:18 |
tristan | ohhhh | 07:18 |
tristan | albfan[m], I think we still dont support the latest breakage introduced by fast-moving sphinx | 07:18 |
tristan | albfan[m], pip3 install sphinx==1.7.1 | 07:19 |
tristan | along with the other doc requirements | 07:19 |
tristan | there is an MR to "fix it", but the result is an ugly autogenerated ToC in some section | 07:20 |
gitlab-br-bot | buildstream: 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/454 | 07:25 |
albfan[m] | tristan: ok | 07:25 |
*** toscalix has joined #buildstream | 07:29 | |
*** toscalix has quit IRC | 07:30 | |
juergbi | tristan: hm, don't we still need to setup remotes after loading the elements as otherwise we don't have the subprojects yet | 07:48 |
tristan | Eh ? | 07:54 |
tristan | Hmmm | 07:54 |
tristan | Ohhhh | 07:54 |
tristan | juergbi, snap ! | 07:55 |
tristan | too bad | 07:55 |
tristan | juergbi, we could call it *completely* after Stream._load() ? | 07:55 |
tristan | I mean, the tight coupling of that with the load is undesirable isn't it ? | 07:56 |
tristan | the new comment is more interesting, though :) | 07:56 |
juergbi | have to think about that | 07:56 |
juergbi | in general, avoiding the tight coupling would be nice, however, we still change behavior in some places depending on whether we have remotes configures | 07:57 |
juergbi | *configured | 07:57 |
tristan | While resolving element state | 07:57 |
juergbi | e.g., without remotes configured elements never have 'pull pending' | 07:58 |
juergbi | which means that a locally cached artifact is final, even in non-strict mode | 07:58 |
juergbi | while with 'pull pending' it's not | 07:58 |
tristan | Ah right, it has to happen there | 07:59 |
tristan | and 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 selection | 08:00 |
tristan | Originally I had no _load() function, and wanted the convenience helpers from Pipeline() to make it easy enough | 08:00 |
tristan | but then there was a lot of lines of code and opportunity to "get it wrong" | 08:00 |
tristan | I guess we stick with "shove all that stuff in _load()" | 08:01 |
tristan | which has it's own ugly side, but seems the lesser evil | 08:01 |
juergbi | oh, strange gitlab ux. pressing `r` with text selected in an open discussion creates a quote in the comment field outside the discussion :/ | 08:03 |
tristan | some weird things they do are intentional, even, have been surprised a few times | 08:05 |
tristan | I was sure that "task lists" was actually a markdown bug | 08:05 |
*** bethw has joined #buildstream | 08:06 | |
*** ernestask has joined #buildstream | 08:11 | |
gitlab-br-bot | buildstream: 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/446 | 08:20 |
*** solid_black has joined #buildstream | 08:24 | |
*** finn has joined #buildstream | 08:25 | |
*** toscalix has joined #buildstream | 08:27 | |
tristan | juergbi, lets resolve that discussion and merge then ? | 08:28 |
juergbi | Sounds good to me :) | 08:29 |
tristan | I think I'm going to go ahead with the mtime cache keys for workspaces | 08:30 |
tristan | I was not able to think of a convincing reason why mtimes would not be sufficient for the use case so far | 08:30 |
juergbi | Ok, I can't think of any real issues with it, although I still have an uneasy feeling about it | 08:31 |
tristan | Heh | 08:31 |
tristan | I have a more uneasy feeling about the heuristics and guesswork involved in other approaches | 08:31 |
*** dominic has joined #buildstream | 08:34 | |
juergbi | 16 files changed, 193 insertions(+), 277 deletions(-) | 08:35 |
juergbi | always nice when the MR removes more lines than it adds :) | 08:35 |
tristan | yeah, I managed that for a few other refactors, but missed the mark by a long shot with Stream() :-S | 08:36 |
tristan | Mostly boiler plate was added, though | 08:36 |
tristan | juergbi, 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 #buildstream | 08:43 | |
gitlab-br-bot | buildstream: 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/446 | 08:45 |
gitlab-br-bot | buildstream: 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/455 | 08:46 |
tristan | juergbi, grrr, we dont get to see the codequality report ! | 08:47 |
tristan | I think it's because it failed for the target master commit | 08:47 |
tristan | so there is no report to compare :-S | 08:48 |
tristan | coverage increased by a good 0.1% :) | 08:48 |
*** jonathanmaw has joined #buildstream | 08:56 | |
Nexus | i like the bst.build twittername | 08:59 |
Nexus | or bst-build or bst_build | 09:01 |
toscalix | Nexus: only underscore allowed | 09:02 |
toscalix | bst says nothing to non-contributors. I would like to include the full name in the twitter ID | 09:03 |
Nexus | why? mqny tagnames have no relation to the account. call it @banana and just pub buildstream as the name,it will still turn up on search | 09:04 |
*** solid_black has quit IRC | 09:04 | |
Nexus | it needs to be short, bst_build has a nice sound to it | 09:04 |
toscalix | there are many times that you need to reference and link the twitter name in docs and apps | 09:04 |
finn | buildstream build is a bit of a mouthful though | 09:04 |
tristan | toscalix, I tend to agree that bst_build, or bstbuild even... is much nicer than trying to append something which doesnt fit to buildstream | 09:05 |
tristan | especially _prj | 09:05 |
toscalix | and webs plus all helps when using fancy twitter apps will show the user when writting buildstream if that is the ID | 09:05 |
toscalix | tristan: the fact you do not like my suggestion, which is not ideal, does not make bst better | 09:05 |
tristan | toscalix, @bstbuild sounds really fine to me, and I agree with sander that with the right linkage and chitchat they will connect well | 09:06 |
tristan | toscalix, except that bst is pretty much "the" nick name for shortening "buildstream" | 09:06 |
toscalix | with buildtream_x you have the name so you enjoy many little advantages | 09:06 |
tristan | toscalix, so it is certainly much better than @bannana, while @buildstream_x just looks like "oh they came second" | 09:06 |
toscalix | tristan: I do not agree, we need the name | 09:06 |
toscalix | on the ID as preferred | 09:06 |
tristan | _prj is really unattractive, there is no ring to it | 09:07 |
tristan | it looks like a corporate database entry that nobody cared about | 09:07 |
toscalix | letÅ› see if I can get @buildstream and we finish this debate about branding | 09:07 |
toscalix | I a sure we can find another option that includes buildstream on the ID | 09:07 |
toscalix | put bst and your project will be named bst | 09:08 |
tristan | I would note that the majority of the web domains you mentioned are claimed, are indeed claimed, but obnoxiously unused | 09:08 |
toscalix | you are shouting for it | 09:08 |
toscalix | tristan: have you read my mail about the domain? | 09:08 |
toscalix | buildstream.build is not taken | 09:09 |
tristan | I did, and two out of three domains, like .io and .org, are not used by anyone | 09:09 |
tristan | except they are claimed | 09:09 |
tristan | so someone wants a million bucks | 09:09 |
tristan | :-S | 09:09 |
tristan | buildstream.build would be alright as a domain indeed | 09:10 |
toscalix | yep, the name is popular. This is whay usually you take the domain decision at the same time that the project name | 09:10 |
toscalix | for digital brands | 09:10 |
tristan | toscalix, I honestly do think you are exaggerating by saying that people will call the project bst just because of a mere twitter handle | 09:11 |
toscalix | but now we will carry on and we will get a good one. It is just a matter of dedicating time to it | 09:11 |
tristan | of course, I am someone who never owned a twitter account, nor care to read any tweet | 09:11 |
*** finn has quit IRC | 09:12 | |
*** finn has joined #buildstream | 09:13 | |
toscalix | there that people out there that earn good money whith these things so I assume they have an impact | 09:13 |
toscalix | s/that/are | 09:14 |
tristan | I here people even win elections with twitter campaigns these days :) | 09:14 |
finn | twitter campaigns backed up with big data | 09:16 |
finn | and bot accounts | 09:16 |
toscalix | @buildstreambot I like it :-) | 09:16 |
finn | which could be trained to spread the good word | 09:17 |
toscalix | it is a shame we cannot add blockchain to the name. We would be sooo popular | 09:17 |
tristan | just a huge crpytographic blockchain in ascii... @YYs94kcps09LskK3j.... | 09:19 |
gitlab-br-bot | buildstream: 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/455 | 09:19 |
tristan | Nobody will forget how to find it | 09:19 |
tristan | it will be like trying to find a google doc :) | 09:19 |
toscalix | :-) | 09:19 |
Nexus | @bstbst? :) | 09:22 |
Nexus | @gnomebst ? | 09:22 |
skullman | hey bst, wanna build some software? | 09:22 |
finn | when I see bst, I keep thinking British Summer Time | 09:22 |
gitlab-br-bot | buildstream: 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/454 | 09:24 |
toscalix | finn: among other acronyms, different in each country, so people from different places will think about different things. A battle nobody can win | 09:25 |
finn | tbf, BST is the superior one of the timezones we keep here in Britain | 09:25 |
finn | So it can only be a good link to make | 09:26 |
jmac | I'd append a noun describing what it is, e.g. @buildstreamtool | 09:26 |
finn | I like that | 09:26 |
toscalix | buildstream 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 #buildstream | 09:28 | |
toscalix | jmac: that is better than _prj | 09:28 |
gitlab-br-bot | buildstream: 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/454 | 09:31 |
*** bethw has quit IRC | 09:51 | |
*** cs_shadow has joined #buildstream | 09:58 | |
tristan | toscalix, imagine we came up with some kind of crazy name with many syllables, we'd be doomed ! | 10:06 |
tristan | like: koo ber knee tees | 10:07 |
tristan | actually I like jmac's @buildstreamtool as a second choice to @buildstream | 10:07 |
tristan | it doesnt have that underscore and prj, which I somehow dislike a lot | 10:08 |
toscalix | jmac: can you propose the @buildstreamtool name on the ML ? Maybe we have a winner if we cannot get @buildstream | 10:09 |
*** toscalix has quit IRC | 10:12 | |
*** toscalix has joined #buildstream | 10:13 | |
jmac | toscalix: OK | 10:14 |
toscalix | great, thanks | 10:14 |
tristan | Hrrrrm, so the remote cache expiration will calculate the entire size of the cache... every time | 10:15 |
tristan | That sounds expensive | 10:15 |
*** toscalix has quit IRC | 10:15 | |
jmac | toscalix: In a bit, I'm reinstalling my laptop right now | 10:15 |
tristan | juergbi, I wonder if we can reasonably apply this after all :-S | 10:17 |
finn | tristan, do you have any high level block diagrams of how this remote execution API is supposed to fit together? | 10:17 |
juergbi | I think I was asking for performance impact on artifact expiry (local and/or remote) a while ago | 10:18 |
juergbi | because I'm worried about it as well | 10:18 |
tristan | juergbi, 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 100GB | 10:18 |
juergbi | this 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 overhead | 10:18 |
tristan | also, jjardon already complained about performance and needed to add CPUs | 10:18 |
tristan | juergbi, that is indeed better | 10:18 |
tristan | free disk space would be snappy | 10:19 |
valentind | It 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 |
valentind | Is there already a way to do it that I cannot see? | 10:21 |
*** bethw has joined #buildstream | 10:24 | |
tristan | valentind, no we have activities grouped together as "network activities" or "cpu/disk activities (builds)" basically | 10:25 |
tristan | It could be enhanced I guess, but I would first hesitate and wonder if we're working around other problems by providing configuration API | 10:25 |
valentind | 10 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 |
valentind | I think it would be nice to group the ostree pulls together to one call to ostree at a time. | 10:27 |
valentind | Because now, ostree cannot reuse connections. | 10:27 |
tristan | Is the problem actually that ostree does too many simultaneous requests ? | 10:29 |
tristan | valentind, 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 |
valentind | I think it is part of the problem. | 10:29 |
tristan | that is a valid question I think | 10:29 |
valentind | It is from the same server. | 10:30 |
valentind | This is the difference. | 10:30 |
tristan | We also have `ostree` sources, which behave much the same way as pull | 10:30 |
tristan | So then we will have the same problem with source mirroring | 10:30 |
tristan | Is that actually true ? | 10:30 |
valentind | And ostree has this 30 seconds timeout, which other things do not have. | 10:30 |
valentind | Yes, if you have 100 different elements useing ostree as source and it is the same server. | 10:31 |
tristan | So then we dont *really* solve the problem this way | 10:31 |
tristan | Also, we will be very soon replacing ostree with CAS for artifact storage, locally and remotely | 10:31 |
valentind | That is fine. I wanted to know if there was another way to limit pulling artifacts. | 10:32 |
valentind | Because freedesktop-sdk is really struggling now. | 10:32 |
tristan | But 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 dependency | 10:32 |
tristan | So, 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 |
valentind | What we should have is a way to provide our own HTTP client to ostree. | 10:34 |
tristan | and see if the proposed additional configuration is relevant in every setup/underlying protocol | 10:34 |
valentind | So we have control on that. | 10:34 |
tristan | I'm quite sure that ostree will be amenable to fixing issues we identify there, too | 10:35 |
tristan | they are not a distant community :) | 10:35 |
valentind | tristan, 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 |
tristan | That is a good point, I'll note also that networking is my area of least expertise :) | 10:36 |
tristan | I have some kind of allergy to the stuff, it never sticks | 10:36 |
tristan | Anyway 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 inefficient | 10:38 |
valentind | Specially because we use HTTPS | 10:39 |
valentind | And with HTTP2, always reusing connections is important. Because this is the only way to ensure correct priorities. | 10:39 |
tristan | Ah 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 |
tristan | valentind, do you think it's plausible to share connections for fetch() when downloading from a mirror ? | 10:41 |
tristan | I mean, of course considering that a url alias is abstract, and might use any uri scheme | 10:41 |
valentind | For fetch yes. | 10:41 |
valentind | In Python you have to use the same http client. | 10:41 |
tristan | Ah so you could only do it for downloading tarballs ? | 10:42 |
valentind | I am not sure of the details. But it should be possible. | 10:42 |
tristan | not for git, bzr, cvs, whatever ? | 10:42 |
valentind | Well there I do not know. | 10:42 |
valentind | Unless 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 setup | 10:43 | |
tristan | maybe something like that is what the network people call a "proxy" :D | 10:43 |
valentind | Well 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 dinner | 10:48 | |
tristan | aaaaand it still happens with the bwrap version check patch reverted: https://gitlab.com/BuildStream/buildstream/-/jobs/67708867 | 10:50 |
tristan | damn | 10:50 |
*** tristan has quit IRC | 10:53 | |
*** jennis has joined #buildstream | 11:14 | |
gitlab-br-bot | buildstream: issue #398 ("bst init does not respect --element-path option") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/398 | 11:17 |
*** aday has quit IRC | 11:22 | |
*** aday has joined #buildstream | 11:28 | |
Nexus | Is 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-bot | buildstream: 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/461 | 11:36 |
*** jennis has quit IRC | 11:37 | |
*** jennis has joined #buildstream | 12:00 | |
*** jennis_ has joined #buildstream | 12:00 | |
*** aday has quit IRC | 12:17 | |
*** aday has joined #buildstream | 12:22 | |
*** toscalix has joined #buildstream | 12:34 | |
*** bochecha_ has joined #buildstream | 12:42 | |
*** xjuan has joined #buildstream | 12:48 | |
*** aday has quit IRC | 12:51 | |
*** aday has joined #buildstream | 13:22 | |
finn | hey, 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 |
finn | https://gitlab.com/BuildStream/buildstream/issues/288 | 13:49 |
jmac | Yes, I think so | 13:49 |
finn | So since normal_name removes separators in favour of '-', does this mean you want self.name to have separators removed? | 13:52 |
jmac | You'll need to ask tristan that when he's next online | 13:54 |
tlater | I'm pretty sure your interpretation is correct, finn | 13:56 |
tlater | Oh, no | 13:56 |
tlater | We want path separators instead of '-' | 13:56 |
finn | so you'd want the element: hello/world to still be called hello/world? instead of hello-world | 13:57 |
tlater | Having 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 |
tlater | Yep, I think that's the intention | 13:57 |
finn | stops you from getting confused with an element: hello-world/foo | 13:57 |
finn | cool | 13:57 |
finn | thanks | 13:57 |
tlater | If not, should be quick to fix if tristan does complain ;) | 13:57 |
jmac | But the issue says "It is also used to create log file names, these are also better off without the normal_name substitutions." | 13:57 |
jmac | You can't call the log file hello/world | 13:58 |
tlater | jmac: Hm, not sure if a call to os.makedirs is required | 13:58 |
finn | You could call it hello\/world.txt ? | 13:58 |
finn | :P | 13:58 |
tlater | I think the atomic file creation function does that for you | 13:59 |
jmac | I don't think you can escape directory separators | 13:59 |
tlater | It'll be an experiment! ;p | 13:59 |
jmac | Well, I can't on my ext4 system | 13:59 |
jmac | What if your element is called "/"? | 14:00 |
tlater | jmac: Can you name your element that? | 14:00 |
tlater | I suppose you could if you'd first used a different file system | 14:00 |
jmac | I don't know. Last time I looked we didn't have any formal element names | 14:00 |
jmac | formal element name rules, I mean | 14:00 |
jmac | This came up when we had spaces in the project name | 14:01 |
tlater | We might need to define this, then | 14:01 |
tlater | In either case, I think the intention is to - -> / for now | 14:02 |
jmac | Ah, wait, I thought element names were specified in YAML, but they're just pathnames | 14:04 |
jmac | In which case having a logfile called hello/world for an element called hello/world is more acceptable | 14:05 |
tlater | Your point still stands, you could define a weird file system that breaks everything and then copy over your buildstream project | 14:05 |
paulsherwood | iirc there was a philosophical debate about names in the files vs names of the files | 14:05 |
jmac | tlater: But if you've got element names called "/" you can't import them into your (ext4-based) buildstream host at all | 14:08 |
tlater | Also a point | 14:08 |
jmac | There 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 separators | 14:09 |
*** bethwhite_ has joined #buildstream | 14:48 | |
*** bethw has quit IRC | 14:49 | |
*** jonathanmaw has quit IRC | 15:03 | |
*** slaf has joined #buildstream | 15:04 | |
*** slaf has joined #buildstream | 15:04 | |
*** slaf has joined #buildstream | 15:04 | |
*** slaf has joined #buildstream | 15:05 | |
*** slaf has joined #buildstream | 15:05 | |
*** jonathanmaw has joined #buildstream | 15:19 | |
*** slaf has quit IRC | 15:24 | |
*** slaf has joined #buildstream | 15:39 | |
*** slaf has joined #buildstream | 15:39 | |
*** slaf has joined #buildstream | 15:39 | |
*** slaf has joined #buildstream | 15:39 | |
gitlab-br-bot | buildstream: 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/454 | 15:43 |
gitlab-br-bot | buildstream: 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/454 | 15:47 |
*** toscalix has quit IRC | 15: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/EtVb2qak | 15:59 |
gitlab-br-bot | buildstream: 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/428 | 16:01 |
gitlab-br-bot | buildstream: 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/317 | 16:02 |
*** ernestask has quit IRC | 16:02 | |
gitlab-br-bot | buildstream: 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/428 | 16:04 |
gitlab-br-bot | buildstream: 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/454 | 16:10 |
gitlab-br-bot | buildstream: 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/454 | 16:12 |
*** bethwhite_ has quit IRC | 16: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/103 | 16:19 |
*** jonathanmaw has quit IRC | 16:30 | |
*** bethwhite_ has joined #buildstream | 16:36 | |
*** tiago has quit IRC | 16:38 | |
*** bethwhite_ has quit IRC | 16:39 | |
*** tiago has joined #buildstream | 16:41 | |
*** finn has quit IRC | 16:43 | |
*** tiago has quit IRC | 16:45 | |
*** tiago has joined #buildstream | 16:45 | |
*** tiago has quit IRC | 16:45 | |
gitlab-br-bot | buildstream: 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/462 | 17:23 |
*** dominic has quit IRC | 18:34 | |
*** awacheux has quit IRC | 18:55 | |
*** bochecha_ has quit IRC | 19:40 | |
*** bochecha_ has joined #buildstream | 19:41 | |
*** tristan has joined #buildstream | 20:27 | |
*** bochecha_ has quit IRC | 20:47 | |
*** xjuan has quit IRC | 21:14 | |
*** cs_shadow has quit IRC | 22:03 | |
*** tristan has quit IRC | 22:46 | |
*** aday has quit IRC | 23:04 | |
*** jennis_ has quit IRC | 23:10 | |
*** jennis has quit IRC | 23:10 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!