=== sz0 is now known as sz0` === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === zz_nhayashi is now known as nhayashi === sz0` is now known as sz0 === sz0 is now known as sz0` === nhayashi is now known as zz_nhayashi [05:20] Good morning === zz_nhayashi is now known as nhayashi === nhayashi is now known as zz_nhayashi === zz_nhayashi is now known as nhayashi [07:05] good morning [07:49] good morning === xnox is now known as NoNameYet_xnox === Chipaca is now known as UtilitarianUvula [08:27] 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] bug 1234743 in systemd (Ubuntu Trusty) "omapfb module floods system with udev events on samsung galaxy nexus" [High,Fix released] https://launchpad.net/bugs/1234743 [08:27] pitti, we dont build device images for it anymore, might have stopped booting with some recent changes [08:28] ogra_: ack, thanks [08:28] so yes, if it helps, drop it [08:28] pitti, note that either the meizu or bq have PVR chipsets though, we might need it back we we are unlucky [08:29] ogra_: ah, ok; well, it's in git, if we see those produce uevents like mad we can adjust it to those [08:30] right, just dont throw it away :) === psivaa-afk is now known as psivaa === sz0` is now known as sz0 === UtilitarianUvula is now known as Chipaca === MacSlow is now known as MacSlow|lunch === apachelogger is now known as apachelogger_ === apachelogger_ is now known as apachelogger === mpt_ is now known as mpt === _salem is now known as salem_ === andyrock is now known as andyrock-lunch [12:56] bregma, any progress on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1307701 [12:56] Launchpad bug 1307701 in unity (Ubuntu) "Unity does not get touch events when SDK apps running" [High,Confirmed] [12:56] pmcgowan, can't say I spent the last-minute release crush and the holidays working on it, so no progress yet [12:57] bregma, ok, didnt know if it was assigned off to someone to look at === MacSlow|lunch is now known as MacSlow === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [14:52] pitti: Could you please review https://code.launchpad.net/~brian-murray/apport/retrace-package-versions/+merge/210308? [14:53] mvo_: Could you have a look at bug 1309386? [14:53] bug 1309386 in unity-control-center (Ubuntu) "System details page not aware of phased-updates" [High,Triaged] https://launchpad.net/bugs/1309386 [14:54] bdmurray: sure [14:54] mvo_: thanks === wedgwood is now known as Guest26994 === wedgwood1 is now known as wedgwood === tkamppeter__ is now known as tkamppeter [15:34] 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] /wg 53 [15:35] sorry [15:41] tedg: libwhoopsie? [15:41] tedg: and thanks to the both of you for taking on that work [15:42] ev, Heh, it's fun filling bugs on other people ;-) [15:42] I have so little time for whoopsie and apport these days. It's encouraging to know that other people are stepping up [15:42] lol [15:44] 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. [15:44] bug 1296629 in ubuntu-release-upgrader (Ubuntu) "Ubuntu 14.04 partial upgrade error: Removing python3-plainbox:i386 rather than change python3:any:i386" [Medium,Confirmed] https://launchpad.net/bugs/1296629 === arges` is now known as arges [16:25] NoNameYet_xnox: nonameyet was already used. === jamespag` is now known as jamespage [16:39] is there a way to test the 12.04 to 14.04 upgrade using do-release-upgrade? [16:40] now that it's not in development -d doesn't seem to pick it up [16:40] and so it just tries to upgrade to 12.10 [16:41] james_w: is your 12.04 installation fully updated? [16:42] yeah [16:42] odd - people have reported being able to upgrade from 12.04 to 14.04 [16:44] james_w: what does Prompt= say in /etc/update-manager/release-upgrades? [16:44] james_w: edit /etc/update-manager/release-upgrades and set Prompt=lts [16:44] Laney: normal [16:44] :P [16:44] aha [16:45] that did it, thanks [16:45] enjoy [16:46] cheers :) === bfiller is now known as bfiller_afk === sz0 is now known as sz0` [16:57] slangasek: do you want to target https://blueprints.launchpad.net/ubuntu/+spec/core-1403-systemd-transition at u-series, or for later? [16:58] 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] 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] I'm going to go out on a limb and say that Firefox is using more memory than it should.. [17:03] clint 5542 13.3 80.3 15004536 13098528 ? Dl Apr21 191:15 /usr/lib/firefox/firefox [17:04] ogra_: We have to experiment with it before we switch to it, no matter what [17:05] And I'd expect "phone still works" to be a blocking criterion [17:05] cjwatson, yeah, i'm just scared by the default switch, surely not by playing [17:05] The default switch will have to happen eventually too, and we're always trying to ship a stable product. [17:06] So, no room for fear. Just lots of testing before we swap. [17:06] well === sz0` is now known as sz0 [17:06] 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] 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] infinity, that would make us end up with gigantic PPAs filled with stuff that has to be maintained in two places [17:07] ogra_: Sure, but a snapshot dead in the middle of a distro cycle is also going to be problematic. [17:07] i think U should be the base and we fork at some point [17:08] rather than forking trusty and having to merge back the whole chunk later into U [17:08] the whole trusty phone images were incredibly stable [17:09] during the whole cycle ... my worry is if we can retain that stability in a non LTS cycle during development [17:09] if it would be as stable as trusty was we surely would be fine with U [17:09] ogra_: I started playing with it in Ubuntu the trusty cycle. :P [17:10] do you like it ? === ogasawara_ is now known as ogasawara [17:11] There are actually a couple benefits to upstart, but shutdown is far faster with systemd. (Bootup is the same though.) [17:11] is it ? [17:11] the numbers i have seen systemd was always slower [17:11] (on bootup that is) [17:12] It's going to depend on a bunch of other integration work, either way [17:12] indeed [17:12] 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] 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] 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] pitti: oh, though I guess installing 'systemd' doesn't change init, so that's probably ok after all [17:13] pitti: anyway, blueprint targeted, yah [17:21] 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] 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? === andyrock-lunch is now known as andyrock [17:33] orbisvicis: backporting to what? 10.04? [17:33] orbisvicis: it is normal with python-support though, yes. the symlinks in /usr/lib/python* are created at install time [18:04] dobey: yes. thanks, now I know, at least, that the symlinks aren't being generated during installation [18:05] orbisvicis: i think dh_python in 14.04 doesn't have the symlinks or pyshared dir at all. [18:07] dobey: backporting to 10.04, most likely the symlinks *should* exist? [18:08] orbisvicis: after installation, they will get created, yes [18:08] well, the package works so I won't bother about it [18:08] that's how pysupport works [18:09] or during installation i guess (depending on how pedantic you want to be about unpacking, postinst, and dpkg triggers) [18:11] dobey: any ideas why they wouldn't have been generated. python-support 1.0.4 ? === roadmr is now known as roadmr_afk [18:12] what do you mean not generated? [18:12] at package build time? or during install? [18:14] dobey: during install [18:14] you installed the package, and it can be imported, right? [18:15] dobey: yep [18:16] orbisvicis: then symlinks must have been created, and i guess you are looking in the wrong place for them :) [18:16] dobey: good enough ;) [18:16] for me [19:03] does cdbs have "upstream" ? [19:05] found t [19:05] *it [19:11] orbisvicis: upstream is Debian === roadmr_afk is now known as roadmr === bfiller_afk is now known as bfiller === salem_ is now known as _salem