As mentioned in the summary, if this patch gets into the repo, we should deprecate nvidia-docker and nvidia-container-runtime.

Abandoning since I made a mistake. This is corrected and re-submitted in D7736.

Remove empty abi_used_libs

Make the rm command applicable to all python 3 versions.

@JoshStrobl Can you take a look at the patch again to see whether it is good now?

This issue has happened again since the update of libvte to 0.58.0. Kindly ping @JoshStrobl to look at it since he is the maintainer of libvte.

Let ypkg decide the component for devel subpackage

-devel subpackage belongs to programming.devel component

@JoshStrobl Can you review this patch again?

Rebase against master branch

Update to 1.3.0

@joebonrichie The build finishes successfully for me against llvm 9 with solbuild after removing the following line from FindLLVM.cmake:

@joebonrichie First thanks for the effort on updating llvm as well as other toolchains for us. I really appreciate your work.

@DonHugo I updated the documentation according to your suggestion. Can you take a look and see whether that is better?

@DonHugo I created a pull request to add the documentation for enabling fzf command-line autocompletion and key-bindings to the Solus help center here: https://github.com/getsolus/help-center-docs/pull/230. Can you try to see if it works correctly for you?

Update the test plan. Tested against latest network manager now.

In D6912#116158, @maverick1 wrote:

@xulongwu4, is the patch for OpenCV 4 needed? Because we have got 3.4.7 version in our repo.

Rebase on master branch

python3 is enough for my use case.

In T8326#157711, @DonHugo wrote:

If you don't want to enable that functionality, wouldn't it make sense to inform the user about the about it and tell them where to find the necessary files?

The keybindings are not enabled by default. If you want to enable it, you can add the source statement in your shell init script. For example, I have this in .bashrc:

Add MAINTAINERS.md file

Add MAINTAINERS.md file

I can confirm the problem exists

pytorch-devel belongs to programming.library now

Max memory usage I saw was 3.5GB which is actually pretty crazy.

I actually can't build it due to ld.bfd sucking all my memory, and, can't build it with clang + lld due to --copy-needed-dt-entries being inherited.

@joebonrichie Are you referring to pytorch here? That would be weird since D6912 built with opencv 4.1.1 successfully as it is right now. My machine has plenty of memory though. I will test it on another machine with 16 GB memory and see how it goes.

@joebonrichie I submitted a patch for pytorch 1.2.0 (D6912) and I can confirm that it builds with opencv 4.1.1.

Add patch to build with opencv-4

I found a solution to this problem after some research.

Now that pytorch 1.2.0 is available, I will abandon this patch and submit another one for 1.2.0

I am happy to maintain it.

This could be helpful: https://vi.stackexchange.com/questions/9959/why-syncolor-vim-is-sourced-at-the-end-of-cygwin-vim-started-and-replaced-the-sp

Update test plan.

@joebonrichie I can take a look at the possibility of building pytorch with opencv 4.1.0 after D6209 is accepted.

@JoshStrobl Any news/thoughts on this patch?

Fix newlines in summaries.

Fix summary to changelog.

Fix summary

Update the summary.

BTW, the name of the repo is misspelled. It is supposed to be python-keras-preprocessing rather than python-kera-preprocessing.