https://bugs.kde.org/show_bug.cgi?id=463439
--- Comment #7 from Erich Eickmeyer <eeickme...@ubuntu.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
