remove separate doc package

I a have a patch ready for it. Currently compiling some simple test programs and running the unit tests.

Only use patch for changing/enabling options inside tlp.conf. I think shipping a tlp.conf via files is not a good option. By doing so we could miss adding upcoming features in next releases. By using a patch they are at least available in the config (even if disabled by default). So they can be activated by the users more easily.

Removed TNNN from summary and added a testplan. Also added a homepage field in package.yml

moved component field above summary and added homepage field

Update revision to remove TNNN from summary and added a testplan

Remove TNNN from Summary and simplified title

Updated test Plan and removed Fix TNNNN from Summary

Bump revision to 4 and move component field above summary

Bump release to 2 and move component field above summary

Align fields in package.yml

Bum release to 4 and rearange fields in package.yml according to comment from algent

1. Updating D8861: Add component to package.yml and update license to be SPDX compliant for chmlib

Change component to programming.library

fix typo "dropwdown" and install under '/usr/' instead of '/usr/local/'

Just wanted to bring this task back up. Patches for the needed packages are available at D8723, D8722, D8721, D8720. Please let me know what I need to do to get these accepted into solus

Changed Revision back to 4, removed component.xml and fixed license Identifier

I would like to reopen this task. I am heavily using podman for developement purposes and having fuse-overlayfs (T8408) would be very nice to improve disk usage.

Requires Gradle 5.0+ to build

anything further needed?

You can add me as maintainer if you like (and if it's posible. Started working on solus just recently).

Change license identifier to GPL-3.0-or-later (SPDX) and remove "-" from install step. "netowrking: no" removed and enable stripping

remove "-" from install step

do not build static files

Update to latest release 0.23.1, Build against python3 and remove unneeded doc files.

removed "strip: yes" and "-" from install step

removed "strip: yes" and "-" from install step

I have finished testing. What I did:

Any further information required?

Any further information required?

I have package builds for this and all it's dependencies ready. I am currently doing some testing with the application (Scanning QR-Codes, generating TOTP codes, etc.)

It looks like there is an issue if someone is using a non-GNOME Window Manager (like kwin for KDE Plasma). See Bug Report: 1182700

Ping. Just to bring this Topic back to life.

In T6658#168843, @DataDrake wrote:

Please be patient. I am swamped at work right now and have higher priority issues in Solus to deal with in the little free time I do have, else this would have already been implemented. And please, this isn't debate club. I have laid out the solution that I believe is the best path forward for Java on Solus after almost two years of arguments here and in other communications channels about all of this and more.

In T6658#161250, @DataDrake wrote:

Pretty simple really. Each JDK should have its own directory in /usr/lib64.

I think this is the "best" solution. Afterwards one could select his Java version via an extra cmdline tool which creates symlinks for java/javac/jshell/jar. That's how Debian is doing it for update-alternatives (https://linux.die.net/man/8/update-alternatives) or Arch for archlinux-java (https://wiki.archlinux.org/index.php/Java#Package_pre-requisites_to_support_archlinux-java).

I tried creating a patch for the newer Version. Unfortunately it needs Java 11 which is not inside the repositories as of now. Discussion about how to include Java 11 is ongoing: https://dev.getsol.us/T6658

I don't think that it will be for personal use only. For example the following projects are also using uriparser:

Created Package request: https://dev.getsol.us/T8857

In D8582#137852, @DataDrake wrote:

Is this needed for another package? I don't see a Package Request for this.