/srv/irclogs.ubuntu.com/2019/06/19/#ubuntu-release.txt

-queuebot:#ubuntu-release- New source: ubuntustudio-menu-add (eoan-proposed/primary) [0.1]00:47
tewardrelease 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
tewards/release team/archive admins/01:09
tewardvorlon: ^ if you can01:09
-queuebot:#ubuntu-release- Unapproved: bash (cosmic-proposed/main) [4.4.18-2ubuntu3 => 4.4.18-2ubuntu3.1] (core)01:09
-queuebot:#ubuntu-release- Unapproved: bash (bionic-proposed/main) [4.4.18-2ubuntu1.1 => 4.4.18-2ubuntu1.2] (core)01:15
vorlonteward: done04:00
-queuebot:#ubuntu-release- New: rejected ubuntustudio-menu-add [source] (eoan-proposed) [0.1]04:01
-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]07:24
jamespagebdmurray: sorry missed your ping - let me look09:07
jamespagebdmurray: yes that's fine to superceed the one already in proposed - the patches for 2.3 are included in the new point release09:10
jamespagesahid: ^^09:10
-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:19
-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]09:23
* rbasak is (virtually) sprinting today and generally unavailable for SRU work - sorry10:11
-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)10:34
=== cpaelzer__ is now known as cpaelzer
-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:54
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1035.37]10:55
acheronukvorlon: regards lmdb being required for appstream and possible MIR: https://github.com/ximion/appstream/commit/358e9394631b87797f56dcb7e09e459b4044e631#commitcomment-3399517812:18
Laneyacheronuk: it's going to need it, feel free to get that filed if you want12:51
Laneydesktop team's going to sign on for that one12:51
* Laney attempts to deploy an autopkgtest-lxd-worker12:53
coreycbbdmurray: dosaboy is going to update the regression potential on 172258413:13
xnoxvorlon:  "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:27
tewardvorlon: thanks for the reject, I'll make sure they get to fixing it.13:43
-queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.9.0-0ubuntu3 => 2.9.0-0ubuntu3] (core)13:45
vorlonxnox: yes, and it's interesting because it also implies s390-tools-signed can't have packaging-only updates13:54
xnoxvorlon:  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
xnoxvorlon:  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.13:58
vorlonxnox: well you can talk to apw about lp signing services14:05
cjwatsonThat sort of rearrangement is serious work and a bit outside what apw has been doing14:06
cjwatsonI don't object to the theory but it's Hard (tm)14:06
cjwatson(Well, I wouldn't do it quite like that but anyway)14:07
apwvorlon, what we are doing with other signed packages is letting them have wider versions14:13
vorlonapw: 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 packages14:16
apwvorlon, yeah i recon mine are mostly that way too, and then use a >= instead for forward ones14:17
apwxnox, can you not just have the forward dep be more like Depends: >= $(DEB_VERSION) <= $(DEB_VERSION).9914:22
apwthen the signing package can gain a .1 .2 if it needs to be revved without14:22
cyphermoxvorlon: if I may, also we're quite close to having fully reproducible binaries for shim, modulo the signature.14:26
cyphermoxthe only issue at this point is the ephemeral key we use (which we could get rid of)14:27
xnoxcjwatson:  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
xnoxfor just like what - 4-5 signy things14:30
cjwatsonxnox: Yes, such a project is in the LP backlog14:41
cjwatsonAnd has sort of half a design14:41
cjwatsonWon't be this cycle though14:42
vorlonapw: 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 locally14:48
apwvorlon: sitting in new for signed overnight14:57
-queuebot:#ubuntu-release- Unapproved: accepted bash [source] (cosmic-proposed) [4.4.18-2ubuntu3.1]15:59
-queuebot:#ubuntu-release- Unapproved: accepted bash [source] (bionic-proposed) [4.4.18-2ubuntu1.2]16:01
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (disco-proposed) [2.60.4-0ubuntu0.19.04.1]17:00
ddstreetbdmurray for lp #1831933 would you prefer if i attach debdiffs (or open MPs) or just upload to the sru queues myself?17:06
ubot5Launchpad 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/183193317:06
bdmurrayddstreet: 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:15
ddstreetack, thanks will do17:18
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.16.5 => 1:19.04.16.6] (core)18:54
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (cosmic-proposed/main) [1:18.10.11.8 => 1:18.10.11.9] (core)18:56
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.33 => 1:18.04.34] (core)18:58
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.9.0-0ubuntu3]20:31
xnoxvorlon:  is https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html stuck?21:40
xnoxi expect pass for all the openssl, and results are visible on a.u.c but not in excuses =/ i am confused.21:40
Laneyxnox: you can view the logs under https://people.canonical.com/~ubuntu-archive/proposed-migration/log/21:43
Laneythe answer is yes21:43
Laneysame reason as was being discussed in #ubuntu-devel21:43
Laneyshould I try to fix fauxpkg.py to ignore FauxPackages if it'd clobber a real pkg?21:49
LaneyI 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:50
xnoxah21:59
vorlonor should fauxpkg.py be changed to output the entry with Architecture: foo instead of Architecture: all?22:00
Laneyit's not only the Architecture section that breaks it - any mismatch causes errors22:03
vorlonok22:03
Laneywell if we're going to remove it then I'll pass on any fixes to the script for now22:05
Laneywe can reconsider if it comes up again22:05
Laney(sorry for anyone following - this was split between #ubuntu-release and #ubuntu-devel)22:06
infinityLaney: 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:10
Laneyinfinity: Something like https://bazaar.launchpad.net/~laney/britney/fauxpkg-no-clobber/revision/31822:26
LaneyPackages_arch aren't already parsed, unfortunately (but it seems to be reasonably speedy)22:26
* Laney is off - feel free to do whatever with that22:30
infinityLaney: 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. :)22:30

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!