[08:06] <dholbach> good morning
[09:52] <matv1> creating read/writeable image will just break system updates right? not clickstore updates..?
[09:53] <popey> well, it doesn't "break" either really
[09:53] <popey> but you lose any changes you make to the root fs when you do an ota update
[09:54] <matv1> ah
[09:56] <matv1> "By default the system is read-only. You can switch to read-write mode, although this disables Ubuntu system upgrades."
[09:57] <matv1> so that is not actualy true?
[10:01] <beuno> matv1, correct, the click store still works
[10:01] <beuno> matv1, I would guess it disables OTA system upgrades, as you'd loose data if you did upgrade that way
[10:01] <beuno> s/guess/expect
[10:02] <beuno> I'm sure you can manually override
[10:03] <JamesTait> Good morning all; happy Monday, and happy Home-Made Bread Day! :-D
[10:03] <matv1> bueno That would make sense to me. but popey seems to sugest that system upgrades will just keep on working.
[10:03] <matv1> ah no matter. I will find out soon enough :)
[10:03] <ogra_> you will get them offered
[10:04] <ogra_> (and you *can* apply them, but they will break your changes ot the system if your changes strech somewhere into the readonly image)
[10:05] <ogra_> (note that apt-get update already does that)
[10:05] <ogra_> (changing ro stuff i mean)
[10:06] <matv1> ogra_ okay I see. So be carefull is what youŕe all saying because they will be overwritten
[10:06] <matv1> thats clear then thnx
[10:07] <ogra_> and apt-get upgrade/dist-upgrade will break at some point
[10:07] <ogra_> in case you what to limit yourself to using apt
[10:08] <ogra_> s/what/want/
[11:14] <mandel> ogra_, did you get my last message?
[11:14] <mandel> ogra_, the bip service I use was failing :-/
[11:14] <mandel> ogra_, I'm getting the following message => Nov 17 05:57:32 ubuntu-phablet kernel: [    9.399181]init: cannot find '/sbin/adbd', disabling 'adbd'
[11:15] <mandel> ogra_, after installing the new android tools package
[11:30] <sil2100> Kaleo: ping! Hey, I have a question about progress on bug LP: #1376495
[11:30] <sil2100> Kaleo: since we didn't see too many updates on the bug recently - what's the status there?
[11:39] <ogra_> mandel, it fooled you ;)
[11:39] <ogra_> mandel, thats the android init ... which indeed isnt suppose to find that binary (we delete it in the container on boot)
[11:39] <mandel> ogra_, agh, ok
[11:40] <mandel> ogra_, where are the logs of our adbd written, I'm clearly grepping the wrong ones
[11:40] <ogra_> /var/log/upstart/android-tools-adbd...
[11:42] <mandel> ogra_, ack
[11:45] <Kaleo> sil2100, I believe it's been fixed for a month now
[11:47] <sil2100> Kaleo: in vivid?
[11:47] <sil2100> Kaleo: since we still see this failure on ubuntu-rtm
[11:47] <Kaleo> sil2100, in RTM
[11:47] <Kaleo> sil2100, let's check with omer
[11:53] <sil2100> Kaleo: maybe we're seeing a different crash then?
[11:53] <Kaleo> sil2100, possible
[11:53] <Kaleo> sil2100, you know what
[11:53] <Kaleo> sil2100, let's make it a new bug
[11:54] <Kaleo> sil2100, can you provide logs?
[11:57] <sil2100> Kaleo: sure, if you have access to the VPN you can find those here http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/161:20141114:20141106-572f18d/709/camera_app/
[11:57] <Kaleo> sil2100, ok do you see the failure on vivid as well?
[11:58] <sil2100> Kaleo: vivid has only 3 failures and no crash
[11:59] <Kaleo> sil2100, odd, the camera app version should be the same in both distrib.
[12:00] <Kaleo> so irritating
[12:01] <ogra_> do you guys compare the same arches ?
[12:03] <ogra_> Kaleo, sil2100, no crash but 5 failures http://dashboard.ubuntu-ci:8080/smokeng/vivid/touch/krillin/27:20141117:20141110-a638ede/716/camera_app/
[12:03] <ogra_> (thats vivid, same arch)
[12:04] <ogra_> mak has indeed only 3 errors on vivid
[12:06] <Kaleo> :)
[12:06] <mpt> I see a lot of bugs reported “XYZ screen is not localized”
[12:07] <mpt> I wonder if there’s a way of preventing that common mistake
[12:53] <seb128> mpt, what "common mistake"?
[12:53] <seb128> mpt, translation bugs?
[12:53] <mpt> seb128, leaving strings unlocalizable
[12:53] <seb128> mpt, it's a bit like saying "I see a lot bugs report "XYZ hits a segfault""
[12:57] <seb128> mpt, trying to reply to your question, "string is not translated" doesn't have a common "gotcha" we can easily check for
[12:57] <mpt> seb128, segfaults can be avoided by not writing in C, right? ;-)
[12:58] <seb128> mpt, the format depends of the language, the issue can be that the string is not correctly marked as translatable, or that the translation domain is not correctly set, or that the template is outdated, or that the launchpad import failed, or that the translators didn't pick it up yet, or that we didn't have a langpack export including yet, or that the langpack are buggy and don't include the domain, or...
[12:58] <mpt> Ah, ok
[12:58] <seb128> or that the program is started with the wrong env
[12:58] <seb128> or...
[12:58] <seb128> you get the idea I guess ;-)
[12:59] <seb128> mpt, yeah, avoiding C, and C++, and buggy python bindings, and vala, and... ;-)
[13:05] <Mirv> renatu: hey! do you want to go ahead with qtpim upgrade to latest git? if you want to execute on it, now would be a ~good time with vivid open :) so the plan would probably be that I update qtpim in a PPA to a git hash of you choice, and you'd fix the reverse dependencies and have those land to the same silo via MP:s
[13:05] <Mirv> renatu: let me know if/when you want to start on that
[13:06] <Mirv> renatu: that's of course assuming there's some benefits to be had from doing that work and having the newer git
[13:24] <renatu> Mirv, the qtpim MR is blocked for a while because of some errors with qmake, they are waiting for qt 5.4 to merge the pending merges, would be nice wait until it get solved
[13:27] <Mirv> renatu: ok. then it sounds it'll be later. and if current qtpim does not build against 5.4, it might be the qtpim transition would need to be done _together_ with 5.4.0 landing. let's see.
[13:27] <Mirv> which is not nice as it makes the landing yet bigger, but we need to do what we need to do
[13:29] <jgdxx> seb128, I've removed the unnecessary local component changes in [1], care to take a last look? :) [1] https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/about-multiline-fixes-1390148/+merge/241868
[13:43] <jgdx> mpt, hi, mind taking a look at [1], specifically how we lay out multiple IMEI values? I've implemented it[2], but it's trivial to change this implementation to whatever you recommend. [1] https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1205294 [2] http://i.imgur.com/jL9Vrw7.png
[13:43] <seb128> jgdx, approved
[13:44] <jgdx> seb128, thanks
[13:45] <seb128> jgdx, feel free to do another mp with the component change btw ;-)
[13:48] <jgdx> seb128, sure thing, however the improvement was marginal. Might be worth waiting for the UITK.
[13:48] <seb128> jgdx, k, your call, that's one of the reason I asked you for a different mp, if we change it we should document the motivation for the change ;-)
[13:55] <jgdx> seb128, totally agree and noted for future mps. :)
[14:02] <mpt> jgdx, so that’s one per SIM? I’d prefer an “IMEI:” list with two items in it, but eh, doesn’t matter much
[14:07] <jgdx> mpt, right, that makes more sense actually.
[14:25] <dobey> anyone on rtm-proposed on mako? does mms work for you?
[14:52] <seb128> hum
[14:53] <seb128> kenvandine, jgdx, did you see errors like that before?
[14:53] <seb128> https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/215/testReport/junit/ubuntu_system_settings.tests.test_cellular/DualSimCellularTestCase/test_allow_roaming_sim_1/
[14:53] <seb128> "Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorIN3mir25socket_disconnected_errorEEEEE
[14:53] <seb128> std::exception::what: Failed to send message to server: Broken pipe"
[14:53] <kenvandine> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorIN3mir25socket_disconnected_errorEEEEE
[14:53] <kenvandine> looks like something needs to be rebuilt maybe
[14:53] <seb128> would who know about that?
[14:54] <kenvandine> mir
[14:54] <seb128> but mir didn't change recently?
[14:54] <kenvandine> Caught exception at Mir/EGL driver boundary: /build/buildd/mir-0.8.0+14.10.20141010/src/client/rpc/stream_socket_transport.cpp(164): Throw in function virtual void mir::client::rpc::StreamSocketTransport::send_data(const std::vector<unsigned char>&)
[14:54] <kenvandine> sounds like mir though
[14:55]  * seb128 wonders is that's a transient issue
[14:55]  * seb128 retries CI
[14:55] <kenvandine> i would be very sad if that was a transient issue
[14:55] <kenvandine> then again, cpp has been known to make me sad :/
[14:56] <kenvandine> i guess it could be a code path not usually exercised
[14:56] <seb128> let's see
[14:57] <seb128> it could also be a boost sync in vivid
[14:57] <seb128> or something
[15:56] <kenvandine> pitti, i just realized that dbus-daemon in rtm is way behind utopic and vivid... do you think this high cpu bug could actually be dbus-daemon, and not completely caused by the upower version?
[15:59] <pitti> kenvandine: I'm afraid I don't have any facts to confirm or deny this
[15:59] <kenvandine> me either :)
[16:00] <pitti> kenvandine: there's certainly several things which multiply here -- copious driver notifications, the weird multiplication of battery events (to 1/s) in upowerd, plus that "burst" behaviour which we don't have logs for yet
[16:00] <kenvandine> pitti, i just heard this morning there was some people wanting to backport dbus-daemon to rtm
[16:00] <pitti> kenvandine: I don't think teh new DBUS broke ABI, so it should be possible to install on RTM
[16:00] <kenvandine> i can try that, after lunch :)
[16:00] <kenvandine> i don't want to break my daily driver phone before going out :)
[16:00] <pitti> kenvandine: that certainly sounds much scarier/more intrusive than backporting upower, but if either of those help, having both might help power consumption even more
[16:01] <pitti> heh
[16:01] <pitti> kenvandine: I don't get any of that effect on mako, but I'm happy to install the new dbus to see if it breaks booting or unity or system-settings
[16:01]  * pitti goes to install
[16:03] <kenvandine> pitti, and what's crazy is i saw dbus-daemon hit 73% while the screen was off!
[16:03] <kenvandine> and looking at those logs, nothing really jumped out at me as a cause
[16:05] <pitti> kenvandine: ok, it at least cleanly installs (dbus and libdbus-1-3); I just took the utopic packages which pull in libsystemd0 and libcap-ng0, the former won't happen with a soruce build on RTM
[16:05] <kenvandine> pitti, i did switch my krillin to vivid-proposed and verified i couldn't reproduce the problem there
[16:05] <kenvandine> on the same device, so something in that stack fixes it :)
[16:06] <kenvandine> pitti, i'll test installing that on my krillin this afternoon
[16:07] <kenvandine> that should give us an idea if it's upower or dbus-daemon
[16:07] <pitti> kenvandine: ok, it booted again and I don't see any obvious breakage
[16:07] <kenvandine> i certainly think it would be a good idea to get upower 0.99 in rtm though, just for the change notifications
[16:07] <pitti> *nod*
[16:08] <kenvandine> pmcgowan, ^^
[16:08] <kenvandine> we need to really talk about that
[16:08] <kenvandine> pmcgowan, but let me rule out dbus-daemon as the culprit first
[16:08] <pmcgowan> kenvandine, ok, following the bug
[16:08] <ogra_> kenvandine, it breaks apparmor
[16:09] <kenvandine> ogra_, grrr, this is why we need to talk about it :)
[16:09] <ogra_> kenvandine, wE're all well aware about the two missing revisions in RTM and ricmm is actually researching if it could help with the CPU eating
[16:09] <kenvandine> ogra_, see bug 1337200
[16:10] <ogra_> kani know it :)
[16:10] <ogra_> kenvandine, i know it, yes :)
[16:10] <ogra_> the point is that it doesnt look like securioty can get the apparmor issues fixes quickly
[16:10] <kenvandine> is there another bug # that ricmm is tracking?
[16:10] <kenvandine> just want to prevent duplicate work
[16:10] <kenvandine> bummer
[16:11] <ogra_> yeah, there is another one
[16:11] <kenvandine> i think one of these needs to be duped then
[16:11] <ogra_> bug 1380848
[16:12] <kenvandine> ogra_, oh, is that for dbus-daemon?
[16:12] <kenvandine> we've been focusing on upower
[16:13] <kenvandine> but i'm thinking it's possible there could be dbus-daemon bugs making it worse
[16:13] <ogra_> yeah
[16:14] <ogra_> kenvandine, there is another one as well, thats not tied to unity8 resets ...
[16:15]  * ogra_ tries to find it 
[16:17] <tyhicks> FYI, I'm working on the dbus-daemon bug that involves apparmor (LP: #1362469)
[16:17] <jdstrand> pitti, kenvandine: we really don't want dbus 1.8 in rtm due to bug #1362469. that said, testing if dbus 1.8 fixes the issue and then identifying a patch to backport is worthwhile
[16:17] <jdstrand> tyhicks: hi! :)
[16:17] <tyhicks> hey :)
[16:18] <jdstrand> unless of course, tyhicks finds the issue for the aforementioned bug
[16:18]  * jdstrand would still consider it risky to go to 1.8 this late, but that is not my call)
[16:18] <tyhicks> even if I can fix bug #1362469, it seems pretty risky to jump up to 1.8 so late in the rtm cycle (I did the dbus merge)
[16:19] <jdstrand> tyhicks: hehe
[16:19] <jdstrand> yes! :)
[16:19] <tyhicks> kenvandine: has it been confirmed that dbus 1.8 fixes the bug?
[16:20] <ogra_> tyhicks, what is "the rtm cycle" ?
[16:21] <ogra_> rtm is rolling ... 1.8 will land in it anyway at some point
[16:21] <jdstrand> ogra_: yes, but we aren't rolling before the GM
[16:21] <ogra_> heh, no
[16:21] <ogra_> well, we are ... but very very veeery slooow
[16:21] <jdstrand> which I think is all he meant
[16:21] <jdstrand> hehe, yes
[16:21] <tyhicks> right
[16:25] <kenvandine> tyhicks, i actually don't think it fixes the bug i've been looking at
[16:26] <kenvandine> pitti, pmcgowan: i don't think it could be dbus-daemon, it's only reproducible when the device is plugged in
[16:26] <tyhicks> kenvandine: ok - good to know
[16:26] <kenvandine> without being plugged in you can look at top, etc... but resuming from sleep settings is responsive
[16:26] <tyhicks> the apparmor bug is one of my top priorities so it should be fixed soon but it isn't an easy bug to track down and I don't have a solid timeline for the fix
[16:30] <zmaj> hello anyone here actually using ubuntu-touch?
[16:31] <popey> yes ☻
[16:31] <zmaj> could you see something for me on the app store?
[16:31] <zmaj> please?
[16:31] <popey> sure, wassup?
[16:31] <zmaj> search for bugapp
[16:32] <zmaj> I am the developer of that app btw
[16:32] <popey> zmaj: http://popey.mooo.com/screenshots/device-2014-11-17-163234.png
[16:33] <zmaj> nice,could you test it how it works?
[16:33] <zmaj> thx btw.
[16:34] <zmaj> i designed it for landscape mode
[16:34] <popey> i cant right this moment, bit busy
[16:34] <popey> ask on the google+ app developer community - I'm sure someone will ☻
[16:34] <zmaj> aha ok,well at least it is on the store :D
[18:45] <ogra_> jdstrand, did you notice that you can browse the filesystem from the browser ?
[18:45]  * ogra_ found that on the weekend 
[18:45] <ogra_> file:///
[18:45] <ogra_> just works :P
[18:46] <ogra_> i wonder if we should do something about that
[18:46] <ogra_> (given we dont allow the filemanager to access paths above $HOME by default)
[18:49] <jdstrand> ogra_: we do need to do something about that. can you file a bug?
[18:49] <ogra_> will o
[18:49] <ogra_> *do
[18:50]  * jdstrand adds a note to update the spec
[18:53] <ogra_> jdstrand, bug 1393515
[18:53] <jdstrand> thanks!
[19:04] <riku> ogra_: I fixed my system, twm actually works fine and I haven't had a problem with the touchscreen at all
[19:04] <riku> just one question
[19:04] <riku> how do I make the screen rotate?
[19:04] <riku> it defaults to portrait with lightdm-gtk-greeter and twm
[19:05] <riku> and the gyro won't rotate it
[19:05] <ogra_> i dont think you can with xrandr, you would have to use an xorg.conf with hardcoded modeline or some such
[19:05] <riku> can I make it default to be rotated clockwise?
[19:05] <riku> was what I was going to ask
[19:06] <riku> hmm but I cut my RAM usage from 548MB to below 200MB
[19:06] <riku> maybe #ubuntu can help me since it's not explicitly related to this device
[19:12] <kenvandine> pitti, pmcgowan: how would you guys feel about creating an rtm silo to build what we need for a upower transition for testing
[19:12]  * ogra_ would love that ...
[19:12] <ogra_> but its a lot of work for potentially nothing ...
[19:13] <kenvandine> i think it's the best way to really know if it's worth it
[19:13] <kenvandine> i doubt it's a lot of work for rtm
[19:13] <kenvandine> 5 packages maybe?
[19:13] <kenvandine> upower, powerd, indicator-power and system-settings
[19:13] <kenvandine> anything else?
[19:13] <pmcgowan> and apparmor?
[19:13] <pmcgowan> or was that not an issue
[19:13] <kenvandine> not for powerd
[19:14] <kenvandine> that's for dbus
[19:14] <pmcgowan> ok
[19:14] <ogra_> yeah
[19:14] <kenvandine> and just for testing we could try making those syncs with a rebuild
[19:14] <kenvandine> instead of cherry-picking for rtm branches
[19:14] <kenvandine> we won't land it, just to quickly see
[19:15] <taiebot> Is vivid 23 working?  i do not want to upgrade as there is no image created on the smoke tests http://ci.ubuntu.com/smokeng/vivid/
[19:17] <dobey> taiebot: it's running on my mako, but i'm not sure which definition of "working" you are looking for :)
[19:17] <ogra_> cleaning your hose ...
[19:17] <ogra_> ... doing the gardening
[19:17] <kenvandine> ogra_, what's the syntax for syncing multiple sources?
[19:18] <ogra_> convergence ;)
[19:18] <ogra_> kenvandine, hmm, i would do one copy-package for each ...
[19:18] <kenvandine> source copy?
[19:18] <kenvandine> not rely on the spreadsheet?
[19:18] <kenvandine> ogra_, look at line 49
[19:19] <kenvandine> i was going to reuse the testing silo i had for this last week
[19:19] <ogra_> well, ask sil or robru to do a sync for you
[19:19] <ogra_> thats a manual process anyway afaik
[19:19] <ogra_> the line looks ok
[19:19] <kenvandine> ogra_, can't i just do it myself ?
[19:20] <kenvandine> i do want to rebuild the sources
[19:20] <robru> kenvandine: yep you can assign that yourself, the default options to the build job will rebuild the sources
[19:20] <ogra_> that should happen automatically afaik ... for rtm the version should be mangled
[19:21] <phillip> hi can someone explane me the relevance of
[19:21] <ogra_> (which does a rebuild)
[19:21] <kenvandine> robru, so i can just reconfigure the silo?
[19:21] <phillip> https://translations.launchpad.net/ubuntu-rtm/14.09/+lang/de/
[19:21] <kenvandine> or do i need to use copy-package
[19:21] <robru> kenvandine: what did you do? add source packages? use the 'assign silo' from the menu and it'll reassign it.
[19:22] <ogra_> phillip, pitti or dpm should be able to ... but might be that they are both gone already
[19:22] <robru> kenvandine: i don't see any reason this would require copypackage
[19:22] <kenvandine> i already have a silo
[19:22] <kenvandine> robru, great, i thought ogra_ said it would be a manual process
[19:22] <phillip> ogra_: yeah, thanks.
[19:22] <robru> ogra_: kenvandine: did I miss something? the speadsheet row looks like a totally ordinary sync. I don't see any reason it would require any manual work
[19:23] <ogra_> kenvandine, well, i understood it once was a manual process of the trainguards :)
[19:23] <kenvandine> robru, so reconfigure complains settings is already in silo 3
[19:23] <kenvandine> how do i override that on reconfigure?
[19:23] <taiebot> dobey: booting and be able to use it as a phone would be great :-D. After a year of using it i must say it is still quite an experience to update ;-).
[19:23] <ogra_> my knowledge is ages behind though :)
[19:23] <robru> kenvandine: reconfigure with IGNORE_SOMETHINGOROTHER
[19:23] <robru> ogra_: yeah we automated syncing months ago
[19:23] <ogra_> right
[19:23] <kenvandine> yeah but i have no form?
[19:23] <kenvandine> or just add it to the url i guess
[19:24] <robru> kenvandine: when you go to the 'assign silo' link from the spreadsheet it gives a form before clicking the link. there's a checkbox for ignore there
[19:24] <kenvandine> robru, this is a reconfigure
[19:24] <kenvandine> i already have a silo
[19:24] <robru> kenvandine: yes, you need to use 'assign silo', it does reconfigures if you already have a silo.
[19:24] <kenvandine> for testing last week, just taking more extreme approach and testing more
[19:25] <kenvandine> oh
[19:25] <kenvandine> thx
[19:25] <robru> kenvandine: the 'reconfigure' link is the limited one, it can't add any new projects anyway
[19:25] <dobey> taiebot: well, i don't have a sim in it, so i don't know if phone and all still works, but if it worked in 22, i'd expect 23 is probably fine. there is a known problem with app installation, though (in vivid in general, not specific to that image)
[19:25] <kenvandine> robru, thx, didn't know we could do that... rock on!
[19:26] <robru> kenvandine: lol, yeah, yet another hidden misfeature in the spreadsheet. you're welcome
[19:26] <kenvandine> :-D
[19:27] <kenvandine> robru, also, is there a way to rebuild a current package in rtm along with the sync of other packages?
[19:27] <kenvandine> because i don't really need to sync settings, just rebuild what's already in rtm
[19:28] <kenvandine> oh, that's not true actually
[19:28] <kenvandine> nm
[19:29] <robru> kenvandine: heh, yeah not really. the sync feature is just a special case of the manual source sync feature, unfortunately there's no way to mix them, the silo is either one or the other. it's possible to mix MPs and manual sources however.
[19:30] <kenvandine> robru, ok, thx again
[19:31] <robru> kenvandine: you're welcome
[20:06] <dobey> why are the buttons in dash previews on vivid images "light blue" instead of orange?
[20:27] <josharenson> Where can I file a bug against phablet-tools? It isn't setup on lp.
[20:32] <kenvandine> ogra_, what's the trick for updating a package that has a config file loopback mounted?
[20:32] <kenvandine> like powerd
[20:32] <kenvandine> i umounted the config file
[20:32] <kenvandine> but dpkg still refuses to replace it
[20:34] <pmcgowan> josharenson, https://bugs.launchpad.net/ubuntu/+source/phablet-tools
[21:55] <keithzg> So . . . considering upgrading my Nexus 4's primary ROM to stock 5.0, does Ubuntu Touch work still with multiboot with 5.0 as a primary ROM? I'd suspect I'd have to flash the older radio partition, or?
[21:56] <popey> keithzg: i suspect it's unlikely anyone has tested that combo
[21:57] <dobey> Tassadar: ^^
[21:57] <Tassadar> if you mean with multirom, it should still work just like before, but I dunno about radio
[21:57] <Tassadar> I don't have n4
[21:58] <keithzg> Yeah, sorry I meant multirom, yeah.
[21:59] <keithzg> I tried installing 5.0 as a multirom ROM, and it just hangs after caching all the apps. So I have Android 4.2.2, SailfishOS and Ubuntu Touch all working fine, but now it seems too boringly stable ;)
[22:00] <keithzg> If nobody else has tried it yet, I guess I might as well be the one to find out!
[22:01] <keithzg> I hear that SailfishOS and 4.4 worked if one used the 4.2.2 radio.
[22:11] <dobey> meh, still can't send an mms. :-/
[22:14] <dobey> how do i tell *why* an mms failed to send?
[22:35] <keithzg> Hrmm. Flashing the factory 5.0 images onto my Nexus 4 *seems* to work, but then it stays playing the boot animation endlessly afterwards. Crap.
[22:40] <bubbasaures> keithzg, Have had on occasion had to reinstall installs, all images
[22:42] <keithzg> bubbasaures: Yeah, I tried flashing via the official factory images, flashing all (bootloader, radio, and the main zip). Now tried it a second time, this time using the script it ships with (not that I didn't just type the few lines it has in it out in my terminal manually the first time).
[22:43] <keithzg> Now I'm trying factory reset via the stock recovery, just in case *that* works...
[22:43] <nhaines> 5.0 is awfully nice.
[22:44] <keithzg> I wouldn't know :P
[22:44] <keithzg> Still just going to the endless boot animation. At least I get a popup on my desktop saying that it noticed an MTP device has been connected to my computer, so it's clearly doing *something*...
[22:45] <keithzg> Is there any way to boot an Android device while writing a log? Or to read some sort of boot log after the fact?
[22:47] <keithzg> At this point I'm tempted to just flash it back to 4.2.2 and see if at least *that* isn't broken...
[22:57] <ogra_> kenvandine, chrooted from recovery
[22:59] <ogra_> (i was planning to wrie a script for that one day)
[23:02] <bubbasaures> 5.0 just arrived on my nexus 7 2012
[23:05] <keithzg> Both my 2012 Nexus 7s broke, heh. One just died one day, and would only flicker the screen backlight when plugged into power; the other the screen cracked when a housemate's cat tripped me. My Nexus 7 2013 is the LTE version, so I'll probably get 5.0 on that in, oh, January? ;)
[23:05] <keithzg> Flashing 4.2.2 back onto my Nexus 4 it booted just fine, gonna try the OTA route and see how far that takes me.
[23:06] <nhaines> Clear your cache afterwards.
[23:10] <keithzg> nhaines: Oh believe me, I have done so with an OCD level of repetition and consistency :P
[23:11] <nhaines> keithzg: I just flashed the factory image to my N5, but in the past I've been pretty happy with OTA updates as long as I cleared my cache.  :)
[23:13] <keithzg> nhaines: To be clear here, I do mean literally OTA, I'm letting them just be found and installed by the OS itself!
[23:14] <nhaines> keithzg: and I literally mean you probably want to do a factory reset after a major OTA update.
[23:17] <keithzg> nhaines: Ah, I see. Well, never had issues before, and I was wiping obsessively when I was trying to do it manually, so I'm just going to try doing it all the normal way for now at least until I reach the end of the update chain.
[23:31] <mterry> tedg, you still around by any chance?
[23:35] <mterry> tedg, well when you do get this message, we should chat about my latest comments in https://code.launchpad.net/~mterry/unity8/greeter-profiles/+merge/237155