| *** mcatanzaro has joined #buildstream | 00:16 | |
| *** mcatanzaro has quit IRC | 03:04 | |
| *** Prince781 has joined #buildstream | 03:23 | |
| *** Prince781 has quit IRC | 04:31 | |
| *** valentind has joined #buildstream | 06:57 | |
| *** valentind has quit IRC | 07:22 | |
| *** dominic has joined #buildstream | 08:30 | |
| *** dominic has quit IRC | 08:31 | |
| *** juergbi has quit IRC | 08:49 | |
| *** juergbi has joined #buildstream | 08:53 | |
| *** toscalix has joined #buildstream | 08:55 | |
| *** tristan has quit IRC | 09:19 | |
| *** tristan has joined #buildstream | 09:23 | |
| *** dominic has joined #buildstream | 09:24 | |
| tlater | Ah, juergbi, about classmethods, the `cls` there refers to the class that this function is part of | 09:38 |
|---|---|---|
| tlater | I.e., if you inherit from a class that implements one of these class methods | 09:38 |
| tlater | Your new class will be able to refer to itself through `cls` | 09:38 |
| juergbi | i'm missing the context | 09:39 |
| juergbi | when did we talk about classmethods? | 09:39 |
| tlater | Rather than pointing to its parent, which you'd usually get if you referred to it directly | 09:39 |
| tlater | juergbi: Yesterday, I was a bit late to this x) | 09:39 |
| juergbi | did you mean jennis/jmac? | 09:39 |
| tlater | Oh, sorry, yep | 09:39 |
| tlater | jennis in particular - silly autocomplete finger | 09:40 |
| *** jonathanmaw has joined #buildstream | 09:42 | |
| *** aday has joined #buildstream | 09:50 | |
| jennis | ahh thanks tlater | 09:56 |
| jennis | is @classmethod almost like a builtin decorator then? | 09:57 |
| tlater | jennis: It *is* a builting decorator :) | 09:57 |
| tlater | s/ing/in/ | 09:57 |
| jennis | So it looks to me as if we're replacing the ScriptWriter.get_args() function with our own slightly modified version? | 10:03 |
| jennis | ScriptWriter get_args(): https://github.com/pypa/setuptools/blob/master/setuptools/command/easy_install.py#L2093 | 10:03 |
| jennis | ours: https://gitlab.com/BuildStream/buildstream/blob/master/setup.py#L165 | 10:03 |
| tlater | jennis: Yep, that's exactly what's happening | 10:06 |
| * tlater assumes this came up because pylint can't figure this out and is giving you a warning | 10:06 | |
| tristan | jmac, have a moment ? | 10:30 |
| jmac | Not during standup | 10:30 |
| tristan | jmac, :) | 10:30 |
| jmac | 5 mins | 10:30 |
| *** aday has quit IRC | 10:31 | |
| tristan | Anyway I'll write... | 10:31 |
| tristan | jmac, so; regarding the sequence ID thing... I can understand that; in order to get benchmarking "off the ground" there will be some churn, which is fine and acceptable especially during unstable dev cycle | 10:32 |
| tristan | I am only a little concerned about the long term picture; the idea of sequence ID for a task, and another for a subtask seems very sensible; and while it may seem to be prematurely over-engineering a thing... in this case I just feel that some foresight can pay off | 10:34 |
| tristan | I just wanted to say a word about this since you are looking into it... the reason being; for a benchmarking suite; it is interesting to remain backward compatible; so that we can compare performance far back into history later on | 10:35 |
| jmac | I agree that main activtiy/subactivity ids are the right way to go | 10:35 |
| jmac | I'm not actively looking into it at the moment though | 10:36 |
| tristan | I can imagine say; that benchmarking will eventually "grow new things" which are not comparable with earlier versions of buildstream which dont time certain things | 10:36 |
| tristan | but it would be nice that the things we can benchmark from the beginning, are benchmarkable forever | 10:36 |
| tristan | jmac, understood :D | 10:36 |
| jmac | That would definitely be desirable, and that's why also codifying the activity names is a good plan | 10:37 |
| jmac | At the moment we don't really know what we want out of our benchmarks, so I'm throwing possible formats around | 10:38 |
| *** aday has joined #buildstream | 10:38 | |
| tristan | jmac, sure - I just wanted to point out that... in this scenario, a little over-engineering can have long term benefits :) | 10:39 |
| tristan | I think we're on the same page, though | 10:39 |
| tristan | (it's been sitting in the back of my mind for a while, just wanted to communicate it) | 10:40 |
| jmac | Thank you | 10:40 |
| Nexus | tristan, tlater i ran the last command that it seems to run (printing out the args and turning that into a bst command) | 10:42 |
| Nexus | and it works | 10:42 |
| tlater | Ah, interesting | 10:42 |
| Nexus | the build succeeded | 10:42 |
| tlater | Nexus: Have you checked what the test that runs *just before* our hanging test does? | 10:42 |
| * tlater suspects it might be messing with the environment | 10:43 | |
| tlater | I.e., try perhaps only running the hanging test with the test suite | 10:43 |
| Nexus | i have the build log on my screen if thats what you're talking about | 10:43 |
| tlater | Hm, no, not quite | 10:43 |
| tlater | You know when you run the whole suite with `sudo BST_FORCE_BACKEND=unix ./setup.py test --integration`? | 10:44 |
| * Nexus nods | 10:44 | |
| tlater | Eventually you end up with the hanging test we're trying to debug | 10:44 |
| tlater | What if the test that runs *just before* that test screws up everything? | 10:44 |
| Nexus | well then we're doomed | 10:45 |
| Nexus | DOOOOOMED | 10:45 |
| Nexus | i'll look into it | 10:45 |
| tristan | ./setup.py test --addargs 'path/of/failing/test::test_name' is interesting, so you know if it works when you *just run that test* | 10:45 |
| tlater | Nexus: It might be worth running: `sudo BST_FORCE_BACKEND=unix ./setup.py test --addopts '--integration tests/<whatever test is hanging>'` | 10:45 |
| tristan | right, like tlater says :) | 10:45 |
| * tlater seriously needs to write a little doc for these test invocations | 10:46 | |
| *** aday has quit IRC | 10:51 | |
| Nexus | seems to hang [tristan tlater] | 10:52 |
| gitlab-br-bot | buildstream: merge request (jmac/composition-docs-fix->master: Docs: Better explanation of defaults) #316 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/316 | 10:52 |
| tlater | :( | 10:52 |
| tlater | It's only running that test and no others? | 10:52 |
| Nexus | yup | 10:52 |
| *** aday has joined #buildstream | 10:55 | |
| tristan | juergbi, Say I have a loaded build graph... and there "are junctions in play", given an element in the graph: Can I get a list of the closest dependencies which cross a junction boundary ? | 10:58 |
| tristan | this would be very helpful in constructing a useful error message | 10:59 |
| juergbi | tristan: i don't think there is no code to determine that yet | 10:59 |
| tristan | I think you mean the opposite of what you said :D | 11:00 |
| tristan | but yeah, I suspected that much, just curious | 11:00 |
| * tristan wonders if we have something efficient for this... | 11:00 | |
| tristan | Element.dependencies() could be breadth first if recurse=False | 11:01 |
| tristan | or not necessarily even breadth first, just doing non-recursive loop could let me do it | 11:01 |
| tristan | juergbi, also, what would you use to detect that ? ... an element can *depend on an element across a junction boundary* as I understand it | 11:03 |
| tristan | juergbi, so what we have currently, is Plugin._get_project() + Project._junction ? | 11:04 |
| tristan | maybe a private direct accessor on the Element class would be nice ? | 11:04 |
| tristan | or maybe for this case, I just want to check `if dependency._get_project() is not search._get_project()` | 11:05 |
| juergbi | tristan: you can anyway directly compare project instances | 11:10 |
| juergbi | no need to compare the junction name | 11:10 |
| gitlab-br-bot | buildstream: merge request (jmac/composition-docs-fix->master: Docs: Better explanation of defaults) #316 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/316 | 11:12 |
| *** aday has quit IRC | 11:15 | |
| *** aday has joined #buildstream | 11:23 | |
| tristan | juergbi, yup, on it... I'm a bit slow today... went to dentist... scary | 11:33 |
| tristan | juergbi, at what point in _pipeline.py do I know that the pipeline is fully loaded ? I'm not seeing where junctions get added | 11:34 |
| tristan | Ah | 11:34 |
| tristan | juergbi, nice, you do it *all* in _loader.py it seems, that's convenient :) | 11:35 |
| * tristan starting to get the feel of junctions in the codebase | 11:35 | |
| tristan | looks like it might be nice to shove all Project() instantiation into Loader() | 11:37 |
| * tristan leaves things as is, though | 11:37 | |
| juergbi | i.e., move toplevel project creation to Loader? would mean CLI options have to be passed through somehow but it could make sense | 11:39 |
| tristan | Just seeing as the Loader() now creates projects... things are getting "biggish", would be desirable to streamline more | 11:40 |
| tristan | not sure exactly it makes the most sense | 11:40 |
| juergbi | may be worth looking into, yes. top-level project is currently created very early and not in a single place, so would be a slightly wider change | 11:42 |
| tristan | Ok this is weird, I should fix this... | 11:49 |
| tristan | CLI -> App -> Pipeline: Initialization is confusing with regards to elements, except_, and track_elements | 11:50 |
| tristan | really; so what is except_ when you initialize a pipeline now ? | 11:50 |
| *** aday has quit IRC | 12:04 | |
| *** aday has joined #buildstream | 12:07 | |
| tristan | tlater, jennis... just curiously; does your linting work cover mutable default function arguments ? | 12:30 |
| tlater | tristan: Yes! | 12:31 |
| tristan | Nice :) | 12:31 |
| * tlater thinks jennis also refactored a few of the ones that sneaked into the repo | 12:31 | |
| * tristan just discovered except_=tuple() in main.py | 12:31 | |
| tristan | probably one of them | 12:31 |
| tristan | they are easy to forget | 12:32 |
| juergbi | those are actually still in the pylint branch, hm | 12:36 |
| juergbi | tuples are immutable and thus it's not a dangerous default value? | 12:36 |
| tristan | Ah, I didnt realize they are immutable | 12:37 |
| tristan | not mutable, not dangerous | 12:37 |
| jennis | Yes it didn't come up through the linting, many default assignments such as foo=[] were changed | 12:40 |
| jennis | So I suspect juergbi is right | 12:40 |
| tristan | https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences | 12:45 |
| tristan | below example: "Tuples are immutable, and usually contain a heterogeneous sequence of elements that ... bla bla" | 12:45 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 12:48 |
| jennis | juergbi, I've pushed the branch ^ | 12:48 |
| tristan | juergbi, we may need an overhaul of where element.name is used, but element._get_full_name() should be used instead | 12:49 |
| jennis | please could you review it | 12:49 |
| jennis | Tristan, we also have a element.normal_name variable | 12:50 |
| tristan | jennis, I think we recently decided basically that that should be trashed | 12:51 |
| juergbi | yes, should revisit that | 12:51 |
| juergbi | jennis: ta, will take a look | 12:51 |
| *** mcatanzaro has joined #buildstream | 12:52 | |
| * tristan takes a short list of things he wants to get to refactoring pronto | 12:52 | |
| juergbi | jennis: has pylint problems dealing with += or what was that about? | 12:56 |
| tlater | juergbi: Pylint uses heuristics to try and guess the type of some variables | 12:58 |
| tlater | Those heuristics fail in that specific location... | 12:59 |
| juergbi | looks like quite an odd failure but wel | 12:59 |
| juergbi | *well | 12:59 |
| tlater | jennis said he'd raise an issue on their repo about it | 12:59 |
| juergbi | that sounds good | 12:59 |
| juergbi | what happens inside list comprehension should be unrelated to the thing outside list comprehension (except for used variables) | 13:00 |
| tlater | Pylint occasionally tries to guess types for variables based on how you use them - if it can't find the corresponding class definition | 13:01 |
| tlater | I think it's something about += to a string | 13:01 |
| juergbi | i would prefer conservative heuristic | 13:01 |
| juergbi | false positives are bad for warning tools like that, imo | 13:02 |
| * tlater agrees | 13:02 | |
| tlater | I think we can set the "confidence" level, but I'm not sure how much it actually affects | 13:02 |
| tlater | jennis: Do you know if we can blanket disable type guessing? | 13:02 |
| * tlater doesn't quite remember what the config allowed | 13:03 | |
| juergbi | ah. the situation is not really bad right now, i'm not opposed to keeping it as is. i was just wondering | 13:03 |
| juergbi | (i'm also not opposed to further tuning, of course, but can also do this later) | 13:04 |
| tlater | Yeah, the config is pretty well-tuned at this point :) | 13:04 |
| tlater | Is it just me or are the (non-integration) tests much slower these days? | 13:06 |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 13:11 |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 13:12 |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 13:12 |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 13:15 |
| tristan | tlater, I think there are more of them | 13:19 |
| tlater | That does make sense | 13:20 |
| juergbi | hm, duplicated comment in gitlab :/ | 13:22 |
| *** tristan has quit IRC | 13:24 | |
| tlater | Gah, looks like gitlab isn't running CI properly atm | 13:24 |
| tlater | 10 minutes to start pulling a docker image :| | 13:25 |
| *** tristan has joined #buildstream | 13:28 | |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 13:45 |
| jennis | tlater I'm not sure off the top of my head | 14:03 |
| jennis | Would've thought that whereever you read this: <tlater> Pylint occasionally tries to guess types for variables based on how you use them - if it can't find the corresponding class definition. It would have said | 14:04 |
| jennis | assuming you read that somewhere ;P | 14:04 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 14:08 |
| tlater | jennis: That was a blog post iirc, they didn't mention how to disable this. | 14:10 |
| Nexus | Is anyone against the use of `arpy` for dealing with the dpkg plugin? | 14:36 |
| gitlab-br-bot | buildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/317 | 14:47 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: WIP: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 14:57 |
| jmac | Can anyone point me at the bits in the code which cause element keys to inherit from project config? | 15:04 |
| gitlab-br-bot | buildstream: issue #214 ("We need a way to make elements depend on a subset of an element's output") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/214 | 15:06 |
| jmac | Ok, think I found it, n/m | 15:13 |
| gitlab-br-bot | buildstream: merge request (change_the_location_of_generate-base.sh->master: Changed the location of generate-base.sh) #307 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/307 | 15:19 |
| gitlab-br-bot | buildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/317 | 15:25 |
| ltu | jennis, how come https://gitlab.com/BuildStream/buildstream/merge_requests/307 was closed? | 15:29 |
| ltu | i wonder if we should make a note on the MR for provenance | 15:29 |
| jennis | It was just a very small change that juerg didn't think was necessary | 15:29 |
| jennis | juergbi, at the top of the cli file I disabled redefined-outer-name warnings for the whole file. I think I did this before because I didn't realise that you also had to modify the arguments of the click decorator (otherwise it fails most of the tests) | 15:38 |
| jennis | So I've disabled it and will change the "track", "build" and "workspace" so we're consistent | 15:39 |
| jennis | unless you disagree? | 15:39 |
| *** valentind has joined #buildstream | 15:57 | |
| milloni | is Nexus around? | 16:01 |
| Nexus | milloni: o/ | 16:02 |
| milloni | Nexus, could you please do git branch --contains 10fa1b4ec2ac5205230397b63d5652d7db2bb268 | 16:02 |
| milloni | on your fork of buildstream | 16:02 |
| Nexus | of modandtest? | 16:03 |
| milloni | it will check all branches | 16:03 |
| Nexus | no such commit 10fa1b4ec2ac5205230397b63d5652d7db2bb268 | 16:04 |
| milloni | ok | 16:04 |
| milloni | i could not build the docs on modAndTest | 16:04 |
| milloni | but I could do that on that branch rebased off of master on upstream | 16:04 |
| Nexus | hmm | 16:05 |
| Nexus | ah, thats from the main repo | 16:06 |
| Nexus | not my fork | 16:06 |
| milloni | Nexus, were you building docs from the fork or main repo? | 16:08 |
| Nexus | fork | 16:08 |
| milloni | ok | 16:08 |
| milloni | it mightve changed anyway commit shas actually | 16:08 |
| milloni | anyway it builds if you include all commits from master | 16:09 |
| milloni | so that's that | 16:09 |
| Nexus | i just built the docs in a containter, and they still build needing only sphinx and sphinxclick | 16:09 |
| milloni | but sphinx parses the source code of buildstream doesn't it? | 16:09 |
| milloni | the error is when parsing the source code, not the docs that you've written | 16:10 |
| Nexus | this issue is that your docs are referencing code that does not exist | 16:10 |
| milloni | so the source code from the snapshot on modAndTest doesn't parse well, but updated source code from master does | 16:10 |
| Nexus | tlater, jonathanmaw have either of you got any thoughts on this? | 16:11 |
| milloni | these are autogenerated from .rtf from the source code | 16:11 |
| milloni | they're not written by a human | 16:11 |
| Nexus | what was the error you got again? | 16:12 |
| jennis | These two functions `msg_byteorder` and `sys_byteorder` both have eachother as arguments. Is this intentional? Doesn't seem right to me | 16:17 |
| jennis | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_artifactcache/pushreceive.py#L63 | 16:17 |
| milloni | Nexus, https://paste.codethink.co.uk/?4181 | 16:18 |
| juergbi | jennis: it looks indeed a bit odd | 16:21 |
| jennis | I've changed it so that the arguments do not have the other function named and running the tests now | 16:22 |
| *** xjuan has joined #buildstream | 16:26 | |
| jonathanmaw | milloni: Do I understand correctly that you're using commit "98eb7381c8713157b549b6b18e07a3ffab987b69" from repo "git@gitlab.com:knownexus/buildstream.git", and when building the documentation for buildstream/sandbox/sandbox.py, you're getting an error message over the use of the label "sandboxing" | 16:27 |
| jonathanmaw | is that correct? | 16:27 |
| milloni | jonathanmaw, 98eb7381c8713157b549b6b18e07a3ffab987b69 from https://gitlab.com/knownexus/buildstream | 16:30 |
| milloni | running | 16:30 |
| milloni | make | 16:30 |
| milloni | from doc | 16:30 |
| *** toscalix has quit IRC | 16:31 | |
| jonathanmaw | milloni: hrm, I can't repeat your issue. Does it keep happening even if you do `git clean -dfx` from the "doc/" directory? | 16:38 |
| juergbi | jennis: possibly better understandable function declarations are python_to_msg_byteorder(python_byteorder) and msg_to_python_byteorder(msg_byteorder) | 16:39 |
| jennis | Yes jmac has suggested that | 16:43 |
| jennis | I will make the changes | 16:43 |
| jennis | These functions are only used once each afaics | 16:44 |
| jennis | juergbi, do you think this should be done in a separate commit or within the "dealt with redefined outername" commit? | 16:46 |
| juergbi | a separate commit could make sense but it's fine with me either way | 16:47 |
| gitlab-br-bot | buildstream: merge request (214-filter-workspacing->master: WIP: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/317 | 16:49 |
| milloni | jonathanmaw, yes | 16:50 |
| jonathanmaw | milloni: hrm, can you show me the output of `git cat-file -p 98eb7381c8713157b549b6b18e07a3ffab987b69^{tree}` please? | 16:54 |
| jonathanmaw | cache key collision is unlikely, but I'd like to rule it out | 16:55 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 17:10 |
| jennis | juergbi, I've made all the changes you've suggested and a few more | 17:10 |
| jennis | One thing to note, there was one redefined builtin I could not seem to fix, wonder if you could take a look? | 17:11 |
| * jennis finds the right link | 17:11 | |
| jennis | https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/utils.py#L825 | 17:11 |
| jennis | juergbi ^^ that's from the main repo, on my branch I've disabled the redefined builtin warning | 17:12 |
| juergbi | ah, python standard library itself wouldn't pass that checker... | 17:14 |
| juergbi | i don't think we can really do anything else about this | 17:15 |
| jennis | Please could you expand? | 17:16 |
| jennis | Because if it's to do with the decorator, the pylintrc file addresses contextmanager-decorators | 17:17 |
| juergbi | tempfile.mkdtemp() accepts a `dir` keyword argument | 17:17 |
| juergbi | that's part of the python standard library, not defined by us | 17:17 |
| juergbi | that's assuming it's about dir. or do you see it contextmanager-related? | 17:17 |
| jennis | https://gitlab.com/jennis/buildstream/blob/239-use-pylint-for-linting/.pylintrc#L168 | 17:18 |
| jennis | ahh no it is about dir | 17:18 |
| jennis | just a coincidence that it's using that decorator as I remember seeing that in the pylintrc file | 17:19 |
| *** dominic has quit IRC | 17:19 | |
| milloni | jonathanmaw, https://paste.codethink.co.uk/?4182 | 17:21 |
| juergbi | jennis: we could possibly change our parameter but still use dir= for the standard library call. however, i think in this case it's better to be consistent with the python standard library and have the pylint disable | 17:22 |
| jennis | juergbi: Ok, I agree | 17:23 |
| jonathanmaw | milloni: hrm, that matches what I had. What does `git status --ignored` say when called from the root of the repository? | 17:26 |
| juergbi | jennis: gitlab is not responding, so here my last comment: You're now adding the `Lock` import in "pylint - dealt with import warnings" and then removing it in a separate commit. That doesn't make sense. Please remove it from the former commit, i.e., squash the two together. | 17:27 |
| juergbi | (the import doesn't exist in master anymore) | 17:28 |
| jennis | mhmm I'll just reset to the penultimate commit | 17:28 |
| jennis | not sure where it would have been added | 17:28 |
| juergbi | in an earlier version you moved the import to a different place. in master the import was removed. in your rebase to master, the reordering (removed line and added line) became an added import line | 17:30 |
| jennis | I see | 17:30 |
| juergbi | it's just a small rebase fallout | 17:30 |
| jennis | all done (: | 17:31 |
| juergbi | i'm surprised that there is no unused import warning when running pylint on that earlier commit | 17:31 |
| jennis | juergbi ^ | 17:31 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 17:31 |
| jennis | Did you just run pylint on that commit? | 17:32 |
| juergbi | ta | 17:32 |
| juergbi | yes | 17:32 |
| jennis | mhm | 17:32 |
| jennis | that is odd | 17:32 |
| jennis | aha | 17:33 |
| jennis | there is still a section messages we would like to enable at some point in the pylintrc file | 17:33 |
| jennis | so unused import is actually disabled | 17:33 |
| jonathanmaw | milloni: I've got to go now. If you post your results I'll check them in the IRC logs when I get back. | 17:34 |
| milloni | thanks jonathanmaw | 17:35 |
| jennis | juergbi, should I go through these? | 17:35 |
| juergbi | jennis: ah, didn't realize that | 17:35 |
| juergbi | i'd say let's first merge what we have | 17:35 |
| *** jonathanmaw has quit IRC | 17:35 | |
| jennis | ok | 17:35 |
| juergbi | i'm trying to fetch from gitlab, but it's acting up :/ | 17:35 |
| jennis | yes it's being v slow for me | 17:36 |
| gitlab-br-bot | buildstream: issue #239 ("Use pylint for linting") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/239 | 17:54 |
| gitlab-br-bot | buildstream: merge request (239-use-pylint-for-linting->master: Resolve "Use pylint for linting") #283 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/283 | 17:54 |
| gitlab-br-bot | buildstream: merge request (jmac/build-uid-2->master: WIP: Sandbox configuration key to specify uid/gid for sandbox) #318 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/318 | 18:08 |
| gitlab-br-bot | buildstream: merge request (jmac/build-uid->master: WIP: Specify custom UID for build sandbox in elements) #301 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/301 | 18:08 |
| *** tiago has quit IRC | 18:28 | |
| *** toscalix has joined #buildstream | 19:30 | |
| *** toscalix has quit IRC | 19:34 | |
| *** xjuan has quit IRC | 20:25 | |
| *** mcatanzaro has quit IRC | 22:50 | |
| *** valentind has quit IRC | 22:59 | |
| *** aday has quit IRC | 23:39 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!