[00:23] <xnox> laney:  is appstream issue with zstd manifested as a bug report at all anywhere? is there a bug against like ubuntu, ubuntu-publishing-scripts or some such? any logs or errors? I don't know if that's progressing, or if there is a way for me to help.
[00:23] <xnox> laney:  can you point me at anything?
[00:23] <xnox> i only heard about this via chat messages.
[00:52] <RAOF> Eickmeyer: About the displaycal upload: why isn't this a sync from Debian? It's not clear to me that deb-that-installs-a-flatpak is a better choice than deb-that-depends-on-python2.7 (which is presumably the other option)?
[00:52] <RAOF> A README.Debian would perhaps have been a good idea to document the reasoning.
[02:18] <Eickmeyer> RAOF: We removed it from our repositories because it won't work. Did you read my email?
[02:18] <Eickmeyer> RAOF: The Debian version doesn't work.
[02:19] <Eickmeyer> RAOF: https://lists.ubuntu.com/archives/ubuntu-release/2021-June/005235.html
[04:48] <RAOF> Ah, didn't see that.
[04:48]  * RAOF goes to work out why he's apparently not subscribed to ubuntu-release before adding his 2¢
[04:48] <RAOF> (do you want displaycal to be seeded? Because I don't think the package you've uploaded will do that)
[04:48] <RAOF> That reasoning makes sense, although I wonder if we need a better mechanism for “these $NON_DEBS should be seeded”.
[08:04] <laney> xnox: Don't think so. I just found the log message for juliank. Feel free to file one.
[08:04] <laney> here: https://github.com/ximion/appstream-generator
[08:07] <laney> I think it'd be best to start with adding a testcase there with a zstd-compressed deb, and then fixing it. We usually chat about this in #packagekit btw.
[09:38] <xnox> laney:  and we do run that snap as part of Ubuntu archive publishing?
[09:38] <xnox> i see rsync of appstream stuff
[09:43] <laney> yes
[09:43] <laney> well, depends exactly what you mean
[09:44] <laney> but that is the thing you have to fix - not relevant to this issue exactly when and how it's run
[10:04] <xnox> laney:  i think it might. I see that libarchive.so.13 is staged inside the snap, but not libzstd which is used from the host. Which makes things a little bit more treaky. Is the appstream.internal host bionic?
[10:12] <laney> xnox: xenial. are you sure about what you're saying though? libzstd1 is a dependency of libarchive13 so it would at most be removed because it's in the base snap (if it is, didn't check).
[10:12] <laney> xnox: I'm just testing an update to the snap for other fixes though, so wait a bit, I'll re-process "hello"
[10:13] <xnox> ok.
[10:13] <laney> It didn't get rebuilt for a while for stupid FTBFS reasons
[10:13] <xnox> laney:  i see upstream bugs in libarchive "when build against newer libzstd, and runs against old libzstd, bugs happen" in the libarchive changelogs.
[10:14] <xnox> xenial's libzstd1 is beyond the horizon to trigger bugs. thus imho we need this:
[10:15] <xnox> laney:  https://paste.ubuntu.com/p/DnSdfjHDSQ/
[10:15] <xnox> i have no idea how come libraries are mentioned one by one like that.
[10:16] <laney> I dunno, let's see
[10:16] <laney> It feels wrong, the deps of libarchive should arrange for this
[10:16] <laney> I'll try this new build in a bit
[10:19] <xnox> i think it doesn't have to.... cause libzstd1 is present on all ubuntu host builders..... and i think snaps can make a choice to stage things, use from base, use from host.
[10:20] <xnox> ldd /snap/appstream-generator/153/usr/bin/appstream-generator | grep -v /snap/appstream-generator => does not look great
[10:20] <xnox> https://paste.ubuntu.com/p/9bz4s3JDWQ/
[10:21] <xnox> not sure if all of these should be staged into the snap, or used from the host. but certainly libzstd.so.1 is of interest for us at the moment.
[10:21] <xnox> https://github.com/ximion/appstream-generator/pull/94
[10:21] <ubottu> Pull 94 in ximion/appstream-generator "snapcraft: stage libzstd1" [Open]
[10:22] <laney> Stop, please.
[10:22] <laney> That's base snap stuff, it's all fine AFAICS.
[10:23] <laney> I'll run this build and then we'll see what it looks like.
=== didrocks999 is now known as didrocks
[12:34] <rbasak> Will SRU tooling (sru-review, etc) correctly work through a bug reference that refers to a duplicate bug?
[12:35] <rbasak> I've not seen this case before.
[12:39] <diddledan> cjwatson: I see I caused you to poke at packages.u.c, too - my own MR is now submitted to fix ubuntu ports indexing: https://salsa.debian.org/webmaster-team/packages/-/merge_requests/19
[12:39] <ubottu> Merge 19 in webmaster-team/packages "Parse Ubuntu Ports more completely" [Opened]
[12:40] <cjwatson> diddledan: Only very much in passing, but yeah
[12:40] <diddledan> :-)
[12:41] <cjwatson> diddledan: Thanks
[12:42] <diddledan> gotta stretch the legs of my @ubuntu.com ;-p
=== georgiag_ is now known as georgiag
[14:09] <laney> xnox: this rebuilt one works
[14:09] <laney> I dunno why, must have picked up a fixed something something
[14:09] <laney> I'll put it into production after lunch
[14:18] <xnox> laney:  winning!
[14:30] <juliank> xnox: reprepro zstd srus, yay, nay, status?
[14:43] <xnox> juliank: did not start preparing them, as was busy verifying my other srus. about to start making them.
[14:44] <xnox> juliank: if you want to help, i guess please look at other things? i.e. whatever is next highest priority? aptly?
[14:44] <xnox> fastly?
[14:44] <xnox> or whatever those things are.
[14:45] <juliank> xnox: just curious on status, I guess aptly would be worth doing? Also have to get other SRUs verified/finalized (shim/apt)
[14:45] <juliank> Nobody approving my shim signing tarballs on xenial :(
[14:58] <rbasak> jibel: looking at ubiquity 20.04.15.14 in focal unapproved, that latest change isn't in impish. Is that expected? And is this a fix for one of the existing SRU bugs, or a new issue that also needs fixing? I'm not sure how to assess regression risk for this change as distinct from the previous changes that have SRU bugs.
[16:40] <jibel> rbasak, it's been uploaded to impish at the same time https://launchpad.net/ubuntu/+source/ubiquity/21.10.3. It's an oversight for the SRU currently in focal so basically the same issue. We stopped configuring kerberos but didn't remove the now useless package.
[16:41] <Eickmeyer> RAOF: Yeah, the idea is to seed it in Studio.
[16:51] <bdmurray> This report seems to be out of date https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html
=== JanC_ is now known as JanC