*** inigomartinez has quit IRC | 00:07 | |
*** ptomato[m] has quit IRC | 00:07 | |
*** rafaelff[m] has quit IRC | 00:08 | |
*** ernestask[m] has quit IRC | 00:08 | |
*** cgmcintyre[m] has quit IRC | 00:08 | |
*** mattiasb has quit IRC | 00:08 | |
*** waltervargas[m] has quit IRC | 00:08 | |
*** connorshea[m] has quit IRC | 00:08 | |
*** pro[m] has quit IRC | 00:08 | |
*** asingh_[m] has quit IRC | 00:08 | |
*** segfault3[m] has quit IRC | 00:08 | |
*** awacheux[m] has quit IRC | 00:08 | |
*** bochecha has quit IRC | 00:08 | |
*** theawless[m] has quit IRC | 00:08 | |
*** abderrahim[m] has quit IRC | 00:08 | |
*** kailueke[m] has quit IRC | 00:08 | |
*** ssssam[m] has quit IRC | 00:08 | |
*** m_22[m] has quit IRC | 00:08 | |
*** alatiera has quit IRC | 00:08 | |
*** jjardon[m] has quit IRC | 00:08 | |
*** inigomartinez has joined #buildstream | 00:10 | |
gitlab-br-bot | buildstream: issue #363 ("Allow modifying elements with unversioned config file") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/363 | 00:20 |
---|---|---|
*** ptomato[m] has joined #buildstream | 01:04 | |
*** Prince781 has joined #buildstream | 01:20 | |
*** mattiasb has joined #buildstream | 02:23 | |
*** Prince781 has quit IRC | 02:29 | |
*** ernestask[m] has joined #buildstream | 02:37 | |
*** ernestask[m] is now known as Guest43667 | 02:38 | |
*** connorshea[m] has joined #buildstream | 03:03 | |
*** waltervargas[m] has joined #buildstream | 03:05 | |
*** rafaelff[m] has joined #buildstream | 03:23 | |
*** solid_black_ has quit IRC | 04:03 | |
*** kailueke[m] has joined #buildstream | 04:04 | |
*** awacheux[m] has joined #buildstream | 04:33 | |
*** tristan has quit IRC | 05:50 | |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 05:51 |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 05:55 |
*** bochecha has joined #buildstream | 05:58 | |
*** abderrahim[m] has joined #buildstream | 05:58 | |
*** ssssam[m] has joined #buildstream | 06:06 | |
*** alatiera has joined #buildstream | 06:07 | |
jjardon | Hi, 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 #buildstream | 06:16 | |
gitlab-br-bot | buildstream: merge request (jjardon/build_badge->master: README.rst: Add pipeline status badge) #407 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/407 | 06:23 |
*** asingh_[m] has joined #buildstream | 06:32 | |
*** cgmcintyre[m] has joined #buildstream | 06:42 | |
gitlab-br-bot | buildstream: merge request (jjardon/build_badge->master: README.rst: Add pipeline status badge) #407 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/407 | 06:45 |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 06:45 |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 06:46 |
tristan | juergbi, I think I misunderstood #182 which you reopened | 06:53 |
tristan | juergbi, this is about closing a workspace which does not exist... in the workspaces file even ? | 06:54 |
tristan | and the ordering of messages | 06:54 |
juergbi | yes | 06:54 |
juergbi | you originally filed the issue ;) | 06:54 |
tristan | Easy to fix, indeed | 06:54 |
tristan | I looked into testing interactive mode but still didnt find much useful :-( | 06:55 |
tristan | I found some pytest things which run a test with some "input", but we need more than that | 06:55 |
tristan | we need sessions, and wait for being prompted something... and then answering... etc... so we probably need to implement that ourselves | 06:56 |
juergbi | we probably need to fork and handle I/O from there | 06:56 |
juergbi | don't know whether there is something in the pytest ecosystem | 06:57 |
tristan | We can pretty easily cheat the app into pretending it's interactive mode without a real tty | 06:57 |
gitlab-br-bot | buildstream: 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/405 | 06:57 |
tristan | but yeah, we probably need some fork | 06:57 |
tristan | and that probably makes things also complicated for coverage report collection | 06:58 |
*** theawless[m] has joined #buildstream | 07:02 | |
*** jjardon[m] has joined #buildstream | 07:08 | |
juergbi | if we use the fork for the emulated user and keep bst itself in the parent, coverage should be fine | 07:10 |
gitlab-br-bot | buildstream: issue #364 ("bst workspace open --force doesnt work") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/364 | 07:11 |
gitlab-br-bot | buildstream: merge request (tristan/workspace-cli-fixes->master: Some fixes for the workspace CLI) #408 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/408 | 07:12 |
tristan | juergbi, Ah good point | 07:12 |
tristan | interesting | 07:12 |
tristan | well... that's more than a days work... hehe | 07:13 |
tristan | eh, I'll make !408 a bit better first... | 07:21 |
*** solid_black_ has joined #buildstream | 07:22 | |
gitlab-br-bot | buildstream: merge request (tristan/workspace-cli-fixes->master: Some fixes for the workspace CLI) #408 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/408 | 07:25 |
*** solid_black_ has quit IRC | 07:25 | |
*** solid_black_ has joined #buildstream | 07:25 | |
*** solid_black_ has quit IRC | 07:29 | |
gitlab-br-bot | buildstream: issue #182 ("Closing non-existing workspace") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/182 | 07:37 |
gitlab-br-bot | buildstream: issue #182 ("Closing non-existing workspace") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/182 | 07:37 |
gitlab-br-bot | buildstream: merge request (tristan/workspace-cli-fixes->master: Some fixes for the workspace CLI) #408 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/408 | 07:37 |
*** pro[m] has joined #buildstream | 07:39 | |
*** segfault3[m] has joined #buildstream | 07:47 | |
gitlab-br-bot | buildstream: 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/403 | 07:50 |
paulsherwood | /win/win 12 | 07:52 |
paulsherwood | eek | 07:52 |
*** tristan has quit IRC | 07:54 | |
*** tristan has joined #buildstream | 07:59 | |
*** jennis has quit IRC | 08:00 | |
*** toscalix has joined #buildstream | 08:03 | |
*** jennis has joined #buildstream | 08:04 | |
*** m_22[m] has joined #buildstream | 08:05 | |
gitlab-br-bot | buildstream: merge request (tristan/fix-workspace-force-open->master: Fix force openening of workspaces) #409 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/409 | 08:11 |
tristan | juergbi, any thoughts on 409 ? | 08:16 |
tristan | juergbi, 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 directory | 08:16 |
tristan | anything that could go wildly wrong with that you think ? | 08:17 |
juergbi | assuming link_files properly handles overwriting, I can't think of an issue right now | 08:18 |
juergbi | it should already handle symlinks etc | 08:19 |
juergbi | not deleting existing files could produce some odd behavior with certain sources | 08:20 |
juergbi | essentially merging two .git directories is pretty odd | 08:20 |
juergbi | but I can't think of anything that would actually break like that | 08:20 |
juergbi | that said, I generally prefer replacing the whole workspace instead of some odd merge | 08:21 |
juergbi | which is what we already support via reset, afaict | 08:21 |
gitlab-br-bot | buildstream: 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/403 | 08:21 |
juergbi | what's the use case of merge (open --force) compared to reset? | 08:22 |
juergbi | incremental build will anyway no longer work | 08:22 |
tristan | bst workspace reset requires an already existing workspace, and it will delete files that you might have lying around | 08:24 |
paulsherwood | tristan: 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 |
paulsherwood | in particular i think https://blogs.gnome.org/tvb/files/2017/01/build-bootstrap-cropped-1.png would be a useful addition | 08:24 |
tristan | paulsherwood, sure ! I think with jjardon's patch which integrates it both in the README.rst and also in the documentation it will be nice | 08:25 |
tristan | I'm going to fix a small typo in there | 08:25 |
tristan | "BuildStream is an Free Software tool..." s/an/a | 08:25 |
*** noisecell has joined #buildstream | 08:25 | |
paulsherwood | eek :) | 08:25 |
tristan | eh, I'd rather just fix it than play ping pong in merge requests | 08:26 |
paulsherwood | tristan: let me fix that, with some further tweaks | 08:26 |
tristan | alright then | 08:26 |
tristan | paulsherwood, also, can I ask you to fix it to be more consistent with our other documentation .rst files ? | 08:27 |
tristan | essentially... A.) No empty line after a title line ----------- or ============== | 08:27 |
tristan | B.) Two empty lines before any title line | 08:27 |
tristan | having it all the same way just makes editing the rst files more comfortable | 08:28 |
tristan | juergbi, 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 option | 08:30 |
juergbi | tristan: 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 case | 08:30 |
tristan | juergbi, i.e. if removing API was a discussion we could have, then we'd have a different discussion right ? | 08:30 |
juergbi | right, just thought I'd mention it ;) | 08:30 |
tristan | Yeah, I sort of agree that it's not the most desirable option to have, but hindsight is 20/20 :) | 08:31 |
gitlab-br-bot | buildstream: merge request (tristan/fix-workspace-force-open->master: Fix force openening of workspaces) #409 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/409 | 08:32 |
tristan | paulsherwood, if we add pngs, I'd rather look at more recent slides, say from FOSDEM | 08:33 |
tristan | paulsherwood, the original pngs you linked to are very old, and I tidied these up to represent things closer to what we implemented | 08:34 |
* tristan looks for more recent libreoffice files | 08:36 | |
tlater | jjardon: 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-bot | buildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 08:39 |
tristan | hmmmm, old images and .odg files are hard to find :-S | 08:44 |
jjardon | tlater: yeah, let's open a MR and merge it? | 08:44 |
jjardon | It's actually quite handy example and I didn't know that it exists | 08:45 |
*** jonathanmaw has joined #buildstream | 08:45 | |
jjardon | and now is part of the README so I think it makes sense | 08:45 |
tristan | paulsherwood, I have the original .odg file for the png you linked though, if you'd like to be able to edit it | 08:46 |
tlater | jjardon: I thought I had an MR open already... Well, I opened one :) | 08:46 |
gitlab-br-bot | buildstream: issue #364 ("bst workspace open --force doesnt work") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/364 | 08:46 |
gitlab-br-bot | buildstream: issue #364 ("bst workspace open --force doesnt work") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/364 | 08:46 |
gitlab-br-bot | buildstream: merge request (tristan/fix-workspace-force-open->master: Fix force openening of workspaces) #409 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/409 | 08:46 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 08:47 |
tristan | paulsherwood, 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 future | 08:49 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 08:51 |
jjardon | tlater: thanks; ok to change the license to something more permissive? https://gitlab.com/BuildStream/buildstream-examples/merge_requests/3 | 08:54 |
gitlab-br-bot | buildstream: merge request (documentation-formatting-in-HACKING->master: Documentation formatting in hacking) #411 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/411 | 08:55 |
gitlab-br-bot | buildstream: merge request (documentation-formatting-in-HACKING->master: Documentation formatting in hacking) #411 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/411 | 08:57 |
*** bethw has joined #buildstream | 08:58 | |
gitlab-br-bot | buildstream: merge request (documentation-formatting-in-HACKING->master: Documentation formatting in hacking) #411 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/411 | 08:58 |
tlater | jjardon: Yep, that seems sensible | 08:59 |
jjardon | tlater: cheers | 09:00 |
gitlab-br-bot | buildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/412 | 09:12 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 09:16 |
gitlab-br-bot | buildstream: 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/413 | 09:18 |
gitlab-br-bot | buildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/412 | 09:20 |
gitlab-br-bot | buildstream: 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/413 | 09:20 |
*** bethw has quit IRC | 09:36 | |
gitlab-br-bot | buildstream: 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/413 | 09:41 |
gitlab-br-bot | buildstream: 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/413 | 09:43 |
paulsherwood | tristan: i'll take a shot at the diagram | 09:43 |
tristan | thanks ! | 09:43 |
tristan | paulsherwood, I think I detailed the changes pretty well in the comments, it's just a matter of changing some names, and doing an export / crop | 09:44 |
tristan | wish I had a more recent one handy | 09:44 |
jjardon | tristan: (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/353 | 09:52 |
gitlab-br-bot | buildstream: 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/414 | 09:56 |
tlater | jjardon: We also depend on bwrap for sandboxing and ostree for caching artifacts - not sure if those are relevant to the list | 10:01 |
tristan | I think those are not in the list because they are already documented ? | 10:04 |
tristan | tlater, also, it is a hard requirement | 10:04 |
jjardon | tlater: rigth, what about build systems? Do we depend on autotools / meson / qmake ...etc from the host? | 10:04 |
tristan | that list is about optional stuff... but we should add ssh to it because of artifact pushing | 10:04 |
tristan | jjardon, not at all | 10:05 |
tristan | never | 10:05 |
jjardon | ok, cool | 10:05 |
tristan | jjardon, only for Source plugins to obtain data | 10:05 |
jjardon | rigth | 10:05 |
tlater | Not depending on host build systems is sort of the point of buildstream :) | 10:05 |
jjardon | well, I didnt know that we depend for the Source plugins, so better to be sure | 10:06 |
tristan | tlater, you let juergbi steal all my fire ?? | 10:07 |
tristan | tlater, it's one of the points, though :D | 10:07 |
*** mohan43u has quit IRC | 10:09 | |
gitlab-br-bot | buildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/412 | 10:11 |
tristan | paulsherwood, https://gitlab.com/BuildStream/buildstream/tree/ps-add-diagram is a bit funny :) | 10:12 |
tristan | worth a giggle at least... it needs a downscale I think... I can only see a corner of the image in my browser :D | 10:12 |
paulsherwood | tristan: i downscaled before, you said "The image upscales horribly in my browser" | 10:14 |
tristan | paulsherwood, I mean, it should not be scaled at all... | 10:14 |
paulsherwood | i have not found a way to get gitlab to handle image scaling properly in RST | 10:14 |
tristan | probably have to find the rst invocation for telling it to not scale the image, but to center it instead | 10:14 |
tristan | hmmm | 10:14 |
tristan | I see :-S | 10:14 |
paulsherwood | the render is way larger than the original image | 10:15 |
* paulsherwood shakes fist at gitlab | 10:15 | |
tristan | paulsherwood, http://docutils.sourceforge.net/docs/ref/rst/directives.html#images | 10:16 |
tristan | did you find that ? | 10:16 |
*** mohan43u has joined #buildstream | 10:16 | |
tristan | looks like maybe :scale: 100% ... :align: center ... might do it ? | 10:16 |
paulsherwood | yes. gitlab seems to ignore them | 10:16 |
tristan | Hrrrrmmmm | 10:16 |
tristan | paulsherwood, maybe it's better to split this out then and only have it in the actual docs ? | 10:17 |
jjardon | tristan: paulsherwood are we sure we want to put that in the README, and not in https://buildstream.gitlab.io/buildstream/ ? | 10:17 |
tristan | jjardon, exactly what I was thinking... but I wouldn't have minded since you add the README.rst to the docs | 10:17 |
paulsherwood | jjardon: i'm aiming for the readme first, then the website :-) | 10:17 |
tristan | in a further MR which I havent merged yet | 10:17 |
tristan | paulsherwood, lets accept gitlab rst rendering limitations and do this part only in the actual docs I think | 10:18 |
gitlab-br-bot | buildstream: 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/405 | 10:19 |
tristan | I suppose this would be an introduction section or such which would include the README.rst, before the meat of the docs | 10:19 |
jjardon | paulsherwood: 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 site | 10:19 |
tristan | jjardon, I'm quite sure it will work on the website, because sphinx will transform it into html | 10:20 |
tristan | most probably way more capably than gitlab's rudimentary support for displaying a simple readme file | 10:20 |
jjardon | tristan: not that, not sure if the link to the image is going to work or not, let me try | 10:21 |
tristan | Ok | 10:21 |
tristan | jjardon, look at the existing rst files, I suppose the relative paths used in `.. literalinclude::` expressions are a good hint | 10:22 |
tristan | jjardon, for where to source the png from | 10:22 |
tristan | just grep that in doc/source and find examples of paths | 10:22 |
tlater | Doesn't gitlab allow just putting plain HTML tags in the file? You could try and force scaling it by creating literal HTML. | 10:23 |
tlater | I think they have a whitelist of allowed tags/attributes | 10:23 |
tlater | Might be confusing it with github though | 10:23 |
jmac | If you do that will it still work with Sphinx? | 10:24 |
paulsherwood | that may work. but once we're hacking to that extent, i'd ask why aren't we doing readme.md rather than rst | 10:24 |
tristan | tlater, I think that sucks... because we'll reuse the README.rst in the docs as an introduction as well | 10:24 |
paulsherwood | that answers my previous question :) | 10:24 |
gitlab-br-bot | buildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/412 | 10:27 |
jennis | tristan, to address your point on !410, we decided on having a "Commands" section under "Using BuildStream" that will be more wordy explanations | 10:28 |
paulsherwood | i can frab it with loads of whitespace on the right... but ewww | 10:28 |
jennis | Now, we already have the invoking buildstream, this should be under "Reference Documentation" right? | 10:29 |
gitlab-br-bot | buildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/412 | 10:34 |
tristan | jennis, right that part I always found ambiguous, we have to put Commands (Invoking BuildStream) in either one place or the other | 10:35 |
tristan | jennis, it either goes in the Reference, or in Using BuildStream | 10:35 |
tristan | I 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 plugins | 10:36 |
jennis | tristan, ok let's do that. And within the Getting Started / Examples we'll have more "wordy" explanations about some of the key commands | 10:37 |
tristan | jennis, is there some kind of confusion, is there a "Commands" _and_ and "Invoking BuildStream" ? I think they are two different names of the same thing | 10:37 |
tristan | Uhhhh | 10:37 |
jennis | So, atm we only have the invoking | 10:37 |
*** bethw has joined #buildstream | 10:37 | |
tristan | jennis, 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 |
jennis | right ok | 10:38 |
tristan | I.e. there is only *one thing*, it only needs to be enhanced so that we can add text to each command explaining stuff | 10:38 |
*** aday has joined #buildstream | 10:39 | |
jennis | So, lets just rename "Invoking BuildStream" to "BuildStream commands", keep it under "Using BuildStream" and flesh it out later? | 10:39 |
tristan | jennis, 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 |
jennis | yes that will come :) right now I just want to focus on having the structure look sensible | 10:40 |
tristan | jennis, lets call it Commands, under Using BuildStream | 10:40 |
tristan | and avoid too many BuildStream is BuildStream BuildStream BuildStream... | 10:40 |
jennis | tristan, ok agreed. I'll update !410 accordingly | 10:40 |
jennis | tristan, just to clarify, we want "User configuration" and "Authoring projects" under "Reference documentation"? | 10:45 |
tristan | jennis, User Configuration probably goes under Using BuildStream no ? | 10:45 |
* tristan consults the google doc | 10:45 | |
tristan | we didnt cover that | 10:46 |
tristan | jennis, lets put user configuration with using | 10:46 |
tristan | jennis, and hope to make that more human, entry level friendly over time | 10:46 |
tristan | actually yeah it seems already pretty user friendly, but could be improved and completed | 10:47 |
tristan | jennis, we might do some further changes to Authoring Projects, what it really is, is the terse complete reference documentation of the project format | 10:49 |
tristan | maybe we'll rename it and restructure within there too to bring it all together | 10: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 | |
jennis | tristan, ok :) I've do some more restructuring and update the MR | 10:50 |
jennis | i'll* | 10:50 |
tlater | It's hard to send out debug messages without having them overwritten by some pipeline message :| | 10:50 |
tristan | tlater, as long as you have a Context object | 10:50 |
tlater | Well, that interface wants a Message, which requires a plugin ID | 10:51 |
tristan | tlater, some classes create their own convenience _message() thing | 10:51 |
tlater | And as far as I can tell you can only give that an element's plugin ID? | 10:51 |
tristan | tlater, I wouldnt be averse to adding such a convenience at the Context level and removing the others | 10:51 |
tristan | tlater, no, I think it need not be specified | 10:52 |
tristan | tlater, see how Pipeline() implements it for instance | 10:52 |
tlater | Oh, I can set that to None? | 10:52 |
tlater | Ack | 10:52 |
tlater | o\ | 10:52 |
tristan | you can just not provide one | 10:52 |
tlater | ta tristan, if you set it to a garbage string buildstream complains, so I thought it was requried | 10:52 |
tristan | it will show up as one of those startup messages which dont display an element name | 10:52 |
tristan | or cache key | 10:52 |
* tlater thinks a convenience context function might be neat, but will hold off on creating one for now. | 10:54 | |
tristan | if 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 one | 10:54 |
tristan | (there are not many, though) | 10:55 |
* tlater would prefer to remove them | 10:55 | |
tristan | and then replace the calls with something like self.context.message(...) | 10:55 |
tristan | that works | 10:55 |
tlater | tristan: 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 messages | 10:56 |
tristan | (also helps clarify what voodoo a message() function is doing) | 10:56 |
tlater | I.e., have context.info, context.warn | 10:56 |
tristan | tlater, sure, it's all private API anyway | 10:56 |
tristan | I think it can just keep the **kwargs trick too so that wrappers are easy to do | 10:57 |
tristan | only the public API facing Plugin.info()... functions need explicit signatures | 10:57 |
tlater | tristan: 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-bot | buildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 11:08 |
tristan | tlater, if you can simplify it, do it ! | 11:10 |
tristan | tlater, I just took something that worked and repeated it ;-P | 11:10 |
tlater | Ah, heh, was just wondering whether I'm missing an intricacy of python here | 11:10 |
jennis | tristan, if you get a chance could you look at !410 please? | 11:11 |
tristan | jennis, I havent been keeping track but... have you been rebasing and squashing your branch into sensible commits ? | 11:13 |
tristan | jennis, looks like a lot of commits, but they may be justified... | 11:13 |
* tristan looks at changes | 11:13 | |
jennis | They are sensbile commits | 11:14 |
jennis | I'll have a look and see if any can be squashed | 11:14 |
tristan | jennis, no worry; I just wanted to ask you because I didnt want to go and tediously check them all myself | 11:16 |
tristan | jennis, 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 word | 11:17 |
tristan | which seems to be a big sweeping change you've effected | 11:17 |
tristan | I dont mind either way but consistency is important :) | 11:17 |
tristan | jennis, in the future, please remember to title your branches jennis/branch-name | 11:18 |
tristan | and the docs dont build | 11: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.rst | 11:19 |
jennis | tristan, yes consistency is important. I will update that MR accordingly | 11:20 |
jennis | tristan, and yes I will do that in the future | 11:20 |
tristan | jennis, I wanted to see the docs before saying anything... but they dont build | 11:20 |
tristan | were you able to build it locally ? | 11:20 |
jennis | yes | 11:20 |
tristan | strange | 11:21 |
jennis | I had that error and changed the anchor names appropriately | 11:21 |
jennis | I'll have another look | 11:21 |
tristan | maybe you didnt repush the branch | 11:21 |
tristan | or maybe there is a file which was supposed to be renamed but the source wasnt removed | 11:21 |
* tristan tries a git clean -xdf first | 11:22 | |
jennis | I think it's the latter | 11:22 |
tristan | jennis, looks like I had a stale file after pulling | 11:22 |
tristan | it builds now | 11:22 |
tristan | after git clean -xdff | 11:22 |
tristan | that is odd, though | 11:23 |
tristan | jennis, ok... "general documentation" needs to go | 11:23 |
jennis | Ok I wanted to speak to you about this | 11:24 |
tristan | Artifact Caches probably goes under Installing | 11:24 |
tristan | the other two are reference material, which dont fit into the documentation structure very well | 11:25 |
tristan | "Cache Keys" is basically, someone wanted it to be documented, and we accepted it, but it doesnt fit into anything anywhere | 11:25 |
jennis | Ok then, lets rename that to "Configuring an artifact cache" then? | 11:25 |
jennis | Yes tristan, hence why I made the general documentation section "describing some of BuildStream’s prominent features" | 11:26 |
jennis | but if you're opposed I'll put it back into reference documentation | 11:26 |
tristan | Right, so that sounds good to me | 11:26 |
tristan | Configuring an artifact cache | 11:26 |
tristan | Or | 11:27 |
tristan | jennis, maybe we should call it an "artifact share" ? | 11:27 |
tristan | Meh, we can call it a cache | 11:27 |
tristan | jennis, yes I am certainly opposed | 11:27 |
tristan | jennis, a big point of this exercise is to sort things out well, both of these reading materials are rather terse and involved | 11:28 |
tristan | I want to hide them away under reference documentation | 11:28 |
jennis | I see, ok I'll make the changes | 11:29 |
tristan | jennis, do you know how that ToC works ? it's all quite an enigma to me | 11:29 |
tristan | jennis, what I wonder is, can we stop showing the subitems in the toctree in index.rst, but not everywhere else ? | 11:29 |
jennis | tristan, I think that's easy to do | 11:29 |
tristan | maybe it's not that important... | 11:30 |
jennis | I suspect its to do with: .. toctree:: | 11:30 |
jennis | :maxdepth: 2 | 11:30 |
tristan | but I feel like a good starter would be a much less crowded main page with a "Choose your poison" | 11:30 |
tristan | Install, Use, Reference, Resources, Hacking seems like enough to me | 11:31 |
jennis | ok, we're nearly there :P | 11:31 |
tristan | and the sidebar already has a lot of navigation capability should the user need it | 11:31 |
tristan | jennis, I dont mind treating this separately but: Do you think we can change the "Core framework" to use a toctree as well ? | 11:32 |
tristan | jennis, same with Authoring projects -> Plugins | 11:34 |
jennis | tristan, 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 see | 11:37 |
tristan | jennis, these are also other .rst files, they are generated and should be addressable somehow | 11:37 |
tristan | jennis, maybe looking at the generated files they link to can help | 11:38 |
jennis | right ok, I'll deal with this General documentation section first and then have a look | 11:38 |
tristan | the plugin ones, we generate quite manually in our makefile, the core reference documentation ones, we have sphinx-api-doc generate | 11:38 |
tristan | jennis, lets handle that separately | 11:38 |
tristan | I'd also like to remove the redundant "buildstream" section from there and manually structure our toctree | 11:39 |
jennis | Agreed, this MR is beginning to get loaded with commits | 11:39 |
jennis | tristan, I'm not sure how smoothly artifacts.rst will fit in with installing / I don't personally think it should go there | 11:48 |
jennis | I'd be more inclined to also have this in reference documentation | 11:49 |
jennis | Do you agree? | 11:50 |
tristan | I understand the concern, but dont really agree | 11:50 |
tristan | I'm a bit on the fence though | 11:51 |
tristan | on the one hand, I feel that reference documentation should capture the detailed stuff about the format and the plugin API, and the architecture in general | 11:51 |
tristan | and as such, how to install an artifact server should not fit into that scope | 11:52 |
jennis | So potentially an "Advanced options" within Installing? | 11:52 |
tristan | on the other hand, installing an artifact server seems like it requires too much knowledge to fit into installing ? | 11:52 |
tristan | I think it goes in Installing really | 11:53 |
tristan | And we should call it an artifact server, not an artifact share | 11:53 |
tristan | or an artifact cache | 11:53 |
tristan | artifact cache is more general terminology I think, this is specifically a server | 11:53 |
tristan | jennis, Advanced options I dont like, it makes things harder to find | 11:53 |
jennis | ok | 11:53 |
tristan | jennis, rather, one thing is "Installing BuildStream", another thing is "Installing an artifact server" | 11:54 |
gitlab-br-bot | buildstream: merge request (ps-add-diagram->master: Fix typo, mention inspiration projects, add diagram) #412 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/412 | 11:54 |
tristan | jennis, eventually, there will also be "Installing a source mirroring service" | 11:54 |
tristan | jennis, I dont expect to have an install story beyond those three | 11:54 |
gitlab-br-bot | buildstream: merge request (ps-add-inspiration-projects->master: Fix typo, add inspiration projects) #415 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/415 | 11:54 |
tristan | and have my own prejudices about docker, a necessary evil I guess | 11:55 |
jennis | Ok, so how about a main_install.rst file which has install_buildstream.rst install_artifact_server.rst etc...? | 11:55 |
tristan | sounds good to me | 11:55 |
gitlab-br-bot | buildstream: merge request (ps-add-inspiration-projects->master: Fix typo, add inspiration projects) #415 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/415 | 12:36 |
gitlab-br-bot | buildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #374 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/374 | 12:41 |
*** aday has quit IRC | 12:48 | |
*** aday has joined #buildstream | 12:49 | |
*** Guest43667 is now known as ernestask[m] | 12:52 | |
*** aday has quit IRC | 12:53 | |
*** ernestask[m] is now known as Guest11966 | 12:53 | |
*** aday has joined #buildstream | 12:53 | |
*** Guest11966 is now known as ernestask[m] | 12:57 | |
gitlab-br-bot | buildstream: merge request (ps-add-inspiration-projects->master: Fix typo, add inspiration projects) #415 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/415 | 13:00 |
gitlab-br-bot | buildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #374 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/374 | 13:01 |
tristan | juergbi, I'm confused what is the 'tempdir' in a Loader object ? | 13:10 |
tristan | in fact, it looks unused | 13:11 |
juergbi | tristan: it's only used for cleanup | 13:12 |
juergbi | needed to keep subproject dirs alive | 13:12 |
tristan | hmmm | 13:12 |
tristan | juergbi, 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 |
juergbi | yes | 13:14 |
tristan | juergbi, so we could essentially change this to have the loader keep a list of tempdirs it created to remove at cleanup time ? | 13:14 |
tristan | I wont do that just yet... but find it an odd thing to do :) | 13:15 |
juergbi | we could clean everything up in the toplevel Loader but it doesn't sound cleaner to me | 13:15 |
juergbi | as you'd have to pass it up to the toplevel | 13:15 |
tristan | not the toplevel loader | 13:15 |
juergbi | ah, the parent | 13:15 |
tristan | the loader which launched a subproject, right | 13:15 |
juergbi | yes, would be possible | 13:16 |
tristan | the one which creates the resource, releases it | 13:16 |
juergbi | but as the lifetime of the tempdir is bound by the Loader, it made sense to me to release them together | 13:16 |
juergbi | i.e., the parent gifts the directgory | 13:16 |
juergbi | *directory | 13:16 |
tristan | yes | 13:16 |
tristan | juergbi, I'll keep it this way, I'm in the process of tearing the loader apart and adding docs | 13:17 |
tristan | I think it's actually the last step of #285 | 13:17 |
* tristan might rename it at most | 13:18 | |
juergbi | tristan: 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 tempdir | 13:21 |
* juergbi never got around fixing that up | 13:22 | |
tristan | right, I'll leave that to you, I recall being okay with that as long as we keep it private | 13:26 |
*** mohan43u has quit IRC | 13:28 | |
*** mohan43u has joined #buildstream | 13:28 | |
jjardon | sorry to bother with this again: fuse and findutils are needed from the host as well, rigth? | 13:32 |
tristan | why findutils ? | 13:32 |
jjardon | I'm not sure; it's being installed in the docker image | 13:32 |
tristan | fuse is required yes | 13:32 |
jjardon | ok, I will take a closer look why findutils is being installed | 13:33 |
tristan | jjardon, maybe because we like to call `find` sometimes in the .gitlab-ci.yml ? | 13:33 |
tristan | I think that's typical, to ensure we can debug CI | 13:33 |
jjardon | It 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 tody | 13:35 |
jjardon | tristan: probably same with which and quilt ? | 13:35 |
tristan | jjardon, quilt I think is for a specific bst-external plugin | 13:36 |
tristan | http://buildstream.gitlab.io/bst-external/sources/quilt.html#module-sources.quilt | 13:37 |
tristan | jjardon, 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 | |
jjardon | tristan: maybe they though about that; but there CI at all there at the moment | 13:38 |
jjardon | there is not* | 13:38 |
tristan | yup I guess not, so I guess it is a work in progress | 13:38 |
gitlab-br-bot | buildstream: 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/383 | 13:38 |
tristan | jjardon, I think we also need to make buildstream testing utilities public API for downstream plugins to use | 13:39 |
tristan | which is also a work in progress | 13:39 |
tlater | Isn't which used to figure out where host tools are in bst utils? | 13:40 |
jjardon | oh! 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 |
tlater | jjardon: ssssam[m] wrote something fancy in that plugin that just parses the docker image for us. | 13:42 |
tlater | I don't think it has external dependencies | 13:42 |
jjardon | rigth | 13:42 |
tristan | Ummm, I doubt which is used, we use python's find program in path thingy | 13:44 |
tristan | shutils.which() shouldnt call out to host which, no. | 13:44 |
tristan | shutil.which() rather | 13:44 |
tlater | Oh, nevermind then, I thought I recalled a call to `which` somewhere | 13:45 |
tlater | Might have confused it with shutil.which() | 13:45 |
gitlab-br-bot | buildstream: 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/383 | 13:46 |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 13:48 |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 13:52 |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 13:53 |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 13:54 |
tristan | Whoa | 13:55 |
tristan | juergbi, the Loader code is actually starting to be workable | 13:55 |
gitlab-br-bot | buildstream: merge request (jjardon/install_deps->master: Update install instructions) #406 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/406 | 13:55 |
* tristan is awestruck | 13:55 | |
*** tristan has quit IRC | 14:00 | |
*** tristan has joined #buildstream | 14:05 | |
laurence | juergbi, 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 |
tristan | tlater, right, so regarding architecture for LRU expiry... | 14:14 |
laurence | Talking specifically about https://gitlab.com/BuildStream/buildstream/issues/136 and https://gitlab.com/BuildStream/buildstream/issues/135 | 14:14 |
tristan | tlater, 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 operation | 14:15 |
tristan | similar to how we do event notifications... | 14:15 |
tristan | tlater, That would have to assess whether it's necessary to launch the Job | 14:15 |
tristan | Also, in this case, contrary to how event notifications would work, we'd probably want to ensure exclusivity of cleanup tasks | 14:16 |
gitlab-br-bot | buildstream: 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/383 | 14:16 |
tristan | tlater, and maybe we'd want to delay launching further pull/build jobs if a cleanup task is currently running | 14:16 |
juergbi | laurence: 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 |
tlater | By exclusivity you mean only run one cleanup job? | 14:17 |
tristan | exactly | 14:17 |
tristan | at a time | 14:17 |
laurence | juergbi, understood, thanks. | 14:17 |
juergbi | laurence: 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 downloads | 14:17 |
juergbi | laurence: and CAS makes this easier | 14:17 |
tristan | tlater, 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 size | 14:18 |
tlater | I'm not sure that last bit is possible | 14:18 |
tlater | However it's possible to minimize the number of times we actually calculate the size | 14:18 |
laurence | juergbi, 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 |
juergbi | tlater: I think we should aim for tracking the size without constantly recalculating it | 14:19 |
tlater | Yep | 14:19 |
tlater | Calculate once, make sure we know how much data we removed | 14:19 |
tristan | tlater, in that case, that operation should be guaranteed by artifact caches to be atomically readable from the disk | 14:19 |
tristan | right, I'll leave you to that part | 14:20 |
tlater | Yep, I understand | 14:20 |
tristan | tlater, also, it's important of course, that if we have an auxiliary task running, it does block termination of the scheduler | 14:20 |
tristan | that would seem a no brainer, but may currently be tied to "queues" | 14:20 |
juergbi | laurence: 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 rest | 14:21 |
tlater | tristan: Yep, have had a bit of a struggle with that | 14:21 |
tristan | tlater, 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 such | 14:21 |
tristan | tlater, that part will have to be refactored so that a Job is Element agnostic | 14:22 |
juergbi | laurence: 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 this | 14:22 |
juergbi | tristan, 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 |
juergbi | I mean, fork off early on and then keep it around sleeping | 14:23 |
tristan | juergbi, there is a *lot* of work that Job does | 14:24 |
tristan | juergbi, and I'm currently *very* uncomfortable with the way we arbitrarily fork OSTree working jobs in early init without going through Job | 14:24 |
laurence | juergbi, also very helpful, thanks again. | 14:24 |
tristan | juergbi, 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 process | 14:25 |
juergbi | hm,r ight, with logging and everything | 14:25 |
tlater | otoh, I think that doing the cleanup in jobs is going to make it a bit slower than if we had a separate worker | 14:25 |
juergbi | probably indeed makes sense | 14:25 |
tlater | With a separate worker we could wait to send of a batch of deletion jobs at once | 14:25 |
* tlater is a bit concerned about the efficiency of ostree.prune() | 14:26 | |
juergbi | couldn't we batch this also with Job? | 14:26 |
tristan | tlater, we should be able to batch this with a Job as well | 14:26 |
tristan | that's what I sort of expected | 14:26 |
tlater | Hm, you're right, we'd just need to keep some state around | 14:26 |
tristan | "Go delete the least useful 10 artifacts please", or similar | 14:26 |
juergbi | I definitely expect ostree.prune() to be slow (although Linux's aggressive dentry cache can save us) | 14:26 |
tristan | or "Go free up 1GB of disk space" | 14:27 |
juergbi | it actually has to traverse all tree objects, right? | 14:27 |
tristan | not sure how you intend to group deletions | 14:27 |
tlater | Yeah, that's sort of what I'm thinking, that would be in assessing whether the cleanup is necessary | 14:27 |
juergbi | so I expect this indeed to be very slow | 14:27 |
tristan | tlater, this can be done with a threshold for the balooning | 14:27 |
juergbi | I would suggest to have different size thresholds | 14:28 |
juergbi | right :) | 14:28 |
gitlab-br-bot | buildstream: 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/383 | 14:28 |
tlater | Yup, that's where I was going to go originally, just forgot that jobs can do something on the main thread :) | 14:28 |
juergbi | trigger deletion when you're over the upper threshold | 14:28 |
*** Prince781 has joined #buildstream | 14:28 | |
juergbi | and deletion brings size down to the lower threshold | 14:28 |
tristan | right, but you probably want a median | 14:29 |
tristan | i.e. lets say there are 3 values | 14:29 |
tristan | the quota that we dont want to bust | 14:29 |
tristan | the threshold where we want to bring the quota down to | 14:29 |
tristan | and the value in between | 14:29 |
tristan | The value in between is where you launch the cleanup job | 14:29 |
tristan | to bring it down to the threshold | 14:30 |
tristan | The quota is where you start refusing to launch new Pull or Build jobs | 14:30 |
tristan | otherwise you have Pull and Build jobs waiting on a long running cleanup, which sucks | 14:30 |
juergbi | yep | 14:30 |
gitlab-br-bot | buildstream: 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/383 | 14:31 |
* tristan expects this to be one of the more fun things tlater gets to do on BuildStream :) | 14:33 | |
tlater | It sounds pretty fun :) | 14:33 |
*** Prince781 has quit IRC | 14:34 | |
tlater | tristan: What happens if we want both an event hook and a cleanup job to run? | 14:35 |
tlater | Do we start scheduling auxiliary tasks? x) | 14:35 |
tristan | That would be a different brand | 14:35 |
*** Prince781 has joined #buildstream | 14:35 | |
tristan | tlater, dont worry about event hooks too much, I presume that you may end up with a Job, and an ElementJob and a CleanupJob, or suchlike | 14:36 |
tristan | which will have different properties | 14:36 |
tristan | tlater, for event tasks, they are not mutually exclusive | 14:36 |
tristan | tlater, I expect to have a configurable timeout for killing them | 14:36 |
tristan | and launch them unconditionally | 14:36 |
tlater | Just thinking about whether I can set a nice interface to launch auxiliary tasks, but I guess that can be added when we get to events | 14:37 |
tristan | anyway, I'm sure that even if you dont give it much thought, it will still be a good refactor towards event hook launching | 14:37 |
tristan | yeah you have other plumbing to do | 14:38 |
tlater | Well, it does beat anything I've managed to come up with | 14:39 |
tlater | I'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 |
tlater | Ta for the help tristan/juergbi, this should get me somewhere :) | 14:42 |
tristan | gah | 14:46 |
tristan | cs_shadow, https://gitlab.com/bloomberg/bst/buildstream/pipelines/20638137 | 14:46 |
tristan | cs_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 |
tristan | Maybe it would be better to push merge requests directly to upstream ? | 14:47 |
tristan | I think we might have more efficient runners | 14:47 |
cs_shadow | oh! is it the shared workers that are responsible for the slowness? | 14:48 |
*** valentind has quit IRC | 14:48 | |
cs_shadow | I can re-create the MR from a branch on buildstream/buildstream if you'd prefer that | 14:49 |
tristan | I ... would ask jjardon before coming to any conclusion... but I would suspect so | 14:49 |
tristan | cs_shadow, sure... and add a NEWS entry ! | 14:49 |
tristan | I 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 ;-S | 14:49 |
jjardon | cs_shadow: buildstreamer runners are faster that the ones gitlab.com offers for free | 14:50 |
cs_shadow | tristan: sure, let me start a new MR. Hopefully I'll be faster than the current CI :) | 14:50 |
tristan | but at this point, I think I'm going to merge one refactor ahead of you, which I'm sure wont cause a conflict | 14:50 |
gitlab-br-bot | buildstream: merge request (tristan/loader-private-refactor->master: Loader private refactor) #416 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/416 | 14:51 |
*** valentind has joined #buildstream | 14:52 | |
tristan | gah | 14:55 |
tristan | One more to go | 14:55 |
tristan | tlater, you are gonna hate me haha | 14:55 |
tlater | Oh boy, what's it going to be this time? | 14:56 |
tlater | x) | 14:56 |
tristan | tlater, tomorrow, you will receive a gift from me: it will be a huge merge conflict in _scheduler/ | 14:56 |
tristan | and it will be *the last* part of my quest to address #285 | 14:56 |
tlater | Ah, nice | 14:56 |
gitlab-br-bot | buildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #417 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/417 | 14:57 |
tristan | which has included a vast number of tiny fixes, removals of unused members, and additions of API documentation comments for non-public API | 14:57 |
cs_shadow | tristan: 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 |
tristan | cs_shadow, yep, just say "Closed in favor of !417" for traceability | 15:00 |
gitlab-br-bot | buildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #374 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/374 | 15:01 |
gitlab-br-bot | buildstream: merge request (tristan/loader-private-refactor->master: Loader private refactor) #416 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/416 | 15:02 |
cs_shadow | done. Presumably GitLab won't try to auto-merge a closed MR :) | 15:03 |
tristan | heh, that would be a funny bug indeed | 15:04 |
gitlab-br-bot | buildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #417 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/417 | 15:04 |
tristan | lucky jmac, he's got all the runners | 15:05 |
* tristan thinks we should call them walkers instead, until they are faster | 15:06 | |
jmac | I can probably cancel several jobs | 15:07 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: WIP: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 15:08 |
*** valentind has left #buildstream | 15:08 | |
jmac | Nope, those are all valid | 15:08 |
tristan | jmac, you've only got one | 15:08 |
tristan | yeah :) | 15:08 |
*** valentind has joined #buildstream | 15:08 | |
jmac | I'd like it if I could manually trigger test jobs instead of it happening automatically on push | 15:08 |
jennis | tristan, hi, would you be able to look over !410 again please? | 15:09 |
jmac | Doing a full retest for a whitespace change is wasteful | 15:09 |
tristan | jennis, uhhhh | 15:09 |
tristan | jennis, it's now midnight and I wanna eat and be lazy for a while | 15:09 |
tristan | jennis, I probably wont be able to resist the temptation to look it over, but it may not happen for a bit | 15:10 |
tristan | lemme give it a quick look before I walk to the fried chicken farm... | 15:10 |
tlater | There's a fried chicken farm in SK? | 15:12 |
* tlater imagines fried chicken walking around | 15:12 | |
tristan | yes, it's more efficient to grow them pre-fried :) | 15:13 |
tristan | they live in a sort of bbq sause sty | 15:13 |
tristan | sauce | 15:13 |
tlater | Yeah, I guess if you fry them when they're still small it takes less energy | 15:13 |
tristan | and roll around like pigs, so they are properly marinated when you bring them home | 15:13 |
tristan | some of them have breaded skin too, delicious little chickens... | 15:14 |
tristan | jennis, I think that one is a WINNER ! | 15:14 |
tristan | ding ding ding | 15:14 |
jennis | :) | 15:14 |
tristan | wanna race me with your walker ? | 15:14 |
tristan | jennis, I'll unset WIP and we can see which walker gets there first :) | 15:15 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 15:15 |
tristan | ah, you lose I think | 15:15 |
tristan | you need a rebase | 15:15 |
tlater | Aww | 15:16 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 15:17 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 15:17 |
tristan | aaand we're off ! https://gitlab.com/BuildStream/buildstream/pipelines?scope=all&page=1 | 15:20 |
* tristan envisions a race of walkers... after having finished season 8 of the walking dead | 15:21 | |
tristan | you could still win, my walker is nervous: https://gitlab.com/BuildStream/buildstream/pipelines/20645876 | 15:22 |
jjardon | nice job jennis ! | 15:25 |
jennis | thanks | 15:33 |
jennis | tristan, sorry I was in a meeting, will rebase now | 15:33 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 15:36 |
laurence | yes, sterling work, jennis ! | 15:37 |
gitlab-br-bot | buildstream: 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/389 | 15:38 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 15:43 |
*** toscalix has quit IRC | 15:46 | |
tristan | I won \o/ | 15:51 |
tristan | jennis, I had rebased for you, but you lost | 15:51 |
jennis | tristan, aha, I squashed some case changes into another commit and repushed | 15:52 |
jennis | looks like the pipeline is pending | 15:52 |
tristan | whoa... gitlab is being weird | 15:52 |
tristan | https://gitlab.com/BuildStream/buildstream/pipelines/20645876 | 15:52 |
tristan | it's complete... but stiiiiill walking | 15:52 |
gitlab-br-bot | buildstream: merge request (reset-all-workspaces->master: Add option to reset multiple workspaces) #417 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/417 | 15:53 |
tristan | Aha! | 15:54 |
tristan | cs_shadow, wins ! | 15:54 |
tristan | and even though my walker had reached the finish line, he still took it from me ! | 15:54 |
gitlab-br-bot | buildstream: merge request (tristan/loader-private-refactor->master: Loader private refactor) #416 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/416 | 15:55 |
tristan | jennis, time for another race... | 15:55 |
jennis | :p | 15:55 |
jennis | Looks like you've got a headstart | 15:55 |
tristan | you are taking longer to merge ! | 15:56 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 15:56 |
tristan | that aint my fault | 15:56 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 15:56 |
tristan | oh, I had already rebased you in the UI | 15:58 |
jennis | hahaa | 15:58 |
jennis | again | 15:58 |
tristan | jennis, I didnt mean to be unfair :) | 15:58 |
jennis | you're deliberately stalling me | 15:58 |
tristan | I mean, I rebased them both at the same time | 15:58 |
tristan | yours took longer to rebase, I presume you force pushed a rebase and that retriggered ? | 15:58 |
jennis | indeed | 15:58 |
tristan | https://gitlab.com/BuildStream/buildstream/pipelines/20650253 (mine) https://gitlab.com/BuildStream/buildstream/pipelines/20650338 (yours) | 15:59 |
tristan | jennis, you are ahead of me ! | 15:59 |
tristan | haha | 15:59 |
jennis | lol | 16:00 |
*** Prince781 has quit IRC | 16:06 | |
gitlab-br-bot | buildstream: merge request (documentation-formatting-in-HACKING->master: Documentation formatting in hacking) #411 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/411 | 16:07 |
tristan | tlater, the secret is to hatch a fried egg :) | 16:10 |
gitlab-br-bot | buildstream: issue #365 ("gir1-ostree version is wrong on Debian stable") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/365 | 16:11 |
jennis | oh they're off again | 16:15 |
tristan | I'm in the lead | 16:16 |
* jennis see's a cancel running button | 16:16 | |
tristan | haha | 16:17 |
gitlab-br-bot | buildstream: issue #365 ("gir1-ostree version is wrong on Debian stable") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/365 | 16:20 |
*** Prince781 has joined #buildstream | 16:30 | |
gitlab-br-bot | buildstream: merge request (tristan/loader-private-refactor->master: Loader private refactor) #416 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/416 | 16:32 |
jennis | :O | 16:32 |
jennis | http://www.nooooooooooooooo.com/ | 16:32 |
gitlab-br-bot | buildstream: 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/389 | 16:50 |
gitlab-br-bot | buildstream: issue #365 ("gir1-ostree version is wrong on Debian stable") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/365 | 16:51 |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 16:52 |
gitlab-br-bot | buildstream: 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/389 | 16:53 |
gitlab-br-bot | buildstream: merge request (richardmaw/key-summary->master: List resolved element keys in job summary) #389 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/389 | 16:53 |
*** jonathanmaw has quit IRC | 17:00 | |
gitlab-br-bot | buildstream: merge request (restructure-ToC-on-homepage->master: Restructure ToC) #410 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/410 | 17:07 |
*** noisecell has quit IRC | 17:12 | |
gitlab-br-bot | buildstream: merge request (getting-started-section->master: WIP: Getting started section) #418 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/418 | 17:20 |
*** bethw has quit IRC | 17:21 | |
*** Prince781 has quit IRC | 19:16 | |
*** tristan has quit IRC | 20:37 | |
*** Prince781 has joined #buildstream | 20:38 | |
*** Prince781 has quit IRC | 21:14 | |
*** aday has quit IRC | 22:05 | |
*** slaf has quit IRC | 22:24 | |
*** slaf has joined #buildstream | 22:25 | |
*** slaf has joined #buildstream | 22:26 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!