*** bochecha has quit IRC | 00:06 | |
*** alatiera_ has quit IRC | 00:07 | |
*** catonano has quit IRC | 00:35 | |
*** abderrahim has quit IRC | 00:40 | |
*** abderrahim has joined #buildstream | 00:46 | |
*** xjuan has quit IRC | 00:49 | |
*** abderrahim has quit IRC | 00:51 | |
*** abderrahim has joined #buildstream | 00:51 | |
*** abderrahim has quit IRC | 01:27 | |
*** abderrahim has joined #buildstream | 01:28 | |
*** abderrahim has quit IRC | 01:31 | |
*** abderrahim has joined #buildstream | 01:41 | |
gitlab-br-bot | buildstream: merge request (valentindavid/rmtree_oserror->master: Catch correct exception from shutil.rmtree) #849 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/849 | 04:17 |
---|---|---|
*** mohan43u has joined #buildstream | 04:29 | |
*** alatiera_ has joined #buildstream | 05:00 | |
gitlab-br-bot | buildstream: merge request (juerg/dummy-sandbox->master: _platform/linux.py: Accept all configs for dummy sandbox) #843 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/843 | 05:08 |
*** abderrahim has quit IRC | 05:23 | |
*** abderrahim has joined #buildstream | 05:23 | |
gitlab-br-bot | buildstream: merge request (juerg/dummy-sandbox->master: _platform/linux.py: Accept all configs for dummy sandbox) #843 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/843 | 05:36 |
*** abderrahim has quit IRC | 05:44 | |
*** abderrahim has joined #buildstream | 05:44 | |
*** catonano has joined #buildstream | 05:48 | |
*** abderrahim has quit IRC | 06:08 | |
*** abderrahim has joined #buildstream | 06:09 | |
*** abderrahim has quit IRC | 06:18 | |
*** abderrahim has joined #buildstream | 06:18 | |
*** Nexus has joined #buildstream | 06:56 | |
*** catonano has quit IRC | 07:18 | |
gitlab-br-bot | buildstream: merge request (tristan/fix-status-messages->master: fix status messages) #845 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/845 | 07:33 |
gitlab-br-bot | buildstream: merge request (tristan/fix-status-messages-1.2->bst-1.2: fix status messages (1.2)) #846 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/846 | 07:35 |
gitlab-br-bot | buildstream: merge request (juerg/cas-batch-1.2->bst-1.2: CAS: Implement BatchUpdateBlobs support) #844 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/844 | 07:35 |
*** tristan has joined #buildstream | 07:45 | |
*** toscalix has joined #buildstream | 07:47 | |
*** toscalix has quit IRC | 07:48 | |
*** toscalix has joined #buildstream | 07:49 | |
gitlab-br-bot | buildstream: merge request (juerg/cas-batch-1.2->bst-1.2: CAS: Implement BatchUpdateBlobs support) #844 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/844 | 08:05 |
gitlab-br-bot | buildstream: merge request (tristan/fix-status-messages->master: fix status messages) #845 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/845 | 08:07 |
*** jennis has joined #buildstream | 08:18 | |
*** jmac has joined #buildstream | 08:19 | |
*** paulsherwood has joined #buildstream | 08:20 | |
*** phildawson has joined #buildstream | 08:20 | |
adds68 | juergbi, hey would you have any idea what the error on issue https://gitlab.com/BuildStream/buildstream/issues/692, could be indicating? | 08:23 |
Kinnison | adds68: are you giving it the full chain? | 08:25 |
*** tristan has quit IRC | 08:25 | |
Kinnison | adds68: Your system might lack the intermediate certs for LE | 08:25 |
gitlab-br-bot | buildstream: merge request (docs_Search_not_working->master: Fixing: Search functionality in the Documentation has stopped working) #848 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/848 | 08:25 |
adds68 | Kinnison, yea, i'm passing fullchain.pem | 08:25 |
Kinnison | Oddness | 08:26 |
Kinnison | Does the system you're running on have a "normal" set of root certs? | 08:26 |
adds68 | Kinnison, viewing that file also shows it has the intermediate LE cert in there | 08:26 |
Kinnison | e.g. is /etc/ssl/certs full'o'stuff ? | 08:26 |
* adds68 checks again | 08:26 | |
adds68 | Kinnison, inside there is only a "ca-bundle" cert | 08:27 |
Kinnison | is that sizeable? | 08:27 |
Kinnison | If no, you're probably lacking the OS-provided root set | 08:27 |
Kinnison | SSL is hard :( | 08:27 |
adds68 | Kinnison, du returns 0, yet there is data in the file? | 08:29 |
Kinnison | it may be a symlink | 08:29 |
Kinnison | what OS is this? | 08:29 |
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 | 08:29 |
gitlab-br-bot | buildstream: issue #454 ("BuildStream client-side implementation of remote execution") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/454 | 08:30 |
adds68 | Kinnison, ahh, 1 sec, this is fedora | 08:30 |
Kinnison | is the ca-certificates RPM installed? | 08:30 |
adds68 | Kinnison, yea they are both symlinks --> /etc/pki/ca-trust/extracted/pem/* | 08:31 |
adds68 | Kinnison, i'll check now | 08:31 |
Kinnison | and that's well populated? | 08:31 |
*** tristan has joined #buildstream | 08:32 | |
adds68 | Kinnison, yea that is well populated | 08:32 |
gitlab-br-bot | buildstream: issue #476 ("Specify the behaviour when overwriting files, symlinks or directories") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/476 | 08:32 |
adds68 | Kinnison, seems ca-certificates is also installed | 08:32 |
*** ChanServ sets mode: +o tristan | 08:33 | |
Kinnison | adds68: one grpc related thing I've seen suggests it might be choking if the root cert is duplicated | 08:34 |
Kinnison | adds68: try with the plain cert, rather than the fullchain | 08:34 |
adds68 | Kinnison, oo ok, i'll try that now :) | 08:34 |
juergbi | adds68: depending on where your grpc comes from, it might use its own internal root certificates instead of the system one | 08:42 |
juergbi | however, I would expect let's encrypt certificates to work in either case | 08:42 |
juergbi | jmac: I commented on !837 | 08:44 |
jmac | I saw | 08:47 |
jmac | I'm quite certain 837 does fix the issues described in #684, either that or I don't get them in the first place | 08:48 |
jmac | But the points you make are valid | 08:48 |
*** raoul has joined #buildstream | 08:48 | |
juergbi | jmac: is your TMP on the same filesystem as ~/.cache/buildstream? | 08:49 |
jmac | Yes | 08:50 |
juergbi | ok, that explains | 08:50 |
juergbi | that's often not the case | 08:50 |
jmac | I was getting permission errors on centos.bst though, and not ones from the artifact cache. I'll have to re-run it | 08:51 |
juergbi | yes, there are three potential points for exceptions | 08:51 |
juergbi | the first one you only get if TMP is a different filesystem | 08:51 |
juergbi | the second one is from import_files and fixed by the added chmod in your MR | 08:51 |
juergbi | the third one is CAS | 08:51 |
jmac | Right | 08:51 |
juergbi | the first two are regressions from 1.2, the third one is not | 08:51 |
jmac | Moving the temporary import directory to ~/.cache/buildstream sounds easy | 08:52 |
juergbi | yes | 08:52 |
*** jonathanmaw has joined #buildstream | 09:00 | |
*** finn_ has joined #buildstream | 09:04 | |
gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: Out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 09:04 |
adds68 | Kinnison, juergbi sorry i had a meeting | 09:12 |
adds68 | Kinnison, plain cert did not work =/ | 09:12 |
adds68 | juergbi, it is installed via pip i think? | 09:13 |
juergbi | yes, the pip one might indeed not properly use the system root certificates | 09:13 |
juergbi | pip vs distro fight ;) | 09:13 |
Kinnison | :/ | 09:14 |
juergbi | however, I would still expect let's encrypt to work unless the pip package is configured for no trusted CAs | 09:14 |
juergbi | I don't think it's something we can really fix in BuildStream code. however, maybe we could adapt the install instructions to improve this, once we know how... | 09:15 |
adds68 | juergbi, hmm ok, i will try and install from the system, i thought LE was now trusted | 09:16 |
*** bochecha has joined #buildstream | 09:22 | |
* tlater[m] wonders if he should approve CI messages to the buildstream-notification-list | 09:23 | |
tlater[m] | Were those recently blocked for some reason? | 09:23 |
tiagogomes | erm, do you have to manually approve all of these messages? That won't work well | 09:24 |
tlater[m] | Agreed, but I'm not quite sure why they're popping up - I'd have figured these would be allowed one way or the other. | 09:24 |
tlater[m] | But then I'm not quite sure what we want on that list, so... | 09:25 |
*** lachlan has joined #buildstream | 09:27 | |
tiagogomes | I activated CI notifications for whom subscribes to those be notified of failures on the overnight scheduled pipelines | 09:27 |
tlater[m] | Ah, fair enough | 09:29 |
tlater[m] | I'll have a look and see if I can blanket allow these then | 09:29 |
tlater[m] | Because it's stupid that they're being caught | 09:29 |
* tlater[m] clicked the "train bayesian" button, seems like there's not much else that can be done | 09:34 | |
tlater[m] | I suppose it's to avoid someone abusing the gitlab email to spam us | 09:34 |
adds68 | juergbi, seems dnf can not find grpc/grpcio | 09:35 |
adds68 | juergbi, on the grpc docs it only shows installation via package managers like pip ? | 09:36 |
coldtom | adds68: it's not in the repos yet, bochecha is currently trying to get it in | 09:38 |
gitlab-br-bot | buildstream: merge request (tristan/fix-terminated-jobs->master: _scheduler: Fix bookkeeping of terminated jobs) #850 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/850 | 09:38 |
adds68 | /o\ | 09:38 |
bochecha | adds68: still in my copr for now | 09:39 |
gitlab-br-bot | buildstream: merge request (tristan/fix-terminated-jobs-1.2->bst-1.2: _scheduler: Fix bookkeeping of terminated jobs) #851 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/851 | 09:39 |
bochecha | adds68: https://gitlab.com/BuildStream/buildstream/issues/686 | 09:39 |
tristan | tlater[m], I've just fixed your issue #479, with !850 & !851 | 09:42 |
tristan | tlater[m], Care to give those a lookover ? | 09:42 |
tlater[m] | Sure! | 09:42 |
tristan | Seems there are more regressions around termination, though :-( | 09:42 |
tristan | One by one | 09:42 |
tristan | Especially, I'd like to fix that when you hit ^C a second time, it doesnt pop up and ask you again | 09:43 |
tristan | that UX is horrible | 09:43 |
tlater[m] | Oh, that is actually annoying, never caught onto that. | 09:43 |
tristan | err, anyway phrased backwards, it *does* currently pop up and ask you again | 09:43 |
tlater[m] | Maybe we should also have a message that goes "terminating" | 09:43 |
tristan | We do | 09:43 |
tristan | We have two actually | 09:44 |
tristan | First, we show a message that we are terminating tasks | 09:44 |
tristan | Then, if those tasks don't respond to SIGTERM after a timeout, we have warnings that they were killed | 09:44 |
tlater[m] | Ah, but I meant something a bit more permanent, so that it looks like buildstream is actually busy terminating. | 09:44 |
adds68 | bochecha, ah so this means installing Buildstream i meant grpc, i think there are some crossed wires here | 09:45 |
tlater[m] | It's easy to miss that message and assume we're just continuing to build | 09:45 |
tristan | tlater[m], Well, they are the last lines which appear, and the status bar doesnt show up at that time | 09:45 |
bochecha | adds68: I missed the beginning of the conversation and assumed you were talking about bst :P | 09:45 |
adds68 | But yes maybe installing buildstream via the system package manager will solve the issue | 09:45 |
tristan | tlater[m], really, if you don't have that obnoxious double question popping up, it looks very clear what is going on | 09:45 |
bochecha | adds68: though grpc is still in my copr as well, and the issue I mentioned has details about its inclusion in fedora :) | 09:45 |
adds68 | bochecha, seems currently grpcio is having difficulties with system certificates, which maybe down to the python installation | 09:46 |
tristan | tlater[m], note that my fixes for #479, consequently also fix the end of build summary message to say "WARNING Build terminated", instead of "FAILURE" | 09:46 |
tristan | That seems to have just been a side effect of bad bookkeeping of tasks | 09:46 |
adds68 | bochecha, i guess i can just install using your linked rpm in the that bugzilla? :d | 09:47 |
bochecha | adds68: it's a source rpm in the bugzilla | 09:48 |
bochecha | adds68: add the copr and install from there? | 09:48 |
bochecha | adds68: https://docs.buildstream.build/install_linux_distro.html#fedora | 09:49 |
adds68 | bochecha, documentation :O nice! | 09:50 |
bochecha | adds68: that's been there for a while already :P | 09:50 |
tlater[m] | tristan: This is a surprisingly simple fix. I guess we just weren't sure whether it was intended to be a failure when this was originally written. | 09:50 |
tristan | tlater[m], yeah it was pretty straight forward | 09:51 |
tristan | tlater[m], Note that the fix for master in queue.py is different than for bst-1.2, because now that we cache failed builds, failed jobs need to be propagated through the queues unconditionally | 09:51 |
tristan | That is a whole other can of worms | 09:52 |
tristan | tlater[m], I.e., I wonder how this plays fairly with the frontend popping up and asking whether you want to terminate,quit,continue,debug etc | 09:52 |
tlater[m] | Ah, right, I actually missed that | 09:53 |
tristan | I think I recall discussing this with skullman, and the result was that we force the next job to be included in the batch of pending jobs to execute in a `quit` scenario | 09:53 |
tlater[m] | So the difference is that in master jobs are always added to the done queue? | 09:53 |
tristan | But I'm not exactly clear on how the scheduler has grown a feature to understand this | 09:53 |
tristan | tlater[m], Yes, which - I'm not sure how that plays out in reality honestly; we probably need more rigorous testing because, the possible side effects are pretty scary to think of; maybe there is a clause somewhere to ignore failed elements landing on your incoming queue | 09:55 |
*** finn_ is now known as finnb | 09:55 | |
tristan | tlater[m], Anyway, I think we can put #479 behind us :) | 09:55 |
adds68 | juergbi, bochecha seems using the copr installation is also giving me the same error :( | 09:55 |
tristan | The double prompt at terminate time is next on the chopping block | 09:55 |
* adds68 isn't sure if it's LE or bst at this point | 09:55 | |
tlater[m] | Yeah, it at least fixes that :) | 09:56 |
bochecha | adds68: ok, what's the error? | 09:56 |
adds68 | bochecha, oops sorry, here is the original link, https://gitlab.com/BuildStream/buildstream/issues/692 | 09:56 |
gitlab-br-bot | buildstream: issue #479 ("Incorrect summary when terminating builds") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/479 | 09:59 |
gitlab-br-bot | buildstream: merge request (tristan/fix-terminated-jobs->master: _scheduler: Fix bookkeeping of terminated jobs) #850 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/850 | 09:59 |
gitlab-br-bot | buildstream: merge request (tristan/fix-terminated-jobs-1.2->bst-1.2: _scheduler: Fix bookkeeping of terminated jobs) #851 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/851 | 10:00 |
tristan | Would be nice to also fix "Unknown child process pid 19753, will report returncode 255" when terminating | 10:01 |
tlater[m] | That's a double-kill for a process | 10:01 |
tristan | I think this might be done with ChildWather.remove_child_watcher() | 10:01 |
tristan | tlater[m], It is not ! | 10:01 |
tristan | tlater[m], It seems to be happening every time; or wait... maybe you are right | 10:02 |
tlater[m] | I've seen that error before when double-killing processes | 10:02 |
tlater[m] | I thought I'd caught all scenarios in which that can happen, but evidently not | 10:02 |
tristan | tlater[m], Maybe the two are linked ! because of force terminate needing a second kick in the nuts with the obnoxious double-ask to the user ! | 10:02 |
tristan | i.e., it's not the case where we timeout and force kill, it's happening in a regular terminate | 10:03 |
*** finnb has quit IRC | 10:03 | |
tlater[m] | I've only seen it on force exits, so that's quite possible | 10:03 |
*** finn_ has joined #buildstream | 10:04 | |
tlater[m] | Also no integration tests for interactive stuff, so this wouldn't be caught... | 10:04 |
tlater[m] | These termination issues just show that we really need those. | 10:04 |
bochecha | adds68: try validating the cert with openssl cmd | 10:06 |
gitlab-br-bot | buildstream: issue #693 ("User is promted a second time when force terminating with ^C") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/693 | 10:09 |
tristan | tlater[m], I've just filed it in detail https://gitlab.com/BuildStream/buildstream/issues/693 | 10:10 |
tristan | tlater[m], I would argue that they also indicate that developers need to smoke test more with real projects, rather than relying on CI as a safety net | 10:11 |
tristan | tlater[m], But, both are true | 10:11 |
*** finn has quit IRC | 10:31 | |
*** finn_ is now known as finn | 10:31 | |
*** finn_ has joined #buildstream | 10:31 | |
finn | if anyone uses the bst-artifact-server, I'd be interested to have any feedback on this: | 10:32 |
finn | https://buildgrid.gitlab.io/buildgrid/using_cas_server.html | 10:32 |
gitlab-br-bot | buildstream: merge request (jmac/vdir_import_test->master: WIP: Import test for virtual directories) #815 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/815 | 10:38 |
tristan | Hmmm, any idea what could be re-introducing a SIGINT after terminate ? | 10:39 |
tristan | Analyzing this, things seem to be happening as expected: User hit's ^C -> We enter Scheduler.jobs_suspended() context manager (indirectly) -> This disconnects the event loop connections for SIGINT -> We prompt the user and handle click.Abort (which is ^C) -> We tell the Scheduler.terminate_jobs() (indirectly) -> We exit Scheduler.jobs_suspended(), which reconnects to SIGINT -> Then after the jobs get terminated... we get another SIGINT event ! | 10:41 |
tlater[m] | That seems... odd? Maybe we don't eat the original sigint event and it sticks around somehow? | 10:43 |
tristan | Ohhhhhhh | 10:43 |
tristan | Looky here | 10:43 |
tristan | In that scenario | 10:43 |
tristan | Scheduler.terminate_jobs() gets called a bunch of times ! | 10:43 |
tristan | Aha | 10:44 |
tristan | tlater[m], So, there is some kind of feedback loop where we receive the SIGTERM signals we send to the child processes in the parent | 10:45 |
tristan | tlater[m], Remember that there is a counter for that ? | 10:45 |
tristan | Ah no, it is with SIGTSTP | 10:45 |
Kinnison | isn't that ^Z ? | 10:45 |
tristan | Kinnison, Yes | 10:46 |
tristan | I was wrong, but still suspect that we are receiving a SIGTERM in the parent process for every SIGTERM we send to the child | 10:46 |
tlater[m] | Ah, right, that was an issue we had at some point last year | 10:46 |
Kinnison | That wouldn't be normal POSIX signal behaviour | 10:46 |
tristan | Kinnison, is it standard for SIGTSTP ? | 10:47 |
tristan | (^Z) | 10:47 |
Kinnison | TSTP might be sent through the group | 10:47 |
* Kinnison can't recall off-hand | 10:47 | |
tristan | Although, literally the first thing we do in a child process is call os.setsid() | 10:48 |
tristan | And we launch the job with blocked signals, letting the child unblock them when ready | 10:49 |
* Kinnison recalls something about setpgrp() and setsid() working together | 10:49 | |
jmac | jonathanmaw: Is source mirroring a recent addition to BuildStream, or has it been around forever? I couldn't see an MR adding it. | 10:57 |
*** slaf_ has joined #buildstream | 10:58 | |
*** slaf_ has joined #buildstream | 10:58 | |
jonathanmaw | jmac: it's been around for a while | 10:58 |
tristan | Kinnison, That seems to be system daemon related, no permission to do that afaics (os.setpgrp() hits EPERM) | 10:58 |
*** slaf_ has joined #buildstream | 10:58 | |
*** slaf_ has joined #buildstream | 10:58 | |
jmac | OK | 10:58 |
tristan | Well, I have a fix for the behavior, I just don't like my fix very much | 10:58 |
*** slaf_ has joined #buildstream | 10:59 | |
*** slaf_ has joined #buildstream | 10:59 | |
*** slaf has quit IRC | 10:59 | |
*** slaf_ is now known as slaf | 10:59 | |
jonathanmaw | jmac: the original MR was https://gitlab.com/BuildStream/buildstream/merge_requests/404 I think, though there have been various changes building on it | 10:59 |
toscalix | do we want to have the IRC monthly meeting while most of us are in the same room? | 11:00 |
jmac | jonathanmaw: That's fine - I was just looking for some documentation on how mirroring should be specified. I've found it in the documentation now. | 11:00 |
tristan | I can verify now that we are indeed having feedback SIGTERM in the main process | 11:02 |
toscalix | I would prefer to have the IRC monthly meeting next week | 11:05 |
toscalix | so we have more time face to face and we can use the meeting to prepare the gathering | 11:05 |
tristan | toscalix, Is it already scheduled for next week ? | 11:06 |
tristan | I agree that we don't change it | 11:06 |
toscalix | no, for week 42 | 11:06 |
tristan | Oh you mean you want to bump it up one week | 11:06 |
toscalix | yes | 11:06 |
tristan | I am okay with that, in any case I would like to have it separately | 11:06 |
tristan | For anyone who doesn't attend Manchester, they still get a meeting where we are not all distracted | 11:07 |
toscalix | valentind: laurence Kinnison jmac tlater[m] others? | 11:08 |
* tlater[m] thinks this is sensible | 11:09 | |
jmac | It'll then be during BazelCon which a few of us are attending. I don't mind if you move it, I probably won't attend though. | 11:10 |
toscalix | ah, bazelCon. And the week after is ELCE | 11:11 |
toscalix | so maybe we simply leave it as it is | 11:11 |
juergbi | Kinnison: added env variable test to buildbox !7 | 11:12 |
gitlab-br-bot | buildstream: merge request (jonathan/source-mirror-project-refs->master: tests: Add regression test for mirroring with project.refs) #823 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/823 | 11:12 |
tlater[m] | tristan: I'll be holding a tutorial session during the meetup in two weeks... Trying to come up with a script right now. | 11:13 |
tlater[m] | I'm not sure what I should focus on though | 11:13 |
tlater[m] | On the one hand, we have BuildStream's integration features, and on the other its application development features | 11:13 |
toscalix | tlater[m]: is 101. Assume people do not know anything about buildstream | 11:14 |
toscalix | so installation is first | 11:14 |
mablanch | juergbi, I can't approved BuildBox !7, but looks good to me and tested ok. | 11:14 |
tlater[m] | Absolutely, I'm just not sure what to show after installation | 11:14 |
toscalix | tlater[m]: you should also walk them through the docu | 11:14 |
juergbi | mablanch: thanks | 11:14 |
toscalix | tlater[m]: examples | 11:14 |
toscalix | the ones in the documentation | 11:15 |
toscalix | we use the training sessions to validate the docu | 11:15 |
tlater[m] | Heh, fair enough, that should be alright. | 11:15 |
toscalix | if you need to add info to the examples or new examples... you have there info to include in the docu | 11:16 |
tlater[m] | I just wonder if it properly shows why you'd want to use buildstream over whatever you're already using buildstream | 11:16 |
toscalix | tlater[m]: not sure if this helps... there is a 102 session the day after, a more advance one | 11:20 |
tlater[m] | Ah, who is holding that? Probably a good idea to sync up on what each of us covers | 11:20 |
toscalix | tpollard: and jennis | 11:20 |
toscalix | adds68: will support all of you with examples related with freedesktop-sdk | 11:21 |
jennis | yes tlater[m], let's sync up | 11:24 |
jennis | 102 should probably cover workspaces, build shells, junctions | 11:25 |
jennis | maybe dive into plugins a bit more | 11:25 |
tlater[m] | jennis: Ah, that's interesting. I'd have thought of workspaces as one of the basic parts | 11:25 |
jennis | ok then include that in 101 :p | 11:25 |
tlater[m] | Hell, even build shells - I think the 101 should cover anything you need to develop with buildstream. | 11:25 |
jennis | Let's get a whiteboard later today? | 11:26 |
tlater[m] | Yeah, that's probably best. I'll run through the docs in the meantime and get a write up of all features, so we can coordinate. | 11:26 |
jennis | sounds like a plan! | 11:26 |
jennis | Do we have an option to 'only try and push' to the cache, and not bother looking for an artifact to pull | 11:30 |
laurence | toscalix, perhaps we can try the irc meeting, but if all of the attendees are physically present in manchester, then abandon it quickly | 11:31 |
laurence | since surely the important points will be covered and captured during the week | 11:31 |
jennis | Currently I'm trying to push (previously) unbuilt elements to a remote cache, but it always checks the remote cache first to see if it's there | 11:32 |
toscalix | laurence: we can do that if there is not external participants, yes | 11:32 |
jennis | And for my pipeline of 1500 elements, I'm checking the empty remote cache for about 20 mins before I start building and pushing things | 11:32 |
tpollard | jennis: not as far as I'm aware | 11:33 |
jennis | I know we have `bst push`, but I assume that needs a local build before hand, so I guess I could build without a specific remote cache, then add the cache and then push --deps all | 11:34 |
jennis | but I'm wondering whether this option is something we should consider | 11:34 |
jennis | without a specified remote cache* | 11:35 |
juergbi | jennis: isn't it starting the first build before it finishes pull attempts? | 11:41 |
jennis | no | 11:41 |
juergbi | hm, maybe we could fix that | 11:41 |
juergbi | might be due to fetch jobs being the same class as pull jobs | 11:41 |
juergbi | also, maybe we should introduce a batch API for refs | 11:42 |
jennis | ^^ I wondered whether this was already in motion | 11:42 |
tpollard | that would be good | 11:42 |
jennis | ? | 11:42 |
juergbi | not planned yet. the API/protocol should be simple to add, however, it might not be so easy to actually use it in BuildStream | 11:43 |
juergbi | as these checks are handled element by element | 11:43 |
jennis | Ahh, I thought this batch request could be sent immediately after we determine the pipeline | 11:45 |
jennis | because at that point we have refs and names... | 11:45 |
jennis | can't we then retrieve a list from the server about which elements are 'fetchable'? | 11:47 |
juergbi | due to non-strict build and workspaces, not everything is always available at the start of the session | 11:47 |
jennis | oh ofc | 11:47 |
juergbi | I don't think providing full listing makes sense | 11:47 |
juergbi | 1) it doesn't scale if the same CAS is used for tons of projects | 11:48 |
jennis | but you wouldn't be fetching a workspace and it's reverse dependencies anyway, you'll have to rebuild these right | 11:48 |
juergbi | 2) this could actually be a security issue (right now, nothing is accessible without digests) | 11:48 |
gitlab-br-bot | buildstream: merge request (jonathan/source-mirror-project-refs->master: tests: Add regression test for mirroring with project.refs) #823 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/823 | 11:49 |
jennis | right ok, perhaps this would need further discussion then | 11:49 |
juergbi | with strict builds, you're correct. but there are non-strict builds | 11:49 |
jennis | oh yes, good point | 11:49 |
juergbi | another point is that we actually want to allow pulling elements later during a session even if they were not cached at the beginning | 11:50 |
juergbi | think of long-running build sessions | 11:50 |
jennis | if another dev pushes it in the meantime...? | 11:50 |
juergbi | yes (or more realistically, CI) | 11:50 |
jennis | Ok, perhaps batched isn't the way forward here then | 11:51 |
jennis | but halting all builds until we've checked should probably be fixed | 11:51 |
juergbi | I think the best option is really to ensure that fetch jobs are not starved by pull jobs (if that indeed is the issue) | 11:51 |
juergbi | checking in the background shouldn't hurt too much | 11:51 |
juergbi | I'd even say fetch jobs could always be considered higher priority than pull jobs | 11:52 |
juergbi | maybe we need something more sophisticated, but a simple solution might work quite well | 11:53 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt->master: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #852 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/852 | 11:55 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt-1.2->bst-1.2: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #853 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/853 | 11:56 |
tristan | tlater[m], !852 and !853 fix the behavior, I'm still quite confused as to why this started happening, though | 11:57 |
tlater[m] | tristan: I'll have a look. | 11:57 |
tristan | I added a lot of trace while debugging this, interestingly it really only happens if you hit ^C a second time, if you choose (t)erminate, then it doesnt happen | 11:57 |
tlater[m] | That does sound like the signal is blocked but re-appears when we unblock signals | 11:58 |
tristan | And this keyboard interrupt *does* happen while in the Scheduler.jobs_suspended() context manager, where we have clearly disconnected the signals from the main loop | 11:58 |
tristan | But we don't do that | 11:58 |
tristan | I.e. we don't block SIGINT, we actually *need* SIGINT for click.Abort to be raised and handled in the App interactive session | 11:59 |
tlater[m] | Oh, right | 11:59 |
tristan | We *do* go ahead and block it for the remainder of the program lifetime, after that point | 12:00 |
tristan | Because we don't want ^C interfering with clean shutdown | 12:00 |
tristan | So, we (A) disconnect the asyncio mainloop signal handler... (B) Receive SIGINT in the form of click.Abort exception... (C) Call terminate_jobs, which blocks SIGINT forever and schedules termination in the mainloop... (D) Reconnect signals at that point | 12:02 |
tristan | tlater[m], While that patch does fix the really obnoxious double prompt, it however does *not* fix the "Unknown child process pid 32561, will report returncode 255" messages | 12:02 |
tristan | And those happen *before* we redundantly call terminate_jobs() as a result of receiving feedback SIGTERM events in the main process | 12:03 |
tristan | Still, situation much improved | 12:03 |
tristan | Hmmm, I did consider making this a FIXME/XXX comment | 12:04 |
tristan | Will do, why not | 12:05 |
tlater[m] | Cool, I'm happy with it otherwise. It should just be clear that we want to get to the bottom of this eventually | 12:05 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt->master: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #852 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/852 | 12:05 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt-1.2->bst-1.2: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #853 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/853 | 12:06 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt->master: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #852 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/852 | 12:06 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt-1.2->bst-1.2: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #853 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/853 | 12:07 |
tristan | Hmm, not sure why we got double notifications for those MR updates | 12:07 |
Kinnison | juergbi: I'll look again in a bit | 12:16 |
tlater[m] | Do we have a nice way to access logging yet? Or do you still need to wade through `~/.cache/buildstream/logs`? | 12:33 |
tristan | tlater[m], Still no feature :-/ | 12:35 |
tristan | Which reminds me... We *still* don't print anything useful in the cleanup/cache_size logs | 12:36 |
tristan | There is interesting information there, like how much size was detected and how much remains in quota... and which artifacts we deleted in a cleanup job | 12:37 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt-1.2->bst-1.2: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #853 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/853 | 12:37 |
tlater[m] | Yep, this would be useful at least for debugging | 12:37 |
tristan | Eeek, is this already a filed issue: https://gitlab.com/BuildStream/buildstream/-/jobs/104201523 ? | 12:38 |
tristan | CacheSizeJob unhandled exception: FileNotFoundError: [Errno 2] No such file or directory: '/builds/BuildStream/buildstream/dist/buildstream/tmp/test_push_pull_non_strict0/cache/artifacts/cas/refs/heads/test/target/tmp8_hdcyb3' | 12:39 |
tlater[m] | tristan: Not as far as I know | 12:41 |
tlater[m] | Looks like a race condition when walking the cache directory | 12:42 |
tristan | This is because of tmp files being created/removed while committing an artifact, and CacheSizeJob not finding a file it thinks should exist | 12:42 |
tristan | tiagogomes, Didn't we fix this by giving CAS a tmp directory outside of it's store ? | 12:43 |
tlater[m] | Regardless, utils._get_dir_size() should guarantee that there's no race condition between it finding a file and calculating its size | 12:45 |
tristan | I think we did | 12:45 |
tristan | tlater[m], I was thinking that before, but this might be better | 12:45 |
tristan | I.e. we should be able to guarantee that files in cas/ only get deleted as a result of cleanup, no ? | 12:46 |
Kinnison | juergbi: LGTM, you have an approve for bb!7 | 12:46 |
tristan | And the fact that this error is raising, shows us that for some reason CasCache is not using it's tempdir for tempfiles, but creating temp files in "refs/heads/..." | 12:47 |
tlater[m] | tristan: My only worry with leaving it as-is is that we might use that function elsewhere | 12:47 |
tlater[m] | And we might not be able to guarantee that for things other than the cache | 12:47 |
gitlab-br-bot | buildstream: merge request (jonathan/source-mirror-project-refs->master: tests: Add regression test for mirroring with project.refs) #823 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/823 | 12:48 |
tristan | tlater[m], I'm not convinced, rather we should document the function to assume that things don't inadvertently disappear from the directory while it is being walked | 12:48 |
tlater[m] | Yeah, that works too | 12:48 |
tlater[m] | Anyway we need to figure out why files blip out of existence :) | 12:49 |
tristan | Aha, I see | 12:50 |
tristan | The issue is that utils.save_file_atomic() needs to be given a tempdir, or else it will assume that it's okay to put it beside where the file is going to land | 12:50 |
* tristan notices that utils.save_file_atomic() doesnt even have proper API docs, while it does even have an example | 12:51 | |
tristan | Why does save_file_atomic expose so many parameters anyway ? | 12:54 |
tristan | Ok, I won't fix that together | 12:55 |
gitlab-br-bot | buildstream: issue #694 ("Re-think and document incremental workspaces better") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/694 | 12:58 |
gitlab-br-bot | buildstream: merge request (Qinusty/634-workspace-failed-builds->master: Do not save workspace on failed build) #812 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/812 | 12:59 |
gitlab-br-bot | buildstream: merge request (tristan/fix-cache-size-race->master: fix cache size race) #854 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/854 | 13:02 |
tristan | And here is the fix for the race condition: https://gitlab.com/BuildStream/buildstream/merge_requests/854 | 13:03 |
* tristan backports | 13:03 | |
gitlab-br-bot | buildstream: merge request (Qinusty/634-workspace-failed-builds->master: Do not save workspace on failed build) #812 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/812 | 13:03 |
gitlab-br-bot | buildstream: merge request (tristan/fix-cache-size-race-1.2->bst-1.2: Tristan/fix cache size race 1.2) #855 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/855 | 13:05 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt->master: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #852 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/852 | 13:05 |
gitlab-br-bot | buildstream: merge request (tristan/fix-cache-size-race->master: fix cache size race) #854 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/854 | 13:06 |
*** solid_black has quit IRC | 13:12 | |
*** cs-shadow has joined #buildstream | 13:19 | |
tlater[m] | So python 3.7 is giving me this warning: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working | 13:26 |
tlater[m] | This happens in a lot of our yaml loading code | 13:26 |
tlater[m] | As far as I can tell, python<3.7 don't support loading mapping from collections.abc | 13:27 |
tlater[m] | But python>=3.8 won't support loading it from collections | 13:27 |
tlater[m] | Any idea how we should migrate? | 13:27 |
tlater[m] | Maybe better to ask on #python or somesuch | 13:27 |
tristan | This comes as a surprise to me, as I recall we *were* considering using collections.abc, but never went ahead and actually did it yet | 13:27 |
tlater[m] | Ah, nevermind, I misread | 13:28 |
tlater[m] | That has been possible since 3.3 | 13:28 |
tlater[m] | I figure we should just start using the .abc then? | 13:28 |
tlater[m] | We require 3.5 anyway, so this shouldn't be an issue | 13:28 |
tristan | I think if we use abc *at all*, we should do it across the codebase, not arbitrarily here and there | 13:29 |
tlater[m] | tristan: I'd move the entire codebase to start using collections.abc for Mapping so that we don't fall under the bus when 3.8 starts being used | 13:29 |
tristan | In fact, I feel the same way about haphazardly deciding to use @property here and there, while the rest of the codebase communicates a clear consistent standard use of explicit accessors name `def get_foo(self):` | 13:30 |
tlater[m] | Do you mean I should start using abstract base classes for our abstract classes to? | 13:30 |
tristan | tlater[m], it would be good to use ABC for ArtifactCache, Sandbox, Plugin, Element, Source | 13:31 |
tristan | It can be done without breaking API | 13:31 |
tristan | And will allow better linting | 13:31 |
tlater[m] | Hm, to be fair, that doesn't seem too involved | 13:31 |
tristan | However, there are some cases where ABC is too rigid | 13:31 |
tristan | For instance, it thinks that an abstract method should not have a default implementation, or that an implementor *must* implement an abstract method | 13:32 |
tristan | Which, is just not true | 13:32 |
tlater[m] | Well, in that case it's not an abstract method | 13:32 |
tristan | So, our uses of ABC would be a bit contorted, I think that's why I didnt go forward with it | 13:32 |
tristan | tlater[m], Only according to ABC, not according to basic OOP concepts | 13:33 |
tlater[m] | I'm pretty sure according to OOP concepts it is not considered an abstract method, since abstract methods are those that have no implementation. | 13:33 |
tlater[m] | That doesn't keep you from overriding a normal method | 13:33 |
tristan | Well, not sure what it buys us then to use ABC | 13:34 |
tlater[m] | tristan: I'm getting a bit annoyed by my linter showing me deprecation warnings, would you accept an MR that only deals with the about-to-be-deprecated python API? | 13:34 |
tristan | I.e. if we don't describe it as an @abstractmethod, then we don't have any added protection for other... what would you call them, virtual methods ? | 13:35 |
tristan | tlater[m], How about stop using ABC altogether, where are we using it and why ? | 13:35 |
tlater[m] | tristan: We aren't using ABC - this is python moving one of their modules to a different name, and has nothing to do with ABC itself | 13:35 |
tlater[m] | (Internally perhaps this means that they started using ABC) | 13:36 |
tristan | tlater[m], Right, but the deprecation warning you mentioned above mentions this, so if we are not using it, it is a dependency that is doing that | 13:36 |
tlater[m] | tristan: The dependency is python | 13:37 |
tristan | As such, it's sort of out of our control, but I would presume that dependency will probably work itself out by that time | 13:37 |
tristan | Sigh, so python introduces a deprecation warning, which itself causes to happen in it's own standard library ? | 13:37 |
tristan | Then, this is a non-issue right ? | 13:37 |
tristan | Python will sort itself out | 13:37 |
tlater[m] | tristan: One of the lines showing that warning is this one: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_context.py#L22 | 13:38 |
tlater[m] | If we keep this into python3.8 buildstream will fail to load half of our yaml parsing | 13:38 |
tristan | Ahh | 13:38 |
tlater[m] | What that warning suggests is replacing that line with `from collections.abc import deque, Mapping` | 13:38 |
tristan | tlater[m], That deprecation warning is poorly worded IMP | 13:38 |
tristan | IMO | 13:39 |
tristan | tlater[m], Yes that sounds entirely sensible | 13:39 |
tlater[m] | Agreed, I had to dig into docs to understand it ;p | 13:39 |
tristan | It seems to suggest that people think about dequeue, Mapping, etc... as "ABCs" | 13:39 |
tristan | But anyway, I got the picture now, yes please of course that MR would be correct :) | 13:40 |
tlater[m] | Cool - I was mostly confused because I thought we'd deprecate using python<3.7 | 13:40 |
*** catonano has joined #buildstream | 13:40 | |
adds68 | juergbi, bochecha, Kinnison it seems rebuilding the server fixed this issue, i am wondering if it was due to snakeoil certificates being generated before the valid ones | 13:41 |
tristan | tlater[m], Seems pretty superficial change on Python's part; I don't think it's really that costly for them to keep supporting it until python 4 | 13:42 |
gitlab-br-bot | buildstream: issue #693 ("User is promted a second time when force terminating with ^C") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/693 | 13:42 |
gitlab-br-bot | buildstream: merge request (tristan/fix-double-terminate-prompt->master: _scheduler/scheduler.py: Ignore interrupt events while terminating.) #852 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/852 | 13:42 |
tlater[m] | I agree, I think it's a bit stupid. But we'd have to lobby python to change that, so... | 13:42 |
* tristan dislikes that python thinks it's just a-okay to warn people in one cycle that they will break peoples apps in the next | 13:42 | |
tristan | An app written against a stable API today, should work in 10 years | 13:43 |
gitlab-br-bot | buildstream: merge request (tristan/fix-cache-size-race->master: fix cache size race) #854 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/854 | 13:44 |
gitlab-br-bot | buildstream: merge request (tristan/fix-cache-size-race-1.2->bst-1.2: Tristan/fix cache size race 1.2) #855 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/855 | 13:44 |
*** catonano has quit IRC | 13:44 | |
*** catonano has joined #buildstream | 13:45 | |
*** catonano has quit IRC | 13:46 | |
*** catonano has joined #buildstream | 13:47 | |
Kinnison | adds68: glad to hear you solved your problem | 13:54 |
*** tiagogomes has quit IRC | 13:57 | |
adds68 | Kinnison, :D | 14:00 |
tlater[m] | Heh, I just discovered a pylint annoyance where @abc classes would help | 14:05 |
tlater[m] | It can't quite figure out that a method raises a NotImplementedError but is intended to return something when implemented | 14:06 |
*** tristan has quit IRC | 14:06 | |
tlater[m] | So it flags a bunch of lines as us assigning from a function that doesn't return a value | 14:06 |
* tlater[m] should investigate what @abc would add over our current implementation at some point | 14:07 | |
jmac | Similarly, pylint likes to complain that a class's __init__ didn't call its superclass's __init__, despite the superclass __init__ just being a NotImplementedError | 14:09 |
gitlab-br-bot | buildstream: merge request (tristan/fix-cache-size-race->master: fix cache size race) #854 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/854 | 14:09 |
tlater[m] | Yeah, these things would be fixed by using python's proper abstract class infrastructure | 14:10 |
tlater[m] | It would also flag them early for people who don't believe in pylint | 14:11 |
*** tristan has joined #buildstream | 14:14 | |
gitlab-br-bot | buildstream: issue #695 ("Allow configuring default location for workspaces") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/695 | 14:34 |
*** tiagogomes has joined #buildstream | 14:36 | |
gitlab-br-bot | buildstream: issue #229 ("Allow configuring default location for workspaces") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/229 | 14:38 |
gitlab-br-bot | buildstream: issue #692 ("SSL root certificate error when configuring a cache") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/692 | 14:46 |
gitlab-br-bot | buildstream: merge request (tiagogomes/docs-improvements->master: Documentation improvements) #835 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/835 | 15:39 |
*** catonano has quit IRC | 16:18 | |
gitlab-br-bot | buildstream: merge request (jmac/temporaries-inside-cachedir->master: Move the temporary staging directory to artifactdir) #856 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/856 | 16:20 |
gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/bwrap-check-runtime-only->master: WIP: Make bwrap check runtime only) #847 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/847 | 16:21 |
*** tiagogomes has quit IRC | 16:22 | |
*** toscalix has quit IRC | 16:29 | |
Kinnison | juergbi: I've updated !847 since your change to the linux platform was merged. All the current test suite passes so I hope it's enough. I'm not happy without a specific test for 847's changes, but ultimately the timeline on that is up to you and tristan regarding extra dockers etc. | 16:29 |
jmac | https://gitlab.com/BuildStream/buildstream/merge_requests/856 is a (hopefully) 5-minute review job if anyone fancies it | 16:32 |
* Kinnison takes a quick look for jmac | 16:36 | |
gitlab-br-bot | buildstream: merge request (jmac/temporaries-inside-cachedir->master: Move the temporary staging directory to artifactdir) #856 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/856 | 16:37 |
Kinnison | jmac: the reasoning is sound and the change looks good to me | 16:37 |
* Kinnison approves | 16:37 | |
*** tiagogomes has joined #buildstream | 16:37 | |
*** jonathanmaw has quit IRC | 16:43 | |
gitlab-br-bot | buildstream: merge request (jmac/temporaries-inside-cachedir->master: Move the temporary staging directory to artifactdir) #856 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/856 | 16:44 |
*** xjuan has joined #buildstream | 16:49 | |
*** phildawson has quit IRC | 16:54 | |
*** raoul has quit IRC | 17:30 | |
*** tristan has quit IRC | 18:53 | |
*** tristan has joined #buildstream | 18:56 | |
*** tristan has quit IRC | 19:02 | |
*** tristan has joined #buildstream | 19:15 | |
*** lachlan has quit IRC | 19:19 | |
*** catonano has joined #buildstream | 19:50 | |
cs-shadow | hi! Do we have a known issue with our aarch64 runners? https://gitlab.com/BuildStream/buildstream-docker-images/-/jobs/104044816 failed without ever getting assigned a worker | 20:26 |
gitlab-br-bot | buildstream: merge request (chandan/bst-docker-import->master: Add contrib script to generate Docker images from bst checkout) #857 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/857 | 21:31 |
gitlab-br-bot | buildstream: merge request (chandan/bst-docker-import->master: Add contrib script to generate Docker images from bst checkout) #857 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/857 | 21:31 |
gitlab-br-bot | buildstream: merge request (chandan/bst-docker-import->master: Add contrib script to generate Docker images from bst checkout) #857 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/857 | 21:43 |
*** bochecha has quit IRC | 22:08 | |
*** bochecha has joined #buildstream | 22:08 | |
*** bochecha has quit IRC | 22:12 | |
*** bochecha has joined #buildstream | 22:13 | |
gitlab-br-bot | buildstream: merge request (valentindavid/staging_order_and_link_files->master: Make link_files and copy_files and behave independently to staging order) #858 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/858 | 22:34 |
*** xjuan has quit IRC | 23:02 | |
*** catonano has quit IRC | 23:06 | |
*** bochecha has quit IRC | 23:21 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!