[00:06] <jbicha> I use requestsync for merges too, I just change the subject and the description fields to match what I'm trying to do
[00:06] <jbicha> you can do that before you submit or after
[00:07] <jbicha> I'm really happy you're fixing that for xenial :)
[05:41] <cpaelzer> good morning
[05:57] <cking> pitti, can you help me out on bug 1579036, i've verified the SRU for xenial and it's been stuck in -proposed for a while
[06:08] <chiluk> hey debfx, do you know what's going on with the ubuntu quassel package?  I was looking at doing the merge for it, and the debian/control file points at Vcs-Bzr: lp:~ubuntu-dev/quassel/ubuntu and Vcs-Browser: http://bazaar.launchpad.net/~ubuntu-dev/quassel/ubuntu which both seem out of date.  Should I just ignore those referenced projects and update the control file to point elsewhere?
[06:41] <ginggs> chiluk: from what i can tell, quassel is maintained independently in ubuntu
[06:41] <ginggs> in https://launchpad.net/ubuntu/+source/quassel/+publishinghistory all the versions are -0ubuntu
[06:45] <chiluk> ginggs: they all seem to be merges with debian sources, but the above mentioned project seems to be out of date, but it still is being mentioned in the most recent control file.
[06:49] <debfx> chiluk: yep you can ignore that. ScottK and I are maintaining quassel in Debian now.
[06:49] <ginggs> chiluk: i don't think pointinf the Vcs-* fields at the Debian Vcs would be correct.  It is also strange to me that the Debian version got an epoch bump, but the Ubuntu version never did.
[06:49] <chiluk> ok.. debfx.. would you like me to attempt a merge from debian back into ubuntu?
[06:50] <ginggs> chiluk, debfx: it would be great if we could sync up with Debian at come point
[06:52] <debfx> I think you can mostly the sync the package. there might be some transitioning stuff needed.
[07:14] <doko> mdeslaur, http://bugs.python.org/issue26867 is there a way to query the enabled protocols?
[07:15] <mdeslaur> doko: not that I know of, unfortunately
[07:16] <mdeslaur> doko: let me think if there's a better patch for that, and I'll get back to you
[07:34] <pitti> cking: sure, looks nice and green; released
[07:34] <cking> pitti, many thanks!
[07:56] <pitti> infinity: if you want to fix reportbug locally for you, just apply this inline: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=fd907eea
[07:59] <infinity> pitti: Ta.
[08:10] <slangasek> nacc: bootstrap done
[08:13] <pitti> cking: argh -- one of the two instances now failed with http://paste.ubuntu.com/17319931/
[08:13] <pitti> cking: at least that now seems to be something entirely different
[08:15] <cking> pitti, aren't those alignment faults caused by a bad userspace program that the kernel is handling?
[08:19] <pitti> cking: yeah, that's what it looks like; but ssh stopped responding, so I guess some test did something bad to the host
[08:20] <pitti> cking: anyway, no stuck processes so far
[08:25] <cking> pitti, so the aarch32 BKPT error occurs during ptracing of a 32 bit executable, so it maybe that the child died, perhaps the parent tracer gets hung by that
[08:27] <pitti> tdaitx: https://bugs.launchpad.net/auto-package-testing/+bug/1550280
[08:40] <pitti> infinity: bug 1510344
[09:22] <chiluk> debfx, quassel can not be directly synced because of name changes in the  d/control file.
[09:41] <_morphis> stgraber: ping
[10:27] <barry> nacc: ping
[10:31] <mwhudson> pitti: for some reason i just had the idea of writing a charm for britney
[10:31] <mwhudson> pitti: must be time for bed
[10:31] <pitti> mwhudson: much appreciated :)
[10:32] <pitti> mwhudson: this is actually on the sprint agenda for discussion :)
[10:32] <mwhudson> pitti: haha
[10:32] <mwhudson> i am there in spirit if not in body
[10:39] <juliank> infinity: mvo: Time to do "syncpackage -d experimental -V 1.3~exp2 -b 1592171  -s juliank apt" for bug 1592171, and "syncpackage -r xenial -V 1.2.13 -s juliank apt" for SRU bug 1573547 ? (Not sure if the commands are entirely sane; -V ... is probably not needed, but probably does not hurt) - More APT for everyone!
[10:39]  * juliank is learning syncpackage commands
[10:43] <Unit193> juliank: FWIW, ~ubuntu16.04.1 would be appended.
[10:43] <juliank> Unit193: No need to, 1.2 is the xenial line
[10:44] <juliank> Unit193: (that's what infinity basically wrote)
[10:45] <Unit193> !info apt xenial
[10:45] <juliank> Unit193: Yeah, 1.2.12 was a different case. It autosynced to yakkety by accident...
[10:45] <juliank> yakkety now has 1.3
[10:45] <Unit193> Aha, niiice.  And yeah, noticed that bit.
[10:47] <rbasak> juliank: there won't be a bug reference to follow in the changelog to get to the SRU bug though.
[10:47] <juliank> rbasak: There is a (LP: #1573547) in the changelog
[10:48] <rbasak> juliank: oh, great :)
[10:48] <Unit193> Indeed, pretty fancy.
[10:51] <juliank> I'm considering going with the same APT release series for (maybe) 16.10, 17.04, (maybe) 17.10 as I do for the Debian stable release (Deb freeze is in Jan, probably lasts long enough for 17.10) Then all could be pseudo-synced to the same version.
[10:52] <juliank> On the other hand, it might make sense to let experimental APT versions flow into 17.10 in preparation for 18.04.
[10:53] <Unit193> Oh, I meant to ask last time, do you have a vcs for command-n-f?  (Timed out on OFTC for now or I'd ask there.)
[10:53] <juliank> Unit193: Not really anymore :/
[10:54] <juliank> the newer ubuntu one has one somewhere though, I hope
[10:55] <juliank> Long term, I'd like to merge
[11:44] <seb128> Trevinho, bah, infinity copied the u-s-d SRU over to yakkety, unsure if that means you need to rebase your silo or if we just land that anything like the copy hadn't be done
[11:44] <Trevinho> seb128: ah...
[11:45] <Trevinho> seb128: in general in these cases I'd just pull that revision into trunk
[11:45] <Trevinho> seb128: since it's already in distro
[11:45] <Trevinho> seb128: I can do that and redo a rebuild
[11:45] <seb128> your call
[11:46] <seb128> I would just discard it if it was me
[11:46] <Trevinho> seb128: have you approved all the branches involved? Since one wasn't
[11:46] <seb128> Trevinho, which one?
[11:46] <Trevinho> seb128: is that just a changelog?
[11:46] <Trevinho> entry I mean
[11:46] <seb128> no, it's the xenial SRU
[11:46] <seb128> so the keyboard backlog fix for boot
[11:46] <Trevinho> seb128: https://code.launchpad.net/~3v1n0/unity-settings-daemon/keep-cached-kbd-backlight-updated/+merge/294662
[11:46] <seb128> the > changed to >=
[11:47] <seb128> ah
[11:47] <seb128> I was hoping somebody else would test that one since I don't have the hardware
[11:47] <seb128> I guess I can do a code review at least
[11:47] <pitti> cyphermox: https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-network-yaml
[11:55] <Trevinho> seb128: however, in a second though, well I'd just overwrite the landing in yakkety... Since the change is already in the silo anyway
[11:55] <seb128> Trevinho, wfm!
[11:56] <Trevinho> seb128: so once that review is done I think you can just hit the publish with the IGNORE_VERSIONDESTINATION flag
[11:56] <seb128> right
[11:56] <seb128> thanks for confirming
[12:17] <coreycb> arges, hi, we have some openstack SRU's in the review queue if you have some time to review.  I'm particularly looking to get the xenial ones moving along.
[12:34] <funman> hello
[12:35] <funman> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc3-yakkety/BUILD.LOG (warning: 13MB) shows package is built with do_tools=0, thus no linux-tools deb being built. Why not?
[12:43] <funman> ah moving to #ubuntu-kernel
[12:55] <rbasak> cyphermox: are you making any progress on bug 1585771?
[13:00] <cyphermox> rbasak: I had not; looking at it now
[13:01] <cyphermox> (if teh source ever downloads)
[13:02] <arges> coreycb: ok looking
[13:02] <arges> coreycb: i'll look at xenial today, and others tomorrow since it is my sru day
[13:02] <arges> sprinting atm
[13:02] <coreycb> arges, no problem, thanks
[13:13] <rbasak> cyphermox: thanks! I was going to assign it to someone on the server team but you grabbed the assignment first.
[13:17] <cyphermox> rbasak: well, if you want to take care of it, by all means
[13:24] <arges> coreycb: did you upload horizon?
[13:24] <arges> or keystone
[13:25] <coreycb> arges, hmm to xenial?
[13:25] <arges> coreycb: yes
[13:25] <arges> bug 1591248
[13:26] <coreycb> arges, looking
[14:00] <arges> coreycb: ok i'm leaving soon so i'll get ot the rest tomorrow
[14:01] <coreycb> arges, ok.  horizon is uploaded and I dropped keystone  from that bug since it's not finished.  thanks!
[14:35] <cyphermox> rbasak: I'm looking at it (for realz now), this is more complicated than expected
[14:36] <barry> nacc: ping
[14:37] <sarnold> It's 7:37 back in portland, it might still be a while :)
[14:49] <pfsmorigo> Is debian-install that creates /etc/default/grub file?
[14:56] <doko> tumbleweed, my test rebuilds for the pypy SRU were successful: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[14:56] <tumbleweed> doko: \o/
[14:58] <barry> sarnold: yeah.  i was hoping he might be an early riser ;)
[14:59] <sarnold> .. or perhaps late sleeper? :) heh
[14:59] <barry> or maybe his alarm would start screaming when i pinged his nick
[15:01] <tumbleweed> doko: want to copy it into -proposed then? (can you from that PPA?)
[15:01] <tumbleweed> doko: also, are the rebuilds required? I assume not
[15:04] <doko> tumbleweed, well, build-deps for some main packages, so I thought I would better check
[15:05] <tumbleweed> oh, absolutely
[15:05] <tumbleweed> I just meant, we don't have to do in-archive builds
[15:05] <doko> now in the queue
[15:05] <infinity> pfsmorigo: It's copied into place by the grub2 postinst, and potentially altered by grub-installer during install.
[15:19] <nacc> slangasek: thank you!
[15:22] <nacc> slangasek: how does this work with excuses? phpunit is still stuck because phpunit-mock-object and php-codecoverage are both regressing phpunit's older version (which is expected); and they do pass with the new version. Basically, they all need to be considered together, I think?
[15:25] <barry> nacc: https://github.com/gitpython-developers/GitPython/issues/470 - i am working on a fix.  we can probably talk about it in a few hours
[15:25] <barry> nacc: i will probably also have a few changes for usd-import
[15:25] <nacc> barry: ah nice!
[15:26] <nacc> barry: sure, thanks, much appreciated :)
[15:26] <barry> nacc: since you're here and i have a few minutes...
[15:28] <nacc> barry: yep, i'm around now :)
[15:29] <barry> nacc: so i was looking for some packages to test this on, and saw a merge request for sbuild on the patch pilot page.  i started to import it and hit a crash.  after *much* debugging, turns out that some sbuild changelog entry has non-utf8 characters in it, and python3-git tries to decode the bytes with utf-8 in strict mode, and that crashes.  they have a safe_decode() method which does an `errors='replace'` so that seems appropriate to
[15:29] <barry> wrap around the stdout/stderr bytes it gets back from the `git show-file` subproc call.  if our network wasn't so horrible i would have tested this hours ago, but now i'm running another import to see if that works.  doesn't help that the dpmt git-dpm branch for python-git is hosed.  i may just upload a fix to ubuntu until that gets unwedged
[15:31] <nacc> barry: make sense ... yeah, it seems ... odd that there is a stray character there. I guess the committer didn't use the right UTF character and it got mis-translated by some tooling to <F6> ?
[15:31] <barry> nacc: yep
[15:31] <barry> nacc: so yeah, a bug in the changelog, but a pretty much permanent one :)
[15:31] <nacc> yeah, we probably need better error-handling there too, then
[15:32] <barry> nacc: so one of the changes i will propose is to log the exception in usd-import instead of swallowing it ;)
[15:33] <nacc> barry: yep, perfectly fine by me :)
[15:33] <barry> nacc: coolio
[15:33] <nacc> barry: i will admit to not being the most experienced python developer -- patches are definitely welcome!
[15:34] <barry> nacc: +1
[15:38] <cjwatson> barry: Hm, really?  The current changelog in sbuild.git debian/unstable is entirely UTF-8.
[15:38] <cjwatson> barry: As is the current one in the Ubuntu archive.
[15:38] <barry> cjwatson: it was in an older published ubuntu changelog, but i don't remember the version number right now
[15:39] <barry> cjwatson: maybe nacc can see it as he correctly identified the <F6>
[15:39] <nacc> per the gh bug report, seems to be 0.24
[15:39] <cjwatson> Oh, so full-history importing
[15:39] <nacc> cjwatson: yep
[15:40] <nacc> find all sorts of corner cases that way :)
[15:40] <cjwatson> Yeah, fixed in 6756b2a6 but you gotta cope with this.
[15:41] <barry> nacc, cjwatson anyway, ttyl
[15:42] <nacc> barry: np, thanks for the info!
[15:42] <rbasak> May I have a review of https://github.com/ltangvald/mysql-5.7/commit/fa6ea034692 from an experienced dev please? The mechanics are simple but I want to make sure the approach is correct (seddery of conffile)
[15:46] <stgraber> _morphis: hey
[15:46] <nacc> cjwatson: before i file an unnecessary update to LP: #1592139; can you help me understand how the bootstrapped packages "should" interact with excuses? these three binary packages can only proceed together, and they all work in -proposed. But necessarily, the phpunit-mock-object and php-codecoverage packages break the version of phpunit in release.
[15:47] <cjwatson> nacc: Break in what sense?
[15:50] <nacc> cjwatson: the unit tests fail, but I believe it's variously because the formatting of the output has changed with the newer dependency packages from -proposed, or there are functional changes. Those same unit tests in the newer version of phpunit pass.
[15:51] <nacc> cjwatson: actually, the excuses output is a bit confusing
[15:51] <cjwatson> nacc: Probably just wants the autopkgtests rerun with the newer phpunit in this case, I think, but get pitti to have a look.
[15:51] <nacc> for non-amd64/armhf, it's passing with teh newer version of phpunit, but for those two, it's failing for the older version
[15:51] <nacc> ack, that does seem to be all, thanks!
[15:52] <nacc> pitti: :) if you could help out, i'd appreciate it. Trying to get the set of phpunit, phpunit-mock-object and php-codecoverage through. I think phpunit-mock-object and php-codecoverage's autopkgtests need to get rerun with the newer phpunit wehre it's failing for the older phpunit
[16:31] <nacc> Logan: fyi, phpunit/phpunit-mock-object/php-codecoverage should get into release shortly, which should unblock some stuff :)
[16:49] <popey> bdrung: hello! I've just been bitten by bug 1581807 (which you have a fix for). Do you need help with it? I'd love to see that land so I can build Audacity.
[17:26] <nacc> Logan: (or anyone else), now that phpunit is installable in yakkety and is up-to-date, do the various tests/builds that failed due to deps need to be manually restarted? they aren't in dep-wait, they simply failed to build (because phpunit wasn't installable)
[17:26] <nacc> e.g., https://launchpad.net/ubuntu/+source/php-react-promise/2.4.1-1 but there are many others
[17:38] <cjwatson> nacc: If LP doesn't say "Dependency wait" for them on the +build page, they will have to be manually retried.
[17:39] <cjwatson> nacc: I've retried.  If you can get a list of package names then I can do them in bulk.
[17:39] <cjwatson> nacc: *retried php-react-promise
[17:39] <nacc> cjwatson: ack, i'll start collating that list now
[17:58] <nacc> rbasak: sorry to pester, did you get a chance to review the php-imagick merge?
[18:10] <nacc> cjwatson: http://paste.ubuntu.com/17334290/
[18:11] <nacc> cjwatson: those are all the ones i found that failed to build due to phpunit alone; i'm looking through the rest of the php packages in excuses as well
[18:17] <cjwatson> nacc: php-constant-time was already built, just in NEW; I've retried the rest
[18:17] <nacc> cjwatson: ah sorry, thanks!
[18:17] <cjwatson> (an older version of php-constant-time did fail and may still have been in excuses)
[18:18] <nacc> cjwatson: yeah, i think that must have been what i saw
[18:42] <rbasak> nacc: sorry, not yet. I was trying to make progress on MySQL today. I'll take a look at outstanding sponsoring tomorrow.
[20:09] <nacc> rbasak: thanks!
[20:44] <Logan> nacc: you're awesome!
[21:13] <nacc> Logan: thanks for the pokes on it, sorry it took so long to get resolved
[21:29] <nacc> cjwatson: did php-sabre-vobject get retried? lp says the failed build is still from 5/23?
[21:29] <nacc> oh! my fault  -- php-sabre-vobject-3
[21:29] <nacc> sorry!
[21:45] <nacc> hrm, attempting `requestsync -n php-symfony-security-core`, but it reports that it doesn't exist in the primary archive of sid; however rmadison says it is in unstable?
[21:51] <jbicha> nacc: try requestsync symfony
[21:51] <jbicha> it uses the source package name, and I don't think you want -n
[21:52] <nacc> jbicha: ah sorry
[21:52] <nacc> jbicha: you're right!
[21:52] <nacc> i just glossed the source package name
[21:52] <nacc> ok, will go look at the merge :)
[21:53] <nacc> jbicha: thanks for the hint!
[22:05] <slangasek> nacc: phpunit, yes, I saw the autopkgtest results earlier and reschedulded tests with all three packages
[22:05] <slangasek> nacc: so I believe those have all migrated now
[22:06] <nacc> slangasek: yep, thanks!
[22:06] <nacc> slangasek: if you have a moment, could you manually retrigger the build of php-sabre-vobject-3? i typo'd my request to cjwatson earlier
[22:07] <slangasek> nacc: done
[22:07] <nacc> slangasek: thanks!
[22:12] <nacc> slangasek: down from ~430 mentions of php on excuses to ~300 :)
[22:41]  * mwhudson DOSes the launchpad builders with go 1.6.2 rebuilds
[22:45] <cjwatson> mwhudson: that's ok, they aren't going to notice in the middle of the test rebuilds
[22:45] <mwhudson> cjwatson: heh
[22:46] <mwhudson> cjwatson: i was wondering, do you have any handwavy idea of how many builds are done a day?
[22:46] <cjwatson> mwhudson: total across all arches?
[22:46] <mwhudson> yeah
[22:46] <mwhudson> a few thousand?
[22:47] <cjwatson> /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-20160610.gz:8186
[22:47] <cjwatson> /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-20160611.gz:6754
[22:47] <cjwatson> /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-20160612.gz:6617
[22:47] <cjwatson> /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-20160613.gz:4439
[22:47] <cjwatson> cjwatson@carob:~$ zgrep --count 'Dispatching job' /srv/launchpad.net-logs/production/alphecca/buildd-manager.log-201606{10,11,12,13}.gz
[22:47] <cjwatson> sorry for order
[22:47] <mwhudson> heh
[22:47] <mwhudson> so my extra 900 is an extra ~10%
[22:48] <cjwatson> the numbers above are without a test rebuild running though, and those started today
[22:52] <mwhudson> heh i see build ten million must have been pretty recently
[22:52] <cjwatson> oh yeah, I totally didn't notice that
[22:54] <cjwatson> not actually run yet, so probably part of the test rebuilds
[22:54] <cjwatson> https://launchpad.net/ubuntu/+archive/test-rebuild-20160614/+build/10000000 has the honour
[22:56] <mwhudson> earth shattering
[23:58] <nacc> so i think i fixed one of the puppet autopkgtest issues (LP: #1570472)
[23:58] <nacc> but the other one (puppet-module-puppetlabs-ntp)
[23:58] <nacc> if i have adt-run drop to a shell on failure, the script in question (run-tests) runs both tests succesfully
[23:59] <nacc> it's also failing in debian, fwiw, at the same point (introducing puppet 4.5.0)