| *** leopi has joined #buildstream | 04:34 | |
| paulsher1ood | morning folks... https://gitlab.com/BuildStream/website/merge_requests/57 | 06:45 |
|---|---|---|
| paulsher1ood | that changes Portfolio to About | 06:45 |
| *** tristan has quit IRC | 07:07 | |
| *** lachlan has quit IRC | 07:11 | |
| *** tristan has joined #buildstream | 07:24 | |
| *** ChanServ sets mode: +o tristan | 07:24 | |
| * tristan realizes he was speaking into a disconnected black hole | 07:25 | |
| tristan | paulsher1ood, SotK fixed the site to be relocatable, which effects how we express internal site links | 07:25 |
| tristan | paulsher1ood, It's a small fix, [About](about.html) becomes [About]({filename}about.md}), and... | 07:25 |
| tristan | ...a change to the page itself, at the top instead of "save_as: about.html", you need "slug: about" | 07:26 |
| tristan | paulsher1ood, I can do the change myself | 07:26 |
| tristan | And thanks, I was really wondering what this portfolio thing was all about, also | 07:26 |
| tristan | Any thoughts about "Updates" > "News" ? | 07:27 |
| *** rdale has joined #buildstream | 07:59 | |
| *** leopi has quit IRC | 08:00 | |
| paulsher1ood | +1 for that | 08:09 |
| qinusty | +1 | 08:11 |
| paulsher1ood | hmmm... how come my website mr can no longer be merged? | 08:13 |
| qinusty | Require local rebase perhaps? | 08:13 |
| paulsher1ood | yup | 08:14 |
| gitlab-br-bot | buildstream: merge request (jmac/remote_execution_client->master: WIP: Remote execution client) #626 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/626 | 08:16 |
| *** leopi has joined #buildstream | 08:19 | |
| paulsher1ood | fixing now | 08:20 |
| paulsher1ood | should be ready pls could someone review? https://gitlab.com/BuildStream/website/merge_requests/57 | 08:23 |
| qinusty | Is it just me, or does gitlab seem more responsive today? | 08:23 |
| qinusty | Push/pull/fetch wise | 08:24 |
| tristan | paulsher1ood, Did you get my comments above ? | 08:24 |
| tristan | paulsher1ood, just some minor points about how we refer to links have changed with SotK's change that allows the website to be relocatable when built with `make html` | 08:25 |
| * tristan looks at the MR... | 08:25 | |
| tristan | A right, thanks qinusty for review, indeed your comment is correct and the only one | 08:27 |
| qinusty | Did we end up deciding on what to do regarding links? | 08:28 |
| qinusty | inline or... | 08:28 |
| tristan | paulsher1ood, Note that you can now `pip3 install -r requirements.txt` and run `make html`, and view the resulting output/index.html in your browser | 08:28 |
| * qinusty recommends using pipenv or virtualenv | 08:28 | |
| tristan | qinusty, I have a middle ground to propose for that to be honest | 08:28 |
| qinusty | Wait! | 08:29 |
| * qinusty finds what he wanted to suggest | 08:29 | |
| tristan | qinusty, I think that (A) The argument to keep links separate at the bottom is mostly about the desire to copy paste parts of the site and duplicate them elsewhere | 08:29 |
| qinusty | https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#links [text][1] | 08:29 |
| tristan | qinusty, And (B) I think that the only place where we would ever want that to happen, is in the articles | 08:29 |
| qinusty | [1]: link | 08:30 |
| tristan | qinusty, that is worse | 08:30 |
| tristan | qinusty, it just adds an *extra* level of ambiguitiy/lookup | 08:30 |
| qinusty | You think? Feels more natural since the text can be modified in one place, so can the link. But the reference is unique | 08:30 |
| tristan | Then you have to make sure your numbers all match up | 08:30 |
| qinusty | You don't need to use numbers :D | 08:30 |
| tristan | Meh, I'm ambivalent; I want [Links](inline.html) all the time, but am trying to be understanding of people who want to copy paste for other purposes | 08:31 |
| tristan | Which I think is *only* relevant for articles | 08:31 |
| tristan | The "articles" (public service announcements, releases, etc), are pretty much one off writeups | 08:32 |
| qinusty | Fair enough. [text][id] .... [id]: link... Seems more like referencing in papers/articles to me :D | 08:32 |
| tristan | If you are Copy/Pasting the FAQ, instead of referring to the website; you are doing something wrong | 08:32 |
| tristan | You are duplicating information that is likely to get out of date, the up to date copy should always be linked to, never copied in some location where people can have an opportunity to read something out of date | 08:33 |
| tristan | That goes for the whole site basically, except for the articles | 08:33 |
| paulsher1ood | tristan: i've been viewing in my browser already | 08:34 |
| tristan | So what I would prefer; is that we *always* do [link](target.html) everywhere on the site; to make things all inline and easy to maintain | 08:34 |
| paulsher1ood | i'd be surprised if my changes have broken any links | 08:34 |
| paulsher1ood | do we have a link-checker on the CI? | 08:34 |
| tristan | paulsher1ood, Links were previously pointing to file:///faq.html, until I changed them to be relative a day ago (probably before you tried viewing them, it was early morning yesterday) | 08:35 |
| tristan | paulsher1ood, but I screwed it up, and SotK fixed it | 08:35 |
| tristan | paulsher1ood, unfortunately no :( | 08:35 |
| paulsher1ood | ack, and my mr is rebased on top of sotk's fix | 08:35 |
| tristan | Sphinx does this like a grown up, pelican on the other hand is very bad about error checking | 08:35 |
| *** toscalix has joined #buildstream | 08:35 | |
| tristan | paulsher1ood, Did you fix qinusty's comment ? | 08:35 |
| paulsher1ood | no i hadn't seen them | 08:36 |
| tristan | toscalix, We are discussing links again; My understanding is that you want easier copy/paste-ability for publicity stuff | 08:37 |
| tristan | toscalix, So I'd like to propose a middle ground: Always [Link](inline.html) when editing any of the "Site pages"... and always [Link] with the references at the bottom for the Articles | 08:37 |
| tristan | toscalix, My thoughts are that, if people are copying parts of the actual site, they are duplicating something which should be referred to instead; however the articles make sense for press releases and such | 08:38 |
| tiagogomes | o/ | 08:38 |
| tristan | toscalix, Also the articles should be one off changes | 08:38 |
| tristan | I.e. articles dont risk getting outdated | 08:39 |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/58 I assume I'm fine to just merge something like this? | 08:39 |
| tristan | But copy/pasting the FAQ instead of referring to it, is a bad thing | 08:39 |
| tristan | toscalix, anyway; that is the middle ground I'd like to propose for the linking | 08:39 |
| tristan | tiagogomes, ? | 08:39 |
| tristan | qinusty, I don't think so, it looks like you removed some comments which were there to assist whoever was going to fill out some content ? | 08:40 |
| * qinusty reviews his MR | 08:40 | |
| tiagogomes | ah, {filename} only works if slug was set | 08:41 |
| * qinusty realises he accidently branched from his other MR | 08:41 | |
| tristan | tiagogomes, right, SotK's MR changes the pages to set slug: instead of save_as: | 08:41 |
| tristan | I tried it locally, seems to work well | 08:41 |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/58/diffs Fixed tristan :D That was the intention of the MR | 08:42 |
| tristan | There are again still some hardcoded references to buildstream.build creeping into the FAQ | 08:42 |
| tristan | qinusty, Yeah, definitely :) | 08:42 |
| tristan | qinusty, So if you're going to accidentally merge stuff you didn't intend to, please be more careful ! | 08:43 |
| tristan | hehe | 08:43 |
| * qinusty needs to stop checking out new branches from his MR branches | 08:43 | |
| qinusty | I kinda wish checkout used master by default D: | 08:43 |
| tristan | I saw the discussion about the table for the releases, and yeah agree it's a downside to the alchemy theme, we should fix that in some way | 08:44 |
| tristan | qinusty, You can use a git invocation which does that explicitly, I'm pretty sure | 08:44 |
| tristan | qinusty, then it would always be in your ^R search history :) | 08:44 |
| qinusty | Yeah `git checkout -b newbranch frombranch` | 08:45 |
| qinusty | :D | 08:45 |
| qinusty | But since newbranch comes first, I have to type out frombranch every time | 08:45 |
| tristan | yep, and you probably want origin/master juuuust incase | 08:45 |
| qinusty | Indeed | 08:45 |
| qinusty | It's usually easy to rebase master onto origin/master anyway, since we don't modify history | 08:46 |
| tristan | qinusty, I mean in case you have staged changes there which you forgot to create a branch for (happens to me at times) | 08:47 |
| qinusty | ahhhh | 08:47 |
| qinusty | yes | 08:47 |
| Kinnison | I tend to start by `git checkout frombranch` ... check I'm where I thought I wanted to branch from ... `git checkout -b newbranch` | 08:47 |
| qinusty | Yeah, I just tried to quickly throw up an MR for the gitignore change :D | 08:47 |
| * tristan very frequently just checks `git branch` | 08:47 | |
| qinusty | and skipped the thought of which branch I was coming from | 08:47 |
| * qinusty has his branch in his shell prompt | 08:48 | |
| * qinusty should really know | 08:48 | |
| tristan | But then it's true that it's tedious, like... I almost never change my CWD, why "go all the way over there" just to run a command; kindof novice | 08:48 |
| tristan | but I guess I'm a git novice, I always change my branch first :) | 08:49 |
| Kinnison | :-) | 08:49 |
| qinusty | git is just too powerful | 08:49 |
| * Kinnison thinks that using git as a novice is usually the best way | 08:49 | |
| qinusty | always more to learn | 08:49 |
| Kinnison | use the simple commands | 08:49 |
| * qinusty never rebased or bisected before working on BuildStream | 08:49 | |
| * Kinnison made the mistake of learning *how git works* (internally) and so thinks of rebase as a simple command | 08:50 | |
| paulsher1ood | qinusty: incoming... i fixed a bit more text in response to your comment | 08:50 |
| * Kinnison wonders if paulsher1ood intends to have a 1 instead of a w | 08:51 | |
| * paulsher1ood fails to parse Kinnison's comment | 08:54 | |
| Kinnison | paulsher1ood: your nick is your backup nick | 08:54 |
| qinusty | tristan, I'm not 100% on `slug` myself, is the convention for {filename} to contain .html? | 08:54 |
| tiagogomes | qinusty {filename} is to specify intra-site links to files in the source content hierarchy instead of files in the generated hierarchy | 08:59 |
| *** tristan has quit IRC | 09:00 | |
| *** tristan has joined #buildstream | 09:00 | |
| *** ChanServ sets mode: +o tristan | 09:01 | |
| SotK | the thing that fixed {filename} was setting PAGE_URL and PAGE_SAVE_AS in pelicanconf.py, which uses the slug | 09:02 |
| * tristan lost power :( | 09:02 | |
| Kinnison | oops | 09:03 |
| Kinnison | at least you found it again | 09:03 |
| tiagogomes | That's basically the plot for Thor | 09:03 |
| qinusty | :D | 09:04 |
| tristan | yep, checked logs | 09:04 |
| qinusty | In a gitlab ci script can I run something as `command &` to run in the background? | 09:04 |
| paulsher1ood | Kinnison: ack. not intentional | 09:05 |
| tiagogomes | qinusty I don't why you couldn't. But why would you do that | 09:06 |
| qinusty | Link validation :D | 09:06 |
| qinusty | Gotta serve the site | 09:06 |
| qinusty | then crawl | 09:06 |
| paulsher1ood | right. so have a staging site, serve there | 09:07 |
| paulsher1ood | any codethings could crib the codethink soln for example | 09:07 |
| * paulsher1ood gets gently irritated about being a second-class citizen on this project, just as he has been before... | 09:08 | |
| paulsher1ood | speci | 09:08 |
| paulsher1ood | specifically... i can't merge my own changes to the website. others are critiquing my changes, which is fine... but it wold be easier and less work all round in some cases to just fix and merge, rather than discuss | 09:10 |
| paulsher1ood | there's a possibility that some folks think it best to 'train/educate' contributors... which would be fine... | 09:10 |
| paulsher1ood | except that first-class citizens have already committed stuff that's worse than my patches | 09:10 |
| paulsher1ood | /lecture mode off | 09:11 |
| gitlab-br-bot | buildstream: merge request (richardmaw/subprocess-PWD->master: Ensure PWD is set in process environment) #782 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/782 | 09:12 |
| tiagogomes | qinusty can you revert https://gitlab.com/BuildStream/website/merge_requests/58? The generated files are in the 'output' directory since yesterday I add pre merge CI :) | 09:14 |
| toscalix | I set up the review process on the website | 09:15 |
| tiagogomes | So your 'public' directory is stale | 09:15 |
| qinusty | Ahhhhh okay tiagogomes, I still had files locally :D | 09:15 |
| toscalix | I added 4 approvers and 3-4 people had merge rights | 09:15 |
| toscalix | the approvers part was removed yesterday | 09:15 |
| toscalix | I believe. I think we should put it back | 09:15 |
| toscalix | so we can increase the number of people involved in changes | 09:16 |
| toscalix | between approvers and maintainers | 09:16 |
| toscalix | I have been adding those who work on the website as approvers and maintainers as needed | 09:17 |
| qinusty | It makes sense to have someone review changes with content/links etc. Even to just make sure things make sense to more than one individual | 09:17 |
| toscalix | I have no problem with adding paulsher1ood to the group now that he seems interested in contributing to the website | 09:18 |
| toscalix | I take paulsher1ood words as a request, so I add you | 09:18 |
| toscalix | In my case, for instance, I am perfectly happy with not having merge rights on the website | 09:19 |
| toscalix | I sleep better, with my git, knowlege, without that responsibility | 09:19 |
| toscalix | by the way, the rule I put is having one approver | 09:20 |
| *** jonathanmaw has joined #buildstream | 09:20 | |
| toscalix | I will put it back | 09:20 |
| toscalix | if tiagogomes is ok with it since he is doing the technical work. Maybe you want to do it after a couple of extra days, when the web is settle | 09:21 |
| toscalix | tiagogomes: ? ^ | 09:21 |
| toscalix | ah, no, 5 approvers. We started with 3 | 09:22 |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/60 fixes our broken link on rebasing issue. Gitlab CI will now fail if any internal links on our CI leads to 404 | 09:22 |
| qinusty | please review | 09:22 |
| qinusty | See pipeline for example | 09:22 |
| toscalix | paulsher1ood: is now approver and maintainer | 09:23 |
| toscalix | does anybody else want to contribute as approver? It would be of great help | 09:23 |
| * qinusty isn't sure if he is classed as an approver. But is happy to review/approve MR's | 09:23 | |
| toscalix | qinusty: I think you would be a good one | 09:23 |
| toscalix | out of the 5, for instance we have one on vacation, one in an event and one in a different timezone | 09:24 |
| tiagogomes | I am fine with anything. I wouldn't like to not receive a new item on Todos whenever someone sends a MR though | 09:24 |
| toscalix | tiagogomes: I support your idea | 09:24 |
| tiagogomes | *would | 09:25 |
| tiagogomes | qinusty looks good, did you check that if any 404 happens the exit code is not 0? | 09:25 |
| toscalix | qinusty: added | 09:25 |
| tiagogomes | pelican was always 0 by default | 09:25 |
| qinusty | Yeah, see https://gitlab.com/BuildStream/website/pipelines/29544020 where it broke before I added a sleep | 09:26 |
| qinusty | I needed to sleep for `make serve &` to initialize properly | 09:26 |
| tiagogomes | It doesn't validate if some uses buildstream.build in the URL, but that's better than nothing :) | 09:27 |
| *** lachlan has joined #buildstream | 09:31 | |
| tristan | paulsher1ood, I can make you merger there, it's a recently created repo, just need to add you | 09:32 |
| qinusty | yeah tiagogomes, hopefully they will be picked up on MR. Primarily this is to stop someone rebasing and not realising the changes they just dragged in break their links | 09:34 |
| tristan | ah someone already did it | 09:34 |
| tiagogomes | qinusty merged. Perhaps we should also have a "make test" target which runs the link checker, so that one can check the links before pushing it to CI | 09:34 |
| qinusty | yeah, I'll add that now :D | 09:34 |
| tristan | If you all want to get bogged down in approvals, I won't object - I feel that at this stage, most of the changes required are no-brainer one liners; and we're wasting valuable time with approvers | 09:35 |
| toscalix | I think this is a good place to try different approaches adnd see how it goes | 09:37 |
| toscalix | so we can translated them to other areas of the project | 09:37 |
| toscalix | so omre people get involve in reviewing | 09:37 |
| toscalix | more involved in .... | 09:37 |
| paulsher1ood | :-) | 09:38 |
| toscalix | So I am willing to sacrifice a little bit of efficiency for those some if we gain traction in reviewing activities | 09:38 |
| toscalix | man I need coffee. I cannot write a single sentence today correctly | 09:39 |
| tiagogomes | paulsher1ood are you going to fix the slug on your MR or you lack time | 09:39 |
| toscalix | bad day for writing contents :-D | 09:39 |
| paulsher1ood | tiagogomes: sorry, busy elsewhere | 09:40 |
| tiagogomes | ok | 09:40 |
| tristan | Again I wont object but; there is also the angle that: Not requiring approvals, does not need to mean people cannot give approvals | 09:41 |
| tristan | Or ask for review | 09:41 |
| tiagogomes | Does anyone mind if I merge https://gitlab.com/BuildStream/website/merge_requests/57 and then fix the slug afterwards? The branch for that MR is an different repo so I can't check it out easily | 09:43 |
| tristan | tiagogomes, I think you should go ahead, I offered to fix it for paulsher1ood this morning too | 09:43 |
| tiagogomes | hm, I can't merge | 09:44 |
| tristan | tiagogomes, you have to fetch his repo, make the change, and submit new MR | 09:46 |
| tristan | tiagogomes, because it went out of date, rebase UI feature is not possible on an external repo (we don't have rights to modify paulsher1ood's own repo) | 09:46 |
| toscalix | tiagogomes: fixing that | 09:47 |
| toscalix | ah, no, need rebase | 09:47 |
| toscalix | cannot fix | 09:47 |
| tristan | exactly | 09:47 |
| tristan | toscalix, Have you given some thought to what I said about links when you walked in ? | 09:47 |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/61 do the job tiagogomes? | 09:48 |
| toscalix | I want to leave it as tiago propose it | 09:48 |
| toscalix | I think it is a nice and clean way to review content | 09:48 |
| tristan | toscalix, I think that we really should not allow copy/paste of the site, *unless* it is for the release announcements or articles, for press releases | 09:48 |
| qinusty | The slight inconvenience is that this `make devserver` command doesn't seem to work for me | 09:48 |
| toscalix | I bought his reason for using this way | 09:48 |
| toscalix | I remember using it in mediawiki, I think. It was cool | 09:49 |
| tristan | Hmmm | 09:49 |
| tristan | Ok sure, tiagogomes so what is the policy then exactly ? All links must be at the bottom except for links which link into the internal site ? | 09:49 |
| toscalix | I have used it in two pages only | 09:49 |
| toscalix | so it will take some time until we comply | 09:49 |
| tristan | tiagogomes, I.e. [Link]({filename}faq.md) always... and [Link]: http://external-link.com at the bottom always ? | 09:50 |
| tiagogomes | tristan that's my personal preference, but I know that we disagree :) | 09:50 |
| tristan | I think it's error prone and harder to maintain yes, but I've said my peace | 09:51 |
| tiagogomes | I need an approval for https://gitlab.com/BuildStream/website/merge_requests/62 | 09:51 |
| tristan | tiagogomes, but it would be good to make it policy whatever is chosen, an intermingled mess is not a good idea | 09:51 |
| tristan | Ok, so we need a new one like this for "Updates" -> "News" | 09:52 |
| toscalix | for contents, you can assign the MR to me. I will get a notification and review it | 09:52 |
| * tristan creates | 09:52 | |
| tiagogomes | I argue that you will change the content more than to edit the urls of the links. So having the content easier to parse and edit by not adding possibly longs URLs is more important | 09:52 |
| toscalix | for tech topics, assign it to a different person. You can assign the MR to several people | 09:52 |
| qinusty | Also toscalix, The thing I was talking about yesterday exists. https://paste.gnome.org/pja13hhzy/b4bsxx/raw | 09:52 |
| tristan | tiagogomes, It's fine, actually since the beginning, I raised it because I think it's error prone in general; but the conversation evolved since then, it's not a battle worth fighting for me :) | 09:53 |
| toscalix | qinusty: I see what you mean. Yes, I was aware of these two options | 09:53 |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/61/commits needs approval post rebase | 09:54 |
| toscalix | What I was not aware of was the one tiagogomes told me about. I only saw it in mediawiki, confluence... maybe some other I do not remember | 09:54 |
| tiagogomes | tristan but most of all, let's be consistent :) | 09:54 |
| tristan | tiagogomes, that's why I said about policy | 09:55 |
| toscalix | please let's not forget about the tables | 09:55 |
| tristan | tiagogomes, it's worth going over the whole site and doing it once, so that people fall inline when editing anything | 09:55 |
| * toscalix stops talking about somebodyelse's job and goes back to his | 09:55 | |
| tristan | toscalix, qinusty has a branch for the tables I believe | 09:55 |
| qinusty | He knows :D | 09:56 |
| qinusty | tiagogomes and toscalix disagree on tables though, did we decide on a style? | 09:56 |
| toscalix | qinusty: we disagree with what we have now is nice | 09:56 |
| toscalix | I am sure we can find a format we both agree with. | 09:57 |
| qinusty | Okay, well I'll merge the tables one with my features page branch | 09:57 |
| qinusty | and we can experiment in the future | 09:57 |
| tiagogomes | I really think that makes tables look awful | 09:58 |
| tiagogomes | Do you still have the link? | 09:58 |
| tristan | qinusty, post merge comment: https://gitlab.com/BuildStream/website/merge_requests/61#note_99365530 | 09:58 |
| toscalix | tiagogomes: we need a way to clearly differentiate rows and columns. If you do not like borders.... experiment with colours | 09:58 |
| qinusty | Intentional tristan :D | 09:59 |
| tristan | qinusty, ok :) | 09:59 |
| qinusty | The apostrophes are shifteed | 09:59 |
| qinusty | shifted* | 09:59 |
| tristan | If the text is all aligned, and at least more space between columns, why is it important to distinguish between columns ? | 10:00 |
| tristan | I think it is certainly true for rows | 10:00 |
| tristan | color alternation between them could be good | 10:01 |
| tristan | Then again, I'm not religiously opposed to borders even if they are old fashion and look like a spreadsheet | 10:01 |
| toscalix | isn't the install guide assuming the user knows what PyPi is? I wonder if every developer that requires an integration tool is familiar with it | 10:05 |
| tristan | toscalix, We could call it `pip` but, I think the key part here is that at https://buildstream.build/install.html, the PyPI link says "(recommended)" | 10:11 |
| tristan | The same could be said of a tarball or git, with varying accuracy | 10:12 |
| tristan | tiagogomes, any idea why there is a MENUITEM for 'updates.html', but there is no 'updates.md' ? | 10:14 |
| tristan | hard coded pelican stuff ? | 10:14 |
| tiagogomes | tristan that page is automatically generated based on the list of articles (ARTICLES_SAVE_AS) | 10:15 |
| tristan | tiagogomes, ah gotcha | 10:15 |
| tristan | qinusty, eeek, how come when I do `make test` it tells me pylinkvalidate.py is not there, and it isn't ? | 10:15 |
| tristan | qinusty, how did it pass the CI if you forgot to `git add` it ? | 10:16 |
| toscalix | I think that the less knowledge of python we assume the developer has, the wider audience we are reaching, specially with developers coming from other languages | 10:16 |
| toscalix | yes, the same applies to git... sadly | 10:17 |
| tiagogomes | tristan requirements.txt | 10:17 |
| tristan | toscalix, the problem with saying "pip" is that, you also use "pip" to install from a tarball or from git | 10:17 |
| tristan | tiagogomes, ah I see, I notice now the Makefile doesnt prefix it with $(BASEDIR) | 10:18 |
| tiagogomes | https://gitlab.com/BuildStream/website/merge_requests/63/ | 10:18 |
| toscalix | maybe a clarification or a link to a resource that explains that would be enough | 10:18 |
| toscalix | it was a general comment. I do not know the solution | 10:18 |
| tristan | toscalix, yeah I understand, note that there will also be a badge for this provided by PyPI itself, not sure of the status on that yet | 10:20 |
| tristan | badge was broken last time around saying "Invalid json response", but normally it links to BuildStream page at PyPI and shows the latest release published there | 10:21 |
| tristan | https://gitlab.com/BuildStream/website/merge_requests/64 <-- changes "Updates" -> "News", I grepped for "updates" in the content and didnt find any links to that page besides the menubar (and ran the test) | 10:22 |
| qinusty | tristan pip install -r requirements.txt | 10:24 |
| tristan | qinusty, yup, tiagogomes told me :) | 10:42 |
| qinusty | spotted after scrolling down :D I jumped to the ping | 10:43 |
| tristan | qinusty, Is there any reason BTW, that `make test` link checking requires running the server in the background ? | 10:43 |
| tristan | qinusty, couldn't it just instpect the output/ directory, and implicitly depend on the html target ? | 10:43 |
| qinusty | The link checker requires it to be served. | 10:43 |
| tristan | Meh | 10:44 |
| tristan | Ok | 10:44 |
| * qinusty shrugs | 10:44 | |
| tristan | obnoxious when running locally, unimportant in CI | 10:44 |
| qinusty | Ideally | 10:44 |
| qinusty | make devserver would work | 10:44 |
| qinusty | aand I could have make test do `make devserver \n make test \n make stopserver` | 10:44 |
| qinusty | but noooooo | 10:44 |
| tristan | heh | 10:46 |
| *** finn has quit IRC | 10:52 | |
| tiagogomes | https://gitlab.com/BuildStream/website/merge_requests/63 | 10:53 |
| *** finn has joined #buildstream | 10:55 | |
| toscalix | qinusty: could not merge your MR | 10:56 |
| tristan | tiagogomes, haha, Kill the TOCs ! | 10:56 |
| qinusty | Yup, it needs rebasing and I haven't pushed my latest rebase toscalix | 10:56 |
| toscalix | since we are adding content to the same page, can you review mine so I merge it first? | 10:56 |
| qinusty | Sure | 10:56 |
| tristan | tiagogomes, I personally like it, but I feel that we should split up the source install into three pages (install dependencies, install, post install setup on different pages) | 10:56 |
| qinusty | In general, approve and let someone merge. I wouldn't merge incase someone has local changes they'd like to push to their MR | 10:57 |
| toscalix | tristan: that is a terrible idea | 10:58 |
| toscalix | every time you split a page, you loose most of the visitors | 10:58 |
| toscalix | because they have to come back and forth since you are creating a tree instead of a single path | 10:58 |
| toscalix | so if the instructions are a single path... fine | 11:00 |
| toscalix | but no back and forth | 11:01 |
| qinusty | But then again, having one massive page makes people want to leave | 11:01 |
| qinusty | too much text on the screen | 11:01 |
| toscalix | qinusty: depends in if you have to consume it all or not | 11:01 |
| paulsher1ood | change font style. use less words :-) | 11:01 |
| toscalix | that is your guess | 11:01 |
| paulsher1ood | s/style/size/ | 11:01 |
| toscalix | I have been in projects in which having different pages for instructions ended up in loosing users | 11:02 |
| paulsher1ood | +1 for killing ToCs | 11:02 |
| qinusty | +1 | 11:02 |
| SotK | +1 | 11:02 |
| toscalix | I am too used to listening to opinions that are not backed up by data in this regard. As a starting point, make the most conservative guess, with a reduced number of pages | 11:02 |
| qinusty | Honestly, if they're going to leave over having to click a link. They really didn't want to open a terminal and follow install instructions in the first place | 11:02 |
| toscalix | then check the data and plit up | 11:03 |
| tristan | Well, with the +1's for killing the tocs, I will just point out: https://gitlab.com/BuildStream/website/merge_requests/63#note_99386052 | 11:03 |
| tristan | For your collective consideration | 11:03 |
| SotK | also +1 for keeping the whole install path on one page, unless its crazy complicated | 11:03 |
| tristan | SotK, https://buildstream.build/install.html | 11:04 |
| tristan | Problem is we provide per-distro instructions to make installing dependencies easier for people (just copy paste), that part grows | 11:04 |
| toscalix | we had in the design https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/content_design/BuildStream_Content_Structure_critical_path.pdf | 11:04 |
| tristan | Then again; It could be alright to just keep the ToC on that page | 11:05 |
| toscalix | we analise data and then decide to modifiy it | 11:05 |
| toscalix | that was my original approach | 11:05 |
| toscalix | sadly I was not able to convince that we should stick to it. | 11:06 |
| tristan | If we're going to remove ToCs, we still need easy navigation, and consumable parts; otherwise we should keep ToCs at least where they help | 11:06 |
| toscalix | but the principle remains. Short and clearly defined critical path, data anlysis and then... guess again | 11:07 |
| toscalix | anyway.... | 11:07 |
| tristan | toscalix, The fact that you did this design is still valuable, even if it is not followed in practice. The overhead of doing all of this was clearly too much however for people to contribute meaningfully in the design phase. | 11:07 |
| tristan | That is unfortunate, but we have time constraints, rather restraints in resourcing our time to contribute to this process | 11:08 |
| *** lachlan has quit IRC | 11:08 | |
| toscalix | I appreciate your words but I disagree with that view. You have in your team somebody that has done this several times and you decided to trust your ideas above his experience | 11:08 |
| toscalix | but no, the design is correct to start with | 11:09 |
| toscalix | based on my previous experience. I am fine with challenging it | 11:09 |
| SotK | tristan: I feel like I'd have something like a page for each type of source install, each containing the full instructions for that install | 11:09 |
| toscalix | but not based on ..... gut feelings | 11:09 |
| tristan | toscalix, There is one single point that you got wrong - please don't conflate that too much. Users do not download BuildStream, the design needs to fit the actual recommendations, and that is all. | 11:09 |
| *** alatiera_ has joined #buildstream | 11:10 | |
| toscalix | but again, all this isn't important now. We need to finish the content and then go out there and make noise | 11:10 |
| tristan | SotK, it's duplicating a lot of information, though | 11:10 |
| toscalix | with data, we will find out what to do next | 11:10 |
| toscalix | I think we could have started in a much better position that we will taking advantage of previous "mistakes" | 11:10 |
| toscalix | that's all | 11:11 |
| SotK | tristan: yeah that's the downside I guess, though I expect you could use a custom page template to remove duplication in the source | 11:11 |
| *** jonathanmaw_ has joined #buildstream | 11:12 | |
| *** jonathanmaw has quit IRC | 11:13 | |
| SotK | (you can add arbitrary metadata to the top of pelican markdown files, so defining "pre-install-instructions" and "post-install-instructions" pointing to the relevant source files, and use those in a custom template for that type of page to inline the rendered content from that source file | 11:13 |
| SotK | ) | 11:13 |
| *** finn has quit IRC | 11:14 | |
| *** abderrahim has quit IRC | 11:18 | |
| *** abderrahim has joined #buildstream | 11:19 | |
| *** finn has joined #buildstream | 11:19 | |
| tristan | SotK, indeed, an "include" style of page generation could work well here | 11:19 |
| qinusty | reviewed toscalix, a few of these are completely based off how I interpret the text. But would accept any further review on my comments from people. | 11:20 |
| tristan | This way we have all of the relevant information for the selected install method in one place, sacrificing the ability to link specifically to pre/post steps (but that seems unneeded in this case) | 11:20 |
| qinusty | Going for lunch, will check back after. | 11:20 |
| * tristan comments on the ToC removing MR with a summary of SotK's suggested changes: https://gitlab.com/BuildStream/website/merge_requests/63#note_99391893 | 11:25 | |
| *** lachlan has joined #buildstream | 11:26 | |
| tiagogomes | Some pages should still have a ToC, like the FAQ page, so I didn't remove all the ToCs for now but just the ones which were visibly wrong to have | 11:29 |
| tiagogomes | If source_install is split, then probably shouldn't have one. But right now it is a single page (and I actually prefer that) | 11:31 |
| tristan | tiagogomes, sorry then I misunderstood what https://gitlab.com/BuildStream/website/merge_requests/63/diffs#4cd8c938f4dfb9b2579dcfaf97c623df6ca28eb8_44_44 does | 11:36 |
| tristan | tiagogomes, I thought that means we're removing the extension, but it just means we're not "titling the tocs" ? | 11:36 |
| * tiagogomes lazily: | 11:37 | |
| tiagogomes | 44f8a83 (HEAD -> tiagogomes/toc-improvements, origin/tiagogomes/toc-improvements) faq: improve table of contents | 11:37 |
| tiagogomes | 6fcbdca Remove TOC from about and community pages | 11:37 |
| tiagogomes | 2c102d9 Don't set a title for the table of contents | 11:37 |
| tristan | tiagogomes, you prefer that it is all on one page over SotK's include idea ? | 11:37 |
| tristan | I'm a bit ambivalent, but think it would be nice to provide a page that has less information, more targeted at what the user chose | 11:38 |
| tiagogomes | I prefer to have less pages as possible. But looking at install, there's a direct link from pypi, tarball and git, so there wouldn't be an extra step to get there | 11:42 |
| tiagogomes | So I am fine with it. But then we should also split package_install.html no? | 11:43 |
| tiagogomes | https://flatpak.org/setup/ has a different page for each distro | 11:43 |
| tristan | tiagogomes, splitting up package install could be good too, I'm surprised there is no command line to copy/paste for Arch users :-S | 11:46 |
| tristan | jjardon, would you like to correct that at https://buildstream.build/package_install.html#arch ? | 11:46 |
| tiagogomes | He is on US | 11:49 |
| SotK | yeah I'd split up package install too | 11:49 |
| SotK | its a bit intimidating to see a page with a million sections when what you want are quick copy/paste instructions | 11:50 |
| SotK | I *think* links to anchors in the included pages will work fine (though it'd have to be something like `{filename}install/pypi.md#pre-instruction-foo` in the source I expect) | 11:51 |
| tristan | ok yeah he's in LAS | 11:54 |
| tristan | SotK, except I can't seem to find a use case for that off hand, but nice to know it might be possible | 11:55 |
| *** tristan has quit IRC | 12:02 | |
| toscalix | hi, since we have today at 17:00 BST a talk in LAS where bst will be named so people might look on our website it would be smart to avoid risky changes as we approach that time | 12:05 |
| paulsher1ood | what's LAS? | 12:05 |
| persia | Libre Application Summit | 12:05 |
| paulsher1ood | ah, ok | 12:06 |
| tiagogomes | The buildstream website doesn't pop up when searching on google | 12:09 |
| toscalix | buildstream.com will be hard to beat | 12:10 |
| toscalix | we need to define the keywords on the front page | 12:10 |
| toscalix | in order to elaborate a text that help us in that regard | 12:11 |
| persia | Also takes time. Age of sites is important in many ranking algorithms. | 12:11 |
| *** bochecha has joined #buildstream | 12:12 | |
| *** lachlan has quit IRC | 12:20 | |
| toscalix | qinusty: the content design doc make reference to the following | 12:29 |
| toscalix | there are pages that, with the next release, will need to be "moved" because new pages will replace them | 12:29 |
| toscalix | when you have only a couple of those cases, it is not big deal, but when the number of pages grow, you need a strategy on you will manage the links to those pages | 12:30 |
| toscalix | the risks is not just to break the links on your side, | 12:30 |
| toscalix | but to break first class references from external sites | 12:31 |
| SotK | hm, what pages will be moved? | 12:31 |
| toscalix | we need a strategy for the release announcement and the feature page for now, which are release specific | 12:31 |
| toscalix | each tool/website tool manage links differently | 12:32 |
| toscalix | so usually you manage this by setting some fixed links in your dns | 12:32 |
| toscalix | so that was my original idea | 12:32 |
| toscalix | tiagogomes: confirmed that this is not possible with gitlab pages | 12:32 |
| toscalix | I just told qinustyin the MR to avoid using specific version numbers in the page titles | 12:33 |
| toscalix | I would like to have time to think about how will we do it | 12:33 |
| toscalix | well.... propose it | 12:34 |
| toscalix | so we call the 1.2 feature page just feature page and the 1.2 release announc. release-announcement | 12:35 |
| toscalix | for now | 12:35 |
| *** bochecha has quit IRC | 12:38 | |
| SotK | any specific reason to avoid the version number in the page names/links? | 12:38 |
| SotK | just having a "1.2 feature page" or similar from the beginning feels like the easiest future-proof option to me | 12:39 |
| toscalix | there are already several pages pointing at feature page, without number | 12:50 |
| toscalix | static pages that will always point to the latest version | 12:50 |
| toscalix | of the feature page | 12:50 |
| toscalix | if you version the title.... you need to change them every time | 12:50 |
| toscalix | on the contrary, we might find a way that, when we move the pages in the future, we can redirect. We can take the opposite approach, but now we have only two pages to move so I guess that the first strategy will be cheaper | 12:52 |
| qinusty | but the current feature page is feature_page.md? | 12:52 |
| toscalix | so it is good | 12:52 |
| toscalix | that is correct. With the next release, we will substitu it for the new feature page and put the 1.2 somewhere else | 12:53 |
| toscalix | either we change the name, or add it into a different folder and use categories... | 12:53 |
| toscalix | I really do not know how to handle group of pages with gitlab | 12:53 |
| toscalix | I assume we can make use of the category field | 12:54 |
| toscalix | I cannot remember now but I added a category and tag to the release announcement | 12:54 |
| toscalix | I do not know how we will handle it. But we will need to | 12:55 |
| qinusty | toscalix I disagree with this process. We should have feature_page_1.2.md. We can give it the slug feature_page. Which will give it the url feature_page... | 12:55 |
| toscalix | the original idea was to have announcment.buildstream.build | 12:55 |
| toscalix | for instance | 12:55 |
| qinusty | Renaming the feature_page.md file every release just means moving the file in git every time... | 12:55 |
| *** bochecha has joined #buildstream | 12:56 | |
| toscalix | all I am saying is that I had a plan. It doesn work. We need a new plan. We do not have it. So let's try to avoid creating overhead until we do. I hope you guys put some technical solutions on the table and see what is best | 12:57 |
| qinusty | merged toscalix | 12:57 |
| toscalix | qinusty: thanks | 12:58 |
| *** phildawson has quit IRC | 12:59 | |
| *** phildawson has joined #buildstream | 12:59 | |
| qinusty | Please review https://gitlab.com/BuildStream/website/merge_requests/55 toscalix :D | 13:01 |
| *** bochecha has quit IRC | 13:02 | |
| qinusty | We can resolve any styling issues for the tables in a separate issue. | 13:02 |
| *** bochecha has joined #buildstream | 13:02 | |
| *** bochecha has joined #buildstream | 13:03 | |
| qinusty | I also raised https://gitlab.com/BuildStream/website/issues/21 for people to discuss the whole Install/Download thing tiagogomes, toscalix, tristan, valentind | 13:04 |
| *** bochecha has quit IRC | 13:04 | |
| *** bochecha has joined #buildstream | 13:04 | |
| *** bochecha has quit IRC | 13:09 | |
| *** bochecha has joined #buildstream | 13:09 | |
| *** bochecha has quit IRC | 13:11 | |
| *** bochecha has joined #buildstream | 13:12 | |
| *** bochecha has joined #buildstream | 13:13 | |
| tiagogomes | toscalix what should I do next for the wesite? | 13:29 |
| qinusty | Can you review https://gitlab.com/BuildStream/website/merge_requests/55 if you're free tiagogomes | 13:30 |
| *** bochecha has quit IRC | 13:31 | |
| *** bochecha has joined #buildstream | 13:31 | |
| tiagogomes | qinusty could you remove the change added to the css for the tables from that MR? | 13:31 |
| qinusty | I /can/, but my thoughts were that we'd add it then modify the style as appropriate based on further discussion | 13:32 |
| tiagogomes | Also looking at https://buildstream.gitlab.io/-/website/-/jobs/95309553/artifacts/output/feature.html, you want to left justify the 2nd column, and right or left justify the 1st column | 13:32 |
| tiagogomes | What "What's new software components table:" supposed to be? | 13:33 |
| qinusty | Splitting it into a new commit. | 13:34 |
| qinusty | table css that is | 13:34 |
| qinusty | New software components is not part of the diff. It was there before I started my changes. toscalix, drew up the structure | 13:35 |
| qinusty | I couldn't populate it due to not understanding the desired contents | 13:35 |
| tiagogomes | Right, but I still do wonder | 13:35 |
| qinusty | Also, the justify will happen in our css | 13:36 |
| qinusty | Column headers should be left justified. | 13:36 |
| qinusty | correct? | 13:36 |
| qinusty | sorry, table rows* | 13:36 |
| qinusty | not columns headers | 13:36 |
| qinusty | Justifying individual columns is where it gets tricky with markdown tables I think. We don't have that much control over pelican | 13:37 |
| tiagogomes | is this not possible with css? | 13:39 |
| qinusty | Not with how pelican generates the tables afaik | 13:39 |
| tiagogomes | I wouldn't even use tables there. Prose would be better | 13:40 |
| *** bochecha has quit IRC | 13:40 | |
| tiagogomes | td:nth-child(2) | 13:40 |
| qinusty | If you look at the html, we have <th> and <td> to work with for styling | 13:40 |
| *** bochecha has joined #buildstream | 13:41 | |
| * qinusty shrugs, web stuff | 13:41 | |
| qinusty | if it can be done | 13:41 |
| qinusty | feel free to push to my css MR when I make it | 13:41 |
| *** bochecha has quit IRC | 13:42 | |
| *** alatiera_ has quit IRC | 13:42 | |
| *** bochecha has joined #buildstream | 13:42 | |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/66 | 13:43 |
| *** alatiera_ has joined #buildstream | 13:43 | |
| *** bochecha has quit IRC | 13:44 | |
| toscalix | tiagogomes: the ticket corresponding to that page provides some hints, if they are not in the template itself https://gitlab.com/BuildStream/website/issues/1 | 13:47 |
| toscalix | I put 3 tables to cover all cases. We might end up having only two | 13:47 |
| toscalix | one table is for the features. Each one of them would be explained in more detaile in buildstream in detail, with references to the tech docu | 13:48 |
| toscalix | the second table make reference to software components | 13:48 |
| toscalix | this is the table that provides info about software and versions that the tool brings or requires that I need to know in order to avoid dependency problems, or things like that | 13:49 |
| toscalix | I believe for instance that we have quite a very hard requirement on the python version | 13:49 |
| toscalix | which for people working on corporate environments is very important to know in advance. They might be more | 13:50 |
| toscalix | the third table is more questionable. Since we have a plugin oriented strategy, my guess was that we might need to consider information that does not fit in the previous two tables | 13:51 |
| toscalix | it is important to understand that we will try to keep the first two tables, at least, in the coming features pages | 13:51 |
| toscalix | adding a row for the following release | 13:51 |
| toscalix | the first table will provide a sense of how features evolve and the second table is very valuable for anybody in need to manage the installation, but specially the maintenance, of the installations | 13:53 |
| toscalix | let's keep in mind that we aim to develop a tool for those who care about long term maintenance of their apps, so having a clear view of the dependencies that our tool carry on is essential | 13:54 |
| toscalix | I am usure how the third table is going to work. Maybe when I see it completed, we agree that it is better to remove it and add the content as paragraph | 13:54 |
| toscalix | I am confident that the first two tables will be valuable overtime | 13:55 |
| *** lachlan has joined #buildstream | 13:56 | |
| gitlab-br-bot | buildstream: merge request (jmac/remote_execution_client->master: WIP: Remote execution client) #626 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/626 | 13:57 |
| tiagogomes | I don't think we need a table for the software dependencies, and if we indeed needed one for the package creator, it shouldn't be there | 13:57 |
| tiagogomes | New features in software project are typically described in a list of items, or just prose, but never in a table | 13:57 |
| toscalix | tiagogomes: if you check the template you will see that the three main features will have a short paragraph at the beginning of the table | 13:58 |
| toscalix | the features will be described in BuildStream in detail | 13:59 |
| toscalix | the table is to name them, have a sens e of "per release" and add a short comment about what is new on it | 13:59 |
| toscalix | so I obviously agree with your view | 13:59 |
| toscalix | that there should not be description in tables | 13:59 |
| toscalix | but again, there are 5 maintainers, I believe and more with approve rights. And since somebody disagree in every single page paragraph.... feel free to implement what you think is right, convince an approver and maintainer... and problem solved. We will deal with the collage effect in the far future | 14:03 |
| toscalix | ah, I need to fill out what the 3 main features are, based on what it is in the release announcement | 14:04 |
| gitlab-br-bot | buildstream: issue #631 ("Remote-execution user configuration (technical debt)") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/631 | 14:11 |
| gitlab-br-bot | buildstream: issue #632 ("CAS server: Implement BatchReadBlobs") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/632 | 14:13 |
| gitlab-br-bot | buildstream: merge request (juerg/cas-batch->master: WIP: _artifactcache/casserver.py: Implement BatchReadBlobs) #785 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/785 | 14:14 |
| *** lachlan has quit IRC | 14:15 | |
| *** tiagogomes has quit IRC | 14:16 | |
| *** tiagogomes has joined #buildstream | 14:16 | |
| *** lachlan has joined #buildstream | 14:33 | |
| *** lachlan has quit IRC | 14:39 | |
| * qinusty hates pylint/pytest | 14:45 | |
| qinusty | Why is there /always/ something wrong with it, primarily with linting and consistency between versions. | 14:46 |
| *** lachlan has joined #buildstream | 14:46 | |
| *** jonathanmaw has joined #buildstream | 14:51 | |
| *** jonathanmaw_ has quit IRC | 14:52 | |
| gitlab-br-bot | buildstream: merge request (Qinusty/message-helpers->master: Continued work on improving BuildStream messaging API) #670 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/670 | 14:53 |
| toscalix | tiagogomes: did you change the name of the page from updates to news ? | 15:19 |
| toscalix | can it be turned back, please? | 15:19 |
| toscalix | 1.- we do not change names | 15:20 |
| toscalix | 2.- that link will also be for the blog, which is no news | 15:20 |
| toscalix | I chose that name base of the codethink page, which I think is an improvement | 15:20 |
| toscalix | and now there are links to it | 15:20 |
| toscalix | I would reaaaaally appreciate if we stop chenging names of pages | 15:21 |
| toscalix | adding pages, spliting pages, removing pages....at this point so we do not have to go back and fix what we did | 15:21 |
| toscalix | we can do that in a second round of effort in the near future | 15:21 |
| toscalix | tiagogomes: I am not saying you did it. I do not know who. I do not care honestly. I just want it back, if possible | 15:23 |
| tiagogomes | I didn't change the name of that page to news. Though it was discussed here and agreed that it would preferable. | 15:28 |
| *** lachlan has quit IRC | 15:28 | |
| toscalix | once again, people does not cosider the already done work and refuse to read the design document | 15:28 |
| toscalix | that page will have news.... and blog posts | 15:29 |
| tiagogomes | Regarding your last point, I wished when I started working on some feature / bug fix master was frozen so I never had to rebase my changes. However is not how collaborative work is done with git | 15:29 |
| paulsher1ood | toscalix: we discussed the change to news earlier today and got multiple +1s | 15:29 |
| paulsher1ood | it's a better word than updates | 15:30 |
| toscalix | did you guys consider that there will be blog posts there? | 15:30 |
| toscalix | just like in the codethink page? | 15:30 |
| paulsher1ood | blog posts can be considered news | 15:30 |
| toscalix | disagree completely..... let's move on | 15:30 |
| paulsher1ood | :) | 15:30 |
| paulsher1ood | tristan asked updates > news, qinusty and i were +1 | 15:32 |
| tiagogomes | If there were both 'news' and 'updates' links, I'd be confused | 15:32 |
| qinusty | Updates can be software updates. | 15:32 |
| qinusty | News is news | 15:32 |
| toscalix | paulsher1ood: did you guys paid attention to current links? | 15:34 |
| toscalix | not sure there is any pointing there | 15:34 |
| * qinusty is confused at why this is an issue. | 15:35 | |
| qinusty | If there are links, change them. If not, *shrug*. Renaming a page is not a massive issue at this stage. We're talking < 1m of effort. Changing at a later date may break public links from articles which we cannot change | 15:36 |
| *** iker has joined #buildstream | 15:55 | |
| *** lachlan has joined #buildstream | 16:00 | |
| *** iker has quit IRC | 16:00 | |
| *** lachlan has quit IRC | 16:03 | |
| *** lachlan has joined #buildstream | 16:09 | |
| mablanch | Any reason why running 'python setup.py test' would randomly stop at some point of the execution with 'Aborted'? | 16:18 |
| tiagogomes | at a random test? | 16:23 |
| gitlab-br-bot | buildstream: merge request (jmac/remote_execution_client->master: WIP: Remote execution client) #626 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/626 | 16:25 |
| WSalmon | who looks after https://gnome7.codethink.co.uk/tarballs/ and who build the arch image? | 16:27 |
| WSalmon | *alphine not arch.. | 16:29 |
| tpollard | does bst pull --deps (all) also bring in runtime dependencies? | 16:34 |
| mablanch | tiagogomes, As it seems yes... | 16:36 |
| tpollard | I'm trying to workout why a local artifact cache from bst build (when pulling from a remote) is smaller than when doing bst pull --deps all | 16:40 |
| tpollard | if it's bringing in runtimes then I guess it makes sense | 16:40 |
| tiagogomes | WSalmon I think you should ask on #freedesktop-sdk on freenode | 16:41 |
| tiagogomes | mablanch weird | 16:41 |
| tiagogomes | tpollard could it be because of the artifacts/extract directory | 16:45 |
| tpollard | hmm | 16:54 |
| *** phildawson has quit IRC | 17:01 | |
| *** lachlan has quit IRC | 17:07 | |
| gitlab-br-bot | buildstream: merge request (jmac/remote_execution_client->master: WIP: Remote execution client) #626 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/626 | 17:19 |
| *** jonathanmaw has quit IRC | 17:22 | |
| *** phildawson has joined #buildstream | 18:13 | |
| *** phildawson has quit IRC | 18:17 | |
| *** toscalix has quit IRC | 18:23 | |
| *** bochecha has joined #buildstream | 19:20 | |
| *** alatiera_ has quit IRC | 20:02 | |
| *** alatiera_ has joined #buildstream | 20:02 | |
| *** benschubert has quit IRC | 20:18 | |
| *** leopi has quit IRC | 20:56 | |
| *** tristan has joined #buildstream | 21:29 | |
| *** bochecha has quit IRC | 21:37 | |
| *** alatiera_ has quit IRC | 21:38 | |
| *** alatiera_ has joined #buildstream | 21:38 | |
| *** Prince781 has joined #buildstream | 22:16 | |
| *** alatiera_ has quit IRC | 22:25 | |
| *** tristan has quit IRC | 22:31 | |
| *** rdale has quit IRC | 23:00 | |
| *** Prince781 has quit IRC | 23:39 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!