| *** sstriker has quit IRC | 00:12 | |
| *** Prince781 has quit IRC | 00:20 | |
| *** Prince781 has joined #buildstream | 00:58 | |
| *** mcatanzaro has quit IRC | 01:18 | |
| *** tristan has joined #buildstream | 07:00 | |
| *** Prince781 has quit IRC | 07:09 | |
| *** i0d3l4y has joined #buildstream | 07:16 | |
| *** noisecell has joined #buildstream | 07:36 | |
| *** i0d3l4y has quit IRC | 08:16 | |
| *** aiden has left #buildstream | 09:13 | |
| *** aiden has joined #buildstream | 09:13 | |
| *** valentind has joined #buildstream | 09:21 | |
| jennis | juergbi, tlater were you referring to using this to deal with dir_? | 09:24 |
|---|---|---|
| jennis | https://github.com/PyCQA/pylint/blob/master/pylint/extensions/bad_builtin.py | 09:24 |
| tlater | Yep | 09:24 |
| tlater | We should probably use that in general | 09:24 |
| tlater | It seems it was mostly disabled because too many people didn't understand why you shouldn't use certain builtins | 09:25 |
| tlater | skullman: I suspect you haven't enabled CI on your buildstream fork: https://gitlab.com/BuildStream/buildstream/merge_requests/312 | 09:37 |
| skullman | tlater: having a look | 09:40 |
| tristan | skullman, did you request developer access ? I recommend working on the main repo directly, it's less hassle than a fork | 09:43 |
| skullman | tristan: it was pretty late by the time I got around to it and assumed nobody would respond. Is that a button on GitLab I can press or something? | 09:45 |
| tristan | yeah, hold on... | 09:49 |
| skullman | ah, I hadn't noticed the button since I wasn't logged in when I loaded the page | 09:50 |
| tristan | ah you found it :) | 09:50 |
| tristan | faster than me | 09:50 |
| tristan | policy is just accept developer access; as it's non-destructive | 09:51 |
| skullman | ah cool | 09:51 |
| * tlater wonders if MRs can be migrated to new branches | 09:51 | |
| tristan | new policy should be, prefix your branch names with user name; I'm going to follow that too now since we're more active than before | 09:51 |
| tristan | tlater, probably not worth worrying about; if it's a long standing MR just create a new one to obsolete the old | 09:52 |
| skullman | I tend to put my name on my branches anyway. While you're around. I noticed there's provenance tracking in the data structures. Should I be adding some provenance data for new fields? | 09:52 |
| tristan | skullman, that is entirely automated by _yaml module at load time | 09:53 |
| tristan | The Provenance objects is just filename/line/column info | 09:53 |
| skullman | I meant fields added to those structures. e.g. the dict was a yaml document that was loaded, but I add a new field, should I try to add something to say it came from somewhere else, pretend that it came from the same file but without a line or column, or just leave it without any provenance for that field? | 09:54 |
| tristan | In what case do you need to do this ? | 09:55 |
| *** slaf- has joined #buildstream | 09:55 | |
| tristan | skullman, most likely answer is going to be just leave it without | 09:56 |
| skullman | tristan: adding a new version field to a loaded dict. | 09:56 |
| *** slaf- has joined #buildstream | 09:56 | |
| tristan | Just leave it, then | 09:56 |
| skullman | ok, none of the tests have complained about them missing, I'm just worried because I'm not familiar enough with the code to know if it'll cause bugs elsewhere | 09:57 |
| tristan | skullman, the provenance is only useful for reporting errors about things which were loaded | 09:57 |
| tristan | i.e. the node_get() family of functions will use it to make better errors | 09:57 |
| *** slaf has quit IRC | 09:57 | |
| *** slaf- is now known as slaf | 09:57 | |
| tlater | Hm, I wonder how frequently we should change workspace.yml versions | 10:06 |
| tlater | I think we have 3 version changes that will happen basically in the same week | 10:07 |
| tlater | Is there any way we could better coordinate this? | 10:07 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: WIP: Add versioning to workspaces yaml configuration) #313 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/313 | 10:08 |
| gitlab-br-bot | buildstream: merge request (richardmaw-271-workspaces-versioning->master: WIP: Add versioning to workspaces yaml configuration) #312 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/312 | 10:09 |
| tristan | tlater, I am very, very not fussed about that version being incremented with every change | 10:11 |
| tristan | tlater, I would say, if three version changes happen in one week; ok I dont care... if they only change once in that week, sure... as the first patch, or the last one; I also dont care | 10:12 |
| tristan | That version check is: If you have a BuildStream installation one day and open a workspace... and then another day; you *downgrade* buildstream... or say a year later you install an older version of buildstream... | 10:13 |
| tristan | Then instead of exploding, it tells you that your local state .bst/workspaces.yml file requires a newer version of BuildStream | 10:13 |
| * tlater wasn't sure if anything might break with updates | 10:13 | |
| tlater | But I really can't think of a scenario | 10:14 |
| tristan | no, workspaces.yml is internally managed user local state, it's not like project format that way | 10:14 |
| tristan | you can't pull an update of your project and then have a problem | 10:15 |
| * tlater boldly changes version to "2" on his branch then | 10:15 | |
| *** dominic has joined #buildstream | 10:15 | |
| tristan | I honestly would have been okay with an unversioned thing; others had a nitpick on that so lets do it | 10:16 |
| tlater | Hm, I am starting to wonder if a separate class would be better for workspaces. It looks like Project will gain a handful of methods every time we change the workspace format. | 10:19 |
| tristan | tlater, I suggested that yes | 10:20 |
| tristan | I dont mind the patch either way for now, but as it grows, that's exactly what we should do | 10:20 |
| *** ernestask has joined #buildstream | 10:25 | |
| 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 | 10:59 |
| gitlab-br-bot | buildstream: merge request (tristan/project-refs->master: WIP: Optionally load and store source references in project.refs) #314 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/314 | 11:02 |
| *** valentind has quit IRC | 11:06 | |
| gitlab-br-bot | buildstream: merge request (issue-89_unique_build_dirs->master: WIP: Made modification to generate unique subdirs for built elements) #310 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 11:14 |
| tlater | Nexus: Let's go through updating host tools here | 11:18 |
| tlater | Currently the CI uses this image: https://gitlab.com/BuildStream/buildstream/blob/master/.gitlab-ci.yml#L1 | 11:19 |
| tlater | The source for it lives here: https://gitlab.com/BuildStream/buildstream-docker-images/tree/master/fedora | 11:19 |
| tlater | What you'll need to do is add installing your host tool (dpkg I think) to that image | 11:20 |
| tlater | If you push to buildstream-docker-images/master it will automatically build and push the new image to dockerhub | 11:21 |
| tlater | After that you only need to update .gitlab-ci.yml to refer to your new tag | 11:21 |
| tlater | Nexus: You might want to take up whether this is actually required in master with tristan first though, I'm not sure why we would have dpkg as a hard buildstream dependency. | 11:23 |
| Nexus | tlater: due to the dpkg plugin | 11:23 |
| Nexus | it's the cleanest way to have it, without writing my own dpkg in python, which is no better | 11:24 |
| tristan | tlater, it sounds better suited to bst-external, but in either case it will not be a hard dependency | 11:24 |
| tristan | tlater, we have preflight stage to tell the user they need host tools if their project needs them | 11:25 |
| tlater | Ah, alright | 11:25 |
| tlater | I've been thinking of anything in the docker image as a hard dependency, but I suppose the CI needs even these kinds of tools. | 11:26 |
| tristan | the CI needs to test everything yeah | 11:26 |
| 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 | 11:27 |
| *** tristan has quit IRC | 11:31 | |
| *** tristan has joined #buildstream | 11:50 | |
| tlater | Hm, there's no nice way to access artifact metadata for a given key yet, is there? | 11:58 |
| *** Prince781 has joined #buildstream | 13:42 | |
| *** Prince781 has quit IRC | 14:02 | |
| *** Prince781 has joined #buildstream | 14:06 | |
| milloni | hello | 14:10 |
| milloni | I've been wanting to get into buildstream | 14:10 |
| milloni | in my free time, where do I start? | 14:10 |
| milloni | (as a developer) | 14:11 |
| milloni | are there any simple issues I could work at? | 14:12 |
| *** mcatanzaro has joined #buildstream | 14:14 | |
| tlater | o/ milloni | 14:18 |
| *** Prince781 has quit IRC | 14:19 | |
| *** Prince781 has joined #buildstream | 14:20 | |
| tlater | There are a ton of issues, quite a few simple, tristan can probably point out the fun ones. Still, some less fun ones I can see at a glance: | 14:21 |
| tlater | https://gitlab.com/BuildStream/buildstream/issues/257 https://gitlab.com/BuildStream/buildstream/issues/271 https://gitlab.com/BuildStream/buildstream/issues/288 https://gitlab.com/BuildStream/buildstream/issues/289 | 14:21 |
| tlater | milloni: That last one would probably be a massive improvement :) | 14:21 |
| Nexus | anyone know why i got an error saying "ERROR: Job failed: execution took longer than 3h0m0s seconds" | 14:24 |
| Nexus | inb4 the job took over 3h joke | 14:24 |
| tlater | Nexus: The job took over 3h | 14:25 |
| jjardon[m] | Nexus: what repo? | 14:25 |
| Nexus | jjardon[m]: https://gitlab.com/BuildStream/buildstream/merge_requests/310 | 14:25 |
| tlater | Nexus: "Duration: 180 minutes 4 seconds" | 14:26 |
| * Nexus slaps tlater | 14:26 | |
| tlater | For some reason your CI just took that long... Did you write a really convoluted test? | 14:26 |
| Nexus | i don't think so! | 14:26 |
| jjardon[m] | Nexus: CI is configured to fail after 180 minutes | 14:26 |
| tlater | It also sometimes happens that gitlab gitches a bit | 14:26 |
| jjardon[m] | Nexus: any idea why that job is taken more than normal? | 14:26 |
| milloni | thanks tlater | 14:26 |
| Nexus | but it passes fine on mine and takes ~10 | 14:27 |
| * Nexus runs it again | 14:27 | |
| *** Prince781 has quit IRC | 14:27 | |
| tlater | That might just solve it :) | 14:27 |
| tlater | Though do keep track of how long it takes, if it's anywhere near that long again you should take a closer look. | 14:27 |
| Nexus | yep | 14:27 |
| *** noisecell has quit IRC | 14:29 | |
| *** Prince781 has joined #buildstream | 14:31 | |
| milloni | tlater, in issue #289, what's a runtime in this context? | 14:36 |
| tlater | milloni: A sysroot, in essense | 14:36 |
| tlater | A buildstream project always needs a base sysroot, which is used to set up the initial sandbox | 14:36 |
| tlater | Anything else can be run from there | 14:36 |
| tlater | milloni: If you'd like to tackle that issue, it would probably make sense to try and set up a buildstream project from scratch first - Nexus can probably link some docs to help with that | 14:37 |
| Nexus | tlater: jjardon[m] looks like it stopped again | 14:38 |
| tlater | Nexus: Hrm, so it's an issue with that test case, hm | 14:39 |
| milloni | tlater, so do i understand correctly, there's a configuration option for setting up a runtime, but if you don't specify that option and try to run shell commands anyway, it won't complain that you didn't set that option | 14:39 |
| milloni | it will only say that /bin/sh is not available | 14:39 |
| tlater | milloni: That's the gist of the issue, yes | 14:39 |
| tlater | The configuration in this case is a buildstream element | 14:40 |
| Nexus | hmmmm | 14:40 |
| * Nexus has a secret thought | 14:40 | |
| tlater | Nexus: I think your docs would really help milloni here :) | 14:40 |
| Nexus | wut, | 14:40 |
| Nexus | which ones, whats going on? | 14:40 |
| milloni | Nexus, yes please | 14:40 |
| milloni | Nexus, do you have docs to set up a buildstream project? | 14:41 |
| Nexus | https://gitlab.com/BuildStream/buildstream/issues/169 | 14:41 |
| Nexus | install buildstream and build a project | 14:41 |
| Nexus | are linked in there | 14:41 |
| milloni | thanks Nexus | 14:41 |
| Nexus | np | 14:41 |
| tlater | milloni: This *is* the topic most starters struggle with initially, so shout if you get stuck | 14:42 |
| milloni | where are the docs for buildstream in general? | 14:42 |
| tlater | milloni: These are our reference docs: https://buildstream.gitlab.io/buildstream/ | 14:42 |
| tlater | We also have some gnome wiki pages, not sure where they are exactly | 14:43 |
| Nexus | you know what would be great?... if my docs got merged. | 14:43 |
| milloni | cool, I'll look into this over the weekend. thanks | 14:43 |
| tlater | :) | 14:43 |
| tlater | Nexus: Back to failing tests | 14:44 |
| tlater | Secret thoughts? | 14:44 |
| tlater | I can't see anything obvious about that test case, best guess is that that f.read() call somehow fails to terminate | 14:45 |
| *** noisecell has joined #buildstream | 14:45 | |
| jmac | Nexus: Is there an outstanding merge request? I can see !183 but that's closed. | 14:46 |
| Nexus | jmac: i think tristan cancelled it | 14:47 |
| tlater | It's kinda cute because your docs are still the best thing to link someone to | 14:47 |
| Nexus | oh wait | 14:47 |
| Nexus | https://gitlab.com/BuildStream/buildstream/merge_requests/206 https://gitlab.com/BuildStream/buildstream/merge_requests/236 https://gitlab.com/BuildStream/buildstream/merge_requests/237 https://gitlab.com/BuildStream/buildstream/merge_requests/238 | 14:48 |
| Nexus | all my docs | 14:48 |
| Nexus | tlater: ikr? | 14:48 |
| * jmac can't see any outstanding reason not to merge 206 | 14:50 | |
| Nexus | tristan: | 14:51 |
| *** Prince781 has quit IRC | 14:56 | |
| jmac | Hmm, I'm seeing source_dist take ages on gitlab now, might be the same thing Nexus had | 14:57 |
| Nexus | mine was `test_script_cwd` | 14:58 |
| tlater | jmac: That *might* be the case, but Nexus' tests hang on the same exact case | 14:58 |
| tlater | So I think it's only Nexus' branch | 14:58 |
| jmac | I have a merge request for the benchmarks repo, https://gitlab.com/BuildStream/benchmarks/merge_requests/2 | 15:10 |
| jmac | Any chance someone could take a look, maybe Nexus? Since jonathanmaw isn't here | 15:11 |
| jmac | Not urgent | 15:11 |
| Nexus | sure | 15:11 |
| jmac | Does anyone have any views on adding type annotations to python code in BuildStream? I'm quite keen on them as it makes it easier for me to read code, even if we never do any type-checking on them | 15:42 |
| tlater | jmac: I thought type annotations weren't supported in python3.4? | 15:43 |
| jmac | Function argument annotations are valid in Python 3.0 so far as I know | 15:43 |
| jmac | They have a more specific meaning in 3.4 | 15:43 |
| jmac | Sorry, 3.5 | 15:44 |
| * tlater would like having them, if only to make code completion handier | 15:45 | |
| Nexus | apparently typing was added in 3.5, according to https://docs.python.org/3/library/typing.html but i'm by no means an authority on it, just a casual googler of the matter | 15:45 |
| Nexus | *unrelated note* How hard would it be to update buildstream to the latest python/ | 15:46 |
| Nexus | ? | 15:46 |
| tlater | Nexus: It's already fully supported | 15:47 |
| Nexus | then why use 3.4? | 15:47 |
| tlater | Because some people run python3.4 | 15:47 |
| Nexus | ic | 15:47 |
| * juergbi likes type annotations | 15:47 | |
| tlater | Notably, the previous major version of debian (which we support) | 15:47 |
| tlater | If type annotations don't break 3.4 support they'd be a great addition I think, but for consistency we'd need someone to do a massive overhaul on our repo :/ | 15:48 |
| juergbi | i don't think we actually support jessie anymore but other distros might still be on 3.4 | 15:48 |
| * tlater has seen the doc comments get out of sync with actual types in places, too | 15:48 | |
| tlater | So a conversion tool probably wouldn't work | 15:49 |
| jmac | https://www.python.org/dev/peps/pep-3107/ was in 3.0, and that allows you to put anything you like in the annotation; the direct use of that to mean types only comes in in 3.5 | 15:49 |
| jmac | I don't think it's likely that we'll overhall the whole repo to add types everywhere | 15:49 |
| jmac | overhaul! | 15:50 |
| * tlater finds the idea of mixing styles ugly | 15:51 | |
| juergbi | maybe one file at a time? | 15:52 |
| jmac | That's a bit like saying you shouldn't add a comment unless you add comments on all functions | 15:52 |
| juergbi | well, we should be clear about whether we want them or not. having people write new code, some with and some without annotations, sounds bad | 15:53 |
| juergbi | and assuming we want them, the aim should definitely be to consistently add them to existing functions as well | 15:54 |
| juergbi | however, this could be done in multiple steps to make it more feasible | 15:54 |
| juergbi | tristan might want it in a single step, though | 15:55 |
| jmac | It does not sound bad to me | 15:55 |
| * tlater wonders if pylint has a way to enforce type hints | 15:56 | |
| juergbi | we have to be careful, there may be places where we accept multiple types (list or string) | 15:57 |
| jmac | Of course. | 15:57 |
| jmac | That in itself is a source of confusion, so all the more reason to make it explicit that we accept both | 15:58 |
| tlater | It would be great if we could also express whether set() is supported | 15:58 |
| Nexus | jmac: other than what i mentioned, no problems with what you've pushed up, just trying to test it locally now | 16:00 |
| jmac | Thanks Nexus | 16:01 |
| Nexus | it'd help if i wasn't looking in the buildstream main repo... | 16:11 |
| Nexus | is there even any kind of test for this? | 16:12 |
| jmac | For the feature I'm adding? No. | 16:13 |
| jmac | There's only one test for the repo at the moment, just to run the perf test with default settings and see if it exits with value 0 | 16:14 |
| *** mcatanzaro has quit IRC | 16:17 | |
| milloni | Nexus, links in https://gitlab.com/knownexus/buildstream/blob/buildproject/doc/source/buildproject.rst seem broken | 16:19 |
| *** mcatanzaro has joined #buildstream | 16:20 | |
| Nexus | milloni: sadly yes, it's intended for use when merged. The linked files are (for the most part)also in that repo under the appropriate branch names | 16:20 |
| milloni | ah, ok thanks | 16:20 |
| Nexus | np | 16:20 |
| Nexus | milloni: i think your best option is to clone the repo, build the docs and read them that way | 16:22 |
| Nexus | then all the links should work :) | 16:23 |
| milloni | good idea | 16:23 |
| Nexus | jmac: i see | 16:24 |
| Nexus | i have no idea how to do that | 16:24 |
| Nexus | does the perf laptop run those? | 16:24 |
| jmac | I suppose I should add some then | 16:24 |
| Nexus | if so has this been tested on it? | 16:24 |
| Nexus | :) | 16:25 |
| jmac | Nexus: The perf laptop isn't running anything at the moment. I've done all the tests using my desktop. | 16:25 |
| Nexus | kk | 16:25 |
| milloni | it seems sphinx is needed to build the docs, but is not listed as a dependency in setuptools? is that intentional? | 16:27 |
| Nexus | iirc it's because it's not a buildstream dependency, and the docs are only build for the site | 16:28 |
| jennis | If I want a project.conf that uses two different plugins, and each require a different `path:`, what's the solution for this? | 16:28 |
| jennis | Can you have two plugins:...? | 16:28 |
| Nexus | built* | 16:28 |
| Nexus | i think so | 16:28 |
| Nexus | you just put them one beneith the other | 16:29 |
| Nexus | oh dear god i can't spell | 16:29 |
| * Nexus quits english | 16:29 | |
| Nexus | beneath********* | 16:29 |
| jennis | lol | 16:29 |
| Nexus | (╯°□°）╯︵ɥʇɐǝuǝq | 16:29 |
| jennis | doesn't look like that's worked :o | 16:30 |
| * Nexus wanders over to jennis | 16:32 | |
| milloni | Nexus, https://pastebin.com/jSBbk86e | 16:44 |
| milloni | can't build docs from your branch, but I can from main branch | 16:44 |
| Nexus | interesting | 16:45 |
| Nexus | milloni: which branch was that? | 16:47 |
| Nexus | modandtest? | 16:48 |
| milloni | uhmmm actually | 16:48 |
| milloni | ok, so I never even changed the branch | 16:48 |
| Nexus | lol | 16:48 |
| Nexus | that's a relief, because i spent several hours removing all of those errors | 16:49 |
| milloni | Nexus, I'm on modAndTest and, still getting an error | 16:50 |
| Nexus | is ssssam[m] around? | 16:51 |
| *** schmorris has joined #buildstream | 16:52 | |
| Nexus | milloni: interesting, which error? | 16:52 |
| milloni | Nexus, https://pastebin.com/ZuetKF29 | 16:54 |
| milloni | I think it's the same error | 16:54 |
| Nexus | did you clean up the repo when you moved? | 16:56 |
| Nexus | if might be looking at a file that didn't exist at the time i wrote this | 16:57 |
| *** schmorris has quit IRC | 16:59 | |
| milloni | Nexus, I ran git clean -f -d | 17:02 |
| * Nexus usually runs git clean -dfx just to be sure but that's unlikely to change anything | 17:03 | |
| Nexus | how odd | 17:03 |
| Nexus | it builds on mine | 17:03 |
| milloni | cloned again into a separate dir to be sure, checkout'd modAndTest, ran make -C doc | 17:04 |
| milloni | still fails | 17:04 |
| Nexus | run `make` from the doc dir and see if it works | 17:05 |
| Nexus | but that worked for me too :/ | 17:05 |
| Nexus | commit 98eb7381c8713157b549b6b18e07a3ffab987b69 | 17:05 |
| Nexus | ? | 17:05 |
| milloni | didn't work from doc dir either | 17:06 |
| milloni | yes, that commit | 17:06 |
| *** valentind has joined #buildstream | 17:06 | |
| Nexus | milloni: can you do a `grep -rn . -e "sandboxing" for me pls and tell me what you find? | 17:10 |
| milloni | ./build/html/buildstream.sandbox.sandbox.html:40:<p>See also: <span class="xref std std-ref">sandboxing</span>.</p> | 17:11 |
| milloni | Binary file ./build/doctrees/buildstream.sandbox.sandbox.doctree matches | 17:11 |
| Nexus | i don't have that line in ./build/html/buildstream.sandbox.sandbox.html ._. | 17:12 |
| milloni | wat | 17:13 |
| Nexus | 40 <div class="bodywrapper"> | 17:13 |
| milloni | Nexus, `git remote get-url origin` gives https://gitlab.com/knownexus/buildstream | 17:15 |
| Nexus | i have that in master though... | 17:15 |
| milloni | git branch | 17:15 |
| milloni | modAndTest | 17:15 |
| Nexus | https://gitlab.com/knownexus/buildstream.git | 17:15 |
| Nexus | * modAndTest | 17:15 |
| Nexus | milloni: sandboxing is only in the current master, not in the repo you're using :p | 17:16 |
| milloni | current master on buildstream/buildstream? | 17:16 |
| Nexus | yes | 17:16 |
| milloni | wtf | 17:17 |
| Nexus | SOMEHOW it looks like you've merged the two | 17:17 |
| Nexus | milloni: do you have a sandboxing.rst file in your doc/source ? | 17:17 |
| milloni | Nexus, I don't have that file | 17:18 |
| Nexus | good, you shouldn't | 17:19 |
| Nexus | so why does it think you do | 17:19 |
| Nexus | hmm | 17:19 |
| Nexus | try downlodaing a tar of the repo and extracting it | 17:19 |
| Nexus | instead of using git | 17:19 |
| milloni | Nexus, before I do that | 17:24 |
| milloni | different sphinx versions? | 17:24 |
| Nexus | erm, what's the sphinx package called? | 17:24 |
| milloni | I installed from pip | 17:24 |
| milloni | do | 17:25 |
| milloni | python3 | 17:25 |
| milloni | import sphinx | 17:25 |
| milloni | sphinx.__version__ | 17:25 |
| Nexus | '1.6.5' | 17:25 |
| milloni | mine is 1.7.1 | 17:25 |
| milloni | that's probably what is causing this | 17:27 |
| Nexus | milloni: what package did you install? just pip install sphinx? | 17:27 |
| Nexus | pip3* | 17:27 |
| milloni | yes | 17:27 |
| milloni | you might have not upgraded in a while | 17:27 |
| Nexus | facinating | 17:27 |
| Nexus | i have multiple installed | 17:28 |
| milloni | heh | 17:28 |
| Nexus | i just uninstalled it and it still exists | 17:28 |
| milloni | that's probably because there's pip install --user | 17:28 |
| milloni | but there's no pip uninstall --user | 17:28 |
| *** dominic has quit IRC | 17:31 | |
| Nexus | ok, completely removed sphinx and reinstalling | 17:31 |
| Nexus | 1.7.1 | 17:32 |
| Nexus | build succeeded. | 17:32 |
| Nexus | :) | 17:32 |
| Nexus | milloni: it was a good theory :p | 17:32 |
| milloni | \o/ | 17:32 |
| milloni | oh | 17:32 |
| milloni | no :( | 17:32 |
| Nexus | lol | 17:33 |
| Nexus | tar idea? :) | 17:33 |
| Nexus | atleast i have the new sphinx :) | 17:33 |
| Nexus | so not a complete loss | 17:33 |
| milloni | do you think it might be possible taht you still have multiple sphinx versions? | 17:33 |
| * milloni downloads the tar | 17:33 | |
| Nexus | i tried importing sphinx after removing it manually and it failed | 17:34 |
| Nexus | any luck? | 17:40 |
| *** ernestask has quit IRC | 17:43 | |
| *** ernestask has joined #buildstream | 17:47 | |
| milloni | Nexus, nope | 17:47 |
| Nexus | https://goo.gl/pHPFVb | 17:48 |
| milloni | it looks like there must be a difference between my build env and yours | 17:48 |
| milloni | we've checked sphinx, let me see what else is involved | 17:49 |
| Nexus | that's literally the thing buildstream is trying to fix :P | 17:49 |
| milloni | you could build docs using buildstream... but how will you know how to use buildstream without the docs? | 17:49 |
| Nexus | you need to build buildstram using buildstream so you can read the docs to create a build | 17:49 |
| milloni | that too lol | 17:50 |
| milloni | well I mean people are using gcc to build gcc so that's not that crazy of an idea | 17:50 |
| Nexus | :D | 17:50 |
| Nexus | i'm afraid you may need more assistance than i can provide you atm :/ | 17:51 |
| Nexus | without actually seeing your local repo anyway | 17:51 |
| Nexus | have you tried diffing your pull and master? | 17:52 |
| Nexus | or your pull and my repo | 17:52 |
| milloni | Nexus, could you please do | 17:55 |
| milloni | pip3 install --upgrade sphinx-click | 17:56 |
| Nexus | 0upgraded | 17:56 |
| Nexus | build succeeded. | 17:56 |
| milloni | I know my modAndTest is rebased on top of master, but master hasn't been updated in a while | 17:56 |
| milloni | in that fork | 17:56 |
| Nexus | yes, it's very far behind master | 17:57 |
| Nexus | don't rebase | 17:57 |
| milloni | I didn't | 17:58 |
| Nexus | hmmmm | 17:58 |
| * Nexus is going for the day | 17:59 | |
| Nexus | best of luck, if you're still having this issue on monday, i'll get others involved | 17:59 |
| milloni | thanks | 18:00 |
| *** xjuan has joined #buildstream | 18:26 | |
| *** tiago has quit IRC | 18:39 | |
| *** toscalix has joined #buildstream | 20:32 | |
| *** ernestask has quit IRC | 20:35 | |
| *** xjuan has quit IRC | 21:20 | |
| *** toscalix has quit IRC | 21:32 | |
| *** noisecell has quit IRC | 22:20 | |
| *** tristan has quit IRC | 22:25 | |
| *** toscalix has joined #buildstream | 22:35 | |
| *** valentind has quit IRC | 23:12 | |
| *** valentind has joined #buildstream | 23:12 | |
| *** valentind has quit IRC | 23:38 | |
| *** toscalix has quit IRC | 23:38 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!