On 2026/06/30 18:02, Jeremie Courreges-Anglas wrote:
>
> I import all my new ports with portimport(1), from /usr/ports/mystuff.
> I feel like it's always been the preferred way to run it, and using
> mystuff should be the preferred way to handle *new* ports in general
> (not so much for updates). Sadly when run from mystuff without
> specifying -p it has always suffered from an annoying error message
> when, right after import, the script tries to cd
> $portsdir/pkgpath-blah and run cvs update:
>
> cvs server: failed to create lock directory for `/cvs' (/cvs/#cvs.lock):
> Permission denied
> cvs server: failed to obtain dir lock in repository `/cvs'
> cvs [server aborted]: read lock failed - giving up
>
> The problem is that $portsdir here is computed from $PWD and thus
> includes mystuff. The error message is just super unhelpful.
>
> Fixing this for the common case is easy: use /usr/ports base directory
> for running cvs update after import. People who use a different
> PORTSDIR can specify -p. I don't understand how the current
> portimport(1) would avoid puking errors with non-default PORTSDIR
> anyway.
>
> Test run using an already imported directory. I just tweaked the
> patched portimport to use cvs -n.
>
> ritchie /usr/ports/mystuff/devel/libigloo$ ls /usr/ports/devel/libigloo
> ls: /usr/ports/devel/libigloo: No such file or directory
> ritchie /usr/ports/mystuff/devel/libigloo$ diff -u
> /usr/ports/infrastructure/bin/portimport /tmp/portimport
> --- /usr/ports/infrastructure/bin/portimport Tue Jun 30 17:26:34 2026
> +++ /tmp/portimport Tue Jun 30 17:51:43 2026
> @@ -67,7 +67,7 @@
>
> read ans?'Does this look correct? [y/n] '
> if [[ $ans == +(y|Y) ]]; then
> - cvs -d$cvsroot import ports/$pkgpath $user ${user}_$timestamp
> + cvs -n -d$cvsroot import ports/$pkgpath $user ${user}_$timestamp
> grep -q "^@new" pkg/P* && echo "New users/groups, remember to commit
> infrastructure/db/user.list!"
> cd "$portsdir/${pkgpath%/*}"
> cvs -d$cvsroot update -AdP ${pkgpath##*/}
> ritchie /usr/ports/mystuff/devel/libigloo$ /tmp/portimport
> Package(s) would be named: libigloo-0.9.5
> Import would go into: ports/devel/libigloo
> Does this look correct? [y/n] y
> U ports/devel/libigloo/Makefile
> U ports/devel/libigloo/distinfo
> U ports/devel/libigloo/pkg/PLIST
> U ports/devel/libigloo/pkg/DESCR
>
> No conflicts created by this import
>
> U libigloo/Makefile
> U libigloo/distinfo
> U libigloo/pkg/DESCR
> U libigloo/pkg/PLIST
> Don't forget to commit the devel/Makefile when you're done!
> /usr/ports/devel
> ritchie /usr/ports/mystuff/devel/libigloo$ ls /usr/ports/devel/libigloo
> CVS/ Makefile distinfo pkg/
> ritchie /usr/ports/mystuff/devel/libigloo$
>
> While here, I can't see how rev 1.8 (use of cvs -R) fixed anything so
> let's just revert that. The diff for the portimport(1) manpage is
> trivial and not included here.
>
> ok?
>
>
> Index: portimport
> ===================================================================
> RCS file: /cvs/ports/infrastructure/bin/portimport,v
> diff -u -p -r1.10 portimport
> --- portimport 19 Feb 2020 17:53:18 -0000 1.10
> +++ portimport 30 Jun 2026 15:26:34 -0000
> @@ -29,7 +29,7 @@ usage() {
> }
>
> user=$(id -un)
> -portsdir=
> +portsdir=/usr/ports
...
> -portsdir=${portsdir:-${PWD%"/$pkgpath"}}
how about this?
portsdir=${portsdir:-/usr/ports}
> grep -q "^@new" pkg/P* && echo "New users/groups, remember to commit
> infrastructure/db/user.list!"
> cd "$portsdir/${pkgpath%/*}"
> - cvs -R -d$cvsroot update -AdP ${pkgpath##*/}
> + cvs -d$cvsroot update -AdP ${pkgpath##*/}
agreed, -R makes no sense here.
I suppose it could mv ${pkgpath} ${pkgpath}.bak or similar if run from
/usr/ports?
