| *** xjuan has quit IRC | 00:12 | |
| *** bochecha has quit IRC | 00:50 | |
| *** tristan has joined #buildstream | 05:41 | |
| *** ChanServ sets mode: +o tristan | 05:41 | |
| gitlab-br-bot | buildstream: issue #591 ("Missing required key on project.conf causes wrong provenance file name on error message") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/591 | 05:50 |
|---|---|---|
| *** leopi has joined #buildstream | 06:03 | |
| gitlab-br-bot | buildstream: merge request (tristan/591-workaround-1.2->bst-1.2: Backport workaround for #591) #767 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/767 | 06:29 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail->master: Retries log as failures) #766 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/766 | 06:37 |
| gitlab-br-bot | buildstream: merge request (tristan/591-workaround-1.2->bst-1.2: Backport workaround for #591) #767 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/767 | 06:52 |
| *** toscalix has joined #buildstream | 07:49 | |
| *** tristan has quit IRC | 07:52 | |
| *** tiagogomes has quit IRC | 08:01 | |
| *** tiagogomes has joined #buildstream | 08:01 | |
| gitlab-br-bot | buildstream: issue #470 ("bst --track modifies bst files even when their source refs are unchanged") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/470 | 08:08 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail->master: Retries log as failures) #766 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/766 | 08:15 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail->master: Retries log as failures) #766 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/766 | 08:16 |
| *** tristan has joined #buildstream | 08:18 | |
| *** rdale has joined #buildstream | 08:32 | |
| tristan | qinusty, regarding that assertion and why it's probably failing CI, only the messages which come from child tasks can have a logfile, and they always do | 08:42 |
| qinusty | probably, I'll take a look after I've sorted the SKIPPED MR | 08:43 |
| tristan | qinusty, the situation with all the whacky state in Message objects probably needs cleanup as a separate activity (you have an issue open for that), so if there actually is a stack trace that your added clause in widget.py protects against, it would be good to fix that case or know where that message came from | 08:44 |
| qinusty | I agree, I was going to lump that in with the Message API MR | 08:44 |
| tristan | nod, makes sense | 08:44 |
| qinusty | Which I plan to further work on after release | 08:45 |
| qinusty | because there's 0 possibility of the message API going near the release, so I decided to leave it for a bit | 08:45 |
| tristan | qinusty, was there a stack trace ? or did you just want to add that line impulsively ? | 08:45 |
| * tristan would totally understand the impulse | 08:45 | |
| qinusty | Stack trace when I stopped the WARNING happening | 08:45 |
| qinusty | Because the "Try #..." thing didn't have logfile set | 08:45 |
| qinusty | https://gitlab.com/BuildStream/buildstream/issues/619 | 08:46 |
| tristan | right, so the fix for that would be to ensure it has the logfile | 08:46 |
| tristan | instead of pretending it's okay to have a failure without a logfile | 08:46 |
| qinusty | Yes. I changed that now :D | 08:46 |
| tristan | Ah great | 08:46 |
| qinusty | I wasn't sure how strict the logfiles were associated with Start/Fail etc | 08:47 |
| qinusty | I don't know all usecases | 08:47 |
| tristan | yeah it will be great to have these changes in the release :) | 08:47 |
| * qinusty is hoping to get them sorted this morning | 08:47 | |
| tristan | qinusty, I think as a part of the logging refactor you have separately, we might just ensure the logfile is set for everything coming out of a Job | 08:47 |
| tristan | and not have to set it anywhere special | 08:47 |
| tristan | in any case, a job is what dispatches the messages to the frontend, and the job should always be aware of it's logfile already | 08:48 |
| tristan | but no need to rush in too many changes at once for this warning -> failure thing I think | 08:48 |
| qinusty | Agreed, I'm trying to filter out things I'm spotting for the Message API and resist fixing them now | 08:49 |
| tristan | qinusty, few more comments on the other SkipJob exception issue; and going to go eat some lunch | 09:01 |
| tristan | qinusty, mainly that is missing the updates to job.py which will (A) Serialize the skipped state of the job before exiting, along with the return code etc... (B) Handle the Skip exception there and issue a SKIPPED message directly in the job harness... (C) Notice the serialized skipped status on the receiver side and ensure the job has a skipped state... (D) Queue base implementation needs to notice this skipped state so as to bookkeep it correctly | 09:03 |
| tristan | in it's skipped list | 09:03 |
| qinusty | Looking into that now :D | 09:03 |
| *** tristan has quit IRC | 09:06 | |
| *** jonathanmaw has joined #buildstream | 09:15 | |
| toscalix | valentind: after sorting out the download page, can you focus on the installation guide/page? we will need not just to move it and ensure the the format is right, but also that the documentation guide links are corrected | 09:26 |
| *** alatiera has joined #buildstream | 09:29 | |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 09:29 |
| *** tristan has joined #buildstream | 09:39 | |
| *** ChanServ sets mode: +o tristan | 09:39 | |
| gitlab-br-bot | buildstream: merge request (Qinusty/skipped-rework->master: Add SkipError for indicating a skipped activity) #765 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/765 | 09:39 |
| *** solid_black has joined #buildstream | 09:48 | |
| gitlab-br-bot | buildstream: merge request (Qinusty/skipped-rework->master: Add SkipError for indicating a skipped activity) #765 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/765 | 09:48 |
| toscalix | jjardon: how severe is https://gitlab.com/BuildStream/buildstream/issues/618 ? | 09:50 |
| toscalix | are we aiming to fix this today? | 09:51 |
| jjardon | toscalix: no critical, but I think a bug that should be adressed in bst-1.2 branch at some point | 09:51 |
| toscalix | ok, thanks | 09:51 |
| qinusty | Anyone having issues running their tests locally. I've been having a new issue which is preventing me from running ANY of my tests locally | 09:56 |
| coldtom | qinusty: i've been experiencing issues with running tests the last couple days | 09:57 |
| qinusty | coldtom, re: https://gitlab.com/BuildStream/buildstream/issues/618. tristan mentioned something to do with junction project configurations, did you investigate this? | 09:57 |
| qinusty | Yeah I'm getting really sick of it, I can't test my patches locally atm | 09:58 |
| qinusty | https://paste.gnome.org/pwkpqejza | 09:59 |
| *** abderrahim has quit IRC | 10:18 | |
| *** abderrahim has joined #buildstream | 10:18 | |
| toscalix | tiagogomes: https://gitlab.com/BuildStream/website/merge_requests/11 | 10:22 |
| toscalix | when you can | 10:22 |
| tiagogomes | I just left a comment | 10:24 |
| qinusty | What is the general consensus with https://gitlab.com/BuildStream/buildstream/issues/609? Not critical? jjardon, toscalix, tristan? | 10:26 |
| tristan | qinusty, it's high impact, cannot be solved by 1.2.0, lets hope to get a fix in for 1.2.1 ASAP | 10:28 |
| qinusty | Okay, I'm trying to deal with these two MR's. Slowed by my lack of local testing which I am also trying to find a solution for D: | 10:29 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail->master: Retries log as failures) #766 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/766 | 10:30 |
| jjardon | qinusty: agree with tristan ; annoying bug but it can be solved later in the 1.2.x series | 10:31 |
| tristan | I am suddenly quite curious about https://gitlab.com/BuildStream/buildstream/issues/618 | 10:32 |
| tristan | Am I misreading that ? The parent project should not inherit the artifact caches of the junctioned sub-project, and modifying the project.conf in the parent project should also not effect the junctioned sub-project elements relationship to a cache server | 10:33 |
| qinusty | Basically tristan, coldtom removed his `artifacts:` section from his project.conf | 10:34 |
| qinusty | and it was still pulling from the cache | 10:34 |
| coldtom | tristan: BuildStream was pulling from the cache I just removed, on an element defined only in that project | 10:35 |
| coldtom | tristan: expected behaviour here would be for the bootstrap to still pull from the cache, but not elements in the main SDK, actual behaviour was elements from the SDK pulling | 10:35 |
| tristan | coldtom, yes, commented on the issue, sorry for being confused, this is indeed a bug | 10:36 |
| tristan | qinusty, I keep hearing this in the context of sub projects that I jumped the gun on my previous comment on the issue | 10:37 |
| qinusty | No worries, I just wanted to make sure potential solutions weren't overlooked :D | 10:37 |
| tristan | yeah; I suspect this is just a code error in the artifact cache, or in the loading of it's configuration | 10:38 |
| tristan | commented that we better start with a test case, and then fixing should be pretty straight forward | 10:38 |
| tristan | I feel like the artifact cache configuration is backwards in terms of ownership - probably worth some churn and refactor | 10:39 |
| tristan | The artifact cache does the looping on the URLs it thinks it should push to / pull from... and the artifact cache also goes and does some custom reading of configuration not handled by _project.py or _context.py | 10:40 |
| tristan | This should probably be reversed: The ArtifactCache() should be dumber with configuration; it should just be told to push / pull from a specific artifact cache... And... the BuildStream core should load the configuration in the usual places... And... the PullQueue / PushQueue action implementations should instead be responsible for asking the element to be pushed/pulled to/from a specific server | 10:41 |
| tristan | juergbi, Thoughts on that cleanup ^^^ ? | 10:41 |
| tristan | juergbi, I think the reason we did this the other way around, was that specifically at push time, with OSTree we saved time this way, because we needed to create a temporary repo for the purpose of pushing (i.e. an archive-z2 repo) | 10:42 |
| tristan | This whole mess can probably be straightened out now that we use the CAS cache instead, right ? | 10:42 |
| juergbi | it would definitely be good to not have it in CASCache. whether it should be in ArtifactCache or some other place, I'm not sure | 10:45 |
| tristan | I think cleanest is to have it in Push/PullQueue, and have the whole ArtifactCache API take some kind of ArtifactRemote or similar object to describe a remote; get the business logic out of there | 10:50 |
| tristan | but this is just a hypothetical change at this point; need to find time to actually churn it | 10:51 |
| tristan | qinusty, Solved your FAILURE message problem on !766 for you | 10:54 |
| tristan | qinusty, https://gitlab.com/BuildStream/buildstream/merge_requests/766/diffs#note_98106355 | 10:55 |
| qinusty | Okay, we should have an assertion there at some point I think... | 10:56 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail->master: Retries log as failures) #766 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/766 | 10:58 |
| tristan | qinusty, I don | 11:05 |
| tristan | gah | 11:05 |
| tristan | qinusty, I don't think so, we should aggressively refactor Message() as a whole | 11:05 |
| tristan | qinusty, In any case, no messages should have to explicitly set the logfile | 11:06 |
| qinusty | In the case of the message api rework yes. | 11:06 |
| qinusty | But for now.... | 11:06 |
| tristan | qinusty, logfile should just be stamped here: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_scheduler/jobs/job.py#L507 | 11:06 |
| tristan | qinusty, for now... better not to disrupt the delicate balance of things until we bring clarity anyway | 11:07 |
| qinusty | agreed | 11:07 |
| qinusty | Simple changes for GM dya | 11:07 |
| qinusty | day | 11:07 |
| tristan | qinusty, on that note, I am regretful but doubt that the Skip changes will land :-S | 11:08 |
| qinusty | Indeed | 11:08 |
| tristan | qinusty, maybe it's better to consider the whole problem and do a better review and land it directly after 1.2.0 | 11:08 |
| qinusty | after reading your comment, agreed. It works with the current implementation but ideally the SkipJob exception would propagate and be handled directly by queue.py | 11:09 |
| tristan | I don't see any reason why we would ever need to determine if a job was skipped in the post processing bottom half anymore, with the introduction of SkipJob | 11:10 |
| tristan | So all of those code paths should be removed with the introduction of SkipJob | 11:11 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Resolve "os.sched_getaffinity() not supported on MacOSX Blocks #411") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 11:11 |
| tristan | (there are not many, since only push/pull uses it, but the boiler plate from Queue which even allows it should be removed too) | 11:11 |
| qinusty | Indeed, I'll follow it up after 1.2.0 alongside my work on MessageAPI | 11:16 |
| qinusty | If I keep them close, perhaps I can land Message API first | 11:16 |
| qinusty | Meaning everything will be clean | 11:16 |
| qinusty | How do we set sysctl kernel.unprivileged_userns_clone=1 for our test containers? | 11:17 |
| * qinusty is trying to test through docker since his local env seems broken | 11:17 | |
| tristan | qinusty, I'd rather do this separately from the Message API; because I don't intend to backport that part | 11:17 |
| qinusty | Ah okay | 11:18 |
| qinusty | I'll land it first then to make the messaging backportable | 11:18 |
| tristan | And it would be really nice to improve the story about START <--> SUCCESS/FAILURE/SKIPPED, and document that | 11:18 |
| qinusty | Yeah, Are the task START messages very clear? It shows the log message but not the action_name | 11:19 |
| qinusty | I feel that whenever I see them, I just ignore them | 11:19 |
| tristan | That's because there is too much noise I think | 11:19 |
| qinusty | How does self.message(MessageType.START, self.action_name, logfile=filename) | 11:19 |
| qinusty | End up not printing self.action_name | 11:20 |
| qinusty | but instead prints a filename? | 11:20 |
| tristan | It does | 11:20 |
| tristan | The action name is printed in every line pertaining to that task, which is related to the action | 11:20 |
| tristan | [timestamp][hash][action_name:element_name] MessageType: Additional text here... | 11:21 |
| qinusty | Where are we talking here. This why we need the diagram :D I'm talking START <message>, where message should be action_name for consistency | 11:21 |
| qinusty | but it is overwritten and ends up being a filename? | 11:21 |
| qinusty | But action_name is passed as message... | 11:21 |
| tristan | qinusty, look at action_name in the above | 11:21 |
| tristan | qinusty, it appears in *every message* | 11:22 |
| qinusty | I know. But that isn't how the message API works is it ? | 11:22 |
| tristan | It is | 11:22 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail->master: Retries log as failures) #766 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/766 | 11:22 |
| qinusty | Job.message does (Message_type, message, **kwargs) | 11:22 |
| qinusty | MessageType.START, self.action_name | 11:23 |
| qinusty | But self.action_name is not printed as message | 11:23 |
| qinusty | it is extracted somewhere? | 11:23 |
| tristan | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_scheduler/jobs/job.py#L509 | 11:23 |
| tristan | Oh, there, I see | 11:23 |
| tristan | qinusty, yeah that is just dropped and ignored | 11:24 |
| qinusty | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_scheduler/jobs/job.py#L318 | 11:24 |
| qinusty | That's confusing from a developers point of view | 11:24 |
| qinusty | I could pass ANYTHING into message with MessageType.START and a filename would be displayed? | 11:24 |
| tristan | qinusty, YES | 11:24 |
| qinusty | weird | 11:24 |
| tristan | qinusty, It is one of the more confusing areas; which is why it is important to do an overhaul of the Message() structure | 11:25 |
| qinusty | So a START message should ALWAYS be followed by a log filename if associated with job? (that is expected) | 11:25 |
| tristan | qinusty, I think it's that way because we assume that a message should have a message text; except these ones are special | 11:25 |
| qinusty | Perhaps when we overhaul the message API, it'll be clearer since we'll provide helper functions with clearer parameters | 11:26 |
| tristan | qinusty, Not a nested START message from timed_activity(), a Job message yes | 11:26 |
| qinusty | Okay, sounds good. I'll backport !766 and head for lunch | 11:27 |
| tristan | This part "[timestamp][hash][action_name:element_name] MessageType" Provides all the context one needs to know about a job; the rest is just details of stuff happening within that job | 11:28 |
| qinusty | We do DEFINITELY need to document the output for users. | 11:28 |
| tristan | But it's important to print the logfile, while it's not important to add more stuff to the global message; and it's also important to not add more newlines for the sake of the logfile for every job | 11:29 |
| tristan | And even further, it's also very important to be very conservative with the line length; columns in the terminal are the most precious asset; and wrapping is horrible | 11:29 |
| tristan | So, that's why we put the logfile name where we do, and why we strip the leading log base directory from it too | 11:30 |
| tristan | qinusty, the main conundrum here is that element names are obnoxiously variable in length | 11:30 |
| tristan | So, I keep wondering if we could do more height for width in our logging than just the height for width we do in the status area | 11:31 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail->master: Retries log as failures) #766 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/766 | 11:31 |
| toscalix | valentind: quite a few comments I made. I like the idea of the table because visually it is easier to associate instructions to the download and versions | 11:31 |
| tristan | qinusty, there was a point in the passed where we calculated the longest possible element name so that we could align the messages after the element name portion | 11:32 |
| tristan | qinusty, at that time, logging was SO MUCH MORE beautiful | 11:32 |
| toscalix | I would like to have a table if possible | 11:32 |
| toscalix | instead of text. We would need to do a table for the next release anyway | 11:32 |
| tristan | qinusty, and easy to read; but the problem is people started creating element names that are so long... so we'd have to consider terminal width in the calculation, and do some adjustments and possibly consistently line break the log lines on smaller terminals | 11:33 |
| toscalix | tristan: has the #470 fixes been backported? | 11:33 |
| tristan | qinusty, that way we might be able to have say, all of the "[...]" portions of the log line wrapped on two lines, and preserve alignment of the text which follows "MessageType" | 11:34 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail-backport->bst-1.2: Retries should fail Backport 1.2) #768 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/768 | 11:34 |
| qinusty | Backport ready for pipeline tristan ^ | 11:34 |
| tristan | toscalix, yes, in !760 | 11:34 |
| toscalix | great | 11:34 |
| tristan | qinusty, merge it :D | 11:34 |
| valentind | toscalix, I might have mixed up download page and installation guide page. Did not realize that was a difference. | 11:35 |
| toscalix | valentind: my recommendation is that you start by this ticket: https://gitlab.com/BuildStream/website/issues/9 | 11:36 |
| tristan | qinusty, When I set out to do logging in BuildStream, I was sick and tired of reading log files with a lot of the same information on each line, but without columnisation and alignment of fields; it's really tiresome for my eyes to have to scan all these unaligned lines | 11:36 |
| toscalix | each page has its own ticket explaining the page | 11:36 |
| toscalix | including references to the content structure document | 11:36 |
| toscalix | and the diagrams that summarises the structure | 11:37 |
| toscalix | the download page is all about structured links | 11:37 |
| toscalix | nothings else | 11:37 |
| qinusty | I agree tristan, I like that builds treatment mostly manages to align everything | 11:37 |
| qinusty | Buildstream, mobile autocorrect D: | 11:37 |
| tristan | BuildStream ! | 11:37 |
| tristan | hehe | 11:37 |
| tristan | qinusty, yeah, anyway that is a personal goal of mine, I might need to take out my own time to get a more ideal solution; which considers the terminal width while rendering lines and does the best possible fit | 11:38 |
| valentind | What was the badge for, the installation guide? | 11:38 |
| toscalix | the badges will be present in the download page | 11:39 |
| valentind | In plural? Which ones? | 11:39 |
| toscalix | the general idea is.... everytime sombody wants to consume buildstream, no matter her profile, it will be routed to the download page, and only to the download page | 11:40 |
| toscalix | the portfolio page says it will include the badge, but when you are done with the download page, I will probably rectify and decide to include them only in the download page | 11:41 |
| toscalix | the download page takes you to the installation page....and that one to the known issues, and that one to the FAQ. That is the critical path | 11:42 |
| toscalix | and the FAQ to the mailing list | 11:42 |
| toscalix | and to the examples | 11:42 |
| toscalix | so when we get support requests from novell users....it is not because they haven found the resourses, among other goals | 11:43 |
| toscalix | in summary, badges in the download page | 11:43 |
| valentind | toscalix, I am trying to understand this content structure. But I am not sure what semantic it has. Are those arrows links? | 11:44 |
| toscalix | yes, the main ones | 11:44 |
| toscalix | the website has a menu | 11:44 |
| toscalix | the arrows are the menu links | 11:45 |
| toscalix | inside the pages, there will be additional links | 11:45 |
| tristan | valentind, toscalix; I would consider them as parent <--> child relationships, rather than just links, but yes those are generally implemented with links when it is on a webpage | 11:45 |
| toscalix | tristan: correct, parent-child | 11:46 |
| valentind | So I see C.1. being the download page. | 11:46 |
| tristan | Regardless of the CSS and page design, this content structure makes sense | 11:46 |
| toscalix | sitemap relations | 11:46 |
| valentind | Where is the install guide page? | 11:46 |
| toscalix | we do not have it yet | 11:46 |
| toscalix | you need to extract the content from the documentation | 11:46 |
| tristan | valentind, Right now the install guide is in the BuildStream documentation, but I think we should migrate it to the website and remove it from the docs | 11:47 |
| toscalix | agree | 11:47 |
| tristan | it's the right separation | 11:47 |
| toscalix | valentin so there is one job first which is copy paste it in the website and format it. Let's see if can condense it in a single web page, even if it is long | 11:47 |
| tristan | So, we will keep them in the docs for some time, and only remove them from there once we know that all the relevant links have been updated, some time after | 11:47 |
| valentind | Will we have some kind of submenus? Will we have a link "path" so people can go upward? | 11:48 |
| tristan | Probably at least adding a link to the website from the docs, just in case | 11:48 |
| toscalix | then you need to work out the documentation to ensure that the instalation guide is removed and that there are no bloken links | 11:48 |
| toscalix | or dead ends | 11:48 |
| toscalix | tiagogomes: , that question is for you | 11:48 |
| tristan | valentind, I think that from every page you can access the main categories, but this might be more related to site design | 11:49 |
| tristan | I think the current pelican theme is super outdated, and we'll probably migrate to one of those fancy things where you scroll down the page to find your main topic entry points | 11:49 |
| toscalix | the title is clickable, but the site menu shows the childs, not the parent. valentind question is a good one | 11:49 |
| tristan | That'll happen once designers get involved, I would guess | 11:50 |
| toscalix | do you guys use the word pertinent? | 11:50 |
| toscalix | tiago is our official senoir designer today | 11:50 |
| tristan | toscalix, yes, that word makes perfect sense in english, I use pertinent all the time :) | 11:50 |
| toscalix | and I am today the senior content or documentation manager and technical writer. Oh man, not sure I will be able to have lunch | 11:50 |
| toscalix | without being killed by the real senior content managers and tech writers | 11:51 |
| toscalix | and now.... the front page, which in general, should be the last one in the bottom up approach | 11:52 |
| tristan | toscalix, tiagogomes... I dont think this is pertinent to what we intend to accomplish this week but: https://buildroot.org/, https://flatpak.org/, https://www.yoctoproject.org/ | 11:53 |
| gitlab-br-bot | buildstream: merge request (Qinusty/retries-should-fail-backport->bst-1.2: Retries should fail Backport 1.2) #768 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/768 | 11:54 |
| tristan | This is what is smart and sexy nowadays and I would expect the general flow for the front page to go in that direction, that is, if anyone concerned with aesthetics gets involved | 11:54 |
| valentind | Are we going to have a site map? I suppose we will need to declare the hierarchy of pages somehow. | 11:55 |
| tristan | I guess the first two links are better examples, but even the last one uses the same kind of flow, that is modern web UI | 11:55 |
| toscalix | valentind: we will have to. I would assume it will be automatically generated | 11:59 |
| toscalix | if not, we will do it | 11:59 |
| valentind | Should we use directories? | 11:59 |
| toscalix | I haven seen them in other sites so it might not be technically viable | 12:00 |
| toscalix | but tiagogomes should answer that | 12:00 |
| toscalix | haven't... using a ES keyboard the last few days | 12:01 |
| valentind | toscalix, what is GDP? | 12:06 |
| toscalix | a project where codethink worked for a year were we were in charge of the delivery/releases | 12:07 |
| toscalix | we had no designer and we did the contents on a wiki | 12:08 |
| toscalix | so it is a good example for this case at this point | 12:08 |
| valentind | toscalix, By the way "#" means "h2" in HTML. | 12:08 |
| valentind | Ah no | 12:09 |
| valentind | Sorry. | 12:09 |
| valentind | I was wrong. | 12:09 |
| valentind | No yes. # is h2. | 12:09 |
| valentind | ## is h3... | 12:09 |
| toscalix | ouch, then I need to correct all the other templates | 12:10 |
| toscalix | but the content is in markdown, right? | 12:10 |
| valentind | Yes. But you are not supposed to have more than one h1 in html. | 12:10 |
| valentind | So they made the "title" be "h1". Which makes sense. | 12:11 |
| toscalix | I see | 12:11 |
| toscalix | let's see if I can change all the titles before EOD | 12:12 |
| valentind | Also, I would put [TOC] between the title and the first section. | 12:12 |
| toscalix | unsure if the TOC includes the title or not | 12:12 |
| toscalix | valentind: agree | 12:12 |
| *** tristan has quit IRC | 12:27 | |
| gitlab-br-bot | buildstream: issue #616 ("timed activities sometimes balanced with WARNING in place of FAILURE, when task retries are enabled") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/616 | 12:29 |
| *** tlater[m] has quit IRC | 12:35 | |
| *** pro[m] has quit IRC | 12:35 | |
| *** ssssam[m] has quit IRC | 12:36 | |
| *** theawless[m] has quit IRC | 12:36 | |
| *** dineshdb[m] has quit IRC | 12:36 | |
| *** connorshea[m] has quit IRC | 12:36 | |
| *** albfan[m] has quit IRC | 12:36 | |
| *** krichter[m] has quit IRC | 12:36 | |
| *** cgmcintyre[m] has quit IRC | 12:36 | |
| *** awacheux[m] has quit IRC | 12:36 | |
| *** abderrahim[m] has quit IRC | 12:36 | |
| *** asingh_[m] has quit IRC | 12:36 | |
| *** segfault3[m] has quit IRC | 12:36 | |
| *** rafaelff[m] has quit IRC | 12:36 | |
| *** kailueke[m] has quit IRC | 12:36 | |
| *** mattiasb has quit IRC | 12:36 | |
| *** oknf[m] has quit IRC | 12:36 | |
| *** jjardon[m] has quit IRC | 12:36 | |
| *** waltervargas[m] has quit IRC | 12:36 | |
| *** m_22[m] has quit IRC | 12:36 | |
| *** alatiera is now known as alatiera_ | 12:37 | |
| *** bochecha has joined #buildstream | 12:39 | |
| *** tlater has quit IRC | 12:43 | |
| *** m_22[m] has joined #buildstream | 12:44 | |
| *** tlsa has left #buildstream | 12:48 | |
| * tiagogomes points out that he knows nothing about Pelican. All I can do is search as you | 12:55 | |
| toscalix | tiagogomes: you are the pelican master today | 12:58 |
| toscalix | :-D | 12:58 |
| bochecha | pelican the static website generator? | 12:59 |
| * tiagogomes yanks a feather | 12:59 | |
| tiagogomes | bochecha yes | 12:59 |
| bochecha | I built my website with Pelican… I haven't touched it in a while so I might have forgotten a lot about it, but maybe I can help? :) | 13:00 |
| tiagogomes | :) | 13:05 |
| tiagogomes | Should we use any of these themes: http://www.pelicanthemes.com/ | 13:07 |
| bochecha | that's not something I can help with :P (I made my own theme) | 13:10 |
| gitlab-br-bot | buildstream: merge request (tpollard/483->master: plugins/git.py: Warn if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 13:33 |
| toscalix | tiagogomes: I sent a new MR. I had to fight with git. On days like this, I realise I need to learn more about git | 13:52 |
| toscalix | quick lunch and back for the roadmap page, the last one to be structured | 13:53 |
| toscalix | then... fill out contents | 13:54 |
| *** leopi has quit IRC | 14:03 | |
| *** doras[m] has joined #buildstream | 14:16 | |
| *** awacheux[m] has joined #buildstream | 14:16 | |
| *** theawless[m] has joined #buildstream | 14:16 | |
| *** waltervargas[m] has joined #buildstream | 14:16 | |
| *** tlater[m] has joined #buildstream | 14:16 | |
| *** ssssam[m] has joined #buildstream | 14:16 | |
| *** rafaelff[m] has joined #buildstream | 14:16 | |
| *** albfan[m] has joined #buildstream | 14:16 | |
| *** abderrahim[m] has joined #buildstream | 14:16 | |
| *** asingh_[m] has joined #buildstream | 14:16 | |
| *** inigomartinez has joined #buildstream | 14:16 | |
| *** mattiasb has joined #buildstream | 14:16 | |
| *** kailueke[m] has joined #buildstream | 14:16 | |
| *** cgmcintyre[m] has joined #buildstream | 14:16 | |
| *** krichter[m] has joined #buildstream | 14:16 | |
| *** jjardon[m] has joined #buildstream | 14:17 | |
| *** alatiera has joined #buildstream | 14:17 | |
| *** segfault3[m] has joined #buildstream | 14:17 | |
| *** connorshea[m] has joined #buildstream | 14:17 | |
| *** pro[m] has joined #buildstream | 14:17 | |
| *** dineshdb[m] has joined #buildstream | 14:17 | |
| *** Demos[m] has joined #buildstream | 14:17 | |
| *** oknf[m] has joined #buildstream | 14:17 | |
| 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 | 14:19 |
| *** lachlan has joined #buildstream | 14:51 | |
| *** lachlan is now known as lchlan | 14:54 | |
| toscalix | valentind: around? | 14:55 |
| valentind | toscalix, yes | 15:00 |
| toscalix | not sure what to do about your MR related with the download page. | 15:00 |
| toscalix | are you focused on the installation guide? | 15:00 |
| valentind | toscalix, I am working on that. | 15:00 |
| toscalix | ah, ok | 15:00 |
| valentind | I will do it. Just I had interruptions. | 15:01 |
| toscalix | np | 15:01 |
| valentind | Sorry about it. | 15:01 |
| toscalix | no problem | 15:03 |
| toscalix | really | 15:03 |
| *** solid_black has quit IRC | 15:29 | |
| *** lchlan has quit IRC | 15:40 | |
| *** lchlan has joined #buildstream | 15:42 | |
| gitlab-br-bot | buildstream: merge request (Qinusty/cache-size-directory->master: Move cache_size.pid.log files into a subdirectory of logs) #769 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/769 | 15:57 |
| gitlab-br-bot | buildstream: merge request (Qinusty/cache-size-directory-backport->bst-1.2: Backport: Move cache_size.pid.log files into a subdirectory of logs) #770 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/770 | 15:59 |
| valentind | toscalix, I have converted the installation documentation from the documentation. https://gitlab.com/BuildStream/website/merge_requests/17 | 16:27 |
| toscalix | will check in a minute | 16:28 |
| valentind | There is no modification yet. Should we split it in several pages? | 16:28 |
| valentind | I am going back to the download page now. | 16:29 |
| toscalix | first.... I am trying and failing to erase a couple of branches on the website repo | 16:29 |
| toscalix | those that have toscalix on the name | 16:29 |
| valentind | toscalix, from https://gitlab.com/BuildStream/website/branches ? | 16:30 |
| toscalix | ah, thanks | 16:30 |
| toscalix | I lookig for this page | 16:30 |
| valentind | It is easier. I think you can do with "git push --delete" otherwise. | 16:30 |
| toscalix | git push origin --delete name of the branch did not seem to work | 16:31 |
| toscalix | will try again... | 16:31 |
| gitlab-br-bot | buildstream: merge request (dp0/513/cas-cache-client-certs->master: WIP: Support dynamic client certificates for CAS cache) #594 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/594 | 16:33 |
| toscalix | ah, now | 16:34 |
| valentind | I mixed up some links, but will fix them. | 16:38 |
| toscalix | checking your MR | 16:38 |
| toscalix | commented | 16:41 |
| toscalix | except fot the detail of the comment, I think it is good | 16:44 |
| valentind | I actually fixed it already. | 16:45 |
| valentind | I will make a new partial MR for downloads. Going step by step. | 16:46 |
| valentind | toscalix, https://gitlab.com/BuildStream/website/merge_requests/18 | 16:49 |
| toscalix | approved. should I remove the branch? | 16:51 |
| valentind | Yes | 16:52 |
| toscalix | good work | 16:53 |
| valentind | That was some changes for the download page that you merged. | 16:53 |
| *** jonathanmaw has quit IRC | 16:53 | |
| valentind | Maybe it was !17 you wanted to merge. | 16:53 |
| toscalix | we just need to add now to the top of the first table the rows for the new release, and a column with instructions | 16:54 |
| toscalix | that one too, but there is acomment I am not sure you adressed | 16:54 |
| toscalix | ah, you did | 16:54 |
| toscalix | merged both | 16:54 |
| toscalix | !18 required more a few changes but it is easy to do them now that we have the table redenring correctly | 16:55 |
| toscalix | additions, not changes | 16:55 |
| toscalix | I am trying to create a MR for the community page, which is the last one | 16:56 |
| valentind | I am not sure how instructions would fit in the table. | 16:57 |
| gitlab-br-bot | buildstream: merge request (dp0/casserver-tests->master: WIP: Enhance tests for casserver) #771 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/771 | 17:04 |
| tiagogomes | https://buildstream.build/ landing page, logo and whitelisted menu items | 17:06 |
| toscalix | new MR with the community page. Only roadmap missing | 17:08 |
| toscalix | tiagogomes: I added to gitlab a bigger pic of beever | 17:08 |
| * toscalix tries to remember where di I put it | 17:09 | |
| toscalix | ah, of course, in the ticket for the front page: https://gitlab.com/BuildStream/website/issues/12 | 17:10 |
| toscalix | you have there the link | 17:10 |
| tiagogomes | The image is a 800x798. It is reduced because otherwise it would be too big | 17:10 |
| toscalix | ah, ok | 17:10 |
| tiagogomes | posts links are not working, something for monday | 17:10 |
| toscalix | I would remove the beaver and add to BuildStream the sentece we have as title, that is, "BuildStream, the software integration tool" | 17:11 |
| toscalix | it is a good improvement anyway | 17:11 |
| toscalix | we moved things forward today | 17:12 |
| toscalix | made a note on the ticket | 17:14 |
| toscalix | redirections finished. Assigned to tiagogomes for Monday | 17:23 |
| gitlab-br-bot | buildstream: merge request (Qinusty/cache-size-directory->master: Move cache_size.pid.log files into a subdirectory of logs) #769 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/769 | 17:33 |
| *** lchlan has quit IRC | 17:36 | |
| *** toscalix has quit IRC | 17:55 | |
| *** lachlan has joined #buildstream | 18:00 | |
| *** lachlan has quit IRC | 19:06 | |
| *** alatiera_ has quit IRC | 20:33 | |
| *** rdale has quit IRC | 20:48 | |
| *** bochecha has quit IRC | 22:16 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!