[08:27] <laney> xnox: different dependency per arch, so the symlinks happened differently, so the trailer is different
[10:57] <cpaelzer> I should take a old-style paper-note about it as I think I ask this the third time but what exactly is the big_packages sizing in regard to memory
[10:58] <cpaelzer> I see it was broken out from the old repo and now is controlled via https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs
[10:58] <cpaelzer> but neither has revealed me the actual size and canonistack does not list the flavor that https://autopkgtest-cloud.readthedocs.io/en/latest/administration.html#give-a-package-more-time-or-more-resources refers to
[12:36] <bdmurray> cpaelzer: https://wiki.ubuntu.com/ProposedMigration#autopkgtests
[12:40] <cpaelzer> thank you bdmurray
[12:40] <cpaelzer> and gladly that confirms we get the 8G that match Debian with it
[13:16] <xnox> laney:  leh sigh
[16:29] <schopin> Could a kind soul with the proper accesses trigger autopkgtests on this PPA for all arch but s390x, on impish, for the openssl package ? ~schopin/openssl3
[16:34] <bdmurray> schopin: Could you craft the urls for those tests?
[17:17] <Tenkawa> Is there a way to manually call dpkg-deb to use xz or gz in Impish instead of zstd in Impish if needed for building backwards compatible archives?
[17:17] <Tenkawa> oops on the 2 Impish'es there
[17:18] <Tenkawa> or a configuration variable set would be fine too.
[17:35] <cjwatson> Tenkawa: -Zgzip or -Zxz
[17:35] <cjwatson> Tenkawa: if it's being called via dh_builddeb (which is usual), then "dh_builddeb -- -Zgzip" etc.
[17:37] <Tenkawa> cjwatson: ok… thanks.. I was looking at the script and thats what I thought.. I wasn't sure if that was all but thought so.. I'll give it a go shortly.. thanks
[17:37] <cjwatson> Tenkawa: but zstd support was added all the way back to xenial, so this is unlikely to be necessary just for backward-compatibility
[17:38] <Tenkawa> I am not 100% convinced the destinations are all going to be ubuntu and that might be what happened
[17:38] <cjwatson> (in bionic at release time; in xenial as a fairly recent stable update, in order to support Launchpad)
[17:39] <Tenkawa> just debian format
[17:39] <Tenkawa> I just got a bug report that my archive format changed
[17:39] <Tenkawa> in testing
[17:40] <Tenkawa> I just started upgrading to Impish to evaluate upgrading the porting
[17:41] <Tenkawa> thats been the only hiccup so far
[17:41] <Tenkawa> for arm64 on Raspberry PI 4 and Odroid N2+
[17:43] <Tenkawa> Thanks again for the help.. Going to go give it a try. Will sit around for a bit.. Have been very impressed by what I've seen in the last few days
[18:13] <ginggs> bdmurray: looks like schopin left, but I've triggered them https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=openssl&ppa=schopin/openssl3&trigger=openssl/3.0.0~~beta1-1ubuntu1~ppa6
[18:14] <bdmurray> ginggs: Great, thanks!
[18:14] <ginggs> np!
[20:17] <Eickmeyer> I have a versioning question. I'm wanting to update jackd2 in Impish, but it's currently a sync from Debian with a ~dfsg on it. I know that when Debian releases an update, it'll likely be the same version with the ~dfsg, but since it's a repack, if I attempt to resync it the tarball won't be the same.
[20:17] <Eickmeyer> How can I version this so that it can be resynced when the time comes?
[20:18] <Eickmeyer> I'm thinking jackd2_1.9.19~dfsg~0.orig.tar.gz (for the tarball, for instance.)
[22:15] <jbicha> Eickmeyer: I don't think we have a standard naming convention for that so IMO that's fine. You could also ask Debian if they'd be willing to upload the new version to experimental now
[22:17] <Eickmeyer> jbicha: The entire multimedia team is MIA right now. :/
[22:19] <GunnarHj> Eickmeyer: I'd replace ~0 with -0, i.e. hyphen instead of tilde.
[22:20] <Eickmeyer> GunnarHj: Unfortunately, that has the effect of overriding any future sync of the same package version.
[22:21] <GunnarHj> Eickmeyer: Wouldn't the Debian version be -1 ?
[22:21] <Eickmeyer> GunnarHj: Yes, but not the tarball.
[22:22] <GunnarHj> Eickmeyer: Ah, sorry, it's late here...
[22:22] <Eickmeyer> GunnarHj: No worries. :)
[22:28] <dbungert> May I interest someone in a retest click?  I'd like to unblock linux-meta for what I believe to be a flaky test in casper https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=casper&trigger=linux-meta/5.13.0.12.23&trigger=linux-signed/5.13.0-12.12&trigger=linux/5.13.0-12.12
[23:25] <rbasak> Eickmeyer: ideally, ask the Debian maintainer to kindly use the same repack. Failing that you can do things with versioning like you suggested, but I wouldn't worry about trying too hard - tarball mismatches can be annoying but so is annoying versioning, and you'll probably move on to a future upstream tarball eventually anyway.
[23:26] <rbasak> ~ubuntu maybe, rather than ~0, to make it clear?
[23:26] <rbasak> It doesn't need a number any more than we version our repacks for a particular upstream release.
[23:32] <bdmurray> I retried casper
[23:34] <dbungert> bdmurray: thanks!  I'm looking into the flakiness as this seems to be not a new problem.
[23:39] <Eickmeyer> rbasak: Ok, I'll go with ~ubuntu. Thanks!