I’ve followed the instruction from the wiki
https://sailfishos.org/wiki/Platform_SDK_Target_Installation
to get the latest EA targets for 4.1.0.23 (namely, I’ve used sdk-assistant create
for the tooling and the architecture targets). I’m using the docker version of SDK.
After starting a docker image, I can see the new 4.1.0.23
targets and run my favorite mb2
command. But the package I’m building has dependencies to be installed, and installation crash with the following log:
[mersdk@7431b3a6e4a1 kf5-calendarcore]$ mb2 -t SailfishOS-4.1.0.23-armv7hl -s rpm/kf5-calendarcore.spec build
The following 6 NEW packages are going to be installed:
extra-cmake-modules icu libical libical-devel libicu-devel qt5-qttest-devel
6 new packages to install.
Overall download size: 1.2 MiB. Already cached: 0 B. After the operation, additional 1.2 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Installation of icu-68.2+git1-1.3.3.jolla.armv7hl failed:
Error: Subprocess failed. Error: RPM failed: error: db4 error(-30971) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch
error: cannot open Packages index using db4 - (-30971)
error: cannot open Packages database in /var/lib/rpm
Abort, retry, ignore? [a/r/i] (a): a
After looking here and there, I noticed that the /var/lib/rpm
directory inside the target contained this :
[SB2 sdk-build SailfishOS-4.1.0.23-armv7hl] root@7431b3a6e4a1 kf5-calendarcore # ls -al /var/lib/rpm
total 17444
drwxr-xr-x 2 1000 100000 4096 May 17 11:35 .
drwxr-xr-x 22 1000 100000 4096 May 17 11:30 ..
-rw-r--r-- 1 1000 100000 0 May 10 10:56 .dbenv.lock
-rw-r--r-- 1 root root 0 May 17 11:35 .rpm.lock
-rw-r--r-- 1 1000 100000 1703936 May 10 10:56 Basenames
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Conflictname
-rw-r--r-- 1 1000 100000 282624 May 10 10:56 Dirnames
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Enhancename
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Filetriggername
-rw-r--r-- 1 1000 100000 12288 May 10 10:56 Group
-rw-r--r-- 1 1000 100000 16384 May 10 10:56 Installtid
-rw-r--r-- 1 1000 100000 36864 May 10 10:56 Name
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Obsoletename
-rw-r--r-- 1 1000 100000 13058048 May 10 10:56 Packages
-rw-r--r-- 1 1000 100000 253952 May 10 10:56 Providename
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Recommendname
-rw-r--r-- 1 1000 100000 217088 May 10 10:56 Requirename
-rw-r--r-- 1 1000 100000 57344 May 10 10:56 Sha1header
-rw-r--r-- 1 1000 100000 36864 May 10 10:56 Sigmd5
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Suggestname
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Supplementname
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Transfiletriggername
-rw-r--r-- 1 1000 100000 8192 May 10 10:56 Triggername
-rw-r--r-- 1 1000 100000 24576 May 10 10:56 __db.001
-rw-r--r-- 1 1000 100000 212992 May 10 10:56 __db.002
-rw-r--r-- 1 1000 100000 1318912 May 10 10:56 __db.003
-rw-r--r-- 1 1000 100000 548864 May 10 10:56 __db.004
Which may or may not be what is expected. But after that, I ran rpm --rebuilddb
inside the target as root, and the whole contain of that directory disappeared and everything is working again.