| *** leopi has joined #buildstream | 04:41 | |
| *** tristan has joined #buildstream | 05:21 | |
| *** leopi has quit IRC | 05:36 | |
| *** leopi has joined #buildstream | 06:11 | |
| *** iker has joined #buildstream | 07:25 | |
| *** finn_ has joined #buildstream | 07:55 | |
| *** finn has quit IRC | 07:57 | |
| *** finn_ has quit IRC | 07:57 | |
| *** finn has joined #buildstream | 07:57 | |
| *** finn has quit IRC | 08:02 | |
| *** finn has joined #buildstream | 08:03 | |
| tristan | https://gitlab.com/BuildStream/website/merge_requests/67 <-- This adds a "Documentation" menu item which links directly to http://buildstream.gitlab.io/buildstream/ | 08:04 |
|---|---|---|
| qinusty | Looks good to me | 08:06 |
| tristan | tlater[m], My tests are failing for the crash fixer; I think because the tests are invalid and need fixing - now I have a cleanup job running | 08:06 |
| *** rdale has joined #buildstream | 08:06 | |
| tristan | So I set my cache quota to 16GB with a 15GB cache, and tracked a new freedesktop-sdk junction to get a nice fat update | 08:07 |
| tristan | And it caused the cache to grow and hit the limit | 08:07 |
| tristan | Now I have a cleanup job which has been running for... get this... 20min so far and still running ! | 08:07 |
| tristan | 22 actually | 08:08 |
| tristan | My cache is now 13GB | 08:08 |
| qinusty | tristan, feel free to chip in to https://gitlab.com/BuildStream/website/issues/21 when you a chance. I'm trying to collate the argument on both sides. | 08:08 |
| paulsher1ood | i'll ask again... shouldn't cleanup run on startup, in the background? | 08:08 |
| paulsher1ood | ybd cleanup regularly takes up to five minutes on reasonable systems | 08:09 |
| *** phildawson has joined #buildstream | 08:09 | |
| tristan | paulsher1ood, you dont know if you are going to need to cleanup really until you do cleanup, and ideally you dont want to cleanup often, or more than you need to | 08:09 |
| tristan | Yes, well I'm complaining about performance with the CAS prune right now | 08:09 |
| paulsher1ood | my proposal considers that, afaict | 08:10 |
| paulsher1ood | s/proposal/suggestion/ | 08:10 |
| tristan | We want to do the least amount of cleanup possible, right ? In case you need the artifacts due to switching branches, you keep around as much as possible with LRU | 08:10 |
| tristan | Still we also want to balance that with doing not too many cleanups; so we try to make enough space when it happens | 08:11 |
| tristan | Now, if you do it at startup, it doesnt mean you wont anyway have to do it again after building or downloading 400 builds | 08:11 |
| tristan | I do agree that it makes sense to evaluate and possibly launch a cleanup at startup, too | 08:13 |
| paulsher1ood | hmm. i'm assuming (maybe wrong...) that the machine is sized to perform at least one full transaction (download, build, deploy) | 08:13 |
| tristan | It might be that we do, I didnt test that | 08:13 |
| tristan | I just reached the quota in mid-flight | 08:13 |
| paulsher1ood | had there been a cleanip a) after previous run, or b) on startup? | 08:13 |
| tristan | Well that is considered too; We know all of the artifacts which are needed in the build, and we *never* delete artifacts that are needed for the build in context | 08:14 |
| tristan | We instead bail out at that point | 08:14 |
| paulsher1ood | ybd does the same iirc | 08:14 |
| tristan | So BuildStream starts with say; you have 15GB of artifacts, and your limit is set to 20GB... We dont know how much space the new artifacts will take | 08:15 |
| tristan | So we dont cleanup until you approach that limit | 08:15 |
| tristan | If you start up with the limit reached, then we should indeed make room at startup | 08:15 |
| paulsher1ood | that's wrong imo | 08:16 |
| tristan | Assuming that creating the artifacts is more expensive than keeping them around, we would want to delete as less as possible | 08:16 |
| tristan | Of course, you never want to just wipe the whole cache | 08:16 |
| paulsher1ood | there should be a 'get me this much space if possible' target on startup | 08:17 |
| *** finn has quit IRC | 08:17 | |
| tristan | Regardless if we want to bring the cache down to a lower end value (this target exists at startup as well as later on), you still don't know that you won't need to clean up later again | 08:18 |
| tristan | So, while I agree it makes sense to do it once at startup, I disagree that it will never happen again during a build which uses an unpredictable amount of disk space | 08:18 |
| tristan | At which point, whether it happened at startup or later, is not too big of a deal, so long as it doesnt happen too often and doesnt take too much time when it does | 08:19 |
| tristan | right now, it's clearly taking way too much time, whether it is at startup or not | 08:20 |
| tristan | qinusty, I don't know why you want to further argue this in issue 21, honestly | 08:21 |
| tristan | qinusty, better to just let it rest right ? | 08:22 |
| paulsher1ood | ... in the background. ybd forks to do this. | 08:22 |
| tristan | Yeah, that is exactly a problem, CAS is unsafe for this | 08:23 |
| paulsher1ood | oh? | 08:23 |
| tristan | Parallelism of cache additions and pruning would be great | 08:23 |
| tristan | Was not possible with OSTree and has not been implemented with CAS | 08:23 |
| paulsher1ood | it doesn't support that? why not? | 08:23 |
| paulsher1ood | ybd/kbas *does* support it | 08:23 |
| qinusty | Primarily, I'm just trying to avoid further conflict on the topic. It was raised due to a discussion by toscalix on an MR of mine. | 08:23 |
| paulsher1ood | qinusty: discussion is not conflict | 08:24 |
| paulsher1ood | this stuff is nontrivial, it's unsuprtising that people may not immediately agree | 08:24 |
| *** finn has joined #buildstream | 08:25 | |
| tristan | paulsher1ood, problem is when you have file deduplication; and refs, then you (A) Want to delete all the deduplicated objects reachable by nothing other than this artifact which you know you can remove... But (B), you have new commits at the same time which start to refer to these objects you are removing | 08:25 |
| qinusty | Agreed. Bad wording by me, I wasn't too sure when creating the issue that we had resolved this discussion fully. | 08:25 |
| qinusty | Therefore the issue was raised for further discussion. | 08:25 |
| qinusty | For those which did not fully agree, to read the arguments for both sides. | 08:25 |
| paulsher1ood | the support in ybd/kbas is achieved by the single trick Kinnison explained to me (ie. atomicity via directories) | 08:25 |
| paulsher1ood | is it possible to adjust cas so that artifacts are directories not files? | 08:26 |
| tristan | paulsher1ood, not really, it's ultimately easy because artifacts are not deduplicated at all; you only have an extract directory to atomically move, and a tarball to atomically delete | 08:26 |
| paulsher1ood | tristan: i'm confused. "it's ultimately easy? in bst? what's the problem then? | 08:27 |
| tristan | Instead with CAS, you have hashed objects (the actual files, hashed by their content) and symbolic refs, and you reconstruct the directory on demand using the deduplicated hash objects | 08:27 |
| tristan | Sorry, it's ultimately easy with YBD/kbas | 08:27 |
| paulsher1ood | ok | 08:28 |
| tristan | because every artifact is separate and contains all the data, no deduplication | 08:28 |
| tristan | Here we have to prune a deduplicated store, removing only the files which are not used by any other artifact | 08:28 |
| tristan | in order to remove an artifact | 08:28 |
| tristan | I think discussion with juergbi and others around this resulted in talk of ref counting of the objects | 08:29 |
| *** toscalix has joined #buildstream | 08:29 | |
| paulsher1ood | ewww :) | 08:29 |
| tristan | which could allow for parallel commit / prune | 08:29 |
| tristan | well, considering the problem, it seems like the right approach - it's just not as dead simple as we would love it to be | 08:30 |
| paulsher1ood | so we have lru. if we had also a representation of all artifacts needed by any active jobs, we could prune at will, is that correct? | 08:31 |
| juergbi | the concurrent commit and prune shouldn't be that difficult to handle | 08:32 |
| juergbi | ensure mtime is updated for items relevant to the current commit and then make sure we never purge objects that are very recent | 08:32 |
| paulsher1ood | can we guarantee that any file is deleted, any job(s) finding they need it will reconstruct it? and that one pristine version of the file will land when the reconstruction(s) have succeeded? | 08:32 |
| Kinnison | I have spent quite a bit of time thinking about how to garbage collect a CAS while still allowing its use, but I've been thinking on the server side, not local caches. However as juergbi says, it's mostly about knowing your anchors, chasing them through, and then obeying time. | 08:33 |
| paulsher1ood | ok i'll drop out, since i'm sure that between Kinnison, juergbi and tristan there's enough expertise thinking about this | 08:33 |
| Kinnison | paulsher1ood: Yes, though it may require arbitrary amounts of work and relies on the concept/hope that an artifact build is reproducible | 08:33 |
| paulsher1ood | may the force be with you :-) | 08:33 |
| * Kinnison doesn't want to stop paulsher1ood contributing | 08:34 | |
| * Kinnison is, unfortunately, at the whiteboard and waffle stage of considering garbage collection in his CAS implementation, but hopefully I'll write down my thoughts into something more concrete in the near future | 08:35 | |
| paulsher1ood | understood, i'm not suggesting that i'll stop contributing :-) | 08:35 |
| *** leopi has quit IRC | 08:36 | |
| tristan | paulsher1ood, deleting a part of an artifact that might be needed later in the build is one thing; at the time of the next build we could reconstruct it, but deleting a part of an artifact which is already needed by a previous build would be more catastrophic | 08:37 |
| paulsher1ood | previous build should always be ready to reconstruct? | 08:38 |
| tristan | Well, we need to stage the previous artifacts which are depended on by later builds right ? | 08:39 |
| tristan | Otherwise we find ourself in a loop where we have to reconstruct things on demand | 08:39 |
| tristan | Also a possibility, but seems quite undesirable :) | 08:39 |
| tristan | Rebuild artifact we already built, because we cleaned something up in between, and then need the artifact again | 08:39 |
| paulsher1ood | i fear that's what ybd does, in effect :) | 08:40 |
| tristan | anyway, I agree juergbi and Kinnison have better ideas; just don't want you to think your ideas are unwelcome :) | 08:41 |
| Kinnison | tristan: as I said, it's "safe" albeit requiring potentially arbitrary amounts of work :-) | 08:41 |
| tristan | paulsher1ood, I suspect that with the way artifacts work in YBD, that doesnt happen; because you will probably lock all the cache keys you need and never delete those in your cleanup thread | 08:42 |
| tristan | paulsher1ood, but yeah the recursive nature of the code indicate that might be possible with YBD :) | 08:42 |
| paulsher1ood | it is possible, there's no locking of cache keys. iirc i prioritised that the build would always succeed if possible over doing the fewest possible constuction steps | 08:44 |
| * paulsher1ood may be wrong, it's a long time ago | 08:44 | |
| tristan | Hah ! | 08:45 |
| tristan | Ok this is damn weird, what failed in CI failed in my smoketesting; I expect it's a really stupid mistake too | 08:45 |
| * Kinnison realises his proposal relies on the monotonicity of time and worries that might fail in a distributed setting | 08:45 | |
| tristan | Ah, lower threshold is 50%, and no tolerance, that is why it fails | 08:45 |
| tristan | got it | 08:45 |
| qinusty | hmmmm, what happens if you raised an exception in an asyncio coroutine? | 08:47 |
| *** leopi has joined #buildstream | 08:52 | |
| tristan | tlater[m], progress on cache cleanup issue here: https://gitlab.com/BuildStream/buildstream/issues/623#note_99629594 :) | 08:52 |
| toscalix | good morning tiagogomes | 08:54 |
| tlater[m] | Hmm, interesting | 08:54 |
| *** tristan has quit IRC | 08:55 | |
| tlater[m] | tristan: I'm pretty sure your suspicion is right | 08:56 |
| tlater[m] | Gah, stupid mistake. We shouldn't check if we can go down to 50% but whether we can get enough space... | 08:56 |
| *** tristan has joined #buildstream | 08:57 | |
| tristan | oops | 08:58 |
| tristan | <tristan> Kinnison, I'm not sure that it can matter for distributed settings - so long as a CAS resides on a given machine | 08:58 |
| tristan | <tristan> Kinnison, it *might* make a difference, but I think some analysis is needed to ensure it actually does; cleanups and persistence should probably happen on the same machine, even if workers and such have their own local copies of what they requested | 08:58 |
| tristan | Anyway, retyped messages which didnt make it with the network hiccup | 08:58 |
| Kinnison | tristan: Re: distributed I was thinking of a situation where you have a CAS shared among many computers via something like NFS, but if that's not a use-case you want to support then it's less of a problem, for sure. | 08:59 |
| tristan | Ohhhh | 08:59 |
| tristan | Kinnison, what with the whole RPC protocol and everything for working with CAS in a network environment; it does seem to me that it would be quite a hack to work around it all with NFS mounts | 09:01 |
| tristan | Then again, people on clouds do crazy things and expect it to perform | 09:01 |
| Kinnison | Heh | 09:01 |
| Kinnison | I think if you say "A disk CAS is meant to be used only by a single computer (single time-domain)" then if someone hacks around it, they get to pick up all the pieces | 09:01 |
| *** kim has joined #buildstream | 09:01 | |
| tiagogomes | toscalix ? | 09:05 |
| toscalix | www does not seem to work on the domain | 09:06 |
| *** kim has quit IRC | 09:06 | |
| tiagogomes | it was never requested | 09:06 |
| toscalix | ah, ok, I added it to the ticket | 09:07 |
| toscalix | can we have it? | 09:07 |
| tiagogomes | yes | 09:11 |
| *** jonathanmaw has joined #buildstream | 09:12 | |
| toscalix | tiagogomes: thanks | 09:14 |
| qinusty | tristan, Re https://gitlab.com/BuildStream/buildstream/merge_requests/765... Can we discuss the current logic for marking jobs as skipped and why it isn't ideal? (as you mention in the issue) | 09:16 |
| tristan | qinusty, yup... I'll refresh my memory... | 09:24 |
| tristan | qinusty, What specifically ? I thought we went over all of this last week right ? | 09:24 |
| qinusty | Yeah, just formalising my thoughts in a response :D There are a few concerns I have regarding attempting to use the SkipJob exception within the main process. | 09:26 |
| tristan | qinusty, https://gitlab.com/BuildStream/buildstream/merge_requests/765#note_99641097 | 09:27 |
| tristan | I just added an example there | 09:28 |
| tristan | Which should help illustrate what I would expect | 09:28 |
| tristan | qinusty, That sounds like technical details; whenever we launch a plugin delegated operation, regardless of whether it is in the main process or in a task, it is in a try / except harness which should handle SkipJob right ? | 09:29 |
| *** lachlan has joined #buildstream | 09:29 | |
| tristan | qinusty, however; in an ideal world, we only run plugin delegated things via the scheduler (I know there are some edge cases where we currently do not, though) | 09:30 |
| tristan | qinusty, That said; SkipJob anyway does not become public API | 09:30 |
| tristan | qinusty, which means a plugin delegated operation cannot raise Skip, We raise Skip from the Queue implementations that run inside of a task, so ... it cannot even happen right ? | 09:31 |
| tristan | qinusty, for instance; I would not expect Skip to be raised from within ArtifactCache() code; I would expect it raised from the task operation in PullQueue / PushQueue, when it has determined that all cache servers traversed were futile | 09:32 |
| tristan | qinusty, The Push/Pull Queues need to determine that with well defined APIs of the ArtifactCache | 09:32 |
| tristan | qinusty, Does that make sense ? | 09:32 |
| qinusty | partial thoughts documented. My main concerns are that we cannot raise SkipJob to be caught by the scheduler simply because we are working from within a child process, and on return we are within an async callback (which afaict, doesn't have a nice way to propagate the exception to scheduler) | 09:34 |
| tristan | Eh ? | 09:34 |
| qinusty | Yeah it does. Currently the only use for SKIPPED is within the artifact cache, in my local implementation I have moved the exception raising to within element. However could move this to Queue potentially due to the logic in place for returning False on queue.process() for skipped | 09:35 |
| tristan | Ok ok... so we are talking about removing the Queue subclass's ability to manually mark a job as skipped as a consequence of it having been skipped in processing | 09:35 |
| tristan | qinusty, I think Skip should only ever be raised in Queue implementations | 09:35 |
| qinusty | Yes. Currently the Queue.process() returns True for processed, False for skipped. From what I understood, you thought this was not ideal | 09:35 |
| tristan | Right, that should be removed in favor of something that the Queue implementations don't need to think about | 09:36 |
| tristan | Since instead of using that API contract, they will now raise Skip in their Queue.process() implementation | 09:36 |
| tristan | qinusty, And you are incorrect about Queue.process() | 09:36 |
| tristan | qinusty, See the docs comment in queue.py | 09:37 |
| tristan | qinusty, That is something that PushQueue/PullQueue do entirely of their own volition | 09:37 |
| qinusty | Ah okay, So currently Queue.done() is the issue? | 09:37 |
| tristan | qinusty, It is the Queue.done() API contract which needs to change; and the PushQueue/PullQueue implementations of Queue which need to be changed | 09:37 |
| tristan | Correct | 09:38 |
| qinusty | Done needs to stay. But the return value for skipped does not. | 09:38 |
| tristan | qinusty, PushQueue/PullQueue use process() to report whatever they want through the return, they happen to report skipped through that | 09:38 |
| tristan | But they dont need to do that anymore | 09:38 |
| tristan | And Queue.done() needs to lose it's ability of marking something as skipped, as that is no longer the contract | 09:39 |
| tristan | qinusty, It might even make sense to make Skip() an internal exception to the _scheduler/ module (or "package" in pythonic terms) | 09:39 |
| tristan | That would remove the ability to have it handled in timed activities; but that still makes sense right ? | 09:40 |
| qinusty | Sounds reasonable. I was approaching this from the other side. This makes much more sense. | 09:40 |
| tristan | Only a task can be SKIPPED | 09:40 |
| tristan | And that fits with how we record skipped tasks in the summary and status area | 09:40 |
| qinusty | So within a Push task, you have a Push timed activity. (that's just how it is) | 09:40 |
| qinusty | the activity would SUCCESS | 09:40 |
| qinusty | and the task would SKIPPED? | 09:40 |
| tristan | qinusty, That is not just how it is; afaics you added that | 09:41 |
| qinusty | I added that to pull | 09:41 |
| qinusty | one of them was timed_activity, the other was not | 09:41 |
| qinusty | I added for consistency | 09:41 |
| tristan | I see | 09:41 |
| tristan | Right; and https://gitlab.com/BuildStream/buildstream/merge_requests/765#note_99641097 politely asks for this to be removed in both | 09:41 |
| tristan | since it's redundant information in the log | 09:41 |
| tristan | qinusty, I think the ability to have any random `timed_activity()` show SKIPPED is orthogonal to the rest, but it seems to me desirable to avoid it | 09:43 |
| tristan | (I do think it should be a separate conversation, though) | 09:43 |
| qinusty | Okay, looking at that log. We have... Start of task, status, info, skipped task | 09:44 |
| qinusty | where's the timed_Activity there? | 09:44 |
| tristan | There is none | 09:44 |
| qinusty | It's been in the code for 2 months | 09:44 |
| tristan | qinusty, remember that that is not where we are going to be issuing the SKIPPED message | 09:44 |
| qinusty | I know. I'm trying to understand what is in the code, and what is in the log | 09:44 |
| tristan | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_scheduler/jobs/job.py#L393 fires the SKIPPED message for the task (or that's the block) | 09:45 |
| tristan | qinusty, ok in that case I don't quite understand the question | 09:46 |
| qinusty | Either way, I'm just confusing things here. I'll work to what we've discussed and try and explain this point once I've thought about it more. | 09:47 |
| tristan | The rationale of those 4 messages is basically: Start / Skipped are the timed task... STATUS is because this is actually only relevant in verbose mode (which is currently ON by default)... INFO is what the task wants to report as interesting information/result | 09:48 |
| tristan | STATUS is like "Now I'm doing this...", INFO is like "This happened which I think you really care about knowing" | 09:49 |
| qinusty | Makes sense, but https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/element.py#L1789 is my point | 09:49 |
| qinusty | Where is that. | 09:49 |
| tristan | qinusty, That is not. | 09:50 |
| tristan | basically, that goes away entirely | 09:50 |
| tristan | it's absolutely useless | 09:50 |
| qinusty | But it doesn't even print into the log. | 09:50 |
| qinusty | That is master. not my branch | 09:50 |
| tristan | I know, it needs to go away is what I'm repeating | 09:50 |
| qinusty | Okay, are the messages suppressed within the log? | 09:51 |
| tristan | I don't understand | 09:51 |
| qinusty | They don't print | 09:51 |
| tristan | Ahhh | 09:51 |
| tristan | qinusty, That can be a side effect of silent_nested | 09:51 |
| tristan | Depending on where it's being called from | 09:51 |
| *** iker has quit IRC | 09:51 | |
| tristan | qinusty, I'm failing to understand the context of your question: You are looking at code that exists and is not doing what you expect it to be doing | 09:52 |
| qinusty | Yes. | 09:52 |
| tristan | qinusty, that's why I'm having a different conversation :) | 09:52 |
| tristan | qinusty, That will be silent nested at work | 09:52 |
| qinusty | I'm trying to further understand the components of the larger problem :D | 09:52 |
| qinusty | Which comes down to silent nested, as you mention | 09:52 |
| qinusty | Okay, I'll strip that out as part of my rework | 09:53 |
| *** alatiera_ has joined #buildstream | 09:53 | |
| tristan | The "silent_nested" originally is there because: A code segment might want to time it's activity... But it might run in the context of something which is already timing it | 09:53 |
| tristan | In a lot of these cases, the messaging becomes explosive, or at least it originally did | 09:53 |
| qinusty | On a side note, completely separate argument. Is there a reason we have a task START messages show the path to the log file instead of a descriptive message? | 09:54 |
| tristan | qinusty, we had this conversation last week *also* | 09:54 |
| qinusty | We did, I did not understand/agree. I feel like it is just confusing to a log reader | 09:55 |
| qinusty | they're obviously /necessary/, but replacing the START message? | 09:55 |
| tristan | qinusty, OK - So you have a task; a task is described already by the [ activity:element.bst ] portion of the log line | 09:55 |
| tristan | There are not all that many kinds of task | 09:55 |
| tristan | Push/Pull/Build/Fetch/Track | 09:56 |
| qinusty | yup | 09:56 |
| tristan | Those are relevant in every line | 09:56 |
| tristan | Now it's also important to put the log line *somewhere* | 09:56 |
| tristan | And it's important to not use too much space, we dont want a newline for every START with a log file underneath, just because we wanted to print some redundant text | 09:57 |
| tristan | What would the task print there asides from "Starting Build" ? | 09:57 |
| tristan | Or "Building" | 09:57 |
| tristan | Or "Tracking", or "Pushing" ? | 09:57 |
| *** iker has joined #buildstream | 09:57 | |
| qinusty | Makes sense, perhaps I'm just reading the logs wrong. I primarily read the right hand side. From what you're saying, to find the the information I'm looking for I should be looking left | 09:58 |
| tristan | qinusty, in the case of the timed activity in question, for push pull; this redundant message was saying "START Pushing deadbeef" | 09:58 |
| tristan | But we already have "Push" and we already have "deadbeef" and we already have "START" | 09:58 |
| tristan | in that line | 09:58 |
| tristan | We *still* need a place to put the log; so since there is nothing really to add to that task line; we put it in the "custom message text" area on the right | 09:59 |
| tristan | (and nicely make it logdir relative, avoiding too much column width) | 10:00 |
| iker | HI. Happened to me that I installed BuildStream yesterday and It was working perfectly, this morning I installed bst-external and since then the bst command is not recognized by bash. Does this happened to someone else? | 10:00 |
| tristan | Oh that's new to me :-S | 10:00 |
| tristan | jonathanmaw, any idea about that ? ^^^^^ | 10:00 |
| qinusty | Where is your buildstream installed? Is that part of your PATH? | 10:00 |
| tristan | qinusty, seems it was already working, though | 10:00 |
| qinusty | in a shell, maybe a new shell? | 10:01 |
| jonathanmaw | iker: I haven't seen that before, either | 10:01 |
| tristan | But yeah that is a good guess :) | 10:01 |
| tristan | qinusty, :) | 10:01 |
| iker | I adjusted the PATH yesterday as described in the BuildStream wiki. Should that be done everyday? | 10:01 |
| tristan | iker, I think the BuildStream docs say to put it in .bashrc or .bash_profile no ? | 10:01 |
| qinusty | PATH should be adjusted in a permanent manner. e.g. ^ | 10:01 |
| tristan | http://buildstream.gitlab.io/buildstream/install_source.html#adjust-path | 10:02 |
| tristan | iker, anyway just add it to the end of your .bashrc and you should be set :) | 10:02 |
| iker | oh yes. I did it in the terminal just to try BuildStream and then I forgot to do it in .bashrc... | 10:03 |
| tristan | iker, interestingly; I have this in my .bashrc for more reasons than just BuildStream (for anything I have installed there) | 10:03 |
| iker | thanks | 10:03 |
| tristan | welcome :) | 10:03 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:03 |
| qinusty | I assume this issue doesn't pop up with pip install tristan? | 10:04 |
| tristan | qinusty, It depends if you install --user or not | 10:07 |
| tristan | qinusty, I think many people install with `--user`, and are distrustful of pip going and writing to your system paths | 10:08 |
| tristan | It'll never happen with distro packages, and you get man pages and bash completions for free | 10:08 |
| tristan | Or, you *should*, bash completions *might* have issues, but it should work out of the box | 10:08 |
| qinusty | Not with fish :( | 10:09 |
| * qinusty wishes he was familiar enough with fish to write the completions for buildstream | 10:09 | |
| tristan | right, but those would be fish completions ! | 10:09 |
| tristan | hehe | 10:09 |
| tristan | qinusty, We should be able to reuse all the same code; someone who knows it well should be able to translate | 10:09 |
| qinusty | indeed | 10:09 |
| tristan | Maybe even a quick google will tell you how to integrate *any* bash completions into fish | 10:10 |
| tristan | maybe a script exists for it somewhere | 10:10 |
| *** lachlan has quit IRC | 10:10 | |
| tristan | ah... /me has to run :-S | 10:11 |
| *** lachlan has joined #buildstream | 10:12 | |
| tristan | I will fix the remaining issues with https://gitlab.com/BuildStream/buildstream/issues/623#note_99629594 this weekend, now that I'm reproducing | 10:12 |
| tristan | Will have to fix the server side of this too :-S | 10:13 |
| tristan | tlater[m], juergbi; regarding performance of the pruning... I think that what we are doing is removing/pruning one artifact at a time | 10:13 |
| tristan | juergbi, do you think it could be easily possible to have a loop which removes a bunch of refs, predicting how much space it can free; before entering prune ? | 10:14 |
| tlater[m] | The prediction part is what I struggled with :| | 10:14 |
| tristan | juergbi, or rather, while removing refs; collecting some state which we can later feed to prune() so that half of it's intense job is already done, and only the objects need removing ? | 10:14 |
| tristan | tlater[m], Maybe as a stop gap; we can do something ugly like 5 artifacts at a time | 10:15 |
| juergbi | the prediction is indeed the tricky part | 10:15 |
| juergbi | however, with suitable metadata about artifact size, we might be able to estimate it | 10:15 |
| juergbi | we can't estimate the deduplication but it should still allow big reduction in work | 10:16 |
| *** lachlan has quit IRC | 10:16 | |
| tlater[m] | Well, we'll be overestimating the amount we remove | 10:16 |
| juergbi | yes | 10:16 |
| tlater[m] | I suppose that would at least give us better batching | 10:16 |
| tlater[m] | Yeah, that could work | 10:17 |
| tristan | juergbi, maybe we could give CAS->prune() (or whatever it is)... A long list of artifacts, and a desired limit of space to make ? | 10:17 |
| tristan | Like, remove as many of these artifacts (in an ordered list), until you make enough space ? I dont know, maybe it amounts to the same | 10:17 |
| tristan | meh | 10:17 |
| *** alatiera_ has quit IRC | 10:17 | |
| tlater[m] | Hm, I wonder how expensive reading artifact metadata is | 10:18 |
| *** alatiera_ has joined #buildstream | 10:18 | |
| tlater[m] | Since you need to extract first | 10:18 |
| tlater[m] | Perhaps we could have some form of manifest that also lists the approximate size? | 10:18 |
| tristan | tlater[m], indeed it's not ideal to remove 5 at a time, but seeing as it took me 30 blocking minutes to clear up ~8G, I think 5 artifacts might be conservative | 10:18 |
| juergbi | tlater[m]: strictly speaking we don't need extract directories for it | 10:18 |
| juergbi | (in the future i hope we can get completely rid of extract directories) | 10:19 |
| tristan | tlater[m], and in any case; the size of an artifact has little bearing on how much can be removed from the store | 10:19 |
| tlater[m] | tristan: juergbi suggests overestimating the size of artifacts we remove, and using that to go all the way down. We can then recalculate the size and check if we've reached our target | 10:19 |
| tristan | juergbi, I agree; however it's difficult to do while preserving the touchy logic of staging; especially with regards to how we fail (or not) with symlinks | 10:19 |
| tristan | tlater[m], that doesnt sound bad either | 10:20 |
| juergbi | with the future i meant when we use buildbox | 10:20 |
| tristan | Anyway, I'll start with fixing the errors, optimize after | 10:20 |
| juergbi | (and have optimized CAS virtual directories) | 10:20 |
| *** alatiera_ has quit IRC | 10:22 | |
| *** tristan has quit IRC | 10:23 | |
| Kinnison | mablanch: I've kicked off a test run | 10:32 |
| mablanch | Running the test suite over the 'jmac/remote_execution_client' branch works on my local machine but fails when executed by the CI (most of the time at a random point with a core dump...). Anyone has already seen that / has an idea why this would happend? | 10:33 |
| mablanch | Kinnison, thanks! | 10:33 |
| *** lachlan has joined #buildstream | 10:35 | |
| *** alatiera_ has joined #buildstream | 10:35 | |
| Kinnison | mablanch: Hmm, I think I have a test suite hang | 10:36 |
| Kinnison | mablanch: there's one process and it's blocked in a futex | 10:37 |
| mablanch | Kinnison, which test is hanging? | 10:37 |
| Kinnison | tests/artifactcache/push.py::test_push | 10:37 |
| * Kinnison tries to work out if you can get Python to dump a stack trace wherver it's at, perhaps on a signal | 10:39 | |
| mablanch | Kinnison, Does it hang if you run: python setup.py test --addopts="tests/artifactcache" | 10:39 |
| *** ikerperez has joined #buildstream | 10:41 | |
| *** lachlan has quit IRC | 10:42 | |
| *** iker has quit IRC | 10:42 | |
| *** sstriker has joined #buildstream | 10:43 | |
| sstriker | Random question: what determines the parallelism of the jobs in the build queue? | 10:43 |
| phildawson | Kinnison, perhaps faulthandler is what you are after? (https://docs.python.org/3/library/faulthandler.html) | 10:43 |
| Kinnison | phildawson: I found that if I install the python debug symbols, I can run 'py-bt' in gdb | 10:44 |
| Kinnison | :-D | 10:44 |
| phildawson | :) | 10:44 |
| Kinnison | seems to be dying in: | 10:44 |
| Kinnison | File "/home/danielsilverstone/buildstream/buildstream/_platform/linux.py", line 68, in _check_user_ns_available | 10:44 |
| Kinnison | (or rather, deeper in the execute child stuff under there) | 10:45 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:45 |
| Kinnison | <built-in method fork_exec of module object at remote 0x7f972d0b7868> | 10:45 |
| Kinnison | File "/usr/lib/python3.5/subprocess.py", line 1221, in _execute_child | 10:45 |
| Kinnison | specifically | 10:45 |
| Kinnison | mablanch: that made it some of the way through and then managed to abort \o/ | 10:47 |
| * Kinnison tries again with a debugger | 10:47 | |
| Kinnison | ooooh | 10:48 |
| Kinnison | found something | 10:48 |
| Kinnison | the abort happens deep in the grpc core | 10:48 |
| Kinnison | doing some mutex frobbing | 10:48 |
| Kinnison | mablanch: C backtrace https://pastebin.com/zScwbgnY | 10:49 |
| Kinnison | mablanch: Python backtrace looks similar (in the execute_child stuff under check_user_ns_available) | 10:49 |
| Kinnison | mablanch: could this be related to however you clean up the grpc stuff between tests? | 10:50 |
| Kinnison | sstriker: There's a number of "workers" permitted, (various kinds thereof, but I imagine build workers are what you're interested in) | 10:50 |
| sstriker | Ignore my earlier question; found my answer. Resources in scheduler. | 10:50 |
| * Kinnison stops | 10:50 | |
| Kinnison | :-) | 10:50 |
| gitlab-br-bot | buildstream: issue #633 ("Remote Execution should maximize parallel builders") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/633 | 11:00 |
| Kinnison | mablanch: sadly that forced gc.collect() didn't stop the aborts | 11:01 |
| sstriker | @Kinnison: that issue probably was no surprise after that question :) | 11:01 |
| *** lachlan has joined #buildstream | 11:01 | |
| * Kinnison worries about what sstriker might have sent his way | 11:01 | |
| * sstriker mumbles... how do I @ mention in irc again? | 11:02 | |
| Kinnison | sstriker: You have problems in IRC, I have problems in slack :-D | 11:06 |
| Kinnison | mablanch: We may have a serious blocker problem here | 11:06 |
| Kinnison | mablanch: consider https://github.com/grpc/grpc/issues/13873#issuecomment-390326741 | 11:06 |
| Kinnison | Specifically: right now, gRPC only allows fork() iff the parent process has not yet initiated a gRPC connection (full documentation on the present state of things at https://github.com/grpc/grpc/blob/master/doc/fork_support.md). | 11:06 |
| mablanch | Kinnison: Ouch... | 11:07 |
| Kinnison | The content of https://github.com/grpc/grpc/blob/master/doc/fork_support.md does *not* fill me with joy | 11:08 |
| sstriker | Kinnison: sadness. Begs the question whether python is fit for purpose here (I'm assuming you are referring to #buildgrid context here, not buildstream side of things?) | 11:10 |
| Kinnison | mablanch: I'm going to grab some lunch, then we should discuss the impact of this on the possibility of CAS related stuff | 11:10 |
| Kinnison | sstriker: No, mablanch and I are trying to work through !626 | 11:10 |
| Kinnison | sstriker: BuildStream uses gRPC to talk between CASs | 11:11 |
| sstriker | Got it. | 11:11 |
| Kinnison | mablanch: I intend to have some lunch, then we should discuss the impact of this if you've not found a workaround by then. | 11:12 |
| mablanch | Kinnison, Ok | 11:12 |
| sstriker | I'll leave it to you. I'm sure there will be a solution :) | 11:12 |
| *** lachlan has quit IRC | 11:16 | |
| *** sstriker has quit IRC | 11:18 | |
| *** abderrahim has quit IRC | 11:18 | |
| *** abderrahim has joined #buildstream | 11:19 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-287->master: Add validation of configuration variables) #678 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/678 | 11:21 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 11:21 |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-573->master: Reduce IO overhead caused by artifact cache size calculation) #671 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/671 | 11:24 |
| *** lachlan has joined #buildstream | 11:30 | |
| alatiera_ | is there a bst plugin for vim by any chance? | 11:30 |
| tiagogomes | No | 11:40 |
| tlater[m] | alatiera_: We'd definitely appreciate someone writing one | 11:47 |
| tlater[m] | Syntax highlighting/completion on .bst files would be awesome. | 11:48 |
| tlater[m] | (By syntax highlighting I mean coloring variables correctly, which yaml highlighting doesn't) | 11:49 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 11:56 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 12:01 |
| mablanch | Kinnison: I'm updating the tests in order to have all the gRPC calls being made in subprocesses. Will update the branch and ping you for a new test when ready. | 12:05 |
| Kinnison | mablanch: excellent | 12:05 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 12:07 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 12:11 |
| *** lachlan has quit IRC | 12:12 | |
| alatiera_ | tlater[m], heh, yea. I spent half an hour chasing a trailing whitespace in some meson-local: | 12:17 |
| alatiera_ | apparently my vim finds something else to highlight given the .bst | 12:17 |
| alatiera_ | setting the syntax to yaml manually works though | 12:17 |
| tlater[m] | Huh, that's interesting. Any clue what that something is? | 12:25 |
| *** dtf has joined #buildstream | 12:26 | |
| qinusty | reviewed toscalix :D | 12:37 |
| *** finn has quit IRC | 12:47 | |
| *** pro[m] has quit IRC | 12:47 | |
| *** tlater[m] has quit IRC | 12:47 | |
| *** awacheux[m] has quit IRC | 12:47 | |
| *** abderrahim[m] has quit IRC | 12:47 | |
| *** ssssam[m] has quit IRC | 12:47 | |
| *** mattiasb has quit IRC | 12:47 | |
| *** segfault3[m] has quit IRC | 12:47 | |
| *** asingh_[m] has quit IRC | 12:47 | |
| *** kailueke[m] has quit IRC | 12:47 | |
| *** theawless[m] has quit IRC | 12:47 | |
| *** albfan[m] has quit IRC | 12:47 | |
| *** inigomartinez has quit IRC | 12:47 | |
| *** oknf[m] has quit IRC | 12:47 | |
| *** m_22[m] has quit IRC | 12:47 | |
| *** WSalmon has quit IRC | 12:47 | |
| *** lchlan has quit IRC | 12:47 | |
| *** Kinnison has quit IRC | 12:47 | |
| *** paulsher1ood has quit IRC | 12:47 | |
| *** laurence has quit IRC | 12:47 | |
| *** ironfoot has quit IRC | 12:47 | |
| *** flatmush has quit IRC | 12:47 | |
| *** tintou has quit IRC | 12:47 | |
| *** csoriano has quit IRC | 12:47 | |
| *** jjardon has quit IRC | 12:47 | |
| *** Nexus has quit IRC | 12:47 | |
| *** mablanch has quit IRC | 12:47 | |
| *** abderrahim has quit IRC | 12:47 | |
| *** ikerperez has quit IRC | 12:47 | |
| *** alatiera_ has quit IRC | 12:47 | |
| *** jonathanmaw has quit IRC | 12:47 | |
| *** leopi has quit IRC | 12:47 | |
| *** toscalix has quit IRC | 12:47 | |
| *** phildawson has quit IRC | 12:47 | |
| *** rdale has quit IRC | 12:47 | |
| *** tiagogomes has quit IRC | 12:47 | |
| *** SotK has quit IRC | 12:47 | |
| *** gitlab-br-bot has quit IRC | 12:47 | |
| *** adds68 has quit IRC | 12:47 | |
| *** tiagogomes_ has quit IRC | 12:47 | |
| *** coldtom has quit IRC | 12:47 | |
| *** jennis has quit IRC | 12:47 | |
| *** qinusty has quit IRC | 12:47 | |
| *** lantw44 has quit IRC | 12:47 | |
| *** Trevinho has quit IRC | 12:47 | |
| *** abderrahim has joined #buildstream | 12:48 | |
| *** ikerperez has joined #buildstream | 12:48 | |
| *** alatiera_ has joined #buildstream | 12:48 | |
| *** jonathanmaw has joined #buildstream | 12:48 | |
| *** leopi has joined #buildstream | 12:48 | |
| *** toscalix has joined #buildstream | 12:48 | |
| *** finn has joined #buildstream | 12:48 | |
| *** phildawson has joined #buildstream | 12:48 | |
| *** rdale has joined #buildstream | 12:48 | |
| *** tiagogomes has joined #buildstream | 12:48 | |
| *** oknf[m] has joined #buildstream | 12:48 | |
| *** albfan[m] has joined #buildstream | 12:48 | |
| *** pro[m] has joined #buildstream | 12:48 | |
| *** segfault3[m] has joined #buildstream | 12:48 | |
| *** kailueke[m] has joined #buildstream | 12:48 | |
| *** mattiasb has joined #buildstream | 12:48 | |
| *** inigomartinez has joined #buildstream | 12:48 | |
| *** asingh_[m] has joined #buildstream | 12:48 | |
| *** abderrahim[m] has joined #buildstream | 12:48 | |
| *** ssssam[m] has joined #buildstream | 12:48 | |
| *** tlater[m] has joined #buildstream | 12:48 | |
| *** theawless[m] has joined #buildstream | 12:48 | |
| *** awacheux[m] has joined #buildstream | 12:48 | |
| *** SotK has joined #buildstream | 12:48 | |
| *** m_22[m] has joined #buildstream | 12:48 | |
| *** WSalmon has joined #buildstream | 12:48 | |
| *** gitlab-br-bot has joined #buildstream | 12:48 | |
| *** adds68 has joined #buildstream | 12:48 | |
| *** tiagogomes_ has joined #buildstream | 12:48 | |
| *** coldtom has joined #buildstream | 12:48 | |
| *** jennis has joined #buildstream | 12:48 | |
| *** qinusty has joined #buildstream | 12:48 | |
| *** lchlan has joined #buildstream | 12:48 | |
| *** Kinnison has joined #buildstream | 12:48 | |
| *** paulsher1ood has joined #buildstream | 12:48 | |
| *** laurence has joined #buildstream | 12:48 | |
| *** lantw44 has joined #buildstream | 12:48 | |
| *** ironfoot has joined #buildstream | 12:48 | |
| *** flatmush has joined #buildstream | 12:48 | |
| *** Trevinho has joined #buildstream | 12:48 | |
| *** tintou has joined #buildstream | 12:48 | |
| *** csoriano has joined #buildstream | 12:48 | |
| *** jjardon has joined #buildstream | 12:48 | |
| *** Nexus has joined #buildstream | 12:48 | |
| *** mablanch has joined #buildstream | 12:48 | |
| *** irc.acc.umu.se sets mode: +oo ironfoot jjardon | 12:48 | |
| Kinnison | mablanch: | 12:50 |
| mablanch | Kinnison, CI seems to prefer it now. | 12:50 |
| Kinnison | ======================================================================= 35 passed in 26.05 seconds ======================================================================= | 12:50 |
| Kinnison | [Inferior 1 (process 524) exited normally] | 12:50 |
| Kinnison | even under gdb with mutex debug turned to max | 12:50 |
| mablanch | Kinnison, Ok | 12:51 |
| * Kinnison is excited that this might mean we're closer to merge | 12:51 | |
| Kinnison | mablanch: Has anyone other than juergbi and myself looked over !626 yet? | 12:51 |
| mablanch | Kinnison: Thank for the help btw! | 12:51 |
| mablanch | Kinnison, sstriker did. | 12:52 |
| Kinnison | qinusty: If you're not too busy, more eyes on !626 in Buildstream would be cool | 12:52 |
| Kinnison | mablanch: aah yes, excellent | 12:52 |
| mablanch | Kinnison, qinusty: I'll push another update, the unit-test code may benefit from factorisation... | 12:53 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 12:57 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 13:02 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 13:05 |
| *** lachlan has joined #buildstream | 13:14 | |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 13:19 |
| gitlab-br-bot | buildstream: merge request (jmac/remote_execution_client->master: WIP: Remote execution client) #626 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/626 | 13:24 |
| mablanch | qinusty: Tests should be in a better shape now if you want to have a look. | 13:24 |
| qinusty | Still seeing issues mablanch? | 13:25 |
| mablanch | qinusty, Nope! | 13:26 |
| qinusty | Nice! Ping me an MR if you need a review | 13:26 |
| mablanch | qinusty, Oh yes, sorry, here it is: https://gitlab.com/BuildStream/buildstream/merge_requests/626/ | 13:27 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 13:32 |
| qinusty | I do like the addition of unit tests, glad you got the issues fixed mablanch :D I can't review this entire MR right now but the unit tests look like a good start to me. | 13:34 |
| qinusty | What ended up being the cause to the hang? | 13:35 |
| gitlab-br-bot | buildstream: issue #634 ("bug in build after failed build with workspace's") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/634 | 13:36 |
| mablanch | qinusty: Mostly this: https://github.com/grpc/grpc/blob/master/doc/fork_support.md | 13:39 |
| *** lachlan has quit IRC | 13:43 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-287->master: Add validation of configuration variables) #678 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/678 | 13:53 |
| Nexus | Does this make sense to anyone? | 14:13 |
| Nexus | BUG: Message handling out of sync, unable to retrieve failure message for element import element | 14:13 |
| qinusty | magic | 14:14 |
| qinusty | Are you tweaking things, or is this just happening? | 14:14 |
| Nexus | just happening | 14:19 |
| Nexus | on a mac tbf | 14:19 |
| *** lachlan has joined #buildstream | 14:40 | |
| *** ikerperez has quit IRC | 14:45 | |
| qinusty | There was something in the code which indicated this Nexus | 14:46 |
| * qinusty searches | 14:46 | |
| Kinnison | mablanch: so there's one unresolved discussion left on !626 -- how close to asking for merge are we? | 14:47 |
| qinusty | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_frontend/app.py#L536 Nexus, tlater[m] may know | 14:47 |
| Nexus | so it didn't fail, it didn't succeed, and it wasn't terminated... | 14:49 |
| Nexus | i'm glad that buildstream has about as much a clue about this as i do... | 14:49 |
| mablanch | Kinnison, Never been so close. juergbi will you have time to have a look at that comment today? | 14:49 |
| *** lachlan has quit IRC | 14:49 | |
| mablanch | I think qinusty is having a look at the unit-tests part of the MR also. | 14:49 |
| * qinusty took a few glances, but is currently working on an MR | 14:50 | |
| *** iker has joined #buildstream | 14:53 | |
| tlater[m] | Nexus: A lot may cause that | 14:54 |
| tlater[m] | Essentially, your job finished, the process said it failed, but it didn't talk to the main process at all. | 14:55 |
| tlater[m] | It indicates some sort of a crash in a child process. | 14:55 |
| Nexus | tlater[m]: well i'm having a fun little bug atm, where i can do `bst workspace list` anywhere (not in a bst project) and it will return `workspaces: []` | 14:55 |
| tlater[m] | That is entirely unrelated, the above can only happen during a build | 14:56 |
| tlater[m] | Nexus: Feel free to raise an issue about the workspace thing, I figure the expectation is to see "not in a buildstream project". | 14:57 |
| Nexus | it asks you to make a project | 14:57 |
| Nexus | this only happens on MacOS | 14:57 |
| Nexus | adaik | 14:57 |
| Nexus | afaik* | 14:58 |
| tlater[m] | And you made the project? | 14:58 |
| tlater[m] | Anyway, that issue seems like it's fairly easy to fix. Do you have anything else on the crash when you're building? | 14:58 |
| Nexus | https://pastebin.com/Xq5XeLhg | 14:59 |
| Nexus | hastebin never seems to work for me anymore :( | 15:00 |
| tiagogomes | `bst workspace list` doesn't return an empty list to me from anywhere | 15:00 |
| Nexus | tiagogomes: did you try running it on a mac? :) | 15:00 |
| Nexus | tiagogomes: also it returns an empty list if you have no workspaces | 15:00 |
| Nexus | i raised that in a UX post to the mailing list a while ago i think | 15:01 |
| tiagogomes | I did not run in on a mac | 15:01 |
| tpollard | you did Nexus | 15:01 |
| Nexus | good, or i'd be confused :) i don't recommend running bst on a mac just yet | 15:01 |
| Nexus | coolio | 15:01 |
| tlater[m] | Nexus: Yeah, this will be a pain to debug... I wonder what causes that stacktrace on os.mkdirs | 15:02 |
| tlater[m] | That's probably the first thing to investigate | 15:02 |
| tlater[m] | The bug message by itself is not very useful in determining what breaks, unless you're mucking with the scheduler itself. | 15:03 |
| Nexus | nope | 15:03 |
| gitlab-br-bot | buildstream: issue #636 ("Pytest 3.8.0 warnings from datafiles") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/636 | 15:05 |
| tpollard | I thought we'd pinned pytest? or was that just in ci | 15:08 |
| qinusty | Its pinned to be > | 15:22 |
| *** lachlan has joined #buildstream | 15:23 | |
| qinusty | The CI is just docker images, so it's whatever was installed when we last built the docker image for CI tpollard | 15:23 |
| *** WSalmon has quit IRC | 15:27 | |
| *** lachlan has quit IRC | 15:28 | |
| tpollard | I've found the commit I was thinking off, but it's not a hard pin anyway | 15:28 |
| *** WSalmon has joined #buildstream | 15:29 | |
| toscalix | jonathanmaw: good paragraph, thanks | 15:29 |
| iker | When building a project in buildstream I get the next error: Build failure on element: gnu-toolchain/stage1-gcc.bst | 15:29 |
| toscalix | qinusty: thanks for your review. You have some more content | 15:29 |
| toscalix | to review | 15:30 |
| iker | In the logs can be read: https://paste.codethink.co.uk/?4932 | 15:30 |
| iker | this error doesn't happen to other host machines | 15:30 |
| iker | is it possible that I have skipped some steps? | 15:31 |
| Kinnison | iker: that pastebin doesn't work for us. Could you please use pastebin.com or similar? | 15:31 |
| qinusty | It's best not to use codethink pastes in here iker :D | 15:31 |
| iker | o sorry | 15:31 |
| iker | I didn't know that | 15:31 |
| qinusty | paste.gnome.org works | 15:31 |
| WSalmon | https://hastebin.com/ | 15:31 |
| qinusty | I like hastebin, gnome just feels more welcome here :D | 15:32 |
| qinusty | gnome paste never lets me paste as Text though D:< | 15:32 |
| iker | https://paste.gnome.org/pbvrdlwif | 15:32 |
| qinusty | seems like an issue while interacting with some git internals, perhaps skullman may be of assistance | 15:35 |
| skullman | I'm not hugely familiar with the submodule handling logic, that error suggests that it's expecting the commit to have submodules and is surprised when it doesn't. | 15:38 |
| skullman | from what I can see from the code, that shouldn't be a fatal error | 15:41 |
| skullman | what does the rest of the log say? | 15:41 |
| *** finn has quit IRC | 15:42 | |
| *** finn has joined #buildstream | 15:42 | |
| *** rauchen has joined #buildstream | 15:44 | |
| iker | skullman, https://paste.gnome.org/pqs4eqhbx | 15:47 |
| skullman | I can't see anything weird with that, has it been truncated? | 15:48 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: WIP: out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 15:49 |
| iker | It has stopped by itself. Know asks me decide what to do | 15:49 |
| iker | Build failure on element: gnu-toolchain/stage1-gcc.bst | 15:49 |
| skullman | ok, but your log snippets don't show the error | 15:50 |
| toscalix | qinusty: I received a notific. mail with a couple of comments from you related with my last MR. But I cannot see them in the gitlab interface even if I click the link that comes in the notification | 15:59 |
| qinusty | hm. Weird | 15:59 |
| iker | I am building it again, I will send you the logs when the error appears again | 16:00 |
| toscalix | qinusty: np, I will use the mail, but I really cannot find it | 16:01 |
| tiagogomes | https://www.buildstream.build/ works now | 16:02 |
| qinusty | sent it again toscalix :D | 16:03 |
| toscalix | grrrr, now I have a conflict | 16:04 |
| qinusty | I think it's important to avoid the idea of a 'new structure' as everything is backwards compatible. We simply add more customisation options to the configuration file. | 16:04 |
| toscalix | I agree with your comments | 16:05 |
| toscalix | it is simply that I cannot solve my conflict. Hold on a sec | 16:05 |
| toscalix | do you mind to approve this MR that includes many changes and I create a new one right away addressing your two comments? | 16:07 |
| qinusty | Where has the conflict come from? Master hasn't updated any files you've been working on for a while | 16:07 |
| toscalix | qinusty: I cannot tell. There should be none | 16:07 |
| qinusty | What does git status say? | 16:07 |
| toscalix | I made a mistake somewhere | 16:07 |
| toscalix | MR with many commits.... I am not that good | 16:08 |
| qinusty | approved | 16:09 |
| toscalix | thanks. I cannot solve the conflict. I will rebase and create a new MR | 16:11 |
| toscalix | it should be an easy one | 16:11 |
| toscalix | but do not know why I cannot | 16:12 |
| *** rauchen has quit IRC | 16:12 | |
| toscalix | ah, there is a test for checking links. Does it check undefined link and 404? | 16:18 |
| toscalix | undefined=no link at all | 16:18 |
| gitlab-br-bot | buildstream: merge request (Qinusty/skipped-rework->master: Add SkipError for indicating a skipped activity) #765 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/765 | 16:25 |
| qinusty | It just runs a standard crawler on the page to ensure all links lead to valid pages e.g. not 404, 500 | 16:29 |
| qinusty | What does an undefined page look like? | 16:29 |
| toscalix | qinusty: I mean that you define a [link] but then forget to add a URL | 16:33 |
| qinusty | Not much we can do about that. That's a disadvantage to linking at the bottom of the page :D | 16:34 |
| qinusty | We could write a script to do this | 16:34 |
| qinusty | the problem is toscalix, that you can't identify the difference between [text] which is missing a link, and an intended '[text]' | 16:37 |
| *** tpollard has quit IRC | 16:39 | |
| iker | skullman, https://paste.gnome.org/p12yiwazz | 16:43 |
| Kinnison | mablanch: Given juergbi hasn't complained, I think the remaining discussion on 626 is resolved. Since noone else has had anything worrisome to say, I suggest we go ahead and merge if the pipeline is clean | 16:43 |
| gitlab-br-bot | buildstream: merge request (jmac/remote_execution_client->master: Remote execution client) #626 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/626 | 16:43 |
| qinusty | iker, I refer you to flatmush who had this issue the other week. Maybe he can be of some assistance. It either comes from symlink issues or a recursive variable definition in your project. | 16:44 |
| mablanch | Kinnison: The pipeline is ok. It needs at least 1 approval and a maintainer to be merge. | 16:45 |
| qinusty | It only needs a merge mablanch, no approval is necessary currently in buildstream. Developers with granted access can merge. | 16:46 |
| iker | qinusty, I talked with him before but he didn't know about it | 16:46 |
| iker | thanks anyway. I will try to fix it in Monday | 16:46 |
| iker | have a good weekend | 16:47 |
| toscalix | qinusty: no problem | 16:47 |
| mablanch | qinusty, Oh ok, then is needs someone with that kind of access then :) | 16:47 |
| toscalix | qinusty: https://gitlab.com/BuildStream/website/merge_requests/71 | 16:47 |
| *** iker has quit IRC | 16:47 | |
| gitlab-br-bot | buildstream: merge request (jmac/remote_execution_client->master: Remote execution client) #626 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/626 | 16:48 |
| mablanch | Cheers qinusty and Kinnison! | 16:49 |
| Kinnison | congrats on that epic effort mablanch | 16:49 |
| qinusty | Get tristan or toscalix to bump your privileges for merging to BuildStream. Usually they're given after a patch or two. Things to note when merging. Always remove source branch, this is either a tickbox next to merge or on MR creation | 16:50 |
| mablanch | Kinnison: Ah ah, thank you, juergbi, qinusty and you have been of great help! | 16:50 |
| toscalix | juergbi: around? | 16:51 |
| tlater[m] | qinusty: ooi, do you not have permissions to give people permissions? | 16:52 |
| qinusty | Only maintainers I believe | 16:52 |
| qinusty | Since we changed to Developer with extra perms | 16:52 |
| qinusty | As opposed to maintainers who could grant maintainer | 16:52 |
| tlater[m] | Fair enough. I wonder if you should get those permissions given you keep pointing new developers. | 16:53 |
| *** lachlan has joined #buildstream | 16:54 | |
| toscalix | I have permissions but I just use them to configs related with the project management side of the project. | 16:54 |
| toscalix | I do not mess around with areas where I have little or no expertise | 16:55 |
| toscalix | to merge you need the be Maintainer | 16:55 |
| toscalix | we should have one person who is usually available on Friday afternoons since tristan is not | 16:56 |
| jjardon | toscalix: no, there is a list of people that can merge | 16:57 |
| jjardon | no need to be a maintainer | 16:57 |
| toscalix | jonathanmaw: is maintainer. Looking for that list | 17:00 |
| *** lachlan has quit IRC | 17:02 | |
| toscalix | jjardon: I cannot find that list. Do you know where is at? | 17:03 |
| *** alatiera_ has quit IRC | 17:06 | |
| *** alatiera_ has joined #buildstream | 17:06 | |
| toscalix | tlater[m]: is maintainer too | 17:07 |
| toscalix | I guess we have enough people to cover fri afternoon | 17:07 |
| tlater[m] | Yes, that's not really been a problem. | 17:08 |
| toscalix | fine then | 17:08 |
| gitlab-br-bot | buildstream: merge request (jonathan/pickle-yaml->master: WIP: Add a cache of parsed and provenanced yaml) #787 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/787 | 17:09 |
| *** alatiera_ has quit IRC | 17:10 | |
| *** alatiera_ has joined #buildstream | 17:10 | |
| *** toscalix has quit IRC | 17:13 | |
| *** alatiera_ has quit IRC | 17:15 | |
| *** alatiera_ has joined #buildstream | 17:15 | |
| jjardon | toscalix is in the merge_request configuration in the buildstream project | 17:17 |
| *** jonathanmaw has quit IRC | 17:27 | |
| *** lachlan has joined #buildstream | 17:49 | |
| *** lachlan has quit IRC | 17:53 | |
| *** lachlan has joined #buildstream | 18:16 | |
| *** lachlan has quit IRC | 18:21 | |
| *** phildawson has quit IRC | 18:27 | |
| *** lachlan has joined #buildstream | 18:43 | |
| *** lachlan has quit IRC | 18:57 | |
| *** leopi has quit IRC | 19:11 | |
| *** lachlan has joined #buildstream | 19:18 | |
| *** lachlan has quit IRC | 19:22 | |
| *** alatiera_ has quit IRC | 20:22 | |
| *** alatiera_ has joined #buildstream | 20:22 | |
| *** alatiera_ has quit IRC | 20:34 | |
| *** alatiera_ has joined #buildstream | 20:35 | |
| *** mohan43u has quit IRC | 20:39 | |
| *** mohan43u has joined #buildstream | 20:41 | |
| *** cs-shadow has quit IRC | 21:23 | |
| *** tristan has joined #buildstream | 21:34 | |
| *** alatiera_ has quit IRC | 22:35 | |
| *** mohan43u has quit IRC | 23:18 | |
| *** mohan43u has joined #buildstream | 23:19 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!