On 2019-03-05 23:53, Brett Cornwall wrote:

...

url='https://releng.io/' arch=('any') license=('BSD')

I don't see this license in the project. It needs to be in the project, and if it is indeed BSD licensed you need to copy the license to "$pkgdir/usr/share/licenses/$pkgname/" [1]

Oops... I suck at computers and managed to end up in the releng-tool-examples repo. I should go to bed. So I see that the license is indeed in upstream and you've included it in the package. Derp.

...

source=("$pkgname-$pkgver::git+https://github.com/releng-tool/releng-tool.git#tag=v$pkgver")

I see that you're the maintainer of upstream; Why not create a release on Github and then download the tarball here? Typically, pulling sources via git is for '-git' packages.

You should use the release tarball instead of relying on git then, which would be another dependency in this package.

...

sha512sums=('SKIP')

Having a tarball release will mean that you can have checksum verification as well.

^Still applies.

On 2019-03-06 1:59 AM, Doug Newgard via aur-general wrote:

On Tue, 5 Mar 2019 23:53:10 -0700 Brett Cornwall via aur-general <aur-general@archlinux.org> wrote:

...

Capitalize the T!

Can do!

...

You're using python-setuptools, so you'll want to set that in makedepends instead of python.

Noted.

Also missing git as a makedepends. Might want to build in a clean chroot and see what else you're missing. python shouldn't be in the makedepends, as it should be in the global deps array, as stated below.

Based off a comment in a related thread, I may be opting to switching away from the VCS type to just an archive. If for some reason I still decide to stick with Git, I will make sure the dependency is there. I will try to perform additional checks to make sure I have the required dependencies listed.

...

...

package() { depends=('python')

The depends() should just go to the top alongside makedepends for this package. You probably saw this in the examples for the python packaging standards, but this is typically used for a 'split package', i.e. using one PKGBUILD to build versions for both python2 and python3. Since you're only building for python 3 depends() should go to the top.

Thanks. Based off some comments in a related thread, I may go back to my initial attempt in supporting split-packages (as the tool supports running on both Python major versions). I will try to make sure I cleanup the dependencies on next pass. Truthfully, I did not even notice it said "makedepends"; I just blindly assumed it was the way to list dependencies. Time to re-read some more documentation.

...

...

python setup.py install --root="$pkgdir" --optimize=1

Go ahead and add a --skip-build here since you already built earlier.

Odd, I swear I added that. Good catch.

...

[...]

...

install -dm 755 "$pkgdir/usr/share/bash-completion/completions" install -m644 scripts/releng-tool-completion "$pkgdir/usr/share/bash-completion/completions/releng-tool"

No need to create the directory beforehand; This can be shortened into:

install -Dm644 scripts/releng-tool-completion "$pkgdir/usr/share/bash-completion/completions/releng-tool"

I recall seeing another PKGBUILD definition splitting the install operations in two-parts (although I cannot seem to find it at this time). I assume it was to prevent the risk of a host adjusting their umask value and producing unexpected results (i.e. the way submitted ensures directories are built with "755" permissions and the install script is installed with "644" permissions. Although this scrutiny falls apart when the submitted PKGBUILD performs the license installation with a care to ensure an explicit permission set for any generated folders. I do not mind simplifying the change into a single line. I am just curious why this is not an issue (maybe I am overlooking something)? --- The comments are appreciated. On a thread note, I am curious to know why I only saw a single Email for this response, which clearly shows two individuals comments. My curiosity is only driven by my concern to ensure I am receiving Emails properly. If what I receive is an expected output from the mailing list, this comment can be disregarded.

On 2019-03-06 2:03 AM, DJ Lucas (LFS) wrote:

...

pkgname=releng-tool

Python 2/3?

The package type does support either Python variant. When I was first making the package, I first attempted to build the PKGBUILD file following the "Python package guidelines" [1]; however, I felt that it would be incorrect to label the package with such a prefix. The guidelines mention that the prefix is either for "[Python] library modules" or a package that "is strongly coupled to the Python ecosystem". While the tool is built and uses Python for support, it is not specifically designed Python-only projects/etc. My choice to have to use the project's common entry-point/package name felt right to me after seeing the Bazaar package [2] doing the same thing. That being said, if I made an incorrect assumption here, I can make any appropriate change. In additional to the note being either Python 2 or 3, as mentioned above, the tool does support either. After moving from a Python-prefixed package I still had an initial PKGBUILD which would build two types of packages: releng-tool and releng-tool-27. The idea would be that if a host only had one variant of Python, releng-tool could still be installed on the system. Since I am hoping the tool will introduce the entry-point "releng-tool", I did not want to try to also introduce a second entry point "releng-tool-27" (picked to avoid conflicts) primarily since I did not want the Bash completion to hang on "releng-tool" waiting for either a space or a dash before providing additional information. Although now thinking about it, my decision was most likely incorrect. If a user did install only one of the variants, the completion would handle as "desired". If for some reason both are installed, the user should have the right to be able to auto-complete to either. With that in mind, I will most likely be introducing the second variant as well -- possibly in a fashion such as: pkgbase=releng-tool pkgname=(releng-tool releng-tool27)

Use depends here, makedepends implicitly includes depends.

With the above related to possibly introducing the two package types and a discussion in a related thread indicating I may need "python-setuptools" as a "makedepends" entry, I will be cleaning up the listed dependencies. Hopefully it will be correct in my next version.

If you intend to use a version string and not a specific git commit, then get the versioned tarball from https://github.com/releng-tool/releng-tool/archive/v0.1/releng-tool.tar.gz and provide the sums. Also, since you are the developer, sig? You can add it, as well as other compression formats as part of the release process on GitHub. I think it's add resources, or similar, been a bit.

From my past experience with downloading versioned tarballs from GitHub is that there is no guarantee that the fetched package will always be the same hash (useless this is something that has recently changed; although I cannot seem to find any documentation on this). I stumbled upon the VCS option and figured it would be a "better" approach, but I would agree that while Git may help ensure there is no corruption, it does not guarantee authenticity. I am going to be making another release soon, which I then could include signed/checksum packages of the release into GitHub (as you have mentioned). This followed by moving away from the VCS type to an archive and adding the appropriate sha512 hash can be done (assuming this is the preferred approach).

Personal preference, and likely not very useful here, but use -v for install commands, it could save you some time if something breaks in the future.

I will add the tweak. Something always breaks in the future. Thanks for the suggestions. [1]: https://wiki.archlinux.org/index.php/Python_package_guidelines [2]: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... [3]: https://wiki.archlinux.org/index.php/VCS_package_guidelines