Hi Carsten, On 13-11-2019 21:33, Carsten Schoenert wrote: > Hello Paul, > > Am 13.11.19 um 19:35 schrieb Paul Gevers: >> Hi Carsten, >> >> On 13-11-2019 07:20, Carsten Schoenert wrote: >>> But I"m struggling *how* to add such an versioned test dependency. This >>> version requirements are only needed for the autopkgtest(s) so because >>> of this we haven't bumped regulary and wanted package dependency. >> >> Test version requirements go into debian/tests/control. Just add them to >> the appropriate Depends field. > > unfortunately this is not possible this way as the test for > kopano-webapp itself is structured as various depending segments (like > in kopanocore too) there new packages get installed and we need a > pre-configured mariadb-server instance to get the test working. Ack, it seems that autopkgtest is missing some functionality to support this properly. > https://salsa.debian.org/giraffe-team/kopano-webapp/blob/debian/sid/debian/tests/smoke > > So the test is first installing the database server and afterwards the > kopano-webapp-apache2 package as we want to see all automatic pulled in > dependencies are working. One of the dependencies here is > kopano-contacts from src:kopanocore, and we pull also kopano-utils. The > tool kopano-admin (provided by kopano-utils) is currently working > internally differently in testing. As we install packages from > kopanocore as an automatic dependency I see no way to control within the > test the version we need as we can only relay on the version controlling > within the packages itself. > > Sure, we could add a versioned dependency on kopanocore within > kopano-webapp, but there is no real technical reason for this, it would > only help that the autopkgtests do work. And as there is no real need > for a version bump on kopanocore we didn't have done this yet. > >>> I'm happy to add such a needed version anywhere but I simply don't know >>> how. Any example package I can look at something similar. > > I see currently only two possibilities to get kopanocore migrating to > testing. One is to add a new higher version on the depending > kopano-contacts in kopano-webapp-common (which then pulls kopano-libs), > and the second option would be an unblock by the RT. This is still the > right solution in my eyes. > > The first option would need of course a new upload of kopano-webapp. There's a third option: instead of requesting an unblock, I'll schedule the test with both packages from unstable. Than all the other tooling will do the right thing (assuming the test passes as expected). Paul
Attachment:
signature.asc
Description: OpenPGP digital signature