| 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:23 |
| 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. | 00:52 |
| 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:18 |
| Eickmeyer | RAOF: https://lists.ubuntu.com/archives/ubuntu-release/2021-June/005235.html | 02:19 |
| 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”. | 04:48 |
| 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:04 |
| 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. | 08:07 |
| xnox | laney: and we do run that snap as part of Ubuntu archive publishing? | 09:38 |
| xnox | i see rsync of appstream stuff | 09:38 |
| laney | yes | 09:43 |
| laney | well, depends exactly what you mean | 09:43 |
| laney | but that is the thing you have to fix - not relevant to this issue exactly when and how it's run | 09:44 |
| 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:04 |
| 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:12 |
| 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:13 |
| xnox | xenial's libzstd1 is beyond the horizon to trigger bugs. thus imho we need this: | 10:14 |
| 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:15 |
| 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:16 |
| 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:19 |
| 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:20 |
| 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:21 |
| laney | Stop, please. | 10:22 |
| laney | That's base snap stuff, it's all fine AFAICS. | 10:22 |
| laney | I'll run this build and then we'll see what it looks like. | 10:23 |
| === didrocks999 is now known as didrocks | ||
| rbasak | Will SRU tooling (sru-review, etc) correctly work through a bug reference that refers to a duplicate bug? | 12:34 |
| rbasak | I've not seen this case before. | 12:35 |
| 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:39 |
| cjwatson | diddledan: Only very much in passing, but yeah | 12:40 |
| diddledan | :-) | 12:40 |
| cjwatson | diddledan: Thanks | 12:41 |
| diddledan | gotta stretch the legs of my @ubuntu.com ;-p | 12:42 |
| === georgiag_ is now known as georgiag | ||
| 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:09 |
| xnox | laney: winning! | 14:18 |
| juliank | xnox: reprepro zstd srus, yay, nay, status? | 14:30 |
| xnox | juliank: did not start preparing them, as was busy verifying my other srus. about to start making them. | 14:43 |
| 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:44 |
| 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:45 |
| 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. | 14:58 |
| 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:40 |
| Eickmeyer | RAOF: Yeah, the idea is to seed it in Studio. | 16:41 |
| bdmurray | This report seems to be out of date https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html | 16:51 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!