[06:04] <gotwig> hey
[06:10]  * hyperair wonders how reliable ext4 is with auto_da_alloc,data=writeback.
[07:11] <ggherdov> Hi all, getting this while trying the upgrade 12.10 --> 13.04 http://bpaste.net/show/ma5h6BlmF5piP2Hyh7YN/ . what's happening ? (xpost to ubuntu-motu)
[07:13] <Tm_T> ggherdov: hi, 1) this is not user support channel 2) please don't crosspost (:
[07:13] <ggherdov> Tm_T: ok sorry.
[07:13] <Tm_T> np
[07:13] <Tm_T> ggherdov: #ubuntu would be the correct place for user support (:
[07:13] <ggherdov> good,
[08:04] <Kano> hi,can somebody set raring as default and saucy optional for packages.ubuntu.com?
[09:08] <hrw> ^C11:08 hrw@puchatek:~$ gcc --version
[09:08] <hrw> gcc-4.8.real (Ubuntu 4.8.0-4ubuntu2) 4.8.0
[09:08] <hrw> thanks doko ;)
[14:17] <ivoks> hi; there's a problem with synaptic when running in nb_NO locale; it crashes
[14:17] <ivoks> reason why it crashes is known and has been fixed in translations.lp.net few months ago
[14:17] <ivoks> but, it looks like fix never made it to raring
[14:18] <mitya57> ivoks: link to the wrong string?
[14:18] <ivoks> so, i'm not sure what package should i blame; synaptic or langpack? (both have been built months after the fix)
[14:18] <ivoks> mitya57: https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/880493
[14:18] <ivoks> mitya57: well, i'm not norwegian, but...
[14:20] <ivoks> mitya57: i think it's this one: https://translations.launchpad.net/synaptic/main/+pots/synaptic/nb/346/+translate
[14:23] <mitya57> ivoks: I'm looking
[14:23] <ivoks> mitya57: it crashes only on 32bit system, but on 64bit you can see wrong chars on status line of the synaptic's main window
[14:23] <ivoks> mitya57: if .mo is downloaded from lp, everything is fine
[14:42] <mitya57-mobile> ivoks: two of the translations mentioned in comment 46 haven't changed, third one looks like like a minor fix
[14:43] <mitya57-mobile> maybe the string numbers have changed?
[14:43] <ivoks> mitya57-mobile: string numbers probably changed; check out the string i've pasted
[14:44] <ivoks> mitya57-mobile: it looks like a minor change, but it makes synaptic functional; the source of the bug and the impact are known
[14:44] <ivoks> mitya57-mobile: what's uknown is - how do we get this fixed in raring, since it has been fixed in LP since end of 2012.
[14:45] <mitya57-mobile> ivoks: do you mean the "%i pakker i listen, ..." string?
[14:46] <ivoks> mitya57-mobile: yes
[14:47] <mitya57-mobile> ah, I see the wrong %sB at the end
[14:49] <hallyn> hi - bug 1113821 for libvirt in raring - could that get a quick push for sru testing?
[14:49] <dobey> Laney: thanks
[14:54] <mitya57-mobile> ivoks: I have a patch, will push when my wifi gets working again
[14:55] <ivoks> mitya57-mobile: patch is for... synaptic or langpack?
[14:56] <mitya57-mobile> ivoks: synaptic, it's not in main so it's not in langpacks
[14:56] <ivoks> ah, that's the reason...
[14:56] <ivoks> mitya57-mobile: thanks!
[15:15] <mitya57-mobile> ivoks: lp:~mitya57/synaptic/nb-po-fix
[15:16] <mitya57-mobile> mvo: ^
[15:17] <mvo> mitya57-mobile: nice, could you please add a merge-proposal?
[15:19] <mitya57-mobile> mvo: done
[15:21] <mvo> mitya57-mobile: thanks
[15:22] <mitya57-mobile> yw
[15:57] <ivoks> mitya57-mobile: awesome!
[15:57] <ivoks> mitya57-mobile: will you drive SRUs too? :)
[15:59] <mitya57-mobile> ivoks: maybe, can you file a bug (one that you linked above is a more general issue)?
[15:59] <ivoks> mitya57-mobile: ok, i will, tomorrow
[16:00] <mitya57-mobile> thanks, then please assign or subscribe me
[16:00] <ivoks> mitya57-mobile: ok
[16:46] <pitti> slangasek: FYI, that was already requested in bug 1167196; I'll look at your MP, too
[16:58] <bdmurray> barry: bug 1051935 has received a few more duplicates
[17:19] <xnox> Laney: seb128: why was upstart activation support dropped from dbus? ted and desktop actually now needs those patches since upstart is in the user session now with the session dbus.
[17:22] <Laney> xnox: Sorry, I don't know what you're talking about
[17:22] <Laney> got a link or something?
[17:27] <dobey> Laney: hey, is pitti at the sprint too?
[17:27] <Laney> yeah
[17:28]  * pitti waves to dobey, yes
[17:28] <dobey> hi pitti :)
[17:28] <xnox> Laney: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1014850/comments/9
[17:28] <dobey> pitti: did you see bug #1173249 ?
[17:29] <dobey> pitti: there's a debdiff there against pygobject which maybe should also be included in the upstream debian package
[17:31] <pitti> hm, no
[17:31] <pitti> software-center isn't even in Debian
[17:32] <jbicha> http://packages.qa.debian.org/software-center
[17:32] <pitti> and it seems this rather should be the other way around, i. e. s-c and aptdaemon should bump their python-gi dep?
[17:32] <Laney> xnox: I think I OKed this with Seb at the time mainly on the basis that it was unmaintained
[17:33] <dobey> pitti: the problem is when the old versions of those are still installed, but new python-gi is as well
[17:33] <dobey> pitti: so bumping the dep in them won't do anything if they're not installed yet
[17:33] <pitti> so as an SRU, yes; sorry, meeting now, will keep the bug open and look after it
[17:34] <dobey> it's to fix the crashing during upgrade
[17:34] <xnox> Laney: has the upstart team notified of this? from our point of view it was in dbus and usable =) and although default install didn't use it, the facility was provided (same like e.g. upstart socket activation bridge)
[17:35] <xnox> Laney: seb128 anything else? I wonder how far dbus now moved on to readd that functionality
[17:36] <dobey> and software-center has no need to bump the version dep on python-gi. nor does aptdaemon really. the new version works on both the old and new python-gi. problem is that python-gi broke the old versions. because breaking API is fun
[17:36] <xnox> Laney: jodh is an active upstart maintainer that things can be forked off to. regardless that scott was the original author of that patch series.
[17:38] <Laney> Well, now that it's needed it seems like a good time to investigate bringing it back :-)
[17:38] <Laney> Ideally via upstream too ;-)
[17:39] <pitti> Laney: bring back GObjectMeta? no, that won't happen
[17:39] <Laney> pitti: no, not you - talking to xnox
[17:39] <pitti> it has been an internal implementation detail (documented nowhere)
[17:40] <pitti> ah, ok
[17:40] <Laney> I agree that aptdaemon was using private implementation that it shouldn't be
[17:40] <Laney> but it still seems like Breaks: at least to aptdaemon is right
[17:40] <pitti> Laney: btw, I'm landing more logind stuff; do you want to look into landing the remaining logind bits? Robert is here, too
[17:40] <pitti> Laney: right
[17:40] <pitti> thanks dobey for the heads-up
[17:40] <Laney> the s-c one was try try and convince dpkg not to run its trigger until we have a working stack underneath it
[17:41] <Laney> pitti:  where are you? I'll come along in 10 minutes ish
[17:41] <xnox> pitti: bring back upstart activation in the dbus package that was dropped in quantal without asking jodh to rebase the patches.
[17:41] <Laney> wait, Robert is here, wtf
[17:41] <dobey> sure
[17:52] <pitti> Laney: QA room, 210
[17:53] <Laney> ack
[18:17] <pitti> Laney: http://pad.ubuntu.com/saucy-logind-transition
[18:19] <slangasek> pitti: ah, nice :)
[18:19] <pitti> better than spamming everyone on each upload
[18:22] <xnox> barry: in python i want `a[1][0][3] or False` to not ever raise any exceptions.
[18:22] <barry> a.get(1, []).get(0, []).get(3, [])
[18:22] <xnox> barry: because otherwise i have seen `a[1] and a[1][0] and a[1][0][3]` instead.
[18:22] <xnox> barry: that didn't return false though.
[18:23] <qengho> er.  a.get(1, [[False]])...?
[18:23] <xnox> qengho: sure.

