Post

pkgsrc (5/6)

This post is an automatic translation from French. You can read the original version here.

I know, I know … I’m late! Sorry, the week was a bit rough!

Anyway, here are my notes on the latest video by Imil. We continue and finish porting the Python app Archey4 to NetBSD. On the agenda: patching, linting … and sharing directory trees!

Oops …

In what we did last time, a small mistake crept in. Indeed, the naming of zip archives on GitHub is not based on the app name, but on the version number used for the tag:

% cd /usr/pkgsrc/wip/py-archey4

% make distclean
===> Cleaning for py39-archey4-4.13.4
===> Dist cleaning for py39-archey4-4.13.4

% make fetch
=> Bootstrap dependency digest>=20211023: found digest-20220214
=> Fetching archey4-4.13.4.zip
=> Total size: 160197 bytes
Requesting https://github.com/HorlogeSkynet/py39-archey4/archive/refs/tags/v4.13.4.zip
ftp: Error retrieving file `404 Not Found'
fetch: Unable to fetch expected file archey4-4.13.4.zip
[...]

As you can see above, pkgsrc is looking for archey4-4.14.4.zip while on GitHub, the zip URL is:

https://github.com/HorlogeSkynet/archey4/archive/refs/tags/v4.13.4.zip

No worries, we’ll make a few changes:

VERS= 	4.13.4
DISTNAME=	${VERS}
GITHUB_PROJECT=	archey4
GITHUB_TAG=	refs/tags/${VERS}
PKGNAME=	${PYPKGPREFIX}-${GITHUB_PROJECT}-${VERS}
WRKSRC=		${WRKDIR}/${GITHUB_PROJECT}-${VERS}

This time, since pkgsrc uses special variables for the GITHUB site, we build GITHUB_TAG so that the correct archive is downloaded. We also need to adjust our WRKSRC path, since our sources are no longer in the same location.

Our final Makefile therefore looks like this:

# $NetBSD$
VERS=           4.13.4

GITHUB_PROJECT= archey4
GITHUB_TAG=     refs/tags/v${VERS}
DISTNAME=       ${VERS}
PKGNAME=        ${PYPKGPREFIX}-${GITHUB_PROJECT}-${VERS}

CATEGORIES=     sysutils
MASTER_SITES=   ${MASTER_SITE_GITHUB:=HorlogeSkynet/}
EXTRACT_SUFX=   .zip

MAINTAINER=     maintainer@rancune.org
HOMEPAGE=       https://github.com/HorlogeSkynet/archey4
COMMENT=        Archey is a simple system information tool written in Python
LICENSE=        gnu-gpl-v3

DEPENDS+=       ${PYPKGPREFIX}-distro>=1.3:../../devel/py-distro
DEPENDS+=       ${PYPKGPREFIX}-netifaces>=0.10:../../net/py-netifaces

WRKSRC=         ${WRKDIR}/${GITHUB_PROJECT}-${VERS}

.include "../../lang/python/egg.mk"
.include "../../lang/python/application.mk"
.include "../../mk/bsd.pkg.mk"

We still need to test it, after updating distinfo and PLIST:

% make clean
===> Cleaning for py39-archey4-4.13.4

% make disclean
===> Cleaning for py39-archey4-4.13.4
===> Dist cleaning for py39-archey4-4.13.4


% make fetch
=> Bootstrap dependency digest>=20211023: found digest-20220214
=> Fetching 4.13.4.zip
=> Total size: 160197 bytes
Requesting https://github.com/HorlogeSkynet/archey4/archive/refs/tags/v4.13.4.zip
Redirected to https://codeload.github.com/HorlogeSkynet/archey4/zip/refs/tags/v4.13.4
Requesting https://codeload.github.com/HorlogeSkynet/archey4/zip/refs/tags/v4.13.4
   156 KiB    1.41 MiB/s
160197 bytes retrieved in 00:00 (1.40 MiB/s)

% make makedistinfo
=> Bootstrap dependency digest>=20211023: found digest-20220214

% make
=> Bootstrap dependency digest>=20211023: found digest-20220214
===> Skipping vulnerability checks.
WARNING: No /var/db/pkg/pkg-vulnerabilities file found.
WARNING: To fix run: `/usr/pkg/sbin/pkg_admin -K /var/db/pkg fetch-pkg-vulnerabilities'.
===> Building for py39-archey4-4.13.4
[...]
copying archey/logos/raspbian.py -> build/lib/archey/logos
copying archey/logos/rhel.py -> build/lib/archey/logos
copying archey/logos/rocky.py -> build/lib/archey/logos
copying archey/logos/slackware.py -> build/lib/archey/logos
copying archey/logos/ubuntu.py -> build/lib/archey/logos
copying archey/logos/windows.py -> build/lib/archey/logos
copying archey/py.typed -> build/lib/archey

% sudo make deinstall
===> Deinstalling for py39-archey4-4.13.4
Running /usr/pkg/sbin/pkg_delete -K /var/db/pkg  py39-archey4-4.13.4

