Rebase on master.

Rebase on master and add a patch to fix github issue 1038.

Remove unused patches

@DataDrake I am working on updating tensorflow to a newer version. It would be good it this patch can be landed before that.

@DataDrake Do you have some time to review this patch?

@JoshStrobl Yes I can confirm that it still happens on 0.58.3.

@JoshStrobl Can you take a look at this request and see whether it's worth re-evaluating its inclusion in the repo?

You can set the python version you want to use by setting things like PYTHON_EXECUTABLE, PYTHON_INCLUDE_DIR, and PYTHON_LIBRARY when building root: https://root.cern.ch/building-root. One tricky thing about root is that it comes with a lot of packages that might have been installed on the system. So ideally one wants to use the system version rather than the version comes with ROOT if possible.

@JoshStrobl Could you provide your thoughts regarding our feedback? It is not really good for us to keep giving our perspectives while seeing no response from the core team.

@Girtablulu libsplit only keeps the library file (lib*.so) from entering the devel subpackage, but it does nothing to the header files. I think you will need to use the patterns key to require the headers also go to the main package. You can look at the eigen3 package as a template.

@DataDrake No push here. Just wondering when you plan to land this patch. Thanks.

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.