[01:01] <kulyzu> $ cat -         # what does it mean
[04:41] <Mirv> mterry: yes, moved tp qttools
[05:41] <pitti> Good morning
[05:52] <pitti> infinity, doko: hmm, seems the rebuilds of apitrace & friends didn't help, still on update_output.txt?
[06:11] <pitti> installing them does work in a -proposed schroot, so not sure what britney complains about
[06:23] <pitti> doko: python3-talloc{,-dev} is NBS, and python3-ldb has no reverse dependencies; would it be ok to drop the p3-ldb packages again?
[06:51] <infinity> pitti: Erm, "didn't help" how?
[06:51] <pitti> infinity: glibc is still held back by these exact packages in output.txt
[06:51] <infinity> pitti: I told you yesterday that glibc is caught up in the Qt/binutils mess, I'm fixing the kernel to push that through.
[06:52] <infinity> pitti: You're reading the wrong block.
[06:52] <pitti> I looked at "trying: glibc"
[06:52] <infinity> pitti: Yeah, look further. :)
[06:52] <pitti> oh, in 'Trying easy from autohinter'?
[06:52] <infinity> pitti: It gets autohinted with apitrace, etc.  And Qt.  And binutils.  And a bazillion other things.  And linux-tools is the only thing holding it back.
[06:53] <infinity> Which I'm fixing.
[06:53] <pitti> ah, ok; sorry about that then
[06:53] <pitti> there seem to be about five people in the world who can correctly deciver output.txt, and apparently I'm not yet one of them :)
[06:53] <infinity> Turns out that specifying the default compiler for the *entire* kernel source tree (including tools) is a total cluster*^#%, so it's taken a bit longer than expected to fix a thing here. ;)
[06:54] <infinity> I think I have it, though.
[06:54] <infinity> Just one more test.
[06:54] <infinity> Then an upload.
[06:54] <infinity> Then profit.
[06:54] <pitti> indeed; building against a newer linux-libc-dev is fair enough, but that oughtn't result in changed binary deps?
[06:54] <infinity> Then maybe some upstream fixes. >:(
[06:55] <infinity> pitti: No, no.  perf depends on binutils for libbfd.  That's not what I'm "fixing".
[06:55] <infinity> What I'm fixing is making linux-4.4 buildable in yakkety, so I can delete 4.6, insert a 4.4 rebuilt against binutils 2.27, migrate the mess, then copy 4.6 back into proposed.
[06:56] <infinity> Because we can't migrate 4.6, as hard as I tried, due to it being unbootable on arm64.
[06:56] <infinity> Grr.
[06:57] <infinity> And, it turns out, that while you'd think that setting "CC=gcc-5" would do a useful thing (and it mostly does), it completely breaks a few makefiles.
[06:57] <infinity> Which I see upstream patches for in my future.
[06:57] <infinity> Because eff that.
[06:59] <infinity> And that concludes today's lecture on why Adam hates all upstreams.
[06:59]  * pitti knocks on the bench
[09:35] <Odd_Bloke> semiosis: o/ Do you have time to work on https://bugs.launchpad.net/cloud-images/+bug/1605795?  (Specifically, we need to generate a debdiff for the changes needed to xenial and attach it to the bug. :)
[10:38] <infinity> Odd_Bloke: Ahh, crap, I was going to do some backporting of all of that.
[10:38] <infinity> Odd_Bloke: We really should pull more fixes to xenial than just that one.
[10:39] <Odd_Bloke> infinity: Aha, so there _was_ a reason I thought I could get gaughen to bug slangasek about that bug. :p
[11:10] <tseliot> pitti: hey, can you push your last changes to u-d-c, please? I still see the package as unreleased in git
[11:10]  * tseliot -> lunch
[11:11] <pitti> tseliot: whoops, sorry; done
[11:17] <kdub> pitti, have some automated tests that have been running for quite a long time here https://requests.ci-train.ubuntu.com/static/britney/ticket-1654/landing-036-xenial/excuses.html, but they arent listed as running on http://autopkgtest.ubuntu.com/running.shtml, any ideas?
[12:01] <pitti> kdub: kicked those
[12:02] <kdub> thanks pitti
[12:49] <tseliot> pitti: thanks!
[13:00] <coreycb> bdmurray, I've verified bug 1516471
[13:07] <kdub> pitti, do you think it would worthwhile to re-kick the yakkety builds? they seem to have that 'testbed out of date' problem. (last time that happened, I had to just forward the silo to QA testing)
[13:07] <kdub> https://requests.ci-train.ubuntu.com/static/britney/ticket-1654/landing-036-yakkety/excuses.html
[13:08] <kdub> the xenial tests passed after the re-kicking there
[13:24] <pitti> kdub: they are uninstallable; presumably they need to run against all of -proposed, there's a horrible amount of stuff stuck in -proposed right now
[13:24] <pitti> kdub: done
[13:25] <kdub> pitti, yeah, chatted with jibel and got it bumped to the qa queue, so hopefully in the clear
[13:25] <kdub> thanks again for the help
[13:46]  * xnox 's head is spinning with not declared in this scope, only a friend here </3 c++
[14:03] <pitti> mdeslaur: last week during my holidays there were two postgresql CVEs; are these already in the pipeline, or need me to prep updates?
[14:05] <mdeslaur> pitti: oh! didn't notice...could you prepare them?
[14:05] <pitti> mdeslaur: ack
[14:06] <mdeslaur> pitti: thanks! :)
[14:08] <pitti> mdeslaur: I'm creating tracking bug 1614113 (still need to clean up tasks)
[15:02] <flexiondotorg> Laney, I need to submit a few MATE package for rebuilds for GTK 3.20.
[15:03] <flexiondotorg> Some MATE packages have build time rules for 3.20 and all MATE packages in the archive were built against 3.18.
[15:03] <flexiondotorg> What is the correct version suffix for a rebuild, with no other changes?
[15:03] <jbicha> flexiondotorg: run dch -R
[15:03] <flexiondotorg> jbicha, ty
[15:09] <infinity> flexiondotorg: (The rule is "append buildN starting at N=1 for versions without an ubuntuN suffix, else increment ubuntu suffix, but as jbicha points out, dch -R gets it right)
[15:10] <flexiondotorg> infinity, Thanks. Understood. Rebuilds uploading.
[15:17] <pitti> mdeslaur: all done
[15:18] <mdeslaur> thanks pitti! much appreciated
[15:18] <infinity> pitti: Okay, kernel mess finally on its way into proposed.  Hopefully the perfect transition state isn't perturbed in the next hour or so. :P
[15:18] <pitti> ok, everybody hands off the archive!
[15:18] <pitti> infinity: thanks muchly!
[15:18] <infinity> pitti: I'm going to check enough autopkgtests to make sure a reboot smoketest is fine, and then let it in, based on the lack of code changes.
[15:19] <pitti> infinity: agreed, was just going to propose that
[15:19] <pitti> infinity: I would then flush the glibc requests from the queues after a few dozen tests
[15:19] <infinity> s/glibc/linux-meta/ ?
[15:20] <pitti> infinity: oh, I thought glibc; there  aren't that many linux tests
[15:20] <infinity> Nope.
[15:20] <infinity> THough its own self test takes forever, and I won't be waiting on that.
[15:20] <pitti> the three expensive ones are glibc, binutils, and linux itself; the dkms ones are laughable
[15:20] <infinity> Just going to look at some of the fast ones and make sure they indeed install and reboot into the new kernel.
[15:20] <pitti> infinity: shouldn't take *that* long really -- linux doesn't rebuild itself for testing itself
[15:21] <infinity> The qrt suite takes ages.
[15:21] <pitti> but then again linux' tests have been broken for months, so they'll fail anyway
[15:21] <pitti> I wish they would get fixed at some point -- not learning about kernel regressions although we could is a bit of a bummer
[15:21] <infinity> They get examined by hand on a more granular level.
[15:21] <pitti> anyway, nothing for me to steer manually for linux
[15:22] <infinity> But a green baseline would make that waste of time unnecessary.
[15:22] <infinity> And everyone knows it.
[15:33] <semiosis> Odd_Bloke: yes i'll work on it today
[15:34] <Odd_Bloke> semiosis: infinity said he might also look at it, so check with him.
[15:34] <semiosis> Odd_Bloke: to be clear, the goal is to take the xenial branch of livecd-rootfs, apply the needed changes, then generate a diff (debdiff) to attach to bug 1605795
[15:36] <semiosis> Odd_Bloke: infinity: let me know how I can help.  i'll hold off until you confirm if you need anything from me.
[16:42]  * xnox qpid-receive.cpp:135:27: error: no match for 'operator<<' (operand types are 'std::ostream {aka std::basic_ostream<char>}' and 'std::ostringstream {aka std::__cxx11::basic_ostringstream<char>}')
[16:44] <nacc_> rbasak: around? not urgent
[16:51] <gaughen> semiosis, I wouldn't hold off. I'd do the backport and get it already for SRU. I don't want to block on infinity as he's a busy guy and I'd like to get the change sin.
[16:52] <mterry> bdmurray: i just filed https://code.launchpad.net/~mterry/ubuntu-archive-tools/phablet-teams/+merge/303163 based on recent MIR feedback from teams
[16:52] <gaughen> semiosis, so have at it!
[17:00] <nacc> arges: if not all the upstream bits (re: LP: #1490611) apply to the 16.04 source, is it sufficient to just note that? That's why there is a difference in the qem2 changes backported.
[17:01] <arges> nacc: ok good to know. Yea that's useful info to put into the patch description
[17:01] <nacc> arges: ack, updating now, thanks for noticing that!
[17:01] <arges> so the next person who looks at this and wonders why it doesn't match the upstream commit can see why
[17:24] <nacc> barry: thanks for the wiki updates!
[17:25] <nacc> barry: fyi, i did see one i wanted to ask about -- the -d option should work with an appropriate directory (i use it to pick up a failed import, e.g., and to continue after fixing the importer). I think I should add some defensive checks that the specified directory is of the format I expect (or empty).
[17:25] <barry> nacc: hey! hi!  yw.  i was going to ping you to discuss a few other things i ran into, but i saved it in an ephemeral file and lost my notes ;)
[17:26] <barry> nacc: yes, i think that would help.  relative paths should also be allowed i think (unless there are specific technical reasons why it can't)
[17:26] <nacc> barry: yep, probably just oversite on my part, or using the wrong API
[17:26] <nacc> err, oversight
[17:27] <nacc> barry: could you file a bug for that? https://bugs.launchpad.net/usd-importer
[17:28] <barry> nacc: the other thing is that the job of deconstructing and reconstructing the patches is rather complex and does involve some esoteric git knowledge.  that's okay, since the tool does assume up front that you know a fair bit about git, but i also feel like for drive-by mergers, the steps involved won't be committed to muscle memory.  that means (maybe) a quick cheat sheet would be helpful in addition to the detailed docs on the wiki
[17:28] <barry> page
[17:28] <barry> nacc: +1
[17:29] <nacc> barry: yep, that is on my todo
[17:30] <barry> nacc: but overall, it made my merge of claws-mail much nicer than mom (which i've used every time before now).  otoh, claws-mail only has a fairly simple delta over debian.  still, win!  thanks for all the great work on this tool
[17:31] <barry> nacc: LP: #1614189
[17:33] <nacc> barry: thanks!
[17:50] <rbasak> nacc: o/
[17:50] <rbasak> nacc: also, I started importing claws-mail for barry
[17:51] <barry> rbasak: thanks!
[18:13] <nacc> rbasak: heya, just wanted to touch base with you re: https://answers.launchpad.net/launchpad/+question/326278
[18:14] <nacc> rbasak: basically, it seems like we shouldn't rely on a version only being published once in a given series (meaning we need to be able to distinguish by more than series/pocket/version :/
[18:15] <nacc> rbasak: also, i think i mentioned this to you briefly before i was on vac, but i think we want to remove the hardstop in the importer on versions going backward and just trust the publication history? basically http://paste.ubuntu.com/23065299/
[18:19] <rbasak> nacc: the tree should still be identical though, right?
[18:19] <nacc> rbasak: the tree is identical, but it's history is not
[18:19] <nacc> rbasak: the publishing history, that is
[18:23] <rbasak> nacc: if, in the case of this happening, we make an empty commit with the correct tree, would that cause problems?
[18:23] <nacc> rbasak: well, the tricky part right now is detecting that it is happening :)
[18:26] <rbasak> nacc: isn't it the same case that (import|upload)/<version> exists?
[18:26] <nacc> rbasak: do you have time for a hangout? sorry, i know it's late there
[18:29] <rbasak> Let me check.
[18:29] <nacc> rbasak: sorry, just hard to type fast enough to explain what i ran into :)
[18:29] <nacc> rbasak: we can also chat tmrw AM
[18:30] <rbasak> nacc: dinner will be ready in five minutes. Maybe afterwards?
[18:30] <rbasak> I'll ping you.
[18:31] <nacc> rbasak: sure, like i said, we can also talk tomorrow, don't want to interfere with your evening
[18:31] <rbasak> After Denver my body hasn't yet understood what evening means again :-)
[18:32] <nacc> rbasak: ah i can only imagine :)
[22:12] <tgm4883> Can someone take a look at this? https://bugs.launchpad.net/ubuntu/+source/mythbuntu-default-settings/+bug/1613122 I've got a package in proposed waiting on this and not sure what happens with packages in proposed after feature freeze
[22:13] <jbicha> tgm4883: don't worry, if it's in -proposed, it's considered "in" before feature freeze
[22:13] <tgm4883> jbicha: ah cool. Thanks