[aur-general] TU application; freswa

Levente Polyak anthraxx at archlinux.org
Sat May 16 19:01:47 UTC 2020


On 5/6/20 11:19 PM, Frederik Schwan via aur-general wrote:
> 
> I am looking forward to working with you!
> Frederik
> 

Hi Frederik,

I'm happy to _already_ work with you as you are doing a great job on the
bugtracker. I hope we won't loose your power wrangling that beast :D

I managed to cut some free time to review all your packages, so here
comes the feedback,

cheers,
Levente

$ xxarhtna --user freswa

adobe-icc:
- could use TLS in url and source, because why not :}
- would be a good idea to reuse $pkgver in source=()

chisel:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz

dovecot-xaps-daemon:
- should not have the conflicts, its always the special
  variants that conflict on the regular variant, not the
  other way around
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- could use the new set of go binary hardening flags so
  sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS
- License is a non common one but the distribution of anything
  indicating the license is missing.

dovecot-xaps-daemon-git:
- normally its a bit better to have a pkgver that actually
  has any meaning in what kind of version the installed pkg
  matches, like 0.7.r21.b098747 instead of 94.b098747
  git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
- could use the new set of go binary hardening flags so
  sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS
- License is a non common one but the distribution of anything
  indicating the license is missing.

dovecot-xaps-plugin:
- build function doesn't build anything, the package functions
  "make install" will do the real compilation.
- Should not makedepend on git as its not using git
- should not have the conflicts, its always the special
  variants that conflict on the regular variant, not the
  other way around
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- License is a non common one but the distribution of anything
  indicating the license is missing.
- cmake has a convenient "-B build" to that doesn't require mkdir

dovecot-xaps-plugin-git:
- build function doesn't build anything, the package functions
  "make install" will do the real compilation.
- missing provides and conflicts on the regular non -git variant
- normally its a bit better to have a pkgver that actually
  has any meaning in what kind of version the installed pkg
  matches, like 0.7.r21.b098747 instead of 94.b098747
  git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
- License is a non common one but the distribution of anything
  indicating the license is missing.
- cmake has a convenient "-B build" to that doesn't require mkdir

duperemove-git:
- should not pull over plaintext git:// but git+https to provide
  endpoint verification and encryption during transit
- missing conflicts on duperemove
- normally its a bit better to have a pkgver that actually
  has any meaning in what kind of version the installed pkg
  matches, like 0.7.r21.b098747 instead of 94.b098747
  git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'

exfat-dkms-git:
- shouldn't this also provide something like exfat and exfat-dkms
- this shouldn't confict on other special git variant exfat-git
- shouldn't this package be named exfat-nofuse-dkms-git ? its not
  just exfat-dkms, this is in fact exfat-nofuse

exfat-utils-nofuse:
- non quoted usage of ${srcdir} which may fail if it contains spaces
- autoreconf could be executed during prepare step

flexbox-udev:
- non quoted usage of ${srcdir} and ${pkgdir } which may fail if it
  contains spaces

gimp-plugin-separate+:
- modifying or patching files should be done during prepare

gtkhotkey:
- modifying or patching files should be done during prepare

heif:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz

jtool-bin:
- doesn't use a unique source and should prefix it with $pkgver
- package is outdated as v2 exists

latex-tuda-ci:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz

libpurple-lurch:
- should not on every single build side load the whole submodules
  repos, instead they should be declared in source=() and the
  paths updated accordingly -- for an exaple look at the mono package
- static version must not provides=() its -git counterpart

nameinator:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- could use the new set of go binary hardening flags so
  sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS
- must not use 'go get' on a repo as thats not reproducible

onivim2:
- should not have the conflicts, its always the special
  variants that conflict on the regular variant, not the
  other way around

onivim2-git:
- missing provides and conflicts on the regular non -git variant

open-ecard-git:
- should not pull over plaintext git:// but git+https to provide
  endpoint verification and encryption during transit
- missing provides and conflicts on the regular non -git variant
- it this hard depending on the JRE 8 for a reason, can't this be
  run on newer JRE? If so, it would need the startup script to
  hardcode the java jvm path to that specific variant

OpenBoardView:
- cmake has a convenient "-B build" to that doesn't require mkdir

or-tools-java:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- does this really makedepend on git? It it checking out more
  stuff? If so it should be revisited to add those repos to the
  source=() array and popule them otherwise they get downloaded
  on each run
- could use some indention in package()

parcimonie-sh-git
- pkgdesc looks a bit overly long, should be cut a bit

pass-sshaskpass:
- should not pull over plaintext git:// but git+https to provide
  endpoint verification and encryption during transit
- pkgname is wrong as this is in fact a -git package, but the name
  makes it a static version one

pdfposter:
- repo seems to contain unit tests, would be worth running in a
  check() function
- uses setuptools entrypoing wrapper, therefor python-setuptools
  is not just a makedepends but a hard requirement

perl-ntlm:
- seems to lack depends on perl, i hardly doubt a perl module works
  without a single dependency :)
- could use TLS in url and source, because why not :}

pinentry-rofi:
- missing depends on rofi
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- License is a non common one but the distribution of anything
  indicating the license is missing.

python-requests-gpgauthlib:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- missing requires on python-gnupg and python-requests
- repo seems to contain unit tests, would be worth running in a
  check() function

talosctl:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- could use the new set of go binary hardening flags so
  sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS
- Go packages are not 'any' arch, they are architecture dependent

tbt:
- cmake has a convenient "-B build" to that doesn't require mkdir
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- any reason why its deleting the documentation in /usr/share/doc?

thunderbird-nightly:
- this is not a source build and hence must be postfixed with -bin

tomighty:
- is a static version 0.7.2 but doesn't use a static source, the branch
  for 0.7 could change at any point. must depend on a non changing state
- convert operations should be done during build

tpacpi-bat-git:
- should not pull over plaintext git:// but git+https to provide
  endpoint verification and encryption during transit
- normally its a bit better to have a pkgver that actually
  has any meaning in what kind of version the installed pkg
  matches, like 0.7.r21.b098747 instead of 94.b098747
  git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
- pkgdesc looks a bit overly long, should be cut a bit

wrench:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- missing depends on python-requests and python-click
- uses setuptools entrypoing wrapper, therefor python-setuptools
  is not just a makedepends but a hard requirement
- repo seems to contain unit tests, would be worth running in a
  check() function

xfce-polkit:
- autotools stuff should be run during prepare()
- should not have the conflicts on -git, its always the special
  variants that conflict on the regular variant, not the other way around

xfce-polkit-git:
- autotools stuff should be run during prepare()
- normally its a bit better to have a pkgver that actually
  has any meaning in what kind of version the installed pkg
  matches, like 0.7.r21.b098747 instead of 94.b098747
  git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'


EOF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20200516/ffe06dc1/attachment.sig>


More information about the aur-general mailing list