SUMMARY This was an attempt to include the 8.0.0-beta1 for Ubuntu Lunar Lobster, future release 23.04. Regardless of environment, this issue would happen even in a stable release. During an atempt to build from the tarball for 8.0.0-beta1, the Launchpad build system failed to build from source as it is (intentionally) unable to download from external sources. Note that this would be the same for Debian as well. Please include the unit tests in the source tarball as well so that distributions can properly test the beta. Note that we would like these unit tests if they are automated since debhelper typically will run test suites at the end of the build process, typically by invoking "make test". STEPS TO REPRODUCE Attempt to package from official tarball using offiical Debian packaging guidelines invoking Debhelper OBSERVED RESULT Failed to build from source: git clone https://invent.kde.org/graphics/digikam-test-data.git /<<PKGBUILDDIR>>/test-data /bin/sh: 1: git: not found (note: installing git as a build dependency would not resolve this as git would be unable to download in this environment) Complete build log at https://launchpadlibrarian.net/642172379/buildlog_ubuntu-lunar-amd64.digikam_4%3A8.0.0~beta1-0ubuntu1~ppa1_BUILDING.txt.gz EXPECTED RESULT Complete build without invoking git to download unit tests from an external source. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu Lunar Lobster Development Environment (Future 23.04)
The external git repository is delegate to host unit tests data. To drop this extra dependency, just disable unit test build with cmake option -DBUILD_TESTING=OFF Gilles Caulier
(In reply to caulier.gilles from comment #1) > The external git repository is delegate to host unit tests data. > > To drop this extra dependency, just disable unit test build with cmake > option -DBUILD_TESTING=OFF > > Gilles Caulier Thanks, that just leaves the concern that our auto package tests (and Debian's) will have no test suite to run against. These tests are written and included by the upstream developers and our test systems make sure that the packages are correctly tested. This leaves a void in that system. Nearly every other KDE package includes this, so I'm puzzled as to why the deviation.
The deviation is due to the large collection of files to test digiKam implementations, including photos and videos. We use a dedicated git-fs repository for that. As i know no other KDE application do the same for the moment.
(In reply to caulier.gilles from comment #3) > The deviation is due to the large collection of files to test digiKam > implementations, including photos and videos. We use a dedicated git-fs > repository for that. As i know no other KDE application do the same for the > moment. Hi Gilles, This makes sense, but only when building locally. When using a distribution build system, such as the ones in use by Debian and Ubuntu where no external sources can be accessed, this is an impossible situation. These build systems are designed to run the unit tests as designed by the upstream developers for robustness. As far as I know, all KDE applications are meant to be distributed by distributions, and DigiKam is no different, is it not? If it's no different, then the unit tests should not rely on external sources, as is the case currently. In order to get it to build with the unit tests properly, we had to add the unit tests to the packaging side, which is a poor workaround. Disabling the unit tests is simply bad practice from a distribution standpoint, as you can imagine. I hope you understand where we're coming from.
>This makes sense, but only when building locally. And here you are wrong: the digiKam unit-test build is managed in the gitlab CI while developers commit in the source repository. The data are not used only by developers locally, but also online in gitlab. This solution to separate the huge unit test data from the source code is to reduce the tarball size at release time. This solution was proposed by the KDE system admins and i'm sure that others huge KDE applications as Krita and Kdenlive will also take this way in the future. >When using a distribution build system, such as the ones in use by Debian and Ubuntu where no external sources can be accessed, this is an >impossible situation. These build systems are designed to run the unit tests as designed by the upstream developers for robustness. As far as I >know, all KDE applications are meant to be distributed by distributions, and DigiKam is no different, is it not? Of course. But the unit -tests are already processed previously in your CI automatically while the evolution of the application, this is the main goal. >If it's no different, then the unit tests should not rely on external sources, as is the case currently. 2 solutions for you: disabling unit tests while building package as we process unit tests in digiKam CI, or found a solution to open access to external resources as the git-fs data repository in your build CI. Gilles Caulier
Recent trace of the gitlab CI compiling digiKam source code including unit test data: https://invent.kde.org/graphics/digikam/-/jobs/934963/raw Best gilles Caulier
(In reply to caulier.gilles from comment #5) > >This makes sense, but only when building locally. > > And here you are wrong: the digiKam unit-test build is managed in the gitlab > CI while developers commit in the source repository. The data are not used > only by developers locally, but also online in gitlab. Sorry, that was my mistake, I didn't account for CI systems. > This solution to separate the huge unit test data from the source code is to > reduce the tarball size at release time. This solution was proposed by the > KDE system admins and i'm sure that others huge KDE applications as Krita > and Kdenlive will also take this way in the future. Then this issue will be reported accordingly to those projects as well at those times. Also adding Aleix Pol to CC as this is a distribution blocker for the reasons I will outline below. This is basically a huge mistake not to include *everything* needed to build and test the applications in the release tarballs as it only hurts the distributions. Were the distributions not consulted prior to this change? > >When using a distribution build system, such as the ones in use by Debian and Ubuntu where no external sources can be accessed, this is an >impossible situation. These build systems are designed to run the unit tests as designed by the upstream developers for robustness. As far as I >know, all KDE applications are meant to be distributed by distributions, and DigiKam is no different, is it not? > > Of course. But the unit -tests are already processed previously in your CI > automatically while the evolution of the application, this is the main goal. > > >If it's no different, then the unit tests should not rely on external sources, as is the case currently. > > 2 solutions for you: disabling unit tests while building package as we > process unit tests in digiKam CI, We cannot rely on your tests as we cannot trust that your CI system is identical to our build environment. > or found a solution to open access to > external resources as the git-fs data repository in your build CI. That's a non-starter per policy. That simply will not happen under any circumstances as that breaks our trusted sources policy. I am far from the person in charge of this policy, that lies with the Ubuntu Technical Board. The only solution to this problem is to reverse this change as proposed by the KDE system admins (you said proposed, you never said it was mandated, so I'm not sure why it took effect). I'm sure it was well-intentioned to keep the size of the tarballs down, but it seems as though the proposal did not count on the fact that many distributions, Debian and Ubuntu included, need to do the unit tests against their own build environments.
Tests if for developpers and CI, not for packaging. Simply disable tests build with right cmake option provided by the project.