[00:47] -queuebot:#ubuntu-release- New source: ubuntustudio-menu-add (eoan-proposed/primary) [0.1] [01:09] release team: reject ubuntustudio-menu-add please, that was sponsored but on cursory review from sarnold due to some hatred of subprocess calls and unsafe wraps which I fully agree with. (I did a cursory code review, and I've done these 'hacks' before but... I'm in full agreement it needs work after going more in-depth into the code) [01:09] s/release team/archive admins/ [01:09] vorlon: ^ if you can [01:09] -queuebot:#ubuntu-release- Unapproved: bash (cosmic-proposed/main) [4.4.18-2ubuntu3 => 4.4.18-2ubuntu3.1] (core) [01:15] -queuebot:#ubuntu-release- Unapproved: bash (bionic-proposed/main) [4.4.18-2ubuntu1.1 => 4.4.18-2ubuntu1.2] (core) [04:00] teward: done [04:01] -queuebot:#ubuntu-release- New: rejected ubuntustudio-menu-add [source] (eoan-proposed) [0.1] [07:24] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-18.19~18.04.2] [07:24] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-18.19~18.04.2] [07:24] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-23.24~18.04.1] [07:24] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.0.0-18.19~18.04.2] [07:24] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-23.24~18.04.1] [09:07] bdmurray: sorry missed your ping - let me look [09:10] bdmurray: yes that's fine to superceed the one already in proposed - the patches for 2.3 are included in the new point release [09:10] sahid: ^^ [09:19] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-53.57~16.04.1] (kernel) [09:19] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-53.57~16.04.1] (kernel) [09:23] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-53.57~16.04.1] [09:23] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-53.57~16.04.1] [10:11] * rbasak is (virtually) sprinting today and generally unavailable for SRU work - sorry [10:34] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1035.37] (kernel) [10:34] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1009.9] (core, kernel) [10:34] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1014.15] (kernel) === cpaelzer__ is now known as cpaelzer [10:54] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1014.15] [10:54] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1009.9] [10:55] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1035.37] [12:18] vorlon: regards lmdb being required for appstream and possible MIR: https://github.com/ximion/appstream/commit/358e9394631b87797f56dcb7e09e459b4044e631#commitcomment-33995178 [12:51] acheronuk: it's going to need it, feel free to get that filed if you want [12:51] desktop team's going to sign on for that one [12:53] * Laney attempts to deploy an autopkgtest-lxd-worker [13:13] bdmurray: dosaboy is going to update the regression potential on 1722584 [13:27] vorlon: "xnox: s390-tools Depends: s390-tools-signed (= ${DEB_VERSION}) interesting" i thought you spotted unescaped string. But i checked, it's all doing correct stuff. I guess you did "interesting" comment similar to how apw said that "omg this is so much easier, i should steal that" although it is a bit of cheat =) [13:43] vorlon: thanks for the reject, I'll make sure they get to fixing it. [13:45] -queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.9.0-0ubuntu3 => 2.9.0-0ubuntu3] (core) [13:54] xnox: yes, and it's interesting because it also implies s390-tools-signed can't have packaging-only updates [13:58] vorlon: i'm happy to decouple the two, if we do reproducible builds. Cause in practice it is very rare when stage3.bin actually changes. Thus imho I'd just make s390-tools download signed blob and ship it if it matches. And have s390-tools-signed contain sources, that are rebuilt reproducibly and publish signed blob with a version mangled to include the stage3 binary checksum. or something like that. [13:58] vorlon: somehow i think a build should be able to generate a signing tarball, be suspended, and resume with launchpad having published signed bits somewhere. Ie. i'd love to move away from this dual-source package / two build-records. [14:05] xnox: well you can talk to apw about lp signing services [14:06] That sort of rearrangement is serious work and a bit outside what apw has been doing [14:06] I don't object to the theory but it's Hard (tm) [14:07] (Well, I wouldn't do it quite like that but anyway) [14:13] vorlon, what we are doing with other signed packages is letting them have wider versions [14:16] apw: well, on grub and shim what we are doing is the -signed package depends on the unsigned one, so there are strict dependencies but the other way around and not assuming lockstep binary package versioning across source packages [14:17] vorlon, yeah i recon mine are mostly that way too, and then use a >= instead for forward ones [14:22] xnox, can you not just have the forward dep be more like Depends: >= $(DEB_VERSION) <= $(DEB_VERSION).99 [14:22] then the signing package can gain a .1 .2 if it needs to be revved without [14:26] vorlon: if I may, also we're quite close to having fully reproducible binaries for shim, modulo the signature. [14:27] the only issue at this point is the ephemeral key we use (which we could get rid of) [14:30] cjwatson: yeah =) i can dream. But e.g. Intel had a rest-api signing service like that. And OBS does something like that similarly. I.e. i'd be happy for launchpad to take the build-dep, and mangle it for me to attach sigs / replace files, before .deb is published. for example. but yeah, quite a lot of rearrangements. [14:30] for just like what - 4-5 signy things [14:41] xnox: Yes, such a project is in the LP backlog [14:41] And has sort of half a design [14:42] Won't be this cycle though [14:48] apw: do you have any idea why all the bionic daily builds are reporting linux-generic-hwe-18.04 uninstallable in bionic-proposed? I thought maybe it was build skew, but things appear to have been published 20+ hours ago and the last build failure email I have is from 7 hours ago; and I can't seem to reproduce the uninstallability locally [14:57] vorlon: sitting in new for signed overnight [15:59] -queuebot:#ubuntu-release- Unapproved: accepted bash [source] (cosmic-proposed) [4.4.18-2ubuntu3.1] [16:01] -queuebot:#ubuntu-release- Unapproved: accepted bash [source] (bionic-proposed) [4.4.18-2ubuntu1.2] [17:00] -queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (disco-proposed) [2.60.4-0ubuntu0.19.04.1] [17:06] bdmurray for lp #1831933 would you prefer if i attach debdiffs (or open MPs) or just upload to the sru queues myself? [17:06] Launchpad bug 1831933 in ubuntu-release-upgrader (Ubuntu Disco) "do-release-upgrade tries to install snaps even if it knows it can't reach the snapstore" [Undecided,New] https://launchpad.net/bugs/1831933 [17:15] ddstreet: uploading to the queues themselves is fine with me but you'll also want to run pre-build.sh so mirrors.cfg, DistUpgradeVersion.py, and the demotions files get updated. Its not necessary to document those changes in the changelog though. [17:18] ack, thanks will do [18:54] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.16.5 => 1:19.04.16.6] (core) [18:56] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (cosmic-proposed/main) [1:18.10.11.8 => 1:18.10.11.9] (core) [18:58] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.33 => 1:18.04.34] (core) [20:31] -queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.9.0-0ubuntu3] [21:40] vorlon: is https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html stuck? [21:40] i expect pass for all the openssl, and results are visible on a.u.c but not in excuses =/ i am confused. [21:43] xnox: you can view the logs under https://people.canonical.com/~ubuntu-archive/proposed-migration/log/ [21:43] the answer is yes [21:43] same reason as was being discussed in #ubuntu-devel [21:49] should I try to fix fauxpkg.py to ignore FauxPackages if it'd clobber a real pkg? [21:50] I can't really explain why this suddenly broke for gnome-shell though - my only theory is that the production copy of FauxPackages wasn't being used properly (something to do with the observed conflict) [21:59] ah [22:00] or should fauxpkg.py be changed to output the entry with Architecture: foo instead of Architecture: all? [22:03] it's not only the Architecture section that breaks it - any mismatch causes errors [22:03] ok [22:05] well if we're going to remove it then I'll pass on any fixes to the script for now [22:05] we can reconsider if it comes up again [22:06] (sorry for anyone following - this was split between #ubuntu-release and #ubuntu-devel) [22:10] Laney: Ignore-if-clobber would work too, yeah. If you can see a way to trivially slap that in somewhere, I don't think it would be wrong. [22:26] infinity: Something like https://bazaar.launchpad.net/~laney/britney/fauxpkg-no-clobber/revision/318 [22:26] Packages_arch aren't already parsed, unfortunately (but it seems to be reasonably speedy) [22:30] * Laney is off - feel free to do whatever with that [22:30] Laney: Yeah, that seems vaguely reasonable, except maybe for the section.get('Source'.. bit that I don't understand cause I don't speak python-apt. :)