[05:20] <pitti>  Good morning
[07:05] <dholbach> good morning
[07:49] <zyga> good morning
[08:27] <pitti> ogra_: we dropped/will drop support for the Galaxy Nexus, right? i. e. is it ok to drop the workaround for bug 1234743?
[08:27] <ogra_> pitti, we dont build device images for it anymore, might have stopped booting with some recent changes
[08:28] <pitti> ogra_: ack, thanks
[08:28] <ogra_> so yes, if it helps, drop it
[08:28] <ogra_> pitti, note that either the meizu or bq have PVR chipsets though, we might need it back we we are unlucky
[08:29] <pitti> ogra_: ah, ok; well, it's in git, if we see those produce uevents like mad we can adjust it to those
[08:30] <ogra_> right, just dont throw it away :)
[12:56] <pmcgowan> bregma, any progress on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1307701
[12:56] <bregma> pmcgowan, can't say I spent the last-minute release crush and the holidays working on it, so no progress yet
[12:57] <pmcgowan> bregma, ok, didnt know if it was assigned off to someone to look at
[14:52] <bdmurray> pitti: Could you please review https://code.launchpad.net/~brian-murray/apport/retrace-package-versions/+merge/210308?
[14:53] <bdmurray> mvo_: Could you have a look at bug 1309386?
[14:54] <mvo_> bdmurray: sure
[14:54] <bdmurray> mvo_: thanks
[15:34] <tedg> ev, So charles and I have some code for reporting recoverable problems that we've cut-and-pasted a few places, we're thinking it should go in a lib somewhere. Do you have a good place to put that?
[15:35] <cjwatson>  /wg 53
[15:35] <cjwatson> sorry
[15:41] <ev> tedg: libwhoopsie?
[15:41] <ev> tedg: and thanks to the both of you for taking on that work
[15:42] <tedg> ev, Heh, it's fun filling bugs on other people ;-)
[15:42] <ev> I have so little time for whoopsie and apport these days. It's encouraging to know that other people are stepping up
[15:42] <ev> lol
[15:44] <jibel> mvo_, when you have time could you have a look at bug 1296629 ? I cannot reproduce with the clone, but the upgrade path is different.
[16:25] <ScottK> NoNameYet_xnox: nonameyet was already used.
[16:39] <james_w> is there a way to test the 12.04 to 14.04 upgrade using do-release-upgrade?
[16:40] <james_w> now that it's not in development -d doesn't seem to pick it up
[16:40] <james_w> and so it just tries to upgrade to 12.10
[16:41] <Logan_> james_w: is your 12.04 installation fully updated?
[16:42] <james_w> yeah
[16:42] <Logan_> odd - people have reported being able to upgrade from 12.04 to 14.04
[16:44] <Laney> james_w: what does Prompt= say in /etc/update-manager/release-upgrades?
[16:44] <Logan_> james_w: edit /etc/update-manager/release-upgrades and set Prompt=lts
[16:44] <james_w> Laney: normal
[16:44] <Logan_> :P
[16:44] <james_w> aha
[16:45] <james_w> that did it, thanks
[16:45] <Laney> enjoy
[16:46] <Logan_> cheers :)
[16:57] <pitti> slangasek: do you want to target https://blueprints.launchpad.net/ubuntu/+spec/core-1403-systemd-transition at u-series, or for later?
[16:58] <pitti> slangasek: I have some working test packages in a PPA now; I dropped the systemd-services split as it was quite a large change towards Debian and didn't get accepted; and it seems rather unnecessary now
[16:59] <pitti> bdmurray: ack, will do first thing tomorrow; back from holidays now
[17:00]  * ogra_ wonders if U is really the cycle for systemd toying, given the phone teams need to build a stable phone release on top of it by summer
[17:03] <SpamapS> I'm going to go out on a limb and say that Firefox is using more memory than it should..
[17:03] <SpamapS> clint     5542 13.3 80.3 15004536 13098528 ?   Dl   Apr21 191:15 /usr/lib/firefox/firefox
[17:04] <cjwatson> ogra_: We have to experiment with it before we switch to it, no matter what
[17:05] <cjwatson> And I'd expect "phone still works" to be a blocking criterion
[17:05] <ogra_> cjwatson, yeah, i'm just scared by the default switch, surely not by playing
[17:05] <infinity> The default switch will have to happen eventually too, and we're always trying to ship a stable product.
[17:06] <infinity> So, no room for fear.  Just lots of testing before we swap.
[17:06] <ogra_> well
[17:06] <ogra_> being the one trying to optimize the boot speed i'm a bit unsure if i want to do all that throw away work :P
[17:06] <infinity> ogra_: Is the intent on the phone really to ship a U snapshot instead of sorting out a clever way to build on top of T?
[17:07] <ogra_> infinity, that would make us end up with gigantic PPAs filled with stuff that has to be maintained in two places
[17:07] <infinity> ogra_: Sure, but a snapshot dead in the middle of a distro cycle is also going to be problematic.
[17:07] <ogra_> i think U should be the base and we fork at some point
[17:08] <ogra_> rather than forking trusty and having to merge back the whole chunk later into U
[17:08] <ogra_> the whole trusty phone images were incredibly stable
[17:09] <ogra_> during the whole cycle ... my worry is if we can retain that stability in a non LTS cycle during development
[17:09] <ogra_> if it would be as stable as trusty was we surely would be fine with U
[17:09] <Unit193> ogra_: I started playing with it in Ubuntu the trusty cycle. :P
[17:10] <ogra_> do you like it ?
[17:11] <Unit193> There are actually a couple benefits to upstart, but shutdown is far faster with systemd.  (Bootup is the same though.)
[17:11] <ogra_> is it ?
[17:11] <ogra_> the numbers i have seen systemd was always slower
[17:11] <ogra_> (on bootup that is)
[17:12] <cjwatson> It's going to depend on a bunch of other integration work, either way
[17:12] <ogra_> indeed
[17:12] <Unit193> Updates are still pretty smooth, only times it isn't is when no init script is shipped in the package, and only an upstart job is, like with whoopsie.
[17:12] <cjwatson> e.g. in Debian, minimal systems with upstart vs. systemd, systemd boots significantly quicker (which is no doubt due to missing upstart jobs in various places)
[17:12] <slangasek> pitti: the systemd-services split is still necessary for the time being; we need to be able to land systemd in the archive on an opt-in basis before we make it the default
[17:13] <slangasek> pitti: oh, though I guess installing 'systemd' doesn't change init, so that's probably ok after all
[17:13] <slangasek> pitti: anyway, blueprint targeted, yah
[17:21] <orbisvicis> i've just built my first python-support package for a simple script (arch: all, requires .install file). Is it normal that all files were isntalled to /usr/share/pyshared/ and /usr/lib/python{2.6,2.7}/* is empty ?
[17:25] <orbisvicis> I am backporting a package from dh_python2, which installs to both /usr/share/pyshared/ and /usr/lib/python* (duplicates content from pyshared), which is why I'm asking. Is something missing?
[17:33] <dobey> orbisvicis: backporting to what? 10.04?
[17:33] <dobey> orbisvicis: it is normal with python-support though, yes. the symlinks in /usr/lib/python* are created at install time
[18:04] <orbisvicis> dobey: yes. thanks, now I know, at least, that the symlinks aren't being generated during installation
[18:05] <dobey> orbisvicis: i think dh_python in 14.04 doesn't have the symlinks or pyshared dir at all.
[18:07] <orbisvicis> dobey: backporting to 10.04, most likely the symlinks *should* exist?
[18:08] <dobey> orbisvicis: after installation, they will get created, yes
[18:08] <orbisvicis> well, the package works so I won't bother about it
[18:08] <dobey> that's how pysupport works
[18:09] <dobey> or during installation i guess (depending on how pedantic you want to be about unpacking, postinst, and dpkg triggers)
[18:11] <orbisvicis> dobey: any ideas why they wouldn't have been generated. python-support 1.0.4 ?
[18:12] <dobey> what do you mean not generated?
[18:12] <dobey> at package build time? or during install?
[18:14] <orbisvicis> dobey: during install
[18:14] <dobey> you installed the package, and it can be imported, right?
[18:15] <orbisvicis> dobey: yep
[18:16] <dobey> orbisvicis: then symlinks must have been created, and i guess you are looking in the wrong place for them :)
[18:16] <orbisvicis> dobey: good enough ;)
[18:16] <orbisvicis> for me
[19:03] <orbisvicis> does cdbs have "upstream" ?
[19:05] <orbisvicis> found t
[19:05] <orbisvicis> *it
[19:11] <Logan_> orbisvicis: upstream is Debian