[04:09] <alex___> hall
[04:09] <alex___> hallo
[04:10] <alex___> whadd
[05:20] <echoe> is there any way to turn the phone off within the software?
[06:38] <dholbach> good morning
[07:48] <JamesTait> Good morning all; happy Save The Elephant Day! :-D
[07:55] <Aki-Thinkpad> JamesTait, Save the elephant day?
[07:56]  * JamesTait detects the merest hint of an echo.
[07:57] <Aki-Thinkpad> JamesTait, goto #postgres; they might be interested :P
[08:55] <sqwaw> strange issue
[08:56] <sqwaw> wifi only has connect to known networks
[08:56] <sqwaw> can't seem to join any
[08:56] <sqwaw> ifconfig only shows loopback
[09:28] <sqwaw> aaaand nevermind, reflash and it's working :/
[09:43] <pstolowski> Saviq: hi! one more advice needed.. what was the upgrade path you used for my phone in london? I flashed an old image (~100) with ubuntu-device-flash, then system-image-cli --channel=devel-proposed, but that gets stuck on the 'google' bootsplash
[09:45] <ogra_> pstolowski, did you ever make that image writable  ?
[09:45] <pstolowski> ogra_: i didn't
[09:45] <ogra_> do you have adb
[09:45] <Saviq> pstolowski, you're in good hands :)
[09:45] <pstolowski> ogra_: oh, wait, I did long time ago..
[09:45] <pstolowski> ogra_: sure i've
[09:46] <ogra_> (smells like your boot.img didnt get updated alongside ... stgraber was suspecting it could be related to writability)
[09:46] <ogra_> adb shell initctl status lxc-android-config
[09:46] <ogra_> does that say "stopped" ?
[09:47] <pstolowski> ogra_: it says stop/waiting
[09:47] <ogra_> right
[09:47] <ogra_> so your android container does not run ... most likely because you didnt get the new boot.img during upgrade
[09:48] <ogra_> adding -b0 (forcing the version to zero) to your system-image-cli call above would have avoided that
[09:48] <pstolowski> ogra_: i'll remote .writable-image, then system-image-cli --build=0, and retry, makes sens?
[09:48] <pstolowski> * sense
[09:48] <ogra_> try that, yeah
[09:55] <nerochiaro> my phone gets stuck at bootloader after installing an image, any ideas on how can i get it back to life or figure out what's wrong ?
[10:32] <mhr3> ev, hey, do you know if crashes on the phone are automatically sent to daisy?
[10:32] <ogra_> mhr3, they arent
[10:32] <mhr3> ogra_, do you know why?
[10:32] <ogra_> no :)
[10:32] <mhr3> ev, i guess you will know :)
[10:33] <ogra_> env MATCH=NULL
[10:33] <ogra_> script
[10:33] <ogra_>     [ -e /var/lib/apport/autoreport ] || exit 0
[10:33] <ogra_>     [ "$MATCH" = NULL ] && exit 0
[10:33] <ogra_> from /etc/init/apport-noui.conf
[10:34] <ogra_> run: sudo -u \#32011/usr/share/apport/whoopsie-upload-all
[10:34] <ogra_> manually ...
[10:38] <nik90> ogra_: my phone is stuck at the google logo. I have flashed devel, trusty and trusty-proposed. Still same issue. Any workarounds?
[10:38] <ogra_> nik90, did you use --bootstrap ?
[10:38] <nik90> ogra_: on running adb shell and then top, I notice there are not unity8 processes
[10:38] <nik90> ogra_: no I didnt
[10:38] <ogra_> you should :)
[10:38] <ogra_> else you will always have the boot.img from the very first install
[10:39] <nik90> ah ...thnx...trying now
[10:40] <nik90> ogra_: does it automatically go into the bootloader or do I need to press any magic key combination? In the terminal it says, Expecting the device to be in the bootloader... waiting
[10:41] <ogra_> i think it should do that automatically ... though i actually never tested that ... i usually do: "adb reboot bootloader" before i even try to flash
[10:41] <ogra_> (you can do that from a second terminal if it doesnt do it alone)
[10:42] <nik90> ah okay..I had to do it manually from the second terminal
[10:42]  * nik90 copies the above commands to a text file
[10:59] <ev> mhr3, ogra_: there was a bug in the upstart job way back when: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1235436
[11:00] <ev> this is fixed, but I guess we missed a few adjustments to get the phones autosubmitting
[11:00] <ev> I'll ask bdmurray to have a look
[11:01] <ogra_> root@ubuntu-phablet:~# ls /var/lib/apport/
[11:01] <ogra_> ls: cannot access /var/lib/apport/: No such file or directory
[11:01] <ogra_> making the dir writable doesnt suffice ... it needs to exist on first boot
[11:02] <ogra_> (postinst or some such needs to create it)
[11:03] <ogra_> ev, the point is that the "MATCH=NULL" will always match so it cant work, no matter if that dir exists and is writable or not
[11:04] <mhr3> ev, hope it won't take another 6 months
[11:04] <ev> mhr3: what took six months?
[11:04] <ev> mhr3: we've been very good in whoopsie of backporting changes, entirely thanks to bdmurray.
[11:04] <ogra_> ev, we havent been good at rolling images with backports ...
[11:05] <mhr3> ev, the bug you linked to is 6months old
[11:05] <ogra_> package changes dont help on the phone without an image buiold
[11:08] <ev> mhr3: it happened during my transition to management
[11:09] <ev> it was a time where work on the error tracker had to be suspended while we found a workable model for it to continue under
[11:10] <mhr3> ev, sorry, was meant as a nudge-nudge-wink-wink :)
[11:11] <ev> mhr3: if I could put 4039240397 people full time on the error tracker, I would. Believe me. If you guys really want and need this stuff, I'd encourage you to help out and I'll carve out some of my own time to get you bootstrapped on it. :)
[11:12] <ogra_> ev, btw adding a sleep 60 to delay the uploading for a minute after a new .crash file appears would prevent the boot from being hit by the uploading in case a .crash file appears during boot
[11:12] <ogra_> (in the script block)
[11:13] <mhr3> ev, well the server bits work now, so it seems that the job to actually autosubmit the crashes is only missing piece
[11:13] <ogra_> (we have quite some issues if apport thinks it shoould collect data during a boot ... like 30sec to 1min extra time added to the boot time)
[11:13] <mhr3> ev, to *fix* the job
[11:14] <ogra_> mhr3, ther are multiple issues ... the directory needs to be pre-created, the "MATCH" stuff needs to be dropped ... well, and i would prefer if the uploading didnt happen during boot
[11:15] <mhr3> ogra_, multiple small issues ;)
[11:15] <ogra_> right
[11:15] <ogra_> but we are one day before release
[11:15] <mhr3> true
[11:16] <ogra_> so this needs to be looked at very very carefully if we want to still fix it
[11:16] <ogra_> (and testing of teh changes should start asap)
[11:28] <asac> "Only issue I observed so far is that upgrade screen shows 13.10 when actually it is downloading 14.04 trusty image. This is bit of misleading.
[11:28] <asac> "
[11:28] <asac> do we need to bump something still?
[11:28] <asac> somewhere?
[11:29] <asac> where does the upgrade take this data from?
[11:29] <ogra_> dunno ... probably gatox konws
[11:29] <asac> gatox: ^^
[11:29] <ogra_> iirc he does the UI
[11:29] <asac> gatox: we tested upgrading from 13.10 to latest 14.04 image and observed the above
[11:30] <asac> ogra_: whoelse?
[11:30] <asac> i need more folks
[11:30] <ogra_> asac, what about the above ? (whoopsie auto uploads)
[11:30] <ogra_> asac, well, its seb128's team
[11:30] <asac> ev: forgot to ask about whoospie ... did you find out why its broken?
[11:30] <ogra_> not sure if mandel knows much about the UI side, he does download-manager
[11:30] <asac> seb is off?
[11:30] <ogra_> asac, it is turned off in the upstart job
[11:31] <ogra_> asac, but there is more
[11:33] <ogra_> asac, there is a bug that was never properly fixed (missing dir), there is the explicit exit 0 in the upstart job that makes it not start at all and there should be a sleep i the upstart job so it doesnt kick in during boot
[11:33] <asac> ok
[11:33] <asac> well, if we can convince ourselves to push this build to stable
[11:33] <asac> we planned to keep stable == devel for a while
[11:33] <asac> so we can do that after
[11:34] <ogra_> well, adding the fixes would take me 5 min ... the prob is do we get enough testing
[11:36] <ogra_> there are chances to get it into the release ... but since this feature has been off since forever i'm not sure we should actually do it
[11:52] <sergiusens> ogra_: one more to add; don't process crashes if on battery please :-)
[11:54] <ogra_> sergiusens, i doubt thats something we can fix now before release
[11:54] <sergiusens> ogra_: in my mind we are rolling until feature freeze applies to us ;-)
[11:55] <ogra_> well, but your mind does not do press reviews of images that were announced :)
[11:55] <sergiusens> I'm thinking that the more we get in sync with desktop the more we will drop our rolling capabilities
[11:55] <ogra_> news sites will pick up the released image and judge it
[11:55] <sergiusens> ogra_: the press review that matters is meizu and bq :-)
[11:55] <ogra_> or the other way round
[11:56] <ogra_> they matter too
[11:56] <ogra_> but they are 14.10 ... by then we are hopefully feature complete and rock solid
[11:56] <ogra_> (and fast)
[11:57] <ogra_> sergiusens, oh, btw, didnt you add a "adb reboot bootloader" to ubuntu-device-flash recently ? seems nik90 had to manually do that above
[11:57] <asac> i dont think we should fix the disabled whoospie today
[11:57] <asac> lest do that right after the image got out
[11:57] <ogra_> asac, ok
[11:57] <asac> and have that exposed for abit
[11:57] <asac> also think about battery part etc.
[11:57] <ogra_> yep
[11:58] <sergiusens> ogra_: I wanted ubuntu-device-flash with --bootstrap to behave like ./flash-all.sh
[12:01] <sergiusens> ogra_: and no bug logged for this just made me forget of thinking about it
[12:01] <ogra_> ah, i thought i even had seen a MP
[12:02] <ogra_> asac, i re-opened bug 1235436 FYI
[12:02] <ogra_> (since it claimed fix-released)
[12:11] <nerochiaro> sergiusens: after installing the most recent image my phone seems to be stuck at bootloader. how can i revive it ?
[12:12] <sergiusens> nerochiaro: have you rebooted at least once?
[12:12] <sergiusens> ogra_: does the full image still fit into /cache/recovery?
[12:13] <ogra_> sergiusens, for my last OTA it did
[12:13] <ogra_> and for my bootchart --bootstrap install it did too
[12:13] <sergiusens> ogra_: yeah, wondering if FULL images this fit
[12:13] <sergiusens> ogra_: we are good then
[12:14] <sergiusens> nerochiaro: can you rm any tar files from /cache/recovery/ and try flashing again?
[12:14] <ogra_> the cdimage tarball is tgz ... the system-image tarballs are tar.xz so there is still some wiggle room
[12:21] <nerochiaro> sergiusens: i was running off of a dual boot installation, if that matters. how can i get a shell to remove the files from there ?
[12:22] <pstolowski> ogra_: no luck with what we discussed earlier. stuck on 'google'
[12:22] <sergiusens> nerochiaro: does ubuntu-device-flash work with dual boot? We officially dont support dual boot and I've never used it
[12:22] <sergiusens> I don't think it does, fwiw
[12:22] <ogra_> pstolowski, weird, that should have force upgraded the boot.img
[12:23] <rickspencer3> I once joined an open AP in my house but it doesn't actually work (requires a password in the web browser type thing). every time I turn on my phone, it connects to that AP. Is there a GUI way to turn it off, or do I need to delete a NM file or something?
[12:23] <ogra_> pstolowski, you can work around it by running: update-initramfs -u
[12:23] <ogra_> (and ignore the scary errors it prints)
[12:23] <ogra_> oh, and the image needs to be writable for this to work
[12:23] <sergiusens> rickspencer3: there is no 'edit connections' yet; should be the system settings when it happens
[12:23] <rickspencer3> thanks sergiusens
[12:27] <cyphermox> rickspencer3: you'll want to find the file to the AP's name in /etc/NetworkManager/system-connections
[12:28] <cyphermox> (and delete it)
[12:28] <rickspencer3> thanks cyphermox
[12:28] <rickspencer3> yeah, that's all I did
[12:28] <cyphermox> yup
[12:28] <rickspencer3> I just wanted to test the gui way if there was one
[12:28] <cyphermox> unfortunately there isn't yet :(
[12:28] <rickspencer3> I try to be good and use the features as much as possible :)
[12:28] <rickspencer3> cyphermox, understood
[12:28] <rickspencer3> I suppose we need a "forget this AP" feature
[12:29] <cyphermox> yeah
[12:29] <nerochiaro> dpm: for development if one is using dual boot the right channel is trusty-proposed, right ?
[12:29] <cyphermox> some kind of side swipe of the AP maybe
[12:29] <rickspencer3> man what we really need is to cache these pictures for the app store
[12:29] <cyphermox> assuming that's possible in an indicator :)
[12:29] <rickspencer3> or maybe we do and they are just slow to load
[12:30] <pstolowski> ogra_: awesome, that fixed it, i.e. it booted into the new image, thanks!
[12:30] <dpm> nerochiaro, trusty should work too. I had been using the stable channel for quite a while, I just recently switched to trusty-proposed to get new scopes goodness before the latest stable image was promoted
[12:31] <nerochiaro> dpm: ok, the problem is that after the last update i'm stuck at bootloader when i reboot in ubuntu. i'm trying again after wiping /cache/ just to see if anything changes
[12:31] <ogra_> pstolowski, welcome
[12:31] <ogra_> cyphermox, i opened a new rfkill bug for you ... probably we can still get that in
[12:32] <dpm> nerochiaro, I've heard others have had the problem recently, even if they weren't using dual boot. nik90, did you manage to fix your "stuck in Google logo" issue? ^
[12:32] <cyphermox> ogra_: rfkill is seeded.
[12:32] <ogra_> ah, k
[12:32] <ogra_> well, would be a trivial change
[12:32] <cyphermox> what's the bug number
[12:32] <ogra_> (adding a dir to the .dirs file)
[12:33] <ogra_> cyphermox, bug 1308459
[12:36] <sergiusens> dpm: I was told that nik90's issue was with ubuntu-device-flash...
[12:37] <sergiusens> dpm: they should be unrelated; but stuck at google logo means; grab logs for /cache/recovery/*.log, kernel messages and logcat
[12:37] <ogra_> sergiusens, well, he flashed multiple images in succession before ... without using --bootstrap
[12:38] <ogra_> sergiusens, unpacking of the android initrd happens from the initramfs since like 10 images or so ... if boot.img doesnt get updated along with teh rootfs as it always should, the container wont start
[12:38] <sergiusens> ogra_: if you come from something different than pure ubuntu touch, you need to bootstrap; I thought I made that clear on the wiki; you can have some levels of success without bootstrap; but on your own
[12:38] <ogra_> right
[12:39] <sergiusens> ogra_: that's why I made the command switch very noticeable; no better word than 'bootstrap' :-)
[12:39] <ogra_> with the above change you wont have success though ... unless you have a newer intird
[12:39] <ogra_> yeah
[12:39] <sergiusens> ogra_: I guess that change breaks dual boot; but they'll have to play catchup
[12:40]  * sergiusens reboots into updated ubuntu, brb
[12:40] <sergiusens> ...or not :-P
[12:40] <nik90> dpm: yeah I fixed my issue
[12:41] <nik90> nerochiaro: I had the issue with the latest image, but that's because I didn't use --bootstrap while flashing it
[12:48] <dpm> ok, thanks sergiusens, nik90
[12:52] <nerochiaro> dpm: nik90: how do i remove dual boot anyway ?
[12:52] <nerochiaro> dpm: nik90: and just run ubuntu
[12:52] <dpm> nerochiaro, you can just wipe your device
[12:53] <nik90> nerochiaro: may be try ubuntu-device-flash --channel=trusty --wipe --bootstrap
[12:53] <nik90> nerochiaro: the --wipe should remove everything
[12:56] <nerochiaro> nik90: --bootstrap it tells me it detects device "tuna" but it's not supported
[12:56] <nik90> nerochiaro: isn't your device a nexus 4?
[12:56] <nerochiaro> nik90: galaxy nexus
[12:57] <nik90> nerochiaro: I don't know..may be it is not supported for galaxy nexus
[12:58] <nerochiaro> dpm: what do you mean ?
[12:58] <dpm> nik90, I meant essentially what nik90 pasted
[12:59] <dpm> but it seems ubuntu-device-flash no longer supports the Galaxy Nexus
[12:59] <dpm> sergiusens, would phablet-flash work for nerochiaro's Galaxy Nexus? ^
[13:00] <asac> ogra_: did our image size grow again
[13:00] <asac> iftikhar was ablet to upgrade a couple horus ago
[13:00] <ogra_> not since yesterday
[13:00] <asac> from stable to devel
[13:00] <asac> but now it doesnt work anymore
[13:02] <ogra_> asac, the tarball was the same size for the last four images
[13:05] <pmcgowan> dpm, galaxy must be supported  nerochiaro what happens if you put in --device=maguro, what the heck is tuna
[13:05] <dpm> a fish? ;)
[13:05] <ogra_> pmcgowan, galaxy wont work with latest images
[13:05] <sergiusens> dpm: ubuntu-device-flash should work
[13:05] <pmcgowan> ogra_, huh?
[13:05] <sergiusens> dpm: but there are no images for maguro on devel-proposed
[13:05] <ogra_> pmcgowan, we dont produce images for it anymore
[13:06] <pmcgowan> ogra_, how come
[13:06] <ogra_> the android boot and system.img are outdated
[13:06] <pmcgowan> must have missed a memo
[13:06] <ogra_> pmcgowan, asac asked for it
[13:06] <sergiusens> pmcgowan: tuna is the basename for all the galaxies
[13:06] <sergiusens> dpm: nerochiaro for ubuntu-device-flash just add --device maguro as pmcgowan mentions
[13:07] <pmcgowan> ogra_, we have devs with only maguros still I think
[13:07] <sergiusens> that only happens when you bootstrap
[13:07] <ogra_> pmcgowan, maguro is stuck on 188 ... there were rootfs rebuilds for it because they dont cost us anything ... but they only worked by sheer luck
[13:07] <pmcgowan> I see
[13:07] <sergiusens> pmcgowan: there was an email 2 months ago from asac mentioning this
[13:07] <ogra_> right
[13:07] <pmcgowan> I recall it was coming but not that it happened
[13:07]  * sergiusens wonders if people skim through emails at least
[13:07] <ogra_> happened shortly after that email
[13:07] <pmcgowan> ok
[13:08] <asac> the android 4.4 switch was the time when we couldnt continue doing it anymore.
[13:08] <ogra_> (as the ermail even said i think)
[13:08] <ogra_> right
[13:08] <pmcgowan> ok I simply forgot
[13:08] <asac> rsalveti treid to keep it going but that didnt go that well
[13:08] <asac> the idea was that we get the emulator, but there were too many firedrills
[13:08] <asac> so now we have only arm emulator
[13:08] <asac> which is awful
[13:08] <ogra_> depends ... you can do gardening while the tests run ... or the dishes
[13:08] <ogra_> :)
[13:08] <pmcgowan> seems nerochiaro may need a new phone then
[13:09] <pmcgowan> bfiller, ^^
[13:09] <asac> however, i dont know about many real engineers that dont have a mako nowadays
[13:09] <ogra_> pmcgowan, nobody should work with unsupported HW
[13:09] <pmcgowan> agreed
[13:09] <asac> pmcgowan: yes, maguro only is a big flag
[13:09] <asac> to raise
[13:09] <ogra_> nerochiaro, you can work around the outdated initrd at least by running "update-initramfs -u" for now
[13:09] <asac> we have no preallocated budget, but if i get mroe engineers that dont have a supported device we surely can get that
[13:10] <pmcgowan> asac, does your spreadsheet tell you if anyone is in that situation?
[13:10] <ogra_> that should get you going ... but i wouldnt trust any test results on such a device
[13:10] <sergiusens> pmcgowan: fwiw I bought a mako myself ;-)
[13:10] <bfiller> pmcgowan: nerochiaro and artmello need nexus 4's
[13:10] <bfiller> nerochiaro: can you use tablet if having problems with GN?
[13:10] <ogra_> bfiller, updating the initrd by hand should work
[13:10] <asac> pmcgowan: not easily. relying on requests
[13:11] <ogra_> but the device test results wont be reliable in any case
[13:11] <rsalveti> ogra_: did you find out what happened that made the image bigger lately?
[13:11] <pmcgowan> asac, ok then we need 2 approved per bfiller above
[13:11] <nerochiaro> bfiller: i can use the tablet, nexus 10
[13:12] <ogra_> rsalveti, not really ... the latest 2MB come from the addition of libmockdev0 ... which seems to be an added dep ... but there were no huge additions or anything
[13:12] <ogra_> rsalveti, might be it just piled up over time while nobody watched it
[13:12] <rsalveti> right
[13:12] <asac> pmcgowan: closes we had was this: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdDZyRE42M0FQNGF2c1VwakJ1cHo3c0E&usp=drive_web#gid=0
[13:12] <pmcgowan> ogra_, rsalveti yeah I got tired of doing that
[13:12] <asac> pmcgowan: i think bills section wasnt filled out... could be i missed to ping him or he didnt get to it
[13:12] <asac> when i pinged him
[13:12] <asac> so let him fill out his section i guess
[13:12] <pmcgowan> ok cool
[13:13] <asac> pmcgowan: for everyone who filled out we dont have that prob
[13:13] <pmcgowan> ogra_, rsalveti can we put a check somewhere that flags both a larger image and new packages?
[13:13] <pmcgowan> asac, vg
[13:13] <ogra_> asac, we should put that in the release notes btw ... since we technically dont block maguro updates
[13:13] <ogra_> (on devel-proposed)
[13:13] <rsalveti> pmcgowan: I think ogra_ had that in his todo list or some sort of it
[13:13] <asac> ogra_: we dont promote maguro i hope
[13:14] <asac> i thought the build was killed?
[13:14] <ogra_> asac, no, but they can switch channels or some such
[13:15] <asac> ogra_: who can switch channels?and what would be the effect/
[13:15] <ogra_> asac, we do still roll system-images with the old android ... and for it to work we would need at least one android rebuild sepcifically targeting maguro
[13:15] <ogra_> the system-image builds come for free
[13:15] <ogra_> thats why we still left them running while we knew it still worked
[13:16] <asac> ogra_: we shoud really stop doing that
[13:16] <asac> roll images for old android
[13:16] <asac> we are just shipping something broken at best
[13:16] <ogra_> why ? it proves our backwards compatibility
[13:16] <ogra_> i dotn think it is bad ...
[13:16] <asac> we dont test them
[13:17] <asac> we dont know :)
[13:17] <asac> we cant react
[13:17] <ogra_> we get feedback ...
[13:17] <asac> right. so thats causing the confusion above then
[13:17] <asac> e.g. people not gettnig that dont have maguro builds anymore
[13:17] <asac> if we still have them
[13:17] <asac> kind of obvious :)
[13:18] <rsalveti> the android is not the problem, the real issue now is that they can't use SF anymore
[13:18] <asac> there are many things i feel might be interesting; but in practice we have no time/resources to care about this
[13:18] <rsalveti> which was the only way to make it useful
[13:18] <asac> weq should just call it a day and kill them
[13:18] <ogra_> stgraber, ^^^^ can you rip maguro out of system-image imports ?
[13:18] <asac> we have proven we can in theory do backward compatibilty
[13:18] <asac> so maybe next time we do that proper
[13:18] <asac> rsalveti: so what do you think?
[13:19] <rsalveti> yeah, we should stop importing it
[13:19] <asac> stop importing?
[13:19] <rsalveti> same for grouper
[13:19] <ogra_> right
[13:19] <asac> for sure
[13:19] <asac> hell
[13:19] <asac> kill that stuff
[13:19] <ogra_> stgraber, grouper too
[13:19] <asac> i am sure people are still using grouper for dev
[13:19] <ogra_> well
[13:19] <asac> which was the whole rason to kill it so that people would come out of their caves and we can fix that they are using those builds
[13:20] <ogra_> both are still fine for low level stuff
[13:20] <ogra_> as long as you dont rely on Mir ...
[13:20] <ogra_> or any screen stuff
[13:20] <asac> guys that need that
[13:20] <asac> can just assemble stuff on their own
[13:20] <asac> its just misleading
[13:21] <asac> i dont mind if we still  produce the parts
[13:21] <rsalveti> right, just not importing to system-image
[13:21] <asac> but system-image? i just think thats wrong
[13:21] <asac> just kill that
[13:21] <ogra_> right
[13:21] <ogra_> thats why i pinged steev
[13:21] <ogra_> err
[13:21] <ogra_> stgraber,
[13:21] <asac> good
[13:22] <ogra_> tsk
[13:22] <asac> kill maguro and grouper from system-image
[13:22] <asac> then we wont have confusion
[13:22] <asac> and just say in release notes that maguro and grouper are not available anymore
[13:22] <ogra_> right
[13:23] <ogra_> we'll also have to rip them out from cdimage ... but thats for after release ... i wont touch that code now
[13:25] <asac> yeah sounds like not prio
[13:32] <sil2100> boiko: hello!
[13:32] <boiko> hi sil2100!
[13:33] <sil2100> boiko: so, I have a question - I see you were working on the dialer-app crash during tests, right? (something qtubuntu related)
[13:33] <boiko> sil2100: well, now I am not actually working on it, it is more that I am waiting on other fixes
[13:33] <boiko> sil2100: but yes
[13:39] <sil2100> boiko: what I wanted to ask: when does the crash happen exactly?
[13:41] <boiko> sil2100: so, what happens is: the test is making sure incoming calls are working, so we launch the dialer-app (without using upstart)
[13:41] <boiko> sil2100: and then when the snap decision is accepted, telephony-service-approver requests the dialer-app to be activated using URI dispatcher
[13:42] <boiko> sil2100: which in turns use upstart to launch the app, but as there is another instance already running, unity8 rejects this new app instance and then it crashes
[13:42] <boiko> sil2100: so, the test passes because the instance that crashes is not the one being handle by autopilot
[13:44] <sil2100> hmmm
[13:45] <sil2100> Which test was causing this behavior?
[14:00] <sergiusens> mandel: care to review a tiny MR? https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/download_error_message/+merge/216114
[14:00] <mandel> sergiusens, sure, I'm blocked until om26er can get out of a hangout, looking
[14:00] <mandel> sergiusens, rejected ;)
[14:01] <sergiusens> mandel: too small?
[14:01] <sergiusens> :-)
[14:01] <mandel> sergiusens, 500 lines or I wont even look at it hehe
[14:02] <sergiusens> mandel: I have one of those coming up f you want right after Easter; the mms encoder ;-)
[14:03] <mandel> sergiusens, I should not open my mouth.. or type
[14:08] <ogra_> Bug 1240875
[14:18] <boiko> sil2100: oups, just saw you asked about the test. it is test_outgoing_answer_local_hangup
[14:19] <ogra_> boiko, whats the reason to not start the ap via upstart ?
[14:19] <ogra_> thats something that should never happen in real life
[14:19] <ogra_> *the app
[14:20] <sil2100> hmmm
[14:21] <boiko> ogra_: well, I explained that in the mailing list, but it is that at some point the dialer-app is not properly terminated by one of the tests, and the next tests fail
[14:21] <sil2100> boiko: I thought that outgoing means that that we're calling the given number and just waiting for it to pick up
[14:21] <boiko> sil2100: oups, wait, I might have picked the wrong test name, just a sec :)
[14:22] <sil2100> boiko: at least the test says so - we're calling the given number and waiting x seconds for it to answer
[14:22] <sil2100> Ah ;)
[14:22] <sil2100> Since I'm in the middle of figuring out the test_outgoing_answer_local_hangup /(_remote_hangup) failures
[14:22] <boiko> sil2100: yeah you are right, it is the test_incoming one
[14:23] <boiko> sil2100: but they actually might be related, I remember sometimes after running the test_incoming, the system would get in a unusable state and then other tests would fail with crashes and so
[14:26] <boiko> sil2100: I was trying to use the ubuntu-test-cases to reproduce the env, but it was not working here, need to check what is going on
[14:27] <sil2100> boiko: yeah, since what I see from the failures - it looks like in _local_hangup the dialer-app app just simply dies right before the test finishes
[14:28] <sil2100> boiko: that's because it actually fails finding MainView from the last line of the test, while inbetween this line and the previous one checking for MainView nothing happens
[14:28] <sil2100> There's just an assert and a 3 second wait
[14:28] <sil2100> No operations are performed
[14:30] <stgraber> ogra_: ok, so you want me to drop maguro and grouper right?
[14:30] <ogra_> stgraber, yeah
[14:31] <stgraber> ogra_: ok, so they'll entirely disappear from all the trusty channels, is that fine (not just stop importing)?
[14:31] <ogra_> but keep the last maguro build in devel please so people still have something to tinker with ... just dont import new stuff
[14:31] <stgraber> ah, ok
[14:31] <ogra_> we snapshotted 188 for maguro for that back then
[14:31] <stgraber> that may be slightly trickier :)
[14:31] <ogra_> people should use that
[14:31] <ogra_> asac, rsalveti ^^^^opinions ?
[14:32] <ogra_> stgraber, lets hear what the others think
[14:32] <stgraber> ok, so I can remove maguro and grouper entirely from trusty-proposed and all its sub-channels
[14:32] <stgraber> and we can keep it in trusty itself
[14:32] <stgraber> you simply won't be able to copy to it since you won't have any source image
[14:32] <ogra_> roght, proposed is fine in any case
[14:32] <rsalveti> right
[14:33] <rsalveti> for maguro is fine
[14:33] <ogra_> but i'm not sure what to do with trusty/devel
[14:33] <boiko> sil2100: I will spend some more time on that today checking what is going on. it is weird cause this bug only happens in the smoke tests, if I simply autopilot run dialer_app on the device this works
[14:33] <ogra_> since that will become stable and later U
[14:33] <rsalveti> ogra_: when did we last proposed an image for grouper?
[14:33] <ogra_> we currently keep 188 in devel/trusty for maguro
[14:33] <ogra_> 250 i think
[14:33] <ogra_> have to check
[14:34] <rsalveti>             "version": 294
[14:34] <rsalveti> ogra_: ^
[14:34] <ogra_> yeah
[14:34] <rsalveti> so yeah, just cleaning them from trusty-proposed should be fine
[14:34] <sil2100> boiko: same for me sadly, yes
[14:34] <rsalveti> leave them in trusty still
[14:34] <ogra_> rsalveti, that still doesnt give any hint for dvel
[14:34] <ogra_> rsalveti, but that will become U on friday
[14:34] <rsalveti> ogra_: what devel really means?
[14:34] <rsalveti> right
[14:34] <ogra_> which means we should flush it
[14:35] <rsalveti> is it just a link or just imported twice and always imported to devel?
[14:35] <ogra_> and move all stuff we want to keep to stable
[14:35] <rsalveti> right
[14:35] <ogra_> and we dont want to move grouper or maguro
[14:36] <ogra_> so since we will wipe them *at some point* the question is, should we cause more work for stgraber now just to keep them for a few days or wipe them from devel too
[14:36] <asac> stgraber: ogra_: i dont know. preserving the last maguro would be nice i guess, but if there is no way, i doubt it would be critical.
[14:36] <asac> no way with reasaonable effort
[14:36] <ogra_> asac, well, it would have to go to stable
[14:37] <asac> ?
[14:37] <ogra_> devel will point to U
[14:37] <asac> we surely dont want to put it to stable
[14:37] <asac> if we delete it, we delete it :)
[14:37] <asac> hmm
[14:37] <ogra_> devel will change ... thats the point
[14:37] <asac> but stable != trusty
[14:37] <asac> but trusty wont
[14:37] <ogra_> do we want to keep non U images in devel
[14:37] <asac> and stable is not the same as trusty i assuem
[14:37] <ogra_> trusty will be stable with the release
[14:37] <ogra_> or not ?
[14:38] <stgraber> ok, I'm back
[14:38] <asac> i dont know how we planned to do it
[14:38] <ogra_> so trusty/devel images go to the stable channel
[14:38] <stgraber> ok, so what I guess we should do is:
[14:38] <asac> i assumed that a stable promotion would not be done by just moving stable to trusty
[14:38] <stgraber>  - Drop maguro and grouper from trusty-proposed and all aliases, redirects and sub-channels
[14:38] <stgraber>  - Keep them in trusty itself
[14:38] <stgraber>  - Drop them when setting up U
[14:38] <ogra_> asac, no, we copy trusty/devel content to stable
[14:39] <asac> right its a copy, not a link, so we can keep it in trusty, but not promote that to stable
[14:39] <stgraber> which means they'll be in devel only until we open U, then they'll vanish, though they'll still be available if someone then uses stable or trusty
[14:39] <ogra_> stgraber, right, but thats pointless
[14:39] <ogra_> stgraber, if we drop them anyway you can as well drop them now and have a lit less work
[14:39] <stgraber> which may be a problem because we probably don't want them in stable :)
[14:39] <asac> stgraber: so stable should stay on the 13.10
[14:39] <asac> image
[14:39] <ogra_> i want a plan that doesnt make us drop them
[14:39] <asac> and trusty should keep what is currently in there
[14:39] <ogra_> or drop them right now
[14:39] <sil2100> boiko: anyways, thanks for looking into that if anything!
[14:39] <ogra_> half breeded stuff between these two doesnt make any sense
[14:40] <boiko> sil2100: sure, no problems :)
[14:40] <asac> if we only have choice to drop them or promote to stable, we want to drop them
[14:40] <stgraber> ok, well let me kill those two from the -proposed channels at least since we seem to agree on those at least
[14:40] <asac> yeah no new proposed images for them
[14:40] <ogra_> right
[14:40] <asac> then lets talk about what we do tomorrrow with our latest and greatest trusty images and how we make what stable
[14:41] <ogra_> well, trusty should move too stable imho
[14:41] <ogra_> and replace the old stable
[14:41] <ogra_> the point is ... if we want to keep images for grouper and maguro ... where do we do that
[14:42] <ogra_> do we just move them forward to U and have them in devel then ?
[14:42] <ogra_> even though they are not actually U images
[14:42] <asac> maybe we can make a channel called "graveyard" or "rip"?
[14:43] <asac> anyway, lets really talk first how the stable promotion in general willb e done tomorrow
[14:43] <rsalveti> I think stable is not related to the release
[14:43] <ogra_> rsalveti, well
[14:43] <asac> its not related to the release-named channel
[14:43] <ogra_> to what then ?
[14:43] <rsalveti> not necessarily :-)
[14:43] <rsalveti> to what we call stable :-)
[14:43] <asac> its a separate channel where we push builds that we feel are stable enough
[14:44] <ogra_> rsalveti, and will we call the trusty image stable tomorrow ?
[14:44] <ogra_> :)
[14:44] <asac> like cherry picking builds from devel until we have a way to branch out
[14:44] <rsalveti> ogra_: that's up to asac I believe
[14:44] <asac> if upgrade testing goes well, we plan to
[14:44] <ogra_> right
[14:44] <asac> we might send an update with the two main issues
[14:44] <ogra_> thats what i expect
[14:44] <asac> shortly after
[14:44] <ogra_> but the image in trusty will become our new stable
[14:45] <stgraber> ogra_: http://paste.ubuntu.com/7261856/
[14:45] <ogra_> the two dropped arches wont
[14:45] <ogra_> now where do we keep the images for these two arches
[14:45] <asac> ogra_: the images we pick. not all images
[14:45] <ogra_> asac, yes
[14:45] <asac> e.g. pick flo and mako
[14:45] <ogra_> asac, yes
[14:45] <asac> but not grouper and maguro for instance
[14:45] <ogra_> asac, yes
[14:45] <ogra_> that conversation starts becoming easy :P
[14:46] <asac> so in that sense i dont see how keeping the last maguro builds in trusty harms
[14:46] <ogra_> (up key and enter :P )
[14:46] <asac> because thje maguro wont be in stable that way
[14:46] <asac> but ... lets see if thats the truth
[14:46] <ogra_> asac, *where* do we store the images for maguro and grouper
[14:46] <asac> ogra_: why store?
[14:46] <asac> they are in trusty channel
[14:46] <ogra_> asac,  devel should be flushed for the new cycle
[14:46] <asac> cant they just live there?
[14:46] <asac> but trusty is a separate channel that is currently just a symlink
[14:46] <ogra_> so people would explicitly have to say --channel trusty
[14:46] <asac> if we move devel to u, trusty would still exist
[14:46] <asac> right
[14:46] <stgraber> so currently that's not how things work at all, stable is an alias, an alias can't have different devices than the channel it points to
[14:47] <ogra_> while we try to discourage the use of the names
[14:47] <ogra_> s/names/release names/
[14:47] <stgraber> stable currently points to the saucy channel and so has all the same devices as the saucy channel
[14:47] <asac> stgraber: right, but i think stable needs to be independent kind of
[14:47] <asac> stgraber: is that technically not possible?
[14:47] <ogra_> stable would have to become its own channel
[14:47] <asac> so we can cherry pick builds we want to promote to stable from wherever we want
[14:47] <ogra_> not being an alias
[14:47] <asac> right. just its own primary channel
[14:48] <stgraber> sa it is today, no, it's not possible
[14:48] <ogra_> currently its just a link to saucy
[14:48] <stgraber> because of what happens with version numbers when we initialize a new series
[14:48] <stgraber> a new series starts with ID = 1. Aliases are how the device knows that it needs to reset the clock and do a full upgrade.
[14:48] <asac> can we highjack our saucy channel to be our stable channel?
[14:48] <davidcalle> cwayne, ping
[14:48] <asac> and then fix it later?
[14:49] <asac> by adding feature to start channel ID with an offset
[14:49] <ogra_> i suspect we would have to reset the version in stable
[14:49] <ogra_> saucy = v1
[14:49] <ogra_> trusty = v2
[14:49] <asac> well
[14:49] <asac> we could create a fresh stable
[14:49] <asac> copy the saucy build in there
[14:49] <asac> and force an offset
[14:49] <ogra_> thats what i say :)
[14:49] <asac> until we can force an offset we can misuse the saucy channel
[14:49] <asac> ogra_: you left out forcing an offset :)
[14:49] <ogra_> v1 saucy ... in a new stable channel
[14:50] <ogra_> v2 trusty in that same channel
[14:50] <asac> so our current stable image has v1?
[14:50] <ogra_> no
[14:50] <ogra_> we would have to change to that
[14:50] <stgraber> actually we do support setting an offset when creating a channel
[14:50] <ogra_> and people from saucy 101 would get upgraded
[14:50] <asac> cool
[14:50] <asac> stgraber: so we could do it if we wanted in theory?
[14:50] <ogra_> *wouldnt
[14:51] <ogra_> the prob is that we kept the image number for saucy
[14:51] <stgraber> asac: so the main reason to reset the IDs is because of the hashing method used by the client, we have a limited numbers of bits we can use for the version
[14:51] <ogra_> so the next stable has to be greater than 101
[14:51] <stgraber> asac: if we never reset the ID and we hit that limit, we're screwed
[14:51]  * stgraber digs the actual limit from the spec
[14:51] <asac> stgraber: why did we choose an amount of bits that would constrain us ever in time of universe :)?
[14:52] <stgraber> asac: we didn't, python did
[14:52] <asac> we have a byte or what?
[14:52] <stgraber> asac: we're on a 32bit arch, we need to hash two versions together so we have 32bit total hence 16bit for the version number
[14:52] <asac> what is our max build number?
[14:52] <stgraber> so we are technically limited at 65536
[14:53] <asac> ok thats a bit ahead :)
[14:53] <ogra_> just a small bit !
[14:53] <stgraber> if we switch to arm64 by then, then we're good for a long long time
[14:53] <asac> hehe
[14:53] <rsalveti> haha
[14:53] <asac> why didnt we just hash bigger things together
[14:53] <asac> but well
[14:53] <ogra_> even if we switch to arm64 ... i bet the recovery busyboy wont handle bigger numbers still :)
[14:53] <asac> stgraber: so what bout the proposal to misuse the saucy channel and copy our build to that
[14:54] <asac> until we have sorted waht to do with an independent stable cdhannel?
[14:54] <ogra_> (we cant dd imaggges bigger than 2G today because of that)
[14:54] <stgraber> ogra_: it's the ubuntu side doing that, not recovery, so not a problem there :)
[14:54] <asac> and leave stable pointing to saucy?
[14:54] <ogra_> stgraber, yeah, but i'm sure we'd run into recovery issues too
[14:54] <stgraber> asac: it's not very hard to setup stable the right way, so I'd prefer we do that instead of abusing saucy
[14:54] <asac> ok
[14:54] <rsalveti> ogra_: what is the issue with the 2G limitation?
[14:54] <asac> stgraber: right way means: lets do an offset by 101 this time?
[14:55] <ogra_> stgraber, asac, but dont forget that people running stable run image 101 (or 102)
[14:55] <asac> and copy the last saucy in there, and then the new trusty from today/tomorwo?
[14:55] <ogra_> rsalveti, dd ... in recovery busybox cant address bigger stuff
[14:55] <asac> stgraber: or what do you suggest?
[14:55] <rsalveti> ogra_: hm, can't we just fix that?
[14:56] <ogra_> rsalveti, would be nice, not sure though ... might be a bionic limit ... unsigned int etc
[14:56] <rsalveti> not critical I guess
[14:56] <ogra_> right
[14:56] <ogra_> it would be nice for rootstock
[14:56] <stgraber> asac, ogra_: right. 1) Remove current stable channel alias 2) Create a seperate stable channel with all the devices from saucy 3) Copy all the saucy stuff over so it's identical to the alias
[14:56] <ogra_> so you could make images at random size
[14:56] <ogra_> for development thats helpful
[14:56] <stgraber> asac, ogra_: then when we want to start copying trusty stuff over we can just add the devices we care about, drop those we don't anymore and then copy using copy-image
[14:56] <ogra_> stgraber, and regard that trusty 300 needs to become stable 103
[14:57] <ogra_> so that the phoes still pick it up
[14:57] <stgraber> ogra_: no, we'll simply copy whatever trusty version you want over without renumbering, it'll higher than our current saucy one anyway (which is currently 101)
[14:57] <asac> stgraber: awesome!
[14:57] <ogra_> stgraber, ugh
[14:57] <asac> stgraber: sounds like a plan. you think you can pull that off still?
[14:57] <ogra_> so in ten releases we are at image 1113
[14:58] <ogra_> or some such
[14:58] <ogra_> just because we kept artificial gaps
[14:58] <asac> well, if stable is kind of rolling we can still introduce a new hashing algorithm i presume
[14:58] <asac> as long as we dont do that too late :P
[14:58] <ogra_> well, out minimal image number is 102 already
[14:58] <ogra_> with trusty it will be over 300
[14:59] <stgraber> ogra_: well, if you don't care about the version number in stable matching that in the source channel (trusty), we can simply not pass -k to copy-image
[14:59] <stgraber> ogra_: then you'll just get whatever's the next one in the stable channel
[14:59] <ogra_> U might only have 250 builds ... and will have to be up-numbered
[14:59] <ogra_> stgraber, thats what i mean
[14:59] <ogra_> keep the damage low
[15:00] <ogra_> else we grow and grow with big gaps ... just to then count in single steps once we surpassed the version of devel
[15:00] <stgraber> ogra_: ok, so yeah, we can absolutely do that. I can easily have stable start at ID 1, then increment with every copy, which would put us currently around ID 15 with saucy, then just keep incrementing when you copy stuff from trusty
[15:01] <ogra_> stgraber, well, 103
[15:01] <ogra_> not 1
[15:01] <ogra_> because we might have people out there on stable 101
[15:01] <ogra_> or 102
[15:02] <stgraber> ogra_: nope, when I turn an alias to a standard channel, system-image will consider this an alias change, so I can switch to a lower number
[15:02] <ogra_> oh !
[15:02] <ogra_> sweet !
[15:06] <olli_> hey popey, seems like https://bugs.launchpad.net/notes-app/+bug/1288885 is in flight
[15:06] <popey> olli_: yeah, updates in the ppa
[15:06] <popey> olli_: feel free to update and test
[15:07] <olli_> will this also fix the apps wrapped in a shell script?
[15:07] <olli_> i.e. https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1300911
[15:07] <olli_> popey, will try
[15:07] <popey> olli_: well, that bug seems overly wide, all of the core apps having tasks, probably not needed?
[15:07] <popey> be good to focus on the ones that are actually broken
[15:08] <popey> i.e. can you re-test now pls ☻
[15:09] <olli_> popey, there were two issues to be fixed and they are represented by the task (as you asked me to do)
[15:09] <olli_> one fix was to add -qt5 which is handled in 1288885
[15:09] <olli_> the second fix is to add "exec" when there is a shell script, in https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1300911
[15:10] <olli_> popey, I'll test now, but I have a feeling we missed the 2nd bug
[15:10] <popey> and you had a conversation yesterday, and Saviq said add -qt5
[15:10] <popey> I understood 130091 (adding exec) was not wanted
[15:10] <popey> after that conversation
[15:10] <olli_> I don't think that's what we said
[15:10] <olli_> Saviq, ^
[15:10] <olli_> popey, there is just 2 different ways how to start an app
[15:11] <Saviq> popey, that's the only thing we can do for unity8 atm (the exec thing)
[15:11] <olli_> but let me test before getting further down that road
[15:11] <stgraber> ogra_, asac: http://paste.ubuntu.com/7262000/
[15:11] <stgraber> slangasek: ^
[15:11] <Saviq> popey, it will only accept connections from the PID that upstart reports the app started as
[15:11] <Saviq> popey, without exec, qmlscene gets a different PID, and gets rejected
[15:12] <ogra_> stgraber, 3.1 .... dont drop mako :)
[15:12] <ogra_> s/mako/grouper/
[15:12] <asac> stgraber: 3) (LATER) Start moving trusty to stable
[15:12] <asac> stgraber: how much later?
[15:12] <ogra_> tomorrow
[15:12] <asac> from what i read that feels like the step we need to do to release
[15:13] <ogra_> whenever we release#
[15:13] <ogra_> right
[15:13] <stgraber> ogra_: oh yeah, that
[15:13] <ogra_> 3 is the actual relkease
[15:13] <slangasek> stgraber: hi, I don't have context for this pastebin, what's going on?
[15:13] <asac> stgraber: whats the rational for not keeping the old build IDs from the saucy builds? e.g. with an offset?
[15:13] <stgraber> ogra_: http://paste.ubuntu.com/7262013/
[15:13] <ogra_> slangasek, shuffling channels and subarches
[15:14] <genii> Hi guys... does anyone know if there is a Touch image which can work on what is basically a stock Blaze Tablet ( omap4470 )
[15:14] <ogra_> slangasek, like we want to keep images around for unsoupported devices (grouper, maguro) but in an unsupported way
[15:14] <stgraber> asac: we could, but I think it'd just make things more confusing as we start copying over trusty because people would then have build IDs matching for a while (so long as they're on saucy) and then not match anymore
[15:14] <stgraber> asac: I feel it's best not to have them match to begin with to clear any doubt about this
[15:15] <asac> stgraber: but useres currently running 101 from stable would still get an upgrade to 16?
[15:15] <ogra_> yes
[15:15] <asac> if thats the case then i dont mind
[15:15] <ogra_> thanks to the system-image magic
[15:15] <popey> saviq, olli_: ok, my misunderstanding.
[15:15] <stgraber> asac: yep, we have logic that should make that happen. I pinged barry to confirm.
[15:15] <asac> slangasek: 1. we want to release; 2. we have unsupported builds in devel/trusty channel that we dont want to release; 3. we also do not want to remove from trusty channel
[15:16] <slangasek> asac: ok, so this is making the 'stable' channel useful?
[15:16] <asac> and in general we would probably be able to cherrypick or promote builds coming from any channel to stable without having to redirect the alias necessariy
[15:16] <olli_> popey, np, just got to test dropping letters... issue still exists and DL is listed in both apps, i.e. needs both fixes
[15:16] <stgraber> slangasek: basically, asac wants to move from a simple alias from stable to whatever's the current stable release to instead cherry-picking
[15:16] <olli_> popey, how can we help to move that?
[15:16] <popey> olli_: patches welcome
[15:17] <stgraber> slangasek: so stable will potentially have a different set of devices from trusty, will no longer have matching build IDs and will require manual intervention to publish new images
[15:17] <asac> slangasek: we want to surely ship the build we release in stable channel
[15:17] <slangasek> hmm
[15:17] <asac> slangasek: option 1 was to just point stable to trusty, but that also ships our probably broken grouper and maguro unless we wipe them from trusty retroactively (which i agree with gora is probably a bit harsh)
[15:18] <slangasek> I worry that "manual intervention" means it won't happen
[15:18] <ogra_> and gets is in awkward situations with version numbers
[15:18] <asac> slangasek: we have to solve the stable/beta promotion problem anyway
[15:18] <asac> slangasek: thats independent
[15:18] <ogra_> s/is/us/
[15:18] <slangasek> asac: ok
[15:19] <asac> slangasek: its connected to finding the right balance of devel vs. beta/stable cadence
[15:19] <asac> and figuring how we want to do that anyway
[15:19] <asac> slangasek: we should sit together with achiang and colin to sort this out
[15:19] <asac> let me give you a doc
[15:20] <olli_> popey, so out of the list in 1288885 stock ticker, calculator, clock, music and terminal don't work under u8/preview
[15:20] <olli_> popey, I can try to send you patches, but my bzr skills are non-existing, so it might just be a regular diff, hope that works
[15:21] <popey> olli_: do you have a dev who can help me?
[15:21] <popey> if we ask nik90 nicely he may be able to help .. ?
[15:22] <popey> they're one line fixes, but everyone is somewhat bogged down, so if you have a dev who can help submit merges, that would be great, we can shepherd them through jenkins etc
[15:22] <olli_> popey, asking bregma to join here, maybe he can give me a hand
[15:26] <stgraber> ogra_, asac, slangasek: ok, so I've done the -proposed bits and I'll leave the rest alone for now. I've checked with barry and it looks like the client will do the right thing if we choose to proceed, just let me know and it should take me 2-3 hours to implement (and test).
[15:26] <ogra_> stgraber, ok, please plan these 2-3h for tomorrow then
[15:26] <ogra_> assuming we do our release then
[15:26] <asac> stgraber: i feel your plan makes sense; lets give slangasek some more time to think
[15:26] <ogra_> :)
[15:27] <asac> and veto/find issues etc.
[15:27] <slangasek> no time needed here for thinking
[15:27] <ogra_> yeah
[15:27] <slangasek> please go ahead
[15:27]  * ogra_ notes down ... "slangasek ... thinks in no time"
[15:27] <asac> cool
[15:27] <ogra_> :)
[15:27] <asac> stgraber: anything that might be awful if we do it this way?
[15:27] <asac> if you know something please speak up, otherwise go for it :)
[15:28] <asac> and thanks for short notice help
[15:28] <ogra_> well, dont release yet :)
[15:28] <ogra_> keep that for tomorrow
[15:28] <stgraber> asac: not really, that's actually how things are meant to be used, the awful thing is you artificially keeping the build IDs in sync between the other channels :)
[15:28] <ogra_> yeah, but everything else makes testing awful
[15:28] <stgraber> there will be a one time full update for users currently on the stable channel but that shouldn't be many people
[15:29] <asac> stgraber: which channels would we keep the IDs in sync now?
[15:29] <asac> i think its fine to get a full update
[15:29] <asac> the image probably changed massively anywya :)
[15:30] <stgraber> you're still keeping trusty-proposed and trusty in sync and the i386 and armhf livefs in sync but as ogra_ said, that's to make things nicer for QA (though it's starting to be a problem now that we have multiple rootfs which may not build at the same time :))
[15:31] <stgraber> asac: ok, so I'll implement everything except copying trusty today, that way tomorrow you can just do the trusty copy whenever you want
[15:31] <asac> stgraber: you mean copying from trusty to stable?
[15:31] <asac> yeah thats great
[15:33] <stgraber> asac: I mean I'm going to do all of 2) today and we can do 3) tomorrow
[15:33] <asac> stgraber: we also want to drop grouper
[15:33] <asac> in 3.1.
[15:33] <asac> or am i wrong?
[15:34] <ogra_> you look at the wrong paste :)
[15:34] <asac> wait
[15:34] <ogra_> asac, http://paste.ubuntu.com/7262013/
[15:34] <ogra_> he updated it
[15:34] <asac> indeed :)
[15:35] <nik90> olli_, popey: Yeah sure I can do that
[15:36] <olli_> nik90, lovely
[15:37] <olli_> nik90, I am currently looking at dropping-letters atm
[15:38] <olli_> seems like trunk has the fix I am looking for (i.e. dropping-letters.desktop says "Exec=qmlscene -qt5 ..."))
[15:38] <olli_> which according to popey is rev 46, PPA has 44
[15:38] <olli_> which doesn't have the "-qt5" flag
[15:38] <popey> thanks nik90
[15:38] <nik90> hmmm launchpad isn't loading for me...
[15:38] <sil2100> oSoMoN: how's the landing line 21 going?
[15:38] <olli_> nik90, for some context: I am looking at fixing packages listed in https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1300911
[15:40] <nik90> olli_: if you give me the diff, I can propose a MP with that which popey can then approve
[15:40] <popey> mzanetti: have you seen this in the new task switcher - vertical line.. http://popey.com/~alan/phablet/device-2014-04-16-164030.png
[15:41] <mzanetti> popey: yes
[15:41] <olli_> nik90, for dropping-letters we are good with what's in trunk
[15:41] <popey> nik90: so basically we just need an "exec" before the qmlscene calls for those apps which don't start on unity8, right olli_ ?
[15:41] <olli_> popey, if it's in a shell wrapper
[15:41] <popey> mzanetti: got a bug, need one?
[15:42] <nik90> olli_: most of the core apps use the qmlscene shell wrapper (except for reminders, filemanager I thinnk)
[15:42] <olli_> nik90, I'll send diffs and a list of actions via mail to coordinate
[15:42] <mzanetti> popey: don't have one
[15:42] <nik90> olli_: ok
[15:43] <popey> thanks olli_ nik90
[15:57] <stgraber> ogra_: ok, touch i386 added to the tracker and nusakan, so everything should now work fine there
[15:58] <ogra_> merci  !
[15:58] <stgraber> ogra_: next up is the system-image stable channel stuff, preparing that now (may grab some lunch before)
[15:58] <stgraber> while I'm flashing current stable on my mako...
[15:58] <ogra_> :)
[16:00] <mhall119> cjwatson: ping re: shared libraries in click packages
[16:02] <cjwatson> mhall119: is it release-critical?
[16:05] <mhall119> cjwatson: nope, so if you're busy with release stuff it can wait
[16:05] <mhall119> cjwatson: would you prefer an email?
[16:05] <cjwatson> mhall119: yeah, could use not being distracted at the moment, if it could wait till after release that'd be good
[16:05] <cjwatson> mhall119: e-mail would be fine
[16:24] <asac> mandel: did we find out why we see 13.10 when we upgrade from saucy image to latest devel?
[16:24] <asac> where this info is coming from?
[16:24] <asac> (sorry if the answer is in mail)
[16:42] <asac> seb128: did you see iftikhar
[16:43] <asac> seb128: can you check this one: http://paste.ubuntu.com/7262498/
[16:43] <asac> seb128: its also in your inbox
[16:43] <asac> seb128: the two system setting ones
[16:43] <seb128> asac, the email stating that language and whoopsie preferences are lost on upgrade?
[16:43] <seb128> asac, yeah, saw that
[16:43] <asac> seb128: yeah. dont think its critical
[16:44] <seb128> no, it's not
[16:44] <asac> but if its trivial, we could do it still
[16:44] <seb128> and it's not a settings problem
[16:44] <asac> seb128: so who would own it?
[16:44] <seb128> the settings are only an app to drive backends
[16:44] <seb128> well, locale is a file on disk
[16:44] <seb128> who should own user file vanish on upgrade?
[16:45] <seb128> same for whoopsie ... maybe ev in case the whoopsie configuration format/storage changed?
[16:45] <ev> the configuration format has remained the same for some time: /etc/default/whoopsie
[16:45] <ev> it's been that since 12.04 if memory serves
[16:46] <seb128> ev: is that the configuration that is edited when you use the UI?
[16:46] <ev> yes
[16:46] <seb128> on the touch image
[16:46] <ev> not directly though
[16:46] <ev> it talks to a dbus service which edits it
[16:46] <seb128> asac, is iftikhar doing IRC?
[16:46] <asac> seb128: yes iahmad
[16:46] <asac> iahmad: :)
[16:46] <seb128> ev: that email states that the config value change when upgrading from saucy touch to trusty
[16:47] <seb128> iahmad, hey
[16:47] <asac> seb128: he is far eaast though ... so not sure if he is still on
[16:47] <asac> pakistan iirc
[16:47] <seb128> is there any way you could get the value of ~/.pam_environment and /etc/default/whoopsie before and after upgrade
[16:47] <seb128> asac, ok, if he doesn't reply I'm going to follow up on the email
[16:52] <ev> seb128: which mail this this?
[16:52] <ev> is this*
[16:53] <seb128> ev: http://paste.ubuntu.com/7262498/
[16:54] <daker> popey: can you link me your click packages mirror ?
[16:54] <tedg> alecu, Where to do bugs for com.ubuntu.developer.alexandre-abreu.content-hub-html5-exporter_content-hub-html5-exporter_0.1 go? bug 1294103
[16:54] <ev> seb128: yeah, knowing the value of /etc/default/whoopsie before and after upgrade would help. It could be that the dbus service died (or is wedged) and so the UI doesn't know what to set the default state of the button to.
[16:55] <ev> so thanks for following up and requesting that
[16:55] <ev> please do CC me if you'd like
[16:55] <seb128> ev: yw!
[16:55] <seb128> ev: ok, let's see what in the reply about the file content before/after update
[16:55]  * ev nods
[16:56] <alecu> tedg: sorry, don't know about that
[16:57] <popey> daker: it's offline, on my pc - what do you need?
[16:57] <tedg> alecu, Sorry, wrong guy :-)
[16:57] <tedg> alex_abreu,  Where to do bugs for com.ubuntu.developer.alexandre-abreu.content-hub-html5-exporter_content-hub-html5-exporter_0.1 go? bug 1294103
[16:58] <alecu> no prob :-)
[16:59] <stgraber> ogra_: I have turned off the cron job on nusakan as I'm working on the stable channel, please don't do any manual action over there until I'm done, thanks!
[16:59] <daker> popey: don't worry i just have to plug the phone and look directly into the click files :)
[16:59] <ogra_> stgraber, ok, i just promoted 299 to devel though ...
[17:00] <ogra_> (just FYI)
[17:00] <stgraber> ogra_: ok, well if you did that after I started, it won't appear on the public server for a little while, publishing is disabled
[17:00] <ogra_> well, i see it
[17:01] <ogra_> so we should be fine
[17:01] <ogra_> (in the devel channel)
[17:01] <popey> i see it too
[17:01] <stgraber> yeah, looks like you did that right before I turned off publishing then :)
[17:01] <ogra_> timing ... :)
[17:02] <sergiusens> mandel: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/space-errors/+merge/216154
[17:03] <alex_abreu> tedg, mmmh this is not an official app, is it?
[17:04] <tedg> alex-abreu, Heh, don't ask me, it just has your name in the appid so I asked you ;-)
[17:05] <alex-abreu> tedg, yeah :) but it was meant to be an example for a click app .. it has never been uploaded to the store (not by me at least :) ) ...
[17:05] <alex-abreu> tedg, but anyway ... in unity-webapps-qml https://bugs.launchpad.net/unity-webapps-qml
[17:06] <tedg> alex-abreu, K, I'll move it over there and mark it invalid. That way it's documented.
[17:14] <stgraber> ogra_: http://system-image.ubuntu.com/ubuntu-touch/stable/grouper/ updated
[17:14] <stgraber> ogra_: however I need to add a small trick to get existing devices to upgrade, doing the change here, should be in production within the hour (will be a temporary change we can drop in ay 2-3 months when everyone is expected to have run at least on upgrade)
[17:16] <ogra_> stgraber, fine with me
[17:16] <mandel> sergiusens, on it
[17:23] <sergiusens> mandel: added a comment on how to trigger the failure if your smarts fail ;-)
[17:25] <mhall119> ogra_: stgraber: I don't see r299 available on my phone, should I?
[17:25] <ogra_> yes
[17:25] <mhall119> I'm on 296, and it says I'm up to date
[17:25] <mhall119> on mako
[17:25] <mandel> sergiusens, small needs info
[17:25] <daker> we are already on 300
[17:25] <ogra_> da"we" ?
[17:26] <ogra_> daker, "we" ?
[17:26] <ogra_> proposed is
[17:26] <kenvandine> bfiller_afk, bug 1308653
[17:26] <ogra_> thats the brave guys ...
[17:26] <mhall119> daker: maybe on -proposed :-P
[17:26] <kenvandine> bfiller_afk, wish list :)
[17:26] <daker> ogra_: -proposed
[17:26] <mhall119> ogra_: even system-image-cli says I'm up to date
[17:26] <ogra_> mhall119, well, i definitely see it on the server and all index files are up to date listing it
[17:27] <ogra_> mhall119, your phone just doesnt like you i guess :P
[17:27] <mhall119> ogra_: http://system-image.ubuntu.com/ubuntu-touch/devel/mako/ doesn't show 299, not for me anyway
[17:28] <stgraber> so we may not have been great at timing after all :)
[17:28] <ogra_> mhall119, hmm, probably the syncing issue that stgraber maentioned above
[17:28] <sergiusens> mandel: I don't really need to, but ok ;-)
[17:28] <ogra_> stgraber, it was there
[17:28] <ogra_> stgraber, i swear
[17:28]  * ogra_ goes upstairs to check his desktop ... got the page still open there 
[17:28] <stgraber> ogra_: it may actually have been dropped entirely from system-image as I had to restore backups a couple of times, possibly while you were publishing, just took a while for system-image to catch up
[17:28] <stgraber> ogra_: we'll have to re-promote probably
[17:29] <balloons> seb128, I'm re-doing the upgrade from stable to devel.. what files are you interested in besides whoopsie and locale?
[17:29] <ogra_> stgraber, well, doe it use a similar round robin sync mechanism cdimage has  ?
[17:30] <mandel> sergiusens, that is why I added the needs info :)
[17:30] <mandel> sergiusens, you might want to at least log it, you never know..
[17:30] <ogra_> stgraber, on cdimage i often enough have the image shown and vanishing for like 10min when reloading because the backend server round-robins
[17:30] <ogra_> stgraber, sitting on my desktop now, i got the  inhttp://system-image.ubuntu.com/ubuntu-touch/trusty/manta/ front of me and see 299 in there
[17:31]  * ogra_ is brave and reloads
[17:31] <ogra_> and its gone :(
[17:31] <seb128> balloons, those should be enough
[17:35] <stgraber> ogra_: ok, so I think I've got stable sorted out here, my mako is now upgrading.
[17:35] <ogra_> cool
[17:35] <sergiusens> mandel: ok, pushed some sugar coating
[17:36] <stgraber> ogra_: feel free to re-promote 299 now, I won't need to revert the www tree again
[17:37] <ogra_> ok
[17:37] <mandel> sergiusens, sugar coating is nice :)
[17:38] <ogra_> mhall119, enjoy
[17:39]  * mhall119 downloads before stgraber can kill it again :)
[17:39] <ogra_> haha
[17:40] <mhall119> maybe....stuck at 0%
[17:40] <pmcgowan> ogra_, what is the intention for stable? who is that for as it will never be as good as the latest proposed?
[17:40] <ogra_> stgraber, oh.while you're at it, generic_x86 could need some version syncing
[17:41] <ogra_> pmcgowan, a non moving snapshot you can safely develop and test your apps on ?
[17:41] <pmcgowan> if it met some completion criteria I would agree, but perhaps we are just too early to have it be meaningful
[17:42] <stgraber> ogra_: ok, I'll do some bumping in trusty-proposed then, please don't use copy-image while I do that as I need to hack the code locally for that kind of trick :)
[17:42] <pmcgowan> ogra_, if it was maintained with updates I think it would have value
[17:42] <pmcgowan> but its not at this point
[17:42] <ogra_> pmcgowan, well, there will be an ubuntu release announced ... and press will look for testing phone progress too
[17:43] <ogra_> stgraber, i wont touch anything there anymore today :)
[17:43] <pmcgowan> thats part of the issue, devel will always be better for evaluation
[17:43] <ogra_> pmcgowan, sure
[17:43] <ogra_> but we had stable with the last release already
[17:43] <pmcgowan> yeah I never upderstood that either
[17:44] <pmcgowan> seemed to confuse people, why they didnt see the new stuff
[17:44] <stgraber> ogra_: so copy 297 as 300 right?
[17:44] <ogra_> yep
[17:45] <mandel> sergiusens, you need to take a look at https://code.launchpad.net/~sergiusens/nuntium/decode-cli-writes/+merge/215786 too
[17:45] <mhall119> bfiller_afk: is contact syncing working? I don't seem to have anything coming in
[17:46] <stgraber> ogra_: done
[17:46] <ogra_> pmcgowan, well, eventually i would expexct us to actually use stable regulary ...
[17:46] <sergiusens> mandel: yeah, already made my comments on that one over irc :-P
[17:46] <ogra_> once we actually are stable and feature complete
[17:46] <mandel> sergiusens, buuuu add them in the mp
[17:47] <mandel> sergiusens, mainly so that people know it :)
[17:47] <ogra_> pmcgowan,  i dont think it does any harm to already have it and test upgrades from stable to stable etc etc
[17:48] <sergiusens> mandel: I can't multitask, I'm blocked waiting for your approval on another MR ;)
[17:48] <pmcgowan> ogra_, agreed that part is valuable looking forward
[17:50] <mandel> sergiusens, which mr?
[17:50] <mandel> sergiusens, have I missed one?
[17:50] <sergiusens> mandel: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/space-errors/+merge/216154
[17:50] <sergiusens> mandel: still says needs information ;-)
[17:50] <sergiusens> not sure why :-P
[17:51] <mandel> sergiusens, done
[18:06] <mhall119> is there a way for an app to tell the OSK not to use predictive/corrective helpers?
[18:07] <pmcgowan> mhall119, yes there is a hint to set
[18:07] <pmcgowan> on the textfield
[18:08] <ogra_> we should set it for the terminal app
[18:08] <ogra_> so it doesnt print your sudo password (or ssh) inverse on the screen :)
[18:11] <pmcgowan> mhall119, ogra_ wonder if the default is backwards, do you usually want it or not
[18:11] <pmcgowan> I find it in the way a lot
[18:12] <ogra_> i like having suggestions ... i dont like having them applied automatic in any form
[18:12] <ogra_> (not even the "line starts capitalized" one)
[18:19] <mhall119> pmcgowan: ogra_: it looks like for the terminal we have to do it in the C++ plugin
[18:20] <ogra_> well, probably people want it ... we should just make sure that password prompt input gets respected
[18:20] <ogra_> and not printed ...
[18:22] <mhall119> I don't think anybody wants it for terminal
[18:23] <ogra_> depends o the suggestions
[18:23] <mhall119> it breaks double-tap tab completion
[18:23] <ogra_> double-tap tab completion ??
[18:23]  * ogra_ checks 
[18:23] <mhall119> did you not know about this?
[18:23] <ogra_> wow !
[18:23] <ogra_> no
[18:24] <ogra_> thats extremely cool !
[18:24] <mhall119> it is, until the helpful keyboard breaks it
[18:26] <stgraber> ogra_, asac, slangasek: confirmed that the stable channel is now a separate manually managed channel, renumbering was done and I confirmed a mako on stable 101 upgraded to stable 10 succesfuly
[18:26] <slangasek> stgraber: cheers
[18:27] <stgraber> (well, not really upgraded since they are technically the exact same issue, but whatever, it thought it did an upgrade :))
[18:27]  * ogra_ hugs stgraber 
[18:49] <daker> 6 months later and the camera button is still disable, i can't record videos :(
[18:49] <daker> disabled*
[18:51] <asac> stgraber: is there a way we could get tomorrow QA do a final validationm run of doing that upgrade?
[18:51] <stgraber> asac: probably not since the old stable channel no longer exists. If they have a device around that's on stable at build 101, then yes they can
[18:52] <stgraber> when we're resetting a channel, it's kinda hard to do QA on that after the fact
[18:54] <asac> ok
[18:55] <asac> stgraber: we kind of have the old stable still in form of saucy though, right?
[18:55] <asac> so might be as simple as install saucy, hacmk config to spoof that it was coming from stable
[18:55] <asac> and upgrade?
[18:55] <stgraber> sure, you can do that, except that the result will be pointless
[18:55] <asac> really? :)
[18:55] <stgraber> because that's upgrading from one channel to another which we know works properly
[18:56] <asac> must be at least half a point to it :P
[18:56] <asac> lol
[18:56] <stgraber> the tricky part is upgrading from a channel to itself with a lower version
[18:56] <stgraber> which is a completely different code path
[18:56] <stgraber> (and one that required me to make two server side changes to get right)
[18:57] <asac> stgraber: ok, you feel confident that we have covered our backs enough? If so, i guess just stay around tomorrow and lets hope for best
[18:58] <stgraber> asac: I have unit tests on the server side code and I did the end to end testing on an entirely wiped mako here, running the upgrade in debug mode to make sure everything went right, so I'm pretty sure it's good
[19:05] <sergiusens> stgraber or ogra_ https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/channels/+merge/216195
[19:06] <sergiusens> please :-)
[19:07] <ogra_> done
[19:10] <sergiusens> ogra_: links made me forget :-/
[19:22] <mhall119> olli_: https://code.launchpad.net/~ories/ubuntu-terminal-app/unity8_preview_fix/+merge/216171 needs a commit message to land
[19:50] <mhall119> bzoltan: http://pastebin.ubuntu.com/7263391/ I'm getting this now trying to build Trojita for armhf, it was working before but today I had to add a "Kit" and it won't build it anymore
[19:51] <elopio> tedg: ping
[19:51] <elopio> Qt.openUrlExternally("settings:///system/online-accounts") will call url-dispatcher through dbus?
[19:51] <tedg> elopio, On touch, yes.
[19:52] <elopio> tedg: what will happen on desktop?
[19:52] <tedg> elopio, It'll call xdg-open and probably nothing good will happen :-)
[19:53] <elopio> tedg: ok, so the 'nothing good' I'm seeing is expected :)
[19:53] <elopio> thanks.
[19:54] <tedg> Heh, yes, just the expected amount of evil. Nothing more, nothing less. :-)
[20:13] <dobey> tedg: https://www.youtube.com/watch?v=F6X9KcrXHwg
[20:14] <tedg> heh
[20:22] <kyleN> Hi. I noticed the .zip file for the flo device is not present on cdimages, yet it is for the other device types. And the touch/install wiki says you need the zip file. http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/
[20:22] <kyleN> anyone know why?
[20:22] <dobey> no idea
[20:22] <dobey> but 2014/04/16 16:22:37 Device grouper not found on server https://system-image.ubuntu.com channel trusty-proposed
[20:23] <dobey> :(
[20:23] <kyleN> dobey, is that because grouper is no longer a target device?
[20:23] <dobey> and trying to flash just trusty instead of -proposed is giving me image 294
[20:23] <dobey> kyleN: i doubt it. it worked fine yesterday when i flashed
[20:23] <kyleN> hmm
[20:24] <dobey> and flashing just trusty works, but it's only 294, not 299
[20:27] <kyleN> pmcgowan, do you know who can straighten out these two questions?
[20:27] <ogra_> dobey, yes, it was finally dropped
[20:28] <dobey> ogra_: then why does --channel trusty work?
[20:28] <dobey> sigh :(
[20:28] <ogra_> kyleN, we dont produce zips since we switched to android 4.4 quite a while ago
[20:29] <pmcgowan> kyleN, grouper and maguro officially met their demise
[20:29] <ogra_> dobey, thats the very last image ... we didnt want to drop it without keeping at least one image around ... same for maguro
[20:29] <kyleN> thx guys
[20:30] <dobey> well fml
[20:30] <ogra_> grouper is at 250 iirc and magureo at 188
[20:30] <dobey> time to flash it back to android i guesa and resotre it to original nexus status, and hopefully sell it for at least half what i paid for it :(
[20:31] <ogra_> well, have your manager get you a flo
[20:31] <dobey> no, grouper is at 294 on "trusty" anyway
[20:31] <ogra_> ah
[20:31] <ogra_> i forgot when i promoted the last one
[20:31] <dobey> irony is that flo wasn't supported when i got the n7
[20:31] <mhall119> does grouper 294 work well with mir, or does it still need surfaceflinger?
[20:31] <ogra_> yeah
[20:32] <dobey> so i bought a flo, and couldn't flash it, so i had to return it and buy a grouper :(
[20:32] <ogra_> mhall119, if it would, it wouldnt work :)
[20:32] <ogra_> mhall119, SF support got dropped completely a while ago
[20:32] <mhall119> hmmm, last time I had it on my grouper with mir it had that annoying flashing bug that made it unusable
[20:32] <ogra_> that was fixed
[20:33] <dobey> that was a long time ago
[20:33] <ogra_> Mir should "work"
[20:33] <mhall119> ah, cool, will flash again to 294 before my release party
[20:33] <dobey> it "works" on grouper
[20:33] <ogra_> nit actually performant but "work"
[20:33] <dobey> some things just freeze quite often
[20:33] <mhall119> everything in grouper has scare-quotes around it, I know
[20:33] <ogra_> :)
[20:33] <kyleN> ogra_, the touch/install wiki section on manual install says you need the zip. Since we don't need it, it is correct to say all you need to do is fastboot flash the three image files and reboot?
[20:33] <ogra_> use flo :)
[20:33] <kyleN> https://wiki.ubuntu.com/Touch/Install
[20:33] <mhall119> which is a shame, because Android runs pretty well on that hardware
[20:33] <mhall119> ogra_: you going to send me one?
[20:34] <dobey> ogra_: which we'll also stop supporting in another 6 months, i'm sure :(
[20:34] <ogra_> kyleN, yeah, manual doesnt really work anymore ... we need to replace that bit ... nobody had time to work out something new
[20:34] <daker> mardy: hey i am trying to add a facebook account, i am getting this :( http://i.imgur.com/2StMCGe.png
[20:34] <mhall119> dobey: a lot can change in 6 months, look where we were in October
[20:34] <ogra_> dobey, depends ...
[20:34] <kyleN> ogra, I am replacing it now if it has value. does it?
[20:34] <dobey> mhall119: my workstation has been running just fine for over 2 years :)
[20:35] <ogra_> kyleN, well, my rootstock-ng instructions from the mailing list should essentially replace it
[20:35] <mhall119> dobey: we can fix that
[20:35] <ogra_> i think thats the baes in the direction of a manual install we can offer still
[20:35] <kyleN> ogra seems then like it is outdated and not needed
[20:35] <ogra_> *best
[20:35] <kyleN> (why bother with a manual install...)
[20:36] <ogra_> people doing image development might want to
[20:36] <ogra_> and porters
[20:36] <ogra_> i'll try to find some time tomorrow and work out a proper manual section
[20:36] <kyleN> ok, thanks ogra
[20:37] <ogra_> np, thanks for pointing it out, i had forgotten abou it
[20:37] <dobey> mhall119: i'm sure the kids dying in africa from lead poisoning from disassembling electronis for "recycling" will love you for it :)
[20:37] <mhall119> well, that escalated quickly
[20:39] <dobey> it's too bad all the phone makers seem to have decided to become laptop makers instead, all at the same time
[20:40] <canarias> i just heard about ubuntu for android today, is it out yet? im dying to test it. seems so superior
[20:40] <popey> nope
[20:41] <canarias> only first stage tests
[20:41] <canarias> any eta on when a stable release will be available for download?
[20:42] <ogra_> ubuntu for android would have to be released by a phone manufacturer ... it requires deep changes in android
[20:42] <ogra_> and i doubt any such thing will happen in the near future
[20:43] <canarias> can always flash the phone myself like u do with a rooted device
[20:44] <ogra_> meanwhile you could install Ubuntu for Phones though ... if you have a nexus device ... or wait for teeh second half of the year where actual phones with ubuntu preinstalled will be released
[20:44] <ogra_> but ubuntu for android requires vendor partnership that doesnt exist atm yet
[20:53] <mhall119> dobey: phones are laptops, laptops are phones...if only *somebody* had one OS that would work on both!
[20:55] <Beldar> oh......the irony
[21:00] <dobey> mhall119: if only manufactures didn't make phones the same size as my laptop
[21:02] <mhall119> dobey: I'm right with you, The Galaxy Note 3 has almost the same screen size as my first netbook :(
[21:03] <mhall119> in actual size, not pixels, in pixels is like 4x or higher
[21:03] <dobey> the nexus 5 actually looks really nice, it's just 1.5" too big
[21:04] <mhall119> how big is it? I find the Nexus 4 just a tiny bit too big at the corners
[21:04] <mhall119> everything else I can reach with my thumb one-handed
[21:04] <mhall119> the Edge prototype felt perfect, IMO
[21:05] <dobey> n5 is bigger than the n4
[21:05] <dobey> it has a 5" screen after all
[21:46] <ubuntuPuzzler> Is anyone here???
[21:47] <ubuntuPuzzler> Hello??!?!??!?!?!!?!?!?!?!?
[22:20] <olli_> mhall119, how do I fix it
[22:24] <olli_> mhall119, popey, nik90 fixed
[22:25] <olli_> ^commit msgs that is
[23:32] <doflah> after updating r250 -> r294, System Settings crashes when checking for updates.  I have the same problem with r296 and r299