Review request: toolshed & toolshed-hg

hpmachining · 2018-05-27 18:33:51

Here are 2 PKGBUILD files for Toolshed that I would like reviewed, please. Toolshed is a set of tools for 6809 / 6309 cross-development to go along with the lwtools package I posted about here.

This is my first try at PKGBUILDs using a VCS repository, so any feedback will be appreciated.

One thing I am unsure about is my handling of the licensing. I got the "copyright" file from a Debian package created by one of the upstream developers. I also extracted a "LICENSE" file from one of the source files in the casm/src/ directory in the source tree. Is this sufficient?

toolshed PKGBUILD

# Maintainer: Paul Hentschel <paul at hpminc dot com>

pkgname=toolshed
pkgver=2.2
pkgrel=1
pkgdesc="Utilities for Tandy Color Computer and Dragon microcomputers cross-development."
arch=('x86_64')
url="http://toolshed.sourceforge.net"
license=('custom')
groups=('os9-dev')
depends=('glibc')
makedepends=('mercurial' 'discount')
source=("$pkgname-$pkgver::hg+http://hg.code.sf.net/p/toolshed/code#tag=v2_2"
        "copyright")
sha256sums=('SKIP'
            'd8c35bfb5ed2c18e21303c263786788ff8b4b25a7ce940cf3d108b4e7e33d645')

build() {
  cd "$pkgname-$pkgver"
  make -C build/unix 
}

package() {
  cd "$pkgname-$pkgver"
  make DESTDIR="$pkgdir/" -C build/unix install

  # Install license files
  sed -n '/Copyright/,/PARTICULAR PURPOSE./p' casm/src/util.h > LICENSE
  install -Dm644 -t "$pkgdir/usr/share/licenses/$pkgname" "$srcdir"/copyright LICENSE
  
  # Install image for HTML manual
  install -m644 doc/cover.jpg "$pkgdir/usr/share/doc/$pkgname/"
}

# vim:set ts=2 sw=2 et:

toolshed-hg PKGBUILD

# Maintainer: Paul Hentschel <paul at hpminc dot com>

pkgname=toolshed-hg
pkgver=r672.041c3b1b927b
pkgrel=1
pkgdesc='Utilities for Tandy Color Computer and Dragon microcomputers cross-development.'
arch=('x86_64')
url='http://toolshed.sourceforge.net'
license=('custom')
groups=('os9-dev')
depends=('glibc')
makedepends=('mercurial' 'discount')
conflicts=("${pkgname%-hg}")
provides=("${pkgname%-hg}")
source=("${pkgname%-hg}::hg+http://hg.code.sf.net/p/toolshed/code"
        "copyright")
sha256sums=('SKIP'
            'd8c35bfb5ed2c18e21303c263786788ff8b4b25a7ce940cf3d108b4e7e33d645')

pkgver() {
  cd "$srcdir/${pkgname%-hg}"
  printf "r%s.%s" "$(hg identify -n)" "$(hg identify -i)"
}

build() {
  cd "$srcdir/${pkgname%-hg}"
  make -C build/unix 
}

package() {
  cd "$srcdir/${pkgname%-hg}"
  make DESTDIR="$pkgdir/" -C build/unix install

  # Install license files
  sed -n '/Copyright/,/PARTICULAR PURPOSE./p' casm/src/util.h > LICENSE
  install -Dm644 -t "$pkgdir/usr/share/licenses/$pkgname" "$srcdir"/copyright LICENSE
  
  # Install image for HTML manual
  install -m644 doc/cover.jpg "$pkgdir/usr/share/doc/${pkgname%-hg}/"
}

# vim:set ts=2 sw=2 et:

copyright file

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: toolshed
Source: https://sourceforge.net/projects/toolshed/

Files: *
Copyright: 2004 Boisy G. Pitre
License: Public Domain

