| *** mattiasb has quit IRC | 01:04 | |
| *** Demos[m] has quit IRC | 01:04 | |
| *** albfan[m] has quit IRC | 01:04 | |
| *** rafaelff[m] has quit IRC | 01:04 | |
| *** m_22[m] has quit IRC | 01:04 | |
| *** awacheux[m] has quit IRC | 01:04 | |
| *** waltervargas[m] has quit IRC | 01:04 | |
| *** inigomartinez has quit IRC | 01:04 | |
| *** abderrahim[m] has quit IRC | 01:04 | |
| *** cgmcintyre[m] has quit IRC | 01:04 | |
| *** segfault3[m] has quit IRC | 01:05 | |
| *** connorshea[m] has quit IRC | 01:05 | |
| *** tlater[m] has quit IRC | 01:05 | |
| *** dineshdb[m] has quit IRC | 01:05 | |
| *** oknf[m] has quit IRC | 01:05 | |
| *** albfan[m] has joined #buildstream | 01:22 | |
| *** rafaelff[m] has joined #buildstream | 01:28 | |
| *** mattiasb has joined #buildstream | 01:30 | |
| *** m_22[m] has joined #buildstream | 01:40 | |
| *** awacheux[m] has joined #buildstream | 01:40 | |
| *** waltervargas[m] has joined #buildstream | 01:47 | |
| *** Demos[m] has joined #buildstream | 01:59 | |
| *** inigomartinez has joined #buildstream | 02:05 | |
| *** abderrahim[m] has joined #buildstream | 02:14 | |
| *** cgmcintyre[m] has joined #buildstream | 02:16 | |
| *** segfault3[m] has joined #buildstream | 02:26 | |
| *** connorshea[m] has joined #buildstream | 02:27 | |
| *** tlater[m] has joined #buildstream | 02:33 | |
| *** dineshdb[m] has joined #buildstream | 02:34 | |
| *** oknf[m] has joined #buildstream | 02:37 | |
| *** leopi has joined #buildstream | 04:36 | |
| juergbi | coldtom: Qt's make install does appear to support INSTALL_ROOT. This doesn't work properly? | 05:43 |
|---|---|---|
| coldtom | freedesktop-sdk uses DESTDIR, I didn't know INSTALL_ROOT existed, I'll try it now juergbi | 06:08 |
| *** tristan has joined #buildstream | 06:08 | |
| *** leopi has quit IRC | 06:30 | |
| *** leopi has joined #buildstream | 06:35 | |
| coldtom | juergbi: it builds! Just need to make sure it's configured correctly now | 06:45 |
| juergbi | great | 06:46 |
| *** toscalix has joined #buildstream | 07:53 | |
| qinusty | tlater[m], retries are kinda tested. They're not interactive. We simply cause an issue which will trigger the retries until failure. Then check the "Try #" string is within the stderr | 08:05 |
| toscalix | qinusty: what is it needed to merge your MR 31 in website ? | 08:08 |
| toscalix | I would like to finish the page | 08:08 |
| qinusty | I left a comment, there are some questions which I do not believe I can answer in a meaningful way | 08:09 |
| toscalix | I will try | 08:09 |
| qinusty | feel free to push to the branch | 08:10 |
| toscalix | qinusty: can you merge it? | 08:12 |
| qinusty | Sure | 08:13 |
| Kinnison | tristan: I've referenced the relevant RPCs on #554 | 08:26 |
| *** alatiera_ has joined #buildstream | 08:27 | |
| Kinnison | tlater[m]: thanks for shepherding !778 last night, I wasn't expecting that quick a response :-) | 08:29 |
| *** rdale has joined #buildstream | 08:33 | |
| tristan | Kinnison, So last time juergbi and I spoke about this; he said it was the next part of his work already - has this changed ? | 08:38 |
| tristan | juergbi, ^^ ? | 08:38 |
| Kinnison | tristan: I don't know if juergbi has been working on bst-artifact-server and friends, I know he's been focussed a lot on buildbox of late. | 08:39 |
| juergbi | tristan: no, I'm working on batch support in buildbox right now | 08:39 |
| juergbi | buildstream side is right after that | 08:39 |
| tristan | Ok, so porting that is probably very straight forward ? | 08:39 |
| juergbi | (it started a bit later due to investigation of buildbox issues and some other tasks) | 08:40 |
| Kinnison | Adding support to bst-artifact-server should be pretty easy. Reworking cascache.py's fetchers might be a smidge more complex but not too hard. | 08:40 |
| juergbi | I expect the port to be relatively straight forward, yes | 08:40 |
| tristan | Great to hear; I've been counting on it :) | 08:40 |
| qinusty | I was considering getting some GIFS of buildstream UI, found a bug in asciicast2gif for asciinema :( START messages are grey for some reason https://i.imgur.com/VDgwxoU.jpg | 08:41 |
| mablanch | juergbi, Have you ever had problems with BuildStream tests hanging when using the ArtifactShare util? | 08:42 |
| tristan | tlater[m], Dont know if you are around but; I have a partial fix for the local cleanup crashes | 08:46 |
| tristan | tlater[m], and some questions | 08:46 |
| tristan | tlater[m], On top of the changes we already discussed, I had to make the cache_size job NOT require the artifact cache exclusively; that seems fine to do anyway because we will always recheck the size after something was added | 08:47 |
| tristan | tlater[m], My main question is; Why do we not launch a cache_size job in response to a build job completing, like we do for a pull job ? | 08:47 |
| tristan | tlater[m], My secondary question is; Why do we allow more than one cache_size job to be in the queue ? It seems I see like 10 of them run in sequence, silly | 08:48 |
| juergbi | mablanch: during CAS development I experienced hangs but I don't think I've seen it hang since it was merged | 08:50 |
| mablanch | juergbi, OK, I'll investigate, thank you. | 08:51 |
| *** tristan has quit IRC | 08:52 | |
| *** jonathanmaw has joined #buildstream | 08:55 | |
| tlater[m] | tristan: I don't think there's a problem if the cache size job doesn't require the cache either, that seems right. | 09:24 |
| tlater[m] | As for the multiple cache size jobs in the queue, that should definitely not happen. I'm not sure why it does yet. | 09:27 |
| tiagogomes | tristan for your first question, the reason is that for build jobs we can determine the size of the artifact committed and dynamically update the cache size with that information. For pull jobs, right now, you can't do that | 09:28 |
| tiagogomes | https://gitlab.com/BuildStream/buildstream/merge_requests/671 adds support for dynamically update the cache size for pull jobs as well, so that cache size job is no longer needed | 09:29 |
| *** tristan has joined #buildstream | 09:29 | |
| *** ChanServ sets mode: +o tristan | 09:29 | |
| tlater[m] | tristan asks this the other way around, tiagogomes, but I suppose that is a typo unless he found a pretty big bug. | 09:30 |
| tlater[m] | tristan: On the second question, I don't exactly know why multiple are being launched. I don't think there are multiple in the queue simultaneously though. | 09:33 |
| tlater[m] | As far as I can tell, as long as the cache is empty, buildstream will launch a cache size job as long as there is not one already running | 09:34 |
| tlater[m] | That *is* silly. I think there's a check somewhere that launches a job when we don't know the size, which much be triggered by 0 | 09:35 |
| tristan | cache key empty ? | 09:35 |
| tristan | What is an empty cache key ? | 09:36 |
| tlater[m] | Umm, there's no key in that sentence for me | 09:36 |
| tristan | oops | 09:36 |
| tristan | Ok, as long as the cache is empty, still makes no sense ? | 09:36 |
| tristan | if the cache is empty, we dont need to calculate it's size | 09:37 |
| tlater[m] | I agree, this is a bug | 09:37 |
| tlater[m] | I didn't see this when I landed the patch originally | 09:37 |
| tristan | (A) We should queue a CacheSize job only if none is already pending and waiting to run... (B) It should be triggered by virtue of a build job or pull job having completed | 09:38 |
| tristan | I will update my branch with the added local change, which makes the CacheSize Job not exclusively require the CACHE resource | 09:39 |
| * tiagogomes sighs | 09:39 | |
| tlater[m] | tristan: Are you sure multiple are queued together? | 09:39 |
| tiagogomes | Have you read what I wrote above? | 09:39 |
| tristan | We dont need to wait for all build + pull jobs to complete before calculating the size | 09:39 |
| tristan | I didnt check the logs since I got back yet, no | 09:39 |
| * tristan checks the baserock irc log thingy | 09:39 | |
| tiagogomes | <tiagogomes> tristan for your first question, the reason is that for build jobs we can determine the size of the artifact committed and dynamically update the cache size with that information. For pull jobs, right now, you can't do that | 09:40 |
| tiagogomes | <tiagogomes> https://gitlab.com/BuildStream/buildstream/merge_requests/671 adds support for dynamically update the cache size for pull jobs as well, so that cache size job is no longer needed | 09:40 |
| tristan | tiagogomes, Does it do that *right now* ? I think that is a bit more complex | 09:41 |
| tristan | If a build & pull job calculates how much it will add to the cache, then it needs to lock the cache_size file for read/add/write | 09:42 |
| *** lachlan has joined #buildstream | 09:42 | |
| tristan | Currently the last cache_size job updates the file atomically | 09:42 |
| tristan | Maybe that approach is a bit more risky in a situation where we just need it to not crash and pretty much work ? | 09:42 |
| tlater[m] | tristan: The dynamic update is not written to the file. Buildstream pretends to know the size and double checks before it starts cleaning. | 09:43 |
| tristan | Also, tiagogomes: It is untrue that the build job can have any idea how much it will be able to add to the cache | 09:43 |
| tiagogomes | tristan yup, due deduplication done by cas | 09:43 |
| tristan | Right | 09:43 |
| tiagogomes | But it is what I think it happens now. grep for _add_artifact_size | 09:44 |
| tristan | sheesh, okay so we first had an in memory cache of the size... and now we *added* this cache_size file... but those two values are not in sync ??? | 09:44 |
| tlater[m] | Yes, it is. I did that to avoid launching a calculation job every time we finish a build. | 09:44 |
| tiagogomes | And I think that dynamic update is committed to disk | 09:44 |
| tristan | Hmmm | 09:44 |
| tiagogomes | I mean, the dynamic cache size calc | 09:44 |
| tlater[m] | Oh, it is? I'm not up to date on the file yet. | 09:45 |
| tristan | Ok so I have a crashing cleanup job in production - what is the *simplest* way to fix this ? | 09:45 |
| tristan | The cache size job seems to really not take a lot of time | 09:45 |
| tlater[m] | That changes with a huge cache | 09:46 |
| tristan | How huge ? mine was 24GB the other day | 09:46 |
| tristan | Also, remember that we ensured that we only now calculate the cas subdirectory | 09:46 |
| tristan | And we cleanup the associated extracts as well | 09:47 |
| tristan | So it should be much smaller; valentind had some metrics for this | 09:47 |
| tlater[m] | Ok, but I feel like someone might still end up with a multiple-terabyte cache | 09:47 |
| tlater[m] | After a long time of building... | 09:48 |
| tristan | tlater[m], in other words; for all real world use cases we have *today*, a simpler approach can fix it | 09:48 |
| tiagogomes | I would argue that 24GB is not a considerable cache. Probably you need more just for freedesktop sdk | 09:48 |
| tristan | tlater[m], And by the time we end up enhancing the CAS to actually *really* tell us how many bytes a commit added, and how many bytes a prune removed... then it will be an appropriate time to do the more complex thing ? | 09:49 |
| tristan | tiagogomes, freedesktop SDK costed me ~10GB, indeed | 09:50 |
| tlater[m] | Yeah, that makes sense | 09:50 |
| tristan | I am more interested in not having a crash than reaching for the moon here | 09:50 |
| tiagogomes | ooc what is the crash | 09:51 |
| tlater[m] | But does this have anything to do with the crash? I thought that was caused by having a clean and a pull job run simultaneously? | 09:51 |
| tristan | This is an emergency change which has to land like yesterday; we shoulnt be talking about making things more enhanced | 09:51 |
| tristan | tiagogomes, it starts here: https://gitlab.com/BuildStream/buildstream/issues/623 | 09:52 |
| tristan | tiagogomes, what happens is that currently we have pull/build running in parallel with cleanup; as it was not properly set to be exclusive | 09:52 |
| tristan | So it first corrupts your artifact cache at prune time | 09:52 |
| tristan | Then it crashes during remove, because stuff is being added at the same time | 09:53 |
| tristan | It will probably crash in other interesting ways as soon as you corrupt your cache | 09:53 |
| tiagogomes | aah, still this one, but i thought you had a patch to have build and pull jobs to acquire the cache as resource | 09:53 |
| tristan | I have been trying to test it ! and I added another thing to it last night; which I still have to put up on the MR | 09:54 |
| tristan | I am asking questions because related to that; it looks like we're only caring about pulls but ignoring that builds can add size (thanks for clarifying that is not the case) | 09:54 |
| tristan | And that we are running redundant jobs, when only the last one needs to run | 09:54 |
| tristan | It would be good to fix the server side part of this with the same 1.2.1 release, also :-S | 09:55 |
| tristan | that is a current pain point; we're manually zapping caches cause the server side crashes instead of cleaning up | 09:55 |
| tristan | I wonder if the bst-artifact-server is properly making cache cleanups exclusive to cache additions | 09:56 |
| *** lachlan has quit IRC | 09:56 | |
| tlater[m] | tristan: I'll take a closer look at the multiple jobs launching issue in a bit | 09:59 |
| tristan | I think that we can still rule that out as: Freaking weird but not necessarily related to fixing the crash | 10:00 |
| tlater[m] | Do you still see a crash with the current patches? | 10:00 |
| qinusty | Can someone direct me towards what CAS is outside of buildstream? | 10:01 |
| qinusty | Intel CAS? | 10:01 |
| paulsher1ood | it's not intel cas | 10:02 |
| qinusty | CAS means a lot of things apparently | 10:02 |
| paulsher1ood | it's bazel cas | 10:02 |
| paulsher1ood | https://docs.bazel.build/versions/master/remote-caching.html | 10:02 |
| juergbi | spec is here https://github.com/bazelbuild/remote-apis | 10:03 |
| qinusty | Thanks paulsher1ood, juergbi | 10:04 |
| qinusty | Is someone fixing the buildstream.build links? or should I include it in my next Mr | 10:12 |
| qinusty | s/Mr/MR* | 10:12 |
| *** lachlan has joined #buildstream | 10:12 | |
| toscalix | I am working on the FAQ. Then the feature page, although I will need help there | 10:13 |
| tiagogomes | qinusty I just sent a MR | 10:13 |
| qinusty | nice, I'll review it quickly | 10:14 |
| tristan | tlater[m], I was only able to confirm that cleanup no longer runs concurrently with the others; when cleanup runs it consistently crashes cause the damage was done | 10:17 |
| qinusty | looks good to go tiagogomes :D | 10:17 |
| tristan | tlater[m], So I zapped my cache and I'm building gnome-build-meta a lot, trying to get a cache with enough disposable artifacts to test it | 10:17 |
| tristan | I will try with an older ref of freedesktop-sdk, then update again, that'll do it | 10:18 |
| toscalix | tiagogomes: I prefer the way you suggested me for ordering the links because it will be easier to extract the contents and paste them in a different tool/format | 10:18 |
| qinusty | ordering links? | 10:19 |
| tristan | toscalix, I'm not sure what this is about, but I would recommend against the way you put the links in portfolio.md (i.e. [Link text here] ... and then all the [Link text here]: http://link.target.com entries at the end) | 10:20 |
| tristan | toscalix, in general this is harder to maintain over time because the targets are separate from the links | 10:20 |
| tristan | When things change you have to update them in two places | 10:21 |
| toscalix | tristan: that is a different point and, as I mentioned earlier, I learnt about it yesterday afternoon so I am following it now | 10:21 |
| tristan | toscalix, :) | 10:21 |
| tristan | toscalix, I was just missing context, I know you learned about relative links from your earlier mention, I didnt know you learned about [Link Name](link_target.html) :) | 10:22 |
| * tristan fixes the remaining hard coded links that he missed in the previous round, from 2018 directory | 10:23 | |
| * qinusty also did this | 10:23 | |
| tristan | Notice that some links were broken due to using the [Link Name]({filename}pony.md) usage | 10:23 |
| tiagogomes | tristan I feel the opposite way. Having long URLs in the middle of content makes harder to review and edit the content | 10:23 |
| qinusty | Wait git fetch tristan, tiago fixed the ## about section | 10:23 |
| tristan | That pelican markdown feature doesnt work | 10:23 |
| tristan | qinusty, ok gotcha | 10:24 |
| qinusty | But when you want to replace the text for the hyperlink tiagogomes, you replace it in two places | 10:24 |
| tiagogomes | So? How often are you going to do that? | 10:24 |
| qinusty | I'm doing it rn while checking for grammar/spelling :D | 10:24 |
| *** lachlan has quit IRC | 10:24 | |
| tristan | Often enough for it to matter, also a bottom section of link target indexes will go stale; links will disappear from the text and fail to disappear from the bottom, deadcode crops up | 10:25 |
| qinusty | I would review the website stuff in a browser anyway | 10:25 |
| qinusty | I checkout, make html, make serve and check the page. so I don't see the whole [...](....) | 10:25 |
| tristan | Readability of the markdown is still important; but you get used to the links | 10:25 |
| tiagogomes | True as well, but I still very much prefer not having URLs polluting the content | 10:25 |
| qinusty | Tbh, it'd be okay if we could could do a sort of referencing | 10:26 |
| tristan | That's why it also sucks to have lines which trail over 120 characters | 10:26 |
| qinusty | If we could place the LINK at the bottom, and [@1] where 1 is referenced below | 10:26 |
| tristan | I find it tiresome to put the link at the bottom and remember to put all the links | 10:26 |
| * qinusty wonders if such a plugin exists | 10:26 | |
| tristan | And the worst is; a combination of both | 10:26 |
| qinusty | I just find referencing the TEXT at the bottom | 10:27 |
| qinusty | is a slightly ridiculous concept | 10:27 |
| tristan | Most links are pretty short, as they are internal references | 10:27 |
| qinusty | Like a lookup table | 10:27 |
| tiagogomes | oh yeah, for internal references inline links are better. But for external URLs I prefer them to be defined at the bottom for the reasons I wrote above | 10:28 |
| tristan | tiagogomes, But a combination of both invites the patch submitter to choose, which means we end up with a bit of a mess | 10:29 |
| tiagogomes | I don't think internal inlines and external separate are much of a mess :) | 10:29 |
| tristan | tiagogomes, but someone who didnt talk to us first, will not know the difference, they will certainly do something different | 10:31 |
| qinusty | tiago, do you use vim? :D | 10:31 |
| tristan | that's what I mean, combination of both invites the submitter to choose | 10:31 |
| qinusty | https://github.com/plasticboy/vim-markdown can conceal links I believe. Increasing readability | 10:32 |
| tristan | Ok so... at this point https://buildstream.build/source_install.html#installing_dependencies seems to be fixed with the ToC ordering, no only the CSS changed, I'll fix that | 10:32 |
| tristan | Let's make a cleaner difference between the hierachy of headings | 10:33 |
| tristan | Debian is incorrectly a child of Arch linux in the ToC | 10:33 |
| tiagogomes | I use vim but I am cursing it that is collapsing sections or rst files! | 10:33 |
| tristan | But *appears* to be separate in the text | 10:33 |
| tristan | looks like h1 and h2 render the same way, causing this | 10:33 |
| tiagogomes | h1 should be reserved for the page title. So markdown should start with ## forward | 10:34 |
| tristan | Ok, h2 and h3 also look very similar, though | 10:34 |
| tristan | Let's make h2 bold at least | 10:34 |
| tristan | So that h3 children at least appear to be children | 10:34 |
| tristan | ok that was a one line change | 10:36 |
| tristan | gitlab not accepting pushes now ? | 10:37 |
| tristan | oops my fault, sorry for noise | 10:37 |
| qinusty | Making up for the lack of gitlab bot noise lately :D | 10:38 |
| tristan | Yep :) | 10:39 |
| tristan | Someone's gotta do it | 10:39 |
| tiagogomes | tbh, this all looks bad. I don't know if we should experiment with another theme instead of trying to fix this one | 10:39 |
| tristan | That is also a good idea | 10:40 |
| tristan | tiagogomes, Can we find a theme which renders <pre> sections with nice little boxes for the code examples ? | 10:40 |
| tiagogomes | This exists http://www.pelicanthemes.com/ | 10:40 |
| tiagogomes | The default theme does that :P | 10:40 |
| tristan | tiagogomes, I'll fix the broken annotations in the meantime | 10:40 |
| tristan | Oh, so why are we not using that ? | 10:40 |
| tristan | Well, I guess it's ugly for other reasons | 10:41 |
| tiagogomes | well, comment the THEME=theme line and see it for yourself :) | 10:41 |
| tristan | Aha, it's the indentation, it wants exactly 4 spaces | 10:42 |
| * tristan is fixing the :::shell problems for the moment, will get back... | 10:42 | |
| qinusty | Is there any way of `make serve` refreshing on change files? | 10:43 |
| qinusty | similar to how django `manage.py runserver` does | 10:43 |
| tiagogomes | There is a `make devserver`, but I never tested it | 10:43 |
| qinusty | develop_server.sh seems to be broken | 10:45 |
| tristan | Is it supposed to be ::shell ? or :::shell ? | 10:45 |
| qinusty | where'd you get it from? | 10:45 |
| tristan | Seems they are both doing the right thing, which is odd | 10:45 |
| qinusty | http://docs.getpelican.com/en/3.6.3/content.html ::: | 10:45 |
| qinusty | I think the css is just more the issue | 10:46 |
| qinusty | not the generation of html | 10:46 |
| qinusty | It generates the code blocks as expected | 10:46 |
| tristan | qinusty, I found an instance of "::shll" instead of ":::shell" | 10:48 |
| qinusty | D: | 10:49 |
| tristan | qinusty, I think the ::shll was "swallowed up", and it just looked the same because syntax highlighting is not doing anything nice for shell commands, and it's already in <pre> | 10:49 |
| tristan | So it looks the same | 10:49 |
| qinusty | Yeah our <pre> <code> css is just not what we expect when we think code block | 10:49 |
| tristan | Of course, pelican doesnt even tell us about the error/warning when it swallows up an invalid "::shll" | 10:49 |
| qinusty | \o/ | 10:50 |
| *** lachlan has joined #buildstream | 10:51 | |
| tiagogomes | tristan it really can't. For it ::shll is just some random text you wrote | 10:52 |
| tristan | tiagogomes, Except it was not showing up, at least I think it wasnt | 10:52 |
| tiagogomes | aah | 10:52 |
| tristan | yeah it wasnt, just tested it | 10:52 |
| tristan | It did a code block for it, because of proper indentation; the ::shll just went away | 10:53 |
| tristan | But anyway, moving to the next | 10:53 |
| tristan | tiagogomes, commenting out the THEME= makes things much better indeed, *except* for all this weird noise below the menubar and above the page content | 10:53 |
| tristan | lets find a decent theme... | 10:53 |
| *** WSalmon_ has quit IRC | 10:56 | |
| tristan | Hmm, http://www.pelicanthemes.com/ blueidea looks good, but the syntax highlight does nothing, and still places all this weird shit under the menubar and before the content | 10:58 |
| tristan | I think that is a problem with our site, not the theme | 10:58 |
| *** WSalmon has joined #buildstream | 10:58 | |
| tristan | tiagogomes, notice all the buttons under the menubar and before the page when you comment out the theme ? | 10:58 |
| tiagogomes | I was trying alchemy | 10:59 |
| tristan | oops, (backwards)[link] in install, /me fixes that one... | 11:00 |
| tiagogomes | The default theme doesn't use MENUITEMS, so it puts a link to every page there, which won't fir | 11:01 |
| tiagogomes | fit | 11:01 |
| tristan | tiagogomes, How come I see a menubar with [Portfolio, Install, Updates, Community, FAQ, BuildStream in Detail] at the top ? | 11:04 |
| tristan | Ohhh | 11:05 |
| tristan | It just decided that those were the menubar by itself | 11:05 |
| tristan | So... maybe MENUITEMS sucks ? | 11:05 |
| tiagogomes | why does it suck? | 11:05 |
| tristan | tiagogomes, I have a *feeling*, that we are supposed to put things that dont belong in the menubar, into subfolders ? | 11:05 |
| tristan | And then any theme we want will "just work" ? | 11:05 |
| tristan | Just a guess | 11:05 |
| tristan | I mean, I guess we can opt for a theme that supports MENUITEMS, and have the liberty to at least order the toplevel pages | 11:06 |
| tristan | and no it doesnt "suck", just makes us a bit less free to rely on it | 11:06 |
| tiagogomes | Looking at the templates, that wouldn't work | 11:06 |
| tristan | tiagogomes, how does alchemy look ? | 11:06 |
| tiagogomes | I looks much better. Codeblocks are not working though | 11:07 |
| qinusty | not working? Or not styled as we'd like? | 11:08 |
| qinusty | we can restyle | 11:08 |
| tristan | qinusty, That's what we're trying to avoid by looking for another theme | 11:09 |
| tristan | <tiagogomes> tbh, this all looks bad. I don't know if we should experiment with another theme instead of trying to fix this one | 11:09 |
| tristan | qinusty, ^^^ | 11:09 |
| qinusty | Okay but, if it's a matter of sticking a border on it. And changing the font | 11:09 |
| qinusty | The theme has more issues than the code blocks :D | 11:10 |
| qinusty | as tiago said | 11:10 |
| tristan | Better a single fix that actually fixes it, rather than doing down the web rabbit hole | 11:10 |
| qinusty | web *shivers* | 11:10 |
| tiagogomes | tristan I think alchemy is much nicer than the previous one | 11:10 |
| tiagogomes | And the codeblocks were not working in the previous one as well | 11:10 |
| tiagogomes | I think it is not working because we need to add codehilite to the markdown extensions | 11:10 |
| tristan | qinusty, I've done web before *shudders*, whenever you put a CSS attribute, be sure to consult MDN that it is supported on all browsers, find the hacks to make it work on all browsers, yada yada | 11:11 |
| tristan | A good theme should do it for us | 11:11 |
| tristan | tiagogomes, it's in pelicanconfig.py at the bottom in MARKDOWN | 11:11 |
| tristan | not done correctly you think ? | 11:11 |
| tristan | tiagogomes, you are right, I have a fix | 11:16 |
| tristan | Except, it's not rendering well | 11:16 |
| tristan | https://github.com/getpelican/pelican/issues/2091#issuecomment-274313105 | 11:16 |
| tristan | The boxes show up with round edges, but then are clipped with a little black box | 11:17 |
| tristan | But I think the fix is still correct | 11:17 |
| tristan | With blueidea, they work wonderfully | 11:17 |
| tristan | Fixed | 11:20 |
| tiagogomes | erm | 11:22 |
| tiagogomes | I don't think you can simply add 'markdown.extensions.codehilite' to 'extensions' | 11:22 |
| tristan | Crap, it didnt work | 11:22 |
| tristan | tiagogomes, that's not all I did | 11:22 |
| tristan | It worked locally :-S | 11:23 |
| tiagogomes | You only need to add `'css_class': 'highlight'` | 11:23 |
| tristan | tiagogomes, I followed this: https://github.com/getpelican/pelican/issues/2091#issuecomment-274313105 | 11:23 |
| tristan | It should both list the extensions, AND add their configuration | 11:23 |
| * tristan does a clean build and sees if some stale rubbish caused it to work | 11:24 | |
| tiagogomes | Did you tried with the theme we are using, probably that's the problem | 11:24 |
| tristan | Still works locally | 11:25 |
| tristan | tiagogomes, Nope | 11:25 |
| tristan | tiagogomes, With the current theme we use, it does round edge boxes which are still better than nothing | 11:25 |
| tristan | With blueidea, it's high contrast invert black boxes which are much sexier | 11:26 |
| tristan | Both work | 11:26 |
| tiagogomes | perhaps the container image needs pygments? | 11:26 |
| tristan | The current theme has these black corners around the round edge boxes | 11:26 |
| tristan | Maybe, what is that ? | 11:26 |
| tristan | Can we install it in CI ? | 11:26 |
| tiagogomes | Some dependency | 11:26 |
| tristan | Instead of manufacturing a new image | 11:27 |
| tiagogomes | ah yeah, that's what I meant | 11:27 |
| tristan | I wonder if I have that | 11:27 |
| tiagogomes | what `pygmentize -L` does on your machine | 11:27 |
| tristan | Yep, have that | 11:28 |
| *** krichter[m] has quit IRC | 11:30 | |
| *** pro[m] has quit IRC | 11:30 | |
| *** cgmcintyre[m] has quit IRC | 11:30 | |
| *** oknf[m] has quit IRC | 11:30 | |
| *** segfault3[m] has quit IRC | 11:30 | |
| *** Demos[m] has quit IRC | 11:30 | |
| *** mattiasb has quit IRC | 11:31 | |
| *** asingh_[m] has quit IRC | 11:31 | |
| *** doras[m] has quit IRC | 11:31 | |
| *** kailueke[m] has quit IRC | 11:31 | |
| *** theawless[m] has quit IRC | 11:31 | |
| *** jjardon[m] has quit IRC | 11:31 | |
| *** alatiera has quit IRC | 11:31 | |
| *** dineshdb[m] has quit IRC | 11:31 | |
| *** tlater[m] has quit IRC | 11:31 | |
| *** awacheux[m] has quit IRC | 11:31 | |
| *** connorshea[m] has quit IRC | 11:31 | |
| *** abderrahim[m] has quit IRC | 11:31 | |
| *** inigomartinez has quit IRC | 11:31 | |
| *** waltervargas[m] has quit IRC | 11:31 | |
| *** m_22[m] has quit IRC | 11:31 | |
| *** rafaelff[m] has quit IRC | 11:31 | |
| *** albfan[m] has quit IRC | 11:31 | |
| *** ssssam[m] has quit IRC | 11:31 | |
| toscalix | tiagogomes: do you know why https://gitlab.com/BuildStream/website/merge_requests/51 does not require me approval to be merge? | 11:31 |
| *** abderrahim has joined #buildstream | 11:31 | |
| * tristan runs test with pygments | 11:32 | |
| tristan | tiagogomes, fixed, notice that the boxes still dont render well, though | 11:34 |
| tristan | They appear intended to be round edged, but have some black pointy edges | 11:34 |
| tristan | That'll still work once we find a decent new theme, though | 11:34 |
| tiagogomes | toscalix your approval? I am confused, you created the MR | 11:34 |
| tristan | And probably work much more nicely than this theme | 11:34 |
| tristan | Ah | 11:35 |
| tristan | toscalix, I disabled that this morning while fixing stuff, wasnt going to wait around | 11:35 |
| tristan | I've fixed dozens of things in the last 30 minutes which would have been impossible if using the "Approvals" feature | 11:35 |
| tristan | I *also* added the setting to ensure linear history, this thing was setup to allow server side merge / commit | 11:36 |
| tristan | tiagogomes, Are you hunting for a decent theme ? I have a SotK sitting in #pelican who suggested https://github.com/getpelican/pelican-themes/search?q=MENUITEMS as a starting point to find themes with support for MENUITEMS | 11:38 |
| *** m_22[m] has joined #buildstream | 11:38 | |
| tristan | Fancy seeing him there ;-) | 11:38 |
| tiagogomes | Is not very difficult to tame any theme to support MENUITEMS | 11:39 |
| toscalix | it would be good to keep track of the technical work done on the website on this ticket https://gitlab.com/BuildStream/website/issues/9 | 11:39 |
| tiagogomes | - {% for page in pages %} | 11:39 |
| tiagogomes | + {% for title, link in MENUITEMS %} | 11:39 |
| tiagogomes | - {% for page in pages %} | 11:40 |
| tiagogomes | + {% for title, link in MENUITEMS %} | 11:40 |
| tiagogomes | - <li class="list-inline-item"><a href="{{ SITEURL }}/{{ page.url }}">{{ page.title }}</a></li> | 11:40 |
| tiagogomes | + <li class="list-inline-item"><a href="{{ link }}">{{ title }}</a></li> | 11:40 |
| *** dtf has joined #buildstream | 11:49 | |
| tristan | tiagogomes, have you tried that ? | 11:51 |
| tiagogomes | yes | 11:51 |
| tristan | tiagogomes, anyway can I leave theme selection in your hands now ? | 11:51 |
| tristan | I like blueidea but... honestly I havent tried a bunch of them | 11:52 |
| tristan | I'm sure there is better | 11:52 |
| tristan | Let me get a fix in for that crash, at least it's a partial fix | 11:52 |
| tristan | And look at WSalmon's issue if I can still find it in my million open browser tabs... | 11:53 |
| bethw | tristan, I guess that's 512 if that helps in your search | 11:54 |
| bethw | https://gitlab.com/BuildStream/buildstream/issues/512 | 11:55 |
| tristan | bethw, I dont know, I found the browser tab | 11:56 |
| tristan | bethw, but it seems that https://gitlab.com/BuildStream/buildstream/merge_requests/776/ doesnt mention that issue | 11:56 |
| *** SotK has joined #buildstream | 11:58 | |
| * SotK waves | 11:58 | |
| SotK | I saw in the logs your theme problems involve weird code blocks and took a look to see whats causing it | 11:59 |
| bethw | tristan, then ignore me, I'm thinking of something else | 12:00 |
| SotK | https://gitlab.com/BuildStream/website/blob/master/theme/static/css/style.css#L65 sets a grey background and border (with radius) on the <pre> elements, but https://gitlab.com/BuildStream/website/blob/master/theme/static/css/pygments.css#L2 sets a dark background on the <div> that wraps it (without any radius) | 12:01 |
| SotK | so your dark corners are the dark background from pygments not covered up by the opaque grey <pre> because of the border-radius | 12:01 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-cache-exclusivity->master: _scheduler/queues: Mark build and pull queue as requiring shared access to the CACHE) #775 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/775 | 12:02 |
| SotK | assuming you want dark boxes just remove the border and background properties from .highlight > pre in style.css | 12:02 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-cache-exclusivity-1.2->bst-1.2: Tristan/fix cache exclusivity 1.2) #779 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/779 | 12:03 |
| tristan | SotK, For now; I think that basically we agree that we need to choose a theme because the current one sucks | 12:05 |
| tristan | SotK, And that should be done before tweaking CSS manually | 12:05 |
| tristan | SotK, I assume you've seen already, e.g.: https://buildstream.build/source_install.html#stretch ? | 12:06 |
| tristan | Yeah I would guess since you've seen the blocks | 12:07 |
| tristan | But another problem is that h2, h3, etc are hardly distinguishable | 12:07 |
| tristan | And we've already tweaked that; so - still it's better to find a saner theme first | 12:07 |
| SotK | yeah, if you uncheck border and background in your browser inspector the blocks actually look pretty nice | 12:07 |
| SotK | but I agree with your analysis of the theme :) | 12:08 |
| SotK | I've yet to find a pelican theme that I like enough to recommend for general use, thats why I just write custom ones when I want a pelican thing | 12:09 |
| tristan | heh | 12:09 |
| SotK | (or more accurately, design a mockup in plain html/css and then convert that to a pelican theme) | 12:09 |
| tristan | Yeah I liked blueidea, it had smaller text in the code blocks and highcontrast invert on the them, which is sexy | 12:09 |
| tristan | h1, h2, ... also seemed saner; but - I havent tried a lot - I actually just looked on the page for one that looked okay and tried that one heh | 12:10 |
| tristan | The menubar is so 90s, can't believe I find myself saying that - I still think complex application UIs should have menubars, some reason I feel differently about web pages :-S | 12:11 |
| gitlab-br-bot | buildstream: issue #626 ("Cancel pending remote execution requests on shutdown") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/626 | 12:18 |
| SotK | heh, I'm not religiously opposed to simple menu/navigation bars but I prefer them when they look nice | 12:18 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: WIP: out of sourec builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 12:20 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: WIP: out of sourec builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 12:20 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-cache-exclusivity->master: _scheduler/queues: Mark build and pull queue as requiring shared access to the CACHE) #775 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/775 | 12:21 |
| *** solid_black__ has joined #buildstream | 12:21 | |
| WSalmon | sorry bethw and tristan i did want you to look at https://gitlab.com/BuildStream/buildstream/merge_requests/776/ the message was just saying this is all very wip but it also now says that it is related to #512 | 12:21 |
| gitlab-br-bot | buildstream: merge request (tristan/fix-cache-exclusivity-1.2->bst-1.2: Tristan/fix cache exclusivity 1.2) #779 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/779 | 12:21 |
| qinusty | Can I get a review of https://gitlab.com/BuildStream/website/merge_requests/48? | 12:25 |
| tristan | qinusty, I'm seeing whitespace changes and fixing of links | 12:26 |
| tristan | With the addition of some more interesting links | 12:26 |
| tristan | qinusty, is that all this changes ? | 12:26 |
| * qinusty cannot actually merge himself | 12:26 | |
| tristan | qinusty, done, lemme add you to the website project... | 12:27 |
| tristan | WSalmon, I especially dislike that you are staging the sources not in %{build-root} anymore, but I think this might be alright so long as the contract is very very clear | 12:28 |
| tristan | WSalmon, gimme a sec... | 12:28 |
| qinusty | Cheers, I do think that people should have their MRs atleast looked over for the website though. Rather than self merging. It can help reduce the number of grammatical/readability issues | 12:28 |
| tristan | qinusty, Added you | 12:29 |
| qinusty | ty | 12:29 |
| tiagogomes | tristan, the website with alchemy https://gitlab.com/BuildStream/website/-/jobs/94888715/artifacts/download | 12:29 |
| tristan | qinusty, I agree, but there is a limit to that - if we put you member that means we trust you wont do stuff you think might be destructive | 12:29 |
| paulsher1ood | .wub 34 | 12:30 |
| paulsher1ood | bah | 12:30 |
| tristan | tiagogomes, I think you mean: https://buildstream.gitlab.io/-/website/-/jobs/94888715/artifacts/output/index.html | 12:30 |
| tiagogomes | No. I meant to download the tarball. But your way is better :) | 12:31 |
| tristan | tiagogomes, Looks sober and nice to me :) | 12:31 |
| tiagogomes | there are broken links in buildstream.build :( | 12:31 |
| tristan | tiagogomes, Those might be fixed by qinusty's latest thing, not sure | 12:32 |
| tristan | Where are the broken links ? | 12:32 |
| qinusty | In the release article, there were 2 more I fixed | 12:32 |
| tiagogomes | Go to updates, open an article, and them try to use the nav bar | 12:32 |
| tiagogomes | *then | 12:32 |
| WSalmon | tristan, my first thougth was to get the source to use the elements directory variable and reuse that as its directory variable unless it redeclared it but this methord was sugested as a cleaner way but i dont mind how i do it i was just looking for a nice consistent way.. | 12:32 |
| qinusty | git grep shows none in my latest branch tiagogomes | 12:33 |
| tristan | WSalmon, yeah that thought is not gonna work, wrong order of interactions; sources just belong to elements | 12:33 |
| tristan | qinusty's branch changed some buildstream.build hardcoded URLs to proper relative ones, though | 12:33 |
| tristan | Which is good | 12:33 |
| tristan | WSalmon, So basically, what I understand is you are adding core functionality to place the whole source staging area into a subdirectory; in order to avoid setting the directory in the Source itself | 12:34 |
| *** solid_black__ has quit IRC | 12:35 | |
| WSalmon | yep the system works without that patch but i dont like having to set "diretory" twice.. i am open to not using that patch but it seemed nice, if you can sugest a better way i dont mind | 12:36 |
| tristan | WSalmon, It wont work. | 12:36 |
| WSalmon | what wont work? | 12:37 |
| tristan | WSalmon, You are ignoring that Element.stage() is just a build time thing; while Element._open_workspace() does not traverse that codepath | 12:37 |
| tristan | From what I can tell, at least; you wont get an open workspace with what you would expect | 12:37 |
| tristan | Or, have I missed the part where you also do the same thing in Element._open_workspace() ? | 12:39 |
| tristan | Doubt it | 12:39 |
| WSalmon | do you like this way of doing it enough for me to mirror the behavour in Element._open_workspace()? as i am going to have to fix the other opening workspaces bug around the build location? or do you not like this way of doing it? | 12:40 |
| tristan | WSalmon, As a matter of course, I _always_ dislike changes in the core | 12:42 |
| tristan | Those are high risk | 12:42 |
| tristan | WSalmon, here, I have found one edge case that you did not, and it took me < 10min... I dont know which edge case I will only notice in a few months | 12:42 |
| tristan | However, that is not to say there can never be core enhancements | 12:43 |
| tristan | WSalmon, The goal you are after is to have a very simple switch which enables this out of source directory build directory thing, so it's a bit of convenience | 12:43 |
| tristan | For those cases where... I dunno, you really enjoy having a build directory that is not a subdirectory of the source directory ? | 12:44 |
| tristan | I don't recall all of the context here, but lets consider; is it really worth a core feature ? | 12:44 |
| tristan | WSalmon, for one, if we go down this road; expect scope creep - because we do have other problems which revolve around the same area | 12:45 |
| tristan | WSalmon, Builds behave differently when started from a workspace or from a build, I think actually you noticed or ran into this | 12:46 |
| tristan | WSalmon, and it is exactly *because* the workspace opening codepaths do not flow through the same codepaths | 12:46 |
| WSalmon | yep, i dont understand why they diverge so much but i am still getting to know the code base | 12:46 |
| tristan | WSalmon, i.e. the command-subdir is automatically created at build time by the core; while it is not created when opening a workspace | 12:46 |
| tristan | So - One goal would be to streamline those codepaths without breaking any API | 12:47 |
| tristan | That is difficult | 12:47 |
| WSalmon | yep thats what i was saying i will probs need to fix for this ticket | 12:47 |
| WSalmon | the bug not the nessisarily the code path | 12:47 |
| tristan | WSalmon, if this comes with more and more branches, rather than existing branches flowing through the same common code path, that will be even worse | 12:48 |
| tristan | Fixing the bug without fixing the complexity, creates new sets of problems | 12:49 |
| tristan | I am talking in the abstract; but what I would expect to see for this; is Stream.open_workspace() -> Element._init_workspace() -> Element.stage() -> Source.init_workspace() Implicitly knowing that we are in the context of opening a workspace | 12:50 |
| tristan | *Something* along those lines | 12:50 |
| tristan | Rather than... Element._init_workspace() -> Source.init_workspace(), + Lets add duplicate lines of code here where we expect that Element implementations might have done things we dont know about | 12:51 |
| tristan | Remember that Element.stage() can do *basically whatever it wants* | 12:51 |
| tristan | WSalmon, When considering a merge request; my first consideration has to be: Does this bring the codebase together more as a coherent whole ? Or does it make things more complex and branchy ? | 12:52 |
| tristan | If the latter; Then I certainly prefer having documentation informing the user how to achieve an out of source build, than introduce anything to the core | 12:52 |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/52/ will need toggling off and on merge | 12:56 |
| qinusty | tristan ^ | 12:56 |
| tristan | what ? | 13:03 |
| tristan | I dont understand, that wasn't merged ? | 13:03 |
| tristan | oh cancel automatic and rebase | 13:04 |
| tristan | qinusty, Gotcha | 13:04 |
| tristan | WSalmon, I have a suggestion - *first* fix the bug that workspace initialization does not pass through Element.stage() implementations | 13:04 |
| qinusty | Gitlab \o/ | 13:04 |
| tristan | WSalmon, After that, your approach will make more sense | 13:05 |
| WSalmon | tristan, thanks for looking at this, i am looking again at how things get set up norm vs workspace, i will have a go | 13:06 |
| tristan | WSalmon, that will basically require some trickery | 13:06 |
| tristan | Such that arbitrary Element.stage() implementations, when they call Element.stage_sources(), opens workspaces instead | 13:07 |
| tristan | WSalmon, Taking BuildElement for example, see it's Element.stage() implementation here: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/buildelement.py#L174 | 13:07 |
| tristan | WSalmon, Notice that we *cannot* change BuildElement to support this, and it already calls Element.stage_dependency_artifacts(): https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/buildelement.py#L165 | 13:08 |
| tristan | WSalmon, So, we probably need to create a virtual Sandbox() for the purpose of doing this, and cause stage_dependency_artifacts() to be a no-op, *maybe* | 13:09 |
| tristan | WSalmon, in fact, what we are interested in here; is the result of an Element implementation's stage() operation; but *only* the %{build-root} portion of the sandbox | 13:10 |
| *** leopi has quit IRC | 13:10 | |
| tristan | WSalmon, some elements, like script elements, stage dependency artifacts into the %{build-root}, this fix will make them workspaceable | 13:10 |
| tristan | which is nice | 13:10 |
| * qinusty remembers he can't run a buildstream test suite locally :/ | 13:10 | |
| *** doras[m] has joined #buildstream | 13:11 | |
| *** awacheux[m] has joined #buildstream | 13:11 | |
| tristan | WSalmon, Maybe the virtual directory stuff going into master can help make staging outside of %{build-root} a no-op transparently | 13:11 |
| *** theawless[m] has joined #buildstream | 13:11 | |
| *** waltervargas[m] has joined #buildstream | 13:11 | |
| *** tlater[m] has joined #buildstream | 13:11 | |
| *** ssssam[m] has joined #buildstream | 13:11 | |
| *** rafaelff[m] has joined #buildstream | 13:11 | |
| *** abderrahim[m] has joined #buildstream | 13:11 | |
| *** asingh_[m] has joined #buildstream | 13:11 | |
| *** inigomartinez has joined #buildstream | 13:11 | |
| *** mattiasb has joined #buildstream | 13:11 | |
| *** kailueke[m] has joined #buildstream | 13:11 | |
| *** cgmcintyre[m] has joined #buildstream | 13:11 | |
| *** krichter[m] has joined #buildstream | 13:12 | |
| *** jjardon[m] has joined #buildstream | 13:12 | |
| *** alatiera has joined #buildstream | 13:12 | |
| *** segfault3[m] has joined #buildstream | 13:12 | |
| *** connorshea[m] has joined #buildstream | 13:12 | |
| *** pro[m] has joined #buildstream | 13:12 | |
| *** albfan[m] has joined #buildstream | 13:12 | |
| *** dineshdb[m] has joined #buildstream | 13:12 | |
| *** Demos[m] has joined #buildstream | 13:12 | |
| *** oknf[m] has joined #buildstream | 13:12 | |
| tristan | WSalmon, Also, a big problem with this whole idea is that dependency artifacts are expected to have all possible file attributes set inside the build sandbox, eventually including fancy things like xattrs; which are either unsupported on the user's filesystem outside of the container, or the user does not have permission to own | 13:12 |
| tristan | WSalmon, So it's possible that the whole plan doesnt make sense; or alternatively, we explicitly disallow the staging of artifacts into a workspace | 13:13 |
| tristan | WSalmon, All of these things need to be analyzed and considered | 13:13 |
| tristan | tiagogomes, I am very much liking this theme, are you going to merge it ? | 13:18 |
| tiagogomes | I was lunching | 13:21 |
| tristan | Ah | 13:21 |
| tiagogomes | The Alchemy right? | 13:22 |
| tristan | I think I'm going to hit the road soon too, starting to be that time | 13:22 |
| tristan | tiagogomes, yeah the link you posted of the artifact | 13:22 |
| tristan | tiagogomes, (A) It's clean and sober, so uncontroversial, (B) It makes the code blocks look nice, (C) It makes the h[1-5] tags look sensible, (D) It even makes the literal text look nicer than the old theme | 13:23 |
| tristan | All benefits afaics | 13:23 |
| tristan | Another plus, is the header bar is no longer green ! | 13:23 |
| tristan | hehe | 13:23 |
| tristan | The downsides I see to this theme are only: (A) The main site header "BuildStream, the software integration tool" Is HUUUUUGE... (B) The 5 menu items are quite small | 13:24 |
| tiagogomes | It doesn't give a fantastic look, but it is a big step from the former one in terms of aesthetics | 13:25 |
| tristan | No it doesn't but I think that until we have something modern; this is aesthetically nice for a neutral and simple / basic site | 13:25 |
| tiagogomes | yeah, that's why I've chose it | 13:26 |
| tristan | Great | 13:26 |
| tristan | We'll have to focus on the content after this I think, and fix those broken links (you said there were broken links ?) | 13:27 |
| tristan | One thing that is a bit annoying; we either dont have any link to the documentation (oops ?) - Or it is hiding somewhere deep like an FAQ that nobody will look at | 13:27 |
| tristan | I would argue that a toplevel menu item leading the user directly to buildstream.gitlab.io/buildstream would be a great idea | 13:28 |
| SotK | +1 | 13:28 |
| tiagogomes | The links broken are not in the markdown. Is something else with the template instantiation. If you open an article and then try to use the nav bar, you will see the links are broken | 13:30 |
| tristan | Ah, the "articles" are the last thing I've been looking at, I even missed them in the previous link-fixing iteration | 13:31 |
| tristan | lets see, how do you "arrive at an article" | 13:31 |
| tiagogomes | https://buildstream.build/articles/2018/BuildStream-1.2-is-out!/ | 13:31 |
| tristan | "Updates" | 13:32 |
| tristan | Should "Updates" not be called "News" ? | 13:32 |
| tristan | Aha | 13:32 |
| tristan | tiagogomes, Technically, that is the markdown; and is related to absolute vs relative URLs | 13:33 |
| tiagogomes | I don't think so. The nav bar is not generated by markdown | 13:33 |
| tristan | It would be nice if there was some sort of {site-root} substitutable thing in the links so that they are equally viewable locally | 13:33 |
| tristan | Ah the navbar too | 13:33 |
| tristan | Yeah, crap | 13:33 |
| SotK | you want to update the hrefs in https://gitlab.com/BuildStream/website/blob/master/alchemy-theme/alchemy/templates/include/header.html so that they are like "/{{ link }}" | 13:34 |
| tiagogomes | ah, I didn't spot the others | 13:34 |
| tristan | SotK, So the problem I had was that, all the links were being noted like: [FAQ](/faq.html), instead of [FAQ](faq.html) | 13:35 |
| tristan | SotK, Fixing that, made the site viewable locally; *mostly*, but breaks the links in subfolders | 13:35 |
| tristan | I think that what it *should* be, is [Link Name]({project}faq.md) | 13:36 |
| tristan | That currently breaks because, we have this obnoxious "pages" subdirectory | 13:36 |
| tristan | So those [FAQ]({project}faq.md) translate to http://domain/pages/faq.html | 13:37 |
| tristan | But - the html file is actually at http://domain/faq.html | 13:37 |
| tristan | SotK, I *think* that if we nuke this `pages/` subdirectory and place all of the md files where they are expected to be found on the actual site, and use the "{project}page.md" format for links, then the site will be properly relocatable (viewable from a file:/// url) and all the links will work | 13:38 |
| tristan | SotK, tiagogomes; is that a pretty accurate assessment ? | 13:38 |
| tiagogomes | tristan, we need to add a forward slash as I had put in the beginning, so that it always starts at the root of the website | 13:39 |
| *** leopi has joined #buildstream | 13:39 | |
| tristan | tiagogomes, Does the {project} thing work or doesnt it ? | 13:39 |
| tristan | tiagogomes, That forward slash makes all links point to file:///faq.html, etc | 13:39 |
| tristan | If it does not for you, I don't know what you did | 13:40 |
| tiagogomes | 'pages' is a special directory where pelican looks for static pages. Everything outside of it is an article | 13:40 |
| tristan | But `make html` doesnt work for me that way | 13:40 |
| tiagogomes | From an article: http://127.0.0.1:8000/community.html | 13:40 |
| tristan | No no, lets not have to run the server jaysus | 13:41 |
| tiagogomes | I use make serve | 13:41 |
| tristan | I want to just generate a static set of html that is relocatable without any tinkering, it's not supposed to be difficult | 13:41 |
| tristan | tiagogomes, That browse artifacts trick on gitlab worked, because of that simplicity | 13:41 |
| tristan | I think the {project}foo.md translation is broken and can be fixed, because valentind had some links like that; only problem is that they were pointing to pages/foo.html instead of directly to foo.html | 13:42 |
| *** lachlan has quit IRC | 13:43 | |
| tristan | So, *maybe* the problem, is that those pages should actually be published at http://domain.com/pages/foo.html | 13:43 |
| SotK | setting PAGE_URL in pelicanconf.py might fix that | 13:43 |
| SotK | like: https://github.com/ColdrickSotK/sotk.co.uk/blob/master/pelicanconf.py#L16 for example | 13:44 |
| SotK | (though that generates things like `sotk.co.uk/things/`) | 13:44 |
| mablanch | juergbi: Thanks for the review of !626. Regarding the commit split of the CASCache work, do you want me to keep the _push_refs_to_remote() refactoring or not? It has been introduced before we add the push_* and pull_* helpers and is not really necessary any-more (except if you have future plans that may use it). | 13:44 |
| SotK | but if you do something like '{slug}.html' for PAGE_URL and PAGE_SAVE_AS it should eliminate the "pages" bit I think (it does for the page object's "url" in templates anyway) | 13:46 |
| SotK | I've also always used `make serve` or equivalent and haven't used the {project} stuff | 13:46 |
| SotK | hm, {project} doesn't seem to exist in the version of pelican I have here | 13:51 |
| juergbi | mablanch: it's probably still sensible even if not strictly needed. it might be useful in the future if we make CASCache a bit dumber, i.e., move the logic out that decides when to use which remotes | 13:54 |
| tristan | SotK, I'm not entirely sure it was {project}, going from memory here | 13:54 |
| mablanch | juergbi: Ok, I'll keep it, thank you. | 13:55 |
| tristan | SotK, I did look at an issue that proposed supporting it in MENUITEMS, lemme check | 13:55 |
| SotK | {filename} is a thing which seems to do similar | 13:55 |
| tristan | Right | 13:55 |
| tristan | That's it | 13:56 |
| tristan | https://github.com/getpelican/pelican/issues/2272 | 13:56 |
| tristan | So just s/{project}/{filename} in all the stuff I was saying above, that's what I'm talking about | 13:56 |
| tristan | It put the pages/ directory into the formatted URL, which lead me to think, better just not put the pages into a pages/ subdirectory in the first place | 13:56 |
| tristan | Or rather, publish them to a pages/ subdirectory; make 'em match | 13:57 |
| tristan | And presto, you have a relocatable site | 13:57 |
| *** tristan has quit IRC | 14:03 | |
| *** lachlan has joined #buildstream | 14:05 | |
| tiagogomes | I think the markdown needs to be in a pages subdirectory. I think buildstrean.build/pages/download.html is awful | 14:06 |
| SotK | ok, I tested it out, setting PAGE_URL and PAGE_SAVE_AS to not include `pages` in the url is indeed honoured by {filename} | 14:06 |
| SotK | and yeah, you need to have pages in a pages subdirectory, or else pelican will treat them as articles | 14:08 |
| tiagogomes | yup | 14:08 |
| qinusty | Anyone had these issues before https://paste.gnome.org/pppnlf3wc ? pytest is not having fun... | 14:10 |
| qinusty | Apparently all of the __init__.py files we have within our test folders are causing the issues? Are they necessary? | 14:11 |
| SotK | I don't believe it to be possible to have pelican generate links that are like "foo/../bar/faq.html" without manually typing something like that in the markdown, which is I think what would be needed to have it working file:// uris | 14:12 |
| SotK | and that's never going to work with the navbar links | 14:12 |
| SotK | (or more accurately, something like "../faq.html") | 14:14 |
| toscalix | qinusty: available? | 14:16 |
| qinusty | Trying to solve some issues I've been having in general with my test suite, but not getting anywhere. So yep | 14:17 |
| qinusty | toscalix | 14:17 |
| Kinnison | quI have that issue before, I just dumped my .eggs and reran the tests and it recovered for me | 14:17 |
| Kinnison | qinusty: ^ | 14:17 |
| Kinnison | I can type, honestly | 14:17 |
| qinusty | hmm | 14:17 |
| qinusty | I dumped my pytest-* eggs | 14:17 |
| qinusty | but I'll dump all and see what happens | 14:17 |
| toscalix | qinusty: there are several pages that requires conetnt, but from all of them, there is one we cannot make some noise without which is the feature page | 14:18 |
| toscalix | sadly it is a page that it will require me a lot of effort and, together, we can do it this afternoon | 14:18 |
| toscalix | since it requires some technical knowledge about the tool | 14:18 |
| toscalix | https://buildstream.build/feature.html | 14:19 |
| qinusty | I can try and help, but I've not actually contributed to any of the key features in this release, primarily bugfixes on smaller features and implementing features for 1.4 | 14:19 |
| gitlab-br-bot | buildstream: merge request (willsalmon/outOfSourecBuild->master: WIP: out of source builds) #776 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/776 | 14:19 |
| qinusty | e.g I've not actually used Includes or source mirroring | 14:19 |
| toscalix | qinusty: it would a good start if can format the tables, taking the download page as example | 14:20 |
| qinusty | Can do | 14:20 |
| toscalix | I will concentrate on the last couple of sections | 14:20 |
| gitlab-br-bot | buildstream: issue #627 ("Remote-execution instance configuration support") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/627 | 14:49 |
| *** juergbi has quit IRC | 14:52 | |
| *** lachlan has quit IRC | 14:58 | |
| * qinusty is unsure what we want in these tables toscalix, they're formatted okay | 14:59 | |
| *** juergbi has joined #buildstream | 14:59 | |
| toscalix | tiagogomes: somehow the new theme changed how the tables are rendered | 15:00 |
| toscalix | I do not see the lines now | 15:01 |
| tiagogomes | Is that a problem? | 15:02 |
| toscalix | https://buildstream.build/releases.html | 15:03 |
| toscalix | take a look. I think so | 15:03 |
| tiagogomes | It doesn't look fantastic but not broke either. We can't be switching theme again | 15:05 |
| qinusty | It's a small CSS change, decide what we want and we can implement it | 15:05 |
| toscalix | The tables should have borders | 15:06 |
| toscalix | the first row (header) should be centered (minor issue) | 15:06 |
| qinusty | How thick should the borders be? How much padding should be included on each cell? | 15:07 |
| tiagogomes | Isn't tables with borders so 90ies | 15:07 |
| toscalix | I lthink it would be too much detaild from my side. | 15:07 |
| toscalix | but borders.... I think tables should have a way to differentiate rows, at least | 15:09 |
| SotK | my broad recommendation: indicate separation firstly with space and then with background colouring if needed (alternate colours for table rows for example), with lines/borders as a last resort | 15:09 |
| toscalix | if you want to use colours... fine | 15:10 |
| SotK | ("space" meaning logically linked things should be visually close together, separate things should be noticably more separated in space) | 15:11 |
| toscalix | another minor point on this theme is the ToC. The previous theme was better on that | 15:11 |
| *** lachlan has joined #buildstream | 15:12 | |
| toscalix | this theme looks nicer | 15:12 |
| gitlab-br-bot | buildstream: issue #628 ("Remote-execution execution flow optimisation (technical debt)") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/628 | 15:13 |
| toscalix | anyway, back to the feature page | 15: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 | 15:24 |
| qinusty | How does this releases page magic work valentind? | 15:27 |
| tiagogomes | It uses a home backed extension: get_releases.py | 15:29 |
| qinusty | So it needs a web server? | 15:29 |
| qinusty | No, during generation | 15:30 |
| qinusty | nvm | 15:30 |
| qinusty | toscalix, what are we putting in these feature tables? I assume tristan or valentind will populate them at some point | 15:34 |
| toscalix | qinusty: in general, each page includes info in the template and the related ticket, in this case https://gitlab.com/BuildStream/website/issues/1 | 15:34 |
| toscalix | If it is not clear enough, I will develop further | 15:35 |
| qinusty | It is fairly clear, however I cannot populate this information accurately. | 15:35 |
| toscalix | the ticket should include a couple of examples to other projects | 15:35 |
| toscalix | qinusty: I have the same problem | 15:35 |
| toscalix | we simply need help from somebody with a deeper knowledge of the tool | 15:36 |
| toscalix | valentind: did a list of the features | 15:36 |
| toscalix | that should be included in this table | 15:36 |
| toscalix | ah, great, he add them to the ticket | 15:36 |
| toscalix | I love when people use the tickets :-) | 15:36 |
| gitlab-br-bot | buildstream: issue #629 ("Remote-execution testing (technical debt)") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/629 | 15:37 |
| *** alatiera_ has quit IRC | 15:54 | |
| *** alatiera_ has joined #buildstream | 15:54 | |
| *** alatiera_ has joined #buildstream | 15:55 | |
| gitlab-br-bot | buildstream: issue #630 ("Remote-execution connection recovering (technical debt)") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/630 | 16:04 |
| qinusty | https://buildstream.gitlab.io/-/website/-/jobs/95005643/artifacts/output/feature.html thoughts toscalix? | 16:16 |
| tiagogomes | yikes, now tables do really look bad :| | 16:19 |
| toscalix | tiagogomes: they look bad but the content is clearer | 16:23 |
| toscalix | I think it is better now | 16:23 |
| toscalix | qinusty: from the feature page, we will try to route readers to BuildStream in Detail, which include the description of the features, the impact, why they are important, etc. | 16:24 |
| toscalix | hopefully the developers of each feature will fillout that section | 16:24 |
| toscalix | on BuildStream in Detail | 16:25 |
| toscalix | qinusty: https://gitlab.com/BuildStream/website/blob/master/content/pages/buildstream_in_detail.md | 16:26 |
| toscalix | qinusty: I like the fact that you added a detail column | 16:27 |
| toscalix | with a short explanation of the features | 16:27 |
| toscalix | I would keep though the v1.0 v1.2 columns | 16:27 |
| mablanch | juergbi: There is a comment on !626 that was left with no answer. Sorry to bother you again, but if you could have a quick look: https://gitlab.com/BuildStream/buildstream/merge_requests/626#note_98131551 :) | 16:27 |
| toscalix | if the feature is totally new in v1.2 you put in the column new feature | 16:28 |
| toscalix | but usually features are not fully implemented in a single release | 16:28 |
| persia | Hrm? Most of the features in 1.2 weren't started until after 1.0, as far as I remember. | 16:29 |
| toscalix | so that table is the opportunity to provide a short explanation about the steps taken in that feature | 16:29 |
| persia | Similarly, I don't think most of the features expected for 1.4 have precursors in 1.2/ | 16:29 |
| toscalix | after 3 or 4 releases you end up having a nice story to tell about the evolution of the key features that makes the product cool | 16:30 |
| paulsher1ood | toscalix: should "Portfolio" be "About" | 16:30 |
| toscalix | persia: which tell us something too. On the other side, some features we are introducing now will be enhanced the next release | 16:31 |
| toscalix | paulsher1ood: if you think about BuildStream as product, yes. If you think about it as a community... no | 16:31 |
| * paulsher1ood has *never* seen Portfolio used in this context | 16:32 | |
| toscalix | so we have a community page and a portfolio page | 16:32 |
| tiagogomes | I am not a big fan of the name. I associate portfolio with artists | 16:32 |
| paulsher1ood | please can you provide a link to another project that uses the word as a link in this context? | 16:32 |
| toscalix | paulsher1ood: I think the name can be improved, yes. | 16:32 |
| SotK | "portfolio" made me confused too | 16:32 |
| persia | Which page are we looking at? | 16:32 |
| paulsher1ood | s/Portfolio/About/ then | 16:33 |
| toscalix | About though.... many might expect content about the people/org behind the project | 16:33 |
| paulsher1ood | any page mentioning "Portfolio" | 16:33 |
| paulsher1ood | toscalix: no web page is perfect | 16:33 |
| toscalix | persia: https://buildstream.build/portfolio.html | 16:34 |
| paulsher1ood | if there is some specific meaning you intend in the concept "Portfolio" i'd like to understand it, but otherwise "About" would be usual in english sites | 16:34 |
| toscalix | that page describes the toolset and the different deliverables | 16:34 |
| persia | Yeah. That's clearly an "about" page. | 16:35 |
| persia | And people with expectations that "about" being a marketing platform for some sponsor can go educate themselves about community initiatives. | 16:35 |
| toscalix | some people put products | 16:36 |
| toscalix | or services | 16:36 |
| toscalix | and about is "who we are" | 16:36 |
| persia | Also, I don't consider "releases", "snapshots", and "master" as deliverables. There should just be "BuildStream". Folk who need newer than the latest release for some reason (and operate at risk) should consider snapshots. Those who need today's changes are are willing to operate at more risk (please, not for production), can use master. | 16:36 |
| persia | That page is "about buildstream". | 16:36 |
| SotK | products and services suggest sales pages to me | 16:37 |
| toscalix | SotK: it was just an example | 16:37 |
| toscalix | persia: about BuildStream would work | 16:37 |
| persia | To me, "portfolio" implies a selection of things. If we wanterd to highlight a bunch of example systems developed with buildstream, or lots of cool projects, that would make sense to me as "portfolio". | 16:37 |
| SotK | +1 | 16:37 |
| paulsher1ood | ypu | 16:37 |
| paulsher1ood | yup, even | 16:37 |
| persia | Now if the community grows, and lots more people use BuildStream, I'd be delighted to see a "BuildStream Portfolio" page linking to as many users as let us do so. | 16:38 |
| paulsher1ood | i'll make a change | 16:38 |
| toscalix | paulsher1ood: there are many links pointing to that page | 16:38 |
| toscalix | and is referred to as portfolio in several places. Take that into account | 16:38 |
| persia | Then it's a big change, affecting many files. | 16:39 |
| toscalix | persia: there was some structure design behind the web :-) | 16:39 |
| toscalix | critical paths.... | 16:40 |
| * persia doesn't understand how changing a pagename affects structure, but does understand that big changes to fragile things need to be handled carefully | 16:40 | |
| persia | Does pelican have a test that can be configured to fail whenever dangling links are defined? | 16:40 |
| toscalix | gitlab makes easier to know what needs to be changed....but still | 16:40 |
| toscalix | persia: that question has popped up several times. I have not read a clear answer. We have no pelican expèrt around here, I am afraid | 16:41 |
| toscalix | tiagogomes: is doing his best, I am happy about it | 16:42 |
| *** dtf has quit IRC | 16:43 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/test-config-fixes->master: Fix tests that attempt to access the home directory) #780 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/780 | 16:45 |
| *** dtf has joined #buildstream | 16:45 | |
| toscalix | qinusty: do you have a clear idea on what to do next about the page? I have been on 3 or 4 things in parallel and might have lost you | 16:46 |
| SotK | I don't know of anything that checks that, but my knowledge is not exhaustive | 16:46 |
| SotK | if you use links to source files with {filename}, the generation command gives a warning which you can make fatal | 16:51 |
| SotK | if the source filename changes that is | 16:51 |
| gitlab-br-bot | buildstream: merge request (richardmaw/fix-chroot-sandbox-devices->master: WIP: fix chroot sandbox devices) #781 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/781 | 16:52 |
| toscalix | qinusty: I am afraid I will keep working on the feature page tomorrow. I simply have no brains to come up with nice texts | 16:52 |
| toscalix | well... nice under my own standards :-) | 16:52 |
| qinusty | Okay, best to get someone who implemented the feature to detail it. They'll describe it in its true light | 16:53 |
| toscalix | qinusty: yes, so do not worry about it on this page. Just remove the link to the tech docu for now | 16:55 |
| toscalix | and keep working on the tables. Scroll up a little. I did some considerations to what you showed me. | 16:56 |
| toscalix | I will over them again in detail on the MR | 16:56 |
| toscalix | once we aredone with feature page, we move onto bst in detail | 16:57 |
| *** jonathanmaw has quit IRC | 17:06 | |
| 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 | 17:07 |
| *** toscalix has quit IRC | 17:13 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/builddir-sockets->master: WIP: Fix: While caching build artifact: "Cannot extract [path to socket file] into staging-area. Unsupported type.") #783 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/783 | 17:16 |
| gitlab-br-bot | buildstream: merge request (richardmaw/element-cache-state-simplify->master: Simplify element state by removing `__cached`) #784 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/784 | 17:20 |
| *** rdale has quit IRC | 17:27 | |
| *** bochecha has joined #buildstream | 17:51 | |
| *** alatiera_ has quit IRC | 18:34 | |
| *** alatiera_ has joined #buildstream | 18:34 | |
| *** alatiera_ has quit IRC | 18:45 | |
| *** bochecha has quit IRC | 19:05 | |
| *** leopi has quit IRC | 19:56 | |
| *** tristan has joined #buildstream | 20:09 | |
| SotK | I assume a MR fixing all the broken links would be appreciated? | 20:46 |
| tristan | SotK, I'd like to try my hand at making a relocatable site possible, such that you dont have to do `make serve` and can put the site anywhere and it will "just work" regardless of it's path | 20:51 |
| tristan | That kind of patch would be much, much more appreciated :) | 20:51 |
| tristan | It's really surprising to me, sphinx does this perfectly fine; I dont see why a simple markdown converter as popular as pelican can't do it | 20:52 |
| SotK | I'll see if I can mess with the template to get it to work like that then | 21:08 |
| *** leopi has joined #buildstream | 21:11 | |
| * SotK makes it work, but its pretty ugly | 21:29 | |
| SotK | heh, or I thought I did | 21:34 |
| SotK | oh, I did, I just have too many tabs open | 21:34 |
| tristan | SotK, Yay \o/ | 21:36 |
| * SotK makes it less ugly and works out how to use gitlab | 21:50 | |
| SotK | tristan: https://gitlab.com/BuildStream/website/merge_requests/56 | 21:55 |
| *** leopi has quit IRC | 22:02 | |
| SotK | that only makes the test builds properly relocatable actually, since the production build hardcodes https://buildstream.build as the SITEURL | 22:10 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
