=== mmrazik is now known as mmrazik|afk
=== henrix_ is now known as henrix
=== mmrazik is now known as mmrazik|afk
=== doko_ is now known as doko
=== highvolt1ge is now known as highvoltage
[12:36] <jamespage> please could rtslib be demoted back to universe
[12:39] <cjwatson> jamespage: done
[12:40] <jamespage> thanks cjwatson
[13:24] <jamespage> doko, tomcat7 and jenkins both fixed fyi
[13:24] <doko> jamespage, already accepted =)
[13:25] <jamespage> so I see :-)
[13:29] <doko> infinity, did you look at the newlib ftbfs?
[13:30] <jamespage> doko, that jenkins update fixes the other two jenkins-* ftbfs as well
[13:30] <doko> ok, will give them back later
[13:31] <jamespage> doko, ta
[13:33] <doko> jamespage, I did subscribe you for review of my ecj update
[13:33] <jamespage> doko, lemme take a look
[13:44] <doko> Riddell, ScottK: uploaded a hack for the qt-assistant-compat ftbfs. but if you want to track this down properly ...
[13:44] <Riddell> thanks doko
[13:44] <doko> Riddell, should I accept it?
[13:44] <Riddell> doko: tracked down pykde issue, patch added to pyqt by someone
[14:00] <apw> looking to sync eventstat for QA use for power testing and the like, is unseeded
=== fginther` is now known as fginther
[14:39] <cyphermox> hi, could someone please review https://bugs.launchpad.net/autopilot-qt/+bug/1157697 ? we'd like to add a package to ship the new unit and integration tests being added to autopilot-qt, so that they can be reused
[14:39] <ubot2`> Launchpad bug 1157697 in autopilot-qt "[FFE] autopilot-qt lacks testing" [Critical,In progress]
[15:06] <dobey> can i get anyone to look at the freeze request on bug #1151621 ?
[15:06] <ubot2`> Launchpad bug 1151621 in Ubuntu Software Center stable-5-6 "[UIFe] TypeError when opening edit menu" [Undecided,Triaged] https://launchpad.net/bugs/1151621
[15:07] <dobey> or i need to attach a debdiff?
=== stgraber_ is now known as stgraber
[16:12] <Ursinha> stgraber, infinity, hey guys, is our call now or in one hour or so?
[16:13] <stgraber> Ursinha: not sure, though I'm not supposed to be around today (day off) and will be leaving for the airport in a few minutes
[16:13] <stgraber> Can someone from ubuntu-release review bug 1166286?
[16:13] <ubot2`> Launchpad bug 1166286 in lxc (Ubuntu) "[FFe] LXC 0.9 final" [Undecided,New] https://launchpad.net/bugs/1166286
[16:14] <Ursinha> stgraber, ah, safe travels :)
[16:14] <stgraber> I mentioned this when asking for the 0.9~rc1 FFe, final is now there and is ready for upload. If this gets approved in the next 45min I can even get this uploaded before I switch continent and become unreachable for a few days.
[16:18] <infinity> Ursinha: I think the later time is the right one, though it'll be cutting it close with a doctor's appointment I have, so I might end up skipping it too.
[16:19] <infinity> stgraber: Looks good to me, go for it.
[16:19] <stgraber> infinity: thanks
[16:21] <Ursinha> infinity, that's right, I talked to cjwatson already and pgraner won't be around as well, maybe there's no point having a call this week
[16:21] <Ursinha> ccccccbfuiiktniktllkncrlvuhlnvrnjgbutjvticbi
[16:21] <Ursinha> argh, sorry
[16:22] <infinity> My Portuguese is a bit weak, I'm not sure what that means.
[16:24] <infinity> cjwatson  / slangasek: In light of pgraner getting remarried by Elvis, stgraber being on an airplane, and me being prodded by medical professionals, you may want to cancel the sync call.  Or have a friendly gathering of three people.  Your call.
[16:24] <cjwatson> Heh, we just figured we'd cancel
[16:25] <cjwatson> I'm mostly swearing at ghc today anyway
[16:25] <cjwatson> As well as a prototype that Steve asked me for, not release-relevant
[16:26] <cjwatson> infinity: Did you end up needing to brutalise publish-release any more at the end of last week?  I didn't see any patches
[16:27] <infinity> cjwatson: I mangled publish-image-set, didn't do anything to publish-release.
[16:27] <infinity> cjwatson: publish-release DOES fail in dry-run though.
[16:27] <cjwatson> Oh, yes, you said something about that
[16:28] <infinity> cjwatson: I just opted for not caring at the time, since it worked fine otherwise.
[16:28] <infinity> cjwatson: It tries to write out the html/htaccess bits even when dry.  Probably just needs the whole thing wrapped in a big "if: nu uh", unless you want some pretty "would be doing" output.
[16:29] <cjwatson> Yeah, that's easily fixed
[16:29] <cjwatson> I've got a self.do wrapper method for that kind of thing
[16:32] <cjwatson> infinity: fixed, r1236
[16:32] <infinity> Cheers.
[17:41] <doko> jamespage, https://launchpad.net/ubuntu/+source/rtslib/2.1.fb27.isreally.2.1-0ubuntu1/+build/4477711
[17:42] <doko> Missing build dependencies: python-simpleparse
[17:50] <bdmurray>  .disk/info on a live cd still says Alpha fwiw
[17:57] <jamespage> doko, it needs demoting to universe
[18:14] <doko> jamespage, ahh, was already in raring, but not -proposed
=== james_ is now known as Guest53945
[19:58] <apw> infinity, as per our discussion i have uploaded a linux-lowlatency/linux-meta-lowlatency pair for raring
[20:01] <apw> thanks for keeping up queuebot :)
[20:34] <dobey> should i just upload something that's pending approval for UIFe in raring to proposed?
[20:34] <doko> UIFe?
[20:34] <dobey> apw: yay, maybe i can finally switch back to the lowlat kernel now :)
[20:46] <antarus> slangasek: is there actual documentation for these /usr/share/pam-configs and I'm jus missing it?
[20:47] <antarus> https://wiki.ubuntu.com/PAMConfigFrameworkSpec is rather...sparse?
[20:47] <slangasek> antarus: that's the documentation, such as it is
[20:47] <slangasek> antarus: there's a need for better documentation in the package, which I haven't done yet.  What's your question?
[20:48] <antarus> so we have...I'll call them 'complicated' pam configurations
[20:48] <antarus> right now they are all puppet templates, and we just do everything 'wrong'
[20:49] <antarus> so auth-type is sort of like 'required vs optional' ?
[20:49] <antarus> and what is the difference between 'auth' and 'auth-initial' ?
[20:49] <doko> h
[20:49] <antarus> just some sort of ordering?
[20:49] <doko> oops
[20:52] <antarus> slangasek: I guess one more important question; this only affects common-* right?
[20:53] <antarus> slangasek: is there no way to specific a per-service pam offering?
[20:54] <dobey> doko: sorry, yes a ui freeze exception: bug #1151621
[20:54] <ubot2`> Launchpad bug 1151621 in Ubuntu Software Center stable-5-6 "[UIFe] TypeError when opening edit menu" [Undecided,Triaged] https://launchpad.net/bugs/1151621
[20:54] <slangasek> antarus: 'auth' and 'auth-initial': some modules require different behavior depending on whether they're the first password-prompting module in the stack, or not
[20:54] <slangasek> antarus: 'required vs optional'> not exactly; per the wiki page, it's "Primary" == find any one that is okay, vs. "Additional" == run all without regard to success of other "Additional" modules
[20:55] <slangasek> antarus: so for instance, if you wanted to authenticate via Unix password OR kerberos OR fingerprint reader, these would all be "primary"; if you wanted to impose additional auth requirements serially, you would use "Additional"
[20:55] <slangasek> antarus: and yes, this is all only for common-* - per-service pam configs are out of scope
[20:56] <antarus> slangasek: great, thanks for the clarification
[21:37] <infinity> doko: That's a pretty impressively large gdb update this late...
[21:37] <doko> infinity, sure, but what would it break?
[21:37] <infinity> gdb, presumably? :)
[21:37] <doko> that we can fix
[21:38] <doko> but it's unlikely to break anything else
[21:38] <doko> well, maybe apport, but that will get disabled anyway for the release
[21:39] <doko> but look at the test results yourself
[21:39] <infinity> I assume the retracers also use the gdb native to the release.
[21:39] <infinity> Is there a PPA build?
[21:39]  * infinity looks in toolchain-r
[21:39] <doko> toolchain-r/ppa
[21:40] <infinity> Alright, I'll have a poke.
[21:40] <infinity> If the only argument for this is aarch64, I'm not sure it's worth any risk, since you can just land it in three weeks in S instead.
[21:41] <doko> ohh, it's python3 too, any general goodness like dwarf4
[21:41] <doko> s/any/and/
[22:52] <cjwatson> Laney: Hmm, I found a bug in the GHC ARM linker, essentially in passing - could cause it to jump into space sometimes
[22:53] <cjwatson> Laney: I'm not going to pretend I know it's http://hackage.haskell.org/trac/ghc/ticket/7316, and will file it separately, but it will be interesting to see if it turns out to cover that
[22:53] <cjwatson> Laney: (there was a sign handling error in Thumb relocation)
[23:25] <infinity> cjwatson: Hrm.  Thumb-only?  That could explain the armel/armhf differences in some cases.
[23:25] <cjwatson> infinity: Indeed.
[23:26] <cjwatson> The ARM encoding of BL doesn't use a sign bit in the same way.
[23:26] <cjwatson> ^- Could somebody review that apt-cacher-ng, which I sponsored?  Biggish customer waiting for it.
[23:26] <cjwatson> (And the previous state of acng appears to have sucked)
[23:27] <cjwatson> infinity: This isn't ARM's only problem, but I think I may have figured out ghci's woes as well; building a test package overnight to find out
[23:27] <infinity> cjwatson: Dude.  You're a machine.
[23:27] <infinity> (And I'll poke that acng when LP spits out a diff)
[23:28] <cjwatson> The other part of the patch looks like http://paste.ubuntu.com/5690839/, and similar though a bit modified for ghc-7.6
[23:29] <cjwatson> If you were to deduce that this has been a metric pain to figure out you'd be right
[23:29] <cjwatson> Anyway, with any luck tomorrow morning I'll be able to see if conduit now builds ...
[23:31] <cjwatson> If so then I just need to persuade GHC maintainers to apply patches and then it should be a few days from that to a completed transition, or good enough to remove the remaining blockers
[23:31] <infinity> \o/
[23:32] <infinity> I suspect convincing the Debian maintainers won't be hard. :P
[23:32] <infinity> They take porting patches very nearly blindly.
[23:37] <phillw> cjwatson: please be gentle, I've just emailed you re: mini-iso / netboot.
[23:50] <slangasek> cjwatson: this acng patch is surprisingly large for what it purports to do?
[23:51] <cjwatson> I looked at it myself a while back, it's quite hard to reduce
[23:51] <slangasek> well, e.g.:
[23:51] <slangasek> +-      off_t m_nRangeFrom, m_nRangeTo;
[23:51] <slangasek> ++      off_t m_nReqRangeFrom, m_nReqRangeTo;
[23:51] <cjwatson> But happy to go back to Chris to ask for further reductions if need be
[23:52] <cjwatson> Yeah, true, that could be reduced
[23:52] <slangasek> and the SetOption() API change also looks unrelated
[23:53] <slangasek> in fact, the only use of the new API discards the dupeCheck result
[23:54] <cjwatson> The reason I didn't go round myself was that the test cycle involves a bunch of laptops at a customer's site, so I was preferring the one that I knew to already have been tested
[23:54] <cjwatson> (The main symptom is racy)
[23:55] <cjwatson> But if you think it's too risky as it stands then that should take precedence
[23:55] <slangasek> well, it's at least more time-consuming to review than it otter be
[23:56] <slangasek> I'll probably finish the review & accept, but ask arges to send cleaner patches next time
[23:56]  * cjwatson -> bed, feel free to follow up with arges directly ...