[00:00] <slangasek> pretty sure we should shoot sl-modem-daemon in the head; I remember it being unmaintained/unmaintainable and RC-buggy already back in lucid
[00:00] <infinity> Well, dropping that might get your CDs down to size.  Maybe.
[00:00] <infinity> Then again, if we just give up the CD size thing, we could go 750 or 800 and include some actual translations again.  Which could be nice.
[00:01] <slangasek> certainly, the intersection of (people who need a newer image for enablement) and (people who need sl-modem-daemon) should be null
[00:01] <infinity> Linux for Human Beings* (who speak English) is a bit irritating.
[00:01] <slangasek> if it makes you feel better about it, we could squeeze the tlh langpack on
[00:01] <infinity> *snicker*
[00:38] <infinity> linux/armhf build down from 17.5h to 5.25h.  I think I'm happy with that.
[01:16] <Sarvatt> infinity: just curious, is that on a 24 node calxeda or a 12 node?
[01:18] <slangasek> 24
[01:18] <Sarvatt> kind of expected faster for 24 vs a panda if it was that.. unless the old ones weren't pandas
[01:19] <slangasek> Sarvatt: 24 *nodes* != 24 *cpus*
[01:19] <slangasek> think blade server
[01:19] <slangasek> each of which is quad-core
[01:19] <slangasek> (IIRC)
[01:23] <Sarvatt> ah, so it builds on one and the rest can be off building other stuff?
[01:31] <slangasek> Sarvatt: yes; each node is a separate host, https://launchpad.net/builders kishi[1-23]
[01:31] <Sarvatt> oh thats awesome :)
[01:35] <Sarvatt> if only LO webkit kernel firefox and chromium could be blocked it would be enough for public arm ppas :)
[01:35] <infinity> Sarvatt: Yeah, each node is a quad core A9 w/ 4G of RAM and its own disk.  They just happen to share a box and a network/power backplane.
[01:36] <infinity> Sane ARM PPAs will happen when we have ARM kit that can do paravirt.  So, A15s or A57s.
[06:23] <didrocks> Mirv: NEWed FYI ^
[06:24] <Mirv> ah, great
[08:41] <tjaalton> didrocks: hey, have you had time to look at MIRing nvidia-prime & fglrx-pxpress (lp1204820)?
[08:41] <didrocks> tjaalton: not today, can append that on Monday
[08:42] <tjaalton> didrocks: ok, thats fine, thanks
[09:04] <cjwatson> slangasek: Debian's still not ready to cope with :any, AFAIK; current sbuild and buildd can cope, but I don't think wheezy's can, and I think wanna-build explodes.  This was on my list to chase down at DebConf
[10:06] <jibel> cjwatson, infinity FYI I swtiched autopkgtest to ftpmaster and per package configuration files when there is one. So linux and libreoffice can use bigger disks, more RAM and CPUs.
[10:06] <jibel> and linux is green now
[10:30] <rbasak> SRU verification failed on bug 1121874. 32 affected on bug 1210380, which appears to include people who aren't aware that they have -proposed enabled.
[10:30] <ubot2`> Launchpad bug 1121874 in mysql-5.5 (Ubuntu) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged] https://launchpad.net/bugs/1121874
[10:30] <ubot2`> Launchpad bug 1210380 in mysql-5.5 (Ubuntu) "package mysql-server-5.5 5.5.32-0ubuntu<IP_ADDRESS> failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1210380
[10:31] <rbasak> 32 affected in just a few hours, so please can we pull mysql-server-5.5 from -proposed asap?
[10:32] <xnox> !regression-alert
[10:32] <ubot2`> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
[10:32] <xnox> see rbasak ^
[10:32] <rbasak> xnox: it's only -proposed, not -updates
[10:32]  * xnox ponders where above list of people is maintained.....
[10:33] <rbasak> In ubottu, AFAIK.
[10:33] <xnox> cause it should include update list of archive admins... who can remove packges.
[10:33] <rbasak> Evidently nobody tested this upload. doko ^^
[10:35] <seb128> infinity, slangasek: ^
[10:35] <seb128> xnox, rbasak: I can run the delete command if you want
[10:35] <seb128> but I'm neither nor in SRU team nor knowing the details about this specific issue
[10:36] <rbasak> It's only i -proposed, so I don't think it's critical to do it right this minute. An hour is fine IMHO, so I guess we can wait for an SRU team member.
[10:36] <seb128> e.g I decline responsibility if deleting it is wrong :p
[10:36] <seb128> let me delete it
[10:37] <seb128> rbasak, xnox: it's "mysql-5.5 5.5.32-0ubuntu<IP_ADDRESS> in precise-proposed"?
[10:38] <rbasak> seb128: yes. 5.5.32-0ubuntu<IP_ADDRESS>, 5.5.32-0ubuntu<IP_ADDRESS>, 5.5.32-0ubuntu<IP_ADDRESS>
[10:42] <seb128> rbasak, xnox: dropped from proposed for the 3 series, please see with the SRU team what to do next then
[10:42] <rbasak> seb128: thank you!
[10:42] <seb128> yw
[10:43] <seb128> stokachu, ^
[10:43] <seb128> doko_, ^ you sponsored it it seems
[12:27] <jdstrand> cjwatson: hey, you probably saw but I thought I'd explicitly say, I approved the click MIR yesterday
[12:30] <xnox> Do we want python-virtualenv in main or not?
[13:29] <stgraber> jibel: aware of any autopkgtest problem? I see ceph as RUNNING according to britney but it's been done for a couple of days now and lxc is also marked as RUNNING though it's not listed on either public or private jenkins
[13:30] <stgraber> jibel: nevermind, they both just started doing stuff :)
[13:31] <stgraber> jibel: so looks like they're shown as RUNNING before they actually get scheduled (or before the UI knows about them?)
[13:32] <jibel> stgraber, yes, there is a delay between the time britney submits a test request and jenkins catches it
[13:33]  * stgraber gets some popcorns and watches the lxc adt run, hoping this one will succeed
[13:34] <jibel> stgraber, jenkins polls every 15mn for new tests, it is on my todo to replace this with an inotify watch on the incoming directory
[13:35] <ScottK> It would be nice if those would be called "PENDING" or something until they start.
[13:36] <stgraber> jibel: that'd be nice indeed. I think we forgot (or didn't know) about this 15min delay when we discussed the total build+migration time for packages back at the release engineering sprint (I think we assumed it'd just start instantly)
[13:39] <stgraber> jibel: http://<IP_ADDRESS>:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-lxc/ARCH=amd64,label=adt/30/ <- any idea? (I'll see if I can reproduce it here)
[13:42] <jibel> stgraber, no idea why mkstemp call fails
[13:56] <stgraber> jibel: hmm, reproducable locally, odd. Let's see if I get that too outside of adt
[14:04] <stgraber> jibel: same lxc-create outside of adt is fine...
[14:20] <stgraber> jibel: hey, so what weird magic is adt-run doing?
[14:21] <stgraber> jibel: I'm sshed into the VM, running "lxc-create -t ubuntu -n saucy-dep8 -- -r saucy" works, running it through adt-run doesn't
[14:25] <stgraber> jibel: found it!
[14:25] <stgraber> jibel: unset TMPDIR
[14:25] <jibel> stgraber, hm, it could be because adt-run redefined TMPDIR
[14:25] <jibel> :)
[14:25] <stgraber> and now everything works
[14:26] <stgraber> jibel: did that behaviour change recently? I'm wondering because we did have succesful runs for lxc...
[14:27] <jibel> stgraber, no it didn't, adt-run setting TMPDIR has always been a problem
[14:27] <stgraber> ok, not sure how our tests ever worked then ;) anyway, I'll just push the unset TMPDIR to the archive and be done with it
[14:32] <stokachu> seb128: what was wrong with it?
[14:34] <seb128> stokachu, bug 1210380
[14:34] <ubot2`> Launchpad bug 1210380 in mysql-5.5 (Ubuntu) "package mysql-server-5.5 5.5.32-0ubuntu<IP_ADDRESS> failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1210380
[14:37] <stokachu> seb128: hmm ok i tested it and it worked lemme go back and see what happened
[14:50] <stokachu> seb128: ok i see the issue lemme go back and talk with support and get it straightened out
[14:52] <seb128> stokachu, thanks
[14:54] <jdstrand> cjwatson: ok, handled click promotion to unblock people. see https://bugs.launchpad.net/ubuntu/+source/click/+bug/1208800/comments/4 and change as desired
[14:54] <ubot2`> Ubuntu bug 1208800 in click (Ubuntu) "[MIR] click" [Undecided,Fix released]
[14:56] <slangasek> cjwatson: +1 for having it fixed at DebConf :)
[14:58] <rtg> Why is Saucy armhf kernel still in the NEW state ? Its been done for over 7 hours.
[14:58] <slangasek> rbasak: why are people not aware they have -proposed enabled?
[14:59] <slangasek> rtg: because NEW requires manual processing
[15:00] <rbasak> slangasek: I think there may be a class of users who just check everything, including maybe the -proposed box in update-manager.
[15:01] <rbasak> slangasek: a comment like "Ubuntu: fix it soon, it broked all my mysql servers when upgraded." for something only in -proposed suggests this to me.
[15:02] <slangasek> heh
[15:08] <ScottK> I have suggested before that the wording around proposed is just a bit too inviting to casual users.  The response was basically, "but we want a lot of people to test running proposed".
[15:08] <ScottK> I thought that was wrong before and I think it's wrong now.
[15:09] <ScottK> I think it would be better to make proposed NotAutomatic like backports so you only get packages you explicitly want from proposed.
[15:10] <rbasak> I'm not completely convinced by that. We have enough users that some proportion will always misinterpret, no matter what you do. The question is what that proportion is, and all we have here is evidence that at least one user misinterpreted.
[15:11] <rbasak> There exist casual users who actually like to be on the bleeding edge and accept that, and 44 of the 45 affected may belong to that group (we have no indication otherwise).
[15:11] <ScottK> I've also seen people enable proposed when asked to test something, take one look at it and say "It wants to upgrade 80 packages, OMG, no!"
[15:11] <rbasak> I have no objection to pinning back -proposed by default, for when it is enabled.
[15:13] <rbasak> Though perhaps that might be better off managed with careful update-manager UX.
[15:14] <rtg> Can I get someone to NEW the Saucy armhf kernel binaries ? I'd like them to bubble up into release soon.
[15:17] <ScottK> I think you'd want the combination of NotAutomatic and a proper UI.
[15:19] <infinity> rtg: Done.
[15:19] <rtg> infinity, thanks
[15:19] <infinity> rtg: Are we ready to see 3.11 go to the release pocket today?  Have we triple-checked that tseliot's got nvidia/fglrx happy with it?
[15:20] <rtg> infinity, tseliot has assured me that there are uploaded and functional
[15:20] <rtg> that they*
[15:21] <infinity> rtg: Alright.  We can bump d-i and watch the world burn over the weekend, or do it on Monday.  The latter may still be saner, unless we're all very confident. :)
[15:22] <rtg> infinity, I'm gonna dogfood 3.11 on tangerine today, but I've also been running it on at least one other SNB 2 way. Since I'm gonna be gone this weekend, maybe we should wait until late Sunday ?
[16:15] <infinity> rtg-afk: Waiting until Sunday/Monday to let it out of -proposed is fine by me.  Maybe I'll finish up the d-i/seed mangling by then and you/Andy can do the d-i ABI bump yourselves.
[17:01] <rtg> infinity, wfm
[17:02] <slangasek> ScottK: yes, I thought there was broad agreement that -proposed should be NotAutomatic, the problem is we don't yet have the UI to allow this to do something sensible
[17:02] <ScottK> Ah.  Ok.
[17:03] <ScottK> slangasek: BTW, did you see my comment on the blanket FFe for phone stuff?  Any thoughts?
[17:04] <slangasek> ScottK: yes, saw the comment, sorry for not having a chance to reply yet
[17:04] <ScottK> OK.
[17:04] <slangasek> ScottK: my personal feeling is that the release team's freeze enforcement shouldn't be used as a proxy battle for other disagreements over the contents of packages
[17:05] <slangasek> and that if qt5 maintenance is still problematic, we should face this head-on
[17:05] <ScottK> I agree we should also face it head on, but think it shouldn't get the free pass.
[17:05] <slangasek> for instance, supposing a change to qt5 was needed, and the patch got upstreamed and then backported; should someone have to request a separate FFe for that?
[17:06] <ScottK> No, but based on past performance, I don't think it's reasonable to delegate assuming that'll be done.
[17:06] <slangasek> is that wrt recent past (qt5)?
[17:07] <ScottK> I have not had a chance to review the packages recently.
[17:07] <ScottK> For raring I did give an FFe on the condition the change would be dropped for saucy since it wasn't upstreamable and then guess what didn't happen.
[17:08] <slangasek> ScottK: can you give me a pointer to the source package that happened on? (since there are a few of them in the case of qt5...)
[17:08] <ScottK> Sure.
[17:09] <slangasek> but raring is certainly recent enough that I agree we should be paying attention to this
[17:15] <ScottK> slangasek: The package is qtbase-opensource-src, the FFe was bug 1126205, and the relevant patch, enable_appmenu_support.diff (still there).
[17:15] <ubot2`> Launchpad bug 1126205 in indicator-appmenu (Ubuntu) "[FFe] Bring Unity appmenu / HUD integration to Qt5" [Undecided,In progress] https://launchpad.net/bugs/1126205
[17:15] <slangasek> ScottK: thanks
[17:16] <ScottK> Also, there's another patch in there, fix_maliit_activation.patch, that says it should be upstreamed or dropped, but neither has happened.
[17:17] <seb128> ScottK, it didn't happen *yet*, that's still on their list (I saw somebody mentioning it/the bug on their list of target before updating to 5.1, so they are aware of it)
[17:17] <seb128> ScottK, where you see misbehaviour there are mostly people with just too much to do...
[17:17] <ScottK> seb128: The agreement in the FFe was that it would be dropped when saucy opened.
[17:18] <seb128> ScottK, that patch is already a special case since it's to avoid a regression compared to what we had with qt4, and it has not been creating any issue so far that we know about
[17:18] <seb128> ScottK, right, people who agreed on that shouldn't have said that
[17:19] <seb128> ScottK, it was clear that the requirement was not a reasonable one, I would have argued back against you if I had seen it when the discussion happened
[17:19] <ScottK> That was the time to have the discussion.
[17:20] <seb128> ScottK, the rational was "let's regress rather than take a patch which has been carried for ages in old qt, for the sake of making a point about getting things upstream first or not"
[17:20] <slangasek> seb128: well, that didn't stop someone from agreeing to those conditions...
[17:21] <seb128> ScottK, right, I can't remake history, I just can say I'm going to participate to the discussion next time so we don't sign to do things we are not going to do
[17:21] <seb128> slangasek, right, and I agree there was a screwup there
[17:21] <seb128> slangasek, but I can't really change it after fact...
[17:21] <seb128> slangasek, all we can do is work to ensure we do better next time
[17:23] <slangasek> so, I think that brings me back around to my original point that release team freezes shouldn't be used to dictate policy wrt the contents of packages
[17:24] <slangasek> there's clearly a disagreement here about what the contents of the qt5 packages should be; the arbiter of that disagreement should be the TB, not the release team
[17:24] <ScottK> That's true, but I think it's reasonable for the release team to keep an eye on things late in the cycle to make sure there's no late churn.
[17:29] <seb128> right
[17:29] <seb128> the issue was not the end of the cycle though
[17:29] <seb128> it was having the patch kept for the next cycle
[17:29] <seb128> which as slangasek is more a TB issue than a release team one
[17:32] <ScottK> It started though around a late add of a feature to the package.
[17:34] <seb128> the feature part of the discussion was reasonable, you pushed back
[17:34] <seb128> they got stuff tested properly, including all rdepends
[17:34] <seb128> the rational was "avoid a regression" which was a fair one
[17:35] <seb128> I'm not sure "what happens next cycle" should be used by the release team as an hammer for ffe discussions
[17:35] <seb128> the ffe are about "is that ok to land now", not about "is it ok to have those changes in Ubuntu in principle"
[17:35] <ScottK> Right, but would all that testing have gotten done if they didn't have to ask for an FFe?
[17:35] <ScottK> You know it wouldn't have.
[17:36] <seb128> no, and I agree it makes sense to discuss a blanking ffe
[17:37] <seb128> what I'm arguing against is how "next cycle work" was used there
[17:38] <ScottK> Fair enough.  What I'm arguing is that there's not a demonstrated pattern of following through on agreements.  I don't think there's a lot of point in arguing.  I'm not going to suddenly trust them to DTRT.
[17:39] <ScottK> Getting stuff upstream properly has been a fight with PS and its antecedents since Karmic and I don't expect it to change.
[17:44] <seb128> ScottK, right, but it's not right to use your position in the release team to try to force changes of behaviour of people in exchange of having their ffe approved (when the behaviour is upstreaming of changes and not related to the said ffe)
[17:58] <ScottK> Separate from the patch issue, I think having had an FFe to enforce the additional testing was the right thing for that change.
[23:05] <rsalveti> hey, if someone around, mind checking ofono? there's a new ofono-scripts package, useful to debug ofono-rild related issues in touch
[23:05] <rsalveti> and one less package via ppa
[23:06] <infinity> rsalveti: Poking.
[23:07] <rsalveti> infinity: thanks
[23:10] <infinity> rsalveti: Looks sane.  Those all come from the upstream source?
[23:10] <infinity> rsalveti: Can you get that pushed to Debian too?  Seems like a reasonable addition to the packaging.
[23:10] <rsalveti> infinity: yup, only big change there is the rild patch, to add support for the rild based modems
[23:10] <rsalveti> yup, we discussed with cyphermox and he will be doing the package upstreaming for it next week
[23:11] <rsalveti> debian is a bit behind as well
[23:11]  * infinity nods.
[23:11] <rsalveti> infinity: awesome, thanks so much
[23:12]  * rsalveti vacation \o/
[23:12] <infinity> rsalveti: Are you stealing Ursula from me too, or vacationing alone?
[23:12] <rsalveti> infinity: oh yeah :-)
[23:12] <rsalveti> we'll be in montevideo, uruguay next week
[23:12] <infinity> rsalveti: Awesome.  Have fun.
[23:13] <rsalveti> thanks, have a nice weekend!
[23:13] <infinity> rsalveti: House-hunting a bit?  She was telling me that you're looking to relocate.
[23:13] <rsalveti> yeah, that's a possibility indeed
[23:13] <rsalveti> we'll see :-)
[23:13] <infinity> Very cool.  Enjoy yourselves.
[23:13] <rsalveti> hate this city
[23:13] <rsalveti> heheh
[23:13] <rsalveti> thanks, cya!


[00:46] <rlameiro> ScottL: any news about Stochastic?
[01:17] <ScottL> not yet, but i just sent the email not too long ago...i'm hoping to get an answer tonight though :)
[01:19] <rlameiro> :)
[19:00]  * abogani waves
[19:00] <abogani> persia: Stupid and fast question: Is change name to a source package painful?
[19:46] <scott-work> hi abogani
[19:52] <scott-work> abogani: I still have on my list to create a wiki page for the kernel information that you gave to me, a few tasks that I have left are taking about 1.5 weeks longer than anticipated
[20:20] <abogani> scott-work: Ok, thanks!
[23:51] <TheMuso> ScottL: How is the testing for beta 2 going?