[08:27] xnox: different dependency per arch, so the symlinks happened differently, so the trailer is different [10:57] 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] 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] 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 === sem2peie- is now known as sem2peie [12:36] cpaelzer: https://wiki.ubuntu.com/ProposedMigration#autopkgtests [12:40] thank you bdmurray [12:40] and gladly that confirms we get the 8G that match Debian with it [13:16] laney: leh sigh === genii-core is now known as genii [16:29] 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] schopin: Could you craft the urls for those tests? [17:17] 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] oops on the 2 Impish'es there [17:18] or a configuration variable set would be fine too. [17:35] Tenkawa: -Zgzip or -Zxz [17:35] Tenkawa: if it's being called via dh_builddeb (which is usual), then "dh_builddeb -- -Zgzip" etc. [17:37] 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] 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] I am not 100% convinced the destinations are all going to be ubuntu and that might be what happened [17:38] (in bionic at release time; in xenial as a fairly recent stable update, in order to support Launchpad) [17:39] just debian format [17:39] I just got a bug report that my archive format changed [17:39] in testing [17:40] I just started upgrading to Impish to evaluate upgrading the porting [17:41] thats been the only hiccup so far [17:41] for arm64 on Raspberry PI 4 and Odroid N2+ [17:43] 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] 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] ginggs: Great, thanks! [18:14] np! [20:17] 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] How can I version this so that it can be resynced when the time comes? [20:18] I'm thinking jackd2_1.9.19~dfsg~0.orig.tar.gz (for the tarball, for instance.) === rharper_ is now known as rharper [22:15] 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] jbicha: The entire multimedia team is MIA right now. :/ [22:19] Eickmeyer: I'd replace ~0 with -0, i.e. hyphen instead of tilde. [22:20] GunnarHj: Unfortunately, that has the effect of overriding any future sync of the same package version. [22:21] Eickmeyer: Wouldn't the Debian version be -1 ? [22:21] GunnarHj: Yes, but not the tarball. [22:22] Eickmeyer: Ah, sorry, it's late here... [22:22] GunnarHj: No worries. :) [22:28] 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] 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] ~ubuntu maybe, rather than ~0, to make it clear? [23:26] It doesn't need a number any more than we version our repacks for a particular upstream release. [23:32] I retried casper [23:34] bdmurray: thanks! I'm looking into the flakiness as this seems to be not a new problem. [23:39] rbasak: Ok, I'll go with ~ubuntu. Thanks!