[00:20] <slangasek> sergiusens: retriggered and running; update-manager test has already passed, so that's a positive sign
[00:25] <slangasek> u-r-u also passed
[00:30] -queuebot:#ubuntu-release- New: accepted gcc-7-cross-ports [amd64] (bionic-proposed) [14ubuntu1]
[00:30] -queuebot:#ubuntu-release- New: accepted gcc-7-cross-ports [i386] (bionic-proposed) [14ubuntu1]
[03:35] <slangasek> sergiusens: well, snapcraft 2.40+18.04 passed on armhf, but apparently not before being superseded by 2.40+18.04.1 in the archive?
[03:54] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.18]
[05:17] <tsimonq2> slangasek: Can I please get your opinion on bug 1757350 when you're around?
[05:17] <ubot5> bug 1757350 in etcd (Ubuntu) "Sync etcd 3.2.17+dfsg-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1757350
[05:28] <slangasek> tsimonq2: bug claims a docker.io ftbfs as part of the rationale but docker.io was updated in bionic yesterday
[05:28] <slangasek> someone might want to actually validate that the versions of the revdeps currently in Ubuntu build with the new etcd before syncing it
[05:30] <tsimonq2> slangasek: Right, thanks; what about from a Release Team perspective (once things are sorted) irt needing an FFe?
[05:32] <slangasek> tsimonq2: if you think it needs an FFe, make it an FFe request and we'll process it; otherwise, I don't have time just at the moment to read deeply enough to know if I think it needs an FFe
[05:32] <tsimonq2> slangasek: ack
[05:38] <tsimonq2> $ syncpackage --force -s unit193 xca
[05:38] <tsimonq2> syncpackage: Source xca -> bionic/Proposed: current version 1.4.1-0ubuntu1, new version 1.4.1-1
[05:38] <tsimonq2> syncpackage: Error: The checksums of the Debian and Ubuntu packages mismatch. A fake sync using --fakesync is required.
[05:38] <tsimonq2> That's a new one.
[05:39] <slangasek> a good reason not to create your own upstream tarballs without coordinating with Debian
[05:40]  * tsimonq2 nods
[05:42] <tsimonq2> So then what does "fakesync1" mean wrt the autosyncer?
[05:42] <tsimonq2> Is it treated the same as "build1"?
[05:42] <slangasek> I don't know offhand, I'd have to look at the code
[05:43] <tsimonq2> OK
[05:43] <slangasek> but it doesn't really matter given that every autosync of this package will fail until there's a new upstream version
[05:44] <tsimonq2> :(
[05:44] <tsimonq2> Ukikie: ^
[05:48] <Ukikie> While it is my fault, I don't think I can be blamed too heavily for using the watchfile, which still matches.
[05:48] <slangasek> heh, indeed
[05:48] <slangasek> that counts as "coordinating with Debian", and who knows why Debian didn't coordinate with their own watchfile
[05:49] <Ukikie> That is, pulled from Ubuntu, uscan --download-current-version and rechecked the sum, still matches.  I'm now wondering where Debian's is from..
[05:51] <Ukikie> (And lastly, sha256 matches that of http://xca.hohnstaedt.de/xca/index.php/download \o/)
[05:55] <Ukikie> It doesn't even match the tag?  Whaa..?  Sorry, I'll go contemplate elsewhere.
[05:56] <Ukikie> Anyway, sorry about the mixup.
[05:59] <tsimonq2> slangasek: Could you please thwack the plasma-widget-* packages assigned to ~ubuntu-archive? https://bugs.launchpad.net/~ubuntu-archive/+assignedbugs
[06:01] <tsimonq2> Also, it'd be cool if I could get a c-cycle milestone to throw things at.
[06:02] <slangasek> tsimonq2: the ones you've assigned are Ubuntu-only packages?
[06:02] <tsimonq2> slangasek: Yes.
[06:27] <tsimonq2> slangasek: Thanks.
[09:06] <Laney> slangasek: ok, thanks
[09:06] <Laney> I don't think I'll be very happy if we end up diverging :(
[09:46] -queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [sync] (artful-release) [176.0.0-0ubuntu1]
[10:06] <elbrus> Laney: slangasek: juliank: regarding debian bug 893754
[10:06] <ubot5> Debian bug 893754 in autopkgtest "autopkgtest 5.1 "autopkgtest-default-release" breaks tests that exercise apt" [Normal,Open] http://bugs.debian.org/893754
[10:07] <cjwatson> tsimonq2: auto-sync treats "ubuntu" substrings in versions specially (inhibiting syncing), but it doesn't care about any other version text.
[10:07] <tsimonq2> cjwatson: ack
[10:07] <juliank> elbrus: I just sent an email
[10:09] <elbrus> juliank: reading
[10:09] <elbrus> juliank: but it is python-apt specific?
[10:09] <elbrus> as apt just works int that environment
[10:09] <juliank> apt -o Dir should fail
[10:09] <juliank> In general, it's all very fragile
[10:10] <elbrus> what exactly is fragile?
[10:10] <juliank> What happens is that if you change the root directory in apt by setting Dir, you still have the host's config files read, because you're setting Dir after they are read.
[10:10] <juliank> Now apt tries to find the release you specified in the host apt.conf(.d), but cannot find it inside Dir's sources.list and errors out
[10:10] <elbrus> my problem, why I went for APT::Default-Release is that it is agnostic for the delta between suite and codename
[10:12] <elbrus> I don't want to detect if /etc/apt/sources.list is mentioning a suite or codename, and convert if required (as that means knowing all codenames)
[10:13] <elbrus> therefor, the old method of using "release -a=" doesn't work anymore
[10:13] <juliank> elbrus: It's the same as using "release bionic"
[10:13] <juliank> without a= or n=
[10:13] <elbrus> juliank: so I don't need the a= or n=?
[10:13] <juliank> Right
[10:14] <juliank> If you just write "release foo", it checks codename, suite, version. That's precisely what APT::Default-Release generates
[10:14]  * juliank just learned that
[10:14] <elbrus> so wouldn't python-apt still error out?
[10:14] <juliank> No
[10:14] <elbrus> what's the diff?
[10:14] <juliank> The check for APT::Default-Release validity happens before it creates the pin
[10:15] <juliank> #
[10:15] <juliank> pins are not checked
[10:15] <elbrus> great
[10:15] <Laney> hey elbrus and juliank
[10:15] <elbrus> juliank: can you update the documentation of apt_preferences when you touch it again?
[10:15] <Laney> thanks for being responsive ♥
[10:16] <elbrus> np (although I will be gone for a week after today)
[10:17] <elbrus> hmm, I see an example without the a/n
[10:18] <juliank> yeah, the manpage does not really document it well, but uses it
[10:19]  * juliank writes a bug
[10:19]  * elbrus wished he knew this a year ago
[10:19] <elbrus> much headaches whould have been avoided
[10:20] <juliank> elbrus: I only learned about that today as well :)
[10:20] <elbrus> well, if you didn't know... ;)
[10:20] <juliank> elbrus: though it's been that way since $forever
[10:20] <elbrus> ack
[10:21] <juliank> b2e465d6d3 (Arch Librarian      2004-09-20 16:56:32 +0000  59)       CreatePin(pkgVersionMatch::Release,"",DefRel,990);
[10:21] <juliank> I mean, that was before bzr
[10:22] <juliank> Author: jgg, Date: 2001-02-20 07:03:16 GMT, "Join with aliencode"
[10:22] <Laney> apt's code always makes my head hurt a bit
[10:22]  * elbrus never looked at it
[10:22] <juliank> Laney: just dont read it
[10:22] <Laney> juliank: write only coding
[10:22] <Laney> :P
[10:23] <elbrus> anyways, this probably means I'll have to remove an option from autopkgtest (and ci.debian.net / debci needs adaptation as well if so)
[10:23] <elbrus> pain.
[10:23] <Laney> it's just a different style to what I'm used to, doesn't lend itself to being read in my brain
[10:23] <Laney> why does it?
[10:23] <Laney> don't you replace the default-release with the pin and done?
[10:24] <elbrus> it's an option now
[10:24] <elbrus> to set the default-release
[10:24] <juliank> well, and instead of writing that, write a pin file for the option?
[10:24] <Laney> right
[10:25] <elbrus> and ci.d.n uses it
[10:25] <elbrus> see e.g. the top of https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rqrcode-rails3/30123/log.gz
[10:25] <elbrus> hmm, no it doesn't
[10:25] <elbrus> nevermind
[10:26] <elbrus> juliank: I guess I could do that
[10:26] <elbrus> but question, if pinning doesn't need validation, why does APT::Default-Release?
[10:27] <juliank> Because more people used that then people used pins?
[10:27] <juliank> I don't know
[10:28] <juliank> there is not always a reason for why things are the way they are
[10:28] <elbrus> typically: history
[10:29] <juliank> http://bugs.debian.org/407511
[10:29] <ubot5> Debian bug 407511 in apt "apt: Wrong value for APT::Default-Release may cause unwanted " [Wishlist,Fixed]
[10:29] <juliank> that was the discussion
[10:32] <elbrus> I see
[10:33] <elbrus> by the way, I'll copy this discussion to the bug (unless somebody objects)
[10:33] <juliank> fine with me
[10:38] <Laney> elbrus: something like https://paste.debian.net/1015983/ - untested, because I can't run the chroot tests for some reason
[10:38] <Laney> feel free to start with that if you want to change it
[10:38] <Laney> np on copying to the bug from me too
[10:38] <Laney> +        with open(os.path.join(apt_dir, 'preferences.d', 'autopkgtest-fluffy-proposed')) as f: <- wrong filename
[10:41] <elbrus> Laney: thanks, shorter than I feared
[10:42] <elbrus> Laney: what is the error you get with the chroot? mounting error?
[10:42]  * elbrus couldn't run the tests the other day either
[10:42] <Laney> FileNotFoundError: [Errno 2] No such file or directory: 'chroot': 'chroot'
[10:43] <elbrus> subprocess.CalledProcessError: Command '['mount', '-o', 'bind', '/dev', '/tmp/autopkgtest.test.ovy_j2uz/chroot/dev']' returned non-zero exit status 32.
[10:43] <elbrus> hmm, different
[10:43] <Laney> back shortly, doctors appointment
[10:49] <elbrus> dear release managers; while I am here, another question
[10:50] <elbrus> I am integrating autopkgtest policy in Debian's britney
[10:50] <elbrus> Ubuntu has diverged a bit
[10:50] <elbrus> are you interested in me keeping the support (well 95% or more) for Ubuntu in
[10:50] <elbrus> or will you not merge again anyways?
[10:51] <elbrus> there is a lot in there that is not needed for Debian
[10:51] <elbrus> because in Debian, britney2 doesn't need to download anything
[11:04] -queuebot:#ubuntu-release- New binary: python-daphne [amd64] (bionic-proposed/universe) [1.4.2-1] (no packageset)
[12:05] -queuebot:#ubuntu-release- Unapproved: accepted protobuf [source] (xenial-proposed) [2.6.1-1.3ubuntu1]
[12:15] -queuebot:#ubuntu-release- New binary: protobuf [s390x] (xenial-proposed/main) [2.6.1-1.3ubuntu1] (kubuntu, ubuntu-desktop)
[12:18] -queuebot:#ubuntu-release- New binary: protobuf [ppc64el] (xenial-proposed/main) [2.6.1-1.3ubuntu1] (kubuntu, ubuntu-desktop)
[12:25] -queuebot:#ubuntu-release- New binary: protobuf [amd64] (xenial-proposed/main) [2.6.1-1.3ubuntu1] (kubuntu, ubuntu-desktop)
[12:27] <sergiusens> sil2100: hello there! When you have time, mind letting LP: #1753482 into xenial-updates?
[12:27] <ubot5> Launchpad bug 1753482 in patchelf (Ubuntu) "Please update to the newer version of patchelf in bionic" [Undecided,New] https://launchpad.net/bugs/1753482
[12:29] <apw> elbrus, i personally would hope we would continue to merge, but i guess Laney is more likely to know for sure
[12:30] <Laney> ah sorry
[12:31] <Laney> I think the policies and infrastructure around autopkgtest are likely to stay a bit different
[12:32] <apw> right, but pesumably where we can we would want to base on the debian base i assume
[12:32] <Laney> last I heard Debian wanted to have it file rc bugs, and I'm not sure that amqp is used for the queues there - rather ci.d.n scans the archive or something
[12:32] <Laney> sure
[12:38] <sil2100> sergiusens: hey! Sure, it wasn't verified in the morning, good to see it done now
[12:38] <sil2100> bdmurray: ^
[12:38] <sil2100> sergiusens: released o/
[12:47] <sergiusens> thanks! sil2100 I wanted to document it correctly before doing so :-)
[12:51] -queuebot:#ubuntu-release- New binary: protobuf [arm64] (xenial-proposed/main) [2.6.1-1.3ubuntu1] (kubuntu, ubuntu-desktop)
[13:16] -queuebot:#ubuntu-release- Unapproved: aodh (artful-proposed/main) [5.0.0-0ubuntu2 => 5.1.0-0ubuntu1] (openstack, ubuntu-server)
[13:18] -queuebot:#ubuntu-release- Unapproved: ceilometer (artful-proposed/main) [1:9.0.4-0ubuntu1 => 1:9.0.5-0ubuntu1] (openstack, ubuntu-server)
[13:19] -queuebot:#ubuntu-release- Unapproved: cinder (artful-proposed/main) [2:11.0.2-0ubuntu1 => 2:11.1.0-0ubuntu1] (openstack, ubuntu-server)
[13:19] -queuebot:#ubuntu-release- Unapproved: designate (artful-proposed/main) [1:5.0.0-0ubuntu1 => 1:5.0.1-0ubuntu1] (openstack, ubuntu-server)
[13:20] -queuebot:#ubuntu-release- Unapproved: glance (artful-proposed/main) [2:15.0.0-0ubuntu1 => 2:15.0.1-0ubuntu1] (openstack, ubuntu-server)
[13:21] -queuebot:#ubuntu-release- Unapproved: gnocchi (artful-proposed/universe) [3.1.9-0ubuntu1 => 3.1.15-0ubuntu1] (no packageset)
[13:22] -queuebot:#ubuntu-release- Unapproved: heat (artful-proposed/main) [1:9.0.2-0ubuntu1 => 1:9.0.3-0ubuntu1] (openstack, ubuntu-server)
[13:35] <elbrus> Laney: no britney uses amqp (to file)
[13:35] <elbrus> and ci.d.n just runs the tests requested by britney
[13:35] <Laney> what's the difference then?
[13:35] <elbrus> britney2 doesn't do any internet access
[13:36] <elbrus> so doesn't contact swift (which we don't have)
[13:36] <elbrus> instead it output the amqp to file and that file is uploaded to ci.d.n
[13:36] <elbrus> then the results of ci.d.n are pulled in
[13:37] <elbrus> in the initialization phase of britney run
[13:37] <elbrus> and continue from there
[13:37] <elbrus> I added a penalty/bounty system instead of gating (but gating is still my long term plan for Debian)
[13:38] <elbrus> so that is still there, it's all optional
[13:39] <elbrus> so with my current integration work nearly everything for Ubuntu is still in (at least, until commit 593acb2753)
[13:40] <elbrus> I removed one or two items as it was not worth the effort to implement a proper option, but if Ubuntu is interested in merging again, we'll have to find a way
[13:40] <elbrus> on top of my head, the retry URL is gone
[13:41] <elbrus> the rest *should* still work
[13:42] <elbrus> Paul Gevers master 7130136 autopkgtest lib/adt_testbed.py lib/autopkgtest_args.py tests/autopkgtest * Use apt pinning instead of APT::Default-Release * https://deb.li/3c7JG
[13:43] <elbrus> I verified ^^ a bit, would be cool if somebody else could give it a spin
[13:44] <elbrus> on britney, regarding the RC bug filing thing, that is just an intermediate solution for real regressions being caught by autopkgtesting (and requires manual work by somebody (= me for the time being)
[13:45] <elbrus> my expectation is that if all works well, gating will follow soon, but that is not up to me
[13:45] <elbrus> I believe the RT wants to get people off their fears first
[13:48] -queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.2-0ubuntu1.3 => 2:11.0.3-0ubuntu1] (openstack, ubuntu-server)
[13:50] <elbrus> and Laney thanks for the patch, it seems to work
[13:54] -queuebot:#ubuntu-release- Unapproved: accepted pymacaroons [source] (xenial-proposed) [0.12.0-1~ubuntu16.04.1]
[14:06] -queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (artful-proposed) [1:2.2.27-3ubuntu1.4]
[14:16] <Laney> elbrus: thanks for committing
[14:16] <Laney> I'll try to make some time to look at your stuff at some point
[14:36] -queuebot:#ubuntu-release- Unapproved: mistral (artful-proposed/universe) [5.0.0-0ubuntu1 => 5.2.2-0ubuntu1] (no packageset)
[15:05] -queuebot:#ubuntu-release- New binary: icu [s390x] (bionic-proposed/main) [60.2-3ubuntu2] (core)
[15:07] -queuebot:#ubuntu-release- New binary: icu [ppc64el] (bionic-proposed/main) [60.2-3ubuntu2] (core)
[15:08] -queuebot:#ubuntu-release- New binary: icu [amd64] (bionic-proposed/main) [60.2-3ubuntu2] (core)
[15:09] -queuebot:#ubuntu-release- New binary: icu [i386] (bionic-proposed/main) [60.2-3ubuntu2] (core)
[15:20] <sil2100> bdmurray: oh, as for SRU work: I didn't publish virtualbox into -updates today in the morning since the uploader was requesting a longer testing period
[15:21] <sil2100> bdmurray: but I leave it up to you if you want to release it yourself or not
[15:21] <sil2100> bdmurray: if anything I can always publish it Monday morning
[15:21] -queuebot:#ubuntu-release- New binary: icu [armhf] (bionic-proposed/main) [60.2-3ubuntu2] (core)
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (xenial-proposed) [2.4.18-2ubuntu3.6]
[15:22] <bdmurray> sil2100: I'd defer to the uploader
[15:29] -queuebot:#ubuntu-release- New binary: icu [arm64] (bionic-proposed/main) [60.2-3ubuntu2] (core)
[15:53] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (xenial-proposed/main) [2:10.0.7-3227872-5ubuntu1~16.04.2 => 2:10.2.0-3ubuntu0.16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[16:07] <slangasek> elbrus: thanks for the quick fix for the Default-Release issue!  wrt britney, yes, we do prefer to be able to continue merging from Debian; certainly for autopkgtest gating it would be good to have the implementations track each other, even if there might be different options in use between the releases at any given time, because it's a pretty hairy policy which would benefit from us sharing
[16:07] <slangasek> eyeballs
[16:10] <slangasek> elbrus: gating directly on autopkgtest would really be a good idea, and https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=ubuntu-devel@lists.ubuntu.com;tag=autopkgtest has some more examples now of bugs of varying severities that were caught in Ubuntu but not in Debian testing
[16:12] <slangasek> (I particularly like "your package broke ABI without soname; your revdeps autopkgtests noticed; the package got promoted to testing anyway")
[16:47] -queuebot:#ubuntu-release- New: accepted python-daphne [amd64] (bionic-proposed) [1.4.2-1]
[16:52] <elbrus> slangasek: ack on gating being the prefered solution
[16:52] <elbrus> and great that you like to want to merge in principle
[16:53] <elbrus> gives me more insentive to try and keep the code compatible with Ubuntu's implementation
[16:53] <elbrus> I would recommend upstreaming more bugfixes though... (and the Debian RT team in getting better at merging them)
[16:54] <elbrus> There are one or two commits in your repo that apply to Debian as well I think
[16:55] <slangasek> quite possibly :/
[16:57] <slangasek> infinity: how does one debug why http://people.canonical.com/~ubuntu-archive/priority-mismatches.html wants to pull in wrong things?  there's no detail like on component-mismatches saying why it's being promoted, and I'm having a hard time finding what thinks it should depend on build-essential. :P
[17:04] <cjwatson> snakefruit:/home/ubuntu-archive/mirror/ubuntu-germinate/minimal_ubuntu_bionic_amd64 is the easiest place to look
[17:04] <cjwatson> python3 Depends: dh-python Depends: dpkg-dev Recommends: build-essential, apparently
[17:06] <slangasek> cjwatson: thanks
[17:06] <cjwatson> So the proximate change is dh-python having started to depend on dpkg-dev recently, but python3's dep on dh-python is much longer-standing
[17:06] <cjwatson> Is this essentially dh-python being unable to decide whether it's a runtime thing or a development thing?
[17:07] <slangasek> possibly
[17:07] <cjwatson> Or maybe python3's dep on dh-python is transitional
[17:07] <cjwatson> Yeah, from 2013 when pybuild and dh_python3 were split out
[17:08] <xnox> it should be dropped
[17:08] <cjwatson> Arguably the right thing to do is to drop that dep now, but I bet it would still break a bunch of random builds
[17:08] <slangasek> hmm, well, I'm not sure that transition has finished or if dropping it now will cause an increase in build failures - yeah
[17:08] <slangasek> doko: ^^ opinions on the above?
[17:08] <xnox> there is lintian tag for it
[17:08] <cjwatson> Now if only we had a lintian runner for Ubuntu
[17:08] <slangasek> xnox: do you know the tag name? (maybe in the form of a link to the lintian lab)
[17:09] <xnox> https://lintian.debian.org/tags/python3-depends-but-no-python3-helper.html
[17:09] <cjwatson> Also this is https://bugs.debian.org/893477
[17:09] <ubot5> Debian bug 893477 in python3 "dh-python: New depencency (dpkg-dev) forces the installation of unwanted packages" [Important,Open]
[17:09] <xnox> just 3 things....
[17:09] <xnox> no wrong
[17:10] <cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718819 has a comment claiming 250 affected source packages
[17:10] <ubot5> Debian bug 718819 in python3 "python3 has circular Depends on dh-python" [Important,Open]
[17:10] <slangasek> xnox: hmm, the long description talks about debian/rules calling helpers, which is different than whether things directly build-depend on dh-python
[17:11] <slangasek> well also
[17:11] <slangasek> doko: why did dh-python need synced post-FF?
[17:12] <cjwatson> It might be most expedient to just drop dh-python -> dpkg-dev to Suggests for bionic; not sure
[17:13] <slangasek> I actually can't find anything in the debdiff that uses dpkg-dev
[17:14] <slangasek> I'm just going to drop that relationship for now
[17:14] <cjwatson> dpkg-architecture, apparently
[17:15] <cjwatson> hm, but not in the debdiff, indeed
[17:15] <slangasek> cjwatson: I didn't find dpkg-architecture in the debdiff LP gave me; was I looking wrong?
[17:15] <slangasek> right
[17:17] <cjwatson> yeah, it seems to just fetch it from the environment, but Helmut seems to claim in #892931 that it's required
[17:17] <cjwatson> maybe he's just confused?
[17:17] <LocutusOfBorg> bdmurray, sil2100 you can release if you want, I had an issue, but was related to an unrelated bug affecting some NVIDIA folks, and there is already a patch inside vbox
[17:17]  * cjwatson follows up to that bug
[17:18] <LocutusOfBorg> this is the bug I am referring to https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1751191
[17:18] <ubot5> Ubuntu bug 1751191 in virtualbox (Ubuntu) "Using Vbox with 3D enabled, creates strange stuttering" [High,Confirmed]
[17:18] <LocutusOfBorg> and old bug, that affects every vbox version, so not really a regression
[17:33] <LocutusOfBorg> slangasek, https://autopkgtest.ubuntu.com/packages/apport/bionic/i386 it is safe again, please drop the hint :)
[17:34] <slangasek> LocutusOfBorg: ok.  do you know what fixed it?
[17:35] <LocutusOfBorg> nope sorry
[17:35] <LocutusOfBorg> somebody on the bug pointed that they were fine
[17:35] <LocutusOfBorg> let me debug it a little bit
[17:35] <slangasek> k
[17:36] <slangasek> tsimonq2: LP: #1757657 - being the Debian maintainer does not necessarily mean I assume responsibility for fixing bugs in the package in Ubuntu ;)
[17:36] <ubot5> Launchpad bug 1757657 in heimdall-flash (Ubuntu) "Please port your package away from Qt 4" [Medium,Confirmed] https://launchpad.net/bugs/1757657
[17:36] <LocutusOfBorg> btw please accept virtualbox-hwe in bionic
[17:36] <LocutusOfBorg> it is providing an upgrade path for -hwe packages in xenial
[17:38] <LocutusOfBorg> just glib2.0 has been updated in  the meanwhile and an unrelated library
[17:38] <LocutusOfBorg> I still blame the img files, changed from adt-bionic-i386-apport-20180321-094604 to adt-bionic-i386-apport-20180321-235603
[17:39] <LocutusOfBorg> maybe something on the "host" changed in the meanwhile?
[17:41] <slangasek> not likely
[17:42] <slangasek> if something changed in the image to fix it, that might be a smaller bisect of the packages
[17:42] <slangasek> LocutusOfBorg: there seem to be a number of copies of virtualbox-hwe in source new; I assume you want them all rejected except the last
[17:43] <slangasek> LocutusOfBorg: and why does this need to be a separate source package, vs. metapackages built from the main source package?
[17:44] -queuebot:#ubuntu-release- New: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
[17:44] -queuebot:#ubuntu-release- New: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
[17:44] -queuebot:#ubuntu-release- New: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
[17:44] -queuebot:#ubuntu-release- New: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
[17:45] <LocutusOfBorg> sure, I need only the latest
[17:45] <LocutusOfBorg> well, I will need a real vbox-hwe package as soon as bionic+1 is out
[17:46] <LocutusOfBorg> right now the packaging is the same, except for the renamed binaries, and in the future, build-deps will point to hwe stuff
[17:46] <slangasek> ok
[17:46] <LocutusOfBorg> why should I diverge the main virtualbox packaging from debian, specially because I will need such separate one anyway?
[17:47] <LocutusOfBorg> and yes, I just need the latest :)
[17:47] <slangasek> so since there are no metapackages today for virtualbox in xenial, introducing them in the short term only to have them switch away from metapackages via SRU is not sensible
[17:47] <slangasek> ack
[17:47] <LocutusOfBorg> I have metapackages, probably
[17:47] <LocutusOfBorg> I have that break/replace/provides triplet
[17:47] -queuebot:#ubuntu-release- New binary: python-django-channels [amd64] (bionic-proposed/universe) [1.1.8.1-1] (no packageset)
[17:47] <LocutusOfBorg> and now I have the same for bionic
[17:48] <LocutusOfBorg> but I don't want people to switch from vbox-hwe to vbox and then to vbox-hwe again
[17:48] <LocutusOfBorg> this seems to complicate my SRU for security and bugfixes (kernel upgrades and similar)
[17:48] -queuebot:#ubuntu-release- New: accepted python-django-channels [amd64] (bionic-proposed) [1.1.8.1-1]
[17:49] <LocutusOfBorg> and moreover, most of my work is based on the assumption that I have the same packaging across releases for both debian and ubuntu, I don't want to change that
[17:49] <LocutusOfBorg> (whenever possible)
[18:08] -queuebot:#ubuntu-release- Unapproved: lttng-modules (artful-proposed/universe) [2.9.0-1ubuntu3.1 => 2.9.0-1ubuntu3.2] (no packageset)
[18:08] -queuebot:#ubuntu-release- Unapproved: lttng-modules (xenial-proposed/universe) [2.8.0-1ubuntu1~16.04.4 => 2.8.0-1ubuntu1~16.04.5] (no packageset)
[18:59] <slangasek> xnox: were there no existing consumers of libiculx.so.60 that the new libicu60 needs to declare Breaks: against?
[19:04] <tsimonq2> slangasek: 1757657> But you'll address it in Debian I hope? :)
[19:05] <tsimonq2> I mean, I can NMU, but you know the package better than I...
[19:16] -queuebot:#ubuntu-release- Unapproved: nova (artful-proposed/main) [2:16.0.4-0ubuntu1 => 2:16.1.0-0ubuntu1] (openstack, ubuntu-server)
[19:26] <slangasek> tsimonq2: I plan to eventually address it in Debian, yes; though I also no longer have the hardware to test this with
[19:27] -queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (artful-proposed) [02.18-0.1ubuntu4.1]
[19:29] -queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (xenial-proposed) [02.17-1.1ubuntu3.5]
[19:36] -queuebot:#ubuntu-release- Unapproved: accepted hdparm [source] (artful-proposed) [9.51+ds-1ubuntu0.1]
[19:36] -queuebot:#ubuntu-release- Unapproved: accepted hdparm [source] (xenial-proposed) [9.48+ds-1ubuntu0.1]
[19:39] <elbrus> Laney: what is the file size of state/results.cache in Ubuntu? (or bionic if the result is release specific)
[19:39] <elbrus> do you ever rinse it from old results?
[19:40] <xnox> slangasek, yes, there was.
[19:40] -queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (artful-proposed) [5.1.0-0ubuntu1]
[19:40] <xnox> slangasek, and i did declare the one...
[19:40] <slangasek> xnox: I don't see any new Breaks: in the libicu60 package in NEW
[19:41] <slangasek> s/new//
[19:41]  * xnox checks again
[19:41] <xnox> slangasek, bah, so the one needed was "openttd (<= 1.7.1-1)" and I added it, in the wrong package.... i aded it on the libiculx60
[19:41] <xnox> *sigh*
[19:42] -queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (artful-proposed) [1:9.0.5-0ubuntu1]
[19:42] <slangasek> xnox: ok. are you fixing now-ish, such that I can reject the current binaries and accept the next batch soon?
[19:43] <slangasek> xnox: (or I could do the upload if you're not at keyboard)
[19:43] <xnox> slangasek, i'll upload now
[19:43] <slangasek> ok
[19:44] -queuebot:#ubuntu-release- New: rejected icu [amd64] (bionic-proposed) [60.2-3ubuntu2]
[19:44] -queuebot:#ubuntu-release- New: rejected icu [armhf] (bionic-proposed) [60.2-3ubuntu2]
[19:44] -queuebot:#ubuntu-release- New: rejected icu [ppc64el] (bionic-proposed) [60.2-3ubuntu2]
[19:44] -queuebot:#ubuntu-release- New: rejected icu [arm64] (bionic-proposed) [60.2-3ubuntu2]
[19:44] -queuebot:#ubuntu-release- New: rejected icu [s390x] (bionic-proposed) [60.2-3ubuntu2]
[19:44] -queuebot:#ubuntu-release- New: rejected icu [i386] (bionic-proposed) [60.2-3ubuntu2]
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (artful-proposed) [2:11.1.0-0ubuntu1]
[19:45] -queuebot:#ubuntu-release- Unapproved: accepted designate [source] (artful-proposed) [1:5.0.1-0ubuntu1]
[19:47] -queuebot:#ubuntu-release- Unapproved: accepted glance [source] (artful-proposed) [2:15.0.1-0ubuntu1]
[19:50] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (artful-proposed) [1:9.0.3-0ubuntu1]
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.3-0ubuntu1]
[19:52] -queuebot:#ubuntu-release- New binary: icu [s390x] (bionic-proposed/main) [60.2-3ubuntu3] (core)
[19:54] -queuebot:#ubuntu-release- Unapproved: accepted mistral [source] (artful-proposed) [5.2.2-0ubuntu1]
[19:54] <bdmurray> coreycb: the gnocchi upload has a lot of removals to AUTHORS and Changelog - is that deliberate?
[19:55] -queuebot:#ubuntu-release- New binary: icu [ppc64el] (bionic-proposed/main) [60.2-3ubuntu3] (core)
[19:58] <coreycb> bdmurray: let's hold off on that until i find out
[19:58] <coreycb> bdmurray: thanks for the uploads
[20:02] -queuebot:#ubuntu-release- New binary: icu [arm64] (bionic-proposed/main) [60.2-3ubuntu3] (core)
[20:02] <coreycb> bdmurray: ok let's reject that please
[20:03] -queuebot:#ubuntu-release- New binary: icu [amd64] (bionic-proposed/main) [60.2-3ubuntu3] (core)
[20:03] -queuebot:#ubuntu-release- New binary: icu [armhf] (bionic-proposed/main) [60.2-3ubuntu3] (core)
[20:04] -queuebot:#ubuntu-release- New binary: icu [i386] (bionic-proposed/main) [60.2-3ubuntu3] (core)
[20:14] -queuebot:#ubuntu-release- Unapproved: python-oslo.context (xenial-proposed/main) [2.2.0-2 => 2.2.0-2ubuntu1] (kubuntu, openstack, ubuntu-desktop, ubuntu-server)
[20:15] <xnox> slangasek, new icu is in
[20:15] <slangasek> xnox: indeed
[20:16] -queuebot:#ubuntu-release- New: accepted icu [amd64] (bionic-proposed) [60.2-3ubuntu3]
[20:16] -queuebot:#ubuntu-release- New: accepted icu [armhf] (bionic-proposed) [60.2-3ubuntu3]
[20:16] -queuebot:#ubuntu-release- New: accepted icu [ppc64el] (bionic-proposed) [60.2-3ubuntu3]
[20:16] -queuebot:#ubuntu-release- New: accepted icu [arm64] (bionic-proposed) [60.2-3ubuntu3]
[20:16] -queuebot:#ubuntu-release- New: accepted icu [s390x] (bionic-proposed) [60.2-3ubuntu3]
[20:16] -queuebot:#ubuntu-release- New: accepted icu [i386] (bionic-proposed) [60.2-3ubuntu3]
[20:55] -queuebot:#ubuntu-release- Unapproved: rejected gnocchi [source] (artful-proposed) [3.1.15-0ubuntu1]
[21:21] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (artful-proposed) [2:16.1.0-0ubuntu1]
[21:31] -queuebot:#ubuntu-release- Unapproved: accepted python-oslo.context [source] (xenial-proposed) [2.2.0-2ubuntu1]
[22:25] <slangasek> hmmm ruby doing a lot of segfaulting on arm64? https://launchpad.net/ubuntu/+source/ohcount/3.1.0-1/+build/14240657
[23:16] <tsimonq2> infinity, slangasek: Could I please get some more thwacking? https://is.gd/pRDB9
[23:16] <tsimonq2> argh not again
[23:16] <tsimonq2> https://is.gd/pRDB9o
[23:17] <tsimonq2> that
[23:17] <tsimonq2> slangasek: that Debian package> ack
[23:35] <tsimonq2> Laney: bug 1758082> The Release Team might want to revoke their ACK now that Kubuntu is NACK.
[23:35] <ubot5> bug 1758082 in ubiquity (Ubuntu) "[UIFe] Update ubiquity's Minimal Install page to match the spec" [Undecided,Confirmed] https://launchpad.net/bugs/1758082
[23:42] <RAOF> It'd be convenient to get the Mir FFe (bug #1757952) approved soon; it should also be easy to approve :)
[23:42] <ubot5> bug 1757952 in mir (Ubuntu) "FFe request for Mir 0.31.0.1" [Undecided,New] https://launchpad.net/bugs/1757952
[23:44] <RAOF> (Mostly so that we don't have to support libmiral2 for the duration ☺)