Files: casm/*
Copyright: 2004 Chet Simpson, Digial Asphyxia
License: artistic

Files: makewav/*
Copyright: 2007 Tim Lindner
License: Public Domain

Files: superdos/*
Copyright: 1986 Grosvenor, Compusense.
License: Public Domain

Files: mamou/*
Copyright: 2004 Boisy G. Pitre
License: Public Domain

Files: hdbdos/*
Copyright: 2004 Boisy G. Pitre
License: Public Domain

Files: cocoroms/*.asm
Copyright: 1982 Tandy
License: Public Domain

Files: debian/*
Copyright: 2013 Tormod Volden <debian.tormod@gmail.com>
License: artistic

Trilby · 2018-05-27 19:06:39

As you you fetching a specific tag for the first one, it should have a checksum.

loqs · 2018-05-27 20:10:34

The artistic license covering casm/* https://sourceforge.net/p/toolshed/code … m/src/as.c is probably PerlArtistic supplied in the licenses package.

eschwartz · 2018-05-27 23:27:38

hpmachining wrote:

One thing I am unsure about is my handling of the licensing. I got the "copyright" file from a Debian package created by one of the upstream developers. I also extracted a "LICENSE" file from one of the source files in the casm/src/ directory in the source tree. Is this sufficient?

It's more than sufficient, Debian has far stricter standards than we do. The only thing you need to install is the license you extracted from one of the CASM files. The Debian file giving an extensive breakdown of which source files are licensed how, is, not something we really care about.

loqs wrote:

The artistic license covering casm/* https://sourceforge.net/p/toolshed/code … m/src/as.c is probably PerlArtistic supplied in the licenses package.

The contents are not the same...

https://opensource.org/licenses/Artistic-1.0
https://git.archlinux.org/svntogit/pack … s/licenses

Last edited by eschwartz (2018-05-27 23:31:41)

loqs · 2018-05-27 23:46:13

@Eschwartz thanks for the clarification this seems to be the full license for casm https://web.archive.org/web/20040909004 … ge=license
would you list that as covering the whole work?

eschwartz · 2018-05-28 00:25:40

The rest of the work is public domain, which could be mentioned in the licenses=() array too. In practice, linking PD code to code under some OSS license means you must respect said OSS license, not the PD grant, which means PD doesn't really matter for the built binary result...

I'm confused why the file comments seem to restrict things more than the license file you dug up from the Internet Archive (which is indeed the PerlArtistic license).

Last edited by eschwartz (2018-05-28 00:27:30)

hpmachining · 2018-05-28 01:33:58

Trilby wrote:

As you you fetching a specific tag for the first one, it should have a checksum.

Thank you. I didn't know that. I have been relying on 'makepkg -g' for checksums. I guess I thought the VCS took care of verifying the integrity. I don't know how to do checksums for a repository. I tried getting the hash using 'hg log -r v2_2 --template "{node}\n"' and switching to sha1sums in the PKGFILE, but that didn't work.

==> Validating source files with sha1sums...
    toolshed-2.2 ... NOT FOUND
    copyright ... Passed
==> ERROR: One or more files did not pass the validity check!

I'll keep digging, but if you can point me in the right direction, that would be great!

Eschwartz wrote:

I'm confused why the file comments seem to restrict things more than the license file you dug up from the Internet Archive (which is indeed the PerlArtistic license).

Do you think putting both in the license array ('PerlArtistic' 'custom') and dropping the copyright file would be the right way to handle this?

Thanks for everyone's feedback!

eschwartz · 2018-05-28 02:11:31

There are no checksums for git tags. checksums are meant to prevent file corruption, git does this builtin.

If you want to guarantee you're running the same code the maintainer used, then many people will say you should use the commit hash of the tag, instead of the tag itself.

hpmachining wrote:

Eschwartz wrote:
I'm confused why the file comments seem to restrict things more than the license file you dug up from the Internet Archive (which is indeed the PerlArtistic license).
Do you think putting both in the license array ('PerlArtistic' 'custom') and dropping the copyright file would be the right way to handle this?

Yes. Well, neither one is "wrong", we won't stop you from doing it if you really want, but I think it's pretty pointless and would drop it myself.

But it isn't custom, it is ('PublicDomain' 'PerlArtistic'), since most of the code is public domain.

Trilby · 2018-05-28 10:36:38

Sorry, I was mistaken about the checksum, but in that case, both packages should have an -hg suffix as they are both allowing the upstream VCS to determine what code is actually retrieved.

loqs · 2018-05-28 12:32:11

@Trilby then the systemd package should have a git suffix? https://git.archlinux.org/svntogit/pack … ystemd#n22

Last edited by loqs (2018-05-28 12:32:23)

Trilby · 2018-05-28 12:44:20

Hmm ... I guess there's precedent. But I don't have to like it.

hpmachining · 2018-05-28 22:15:37

Thanks for all the feedback, everyone. It has been very helpful.

Eschwartz wrote:

But it isn't custom, it is ('PublicDomain' 'PerlArtistic'), since most of the code is public domain.

Ok. I had the 'custom' in there for the extracted comments in the LICENSE file. I didn't think I needed to worry about the PD code.

Lone_Wolf · 2018-05-29 14:17:03

The systemd package retrieves a specific commit (using checkout in prepare() function) , so does control which version they get.

Eschwartz wrote:

If you want to guarantee you're running the same code the maintainer used, then many people will say you should use the commit hash of the tag, instead of the tag itself.

I consider myself one of those "many people".
Please use the commit hash, hpmachining.

Last edited by Lone_Wolf (2018-05-29 14:17:50)

hpmachining · 2018-05-29 17:59:47

Lone_Wolf wrote:

Please use the commit hash, hpmachining.

Will do. Thanks.

eschwartz · 2018-05-29 19:16:43

Trilby wrote:

Sorry, I was mistaken about the checksum, but in that case, both packages should have an -hg suffix as they are both allowing the upstream VCS to determine what code is actually retrieved.

Trilby wrote:

Hmm ... I guess there's precedent. But I don't have to like it.

I don't understand this reasoning, an HTTPS server is also being allowed to determine what code is actually retrieved by choosing which files to serve you.

The solution is to use checksums in the case of file sources, and use pinned commit hashes for VCS sources.

But it doesn't really matter, that's not the definition of a VCS package. VCS packages are not "I don't know what code the server may be lying to me by sending", it is "the package dynamically updates itself every time a new commit is published on the server".

-hg is not meant to *warn* you that the developer might force-push and overwrite a tag, against the intention of the package. It's meant to notify you that the package is *intended* to periodically update itself with new versions.

Trilby · 2018-05-29 19:53:30

A non-VCS PKGBUILD should make the same package every time. Perhaps the upstream source for some old version would no longer be available, but then makepkg would just error out due to the source failing to download. So does this non-VCS PKGBUILD make the same package every time (and does the systemd PKGBUILD make the same package every time)? If so, it must download the same source code every time, in which case there can be a checksum on whatever that source is. If there can't be a checksum, it must be due to the source being able to change, in which case the PKGBUILD would not build the same package.

eschwartz · 2018-05-29 20:30:13

You cannot checksum a directory. You can checksum a git revision, but that's what the pinned commit hash is...

And it's still irrelevant.

"A non-VCS PKGBUILD should make the same package every time." ==> this is not true, upstreams will sometimes silently replace tarballs. Assuming checksums are in play, the build will fail, but once you verify the source is still okay, you're still rebuilding the same version only it's actually different code.

Again, the definition of a VCS package is that it is *intended* to change. If it isn't intended to change, but it changes anyway, then that is gross but it's still not a VCS package. It's upstream silently modifying their stable release code.

Last edited by eschwartz (2018-05-29 20:31:08)

Trilby · 2018-05-29 20:35:22

Eschwartz wrote:

"A non-VCS PKGBUILD should make the same package every time." ==> this is not true, upstreams will sometimes silently replace tarballs. Assuming checksums are in play, the build will fail...

Exactly my point. If there is no checksum, then what you go on to describe as "gross" will fly by under the radar where a checksum would have flagged it as out of the ordinary.

Arch Linux

#1 2018-05-27 18:33:51

Review request: toolshed & toolshed-hg

#2 2018-05-27 19:06:39

Re: Review request: toolshed & toolshed-hg

#3 2018-05-27 20:10:34

Re: Review request: toolshed & toolshed-hg

#4 2018-05-27 23:27:38

Re: Review request: toolshed & toolshed-hg

#5 2018-05-27 23:46:13

Re: Review request: toolshed & toolshed-hg

#6 2018-05-28 00:25:40

Re: Review request: toolshed & toolshed-hg

#7 2018-05-28 01:33:58

Re: Review request: toolshed & toolshed-hg

#8 2018-05-28 02:11:31

Re: Review request: toolshed & toolshed-hg

#9 2018-05-28 10:36:38

Re: Review request: toolshed & toolshed-hg

#10 2018-05-28 12:32:11

Re: Review request: toolshed & toolshed-hg

#11 2018-05-28 12:44:20

Re: Review request: toolshed & toolshed-hg

#12 2018-05-28 22:15:37

Re: Review request: toolshed & toolshed-hg

#13 2018-05-29 14:17:03

Re: Review request: toolshed & toolshed-hg

#14 2018-05-29 17:59:47

Re: Review request: toolshed & toolshed-hg

#15 2018-05-29 19:16:43

Re: Review request: toolshed & toolshed-hg

#16 2018-05-29 19:53:30

Re: Review request: toolshed & toolshed-hg

#17 2018-05-29 20:30:13

Re: Review request: toolshed & toolshed-hg

#18 2018-05-29 20:35:22

Re: Review request: toolshed & toolshed-hg

Board footer