| *** leopi has joined #buildstream | 04:33 | |
| *** tristan has joined #buildstream | 06:37 | |
| *** alatiera_ has joined #buildstream | 06:55 | |
| *** rdale has joined #buildstream | 07:38 | |
| *** tristan has quit IRC | 07:49 | |
| *** toscalix has joined #buildstream | 07:53 | |
| *** tristan has joined #buildstream | 08:11 | |
| *** jonathanmaw has joined #buildstream | 08:26 | |
| *** solid_black_ has joined #buildstream | 08:29 | |
| *** solid_black__ has joined #buildstream | 08:31 | |
| *** solid_black_ has quit IRC | 08:33 | |
| *** leopi has quit IRC | 08:40 | |
| *** leopi has joined #buildstream | 08:42 | |
| *** tristan has quit IRC | 08:43 | |
| qinusty | What route are we taking on analytics toscalix, valentind? | 08:48 |
|---|---|---|
| toscalix | none for now | 08:48 |
| toscalix | in the coming weeks I will explore | 08:48 |
| toscalix | anallytics on the website | 08:49 |
| toscalix | telemetry related with the software production comes next. Finally it would be about telemetry on the software itself, in accordance with open source and privacy standards | 08:50 |
| toscalix | I do not think the third step will happen soon | 08:50 |
| toscalix | we have a long way to go before it comes neccessary to understand how the software is being used in order to improve it. There are several Open Source projects that are doing a good job in this regard. We can evaluate them | 08:51 |
| toscalix | I had a nice conversation about this point in a dinner with people from canonical, debian and opensuse. Each one of them has a different approach | 08:51 |
| toscalix | it will be an interesting discussion to have in the future | 08:52 |
| toscalix | KDE for instance will be discusing about it this year. | 08:53 |
| toscalix | There was more resistance a few years ago than now since there are better tools now to respect data privacy while collecting data to improve | 08:54 |
| *** tristan has joined #buildstream | 08:56 | |
| *** ChanServ sets mode: +o tristan | 09:03 | |
| *** bochecha has joined #buildstream | 09:33 | |
| *** dtf has joined #buildstream | 09:35 | |
| *** lachlan has joined #buildstream | 09:36 | |
| qinusty | tristan, what's happening with the development snapshot badge? Will it work prior to 1.3.1? | 09:50 |
| 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 | 09:59 |
| *** lachlan has quit IRC | 10:08 | |
| *** jonathanmaw_ has joined #buildstream | 10:17 | |
| *** jonathanmaw has quit IRC | 10:18 | |
| WSalmon | tristan, thanks for the email and making time to look at the proposal :D | 10:22 |
| *** lachlan has joined #buildstream | 10:48 | |
| toscalix | qinusty: commented on your changes to FAQ | 10:49 |
| *** lachlan has quit IRC | 10:58 | |
| 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 | 11:09 |
| tristan | WSalmon, I've just finished my second reply which took a lot more time and thought | 11:12 |
| tristan | WSalmon, Sorry that you and Sander already replied, but I think I have a much better solution for opening multiple workspaces, I'd appreciate follow up there instead :D | 11:13 |
| tristan | valentind, sorry I've been very tied up and had it on my TODO to get through this workspace proposal before it runs out of sight without me | 11:33 |
| tristan | valentind, regarding your question of the install page for first time users, we should approximately follow http://buildstream.gitlab.io/buildstream/main_install.html | 11:34 |
| tristan | valentind, there are some adjustments we could make; but there are essentially 3 paths to choose: Distro, Source or Docker | 11:35 |
| qinusty | Where does PyPi come into that tristan? | 11:37 |
| valentind | tristan, ok, I proposed to move extract installation from git (or tarball) out of the installation from PyPI, but add a note box to link to the alternative method. This to avoid having user to need to hop over sections to get to the post install. Would that be OK? | 11:37 |
| cs-shadow | qinusty: PyPI comes under "installing via source" section | 11:38 |
| qinusty | I guess technically PyPI is just automating the install via source | 11:39 |
| qinusty | pip* | 11:39 |
| cs-shadow | yeah, and it can't be a complete solution since we have other host dependencies | 11:39 |
| tristan | qinusty, `pip install BuildStream` will fail if you have not installed the native base dependencies on your distro and followed the instructions for that first | 11:43 |
| tristan | qinusty, since pip is unable to automatically install all of the dependencies, it is considered an installation from source indeed | 11:43 |
| valentind | tristan, what is the recommended way? PyPI? Or installing from distro when available? | 11:44 |
| tristan | valentind, I dont understand what you have "extracted" to be honest | 11:44 |
| valentind | tristan, in installation from source, there are 3 sections. | 11:44 |
| tristan | valentind, Let me throw up a mockup (in the middle of), and we can discuss that way | 11:44 |
| valentind | - dependencies | 11:45 |
| valentind | - installation | 11:45 |
| valentind | - post install | 11:45 |
| valentind | In the installation section, there are 2 ways: from PyPI, or from git. | 11:45 |
| valentind | If you install from PyPI, when you are done with the section, you have to hop over and continue to "post-install" | 11:45 |
| valentind | And in my opinion, it is difficult to navigate. | 11:46 |
| valentind | Unless we had a dynamic website where you could collapse sub sections. | 11:46 |
| qinusty | Static websites can do that | 11:47 |
| qinusty | with JS | 11:47 |
| valentind | I think a tabbed box would be better than collapsing in that case. | 11:51 |
| qinusty | https://www.w3schools.com/bootstrap/bootstrap_ref_js_collapse.asp incase interested. We can div up our sections within the markdown I believe. SImilar to the way we do the id for #location | 11:52 |
| tristan | valentind, Ok this is the mockup I was able to very quickly draft: https://gitlab.com/BuildStream/buildstream/snippets/1750969 | 11:52 |
| tristan | valentind, for the main page that is, it keeps the same structure of subpages we currently have at http://buildstream.gitlab.io/buildstream/main_install.html | 11:52 |
| valentind | tristan, OK. | 11:53 |
| valentind | So we have a sub page for the dependencies. | 11:53 |
| tristan | valentind, For semantic versioning, we leave that out as it's too much information; but I think it is relevant on the "download" page, which we should link to from the "tarball" section | 11:53 |
| valentind | tristan, should we have a sub page for the post-install as well. I suppose so. But you forgot. | 11:53 |
| *** lachlan has joined #buildstream | 11:54 | |
| tristan | valentind, Well, currently the dependencies are a part of the "from source" subpage, we could keep it that way | 11:54 |
| tristan | Yes that is important too | 11:54 |
| valentind | qinusty, I will not have time to make some nice javascript. I am travelling tomorrow. But maybe when the site is done we can rework that. | 11:54 |
| tristan | valentind, I think that the main install should guide you through the process as much as possible, by linking you to the relevant parts; but it still makes sense to have all of http://buildstream.gitlab.io/buildstream/install_source.html on one subpage | 11:55 |
| tristan | I.e. then you still have it all in one page if you choose to jump up and down through the content | 11:55 |
| valentind | tristan, OK, so one subpage for the whole source install. And links onto sections from the main install page. | 11:55 |
| qinusty | Okay valentind, I think it'd work with basic html classes, as long as bootstrap is already set up with the theme. | 11:56 |
| mablanch | juergbi, I've updated !626 (REAPI client), would you mind having a look when you'll have time? I'm especially interested in the comments you'd have regarding the CASCache changes. | 11:56 |
| tpollard | can I change the location of the buildstream cache from project.conf? | 11:57 |
| juergbi | mablanch: sure, will do | 11:57 |
| valentind | tristan, OK, we go for that. But I think when we have more time we need to find a way to make navigation within the source installation sub page easier. | 11:57 |
| mablanch | juergbi, Thank you! | 11:57 |
| tristan | valentind, So, in order to reconcile the "Which version to use" issue for people who *want* to choose git (and those people I presume are fairly plentiful), it will be good to link to the download page (semantic versioning section of it), in the same way we link to it from the tarball section | 11:59 |
| tristan | I think that brings a lot of related content together well | 11:59 |
| tristan | And we leave out the artifact server install completely *for now*, it is clutter for the newcommer | 11:59 |
| tristan | Maybe the install guide for the artifact server should remain in the reference manual | 12:00 |
| tristan | valentind, that probably makes sense since (A) We don't guarantee stability of the server side stuff from major release to release... (B) The reference documentation is a per-release thing already, bound to the version of BuildStream you have | 12:01 |
| tristan | and of course (C), it's more terse and involved than a newcommer experience which we want to keep as simple as possible | 12:01 |
| tristan | tpollard, local cache location is not project data, it is user config | 12:04 |
| tpollard | tristan: ok, so I can do it from .config/buildstream.conf right? | 12:04 |
| tristan | tpollard, The remote server URLs are technically only considered project data because a project might provide one to share with it's users | 12:04 |
| toscalix | qinusty: do you have in your radar my comments to your MR31 ? | 12:04 |
| tristan | tpollard, however it can also be overridden from user user config | 12:04 |
| tristan | Yes :) | 12:04 |
| tristan | tpollard, http://buildstream.gitlab.io/buildstream/using_config.html#default-configuration | 12:05 |
| tpollard | cheers tristan | 12:05 |
| tristan | tpollard, currently the user config could be better documented, while we do have full coverage; some of it is only documented via comments in the default configuration | 12:06 |
| tristan | might be best to change that to match what we've done with project configuration docs, and clearly document everything in markup, while also providing the defaults at the bottom | 12:06 |
| toscalix | After lunch I will work on the Community page. | 12:09 |
| toscalix | thanks tiagogomes | 12:10 |
| valentind | tristan, OK, so I think I have fixed everything you asked for on https://gitlab.com/BuildStream/website/merge_requests/27 | 12:27 |
| valentind | tristan, Remember I am leaving tomorrow. So if you need me to change things on this MR, please tell me today. You can finish the MR tomorrow however. | 12:28 |
| *** mohan43u has quit IRC | 12:42 | |
| *** mohan43u has joined #buildstream | 12:42 | |
| WSalmon | what's that easiest way to get build stream to build a element rather than using the cache? i have tweaked a build element and want to see what it dose, currently i just tweak the element.bst file but that seems very silly | 12:46 |
| Nexus | delete the cache | 12:50 |
| WSalmon | umm, i gues its tells you the cache keys... | 12:51 |
| * Nexus just deletes ~/.cache/buildstream/ but results may vary | 12:52 | |
| Nexus | or remove the ref line from the .bst file, i think that works | 12:52 |
| * tristan takes a look | 12:54 | |
| gitlab-br-bot | buildstream: issue #624 ("Stack trace when log files cause UTF-8 errors") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/624 | 13:09 |
| tristan | valentind, semantic versioning -> download page, not FAQ, FAQ already directs user to download page where the latest versions are reflected and directly answer the "What version do I use" question | 13:18 |
| valentind | OK | 13:19 |
| valentind | tristan, toscalix wanted to put it on the portfolio. | 13:20 |
| toscalix | it is already there | 13:21 |
| tristan | Errr | 13:23 |
| toscalix | tiagogomes_: why the bullet points are not rendered properly? | 13:23 |
| tristan | So you want to put the semantic versioning explanation in a place far away from the table which shows the release versions ? | 13:23 |
| toscalix | I put the explanation of the versioning where I explain the deliverables of the project | 13:24 |
| toscalix | only those consuming dev snapshots care about the numbring | 13:24 |
| tristan | toscalix, This is quite breaking; we should see this explanation linked from the install instructions for git at the very least | 13:24 |
| toscalix | numbering | 13:24 |
| tristan | I mean, that is where it is most relevant; user decides they want to install from git; they need an explanation of how the tags work | 13:25 |
| tristan | The practical solution here; was to have semantic versioning tightly coupled with the release table on the downloads page; so that both the tarball + git instructions can point to the same place | 13:25 |
| tristan | It also makes sense from the FAQ to answer "What version should I use", to a location which shows the latest versions, *and* explains the meaning of the version numbers | 13:26 |
| toscalix | Which version should I use.... the lates | 13:26 |
| toscalix | latest | 13:26 |
| tristan | toscalix, Maybe we can move it to the related downloads table; and link to it from the portfolio ? | 13:27 |
| toscalix | again, the user do not care about versioning numbers. They consume releases | 13:27 |
| tristan | toscalix, Ummm, "The latest" is ambiguous; that is *exactly* the reason why paulsher1ood has been frustrated about this | 13:27 |
| toscalix | versioning numbers care for those consuming dev snapshots | 13:27 |
| toscalix | ambiguous....I thought the badge answered that question | 13:27 |
| toscalix | that question should be answered.... go to the download page and click in the badge | 13:28 |
| tristan | toscalix, only when you see the badge; which is on the downloads page, nicely above the list of stable releases with links to their release announcements | 13:28 |
| toscalix | or add the badge directly to FAQ | 13:28 |
| tristan | toscalix, You are only answering the FAQ part of this | 13:28 |
| tristan | toscalix, the *most* important place for someone to know about the semantic version, is for the power user who chose to install from git | 13:29 |
| toscalix | the semantic versioning text is best placed where the different deliverables are described | 13:29 |
| tristan | toscalix, it makes sense to send both users who install from tarball or install from git; to the same location | 13:29 |
| toscalix | if you need to reference to them, add a link | 13:29 |
| tristan | That location shows all the releases, their numbers, and explains the numbering | 13:29 |
| toscalix | but if you do not agree....as like with the download page.... feel free to change it | 13:29 |
| valentind | tristan, I have put it in the download page on the MR. We can maybe decide later which one goes away. | 13:30 |
| toscalix | the download page is important for users....who do not care about release numbering | 13:30 |
| toscalix | adding it to that page only brings irrelevant information to them | 13:30 |
| tristan | toscalix, That is again incorrect; users who do not care about release numbering go to the Install page, and most of them never find the download page | 13:31 |
| tristan | In fact, the download page; should be renamed the "releases" page | 13:31 |
| tristan | It shows all the releases, and shows which one is latest, and is rather a power user thing | 13:31 |
| toscalix | if it is incorrect, then fine, go ahead and change it. | 13:31 |
| tristan | Normal users, do not download. | 13:31 |
| valentind | tristan, we should think of removing the download page from the main menu and put the install page instead. Should I put that in the MR? | 13:31 |
| tristan | valentind, I assumed that you did so far | 13:32 |
| paulsher1ood | "homonym toolset" ??? | 13:32 |
| tristan | paulsher1ood, eek, that looks crazy, wonder where that came from | 13:32 |
| flatmush | I'm currently trying to setup a buildstream cache, I followed the instructions here: | 13:32 |
| flatmush | https://buildstream.gitlab.io/buildstream/install_artifacts.html | 13:32 |
| flatmush | With the only exception being that I only provide the CI with the private key for the push/pull server. | 13:32 |
| flatmush | But I'm getting the following error: | 13:32 |
| flatmush | https://gitlab.com/trustable/distros/minimal-distro/-/jobs/94525056 | 13:32 |
| toscalix | paulsher1ood: tristan if you do not my texts, feel free to change it. I understand it is not one of my strengths | 13:33 |
| toscalix | do not like .... | 13:33 |
| tristan | toscalix, I had to catch up with the workspaces thread before it runs off on the horizon without me today, no worries I understand | 13:34 |
| paulsher1ood | where is the source? i'll fix it | 13:34 |
| tristan | I have not had time to look at everything on the website in detail | 13:34 |
| tristan | paulsher1ood, https://gitlab.com/BuildStream/website | 13:34 |
| valentind | tristan, I put the link in the menu. | 13:34 |
| toscalix | https://gitlab.com/BuildStream/website/tree/master/content | 13:34 |
| paulsher1ood | ack | 13:35 |
| qinusty | toscalix, I did see your ping pop up. But can't find it in my channels... Might be blind. But yes, I'm looking into those changes as we speak | 13:35 |
| tristan | valentind, Great, instead of Download I presume; since that content is now all about the upstream releases and versioning; shall we also title it "Releases" ? | 13:35 |
| valentind | What should we title release? The download page? | 13:36 |
| tristan | valentind, The word "Download" (and I understand why toscalix chose it), comes with the presumption that (A) The user downloads a payload (B) The user proceeds to install the downloaded payload; it makes sense in many contexts | 13:36 |
| valentind | OK | 13:36 |
| tristan | But we ended up having a nice and valuable result there | 13:36 |
| tristan | So yeah, lets call it that; and we'll want to tightly couple this with the major release announcements in some way later on I suppose | 13:37 |
| toscalix | every single new user will look for the word download, no matter how they consume the software | 13:37 |
| * coldtom would look for install first, given i wouldn't want a tarball | 13:37 | |
| toscalix | instead of trying to be accurate, I would rather do the most popular thing, to be predictable | 13:38 |
| * cs-shadow agrees with coldtom | 13:38 | |
| tristan | I understand that windows users would, and people who want to install an ISO distro image ; both would be looking for download | 13:38 |
| tristan | That said, when you arrive on the site; and your choices are (A) (B) (C) and (Install), you will go to (Install) | 13:38 |
| valentind | tristan, done. | 13:39 |
| toscalix | we are not doing these contents for "people like us" | 13:39 |
| toscalix | but for a much wider audience | 13:39 |
| qinusty | I'd argue the people using buildstream are system integrators and software engineers. | 13:40 |
| tristan | toscalix, We are not going over this anymore - it's important that we dont send users to this download page when what they should be doing is following the install instructions instead | 13:40 |
| qinusty | If you're installing onto a Linux system, a tarball e.g. (Download) is even more complicated to you | 13:40 |
| tristan | toscalix, We have to provide the critical path first | 13:40 |
| toscalix | we are not developing contents for people using buildstream, but for those who do not | 13:40 |
| qinusty | Either way, the more complicated install route is the tarball. Hence why it should be kept for power users | 13:41 |
| tristan | toscalix, If we send them to a download page, they will download a tarball, and then wonder what to do with it, then they will go to the installation instructions; and find out they never needed a tarball, or to know what version they wanted in the first place | 13:41 |
| toscalix | the current critical path is broken. You will need to find a new one fast or fix it later | 13:41 |
| tristan | I.e.: It's just a frustrating experience we can avoid. | 13:41 |
| toscalix | the download page can perfectly contain the link to the right install section and a note explaining what to do. | 13:42 |
| toscalix | the point is not the content but which page should be routing users after they read the release annoucnement and they read the feature page | 13:42 |
| tristan | toscalix, That means (A) Extra click to get where you should be... (B) Irrelevant information for the new user given to the user | 13:42 |
| tristan | We want to avoid those things | 13:42 |
| toscalix | last minute ideas without a big pic end up with broken design, like it happens with code. | 13:43 |
| tristan | Users will not read the feature page and release announcement often, honestly; unless they are already existing users. | 13:43 |
| toscalix | So I no not think is worth discussing much about it. We have too much to do | 13:43 |
| toscalix | I will go back to the community page | 13:43 |
| tristan | toscalix, Please just give up; I understand you put effort into this design, and you think there should be a download page - we agree that this is wrong and misleading especially to the new user. | 13:44 |
| * toscalix wonders what a journalist will read first about a release: the announcment and then the feature page | 13:44 | |
| tristan | A journalist is looking for something different than installing and using BuildStream | 13:44 |
| tristan | They might be into the release announcements, indeed | 13:45 |
| adds68 | flatmush, any logs on the server? | 13:45 |
| toscalix | tristan: many of them, the good ones, will want to install it | 13:45 |
| tristan | And we should be able to direct them there through the news feed | 13:45 |
| tristan | toscalix, So they will also be directed to the right places | 13:45 |
| flatmush | adds68: What kind of logs do you want? | 13:45 |
| toscalix | anyway..... my experience in that field does not seem to count either, so back to my work | 13:45 |
| toscalix | Tristan, I see no specific license in the docu so I assume it inherits the license from the repo, which is LGPL2.1, correct? | 13:54 |
| toscalix | tristan ^^ | 13:55 |
| paulsher1ood | https://gitlab.com/BuildStream/website/merge_requests/33 | 13:56 |
| toscalix | paulsher1ood: are you sure you want to name other projects in your front page? This has an impact on the searches | 13:57 |
| tristan | toscalix, Correct | 13:57 |
| adds68 | flatmush, are you running it under systemd for example (the cache server) | 13:58 |
| flatmush | adds68: Yep | 13:58 |
| flatmush | as close to the example as possible | 13:58 |
| adds68 | flatmush, is there any event logs in journalctl ? | 13:58 |
| flatmush | so same ports, same two unit files | 13:58 |
| flatmush | nothing weird happens at the point where the error occurs | 13:58 |
| paulsher1ood | toscalix: why not? | 13:59 |
| paulsher1ood | it's the truth | 13:59 |
| adds68 | hmm, i've seen this before where it's actually a bst issue and not your cache server | 13:59 |
| tristan | flatmush, this looks horrible :-/ I presume you have the latest 1.2.0, and that loading the configuration failed for some reason | 13:59 |
| toscalix | you can tell the truth in another page and use this one to get a better position when searching for build tool, integration tool, etc | 13:59 |
| adds68 | flatmush, what about dmesg? | 13:59 |
| tristan | flatmush, further, there should be a stack trace with a BUG message, I wonder where that went :-S | 14:00 |
| tristan | adds68, thanks for following up on this | 14:00 |
| flatmush | tristan: I'm using the 1.1.7 tag | 14:00 |
| tristan | flatmush, that shouldn't make a difference, I don't recall anything in configuration of caches landing between 1.1.7 and 1.2.0 | 14:00 |
| flatmush | I only gave the client-key field in the artifacts: section of the project.conf | 14:01 |
| flatmush | because I assumed that was all that's needed (otherwise I'd have to upload a load of public keys) | 14:01 |
| toscalix | paulsher1ood: you can tell the truth in another page and use this one to get a better position when searching for build tool, integration tool, etc | 14:02 |
| paulsher1ood | meh | 14:02 |
| paulsher1ood | by all means amend the commit | 14:03 |
| toscalix | ups, approved it | 14:03 |
| flatmush | adds68: I'm getting an sshd key error, but I was under the impression that the cache is just http now? | 14:03 |
| adds68 | flatmush, if you provide keys i think it is https | 14:04 |
| tristan | valentind, lets go ahead with !27, it's better to land right away, observe, iterate | 14:04 |
| flatmush | Sep 04 15:03:47 cache sshd[10657]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key | 14:04 |
| flatmush | but that's happening even when the test isn't running so I suspect not relevant | 14:04 |
| flatmush | adds68: I'm only providing the private key (client-key), because I was under the impression that the public keys aren't needed, is that correct? | 14:05 |
| adds68 | flatmush, no they are always needed unless you are using a proper certificate authority | 14:08 |
| toscalix | tiagogomes: it seems that the bullet points are not rendered properly. Do I need to leave spaces in front of the buller points or something? | 14:08 |
| tiagogomes | toscalix where? | 14:08 |
| toscalix | tiagogomes: https://buildstream.build/portfolio.html | 14:09 |
| tristan | adds68, flatmush; As I suspect you may have found the cause of this error, can you please file an issue about what happened so we can improve the error message here ? I suspect its a very easy fix and would like to have it in 1.2.1 | 14:09 |
| tiagogomes | toscalix they look good to me :) You have to leave a blank line before starting the list | 14:10 |
| toscalix | tiagogomes: checking a different browser | 14:11 |
| toscalix | nop, they are not correct, checking sources | 14:11 |
| tiagogomes | What do you mean by "not correct" | 14:11 |
| flatmush | tristan: Will do | 14:12 |
| toscalix | tiagogomes: I see them as paragraph, not as list, on the website | 14:13 |
| tristan | I'm really stumped why we have a formatted exception in a BUG message without a stack trace :-S | 14:13 |
| qinusty | In our message API overhaul tristan, there are a few instances of BUG messages being instantiated in different places | 14:14 |
| qinusty | perhaps one of them is incorrect? | 14:14 |
| toscalix | tiagogomes: the second paragraph should be a list in https://buildstream.build/portfolio.html | 14:15 |
| tristan | valentind, Did we still not find a solution for the instructions to format like `.. code::` does ? | 14:15 |
| tiagogomes | toscalix you don't see this https://pasteboard.co/HCkYgL2.png | 14:15 |
| toscalix | ah, no, wait | 14:15 |
| 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 | 14:15 |
| qinusty | tristan, I think it's a css thing. ```code``` is definitely a code block | 14:15 |
| tristan | valentind, I.e. nicely boxed code examples, not bold burgundy text | 14:15 |
| tristan | qinusty, Hmmm, ok so I guess we need to fix that in the theme ? | 14:16 |
| qinusty | perhaps | 14:16 |
| tristan | Looks really bad the way it is | 14:16 |
| qinusty | it's putting it inside a <pre> block | 14:16 |
| qinusty | I agree | 14:16 |
| tristan | tiagogomes, are you on it ? | 14:16 |
| qinusty | https://buildstream.gitlab.io/buildstream/HACKING.html#feature-additions | 14:16 |
| qinusty | rip wrong link | 14:16 |
| toscalix | tiagogomes: I see it, correct, the lists are there, it is just that there are asterisks in the middle of the text. Checking why | 14:16 |
| qinusty | http://docs.getpelican.com/en/3.6.3/content.html#syntax-highlighting | 14:16 |
| qinusty | "For Markdown, which utilizes the CodeHilite extension to provide syntax highlighting, include the language identifier just above the code block, indenting both the identifier and the code:" | 14:16 |
| qinusty | They aren't using ``` | 14:17 |
| tiagogomes | toscalix there are asterisks because you put them there in the source | 14:18 |
| *** lachlan has quit IRC | 14:18 | |
| toscalix | tiagogomes: my first report is correct. Some of the lists in that page are not rendered properly | 14:18 |
| tristan | valentind, ^^^^^^ See what qinusty said here regarding how to format the shell commands people need to copy paste while installing | 14:18 |
| qinusty | It looks like indented blocks are code blocks to pelican? | 14:18 |
| tristan | valentind, I suppose we need to use ``` (like what we use in gitlab markdown, actually) | 14:18 |
| toscalix | tiagogomes: maybe it is because there should be a line between text and lists | 14:19 |
| tristan | Then we do ```python or ```yaml if we want syntax highlighting for those | 14:19 |
| tiagogomes | <tiagogomes> toscalix they look good to me :) You have to leave a blank line before starting the list | 14:19 |
| toscalix | your assumption was correct. It renders properly in gitlab but not in pages | 14:19 |
| gitlab-br-bot | buildstream: issue #625 ("BUG without stack trace when public keys are not specified for an artifact cache using a self-signed certificate") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/625 | 14:21 |
| WSalmon | I had a chat with juergbi about "Out of source builds" and we came up with https://gitlab.com/BuildStream/buildstream/merge_requests/776/ i think we have got to quite a nice place but before i spend ages cleaning it up i would really appriciate some architectureal feed back on if i have gont too far especally ragards to buildstream/buildelement.py and buildstream/data/projectconfig.yaml many thanks (tristan) i know you are mega busy but if you | 14:24 |
| WSalmon | are going to veto this is would be great to get it earlier than later :) | 14:24 |
| paulsher1ood | toscalix: sorry, i introduced a typo... https://gitlab.com/BuildStream/website/merge_requests/37 | 14:24 |
| tiagogomes | Aesthetically, what bothers people most on the website | 14:27 |
| tristan | WSalmon, sigh... ok it's on my desk first thing tomorrow, I hope it's not changing too much stuff | 14:27 |
| valentind | tristan, We use ``` | 14:28 |
| tristan | WSalmon, my expectation was this was all doable from yaml for individual elements which support that; my thoughts are the core should not know anything about out of source builds | 14:28 |
| tristan | WSalmon, those are only a detail that some build elements can implement in their yaml (not all of them can do it, even) | 14:29 |
| qinusty | valentind, their docs use indentation for code blocks | 14:29 |
| valentind | Oh so codehilite? | 14:29 |
| qinusty | http://docs.getpelican.com/en/3.6.3/content.html#syntax-highlighting | 14:30 |
| qinusty | valentind ^ | 14:30 |
| tristan | Missing a plugin ? | 14:30 |
| qinusty | Syntax for plugin highlighting, but the actual code block example for markdown | 14:30 |
| qinusty | is just indented. | 14:30 |
| paulsher1ood | tiagogomes: shall i attempt to fix the 'first bullet point is too high' problem? | 14:31 |
| tristan | sounds familiar, so many flavors of markdown | 14:31 |
| tiagogomes | paulsher1ood go for it | 14:31 |
| WSalmon | tristan, it is almost all in yaml 3 lines in python, i hope its ok but if you dont like the core bits than it still all works its just a bit more long hand, thanks for finding some time tomorrow :D | 14:32 |
| tristan | WSalmon, I'll do my best yeah; I'll take a look; about to hit the road now it's 11:30 | 14:33 |
| WSalmon | thanks :D | 14:34 |
| tristan | valentind, tiagogomes; by the way; when we run `make publish` https://gitlab.com/BuildStream/website/blob/master/Makefile ... I don't understand why, but pelican seems to be reporting success even when it spews errors in the output | 14:35 |
| tristan | Would be good to fix it so that we don't accidentally publish broken changes | 14:36 |
| tiagogomes | Are really errors rather than warnings? | 14:36 |
| 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 | 14:37 |
| tristan | tiagogomes, it happened with: "ERROR: Could not process pages/download.md" | 14:37 |
| tristan | tiagogomes, with a result of a missing page, also the accompanying warning was pretty bad | 14:37 |
| tiagogomes | That doesn't look like a warning :o | 14:37 |
| tristan | It would be good to error out on warnings also, we do that for the sphinx builds and it helps catch all sorts of stuff, like broken internal links | 14:38 |
| tristan | anyway, it's since been fixed; but the fact that we don't catch the errors is bad :) | 14:39 |
| tiagogomes | There's nothing on the CI configuration or Makefile that could cause that. I can only think that pelican does not return a non zero exit code on such errors | 14:40 |
| *** tiagogomes has quit IRC | 14:40 | |
| *** tiagogomes has joined #buildstream | 14:41 | |
| tiagogomes | There's nothing on the CI configuration or Makefile that could cause that. I can only think that pelican does not return a non zero exit code on such errors | 14:42 |
| valentind | tristan, Using codehilite: https://gitlab.com/BuildStream/website/merge_requests/38 | 14:43 |
| valentind | However there is no box around. But we can change that in the CSS. | 14:44 |
| tristan | tiagogomes, I just noticed we dont run pre-merge CI | 14:45 |
| flatmush | toscalix: jjardon: Can I get developer access to the buildstream gitlab? I want to push a branch which updates to the artifact cache document. | 14:45 |
| tristan | tiagogomes, in BuildStream, we *build* the docs in pre-merge and post-merge, and it creates an artifact; then we *only* publish the docs in a separate step when running from master | 14:45 |
| toscalix | flatmush: on it | 14:45 |
| tristan | https://gitlab.com/BuildStream/buildstream/blob/master/.gitlab-ci.yml#L140 | 14:46 |
| tristan | https://gitlab.com/BuildStream/buildstream/blob/master/.gitlab-ci.yml#L230 | 14:46 |
| tristan | tiagogomes, ^^^ that might help | 14:46 |
| tiagogomes | pelican always returns 0 :( | 14:46 |
| tristan | wtf ? | 14:46 |
| tristan | Always ? not even an option ? | 14:47 |
| toscalix | flatmush: done | 14:47 |
| tristan | Do they provide a linter instead or smth ? | 14:47 |
| flatmush | toscalix: thanks | 14:47 |
| tristan | Does anyone even use pelican, then ? | 14:47 |
| tiagogomes | ` --fatal errors|warnings` | 14:47 |
| tristan | Ah, that would do it right ? | 14:47 |
| valentind | I have noticed that in plugins when you raise an exception, it is just swallowed and it continues. | 14:48 |
| tiagogomes | yeah, it works. Strange it is not on by default for errors | 14:48 |
| tristan | cool | 14:48 |
| tristan | I mean, weird for plugins, but at least we can make these things fatal and CI the site for breakage | 14:48 |
| * tristan hits the road... enough ! hehe | 14:49 | |
| gitlab-br-bot | buildstream: merge request (benbrewer/install-artifacts-doc-improvements->master: Improve documentation for artifact cache installation) #777 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/777 | 14:50 |
| flatmush | adds68: Can you have a look at that merge request ^^ | 14:51 |
| *** tristan has quit IRC | 14:52 | |
| *** tiagogomes has quit IRC | 14:57 | |
| *** tiagogomes has joined #buildstream | 14:58 | |
| gitlab-br-bot | buildstream: merge request (benbrewer/install-artifacts-doc-improvements->master: Improve documentation for artifact cache installation) #777 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/777 | 14:58 |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/31#note_98750482 toscalix, can you elaborate? | 15:04 |
| WSalmon | flatmush, what dose `_ do? | 15:07 |
| WSalmon | oh | 15:07 |
| WSalmon | i hadnt seen the first ` | 15:08 |
| WSalmon | dose it make the <> a link? | 15:08 |
| *** lachlan has joined #buildstream | 15:08 | |
| flatmush | WSalmon: Good question, I copied it from another page, seemed to be the way external URL's are linked. | 15:08 |
| flatmush | The stuff within the weird quotes is the text, and the angle brackets contain the link, not sure why there has to be an underscore at the end, but it's used that way in other files | 15:09 |
| toscalix | qinusty: canoot now. I do not remember the context. I resolved the discussion | 15:09 |
| WSalmon | https://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html seem so | 15:10 |
| 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 | 15:11 |
| *** lachlan has quit IRC | 15:13 | |
| *** tristan has joined #buildstream | 15:16 | |
| *** ChanServ sets mode: +o tristan | 15:16 | |
| 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 | 15:17 |
| 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 | 15:18 |
| toscalix | tiagogomes: https://gitlab.com/BuildStream/website/merge_requests/36/ | 15:22 |
| 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 | 15:23 |
| tiagogomes | toscalix that has merge conflicts | 15:26 |
| toscalix | ah ok | 15:29 |
| WSalmon | any one got a good cmake example i can use to test my out of source builds with? | 15:32 |
| WSalmon | coldtom, adds68 maybe ^ | 15:32 |
| coldtom | there's a few cmake elements in freedesktop, fcitx is one i had to fix recently iirc | 15:34 |
| WSalmon | ta | 15:36 |
| 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 | 15:44 |
| *** lachlan has joined #buildstream | 15:48 | |
| toscalix | tiagogomes: I think now is better https://gitlab.com/BuildStream/website/merge_requests/39 | 15:48 |
| toscalix | ah, so the name of the download page changed .... can we put it back please? Otherwise we already have plenty of broken links all over the place | 15:49 |
| juergbi | Kinnison: regarding #583, so .close() on Queue and Popen objects don't actually close all fds, or are we failing to invoke close in appropriate places? | 15:51 |
| Kinnison | juergbi: It's insufficient | 15:51 |
| toscalix | valentind: change it back, please | 15:51 |
| Kinnison | juergbi: I believe I have a fix | 15:51 |
| Kinnison | juergbi: I'm just testing it | 15:51 |
| juergbi | :) | 15:51 |
| * Kinnison stashes his scary monkeypatching of os.pipe() and os.close() | 15:51 | |
| tiagogomes | toscalix what do you mean? | 15:52 |
| toscalix | download.html does not exist anumore | 15:53 |
| toscalix | anymore | 15:53 |
| *** dtf has joined #buildstream | 15:54 | |
| Kinnison | Does anyone know why I might get https://pastebin.com/KJB4jXWk when trying to do 'python3 setup.py test' ? | 15:54 |
| *** lachlan has quit IRC | 15:55 | |
| toscalix | wrote a mail to tristan and valentind so they revert the name change of the page or fix the links in the rest of the pages | 15:55 |
| valentind | toscalix, I will fix it. | 16:00 |
| toscalix | thanks | 16:00 |
| valentind | https://gitlab.com/BuildStream/website/merge_requests/40 | 16:03 |
| tpollard | not pulling in the buildtree of llvm feels so liberating | 16:07 |
| tlater[m] | Kinnison: WIld guess, but we've had issues with pylint and pylint-runner version mismatches... | 16:13 |
| tlater[m] | There's a chance you're using incompatible versions - I don't think we've gotten around to pinning the version yet. | 16:13 |
| Kinnison | I dumped my .eggs and it is running now | 16:13 |
| Kinnison | thanks | 16:14 |
| tlater[m] | Ah, alright :) | 16:15 |
| toscalix | qinusty: for now, let's add it as planned in the website. If we move it, it will be in the future | 16:15 |
| Kinnison | Okay, that's fun, loads of lint errors for code which wasn't touched by me /o\ | 16:15 |
| Kinnison | e.g. | 16:15 |
| Kinnison | _____________________________________________________________ [pylint] buildstream/sandbox/_sandboxbwrap.py ______________________________________________________________ | 16:15 |
| Kinnison | R:142,12: Consider using dict.get for getting values from a dict if a key is present or a default if not (consider-using-get) | 16:15 |
| Kinnison | should I ignore those? | 16:15 |
| tiagogomes | toscalix what remains to be done in the website | 16:16 |
| tlater[m] | That in turn is known to be caused by newer versions of pylint than we're used to - qinusty would know which errors that brings up exactly. | 16:16 |
| Kinnison | okies, so I can ignore them. Cool | 16:16 |
| * Kinnison might (terrifyingly) have an MR ready soon | 16:16 | |
| tlater[m] | Kinnison: #570 tells you exactly what errors you can ignore, but that one seems safe :) | 16:17 |
| *** solid_black__ has quit IRC | 16:18 | |
| gitlab-br-bot | buildstream: merge request (tiagogomes/issue-573->master: Reduce IO overhead caused by artifact cache size calculation) #671 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/671 | 16:20 |
| Kinnison | What should the approvers list look like for an MR? It seems to default to requiring tristan approve | 16:23 |
| qinusty | Depends on the impact of the MR Kinnison | 16:25 |
| * tlater[m] isn't sure if "a few who seem qualified" is good enough anymore. Happy to review if you need someone though | 16:25 | |
| Kinnison | tlater[m]: does it cause issues if I leave it set at tristan? | 16:26 |
| qinusty | If it's fairly trivial, you can have one or two contributors review it | 16:26 |
| * Kinnison knows tristan weighed in on the issue (#583) | 16:26 | |
| tlater[m] | No, that shouldn't be an issue | 16:26 |
| qinusty | Nah, it can be left. MR's have a requirement of 0 reviewers technically | 16:26 |
| Kinnison | Okay, I'll leave it as is | 16:26 |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/maybe-reduce-fd-leaks->master: jobs.py: Reduce FD leaks from queues and process objects) #778 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/778 | 16:26 |
| * qinusty will take a look once you push it | 16:26 | |
| Kinnison | qinusty: https://gitlab.com/BuildStream/buildstream/merge_requests/778 | 16:27 |
| * tlater[m] sees Kinnison is playing with fire | 16:28 | |
| Kinnison | ? | 16:28 |
| tlater[m] | Oh, nevermind, it's just a message queue | 16:28 |
| * Kinnison would be quite worried if the queue was on fire | 16:29 | |
| toscalix | tiagogomes: still aorund? | 16:30 |
| qinusty | Kinnison, how does this behave when retries are involved? I am not familiar with the use of a multiprocessing queue between multiple forked processes | 16:30 |
| *** lachlan has joined #buildstream | 16:31 | |
| tiagogomes | toscalix yes | 16:31 |
| Kinnison | qinusty: unless I'm very mistaken, if the job needed to retry, it'd rerun Job.spawn() which would recreate the queue and process instances it needed | 16:31 |
| toscalix | tiagogomes: https://buildstream.build/community.html | 16:31 |
| * Kinnison has a quick peek | 16:31 | |
| *** dtf has joined #buildstream | 16:32 | |
| qinusty | Kinnison, ignore me | 16:32 |
| qinusty | I am being tired and reading the diff back to front | 16:32 |
| Kinnison | hehe | 16:32 |
| toscalix | tiagogomes: I should assume you need 6 spaces for a subitem in a list | 16:32 |
| toscalix | before the asterisk | 16:32 |
| toscalix | comparing the web page with the source: https://gitlab.com/BuildStream/website/blob/master/content/pages/community.md | 16:33 |
| tiagogomes | possibly, you know you can test the changes locally easy | 16:33 |
| toscalix | how? | 16:33 |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/maybe-reduce-fd-leaks->master: jobs.py: Reduce FD leaks from queues and process objects) #778 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/778 | 16:34 |
| toscalix | when I transfer them to html, the rendering is different from the web | 16:34 |
| qinusty | Looks good to me Kinnison | 16:34 |
| toscalix | I export the .md to html | 16:34 |
| Kinnison | qinusty: thanks for the vote of confidence | 16:34 |
| tiagogomes | toscalix it is on the README file | 16:34 |
| qinusty | Just to note, Remember to click `Remove Source Branch` when creating an MR in future :D | 16:34 |
| qinusty | I've ticked it when the merge occurs | 16:34 |
| tlater[m] | Does `del` actually cause python to remove the objects? | 16:35 |
| *** lachlan has quit IRC | 16:35 | |
| tlater[m] | Or does it simply mark them as unused, meaning you have to wait for the garbage collection anyway? | 16:35 |
| Kinnison | tlater[m]: I think it both removes the reference and tries to destroy | 16:35 |
| toscalix | tiagogomes: thanks | 16:36 |
| Kinnison | tlater[m]: certainly it seems to keep the total open FDs below about 25 on my test case | 16:36 |
| qinusty | It calls __del__ tlater, which is a destructor | 16:36 |
| Kinnison | tlater[m]: where without my patch it's up at around 40,000 and rises continuously | 16:36 |
| * tlater[m] double checks | 16:36 | |
| tlater[m] | For some reason I have in my mind that setting to None is actually equivalent | 16:36 |
| tlater[m] | Oh, well, I won't argue with the test then | 16:36 |
| qinusty | I mean, that's a slight reduction Kinnison | 16:36 |
| tlater[m] | Just a tiny one | 16:37 |
| tlater[m] | ;p | 16:37 |
| Kinnison | qinusty: It was a bit of a torture test, to be fair | 16:37 |
| qinusty | Still | 16:37 |
| tlater[m] | I suppose there's no easy way to include such a test in the test suite? | 16:37 |
| Kinnison | tlater[m]: probably not without monkeypatching os.pipe() and os.close() which I did originally to work out where we were leaking the FDs from | 16:38 |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/maybe-reduce-fd-leaks->master: jobs.py: Reduce FD leaks from queues and process objects) #778 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/778 | 16:39 |
| tlater[m] | Thanks for figuring that out then :) Eventually we really should get the performance tests working, so that we don't miss details like these anymore. | 16:40 |
| Kinnison | tlater[m]: It was an amusing debugging effort. At one point I thought multiprocessing.popen_fork was leaking | 16:41 |
| * Kinnison was very pleased he didn't end up needing to file a bug against Python itself | 16:41 | |
| qinusty | But yeah, Nice fix Kinnison :D I'd never come across the issue myself | 16:41 |
| gitlab-br-bot | buildstream: merge request (benbrewer/install-artifacts-doc-improvements->master: Improve documentation for artifact cache installation) #777 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/777 | 16:43 |
| *** WSalmon_ has joined #buildstream | 16:45 | |
| Kinnison | tlater[m]: Given the nit you raised, I'll doublecheck if =None is sufficient in this context | 16:45 |
| *** WSalmon has quit IRC | 16:46 | |
| tlater[m] | Hmm... I am thinking about retries now that I've read chat here. | 16:46 |
| *** toscalix has quit IRC | 16:46 | |
| tlater[m] | iirc jobs are pushed back to the top of the queue when they are retried | 16:47 |
| tlater[m] | I'm not sure if spawn() is called again | 16:47 |
| Kinnison | AFAICT they'd need to be, in order to create a new subprocess to run | 16:47 |
| Kinnison | It looks like the dels are not necessary | 16:47 |
| tlater[m] | Ah, right, we do call Process() in spawn | 16:48 |
| Kinnison | tlater[m]: assuming retries are tested, we'd know soon enough | 16:48 |
| * Kinnison 's test is showing the `del`s aren't needed, so I'll push a cleanup without them | 16:49 | |
| tlater[m] | Retries are not tested to my knowledge, since they are part of the interactive features | 16:49 |
| tlater[m] | Which remain entirely untested... Hence I'm a bit careful about this | 16:49 |
| Kinnison | aah | 16:49 |
| tlater[m] | That said, reading back into the code paths here I think it's fine | 16:49 |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/maybe-reduce-fd-leaks->master: jobs.py: Reduce FD leaks from queues and process objects) #778 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/778 | 16:51 |
| tlater[m] | Between qinusty and me I think it's reviewed enough, feel free to merge after that fix, Kinnison :) | 16:51 |
| Kinnison | I can't | 16:51 |
| Kinnison | 'tis my first ever buildstream commit | 16:51 |
| tlater[m] | Oh, right | 16:51 |
| Kinnison | I've updated the MR with `del` removed | 16:51 |
| tlater[m] | I'll merge it then, permissions for the second patch, iirc? | 16:52 |
| * Kinnison is in no hurry to be granted merge rights :-) | 16:52 | |
| * Kinnison doesn't commonly program in python, so extra eyes are always appreciated | 16:53 | |
| tlater[m] | Heh, merge rights are mostly so I don't need to rebase your patch every time someone else pushes something | 16:54 |
| tlater[m] | ... which, of course, just happened | 16:54 |
| Kinnison | hehe | 16:54 |
| Kinnison | I'm in no rush, I'm about to run away for the evening anyway :-) | 16:55 |
| tlater[m] | I'll still get it done, better than having it lie bare for months | 16:56 |
| tlater[m] | o/ Kinnison | 16:56 |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/maybe-reduce-fd-leaks->master: jobs.py: Reduce FD leaks from queues and process objects) #778 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/778 | 16:57 |
| Kinnison | thanks tlater[m] | 16:57 |
| *** jonathanmaw_ has quit IRC | 17:01 | |
| gitlab-br-bot | buildstream: merge request (danielsilverstone-ct/maybe-reduce-fd-leaks->master: jobs.py: Reduce FD leaks from queues and process objects) #778 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/778 | 17:20 |
| *** lachlan has joined #buildstream | 17:24 | |
| *** rdale has quit IRC | 17:27 | |
| *** lachlan has quit IRC | 17:41 | |
| *** leopi has quit IRC | 18:32 | |
| *** leopi has joined #buildstream | 18:43 | |
| *** leopi has quit IRC | 18:46 | |
| * tristan is pulling freedesktop-sdk.bst:extensions/rust/rust.bst for an hour and a half now | 18:49 | |
| tristan | at like ~3K per second | 18:49 |
| coldtom | tristan: it /is/ big but i think that's a little excessive nonetheless | 18:49 |
| * tristan gives a cold stare to https://gitlab.com/BuildStream/buildstream/issues/554 | 18:50 | |
| tristan | give me a stream, dont round trip and download a gazillion tiny files one by one | 18:50 |
| *** bochecha has quit IRC | 18:52 | |
| *** leopi has joined #buildstream | 18:53 | |
| *** leopi has quit IRC | 19:23 | |
| coldtom | has anyone managed to properly install and configure qt5 using buildstream? I can't get it to both install to an install root and be configured correctly | 19:29 |
| coldtom | more specifically, it seems that installing to an install root requires you to include it in the prefix argument passed to configure, but doing that means it's preserved in qmake configuration after it's been integrated and moved into the correct place in the artifact | 19:30 |
| tristan | coldtom, that's the ugly that I remember indeed; you gotta build qmake into a prefix; and then everything is hard coded to what that qmake thinks is true | 19:44 |
| tristan | coldtom, I could be wrong, but that's how I recall it was used in baserock | 19:44 |
| coldtom | tristan: thanks, that's less simple than i thought this would be :P | 19:49 |
| *** tristan has quit IRC | 20:33 | |
| *** tristan has joined #buildstream | 20:35 | |
| *** alatiera_ has quit IRC | 21:09 | |
| *** tristan has quit IRC | 21:51 | |
| *** alatiera_ has joined #buildstream | 21:58 | |
| *** alatiera_ has quit IRC | 22:09 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
