[05:01] <Mirv> mhall119: pong
[06:53] <Xavier> hHello
[06:53] <Xavier> I have an issue with my Nexus 4 and Unbuntu Trusty channel (104)
[06:53] <Xavier> can you help me ? i don't know how activate the Wifi. It's seem not working
[06:57] <RAOF> Xavier: Do you really mean image 104?
[06:58] <RAOF> Xavier: Also, wifi troubles are likely to be a mismatch between underlying android version and Touch; at one point you needed to flash touch over android 4.3 in order to get working radios, but I thought that got fixed. But it would have been fixed in image ~200ish.
[07:02] <Xavier> My device is Nexus4 (LG) with Android 4.4.2
[07:03] <Xavier> Select channel to install >>> trusty
[07:03] <Xavier> maybe not (104) (was from memory). i re-install it and will say
[07:06] <RAOF> Xavier: Hm. You might need to try flashing to Android 4.3 before flashing Touch. I thought that was resolved, though.
[07:07] <Xavier> i need to come back the version of android ?
[07:08] <Xavier> i don't know how.. (i'm just a "power" user, not dev). the dual boot was installed by a technical architect of ubuntu on the booth of ubuntu at mobile world congress
[07:09] <Xavier> i think it was working. and the i try to uninstall (from android) and re-install (just to try by myself with exactly the same manipulations) and doesn't work...
[07:10] <Xavier> maybe i need to have not the trusty version... but the more recently. wich one you recommand me to try ?
[07:20] <RAOF> Xavier: Ah, you're using the dual-boot thingy.
[07:20] <Xavier> yes
[07:20] <RAOF> Xavier: Sorry, I don't have experience with that bit.
[07:20] <Xavier> :-( sadly for me...
[07:20] <RAOF> But if you hang around in here someone will :)
[09:05] <Xavier> Hi guys (again). With Nexus4 (dualboot) i can't connect my phone to the wifi. Ubuntu seems not enable to activate the wifi-chipset.It found no networks... i'm on the last trusty. Any idea ?
[09:36] <JamesTait> Good morning all; happy Monday, and happy What if Cats & Dogs Had Opposable Thumbs Day! :-D
[10:05] <ogra_> xnox, sisne you fiddled with the py3 port of the ofono scripts as well, is either of these something that rings a bell for you ? https://jenkins.qa.ubuntu.com/job/trusty-touch-flo-smoke-daily/19/artifact/clientlogs/dialer_app/_usr_share_ofono_scripts_list-modems.0.crash/*view*/ https://jenkins.qa.ubuntu.com/job/trusty-touch-flo-smoke-daily/19/artifact/clientlogs/dialer_app/_usr_share_ofono_scripts_enable-modem.0.crash/*view*/
[10:06] <ogra_> they happen on every test (ofono-phonesim is installed before testing though, might have something to do with this)
[10:06] <ogra_> started with the switch to py3 on the infrastructure
[10:07] <ogra_> (apparentlyx it is not locally reproducable... at least not easily)
[10:08] <xnox> ogra_: i saw that with stock ofono, from before trying to port it to python3...
[10:09] <xnox> ogra_: and there is no python in ofono dbus service. the error says no ofono running / present on the system bus...
[10:10] <xnox> either ofnod was not started, or it crashed, or the "manual" was not over-overridden.
[10:11] <xnox> ogra_: it would be nice to see syslog for that job.
[10:16] <ogra_> yeah
[10:16] <ogra_> psivaa, ^^^ is that possible ?
[10:17] <psivaa> ogra_: 1 sec
[10:18] <ogra_> any syslog for any test run should eb fine ... they all expose it
[10:18] <ogra_> *be
[10:25] <psivaa> ogra_: xnox: this is from a mako device: http://pastebin.ubuntu.com/7026722/
[10:25] <psivaa> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/110/artifact/clientlogs/dialer_app/_usr_share_ofono_scripts_dial-number.32011.crash/*view*/ is the crash.
[10:25] <psivaa> i guess both are similar. let me know if you need the log from flo
[10:28] <xnox> psivaa: browsing through it, looks like notes app is buggy? it's constantly denied to create ~/.local/share/notes-app shouldn't it be using a directory based on it's app-id?
[10:28] <xnox> ditto filemanager is getting loads of denies.
[10:29] <ogra_> ofono looks fine though
[10:29] <ogra_> the messages are not any different to my mako that still runs image 194
[10:29] <ogra_> (and works fine)
[10:30] <xnox> ogra_: why does ofono look fine to you? It's started 38 times... shouldn't it turn on and be left running the whole time?
[10:30] <ogra_> xnox, not if the system reboots
[10:30] <psivaa> xnox: those denials don't appear to cause the test results. i'm not sure the  other impacts. i have not written the tests :)
[10:32] <xnox> psivaa: i mean, our apps under normal operations shouldn't be denied things. I trust our security-team more, thus I'd be inclined that our apps try to do something naughty, which is ok on the desktop, but not ok on the phone.
[10:32] <ogra_> they are most likely just missing an apparmor entry
[10:32] <xnox> psivaa: thus, if on the desktop ~/.local/share/notes-app is used, but on the phone it's ~/.local/share/com.ubuntu.notes_app then our convergence will fall apart =)
[10:33] <xnox> ogra_: i thought click apps are only allowed ~/.local/share/${APP_ID} ?!
[10:33] <ogra_> yes, they should be
[10:34] <ogra_> anyway
[10:34] <xnox> ogra_: ok, so notes-app is wrong trying to do things to things outside of it's app_id.
[10:34] <xnox> ogra_: yeah, anyway.
[10:34] <ogra_> i dont see anything unusual wrt ofono in the syslog
[10:34] <xnox> ogra_: phone is rebooted 31 times, yet ofono is brought up 38 times.
[10:35] <xnox> or it's incomplete syslog....
[10:35] <ogra_> i only see it being started 6 times
[10:35] <ogra_> where do you see 38 ?
[10:36] <ogra_> ogra@styx:~/Devel$ grep -c "oFono version" ofono-syslog.txt
[10:36] <ogra_> 6
[10:36] <xnox> i grep for "oFono version 1.12" in http://pastebin.ubuntu.com/7026722/
[10:36] <xnox> and that gives me 38 hits.
[10:37] <ogra_> oh
[10:37] <xnox> yet there are only 31 reboot, by my count....
[10:37] <ogra_> ogra@styx:~/Devel$ wc -l ofono-syslog.txt
[10:37] <ogra_> 8122 ofono-syslog.txt
[10:38] <ogra_> yeah, my copy paste is mangled
[10:38] <ogra_> i guess the other restarts come from ofono-phonesim tearing down the fake modem during testing
[10:40] <ogra_> since people do not see the issue in local testing and you usually dont have ofono-phonesim installed i suspect it needs some changes for the new py3 stuff
[10:41] <xnox> ogra_: ofono-phonesim doesn't use any py3 stuff.... and i see same errors with "py2 stuff"....
[10:41] <xnox> ogra_: ofonod is not published on the dbus and we need to figure out why.
[10:41] <ogra_> well, doesnt it provide a fake dbus service ?
[10:42] <ogra_> i thought that is what it does ...
[10:43] <xnox> phonesim? it starts normal ofnod with a dummy provider.... and it's a compiled binary no python at all....
[10:43] <xnox> and publishes itself to dbus using qt4-dbus by the looks of things.
[10:44] <ogra_> aha
[10:44] <ogra_> http://paste.ubuntu.com/7026834/
[10:44] <ogra_> see that
[10:44] <xnox> the only thing we ported is scripts from py2 to py3... and i have seen same dbus errors with either when i was locally testing.
[10:44] <ogra_> it calls /usr/share/ofono/scripts/list-modems
[10:45] <xnox> ogra_: do we have the /var/log/upstart/ofono-phonesim-autostart.log anywhere?
[10:46] <jussi> Seems I have no sound at all on my mako device.
[10:46] <ogra_> xnox, ask psivaa
[10:46] <xnox> (from/during dialer-app tests)
[10:46] <xnox> psivaa: can we get /var/log/upstart/ofono-phonesim-autostart.log from after dialer-app tests have run?
[10:46] <psivaa> xnox: 1 sec, let me see pls
[10:46] <ogra_> xnox, if the list-modem script need a runnning ofono i can imagine whats wrong here
[10:46] <jussi> Just installed yesterday with latest trusty
[10:46] <xnox> ogra_: why?
[10:46] <ogra_> xnox, ofono starts "on started dbus" ...
[10:47] <ogra_> the ofono-phonesim autostart starts "on runlevel ..."
[10:47] <xnox> ogra_: it's a post-start script....
[10:47] <xnox> ogra_: ofono-phonesim is on manual by default, overriden on touch, thus it doesn't start at all.
[10:47] <ogra_> what puts it to manual ?
[10:48] <xnox> ogra_: thus one needs to manually do $ start ofono-phonesim... (e.g. i suppose test do?!)
[10:48] <xnox> ogra_: and by that time there is dbus running.
[10:48] <ogra_> again, what puts it to manual ?
[10:48] <ogra_> i dont see that in the package
[10:48] <xnox> ogra_: also dbus is available by the time runlevel 2 is emitted.
[10:50] <ogra_> right, i still dont get why you say it is on manual
[10:51] <ogra_> what i see though is debian/local/with-ofono-phonesim
[10:51] <ogra_> which is called by the upstart job it seems ... and fiddles with dbus
[10:52] <ogra_> andf which stops and starts ofono :)
[10:52] <ogra_> there you got your extra restarts
[10:52] <psivaa> xnox: http://pastebin.ubuntu.com/7026862/ is /var/log/ofnono-phonesim.log, there is no ofnon-phonesim-autostart.log file under /var/log/upstart/
[10:53] <ogra_> yeah, that seems to be created by that script
[10:54] <ogra_> there we go ... full of dbus issues
[10:57] <xnox> psivaa: ogra_: right that's fine, cause it starts ofono-phonesim within 3 iterations, and time-out is after 10 iterations.
[10:57] <xnox> psivaa: ogra_: i guess it's better for it to redirect those messages to /dev/null. Since it knows it will take /some/ iterations to bring up ofono-phonesim in post-start.
[10:58] <xnox> psivaa: ogra_: those messages are harmless. What's the actual errors you are hunting for here?
[10:58] <ogra_> xnox, about 12087245 .crash files per test run that we get since the new ofono package landed
[10:59] <ogra_> we have to revert to the py2 versionn until this is fixed
[10:59] <xnox> ogra_: https://launchpad.net/bugs/12087245 something lost?
[10:59] <xnox> ogra_: can i see the crash file? and or correct bug number?
[10:59] <ogra_> (unless we fix thebug before building the next image)
[11:00] <ogra_> my initial ping had two crash files
[11:00] <ogra_> they are always the same ones
[11:01] <xnox> ogra_: well, whoopsie is too good here. It's normal for python scripts to throw exceptions and thus exit....
[11:01] <ogra_> see the crashes column at http://ci.ubuntu.com/smokeng/trusty/touch/ ... in 215 the new ofono landed
[11:01] <xnox> ogra_: so we could modify the script in question to catch the exception (and thus not crash / not generate .crash file)
[11:01] <ogra_> the order is to roll back before next image
[11:01] <xnox> ogra_: and exit non-zero with an erro rmessage.
[11:02] <ogra_> well, but something has caused it
[11:02] <xnox> ogra_: reverts is for the weak, and acknoledging that one does not understand where the problem is comming from.
[11:02] <ogra_> and the last phonesim change dates back to tuesday
[11:02] <ogra_> it only showed up with new ofono
[11:02] <xnox> ogra_: if you don't know what is causing it, try a fix.
[11:03] <xnox> ogra_: psivaa: let me give a patch for list-modems, and check that is actually solves the problem.
[11:03] <xnox> ogra_: psivaa: and you rerun the dialer-app tests with it applied.
[11:03] <ogra_> in which all scripts changed
[11:03] <ogra_> xnox, its not my choice ... the next image needs to not have the crashes, one way or the other
[11:03] <ogra_> its morr than just list-modem
[11:04] <ogra_> i see three different scripts that fail with dbus issues looking through the different crashes, i assume others would too if they were called
[11:04] <psivaa> xnox: ack, will run it
[11:05] <ogra_> there is enable-modem too
[11:05] <ogra_> and dial-number
[11:05] <mardy> Laney: that "Component not ready" message can also mean that there's an error in the QML code
[11:05] <mardy> Laney: you can try to print the error
[11:05] <ogra_> (teh latter one is only in the dialer-app test it seems)
[11:06] <davmor2> Morning all
[11:06] <Laney> mardy: then it would fail all the time, no?
[11:07] <Laney> it works for me locally
[11:07] <mardy> Laney: ah, yes
[11:08] <Laney> need to figure out the proper way of waiting
[11:08] <Laney> the one I have now is racy
[11:09] <mardy> Laney: maybe you already removed that "reset" boolean property locally? I wonder if it may fail because you have a function with the same name
[11:10] <Laney> mardy: it was there still
[11:14] <ogra_> xnox, ok, i can reproduce it here as soon as i install ofono-phoesim-autostart on my tablet
[11:16] <ogra_> urgh ... and it installs xvfb-run and runs it
[11:16] <xnox> ogra_: try with http://paste.ubuntu.com/7026949/ ?
[11:16]  * ogra_ wonders if we actually want that on a phone 
[11:16] <xnox> ogra_: no, we don't want xvfb-run, cause that i presume auto-activates a fresh system dbus and autoactivate the real ofono.
[11:17] <ogra_> xnox, right, so thats our issue
[11:17] <xnox> ogra_: are you in a normal shell, with system dbus available et.al.
[11:17] <ogra_> i'm on my tablet and did "apt-get install ofono-phonesim-autostart"
[11:17] <xnox> ogra_: i've pastebin a patch which should not generate .crash files for list-modems, due to phonesim activation.
[11:17] <ogra_> which got me a lit of xlib stuff and xvfb installed
[11:18] <xnox> well, phonesim depends on qt4 so that's expected to get libs, et.al.
[11:18] <xnox> ogra_: where are these dialer-app tests and how are they running?
[11:19] <ogra_> somewhere in autostart i guess
[11:19] <ogra_> thats not an issue with dialer-app
[11:20] <xnox> fun my tablet fails to boot.
[11:20] <ogra_> xnox, the pstebin was for list-modems ?
[11:20] <xnox> ogra_: yes.
[11:20] <ogra_> (my crash file is for enable-modem :P )
[11:20] <xnox> ogra_: cool! who/where/what calls _that_ ?! =)
[11:21] <xnox> ogra_: networkmanager / NMofono?
[11:21] <ogra_> the upstart job of ofono-phonesim-autostart
[11:22] <ogra_> the upstart job calls /usr/bin/with-ofono-phonesim
[11:22] <ogra_> which mangles dbus and then restarts ofono
[11:23] <Mirv> pete-woods: could you look at bug #1287135? it's a newly found valgrind armhf test error that blocks continuing with the Qt 5.2 landing
[11:24] <pete-woods> Mirv: sure, valgrind + dlopen = fail :(
[11:24] <pete-woods> and obvs Qt does a lot of that
[11:25] <Mirv> pete-woods: ok :(
[11:26] <xnox> ogra_: yeah, stracing it - looks like it does a lot of crap.
[11:26] <ogra_> right
[11:26] <xnox> ogra_: it wants "online-modem" script, it wants "xvfb-run" and etc.
[11:27] <ogra_> xnox, yeah
[11:27] <ogra_> xnox, the funs stuff is that nothing failed with it before the new ofono landed
[11:28] <ogra_> ofono-phonesim was changed on tuesday
[11:28] <ogra_> there were a good bunch of images and tests that didnt fail until ofono landed on friday
[11:30] <ogra_> and autostart was always installed so that xvfb unglyness was always there
[11:31] <xnox> ogra_: so, i have a patch for list-modems, and at least one can now install -autostart without a crash generated for list-modems.
[11:31] <ogra_> so sad that itti is on vacation :/
[11:31] <ogra_> *pitti
[11:31] <xnox> ogra_: that does not however yet, explain other crashes.
[11:31] <ogra_> it seems all scripts the autostart script calls fail like that
[11:32] <ogra_> do we perhaps miss some dep on something like python3-dbus ? in the new ofono
[11:33] <xnox> ogra_: you'd get import error, and python3-dbus is seeded anyway.
[11:33] <ogra_> yeah, i see it installed :(
[11:34] <xnox> (well a crash with ImportError dbus)
[11:34]  * ogra_ sees a python3-dbusmock package 
[11:35] <ogra_> ha !
[11:36] <xnox> ogra_: right, so a enable-modem is execed by with-ofono-phonesim, which may happen before emulated ofono is available...
[11:36] <ogra_> and looking at a test console log i see:
[11:36] <ogra_> The following extra packages will be installed:
[11:36] <ogra_> python-dbusmock ubuntu-ui-toolkit-autopilot
[11:36] <ogra_> which is the 2.7 version !
[11:37] <xnox> so?!
[11:37] <ogra_> do the py3 scripts possibly require a py3 version of that ?
[11:37] <xnox> none of the scripts import dbusmock, nor ubuntu-ui-toolkits, ofono scripts are not importable, but only executable scripts.
[11:38] <xnox> ogra_: again, if any of that was required, and not present under python3, you'd get ImportError....
[11:38] <ogra_> ubuntu-ui-toolkit is just from the test where i grabbed the console log
[11:38] <ogra_> ignore that one
[11:39] <ogra_> xnox, i dont mean that the scripts import it, but that the dbus hacking phonesim does from its script perhaps need the py3 version installed to make it function with the new py3 scripts
[11:39] <ogra_> (god, thats hard to express :P )
[11:40] <xnox> aha. found where the xvfb-run and friends are comming from.
[11:40] <xnox> pitti's black magic code =)
[11:41] <ogra_> hehe
[11:41] <xnox> right, the exception is needed for enable-modem as well, since it's also executed in the loop waiting for org.ofono to appear on dbus.
[11:42] <ogra_> right
[11:43] <ogra_> i tried moving the autostart job to "on started dbus and started ofono" ...
[11:43] <ogra_> doent help
[11:43] <xnox> ogra_: it has always been racy, now the race is expose and/or people paying attention to .crash files.
[11:43] <ogra_> we always pay attention to crash files :) especially if tehy show up in hordes :)
[11:44] <xnox> there are no changes in the code-paths taken... e.g. the difference could be ofono taking longer to show up on dbus when started with this fake phonesim.
[11:44] <xnox> ogra_: anyway, i'll have a full patch for both list-modems and enable-modem crashes.
[11:44] <ogra_> (the other bug with that is that phonesim is constantly installed, should only be used for SIM related tests)
[11:44] <xnox> ogra_: where there any other crashes?
[11:44] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/
[11:45] <ogra_> see the images 215 -217
[11:45] <ogra_> right column is for crashes
[11:45] <ogra_> next to the percentage
[11:45] <ogra_> (214 was relatively fine, from 215 on it exploded)
[11:45] <xnox> ogra_: i see there are crashes since 196....
[11:45] <ogra_> if you click on the image you can go deeper into details
[11:45] <xnox> ogra_: it's not like it was 0....
[11:46] <ogra_> no
[11:46] <ogra_> but they are tests that crash
[11:46] <xnox> ogra_: i think my browser is shit, cause the orange circle nor number are clickable for me.
[11:46] <ogra_> with 215 there was at least one ofono script crash with each test
[11:46] <ogra_> no
[11:46] <ogra_> you click the front column with the image number
[11:46] <ogra_> that gets you a details page
[11:47] <xnox> ah, ok.
[11:47] <ogra_> where you can then click the test name to go into more details
[11:47] <ogra_> if you scroll down on such a detail page you see the log and .crash files
[11:58] <xnox> ogra_: psivaa: please apply this patch http://paste.ubuntu.com/7027072/ to ofono-scripts, then try out installing / start phonesim; phonesim-autostart; running dialer_app tests.
[11:58] <xnox> ogra_: psivaa: without this patch, phonesim is spawned, and crash files are generated, and fake ofono is not yet ready.
[11:58] <SGK> MUST BE OLD , BUT HAVE TO ASK ...ABOUT THE WIFI problem on nexus 4
[11:59] <SGK> any solutions?
[11:59]  * ogra_ shields his ears)
[11:59] <popey> which wifi problem?
[11:59] <xnox> ogra_: psivaa: with this patch it takes upto 3seconds to start fake ofono, but it is fully and reliably up without crash files generated.
[11:59] <ogra_> xnox, 3sec is fine
[12:00] <ogra_> our tests run a lot pre-testing scripts so it wont harm the testing
[12:00] <SGK> wifi not working in dual boot with 4.4
[12:00] <ogra_> SGK, we dont really support dual boot ... but there is a wikipage explaining a workaround (the one with the dual boot install instructions)
[12:01] <SGK> alright then, thanks.. btw , do u hv the link?
[12:02] <SGK> and does it involve flashing radio img?
[12:03] <ogra_> yes iirc
[12:03] <Laney> https://wiki.ubuntu.com/Touch/DualBootInstallation#Android4.4Radio
[12:06] <SGK> thanks guys bye
[12:09] <Laney> byeeeee
[12:12] <Laney> rsalveti: Can we change the way that libhybris installs its egl alternate? It's actively harmful on desktop...
[12:13] <Laney> rsalveti: Like do some dynamic detection to tell if it's needed or put it in a separate package?
[12:16] <ogra_> Laney, it *is* in a separate package afaik
[12:16] <Laney> it's in 'libhybris'
[12:18] <ogra_> hmm, i thought that was moved to Mir
[12:25] <r2zrocky> how to expand mobile cash size for android nexus device
[12:26] <pete-woods> Mirv: can help me get an MR for libqtdbustest that builds against Qt5.2 like yours?
[12:26] <pete-woods> *you
[12:29] <pete-woods> e.g. by setting up jenkins the right way for this one? https://code.launchpad.net/~pete-woods/libqtdbustest/qt-5.2/+merge/209052
[12:33] <Mirv> pete-woods: I don't have such bits, but I can test building the branch in PPA, and then if it fixes the issue the branch can be published via CI Train in the same slot with the whole Qt 5.2 landing
[12:34] <Mirv> pete-woods: also, it seems libqtdbusmock will fail in similar way: https://launchpadlibrarian.net/168215166/buildlog_ubuntu-trusty-armhf.libqtdbusmock_1%3A0.2%2B14.04.20131128.1-0~31.1%2B201403031131~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
[12:35] <psivaa> xnox: ogra_ : so i patched the above to /usr/share/ofono/scripts/enable-modem and /usr/share/ofono/scripts/list-modems . are they the intended files?
[12:38] <Mirv> pete-woods: your branch building now at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+sourcepub/3951050/+listing-archive-extra
[12:40] <pete-woods> Mirv: thanks, looking into it, I don't think the default valgrind suppression files are being kept up to date for ARM
[12:40] <pete-woods> so I think I'll just disable valgrind on ARM, to stop this happening again
[12:42] <Mirv> pete-woods: ok, it might make sense
[12:44] <pete-woods> Mirv: I already have the leak checks running on both i386 and x86_64, and I have no platform specific code, so I think that should be enough coverage
[12:44] <pete-woods> I've updated the branch with this now
[12:48] <psivaa> ogra_: i see the crash even after applying the patch in: http://paste.ubuntu.com/7027072/
[12:49] <ogra_> psivaa, yes, that only fixes list-modems properly
[12:49] <pete-woods> Mirv: https://code.launchpad.net/~pete-woods/libqtdbusmock/qt-5.2/+merge/209060 I also have an MR for the other lib
[12:49] <psivaa> ogra_: ack
[12:52] <Laney> mardy: https://code.launchpad.net/~laney/ubuntu-system-settings/reset-api/+merge/208661 line #153, can you see why that doesn't work?
[12:52] <Laney> I don't know if it's the best way to do it, but I figured it should work anyway
[12:53] <Laney> shall I try !...isReady()?
[12:54] <mardy> Laney: just print component->errors()
[12:55] <Laney> ok
[12:55] <Laney> why does the CI reproduce this 100% of the time and me 0%?
[12:55]  * Laney tries in sbuild
[12:55] <mardy> Laney: if your loop is not enetered, then the most likely explanation is that the component failed to compile
[12:55] <Mirv> pete-woods: yep, the bzr32 of your branch (although you updated already finished). I'll set that branch to be landed via the Qt 5.2 silo
[12:56] <Mirv> pete-woods: and https://code.launchpad.net/~pete-woods/libqtdbusmock/qt-5.2/+merge/209060 for the mock one?
[12:56] <pete-woods> Mirv: yep :)
[12:56] <mardy> Laney: maybe the QtQuick 2.0 module is not installed when building
[12:56] <Laney> it could be insufficient build-deps
[12:56] <Laney> sbuild ought to tell me that
[12:58] <Laney> I don't think anything used that pageComponent before
[12:58] <Laney> in the tests
[12:59] <Laney> mardy: ah, I guess you're right ;-)
[12:59] <Laney> fails in sbuild
[13:00] <Laney> ya, adding qtquick fixes it
[13:14] <ogra_> abeato, err ... "sleep 30" ??? you cant really delay the boot by 30sec
[13:15] <abeato> ogra_, yes, sure, it was a test, not the final solution
[13:15] <ogra_> :)
[13:15] <ogra_> but great that it works
[13:15]  * ogra_ was planning to work on this today, but the ofono breakage of all tests kind of got in my way
[13:16] <abeato> ogra_, np :)
[13:16] <abeato> ogra_, my only problem now is which event to use
[13:16] <ogra_> right
[13:17] <abeato> or, the answer to the question, when do we know all android services are up?
[13:17] <ogra_> abeato, well, its the post-start script ... you could make it emit android and only set the sleep 30 *after* it emitted
[13:17] <ogra_> and inevnt something like rild-ready that you emit additionally
[13:18] <ogra_> abeato, http://paste.ubuntu.com/7027436/
[13:18] <ogra_> something like this (taking your script as a base)
[13:18] <abeato> ogra_, ok, but that will delay ofono start
[13:18] <ogra_> and indeed an "emits rild-ready" at the top of the job
[13:19] <Mirv> pete-woods: hi again. I fired off rebuilds of everything that hasn't rebuilt in a while, so I'm wondering if you coul do similar trick to libusermetrics as well? :)
[13:19] <ogra_> ofono is already delayed by the while loop ... it should be the same just in different words
[13:19] <pete-woods> Mirv: sure thing!
[13:19] <ogra_> abeato, try it ... its just a theory
[13:19] <abeato> ogra_, well, that's maybe right
[13:20] <Mirv> pete-woods: thanks again a lot :)
[13:20] <abeato> maybe I can move that loop to lxc-android-config
[13:20] <ogra_> (the while loop can be dropped if this works and you can probably shorten the 30sec a little )
[13:20] <abeato> after "emit android"
[13:21] <ogra_> the only issue with ofono coming up late is that the UI shows "no signal" on start
[13:21] <abeato> ogra_, right, I guess it is a matter of testing different things
[13:21] <ogra_> but it will switch as soon as ofono is up
[13:21] <ogra_> though i'm not sure how that affects our PIN code handling etc
[13:22] <abeato> ogra_, AFAIK we do not block on start when PIN is needed
[13:22] <abeato> for the moment
[13:23] <abeato> but it is something we might need to do, so we cannot delay ofono too much
[13:23] <ogra_> right, but once we do amd if we want that to happen before the greeter is up that will result in awful boot times
[13:24] <abeato> ogra_, agreed
[13:25] <pete-woods> Mirv: https://code.launchpad.net/~pete-woods/libusermetrics/qt-5.2/+merge/209065 there's one for libusermetrics
[13:26] <pete-woods> Mirv: just so you know, I don't think these problems are due to Qt 5.2, I think it's upgrades to glibc that cause it
[13:26] <pete-woods> I guess we just upload new eglibc without checking _all_ packages or something like that?
[13:29] <Mirv> pete-woods: thanks, I found it already. excellent. all rebuilds have now finished and one more is there: unity-voice
[13:30] <pete-woods> Mirv: :D basically every project I have developed :p (am I the only person who runs things under valgrind?)
[13:30] <Mirv> pitti is not around, but maybe some more autopkgtests could be in order for glibc upgrades
[13:30] <Mirv> pete-woods: it seems so :)
[13:30] <pete-woods> I don't really know what we could do
[13:31] <pete-woods> as you can't really rebuild everything for each glibc MR I'd have thought
[13:31] <Mirv> now ~everything at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages has compiled at least once during the last three weeks or so
[13:34] <pete-woods> Mirv: https://code.launchpad.net/~pete-woods/unity-voice/qt-5.2/+merge/209069
[13:51] <Mirv> pete-woods: getting that too, thanks a lot!
[13:52] <pete-woods> np!
[14:29] <barry> popey: do you have auto-downloads enabled?
[14:29] <popey> barry: no
[14:30] <barry> popey: okay.  still trying to reproduce the problem based on your video :/
[14:30] <popey> barry: i have an update pending on my phone if there's any logs you need, let me know.
[14:30] <barry> popey: /var/log/system-image/client.log
[14:30] <popey> barry: before the update or after I attempt it and get the blacklist error?
[14:31] <barry> popey: after, please :)
[14:31] <popey> barry: http://paste.ubuntu.com/7027754/
[14:32] <barry> popey: okay thanks.  i'll ping you if i need more information
[14:32] <popey> barry: ok, attached log to bug
[14:33] <barry> ack
[14:52] <bfiller> jussi: are the MR's in line 6 of the CI Train ready for build?  (column h)
[14:53] <bfiller> jussi: the thumbnailer ones..
[14:55] <rsalveti> Laney: ogra_: the other libs were moved to a different package
[14:55] <rsalveti> Laney: why do you need hybris?
[14:55] <ogra_> rsalveti, right, thats what i thought
[14:55]  * ogra_ remembers alf's patch 
[14:56] <Laney> rsalveti: I don't, but it gets pulled in sometimes
[14:56] <rsalveti> we can't easily detect during install time because that would break our image process
[14:56] <Laney> there was once an error
[14:56] <Laney> and currently by the mir session
[14:56] <ogra_> fix whatever pulls it in :)
[14:56] <Laney> go on then
[14:56] <rsalveti> right
[14:56] <Laney> get it out of unity8-desktop-x11 or whatever it is
[14:57] <ogra_> ask the maintainer :)
[14:57] <Laney> even so there's still a package which partially breaks your system if you install it
[14:57] <Laney> is that okay?
[14:58] <rsalveti> it's not ideal, we could add some logic in livecd-rootfs to allow libhybris to be installed
[14:58] <rsalveti> in a way we could block libhybris to be normally installed if you pull it by accident
[15:07] <barry> mandel: what image # has the latest and greatest udm?
[15:08] <mandel> barry, uhm.. 213 or 214 AFAIK
[15:08] <mandel> barry, sil2100  knows better
[15:08] <barry> mandel: so definitely by 215, all known bugs are fixed?
[15:08] <mandel> barry, AFAIK, ys
[15:08] <mandel> yes*
[15:08] <barry> mandel: okay, cool, thanks.
[15:08] <Laney> run ;-)
[15:11] <fr33r1d3> Installed Ubuntu on my Nexus 4 with Android 4.4.2 on.. Still needs to flash the radiopart?
[15:12] <Laney> barry: yeah that bug is reproducable
[15:13] <ogra_> fr33r1d3, does radio work, do you have wlan and sound ?
[15:13] <barry> Laney: you mean 1286461?  it makes no sense ;)
[15:13] <ogra_> (then you dont)
[15:13] <fr33r1d3> No, I dont
[15:13] <ogra_> then you do :)
[15:13] <Laney> barry: try it!
[15:14] <Laney> oh no, not that one
[15:14] <Laney> the one p_opey was reporting
[15:14] <Laney> that one you linked is probably a side effect of dual booting
[15:14] <Laney> afaik that messes with /android/cache/recovery/
[15:15] <barry> Laney: yeah.  re: popey's bug, i had to try it 5 times, each time flashing back to 215 and getting the timing just right, but i did finally manage to reproduce it
[15:15] <Laney> I turned off auto downloads before reproing
[15:15] <barry> Laney: well, if dual booting messes with /a/c/r/ not sure what i can do about that :(
[15:15] <popey> barry: yay
[15:15] <barry> but let's concentrate on popey's bug
[15:15] <Laney> system-settings also span and didn't show the in-progress download
[15:15] <Laney> which is pretty annoying
[15:16] <ogra_> abeato, can you please make the sleep 1 and sleep 2 to be "sleep 0.1", we dont want to forcefully sleep 2 sec if the socket is there already
[15:16] <fr33r1d3> ogra: Ok, found the info on how to do it now.. =)
[15:16] <barry> i'm still suspicious about lines 4059-4065.  the reason i asked mandel about it is because that's part of the previous workaround for the atomic renames.  if udm is now doing the atomic renames, then si shouldn't do it anymore, although i can't see why that would fail
[15:17] <ogra_> abeato, seems you didnt use the latest lxc-android-config as base ... there are the sleeps changes
[15:17] <abeato> ogra_, ok, no problem with that
[15:17] <abeato> am, I'll take a look then
[15:18] <Laney> barry: I'm lying, that error is happening on someone's desktop
[15:18]  * barry wants to investigate the udm logs
[15:18] <jussi> bfiller: huh?
[15:18] <barry> Laney: oh, well, then that makes perfect sense.  they have to edit their /etc/system-image/client.ini to point to a directory that actually exists. ;)
[15:18] <barry> Laney: if that's really the case, then the bug *is* invalid
[15:19] <jussi> bfiller: do you have me confused with someone?
[15:19] <mandel> barry, may I get some more context?
[15:19] <bfiller> jussi: oh I do, sorry about that
[15:19] <Laney> you probably shouldn't crash though?
[15:19] <mandel> barry, and yes, we are doing atomic renames
[15:19] <barry> mandel: one sec.
[15:19] <barry> Laney: what should we do instead?
[15:20] <barry> mandel: popey posted this video: https://www.youtube.com/watch?v=YmD6cGYvIAI
[15:20] <barry> mandel: and this log file: http://paste.ubuntu.com/7027754/
[15:20] <barry> mandel: take a look at lines 4058-4065 which happen *before* the file not found error
[15:21] <barry> mandel: that exception is happening at the place where the tempfile location i ask udm to download channels.json to doesn't exist at the point of my rename
[15:21] <Laney> barry: return an error from the dbus call
[15:22] <barry> Laney: let me think about that
[15:23] <Laney> I don't know how you do that in dbus-python, mind
[15:23] <mandel> barry, so, popey is not canceling but going back, correct? therefore the download was no canceled
[15:23] <mandel> Laney, is that correct ^
[15:24] <barry> mandel: that is correct
[15:24] <mandel> Laney, barry or back is canceling the download?
[15:24] <mandel> barry, would be nice to get the udm logs too
[15:24] <barry> mandel: no it doesn't cancel the download
[15:24] <barry> mandel: can you ask popey to attach the appropriate udm log file?
[15:24] <Laney> what is the log file?
[15:25] <Laney> I just reproduced it so I can get that
[15:25] <barry> mandel: ^^
[15:25] <mandel> Laney, ah, nice, it is in /var/log/ubuntu-download-manager
[15:25] <Laney> (ah you can just raise dbus.exceptions.DBusException)
[15:25] <mandel> Laney, zip all of them, I can check the timestamp per file
[15:26] <Laney> mandel: there's just one from today
[15:26] <Laney> or do you really want them all?
[15:26] <mandel> Laney, well, better from today
[15:26] <mandel> Laney, no need to read everything :)
[15:27] <Laney> http://paste.ubuntu.com/7028069/
[15:28] <barry> Laney: can you also post the /var/log/system-image/client.log file?  we can cross reference the two
[15:28] <Laney> barry: yup, http://paste.ubuntu.com/7028074/
[15:29] <mandel> barry, Laney line 49
[15:29] <mandel> in Laney udm logs
[15:29] <mandel> apart from a typo in my logs :-/
[15:29] <mandel> tired instead of tried.. stupid manuel
[15:30] <Laney> maybe you were tired at the time :P
[15:30] <mandel> Laney, he. could be
[15:31] <barry> mandel: yes, i see that also on line 410 which is the name of the file in the client.log that is reporting a FileNotFound
[15:32] <mandel> barry, yes, but that has nothing to do with the file system, is the internal mutex
[15:33] <barry> mandel: line 408 of the udm log, i see an EMIT finished.  but that's for single file download right?  would i see that in response to my groupDownload request?
[15:34] <mandel> barry, yes, the group dowload listens to each file download, and when all downloads are done emits a signal with all the paths
[15:34] <mandel> barry, you are seeing the individual signal
[15:35] <mandel> barry, you can see the group signal => Group Download{ e39d28daf9ff4fa4996628a1c5b8a546}Finished downloads /tmp/system-image-j5cbzv4u/6idp0kwi.tmp /tmp/system-image-j5cbzv4u/jrh0hej7.tmp
[15:35]  * mandel blames who ever told him to remove the spaces in the logs in a review..
[15:54] <aquarius> chrisccoulson, just shilled the hell out of Oxide in my html5-apps app-dev-week session ;)
[15:54] <chrisccoulson> hi aquarius :)
[15:55] <chrisccoulson> heh, thanks
[15:55] <chrisccoulson> how are you?
[15:57] <aquarius> chrisccoulson, am good. I mentioned Oxide and got a zillion questions ;) YOu might wanna review the log...
[15:57] <chrisccoulson> ah thanks, will take a look :)
[16:00] <aquarius> chrisccoulson, http://irclogs.ubuntu.com/2014/03/03/%23ubuntu-app-devel.html#t15:00 once irclogs.u.c catches up :)
[16:53] <timppa> Evening!
[16:54] <timppa> I just noticed that on the music lens/scope if you preview a song in the "popular online" section, you cannot change the volume
[16:55] <timppa> If you adjust volume from the dropdown menu song stops playing
[16:56] <timppa> Is that a known bug?
[16:56] <timppa> running trusty #218 on mako
[16:58] <timppa> actually volume buttons don't work at all
[16:58] <timppa> :)
[16:58] <daker> #218 is the stable channel ?
[16:59] <timppa> nope
[16:59] <daker> then probably hasn't pass QA tests
[17:01] <timppa> maybe
[17:30] <deanm> Hi, I'm looking for some info about how to flash touch into an MTK6592 platform (8-core) device. From the wiki cant seem to be able to find something.
[17:40] <nhaines> deanm: if the wiki doesn't have information about a device being compatible, then neither do we.
[17:40] <nhaines> deanm: you might want to check the XDA developers forum to see if anyone else has attempted it.
[17:40] <nhaines> Otherwise...
[17:40] <nhaines> !device
[17:40] <nhaines> !devices
[17:40] <anselal> hello, i tried to flash ubuntu touch (saucy) on my i9250, and I got stuck on bootloop before I was able to push and flash the last file "saucy-preinstalled-touch-armhf.zip" . Now I am unable to boot into bootloader. When I open my phone it shows the Google logo and then it turns off. Any idea ??
[17:45] <deanm> nhaines: Where can i find more information on how to start working for the MTK platform? Are there any resources on how to go about porting an image etc. ?
[17:45] <nhaines> deanm: I don't knwo what MTK means.
[17:45] <nhaines> deanm: but as far as porting goes, this should be a great start: https://wiki.ubuntu.com/Touch/Porting
[17:46] <stgraber> ogra_: http://paste.ubuntu.com/7028777/
[17:47] <ogra_> stgraber, \o/
[17:47] <ogra_> stgraber, what did you do ?
[17:47] <deanm> nhaines: Thank you
[17:48] <stgraber> ogra_: I didn't change anything, that's just the current values when looking at the logs
[17:48] <ogra_> hmm
[17:48] <ogra_> that cant be right then, it takes much longer than 30 min
[17:49] <stgraber> ogra_: over the past 4 days, the longest run was 35min (because flo an generic triggered a second delta for some reason), the normal run for a cdimage import is 25min, the normal run for a custom import from jenkins is 5min and otherwise, it's below 6s
[17:49] <ogra_> is the mirrorint triggered by import-images ? or is that a server side cron job
[17:49] <ogra_> (the mirroring to the s-i.u.c server)
[17:50] <stgraber> it's triggered by system-image but I have no way of knowing when it's actually done
[17:50] <stgraber> ogra_: if you don't trust my numbers, feel free to look at: for file in /srv/system-image.ubuntu.com/logs/*; do echo start: $(head -n1 $file); echo end: $(tail -n1 $file); echo ""; done :)
[17:50] <stgraber> logs don't lie
[17:51] <ogra_> stgraber, well, if i measure the time between seeing the image on cdimage to seeing it in the -proposed channel under mako its closer to 1:40
[17:52] <ogra_> stgraber, thats why i'm wondering if the final mirror step might probably be delayed ... i trust your logs
[17:52] <ogra_> but your logs only look at what happens on nusakan
[17:53] <ogra_> if the syncing ot the public server is delayed or only happens by hourly cron job or some such that would explain a delay at least
[17:53] <stgraber> yeah, there's no way to know when something's actually visible on the mirror, for simple changes like adding flo/generic, it only took seconds but those files are pretty small
[17:53] <ogra_> yeha
[17:54] <stgraber> it sure isn't an hourly cronjob, it's a ssh trigger and that one clearly works because I can change in the index and have the change publicly visible wiithin seconds
[17:54] <ogra_> hmm
[17:54] <stgraber> but if the pipe is extremely slow for some reason, this may explain some of what you're seeing
[17:55] <ogra_> well, its the only explanation i can imagine ...
[17:56] <stgraber> looking at the timestamps on system-image.ubuntu.com, the latest image finished building at 14:43 and the pool entry on system-image dates 14:56
[17:57] <ogra_> thats not much
[17:57] <ogra_> hmm
[17:58] <stgraber> well, those are rsynced so the timestamps probably match nusakan's...
[17:58] <ogra_> if didrocks had uses the image build notification in the other channel then i could find when he started the build in the logs now
[17:58] <ogra_> *used
[17:58] <ogra_> right
[17:59] <ogra_> 16:10 (local time ... so 15:10 UTC) the image showed up in the mako subdir of the -proposed channel
[18:00] <ogra_> so seems the rsync takes ~15min
[18:01] <ogra_> (i have a wtacher running that checks every minute, but only when new images show up in there)
[18:01] <kdub> is there a quick way to resize the root partition on touch devices?
[18:02] <ogra_> kdub, nope, its a loop mounted img file ... you would need to dd stuff to it with offet, then resize the fs etc etc
[18:02] <stgraber> that's not very impressive for ~500MB of files... we're supposed to have gigabit so this should just take 5s in theory...
[18:02] <ogra_> not trivial
[18:03] <ogra_> stgraber, so i finally found the IRc line when didrocks pinged about building the image, that was  14:54 local (so 13:54 UTC)
[18:03] <kdub> ogra_, thanks
[18:03] <didrocks> 13:55 UTC
[18:03] <ogra_> yep
[18:03] <stgraber> ogra_: I'm going to publish a 2GB file now, let's see how long it takes to make it over
[18:04] <ogra_> thats all in all just 1:15 though ... not *that* bad
[18:04] <ogra_> rsalveti said something about 1:45 and more recently
[18:04] <rsalveti> yup
[18:05] <rsalveti> we can check later today once we trigger a new image
[18:05] <ogra_> yeah
[18:05] <ogra_> around 1h (+/- 15min) is expected and ok i think
[18:05] <rsalveti> yeah
[18:05] <ogra_> if we end up closer to 2h thats something we need to inspect
[18:06] <stgraber> ogra_: took around 1min30 for a 2GB file to rsync over
[18:06] <rsalveti> that was quite fast
[18:06] <ogra_> then i dont get why the sync of the images took 15min
[18:06] <Vendetta8247> Hey guys, may I ask you a question? Is it possible to install Ubuntu Phone on Xperia phones?
[18:06] <ogra_> !devices | Vendetta8247
[18:06] <Vendetta8247> I'm completely new to Unix systems but want to start learning them
[18:07] <ogra_> Vendetta8247, if it is on there, there should be a link
[18:07] <stgraber> well, I guess it depends exactly what IS' network is doing at the time, but at the moment it seems pretty speedy...
[18:07] <ogra_> if it is not, xda-developers might have an image ... and if they dont either, you need to port yourself
[18:08] <Vendetta8247> thanks, sorry for the dumb question. Was about to install it on my PC and just noticed the phone version is available
[18:08] <Vendetta8247> didn't do enough research :)
[18:08] <ogra_> well, the ports are generally not that well supported
[18:08] <ogra_> dont exepct to much :)
[18:08] <Vendetta8247> Yeah, I know :) But I hate the stock ROM and always wanted to Touch Ubuntu
[18:08] <ogra_> we focus on nexus4 here ... all other bits are developed by the community and often lack lots of features (like making calls)
[18:09] <Vendetta8247> and what about Nexus 5? Is there an active support?
[18:09] <Vendetta8247> I'm about to get it this month
[18:10] <ogra_> there is a very active community port of the N5
[18:10] <ogra_> i think most features work
[18:11] <Vendetta8247> That's so nice! I'm a student and this week I'm turning 19. Want to start researching Unix and more coding
[18:11] <Vendetta8247> so maybe someday I will be a part of this community :)
[18:11] <ogra_> (teh good thing is that the code for the N5 is in our tree, we just dont build official images for it, so for the community guys its more a thing of "building" than "porting")
[18:11] <ogra_> Vendetta8247, welcome then :)
[18:12] <rsalveti> I think it might be even easier for xperia devices
[18:12] <rsalveti> I remember they releated trees that were compatible with AOSP at some point
[18:12] <ogra_> yep
[18:12] <Tassadar> Vendetta8247: I'm maintaining an unoffiial system-image server for hammerhead, so the installation is quite easy and it works pretty well
[18:12] <ogra_> some LG, some samsung and some xperias recently got AOSP support
[18:12] <rsalveti> which reminds me I need to upload the kernel for hammerhead
[18:12] <Vendetta8247> ogra_, now I have Xperia S (it was so nice when I bought it) and want to rebuild something inside. Always was interested in OS's
[18:13] <ogra_> Tassadar, you should probably tell also what "hammerhead" is ;)
[18:13] <Tassadar> rsalveti: yeah, sorry if I just did it completely wrong, I have no idea how kernels are maintained :/
[18:13] <rsalveti> no worries, it's fine
[18:13] <Tassadar> Vendetta8247: hammerhead is the boardname of Nexus 5, sorry, I'm used to using those names)
[18:13] <ogra_> :)
[18:13] <ogra_> we all are
[18:14] <Tassadar> and I should write an email to the mailing list about my server
[18:14] <ogra_> its good to have some fresh blood here to remind us of such things ;)
[18:14] <Vendetta8247> sure, I understand. Also used to using the "nozomi" and friends often don't understand me lol
[18:14] <rsalveti> Laney: saw you pushed the gst-bad split, did you also update the seeds?
[18:15] <Vendetta8247> Wow, I'm surprised to see a friendly community. Usually coders are rude and don't like newbies
[18:15] <ogra_> Vendetta8247, but we all were "newbies" when we started :)
[18:16] <ogra_> (the unfriendly ones too ... they probably just have forgotten about it :) )
[18:16] <Vendetta8247> I also consider buying a SGS5 so I might be working on it in a few months
[18:16] <cwayne> Tassadar, you setup a system-image server for hammerhead? link me!
[18:16] <Vendetta8247> yeah, I'm from Ukraine and here people are often so mean. And instead of getting a simple answer they just say how lazy I am and that I will never do a thing
[18:18] <Tassadar> cwayne: http://forum.xda-developers.com/showpost.php?p=50689471&postcount=645, and I'm typing an email to the mailing list with less my-multiboot-thing-related noise right now
[18:20] <Tassadar> cwayne: would be greate if you could try the non-multiboot way of installation, I've tried it myself a couple of times but most people whom I linked this server to don't use it.
[18:24]  * Tassadar wonders if he can somehow detect when was the last change to android parts of source and build it only if necessary
[18:35] <ogra_> Tassadar, you could just try to monitor the andrpid package https://launchpad.net/ubuntu/trusty/+source/android
[18:35] <ogra_> only once we rebuild it the changes actually land in the image
[18:37] <Tassadar> ogra_: is it in the main trusty ppa?
[18:37] <ogra_> Tassadar, multiverse
[18:38] <ogra_> (due to the binary blobs in it)
[18:39] <ogra_> Tassadar, i think there was an RSS feed of the trusty-changes ML ... that gets auto posted if a package is uploaded
[18:43] <nhaines> Tassadar: if I have Ubuntu installed on my N5 via MultiROM Manager, can I use the built-in updater to upgrade?
[18:43] <Tassadar> nhaines: yeah (the one in GUI, not apt-get)
[18:44] <nhaines> Tassadar: yay! \o/
[18:44] <Tassadar> ogra_: rss feed would be great, can't find it anywhere though
[18:44] <nhaines> I guess I *know* why everyone wants to apt-get their phones... but I don't know why everyone wants to apt-get their phones. :P
[18:45] <ogra_> Tassadar, http://dir.gmane.org/gmane.linux.ubuntu.devel.changes.trusty
[18:45] <Tassadar> cool, thanks
[18:46] <ogra_> Tassadar, for the U release you will indeed have to switch over then
[18:55] <mhall119> cjwatson: is there a way to tell click to look somewhere other than /var/lib/schroot/chroots/ for chroot directories?
[18:56] <mhall119> my / partition is almost full, but I have plenty of room on /home/.
[19:10] <nhaines> mhall119: how do you feel about symlinks?
[19:10] <mhall119> nhaines: tried it
[19:10] <mhall119> tried bind mounting
[19:11] <mhall119> still getting a permission error, so I'm trying to rule those out as the cause
[19:11] <mhall119> cjwatson: I even edited the file in /etc/schroot/ for it, pointing to the actual location on disk of the chroot directory
[19:11] <mhall119> cjwatson: I still get E: Access not authorised
[19:11] <mhall119> I: You do not have permission to access the schroot service.
[19:11] <mhall119> I: This failure will be reported.
[19:18] <nhaines> mhall119: http://xkcd.com/838/
[19:23] <mhall119> nhaines: dang, on the naugty list again this year
[19:52] <Tassadar> stgraber: what do you thing about bug 1286542 ? The config from your blogpost has file_keyring in it and I didn't change it, so maybe this is to be fixed on server side?
[19:55] <stgraber> Tassadar: oh yeah, that's a bug in the client, I'll bug barry some more about it ;)
[19:55] <barry> stgraber: well, i'm not so sure
[19:56] <barry> destination file names must be unique
[19:56] <stgraber> barry: well s/bug/undefined behavior we ought to define/g :)
[19:56] <barry> stgraber: better :)  but note that this will also affect u-d-m
[19:57] <stgraber> barry: so the trick with keyring-<hash>.tar.xz is that it is constent BUT included in all delta updates
[19:57] <stgraber> barry: that's required for the corner case where a delta update of the ubuntu rootfs overwrites a file that's usually part of the keyring tarball
[19:57] <Tassadar> why is keyring in deltas anyway? can it change?
[19:58] <stgraber> Tassadar: see above :) the keyring itself can't change, but the files it overrides may change in a delta update, so it's required to be there to re-overwrite them should they have changed somehow
[19:58] <barry> stgraber: the only sane semantics that i can think of is to define files with the same destination name to be identical (*maybe* checking the hash and complaining if they're different).  then we'd essentially only download the file once for the entire upgrade
[19:59] <stgraber> barry: so yeah, keyring-<hash>.tar.xz is a bit special because it's inclued in all full images AND all delta images. Obviously if your update path includes multiple delta images, it'll be in your download list multiple times.
[19:59] <barry> maybe complain too if they have different source urls
[19:59] <Tassadar> oh, okay. And the keyring file exists because custom servers have different gpg keys, while s-i.ubuntu.com has the correct ones in the tarballs already, is that correct?
[20:00] <stgraber> barry: right, so I can guarantee that I'll never give you the same filename with two different content
[20:00] <barry> stgraber: why are these not under gpg/ ?
[20:00] <stgraber> barry: because it's not a keyring, it's a standard .tar.xz which just happens to be called keyring-<hash>
[20:00] <stgraber> barry: (not confusing at all, I know)
[20:01] <barry> ;)
[20:01] <stgraber> that tarball contains two files, system/etc/system-image/archive-master.tar.xz and system/etc/system-image/archive-master.tar.xz.asc
[20:01] <stgraber> it's applied after the ubuntu rootfs, so it'll overwrite the original files
[20:02]  * barry hopes we have no security vulnerabilities!
[20:02] <stgraber> that's the trick we do so porters don't have to repack the whole Ubuntu rootfs for their port and can just use the one from the public server
[20:05] <barry> stgraber, Tassadar: https://bugs.launchpad.net/ubuntu-system-image/+bug/1286542/comments/2
[20:06] <Tassadar> stgraber: hmm, nothing should overwrite files from that keyring tarball during "normal" use, right? I disabled generation of deltas for keyring for now so that the updates work, hope that was a safe thing to do
[20:06] <stgraber> barry: sounds good to me
[20:07] <stgraber> Tassadar: it's indeed unlikely. The only case where this would happen is if we were to change those two files which would mean a new archive key. That never happened since the creation of the Ubuntu project, so it's not terribly likely to happen in the few days that barry will need to get that handled by the client :)
[20:08] <Tassadar> good) and I'll be able to drop that workaround fairly soon, beceause I only store 5 images per channel
[20:16] <robotfuel> barry: ping, what's the relevant ppa from the test plan here  https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-image ?  (the second step)
[20:17] <barry> robotfuel: it *was* the landing-10 silo.  i'll create a new PPA that i'll try to keep up-to-date with proposed s-i and u-d-m
[20:17] <robotfuel> barry: thanks
[20:18] <barry> robotfuel: we'll call it ppa:barry/systemimage
[20:47] <Laney> rsalveti: not yet - the packages are still in NEW & I'm scared to do anything to touch lest I get lynched
[20:47] <Laney> slight exaggeration ;-)
[20:50] <rsalveti> right :-)
[20:51] <cjwatson> mhall119: click doesn't care where you store them, it just uses schroot.  I expect you've configured it wrong.  An easy answer is to make /var/lib/schroot a symlink to somewhere else
[20:52] <robotfuel> Laney: ping
[20:53] <cjwatson> mhall119: if you're getting confused about "access not authorised" then one possibility is that you've recently added yourself to a group whose membership you're relying on, but haven't logged out and back in
[20:53] <Laney> robotfuel: hello, best to say what you want straight away then I can reply straight away too
[20:54] <mhall119> cjwatson: maybe, but changing the schroot config to include my username instead of just 'root' made it work
[20:54] <cjwatson> mhall119: that seems predictable
[20:55] <cjwatson> I'm slightly wrong that click doesn't care where you store them - the "create" and "destroy" subcommands care
[20:55] <mhall119> cjwatson: not sure if it should always have a non-root user, in which case the qtcreator plugin needs updating
[20:55] <cjwatson> (which IMO is a bug)
[20:55] <robotfuel> Laney: do you know who has been writing autopilot tests for ubuntu-system-settings? (I need some custom proxy objects for update testing)
[20:56] <cjwatson> mhall119: click chroot puts both root and your user name in the "users", "root-users", and "source-root-users" key for any chroots it creates
[20:56] <Laney> robotfuel: I have, and rvr has, and om26er worked on them a bit
[20:56] <cjwatson> $ grep cjwatson /etc/schroot/chroot.d/click-ubuntu-sdk-13.10-armhf
[20:56] <cjwatson> users=root,cjwatson
[20:56] <cjwatson> root-users=root,cjwatson
[20:56] <cjwatson> source-root-users=root,cjwatson
[20:56] <cjwatson> ^- like that
[20:56] <Laney> I'm not sure I know what you mean by a proxy object though
[20:57] <Laney> also: system-updates is gatox and I think he did write some tests too
[20:57] <robotfuel> Laney: they have been called the emulator in autopilot, but that term is being replaced with custom proxy objects.
[20:57] <Laney> oh right
[20:58] <mhall119> cjwatson: strange, qtcreator is definitely running as me, bzoltan1 is the chroot creation being run via sudo or something?
[20:58] <Laney> robotfuel: Well I don't know anything about those personally
[20:59] <Laney> for system updates it's probably best for me to redirect you to gatox
[21:02] <cjwatson> mhall119: wouldn't matter, click chroot uses SUDO_USER if there
[21:02] <robotfuel> Laney: If I start one to add what I need, then you and others can add to it. when omer gets back I am sure he can also help.
[21:03] <Laney> robotfuel: Oh, you're offering to /do/ the work?
[21:03] <Laney> in that case... go nuts and I'll review it :-)
[21:03] <robotfuel> Laney: a small part :) thanks
[21:03] <mhall119> cjwatson: somehow it gets root for both
[21:03] <mhall119> users=root,root is what I had
[21:04] <mhall119> some for all 3 user fields
[21:04] <mhall119> s/some/same/
[21:04] <cjwatson> mhall119: maybe it's behind policykit or something?
[21:05] <mhall119> maybe, bzoltan1 might know but it's 10pm in Oslo
[21:06] <bzoltan1> mhall119:  Helsinki :) and 11pm
[21:06] <mhall119> well I didn't have Helsinki in my world clock
[21:07] <bzoltan1> mhall119: :) so what can do for you?
[21:07] <cjwatson> if it's behind policykit, then I could change click chroot to look it up from PKEXEC_UID
[21:08] <mhall119> bzoltan1: since you're still around, any idea where I can get /usr/lib/arm-linux-gnueabihf/qt5/bin/uic ?
[21:08] <bzoltan1> cjwatson: I use pkexec instead of sudo everywhere. We do not have cli for the qtc
[21:08] <mhall119> I can't build my app in the click choot because part of it wants that
[21:08] <bzoltan1> mhall119: qtbase5-dev-tools should provide that
[21:08] <cjwatson>     params->setCommand(QLatin1String(Constants::UBUNTU_SUDO_BINARY));
[21:08] <cjwatson> is that just terrible naming then?
[21:08] <cjwatson> ./src/ubuntu/ubuntuconstants.h:436:const char UBUNTU_SUDO_BINARY[]   = "/usr/bin/pkexec";
[21:09] <cjwatson> hahaha, yes it is
[21:09] <mhall119> bzoltan1: it does on i386, but not armhf
[21:10] <cjwatson> mhall119: please file a click bug saying that "click chroot create/destroy" should be able to figure out the invoking user from PKEXEC_UID
[21:10] <cjwatson> mhall119: should be relatively straightforward, you'll just have to join the queue :)
[21:11] <bzoltan1> mhall119: that would be very odd
[21:12] <cjwatson> cjwatson@pepo:~$ dpkg -c ubuntu/pool/main/q/qtbase-opensource-src/qtbase5-dev-tools_5.0.2+dfsg1-7ubuntu18_armhf.deb | grep uic
[21:12] <cjwatson> -rwxr-xr-x root/root   1046652 2014-02-06 13:57 ./usr/lib/arm-linux-gnueabihf/qt5/bin/uic
[21:12] <cjwatson> mhall119: ^-
[21:12] <cjwatson> However, qtbase5-dev-tools is Multi-Arch: foreign
[21:12] <mhall119> huh, so why doesn't my chroot have it?
[21:12] <cjwatson> which seems like a clear bug to me - it's installing everything to multiarch paths
[21:12] <bzoltan1> mhall119: -rwxr-xr-x root/root   1030268 2013-05-30 18:35 ./usr/lib/arm-linux-gnueabihf/qt5/bin/uic according to the armhgf build logs
[21:12] <cjwatson> and M-A: foreign means that you can't coinstall the i386 and armhf versions
[21:13] <cjwatson> your chroot doesn't have it because the metadata declared in that package mean that you have to choose between architectures
[21:13]  * bzoltan1 is slow
[21:14] <mhall119> bzoltan1: do you understand what cjwatson is saying? because I don't
[21:15] <bzoltan1> mhall119: I do. That is Qt at its best ... not M-A
[21:15] <mhall119> cjwatson: how do I manually tell apt-get to install the armhf package too?
[21:16] <bzoltan1> mhall119:  apt-get install whatever:armhf
[21:16] <cjwatson> mhall119: what I'm saying is that the only way you can do that will involve uninstalling the i386 version at the same time
[21:17] <cjwatson> if that's OK, then fine, apt-get install qtbase5-dev-tools:armhf, although the way this package is laid out sort of suggests to me that there may be problems
[21:17] <cjwatson> I don't know Qt well enough to be able to predict that accurately
[21:17] <mhall119> it's not really
[21:17] <cjwatson> But a Multi-Arch: foreign package installing all its files into /usr/lib/<arch-triplet>/ is just plain bizarre
[21:18] <cjwatson> if that's not OK, then you can't, the Qt packaging maintainers need to fix this
[21:18] <ajalkane> Ubuntu Touch emulator... for me the swipes from bottom to up to bring up the bottom menu do not work. Is this a known problem?
[21:18] <cjwatson> though I'm slightly puzzled why it wouldn't be OK to uninstall the i386 version *from a chroot*
[21:19] <cjwatson> i.e.  click chroot -a armhf -f ubuntu-sdk-13.10 maint apt-get install qtbase5-dev-tools:armhf
[21:20] <mhall119> cjwatson: oh, it just uninstalls from the chroot?
[21:20] <mhall119> that should be okay then
[21:20] <cjwatson> that's the point of click chroot maint, yeah
[21:30] <Killian> Does anyone have the correct Ubuntu installer for the Skyrocket?
[21:32] <Killian> I followed a youtube tutorial and it is on my phone but when I try to install Ubuntu it says "no available channels"
[22:13]  * mhall119 hates compiled languages
[23:24] <basketball> any updates on nexus 7 2013 ubuntu touch since last weekend
[23:28] <basketball> any updates on nexus 7 2013 ubuntu touch since last weekend
[23:42]  * mrjazzcat heard someone mention that the Nexus 7 (grouper) was deprecated.  But, it still shows on the main Touch wiki.  Are images still being created for this device?
[23:47]  * mrjazzcat found it.
[23:48] <mrjazzcat> https://wiki.ubuntu.com/Touch/Install#Supported_devices_and_codenames
[23:56] <mrjazzcat> Alright, one last question, then.  So, the 2012 Nexus 7 is deprecated, but there are emails saying that tests are run on it, so I'm going to presume that images are being created.
[23:57] <mrjazzcat> Is that right?