You are not logged in.
Also:
google-tsunami-security-scanner-git
It doesn't compile on java-14-openjdk (I suppose because it uses gradle v6.2), therefore it should be compiled using java-11-openjdk, but it also compiles well with older versions of openjdk (I haven't tested but probably with oracle jdk too), for now I have specified its dependency jdk11-openjdk, how can I address that jdk8-openjdk is OK too for example?
(I'm not sure if I should another topic for google-tsunami-security-scanner-plugins-git as it is a plugin for this package).
Also:
google-tsunami-security-scanner-plugins-git
Is it ok that I've put this in package? I mean searching for all *.jar files and installing them all.
readarray -d '' jar < <(find "${srcdir}" -name '*.jar' -print0)
for jar_path in "${jar[@]}" ; do
jar_filename="${jar_path##*/}"
install ${jar_path} "${appdir}/${jar_filename}"
done
Any other idea on PKGBUILDs is highly appreciated.
Offline
I've looked only at google-tsunami-security-scanner for now.
The apache license is like BSD, MIT and the other licenses in the first bullet point at https://wiki.archlinux.org/index.php/PKGBUILD#license .
In package() you need to copy the real license to the location mentioned.
conflicts=('google-tsunami-security-scanner-git')
best practice is to have the git version conflict with the stable version, please remove that line.
for now I have specified its dependency jdk11-openjdk, how can I address that jdk8-openjdk is OK too for example?
Let the package depend on java-runtime or java-environment with a version limit , like depends=('java-runtime<12') .
./gradlew shadowJar
Does compilation with gradle from repos fail so you need to use the version upstream provides in the tarball ?
If so, a short comment stating that would be nice to have in the PKGBUILD.
install tsunami.yaml "${appdir}"
that file appears to be used for configuration.
Does upstream provide its own code to process that or do they use something like libyaml ?
This package clearly uses java (albeit in a weird way imo) , so https://wiki.archlinux.org/index.php/Ja … guidelines should be applicable.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
The apache license is like BSD, MIT and the other licenses in the first bullet point at https://wiki.archlinux.org/index.php/PKGBUILD#license .
In package() you need to copy the real license to the location mentioned.
Thank you for pointing that out, but apache license is present in licenses package, and is completely identical to the license in repo, therefore I'm not sure if apache should be handled like the ones you've mentioned.
conflicts=('google-tsunami-security-scanner-git')
best practice is to have the git version conflict with the stable version, please remove that line.
I've removed it, thanks.
aminvakil wrote:for now I have specified its dependency jdk11-openjdk, how can I address that jdk8-openjdk is OK too for example?
Let the package depend on java-runtime or java-environment with a version limit , like depends=('java-runtime<12') .
Thanks, that did the job, but there is a problem, it doesn't change archlinux-java status and therefore if I have installed a java-runtime<12, but my archlinux-java has been set to java-runtime 14, compilation gives me an error.
./gradlew shadowJar
Does compilation with gradle from repos fail so you need to use the version upstream provides in the tarball ?
If so, a short comment stating that would be nice to have in the PKGBUILD.
Actually I haven't checked using gradle from repos yet, will try and if it does that would solve the java-runtime dependency problem too, will give that a shot and post the results.
install tsunami.yaml "${appdir}"
that file appears to be used for configuration.
Does upstream provide its own code to process that or do they use something like libyaml ?
https://github.com/google/tsunami-secur … figuration:
Tsunami uses snakeyaml to parse the YAML config file.
So I assume it doesn't have to use libyaml as a dependency, yes?
This package clearly uses java (albeit in a weird way imo) , so https://wiki.archlinux.org/index.php/Ja … guidelines should be applicable.
I had read that before, but didn't remember that it exactly talks about class paths, thanks for mentioning it, will read it again, it will be very helpful for plugins package.
Offline
Thank you for pointing that out, but apache license is present in licenses package, and is completely identical to the license in repo, therefore I'm not sure if apache should be handled like the ones you've mentioned.
The completely identical result is correct, but only because upstream hasn't put their copyright info in the License.
( I opened [1] to alert them of this.)
Thanks, that did the job, but there is a problem, it doesn't change archlinux-java status and therefore if I have installed a java-runtime<12, but my archlinux-java has been set to java-runtime 14, compilation gives me an error.
That's expected behaviour and can be dealt with in several ways :
- Build in a clean chroot[2]
- set java default manually
- use a wrapper[3]
Tsunami uses snakeyaml to parse the YAML config file.
So I assume it doesn't have to use libyaml as a dependency, yes?
correct, but you may have to add snakeyaml as a dependency[4]
[1] https://github.com/google/tsunami-secur … /issues/53
[2] https://wiki.archlinux.org/index.php/De … root]clean chroot
[3] https://wiki.archlinux.org/index.php/Ja … va_version
[4] currently there is no snakeyaml package in repos or aur, so it would have to be created.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
The apache license is like BSD, MIT and the other licenses in the first bullet point at https://wiki.archlinux.org/index.php/PKGBUILD#license .
In package() you need to copy the real license to the location mentioned.
That's an obviously untrue statement, weakly disproven by your own link that excludes Apache from the list of special licenses, and strongly disproven by the licenses package and all the official packages which list this license and don't distribute license files.
If you still don't believe you're *thoroughly* wrong, feel free to open a discussion on the talk page there and/or advocate for distro-wide changes in tons of packages.
aminvakil wrote:Thank you for pointing that out, but apache license is present in licenses package, and is completely identical to the license in repo, therefore I'm not sure if apache should be handled like the ones you've mentioned.
The completely identical result is correct, but only because upstream hasn't put their copyright info in the License.
( I opened [1] to alert them of this.)
Thus demonstrating your UTTER ignorance of how licenses work. The GPL has the same contents and, I assume you think the same issue. Those are NOT the license terms.
The GPL lists this text after:
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
The Apache license lists this text after:
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
Both refer to the headers you add to source files, and are advisory, not required.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
@ aminvakil :
You handled the license as described in the wiki, please ignore what I said about it.
This is my last post in this thread, I wish you good luck with the packages.
Last edited by Lone_Wolf (2020-07-22 11:08:47)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Lone_Wolf wrote:The apache license is like BSD, MIT and the other licenses in the first bullet point at https://wiki.archlinux.org/index.php/PKGBUILD#license .
In package() you need to copy the real license to the location mentioned.That's an obviously untrue statement, weakly disproven by your own link that excludes Apache from the list of special licenses, and strongly disproven by the licenses package and all the official packages which list this license and don't distribute license files.
If you still don't believe you're *thoroughly* wrong, feel free to open a discussion on the talk page there and/or advocate for distro-wide changes in tons of packages.
Lone_Wolf wrote:aminvakil wrote:Thank you for pointing that out, but apache license is present in licenses package, and is completely identical to the license in repo, therefore I'm not sure if apache should be handled like the ones you've mentioned.
The completely identical result is correct, but only because upstream hasn't put their copyright info in the License.
( I opened [1] to alert them of this.)Thus demonstrating your UTTER ignorance of how licenses work. The GPL has the same contents and, I assume you think the same issue. Those are NOT the license terms.
The GPL lists this text after:
GPL wrote:END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
The Apache license lists this text after:
Apache wrote:END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
Both refer to the headers you add to source files, and are advisory, not required.
Please tone it down. Helping to clear up a misunderstanding is fine, but you can do so without resorting to personal attacks.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
@Lone_Wolf, thanks for all the help!
Last edited by aminvakil (2020-07-25 12:38:23)
Offline