Arch Linux User Repository

@zeroconf, for a straightforward answer, rebuilding libdigidocpp and then qdigidoc4, in that order, worked fine.

Using my AUR helper of choice (paru):

paru -S libdigidocpp && paru -S qdigidoc4

I assume you are using Yay? If that is the case, then cleanBuilding has nothing to do with building in a clean chroot. cleanBuilding in the context of Yay is about whether you allow the build process to rely on a cache that might exist (e.g. from a previous build) & will most likely speed up the build process or whether you want things done from scratch. See here for a brief discussion.

I didn’t look into this in detail, but it seems that Yay does not have explicit support for building in a clean chroot. While this certainly doesn’t mean that you cannot do it (chrooting is an independent concept), I’d still recommend looking at a AUR helper that supports clean chroot builds out of the box (if you are using Yay and it indeed doesn’t). See here. I use aurutils & am happy with it.

However, the setup may take some reading, particularly if you have a nice & recent pacman.conf that introduced the alpm user for downloading packages. True, this is something that likely affects some of aurutils’ alternatives too. You could just comment the alpm line in pacman.conf, but this is not a reasonable solution.

If you decide to go with aurutils then the man pages (man aur & man aur-chroot) should have the essentials, including examples. When faced with questions regarding file permissions & the aforementioned alpm user, this might prove useful (although there are other approaches too).

If you get stuck, have a look at the Arch forum & ask around.

Finally, a few words on why bother with a clean chroot build in the first place. Simply put, a chroot is an environment within an environment (in this case our own host / main system). When we use a clean chroot, we level the playing field in a way, so that the environment a package is built in is more or less similar for everyone (the build process doesn’t ‘see’ our daily system with all its bells and whistles). In addition to this common denominator of sorts, there are the instructions we get from a PKGBUILD (also the same for everyone who build package X).

Generally speaking, if a AUR package builds OK in a clean chroot, this means that the packager has included the correct dependencies in the PKGBUILD. If a user uses such a PKGBUILD but does not use a clean chroot and finds that they cannot build for some reason, then it is a peculiarity of their system that is to ‘blame’, rather than the PKGBUILD*.

It may well be that the packager could modify the PKGBUILD in a way that would make the package work for the aforementioned user, but then another user might come along with another problem of some sort as the environment they try to build in is different... We’d end up with hard to maintain & still unreliable PKGBUILDS and stressed packagers. This is why (AUR) packages should be built in a clean chroot in my opinion. It avoids many possible problems & lets everyone concentrate on actual PKGBUILD trouble (should there be any).

As for your question about how one knows what to rebuild, it was more of a hunch in this particular case. Looking at your Pastebin, I’d rebuild libdigidocpp, but more importantly, as qdigidoc depends on libdigidocpp & the whole ‘kit’ is minuscule, I’d rebuild them both for good measure. Can be done rather fast even on ancient hardware.

*True, it may still be a poor PKGBUILD for other reasons

@kaurman - would be good if you can share commands you used. Didn't do any changes with AUR pkgbuilds and answered All when asked: Packages to cleanBuild? Tried to reinstall only qdigidoc4. If libdigidocpp needs rebuild - is there any importance in which order to rebuild? How you determine, which packages needs to rebuild?

Can confirm the problem. The digidoc client indeed failed to start.

However, the dependencies appear to be fine. All it takes is a rebuild of qdigidoc and libdigidocpp (used the current AUR pkgbuilds without changes and a clean chroot). Worked like a charm.

Sorry to mention but qdigidoc4 stopped working as libxml2 was not found. Seems like it is not dependency for qdigidoc4 - seems like it should be. Installed libxml2 package. As here was not possible post longer log, created a post here https://pastebin.com/ZbP2S9mM Somehow after manually installed libxml2, qdigidoc4 started but (re)installation still failed.

The issue https://ria.ee/uudised/koige-uuemas-digidoc4-kliendi-versioonis-digiallkirjastamine-hairitud has been fixed today, 18.04.2024 with DigiDoc v4.5.1 - https://www.id.ee/artikkel/koige-uuemas-digidoc4-kliendi-versioonis-on-digiallkirjastamine-hairitud/

The latest version (4.5.0) may cause problems: https://ria.ee/uudised/koige-uuemas-digidoc4-kliendi-versioonis-digiallkirjastamine-hairitud

you need to be online, offline sandbox builds do not work. and complain upstream too.

The site serving the TSL https://ec.europa.eu/tools/lotl/eu-lotl.xml is down or blocking download.

The install fails due to mising EE.xml.

[ 24%] Automatic RCC for TSL.qrc

AutoRcc subprocess error
------------------------
The rcc process failed to compile
  "SRC:/qdigidoc4-build/client/TSL.qrc"
into
  "SRC:/qdigidoc4-build/client/qdigidoc4_autogen/EJRQKI7XPS/qrc_TSL.cpp"

Command
-------
/usr/lib/qt6/rcc -name TSL -o /home/jrl/.cache/yay/qdigidoc4/src/qdigidoc4-4.4.0.4447/qdigidoc4-build/client/qdigidoc4_autogen/EJRQKI7XPS/qrc_TSL.cpp /home/jrl/.cache/yay/qdigidoc4/src/qdigidoc4-4.4.0.4447/qdigidoc4-build/client/TSL.qrc

Output
------
RCC: Error in '/home/jrl/.cache/yay/qdigidoc4/src/qdigidoc4-4.4.0.4447/qdigidoc4-build/client/TSL.qrc': Cannot find file 'EE.xml'

make[2]: *** [client/CMakeFiles/qdigidoc4_arcc_TSL.dir/build.make:72: client/CMakeFiles/qdigidoc4_arcc_TSL] Error 1
make[1]: *** [CMakeFiles/Makefile2:370: client/CMakeFiles/qdigidoc4_arcc_TSL.dir/all] Error 2
make: *** [Makefile:156: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: qdigidoc4-exit status 4
 -> Failed to install the following packages. Manual intervention is required:
qdigidoc4 - exit status 4

https://aur.archlinux.org/packages/libdigidocpp#comment-939728