| *** mohan43u has quit IRC | 03:34 | |
| *** mohan43u has joined #buildstream | 03:35 | |
| *** Prince781 has joined #buildstream | 03:50 | |
| *** mohan43u has quit IRC | 04:47 | |
| *** mohan43u has joined #buildstream | 04:48 | |
| *** skullman has quit IRC | 05:24 | |
| *** skullman has joined #buildstream | 05:24 | |
| *** ernestask has joined #buildstream | 05:37 | |
| *** Prince781 has quit IRC | 05:46 | |
| *** mohan43u has quit IRC | 06:25 | |
| *** mohan43u has joined #buildstream | 06:32 | |
| *** toscalix has joined #buildstream | 07:26 | |
| *** bochecha_ has quit IRC | 07:34 | |
| *** bochecha_ has joined #buildstream | 07:41 | |
| *** jonathanmaw has joined #buildstream | 08:24 | |
| *** bethw has joined #buildstream | 08:28 | |
| *** dominic has joined #buildstream | 08:40 | |
| *** tiago has joined #buildstream | 08:50 | |
| Nexus | tlater: Please can i get some of your thoughts regarding the "Source code available in environment in order to debug" task? | 09:06 |
|---|---|---|
| Nexus | what the actual background for this idea was and what's hoped to be achieved etc | 09:06 |
| Nexus | potentially juergbi too if he's here | 09:06 |
| * tlater thinks he mostly went over that yesterday, but sure | 09:07 | |
| tlater | We want to be able to run software debuggers & co when we run `bst shell` | 09:08 |
| tlater | That's essentially it | 09:08 |
| Nexus | So do we want a workspace in the shell? | 09:08 |
| tlater | What do you mean by that? | 09:08 |
| Nexus | asin actually open a workspace inthe sandbox | 09:09 |
| Nexus | as if the user called workspace open | 09:09 |
| tlater | How do you even expect that to work? You don't even have elements inside the sandbox | 09:09 |
| Nexus | That's what i wanted to clarify, whether we'd be introducing them, or we're just adding a directory containing the source | 09:10 |
| Nexus | like a "oh by the way, there's source here too" | 09:10 |
| tlater | The only reason workspaces come into play here is because we don't want to stage the sources of *all* dependencies. | 09:10 |
| tlater | Back when we came up with the feature we decided that any elements that have open workspaces should have their sources (workspace, I suppose) staged into the sandbox somewhere, if this makes sense | 09:11 |
| tlater | IMO this makes sense when `bst shell` is run | 09:11 |
| Nexus | isn't that what bst shell --build does? | 09:12 |
| tlater | Sort of, but it does it for the element whose build environment you want to inspect | 09:12 |
| tlater | So this is limited since you cannot actually run a debugger on the build output | 09:12 |
| tlater | Because there will be no build output... | 09:13 |
| tlater | Similarly, if there's a bug in a library, your debugger won't be able to look into library source code either | 09:13 |
| *** slaf_ has joined #buildstream | 09:14 | |
| Nexus | So we instead want to add "all of the sources used in the build process" ? | 09:14 |
| *** slaf_ has joined #buildstream | 09:14 | |
| tlater | No, because that would be slow as hell | 09:15 |
| tlater | > The only reason workspaces come into play here is because we don't | 09:15 |
| tlater | want to stage the sources of *all* dependencies. | 09:15 |
| tlater | I.e., we stage the sources of only those elements who have workspaces | 09:16 |
| tlater | That in turn allows the user to specify exactly which elements they'd like to debug | 09:16 |
| *** slaf has quit IRC | 09:16 | |
| *** slaf_ is now known as slaf | 09:16 | |
| tlater | So they're happy, and buildstream isn't slow | 09:16 |
| Nexus | so if i have 10 workspaces, and i open a shell, i'll get all of those sources too? | 09:17 |
| tlater | Yeah, I think that's sensible | 09:17 |
| tlater | Since clearly those are being developed | 09:17 |
| tlater | s/$/on/ | 09:18 |
| tlater | We can of course think about enabling/disabling this with a switch on shell, but that's a detail we can consider later | 09:18 |
| *** dominic has quit IRC | 09:19 | |
| Nexus | kk | 09:19 |
| gitlab-br-bot | buildstream: issue #411 ("Native bst support on OS X, remote execution only") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/411 | 09:29 |
| gitlab-br-bot | buildstream: issue #412 ("Native bst support on Windows w/ WSL, remote execution only") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/412 | 09:31 |
| *** dominic has joined #buildstream | 09:39 | |
| jennis | Does anyone have any strong feelings against introducing mocking into our tests? | 09:47 |
| skullman | not particularly, I already feel like they are mocking me when they fail | 09:48 |
| jennis | https://docs.python.org/3/library/unittest.mock.html | 09:49 |
| Nexus | i agree with skullman | 09:56 |
| Nexus | it might make me more inclined to fix them if they mock me | 09:56 |
| skullman | ha | 09:57 |
| *** aday has joined #buildstream | 10:11 | |
| *** noisecell has quit IRC | 10:24 | |
| *** noisecell has joined #buildstream | 10:25 | |
| *** noisecell has quit IRC | 10:48 | |
| *** noisecell has joined #buildstream | 11:00 | |
| Nexus | Please can we clean up the "correction :" commits? | 12:12 |
| tlater | Nexus: It's too late, they're on master now | 12:12 |
| Nexus | damn | 12:12 |
| tlater | +1 on not making commits called "correction :" though | 12:12 |
| tlater | (By extension perhaps not committing to master without *some* review, even for non-code work) | 12:13 |
| * Nexus likes the issue templates | 12:17 | |
| laurence | I have posted to the list re dog-fooding, and would appreciate any comments | 12:21 |
| laurence | specifically if there's an obvious thing I'm missing which would block this from getting started straight away | 12:21 |
| Nexus | didn't tlater raise a point yesterday about a potential problem? | 12:24 |
| tlater | Nexus: We'll see if it is a problem when we start working on it :) | 12:43 |
| noisecell | hi, does someone knows anything about: https://gnome1.codethink.co.uk/logs/build-2018-05-30-091327/build.txt ? these logs are linked from https://wiki.gnome.org/Projects/BuildStream/Infrastructure in "Flatpak SDK builds for ARM" section. Both builds have a number of packages which failed to build in both architectures. I was going to file a bug in: https://gitlab.gnome.org/GNOME/gnome-apps-nightly (as agreed with jjardon) but I feel I should ask h | 12:49 |
| noisecell | ere before doing it, just in case some of you know anything about this. | 12:49 |
| jjardon | mmm, the info in that wiki https://wiki.gnome.org/Projects/BuildStream/Infrastructure is incorrect / out-of-date | 12:53 |
| * jjardon updates | 12:53 | |
| *** xjuan has joined #buildstream | 12:54 | |
| gitlab-br-bot | buildstream: issue #413 ("Add sources to bst shell") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/413 | 12:59 |
| valentind | juergbi, I get some error "TypeError: __new__() got an unexpected keyword argument 'file'" when running juerg/googlecas branch. Would you have any hint on how to debug that? https://pastebin.com/9LkAaGvH | 13:01 |
| toscalix | jjardon: thanks | 13:01 |
| toscalix | jjardon: is there a chance to keep the wiki pages on gitlab and ask people to change them there? At least some of the basic ones. Is this something other GNOME projects do or they always edit directly? | 13:02 |
| jjardon | toscalix: first question; depends on buildstream maintainers where they want to keep the wiki pages. Second question not sure I understand; every trusted user can edit the gnome wiki is that's what you are asking | 13:04 |
| toscalix | directly then, ok | 13:05 |
| juergbi | valentind: hm, an error in the generated code, that's odd. and that's also with Python 3.6 | 13:18 |
| valentind | juergbi, I managed to get it to run by running build_grpc. I suppose this one should be always run if it depends on the python version. | 13:18 |
| valentind | It worked on a python 3.5 without changes. But python 3.6 did not work. | 13:18 |
| juergbi | interesting, I've been testing on 3.6 and it works in CI with Python 3.4 and 3.6 | 13:19 |
| juergbi | always regenerating the code would add a build/install dependency of grpcio_tools. not sure how much of an issue this would be in practice | 13:20 |
| valentind | juergbi, I have python3-protobuf installed by the system. Could it be related? | 13:20 |
| juergbi | it could well be an issue of a mismatch in the installed protobuf version, yes | 13:21 |
| valentind | Or are there other python packages on which the version is important? | 13:21 |
| juergbi | protobuf and grpcio are likely the only modules that matter in this regard | 13:22 |
| juergbi | should probably try to investigate about the stability of generated code | 13:22 |
| *** aday has quit IRC | 13:35 | |
| *** aday has joined #buildstream | 13:35 | |
| valentind | juergbi, minor, but annoying, the server prints a lot of warnings "Could not get common name of subject from certificate.". I followed the documentation. I think we need CN for client certificates for this to disappear. | 13:35 |
| *** finn has quit IRC | 13:46 | |
| *** finn has joined #buildstream | 13:48 | |
| juergbi | valentind: right, thanks. I changed this locally but forgot to change it to the docu | 13:57 |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: Remote Execution CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 14:04 |
| *** finn has quit IRC | 14:16 | |
| *** finn has joined #buildstream | 14:16 | |
| *** finn has quit IRC | 14:21 | |
| *** finn has joined #buildstream | 14:23 | |
| *** sstriker has joined #buildstream | 14:26 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 14:29 |
| tlater | Does the tarcache currently store two artifacts for weak and strong cache keys? | 14:46 |
| tlater | I suppose there is no deduplication going on there, so... | 14:46 |
| tlater | Well, at least that explains my test failures | 14:49 |
| juergbi | tlater: I thought it used symlinks but don't remember exactly | 14:50 |
| tlater | Hm, perhaps the cache size calculation follows symlinks then | 14:52 |
| tlater | No, it doesn't | 14:52 |
| juergbi | tlater: oh, you're right, it creates two archives | 14:53 |
| juergbi | no deduplication at all | 14:53 |
| tlater | Probably not worth looking into too much, the tar cache definitely will be superseded by CAS | 14:54 |
| juergbi | yes | 14:54 |
| tlater | Still, gotcha for my test cases... | 14:54 |
| juergbi | tlater: if it's just an issue with a test case, not causing an actual regression, you could consider marking the test case as linux-only | 14:56 |
| juergbi | (in light of the CAS replacement) | 14:56 |
| tlater | juergbi: I suppose, but it really just made choosing file sizes trickier than I thought. Already solved it, I just thought I was creating an artifact twice for a moment (: | 14:58 |
| juergbi | ah ok | 14:59 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 15:00 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 15:01 |
| *** Prince781 has joined #buildstream | 15:02 | |
| *** jennis has quit IRC | 15:11 | |
| *** jennis has joined #buildstream | 15:11 | |
| *** jennis has quit IRC | 15:18 | |
| *** bochecha_ has quit IRC | 15:19 | |
| *** bochecha_ has joined #buildstream | 15:19 | |
| *** jennis has joined #buildstream | 15:20 | |
| *** sstriker has quit IRC | 15:31 | |
| jennis | mhmm I'm running a specific test file `./setup.py test --addopts 'tests/frontend/push.py'` and it's passing, however when I run ALL the tests `./setup.py test` that file is the only one failing | 15:49 |
| jennis | That's weird, right? | 15:49 |
| Nexus | why is it failing? Maybe the test before isn't cleaning up properly and it's failing because of that | 15:52 |
| jennis | potentially | 15:58 |
| jennis | But that test has just passed in CI | 16:01 |
| noisecell | Hello, Im trying to build https://gitlab.com/baserock/definitions/blob/master/elements/systems/openstack-system-content.bst which it seems it does build in definitions CI: https://gitlab.com/baserock/definitions/-/jobs/71226696 but it doesn't build in my local VM: https://paste.baserock.org/ukugetawos -- Im using BuildStream Version 1.1.3+72.gc0de75e2 and master of definitions. I have followed the instructions to set up buildstream in my VM. am | 16:11 |
| noisecell | Im missing something? | 16:11 |
| noisecell | as a second question I was expecting that none of the packages for that system would need to be rebuilt given that it should be in the cached (the system is built in gitlab) but it seems that some of the packages run build commands, is this expected? | 16:12 |
| gitlab-br-bot | buildstream: merge request (jennis/alternative_remote_expiry->master: Jennis/alternative remote expiry) #477 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/477 | 16:22 |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 16:23 |
| gitlab-br-bot | buildstream: merge request (jennis/136-clean-remote-cache->master: WIP: jennis/136 clean remote cache) #421 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/421 | 16:23 |
| gitlab-br-bot | buildstream: merge request (jennis/alternative_remote_expiry->master: Expire artifacts in the remote artifact cache) #477 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/477 | 16:24 |
| jjardon | noisecell: it's rebuilding because the cache key between the version of bst you are using and the one used to generate the artifacts in the cache is not the same | 16:24 |
| paulsherwood | jjardon: ybd supports versionign of keys... does bst not do that? | 16:25 |
| jjardon | noisecell: https://gitlab.com/BuildStream/buildstream/issues/226 | 16:25 |
| jjardon | paulsherwood: I do not think so | 16:26 |
| noisecell | jjardon, oh, so you have opened this issue already. | 16:34 |
| jjardon | noisecell: did I? :) | 16:36 |
| noisecell | jjardon, https://gitlab.com/BuildStream/buildstream/issues/326 -- for the second question yeah :) | 16:37 |
| noisecell | the first question still stand. Why gnu-toolchain-stage2-gawk detects that it doesn't have a valid compiler? | 16:44 |
| noisecell | "checking whether the C compiler works... no" | 16:44 |
| noisecell | and in the CI this is not an issue? | 16:44 |
| jjardon | noisecell: have you tried to use the exact same version in the CI, to be sure this is not a problem in your environment? | 16:46 |
| noisecell | jjardon, not yet. which problem could I have in my environment jjardon? | 16:48 |
| jjardon | noisecell: I do not know, but I know the CI env is inmutable | 16:48 |
| noisecell | jjardon, I am using a fedora 28 VM with only the packages required to run buildstream so far. | 16:50 |
| *** toscalix has quit IRC | 16:51 | |
| gitlab-br-bot | buildstream: merge request (jennis/alternative_remote_expiry->master: Expire artifacts in the remote artifact cache) #477 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/477 | 16:54 |
| noisecell | jjardon, with 1.0.1 version, it does pull all the artefacts, it doesn't build anything so there are not errors. | 17:03 |
| *** bethw has quit IRC | 17:05 | |
| *** finn has quit IRC | 17:11 | |
| *** dominic has quit IRC | 17:11 | |
| *** jonathanmaw has quit IRC | 17:15 | |
| gitlab-br-bot | buildstream: merge request (richardmaw/cache-fail->master: WIP: Store failed builds in the cache) #475 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/475 | 17:16 |
| *** ernestask has quit IRC | 17:16 | |
| jjardon | noisecell: yeah, seems a regression with bst 1.1.3: https://gitlab.com/baserock/definitions/merge_requests/78, 1.1.2 seems to work (It's failing in another place): https://gitlab.com/baserock/definitions/merge_requests/77 | 17:36 |
| *** lantw44 has quit IRC | 17:49 | |
| *** lantw44 has joined #buildstream | 17:49 | |
| *** finn has joined #buildstream | 17:58 | |
| gitlab-br-bot | buildstream: issue #414 ("Seems bst 1.1.3 doesn't build correctly anymore (it works fine with 1.1.2)") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/414 | 18:07 |
| jjardon | noisecell: I have opened ^ | 18:08 |
| *** finn has quit IRC | 18:17 | |
| *** aday has quit IRC | 18:59 | |
| *** aday has joined #buildstream | 19:07 | |
| *** aday has quit IRC | 19:34 | |
| *** xjuan has quit IRC | 19:42 | |
| *** aday has joined #buildstream | 20:08 | |
| *** milloni has quit IRC | 20:09 | |
| *** milloni has joined #buildstream | 20:10 | |
| *** milloni has quit IRC | 20:18 | |
| *** aday has quit IRC | 20:18 | |
| *** milloni has joined #buildstream | 20:18 | |
| *** bochecha_ has quit IRC | 20:27 | |
| *** Prince781 has quit IRC | 21:06 | |
| *** cs_shadow has quit IRC | 22:05 | |
| *** aday has joined #buildstream | 22:26 | |
| *** aday has quit IRC | 22:30 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!