| *** leopi has joined #buildstream | 04:32 | |
| *** dtf has quit IRC | 05:13 | |
| *** dtf has joined #buildstream | 05:14 | |
| *** alatiera_ has joined #buildstream | 05:42 | |
| *** bochecha has joined #buildstream | 05:59 | |
| *** toscalix has joined #buildstream | 06:48 | |
| *** tristan has joined #buildstream | 07:21 | |
| *** tristan has quit IRC | 07:48 | |
| *** tristan has joined #buildstream | 07:49 | |
| *** ChanServ sets mode: +o tristan | 07:50 | |
| 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 | 07:58 |
|---|---|---|
| *** rdale has joined #buildstream | 08:02 | |
| 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 | 08:17 |
| tristan | bochecha, Hi, care to take a look at https://gitlab.com/BuildStream/buildstream/merge_requests/684#note_95775886 ? | 08:30 |
| *** toscalix has quit IRC | 08:33 | |
| *** toscalix has joined #buildstream | 08:34 | |
| *** jonathanmaw has joined #buildstream | 08:40 | |
| *** tristan has quit IRC | 08:44 | |
| 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 | 08:44 |
| *** tristan has joined #buildstream | 08:46 | |
| *** ChanServ sets mode: +o tristan | 08:47 | |
| valentind | jonathanmaw, does this stored cache size work with multiple sessions running concurrently? | 08:48 |
| jonathanmaw | valentind: I don't know, I haven't tried it | 08:50 |
| jonathanmaw | I suspect it would react poorly since I don't try to write the size file atomically | 08:51 |
| valentind | jonathanmaw, is that planned to be merged to 1.2? | 08:51 |
| jonathanmaw | valentind: not to my knowledge | 08:52 |
| valentind | Writing atomically would not solve it. | 08:52 |
| valentind | OK. So we need a fix for 1.2 | 08:52 |
| jonathanmaw | valentind, looking at https://gitlab.com/BuildStream/buildstream/issues/584 one suggestion is to use a mmap'ed file | 08:54 |
| valentind | That is my suggestion. You can have a mutex in it. | 08:55 |
| valentind | But you still need to handle timeout and recreate, rescan. | 08:55 |
| tristan | jonathanmaw, since you happen to be looking at this at the same time as we were, I wonder if you have looked at Tiago's assessment: https://gitlab.com/BuildStream/buildstream/issues/573 | 08:56 |
| valentind | There are probably some atomic operation with files. But I am not sure all filesystems behave the same. | 08:56 |
| tristan | We rely on os.rename() for that sort of thing | 08:57 |
| qinusty | WSalmon are you working on https://gitlab.com/BuildStream/buildstream/issues/533? | 08:57 |
| tristan | and I think we have a utility for it | 08:57 |
| tristan | valentind, jonathanmaw: utils.save_file_atomic() | 08:57 |
| valentind | tristan, it is not enough. | 08:57 |
| valentind | Because 2 sessions want to write 2 different sizes. | 08:57 |
| tristan | yes | 08:58 |
| valentind | But what you want is the sum of the added values. | 08:58 |
| valentind | So you need to have a swap. | 08:58 |
| tristan | I think that should really be done down in the CAS, not in the high levels of ArtifactCache land | 08:58 |
| valentind | Or something like that. | 08:58 |
| WSalmon | qinusty, nope, i was gona but i got no feedback | 08:58 |
| qinusty | Alright, I was just looking for urgent issues to fix. Mind if I take a look? | 08:59 |
| WSalmon | not at all | 08:59 |
| tristan | For the local cache quota and cleanup, we will need to consider the size of things which are not artifacts, too | 08:59 |
| valentind | tristan, the best would be to have a daemon that starts automatically. | 08:59 |
| tristan | For 1.2, the only thing in the local CAS cache is artifacts, but it wont be true in 1.4 | 08:59 |
| tristan | valentind, at the CAS level, that might make sense indeed | 09:00 |
| * qinusty is getting permission denied (public key) when trying to fetch. | 09:00 | |
| tristan | not sure what is the cleanest / least complex | 09:00 |
| qinusty | Anyone else seeing issues or just me? | 09:00 |
| tristan | qinusty, depends on what you are trying to fetch; could it be that you are trying to fetch a git repo that requires authentication ? | 09:01 |
| valentind | jonathanmaw, I will repopulate my cache to make it slow and test your MR. | 09:01 |
| qinusty | Nope, buildstream | 09:01 |
| tristan | oh, you mean `git fetch`, not `bst fetch` | 09:02 |
| qinusty | Yeah | 09:02 |
| WSalmon | qinusty, i can fetch, some times GL has a hickup especally if its a bit low on ram, have you just tried a gain? | 09:02 |
| qinusty | yup | 09:02 |
| qinusty | It worked yesterday :D | 09:02 |
| WSalmon | can you ssh in and get a identifir and kick out? | 09:02 |
| tristan | qinusty, last year it was an issue; and it would go down for days at a time | 09:02 |
| tristan | I hope it's not happening again :-S | 09:03 |
| qinusty | Is it worth trying to regenerate keys? | 09:04 |
| tristan | I doubt it | 09:04 |
| tristan | sounds very strange :-S | 09:04 |
| jonathanmaw | valentind: thanks. I'll look up mutexes and mmap since I haven't used them in python before. | 09:05 |
| tristan | qinusty, what is in your .git/config ? I have git@gitlab.com:BuildStream/buildstream.git | 09:05 |
| tristan | qinusty, maybe it is failing with an https URI scheme ? | 09:05 |
| qinusty | git@gitlab.com:BuildStream/buildstream.git | 09:06 |
| valentind | jonathanmaw, I have never used them in python before. I suppose we should use native code for that part. But maybe there is better interprocess communication for python than that. | 09:07 |
| tristan | looks like for now we are testing python 3.5.3, 3.6.5 and 3.6.6 | 09:09 |
| tristan | We should probably get an image in there with 3.7.x | 09:09 |
| qinusty | Got to the solution, turns out Git decided to use my OTHER private key by default today. | 09:14 |
| 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 | 09:17 |
| WSalmon | I love a good mystery, although we didnt even have to brake out ssh -v to fix it :D | 09:18 |
| gitlab-br-bot | buildstream: merge request (tristan/pin-pytest-pylint->master: WIP: dev-requirements.txt: Pinning required pytest and pylint versions) #684 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/684 | 09:18 |
| valentind | tristan, So on Debian 9 CI builders, we have pylint 2.1.1. | 09:20 |
| tristan | valentind, only the ubuntu version does not | 09:21 |
| tristan | ubuntu has 1.9.3 | 09:21 |
| valentind | But it is weird it does not complain about more. | 09:21 |
| tristan | But the question is, who does 2.1.1 not work for ? | 09:21 |
| tristan | And what is their python version ? | 09:22 |
| valentind | I have 3.6. Stopped working for me. | 09:22 |
| tristan | fwiw, https://gitlab.com/BuildStream/buildstream/pipelines/28331778 | 09:22 |
| tristan | valentind, that is a run of your `setup.py show` hack | 09:22 |
| valentind | I have this one, were I print exactly what setuptools is using. https://gitlab.com/BuildStream/buildstream/-/jobs/90840031 | 09:22 |
| tristan | the pipelines fail after running the show, but show itself works | 09:22 |
| valentind | Ah ok | 09:22 |
| valentind | Great. | 09:22 |
| valentind | But why does it fail? | 09:23 |
| tristan | something about eggs | 09:23 |
| tristan | doesn't like them pre-fried | 09:23 |
| valentind | Works for my branch. | 09:24 |
| tristan | valentind, I hope that your `setup.py show` thing doesnt download stuff | 09:24 |
| valentind | Ah. We need to use --index-url | 09:24 |
| valentind | Sorry about that. | 09:24 |
| tristan | Right | 09:24 |
| tristan | anyway, if the output is meaningful, that is good | 09:25 |
| tristan | still it's just a test | 09:25 |
| tristan | https://gitlab.com/BuildStream/buildstream/merge_requests/684 <-- this seems to be working well enough with 2.1.1 force installed | 09:28 |
| valentind | Could the version of pep8 be the difference? | 09:28 |
| tristan | valentind, I don't know, actually I don't know what exactly fails for you, and how | 09:28 |
| tristan | valentind, although I think pylint's style checker is independent of pep8 | 09:29 |
| tristan | valentind, please try running the tests locally with this branch: https://gitlab.com/BuildStream/buildstream/tree/tristan/pin-pytest-pylint | 09:29 |
| tristan | it pins all of the versions of the things we already list in dev-requirements.txt, but it does not pin any implied dependencies | 09:30 |
| tristan | Anyone using Fedora today ? | 09:31 |
| tristan | ------------------ if you use Fedora, please help ! ---------------- | 09:31 |
| * tristan is worried we're going to have to trash the whole notification thing | 09:32 | |
| *** flatmush has quit IRC | 09:32 | |
| tristan | at least in 1.2, if the exotic escape sequence doesn't actually work | 09:32 |
| gitlab-br-bot | buildstream: merge request (valentindavid/fix-broken-indentation-after-track->master: Fix broken indentation after track) #622 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/622 | 09:38 |
| gitlab-br-bot | buildstream: merge request (willsalmon/versionTagRegrex->master: Search for tags with the *.*.* patten for version) #601 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/601 | 09:41 |
| valentind | tristan, It seems the version of python3-pytest on Debian sid is the problem. Right now it is 3.6.4. | 09:42 |
| *** solid_black has joined #buildstream | 09:43 | |
| tristan | valentind, what does that mean ? | 09:46 |
| *** flatmush has joined #buildstream | 09:46 | |
| tristan | valentind, it worked ? | 09:46 |
| valentind | That if pinning pytest helped. | 09:47 |
| valentind | Or uninstalling python3-pytest on my system also worked. | 09:47 |
| qinusty | Is the use of an alias with git mandated? | 09:52 |
| qinusty | (within buildstream) | 09:52 |
| tristan | qinusty, strongly recommended | 09:53 |
| tristan | qinusty, for any and all urls | 09:53 |
| qinusty | So strongly that I get a traceback if I don't? :P | 09:53 |
| tristan | no | 09:53 |
| tristan | qinusty, maybe another regression from source mirroring ? | 09:53 |
| tristan | qinusty, this is latest master or bst-1.2 ? | 09:54 |
| tristan | last week valentind fixed an issue with source mirroring around there | 09:54 |
| qinusty | Master, tbf I did have `url: files/repo` | 09:54 |
| qinusty | But that should probably be a fail, not a traceback | 09:54 |
| tristan | qinusty, file an issue, show the traceback, please ? | 09:55 |
| tristan | lets fix it asap | 09:55 |
| qinusty | It's mark_download_url, it splits `alias, _ = url.split(utils._ALIAS_SEPARATOR, 1)` | 09:55 |
| tristan | I bet it's a simple fix | 09:55 |
| qinusty | Clearly, if split returns 1 value. | 09:56 |
| qinusty | It's not enough values | 09:56 |
| tristan | Mhmm | 09:56 |
| gitlab-br-bot | buildstream: issue #597 ("Git url without alias causes ValueError") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/597 | 09:58 |
| tristan | qinusty, I think it will be fine to allow it, even if it's an indication that you are doing something really bad | 10:00 |
| qinusty | Okay, so fix it and trigger warning with a suggestion to use an alias? | 10:00 |
| tristan | qinusty, i.e. not using an alias is not *so* bad as this, you are referring to a git repository that is in an arbitrary location on your local disk | 10:00 |
| tristan | that is pretty bad, it means it will only work on your machine | 10:01 |
| tristan | or worse, it will only work on your machine depending on, your CWD ? | 10:01 |
| tristan | eek | 10:01 |
| qinusty | Well I mean | 10:01 |
| qinusty | files is in the same cwd as elements | 10:01 |
| qinusty | It's the same as having .c files in there? | 10:01 |
| tristan | yeah but who says that will be the CWD of git when run by BuildStream ? | 10:01 |
| tristan | also, if it is part of your project data, it is probably a `local` source | 10:02 |
| tristan | not a git source | 10:02 |
| jmac | Is there any documentation on how to add new configuration options? Or someone willing to talk me through it? | 10:02 |
| valentind | A git repository in a git repository. | 10:02 |
| tristan | gitception | 10:02 |
| tristan | jmac, user configuration ? project configuration ? | 10:03 |
| jmac | Project configuration at the moment | 10:03 |
| qinusty | I'm not actually using this fyi, I was just throwing together a project to use to look into another issue | 10:03 |
| *** WSalmon has quit IRC | 10:04 | |
| tristan | jmac, you need to (A) document it in doc/source/format_project.rst... (B) parse it in _project.py... (C) Add accessors to the Project object for things which want to access it... (D) If there is a default value for the config, it belongs in data/projectconfig.rst | 10:04 |
| valentind | tristan, I have noticed that we already do not check the extract dir for the size. We only do that in Context at load. | 10:05 |
| *** flatmush has quit IRC | 10:05 | |
| tristan | qinusty, yeah I figured, anyway it's a good idea to avoid the exception; in this case mark_download_url AND translate_url, need to be fault tolerant here and accept that there is not always an alias | 10:05 |
| tristan | qinusty, the reason it was working now, is that even if the alias is not found or valid, usually urls have URI schemes | 10:06 |
| tristan | valentind, yyyyeah | 10:06 |
| tristan | valentind, does this significantly change the approach to optimizing things ? | 10:07 |
| valentind | No. But we need to refactor it. We cannot scan for the size without using the artifact cache class. | 10:07 |
| qinusty | So it's still a bug as I see it tristan, it's just working by chance | 10:07 |
| jmac | tristan: OK, I'll stick with just project configuration at the moment and work on the other parts later. Thanks. | 10:08 |
| *** WSalmon has joined #buildstream | 10:08 | |
| tristan | <tristan> qinusty, yeah I figured, anyway it's a good idea to avoid the exception; in this case mark_download_url AND translate_url, need to be fault tolerant here and accept that there is not always an alias | 10:08 |
| *** flatmush has joined #buildstream | 10:08 | |
| *** WSalmon has quit IRC | 10:08 | |
| * qinusty will fix it today | 10:08 | |
| *** WSalmon has joined #buildstream | 10:09 | |
| valentind | tristan, jonathanmaw has already done the refactoring for !679. I think we should cherry pick the commit that does that to backport to 1.2. | 10:09 |
| tristan | bochecha, could really really use your feedback on https://gitlab.com/BuildStream/buildstream/merge_requests/684#note_95775886 | 10:10 |
| tristan | bochecha, I kind of have to make a call on this very nowish, and I just need to know if it will break packaging or not | 10:10 |
| tristan | Duplicated work done in parallel; that sucks :-S | 10:11 |
| tristan | I wanted to reply to the ongoing thread about startup performance, and mention that we had been spending all last week looking at exactly that part | 10:11 |
| tristan | but I was swamped with other stuff | 10:11 |
| cs-shadow | tristan: just for my understanding, is the answer to "Does pylint 2.1.1 behave differently because it is not being run with pytest 3.7.1 ?" yes? | 10:12 |
| tristan | cs-shadow, yeah that's why I want bochecha's attention :'( | 10:12 |
| cs-shadow | that's sucky | 10:12 |
| tristan | cs-shadow, like, all or nothing is better than half way; I sort of feel like; we aught to pin all dependencies to exact versions recursively in dev-requirements.txt, so we can `pip3 install -r dev-requirements.txt` in the CI, without worrying that something might change between runs | 10:14 |
| *** flatmush has quit IRC | 10:14 | |
| tristan | but I don't know if that is going to break packaging stories | 10:14 |
| tristan | cs-shadow, maybe we can make pytest >= 3.7, and pin only pylint to an exact version, in the short term ? | 10:15 |
| tristan | I think, there is absolutely no way out of pinning pylint | 10:15 |
| tristan | and we already pin coverage.py | 10:15 |
| *** flatmush has joined #buildstream | 10:16 | |
| cs-shadow | tristan: Yes, that makes sense. There's another alternative which may warrant more work for us but might solve this packaging problem. | 10:17 |
| cs-shadow | We could pin the versions for the packages that we absolutely need to in setup.py to make lives of packagers easier. For developers, we can keep dev-requirements.txt with exact versions pinned. The logic of parsing it in setup.py will need to change though | 10:17 |
| cs-shadow | a similar approach might also work for runtime dependencies | 10:18 |
| cs-shadow | where requirements.txt has pinned versions that are known to work and setup.py only has coarse constraints specifying what is absolutely needed | 10:18 |
| tristan | cs-shadow, I think that for the short short right now term, lets just pin pylint to the exact version, and pytest to >= 3.7 | 10:20 |
| tristan | cs-shadow, does that mean we need a docker images rebuild ? | 10:20 |
| tristan | cs-shadow, and how does that work ? I think it's weird that you are automating the docker images build with dev-requirements.txt in the first place; because BuildStream will *always* pin the exact refs of the docker images | 10:21 |
| tristan | cs-shadow, i.e. in CI - We demand that the docker image never ever changes, unless we committed a change to .gitlab-ci.yml | 10:22 |
| tristan | Did that somehow change ? | 10:22 |
| tristan | docker images for CI should never change unless BuildStream decides to use a new one | 10:22 |
| cs-shadow | tristan: that should still be the case, i.e. images should only change when a change to .gitlab-ci.yml is committed. We don't use dev-requirements.txt to install the test dependencies but we were thinking of doing so in future to keep version constraints in once place rather than two | 10:24 |
| tristan | cs-shadow, I don't see how that can be possible, though | 10:24 |
| cs-shadow | tristan: and yes, it requires a change in the docker images repo for now. I can do that now. | 10:24 |
| tristan | cs-shadow, i.e. BuildStream cannot commit a change to dev-requirements.txt in master, unless it also updates the images it uses in the .gitlab-ci.yml at the same time, right ? | 10:25 |
| qinusty | jonathanmaw, How come SourceFetcher duplicates the whole mark_download_url() logic? | 10:25 |
| qinusty | Can Source make use of SourceFetcher.mark_download_url()? | 10:25 |
| cs-shadow | tristan: Yes, it will only work if we allow network access to install test dependencies. | 10:26 |
| cs-shadow | tristan: For now, do we agree that we only need to pin pylint and have pytest >=3.7 | 10:26 |
| tristan | cs-shadow, Yes, lets do that today and at least solve the test problem | 10:26 |
| *** jonathanmaw_ has joined #buildstream | 10:27 | |
| cs-shadow | +1 | 10:27 |
| *** jonathanmaw has quit IRC | 10:27 | |
| tristan | qinusty, a SourceFetcher marking a download url is not the same as a Source marking one; basically you only need SourceFetchers when you have multiple URLs | 10:28 |
| tristan | qinusty, which is the vast minority of source implementations | 10:28 |
| tristan | So now I'm futzing around with the fedora VM image I downloaded here: https://www.osboxes.org/fedora/#fedora-28-vbox | 10:31 |
| gitlab-br-bot | buildstream: merge request (jonathan/faster-except-elements->master: Pipeline: Skip except_elements logic if no elements to except) #688 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/688 | 10:32 |
| tristan | it boots and then has a password | 10:32 |
| tristan | ah found it | 10:32 |
| bochecha | tristan: looking | 10:37 |
| tristan | bochecha, for the short term, we're doing something less invasive... I think | 10:37 |
| tristan | bochecha, coverage is already pinned to an exact version, so if you had no issues with that, either it's not a problem, or you accidentally have the exact version of coverage.py that we require | 10:38 |
| * cs-shadow submits https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/63 to apply constraints for pytest and pylint in teststuite images | 10:39 | |
| bochecha | tristan: I only read your last comment, and replied to that, should I read the whole issue? | 10:39 |
| bochecha | tristan: like I said, I already had problems with pinned versions of dev dependencies, and as a result couldn't run the tests in the RPM | 10:40 |
| bochecha | tristan: I think that's fine | 10:40 |
| bochecha | long term, this will settle down, and we can figure things out :) | 10:41 |
| tristan | bochecha, thanks a lot, I think we can easily have a different story for the dev requirements at least for now | 10:42 |
| bochecha | yeah | 10:42 |
| tristan | for today, we have a quicker fix, cause people have random failures compared to CI | 10:42 |
| bochecha | I mean, if you're requiring very new versions of test stuff, eventually they will become old and be available in all distros :) | 10:42 |
| bochecha | and if you require specific old versions of stuff, eventually we can do the work to port to newer ones | 10:42 |
| tristan | bochecha, errrr I dont know about that | 10:44 |
| bochecha | tristan: what do you mean? | 10:46 |
| tristan | I mean, we can port to new versions of things, but it would really suck to support different versions of deps on different distros | 10:46 |
| tristan | assuming the status quo, that python deps think they live in a bubble, it's worrisome | 10:46 |
| tristan | I'm hoping that at least for the runtime dependencies, we can live with fairly recent minimal bound deps, but can't really be sure | 10:47 |
| bochecha | oh, I'm not saying different versions of stuff on different distros | 10:47 |
| bochecha | I'm saying that in the long term, it should get naturally better as your deps come into distros, and start changing less often :) | 10:48 |
| *** WSalmon has quit IRC | 10:48 | |
| bochecha | if in the meantime we have to disable the tests in the packaging, so be it | 10:48 |
| tristan | ok so now I'm futzing around with this fedora VM | 10:54 |
| tristan | how does one do things like, install gcc ? `yum install gcc` I guess ? | 10:54 |
| tristan | gah, it's psutil that doesnt install | 10:56 |
| tristan | bochecha, I have a wild guess... maaaaybe you use fedora ? | 10:56 |
| * tristan still better get this installed | 10:57 | |
| cs-shadow | tristan: you should be able to follow https://gitlab.com/BuildStream/buildstream-docker-images/blob/master/fedora/prepare.sh in case it still doesn't work | 11:01 |
| tristan | cs-shadow, ah good point, but I have it installed | 11:03 |
| tristan | patch just doesnt work | 11:03 |
| bochecha | tristan: yes | 11:03 |
| bochecha | tristan: sudo dnf install $PKG | 11:03 |
| bochecha | if you don't know the package name, then `sudo dnf install /usr/bin/patch` should work | 11:03 |
| tristan | this mythical downstream patch for gnome-terminal that supposedly supports a special escape sequence to bring attention to the terminal | 11:03 |
| tristan | I don't believe it really exists | 11:04 |
| tristan | Although there is a notification whenever a command completes in the background, that is about it | 11:04 |
| bochecha | that's the patch | 11:05 |
| tristan | bochecha, you heard about this famous patch ? | 11:06 |
| bochecha | yes | 11:06 |
| bochecha | I rely on it every day :) | 11:06 |
| tristan | Ok so... here is my problem | 11:06 |
| tristan | bochecha, see tristan/notifications-1.2 branch | 11:06 |
| tristan | latest commit fixes it up a bit | 11:06 |
| bochecha | tristan: patches are here: https://src.fedoraproject.org/rpms/gnome-terminal/tree/master | 11:06 |
| tristan | I think we have the escape sequence wrong | 11:06 |
| tristan | Ohhhh | 11:07 |
| tristan | bochecha, you mean, the patch you rely on every day; just makes a notification when a command completes in the background ?? | 11:07 |
| bochecha | yes | 11:07 |
| tristan | crap, so I am chasing some nonsense myth | 11:07 |
| bochecha | if the terminal window is not focused when a command exits, then you get a notification | 11:07 |
| tristan | yeah | 11:07 |
| bochecha | (might be the terminal tab or window, I'm not sure) | 11:08 |
| bochecha | what did you think it was? | 11:08 |
| jmac | tristan: In most exsiting cases, there isn't much parsing being done in _project.py. There's a lot of composing being done in element.py. Is that only necessary if you've got element config overriding project config? | 11:08 |
| tristan | bochecha, an ansi escape sequence that the terminal parses to make a notification | 11:08 |
| tristan | bochecha, i.e.... when you build something huge and it fails in interactive mode... we print that to the terminal so it draws attention to itself; when BuildStream gives you a prompt | 11:09 |
| bochecha | I'm not sure how it works to be honest | 11:10 |
| tristan | jmac, yes | 11:10 |
| bochecha | this seems to be the patch: https://src.fedoraproject.org/rpms/gnome-terminal/blob/master/f/gnome-terminal-notify-open-title-transparency.patch | 11:10 |
| tristan | yeah I looked at that yesterday | 11:10 |
| bochecha | except it's actually several patches, so some are unrelated | 11:10 |
| bochecha | you'll want to talk to rishi, he's the one who wrote this afaik | 11:10 |
| bochecha | he maintains his patches here: https://github.com/debarshiray/gnome-terminal/ | 11:10 |
| bochecha | https://github.com/debarshiray/vte | 11:10 |
| bochecha | so other distros can reuse them, and I think some do | 11:11 |
| tristan | It's a communications breakdown is what it was | 11:11 |
| jmac | Thanks tristan | 11:11 |
| tristan | mcatanzaro wanted a notification, valentind found something that "worked on gentoo" (only found that out recently)... and I thought it was doing the thing fedora had a patch for | 11:12 |
| tristan | turns out it's just a mess | 11:12 |
| gitlab-br-bot | buildstream: issue #596 ("Systems without FUSE can't use workspaces") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/596 | 11:12 |
| tristan | and jhbuild does some crazy whacky things with status icons + dbus + just about everything in the kitchen sink | 11:12 |
| tristan | trying to grab the users attention | 11:12 |
| valentind | tristan, if VTE_VERSION is defined. It is probably safe to use it. | 11:14 |
| tristan | valentind, except it doesn't *do anything* | 11:15 |
| valentind | Ah no. I have it showing in xterm. | 11:15 |
| tristan | what ? | 11:15 |
| tristan | valentind, Does that escape sequence do anything ? | 11:16 |
| tristan | I have a Fedora VM here, and I dont see anything, maybe it avoids doing something when we do it before exit ? | 11:16 |
| tristan | I'm testing it with just a `bst track` command and put the window out of foxus | 11:16 |
| tristan | focus | 11:17 |
| tristan | valentind, then I just get a notification that the command completed, regardless | 11:17 |
| valentind | tristan, This is the patch gentoo has: https://dev.gentoo.org/~eva/distfiles/vte/vte-0.48.4-command-notify.patch.xz | 11:17 |
| valentind | So yes. It is patched. | 11:17 |
| valentind | It is really annoying this feature did not make to upstream. Because it is very nice. I miss it on Debian. | 11:19 |
| tristan | Hmmm, ok maybe it's working | 11:20 |
| tristan | I just saw it alternate | 11:20 |
| tristan | So what happens is, at the end of the session; we issue the notification | 11:20 |
| valentind | https://fedoramagazine.org/terminal-job-notifications-in-fedora-22-workstation/ | 11:20 |
| tristan | And it shows up ! | 11:20 |
| valentind | tristan, did you try Fedora? | 11:21 |
| tristan | But, fedora's patched version of gnome-terminal just goes ahead and stomps on our notification, saying "The command completed" | 11:21 |
| valentind | tristan, you have to be on another tab or focused on another window for it to notify. | 11:21 |
| tristan | So it shows up for like 0.1 seconds | 11:21 |
| tristan | Which is why I was missing it | 11:21 |
| tristan | I suppose it will work for the failed build though | 11:21 |
| tristan | also, garbage does not show up in the terminal | 11:22 |
| valentind | tristan, but this is fine. We get notified something happened. But what we needed is when we got a interactive prompt from bst. | 11:22 |
| valentind | We do not need notification when bst finishes. Only when it interrupts to the interactive prompt.- | 11:23 |
| tristan | valentind, I'm not sure of that; I think we want to keep calling the App.notify() in the end of sessions too | 11:23 |
| tristan | valentind, i.e.; only the nutty desktops which have added this default notification for anything that completes in the terminal, will have that | 11:24 |
| valentind | tristan, sure, when we have different ways to notify, this will be useful. | 11:24 |
| tristan | right now, it only happens to be that the only terminal that is known to also support the notification via patched VTE, is *also* fedora | 11:24 |
| valentind | (and Gentoo) | 11:25 |
| tristan | So anyway, for now, it's not that annoying that one automatic notification from gnome-terminal squashes our notification | 11:25 |
| tristan | valentind, my patch in tristan/notifications-1.2 (and tristan/notifications) will disable any notifications you had on gentoo | 11:26 |
| tristan | valentind, that needs to be retested | 11:26 |
| tristan | bochecha, and one sad news though; is we now have to depend on the 'distro' python package | 11:26 |
| valentind | tristan, they claim it works since 22. | 11:28 |
| tristan | valentind, do you have a link to the very specific claim, about the special ANSI escape sequence ?? | 11:28 |
| tristan | i.e. I found some blog post about how they have "A notification when a command completes in the background", since fedora 22 | 11:29 |
| tristan | That is unrelated | 11:29 |
| valentind | No. I do not have. I just think that if this was an improved version... then what they had before must have been really ugly. | 11:30 |
| tristan | Man, I'd really love to know back up until which point fedora supports the ANSI escape sequence | 11:30 |
| tristan | But I only know that it works "around now", and I've only tested with a Fedora 28 VM | 11:31 |
| tristan | probably Fedora 27 is safe | 11:31 |
| valentind | The sequence is safe on vanilla vte. I do not get anything happening on gnome-terminal. The problem is terminal that do not use vte. | 11:32 |
| gitlab-br-bot | buildstream: merge request (jonathan/faster-except-elements->master: Pipeline: Skip except_elements logic if no elements to except) #688 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/688 | 11:33 |
| tristan | valentind, life is getting more and more complicated by the minute, then; I suppose this means, we don't need the 'distro' package for this at all ? | 11:47 |
| tristan | maybe VTE_VERSION is going to work | 11:48 |
| tristan | Also, we don't have Laurence or Agustin today... do I have a volunteer to chair the meeting in their stead ? | 11:49 |
| tristan | Or, Agustin will arrive late, Laurence is on holiday | 11:49 |
| valentind | tristan, what was the terminal you got garbage with? | 12:02 |
| valentind | For me, even xterm seems to ignore it. | 12:02 |
| *** leopi has quit IRC | 12:02 | |
| tristan | valentind, my gnome-terminal on debian | 12:08 |
| valentind | I tried also rxvt, konsole, qterminal, xfce4-terminal. | 12:08 |
| tristan | VTE_VERSION says 4400 | 12:08 |
| valentind | And you get garbage? | 12:08 |
| valentind | I have 5202. | 12:09 |
| tristan | Yes, if I make it unconditional, I get an unrendered garbage character, followed by some of the literal text | 12:09 |
| tristan | valentind, do you happen to know what part of vte does this ? | 12:09 |
| tristan | I'm looking at src/mev.c, which seems to handle escape sequences, but can't find how it handles this specifically | 12:10 |
| tristan | maybe with a git annotate I can trace the version it was added in | 12:10 |
| valentind | tristan, I do not remember. Let me see. | 12:10 |
| gitlab-br-bot | buildstream: merge request (chandan/update-ci-tags->master: .gitlab-ci.yml: Bump tags for testsuite images) #689 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/689 | 12:12 |
| tristan | cs-shadow, AWESOME | 12:13 |
| tristan | cs-shadow, Do you think we can make those changes in dev-requirements.txt at the same time ? | 12:14 |
| cs-shadow | tristan: :) I was just writing a similar comment on your MR. I can include your branch in my MR. That way, we will prove that the teststuite images indeed work without requiring to install additional things | 12:15 |
| tristan | cs-shadow, yeah my MRs were mostly frantic tests | 12:16 |
| bochecha | tristan: for runtime? | 12:16 |
| *** WSalmon has joined #buildstream | 12:17 | |
| tristan | bochecha, dev-requirements.txt | 12:17 |
| tristan | "dev-" | 12:17 |
| bochecha | tristan: ah, no problem then :) | 12:17 |
| tristan | grepping through vte I still don't see any evidence that this is handled by vte :-S | 12:20 |
| gitlab-br-bot | buildstream: merge request (chandan/update-ci-tags->master: .gitlab-ci.yml: Bump tags for testsuite images) #689 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/689 | 12:21 |
| gitlab-br-bot | buildstream: merge request (chandan/update-ci-tags->master: .gitlab-ci.yml: Bump tags for testsuite images) #689 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/689 | 12:21 |
| tristan | I have a feeling it doesnt do anything except perhaps trigger a callback on the vte widget | 12:23 |
| tristan | then the embedding application can choose to implement any 777 special escape sequence | 12:23 |
| gitlab-br-bot | buildstream: merge request (chandan/update-ci-tags->master: Restrict pylint/pytest versions and bump CI tags) #689 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/689 | 12:23 |
| valentind | tristan, found it: https://gitlab.gnome.org/GNOME/vte/commit/47879674b97aa610174ce79e427a181ca23aad8d | 12:30 |
| tristan | valentind, Aaaahhh so I was looking at that code and not seeing it getting handled | 12:31 |
| tristan | so, it wont "work" | 12:31 |
| valentind | No. But it will ignore the sequence. | 12:31 |
| tristan | but since a given version, vte will cleanly ignore it instead of puking up garbage ? | 12:31 |
| tristan | ok I see | 12:31 |
| valentind | Yes. | 12:31 |
| valentind | So I need to figure out what is the VTE_VERSION from there. | 12:31 |
| valentind | I suppose 4500. | 12:32 |
| gitlab-br-bot | buildstream: merge request (chandan/update-ci-tags-1.2->bst-1.2: Restrict pylint/pytest versions and bump CI tags) #690 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/690 | 12:32 |
| valentind | Is there a reverse describe? | 12:32 |
| tristan | valentind, I forget what it is again.... I am searching through git log but we need to ask git "What tags have this commit in their history" | 12:33 |
| valentind | 0.44.90 is the previous tag. Then the next one is 0.45.90. | 12:33 |
| tristan | So I guess 4590 ? | 12:34 |
| valentind | The only thing I miss from mercurial is rev expressions. | 12:34 |
| tristan | lemme ask chpe | 12:34 |
| gitlab-br-bot | buildstream: merge request (willsalmon/versionTagRegrex->master: Search for tags with the *.*.* patten for version) #601 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/601 | 12:35 |
| valentind | tristan, we probably want to enable it also for TERM starting with "rxvt-unicode" | 12:36 |
| tristan | valentind, does that use vte or not ? | 12:37 |
| valentind | Because this is the terminal where this sequence orignally comes from. Though I am not sure how they use it. | 12:37 |
| tristan | I guess it doesnt | 12:37 |
| valentind | tristan, no. VTE_VERSION is not defined on urxvt. | 12:37 |
| tristan | valentind, the funny thing is... I think we *still* didn't even ever see that mythical downstream patch fedora uses | 12:39 |
| tristan | Strange | 12:39 |
| tristan | I did see it do something, though | 12:39 |
| gitlab-br-bot | buildstream: merge request (jonathan/faster-except-elements->master: Pipeline: Skip except_elements logic if no elements to except) #688 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/688 | 12:43 |
| gitlab-br-bot | buildstream: merge request (chandan/update-ci-tags->master: Restrict pylint/pytest versions and bump CI tags) #689 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/689 | 12:46 |
| tristan | cs-shadow, rebased #689 since something landed on master first... | 12:47 |
| gitlab-br-bot | buildstream: merge request (jonathan/faster-except-elements-1.2->bst-1.2: Pipeline: Skip except_elements logic if no elements to except) #691 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/691 | 12:47 |
| cs-shadow | tristan: thanks! | 12:47 |
| tristan | next challenge; we have to cut down CI time immensely, this shouldn't be taking more than 15min really | 12:48 |
| tristan | jjardon, pointed me to some instructions to install a runner the other day; but that would imply we have a dedicated machine | 12:48 |
| tristan | I guess we have to look into finding one | 12:48 |
| valentind | tristan, https://src.fedoraproject.org/rpms/vte291/blob/master/f/vte291-command-notify-scroll-speed.patch | 12:50 |
| tristan | valentind, isn't the 'vte' package the important one, not the 'vte' one ? | 12:51 |
| tristan | still, that's interesting | 12:51 |
| valentind | Seems vte is an old package not updated for 8 years. | 12:51 |
| tristan | I had a feeling that vte291 was a GTK+-2 based package | 12:51 |
| tristan | valentind, yeah, that must be the GTK+2 version | 12:52 |
| gitlab-br-bot | buildstream: merge request (willsalmon/versionTagRegrex->master: WIP: Search for tags with the *.*.* patten for version) #601 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/601 | 12:52 |
| valentind | Well, vte is updated but it is the gtk+ 2 | 12:53 |
| valentind | vte291 is the new one. | 12:53 |
| tristan | but the 'vte' spec files are updated very regularly, how can 'vte291' be the new one if it's not changed in 8 years ? | 12:54 |
| *** leopi has joined #buildstream | 13:00 | |
| *** WSalmon has quit IRC | 13:03 | |
| gitlab-br-bot | buildstream: issue #598 ("Fatal warnings prints None when detail not provided") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/598 | 13:16 |
| tristan | valentind, anyway please don't worry about this anymore; I've got a working strategy for vte | 13:18 |
| valentind | tristan, ok | 13:18 |
| tristan | valentind, I'll patch it for now, and I will leave other terminal support out; that we can add separately | 13:19 |
| gitlab-br-bot | buildstream: merge request (chandan/update-ci-tags-1.2->bst-1.2: Restrict pylint/pytest versions and bump CI tags) #690 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/690 | 13:31 |
| gitlab-br-bot | buildstream: merge request (tristan/notifications->master: _frontend/linuxapp.py: Fix special casing around desktop notification escape sequence) #692 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/692 | 13:45 |
| gitlab-br-bot | buildstream: merge request (tristan/notifications-1.2->bst-1.2: _frontend/linuxapp.py: Fix special casing around desktop notification escape sequence) #693 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/693 | 13:45 |
| *** jonathanmaw_ is now known as jonathanmaw | 13:47 | |
| jonathanmaw | FYI folks, the monthly meeting will be held on #buildstream-meetings (note spelling) in 12 minutes | 13:48 |
| jonathanmaw | I've volunteered to chair it this time | 13:48 |
| tristan | \o/ | 13:48 |
| tristan | jonathanmaw, normally the agenda would be up here: https://wiki.gnome.org/Projects/BuildStream/Monthly-Meeting/20180821 | 13:49 |
| tristan | jonathanmaw, but I think we just go off of Agustin's email from last week to the list | 13:49 |
| jonathanmaw | tristan: yep, that's what I found and was working off | 13:50 |
| *** jennis has joined #buildstream | 13:53 | |
| gitlab-br-bot | buildstream: merge request (chandan/update-ci-tags->master: Restrict pylint/pytest versions and bump CI tags) #689 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/689 | 13:57 |
| gitlab-br-bot | buildstream: merge request (Qinusty/598-fatal-warning-none-detail->master: Fatal warnings no longer print None when detail=None) #694 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/694 | 13:57 |
| *** sstriker has joined #buildstream | 13:58 | |
| qinusty | https://gitlab.com/BuildStream/buildstream/merge_requests/694 resolves a small issue with the fatal-warnings feature I spotted. It's a one liner but a quick lookover from someone would be nice :D | 13:58 |
| *** sstriker has quit IRC | 13:59 | |
| *** jonathanmaw has left #buildstream | 13:59 | |
| *** jonathanmaw has joined #buildstream | 13:59 | |
| jonathanmaw | The monthly meeting is now starting in #buildstream-meetings | 14:00 |
| *** sstriker has joined #buildstream | 14:00 | |
| *** solid_black has quit IRC | 14:05 | |
| *** solid_black has joined #buildstream | 14:06 | |
| gitlab-br-bot | buildstream: issue #599 ("Silent warnings") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/599 | 14:17 |
| 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 | 14:20 |
| 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 | 14:35 |
| qinusty | https://gitlab.com/BuildStream/buildstream/merge_requests/670 is ready for review if anyone can spare some time | 15:04 |
| gitlab-br-bot | buildstream: merge request (tristan/notifications->master: _frontend/linuxapp.py: Fix special casing around desktop notification escape sequence) #692 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/692 | 15:10 |
| gitlab-br-bot | buildstream: issue #600 ("Bug: devours memory and stack traces when recursive variables defined") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/600 | 15:14 |
| *** tristan has quit IRC | 15:15 | |
| *** leopi has quit IRC | 15:15 | |
| gitlab-br-bot | buildstream: merge request (tristan/notifications-1.2->bst-1.2: _frontend/linuxapp.py: Fix special casing around desktop notification escape sequence) #693 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/693 | 15:44 |
| gitlab-br-bot | buildstream: merge request (Qinusty/598-fatal-warning-none-detail->master: Fatal warnings no longer print None when detail=None) #694 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/694 | 15:46 |
| 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 | 15:46 |
| 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 | 15:53 |
| *** jennis has quit IRC | 15:55 | |
| *** jennis has joined #buildstream | 15:55 | |
| jennis | Are we planning to backport !633, add 'build-depends' and 'runtime-depends'? | 15:57 |
| jennis | jonathanmaw? | 15:57 |
| jennis | This is in the documentation but not available in our stable version, has there been a discussion regarding occurences like thi | 15:58 |
| jennis | this* ? | 15:58 |
| jonathanmaw | jennis: I don't think there's been any discussion about adding it to bst-1.2 | 16:00 |
| qinusty | can someone explain the differences between mark_download_url() and translate_url() and perhaps why you'd use one over the other? Maybe jonathanmaw, tristan? | 16:00 |
| jonathanmaw | qinusty: mark_download_url and translate_url will both mark the URL, but only translate_url returns the output | 16:02 |
| qinusty | Is there a reason why translate_url isn't called from mark_download_url() specifically? | 16:02 |
| * qinusty is modifying areas around this and could avoid code duplication from refactoring this | 16:03 | |
| jonathanmaw | qinusty: translate_url has a fair amount of logic because it needs to be able to handle the alias being overridden from various places | 16:04 |
| qinusty | But if I change mark_download_url() to call on translate_url(), I can't see it producing any obvious issues | 16:05 |
| qinusty | they seem to do similar things, just translate_url() has the option of overriding | 16:05 |
| jonathanmaw | qinusty: true, but mark_download_url needs the alias component of the URL, and translate_url doesn't currently provide it | 16:06 |
| jonathanmaw | would it make more sense to have a third function that handles the parts of those that they have in common? | 16:07 |
| * qinusty doesn't quite understand __expected_alias | 16:07 | |
| qinusty | wait, only SourceFetcher.mark_download_url() needs __alias | 16:08 |
| 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 | 16:08 |
| * qinusty realises mark_download_url() is abstract | 16:12 | |
| jonathanmaw | qinusty: I think that's an artifact of this functionality going through many iterations | 16:15 |
| jonathanmaw | I can't think of a good reason for source plugins to make it do anything different | 16:15 |
| 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 | 16:24 |
| 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 | 16:30 |
| jmac | Right, !626 is ready for review | 16:32 |
| *** solid_black has quit IRC | 16:42 | |
| jmac | juergbi: I'm going to start reviewing buildbox now - shall I just dive in on the juerg/wip branch and read that or is there a better place to start? | 16:51 |
| juergbi | jmac: yes, that's still the right branch. see !2 | 16:52 |
| jmac | Great | 16:53 |
| juergbi | btw: I successfully built almost whole freedesktop-sdk with the local buildbox backend | 16:54 |
| jmac | Brilliant | 16:54 |
| paulsherwood | almost? | 16:54 |
| juergbi | I see issues in e.g., rust but the error doesn't seem related to buildbox | 16:55 |
| juergbi | haven't cross checked yet whether it works with buildstream master | 16:55 |
| *** WSalmon has joined #buildstream | 16:56 | |
| *** leopi has joined #buildstream | 16:58 | |
| 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 | 17:06 |
| *** jonathanmaw has quit IRC | 17:09 | |
| 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 | 17:11 |
| *** adds68 has quit IRC | 17:11 | |
| *** qinusty has quit IRC | 17:11 | |
| *** coldtom has quit IRC | 17:11 | |
| *** jennis has quit IRC | 17:11 | |
| *** CTtpollard has joined #buildstream | 17:24 | |
| *** tpollard has quit IRC | 17:26 | |
| *** WSalmon has quit IRC | 17:47 | |
| *** adds68 has joined #buildstream | 18:01 | |
| *** rdale has quit IRC | 18:43 | |
| *** leopi has quit IRC | 20:06 | |
| *** bochecha has quit IRC | 20:15 | |
| *** tristan has joined #buildstream | 20:21 | |
| *** tristan has quit IRC | 21:33 | |
| *** alatiera_ has quit IRC | 22:34 | |
| gitlab-br-bot | buildstream: merge request (chandan/pypi-prep->master: setup.py: Add fields required for publishing on PyPi) #695 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/695 | 23:58 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!