[00:47] -queuebot:#ubuntu-release- New binary: hoel [arm64] (bionic-proposed/universe) [1.3.1-1] (no packageset)
[00:47] -queuebot:#ubuntu-release- New binary: multitime [arm64] (bionic-proposed/universe) [1.3-1] (no packageset)
[00:47] -queuebot:#ubuntu-release- New binary: hoel [armhf] (bionic-proposed/universe) [1.3.1-1] (no packageset)
[00:48] -queuebot:#ubuntu-release- New binary: multitime [armhf] (bionic-proposed/universe) [1.3-1] (no packageset)
[01:03] -queuebot:#ubuntu-release- New binary: hoel [ppc64el] (bionic-proposed/universe) [1.3.1-1] (no packageset)
[01:16] -queuebot:#ubuntu-release- New binary: multitime [ppc64el] (bionic-proposed/universe) [1.3-1] (no packageset)
[04:08] -queuebot:#ubuntu-release- New: accepted hoel [amd64] (bionic-proposed) [1.3.1-1]
[04:08] -queuebot:#ubuntu-release- New: accepted hoel [armhf] (bionic-proposed) [1.3.1-1]
[04:08] -queuebot:#ubuntu-release- New: accepted hoel [ppc64el] (bionic-proposed) [1.3.1-1]
[04:08] -queuebot:#ubuntu-release- New: accepted hoel [arm64] (bionic-proposed) [1.3.1-1]
[04:08] -queuebot:#ubuntu-release- New: accepted hoel [s390x] (bionic-proposed) [1.3.1-1]
[04:08] -queuebot:#ubuntu-release- New: accepted hoel [i386] (bionic-proposed) [1.3.1-1]
[04:44] -queuebot:#ubuntu-release- New: accepted multitime [amd64] (bionic-proposed) [1.3-1]
[04:44] -queuebot:#ubuntu-release- New: accepted multitime [armhf] (bionic-proposed) [1.3-1]
[04:44] -queuebot:#ubuntu-release- New: accepted multitime [ppc64el] (bionic-proposed) [1.3-1]
[04:44] -queuebot:#ubuntu-release- New: accepted multitime [arm64] (bionic-proposed) [1.3-1]
[04:44] -queuebot:#ubuntu-release- New: accepted multitime [s390x] (bionic-proposed) [1.3-1]
[04:44] -queuebot:#ubuntu-release- New: accepted multitime [i386] (bionic-proposed) [1.3-1]
[04:45] -queuebot:#ubuntu-release- New: accepted gnome-tweaks [source] (bionic-proposed) [3.27.4-1ubuntu1]
[04:47] -queuebot:#ubuntu-release- New binary: gnome-tweaks [amd64] (bionic-proposed/none) [3.27.4-1ubuntu1] (no packageset)
[04:54] -queuebot:#ubuntu-release- New: accepted gnome-tweaks [amd64] (bionic-proposed) [3.27.4-1ubuntu1]
[05:51] <cpaelzer> slangasek: yes I found that as well - since 1.3.7.8-2 it is good
[05:51] <cpaelzer> I'm abandoning the MP
[06:35] <tjaalton> it's already merged
[06:36] <tjaalton> or to be exact, changed so that it only affected the bad version
[06:41] <doko> tjaalton: freepa needs a bind9 merge
[06:42] <doko> freeipa even
[07:05] <tjaalton> doko: I know, the server team is on it
[07:15] <tjaalton> merging https://code.launchpad.net/~tjaalton/britney/hints-ubuntu/+merge/336803 would unblock python-ldap and then 389-ds-base
[08:17] <apw> tjaalton, what on earth is is attempting to merge that into ?
[08:17] <tjaalton> apw: huh, something silly
[08:17] <apw> are you merging it into the code perhaps
[08:17] <tjaalton> same mistake that cpaelzer did, apparently
[08:18] <tjaalton> I pulled hints-ubuntu, modified it and then pushed it to lp:tjaalton
[08:20] <cpaelzer> thanks that I'm not alone tjaalton :-)
[08:20] <tjaalton> :)
[08:20] <cpaelzer> this is the default that is selected, which is wrong :-/
[08:20] <apw> tjaalton, can you change what it is trying to merge it into, that isn't an editable for me
[08:21] <tjaalton> I'll try
[08:21] <tjaalton> No RSA host key is known for bazaar.launchpad.net and you have requested strict checking.
[08:22] <tjaalton> huh
[08:25] <apw> tjaalton, hmmm going to be one of those days is it
[08:25] <tjaalton> looks like it
[08:26] <apw> tjaalton, anyhow the diff looks fine when its not mad, merged and pushed
[08:26] <tjaalton> cool
[08:28] <apw> tjaalton, https://code.launchpad.net/~tjaalton/britney/hints-ubuntu/+merge/336815
[08:28] <apw> ok i found a button to resubmit it against the right thing i think
[08:32] <tjaalton> good, I couldn't
[10:10] -queuebot:#ubuntu-release- New source: ipxe-qemu-256k-compat (bionic-proposed/primary) [1.0.0+git-20150424.a25a16d-0ubuntu1]
[10:15] <cpaelzer> the above is for bug 1713490
[10:15] <cpaelzer> TL;DR a copy of xenial src:ipxe stripped of most but a few roms we need as compat
[10:15] <cpaelzer> I also need a MIR on this which I think I can only open once through new (to have the src on LP)
[10:16] <cpaelzer> so if one could take a look that would be great
[10:16] <cpaelzer> let me know if there is anything I still need to do to pass the new queue on this
[10:18] -queuebot:#ubuntu-release- New binary: libvirt [s390x] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
[10:20] <cpaelzer> and that is libvirt splitting a few submodules (in Debian) for storage support
[10:22] -queuebot:#ubuntu-release- New binary: libvirt [ppc64el] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
[10:37] -queuebot:#ubuntu-release- New binary: libvirt [arm64] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
[10:43] -queuebot:#ubuntu-release- New binary: libvirt [armhf] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
[11:00] -queuebot:#ubuntu-release- New binary: libvirt [amd64] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
[11:05] -queuebot:#ubuntu-release- New binary: libvirt [i386] (bionic-proposed/main) [4.0.0-1ubuntu1] (ubuntu-server, virt)
[11:09] <smb> Can someone drop the artful upload of ubuntu-fan from the sru queue, please? (would like to replace it with minor packaging changes)
[11:15] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-fan [source] (artful-proposed) [0.12.9~17.10.1]
[11:37] -queuebot:#ubuntu-release- New: accepted libvirt [amd64] (bionic-proposed) [4.0.0-1ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted libvirt [armhf] (bionic-proposed) [4.0.0-1ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted libvirt [ppc64el] (bionic-proposed) [4.0.0-1ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted libvirt [arm64] (bionic-proposed) [4.0.0-1ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted libvirt [s390x] (bionic-proposed) [4.0.0-1ubuntu1]
[11:37] -queuebot:#ubuntu-release- New: accepted libvirt [i386] (bionic-proposed) [4.0.0-1ubuntu1]
[11:39] <cpaelzer> thanks for those accepts
[11:39] <cpaelzer> I'd be happy about an accept or discussion on New source: ipxe-qemu-256k-compat as well
[11:52] <doko> component-mismatches are not updated ...
[11:56] <cpaelzer> If one would accept src:ipxe-qemu-256k-compat I'd know one component-mismatch more than before :-P
[12:18] -queuebot:#ubuntu-release- New binary: bind9 [s390x] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
[12:26] -queuebot:#ubuntu-release- New binary: bind9 [ppc64el] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
[12:29] -queuebot:#ubuntu-release- New binary: bind9 [amd64] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
[12:33] <ahasenack> \o/
[12:33] <ahasenack> heads up: the bind9 upload above needs python3-ply to be pulled back into main. The source and python-ply (py2 version) are in main already
[12:44] -queuebot:#ubuntu-release- New binary: bind9 [arm64] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
[12:48] -queuebot:#ubuntu-release- New binary: bind9 [armhf] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
[13:00] -queuebot:#ubuntu-release- New binary: bind9 [i386] (bionic-proposed/main) [1:9.11.2.P1-1ubuntu1] (core)
[13:56] -queuebot:#ubuntu-release- Unapproved: ubuntu-fan (artful-proposed/main) [0.12.8~17.10.1 => 0.12.9~17.10.1] (no packageset)
[14:01] <smb> ^so its back and waiting to be accepted
[14:16] <cpaelzer> hehe
[14:16] <cpaelzer> one more ping on ipxe-qemu-256k-compat (source) btw
[14:16] <cpaelzer> this really is a rename+strip of src:ipxe from former releases
[14:16] <cpaelzer> and I just realized it has to pass new queue to be able to file the MIR for it
[14:17] <cpaelzer> bug 1746255
[14:28] <cpaelzer> also libvirt in proposed migration puzzles me
[14:29] <cpaelzer> maybe one can help me to track why it is complaining about unsatisfieable Depends
[14:29] <cpaelzer> glusterfs-common is universe
[14:29] <cpaelzer> libvirt (most components) are in main
[14:29] <cpaelzer> but the link to gluster is a suggests (intentionally)
[14:29] <cpaelzer> libvirt-daemon => Suggests: libvirt-daemon-driver-storage-gluster
[14:29] <cpaelzer> libvirt-daemon-driver-storage-gluster_4.0.0-1ubuntu1_amd64.deb => Depends: glusterfs-common
[14:29] <cpaelzer> Seeded is only libvirt-daemon-system/libvirt-bin
[14:29] <cpaelzer> But proposed migration complains:
[14:29] <cpaelzer> libvirt-daemon-driver-storage-gluster/amd64 unsatisfiable Depends: glusterfs-common
[14:29] <cpaelzer> maybe it is not about main/universe after all and I miss something
[14:29] <cpaelzer> but on a system with the ppa of the same source all is installable with/without gluster as I thought it should be
[14:29] <cpaelzer> any hint is welcome
[14:31] <tjaalton> I'm weeding through all the python madness in bionic-proposed, and was wondering why pyasn1/-modules still hasn't migrated and update_output.txt shows that some packages should be uninstallable. well, turns out I can install python-construct but python-dfvfs complains that -construct can't be installed..
[14:32] <tjaalton> and I have a newer version installed already?!
[14:32] <tjaalton>  python-dfvfs : Depends: python-construct (>= 2.5.2) but it is not going to be installed
[14:33] <tjaalton> ahah
[14:33] <tjaalton> there's a braks
[14:33] <tjaalton> *breaks
[14:33] <tjaalton> newer dfvfs is in -proposed
[14:34] <tjaalton> just ftbfs while fine on debian
[14:51] -queuebot:#ubuntu-release- New: accepted bind9 [amd64] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
[14:51] -queuebot:#ubuntu-release- New: accepted bind9 [armhf] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
[14:51] -queuebot:#ubuntu-release- New: accepted bind9 [ppc64el] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
[14:51] -queuebot:#ubuntu-release- New: accepted bind9 [arm64] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
[14:51] -queuebot:#ubuntu-release- New: accepted bind9 [s390x] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
[14:52] -queuebot:#ubuntu-release- New: accepted bind9 [i386] (bionic-proposed) [1:9.11.2.P1-1ubuntu1]
[16:18] <rbasak> cpaelzer: libvirt-daemon-driver-storage-gluster_4.0.0-1ubuntu1_amd64.deb does depend on glusterfs-common.
[16:18] <rbasak> cpaelzer: if it doesn't in the source, perhaps the build added it?
[16:18] <cpaelzer> rbasak: it does, but that is fine
[16:18] <cpaelzer> as libvirt-daemon-driver-storage-gluster_4.0.0-1ubuntu1_amd64.deb itself is only suggested
[16:21] <cpaelzer> so it should not be a component mismatch
[16:21] <cpaelzer> and also glusterfs-common is available in general (I can install it)
[16:21] <cpaelzer> oh well
[16:21] <cpaelzer> maybe it depends on a specific new version of glusterfs-common that is itself blocked by something
[16:21] <cpaelzer> I need to look in that
[16:22] <cjwatson> component-mismatches-proposed is out of date and I suspect that once it comes up to date it'll show -gluster for demotion to universe
[16:22] <rbasak>  Depends: glusterfs-common, libc6 (>= 2.4), libvirt-daemon (= 4.0.0-1ubuntu1)
[16:22] <cjwatson> I might have managed to unstick it earlier; we'll see
[16:22] <cpaelzer> ok, I'll just let it be and consider it a false positive that will be resolved
[16:22] <cpaelzer> because atm that is how it looks to me
[16:23] <cpaelzer> libvirt-daemon-driver-storage-gluster is new and should be only in universe
[16:23] <rbasak> Oh, I see. Now I think I understand the problem. Never mind, sorry.
[16:23] <cjwatson> it probably just went into main by default due to being from a source in main
[16:23] <cjwatson> don't worry about it for now
[16:23] <cpaelzer> yeah
[16:23] <cpaelzer> thanks cjwatson
[16:23] <cpaelzer> all I wanted to hear
[17:15] <cjwatson> cpaelzer: as I thought.  demoting now
[17:46] <flocculant> cpaelzer: re mouse integration - just posted to bug, but as you're here ... success with ppa and tablet - thanks very much :)
[17:48] <flocculant> nvm ...
[18:00] <slangasek> has anyone analyzed why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says 'freeipa-server-dns/amd64 unsatisfiable Depends: bind9-dyndb-ldap (>= 11)' when bind9-dyndb-ldap 11.1-1 is now in bionic-proposed?
[18:00] <nacc> ahasenack: --^
[18:01] <ahasenack> slangasek: bind9 9.11 can't migrate because I missed a universe dependency (lmdb)
[18:01] <ahasenack> slangasek: I have https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1746296 and a branch for it, currently building in a ppa
[18:02] <ahasenack> slangasek: the other universe dependency we need a component-mismatch for, it's python3-ply. The source package (ply) is in main, as is the python-ply (py2) package it produces
[18:02] <slangasek> ahasenack: yes, but that shouldn't translate to "unsatisfiable dependency", it should only translate to "depends on bind9", which is also listed
[18:02] <nacc> yeah that's weird
[18:02] <nacc> they are both in universe
[18:02] <ahasenack> slangasek: that I haven't analyzed, i zeroed in in the lmdb dependency I missed
[18:03] <ahasenack> slangasek: >= 11 seems wrong, shouldn't it be >= 9.11?
[18:04] <ahasenack> oh, it's from another source package
[18:04] <ahasenack> n/m
[18:06] <ahasenack> excuses says "missing build": missing build on amd64: bind9-dyndb-ldap (from 10.1-2)
[18:07] <ahasenack> but 11.1-1 built: https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.1-1/
[18:07] <nacc> ahasenack: nice catch, that's presumably why
[18:18] <ahasenack> excuses is just not seeing the builds for some reason?
[18:18] <nacc> ahasenack: it might be lagging
[18:19] <ahasenack> it's built since december
[18:19] <nacc> ahasenack: then i don't know ;)
[18:19] <ahasenack> https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.1-1/ also says "no changes file available"
[18:20] <oSoMoN> hey, can the libreoffice i386 autopkgtest failure be ignored to allow 1:5.4.4-0ubuntu2 to migrate? it's the same failure that was ignored for the past few updates, because of bug #1699772 (java/kernel stack clash)
[18:21] <oSoMoN> (the good news is that someone from the kernel team is looking into it so hopefully a future kernel update will have a fix)
[18:28] <doko> oSoMoN: lo won't mirgrate until poppler, mpclib, mpfr4, gnustep-* tinyxml2, binutils gcc-* glibc migrate ... and probably other affected transitions
[18:29] <oSoMoN> okay, I'd better be patient then…
[18:30] <doko> oSoMoN: or help identifying stuff which still needs fixing?
[18:30] <oSoMoN> doko, sure, where do I start?
[18:32] <jbicha> doko: does LO 6 need to wait for all those transitions?
[18:32] <doko> oSoMoN: update_excuses and update_output, looking for library packages which won't migrate, i.e. transitions imported from debian and not done in Ubuntu
[18:32] <doko> jbicha: it needs poppler
[18:33] <jbicha> doko: yes, I mean does oSoMoN need to wait to upload LO 6 until after the poppler transition is done?
[18:33] <doko> so fixing autopkg tests which prevent migration of poppler helps
[18:33] <doko> ahh, maybe not
[18:50] <seb128> doko, oSoMoN, it was built before poppler was uploaded so it should be able to migrate no?
[18:50] <seb128> well before poppler at least
[18:51] <doko> no
[18:59] <LocutusOfBorg> apw, merge my patch please? (hints bzr repo)
[18:59] <oSoMoN> the poppler transition happened between I test-built LO in a PPA and I uploaded it, so I had to re-upload with a patch for the new poppler
[19:08] <slangasek> ahasenack, nacc: hmm, then it should still only translate into "depends on bind-dyndb-ldap", which appears to be the source package still building that binary in both bionic and bionic-proposed.
[19:09] <ahasenack> slangasek: for a moment I thought this dyndb-ldap package came from the bind9 source, specially because of the similar version (11.1 vs 9.11) that tricked my eye
[19:09] <nacc> slangasek: yeah, i agree; it feels like 'something' is in the wrong state
[19:09] <nacc> slangasek: rmadison reports the binaries are available, e.g., but excuses doesn't see them?
[19:09]  * slangasek nods
[19:10] <slangasek> so, launchpad says it's there, let's see if it's missing from the packages files
[19:11] <slangasek> it is present in the packages files
[19:12] <slangasek> so that's going to take some rooting around in britney state, sigh
[19:26] <nacc> doko: should i change the state of the libsodium bug task so it's back on the MIR list to modify for bionic?
[19:46]  * slangasek considers manually copying bind-dyndb-ldap to the release pocket to try to unblock
[19:56] <slangasek> ahahaha can't copy bind-dyndb-ldap because it depends on new bind9 sonames <facepalm>
[20:00] <slangasek> ah, but behold, now bind-dyndb-ldap is happy :P
[20:01] <slangasek> ahasenack, nacc: what's the current thinking wrt lmdb?  Is this getting dropped or MIRed?
[20:03] <ahasenack> slangasek: I'm dropping it at the moment, it's for a new tool to convert zone files
[20:04] <slangasek> ok
[20:04] <ahasenack> slangasek: https://launchpad.net/~ahasenack/+archive/ubuntu/bind9-drop-lmdb-1746296/+packages has packages I will test tomorrow
[20:04] <slangasek> ahasenack: test tomorrow> why, vs. me uploading them today?
[20:05] <ahasenack> I just want to be sure the only thing we will not have is that tool to convert the zone files
[20:05] <ahasenack> slangasek: would you like to review my branch perhaps?
[20:06] <ahasenack> slangasek: https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+ref/bind9-drop-lmdb-1746296
[20:06] <slangasek> ahasenack: that seems like something I could manage to test with debdiff before pushing, if necessary :) but also, it seems like that shouldn't block the long and messy proposed-migration dep chain right now
[20:06] <slangasek> sure, I'll look
[20:06] <slangasek> I guess it's still the case that I don't have access to land this branch anywhere?
[20:06] <ahasenack> slangasek: ok, let me do a quick install then. I moved to another task while the packages in the ppa were building
[20:07] <ahasenack> slangasek: probably, me neither. You can take over it with a debdiff if you are happy with it, I don't mind
[20:17] <slangasek> ahasenack: wow, so for some reason, I can't do a clean checkout of this repo; all of the win32 *vcxproj*.in files in the tree show up as modified
[20:18] <slangasek> ahasenack: seems to be some line feed issue, git knows that the files in the working dir don't match but refuses to fix them :P
[20:19] <ahasenack> slangasek: I just did a quick test with a feature that the CHANGES file say would be affected by using the new lmdb library, using the packages from that ppa, seems to have worked fine: https://pastebin.ubuntu.com/26491290/
[20:19] <slangasek> also, was I wrong to expect pristine-tar data on these branches?
[20:20] <ahasenack> created this file: https://pastebin.ubuntu.com/26491297/
[20:20] <ahasenack> slangasek: reading
[20:20] <slangasek> ahasenack: uploaded, thanks
[20:21] <ahasenack> slangasek: I don't know about pristine-tar. I cloned bind (using git ubuntu clone bind9), then created a new branch from ubuntu/devel, and that's what I pushed to lp
[20:21]  * slangasek nods
[20:21] <slangasek> right, so it was more a question of whether I should expect pristine-tar on the usd branches
[20:21] <slangasek> it's possible I was told before that I shouldn't, but I still do, because I'm difficult that way
[20:21] <ahasenack> nacc: ^ :)
[20:22] <ahasenack> slangasek: there will still be one component-mismatch on python3-ply, can you fix that?
[20:22] <ahasenack> python-ply, which comes from the same source ("ply"), is in main
[20:22] <slangasek> ahasenack: already done; will be fixed in next publisher run
[20:22] <ahasenack> great
[20:29] -queuebot:#ubuntu-release- New binary: rsyslog [s390x] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
[20:32] -queuebot:#ubuntu-release- New binary: rsyslog [ppc64el] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
[20:36] -queuebot:#ubuntu-release- New binary: rsyslog [arm64] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
[20:37] -queuebot:#ubuntu-release- New binary: rsyslog [armhf] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
[20:37] -queuebot:#ubuntu-release- New binary: rsyslog [i386] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
[20:41] -queuebot:#ubuntu-release- New binary: rsyslog [amd64] (bionic-proposed/main) [8.32.0-1ubuntu1] (core)
[20:53] <slangasek> tsimonq2: so I caught in scrollback you were discussing skipping alpha2.  I haven't seen anything to the contrary, and it's Tuesday of the milestone week, so I guess this is the plan of record?
[20:56] <nacc> ahasenack: slangasek: we have per-distro pristine-tar branches
[20:56] <nacc> slangasek: let me know if that does not answer your question
[20:56] <slangasek> nacc: so why did git-buildpackage not find them?
[20:56] <slangasek> nacc: was it because I was building from ahasenack's branch instead of from one of the usd branches?
[20:56] <nacc> slangasek: gbp ivoekd directly?
[20:56] <nacc> *invoked
[20:56] <slangasek> yeah
[20:56] <nacc> slangasek: gbp can't find them
[20:57] <nacc> gbp doesn't have any concept of multiple pristine-tar
[20:57] <nacc> we wrap all that with git-ubuntu build :)
[20:57] <nacc> it's possible that's now fixed in the latest gbp, but I think it's not still -- i'll need to look
[20:57] <nacc> basically our wrapper uses a context to checkout the "right" pristine-tar branches to 'pristine-tar' and then calls gbp
[20:58] <nacc> there is a export-orig subcommand now that makes that more accessible
[20:59] <tsimonq2> slangasek: I guess it is, yes.
[20:59] <slangasek> nacc: ah ok
[22:01] <nacc> slangasek: seeing as you did it before, would it be possible for you to promote libsodium again? LP: #1621386? it's pulled up by php7.2-cli now (which is in turn going to get promoted via the seeds)
[22:11] <slangasek> nacc: needs a new team subscriber, unity-api-team should not be considered an owner for new MIRs
[22:11] <nacc> slangasek: it does already
[22:11] <nacc> slangasek: ubuntu-server subscribed to the package
[22:12] <slangasek> nacc: <refresh> oh, so they did
[22:12] <nacc> slangasek: :)
[22:13] <nacc> i also thought i had put a comment to that effect in the MIR bug
[22:13] <slangasek> nacc: you want me to read *both* sentences of the comment?
[22:13] <nacc> slangasek: it is a lot to ask :)
[22:14] <tsimonq2> "Therefore, we will need to include it in main to support Unity 8." woah we're putting Unity 8 BACK in the archive?
[22:14]  * tsimonq2 runs
[22:16] <slangasek> it's actually just a pork barrel MIR
[22:17] <slangasek> "the Server Team will formally support unity8, in exchange for you shipping nodejs in main"
[22:17] <tsimonq2> hah :)
[22:23] <nacc> lol
[22:30] <nacc> slangasek: thanks
[23:17] <juliank> oh, rsyslog landed in NEW.
[23:17] <juliank> Kind of makes sense, I guess
[23:18] <juliank> We do have new binaries after all
[23:19] <juliank> I wonder why that did not happen when lvm2-lockd was introduced, though. that was odd.
[23:19] <juliank> or maybe it did and I did not notice
[23:20] <nacc> juliank: it did, and probably was auto-accepted
[23:20] <juliank> ah
[23:20] <juliank> well, I don't care much as long as it works :)
[23:20] <nacc> (not 100%, but just a guess)
[23:20] <nacc> auto = reviewed by an AA and accepted, i mean
[23:21] <juliank> yeah
[23:23] -queuebot:#ubuntu-release- New binary: rkt [amd64] (bionic-proposed/universe) [1.29.0+dfsg-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: otb [s390x] (bionic-proposed/universe) [6.4.0+dfsg-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New: accepted otb [s390x] (bionic-proposed) [6.4.0+dfsg-1]
[23:37] -queuebot:#ubuntu-release- New: accepted rkt [amd64] (bionic-proposed) [1.29.0+dfsg-1]
[23:37] -queuebot:#ubuntu-release- New binary: otb [ppc64el] (bionic-proposed/universe) [6.4.0+dfsg-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New: accepted otb [ppc64el] (bionic-proposed) [6.4.0+dfsg-1]