[01:47] <doko> slangasek, copied everything to 39, still building. will look at the ftbfs tomorrow. 16 should be obsolete
[09:15] <sil2100> Hello release team! We need an archive admin to preNEW review a new package before publishing it through the train
[09:32] <doko> sil2100, what is this? sounds scary before we copy the gcc5 silo
[09:33] <michi> doko: It’s code that is in thumbnailer at the moment. We are unbundling it so it becomes reusable.
[09:34] <michi> Nothing depends on it right now.
[09:34] <sil2100> https://code.launchpad.net/~unity-api-team/persistent-cache-cpp/devel <- here is the whole packaging + code
[09:35] <michi> sil2100: It’s been reviewed and passed already.
[09:35] <michi> Check the comments in the “Passed” column for silo 51 here: https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng
[09:35] <doko> michi: but you don't plan to update thumbnauler now?
[09:35] <michi> doko: Correct.
[09:35] <doko> looking
[09:36] <michi> We are leaving thumbnailer alone until the dust settles
[09:36] <michi> sil2100: You need to click on the silly speech bubble to see the comments.
[09:36] <doko> hmm, it's not in the NEW queue ... https://launchpad.net/ubuntu/wily/+queue?queue_state=0
[09:37] <sil2100> It's not NEWed yet, we're required to get a preNEW review before pushing it
[09:37] <sil2100> I can publish that to the NEW queue tho if you prefer
[09:37] <doko> ahh, sorry, can't help with this
[09:43] <michi> sil2100: It’s not important for this to go in doko’s PPA. I just want to get the package accept so we (and others) can eventually start using it.
[12:47] <doko> jibel, did slangasek talk to you yesterday?
[12:52] <jibel> doko, he didn't
[12:54] <doko> jibel, he proposed that you could be able to do an image build using the landing39 ppa. not sure how fast you could do that
[12:55] <doko> does this make sense?
[12:56] <doko> otoh, it may fail, because we didn't yet rebuild anything for the renamed libraries
[13:23] <jibel> doko, what would be the difference between an image built from wily + ppa 39 and an image built from proposed on ppa 39 is copied?
[13:24] <jibel> once*
[13:27] <doko> jibel, wily + ppa39 definitely won't work at this point. I think he meant proposed + ppa39
[13:35] <jibel> doko, if everything is installable building from the PPA can be an option
[13:36] <doko> jibel, sure, that would be good to know
[13:39] <doko> jibel, assuming you would work on this, when could such a test be finished?
[13:42] <jibel> doko, for today it's a bit late notice. Time to build an image I won't have any tester left
[13:44] <doko> ok, then let's do it without it
[13:44] <doko> the copy
=== alex_abreu is now known as alex-abreu
=== superm1_ is now known as superm1
[16:53] <slangasek> doko, jibel: I did not propose doing an image build using the landing-039 ppa; I was only asking how long we expected it to take for all the packages to build.  The plan for getting a test image is to build against -proposed once the phone stack is coherent there, which is a daunting prospect in itself
[16:56] <jibel> slangasek, makes sense. That was my understanding of your discussion with doko yesterday.
[17:46] <jderose> infinity: totem is launching fine and dandy in today's 14.04.3 daily... thanks! :D
[17:48] <infinity> jderose: Good deal.
[17:49] <infinity> jderose: I'm not happy with my "fix", but it was the same hack we used for .2, and no one complained there either. :P
[17:49] <infinity> (Well, similar, not identical, or I would have noticed the bug)
[17:50] <jderose> infinity: guess adding one line to debian/control for the appropriate mesa package is too hard :P
[17:50] <jderose> for someone, not you, of course :)
[18:05] <infinity> jderose: Well, one first needs to figure out where "appropriate" is, then the investigation of WTF that's needed at all (it probably should be a conditional load, and it's a bit broken), then a full SRU verification to get it in.  And the guy responsible is on vacation. :P
[18:06] <infinity> jderose: So, a hack works for now.  If a later SRU fixes it better, no one will notice. :P
[18:47] <jderose> infinity: gotcha... and i'm just being a little ornery anyway :P
[20:06] <slangasek> so, if ofono-qt and maliit-framework have made their way into wily, does that mean they didn't actually need g++ rebuilds, or is something broken...
[20:11] <infinity>  Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libqt5core5a (>= 5.2.0), libqt5dbus5 (>= 5.0.2), libstdc++6 (>= 4.1.1)
[20:11] <infinity> So, unless something has broken shlibs or a broken symbols file, I'd say no rebuild was needed.
[20:14] <infinity> Given that qt5core didn't have a package name change, that would imply its rdeps don't need a rebuild...
[20:15] <infinity> Ditto for qt5dbus.
[20:15] <infinity> No idea if my inference is actually correct, mind you, but people seemed to be taking the rename thing seriously, so...
[20:18] <infinity> Of course, given that libstdc++6 deps seem to be (correctly) generated from symbol availability, rather than a hardcoded shlib, that also means the tracker "good" string was a bogus lie.
[20:18] <infinity> Since anything that didn't actually need a transition will be listed as "bad" no matter how many times you rebuild it.
[20:25] <infinity> slangasek: Any objections about me fasttracking that apt/trusty SRU (and releasing on a Friday, oh noes!) once I've re-run all my testcases against the archive build and confirmed it's not broken?
[20:25] <infinity> slangasek: It's the only SRU blocking me turning off -proposed in the trusty dailies, which I'd like to do to (a) unblock the kernel team, and (b) have the images over the weekend be a better representation of the final 14.04.3 builds.
[20:25] <slangasek> infinity: I'm afraid my brain misses context for the apt SRU
[20:26] <infinity> https://launchpad.net/ubuntu/+source/apt/1.0.1ubuntu2.9
[20:27] <slangasek> and 1429041 was the preivous SRU?
[20:27] <infinity> Yeah.
[20:27] <slangasek> (and is the test case from there part of the build-time testsuite?)
[20:27] <infinity> It's not.  I need to learn the apt testsuite and submit two tests upstream, for both these regressions.
[20:28] <infinity> But, for now, I have manual tests to confirm both.
[20:29] <infinity> Manual tests all passed on my test binary built at home, just need to re-run them on the archive build.
[20:29] <infinity> THough, if the results differ, we have much bigger problems. :P
[20:32] <slangasek> infinity: ok, looked at the patch and it's clearly limited to things that are Never-MarkAuto-Sections (which seems like a good thing to say in the Regression Potential bit?) so if you've tested that it does what you need for the point release I'm ok with fast-tracking
[20:33] <infinity> slangasek: Right, re-running tests now.  Well, reruning the 1429041 tests.  The actual bug I was fixing is v-done based on the kylin livefs not being completely busted anymore.
[20:33] <infinity> (They remove ubuntu-desktop as part of their build, which is what exposed the regression)
[21:00] <infinity> slangasek: Alright.  Bug spammed with much testing output.  It all looks good to me.  Want to double-check to see if I'm stupid before I release?
[21:01] <infinity> Next week, I'll have to fix this in wily, vivid, and I suspect also precise (haven't tested there yet).
[21:02] <infinity> Err, I am stupid.  My test removed the wrong package on the second pass.
[21:02]  * infinity redoes that bit.
[21:05] <infinity> slangasek: Okay.  Now all good.  :P
[21:07] <infinity> slangasek: Oh.  You seem to be away, according to your IRC client.  I'll trust my own testing on this one. :P