| *** alatiera_ has quit IRC | 00:50 | |
| *** tristan has quit IRC | 01:02 | |
| *** xjuan has quit IRC | 01:04 | |
| *** bochecha has joined #buildstream | 06:11 | |
| *** bochecha_ has joined #buildstream | 06:11 | |
| *** bochecha has quit IRC | 06:11 | |
| *** bochecha_ is now known as bochecha | 06:11 | |
| *** toscalix has joined #buildstream | 07:39 | |
| gitlab-br-bot | buildstream: merge request (jjardon/pip_dependency->master: source/install_source.rst: pip plugin depends on host pip) #791 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/791 | 07:40 |
|---|---|---|
| jjardon | Can I have a review of this ^ trivial change? | 07:43 |
| gitlab-br-bot | buildstream: merge request (jjardon/pip_dependency->master: source/install_source.rst: pip plugin depends on host pip) #791 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/791 | 07:49 |
| gitlab-br-bot | buildstream: merge request (jjardon/pip_dependency->master: source/install_source.rst: pip plugin depends on host pip) #791 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/791 | 07:49 |
| gitlab-br-bot | buildstream: merge request (jjardon/pip_dependency->master: source/install_source.rst: pip plugin depends on host pip) #791 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/791 | 08:06 |
| qinusty | seems fair to me jjardon | 08:06 |
| *** Lucas2701 has joined #buildstream | 08:09 | |
| Lucas2701 | Salut | 08:09 |
| *** enzo has joined #buildstream | 08:10 | |
| Lucas2701 | salut enzo | 08:10 |
| enzo | salut | 08:10 |
| gitlab-br-bot | buildstream: merge request (jjardon/pip_dependency->master: source/install_source.rst: pip plugin depends on host pip) #791 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/791 | 08:11 |
| *** enzo has quit IRC | 08:14 | |
| *** Lucas2701 has quit IRC | 08:14 | |
| *** jjardon sets mode: +M | 08:15 | |
| *** rdale has joined #buildstream | 08:33 | |
| valentind | qinusty, have you started working on adding the git hashes on the release page? | 08:49 |
| qinusty | Nope, I'm currently reviewing an MR from tiagogomes | 08:50 |
| *** jonathanmaw has joined #buildstream | 08:56 | |
| tiagogomes | jjardon that PR should have probably gone to the website repo | 08:57 |
| tiagogomes | The install instructions will be removed from the buildstream repo | 08:58 |
| jjardon | tiagogomes: what page? | 08:58 |
| jjardon | ah, https://buildstream.build/source_install.html#installing_dependencies | 08:59 |
| tiagogomes | jjardon nevermind, I thought you were changing the buildstream installation instructions by pip :) | 09:00 |
| * tiagogomes hasn't had coffee yet! | 09:00 | |
| WSalmon | dose anyone know anything about `bst source-bundle` it has a seperate code path to what i was looking at so thought i aught to think about it but when i try and run it in the examples in buildstream/doc/examples i get a file not found stack trace even though i can build the element i try to checkout out, dose any one know anything about this before i file a error report/issue in GL | 09:00 |
| jjardon | tiagogomes: review, please? https://gitlab.com/BuildStream/website/merge_requests/80 | 09:09 |
| *** tristan has joined #buildstream | 09:11 | |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 09:12 |
| tiagogomes | merged jjardon, thanks! | 09:13 |
| *** abderrahim has quit IRC | 09:13 | |
| *** abderrahim has joined #buildstream | 09:13 | |
| tiagogomes | has tristan been around? | 09:14 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 09:19 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 09:23 |
| gitlab-br-bot | buildstream: issue #651 ("bst source-bundle fail's for the examples.") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/651 | 09:26 |
| *** lachlan has joined #buildstream | 09:30 | |
| *** ChanServ sets mode: +o tristan | 09:35 | |
| tristan | oops, tiagogomes yes, I have been leaving at around 8pm though these past couple of days so was less present (or less overlapping) on IRC | 09:35 |
| tiagogomes | tristan do you mind if I send a MR to address https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/76/ comments? Or you prefer to do it | 09:37 |
| tiagogomes | freedesktop sdk is already fixed to not redefine max-jobs https://gitlab.com/freedesktop-sdk/freedesktop-sdk/merge_requests/513 | 09:37 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 09:38 |
| qinusty | Does anyone know what could be happening between strip-commands and caching which isn't timed? | 09:41 |
| toscalix | tiagogomes: qinusty tlater[m] sent a mail to the list summarising what is left to be done on the content side | 09:42 |
| toscalix | let's try to finish the work this week | 09:43 |
| toscalix | and move on to other topics the next one | 09:43 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 09:43 |
| toscalix | ah, valentind is back. Approved the MR | 09:45 |
| gitlab-br-bot | buildstream: merge request (richardmaw/builddir-sockets->master: 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 | 09:47 |
| tristan | tiagogomes, Ah, yes you can feel free please ! I missed the last comment from jjardon | 09:54 |
| *** alatiera_ has joined #buildstream | 09:58 | |
| tristan | tiagogomes, as a result of those MRs, I also opened https://gitlab.com/BuildStream/buildstream/issues/641 | 10:00 |
| tiagogomes | tristan and I left a comment there debating if that issue is an issue :) | 10:01 |
| qinusty | Are we aware that the current overhead on the cache quota isn't 2GB? It's 2e9 bytes which is like 1.8GB (which just seems awkward) | 10:02 |
| Kinnison | It's 2GB not 2GiB | 10:03 |
| valentind | Only hard drive manufacturers use GB instead of GiB. Is there a reason we use GB here? | 10:04 |
| Kinnison | ease of typing the constant most likely | 10:05 |
| qinusty | We don't... We use G to specify it. | 10:05 |
| qinusty | So it isn't clear exactly | 10:05 |
| Kinnison | qinusty: where is the relevant code? | 10:05 |
| qinusty | artifactcache.py | 10:05 |
| qinusty | _calculate_cache_quota | 10:06 |
| qinusty | It's just something I noticed while trying to figure out whether I've found an issue. | 10:06 |
| qinusty | tiagogomes will have to correct me maybe here. But the idea of cache cleanup is that if I need 500M of space, I go through the oldest artifacts deleting them until I have enough space? | 10:06 |
| *** ikerperez has joined #buildstream | 10:07 | |
| tiagogomes | The algorithm is correct, but I am not sure if the threshold is 500M | 10:07 |
| qinusty | that isn't a threshold | 10:07 |
| qinusty | it's just my element | 10:07 |
| qinusty | I'm using fallocate to generate arbitary sized artifacts. | 10:08 |
| *** iker has quit IRC | 10:08 | |
| qinusty | So, I disable the overhead (BST_TEST_SUITE=1). Set my quota to 5G. Build an element of size 600M, an element of size 4G and an element of size 500M (in separate builds) | 10:09 |
| qinusty | In theory. We should delete the 600M artifact and be good to go? | 10:09 |
| tiagogomes | I think it should delete both the 4G and 600M | 10:10 |
| qinusty | Why though? | 10:10 |
| qinusty | (That is what I'm observing) | 10:10 |
| tiagogomes | As iirc there's an headroom of 2GB required. So it deletes until there cache size is no bigger than 3GB | 10:11 |
| qinusty | I disabled the headroom | 10:11 |
| tiagogomes | I didn't wrote that code, so my observation is theoretical | 10:11 |
| qinusty | Okay, but say the space is 5G, it shouldn't delete the 4G? | 10:12 |
| tiagogomes | ah | 10:12 |
| qinusty | I will create a reproducible project for people | 10:12 |
| tiagogomes | Ok, looking at the code | 10:14 |
| tiagogomes | It cleans until the cache size is no bigger than 2.5 GB in your example | 10:14 |
| cs-shadow | tristan: Hi, I was thinking of finishing off the pypi-related issues. Seems like we only need to get through two MRs so when you find some time, I would appreciate your opinions on https://gitlab.com/BuildStream/buildstream/merge_requests/731 and https://gitlab.com/BuildStream/buildstream/merge_requests/719 | 10:14 |
| tiagogomes | It cleans until the cache size is bigger than cache_lower_threshold, and cache_lower_threshold is set to be half of the quota | 10:15 |
| qinusty | Yes indeed it does. Well caught. | 10:16 |
| valentind | This is strange. | 10:17 |
| qinusty | tlater has confirmed this is so we don't have to cleanup after every build. He can't type in #buildstream for some reason | 10:18 |
| qinusty | Incoming message dump | 10:19 |
| qinusty | 11:17 <tlater> Also, as an aside, the 2G thing is specified by the systemd standard | 10:19 |
| qinusty | 11:18 <tlater> We figured it would be a good idea to use an existing format | 10:19 |
| qinusty | 11:18 <tlater> I think a comment in that area of code explains this, as well as the relevant documentation. | 10:19 |
| qinusty | 11:18 <tlater> So everything is working as expected - could you perhaps relay all of this? | 10:19 |
| tiagogomes | Has he identified itself with the NickServer? | 10:19 |
| qinusty | 11:20 <tlater> I have! Haha. Not sure what's happening, I'll go figure it out. | 10:20 |
| valentind | When is the cleanup scheduled then? | 10:21 |
| qinusty | cleanup occurs when we hit the quota during a build | 10:21 |
| qinusty | or pull I assume | 10:21 |
| qinusty | tiagogomes, did you intend to leave the DEBUG messages in your MR? They're enabled by default I believe | 10:22 |
| qinusty | which seems strange to me | 10:22 |
| tiagogomes | Yes, there is a separate commit to add debug messages | 10:23 |
| tiagogomes | What is strange to me is that artifact clean operations doesn't provide any information at all | 10:23 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:23 |
| tiagogomes | They should tell you which artifacts were removed, at least if debug is enabled | 10:23 |
| qinusty | I agree, but these should probably not be of type DEBUG. As they're enabled by default | 10:24 |
| qinusty | for some reason | 10:24 |
| qinusty | I can't find any logic which differentiates them | 10:24 |
| *** lachlan has quit IRC | 10:24 | |
| qinusty | Ah, only when coming through plugin.py | 10:24 |
| qinusty | Which context.message doesn't. These are issues which will definitely be addressed in the message api rework. | 10:25 |
| qinusty | Which I hope to get done next week before I end up back at Uni | 10:25 |
| *** tlater[m] has left #buildstream | 10:25 | |
| tiagogomes | Well if DEBUG messages are enabled by default that sounds a separate issue | 10:26 |
| *** tlater[m] has joined #buildstream | 10:26 | |
| qinusty | They're not differentiated unless sent by the public api | 10:28 |
| qinusty | so I'll address that in the message API rework | 10:28 |
| qinusty | but other than that tiagogomes, I left a few points. Other than those, it looks good | 10:29 |
| qinusty | A lot of necessary tidy up :D | 10:29 |
| qinusty | If someone could review https://gitlab.com/BuildStream/buildstream/merge_requests/765 before it falls too far behind on master. It'd be greatly appreciated :D | 10:30 |
| qinusty | valentind, tiagogomes, tlater[m]. Are you currently working on any of the things toscalix mentioned in his email? If so which parts shall I avoid chipping away at | 10:31 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:32 |
| tiagogomes | qinusty I am not | 10:33 |
| valentind | qinusty, No. | 10:33 |
| qinusty | Okay, I'll take a look into the glossary page | 10:33 |
| * tlater[m] thinks he can speak again | 10:35 | |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:39 |
| *** lachlan has joined #buildstream | 10:41 | |
| tlater[m] | qinusty: I'm not working on BuildStream today, but I'm planning on finishing up the known issues links and CAS write-up tomorrow. | 10:42 |
| qinusty | Sounds good. | 10:43 |
| tristan | cs-shadow, done ! | 10:44 |
| qinusty | Once https://gitlab.com/BuildStream/buildstream/merge_requests/765 is reviewed I plan to finish up the message API work which you started tlater[m], messaging will be much clearer | 10:44 |
| cs-shadow | thanks :) | 10:44 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:44 |
| tlater[m] | qinusty: If you don't manage before University I'll clean up after you ;) | 10:45 |
| qinusty | :D That'd be good. The earlier it lands in the 1.4 cycle the better | 10:45 |
| *** lachlan has quit IRC | 10:50 | |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:50 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:55 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 10:57 |
| gitlab-br-bot | buildstream: merge request (chandan/pypi-badge->master: README.rst: Add status badges for PyPI release and Python versions) #719 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/719 | 10:58 |
| gitlab-br-bot | buildstream: issue #652 ("workspace builds do not correctly determin that they are not cached") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/652 | 11:03 |
| *** lachlan has joined #buildstream | 11:14 | |
| *** lachlan has quit IRC | 11:19 | |
| *** lachlan has joined #buildstream | 11:19 | |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 11:22 |
| *** lachlan has quit IRC | 11:23 | |
| *** lachlan has joined #buildstream | 11:37 | |
| *** lachlan has quit IRC | 11:41 | |
| *** lachlan has joined #buildstream | 11:45 | |
| *** bochecha_ has joined #buildstream | 11:58 | |
| *** bochecha has quit IRC | 11:58 | |
| *** bochecha_ is now known as bochecha | 11:58 | |
| *** lachlan has quit IRC | 12:06 | |
| *** WSalmon has quit IRC | 12:12 | |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 12:13 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 12:21 |
| *** WSalmon has joined #buildstream | 12:27 | |
| gitlab-br-bot | buildstream: merge request (chandan/pypi-badge->master: README.rst: Add status badges for PyPI release and Python versions) #719 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/719 | 12:28 |
| *** jonathanmaw_ has joined #buildstream | 12:37 | |
| *** jonathanmaw has quit IRC | 12:38 | |
| qinusty | toscalix, is the intention to use buildstream.build links within feature_page? https://gitlab.com/BuildStream/website/blob/master/content/pages/feature_page.md#L113 | 12:50 |
| qinusty | This does allow for the easy copy and pasting which you mentioned however hinders the links working away from the buildstream.build url e.g. on local machines. | 12:50 |
| toscalix | qinusty: this was probably done by me before tiago pointed to me how to improve the links maintenance | 12:51 |
| qinusty | Also we're missing the [FAQ] link I believe, I'll get an MR up for that soonish | 12:51 |
| qinusty | Okay, I'll do an MR with those two changes in | 12:51 |
| toscalix | ouch, that is my fault probable | 12:51 |
| toscalix | probably | 12:51 |
| qinusty | I also pushed https://gitlab.com/BuildStream/website/merge_requests/82 for review | 12:51 |
| qinusty | It provides a slightly improved approach to feature pages going forward to future releases | 12:52 |
| tristan | qinusty, hard coded links to buildstream.build are broken, there are probably some remaining but need to be trivially fixed :) | 12:52 |
| qinusty | Agreed tristan, just wanted to check there wasn't a reason for having them in the reference style links at the bottom of the page | 12:52 |
| gitlab-br-bot | buildstream: merge request (mac_fixes->master: WIP: Implement compatibility fixes for MacOSX and WSL Blocks #411 and #412") #726 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/726 | 12:52 |
| toscalix | qinusty: I understand your point but again, I advise against using specific release numbers in the feature and release page for now | 12:53 |
| tristan | qinusty, I think that the consensus was to always use the reference style links at the bottom of the page. I prefer not, but others disagreed enough so I don't mind :) | 12:53 |
| toscalix | example, we get a nice reference about buildstream in zdnet. The journalist make a nice description of the tool and then links the release announcement and the feature page. If you add the number, in 6 month that reference is not valid since it will be pointed to an old version. Good reference can be a major source of visitors for over a year, depending on when the come from. So you want the | 12:54 |
| toscalix | current release pages to remain with no version reference | 12:55 |
| toscalix | controlling that through dns is easy, but since we cannot, we will need to "move the pages", keeping the current version as release announcement and feature page | 12:55 |
| tiagogomes | Can we use conditionals on environment variables? | 12:56 |
| toscalix | so external references, but internal ones too, always work | 12:56 |
| tristan | agreed; there should be both I think, you should be able to link to "release 1.2", or link to "current release" | 12:56 |
| toscalix | I have explained this several times. This is the last one. I will approve whatever you decide is a correct approach | 12:56 |
| tristan | tiagogomes, Yes we can | 12:57 |
| tiagogomes | nice | 12:57 |
| tristan | toscalix, I don't think I'm disagreeing, or didn't think so. I'm just saying from a UX perspective, there is a different meaning to link to "release 1.2" and link to "current release"; even if sometimes they point to the same content | 12:58 |
| tristan | toscalix, for example, if I write a blog post and link to the 1.2 release and talk about it; I'd like it to continue to link to that same release in 3 years | 12:59 |
| toscalix | I think my example has a significnatly higher impact | 13:03 |
| toscalix | after the current release is substitute by a new one | 13:03 |
| toscalix | buildstream in detail is not release focused | 13:04 |
| toscalix | and has the descriptions of the features | 13:04 |
| toscalix | pointing there could be a good compromise | 13:05 |
| tristan | toscalix, I don't think we should have to choose either one or the other. I see you mentioned something about dns and redirects or something; but there should be some simple technical way to support both links to the same content/page | 13:07 |
| tristan | maybe it's a different solution ? | 13:07 |
| tristan | for example, even placing a symbolic link in the repository could achieve this ? | 13:08 |
| tristan | i.e. a symbolic "current.html" link which, when read; fetches the content of the "release-1.2.html" that is in the repository | 13:08 |
| *** lachlan has joined #buildstream | 13:10 | |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 13:10 |
| qinusty | toscalix the way my MR works. The latest feature page is ALWAYS feature.html. Previous version feature pages are feature-x.y.html. If we get a reference in an article somewhere, they will always direct to the latest but the archived feature pages will still be generated and accessibly. | 13:19 |
| qinusty | s/accessibly/accessible | 13:19 |
| qinusty | tristan, we could have the feature.html page set to redirect to feature-x.y.html which is the latest version? Meaning that a link to buildstream.build/feature.html will always be latest. But linking to a specific buildstream.build/feature-x.y.html would take you to a version specific feature page. | 13:22 |
| tristan | qinusty, I expect that to be possible indeed | 13:27 |
| tristan | even, maybe just `ln -s feature-x.y.html current.html` would work ? | 13:28 |
| tristan | or feature.html | 13:28 |
| qinusty | potentially, but that means that every release, we need to perform symlinks rather than changing source | 13:28 |
| tristan | is there a difference ? | 13:29 |
| qinusty | you're changing source anyway | 13:29 |
| qinusty | perhaps | 13:29 |
| tristan | I mean, you just update the symlink with the release | 13:29 |
| qinusty | We will need a release procedure with things that need doing | 13:29 |
| qinusty | either way | 13:29 |
| qinusty | So whatever works I guess | 13:29 |
| tristan | If anyone writes an article about a specific release and links to that page; they will do it at the time of the release | 13:29 |
| tristan | not later | 13:29 |
| tristan | So you'd want that link to not break | 13:30 |
| tristan | At the same time, you also want a way to link to the "latest", they are just different purposes of links | 13:30 |
| qinusty | I know. I'm not sure which we want. What I'm saying is that if we link to {filename}feature.md we should get the LATEST, whether it redirects us to {filename}feature-x.y.html or is up for debate. | 13:35 |
| toscalix | our main target are people unaware of buildstream that, once aware of it, might be willing to try out the tool | 13:43 |
| qinusty | https://gitlab.com/BuildStream/website/merge_requests/84 Is a little tidyup toscalix | 13:47 |
| qinusty | But back to my point with https://gitlab.com/BuildStream/website/merge_requests/82... | 13:47 |
| *** tristan has quit IRC | 13:47 | |
| qinusty | The aim is that buildstream.build/feature.html will always point to the LATEST version features. | 13:47 |
| Nexus | juergbi: could you give me some feedback on https://gitlab.com/BuildStream/buildstream/merge_requests/726 please? :) | 13:48 |
| qinusty | But what I'm saying is that you still want the features of 1.2 when 1.4 comes out. So we have feature-1.2.md which is shown on the website as feature.html. When we release 1.4, feature.html becomes 1.4 relevant and feature-1.2.html becomes a thing | 13:49 |
| *** alatiera_ has quit IRC | 13:57 | |
| *** alatiera_ has joined #buildstream | 13:57 | |
| * tiagogomes is sad that there's a new pull_tree method which doesn't update the cache size | 13:58 | |
| *** lachlan has quit IRC | 13:59 | |
| *** alatiera_ has quit IRC | 14:04 | |
| *** alatiera_ has joined #buildstream | 14:12 | |
| qinusty | :( tiagogomes, happy to review any additional commits/changes you put up | 14:17 |
| tiagogomes | the MR was already to big… | 14:17 |
| tiagogomes | And this is not easy to fix… | 14:17 |
| * tiagogomes pulls hairs | 14:17 | |
| qinusty | ah :( | 14:17 |
| gitlab-br-bot | buildstream: merge request (richardmaw/subprocess-PWD->master: Address post-merge review of Ensure PWD is set in process environment) #788 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/788 | 14:26 |
| gitlab-br-bot | buildstream: merge request (tpollard/494->master: WIP: Don't pull artifact buildtrees by default) #786 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/786 | 14:26 |
| qinusty | Did anyone get any further with https://gitlab.com/BuildStream/buildstream/issues/609? maybe valentind or tiagogomes? | 14:35 |
| *** lachlan has joined #buildstream | 14:37 | |
| valentind | qinusty, I have not managed to reproduce. | 14:37 |
| qinusty | It seems fairly reproducible for the GNOME guys. What approach do you think is best for filling up the drive? I'm currently hosting a server on my laptop which is also performing the local builds :/ | 14:38 |
| *** lachlan has quit IRC | 14:42 | |
| Nexus | is #22 still an existing bug? there's been nothing done on it in over a year :p | 14:45 |
| Nexus | https://gitlab.com/BuildStream/buildstream/issues/22 | 14:45 |
| qinusty | If anyone feels they can contribute to the glossary, feel free to check out my branch and push a commit https://gitlab.com/BuildStream/website/merge_requests/85 | 14:46 |
| Nexus | Also, i've checked thr "bzr plugin" check box of https://gitlab.com/BuildStream/buildstream/issues/53 as !242 was said to resolve this and was merged | 14:49 |
| Nexus | Are we still missing ostree from this? | 14:49 |
| tiagogomes | qinusty I didn't do anything for that issue, but didn't Tristan fixed this? | 14:53 |
| qinusty | Not that I am aware of. | 14:53 |
| qinusty | The issue is open, no comments have been left. | 14:53 |
| tiagogomes | I thought his work on cache cleanup exclusivity was for this | 14:53 |
| qinusty | Might me, I'll verify? | 14:56 |
| qinusty | s/me/be | 14:56 |
| tiagogomes | I think tlater[m] was also working on testing this | 14:59 |
| tlater[m] | Yep, we haven't reproduced it yet | 15:00 |
| tlater[m] | But hopefully I'll get there tomorrow | 15:00 |
| qinusty | I assume you're trying to reproduce it on 1.2.0? | 15:00 |
| tlater[m] | I was using master, but I suspect it will affect all versions | 15:01 |
| qinusty | Well tristan's potential fix is merged so | 15:01 |
| qinusty | The error looks the same on the related client issue which tristan closed with his MR. I think they're the same since they use the same underlying logic | 15:02 |
| tlater[m] | qinusty: They don't, actually | 15:02 |
| qinusty | Oh really? | 15:02 |
| tlater[m] | Different code paths entirely | 15:02 |
| tlater[m] | In this case I think we're running into multiple concurrent pushes screwing each other over, since the original algorithm wasn't designed with that in mind on the server end | 15:03 |
| *** dtf has joined #buildstream | 15:03 | |
| tlater[m] | (Since we originally didn't have a server process that could manage the cache size properly) | 15:03 |
| *** dtf has joined #buildstream | 15:04 | |
| *** lachlan has joined #buildstream | 15:06 | |
| WSalmon | big thanks to skullman for explaining some of the finer points of bobble rap to me :D | 15:13 |
| *** lachlan has quit IRC | 15:14 | |
| valentind | We use grpcio, and in there they have 3rd party library for SSL with a strange clause in the copyright notice. | 15:18 |
| valentind | * The licence and distribution terms for any publically available version or | 15:18 |
| valentind | * derivative of this code cannot be changed. i.e. this code cannot simply be | 15:18 |
| valentind | * copied and put under another distribution licence | 15:18 |
| valentind | * [including the GNU Public Licence.] | 15:18 |
| * tlater[m] also enjoys bobble rap | 15:18 | |
| Nexus | lol | 15:19 |
| valentind | So grpcio, which is a derivative, cannot be Apache 2.0? And BuildStream cannot be GPL2.1? | 15:19 |
| valentind | I am not sure what are the implications of this clause. | 15:19 |
| tlater[m] | And autocorrect ;) | 15:20 |
| persia | valentind: Do you have a link to the entire notice? | 15:20 |
| valentind | I am afraid it is going to be a problem to get grpcio included into distributions. | 15:20 |
| valentind | persia, in the source tarball: https://files.pythonhosted.org/packages/f7/40/875c30426e2df486dbb032c28478b2d551f6f8531cbc566040507bd7a4e5/grpcio-1.15.0.tar.gz | 15:20 |
| *** lachlan has joined #buildstream | 15:20 | |
| valentind | persia, file third_party/boringssl/ssl/handshake_server.cc | 15:21 |
| valentind | For example. | 15:21 |
| persia | Anything easier to reach? If not, I'll dig in, but I'm sharing not much bandwidth with lots of folk today | 15:21 |
| valentind | It is called boringssl. | 15:21 |
| valentind | persia, https://boringssl.googlesource.com/boringssl/+/master/LICENSE | 15:21 |
| valentind | Ah, it is actually license of the SSLeay. | 15:22 |
| valentind | I have never seen that before. | 15:22 |
| valentind | Well, since openssl is on distros, it should not be a problem then. | 15:23 |
| persia | valentind: My read is that LICENSE is DFSG-free, so I'd feel comfortable suggesting inclusion to a distro if the distro policy approaches DFSG. | 15:24 |
| persia | *but* my read is also that it is incompatible with LGPLv2.1, do cannot be used as linked dependency of BuildStream. | 15:25 |
| valentind | But I would expect that there are LGPL2.1 libraries linking to openssl. | 15:26 |
| persia | I also have the unqualified opinion that it should be safe to ship that code alongside Apache 2.0 licensed code, but I would be uncomfortable distributing a binary constructed by integration of that code and anything licensed under Apache 2.0. | 15:26 |
| persia | valentind: Last I checked, most distros with LGPL or GPL software used gnutls to do ssl for license-compliance reasons. | 15:27 |
| persia | Note that GNUTLS is itself under a license that makes some uses unsuitable, but for distros that publish all source code anyway, that's not as much of a problem. | 15:27 |
| valentind | persia, so should we provide a patch to grpcio to optionally link to gnutls? | 15:29 |
| persia | What goal is trying to be accomplished? | 15:29 |
| valentind | I am looking into packaging BuildStream for Debian. | 15:29 |
| valentind | And we need to make packages of grpcio, because this is not available on Debian. | 15:30 |
| persia | And you want to be able to link LGPL software against the grpcio package in Debian? | 15:30 |
| persia | Then, yes, I'd suggest a distro-patch in Debian to use gnutls instead of boringssl, assuming they are compatible. | 15:31 |
| valentind | OK | 15:31 |
| persia | Also, I'd very strongly suggest having a chat with an ftp-admin: they are the folk who are qualified to determine if a given licensing chain is considered acceptable to Debian. | 15:31 |
| *** lachlan has quit IRC | 15:31 | |
| persia | I can suggset things that might be or might not be, but nothing I say will actually mean anything, so better to get a real answer before starting work. | 15:31 |
| valentind | I will probably not patch grpcio yet. I will try to first have something working. Then I can go through licensing issues. | 15:32 |
| persia | If you don't have another context to reach one, writing to debian-legal@l.d.o can be a good way to drie a discussion. | 15:32 |
| persia | The ftp-admins often take input from d-l discussions to make their decisions. | 15:33 |
| persia | I very strongly recommend starting the discussion first. The discussion is likely to take many days and may take weeks, Packaging two things might only take a few hours, but keeping state on the packaging and reworking it constantly based on input surely takes at least as klong as the discussion + 1 week. | 15:34 |
| persia | Note that if you want someone other than Debian to distribute or publish the results of your experimentation (say gitlab, because you want to put it in CI), you'll want to make sure they are comfortable with the licensing choice. | 15:35 |
| valentind | I will probably not publish the binaries. | 15:36 |
| persia | That makes it safer. There's lots of different actual rules (and I don't know them all), but if you generally don't mix the codebases (keep different files in different locations), there is a high chance it is acceptable to publish the sources somewhere for consideration and/or review. | 15:38 |
| *** lachlan has joined #buildstream | 15:39 | |
| *** lachlan has quit IRC | 15:43 | |
| *** ikerperez has quit IRC | 16:03 | |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 16:05 |
| *** lachlan has joined #buildstream | 16:07 | |
| *** lachlan has quit IRC | 16:11 | |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 16:12 |
| Nexus | adds68: does this resolve #642 for you? https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 16:13 |
| Nexus | also please can someone else review https://gitlab.com/BuildStream/buildstream/merge_requests/792 for me? | 16:13 |
| adds68 | Nexus, yes that patch looks sensible to me | 16:14 |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 16:14 |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 16:18 |
| *** lachlan has joined #buildstream | 16:19 | |
| tlater[m] | Nexus: What existing error do you match? Do we have a condition for INVALID_PROJECT_CONF somewhere already? | 16:22 |
| * tlater[m] may have forgotten about such an exception. | 16:23 | |
| Nexus | tlater[m]: no it's to match MISSING_PROJECT_CONF | 16:23 |
| tlater[m] | It just seems odd that a yaml error needs to change. | 16:23 |
| Nexus | just so you can tell at a glance, it's purely a readability thing | 16:23 |
| adds68 | Nexus, when you reply 'n' you do receive a yaml error | 16:23 |
| adds68 | Nexus, so maybe defining a new error is not needed, but i'm not sure | 16:23 |
| tlater[m] | Nexus: I disagree that we need a new error type here. | 16:24 |
| *** lachlan has quit IRC | 16:24 | |
| tlater[m] | It's fundamentally incorrect yaml, and the error already points you to the correct file. | 16:24 |
| Nexus | that's fine, though the addition of MISSING_PROJECT_CONF is also mute in that case | 16:24 |
| Nexus | i was simply following that pattern | 16:25 |
| tlater[m] | Yep, I think it's a bit pointless. Just re-raise the INVALID_YAML | 16:25 |
| Nexus | kk | 16:25 |
| Nexus | s/mute/moot/ | 16:26 |
| Nexus | can't spell today | 16:26 |
| tlater[m] | It's a nit, of course, but it would be a bit pointless to have a different error thing for every possible exception you can encounter, so let's not start defining things when they aren't necessary :) | 16:27 |
| gitlab-br-bot | buildstream: merge request (issue-642-Invalid_project.conf_seen_as_missing->master: Incorrect error when malformed project.conf) #792 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/792 | 16:29 |
| Nexus | there. done. you happy now??!? *ruining all my fun ;-;* | 16:30 |
| 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:32 |
| *** phildawson has quit IRC | 16:33 | |
| *** phildawson has joined #buildstream | 16:33 | |
| *** toscalix has quit IRC | 16:36 | |
| 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:38 |
| gitlab-br-bot | buildstream: merge request (richardmaw/fix-chroot-sandbox-devices->master: fix chroot sandbox devices) #781 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/781 | 16:47 |
| 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 | 16:50 |
| *** lachlan has joined #buildstream | 16:56 | |
| *** lachlan has quit IRC | 17:00 | |
| *** lachlan has joined #buildstream | 17:14 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/element-cache-state-simplify->master: Simplify element state by removing `__cached`) #784 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/784 | 17:14 |
| finn | Anyone know what the minimum version of bubblewrap which is supported for buildstream/buildbox? | 17:15 |
| *** phildawson has quit IRC | 17:16 | |
| finn | I'm currently using Debian stretch, with bubblewrap 0.1.7 | 17:16 |
| finn | I'm getting an error with buildbox which says "Unknown option --die-with-parent" | 17:16 |
| *** lachlan has quit IRC | 17:18 | |
| finn | Managed to build from source, so my problem is solved :) | 17:28 |
| gitlab-br-bot | buildstream: merge request (jonathan/pickle-yaml->master: WIP: Add a cache of parsed and provenanced yaml) #787 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/787 | 17:43 |
| *** jonathanmaw_ has quit IRC | 18:01 | |
| *** cs-shadow has quit IRC | 18:04 | |
| *** alatiera_ has quit IRC | 18:32 | |
| Kinnison | I think we recommend bubblewrap from backports | 18:36 |
| *** tristan has joined #buildstream | 18:59 | |
| *** rdale has quit IRC | 19:08 | |
| *** tristan has quit IRC | 19:38 | |
| *** bochecha has quit IRC | 20:04 | |
| *** finn has quit IRC | 21:53 | |
| *** xjuan has joined #buildstream | 23:21 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!