[aur-general] pcb-rnd-svn first package
Hi list, I would like to have some feedback for my first PKGBUILD files for packages. the existing pcb-rnd-svn AUR package is currently broken because the project requires a need dependency: librnd3. thus I decided to create all packages needed/related by it, and fix its optional dependencies. I was able to create all packages on a fresh arch, and checked them against namcap. please let me know if the PKGBUILD are OK so I can submit them. thanks, cuvoodoo
Hi, On 21/07/22 14:15, pcb-rnd--- via aur-general wrote:
Hi list,
I would like to have some feedback for my first PKGBUILD files for packages. the existing pcb-rnd-svn AUR package is currently broken because the project requires a need dependency: librnd3. thus I decided to create all packages needed/related by it, and fix its optional dependencies. I can't find the PKGBUILD you're talking about. I think the list somehow strips or rearranges the attachments.
I was able to create all packages on a fresh arch, and checked them against namcap. Try building in a clean chroot instead, it is a more reliable setup. https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot
Marcin Wieczorek
On Thu, Jul 22, 2021 at 02:20:26PM +0200, Marcin Wieczorek wrote:
I can't find the PKGBUILD you're talking about. I think the list somehow strips or rearranges the attachments.
yes, it seems the tarball got stripped. I've attached them in my previous reply to the first post.
I was able to create all packages on a fresh arch, and checked them against namcap. Try building in a clean chroot instead, it is a more reliable setup. https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot
thanks for pointing it out. this might be simpler than using arch docker images every time.
mmhh, tar.bz2 archive do not seem to be allowed on the list. I've attached all raw files. On Thu, Jul 22, 2021 at 02:15:53PM +0200, pcb-rnd--- via aur-general wrote:
Hi list,
I would like to have some feedback for my first PKGBUILD files for packages. the existing pcb-rnd-svn AUR package is currently broken because the project requires a need dependency: librnd3. thus I decided to create all packages needed/related by it, and fix its optional dependencies. I was able to create all packages on a fresh arch, and checked them against namcap. please let me know if the PKGBUILD are OK so I can submit them.
thanks, cuvoodoo
Hi, the attachments are good now.
# Maintainer: CuVoodoo <pcb-rnd@cuvoodoo.info> pkgname=camv-rnd pkgver=1.0.0 pkgrel=1 pkgdesc="free/open source, small, flexible viewer for PCB-related CAM file formats" url="http://www.repo.hu/projects/camv-rnd/" arch=('i686' 'x86_64') license=('GPL2') depends=('librnd3' 'freetype2') provides=('camv-rnd') source=("http://www.repo.hu/projects/$pkgname/releases/$pkgname-$pkgver.tar.gz") sha256sums=('edf86c4d7d94364abc2b20bbfb3a78501a899f0b324ce0ecda632efd867a1a15') I don't think there is any reason in a package providing it's exact name.
# Maintainer: CuVoodoo <pcb-rnd@cuvoodoo.info> pkgname=fungw pkgver=1.2.0 pkgrel=1 pkgdesc="tiny, portable library written in C (C89) that manages dynamic function calls across different programming languages" url="http://www.repo.hu/projects/fungw/" arch=('i686' 'x86_64') license=('LGPL2') depends=('genht') # fungw is not strictly dependant on genht (it also embeds it), but other packages relying on fungw also can optionally use external genht, and we don't want them to use different versions This reasoning is interesting. If it embeds it, can it "provide" genht too?
# Maintainer: CuVoodoo <pcb-rnd@cuvoodoo.info> pkgname=librnd3-svn pkgver=r32924 pkgrel=1 pkgdesc="free/open source, flexible, modular two-dimensional CAD engine" url="http://www.repo.hu/projects/librnd/" arch=('i686' 'x86_64') license=('GPL') depends=() Empty depends array can be removed (in other places too).
Marcin Wieczorek
thanks for the comments. I also fixed the maintainer/contributor name to include the previous maintainer. On Thu, Jul 22, 2021 at 02:31:54PM +0200, Marcin Wieczorek wrote:
pkgname=camv-rnd pkgver=1.0.0 pkgrel=1 pkgdesc="free/open source, small, flexible viewer for PCB-related CAM file formats" url="http://www.repo.hu/projects/camv-rnd/" arch=('i686' 'x86_64') license=('GPL2') depends=('librnd3' 'freetype2') provides=('camv-rnd') source=("http://www.repo.hu/projects/$pkgname/releases/$pkgname-$pkgver.tar.gz") sha256sums=('edf86c4d7d94364abc2b20bbfb3a78501a899f0b324ce0ecda632efd867a1a15') I don't think there is any reason in a package providing it's exact name.
I did not know you don't need to add 'provide' if the name is the same as the package. thanks for pointing it out, I'll remove them in the non-svg packages
# fungw is not strictly dependant on genht (it also embeds it), but other packages relying on fungw also can optionally use external genht, and we don't want them to use different versions This reasoning is interesting. If it embeds it, can it "provide" genht too?
no, it can't provide genht, it only uses its own copy as fallback if the library is not available. this strategy/dependency was recommended by the author of all this software.
# Maintainer: CuVoodoo <pcb-rnd@cuvoodoo.info> pkgname=librnd3-svn pkgver=r32924 pkgrel=1 pkgdesc="free/open source, flexible, modular two-dimensional CAD engine" url="http://www.repo.hu/projects/librnd/" arch=('i686' 'x86_64') license=('GPL') depends=() Empty depends array can be removed (in other places too).
fixed
I did not know you don't need to add 'provide' if the name is the same as the package. thanks for pointing it out, I'll remove them in the non-svg packages provides: An array of additional packages that the software provides the features of. The package itself cannot be "additional". At least I've always understood it that way.
# fungw is not strictly dependant on genht (it also embeds it), but other packages relying on fungw also can optionally use external genht, and we don't want them to use different versions This reasoning is interesting. If it embeds it, can it "provide" genht too?
no, it can't provide genht, it only uses its own copy as fallback if the library is not available. this strategy/dependency was recommended by the author of all this software. Fair enough.
Also I noticed that the signatures are broken (0 byte files). I don't think it even is PGP. In case you ever contact the upstream make sure to mention this and the fact that they should have https. I'm not sure about that tho, because the authors seem to negate the value of HTTPS or at least point out "false sense of security". http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=https Marcin Wieczorek
On Thu, Jul 22, 2021 at 02:45:38PM +0200, Marcin Wieczorek wrote:
Also I noticed that the signatures are broken (0 byte files). I don't think it even is PGP. In case you ever contact the upstream make sure to mention this and the fact that they should have https. I'm not sure about that tho, because the authors seem to negate the value of HTTPS or at least point out "false sense of security". http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=https
I already pointed out that some .asc are missing or empty. that should be fixed in the next release according to the author. as for the https, I also discussed with the author on IRC, and the http choice is deliberate because the "false" securi ty feeling HTTPS provide are not worth the effort, and he prefers pointing out the anchor of trust issue (as you found in the article). also the signatures provided on the release page only use x.509 certificates. AFAICS only GPG signatures are supported by PKGBUILD. this is why I did not include the signatures.
On 21/07/22 14:54, pcb-rnd@cuvoodoo.info wrote:
On Thu, Jul 22, 2021 at 02:45:38PM +0200, Marcin Wieczorek wrote:
Also I noticed that the signatures are broken (0 byte files). I don't think it even is PGP. In case you ever contact the upstream make sure to mention this and the fact that they should have https. I'm not sure about that tho, because the authors seem to negate the value of HTTPS or at least point out "false sense of security". http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=https
I already pointed out that some .asc are missing or empty. that should be fixed in the next release according to the author.
as for the https, I also discussed with the author on IRC, and the http choice is deliberate because the "false" securi ty feeling HTTPS provide are not worth the effort, and he prefers pointing out the anchor of trust issue (as you found in the article).
also the signatures provided on the release page only use x.509 certificates. AFAICS only GPG signatures are supported by PKGBUILD. this is why I did not include the signatures.
Ok. I'm glad that you considered that and already took action. You could always do some prepare() magic to check the sigs. In current case the packages lacks security measures, only the sums provide integrity. Am I right? Marcin Wieczorek
On Thu, Jul 22, 2021 at 03:32:39PM +0200, Marcin Wieczorek wrote:
also the signatures provided on the release page only use x.509 certificates. AFAICS only GPG signatures are supported by PKGBUILD. this is why I did not include the signatures.
Ok. I'm glad that you considered that and already took action. You could always do some prepare() magic to check the sigs. In current case the packages lacks security measures, only the sums provide integrity. Am I right?
yes, you are right, there is only the sum currently, and the signature is not checked. thanks for mentioning that is could be done in prepare(). I could not find a way to do checks before extraction, since prepare() is only after extraction (not required for checking the archives). do you know a good package example which also verifies x.509 signatures in prepare() (which does not require large/unusual dependencies)? I'm happy to copy it to these projects.
yes, you are right, there is only the sum currently, and the signature is not checked. thanks for mentioning that is could be done in prepare(). I could not find a way to do checks before extraction, since prepare() is only after extraction (not required for checking the archives).
do you know a good package example which also verifies x.509 signatures in prepare() (which does not require large/unusual dependencies)? I'm happy to copy it to these projects.
Openssl would be your only dependency. Prepare extracts the tarball, but it should still be available in the $srcdir, right? And no, I've never seen such example. Marcin Wieczorek
participants (2)
-
Marcin Wieczorek
-
pcb-rnd＠cuvoodoo.info