Package Details: qdigidoc4

Git Clone URL: (read-only, click to copy)
Package Base: qdigidoc4
Description: DigiDoc4 Client is an application for digitally signing and encrypting documents; the software includes functionality to manage Estonian ID-card - change pin codes, update certificates etc.
Upstream URL:
Keywords: esteid
Licenses: LGPL2.1
Submitter: kevku
Maintainer: kevku
Last Packager: kevku
Votes: 16
Popularity: 0.174283
First Submitted: 2018-06-13 16:22 (UTC)
Last Updated: 2022-12-24 15:40 (UTC)

Latest Comments

1 2 3 4 5 6 .. 9 Next › Last »

zeroconf commented on 2022-11-19 10:38 (UTC)

Hopefully is it possible to describe in package recipe so, that compilation happens in right order during software update. Any manual intervention is not meant to be used as rest of update process is automatic. Hopefully there will be no more old OpenSSL dependency but only newest one. Otherwise what is the point to update OpenSSL if still old version is used with its very dangerous vulnerabilities.

kevku commented on 2022-11-14 17:21 (UTC)

you need to rebuild xml-security-c libdigidocpp before qdigidoc4

kaur commented on 2022-11-14 11:29 (UTC) (edited on 2022-11-14 11:31 (UTC) by kaur)

openssl-1.1 should be added as make dependency. Building fails without it. @kevku, can you amend PKGBUILD?

Saduff commented on 2022-10-20 19:50 (UTC)

As of git 2.38.1, git submodule update in the PKGBUILD needs to be changed to git -c protocol.file.allow=always submodule update

More info:

kaurman commented on 2022-08-18 19:35 (UTC)


Worth reading.

fnix commented on 2022-08-18 17:34 (UTC)

Not the peculiarities of every possible system; just those that keep recurring and are hence not particularly rare (which I doubt Qt6 is).

Either way, since the PKGBUILD is ostensibly already fixed with an explicit path to the correct version of Qt, why is it still throwing an error about Qt6?

kaurman commented on 2022-08-18 05:25 (UTC)

Fnix, I think you are missing the point. The suggestion to use clean chroot is nothing personal. It's just that it is very hard to take into account the peculiarities of every possible system. It's just not worth the trouble as readily available solutions exist already, and one can always use an officially supported system.

And yet, over and over again there are complaints about the free pkgbuild not working when it is working just fine. Look at it from the maintainer's point of view;)

fnix commented on 2022-08-18 02:29 (UTC)

So the issue in my case is that the presence of Qt6 (or “garbage”, according to the packager) messes up the paths to Qt5 – which however shouldn't occur in the first place as the correct Qt directory is explicitly defined in PKGBUILD?

zeroconf commented on 2022-08-17 13:06 (UTC) (edited on 2022-08-17 13:07 (UTC) by zeroconf)

AFAIK the PKGBUILD file is fixed against Qt5 and it works in my machine. I've installed it already in several machines and all working! I had also that Qt6 issue initially if you look my previous messages here. Thanks to @kevku the PKGBUILD is fixed in AUR.

Still you can do it also manually:

mkdir /tmp/build-qdigidoc4 && cd /tmp/build-qdigidoc4
wget -q --show-progress -O PKGBUILD

check the section build() in file PKGBUILD at downloaded /tmp/build-qdigidoc4/ folder:

build() {
  cd "$srcdir/$pkgname-$pkgver/$pkgname-build"
  export BUILD_NUMBER=${pkgver##*.}
  cmake .. -DCMAKE_C_FLAGS:STRING="${CFLAGS} -ffile-prefix-map=$srcdir=." \
           -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS} -ffile-prefix-map=$srcdir=." \
           -DCMAKE_INSTALL_PREFIX="/usr" \
           -DCMAKE_INSTALL_LIBDIR="lib" \
           -DCMAKE_INSTALL_SYSCONFDIR="/etc" \

In order to define the Qt5 usage, according previous suggestion, there must be the line:


As you can see, that line already exist in PKGBUILD at AUR. If you need any other parameter there in PKGBUILD, you can insert these.

Then you can continue:

makepkg -s --install
cd ..
rm -fr build-qdigidoc4

Although such manual installing is not suggested, can be done if no other ways are available.