*** leopi has joined #buildstream | 02:13 | |
*** mohan43u has quit IRC | 02:21 | |
*** mohan43u has joined #buildstream | 02:25 | |
*** leopi has quit IRC | 02:52 | |
*** leopi has joined #buildstream | 03:26 | |
*** alatiera_ has joined #buildstream | 04:11 | |
*** alatiera_ has quit IRC | 04:20 | |
*** alatiera_ has joined #buildstream | 04:21 | |
*** alatiera_ has quit IRC | 05:23 | |
*** tristan has joined #buildstream | 05:40 | |
*** alatiera_ has joined #buildstream | 06:19 | |
*** bochecha has joined #buildstream | 07:23 | |
*** toscalix has joined #buildstream | 07:28 | |
*** finn has joined #buildstream | 07:44 | |
gitlab-br-bot | buildstream: issue #394 ("Abstraction of storage used by sandbox") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/394 | 07:48 |
---|---|---|
*** bethwhite_ has joined #buildstream | 08:02 | |
gitlab-br-bot | buildstream: issue #550 ("pulling from the cache doesn't honor the fetchers setting") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/550 | 08:14 |
*** rdale has joined #buildstream | 08:14 | |
gitlab-br-bot | buildstream: merge request (Qinusty/terminate-retries-backport-1.2->bst-1.2: Backport: Prevent terminated jobs retrying) #681 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/681 | 08:19 |
*** WSalmon has joined #buildstream | 08:24 | |
*** jonathanmaw has joined #buildstream | 08:32 | |
*** solid_black has joined #buildstream | 08:32 | |
qinusty | tristan: Regarding the use of failure, success and start messages. Am I right in assuming that we shouldn't be printing failure etc ANYWHERE other than context? Currently, the "Try #2 failed, retrying" message is a FAIL, but I'm thinking we change it to a WARN. A similar concern is in buildqueue.py during enqueue. | 08:49 |
*** tpollard has joined #buildstream | 08:49 | |
*** tpollard has joined #buildstream | 08:49 | |
*** ChanServ sets mode: +o tristan | 08:54 | |
tristan | qinusty, looking at buildqueue.py: "# Bypass queue processing entirely the first time it's tried." is making my eyes bleed :-( | 08:54 |
tristan | qinusty, until we fix that craziness; I think it's appropriate to allow these deep levels of the core to trigger the failure messages without any added convenience; possibly with a lower level messaging function on Context | 08:57 |
tristan | qinusty, my primary worry is that making a pretty convenience API is an invitation to developers to use it | 08:57 |
qinusty | Okay tristan, I'll leave failure open to the internal api outside of context for now. | 08:58 |
tristan | for those messages, they really should only be happening as a result of timed_activity(), otherwise the scheduler itself (in job.py) does the START/SUCCESS/FAIL thing, and it's the only place | 08:59 |
qinusty | I'll mark it appropriately though | 08:59 |
qinusty | Indeed. | 08:59 |
tristan | in fact, the original tlater branch which refactored the scheduler, had resulted in a confusing scattering of those START/SUCCESS/FAIL messages | 08:59 |
qinusty | Also, https://gitlab.com/BuildStream/buildstream/blob/f53ff3705fa92c294cfad111cba27e53292cc2a8/buildstream/_scheduler.py#L607 tristan, this is basically timed_activity(). It predates timed_activity, I assume it was just never updated. | 08:59 |
tristan | which I came around and fixed myself pre-merge with a bit of a logging refactor | 08:59 |
tristan | it seems that this buildqueue.py message escaped me at the time | 09:00 |
tristan | is that commit id master ? | 09:01 |
tristan | qinusty, I dont see it in master, why am I looking at that commit you linked to ? | 09:02 |
tristan | qinusty, that looks like some weird kind of duplicate that belongs in job.py | 09:02 |
tristan | oh, that is part of the Job class | 09:03 |
tristan | is this a really old commit ? | 09:03 |
tristan | qinusty, that looks like it is indeed the code segment from job.py; I don't think that timed_activity() can be made to do the right thing for the child job harness | 09:03 |
*** flatmush has quit IRC | 09:05 | |
qinusty | Hmmm, I'll take a look when I get back to my desk. Pretty sure it's in my branch which was rebased onto master | 09:05 |
*** flatmush has joined #buildstream | 09:05 | |
tristan | that commit says it's in scheduler.py | 09:06 |
tristan | which cannot be, at least not since over a year ago when the scheduler was a single python file | 09:06 |
* qinusty linked the wrong file. | 09:06 | |
qinusty | Job.py child action. Is basically timed_action? | 09:07 |
tristan | qinusty, it's basically the only place that should be firing the messages what timed_activity() does manually, asides from the retry logic | 09:08 |
tristan | s/what/that | 09:08 |
tristan | <tristan> for those messages, they really should only be happening as a result of timed_activity(), otherwise the scheduler itself (in job.py) does the START/SUCCESS/FAIL thing, and it's the only place | 09:09 |
*** leopi has quit IRC | 09:10 | |
*** noisecell has joined #buildstream | 09:11 | |
gitlab-br-bot | buildstream: merge request (tpollard/591->master: WIP: buildstream/_project.py: Report if project.conf is missing name) #680 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/680 | 09:12 |
qinusty | Is there a reason that retry logic /should/ be firing failures? (Since it's still retrying I'd argue it's a warning) | 09:12 |
*** tpollard has quit IRC | 09:14 | |
*** tpollard has joined #buildstream | 09:14 | |
tristan | qinusty, we should we retry something that only had a warning ? I think we only retry things which failed; warnings inform the user something could be amiss, but that we can build just fine anyway | 09:18 |
tristan | Does anyone here use Fedora ? | 09:20 |
tristan | I'd love it if someone who uses fedora could try https://gitlab.com/BuildStream/buildstream/tree/tristan/notifications-1.2 for me | 09:21 |
*** bethwhite_ has quit IRC | 09:22 | |
qinusty | Tristan, I mean it still says failure, but the message should be a warning since the job is still trying. Once it retries n times, it will fail | 09:23 |
tristan | qinusty, I know, I disagree with that, I don't think a warning ever caused something to be retried, and doubt that it should | 09:24 |
valentind | I started to get errors with tests/integration/project/files/pip-source/app1.py when pylint is run. | 09:30 |
tristan | valentind, I just got that too, confusing :-S | 09:34 |
tristan | I think maybe I have a different pylint installation ? | 09:35 |
valentind | I had that since Friday. | 09:35 |
valentind | I did not install pylint on my machine. | 09:35 |
tristan | Maybe we should pin the version | 09:35 |
valentind | And I tried to downgrade the one downloaded by setuptools. | 09:35 |
tristan | but pylint seems not to be in setup.py | 09:35 |
valentind | Yes. but it still happens with 2.0.0 | 09:35 |
valentind | I think there are some other issues. | 09:36 |
tristan | actually I don't think this is pylint related, not the error I got | 09:37 |
tristan | I got an import error | 09:37 |
tristan | lemme try again | 09:37 |
tristan | valentind, I think that it's because there is a python file in the tests directory, without having __init__.py files in all of the preceding directories | 09:38 |
WSalmon | martin had to pin the version of pylint for build grid iirc, martin^ dose this look similar? | 09:39 |
WSalmon | mablanch, even | 09:40 |
valentind | Well, I need to pin also the version of pylint. But this is another issue. | 09:40 |
WSalmon | well mablanch is pretty good at all thinks pytest etc if you want a second pair of eyes, other wise sorry for the noise | 09:42 |
tristan | Ok well, lets pin the version of pylint in the setup.py... or... in the dev-requirements.txt rather, since that is now scattered into a separate file | 09:45 |
tristan | at least we know that has to be done so that CI matches locally run tests | 09:45 |
mablanch | I had to pin the version of pytest in order to fix a test collection issue, doesn't seem to be related to what you're experiencing here... | 09:45 |
tristan | mablanch, if you had to pin it locally, do you think it's possible that it needs to be pinned on any other computer ? | 09:47 |
tristan | aha, ok I see what's going on | 09:47 |
tristan | I wonder how the tests could have ever possibly passed :-S | 09:48 |
mablanch | tristan: Had to pin it for BuildGrid actually, and pinned it in setup.py tests-requirements. | 09:48 |
valentind | tristan, How do you fix the app.py issue? | 09:49 |
tristan | valentind, mablanch; to summarize, the problem I am seeing is that tests/integration/project/files/pip-source/app1.py fails to be imported when running tests | 09:49 |
tristan | it is failing to find/import 'hellolib' | 09:49 |
tristan | This is happening because hellolib is only expected to exist in the sandbox where the integration test runs | 09:49 |
tristan | For some reason, this passed CI, and presumably also passed on cs-shadow's computer | 09:50 |
gitlab-br-bot | buildstream: merge request (fix-quota-tests->master: Mock storage space checks for tests.) #635 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/635 | 09:50 |
tristan | The reason it is happening, is because pytest naturally tries to import every single python file in the tests/ directories at startup time | 09:50 |
tristan | mablanch, thanks for clarifying this was specifically for BuildGrid | 09:50 |
tristan | valentind, do *you* also have to pin pylint ? | 09:51 |
tristan | I think anyway, we need to pin it, even if it's a separate issue; pinning it locally is not a solution | 09:51 |
valentind | tristan, yes. Because the last version complains about new stuff. | 09:51 |
tristan | right, so we should not allow upgrades of dependencies to randomly introduce breakage | 09:52 |
tristan | instead, if someone wants a new version of pylint in the future; they can go ahead and fix the errors it causes, and pin to the new version, in their merge request | 09:52 |
valentind | tristan, ERROR collecting tests/integration/project/files/pip-source/app1.py. It is not pylint. | 09:54 |
valentind | I think it is pytest. | 09:55 |
tristan | valentind, yes these appear to be separate issues | 09:55 |
tristan | valentind, however, if you need to pin the version of pylint for some reason, I think it means it's possible that someone else will too | 09:55 |
tristan | valentind, which means; we have to pin it in dev-requirements.txt; to make sure it's always the same for everyone | 09:56 |
valentind | We need a pytest.ini that lists norecursedirs. | 10:00 |
tristan | valentind, I also fixed it a different way | 10:01 |
valentind | Oh ok | 10:01 |
*** cs-shadow has joined #buildstream | 10:01 | |
tristan | valentind, but not sure which to choose | 10:01 |
valentind | tristan, what is the other way? | 10:01 |
tristan | valentind, in *any* case I think your norecursedirs will work equally in setup.cfg under [tool:pytest] | 10:02 |
tristan | valentind, what I did, was add to the default --addopts: --ignore=tests/integration/project | 10:02 |
tristan | valentind, what did you do exactly for norecursedirs ? I'm not finding docs for that; do you set it to tests/integration/project ? | 10:04 |
tristan | ahh | 10:05 |
tristan | valentind, I see we already have it in setup.cfg, lemme check... | 10:05 |
gitlab-br-bot | buildstream: merge request (Qinusty/terminate-retries-backport-1.2->bst-1.2: Backport: Prevent terminated jobs retrying) #681 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/681 | 10:06 |
valentind | tristan, I am fine with your solution. Mine did not work as expected. | 10:07 |
tristan | valentind, adding tests/integration/project to the existing norecursedirs list in setup.cfg seems to work | 10:07 |
tristan | I prefer your solution in setup.cfg as it follows a pattern we already use | 10:08 |
tristan | but let's see if the tests pass | 10:08 |
tristan | already on master, I have a failing tests for buildstream/_artifactcache/cascache.py, I will have to wait until the end, but it appears to be a pep8 violation | 10:08 |
valentind | OK, I see. | 10:09 |
Nexus | is | 10:12 |
valentind | tristan, Here is an example of pylint error I get for buildstream/_workspaces.py | 10:12 |
Nexus | is it possible to conditionally skip a test file? not just an individual test? | 10:12 |
valentind | R:370,13: Simplify chained comparison between the operands (chained-comparison) | 10:12 |
tristan | valentind, right, and for cascache.py I am getting: W:333,60: Cell variable resource_name defined in loop (cell-var-from-loop) | 10:17 |
valentind | tristan, useless-return, assignment-from-no-return- consider-using-in | 10:17 |
tristan | with whatever random, unpinned version of pylint I am using | 10:17 |
valentind | juergbi said the last version worked for him. | 10:18 |
gitlab-br-bot | buildstream: merge request (tristan/exclude-project-py-from-tests->master: setup.cfg: Add tests/integration/project to norecursedirs) #682 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/682 | 10:21 |
gitlab-br-bot | buildstream: merge request (coldtom/autotools-libtool->master: Upstream freedesktop-sdk autotools config) #683 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/683 | 10:22 |
tristan | ok !682 above should fix this so long as that passes in CI | 10:22 |
tristan | ok "last version" | 10:23 |
tristan | latest is 2.1.1 | 10:24 |
valentind | It does not work for me. But it works for him. Not sure how. | 10:24 |
tristan | grrr | 10:24 |
tristan | latest version of pylint causes *LOTS* of files to fail | 10:29 |
gitlab-br-bot | buildstream: merge request (tpollard/591->master: buildstream/_project.py: Report if project.conf is missing name) #680 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/680 | 10:31 |
Nexus | juergbi, tristan: any idea about my tests question? | 10:34 |
tristan | Nexus, I did a quick google, it appears not really possible; or used to be in older versions of python but stopped working | 10:37 |
tristan | Nexus, or, this maybe does it: https://docs.pytest.org/en/latest/skipping.html#summary ? | 10:38 |
tristan | Nexus, found that by way of https://stackoverflow.com/questions/42511879/pytest-skip-entire-module-file-python-2-and-3 | 10:39 |
tristan | WSalmon, please take a look at https://gitlab.com/BuildStream/buildstream/merge_requests/683 | 10:40 |
Nexus | thanks tristan, i'll have a read | 10:40 |
tristan | valentind, juergbi; so here's what I'm about to do: I'm going to make a test run in CI and use `pip show` to figure out what exact versions we use for pytest, pylint, and basically everything that is now in `dev-requirements.txt` | 10:48 |
tristan | And just hammer those dependencies to the exact versions found in CI | 10:48 |
tristan | Sound sensible ? | 10:48 |
tristan | Or, should I just do it for pylint ? | 10:51 |
tpollard | I need to pin pytest locally, so I'd be happy for it to be pinned by default | 10:52 |
WSalmon | thanks tristan, coldtom and myself have had a chat about this afk | 10:53 |
tristan | tpollard, yeah; it's not really a matter of convenience, it's a matter of requirement I think | 10:53 |
tristan | What's even worse, is that if/when we update one day to a latest image produced by buildstream-docker-images, this will all suddenly blow up in our face | 10:54 |
tristan | well, just about as bad as people not being able to reliably run tests locally | 10:54 |
valentind | tristan, "pip3" | 10:55 |
tristan | valentind, yeah, the script does that actually :) | 10:55 |
valentind | ok then | 10:55 |
valentind | It would be nice if setuptools just showed all resolved versions of dependencies. | 10:56 |
tristan | yeah, looks like pylint depends on some other thing too | 10:57 |
tristan | probably best to go all the way down the rabbit hole | 10:57 |
tristan | at least, these are only development requirements; so in theory, it should not hurt the distro story | 10:58 |
tristan | woot look at that, passing tests | 11:03 |
gitlab-br-bot | buildstream: merge request (tristan/pin-pytest-pylint->master: dev-requirements.txt: Pinning required pytest and pylint versions) #684 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/684 | 11:09 |
tristan | ok let's see how that fares in CI | 11:09 |
tristan | I only pinned pytest and pylint in this case, as I think they are the most likely cause of problems, and I'm not sure that changing things too much at this point is going to cause other problems somehow | 11:10 |
valentind | tristan, https://gitlab.com/BuildStream/buildstream/commit/834b3c0ab55f78b4528c4026ca80a7c030abcad2 | 11:19 |
*** rdale has quit IRC | 11:19 | |
valentind | Then you run "python3 setup.py show". And it shows all versions. | 11:19 |
tlsa | I'm building a kernel under buildstream. Why is LDFLAGS set to "-fstack-protector-strong -Wl,-z,relro,-z,now" in the sandbox? | 11:19 |
valentind | Of dependencies. | 11:20 |
tlsa | the kernel build gives: | 11:20 |
tlsa | ld: unrecognized option '-Wl,-z,relro,-z,now' | 11:20 |
tlsa | because it's being passed straight to `ld` | 11:20 |
valentind | Because maybe LDFLAGS in the kernel are for ld, not for gcc. | 11:21 |
valentind | I suppose the makefiles call ld directly. | 11:21 |
valentind | tlsa | 11:22 |
tlsa | sure, I'm just wondering why buildstream is setting that in the env? | 11:22 |
valentind | I think it is for security reason. | 11:22 |
tristan | I don't think BuildStream is doing that... | 11:22 |
tristan | is it ? | 11:22 |
tlsa | hmm, not sure. I assumed so. I'll dig a bit more | 11:23 |
tristan | http://buildstream.gitlab.io/buildstream/format_project.html#builtin-defaults | 11:23 |
tristan | the default project.conf is there, environment says it is not done there | 11:24 |
tristan | tlsa, I presume this might be from freedesktop-sdk configs ? | 11:24 |
tristan | lemme check autotools element | 11:24 |
tlsa | ah, yeah, it's in the project.conf | 11:24 |
tlsa | yep, freedesktop | 11:24 |
tristan | right, not in autotools either (http://buildstream.gitlab.io/buildstream/elements/autotools.html) | 11:25 |
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:25 |
tristan | tlsa, it does look like something that was inherited, or carried over from the flatpak-builder SDK builds | 11:25 |
valentind | Yes. We define it in freedesktop SDK. It is one of the flag we pass for security reason. | 11:25 |
valentind | I think all distributions use it. | 11:26 |
tlsa | ok | 11:26 |
tristan | in some cases I think some elements override it | 11:26 |
tlsa | I'll dig into why my kernel version is complaining then | 11:26 |
tristan | which might or might not be needed | 11:26 |
*** tristan has quit IRC | 11:31 | |
*** tristan has joined #buildstream | 11:37 | |
*** ChanServ sets mode: +o tristan | 11:42 | |
gitlab-br-bot | buildstream: merge request (tristan/exclude-project-py-from-tests->master: setup.cfg: Add tests/integration/project to norecursedirs) #682 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/682 | 11:47 |
gitlab-br-bot | buildstream: merge request (tristan/pin-pytest-pylint->master: dev-requirements.txt: Pinning required pytest and pylint versions) #684 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/684 | 11:49 |
gitlab-br-bot | buildstream: merge request (tpollard/483->master: plugins/git.py: Warn if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 12:06 |
*** rdale has joined #buildstream | 12:06 | |
gitlab-br-bot | buildstream: merge request (coldtom/autotools-libtool->master: Upstream freedesktop-sdk autotools config) #683 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/683 | 12:13 |
*** CTtpollard has joined #buildstream | 12:32 | |
*** tpollard has quit IRC | 12:33 | |
*** WSalmon_ has joined #buildstream | 12:34 | |
*** WSalmon has quit IRC | 12:35 | |
gitlab-br-bot | buildstream: merge request (coldtom/autotools-libtool->master: Upstream freedesktop-sdk autotools config) #683 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/683 | 12:38 |
valentind | There is something I wonder if it is properly tested. Weak keys are rarely used, and the mtime is not updated I suppose in the cache. So at the end, weak keys would probably be removed from the cache first during cleanup. Even when there is a matching strong key available. When we suddenly use --no-strict, I would expect that we do not find those weak keys in the cache. And then we build again the artifact even though we have artifacts with the | 12:53 |
valentind | same weak key. | 12:53 |
gitlab-br-bot | buildstream: merge request (jonathan/cache-cache-size->master: Jonathan/cache cache size) #679 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/679 | 13:07 |
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 | 13:18 |
gitlab-br-bot | buildstream: issue #594 ("pull step reported a SUCCESS even if the a artifact was not found in the cache server") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/594 | 13:21 |
jjardon | qinusty: hi, is this enough info for you? https://gitlab.com/BuildStream/buildstream/issues/594 | 13:21 |
Nexus | why is pylint shouting at me for a load of "Assigning to function call which doesn't return (assignment-from-no-return)" and similar stuff? | 13:26 |
qinusty | Nexus, it was the issue I get when not using the docker container. *shrugs* I determined it to be a version issue | 13:30 |
qinusty | 3.5.3 | 13:30 |
qinusty | python | 13:30 |
gitlab-br-bot | buildstream: issue #595 ("BUG: Missing Artifact when checking out with --no-strict") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/595 | 13:30 |
qinusty | I just do all my linting within the standard buildstream container now | 13:31 |
Nexus | i've not changed my python version in a long time, have we updated pylint? | 13:32 |
jmac | Something's changed in the project this morning which has given me a lot of pylint errors, not had time to investigate yet though | 13:34 |
cs-shadow | https://gitlab.com/BuildStream/buildstream/merge_requests/684 seems to suggest that 2.1.1 is a "good" version | 13:35 |
cs-shadow | for pylint | 13:35 |
* qinusty had issues with 2.1.1 and python 3.5.3 | 13:35 | |
qinusty | So I'm not sure, I just dockerized it and bam, it works | 13:35 |
Nexus | that's not a fix though, it's just a workaround | 13:36 |
qinusty | Indeed | 13:36 |
Nexus | so, tristan did something with pytest today | 13:37 |
Nexus | Does anyone else get "module missing" error if they go back a couple of commits in master, but dissapears in the current master? | 14:00 |
*** WSalmon_ has quit IRC | 14:07 | |
*** WSalmon_ has joined #buildstream | 14:08 | |
tristan | cs-shadow, meant to ping you about that; so what I did was basically to just check what versions of things were running in the default image in CI, and pinning pytest and pylint to the versions in CI caused tests to pass locally | 14:08 |
tristan | cs-shadow, but it seems that not the same version of pytest & pylint is available in all the different docker images | 14:09 |
tristan | cs-shadow, maybe if we run a build of the docker images with the same version pinning we can make the switch ? | 14:09 |
tristan | qinusty, I'm curious if you use both pytest and pylint at the pinned versions, if it will still break for you | 14:10 |
tristan | and, it would be good to ensure we have a 3.5.x python version in the CI somewhere, I thought maybe the debian 9 image was | 14:11 |
tristan | debian 8 was 3.4 but we discontinued support | 14:11 |
tristan | cs-shadow, you raise some interesting points though in !684, maybe it's better indeed if we (A) Pin all of the development requirements to specific versions and (B) Allow the images to access the internet while installing the dev-requirements.txt deps | 14:13 |
tristan | my patch only pinned pytest and pylint thinking that should be enough | 14:13 |
jonathanmaw | juergbi: when I run tests locally pylint's flagging https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_artifactcache/cascache.py#L333 with "cell-var-from-loop". Should I be worried about that? | 14:38 |
juergbi | jonathanmaw: no, this shouldn't cause any actual issues | 14:41 |
juergbi | hopefully we can bring these pylint messages in sync as it doesn't show up here / in CI | 14:41 |
jonathanmaw | juergbi: when I was working on it, I added "# pylint: disable=cell-var-from-loop" to that line so I wouldn't have to worry about it | 14:43 |
juergbi | we could move uuid_ and resource_name definitions into the request_stream function. I think that should avoid the warning | 14:44 |
jonathanmaw | okie doke, I'll try that out | 14:45 |
*** solid_black has quit IRC | 14:49 | |
gitlab-br-bot | buildstream: issue #596 ("Systems without FUSE can't use workspaces") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/596 | 15:00 |
qinusty | tristan, how can I test the notify functionality still works if I've had to shift some things for my patch? | 15:01 |
cs-shadow | tristan: yes, I think allowing the images to access the internet should probably be fine and will help us with testing changes like this. The teststuite images should still get updated after the change lands and for the next runs, it shouldn't download the extra artifacts | 15:08 |
cs-shadow | tristan: the only thing to consider here is that this approach only works best when we pin all dependencies, otherwise setuptools will try to fetch the latest versions | 15:09 |
* qinusty is slightly bored of having to find and remove .pyc files every time he tests. | 15:10 | |
coldtom | use .gitignore? | 15:11 |
qinusty | How can I prevent these __pycache__ files causing me issues? There must be something I'm doing wrong workflow wise | 15:11 |
qinusty | Nah it's not git | 15:11 |
qinusty | It's running pytest | 15:11 |
coldtom | alias ./setup.py test to ./setup.py test && rm -rf __pycache__ :P | 15:11 |
qinusty | urghhhh | 15:12 |
qinusty | There must be a more elegant solution, I can't be the only one with this issue. It must be something I'm doing wrong | 15:12 |
gitlab-br-bot | buildstream: merge request (valentindavid/extract-expiry->master: WIP: Remove artifact extracts when artifact expires in cache) #685 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/685 | 15:23 |
gitlab-br-bot | buildstream: issue #484 ("Artifact cache expiry relies on granular mtimes") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/484 | 15:27 |
gitlab-br-bot | buildstream: merge request (jonathan/cascache-cell-var-from-loop->master: WIP: Jonathan/cascache cell var from loop) #686 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/686 | 15:32 |
gitlab-br-bot | buildstream: merge request (jonathan/cascache-cell-var-from-loop->master: Jonathan/cascache cell var from loop) #686 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/686 | 15:32 |
gitlab-br-bot | buildstream: merge request (valentindavid/extract-expiry->master: WIP: Remove artifact extracts when artifact expires in cache) #685 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/685 | 15:37 |
gitlab-br-bot | buildstream: merge request (valentindavid/extract-expiry->master: Remove artifact extracts when artifact expires in cache) #685 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/685 | 15:37 |
*** toscalix has quit IRC | 15:37 | |
*** toscalix has joined #buildstream | 15:37 | |
gitlab-br-bot | buildstream: merge request (valentindavid/fix-broken-indentation-after-track->master: Fix broken indentation after track) #622 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/622 | 15:38 |
*** CTtpollard is now known as tpollard | 15:39 | |
*** bochecha has quit IRC | 15:40 | |
gitlab-br-bot | buildstream: merge request (valentindavid/fix-broken-indentation-after-track-1.2->bst-1.2: Fix broken indentation after track) #687 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/687 | 15:42 |
*** dtf has joined #buildstream | 15:54 | |
*** dtf has joined #buildstream | 15:56 | |
gitlab-br-bot | buildstream: merge request (coldtom/autotools-libtool->master: Upstream freedesktop-sdk autotools config) #683 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/683 | 16:10 |
tlsa | is there a way to get a shell prompt in the sandbox of a successfully built element? | 16:17 |
tlsa | similar to the one that's offered when it fails | 16:17 |
tpollard | tlsa: yep, bst shell $element should put you into a shell prompt for the element | 16:20 |
tpollard | -b if you want to stage build dependencies & the workspace for the element if you have one open | 16:21 |
*** WSalmon_ is now known as WSalmon | 16:21 | |
WSalmon | umm also --build might be it | 16:21 |
tlsa | tpollard: cool, thanks! Will that stage also what it built e.g. all the .o files it compliled when it succeded, or will I need to run a build from scratch in there? | 16:23 |
tpollard | tlsa: currently it won't, but it's one proposal that is currently being tracked | 16:24 |
tlsa | ah, cool | 16:24 |
tlsa | it would be helpful for fiddling with a kernel build | 16:25 |
WSalmon | if you want all that stuff then currently you could use a workspace | 16:26 |
*** leopi has joined #buildstream | 16:26 | |
gitlab-br-bot | buildstream: merge request (jonathan/cache-cache-size->master: Jonathan/cache cache size) #679 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/679 | 16:27 |
WSalmon | it should also help with rebuild times as it can reuse all the .a .o's etc | 16:27 |
tlsa | bsp workspace open <element> <dir>? | 16:27 |
WSalmon | yep | 16:28 |
WSalmon | it will then mirror your build directory but it dosent work retrospectively, you have to have set it up before you build | 16:28 |
tlsa | oh, ok | 16:29 |
tristan | qinusty, what I usually do (except it will delete any unstaged files), is `git clean -xdff` | 16:29 |
tristan | cs-shadow, sounds sensible; I think though we may want to do a separate step for the dev-requirements.txt and allow internet access only there | 16:30 |
tristan | cs-shadow, because with the non-dev requirements; we need to be a bit more flexible for the sake of distros | 16:30 |
tlsa | during a `bst build` is there any interactivity supported? E.g. can I type something to show the live log for <element>? | 16:30 |
qinusty | I mean, "find . -name \*.pyc -delete" does the job tristan, but I just find it strange that this is such an issue. Surely pytest is mature enough that this sort of thing is avoidable | 16:30 |
tristan | qinusty, it's normally not an issue I think, it rather only becomes an issue when files are added/removed | 16:31 |
tristan | qinusty, but still, running tests on a 'clean slate' is usually a good thing to do | 16:31 |
gitlab-br-bot | buildstream: merge request (jonathan/cascache-cell-var-from-loop->master: Jonathan/cascache cell var from loop) #686 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/686 | 16:34 |
WSalmon | tlsa not that i know | 16:35 |
tlsa | ok | 16:35 |
WSalmon | often its making lots of stuff at the same time... | 16:35 |
WSalmon | the workspace should change as things get build so you might be able to get a idea of things from that.. but its not the best. | 16:36 |
cs-shadow | tristan: that makes sense to me. We'll have to figure out how to carry around the installed deps (probably leveraging PYTHONPATH) but that shouldn't be too bad. | 16:41 |
cs-shadow | I'll try to put in a fix for this later today (or tomorrow in the worst case) unless anyone beats me to it :) | 16:41 |
gitlab-br-bot | buildstream: merge request (Qinusty/message-helpers->master: Continued work on improving BuildStream messaging API) #670 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/670 | 16:48 |
gitlab-br-bot | buildstream: merge request (Qinusty/message-helpers->master: Continued work on improving BuildStream messaging API) #670 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/670 | 16:49 |
*** awacheux[m] has quit IRC | 16:49 | |
*** oknf[m] has quit IRC | 16:49 | |
*** m_22[m] has quit IRC | 16:49 | |
*** pro[m] has quit IRC | 16:49 | |
*** waltervargas[m] has quit IRC | 16:49 | |
*** dineshdb[m] has quit IRC | 16:49 | |
*** krichter[m] has quit IRC | 16:49 | |
*** theawless[m] has quit IRC | 16:49 | |
*** mattiasb has quit IRC | 16:49 | |
*** doras[m] has quit IRC | 16:49 | |
*** segfault3[m] has quit IRC | 16:49 | |
*** ptomato[m] has quit IRC | 16:49 | |
*** connorshea[m] has quit IRC | 16:49 | |
*** cgmcintyre[m] has quit IRC | 16:49 | |
*** inigomartinez has quit IRC | 16:49 | |
*** albfan[m] has quit IRC | 16:50 | |
*** ssssam[m] has quit IRC | 16:50 | |
*** abderrahim[m] has quit IRC | 16:50 | |
*** kailueke[m] has quit IRC | 16:50 | |
*** rafaelff[m] has quit IRC | 16:50 | |
*** Demos[m] has quit IRC | 16:50 | |
*** jjardon[m] has quit IRC | 16:50 | |
*** alatiera has quit IRC | 16:50 | |
*** asingh_[m] has quit IRC | 16:50 | |
*** theawless[m] has joined #buildstream | 16:59 | |
gitlab-br-bot | buildstream: merge request (valentindavid/fix-broken-indentation-after-track-1.2->bst-1.2: Fix broken indentation after track) #687 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/687 | 17:03 |
*** jonathanmaw_ has joined #buildstream | 17:26 | |
*** jonathanmaw has quit IRC | 17:27 | |
*** toscalix has quit IRC | 17:39 | |
gitlab-br-bot | buildstream: merge request (jonathan/cascache-cell-var-from-loop->master: Jonathan/cascache cell var from loop) #686 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/686 | 17:53 |
*** alatiera_ has quit IRC | 18:19 | |
*** toscalix has joined #buildstream | 18:24 | |
*** toscalix has quit IRC | 18:34 | |
*** rafaelff[m] has joined #buildstream | 18:45 | |
*** mattiasb has joined #buildstream | 18:45 | |
*** kailueke[m] has joined #buildstream | 18:45 | |
*** alatiera has joined #buildstream | 18:45 | |
*** doras[m] has joined #buildstream | 18:45 | |
*** albfan[m] has joined #buildstream | 18:45 | |
*** abderrahim[m] has joined #buildstream | 18:45 | |
*** asingh_[m] has joined #buildstream | 18:45 | |
*** ssssam[m] has joined #buildstream | 18:45 | |
*** awacheux[m] has joined #buildstream | 18:45 | |
*** waltervargas[m] has joined #buildstream | 18:45 | |
*** pro[m] has joined #buildstream | 18:45 | |
*** connorshea[m] has joined #buildstream | 18:45 | |
*** dineshdb[m] has joined #buildstream | 18:45 | |
*** oknf[m] has joined #buildstream | 18:45 | |
*** ptomato[m] has joined #buildstream | 18:45 | |
*** cgmcintyre[m] has joined #buildstream | 18:45 | |
*** inigomartinez has joined #buildstream | 18:45 | |
*** krichter[m] has joined #buildstream | 18:45 | |
*** jjardon[m] has joined #buildstream | 18:45 | |
*** segfault3[m] has joined #buildstream | 18:45 | |
*** m_22[m] has joined #buildstream | 18:46 | |
*** Demos[m] has joined #buildstream | 18:46 | |
*** rdale_ct has joined #buildstream | 18:51 | |
*** rdale has quit IRC | 18:53 | |
*** jonathanmaw_ has quit IRC | 19:54 | |
*** leopi has quit IRC | 21:11 | |
*** tristan has quit IRC | 21:15 | |
gitlab-br-bot | buildstream: merge request (Qinusty/message-helpers->master: Continued work on improving BuildStream messaging API) #670 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/670 | 21:46 |
*** rdale_ct has quit IRC | 22:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!