[00:32] -queuebot:#ubuntu-release- Unapproved: supertux (xenial-proposed/universe) [0.4.0-1 => 0.4.0-1ubuntu1] (no packageset)
[09:16] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (yakkety-proposed) [2.02~beta2-36ubuntu11.1]
[09:16] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (yakkety-proposed) [2.02~beta2-36ubuntu11.1]
[09:23] <Laney> if anyone is good at alignment issues
[09:23] <Laney> pdl/armhf...
[09:27] <Laney> xnox: could you look at libterm-readline-gnu-perl and libtext-bibtex-perl which both fail on s390x please?
[09:27] <Laney> even if to decide if they should be removed
[09:34] <cjwatson> robru,oSoMoN: you don't need to ask me whether it's in production yet, just watch the status of the Launchpad task on https://bugs.launchpad.net/launchpad/+bug/1633608 (though I don't recall whether this will apply to copies)
[09:34] <ubot5`> Ubuntu bug 1633608 in Launchpad itself "Bileto PPA upload rejections are lost to the ether" [High,In progress]
[09:35] <oSoMoN> cjwatson, thanks, I subscribed to the bug
[09:54]  * cjwatson blacklists the GHC 8 transition for now
[09:54] <cjwatson> (this time in a less hacky way)
[10:03] <xnox> Laney, i want to say that those failures are normal, because terminals are weird on s390x. Let try building it on a possibly slightly more conventional installation, to see if e.g. the launchpad builder's configuration can be tweaked.
[10:03] <xnox> however these things did build before. somehow.
[10:22] <apw> cjwatson, is there any way we could get the rejection messages to queuebot ?
[10:23] <apw> cjwatson, or perhaps cc: the emails to -changes or something
[10:28] <cjwatson> a few years ago there was a bunch of work to store them for later auditing
[10:28] <cjwatson> but it was never quite completed
[10:28] <cjwatson> probably better to finish that than to add hacks
[10:35] <xnox> Laney, https://launchpad.net/ubuntu/+source/libtext-bibtex-perl/0.76-1ubuntu1
[10:35] <xnox> and https://rt.cpan.org/Public/Bug/Display.html?id=96593
[10:36] <Laney> xnox: nice, that's a handy find
[10:43]  * Laney might have a patch for pdl
[10:43]  * Laney is new to this alignment shizzle though
[10:43]  * Laney test builds
[10:49] <xnox> Laney, somehow readline state ends up as NONE(0) instead of INITIALIZED(2), there is INITIALIZING(1) in between as well.
[10:49] <xnox> enoclue at the moment why =)
[10:51] <xnox> found it, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840689 will get a better fix for it, but first coffee.
[10:51] <ubot5`> Debian bug 840689 in libterm-readline-gnu-perl "libterm-readline-gnu-perl: FTBFS on 64-bit big endian architectures" [Serious,Open]
[11:09] <Laney> xnox: yeah, saw that - the upstream dude says he will do a proper fix, whatever that means :-)
[11:10] <xnox> it means use unsigned, when unsigned is due
[11:15] <apw> xnox, hopefully it means use long when long is due
[11:15] <Laney> always long your longs
[11:16] <xnox> yeah.
[11:16] -queuebot:#ubuntu-release- Unapproved: webbrowser-app (xenial-proposed/main) [0.23+16.04.20160413-0ubuntu1 => 0.23+16.04.20161028-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
[11:16] <xnox> Gnu.xs:539:5: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] horum. I fail this morning
[11:16] <apw> it was broken then moment they had a cast in there to anything other than void*
[11:23] <xnox> needs patching perl code as well. and magic bridge functions to/from C
[11:23] <xnox> argh
[11:33] <apw> xnox, if there is a proper upstream fix coming ... could we not use the dirty hack until it comes ?
[11:34] <xnox> apw, well dirty hack is scary to me =) if 64 bit, and if big endian, point randomly to the next memory address, as that will be the "right" half of long.
[11:34] <xnox> I think i have it properly in a second. And if not, will upload dirty hack.
[11:34] <apw> xnox, the layout of a long in BE is pretty well defined
[11:34] <xnox> true
[11:35] <apw> what they are doing makes me physically sick, but it likely is "safe"
[11:35] <xnox> there is handing for charp vs pint, adding pulong there.
[11:36] <xnox> to keep up with their sickness
[11:50] <xnox> Laney, apw - https://rt.cpan.org/Public/Bug/Display.html?id=118371#txn-1679838
[11:50] <xnox> uploaded
[11:52] <xnox> all is good https://launchpad.net/ubuntu/+source/libterm-readline-gnu-perl/1.34-1ubuntu1
[11:53] <Laney> xnox: Ta
[11:54] <Laney> and my pdl seems to build so I'll copy that
[11:55] <xnox> apw, wanna shed some light into bus errors that started to appear on armhf in the galera-3 icinga2 and percona-galera-3 packages? http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.61.html
[11:55] <xnox> i have a theory that the new arm64 builders are better at emitting bus errors, and they simply were there the whole time.
[11:56] <xnox> i.e. unaligned access or some such.
[11:56] <Laney> unaligned access indeed
[11:56] <xnox> also have you ever seen this before: https://launchpadlibrarian.net/291194249/buildlog_ubuntu-zesty-s390x.libbitcoin_2.11.0-1ubuntu1_BUILDING.txt.gz
[11:56] <xnox> devlibs error: There is no package matching [ld64-1-dev] and noone provides it, please report bug to d-shlibs maintainer
[11:57] <xnox> ah https://lists.debian.org/debian-mentors/2016/06/msg00648.html
[12:00] <doko> xnox: the change to 64bit kernels triggered a few unaligned accesses for armhf, but I'm not aware of any triggered on arm64
[12:00] <xnox> doko, right, i see three new failures / unagligned accesses triggered on armhf.
[12:00] <xnox> =(
[12:01]  * xnox is reading https://lists.debian.org/debian-mentors/2016/06/msg00652.html and does not understand
[12:01] <cjwatson> We're intentionally not putting any effort into that because it brings us closer to where we wanted to be anyway for phones
[12:01] <cjwatson> (Because the Android kernel does much the same thing; there was previously a problem whereby stuff would succeed on builders and then fail on devices)
[12:02] <cjwatson> So the unaligned accesses should be fixed in packages
[12:02] <xnox> yeah, i understand that the right thing to do is to fix the packages.
=== Pici is now known as ZarroBoogs
[12:51] <Laney> slangasek: I don't understand https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/2074 - doesn't look like they were gone from proposed to me?
[12:51] <Laney> and they've moved back to release now
[12:55] <xnox> Laney, slangasek - i wonder if we can remove remaining broken / untransitioned binaries for perl to get it migrate. =) or are they non-leaf packages?
[12:55] <xnox> as in is all of uwsgi, or just the perl uwsgi?
[12:59] <Laney> xnox: They were demoted
[12:59] -queuebot:#ubuntu-release- Unapproved: metacity (xenial-proposed/main) [1:3.18.7-0ubuntu0.1 => 1:3.18.7-0ubuntu0.2] (ubuntu-desktop)
[13:00] <Laney> I guess we'll see what britney has to say about it (if it's only these packages or if there are other problems too)
[13:00] <xnox> Laney, but you should remove binaries & demote src to -proposed. That way it will be stuck with failure to build and will not migrate by virtue of miracles.
[13:00] <xnox> or keep a block-proposed bug against them.
[13:01] <Laney> They were blocked
[13:01] <xnox> ok. /me goes back to finishing boost1.61 transition laggers =)
[13:02] <Laney> there's a few random failures @ proposed-migration
[13:23] <apw> Laney, there appear to be a coulple of cases where the armhf builds are missing too
[13:24] <apw> Laney, and indeed similarly for s390x, which is oddness
[13:24] <Laney> apw: I think those are ones that just got uploaded
[13:25] <apw> Laney, ahh ok, then i'll wait a bit ... before listing them
[13:26] <Laney> pdl, some readline thing
[13:26] <Laney> and something else
[13:26] <apw> pdl yay
[13:37] <xnox> slangasek, powerpc dropped as release arch in debian
[14:01] -queuebot:#ubuntu-release- Unapproved: ido (xenial-proposed/main) [13.10.0+15.10.20151002-0ubuntu1 => 13.10.0+16.04.20161028-0ubuntu1] (ubuntu-desktop) (sync)
[14:16] <Laney> Just those few (re)removals and autopkgtest failures then
[14:36] -queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.14 => 1.2.15] (core)
[15:32] -queuebot:#ubuntu-release- Unapproved: nova-lxd (xenial-proposed/main) [13.0.0-0ubuntu3 => 13.0.0-0ubuntu3.1] (ubuntu-server)
[15:57] <slangasek> Laney: I did remove those packages from zesty-proposed; which ones do you see still there, at the perl 5.22 versions?
[15:58] <slangasek> Laney: regardless, demoting them to -proposed was the wrong thing in the first place
[16:00] <slangasek> Laney: it's possible there was a race between my removal being processed, and p-m re-copying them from -proposed after I dropped the hints but before the publisher had finished making them disappear from -proposed; this was all done during the window when publishing was really slow
[16:00] <slangasek> Laney: (re-removed now from zesty)
[16:00] <Laney> slangasek: Riiiight - so what's your rule of thumb for demotion vs removal then?
[16:01] <slangasek> Laney: the only time we ought to demote a package is if it depends on something else that's being removed, but itself is not buggy and requires no changes to become installable
[16:02] <Laney> slangasek: If you remove them, they won't come back via autosync, right?
[16:02] <slangasek> Laney: they absolutely will
[16:03] <Laney> I thought it checked for an explicit removal
[16:03] <slangasek> which is what we want to happen, if the package has gotten an upload in Debian that (hopefully) fixes the RC bug that got it removed from testing
[16:03] <slangasek> if it does, that's news to me and behavior that I think should be corrected
[16:03] <slangasek> it won't try to re-autosync at the same /version/
[16:04] <Laney> I certainly see entries that look like that in http://people.canonical.com/~ubuntu-archive/auto-sync/current.log
[16:04] <cjwatson> Uh
[16:04] <Laney> salmon, sga
[16:04] <cjwatson> slangasek: Checking for removals was absolutely deliberate and not something I think should be corrected
[16:04] <Laney> (So that's why I was asking for demotion rather than removal)
[16:05] <slangasek> cjwatson: really?  I thought we had the sync-blacklist for things we were removing and didn't want back
[16:05] <cjwatson> slangasek: That was a nightmare
[16:05] <slangasek> hmm
[16:05] <slangasek> well, I didn't get the memo that this behavior had ever changed ;)
[16:05] <cjwatson> slangasek: It was around the time auto-sync moved to client side, and I banged on about it for a while :)
[16:05] <slangasek> and, as I commented on ubuntu-release, leaving stuff in -proposed is also a bit of a nightmare
[16:06] <cjwatson> IMO and IME auto-syncing stuff that's been removed is just too error-prone
[16:06] <slangasek> I'd much rather require AAs to maintain the sync-blacklist (which I still was!) than to bump stuff in -proposed and make update_excuses unusable
[16:06] <slangasek> :/
[16:07] <cjwatson> The auto-sync log shows what hasn't been synced due to a previous removal
[16:07] <cjwatson> I think it's sufficient to just take a brief glance through that from time to time
[16:07] <slangasek> ok
[16:07] <cjwatson> (I used to do that)
[16:08] <slangasek> but if my first inclination, when glancing at what's not been synced for this reason, is to sync them all and see what sticks? :)
[16:08] <slangasek> anyway
[16:08] <slangasek> gotta go chase dinner on the streets of Bucharest now
[16:08] <cjwatson> slangasek: the auto-sync log tries to give you an indication of why things were removed
[16:09] <cjwatson> IME it's a mix of short-term and long-term reasons
[16:09] <cjwatson> I don't at all object to things being added to the sync-blacklist when the decision is that they should never be shipped in Ubuntu
[16:10] <Laney> apw: Could you take care of my 4 new requests on https://bugs.launchpad.net/ubuntu/+source/kvirc/+bug/1636804 please?
[16:10] <ubot5`> Ubuntu bug 1636804 in nama (Ubuntu) "perl 5.24 demotions" [Undecided,New]
[16:10] <cjwatson> But quite often the next Debian upload after a removal doesn't in fact address the reason it was removed in Ubuntu, e.g. due to stricter build requirements; or the last version in Ubuntu had a delta that should be reapplied if the package is reintroduced
[16:10] <Laney> I don't know if this conversation establishes a new rule about whether you should remove or demote, sorry :(
[16:10] <cjwatson> And there was an antipattern I observed where people added stuff to the sync-blacklist that wasn't actually for a long-term reason
[16:11] <cjwatson> For instance, people were blacklisting things that were removed because they currently failed to build
[16:11] <cjwatson> That was really undiscoverable and so a bunch of packages were inadvertently not shipped when they could have been
[16:11] <cjwatson> So I tried to push for blacklisting only for long-term reasons
[16:12] <Laney> I like(d) using demotion of in-sync things to mean "this will probably be fixed by the next autosync"
[16:12] <Laney> I grant that it does cause excuses to become cluttered if that takes a while
[16:12] <cjwatson> I think it would be good to surface auto-sync's log output in a less plaintexty way
[16:33] <xnox> slangasek, imho removing binaries + demote src to -proposed is fine. and let those things stuck failing to build.
[16:33] <xnox> and auto-sync back in, if and when debian fixes things.
[16:34] <xnox> we need to mimic "removed from testing, broken in sid" somehow on our side.
[16:40] -queuebot:#ubuntu-release- New binary: libcgicc [ppc64el] (zesty-proposed/universe) [3.2.16-0.1~build1] (no packageset)
[16:40] -queuebot:#ubuntu-release- New binary: libcgicc [amd64] (zesty-proposed/universe) [3.2.16-0.1~build1] (no packageset)
[16:40] -queuebot:#ubuntu-release- New binary: libcgicc [armhf] (zesty-proposed/universe) [3.2.16-0.1~build1] (no packageset)
[16:40] -queuebot:#ubuntu-release- New binary: libcgicc [arm64] (zesty-proposed/universe) [3.2.16-0.1~build1] (no packageset)
[16:42] -queuebot:#ubuntu-release- New binary: libcgicc [i386] (zesty-proposed/universe) [3.2.16-0.1~build1] (no packageset)
[16:43] -queuebot:#ubuntu-release- New binary: libcgicc [powerpc] (zesty-proposed/universe) [3.2.16-0.1~build1] (no packageset)
[16:43] -queuebot:#ubuntu-release- New binary: libcgicc [s390x] (zesty-proposed/universe) [3.2.16-0.1~build1] (no packageset)
[17:26] <wxl> so ppc has been dropped as a release architecture from debian. does that mean we're going to be canning the support in ubuntu? (note this does NOT apply to ppc64el) https://lists.debian.org/debian-powerpc/2016/10/msg00125.html
[17:30] <mdeslaur> wxl: infinity's main workstation is a powerpc ;)
[17:39] <wxl> mdeslaur: so i guess i shouldn't expect a response from him any time soon XD
[17:44] -queuebot:#ubuntu-release- New: accepted fwupd [amd64] (zesty-proposed) [0.7.4-2]
[17:46] <balloons> cyphermox, slangasek, I have confirmed $DPKG_MAINTSCRIPT_ARCH is blank during initial installation. This causes the debconf message about invalid arch to appear on valid architecture systems. How would you like to fix the logic?
[19:02] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (precise-proposed/main) [4.1.ESV-R4-0ubuntu5.11 => 4.1.ESV-R4-0ubuntu5.12] (core)
[19:03] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.7 => 4.2.4-7ubuntu12.8] (core)
[19:04] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.3 => 4.3.3-5ubuntu12.4] (core)
[19:04] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (yakkety-proposed/main) [4.3.3-5ubuntu15 => 4.3.3-5ubuntu15.1] (core)
[19:06] -queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.1-0ubuntu1.1 => 2:13.1.2-0ubuntu2] (openstack, ubuntu-server)
[19:25] -queuebot:#ubuntu-release- Unapproved: rejected nova [source] (xenial-proposed) [2:13.1.2-0ubuntu2]
[19:38] -queuebot:#ubuntu-release- Unapproved: openstack-trove (xenial-proposed/universe) [1:5.1.1-0ubuntu1 => 1:5.1.1-0ubuntu2] (no packageset)
[19:48] <cyphermox> balloons: I think we want not DPKG_MAINTSCRIPT_ARCH in the .config file; I shipped an attempt at fixing this in my PPA friday, I will look in a few seconds
[19:48] <cyphermox> can someone please reject shim-signed in yakkety queue?
[19:48] <balloons> cyphermox, ack. I switched it out to replace the arch by using deb_host_arch in rules, and writing out the config.in file
[19:49] <balloons> what do you think of that approach?
[19:49] <cyphermox> yuck
[19:49] <cyphermox> but hey, if it works...
[19:49] <cyphermox> I'd need to see the diff
[19:52] <balloons> cyphermox, heh. Well I can say just pushing back the dpkg --print-architecture version does work
[19:52] <balloons> would you prefer that?
[19:53] <cyphermox> yea, I would
[19:54] <cyphermox> want to get me a debdiff against the juju currently in proposed, I could sponsor that now? :)
[19:54] <balloons> sure thing. I have one for yak/zest too
[19:58] <cyphermox> what for? that one wouldn't prompt
[19:58] <cyphermox> but we also need the xenial
[19:59] <balloons> cyphermox, ohh, for the missing dh_install and missing dependency in the first upload
[19:59] <cyphermox> oh, right
[20:01] <cyphermox> jderose: hey
[20:01] <jderose> cyphermox: hey back :)
[20:16] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.2-0ubuntu2]
[20:19] <balloons> cyphermox, xenial: http://paste.ubuntu.com/23408418/
[20:20] -queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (xenial-proposed) [13.0.0-0ubuntu3.1]
[20:26] <balloons> cyphermox, I hope this works for yakkety/zesty: http://paste.ubuntu.com/23408442/
[20:31] <cyphermox> can we close a bug that describes the regression on yakkety/zesty please?
[20:32] <cyphermox> and is there one for the prompting on xenial?
[20:34] <balloons> cyphermox, ohh, new bugs? This is follow-up imho on the current SRU bugs
[20:35] <balloons> I need to put verification failed in there, or however you wish
[20:35] <cyphermox> I think we might want to track them separately on account of having to upload on top of something already in proposed
[20:35] <cyphermox> or maybe re-close, yeah,
[20:36] <balloons> I would typically see it as verification failed, new upload, re-verify
[20:36] <cyphermox> wfm
[20:36] <balloons> I guess we should re-mention the specific bugs?
[20:36] <cyphermox> yes
[20:37] <balloons> cyphermox, bug 1631038 for sysctl. We don't technically have a bug for the arch issues in the conf script. I guess I would use bug 1617440
[20:37] <ubot5`> bug 1631038 in juju-release-tools "Need /etc/sysctl.d/10-juju.conf" [High,Fix committed] https://launchpad.net/bugs/1631038
[20:37] -queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.21.3 => 1.21.4] (core)
[20:37] <ubot5`> bug 1617440 in juju-core (Ubuntu Yakkety) "[SRU] Juju 2 GA" [High,Fix committed] https://launchpad.net/bugs/1617440
[20:38] <cyphermox> isn't there something for the no-longer-supports-32bit?
[20:39] <slangasek> cjwatson: +1 for only blacklisting due to long-term issues; -1 for pushing to -proposed, which leaves the bottom of update_excuses full of things that are not actionable :)
[20:39] <balloons> cyphermox, bug 1614969
[20:39] <ubot5`> bug 1614969 in juju-core-1 (Ubuntu) "Juju packaging allows builds for unsupported architectures" [Undecided,New] https://launchpad.net/bugs/1614969
[20:40] <slangasek> balloons: "blank during initial installation" - er it should always be set, whether initial install or upgrade.... oh, are you checking this variable from the .config script?
[20:40] <slangasek> right, cyphermox responded. ok
[20:40] <balloons> slangasek, yep. Absolutely confirmed nothing is set when run during install
[20:41] <slangasek> balloons: it's not 'during install', it's "when used from the .config script"
[20:41] <slangasek> because the .config script is called from apt initially, /not/ via dpkg
[20:41] <balloons> slangasek, it IS set if I run a dpkg-reconfigure. sure ...
[20:43] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (yakkety-proposed) [1.21.4]
[20:43] <balloons> slangasek, are you comfortable then just using dpkg --print-architecture for the config?
[20:43] <balloons> I converted the config file to use a .in file, and set it based on DEB_HOST_ARCH in debian rules and was playing with that, but it wasn't as desired, so, we're back to as it was
[20:44] <slangasek> balloons: yes, in that context it's probably better
[20:56] <cyphermox> slangasek: all good, I'll do the sponsorings for balloons now
[21:05] <cyphermox> slangasek: could you please also review that new shim-singed? :)
[21:07] <ginggs> shim-singed as in sung or slightly burnt?
[21:08] <slangasek> cyphermox: probably not tonight yet, sorry
[21:08] <cyphermox> ginggs: as in slightly burnt
[21:08] <cyphermox> permanently-renamed, too
[21:08] <cyphermox> maybe I'll consider shim-sung for the next upload
[21:09] <cyphermox> slangasek: ack
[21:24] -queuebot:#ubuntu-release- Unapproved: juju-core (xenial-proposed/main) [2.0.0-0ubuntu0.16.04.1 => 2.0.0-0ubuntu0.16.04.2] (ubuntu-server)
[21:24] -queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0.0-0ubuntu0.16.10.1 => 1:2.0.0-0ubuntu1.16.10.2] (ubuntu-server)
[21:24] <cyphermox> please reject juju-core in yakkety
[21:24] <cyphermox> crap :/
[21:26] <cyphermox> ^ epoch is very bad, shouldn't have been in that debdiff
[21:26] <cyphermox> bad ballons ;)
[21:26]  * tsimonq2 gives balloons the epoch hat
[21:26] <stgraber> done
[21:26]  * balloons feels ashamed
[21:27] -queuebot:#ubuntu-release- Unapproved: rejected juju-core [source] (yakkety-proposed) [1:2.0.0-0ubuntu1.16.10.2]
[21:27] <cyphermox> stgraber: ta
[21:27] <tsimonq2> balloons: Don't worry, you don't have to wear it as long as the Ducky Tie. :P
[21:28] <stgraber> balloons: we'll find you a corner to sit in next week :)
[21:28] <cyphermox> balloons: there was another subtle issue too, see if you can spot it ;)
[21:28] <balloons> yea. I wonder how many minutes (days?!) I'll have to do that
[21:28] <tsimonq2> stgraber: You guys going to a sprint next week? Make him an actual physical epoch hat. XD
[21:29] <tsimonq2> heheheheheheheheh ;)
[21:29] <stgraber> yeah, bunch of us sprinting in Budapest next week :)
[21:29] <cyphermox> balloons: that would be scary, if there were seconds involved.
[21:29] <tsimonq2> stgraber: Oh nice! :D
[21:29] <stgraber> cyphermox: already in Santa Fe I take it?
[21:29] <stgraber> cyphermox: I'm on a plane to Denver here
[21:30] <cyphermox> yes, already there, about to leave for dinner
[21:30] <stgraber> isn't 3pm a bit early for dinner? :)
[21:30] <balloons> he's stuck fixing my epochs
[21:30] <cyphermox> (basically, as soon as I'm done with this, then I'll be back after)
[21:30] <tsimonq2> balloons: XD
[21:30] <cyphermox> 3pm US dinner.
[21:31] <cyphermox> wait wat
[21:31] -queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0.0-0ubuntu0.16.10.1 => 2.0.0-0ubuntu0.16.10.2] (ubuntu-server)
[21:31] <cyphermox> annoying clocks.
[21:31] <tsimonq2> I'm handing out halloween candy, so I can munch on that. :P
[21:34] <cyphermox> stgraber: feels like it's way beyond 3pm here, and even way past 5pm cyphermox-standard-time. perhaps I've been up for too long.
[21:36] <stgraber> that's why I booked late flights, get to sleep in before leaving and not see the timezone change :)
[21:36] <stgraber> though that's just 2 hours west, the 9 hours east I'll have next weekend will be a bit harder to deal with I suspect ;)
[21:36] <cyphermox> pfft
[23:53] -queuebot:#ubuntu-release- New binary: libcgicc [amd64] (zesty-proposed/universe) [3.2.16-0.1] (no packageset)
[23:53] -queuebot:#ubuntu-release- New binary: libcgicc [ppc64el] (zesty-proposed/universe) [3.2.16-0.1] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: libcgicc [arm64] (zesty-proposed/universe) [3.2.16-0.1] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: libcgicc [i386] (zesty-proposed/universe) [3.2.16-0.1] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: libcgicc [armhf] (zesty-proposed/universe) [3.2.16-0.1] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: libcgicc [s390x] (zesty-proposed/universe) [3.2.16-0.1] (no packageset)
[23:54] -queuebot:#ubuntu-release- New binary: libcgicc [powerpc] (zesty-proposed/universe) [3.2.16-0.1] (no packageset)