% make print-PLIST > PLIST

% make stage-install
[...]
=> Checking file-check results for py39-archey4-4.13.4
=> Checking for non-existent script interpreters in py39-archey4-4.13.4
=> Checking file permissions in py39-archey4-4.13.4
=> Checking for PIE in py39-archey4-4.13.4
=> Checking for RELRO in py39-archey4-4.13.4
=> Checking for missing run-time search paths in py39-archey4-4.13.4
=> Checking for work-directory references in py39-archey4-4.13.4

% sudo make install
=> Bootstrap dependency digest>=20211023: found digest-20220214
===> Skipping vulnerability checks.
WARNING: No /var/db/pkg/pkg-vulnerabilities file found.
WARNING: To fix run: `/usr/pkg/sbin/pkg_admin -K /var/db/pkg fetch-pkg-vulnerabilities'.
=> Creating binary package /usr/pkgsrc/wip/py-archey4/work/.packages/py39-archey4-4.13.4.tgz
===> Building binary package for py39-archey4-4.13.4
=> Creating binary package /usr/pkgsrc/packages/All/py39-archey4-4.13.4.tgz
===> Installing binary package of py39-archey4-4.13.4

Our Makefile is all set!!!!!

Let’s finish porting our app

As we saw last time, while the package seems to install fine, it doesn’t work on NetBSD yet. We’ll need to modify the code and write patches. During the video, Imil limited himself – for time reasons – to commenting out the parts of the code that were causing issues. I won’t detail here which parts were commented out, but rather remind you how to create a patch with pkgsrc.

Let’s say we want to modify the file temperature.py. We use the pkgvi tool, which we saw previously:

% pkgvi work/archey4-4.13.4/archey/entries/temperature.py

When we save and close the file, the diff is automatically generated. (I literally love this tool!)

All that’s left is to build the patch:

% mkpatches

A directory is created in our package, named “patches”. It contains the generated patches.

We now need to add the hash of our patches to our distinfo file. Once again, a single command is all it takes:

% make mps

Simple, right? All that’s left is to recompile, test … But you already know how to do that!

How about my package? Do you like it?

If the job is well done, all that’s left is to publish it. But since we’re conscientious people, we’ll still check the quality of our work!

To do this, there’s a tool called “pkglint” that validates your package:

% pkglint
ERROR: DESCR:1: DESCR files must not have TODO lines.
WARN: DESCR:8: Line too long (should be no more than 80 characters).
WARN: DESCR:12: Line too long (should be no more than 80 characters).
WARN: DESCR:15: Line too long (should be no more than 80 characters).
WARN: DESCR:17: Line too long (should be no more than 80 characters).
WARN: DESCR:19: Line too long (should be no more than 80 characters).
WARN: DESCR:21: Line too long (should be no more than 80 characters).
NOTE: Makefile:4: Variable values should be aligned with tabs, not spaces.
WARN: Makefile:15: COMMENT should not contain "is a".
ERROR: distinfo: Patch "patches/patch-archey_entries_temperature.py.orig" is not recorded. Run "make makepatchsum".
ERROR: patches/patch-archey_entries_temperature.py:3: Each patch must be documented.
3 errors, 7 warnings and 1 note found.
(Run "pkglint -e" to show explanations.)
(Run "pkglint -fs" to show what can be fixed automatically.)
(Run "pkglint -F" to automatically fix some issues.)

Yikes! Good thing this package quality validation tool exists! Indeed, I forgot to fill in the DESCR file, which must contain a description of the package! I also used spaces instead of tabs in my Makefile.

So I follow the advice given, and run the test again:

% pkglint
Looks fine.

There we go! Our package looks great!!!!!

Sharing your pkgsrc tree across multiple machines

At the beginning of the video, Imil presented a pkgsrc use case that I find very interesting. Imagine that my pkgsrc tree is in userspace, and I want to share it across different machines.

I can use NFS, sshfs, or something else, to mount my tree in the directory of my choice. It’s as simple as a mount! However, I don’t want to share the packages tree along with the work directory. (This could cause issues if my architectures are different, for example.)

We can solve this problem with the mk.conf file which, as a reminder, allows you to configure pkgsrc:

WRKOBJDIR=		/home/rancune/tmp/pkgsrc/work
DISTDIR=		/home/rancune/Downloads

The WRKOBJDIR variable, as you’ve probably guessed, specifies the base directory in which packages will be compiled.

DISTDIR, for its part, contains the location where files will be downloaded during a “make fetch”, for example.

For the curious, all useful variables are documented here.

Conclusion

Our package is now ready, but more importantly we got to see how pkgsrc supports and handles Python apps. We’ll quickly see the rest of all this (uh … this afternoon actually! I’m sooo laaate), as Imil was talking about looking into Go!

See you soon,

Rancune.

This post is licensed under CC BY 4.0 by the author.