I had recently upgraded my NAS from FreeBSD 13.0 to FreeBSD 13.1. Unfortunately, I found out that the Deluge package was faulting on startup. It turns out that when FreeBSD updated the
libtorrent-rasterbar package, it had broken the Python bindings, and thus Deluge. However, the old Deluge and Python binding package were still installed – they just didn’t work anymore due to
While it’d be ideal if this were fixed upstream, I didn’t have the patience for this right now. So, I decided to downgrade the
libtorrent-rasterbar package to be compatible with the Python bindings. There were no other dependent packages, so I figured this was safe. Unfortunately, I had to deal with a few curveballs along the way…
The first obstacle was even though I had manually downloaded the package, and specified the file on the command line, this didn’t really work out:
$ sudo pkg install "./libtorrent-rasterbar-1.2.14,1.pkg" Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): Installed packages to be DOWNGRADED: libtorrent-rasterbar: 1.2.16_2,2 -> 1.2.14,1 Number of packages to be downgraded: 1 Proceed with this action? [y/N]: y pkg: archive_read_open_filename((null)): Failed to open '(null)'
Turns out this is a FreeBSD bug – and upstream can’t reproduce it. Oh well, we can do
pkg remove -f (the
-f is important so it won’t remove the Python bindings and Deluge that depend on it, since we’ll quickly reinstall the package. Then we can try it again…. right?
$ sudo pkg -d install -fU "./libtorrent-rasterbar-1.2.14,1.pkg" DBG(1)> pkg initialized DBG(1)> want to get an advisory lock on a database DBG(1)> Jobs> Adding file: ./libtorrent-rasterbar-1.2.14,1.pkg The following 1 package(s) will be affected (of 0 checked): New packages to be INSTALLED: libtorrent-rasterbar: 1.2.16_2,2 Number of packages to be installed: 1 The process will require 11 MiB more space. 3 MiB to be downloaded.
Even though I specified
-U so it won’t check the repo for updates, it still wants to install the latest version. I had ran
pkg clean -a, so we don’t have the cached packages either. In fact, it’ll happily and blithely just download the latest version. Clearly, it must be caching the repo metadata somewhere. After checking with
truss, I found the repo metadata cache (it’s an SQLite database) in
/var/db/pkg. So, we do a little trolling, and temporarily remove that cache. When combined with
-U, it should prevent it from checking the repo for a newer version.
[calvin@illmatic ~]$ sudo mv /var/db/pkg/repo-FreeBSD.sqlite /var/db/pkg/repo-FreeBSD.sqlite.dont [calvin@illmatic ~]$ sudo pkg -d install -U "./libtorrent-rasterbar-1.2.14,1.pkg" DBG(1)> pkg initialized pkg: Repository FreeBSD cannot be opened. 'pkg update' required DBG(1)> want to get an advisory lock on a database DBG(1)> Jobs> Adding file: ./libtorrent-rasterbar-1.2.14,1.pkg DBG(1)> solver: for package: py38-libtorrent-rasterbar cannot find provide for requirement: libtorrent-rasterbar.so.10 Checking integrity...DBG(1)> check integrity for 1 items added done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): New packages to be INSTALLED: libtorrent-rasterbar: 1.2.14,1 Number of packages to be installed: 1 The process will require 11 MiB more space. Proceed with this action? [y/N]: y DBG(1)> want to upgrade advisory to exclusive lock [1/1] Installing libtorrent-rasterbar-1.2.14,1... Extracting libtorrent-rasterbar-1.2.14,1: 100% DBG(1)> release an exclusive lock on a database DBG(1)> release an advisory lock on a database [calvin@illmatic ~]$ sudo mv /var/db/pkg/repo-FreeBSD.sqlite.dont /var/db/pkg/repo-FreeBSD.sqlite [calvin@illmatic ~]$ sudo service deluged restart deluged not running? (check /var/run/deluged/pid). Starting deluged.
Yay! Deluge seems to work again, and after restoring the metadata cache file, pkg will work as it usually does. I’ll have to be careful about updates (unless I can pin?) until upstream ports fixes the issue with the Python bindings.
Use ‘pkg add’ for this situation
This works well, thanks! Unfortunately, people seem to imply pkg add is deprecated in favour of pkg install, even for local packages, so it’s not clear to use that.