[18:23] <qengho> try-except!
[18:24] <xnox> qengho: hardly a one line =)
[18:24] <barry> *finally*
[18:25] <qengho> xnox: space is cheap. understanding is expensive.
[19:05] <ev> bdmurray, cjwatson: I've updated the specification, creating a new "tying it all together" section with the notes from our discussion: https://wiki.ubuntu.com/ErrorTracker/PhasedUpdates#next
[19:05] <ev> can you have a look and make sure everything is there?
[19:05] <bdmurray> ev: look
[19:05] <bdmurray> er looking
[19:13] <cjwatson> ev: Looks mostly there except for a discussion of the curve from 0% up to 100%
[19:13] <cjwatson> (also priority -> urgency)
[19:14] <bdmurray> ev: I added a couple of things
[19:17] <bdmurray> cjwatson: it looks like there already is an ALWAYS_INCLUDE_PHASED_UPDATES in update-manager
[19:18] <cjwatson> bdmurray: right
[19:18] <cjwatson> bdmurray: I don't recall how (or if) that's exposed in the UI
[19:19] <bdmurray> cjwatson: okay, the request was for a UI for it?
[19:19] <ev> cjwatson: can you add the points about the curve to the wiki page?
[19:19] <ev> bdmurray: I've updated the page to account for those two issues per our discussion
[19:26] <cjwatson> bdmurray: yeah
[19:26] <cjwatson> ev: done very telegraphically (in a meeting)
[19:26] <ev> :)
[19:26] <ev> thanks!
[19:35] <roaksoax> deb http://archive.ubuntu.com/ubuntu/ precise-proposed restricted main multiverse universe
[19:35] <roaksoax> ewrr
[21:01] <mpt> mterry, hey, have you seen <https://code.launchpad.net/~sjakthol/update-manager/fix-slow-calculation/+merge/161284>?
[21:09] <xnox> mpt: nice. =)
[21:14] <mterry> mpt, on
[21:14] <mterry> mpt, no I hadn't
[21:26] <xnox> Laney: pitti: seb128_: http://paste.ubuntu.com/5617392/    lxc raring container.
[21:27] <seb128> hum
[21:28] <seb128> xnox, do you have debug output of the job/command?
[21:28] <jibel> xnox, this is a known issue with nested containers. There is a solution to fix this with latest lxc if your host is running raring too
[21:28] <xnox> stgraber: ^ is looking into this....
[21:28] <seb128> oh, ok
[21:28] <xnox> stgraber: wants to edit configs on my host ... =/
[21:30] <xnox> pitti: so in lxc container libpam-logind fails to configure if its cgroups  are not there as expected.
[21:30] <xnox> thus dpkg configure fails and it's all not pretty =/
[21:31] <pitti> xnox: libpam-systemd?
[21:31] <pitti> yeah, I discussed this with stgraber the other da
[21:31] <pitti> y
[21:31] <pitti> I think he said it needs an apparmor update to allow mounting the cgroup in the container
[21:31] <xnox> sure. but we should sru it in raring =/
[21:31] <xnox> stgraber: ^
[21:32] <xnox> or patch libpam-logind to not configure / require / blow up.
[21:32] <pitti> well, you are not supposed to use libpam-systemd in raring in a production env?
[21:33] <ogra_> pitti, pfft, details :P
[22:14] <pitti> stgraber: did you already file a bug about the "reboot after upgrade" issue? Laney and I just analyzed this
[22:20] <Laney> phew, figured it out and it's not *quite* as bad as it could be
[22:22] <Laney> lolicykit
[22:31] <ahoneybun> ogra_: can you make new images for Kubuntu Active?
[22:32] <ogra_> ahoneybun, for nexus7 ?
[22:35] <ScottK> ogra_: Yes.  Nexus7.
[22:36] <ogra_> if you mean S i fear that wont work
[22:36] <ogra_> we are dropping the nexus7 flavour completely
[22:37] <ogra_> (we will start to use the kernel on the ubuntu touch images, which means we need to drop some patches that make the desktop touch stuff work)
[22:38] <ogra_> slangasek, ^^ thats why i was wondering if we should juet let the old nexus7 kernel rot in the archive
[22:38] <ogra_> *just
[22:39] <pitti> slangasek, stgraber: reboot/suspend/etc. breakage after dist-upgrade fixed in policykit-1_0.105-1ubuntu3.dsc FYI
[23:01] <infinity> doko: Is it intentional that gcj-4.8-jdk pulls in gcj-4.7?
[23:03] <ScottK> ogra_: How about for raring?  I think ours hadn't been updated in awhile.
[23:03] <doko> infinity, fix the ecj build
[23:03] <infinity> doko: Oh, right.  I'll pass on that. ;)
[23:04] <ogra_> ScottK, well, why would it work better there if i rebuild the already broken image ?
[23:04] <ogra_> i can indeed trigger a new build, but i doubt it would work better than the last one
[23:04] <ScottK> How old is the last one?
[23:05] <ogra_> hmm some time around beta i think
[23:05] <ScottK> Might get lucky.
[23:05] <ogra_> might actually be that there is a fix in
[23:09] <ogra_> ScottK, running (not sure i can monitor it though, i'm on and off here (sprint))
[23:09] <ScottK> Thanks.
[23:09] <ogra_> ScottK, keep an eye on http://cdimage.ubuntu.com/kubuntu-active/daily-preinstalled/
[23:10] <ogra_> it usually takes between 90-120 min
[23:10] <ScottK> Great.
[23:10] <ogra_> (and feb was actually quite old for the last image ... )
[23:12] <ScottK> Right.  So maybe we get lucky.
[23:22] <cjwatson> ogra_: did you remember to say DIST=raring explicitly, BTW?
[23:23] <cjwatson> ogra_: I switched cdimage to saucy by default just before you started that build, I think ... hadn't noticed you were considering a new raring build
[23:23] <cjwatson> oh, you're standing next to me, ok
[23:23] <infinity> Hahaha.
[23:25] <cjwatson> ScottK: ogra_ said he did say DIST=raring when doing the build, which is good; but I think it'll actually spit out in http://cdimage.ubuntu.com/kubuntu-active/raring/daily-preinstalled/ since raring is no longer the default series
[23:26] <cjwatson> Probably, anyway.  It depends how closely the clocks on my IRC client and nusakan are synced ...
[23:26] <ScottK> OK.  Thanks.
[23:39] <pitti> bkerensa: hey! do you want to upload https://launchpad.net/~bkerensa/+archive/logind now, or shall I do it for you?
[23:41] <slangasek> ogra_, ScottK, ahoneybun: no, I certainly don't think we should "just" let the old nexus7 kernel rot in the archive; I think if flavors want to continue building images for n7 that requires a different kernel build than the one we're willing to maintain for Ubuntu Touch, we should have a conversation with them about assuming maintenance
[23:42] <slangasek> pitti: policykit> thanks :)
[23:42] <slangasek> ogra_: which one is the old nexus7 kernel, anyway?  Is that linux-nexus7?
[23:42] <jbicha> pitti: I believe bkerensa will need sponsorship at the least
[23:42] <pitti> slangasek, stgraber: if you caught the old version, "sudo reboot" will fix it
[23:42] <ogra_> slangasek, yeah, and we will switch it to linux-grouper
[23:42] <pitti> jbicha: np, I can upload it now
[23:42] <slangasek> ogra_: ah
[23:42] <ogra_> so linux-nexus7 could just stay around
[23:43] <slangasek> ogra_: then what is the linux-nexus4 kernel currently in the archive?
[23:43] <ogra_> a wrongly named one :)
[23:43] <slangasek> ogra_: there's no reason archive-wise that it couldn't stay around, but there needs to be an explicit hand-off to maintainers other than the kernel team
[23:43] <ogra_> the discussion to switch to arch vs marketing kernels only took place after the upload
[23:43] <slangasek> ogra_: ah, <shakes fist at rtg>
[23:44] <ogra_> well, its kind of my fault :) ... i started that scheme with the ac100 kernel
[23:44] <slangasek> ogra_: anyway, it wouldn't be fair to either the Kubuntu folks or the kernel team to leave the package in the archive as-is, with Kubuntu images using it and the kernel team not actually maintaining it
[23:44] <ogra_> though there it was actually right to call it like that since the kernel will never be able to run on any other tegra2
[23:45] <ogra_> slangasek, we had that for a good bunch of kernels in the past
[23:45] <ScottK> I'm sure we don't want to maintain a kernel for saucy.
[23:45] <slangasek> ogra_: that was a *bug*.
[23:45] <ogra_> all the stuff that came from linaro was just removed before raring
[23:45] <ogra_> ah
[23:45] <ScottK> This was just about raring.
[23:45] <slangasek> yes, and that was a bug that we left packages in place that were abandonware
[23:45] <slangasek> ah, well if it's just raring, then ignore me ;)
[23:46] <ogra_> ScottK, well, there is not anything to do actually ... its not like there are any changes to it usually
[23:46] <ScottK> We'll follow Ubuntu's lead on kernel stuff.
[23:46] <ogra_> k
[23:46] <ogra_> (android kernels are usually pretty stuck at what they are ... )
[23:48] <slangasek> ScottK: right; the challenge there is that the kernel we'll be building for nexus7 going forward will AIUI work for Ubuntu Touch but not be suitable for X-based systems
[23:49] <slangasek> (mutually incompatible patches at the moment)
[23:49] <ScottK> Sigh.
[23:49] <ScottK> So much for don't worry about Mir, it's all backward compatible.
[23:50] <slangasek> it's not Mir that's being incompatible here, it's the Android kernel
[23:51] <ScottK> OK, but it's compatible with?
[23:51] <slangasek> anyway, if you wanted a Kubuntu Active image using Mir+Xmir, I suppose that would work... once the code exists... :P
[23:51] <slangasek> ScottK: it's compatible with SurfaceFlinger
[23:51] <slangasek> I don't know if it's compatible with Mir, even
[23:51] <ScottK> OK.
[23:51] <slangasek> ScottK: also, I'm playing telephone here so I may have misunderstood the nature of the compatibility issue
[23:52] <ScottK> OK.
[23:52] <ScottK> I need to go help with making dinner anyway.
[23:55] <ogra_> slangasek, ScottK ... not a Mir/SurfaceFlinger issue ... the patch forces  the touchscreen to be an evdev device while Ubuntu Touch uses libinput
[23:56] <ogra_> (in either Mir or SurfaceFlinger ...)
[23:58] <RAOF> ogra_: But Mir also uses evdev?
[23:58] <slangasek> so there you go - not compatible with Mir either ;-P