| *** mohan43u has quit IRC | 01:46 | |
| *** mohan43u has joined #buildstream | 01:49 | |
| *** mohan43u has quit IRC | 01:53 | |
| *** mohan43u has joined #buildstream | 01:57 | |
| *** phoenix has quit IRC | 02:18 | |
| *** mohan43u_ has joined #buildstream | 05:43 | |
| *** mohan43u has quit IRC | 05:44 | |
| abderrahim[m] | tristan: hi. It seems 1.4.2 wasn't published on pypi | 06:25 |
|---|---|---|
| gitlab-br-bot | juergbi opened MR !1850 (juerg/python-3.6->master: Require Python >= 3.6) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1850 | 06:45 |
| *** mohan43u_ has quit IRC | 06:51 | |
| *** mohan43u has joined #buildstream | 06:51 | |
| *** ikerperez has joined #buildstream | 06:53 | |
| *** benschubert has joined #buildstream | 07:42 | |
| * mohan43u | 07:52 | |
| *** narispo has quit IRC | 07:53 | |
| *** santi has joined #buildstream | 08:07 | |
| *** tristan has quit IRC | 08:14 | |
| *** tristan has joined #buildstream | 08:28 | |
| *** narispo has joined #buildstream | 08:29 | |
| *** rdale has joined #buildstream | 08:31 | |
| *** tpollard has joined #buildstream | 08:38 | |
| *** ChanServ sets mode: +o tristan | 08:42 | |
| tristan | abderrahim[m], ahhh, I didn't realize I was supposed to do that ;-) | 08:42 |
| tristan | I think we have some shared account or smth for that, lemme see | 08:43 |
| tristan | Hmmm, I also noticed the announcements.json in the website repo was terribly outdated and was going to update that | 08:45 |
| tristan | But now, the table that it generates is suddenly missing the links to the release announcements on the mailing list: https://buildstream.build/releases.html ??? | 08:45 |
| tristan | So announcements.json is now deadcode ? | 08:45 |
| * abderrahim[m] doesn't know how the website works | 08:46 | |
| tristan | yeah, I believe I had put the release process and everything in the contributing guide but couldnt find it yesterday :-S | 08:47 |
| tristan | but looks like that is gone from the docs, and looks like the process has changed in some ways | 08:48 |
| tristan | The badge up at https://gitlab.com/BuildStream/buildstream/ is not updated, although I could have swore that I did trigger a pipeline on master after pushing the tag | 08:48 |
| benschubert | One of my emails to the ML ended up having a "*** UNCHECKED ***" title and is not available in the buildstream ML archive. Is there something that should be done or should I just re-send the email? | 08:55 |
| tristan | Oh damn, ok the badge thing looks like another side effect of runner screwups | 08:56 |
| abderrahim[m] | tristan: I believe the badges are updated from pypi | 08:56 |
| tristan | valentind, The runners are still acting up, this pipeline is stuck: https://gitlab.com/BuildStream/buildstream/pipelines/131962213 | 08:56 |
| tristan | valentind, and this job has lots of errors: https://gitlab.com/BuildStream/buildstream/-/jobs/494950809 | 08:57 |
| tristan | coldtom, ^^^ | 08:57 |
| tristan | abderrahim[m], nah the badges are generated by running a pipeline on master, every time we run a pipeline on master the badges are updated based on the tags which are present in git at the time | 08:57 |
| tristan | But pypi likes to have badges too :) | 08:58 |
| tristan | other ones | 08:58 |
| tristan | benschubert, did you send it today ? | 08:58 |
| tristan | benschubert, I noticed yesterday it took some hours for the release email to finally get through | 08:58 |
| benschubert | tristan: on the 25th, it was about external plugins tests | 08:59 |
| tristan | Hrrrmmmm | 08:59 |
| * tristan searches his email history for the email jjardon sent him informing him of the list admin password | 08:59 | |
| tristan | which I have forgotten again | 09:00 |
| tristan | maybe my browser has it in the cache | 09:00 |
| benschubert | there was some work done on the backend at gnome apparently so something might have gone awry | 09:00 |
| tristan | yup thanks browser | 09:00 |
| tristan | benschubert, no messages from you in the queue, all spam | 09:01 |
| tristan | Just send it again I guess is best :) | 09:01 |
| benschubert | thanks :) | 09:01 |
| valentind | tristan, I will look later at these CI errors. | 09:02 |
| tristan | Thanks ! | 09:02 |
| valentind | tristan, But this is a sled. It is a different builder. | 09:02 |
| * tristan will forego debugging the badges until a pipeline on master passes | 09:02 | |
| tristan | Aha | 09:02 |
| tristan | valentind, https://gitlab.com/BuildStream/buildstream/pipelines/131862423 | 09:04 |
| tristan | There is another "stuck" pipeline which is not bound to a sled | 09:04 |
| tristan | Although it would be good to fix both :-S | 09:04 |
| benschubert | Ok message sent again :D WSalmon : if you can reply again :/ Sorry for the double work | 09:05 |
| tristan | Weird, "This job has not been triggered yet" with "This job depends on upstream jobs that need to succeed in order for this job to be triggered" | 09:05 |
| tristan | However, everything either passed with warnings or passed | 09:06 |
| WSalmon | benschubert, did you mean me, im lost for context | 09:09 |
| *** lachlan has joined #buildstream | 09:09 | |
| tristan | Oh wait | 09:10 |
| tristan | benschubert, WSalmon; I actually have this in my inbox | 09:10 |
| tristan | But it's not in the archive okay, so it went through the ML but didnt get to the archive | 09:11 |
| benschubert | ah yeah :/ | 09:11 |
| benschubert | WSalmon: ah sorry, my email about the plugins and tests | 09:11 |
| benschubert | but wait actually :) | 09:11 |
| benschubert | tristan: how could that be? who to contact/ :D | 09:12 |
| tristan | I have the replies from Chandan and Ed | 09:12 |
| tristan | Can ask in #sysadmin | 09:12 |
| benschubert | did Ed answer this mail? Haven't got that | 09:12 |
| tristan | benschubert, waaaait a sec | 09:13 |
| tristan | buildbox-casd timeout... | 09:13 |
| tristan | title was like that ?? | 09:13 |
| benschubert | No, "BuildStream and external plugins tests | 09:13 |
| tristan | I definitely got this on buildstream-list, although it appears crossposted to buildgrid too | 09:14 |
| tristan | I never got that one | 09:14 |
| benschubert | Ok, then good I sent it again. Chandan and WSalmon got it, it's in a weird state | 09:14 |
| benschubert | oh well, let's consider the new one the good one :) | 09:15 |
| benschubert | so yeah WSalmon if you mind re-doing your reply to the new thread :) | 09:15 |
| tristan | Yeah, I never got that email | 09:15 |
| tristan | I dont think | 09:15 |
| WSalmon | I only ever recived it with ***unchecked*** in the subject | 09:15 |
| tristan | oooh no ! | 09:15 |
| tristan | Jaysus | 09:15 |
| tristan | I have that one *** UNCHECKED *** too | 09:15 |
| tristan | but no replies | 09:15 |
| benschubert | -_-' | 09:16 |
| tristan | sorry but there are about 6 or so *** UNCHECKED *** emails | 09:16 |
| benschubert | ah yeah no worries :) | 09:16 |
| tristan | no replies to that one when I search "plugin tests", only the original post from Thursday | 09:16 |
| benschubert | I'm wondering where the screw up started in the system now :) | 09:16 |
| benschubert | weirder even | 09:16 |
| benschubert | Well better to have a new thread then | 09:16 |
| tristan | Yeah I'm just trying to figure that out before alerting sysadmins | 09:17 |
| benschubert | WSalmon: I sent it a few minutes ago? | 09:17 |
| benschubert | tristan: there was apparently a maintenance on the backend at that time | 09:17 |
| tristan | So: Do we know of any messages which were never delivered ? | 09:17 |
| tristan | Or only messages which didn't make it to the archive ? | 09:17 |
| tristan | Hmmm I see | 09:17 |
| tristan | Yes I have 5 *** UNCHECKED *** messages all from the same 4 hour period on Thursday | 09:18 |
| tristan | I suppose we can consider this an incident and move on :) | 09:18 |
| benschubert | cheers :) | 09:19 |
| WSalmon | benschubert, i only just got it, i think it takes a while to get through the server so have resend my responce, it may take a few minits to come through | 09:19 |
| benschubert | then you should have a new message from me :) | 09:19 |
| benschubert | WSalmon: yeah no rush :) just want to make sure we have things in the archive now! | 09:19 |
| WSalmon | I have a few `[BuildStream] ***UNCHECKED*** buildbox-casd timeout issues during BuildStream startup` | 09:20 |
| tristan | WSalmon, me too | 09:20 |
| WSalmon | messages duno if everyone got them, might be worth piniging chandan, if they all got through with no checking then i gues that not the end of the world but seems bad they never got on to the Archive | 09:21 |
| WSalmon | has some one asked av about this on #sysadmin? duno if he can fix it without needing everyone to resend? | 09:21 |
| tristan | WSalmon, I was about to but our conclusion is that there was some backend maintenance and this was an incident and not a recurring thing | 09:22 |
| tristan | WSalmon, note all of your *** UNCHECKED *** messages are from the same few hour span I believe | 09:22 |
| WSalmon | i dont know if av can do some magic to move them in to the archive as a one off? | 09:22 |
| * tristan did make a passing remark in #sysadmin right now | 09:23 | |
| gitlab-br-bot | jjardon opened issue #1282 (Publish to pypi from CI) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1282 | 09:52 |
| gitlab-br-bot | willsalmon closed issue #1280 (Junction in junction requires top level junction) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1280 | 10:00 |
| *** lachlan has quit IRC | 10:03 | |
| *** lachlan has joined #buildstream | 10:13 | |
| *** lachlan has quit IRC | 10:20 | |
| *** lachlan has joined #buildstream | 10:52 | |
| valentind | Is master supposed to work on python 3.8? I have an issue with child processes not running correctly. They just return 1 and do not execute the target function. | 10:54 |
| benschubert | It _should_ and we have tests for it. Do you have any debug info? | 10:55 |
| *** lachlan has quit IRC | 10:56 | |
| valentind | benschubert, I had to run make in requirements, because the old requirements do not work with recent pip. | 10:56 |
| valentind | I am wondering if it is the issue. | 10:56 |
| benschubert | what's the problem with the requirements? Which package is broken? | 11:00 |
| benschubert | I am waiting to update all requirements as we'd need a fix in pytest before which I aim to be doing tomorrow | 11:00 |
| valentind | packaging is too old | 11:00 |
| valentind | It would be 20.x it is 19.x | 11:00 |
| valentind | And tox uses pip from host. | 11:00 |
| valentind | pip 20 needs packaging 20. | 11:01 |
| valentind | I tried to only upgrade "packaging" now. But I still get the same issue with child processes that just die at start. | 11:01 |
| benschubert | That's weird I didn't hit that while running the tests on 3.8 with lates requirements | 11:01 |
| benschubert | does --debug --verbose give you something useful? | 11:02 |
| valentind | benschubert, It is happening during running test. | 11:02 |
| tristan | I think the buster python 3.8 in CI is a bit "weird" though no ? I backported the docker to test 3.8 in bst1 and noticed some comments about that | 11:02 |
| valentind | Job.start runs. It creates and start a process. | 11:03 |
| valentind | But Job.child_action does not get called. | 11:03 |
| benschubert | https://gitlab.com/BuildStream/buildstream/-/commit/551e0755e4dcb553ac220c5330a74a7b2b07cb19 can you see an obvious difference with this change? | 11:04 |
| valentind | on_completion registered to add_child_handler gets called with returncode being 1. | 11:04 |
| valentind | It happens with zipp 0.6.0 | 11:05 |
| valentind | Oh wait. | 11:05 |
| valentind | That does not make sense. | 11:05 |
| *** lachlan has joined #buildstream | 11:07 | |
| valentind | benschubert, running your branch, it fails as well. | 11:07 |
| benschubert | are you running tests with coverage actually? | 11:08 |
| benschubert | on py38 | 11:08 |
| valentind | I do not know, I run "tox -e py38" | 11:09 |
| benschubert | ah right | 11:09 |
| benschubert | sorry should have remembere earlier | 11:09 |
| valentind | Coverage.py warning: No data was collected. (no-data-collected) | 11:09 |
| valentind | Coverage.py warning: Plugin file tracers (Cython.Coverage.Plugin) aren't supported with PyTracer | 11:09 |
| valentind | WARNING: Failed to generate report: No data to report. | 11:09 |
| benschubert | that runs tests with coverage and coverage is broken in python3.8 for I don't know which reason | 11:09 |
| benschubert | to use tox -e py38-nocov | 11:09 |
| benschubert | I *hope* coverage 5.0 might help unblock that, but need to fix pytest first :'D | 11:10 |
| tpollard | yep, async under coverage when we merged the 3.8 changes was completely broken | 11:10 |
| valentind | py38-nocover | 11:10 |
| benschubert | ah yes | 11:11 |
| valentind | Well, good I asked, but I could have lost a day finding out that. | 11:11 |
| benschubert | you might have found the real bug by then :D | 11:11 |
| *** lachlan has quit IRC | 11:12 | |
| valentind | Well, at least I get another bug now. | 11:12 |
| valentind | buildbox-casd that does not work. | 11:12 |
| benschubert | not up to date? | 11:12 |
| tpollard | https://gitlab.com/BuildStream/buildstream/-/issues/1173 | 11:12 |
| valentind | 0.0.6 is not enough? | 11:13 |
| benschubert | juergbi: ^ ? | 11:13 |
| tpollard | cypthon doesn't seem to be supporting 5.0 either yet | 11:14 |
| tpollard | *cython | 11:14 |
| juergbi | 0.0.6 is what CI uses right now, so that should work for master | 11:15 |
| juergbi | (I'm in process of updating to 0.0.7, though) | 11:15 |
| *** lachlan has joined #buildstream | 11:17 | |
| valentind | I am not sure what fails. I am trying to test tests/format/include.py::test_include_junction_file | 11:17 |
| valentind | And I get 2 errors. | 11:17 |
| valentind | One is buildstream._exceptions.CASCacheError: Timed out waiting for buildbox-casd to become ready | 11:18 |
| valentind | But maybe it retries and succeeds later. | 11:18 |
| valentind | The other is from the git plugin: | 11:18 |
| valentind | fatal: path '.gitmodules' does not exist in '750392e63e0c4e5108bc410fc35066679b95df46' | 11:18 |
| *** lachlan has quit IRC | 11:20 | |
| valentind | Right but I think buildbox-casd is the issue | 11:21 |
| *** tristan has quit IRC | 11:25 | |
| *** lachlan has joined #buildstream | 11:25 | |
| *** slaf has quit IRC | 11:26 | |
| *** lachlan has quit IRC | 11:32 | |
| *** slaf has joined #buildstream | 11:33 | |
| juergbi | valentind: the casd timeout error is a known issue outside the test suite if the local cache is large and the kernel dentry cache is cold. however, I don't think I've heard of such an issue in the test suite as that works with separate cache directories | 11:37 |
| juergbi | that said, I'm locally testing against buildbox-casd master as I'm working on casd as well | 11:38 |
| juergbi | however, CI uses 0.0.6 and haven't seen it there either | 11:38 |
| valentind | I do not think that is the issue. buildbox-casd is started. It does not seem to do anything. But the socket is not created. | 11:43 |
| *** lachlan has joined #buildstream | 11:43 | |
| juergbi | valentind: do you use NFS or similar? | 11:47 |
| valentind | ext4 | 11:50 |
| valentind | juergbi, Also buildbox-casd has worked before with a previous commit. | 11:50 |
| valentind | It just started to fail now. | 11:50 |
| juergbi | odd, can you give 0.0.7 a shot? | 11:51 |
| juergbi | there will be one test failure (XPASS of test_script_no_root) | 11:51 |
| juergbi | binary is available here: https://buildbox-casd-binaries.nyc3.cdn.digitaloceanspaces.com/buildbox-x86_64-linux-0.0.7-253cb8d6.tar.xz | 11:52 |
| valentind | I will build it. | 11:53 |
| *** tristan has joined #buildstream | 11:55 | |
| *** mohan43u has quit IRC | 11:59 | |
| *** mohan43u has joined #buildstream | 12:03 | |
| *** lachlan has quit IRC | 12:03 | |
| valentind | juergbi, Still the same error. | 12:30 |
| valentind | Oh right, I had this issue before. It was this: https://github.com/grpc/grpc/issues/20757 | 12:33 |
| valentind | I do not remember how I fixed it. | 12:33 |
| *** jib has joined #buildstream | 13:21 | |
| *** lachlan has joined #buildstream | 13:23 | |
| jib | Hi, I have a couple of questions to be able to complete a transition from flatpak-builder to buildstream | 13:23 |
| jib | 1) Is there any way to use ccache to speedup subsequent builds (that would mean storing the ccache folder outside of the sandbox) | 13:24 |
| jib | 2) Is there a way to pass "--option" to bst as string type ? The use case would be to specify the branch to build and to export as flatpak image | 13:25 |
| valentind | for 2) I recommend you generate a yaml file defining a variable that you include. | 13:27 |
| jib | 3) In order to run a testsuite I need to resolve hostnames located inside a VPN, exposing /etc/hosts from the host with the proper IP doesn't seem to make the cut | 13:27 |
| valentind | Put a development version by default. And overwrite the file in the CI to put the right version. | 13:27 |
| jib | @valentind Ok, that was pretty much what I had in mind if passing options as string wasn't possible, thanks | 13:28 |
| valentind | So you run the tests in "bst shell"? | 13:29 |
| jib | "bst shell" but also "bst build" | 13:29 |
| valentind | There is no network in "bst build" | 13:30 |
| jib | because I need the build to fail if the testsuite fails | 13:30 |
| juergbi | jib: 2) are you aware of the `variable` key for options? https://docs.buildstream.build/master/format_project.html#common-properties | 13:30 |
| valentind | juergbi, the problem with the options is that the allowed values have to be declared. | 13:31 |
| juergbi | ah, I see | 13:31 |
| valentind | So you cannot just pass any string. | 13:31 |
| jib | @valentind juergbi yes, that is the problem for passing branches | 13:31 |
| juergbi | source definitions still don't support any variables right now, though. so even an include file with a variable might not help | 13:32 |
| juergbi | this will hopefully be supported in the future, though | 13:32 |
| jib | but generating a yml file is okay and would do the job, though having an option to pass strings from cli would be easier | 13:32 |
| valentind | Was it for the source? I thought it was probably to mark the version somewhere. | 13:33 |
| valentind | I understood it was the version of the flatpak image, not of the upstream element. | 13:33 |
| *** lachlan has quit IRC | 13:33 | |
| juergbi | ah, for that it would be fine, of course | 13:34 |
| jib | Yes it is for the flatpak image because I can do a checkout of the proper branch before starting the build | 13:34 |
| *** lachlan has joined #buildstream | 13:34 | |
| juergbi | jib: 1) this is not currently supported. we do support incremental builds for workspaces, though, which may or may not help in your use case | 13:35 |
| jib | Is there any "test" command which would be able to access the network ? How are we supposed to handle connections to remote machines ? | 13:35 |
| jib | @juergbi Yes I think a can manage to handle it using workspaces indeed, thanks | 13:37 |
| *** lachlan has quit IRC | 13:37 | |
| valentind | jib, I only think of "bst shell" which should have network access. | 13:39 |
| juergbi | jib: 3) I don't think there is a solution right now with `bst build`. it should be fairly simply to support opting out of the network sandboxing (as we already support it for `bst shell`) for individual elements but we should discuss whether this is the right approach | 13:39 |
| valentind | The problem for "build" is that network breaks reproducibility. | 13:40 |
| juergbi | (and have to consider potential issues with simply overriding resolv.conf) | 13:40 |
| juergbi | yes, we definitely don't want to change the default to allow network access | 13:40 |
| juergbi | but I could imagine a `sandbox` `network` option | 13:40 |
| jib | @valentind I can understand that, I think bst should definitively have a "test-commands" with network access like flatpak-builder has | 13:41 |
| *** lachlan has joined #buildstream | 13:41 | |
| juergbi | iirc, in a previous discussion about tests the idea was to have separate test elements | 13:41 |
| valentind | jib, Sure but any other reproducible builds cannot depend on non reproducible test builds. | 13:41 |
| juergbi | i.e., the build elements themselves would still not lose reproducibility | 13:42 |
| coldtom | that was my understanding too juergbi | 13:42 |
| valentind | What we would need is a way to make a reproducible virtual network in sandbox. | 13:42 |
| valentind | So it is possible to do proper integration testing, but reproducible. | 13:43 |
| juergbi | what do you mean by that? | 13:43 |
| juergbi | localhost networking should already work in the sandbox | 13:43 |
| juergbi | if you have a mock or real test server, that should already be fine | 13:43 |
| jib | @valentind the problem then is that you would risk to have reproducible but unproperly tested builds | 13:43 |
| valentind | juergbi, I think in his case he wanted to connect to other machines. | 13:43 |
| valentind | Why unproperly? | 13:43 |
| juergbi | right but presumably because the test runs against some kind of real server that can't be run in the sandbox or not? | 13:44 |
| jib | @juergbi @valentind That is correct, some servers definitively can't be inside the sandbox | 13:45 |
| valentind | Then in this case, "bst shell" | 13:45 |
| jib | @valentind I think using bst shell to have network access is fair. There is still the problem of accessing machines located inside a VPN, do you have any idea how to access them from a network sandbox ? | 13:48 |
| valentind | shell: host-files: ['/etc/resolv.conf'] | 13:52 |
| valentind | I am not aware of the shell to sandbox the network, you should have access to all the network interfaces. | 13:52 |
| jib | @valentind That is strange, I added '/etc/hosts' as host-files and the resolution fails in the sandbox (not on the host) while the accessing machines located inside the VPN by their IP addresses is working... | 13:57 |
| valentind | jib, And have you checked the content of /etc/hosts is correct? | 13:58 |
| valentind | I would also add resolv.conf | 13:58 |
| jib | @valentind Yes because it is working on the host | 13:58 |
| jib | I also added /etc/resolv.conf | 13:58 |
| valentind | Can you "bst shell element.bst -- cat /etc/hosts" ? | 13:59 |
| jib | @valentind I tested it with success with the build flag but I am rebuilding the element to test without it. | 14:05 |
| jib | @valentind I found the problem : I simply needed to expose '/etc/nssswitch.conf' in the sandbox | 14:24 |
| valentind | Oh right. | 14:24 |
| valentind | Or at least put one that allowed hosts. | 14:25 |
| valentind | jib, You are not building on top of Freedesktop SDK? I would expect we have nsswitch.conf | 14:25 |
| valentind | If not we should add it. | 14:25 |
| jib | @valentind I was using app.ym from firefox-buildstream that wasn't exposing it. Btw thanks a lot for it, it helped me a great deal ! | 14:25 |
| valentind | It is components/nsswitch-config.bst | 14:26 |
| valentind | Right. Maybe the test can depend on that element. | 14:26 |
| jib | @valentind Yes I am building on top of freedesktop SDK but I use it as a junction so I am maybe missing a component | 14:26 |
| jib | Thanks, perfect | 14:26 |
| jib | So I guess I now have answers to all my questions, thanks a lot and kudos for all the great work ! :) | 14:31 |
| *** narispo has quit IRC | 14:34 | |
| *** narispo has joined #buildstream | 14:34 | |
| valentind | juergbi, I rebuilt buildbox-casd but linked to my own build of grpc instead of the debian package. And it works. | 14:35 |
| valentind | The debian package is broken. | 14:35 |
| valentind | Probably because they do not use cmake, but the Makefile. Which might not be maintained as well. | 14:35 |
| juergbi | ah, good to know | 14:36 |
| valentind | Or something like that. | 14:36 |
| juergbi | we build buildbox components only against stable debian versions in CI, so not hitting this so far | 14:36 |
| juergbi | debian 10 seems to work fine | 14:36 |
| valentind | I use sid. | 14:38 |
| juergbi | might be good to file an issue to avoid this affecting testing/stable in the future. could be difficult to provide a simple test case, though | 14:40 |
| douglaswinship | Does anyone know how buildstream handles conflicts between dependencies? I've got two different dependencies that both produce different files with the same name, in the same location. I thought it would throw an error, but buildstream seems to be fine with it. It's just chosen one version and gone with that one. | 15:05 |
| douglaswinship | And annoyingly, i wish it had chosen the other one. | 15:05 |
| valentind | douglaswinship, With dependencies | 15:06 |
| valentind | If you want one to overwrite the other, it has to depend on it. And you should declare that the files are overwritten. | 15:06 |
| douglaswinship | Interesting. Declare how? | 15:07 |
| valentind | https://docs.buildstream.build/1.4.2/format_public.html#overlap-whitelist | 15:08 |
| douglaswinship | Thanks! I saw that before, but couldn't make sense of it. I think I understand it now. | 15:13 |
| douglaswinship | I'm still not sure how it made the decision originally though. As it stands now, neither element has a whitelist setting that I'm aware of, but one of them still overwrites the other. | 15:28 |
| juergbi | benschubert: is this node.pyx change reasonable or can you think of a better approach? https://gitlab.com/BuildStream/buildstream/-/merge_requests/1845/diffs?commit_id=cc6ddec45022a68d94b3f47ec0d71a6df4fd679e | 15:32 |
| juergbi | to support optional int keys | 15:33 |
| benschubert | let me have a look | 15:47 |
| benschubert | juergbi: could you benchmark the change? | 15:47 |
| juergbi | with the debian project? sure | 15:48 |
| benschubert | This will generate a completely different C code for those nodes, usings PyObjects instead of C int, so that will reduce the optimisations by quite a bit | 15:48 |
| benschubert | just wonder how much it affect global setup | 15:48 |
| juergbi | I don't think we use tons of ints in elements | 15:49 |
| juergbi | but definitely makes sense to benchmark | 15:49 |
| benschubert | that's true, if the impact is negligible I'm definitely for it :) | 15:49 |
| benschubert | we might want to do the same for booleans later then | 15:50 |
| benschubert | but I remember when I was developing as having a substantial impact, but it wasn't in the final form | 15:50 |
| juergbi | I don't know whether `str` is more efficient than `obj`. if it is, maybe that was the reason | 15:52 |
| benschubert | str is definitely more efficient, cython will use char* internally | 15:54 |
| benschubert | until it _needs_ a string object | 15:54 |
| benschubert | which is then "just" a memoryview | 15:54 |
| benschubert | as far as I understood :) | 15:54 |
| *** lachlan has quit IRC | 16:10 | |
| abderrahim[m] | douglaswinship: about overlaps, bst will just warn by default and take the file from the last element (order is arbitrary but reproducible, and respects dependencies) | 16:33 |
| abderrahim[m] | douglaswinship: you probably want to make the warning fatal so it doesn't overwrite without an overlap whitelist | 16:34 |
| abderrahim[m] | `fatal-warnings: [overlaps]` in your project.conf | 16:35 |
| douglaswinship | abderrahim[m]: interesting. I tried changing to order and it didn't seem to make a difference. I'll retry though. | 16:41 |
| abderrahim[m] | douglaswinship: that's what I meant by "arbitrary but reproducible": if you change the order in your bst files, it doesn't change | 16:43 |
| abderrahim[m] | so if you need something to be considered before another, you need to add a dependency | 16:44 |
| *** lachlan has joined #buildstream | 16:48 | |
| *** jib has quit IRC | 17:00 | |
| benschubert | The order is https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_loader/loadelement.pyx#L163 exactly if you are interested but it's probably too much details :) | 17:01 |
| *** toscalix has joined #buildstream | 17:02 | |
| *** toscalix has quit IRC | 17:08 | |
| douglaswinship | abderrahim[m]: oh, i see what you mean | 17:13 |
| *** santi has quit IRC | 17:23 | |
| *** santi has joined #buildstream | 17:26 | |
| *** lachlan has quit IRC | 17:29 | |
| *** lachlan has joined #buildstream | 17:36 | |
| *** santi has quit IRC | 17:40 | |
| *** ironfoot has quit IRC | 17:43 | |
| *** ironfoot has joined #buildstream | 17:43 | |
| *** ChanServ sets mode: +o ironfoot | 17:43 | |
| *** lachlan has quit IRC | 18:01 | |
| *** tpollard has quit IRC | 18:04 | |
| *** lachlan has joined #buildstream | 18:05 | |
| *** lachlan has quit IRC | 18:09 | |
| *** mohan43u has quit IRC | 18:11 | |
| *** mohan43u has joined #buildstream | 18:11 | |
| *** toscalix has joined #buildstream | 18:16 | |
| *** toscalix has quit IRC | 18:17 | |
| *** toscalix has joined #buildstream | 18:22 | |
| *** phoenix has joined #buildstream | 18:28 | |
| *** toscalix has quit IRC | 18:37 | |
| *** toscalix has joined #buildstream | 18:38 | |
| *** xjuan has joined #buildstream | 18:43 | |
| *** benschubert has quit IRC | 19:54 | |
| *** toscalix has quit IRC | 20:06 | |
| *** phoenix has quit IRC | 21:04 | |
| *** xjuan has quit IRC | 21:32 | |
| *** rdale has quit IRC | 22:21 | |
| *** slaf has quit IRC | 23:40 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!