IRC logs for #buildstream for Tuesday, 2018-04-17

*** inigomartinez has quit IRC00:07
*** ptomato[m] has quit IRC00:07
*** rafaelff[m] has quit IRC00:08
*** ernestask[m] has quit IRC00:08
*** cgmcintyre[m] has quit IRC00:08
*** mattiasb has quit IRC00:08
*** waltervargas[m] has quit IRC00:08
*** connorshea[m] has quit IRC00:08
*** pro[m] has quit IRC00:08
*** asingh_[m] has quit IRC00:08
*** segfault3[m] has quit IRC00:08
*** awacheux[m] has quit IRC00:08
*** bochecha has quit IRC00:08
*** theawless[m] has quit IRC00:08
*** abderrahim[m] has quit IRC00:08
*** kailueke[m] has quit IRC00:08
*** ssssam[m] has quit IRC00:08
*** m_22[m] has quit IRC00:08
*** alatiera has quit IRC00:08
*** jjardon[m] has quit IRC00:08
*** inigomartinez has joined #buildstream00:10
gitlab-br-botbuildstream: issue #363 ("Allow modifying elements with unversioned config file") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/36300:20
*** ptomato[m] has joined #buildstream01:04
*** Prince781 has joined #buildstream01:20
*** mattiasb has joined #buildstream02:23
*** Prince781 has quit IRC02:29
*** ernestask[m] has joined #buildstream02:37
*** ernestask[m] is now known as Guest4366702:38
*** connorshea[m] has joined #buildstream03:03
*** waltervargas[m] has joined #buildstream03:05
*** rafaelff[m] has joined #buildstream03:23
*** solid_black_ has quit IRC04:03
*** kailueke[m] has joined #buildstream04:04
*** awacheux[m] has joined #buildstream04:33
*** tristan has quit IRC05:50
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40605:51
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40605:55
*** bochecha has joined #buildstream05:58
*** abderrahim[m] has joined #buildstream05:58
*** ssssam[m] has joined #buildstream06:06
*** alatiera has joined #buildstream06:07
jjardonHi, any reason why https://gitlab.com/BuildStream/buildstream-examples/tree/x86image/build-x86image has not been merged in master of that repo yet? is there something missing?06:13
*** tristan has joined #buildstream06:16
gitlab-br-botbuildstream: merge request (jjardon/build_badge->master: README.rst: Add pipeline status badge) #407 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40706:23
*** asingh_[m] has joined #buildstream06:32
*** cgmcintyre[m] has joined #buildstream06:42
gitlab-br-botbuildstream: merge request (jjardon/build_badge->master: README.rst: Add pipeline status badge) #407 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40706:45
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40606:45
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40606:46
tristanjuergbi, I think I misunderstood #182 which you reopened06:53
tristanjuergbi, this is about closing a workspace which does not exist... in the workspaces file even ?06:54
tristanand the ordering of messages06:54
juergbiyes06:54
juergbiyou originally filed the issue ;)06:54
tristanEasy to fix, indeed06:54
tristanI looked into testing interactive mode but still didnt find much useful :-(06:55
tristanI found some pytest things which run a test with some "input", but we need more than that06:55
tristanwe need sessions, and wait for being prompted something... and then answering... etc... so we probably need to implement that ourselves06:56
juergbiwe probably need to fork and handle I/O from there06:56
juergbidon't know whether there is something in the pytest ecosystem06:57
tristanWe can pretty easily cheat the app into pretending it's interactive mode without a real tty06:57
gitlab-br-botbuildstream: merge request (jjardon/doc_readme->master: source/index.rst: Use the README as our intro) #405 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40506:57
tristanbut yeah, we probably need some fork06:57
tristanand that probably makes things also complicated for coverage report collection06:58
*** theawless[m] has joined #buildstream07:02
*** jjardon[m] has joined #buildstream07:08
juergbiif we use the fork for the emulated user and keep bst itself in the parent, coverage should be fine07:10
gitlab-br-botbuildstream: issue #364 ("bst workspace open --force doesnt work") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/36407:11
gitlab-br-botbuildstream: merge request (tristan/workspace-cli-fixes->master: Some fixes for the workspace CLI) #408 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40807:12
tristanjuergbi, Ah good point07:12
tristaninteresting07:12
tristanwell... that's more than a days work... hehe07:13
tristaneh, I'll make !408 a bit better first...07:21
*** solid_black_ has joined #buildstream07:22
gitlab-br-botbuildstream: merge request (tristan/workspace-cli-fixes->master: Some fixes for the workspace CLI) #408 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40807:25
*** solid_black_ has quit IRC07:25
*** solid_black_ has joined #buildstream07:25
*** solid_black_ has quit IRC07:29
gitlab-br-botbuildstream: issue #182 ("Closing non-existing workspace") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/18207:37
gitlab-br-botbuildstream: issue #182 ("Closing non-existing workspace") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/18207:37
gitlab-br-botbuildstream: merge request (tristan/workspace-cli-fixes->master: Some fixes for the workspace CLI) #408 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/40807:37
*** pro[m] has joined #buildstream07:39
*** segfault3[m] has joined #buildstream07:47
gitlab-br-botbuildstream: merge request (devcurmudgeon/buildstream-ps-update-readme->master: Update README.rst with more detail) #403 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40307:50
paulsherwood/win/win 1207:52
paulsherwoodeek07:52
*** tristan has quit IRC07:54
*** tristan has joined #buildstream07:59
*** jennis has quit IRC08:00
*** toscalix has joined #buildstream08:03
*** jennis has joined #buildstream08:04
*** m_22[m] has joined #buildstream08:05
gitlab-br-botbuildstream: merge request (tristan/fix-workspace-force-open->master: Fix force openening of workspaces) #409 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40908:11
tristanjuergbi, any thoughts on 409 ?08:16
tristanjuergbi, I'm changing opening workspace codepaths to A.) initialize the workspace in a tempdir in Context.builddir... B.) utils.link_files() into the target workspace directory08:16
tristananything that could go wildly wrong with that you think ?08:17
juergbiassuming link_files properly handles overwriting, I can't think of an issue right now08:18
juergbiit should already handle symlinks etc08:19
juergbinot deleting existing files could produce some odd behavior with certain sources08:20
juergbiessentially merging two .git directories is pretty odd08:20
juergbibut I can't think of anything that would actually break like that08:20
juergbithat said, I generally prefer replacing the whole workspace instead of some odd merge08:21
juergbiwhich is what we already support via reset, afaict08:21
gitlab-br-botbuildstream: merge request (devcurmudgeon/buildstream-ps-update-readme->master: Update README.rst with more detail) #403 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/40308:21
juergbiwhat's the use case of merge (open --force) compared to reset?08:22
juergbiincremental build will anyway no longer work08:22
tristanbst workspace reset requires an already existing workspace, and it will delete files that you might have lying around08:24
paulsherwoodtristan: thanks for merging the readme stuff. i'm thinking of adding a bit more content there, borrowing from your original "Introducing Buildstream" post... would you be ok with that?08:24
paulsherwoodin particular i think https://blogs.gnome.org/tvb/files/2017/01/build-bootstrap-cropped-1.png would be a useful addition08:24
tristanpaulsherwood, sure ! I think with jjardon's patch which integrates it both in the README.rst and also in the documentation it will be nice08:25
tristanI'm going to fix a small typo in there08:25
tristan"BuildStream is an Free Software tool..." s/an/a08:25
*** noisecell has joined #buildstream08:25
paulsherwoodeek :)08:25
tristaneh, I'd rather just fix it than play ping pong in merge requests08:26
paulsherwoodtristan: let me fix that, with some further tweaks08:26
tristanalright then08:26
tristanpaulsherwood, also, can I ask you to fix it to be more consistent with our other documentation .rst files ?08:27
tristanessentially... A.) No empty line after a title line ----------- or ==============08:27
tristanB.) Two empty lines before any title line08:27
tristanhaving it all the same way just makes editing the rst files more comfortable08:28
tristanjuergbi, right so... reset deletes files, open --no-checkout does not set the files into the exact state of the project... and more importantly; we already have the option08:30
juergbitristan: yes but it's anyway not as safe as e.g. git checkout/pull/merge as it overwrites local changes to source files, so I'm not convinced it properly covers the actual use case08:30
tristanjuergbi, i.e. if removing API was a discussion we could have, then we'd have a different discussion right ?08:30
juergbiright, just thought I'd mention it ;)08:30
tristanYeah, I sort of agree that it's not the most desirable option to have, but hindsight is 20/20 :)08:31
gitlab-br-botbuildstream: merge request (tristan/fix-workspace-force-open->master: Fix force openening of workspaces) #409 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40908:32
tristanpaulsherwood, if we add pngs, I'd rather look at more recent slides, say from FOSDEM08:33
tristanpaulsherwood, the original pngs you linked to are very old, and I tidied these up to represent things closer to what we implemented08:34
* tristan looks for more recent libreoffice files08:36
tlaterjjardon: I guess your question went under in MR stauses? That branch hasn't been merged yet because we're not sure what we're going to do with the repository as a whole - perhaps we can merge it anyway, I suppose, if we're not going to use the branch it doesn't matter.08:38
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41008:39
tristanhmmmm, old images and .odg files are hard to find :-S08:44
jjardontlater: yeah, let's open a MR and merge it?08:44
jjardonIt's actually quite handy example and I didn't know that it exists08:45
*** jonathanmaw has joined #buildstream08:45
jjardonand now is part of the README so I think it makes sense08:45
tristanpaulsherwood, I have the original .odg file for the png you linked though, if you'd like to be able to edit it08:46
tlaterjjardon: I thought I had an MR open already... Well, I opened one :)08:46
gitlab-br-botbuildstream: issue #364 ("bst workspace open --force doesnt work") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/36408:46
gitlab-br-botbuildstream: issue #364 ("bst workspace open --force doesnt work") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/36408:46
gitlab-br-botbuildstream: merge request (tristan/fix-workspace-force-open->master: Fix force openening of workspaces) #409 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/40908:46
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41008:47
tristanpaulsherwood, anyway sent you the original source for that image... note that if we add pngs to our docs, we should also add the backing odg files in somewhere like docs/image-sources, so that we can easily modify them in the future08:49
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41008:51
jjardontlater: thanks; ok to change the license to something more permissive? https://gitlab.com/BuildStream/buildstream-examples/merge_requests/308:54
gitlab-br-botbuildstream: merge request (documentation-formatting-in-HACKING->master: Documentation formatting in hacking) #411 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41108:55
gitlab-br-botbuildstream: merge request (documentation-formatting-in-HACKING->master: Documentation formatting in hacking) #411 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41108:57
*** bethw has joined #buildstream08:58
gitlab-br-botbuildstream: merge request (documentation-formatting-in-HACKING->master: Documentation formatting in hacking) #411 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41108:58
tlaterjjardon: Yep, that seems sensible08:59
jjardontlater: cheers09:00
gitlab-br-botbuildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41209:12
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41009:16
gitlab-br-botbuildstream: merge request (make-source-dir-resemble-ToC->master: Restructure directories under source/ to resemble ToC) #413 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41309:18
gitlab-br-botbuildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41209:20
gitlab-br-botbuildstream: merge request (make-source-dir-resemble-ToC->master: Restructure directories under source/ to resemble ToC) #413 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41309:20
*** bethw has quit IRC09:36
gitlab-br-botbuildstream: merge request (make-source-dir-resemble-ToC->master: Restructure directories under source/ to resemble ToC) #413 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41309:41
gitlab-br-botbuildstream: merge request (make-source-dir-resemble-ToC->master: Restructure directories under source/ to resemble ToC) #413 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41309:43
paulsherwoodtristan: i'll take a shot at the diagram09:43
tristanthanks !09:43
tristanpaulsherwood, I think I detailed the changes pretty well in the comments, it's just a matter of changing some names, and doing an export / crop09:44
tristanwish I had a more recent one handy09:44
jjardontristan: (or anyone else that knows); can you check what is in here is correct, please? So I can work in a MR: https://gitlab.com/BuildStream/buildstream/issues/35309:52
gitlab-br-botbuildstream: merge request (jjardon/doc_sandbox->master: docs: Fix build with latest version of sphinx) #414 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41409:56
tlaterjjardon: We also depend on bwrap for sandboxing and ostree for caching artifacts - not sure if those are relevant to the list10:01
tristanI think those are not in the list because they are already documented ?10:04
tristantlater, also, it is a hard requirement10:04
jjardontlater: rigth, what about build systems? Do we depend on autotools / meson / qmake ...etc from the host?10:04
tristanthat list is about optional stuff... but we should add ssh to it because of artifact pushing10:04
tristanjjardon, not at all10:05
tristannever10:05
jjardonok, cool10:05
tristanjjardon, only for Source plugins to obtain data10:05
jjardonrigth10:05
tlaterNot depending on host build systems is sort of the point of buildstream :)10:05
jjardonwell, I didnt know that we depend for the Source plugins, so better to be sure10:06
tristantlater, you let juergbi steal all my fire ??10:07
tristantlater, it's one of the points, though :D10:07
*** mohan43u has quit IRC10:09
gitlab-br-botbuildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41210:11
tristanpaulsherwood, https://gitlab.com/BuildStream/buildstream/tree/ps-add-diagram is a bit funny :)10:12
tristanworth a giggle at least... it needs a downscale I think... I can only see a corner of the image in my browser :D10:12
paulsherwoodtristan: i downscaled before, you said "The image upscales horribly in my browser"10:14
tristanpaulsherwood, I mean, it should not be scaled at all...10:14
paulsherwoodi have not found a way to get gitlab to handle image scaling properly in RST10:14
tristanprobably have to find the rst invocation for telling it to not scale the image, but to center it instead10:14
tristanhmmm10:14
tristanI see :-S10:14
paulsherwoodthe render is way larger than the original image10:15
* paulsherwood shakes fist at gitlab10:15
tristanpaulsherwood, http://docutils.sourceforge.net/docs/ref/rst/directives.html#images10:16
tristandid you find that ?10:16
*** mohan43u has joined #buildstream10:16
tristanlooks like maybe :scale: 100% ... :align: center ... might do it ?10:16
paulsherwoodyes. gitlab seems to ignore them10:16
tristanHrrrrmmmm10:16
tristanpaulsherwood, maybe it's better to split this out then and only have it in the actual docs ?10:17
jjardontristan: paulsherwood  are we sure we want to put that in the README, and not in https://buildstream.gitlab.io/buildstream/ ?10:17
tristanjjardon, exactly what I was thinking... but I wouldn't have minded since you add the README.rst to the docs10:17
paulsherwoodjjardon: i'm aiming for the readme first, then the website :-)10:17
tristanin a further MR which I havent merged yet10:17
tristanpaulsherwood, lets accept gitlab rst rendering limitations and do this part only in the actual docs I think10:18
gitlab-br-botbuildstream: merge request (jjardon/doc_readme->master: source/index.rst: Use the README as our intro) #405 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40510:19
tristanI suppose this would be an introduction section or such which would include the README.rst, before the meat of the docs10:19
jjardonpaulsherwood: we can do both at the same time :) : https://gitlab.com/BuildStream/buildstream/merge_requests/405 tristan I will check if the image link still works in the docs on the web site10:19
tristanjjardon, I'm quite sure it will work on the website, because sphinx will transform it into html10:20
tristanmost probably way more capably than gitlab's rudimentary support for displaying a simple readme file10:20
jjardontristan: not that, not sure if the  link to the image is going to work or not, let me try10:21
tristanOk10:21
tristanjjardon, look at the existing rst files, I suppose the relative paths used in `.. literalinclude::` expressions are a good hint10:22
tristanjjardon, for where to source the png from10:22
tristanjust grep that in doc/source and find examples of paths10:22
tlaterDoesn't gitlab allow just putting plain HTML tags in the file? You could try and force scaling it by creating literal HTML.10:23
tlaterI think they have a whitelist of allowed tags/attributes10:23
tlaterMight be confusing it with github though10:23
jmacIf you do that will it still work with Sphinx?10:24
paulsherwoodthat may work. but once we're hacking to that extent, i'd ask why aren't we doing readme.md rather than rst10:24
tristantlater, I think that sucks... because we'll reuse the README.rst in the docs as an introduction as well10:24
paulsherwoodthat answers my previous question :)10:24
gitlab-br-botbuildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41210:27
jennistristan, to address your point on !410, we decided on having a "Commands" section under "Using BuildStream" that will be more wordy explanations10:28
paulsherwoodi can frab it with loads of whitespace on the right... but ewww10:28
jennisNow, we already have the invoking buildstream, this should be under "Reference Documentation" right?10:29
gitlab-br-botbuildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41210:34
tristanjennis, right that part I always found ambiguous, we have to put Commands (Invoking BuildStream) in either one place or the other10:35
tristanjennis, it either goes in the Reference, or in Using BuildStream10:35
tristanI think maybe Using is better, as it cannot be so terse, and is more targetted at people who use the CLI but not necessarily author projects or plugins10:36
jennistristan, ok let's do that. And within the Getting Started / Examples we'll have more "wordy" explanations about some of the key commands10:37
tristanjennis, is there some kind of confusion, is there a "Commands" _and_ and "Invoking BuildStream" ? I think they are two different names of the same thing10:37
tristanUhhhh10:37
jennisSo, atm we only have the invoking10:37
*** bethw has joined #buildstream10:37
tristanjennis, there is a patch, which takes the automated documentation and splits it up into separate parts, so that we can put the more wordy stuff *in the same place*10:37
jennisright ok10:38
tristanI.e. there is only *one thing*, it only needs to be enhanced so that we can add text to each command explaining stuff10:38
*** aday has joined #buildstream10:39
jennisSo, lets just rename "Invoking BuildStream" to "BuildStream commands", keep it under "Using BuildStream" and flesh it out later?10:39
tristanjennis, in addition to that; we have the option to add more "How Do I" style documentation in the examples; like "How do I use a workspace"10:39
jennisyes that will come :) right now I just want to focus on having the structure look sensible10:40
tristanjennis, lets call it Commands, under Using BuildStream10:40
tristanand avoid too many BuildStream is BuildStream BuildStream BuildStream...10:40
jennistristan, ok agreed. I'll update !410 accordingly10:40
jennistristan, just to clarify, we want "User configuration" and "Authoring projects" under "Reference documentation"?10:45
tristanjennis, User Configuration probably goes under Using BuildStream no ?10:45
* tristan consults the google doc10:45
tristanwe didnt cover that10:46
tristanjennis, lets put user configuration with using10:46
tristanjennis, and hope to make that more human, entry level friendly over time10:46
tristanactually yeah it seems already pretty user friendly, but could be improved and completed10:47
tristanjennis, we might do some further changes to Authoring Projects, what it really is, is the terse complete reference documentation of the project format10:49
tristanmaybe we'll rename it and restructure within there too to bring it all together10:49
* tlater has been bothered by this for a long time, is there any way to use the message handler interface without an element?10:50
jennistristan, ok :) I've do some more restructuring and update the MR10:50
jennisi'll*10:50
tlaterIt's hard to send out debug messages without having them overwritten by some pipeline message :|10:50
tristantlater, as long as you have a Context object10:50
tlaterWell, that interface wants a Message, which requires a plugin ID10:51
tristantlater, some classes create their own convenience _message() thing10:51
tlaterAnd as far as I can tell you can only give that an element's plugin ID?10:51
tristantlater, I wouldnt be averse to adding such a convenience at the Context level and removing the others10:51
tristantlater, no, I think it need not be specified10:52
tristantlater, see how Pipeline() implements it for instance10:52
tlaterOh, I can set that to None?10:52
tlaterAck10:52
tlatero\10:52
tristanyou can just not provide one10:52
tlaterta tristan, if you set it to a garbage string buildstream complains, so I thought it was requried10:52
tristanit will show up as one of those startup messages which dont display an element name10:52
tristanor cache key10:52
* tlater thinks a convenience context function might be neat, but will hold off on creating one for now.10:54
tristanif you create one, then either all the other ones on various objects need to be removed, or need to be changed to pass through that one10:54
tristan(there are not many, though)10:55
* tlater would prefer to remove them10:55
tristanand then replace the calls with something like self.context.message(...)10:55
tristanthat works10:55
tlatertristan: Would you mind having a set of functions that change the MessageType as well? That way we could avoid having to import that for debug messages10:56
tristan(also helps clarify what voodoo a message() function is doing)10:56
tlaterI.e., have context.info, context.warn10:56
tristantlater, sure, it's all private API anyway10:56
tristanI think it can just keep the **kwargs trick too so that wrappers are easy to do10:57
tristanonly the public API facing Plugin.info()... functions need explicit signatures10:57
tlatertristan: That kwargs->dict trick actually, why do we need it? As far as I understood kwargs they can just be passed with **11:04
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41011:08
tristantlater, if you can simplify it, do it !11:10
tristantlater, I just took something that worked and repeated it ;-P11:10
tlaterAh, heh, was just wondering whether I'm missing an intricacy of python here11:10
jennistristan, if you get a chance could you look at !410 please?11:11
tristanjennis, I havent been keeping track but... have you been rebasing and squashing your branch into sensible commits ?11:13
tristanjennis, looks like a lot of commits, but they may be justified...11:13
* tristan looks at changes11:13
jennisThey are sensbile commits11:14
jennisI'll have a look and see if any can be squashed11:14
tristanjennis, no worry; I just wanted to ask you because I didnt want to go and tediously check them all myself11:16
tristanjennis, So there is another MR about the style guide for HACKING.rst... please remember to mention that the style for titles is to only capitalize the first word11:17
tristanwhich seems to be a big sweeping change you've effected11:17
tristanI dont mind either way but consistency is important :)11:17
tristanjennis, in the future, please remember to title your branches jennis/branch-name11:18
tristanand the docs dont build11:19
tristan /codethink/GNOME/buildstream/doc/source/core_framework.rst:6:duplicate label core_framework, other instance in /codethink/GNOME/buildstream/doc/source/main_core.rst11:19
jennistristan, yes consistency is important. I will update that MR accordingly11:20
jennistristan, and yes I will do that in the future11:20
tristanjennis, I wanted to see the docs before saying anything... but they dont build11:20
tristanwere you able to build it locally ?11:20
jennisyes11:20
tristanstrange11:21
jennisI had that error and changed the anchor names appropriately11:21
jennisI'll have another look11:21
tristanmaybe you didnt repush the branch11:21
tristanor maybe there is a file which was supposed to be renamed but the source wasnt removed11:21
* tristan tries a git clean -xdf first11:22
jennisI think it's the latter11:22
tristanjennis, looks like I had a stale file after pulling11:22
tristanit builds now11:22
tristanafter git clean -xdff11:22
tristanthat is odd, though11:23
tristanjennis, ok... "general documentation" needs to go11:23
jennisOk I wanted to speak to you about this11:24
tristanArtifact Caches probably goes under Installing11:24
tristanthe other two are reference material, which dont fit into the documentation structure very well11:25
tristan"Cache Keys" is basically, someone wanted it to be documented, and we accepted it, but it doesnt fit into anything anywhere11:25
jennisOk then, lets rename that to "Configuring an artifact cache" then?11:25
jennisYes tristan, hence why I made the general documentation section "describing some of BuildStream’s prominent features"11:26
jennisbut if you're opposed I'll put it back into reference documentation11:26
tristanRight, so that sounds good to me11:26
tristanConfiguring an artifact cache11:26
tristanOr11:27
tristanjennis, maybe we should call it an "artifact share" ?11:27
tristanMeh, we can call it a cache11:27
tristanjennis, yes I am certainly opposed11:27
tristanjennis, a big point of this exercise is to sort things out well, both of these reading materials are rather terse and involved11:28
tristanI want to hide them away under reference documentation11:28
jennisI see, ok I'll make the changes11:29
tristanjennis, do you know how that ToC works ? it's all quite an enigma to me11:29
tristanjennis, what I wonder is, can we stop showing the subitems in the toctree in index.rst, but not everywhere else ?11:29
jennistristan, I think that's easy to do11:29
tristanmaybe it's not that important...11:30
jennisI suspect its to do with: .. toctree::11:30
jennis   :maxdepth: 211:30
tristanbut I feel like a good starter would be a much less crowded main page with a "Choose your poison"11:30
tristanInstall, Use, Reference, Resources, Hacking seems like enough to me11:31
jennisok, we're nearly there :P11:31
tristanand the sidebar already has a lot of navigation capability should the user need it11:31
tristanjennis, I dont mind treating this separately but: Do you think we can change the "Core framework" to use a toctree as well ?11:32
tristanjennis, same with Authoring projects -> Plugins11:34
jennistristan, I will have a look to see if that's possible, all the ToC stuff so far is calling in other .rst files but let's see11:37
tristanjennis, these are also other .rst files, they are generated and should be addressable somehow11:37
tristanjennis, maybe looking at the generated files they link to can help11:38
jennisright ok, I'll deal with this General documentation section first and then have a look11:38
tristanthe plugin ones, we generate quite manually in our makefile, the core reference documentation ones, we have sphinx-api-doc generate11:38
tristanjennis, lets handle that separately11:38
tristanI'd also like to remove the redundant "buildstream" section from there and manually structure our toctree11:39
jennisAgreed, this MR is beginning to get loaded with commits11:39
jennistristan, I'm not sure how smoothly artifacts.rst will fit in with installing / I don't personally think it should go there11:48
jennisI'd be more inclined to also have this in reference documentation11:49
jennisDo you agree?11:50
tristanI understand the concern, but dont really agree11:50
tristanI'm a bit on the fence though11:51
tristanon the one hand, I feel that reference documentation should capture the detailed stuff about the format and the plugin API, and the architecture in general11:51
tristanand as such, how to install an artifact server should not fit into that scope11:52
jennisSo potentially an "Advanced options" within Installing?11:52
tristanon the other hand, installing an artifact server seems like it requires too much knowledge to fit into installing ?11:52
tristanI think it goes in Installing really11:53
tristanAnd we should call it an artifact server, not an artifact share11:53
tristanor an artifact cache11:53
tristanartifact cache is more general terminology I think, this is specifically a server11:53
tristanjennis, Advanced options I dont like, it makes things harder to find11:53
jennisok11:53
tristanjennis, rather, one thing is "Installing BuildStream", another thing is "Installing an artifact server"11:54
gitlab-br-botbuildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/41211:54
tristanjennis, eventually, there will also be "Installing a source mirroring service"11:54
tristanjennis, I dont expect to have an install story beyond those three11:54
gitlab-br-botbuildstream: merge request (ps-add-inspiration-projects->master: Fix typo, add inspiration projects) #415 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41511:54
tristanand have my own prejudices about docker, a necessary evil I guess11:55
jennisOk, so how about a main_install.rst file which has install_buildstream.rst install_artifact_server.rst etc...?11:55
tristansounds good to me11:55
gitlab-br-botbuildstream: merge request (ps-add-inspiration-projects->master: Fix typo, add inspiration projects) #415 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41512:36
gitlab-br-botbuildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #374 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/37412:41
*** aday has quit IRC12:48
*** aday has joined #buildstream12:49
*** Guest43667 is now known as ernestask[m]12:52
*** aday has quit IRC12:53
*** ernestask[m] is now known as Guest1196612:53
*** aday has joined #buildstream12:53
*** Guest11966 is now known as ernestask[m]12:57
gitlab-br-botbuildstream: merge request (ps-add-inspiration-projects->master: Fix typo, add inspiration projects) #415 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/41513:00
gitlab-br-botbuildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #374 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/37413:01
tristanjuergbi, I'm confused what is the 'tempdir' in a Loader object ?13:10
tristanin fact, it looks unused13:11
juergbitristan: it's only used for cleanup13:12
juergbineeded to keep subproject dirs alive13:12
tristanhmmm13:12
tristanjuergbi, ok so, one loader creates a tempdir for it's subproject, which is effectively the project checkout dir... and feeds it into that loader, giving the subproject loader the responsibility of removing it's own checkout dir ?13:14
juergbiyes13:14
tristanjuergbi, so we could essentially change this to have the loader keep a list of tempdirs it created to remove at cleanup time ?13:14
tristanI wont do that just yet... but find it an odd thing to do :)13:15
juergbiwe could clean everything up in the toplevel Loader but it doesn't sound cleaner to me13:15
juergbias you'd have to pass it up to the toplevel13:15
tristannot the toplevel loader13:15
juergbiah, the parent13:15
tristanthe loader which launched a subproject, right13:15
juergbiyes, would be possible13:16
tristanthe one which creates the resource, releases it13:16
juergbibut as the lifetime of the tempdir is bound by the Loader, it made sense to me to release them together13:16
juergbii.e., the parent gifts the directgory13:16
juergbi*directory13:16
tristanyes13:16
tristanjuergbi, I'll keep it this way, I'm in the process of tearing the loader apart and adding docs13:17
tristanI think it's actually the last step of #28513:17
* tristan might rename it at most13:18
juergbitristan: btw: in https://gitlab.com/BuildStream/buildstream/merge_requests/290 (local junction optimization) things are slightly different as the subproject is no longer necessarily in a tempdir13:21
* juergbi never got around fixing that up13:22
tristanright, I'll leave that to you, I recall being okay with that as long as we keep it private13:26
*** mohan43u has quit IRC13:28
*** mohan43u has joined #buildstream13:28
jjardonsorry to bother with this again: fuse and findutils are needed from the host as well, rigth?13:32
tristanwhy findutils ?13:32
jjardonI'm not sure; it's being installed in the docker image13:32
tristanfuse is required yes13:32
jjardonok, I will take a closer look why findutils is being installed13:33
tristanjjardon, maybe because we like to call `find` sometimes in the .gitlab-ci.yml ?13:33
tristanI think that's typical, to ensure we can debug CI13:33
jjardonIt migth; I will move it to the correct section at https://gitlab.com/BuildStream/buildstream-docker-images/blob/master/fedora/prepare.sh to keep thing tody13:35
jjardontristan: probably same with which and quilt ?13:35
tristanjjardon, quilt I think is for a specific bst-external plugin13:36
tristanhttp://buildstream.gitlab.io/bst-external/sources/quilt.html#module-sources.quilt13:37
tristanjjardon, I presume the bst-external maintainers are also using the same images :)13:37
* tristan makes a vague statement that that project must have maintainers...13:37
jjardontristan: maybe they though about that; but there CI at all there at the moment13:38
jjardonthere is not*13:38
tristanyup I guess not, so I guess it is a work in progress13:38
gitlab-br-botbuildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38313:38
tristanjjardon, I think we also need to make buildstream testing utilities public API for downstream plugins to use13:39
tristanwhich is also a work in progress13:39
tlaterIsn't which used to figure out where host tools are in bst utils?13:40
jjardonoh! we have a docker input plugin as well! I guess we depend on docker in that case? or are we using something fancy like skopeo ?13:41
tlaterjjardon: ssssam[m] wrote something fancy in that plugin that just parses the docker image for us.13:42
tlaterI don't think it has external dependencies13:42
jjardonrigth13:42
tristanUmmm, I doubt which is used, we use python's find program in path thingy13:44
tristanshutils.which() shouldnt call out to host which, no.13:44
tristanshutil.which() rather13:44
tlaterOh, nevermind then, I thought I recalled a call to `which` somewhere13:45
tlaterMight have confused it with shutil.which()13:45
gitlab-br-botbuildstream: merge request (jmac/artifact-receive-profiling->master: WIP: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38313:46
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40613:48
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40613:52
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40613:53
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40613:54
tristanWhoa13:55
tristanjuergbi, the Loader code is actually starting to be workable13:55
gitlab-br-botbuildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/40613:55
* tristan is awestruck13:55
*** tristan has quit IRC14:00
*** tristan has joined #buildstream14:05
laurencejuergbi, in your proposal for remote execution last week, where it says 'Support for LRU cache expiration is possible on the server as we can track artifact downloads' underneath the phase 'CAS Artifact Cache' - does this mean our work on local and remote expiration will eventually be redundant?14:13
tristantlater, right, so regarding architecture for LRU expiry...14:14
laurenceTalking specifically about https://gitlab.com/BuildStream/buildstream/issues/136 and https://gitlab.com/BuildStream/buildstream/issues/13514:14
tristantlater, if we take the approach of ballooning a bit and running cleanup batch jobs... we'd want a way to launch a Job at the end of a Queue operation14:15
tristansimilar to how we do event notifications...14:15
tristantlater, That would have to assess whether it's necessary to launch the Job14:15
tristanAlso, in this case, contrary to how event notifications would work, we'd probably want to ensure exclusivity of cleanup tasks14:16
gitlab-br-botbuildstream: merge request (jmac/artifact-receive-profiling->master: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38314:16
tristantlater, and maybe we'd want to delay launching further pull/build jobs if a cleanup task is currently running14:16
juergbilaurence: no, it will still be needed and we should be able to reuse the current work with CAS (some small adaptations may be required but nothing structural)14:16
tlaterBy exclusivity you mean only run one cleanup job?14:17
tristanexactly14:17
tristanat a time14:17
laurencejuergbi, understood, thanks.14:17
juergbilaurence: however, for expiration on the remote server the long term goal was always to move from the minimal implementation we're working on right now to something that is LRU based on downloads14:17
juergbilaurence: and CAS makes this easier14:17
tristantlater, ideally, the main process does very little work, which means it would be desirable that it does not have to interrogate the artifact cache for size14:18
tlaterI'm not sure that last bit is possible14:18
tlaterHowever it's possible to minimize the number of times we actually calculate the size14:18
laurencejuergbi, i wonder how this affects the work jennis is currently doing then (remote cache LRU) - would it make sense to wait until CAS is complete?14:19
juergbitlater: I think we should aim for tracking the size without constantly recalculating it14:19
tlaterYep14:19
tlaterCalculate once, make sure we know how much data we removed14:19
tristantlater, in that case, that operation should be guaranteed by artifact caches to be atomically readable from the disk14:19
tristanright, I'll leave you to that part14:20
tlaterYep, I understand14:20
tristantlater, also, it's important of course, that if we have an auxiliary task running, it does block termination of the scheduler14:20
tristanthat would seem a no brainer, but may currently be tied to "queues"14:20
juergbilaurence: the main part of the work should stay the same even with LRU. LRU support could just mean updating the timestamp of the artifact reference on download and reuse the rest14:21
tlatertristan: Yep, have had a bit of a struggle with that14:21
tristantlater, so for sure we want to reuse Job to the max, but it's also currently tied to Elements, inasmuch as it needs the element to provide a log file and such14:21
tristantlater, that part will have to be refactored so that a Job is Element agnostic14:22
juergbilaurence: and as the structure of OSTree and CAS is very similar, I expect that the work can mostly be reused. we have to shuffle things around a bit but I don't think we should suspend this14:22
juergbitristan, tlater: are we sure that reusing Job really makes sense? I mean, wouldn't it be easier to just fork off a maintenance task that is woken up when needed?14:23
juergbiI mean, fork off early on and then keep it around sleeping14:23
tristanjuergbi, there is a *lot* of work that Job does14:24
tristanjuergbi, and I'm currently *very* uncomfortable with the way we arbitrarily fork OSTree working jobs in early init without going through Job14:24
laurencejuergbi, also very helpful, thanks again.14:24
tristanjuergbi, it needs to do logging, it needs to have the try/except/finally blocks, it needs to report BUG messages for stack traces which might occur in this process14:25
juergbihm,r ight, with logging and everything14:25
tlaterotoh, I think that doing the cleanup in jobs is going to make it a bit slower than if we had a separate worker14:25
juergbiprobably indeed makes sense14:25
tlaterWith a separate worker we could wait to send of a batch of deletion jobs at once14:25
* tlater is a bit concerned about the efficiency of ostree.prune()14:26
juergbicouldn't we batch this also with Job?14:26
tristantlater, we should be able to batch this with a Job as well14:26
tristanthat's what I sort of expected14:26
tlaterHm, you're right, we'd just need to keep some state around14:26
tristan"Go delete the least useful 10 artifacts please", or similar14:26
juergbiI definitely expect ostree.prune() to be slow (although Linux's aggressive dentry cache can save us)14:26
tristanor "Go free up 1GB of disk space"14:27
juergbiit actually has to traverse all tree objects, right?14:27
tristannot sure how you intend to group deletions14:27
tlaterYeah, that's sort of what I'm thinking, that would be in assessing whether the cleanup is necessary14:27
juergbiso I expect this indeed to be very slow14:27
tristantlater, this can be done with a threshold for the balooning14:27
juergbiI would suggest to have different size thresholds14:28
juergbiright :)14:28
gitlab-br-botbuildstream: merge request (jmac/artifact-receive-profiling->master: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38314:28
tlaterYup, that's where I was going to go originally, just forgot that jobs can do something on the main thread :)14:28
juergbitrigger deletion when you're over the upper threshold14:28
*** Prince781 has joined #buildstream14:28
juergbiand deletion brings size down to the lower threshold14:28
tristanright, but you probably want a median14:29
tristani.e. lets say there are 3 values14:29
tristanthe quota that we dont want to bust14:29
tristanthe threshold where we want to bring the quota down to14:29
tristanand the value in between14:29
tristanThe value in between is where you launch the cleanup job14:29
tristanto bring it down to the threshold14:30
tristanThe quota is where you start refusing to launch new Pull or Build jobs14:30
tristanotherwise you have Pull and Build jobs waiting on a long running cleanup, which sucks14:30
juergbiyep14:30
gitlab-br-botbuildstream: merge request (jmac/artifact-receive-profiling->master: Add artifact cache receive profiling domain and instructions.) #383 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38314:31
* tristan expects this to be one of the more fun things tlater gets to do on BuildStream :)14:33
tlaterIt sounds pretty fun :)14:33
*** Prince781 has quit IRC14:34
tlatertristan: What happens if we want both an event hook and a cleanup job to run?14:35
tlaterDo we start scheduling auxiliary tasks? x)14:35
tristanThat would be a different brand14:35
*** Prince781 has joined #buildstream14:35
tristantlater, dont worry about event hooks too much, I presume that you may end up with a Job, and an ElementJob and a CleanupJob, or suchlike14:36
tristanwhich will have different properties14:36
tristantlater, for event tasks, they are not mutually exclusive14:36
tristantlater, I expect to have a configurable timeout for killing them14:36
tristanand launch them unconditionally14:36
tlaterJust thinking about whether I can set a nice interface to launch auxiliary tasks, but I guess that can be added when we get to events14:37
tristananyway, I'm sure that even if you dont give it much thought, it will still be a good refactor towards event hook launching14:37
tristanyeah you have other plumbing to do14:38
tlaterWell, it does beat anything I've managed to come up with14:39
tlaterI'm sure "man, I wish I could just launch a job after my job!" crossed my mind at some point, too. Stupid tunnel vision.14:40
tlaterTa for the help tristan/juergbi, this should get me somewhere :)14:42
tristangah14:46
tristancs_shadow, https://gitlab.com/bloomberg/bst/buildstream/pipelines/2063813714:46
tristancs_shadow, I was wondering why it wasnt showing up in https://gitlab.com/BuildStream/buildstream/pipelines?scope=all&page=1... it's taking *forever*14:47
tristanMaybe it would be better to push merge requests directly to upstream ?14:47
tristanI think we might have more efficient runners14:47
cs_shadowoh! is it the shared workers that are responsible for the slowness?14:48
*** valentind has quit IRC14:48
cs_shadowI can re-create the MR from a branch on buildstream/buildstream if you'd prefer that14:49
tristanI ... would ask jjardon before coming to any conclusion... but I would suspect so14:49
tristancs_shadow, sure... and add a NEWS entry !14:49
tristanI was going to just add one cause I thought... it'll merge soon and I dont want to trigger another run of CI for that ;-S14:49
jjardoncs_shadow: buildstreamer runners are faster that the ones gitlab.com offers for free14:50
cs_shadowtristan: sure, let me start a new MR. Hopefully I'll be faster than the current CI :)14:50
tristanbut at this point, I think I'm going to merge one refactor ahead of you, which I'm sure wont cause a conflict14:50
gitlab-br-botbuildstream: merge request (tristan/loader-private-refactor->master: Loader private refactor) #416 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41614:51
*** valentind has joined #buildstream14:52
tristangah14:55
tristanOne more to go14:55
tristantlater, you are gonna hate me haha14:55
tlaterOh boy, what's it going to be this time?14:56
tlaterx)14:56
tristantlater, tomorrow, you will receive a gift from me: it will be a huge merge conflict in _scheduler/14:56
tristanand it will be *the last* part of my quest to address #28514:56
tlaterAh, nice14:56
gitlab-br-botbuildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #417 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41714:57
tristanwhich has included a vast number of tiny fixes, removals of unused members, and additions of API documentation comments for non-public API14:57
cs_shadowtristan: I've created https://gitlab.com/BuildStream/buildstream/merge_requests/417 with the NEWS entry. Are you okay if I close https://gitlab.com/BuildStream/buildstream/merge_requests/374?14:58
tristancs_shadow, yep, just say "Closed in favor of !417" for traceability15:00
gitlab-br-botbuildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #374 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/37415:01
gitlab-br-botbuildstream: merge request (tristan/loader-private-refactor->master: Loader private refactor) #416 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41615:02
cs_shadowdone. Presumably GitLab won't try to auto-merge a closed MR :)15:03
tristanheh, that would be a funny bug indeed15:04
gitlab-br-botbuildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #417 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41715:04
tristanlucky jmac, he's got all the runners15:05
* tristan thinks we should call them walkers instead, until they are faster15:06
jmacI can probably cancel several jobs15:07
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41015:08
*** valentind has left #buildstream15:08
jmacNope, those are all valid15:08
tristanjmac, you've only got one15:08
tristanyeah :)15:08
*** valentind has joined #buildstream15:08
jmacI'd like it if I could manually trigger test jobs instead of it happening automatically on push15:08
jennistristan, hi, would you be able to look over !410 again please?15:09
jmacDoing a full retest for a whitespace change is wasteful15:09
tristanjennis, uhhhh15:09
tristanjennis, it's now midnight and I wanna eat and be lazy for a while15:09
tristanjennis, I probably wont be able to resist the temptation to look it over, but it may not happen for a bit15:10
tristanlemme give it a quick look before I walk to the fried chicken farm...15:10
tlaterThere's a fried chicken farm in SK?15:12
* tlater imagines fried chicken walking around15:12
tristanyes, it's more efficient to grow them pre-fried :)15:13
tristanthey live in a sort of bbq sause sty15:13
tristansauce15:13
tlaterYeah, I guess if you fry them when they're still small it takes less energy15:13
tristanand roll around like pigs, so they are properly marinated when you bring them home15:13
tristansome of them have breaded skin too, delicious little chickens...15:14
tristanjennis, I think that one is a WINNER !15:14
tristanding ding ding15:14
jennis:)15:14
tristanwanna race me with your walker ?15:14
tristanjennis, I'll unset WIP and we can see which walker gets there first :)15:15
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41015:15
tristanah, you lose I think15:15
tristanyou need a rebase15:15
tlaterAww15:16
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41015:17
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41015:17
tristanaaand we're off ! https://gitlab.com/BuildStream/buildstream/pipelines?scope=all&page=115:20
* tristan envisions a race of walkers... after having finished season 8 of the walking dead15:21
tristanyou could still win, my walker is nervous: https://gitlab.com/BuildStream/buildstream/pipelines/2064587615:22
jjardonnice job jennis !15:25
jennisthanks15:33
jennistristan, sorry I was in a meeting, will rebase now15:33
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41015:36
laurenceyes, sterling work, jennis !15:37
gitlab-br-botbuildstream: merge request (richardmaw/key-summary->master: WIP: List resolved element keys in job summary) #389 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38915:38
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41015:43
*** toscalix has quit IRC15:46
tristanI won \o/15:51
tristanjennis, I had rebased for you, but you lost15:51
jennistristan, aha, I squashed some case changes into another commit and repushed15:52
jennislooks like the pipeline is pending15:52
tristanwhoa... gitlab is being weird15:52
tristanhttps://gitlab.com/BuildStream/buildstream/pipelines/2064587615:52
tristanit's complete... but stiiiiill walking15:52
gitlab-br-botbuildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #417 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/41715:53
tristanAha!15:54
tristancs_shadow, wins !15:54
tristanand even though my walker had reached the finish line, he still took it from me !15:54
gitlab-br-botbuildstream: merge request (tristan/loader-private-refactor->master: Loader private refactor) #416 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41615:55
tristanjennis, time for another race...15:55
jennis:p15:55
jennisLooks like you've got a headstart15:55
tristanyou are taking longer to merge !15:56
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41015:56
tristanthat aint my fault15:56
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41015:56
tristanoh, I had already rebased you in the UI15:58
jennishahaa15:58
jennisagain15:58
tristanjennis, I didnt mean to be unfair :)15:58
jennisyou're deliberately stalling me15:58
tristanI mean, I rebased them both at the same time15:58
tristanyours took longer to rebase, I presume you force pushed a rebase and that retriggered ?15:58
jennisindeed15:58
tristanhttps://gitlab.com/BuildStream/buildstream/pipelines/20650253 (mine) https://gitlab.com/BuildStream/buildstream/pipelines/20650338 (yours)15:59
tristanjennis, you are ahead of me !15:59
tristanhaha15:59
jennislol16:00
*** Prince781 has quit IRC16:06
gitlab-br-botbuildstream: merge request (documentation-formatting-in-HACKING->master: Documentation formatting in hacking) #411 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41116:07
tristantlater, the secret is to hatch a fried egg :)16:10
gitlab-br-botbuildstream: issue #365 ("gir1-ostree version is wrong on Debian stable") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/36516:11
jennisoh they're off again16:15
tristanI'm in the lead16:16
* jennis see's a cancel running button16:16
tristanhaha16:17
gitlab-br-botbuildstream: issue #365 ("gir1-ostree version is wrong on Debian stable") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/36516:20
*** Prince781 has joined #buildstream16:30
gitlab-br-botbuildstream: merge request (tristan/loader-private-refactor->master: Loader private refactor) #416 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/41616:32
jennis:O16:32
jennishttp://www.nooooooooooooooo.com/16:32
gitlab-br-botbuildstream: merge request (richardmaw/key-summary->master: WIP: List resolved element keys in job summary) #389 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38916:50
gitlab-br-botbuildstream: issue #365 ("gir1-ostree version is wrong on Debian stable") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/36516:51
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41016:52
gitlab-br-botbuildstream: merge request (richardmaw/key-summary->master: WIP: List resolved element keys in job summary) #389 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38916:53
gitlab-br-botbuildstream: merge request (richardmaw/key-summary->master: List resolved element keys in job summary) #389 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/38916:53
*** jonathanmaw has quit IRC17:00
gitlab-br-botbuildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/41017:07
*** noisecell has quit IRC17:12
gitlab-br-botbuildstream: merge request (getting-started-section->master: WIP: Getting started section) #418 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/41817:20
*** bethw has quit IRC17:21
*** Prince781 has quit IRC19:16
*** tristan has quit IRC20:37
*** Prince781 has joined #buildstream20:38
*** Prince781 has quit IRC21:14
*** aday has quit IRC22:05
*** slaf has quit IRC22:24
*** slaf has joined #buildstream22:25
*** slaf has joined #buildstream22:26

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