laney | xnox: different dependency per arch, so the symlinks happened differently, so the trailer is different | 08:27 |
---|---|---|
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:57 |
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 | 10:58 |
=== sem2peie- is now known as sem2peie | ||
bdmurray | cpaelzer: https://wiki.ubuntu.com/ProposedMigration#autopkgtests | 12:36 |
cpaelzer | thank you bdmurray | 12:40 |
cpaelzer | and gladly that confirms we get the 8G that match Debian with it | 12:40 |
xnox | laney: leh sigh | 13:16 |
=== genii-core is now known as genii | ||
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:29 |
bdmurray | schopin: Could you craft the urls for those tests? | 16:34 |
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:17 |
Tenkawa | or a configuration variable set would be fine too. | 17:18 |
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:35 |
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:37 |
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:38 |
Tenkawa | just debian format | 17:39 |
Tenkawa | I just got a bug report that my archive format changed | 17:39 |
Tenkawa | in testing | 17:39 |
Tenkawa | I just started upgrading to Impish to evaluate upgrading the porting | 17:40 |
Tenkawa | thats been the only hiccup so far | 17:41 |
Tenkawa | for arm64 on Raspberry PI 4 and Odroid N2+ | 17:41 |
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 | 17:43 |
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:13 |
bdmurray | ginggs: Great, thanks! | 18:14 |
ginggs | np! | 18:14 |
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:17 |
Eickmeyer | I'm thinking jackd2_1.9.19~dfsg~0.orig.tar.gz (for the tarball, for instance.) | 20:18 |
=== rharper_ is now known as rharper | ||
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:15 |
Eickmeyer | jbicha: The entire multimedia team is MIA right now. :/ | 22:17 |
GunnarHj | Eickmeyer: I'd replace ~0 with -0, i.e. hyphen instead of tilde. | 22:19 |
Eickmeyer | GunnarHj: Unfortunately, that has the effect of overriding any future sync of the same package version. | 22:20 |
GunnarHj | Eickmeyer: Wouldn't the Debian version be -1 ? | 22:21 |
Eickmeyer | GunnarHj: Yes, but not the tarball. | 22:21 |
GunnarHj | Eickmeyer: Ah, sorry, it's late here... | 22:22 |
Eickmeyer | GunnarHj: No worries. :) | 22:22 |
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 | 22:28 |
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:25 |
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:26 |
bdmurray | I retried casper | 23:32 |
dbungert | bdmurray: thanks! I'm looking into the flakiness as this seems to be not a new problem. | 23:34 |
Eickmeyer | rbasak: Ok, I'll go with ~ubuntu. Thanks! | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!