[00:05] <kdub> what starts surfaceflinger in the flipped image?
[00:05] <wbjohnston> alright, I've got the image installed but its not leaving the google logo off of boot
[00:08] <wbjohnston> for a nexus 7
[00:08] <wbjohnston> I flashed the 13.04 desktop preinstalled and boot image on
[00:18] <jcastro> wbjohnston: I just ran into that problem
[00:25] <wbjohnston> did you happen to find a fix
[00:28] <wbjohnston> jcastro
[00:30] <wbjohnston> I've flashed the boot image and full image a couple times but it just won't leave the initial google screen
[00:30] <wbjohnston> not sure what to do on that
[00:31] <jcastro> not sure either
[00:32] <jcastro> I hadn't determined if it was my fault yet, heh
[00:32] <wbjohnston> yeah, I can't either
[00:32] <wbjohnston> and now I have a fukken brick
[00:32] <jcastro> I was just going to wait to see if someone finds a solution
[00:32] <wbjohnston> I would do that
[00:32] <wbjohnston> but I kinda need the tablet
[00:33] <wbjohnston> haha
[00:38] <eolo999> hi I am trying to 'phablet-flash ubuntu-system' on my Nexus 7 but I get this error: ERROR:phablet-flash:Command 'adb shell mount /data' returned non-zero exit status 255
[00:38] <eolo999> i tried both with and without sudo
[00:41] <eolo999> it seems it is a quite common thing similar to what Alan Pope reported here https://bugs.launchpad.net/phablet-tools/+bug/1215436
[00:42] <eolo999> the only difference is that in my case it failed mounting data
[00:42] <eolo999> c'mon :)
[00:51] <eolo999> Is there anybody out there ♫♫♫♫♫
[00:52] <eolo999> INFO:phablet-flash:Restarting device... wait
[00:52] <eolo999> INFO:phablet-flash:Restarting device... wait complete
[00:52] <eolo999> INFO:phablet-flash:Clearing /data and /cache
[00:52] <eolo999> error: device not found
[00:52] <eolo999> ERROR:phablet-flash:Command 'adb shell mount /data' returned non-zero ex
[00:52] <eolo999> (hope not too long paste)
[00:58] <eolo999> I rerun the command in with --debug option and I have a python traceback: http://paste.ubuntu.com/6068617/
[00:59]  * eolo999 never been in a so silent ubuntu channel but I've been missing for long
[01:05] <mhall119> eolo999: it's kind of late for this channel
[01:06] <eolo999> mhall119: why? European?
[01:07] <mhall119> even USA time it's into the evening
[01:08] <mhall119> eolo999: try "adb kill-server; sudo adb start-server" then re-flashing
[01:09] <eolo999> I did that
[01:09]  * eolo999 tries again
[01:09] <mhall119> it shows on adb devices?
[01:09] <eolo999> it shows the device when it starts
[01:10] <eolo999> but in some ways it gets lost in the reboot phase
[01:10] <mhall119> eolo999: hmmm, try "phablet-flash cdimage-touch" then, maybe it's something with the new read-only system image
[01:10] <eolo999> (now i'm in a ipdb shell watching that)
[01:11] <eolo999> it seems mount is returning : 'Usage: mount [-r] [-w] [-o options] [-t type] device directory\r\n'
[01:11] <eolo999> as if it was invoked improperly
[01:12] <eolo999> actually error code 255 may be for wrong invocations
[01:14] <eolo999> WOW!!!
[01:14] <mhall119> cwayne_: uWoot needs screenhots added to it's MyApps entry :)
[01:14] <mhall119> eolo999: I have no idea then, try cdimage-touch
[01:14] <eolo999> ok
[01:15] <eolo999> mhall119: thx
[01:15] <cwayne_> mhall119, i'll add some :)
[01:15] <cwayne_> how do you see it on myapps?
[01:15] <mhall119> cwayne_: myapps provides the screenshots to the click scope so I can see it on my phone
[01:16]  * mhall119 just installed uWoot
[01:16] <cwayne_> mhall119, ah, i haven't seen it in my click scope yet
[01:23] <cwayne_> so what are our plans for installing new themes?
[01:23] <cwayne_> are they going to be click packages?
[01:35]  * cwayne_ just installed his app from myapps
[01:35] <cwayne_> thats a cool feeling :D
[02:29] <plars> rsalveti, fginther: the tests weren't happy, not sure how to deal with the absence of /var/log/installer/media-info
[02:29] <rsalveti> plars: yeah, saw that, I'm creating another image with that stamp
[02:29] <plars> rsalveti: oh  cool
[02:29] <plars> rsalveti: I might be able to hack around it, but if you are already making one we'll just use that :)
[02:29] <rsalveti> yup, should be done soon
[04:42] <picard> I have installed ubuntu touch on my nexus 4, I didn't used it for onw week or so. now the battery is empty I think. but it is not charging anymore if I plug into a power source. what can I do?
[05:50] <Guest38595> i have an android phone which isnt supported by ubuntu..but i want to install ubuntu touch..is there any way..or i'll need to build for it
[06:03] <Snow_> Anyone here working on the phone app ?
[06:06] <george_> hello
[06:06] <george_> I am new to IRC
[06:07] <george_> how does it work? It's like I'm chatting to myself without getting any replies
[06:42] <dholbach> good morning
[06:43] <asac> moin dholbach
[06:43] <dholbach> hey asac
[07:05] <biba> hi
[07:05] <biba> anyone here
[07:05] <biba> i want to know about ubuntu on my andrid
[07:27] <ogra_> asac, hmm, looks like the tests for ro on mako have never had a full run, there is always a good chunk of tests that dont start at all
[07:40] <jman> Is there any work being done to port Touch to any Xiaomi phones?
[08:02] <asac> ogra_: hmm
[08:02] <asac> ogra_: check with psivaa
[08:02] <ogra_> at least rw seems to be pretty reliable now
[08:03] <jman> Just looking at the Mi3 specs, looks promising
[08:04] <jman> (especially considering price point)
[08:04] <help_me> can anyone provide a bit of assistance with my tablet?
[08:05] <help_me> I installed Ubuntu Touch.  It's not quite ready for realtime yet.  Can't access external SD card to revert to Android, can't telnet, bluetooth or access device via usb.
[08:07] <psivaa> morning :)
[08:07] <asac> sil2100: Mirv: while we wait for unity, can we maybe push selected stacks?
[08:07] <asac> sil2100: Mirv: do we have a good overview of what is waiting?
[08:07] <asac> maybe we can pick 1/3 or so of what is waiting, pipe it in and do an image/validation run?
[08:08] <ogra_> psivaa, yo ... coulld you take a look at mako touch_ro ? seems like not all tests run there
[08:09] <asac> psivaa: mornign!
[08:09] <psivaa> ogra_: will do in a sec
[08:09] <asac> psivaa: i think there are a few tests in todays _ro run that need some love
[08:09] <asac> so we can push that as well to /current
[08:09] <psivaa> asac: ack, will take a look
[08:09] <ogra_> well, in fact it seems like a few tests have never run on mako yet
[08:10] <asac> yeah. those i am fine to ignore .. there is one that had a regresison
[08:10] <asac> which i would like to see go green
[08:10] <asac> and then we can push the next one
[08:10] <ogra_> well, they run on maguro ...
[08:10] <help_me> no one can help?
[08:11] <Mirv> asac: most stacks are waiting, I haven't collected a list of packages but could do that now
[08:11] <ogra_> help_me, what kind of tablet is that ?
[08:11] <sil2100> asac: I would have to take a look on what's in the queue,
[08:12] <Mirv> I'm compiling the list now
[08:12] <help_me> Sony Xperia Tablet Z
[08:14] <ogra_> help_me, then you should talk to the person that maintains the port for this device
[08:14] <ogra_> help_me, this is a community maintained device, you can find info (about the status and who does the port) on the devices wikipage
[08:15] <ogra_> !devices | help_me
[08:15] <help_me> i've put in a question to them, but i can break in if i could have access to device in any way or physically power down the unit
[08:15] <ogra_> contact him/her ...
[08:15] <DanielBeck> hello. I'm the developer of RamSamSam Reader. I wanted to ask, if someone could check the design of the application. What things should I change to make it better comply with the ubuntu design guidelines.
[08:18] <jman> Is there a reason that Xiaomi devices are not being ported to? Is it just lack of an interested party?
[08:19] <ogra_> jman, well, the community would have to do it and nobody stepped up yet
[08:19] <jman> no technical limitation?
[08:19] <ogra_> to do a port you actually need the device usually ...
[08:20] <ogra_> that would be the technical limitation here :)
[08:21] <jman> likewise here :)
[08:21] <jman> They're just quite enticing at the moment...
[08:22] <jman> (if I can get one outside of china that is)
[08:22] <ogra_> they definitely build exciting devices
[08:24] <Mirv> asac: http://pastebin.ubuntu.com/6069481/
[08:36] <krabappel2548> hello everyone
[08:37] <krabappel2548> I have a question about merging the rules file of my device in the saucy preinstalled image
[08:37] <krabappel2548> how do I need to do this? :)
[08:39] <ogra_> krabappel2548, you can file a bug against ubuntu-touch-sessiion and attach the file to it for example
[08:40] <ogra_> or if you are familiar with the process file a merge proposal against https://code.launchpad.net/~phablet-team/session-manager-touch/trunk
[09:00] <xnox> mhall119: am I allowed to have multiple package namespaces?
[09:09] <psivaa> Mirv: sil2100: i am having to restart jenkins in magners, due to some hang in the locks and latches plugin.
[09:10] <psivaa> there are some tests cu2d-* running and am wondering if i could abort them and restart?
[09:19] <dpm> pstolowski, morning! So with the gstreamer*-fluendo-mp3 packages that lool prepared, will the mediascanner be able to index mp3 files?
[09:20] <dpm> xnox, mhall119 is away today. You might want to ask cjwatson or beuno perhaps.
[09:21] <pstolowski> dpm: hey! I've yet to check that (will do today)
[09:22] <dpm> pstolowski, thanks, that'd be great, I'm following up on all the core apps blockers to get a summary of the status by the end of today, so if you could give me a heads up when you find out more later on, that'd be awesome
[09:23] <xnox> dpm: well, there is no click limitation, but rather store/upload/sso restriction.
[09:23] <dpm> xnox, then beuno is your man, I think
[09:24] <dpm> or you can ask on the appstore developers ML
[09:28] <psivaa> ogra_: asac: i am restarting the jenkins which runs the touch smoke, due to a hang in one of its plugins. so there will be a delay for about 30 mins in the new run results
[09:28] <ogra_> ok
[09:35] <dholbach> does anybody know why the icons of installed apps are sometimes not shown after reboot/reflash?
[09:37] <popey> dholbach: i have been wondering about this too
[09:37] <JamesTait> Good morning all, happy Friday, and happy Fight Procrastination Day! :-D
[09:37] <popey> JamesTait: nah, we'll fight procrastination tomorrow
[09:38] <JamesTait> popey, http://instantrimshot.com/
[09:38] <dholbach> popey, I think I'll file a bug on unity-scope-click about it (not sure if that's the right place, but they can always reassign it, I guess)
[09:39] <dholbach> popey, bug 1221643
[09:40] <JamesTait> dholbach, popey: confirmed.
[09:41] <JamesTait> Saved me the bother of reporting it this morning. :)
[09:42] <dholbach> I also have two wordchain entries
[09:42] <dholbach> and that although it's not even installed right now, hum.......
[09:44] <dholbach> I might have to reflash the device using --wipe to be sure
[09:58] <rah> I'm getting an error:
[09:58] <rah> host C++: aprotoc <= external/protobuf/src/google/protobuf/io/printer.cc
[09:58] <rah> In file included from external/protobuf/src/google/protobuf/io/gzip_stream.h:46:0, from external/protobuf/src/google/protobuf/io/gzip_stream.cc:39:
[09:58] <rah> /usr/include/zlib.h:34:19: fatal error: zconf.h: No such file or directory
[09:58] <rah> I have /usr/include/x86_64-linux-gnu/zconf.h but no /usr/include/zconf.h
[09:59] <rah> the both the zconf.h and zlib.h are in zlib1g-dev
[09:59] <rah> shouldn't gcc be coping with this?
[10:02] <davmor2> Morning all
[10:02] <cjwatson> rah: Are you cross-compiling from amd64 to armhf here?
[10:03] <rah> https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1155307
[10:03] <rah> cjwatson: yes
[10:03] <cjwatson> No
[10:03] <rah> "No"?
[10:03] <cjwatson> That bug is wrong
[10:03] <cjwatson> You need zlib1g-dev:armhf installed, then, or some other arrangement to get the appropriate configuration for the target arch
[10:04] <rah> but the compilation step says "host C++"
[10:04] <cjwatson> That bug is from people trying to do gcc -m32 on amd64 to build for i386, anyway, not your case
[10:04] <rah> so, presumably, that step is not cross compilation but host compilation?
[10:04] <cjwatson> "host arch" in autotools-speak means the architecture you're compiling for
[10:05] <cjwatson> Whether that's the case in this build system I don't know, but it's fairly common terminology
[10:05] <xnox> rah: do note that zconf.h is moved to a multiarch location, thus do check your include paths as one needs two to compile against zlib.
[10:05] <rah> cjwatson: the "host C++" is not printed by autoconf
[10:05] <cjwatson> You'll need to get the build system to be more verbose in order to find out what it's actually doing
[10:05] <rah> host C++: aprotoc <= external/protobuf/src/google/protobuf/io/printer.cc
[10:05] <cjwatson> rah: Sure, but it's common enough terminology among people doing cross-building
[10:05] <rah> cjwatson: don't you understand what the ubuntu touch build system is reporting there?
[10:05] <cjwatson> rah: I haven't a clue
[10:06] <rah> cjwatson: then why are you responding? :-)
[10:06] <cjwatson> I do other bits of Ubuntu Touch
[10:06] <cjwatson> rah: Because I know about cross-building in general
[10:06] <cjwatson> And about multiarch
[10:06] <rah> so do I
[10:06] <rah> I'm asking about the ubuntu touch build
[10:07] <cjwatson> Have you tried installing zlib1g-dev:armhf to see if it progresses the build?
[10:07] <rah> nope
[10:07] <cjwatson> That would seem like a simple thing to do
[10:07] <rah> it would
[10:08] <cjwatson> Failing that, the next diagnosis step is to find out what compiler line is actually running here
[10:09] <rah> W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/raring/main/binary-armhf/Packages  404  Not Found
[10:09] <rah> how odd
[10:09] <cjwatson> It's on ports.u.c
[10:09] <cjwatson> http://paste.ubuntu.com/6069795/ for instance
[10:09] <rah> I don't understand this
[10:11] <cjwatson> That said: for building Android, armhf packages are probably wrong, since Android is more like armel
[10:11] <cjwatson> So maybe that's a false alleyway
[10:11] <rah> I don't think this is going to solve the problem
[10:11] <ogra_> cjwatson, the build scripts pull the cross compiler from the x86 archive i think
[10:12] <ogra_> oh, binary-armhf ... ignore me
[10:12] <cjwatson> Oh, here we go.  Try building with SHOW_COMMANDS=1
[10:12] <mpt> error: insufficient permissions for device
[10:12] <mpt> ERROR:phablet-flash:Command 'adb shell getprop ro.cm.device ' returned non-zero exit status 255
[10:12] <cjwatson> That'll get it to actually say what it's doing
[10:12] <mpt> ^^ What should I do here?
[10:13] <ogra_> mpt, try adb stop-server && sudo adb start-server
[10:13] <ogra_> and then try again
[10:13] <rah> http://codepad.org/j6bDlKBY
[10:13] <rah> that's the error
[10:14] <mpt> ogra_, "adb stop-server" just gives me the adb help text and exits with error status
[10:15] <mpt> oh, kill-server perhaps?
[10:15] <ogra_> oh, indeed, sorry
[10:15] <rah> I'm wondering why it's referring to out/host/linux-x86/obj/include
[10:15] <mpt> ERROR:phablet-flash:Unsupported device, autodetect fails device
[10:15]  * mpt gnashes teeth
[10:16] <ogra_> mpt, hey, thats one step forward
[10:16] <ogra_> (you now have the permissions)
[10:16] <popey> mpt: is the phone dead?
[10:16] <ogra_> mpt, is the device in recovery mode by chance ?
[10:17] <cjwatson> hm, so that is the ordinary system compiler (albeit via ccache) and it doesn't seem to be removing system directories from the include path
[10:17] <mpt> ogra_, popey, this is why "adb reboot" is step 0 for me in How To Update The Phone
[10:18] <rah> I've installed zlib1g-dev:i386
[10:18] <cjwatson> I don't think that'll help
[10:18] <rah> it seems to be progressing further than it did before
[10:18] <cjwatson> I'd be inclined to (a) add -v to get g++ to dump its final include path (b) attack it with strace -etrace=open
[10:18] <cjwatson> Oh
[10:18] <cjwatson> Sorry, yeah, that's using -m32
[10:19] <rah> so it is
[10:19] <cjwatson> I think lib32z1-dev is probably more correct for that, strictly
[10:19] <cjwatson> Since this is biarch-world rather than multiarch-world
[10:20] <cjwatson> i.e. g++ -m32 rather than i686-linux-gnu-g++ or whatever
[10:28] <timppa> Hi everyone!
[10:28] <timppa> Can someone shed some light regarding GPS support on touch?
[10:29] <timppa> Should it be working already? I've been trying to do a little app but GPS does not seem work
[10:34] <dpm> cjwatson, it seems that click packages installed with pkcon install-local to test them locally are not showing their icons in the dash. That's with today's --pending cdimage. xnox seems to be having the same problem. Any ideas what it could be or where can we look for the icon to find out what's going on?
[10:35] <cjwatson> 20:31 <alecu> mhall119: regarding the missing icon, I'm affected by that too, and currently looking for a solution.
[10:35] <cjwatson> dpm: ^- it's in alecu's domain rather than mine, AFAIK
[10:36] <dpm> cjwatson, ok, will talk to him when I see him online, thanks!
[10:36] <cjwatson> (I suspect it's something like failing to resolve icons relative to the base app unpack directory)
[10:40] <rah> I've run "brunch <codename>"
[10:40] <rah> it's compiled lots of things
[10:41] <rah> I get no error
[10:41] <rah> however, there is no zip file in out/target/product/<codename>
[10:41] <rah> no wait
[10:41] <rah> there is an error
[10:41] <rah> god brunch is annoying
[10:45] <cjwatson> grr, I still haven't got preinstallation of click packages in livecd-rootfs quite right, apparently
[10:46] <cjwatson> I may have to resort to uploading with set -x :-(
[10:50] <mzanetti> tvoss: hey, using a PositionSource {} in QML makes apps crash on the desktop since the latest update?
[10:50] <mzanetti> err... remove the "?" :P
[10:51] <tvoss> mzanetti, now that's weird, got a backtrace for me?
[10:51] <mzanetti> tvoss: it crashes in QEventLoop::exec()
[10:51] <tvoss> mzanetti, okay, that sounds interesting
[10:51] <mzanetti> tvoss: I can push my code so you can reproduce
[10:51] <tvoss> mzanetti, yup, shoot it over
[10:53] <mzanetti> tvoss: git@gitorious.org:getmewheels/getmewheels2.git
[10:53] <mzanetti> tvoss: you should be able to open the .pro file in qtcreator and click play
[10:54] <mzanetti> tvoss: then it'll crash in some exec() call
[10:54] <mzanetti> tvoss: open src/qml/getmewheels2/ubuntu/MainPage.qml and comment away the PositionSource {} code
[10:54] <mzanetti> tvoss: it won't crash any more
[10:54] <tvoss> mzanetti, let me check the qtlocation source package, too
[10:56] <tvoss> mzanetti, can you try to reproduce locally with the qtlocation flickr example?
[10:56] <mzanetti> yeah
[10:57] <tvoss> mzanetti, so I'm getting a segfault in something geoclue
[10:57] <mzanetti> tvoss: reproduced with this: http://paste.kde.org/p70622daa
[10:58] <mzanetti> simple enough? :P
[10:59] <tvoss> mzanetti, yes, but still getting issues with geoclue, which used to be the case before, too, on the desktop
[11:00] <cjwatson> ogra_: Not quite yet, but would you mind if I ran just the livefs part of an ubuntu-touch build in a bit?  I'm having trouble diagnosing why it's not preinstalling click packages, so I just uploaded livecd-rootfs with some more debugging in an attempt to help
[11:00] <mzanetti> tvoss: it didn't crash at least when I wrote all that stuff last weekend
[11:00] <mzanetti> tvoss: it didn't work on the desktop, but also not crash
[11:00] <tvoss> mzanetti, I'm dist-upgrading and looking again
[11:01] <tvoss> mzanetti, but it crashed for me before, popey has filed numerous bugs about qtlocation not working on the desktop
[11:07] <tvoss> mzanetti, okay, I get a backtrace crashing in geoclue
[11:09] <rah> I get the following error trying to build a java program in my device/ directory:
[11:09] <rah> make: *** No rule to make target `.../out/target/common/obj/APPS/framework-res_intermediates/src/R.stamp', needed by `.../out/target/common/obj/APPS/FileExplore_intermediates/src/R.stamp'. Stop.
[11:10] <rah> is this because ubuntu touch doesn't include the android java frameworks?
[11:14] <xnox> rah: there is no java on Ubuntu Touch.
[11:15] <rah> pfft
[11:15] <rah> so I shouldn't bother trying to build anything java related
[11:15] <xnox> rah: most likely you have too much enabled in the android build. E.g. you do not need to build any java apps at all.
[11:15] <xnox> frameworks, et. al.
[11:15] <xnox> kernel, and a few system libs.
[11:16] <rah> this is not in android, this is under my devices/ directory
[11:18] <rah> are .apk files java applications?
[11:18] <rah> that is, does the exclusion of javaness include exclusion of any .apk files?
[11:19] <rah> xnox?
[11:19] <xnox> rah: .apk is a mostly renamed .jar, and you will not be able to run nor install .apk on ubuntu touch.
[11:19] <rah> ok
[11:19] <rah> thanks
[11:26] <ogra_> cjwatson, sure, go for it
[11:27] <cjwatson> Ta.  Should be in the archive shortly ...
[11:30] <rah> target thumb C++: libcamera_compat_layer <= ubuntu/hybris/compat/camera/camera_compatibility_layer.cpp
[11:30] <rah> ubuntu/hybris/compat/camera/camera_compatibility_layer.cpp:116:1: error: 'NativeBufferAlloc' does not name a type
[11:37] <xnox> rah: are you rebuilding the build or porting to new device?
[11:37] <rah> xnox: porting to a new device
[11:38] <Csabeeboy> Yo
[11:38] <xnox> rah: are you following https://wiki.ubuntu.com/Touch/PortingFlippedInProgress ?
[11:38] <rah> xnox: no
[11:38] <rah> xnox: should I be?
[11:38] <xnox> rah: you should =)
[11:39] <xnox> rah: or use much older hybris....
[11:39] <rah> xnox: it might be worth making a note of that fact on https://wiki.ubuntu.com/Touch/Porting
[11:39] <xnox> dholbach: ^
[11:39] <Csabeeboy> I just ordered the power hungry lenovo k900, which has proximity sensor. I would like to adapt Ubuntu mobile to it
[11:40] <Csabeeboy> How can I take part in the development?
[11:42] <rah> the port will not be complete without backporting the AppArmor v3 patchset to older kernels
[11:42] <rah> :-/
[11:43] <jjohansen> rah: how old are we talking? It is done back to 3.0, and in a few weeks maybe back to 2.6.35
[11:43] <rah> I have a 3.3 kernel
[11:43] <Csabeeboy> It would be awesome to have a face recognition for login and a proximity sensor which switches the login on
[11:44] <rah> make: *** No rule to make target `.../obj/STATIC_LIBRARIES/lib_driver_cmd_rtl_intermediates/lib_driver_cmd_rtl.a', needed by `.../obj/EXECUTABLES/hostapd_intermediates/LINKED/hostapd'. Stop.
[11:44] <rah> :-/
[11:45] <jjohansen> rah: you can find the set of backport patches in git://kernel.ubuntu.com/jj/ubuntu-saucy.git  the presquash branches have individual patches showing the changes needed. There are generic kernel backports, and ones for each of the manta, mako, maguro, and grouper kernels
[11:46] <rah> the fact that they're against ubuntu kernels rather than stock kernels is what concerns me :-/
[11:46] <rah> no let me rephrase that
[11:47] <pstolowski> dpm: ping
[11:47] <rah> the fact that they're against ubuntu kernels rather than stock kernels is a big concern :-/
[11:47] <jjohansen> rah: this has the start of some instructions https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels
[11:47] <rah> jjohansen: I'm not doing that right now
[11:47] <jjohansen> rah: there are branches for both stock and ubuntu
[11:48] <dpm> hey pstolowski
[11:48] <jjohansen> rah: eg v3.4-backport-of-apparmor3 is the backport of apparmor to the stock 3.4 kernel
[11:48] <pstolowski> dpm: mediascanner is happy with gstreamer1.0-fluendo-mp3
[11:49] <dpm> \o/
[11:49] <pstolowski> dpm: at this point it needs gstreamer1.0-fluendo-mp3 gstreamer1.0-plugins-base gstreamer1.0-plugins-good
[11:50] <dpm> pstolowski, apart from the fluendo one, do you know if we install the other two by default? I think we do, but only the 0.10 versions
[11:51] <pstolowski> dpm: I asked ogra_ yesterday to push good for 1.0, so should be there or is already (I haven't flashed my phone today not too loose my test setup)
[11:53] <rah> make: *** No rule to make target `/store/rah/pengpod/ubuntu-touch/out/target/product/a1000g/obj/STATIC_LIBRARIES/lib_driver_cmd_rtl_intermediates/lib_driver_cmd_rtl.a', needed by `/store/rah/pengpod/ubuntu-touch/out/target/product/a1000g/obj/EXECUTABLES/hostapd_intermediates/LINKED/hostapd'. Stop.
[11:53] <rah> any ideas on how to fix that?
[11:54] <lool> https://code.launchpad.net/~lool/ubuntu-seeds/add-gst-fluendo-0.10/+merge/184280
[11:54] <lool> asac: so who do I ask to coordinate an additional dep?
[11:58] <asac> lool: dep?
[11:59] <lool> asac: adding packages to the image
[11:59] <lool> asac: this isn't part of automatic landing
[11:59] <lool> AFAIK
[11:59] <lool> asac: Can I just upload that now?
[11:59] <lool> don't think it's disruptive
[12:00] <asac> give me one sec
[12:00] <asac> pstolowski: whats the status of .4?
[12:00] <lool> asac: if we want to control what lands and when it lands to avoid disruptions, would it make sense to have some kind of build sheriff that goes beyond the vanguards for the daily landing stuff?
[12:00] <asac> psivaa: ^^
[12:00] <asac> did we get it into a releasable shape?
[12:00] <asac> ogra_: ?
[12:00] <asac> lool: yeah. all going to be discussed next week
[12:00] <dpm> pstolowski, given that we've got several 0.10 packages already in the image, could you confirm if mediascanner works with gstreamer 0.10 as well?
[12:00] <pstolowski> asac: .4?
[12:00] <asac> pstolowski: sorry wrong nick ... ignore
[12:01] <lool> dpm: he'd likely have to reupload a mediascanner to make use of gstreamer 0.10
[12:01] <lool> which seems going backwards
[12:01] <asac> lool: so whats the change?
[12:01] <ogra_> asac, mako still has never run all tests
[12:01] <lool> asac: adding gstreamer0.10-gst-fluendo (+ its liboil0.3 dep) to get MP3 playback fixed
[12:01] <asac> ogra_: ok... as long as its the same tests not run, its probably something i can ignore for today
[12:01] <asac> :)
[12:01] <ogra_> (we have a total of 261, mako never reached that)
[12:01] <lool> asac: also will do another change to pull gstreamer1.0-gst-fluendo
[12:01] <lool> the first one is for music app / qtmultimedia right now
[12:01] <asac> ogra_: which ones are not run? did yoiu spot those?
[12:02] <pstolowski> dpm: didn't we agree 1.0 is the only really recommended now?
[12:02] <lool> the second one is for mediascanner right now
[12:02] <asac> psivaa: come back :)
[12:02] <dpm> pstolowski, yeah, sorry, I didn't realize that'd require a new upload, ignore the comment, then
[12:02] <asac> hehe
[12:02] <psivaa> asac: ogra_ mako has similar results to maguro on ro images, that has run all the tests
[12:02] <lool> in the future, either we revert mediascanner and others to 0.10, or we port qtmultimedia (underway) and others to 1.0, or we leave both stacks in (ugly, but works)
[12:02] <lool> dpm: ^
[12:03] <asac> psivaa: is it strictly better than yesterdays image?
[12:03] <asac> e.g. the one that was published?
[12:03] <lool> for now I'll focus on adding the right deps to get the current code working
[12:03] <asac> ogra_: can you smoke test maguro... on system-ubuntu
[12:03] <asac> ogra_: maybe we want to push our first over the air :)
[12:03] <asac> then we can land lool
[12:03] <asac> and unity and then open the gates EOD
[12:04] <ogra_> we want lool in the image ?
[12:04]  * lool pulls up the flaps
[12:04] <asac> lool: i guess you could do a local check and run music-app-autopilot
[12:04]  * lool slows down for landing
[12:04] <asac> to get your "you dont think" to "i am pretty sure there is zero impact"
[12:05] <lool> asac: music app was actually confirmed to work with the new package
[12:05] <lool> asac: sure I can test
[12:05] <asac> that would be cool while i study the dashboard a bit :)
[12:05] <lool> asac: the question is more a) who to coordinate with (right now and in general) and b) would it be ok to land now
[12:05] <asac> so calendar-app is a core app, right?
[12:05] <lool> feedback of running music-app-autopilot is good
[12:05] <lool> I'll do that
[12:05] <asac> lool: yeah. for now you coordinate with me ... and yes, once you test the autopilot and you are still available for a few hours incase its busts stuff
[12:06] <asac> upload once ogra has given an OK on the last
[12:06] <asac> popey: can you check 5:20130905.4:20130905.4 ?
[12:06] <asac> popey: so we can roll our first over-the-air? :)
[12:06] <asac> davmor2: ^^
[12:07] <ogra_> asac, so it seems there are no unity8 tests on mako at all
[12:07] <ogra_> on ro
[12:07] <asac> thats not nice
[12:07] <asac> plars: psivaa: can you check whats going on?
[12:07] <ogra_> looking at 5:20130905.4:20130905.4	
[12:07] <asac> yeah seems its just that test suite
[12:07] <psivaa> asac: ogra_ there were unity8 results but one latest run has marred it
[12:08] <asac> ogra_: 4:20130904.3:20130904.3
[12:08] <psivaa> and dashboard does not show the results
[12:08] <asac> that one has the results for unity8 so it seems it can run :)
[12:08] <ogra_> yeah
[12:09] <psivaa> asac: ogra_ : https://jenkins.qa.ubuntu.com/job/saucy-touch_ro-mako-smoke-unity8-autopilot/59/
[12:09] <dpm> asac, calendar-app is a core app, yes
[12:09] <psivaa> is the all passing unity 8 in mako for 5:20130905.4:20130905.4
[12:09] <ogra_> ok
[12:09] <psivaa> now that there is 5:20130906:20130906 we wont be able to get the old run in the dash :)
[12:09] <beuno> xnox, you are not allowed to have multiple namespaces
[12:10] <xnox> beuno: 1 namespace per 1 account ?!
[12:10] <ogra_> psivaa, well, as long as we at some point can see all tests there its all fine i guess
[12:10] <xnox> beuno: ok.
[12:10] <beuno> xnox, yes, that's the plan and current restriction
[12:11] <beuno> xnox, we may allow sharing upload permissions in the future
[12:11] <lool> stgraber, cjwatson: Any objections to requesting a similar r/o public rsync for system-image.u.c images just like we have for cdimage?  (as a new separate rsync module)
[12:12] <psivaa> ogra_: ack, i've asked it to be pulled to the dash manually
[12:12] <iKillCypher> xD okay guys
[12:12] <ogra_> asac, so smoke testing maguro i dont get any way to install any packages .... the apps lens only has the "installed" bit, nothing else
[12:12] <ogra_> lool, ^^^
[12:13] <iKillCypher> ogra_ any idea how to get RIL working for my device ported ?
[12:13] <xnox> ogra_: networking enabled / working internet?
[12:13] <ogra_> wlan seems to work ... i dont have my SIM handy atm
[12:13] <ogra_> asac, but not being able to install click is a blocker i think
[12:14] <xnox> ogra_: i had to reboot & disable/enable click lense to make it realise apps are available on grouper =/
[12:14] <xnox> (scope?)
[12:14] <ogra_> xnox, how would i en/disable the click lens without any UI for that ?
[12:14] <ogra_> as i said, my applications page only has "installed"
[12:14] <ogra_> nothing else
[12:14] <xnox> ogra_: oh.... you dont' even have the "Dash plugins" section? =/ ouch.
[12:14] <psivaa> asac: 5:20130905.4:20130905.4 results are better than any other ro runs of yesterday
[12:15] <ogra_> neither the bit to en/disable lenses nor the click lens
[12:15] <ogra_> xnox, right
[12:15] <iKillCypher> ogra_ any idea how to get RIL working for my device ported ?
[12:16] <ogra_> asac, hmm, the install downloaded a 20130905.1m i'm not really sure what got installed at all
[12:18]  * ogra_ reboots the maguro 
[12:18] <dholbach> xnox, I talked to rsalveti and he wanted to move over the porting guide to the standard location early next week
[12:18] <xnox> dholbach: ok.
[12:18] <asac> ogra_: you might need lool to figure how to test
[12:19] <cjwatson> lool: fine by me insofar as my opinion matters for system-image :)
[12:20] <ogra_> asac, test what ? you cant install apps on the latest ro image on maguro
[12:20] <cjwatson> bah, hostname --fqdn doesn't work in live-build/ubuntu-touch/hooks/60-install-click.chroot
[12:20] <ogra_> thats not releasable
[12:20] <ogra_> i dont think we need to test anything until thats fixed
[12:22]  * cjwatson uploads livecd-rootfs 2.184 to fix builds
[12:22] <ogra_> doesnt the chroot inherit /etc/hostname ?
[12:22] <cjwatson> maybe not at that stage, not sure
[12:23] <cjwatson> I didn't want to spend time investigating with builds broken
[12:23] <cjwatson> maybe later
[12:23]  * cjwatson grabs daily-proposed/grouper to try to see what's up with the click scope
[12:24] <asac> ogra_: no ... how to figure what you test right now
[12:24] <asac> i think its not easy to test proposed :)
[12:24] <ogra_> cjwatson, i see it on mako using the exact same image
[12:24] <asac> cjwatson: do we have an image-creawtion outage :)?
[12:25] <cjwatson> asac: briefly - was trying to debug why preinstalled click apps weren't happening
[12:25] <asac> cjwatson: ok. when will we be able to press a new image again?
[12:25] <asac> we were just about to kick off another run for unity landing
[12:26] <cjwatson> asac: should be within 45 minutes or so, sorry about that, keeping an eye on it
[12:26] <asac> cjwatson: kk sound good. lets try to align/optimize optimize timing next time :)
[12:27] <asac> guess was quite optimal this time though (by coincident)
[12:27] <lool> ogra_: system-image-cli -i to get information
[12:27] <asac> lool: so your change will land together with unity (e.g. not isolated before)
[12:27] <asac> :)
[12:27] <asac> ogra_: so the image is good?
[12:27] <asac> :)
[12:27] <asac> ogra_: can you confirm that you really tested the right image?
[12:27] <asac> :)
[12:27] <lool> asac: doesn't matter  :-)
[12:28] <lool> asac: I have some issues bootstraping straight with system-image, so I'm a bit slow
[12:28] <ogra_> asac, no, it isnt good on maguro, works fine on mako
[12:28] <asac> good
[12:28] <asac> so its perfect :)
[12:28] <asac> ogra_: what you said above didnt read correct
[12:28] <asac> please reinstall from scratch
[12:28] <asac> ogra_: have you tried yesterdays maguro?
[12:28] <asac> we just cant be worse
[12:28] <asac> RO that is
[12:28] <ogra_> asac, you mean like i did 15min ago ?
[12:29] <asac> right
[12:29] <ogra_> i doubt that will change anything, but i can try
[12:29] <asac> yhou were brabbling about a .1
[12:29] <asac> ogra_: also try the image we published yesterday
[12:29] <asac> maybe what you test didnt work there either
[12:29] <ogra_> root@ubuntu-phablet:/# system-image-cli -i
[12:29] <ogra_> current build number: 4
[12:29] <ogra_> device name: maguro
[12:29] <ogra_> channel: daily
[12:29] <ogra_> and
[12:29] <ogra_> ucy/new$ adb shell
[12:29] <ogra_> root@ubuntu-phablet:/# system-image-cli -i
[12:29] <ogra_> current build number: 4
[12:29] <ogra_> device name: mako
[12:29] <ogra_> channel: daily
[12:30] <ogra_> and thats the latest i get ... re-running phablet-flash doesnt give me any new data
[12:30] <ogra_> checking updates through the UI doesnt offer me upgrades
[12:31] <asac> ogra_: 4 is the build we released yesterday
[12:32] <asac> lool: can you help ogra?
[12:32] <ogra_> both are based on
[12:32] <ogra_> root@ubuntu-phablet:/# cat /etc/media-info
[12:32] <ogra_> Ubuntu Saucy Salamander (development branch) - armhf (20130905.1)
[12:32] <asac> ogra_: you need an image that is veresion 5 at least
[12:32] <ogra_> asac, well, phablet-flash doesnt get me one :)
[12:32] <asac> ogra_: 5:20130905.4:20130905.4
[12:32] <asac> right
[12:32] <asac> hence you need lool
[12:32] <asac> he knows the tricks and magics
[12:33]  * ogra_ thinks thats a server side thing
[12:34] <sergiusens> ogra_: https://system-image.ubuntu.com/daily/maguro/index.json
[12:34] <sergiusens> ogra_: or s/maguro/mako/ for mako
[12:34] <ogra_> rightt, looks like there is nothing later
[12:36] <ogra_> i allso saw phablet-flash install maguro-20130905.1.full.tar.xz (and the mako equivalent)
[12:36] <lool> ogra_: what's the issue?
[12:36] <lool> ogra_: getting to pending image?
[12:36] <ogra_> lool, my application page is mostly empty on maguro ... i cant en/disable lenses and the click lens is missing
[12:37] <ogra_> lool, no, not pending
[12:37] <lool> ogra_: so I get that sometimes when network comes up after unlocking the screen
[12:37] <lool> ogra_: if you've configured your wifi, could you try restarting the device?
[12:37] <ogra_> i just ran "phablet-flash ubuntu-system" on a device that never had system images installed
[12:37] <lool> ogra_: did you phablet-network-setup?
[12:37] <ogra_> i rebooted like 20 times now
[12:37] <davmor2> asac: sorry a bit busy when you ping what do you need?
[12:38] <ogra_> network is fine, wlan is up
[12:38] <lool> ogra_: I mean phablet-network
[12:38] <ogra_> i can browse
[12:38] <lool> ogra_: check .cache/unity-scope.log
[12:38] <lool> ogra_: or something like that
[12:38] <lool> ogra_: it's the log of the click scope
[12:38] <ogra_> right, it shows the click packages i installed yesterday
[12:39] <ogra_> i thought installing the system image wipes  the userdata ?
[12:39] <lool> ogra_: I have v5 from daily-proposed on grouper here that I installed over OS updates, and I could install a new Click "Word Chain" today  :-)
[12:39] <lool> it runs too
[12:39] <asac> davmor2: testing 5:20130905.4:20130905.4
[12:39] <asac> on maguro
[12:39] <lool> ogra_: no it does not
[12:39] <lool> ogra_: phablet-flash backs stuff up now
[12:40] <sergiusens> cjwatson: hey, wrt to click preinstalled, anything I can do to help?
[12:40] <lool> ogra_: this was a prereq for switching BTW
[12:40] <cjwatson> sergiusens: I think I've fixed it now - it was hostname confusion in livecd-rootfs
[12:40] <lool> sergiusens: hey, I have a small issue: ubuntu-system doens't accept --bootstrap here
[12:40] <lool> sergiusens: I was trying to understand whether that was normal
[12:40] <davmor2> asac: right let me sort out some logs for a bug first and then I can do that
[12:40] <sergiusens> lool: ubuntu-system is always a bootstrap, that option is not there
[12:40] <sergiusens> lool: phablet-flash ubuntu-system --help
[12:41] <lool> sergiusens: So it will write the recovery each time?  great, thanks!
[12:41] <lool> sergiusens: we need to update the Install wiki then
[12:41] <lool> will test and do it
[12:41] <sergiusens> lool: yup, and since a few days ago it gets it from the server direct
[12:41] <ogra_> lool, well, in any case this image isnt releasable on maguro ...
[12:41] <sergiusens> from the device tarball that is
[12:41] <sergiusens> ogra_: what are you seeing on maguro?
[12:42] <ogra_> sergiusens, application page nearly empty ... only the "installed" category is there
[12:42] <sergiusens> ogra_: I can make phonecalls and play click games
[12:42] <ogra_> i dont have a click lens or the options to en/disable unity modules
[12:43] <ogra_> sergiusens, thats on system image ?
[12:43] <sergiusens> ogra_: oh, yeah, that's a general issue, not maguro specific
[12:43] <jdstrand> cjwatson: I wonder when your fix will land in ubuntu-system
[12:43] <ogra_> sergiusens, well, the exact same image on mako doesnt have that issue
[12:43] <sergiusens> ogra_: dholbach and jdstrand saw that, and I saw it too... searching in the lens fixes that
[12:44] <sergiusens> ogra_: most likely a race in the scope
[12:44] <ogra_> sergiusens, doesnt change a thing here
[12:44] <ogra_> no click lens
[12:44] <ogra_> do i need to search for something specific ?
[12:44] <cjwatson> jdstrand: it's making its way through the archive
[12:45] <sergiusens> ogra_: searching games or hello does it for me
[12:45] <jdstrand> sergiusens: so, stock ticker, dropping letters and sudoko-- are they always supposed to be preinstalled?
[12:45] <sergiusens> jdstrand: yes
[12:45] <jdstrand> cjwatson: did you ask asac to let it through to the image though?
[12:45] <ogra_> searching hellp doesnt reveal anything
[12:45] <jdstrand> sergiusens: I wonder if there should be a smoketest for them being available?
[12:45] <cjwatson> jdstrand: it's not in daily-release ...
[12:46] <sergiusens> jdstrand: well all of them (rssreader, clock, music, calendar,...) but they are currently debs today and are relying on those for testing
[12:46] <sergiusens> jdstrand: let me add one
[12:46] <ogra_> hmpf
[12:46] <jdstrand> sergiusens: cool, thanks :)
[12:47] <sergiusens> jdstrand: can I run the security tool on package build as well in the internal jenkins or is that a bad idea?
[12:48] <ogra_> hmm, i also get the into every boot
[12:48] <ogra_> that looks broken
[12:49] <sergiusens> ogra_: indeed... I find it hard to dismiss as it doesn't stay still either ;-)
[12:50] <ogra_> sergiusens, is --no-backup equivalent to wipe ?
[12:51] <sergiusens> ogra_: yes
[12:51] <ogra_> ok, trying that
[12:51] <sergiusens> ogra_: well, not equivalent entirely, backing up on system images is out of band while on cdimage it's inband
[12:52] <ogra_> well, i just want to get rid of the userdata
[12:52] <sergiusens> ogra_: then that's what you want
[12:52] <ogra_> to make sure there are no old settings interfering
[12:53] <jdstrand> sergiusens: the review tools? I personally wouldn't mind. do note the tools aren't public currently (that may change)
[12:53] <jdstrand> sergiusens: so the results shouldn't be either
[12:54] <jdstrand> well, maybe the errors... I don't know. I'm still not convinced they shouldn't be public :P
[12:54]  * jdstrand hates being a middle man
[12:54] <cjwatson> wow, review tools not public, so app authors don't know the rules they're operating under?
[12:54] <cjwatson> that just seems like a terrible idea
[12:55] <sergiusens> cjwatson: it is rather strange
[12:55] <stgraber> lool: I don't mind having this exported over rsync, however anyone running a mirror should be aware that it'll be rejected unless they also have a valid https certficate for it
[12:58] <asac> ogra_: did you figure how to install the image?
[12:58] <ogra_> asac, ??
[12:58] <asac> ogra_: you had problems installing the latest image above
[12:58] <ogra_> asac, there is nothing to figure out
[12:58] <asac> you had version 4
[12:58] <asac> and not 5:...
[12:59] <ogra_> i had no probalmes installing it, phablet-flasdh works fine
[12:59] <ogra_> there is no version 5
[12:59] <asac> lool: help
[12:59] <lool> stgraber: good point
[12:59] <ogra_> version 4 is the latest image phablet-flash can install
[12:59] <lool> asac, ogra_: ?
[12:59] <asac> ogra_: thats teh released image
[12:59] <ogra_> see the json file
[12:59] <asac> lool: ogra_ doesnt know how to test the 5:... image
[12:59] <lool> the pending one?
[13:00] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/
[13:00] <ogra_> the released one
[13:00] <asac> lool: 5:20130905.4:20130905.4
[13:00] <asac> ogra_: no the one above
[13:00] <lool> use --channel daily-proposed with phablet-flash, or edit channel.ini to set channel: daily-proposed instead of daily
[13:00] <asac> :)
[13:00] <ogra_> i'm using phablet-flash ubuntu-system ...
[13:00] <asac> ogra_: i wnated a confirm that the pending one is good
[13:00] <ogra_> which left me with a broken image
[13:00] <asac> ogra_: so we can push it
[13:00] <lool> ogra_: this will use the stable daily channel by default (== current)
[13:00] <ogra_> lool, right, and current is broken
[13:00] <asac> ogra_: well, it boots for me and i can use wifi etc.
[13:01] <ogra_> asac, you cant install click apps
[13:01] <ogra_> well, i cant
[13:01] <jdstrand> cjwatson: right-- I mean, we tell the devs what is wrong so they get the feedback. The argument is that people shouldn't know all the tests cause it is easier to circumvent them
[13:01] <asac> ogra_: thta might be a problem.
[13:01] <lool> I odnt have maguro
[13:01] <ogra_> asac, thats a hard blocker
[13:01] <asac> ogra_: now i want to know if the latest pending is any worse
[13:01] <asac> or better
[13:01] <lool> ogra_: I did see the bug you mention in some cases
[13:01] <jdstrand> cjwatson: of course it is easy enough to enumerate them with enough effort
[13:01] <lool> like a race on startup
[13:01] <jdstrand> I should bring this up again
[13:01] <asac> ogra_: but that image is already out
[13:01] <lool> ogra_: you could try locally stopping and starting your unity session
[13:01] <ogra_> asac, right, let me wait until that flash finishes ... i re-flashed with wipe just to be sure there os no user data interfering
[13:01] <lool> it wont help fix the race, but it should eventually work  :-)
[13:01] <asac> but yeah check with lool for a while
[13:02] <ogra_> asac, yes, that image is out
[13:02] <lool> TBH, I'm not the best person to debug the scope (alecu is I think) not starting, but I'm happy to help as much as I know
[13:02] <asac> ogra_: right. i want to get the next one out :)
[13:02] <asac> thats the idea
[13:02] <ogra_> and it seems either nobody tested maguro before releasing or my user setup breaks the world here (which would also be a bad bug)
[13:02] <asac> ogra_: well, we tested the RW image
[13:02] <asac> and switched over
[13:02] <asac> so now we have to fix what is left
[13:02] <sergiusens> ogra_: I've been using the images on maguro... haven't seen your issue
[13:03] <asac> and yes, it could have been done better, but then we would have had to wait even longer
[13:03] <cjwatson> jdstrand: I think this is silly - people shouldn't have to play guess-the-next-failure with us
[13:03] <ogra_> right, all i'm saying is that manual testing needs to switch to ro
[13:03] <asac> and keep two baselines in focus
[13:03] <stgraber> lool: oh and they'll also need to hijack the system-image.u.c domain since it's set in a file in the signed image. So yeah, our stuff is not terribly mirror friendly but I think we admited that it wouldn't pretty much at the beginning when we said that if we'd support mirrors, it'd be file-only mirrors (no indexes) and that we'd use http redirect from system-image to spread the load
[13:03] <ogra_> and needs to happen before we release
[13:03] <asac> ogra_: we announced that its the default
[13:03] <cjwatson> jdstrand: the requirements will be commonly known soon enough anyway
[13:03] <jdstrand> cjwatson: did I mention that I hate being the middle-man?
[13:03] <asac> ogra_: and hence i asked you to test touch_ro and not touch
[13:03] <asac> :()
[13:03] <ogra_> asac, we released something untested
[13:03] <cjwatson> jdstrand: *nod*
[13:03] <jdstrand> cjwatson: (ie, I agree ;)
[13:03] <ogra_> only referring to the test results doesnt suffice
[13:03] <cjwatson> ogra_: (FWIW grouper installed a click app fine for me)
[13:03] <asac> i know
[13:03] <jdstrand> I will bring it up again
[13:03] <asac> now
[13:04] <asac> lool: so can we fix that?
[13:04]  * sergiusens can install clicks on maguro on ro_images for a while now
[13:04] <ogra_> ok, after a wipe install i now get the unity plugins ... still no click
[13:05] <cjwatson> still no icons and duplicate entries, but we knew that
[13:05] <asac> ogra_: so for me click never really worked.
[13:05] <asac> ogra_: i never go tthe apps that i installed on the launcher anywwhere
[13:05] <asac> even in yesterdays RW image
[13:05] <ogra_> asac, click worked for me since a week or so in rwe
[13:05] <ogra_> *rw
[13:05] <asac> yeah for me never
[13:05] <ogra_> no issues
[13:05] <asac> so it wasn't a stable feature so i dont think its an all-stop blocker
[13:05] <ogra_> anyway, its not click thats broken
[13:06] <sergiusens> asac: I raised that issue on #ubuntu-unity, they aren't scanning .local/share/applications after the session has started
[13:06] <asac> ogra_: so check other features. like wifi, call etc.
[13:06] <ogra_> its unity missing the lens for it
[13:06] <lool> asac, ogra_: I think we're discussing a range of things here
[13:06] <cjwatson> sergiusens: right, that's a major source of confusion
[13:06] <asac> i dont even want to discuss this right now... i just wanted to know if TODAYs pending image is equal or better than yesterdays image on RO
[13:06]  * sergiusens just installed ushopper on a maguro ro_image and hit open
[13:06] <ogra_> lool, i only discuss one thing ... no click lens in a maguro install of the latest released system image
[13:06] <asac> and yes, i also wanted to know what painful blocker bugs we have
[13:07] <asac> :)
[13:07] <jdstrand> rsalveti (ogra_): I've been thinking about bug #1197133 and a short/mid term solution
[13:07] <lool> ogra_: this is your experience but sergiusens has a difference experience
[13:07] <cjwatson> sergiusens: it's workaroundable by rebooting after the first time you install an app, not that that's obvious
[13:07] <asac> lool: right. what ogra_ says feels important
[13:07] <lool> ogra_: what does the log show?
[13:07] <cjwatson> (the first time you install the first app, I mean)
[13:07] <cjwatson> just for accuracy's sake, click is a scope not a lens
[13:07] <sergiusens> cjwatson: I know, I do that myself :-)
[13:08] <ogra_> lool, i did a wipe install, log is gone
[13:08] <lool> ogra_: you're exaggerating with "no testing at all" claims
[13:08] <jdstrand> rsalveti (and ogra_): it is painful enough to maintain the apparmor policy now with 4 devices and it will become more and more painful and it is difficult on ports
[13:08] <lool> ogra_: it's on app startup
[13:08] <ogra_> lool, sergiusens didnt install from scratch
[13:08] <cjwatson> it provides data to the applications lens
[13:08] <lool> ogra_: I mean, when the scope starts, there should be logs
[13:08] <ogra_> lool, there are none
[13:08] <lool> ogra_: right, and QA has from scratch test runs
[13:08] <asac> davmor2: ok ... so ogra_ is distracted :) with click problems. can you check the RO image from daily channel and see if the daily-proposed is equal or better?
[13:08] <asac> :)
[13:08] <ogra_> lool, which use the phone and install click apps via the scope ?
[13:09] <asac> davmor2: actually not the latest daily-proposed, but 5:20130905.4:20130905.4
[13:09] <asac> thx
[13:09]  * asac waits
[13:09] <jdstrand> rsalveti (and ogra_): how hard would it be for our udev rules to create our graphics devices in something like /dev/graphics/ then symlink them all to /dev?
[13:09] <ogra_> jdstrand, that would most likely break the hardcoded paths in the binary blobs
[13:09] <jdstrand> rsalveti (and ogra_): then we have a single apparmor rule like: '/dev/graphics/* rw,'
[13:09] <jdstrand> ogra_: with a symlink?
[13:09] <ogra_> jdstrand, we and do links indeed
[13:10] <ogra_> (we already do for -dev-graphics iirc)
[13:10] <ogra_> */dev/graphics
[13:10] <jdstrand> eg. /dev/graphics/foocard is what udev creates and the we do /dev/graphics/foocard /dev/foocard
[13:10] <ogra_> s/and/can/
[13:10] <asac> lool: maybe we can land the fix for ogra's click problem together with ricmm's unity landing?
[13:10] <asac> feels like its related ... both land unity stuff
[13:10] <ogra_> jdstrand, root@ubuntu-phablet:/# ls /dev/graphics/
[13:10] <ogra_> fb0  fb1  fb2
[13:11] <ogra_> jdstrand, feel free to just add another rule (these link to /dev/fb*)
[13:11] <cjwatson> ogra_: do you have a ~/.cache/unity-scope-click.log at all?
[13:11] <jdstrand> ogra_: well, that is the wrong way around. /dev/graphics has the symlinks in it. apparmor derefences symlinks
[13:12] <cjwatson> ogra_: It might be worth tarring up ~/.cache and putting it somewhere for investigation
[13:12] <jdstrand> ogra_: so the rules all point to devices in /dev
[13:12] <lool> asac, ogra_ : In a call, brb
[13:12] <jdstrand> ogra_: I was unaware of /dev/graphics. let me back up
[13:12] <ogra_> cjwatson, yeah, and indeed the wipe install removed my wlan setup
[13:13] <jdstrand> ogra_ (and rsalveti): we have rules like this:
[13:13] <jdstrand>   # FIXME: Galaxy Nexus specific (maguro)
[13:13] <jdstrand>   /dev/pvrsrvkm rw,
[13:13] <ogra_> cjwatson, found the log now and enabled wifi ... phone is rebooting, lets see
[13:13] <jdstrand>   # FIXME: Nexus 4 (mako)
[13:13] <jdstrand>   /dev/kgsl-3d0 rw,
[13:13] <jdstrand>   /dev/ion rw,
[13:13] <ogra_> jdstrand, oh, yeah, you wont be able to move these
[13:13] <sergiusens> mzanetti: can you look at bug 1221720 (which you might know about already)
[13:14] <ogra_> they are hardcoded device names in the drivers
[13:14] <jdstrand> ogra_ (and rsalveti): I'd like /dev/pvrsrvkm /dev/kgsl-3d0 and /dev/ion (for example) to all be created under a single directory, and then symlink them back into /dev
[13:14] <jjohansen> jdstrand: there are otherways too
[13:14] <mzanetti> mhr3: do you know the status of that but?
[13:14] <mzanetti> bug
[13:14] <sergiusens> jdstrand: can apparmor cope if it's the other way around?
[13:15] <ogra_> jdstrand, that wont work
[13:15] <jdstrand> eg /dev/somewhere/ion. ln -s /dev/somewhere/ion /dev/ion
[13:15] <jjohansen> sergiusens: apparmor does its path resolution post symlink
[13:15] <jdstrand> jjohansen: I am all ears :)
[13:15] <ogra_> jdstrand, or well, try it and see, but i suspect a lot will break
[13:15] <sergiusens> then no :-)
[13:15] <alecu> lool: hi! I hear that the scope is not starting... is that on today's image?
[13:15] <jdstrand> ogra_: I wonder why a lot would break?
[13:16] <jdstrand> I also can't try it out on all hardware
[13:16] <ogra_> because the binary drivers have the device names hardcoded and want to access the devices directly ...
[13:17] <jdstrand> but I could on mako and grouper I guess. if it generally works, we could have it be the default and then only special case the ones that don't (icky)
[13:17] <ogra_> i'm not sure how clever they would be wrt following links so you need to try it out
[13:17] <stgraber> ogra_: open() against a device or against a symlink to that same device should make no difference
[13:17] <ogra_> but i imagine that many of them open the device directly
[13:17] <jdstrand> ogra_: right, that was what the symlink was for-- the drivers still use the path they know and love
[13:17] <ogra_> stgraber, well, someone try it :)
[13:17] <jjohansen> jdstrand: you could have udev create a rule in an include dir instead of a symlink
[13:17] <ogra_> if we dont lose accceleration ...
[13:18] <jdstrand> jjohansen: I'm not following-- the drivers expect a particular location
[13:19] <mdeslaur> jdstrand: udev creates the device, and creates an apparmor profile for it
[13:19] <jdstrand> jjohansen: and that location is currently /dev/<foo>
[13:19] <jdstrand> oh
[13:19] <jdstrand> I see
[13:19] <mdeslaur> but that assumes that binary drivers use udev, which is most likely not the case all the time
[13:19] <jjohansen> jdstrand: yes, and instead of having udev create a symlink like you suggest it could drop a rule into an include dir
[13:19] <mdeslaur> as udev can't be used by non-gpl stuff IIRC
[13:19] <ogra_> cjwatson, nothing changed after a reboot ... well, except that now the unity plugins dont even list click
[13:20] <jdstrand> I thought that we were using udev for all of those, and I don't think any are GPL
[13:20] <jdstrand> ogra_: ^
[13:20] <ogra_> (now with working wlan
[13:20] <ogra_> )
[13:20] <jjohansen> mdeslaur: why not its a userspace interface, which explicitly exempt from GPL
[13:20] <ogra_> we are using udev to set permissions and adjust device names via symlinks
[13:20] <ogra_> nothing more
[13:21] <mdeslaur> jjohansen: no idea, but I know the desktop nvidia drivers had to stop using udev, and it's the actual X driver that creates the device (yes!)
[13:21] <jdstrand> jjohansen, mdeslaur: I had been thinking about an include dir before. this would work for people that setup udev correctly as well as anyone who just wants to drop a file in there
[13:21] <ogra_> mdeslaur, probably libudev-dev or some such
[13:22] <ogra_> mdeslaur, here we are only processing scripts that largely do nothing more than ln and chmod/chown
[13:22] <lool> alecu: ogra has some issues with the scope on maguro
[13:22] <lool> alecu: with the latest stable image that we've promoted yesterday (image v4 on system-image)
[13:22] <lool> alecu: (with a fresh install)
[13:22] <lool> alecu: sergiusens on the other hand doesn't have the issue with an upgrade to version 4
[13:22] <lool> alecu: there's also a version 5 in daily-proposed, I don't know whether it fixes ogra_'s problem or not
[13:22] <jdstrand> jjohansen, mdeslaur: in the case of nvidia, it could drop a file in there on package install
[13:22] <ogra_> (fresh install means complete system wipe btw)
[13:23] <jdstrand> jjohansen, mdeslaur: this is an interesting idea
[13:23] <lool> alecu: I did see the click scope / app scope not starting in some of my older tests
[13:23] <alecu> ogra_: like "phablet-flash ubuntu-system --no-backup", right?
[13:23] <sergiusens> lool: I'm fresh installed
[13:23] <sergiusens> lool: and on daily channel
[13:23] <ogra_> alecu, exactly
[13:23] <alecu> sergiusens: freshly installed, do you have the .local/share/applications folder created?
[13:24] <ogra_> alecu, aha, i dont
[13:24] <mhr3> mzanetti, see the dupe
[13:24] <sergiusens> alecu: I'm not sure, but I did install ushopper
[13:24] <mdeslaur> jdstrand: yeah, that sounds reasonable...I don't think we'll manage to move the device creation for all the drivers
[13:24] <sergiusens> .local/share/applications/com.ubuntu.developer.majster-pl.ushopper_ushopper_0.1.5.desktop
[13:24] <alecu> ogra_: this looks like a rehash of an old bug
[13:25] <sergiusens> so who created the dir is unbeknown to be now
[13:25] <ogra_> alecu, ok, should i create it or do you want to dig anywhere first ?
[13:25] <alecu> sergiusens: the thing is that it should have been created before the scopes start, otherwise it's not scanned
[13:25] <cwayne_> Kaleo, ping
[13:25] <ogra_> alecu, the symptom for me is that there is no click lens in unity at all
[13:25] <ogra_> (not even in the "dash plugins")
[13:25] <alecu> ogra_: ah, that's different
[13:26] <sergiusens> alecu ogra_: I already created https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1221720 for scanning
[13:26] <plars> psivaa: I've been preemptively killing some of the duplicate ro jobs until we can land the converged ci branch. Once we do that, I'll add support for checking to see if we *really* have a new image, or if it's just stgraber's overzealous json updater :)
[13:26] <rah> my BoardConfig.mk includes wpa-relate entries
[13:26] <rah> like so:
[13:26] <rah>     BOARD_HOSTAPD_DRIVER        := NL80211
[13:26] <rah>     BOARD_HOSTAPD_PRIVATE_LIB   := lib_driver_cmd_rtl
[13:26] <cjwatson> tedg: Your comment about icon attacks that could survive in an XPM makes me think of the Langford Basilisk :-)
[13:26] <cjwatson> asac: oh, before I forget, livefs builds should be working again now
[13:26] <cjwatson> Actually a little while ago, I was doing some other things and not monitoring
[13:26] <rah> will this work in ubuntu touch?
[13:27] <ogra_> alecu, thats from the first two boots (afterwards i enabled wlan) http://paste.ubuntu.com/6070385/ ... it doesnt have logged anything for the three subsequent boots
[13:27] <sil2100> asac: hi! Can I poke you in like 1.5h (since now I'll have a meeting and then lunch) about releasing some of the stacks?
[13:27] <plars> psivaa: basically we're just waiting for a gap in the 5 rebuilds a day craziness at this point
[13:27] <mdeslaur> jjohansen: hrm, perhaps I'm misremembering the udev thing...I think it's having the kernel module create the device that's problematic
[13:27] <rah> or does ubuntu touch demand the use of its own hostapd-related libraries?
[13:27] <ogra_> rah, i dont think we have any hostap support yet
[13:28] <mdeslaur> jjohansen: ie: device_create
[13:28] <jjohansen> mdeslaur: could be though I would think the shim could do that, but then I have different opinions on that than other devs
[13:28] <ogra_> rah, rip it out, make a note and care about it later :)
[13:28] <tedg> cjwatson, Heh, if they can survive an XPM, I'm all for it ;-)
[13:28] <psivaa> plars: ack, i've just started to kill the dupe ones.. but was a bit too late for the earlier builds
[13:28] <asac> sil2100: yes we can also talk now
[13:28] <asac> cjwatson: awesome!
[13:28] <rah> I don't like the idea of ripping it out
[13:28] <asac> thx
[13:28] <asac> sil2100: lets talk about what to do before weekend etc.
[13:28] <rah> ogra_: I think I'm going to see if lib_driver_cmd_rtl can be included instead
[13:28] <ssweeny> pete-woods, ping
[13:29] <ogra_> rah, or that :)
[13:29] <mdeslaur> jjohansen: what, you're love of bsd licensing isn't shared by other kernel devs? :)
[13:29] <mdeslaur> s/you're/your/
[13:29] <jjohansen> hehehe :)
[13:29] <cjwatson> asac: I'd like to confirm that I've got the preinstallation stuff fixed ASAP so that I have another chance to fix it before the weekend if not.  If it's going to be more than an hour before you want to start the next full build, I'd like to do a test run
[13:29] <cjwatson> Otherwise I can piggyback on the output of the next full build
[13:29] <alecu> sergiusens: your bug sounds very similar to this: https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1204599
[13:30] <sil2100> asac: right, I'm having a meeting in a minute though, that's why I wanted to connect after lunch
[13:30] <sergiusens> alecu: it has already been marked a dup ;-)
[13:30] <lool> sergiusens: https://code.launchpad.net/~lool/phablet-tools/fix-sig-log/+merge/184298 (trivial)
[13:31] <lool> sergiusens: FYI, pyflakes: phabletutils/environment.py:159: local variable 'recovery' is assigned to but never used
[13:31] <lool> sergiusens: didn't fix the pyflakes one
[13:31] <sergiusens> lool: I'll look at that
[13:32] <asac> cjwatson: 1h sounds good. let me know when done
[13:32] <alecu> sergiusens: ah, that was fast :-)
[13:32] <asac> cjwatson: will we get a new img out of that as well?
[13:32] <cjwatson> asac: k, running
[13:32] <ogra_> oh, sigh
[13:33] <cjwatson> asac: no, I just ran it in debug mode, didn't want to accidentally publish something unapproved
[13:33] <asac> cjwatson: i dont care either way i think... just wondering :)
[13:33] <asac> ah cool
[13:33] <ogra_> why do i have to run through the intro every boot ?
[13:33] <asac> sounds good
[13:33] <asac> ogra_: thats probable a bug
[13:33] <ogra_> asac, yeah, i didnt have that on rw ...
[13:33] <asac> e.g. app not using the rw directory for settings
[13:33] <asac> ogra_: right. either our sdk didnt land their "transparent" shift
[13:33] <asac> or the app doesnt use sdk
[13:33] <asac> would be my guess
[13:34] <asac> (e.g. hardcoded home path)
[13:34] <plars> psivaa: it's done for the 06 ones at least
[13:34] <ogra_> aha !
[13:34] <asac> jdstrand: do you know if the SDK folks landed their "RW home dir location" thingy?
[13:34] <ogra_> 10 reboots later i suddenly have click in the dash pulgins
[13:34] <asac> nice
[13:34] <sergiusens> ogra_: so there's a race
[13:34] <ogra_> and it claims it is disabled
[13:34] <asac> i think thats the experience i also had on rw
[13:34] <asac> hmm or maybe not
[13:35] <asac> i think mine never showed up
[13:35] <jdstrand> asac: I'm not sure what you are referring to, so I am going to say "no, I don't know" :)
[13:35] <ogra_> clicking "enable" doesnt do anything though
[13:35] <alecu> ogra_: may I ask you to start the scope manually?
[13:35] <alecu> ogra_: G_MESSAGES_DEBUG=all /usr/lib/arm-linux-gnueabihf/unity-scope-click/click-scope
[13:35] <alecu> ogra_: (as the phablet user)
[13:35] <asac> jdstrand: well, sdk is supposed to provide a transparent mechnaism to find the "app home folder" where it can read/write
[13:35] <asac> jdstrand: they were supposed to do that with appid etc. remember?
[13:35] <ogra_> alecu, doing, one sec
[13:36] <lool> ogra_, asac: So it seems you folks are debugging, but it's confirmed ot be a race
[13:36] <asac> no i am not debuggin :)
[13:36] <lool> I saw this too myself, but only occasionally and was working on other bugs at that time
[13:36] <ogra_> lool, that definitely isnt a race here
[13:37] <lool> ogra_: didn't it work once for you?
[13:37] <asac> so let me try
[13:37] <asac> ogra_: you say i cannot install apps?
[13:37] <ogra_> lool, no, never
[13:37] <ogra_> asac, proabbly from cmdline ... i dont have the UI to install any apps here
[13:37] <davmor2> ogra_: asac right is there a way to check I have the right version on the system?
[13:37] <asac> ogra_: yeah its gone here too
[13:37] <ogra_> alecu, i assume that should print anything ?
[13:38] <asac> davmor2: thats a lool and stgraber question
[13:38] <ogra_> alecu, i get no output at all
[13:38] <asac> i hope the answer is "yes", thats easy
[13:38] <lool> davmor2: system-image-cli -i
[13:38] <ogra_> just sits there after issuing the command
[13:38] <asac> lool: that doesnt show if ou have .4 or .3 etc. does it?
[13:38] <alecu> ogra_: ok. Please try doing a search in the app tab of the dash
[13:38] <jdstrand> asac: I don't know if they have a transparent way. I can say that we are using XDG_<some basedir>/$app_pkgname for everything in the apparmor policy. there is Qt API to find the various XDG base dirs, so all they need to do is QtIForgetTheExactAPIForXDG('XDG_DATA_HOME') + '/$app_pkgname'
[13:38] <lool> asac: it does
[13:38] <asac> oh ok
[13:38] <asac> jdstrand: ic
[13:38] <asac> thxz
[13:38] <ogra_> alecu, yeah, there it is
[13:39] <ogra_> alecu, and a ton of output
[13:39] <asac> ogra_: so the intro probably doesnt use XDG dirs
[13:39] <asac> or that feature is broken
[13:39] <asac> mterry can look at it if he is up
[13:39] <ogra_> asac, the intro uses a dbus key (if you remember)
[13:39] <jdstrand> asac: not that app_pkgname is 'name' in the click manifest
[13:39] <jdstrand> asac: s/not/note/
[13:39] <asac> ogra_: yeah. who knows. maybe there are two switches :)
[13:39] <ogra_> asac, so i dont think it uses any XDG stuff additionally
[13:39] <ogra_> heh
[13:39] <ogra_> yeah, who knows
[13:40] <asac> but maybe dbus doesnt use that :)
[13:40] <asac> err
[13:40] <asac> or whatever is behind dbus
[13:40] <lool> So I tried on mako for the first time; the Ubuntu recovery splash / background image / menu isn't always showing up for me
[13:40] <lool> I thought it was always up for grouper
[13:40] <lool> and I see it sometimes
[13:40] <ogra_> wow
[13:40] <lool> but it's not clear to me why it's on / off at times
[13:40] <lool> is this normal?
[13:40]  * ogra_ never saw such behavior
[13:41] <asac> lool: so yeah i can confirm that i dont have the click things in applications
[13:41] <davmor2> meh still 5.3 according to /var/log/installer/media-info ogra_ are the instructions here correct https://wiki.ubuntu.com/Touch/Install#Manual_Download_.26_Installation  Looking at it you just flash the same zip file twice
[13:41] <lool> I mean the screen is black
[13:41] <asac> so i cant install anything
[13:41] <lool> recovery is running, unpacking the .tar.xz
[13:41] <jdstrand> asac: and *not* the full appid (ie, the one used by confinement/lifecycle/unity/etc which is ${app_pkgname}_${appname}_${app_version}))
[13:41] <stgraber> lool: hmm, I've never seen that here on mako
[13:41] <ogra_> davmor2, system-image-cli -i
[13:41] <asac> jdstrand: so the id is not needed anymore?
[13:42] <jdstrand> asac: needed for what?
[13:42] <asac> jdstrand: but you say that you know we set the XDG_ dirs on application startup?
[13:42] <asac> jdstrand: for guessing the path
[13:42] <lool> stgraber: BTW does uncompressing .xz use multiple core?  it's probably IO bound, but might be worth adding to our images some day  :-)
[13:42] <ogra_> asac, sudo -u phablet -i env
[13:42] <ogra_> :P
[13:43] <asac> ogra_: its per-application
[13:43] <asac> not global
[13:43] <ogra_> root@ubuntu-phablet:/# sudo -u phablet -i env|grep XDG
[13:43] <ogra_> XDG_RUNTIME_DIR=/run/user/32011
[13:43] <sergiusens> lool: check /tmp/recovery.log
[13:43] <asac> afaiui
[13:43] <xnox> make clean
[13:43] <ogra_> thats all XDG entries i have
[13:43] <davmor2> ogra_: root@ubuntu-phablet:/# system-image-cli -i  current build number: 0 device name: maguro channel: daily
[13:43] <asac> ogra_: you dont see the real once unless you get zstarted as an app
[13:43] <asac> afaiui
[13:43] <asac> e.g. we set that to a special dir for each app start
[13:43] <ogra_> davmor2, 0 ? thats intresting
[13:44] <davmor2> brb xchat is playing up
[13:44] <ogra_> asac, ah, the upstart stuff, yeah
[13:44] <sergiusens> xnox: cleaning backlog ...
[13:44] <jdstrand> asac: the XDG base dirs are guaranteed to be set. correct. Eg, XDG_DATA_HOME is ~/.local/share. the writable directory for the app under XDG_DATA_HOME is $XDG_DATA_HOME/$app_pkgname. app_pkgname = <'name' in the click manifest>
[13:44] <xnox> sergiusens: ENOFOCUSFOLLOWEYESIGHT
[13:44] <lool> asac, ogra_, alecu: So on a N4, booted with no network (fresh install, nothing on device), passed intro screen, didn't see any appstore apps suggested; ran phablet-network, still no apps, searched for "hello" in the app search at top right on second screen and eventually it found hello world app; it installed fine and ran fine
[13:45] <davmor2> ogra_: are the manual build instructions correct or am I just not reading it correctly?
[13:45] <lool> indeed I do lack all the preinstalled clicks though
[13:45] <lool> but the hello one works
[13:45] <ogra_> lool, right, doesnt work on maguro unless you start the lens manually from cmdline
[13:45] <sergiusens> lool: preinstalled is being fixed right now
[13:45] <ogra_> lool, else the search doesnt fire it up
[13:45] <lool> click list returns:
[13:45] <lool> ar.com.beuno.hello-world        0.6
[13:45] <lool> so it's correct
[13:45] <sergiusens> lool: preinstalling might have hid the lens bug
[13:45] <jdstrand> asac: in this scenario, the app developer is expected to know to call the Qt API to find $XDG_DATA_HOME and to append the $app_pkgname to it
[13:45] <lool> ogra_, asac: So are you guys speaking of preinstalled clicks, or of ones to add from the appstore?
[13:46] <alecu> lool: awesome. So, the click scope is not "retrying" when the connection is restored, so perhaps I should open a bug for it.
[13:46] <ogra_> lool, i'm only talking about the lens
[13:46] <lool> ogra_, asac: Preinstalled ones are known broken, sergiusens is working on these with colin
[13:46] <jdstrand> asac: the SDK could maybe make that easier. I don't think they have cause I don't know of any bugs for it
[13:46] <davmor2> ogra_: manual install even,  from what I can tell it basically says to flash saucy-preinstalled-touch-armhf.zip twice
[13:46] <ogra_> lool, its not there and doesnt come up unless i start it via adb
[13:46] <lool> ogra_: ok; I dont have maguro, so can't tell what's going on
[13:46] <sergiusens> lool: actually cjwatson is fixing (already fixed if you cross fingers)
[13:46] <lool> sergiusens: cool
[13:46] <asac> lool: hmm. would have loved to hear a big warning that preinstalled apps are broken :)
[13:46] <asac> anyway
[13:47] <ogra_> davmor2, we're using phablet-flash ubuntu-system now :)
[13:47] <sergiusens> lool: but not having them for a couple of iterations exposed https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1204599
[13:47] <lool> asac: I didn't know that myself
[13:47] <asac> so you didnt test :)
[13:47] <lool> asac: just summing up today's discussions here
[13:47] <asac> ic
[13:47] <lool> asac: uh
[13:47] <asac> ok so lets wait
[13:47] <davmor2> ogra_: and that will get the 5.4 version installed?
[13:47] <ogra_> lool, well, obviously it works when i run it from cli ... i guess alecu knows whats going on or we'll at least find out
[13:47] <asac> lool: so seems, you, sergiusens and cjwatson are checking out why we have no working click
[13:47] <asac> seems covered
[13:48] <asac> :)
[13:48] <ogra_> davmor2, that will get you the "4" system image
[13:48] <asac> ogra_: can we go back testing the rest?
[13:48] <lool> Yes, well not me, but whatever
[13:48] <asac> :)
[13:48] <asac> ogra_: like ignoring that?
[13:48] <X-c0d3> hi all
[13:48] <davmor2> ogra_: right give me 5 then
[13:48] <X-c0d3> ubuntu phone == ubuntu touch ?
[13:48] <ogra_> asac, how about fixing it before we release something that broken ?
[13:48] <asac> ogra_: we already released
[13:48] <ogra_> X-c0d3, yes
[13:48] <asac> no need to hold the rest back while we have all the priority that we can on that
[13:48] <X-c0d3> i can install on Samsung galaxy ?
[13:48] <lool> sergiusens: where could we run a test that verifies that "click list" isn't empty on the image testing?
[13:48] <alecu> ogra_: I really don't know why it was not started automatically past your second boot
[13:48] <asac> ogra_: as long as it doesnt get worse
[13:48] <asac> and yes, i hate it
[13:48] <jdstrand> asac: this is the API people should be using: http://qt-project.org/doc/qt-5.0/qtcore/qstandardpaths.html
[13:49] <lool> sergiusens: I think this would have caught this preinstalled click regression in the image
[13:49] <lool> (it's really an image thing)
[13:49] <alecu> ogra_: it ought to be started by the dash via dbus activation
[13:49] <sergiusens> lool: on the qa infra, I'm writing a test for that
[13:49] <ogra_> alecu, right
[13:49] <lool> sergiusens: <3
[13:49] <alecu> ogra_: and I only have mako to test
[13:49] <davmor2> ogra_: p-f ubuntu-system seems to be getting 5.1 not 5.4
[13:49] <lool> asac: So bottom-line, we lacked an integration test and sergiusens is adding it
[13:49] <asac> right
[13:49] <asac> davmor2: thats the released one
[13:50] <jdstrand> asac: so, based on that, the SDK could set QCoreApplication::organizationName and/or QCoreApplication::applicationName and all the dev would have to do is use QStandardPaths::DataLocation
[13:50] <asac> davmor2: the one we want to test from the -proposed pocket is 5.4
[13:50] <ogra_> davmor2, right
[13:50] <asac> davmor2: lool should know how to install that
[13:50] <asac> lool: ^^
[13:50] <ogra_> you need a switch
[13:50] <asac> i think we are back to where we started
[13:50] <asac> :)
[13:50] <ogra_> not completely
[13:50] <lool> davmor2: you want --channel daily-proposed
[13:50] <ogra_> i have a click lens now :P
[13:50] <ogra_> (even thogh started via adb)
[13:50] <asac> ogra_: well, with local around hacking
[13:50] <asac> :)
[13:50] <asac> not from the build
[13:50] <asac> yeah
[13:51] <davmor2> lool: thanks on it as soon as this finishes
[13:51] <cjwatson> sergiusens: Yeah, preinstalling might have done, though it depends on whether click hook install-user finishes before the lens starts
[13:51] <jdstrand> asac: (the same holds true for QStandardPaths::ConfigLocation and QStandardPaths::CacheLocation, though the docs don't mention QCoreApplication::organizationName and QCoreApplication::applicationName in reference to those)
[13:51] <lool> davmor2: https://lists.launchpad.net/ubuntu-phone/msg03988.html
[13:51] <lool> asac: please point people at https://lists.launchpad.net/ubuntu-phone/msg03988.html rather than me for future questions about versions and channels  :-)
[13:51] <asac> bzoltan: are you there?
[13:52] <jdstrand> asac: QString QStandardPaths::writableLocation(StandardLocation type) may also be an option, based on http://qt-project.org/doc/qt-5.0/qtcore/qstandardpaths.html#writableLocation
[13:52] <asac> bzoltan: can you tell me if we did something to ensure that all our apps use the right folders now with confindement?
[13:52] <jdstrand> asac: but I'm just readnig docs. I am not a Qt developer :)
[13:52] <asac> oSoMoN: are all apps ported to use the new paths for RO images?
[13:53] <asac> oSoMoN: do you know?
[13:53] <ogra_> stgraber, lool, so "system-image-cli -c daily-proposed" should get me to the proposed image ?
[13:53] <asac> ogra_: yeah. and i would like a honest answer if the same or more works than on todays image :)
[13:54] <asac> ogra_: would be nice if it was better as we then could already test the image upgrades in the wild
[13:54] <asac> by pushing it
[13:54] <cjwatson> asac: sorry, I thought I'd said a few times here that I was working on breakage with preinstalled apps, but I guess not prominently enough
[13:54] <asac> cjwatson: you surely did
[13:54] <ogra_> asac, thats what i'm trying
[13:54] <cjwatson> anyway, this test looks good at least from the log file
[13:54] <jdstrand> asac: your question to bzoltan is slightly different than what we are talking about
[13:54] <popey> hmm 20130905.4 dash seems a bit broken
[13:54] <ogra_> but system-image-cli seems to just sit there
[13:54] <jdstrand> asac: I can answer that. those bugs are still open
[13:54] <popey> search for an app, everything disappears
[13:54] <jdstrand> asac: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html
[13:55] <cjwatson> it's definitely now at least putting them on the image somewhere, which it wasn't before :)
[13:55] <lool> ogra_: I think so, albeit I never used this combination; I usually set channel in channel.ini, but what you wrote should work
[13:55]  * popey flashes 20130906
[13:55] <asac> cjwatson: cool. so next run will them on :)
[13:55] <asac> nice
[13:55] <asac> (after your testing etc.)
[13:55] <lool> ogra_: You can do a dry run with -v to see what would happen
[13:56] <jdstrand> asac: bug #1197060, bug #1197049, bug #1197051, bug #1197056
[13:56] <ogra_> lool, stgraber uuuh ... so after sitting there in my adb shell for 5min the device now rebooted without any warning ... thats pretty scary behavior
[13:56] <lool> cjwatson: yeah, I personally knew the new click would require some adjustments to preinstalled, but didn't think through that we had to coordinate the landing with an update to the image build config
[13:56] <ogra_> lool, stgraber, can we at least have it print some minimal info to stdout
[13:56] <lool> ogra_: that's the -cli verison
[13:56] <ogra_> yeah
[13:56] <lool> ogra_: if you don't want that, use --dry-run
[13:56] <cjwatson> lool: it would have been fine if I hadn't tried to fix builds outside the datacentre at the same time
[13:56] <lool> ogra_: the UI prompts before rebooting, not the CLI
[13:57] <cjwatson> ah well
[13:57] <jdstrand> asac: note, I talked to slangasek and bdmurray about how those bugs aren't showing up under ubuntu-sdk-bugs, even though they should be
[13:57] <ogra_> lool, no, it seems to do exactly what it should, its just that it didnt tell me anything
[13:57] <lool> ogra_: because it's for *real* killers
[13:57] <ogra_> haha
[13:57] <oSoMoN> asac: I don’t know, but we’re having a standup in 5mins, I can ask
[13:57] <lool> cjwatson: too many things in flight for everyone
[13:57] <ogra_> i.e. if i would be $random_dev i would eb scared now
[13:57] <asac> jdstrand: yeah thats cool. that list is helpful. so its fair to say that we would like to see those fixed
[13:57] <asac> for the RO system?
[13:57] <lool> it will all be fine if we just work over the whole week-end
[13:57] <cjwatson> lool: (that is, I was very careful to make sure it was compatible in the right ways so that it didn't require synchronised landings, I just screwed up the livecd-rootfs code)
[13:57] <lool> that way we can cope with the backlog
[13:57] <asac> oSoMoN: yeah. please double check. thx
[13:57] <stgraber> ogra_: -v should show you some more stuff (or add more -v if you want even more details), not sure how verbose -v is these days, I hope it's something sensible
[13:57] <asac> oSoMoN: we now focus on RO images
[13:58] <jdstrand> asac: those bugs I just mentioned must be fixed. right now apps can tamper with each other's data
[13:58] <asac> so you might loose your settings etc. if wrong
[13:58] <ogra_> stgraber, yeah, well, i would like it to friendly tell me at least that it now reboots into the upgrade or some such
[13:59] <jdstrand> asac: they can still webkit cookies, sniff history, modify sqlite databases, etc, etc
[13:59] <ogra_> great, so my click lens survived the upgrade ...
[13:59] <jdstrand> asac: s/still/steal/
[13:59] <bzoltan> asac: As far as I know apps are located in the right place
[13:59] <ogra_> which means i should do a fresh flash again to make sure my tinkering wasnt what fixed it
[13:59] <ogra_> :(
[13:59] <asac> bzoltan: do apps read/write to the right directories?
[13:59] <lool> ogra_: as I said, this is not for the faint of heart
[13:59] <ogra_> lool, lol
[13:59] <lool> ogra_: it might be better for you to stick with the stable released image!  :-P
[13:59] <ogra_> LOL
[13:59] <asac> jdstrand: so you need above fixed before you raise the apparmore confindement bar?
[14:00] <jdstrand> asac: I talked about those 4 bugs with kalikiana a while ago. I don't know the status
[14:00] <ogra_> lool, well, pending is definitely looking better, but since it was an upgrade i'm not sure now it wasnt my fiddling
[14:00] <asac> ogra_: hmm. reflash from scratch :)
[14:00] <jdstrand> asac: those bugs must be fixed for 13.10, otherwise there is confinement is ineffective
[14:00] <bzoltan> asac:  I do not know what apps do... they do whatever they do
[14:00] <jdstrand> s/there is//
[14:00] <ogra_> asac, yes, that will take a while (re-download)
[14:00] <asac> bzoltan: can the sdk support them in doing the right thing?
[14:01] <lool> ogra_: since userdata is preserved, .local/share/applications was likely preserved
[14:01] <bzoltan> asac: you think of black magic?
[14:01] <asac> bzoltan: i assume that the sdk already provides a transparent api
[14:01] <ogra_> lool, right
[14:01] <asac> that allows you to move home dirs etc.
[14:01] <lool> ogra_: don't forget to pass --no-backup
[14:01] <jdstrand> asac: well, I know the status of the bugs-- they are all open. I don't know what progress kalikiana has made
[14:01] <ogra_> lool, heh, surely not
[14:01] <bzoltan> asac: QML does not provide file system access... so it is not a porblem imo
[14:01] <lool> ogra_: but it might WIPE ALL YOUR DATA11!!
[14:02] <ogra_> OMG !!!
[14:02] <lool> ok ok I'll stop
[14:02] <asac> bzoltan: ok... and how about all our services? do they use qt?
[14:02] <ogra_> heh
[14:02] <lool> so going back to this seed
[14:02] <asac> bzoltan: and no app writes something to disk?
[14:02] <asac> right now?
[14:02] <jdstrand> bzoltan: I think what asac is asking is that if app devs use http://qt-project.org/doc/qt-5.0/qtcore/qstandardpaths.html, does the SDK set everything up for them to make it easier. eg, setting QCoreApplication::organizationName and QCoreApplication::applicationName
[14:02] <bzoltan> asac:  yes, most of the QML APIs ar based on Qt libs
[14:02] <ogra_> lool, doing fluendo ?
[14:02] <pmcgowan> asac, of course they do, what is the question?
[14:03] <asac> pmcgowan: i want to figure if all apps use the right folder now for their writing
[14:03] <asac> and if we can check that they do
[14:03] <lool> ogra_: yeah
[14:03] <lool> ogra_: I'll self-approve myself
[14:03] <Jagst3r15> Will Ubuntu touch have its own marketplace?
[14:03] <ogra_> lool, thanks for doing that, i really dont want my name near that upload :P
[14:03] <bzoltan> jdstrand:  we do not do anything special with these stuff
[14:03] <jdstrand> bzoltan: we also must have #1197060, #1197049, #1197051 and #1197056 fixed
[14:03] <asac> pmcgowan: context -> RO image
[14:03] <ogra_> Jagst3r15, it does already
[14:04] <sergiusens> Jagst3r15: it already has
[14:04] <pmcgowan> asac, the profile will ensure that they do, I do not thing we have anything that helps them get the path
[14:04] <Jagst3r15> tablet and phone share the same?
[14:04] <cjwatson> yes
[14:04] <ogra_> sergiusens, well, sometimes *g*
[14:04] <asac> pmcgowan: so most apps currently use hard coded paths?
[14:04] <Jagst3r15> how many apps are there
[14:04] <asac> i think we should then evangelize how to do it right somehow
[14:04] <asac> and clean our apps up a bit
[14:04] <cjwatson> not that many yet, we're just getting the app system going
[14:05] <wellsb> Is there a way to apply a custom stylesheet to a webview?
[14:05] <pmcgowan> asac, I am not sure for example how gallery gets the /Photos dir, but I assume it does so the right way
[14:05] <joe_b> Is there a way to disable the over the air update if you decide to go the "/userdata/.writable_image" route and use apt-get?
[14:05] <lool> ogra_: why is that?
[14:05] <pmcgowan> asac, I think I understand the question, let me find out
[14:05] <lool> ogra_: risky, or due to the mp3 stuff?
[14:05] <ogra_> lool, i still dont think it is right
[14:05] <ogra_> mp3
[14:05] <jdstrand> bzoltan: note, I am not trying to reprioritize those. kalikiana is assigned, they are all prioritized as 'high' and kalikiana is assigned. I am only mentioning them here since asac was asking about them
[14:05] <lool> oh ok
[14:05] <pmcgowan> asac, also assume we wouldnt have a green dash if anything was amiss
[14:06] <cjwatson> lool: do we know that it isn't going to get linked into GPL applications/
[14:06] <cjwatson> ?
[14:06] <ogra_> lool, read the bottom note on the fluendo page
[14:06] <Jagst3r15> cjwatson any place I can see the apps
[14:06] <lool> cjwatson: the fluendo one can be
[14:06] <asac> pmcgowan: right. i think i onbserved the camera hanging after a photo (felt like it had problems writing to disk)
[14:06] <ogra_> lool, no, it cant
[14:06] <asac> pmcgowan: and then ogra was just saying that we didnt remember that he already skipped the intro on reboot
[14:06] <ogra_> lool, the above mentioned note explicitly says that
[14:06] <asac> so i sensed maybe there is something looming.
[14:06] <asac> pmcgowan: thanks!
[14:06] <cjwatson> lool: http://www.fluendo.com/shop/product/fluendo-mp3-decoder/
[14:06] <cjwatson> disagrees with you
[14:07] <cjwatson> Jagst3r15: they're starting to appear in the applications page on very recent images
[14:07] <cjwatson> I don't know if there's a web view yet
[14:07] <davmor2> ogra_, asac, lool:  Right asac wants me to test 20130905.4 if I do phablet-flash ubuntu-system I get 20130905.1 if I do phablet-flash ubuntu-system --channel=daily-proposed I get 20130906 so for 5.4 I would need to install it manually right?
[14:07] <Jagst3r15> oh ok
[14:07] <lool> cjwatson: "with our binary MP3 plug-in"
[14:07] <asac> lool: help davmor2 :)
[14:07] <lool> cjwatson: the binary one specifically, yes?
[14:08] <asac> he needs to select the previous image not the latest in -proposed
[14:08] <Jagst3r15> I cannot test it on an iPhone?
[14:08] <bzoltan> jdstrand: I believe that most of these issue can be solved by setting the XDG_.* environment variables
[14:08] <ogra_> davmor2, i dont think there is a manual method for system images
[14:08] <lool> davmor2: you can set the revision like -r -1 to get the prior revision to the last one, or -2 to get the one prior to that
[14:08] <cjwatson> lool: ah, well, if you plan to risk MP3 patents instead ...
[14:08] <ogra_> Jagst3r15, not until apple provides an android port for iphones or opens up their HW specs
[14:08] <Jagst3r15> k
[14:09] <ogra_> lool, the text says "resulting binary" ... at least in german
[14:09] <cjwatson> lool: (yes, indeed, I think it's just the licensed binary that is GPL-incompatible)
[14:09] <balloons> plars, ok so I'm confused.. why is filemanager not running with the updated package?
[14:09] <Jagst3r15> you think google will release apps for ubuntu phone?
[14:09] <davmor2> lool: so that would be phablet-flash ubuntu-system --channel=daily-proposed -r -1 correct ?
[14:09] <lool> ogra_, cjwatson: Also note that we strip the proprietary source files from the tree
[14:09] <cjwatson> ogra_: I think you need to read the whole paragraph there rather than just picking two words from it
[14:09] <ogra_> hmm
[14:11] <cjwatson> lool: the main thing that's always been GPL-incompatible about this is needing a patent licence and not extending it to downstreams
[14:11] <barry> mandel: https://wiki.ubuntu.com/DownloadService/SpecialUsesCases (link does not exist).  perhaps add it as an anchor on that page?
[14:11] <ogra_> anyway, as long as lool signs that upload and seed change i dont care ... we discussed that long enough
[14:11] <lool> cjwatson: right
[14:11] <cjwatson> lool: if we think we don't need one nowadays and can use the open source code, then I guess it isn't a problem
[14:12] <mandel> barry, I need to create it, I'll do in a few mins
[14:12] <asac> davmor2: so i want to know two things: does that image carry regression compared to what you get without --channel
[14:12] <asac> and 2. what bugs beyond our RW do we have
[14:13] <asac> the 2. is not so important though right now
[14:13] <asac> rather something we can look at after to prioritize how to fix the regressions
[14:13] <asac> that we didnt see
[14:13] <barry> mandel: thanks
[14:13] <plars> balloons: no idea
[14:13] <asac> davmor2: are you unblocked? :)
[14:14] <plars> balloons: where are you seeing that?
[14:15] <davmor2> lool, asac : davmor2@boromir:~/Downloads$ phablet-flash ubuntu-system --channel=daily-proposed -r -1 usage: phablet-flash [-h]  ... phablet-flash: error: unrecognized arguments: -r -1   :'(
[14:15] <balloons> plars, https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-ubuntu-filemanager-app-autopilot/74/artifact/clientlogs/utah.yaml/*view*/
[14:15] <balloons> from http://reports.qa.ubuntu.com/smokeng/saucy/image/4026/ubuntu-filemanager-app-autopilot/
[14:15] <rah> when do Android.mk files get called?
[14:16] <rah> I have a directory with an Android.mk file which isn't getting evaluated
[14:16] <rah> which I know because I put an $(info ...) call in it but it's not doing anything
[14:16] <rah> I don't get any message when I run "make"
[14:16] <davmor2> asac: 5.1 is lovely no idea about 5.4
[14:16] <asac> lool: hey ... we really need your help here :)
[14:17] <cjwatson> davmor2: it's --revision rather than -r
[14:17] <asac> sergiusens: ^^
[14:17] <asac> thanks cjwatson
[14:17] <oSoMoN> Wellark: hey, when you have a moment, can you please approve https://code.launchpad.net/~osomon/webbrowser-app/remove-hud-dep/+merge/184240 ?
[14:17] <davmor2> cjwatson: thanks
[14:17] <cjwatson> -r is just in cdimage-legacy AFAICS
[14:18] <lool> there's a -r with ubutnu-sytem too
[14:18] <cjwatson> nope
[14:18] <cjwatson> not in current code
[14:18] <lool> sorry, --revision
[14:18] <cjwatson> as I said ... :-)
[14:18] <davmor2> thanks guys
[14:18] <lool> Ah missed that
[14:18]  * lool puts on his glasses
[14:18] <lool> I'm an old man
[14:18] <lool> you wouldn't shout at an old man
[14:19] <davmor2> lool: an old vane man if you're not wearing the glasses you need to read with
[14:19] <davmor2> :D
[14:20] <jdstrand> bzoltan: well, maybe, but we don't set XDG to the app specific package name. see https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement#Launching_applications
[14:21] <jdstrand> bzoltan: the bugs have updated information. kalikiana knows what to do aiui
[14:21] <bzoltan> jdstrand: I understand... and other than setting the XDG variables I do not see much option
[14:21] <jdstrand> bzoltan: I disagree. we can talk about each bug
[14:21] <jdstrand> bzoltan: bug #1197049
[14:21] <bzoltan> jdstrand: I hope to be wrong :)
[14:22] <jdstrand> bzoltan: I have a question in comment #6: "In reading unixTempFileDir(), I think this bug may be fixed by setting TMPDIR in the first place (something we plan to do). How can I test for this with an SDK application?"
[14:22] <jdstrand> bzoltan: we are setting TMPDIR now, but I don't have a way to test it
[14:22] <jdstrand> bug #1197051
[14:22] <plars> balloons: that looks like the same number of failures we got before though, right?
[14:23] <jdstrand> bzoltan: kalikiana said he knew how to fix this based on some stuff in the qml mainView (iirc). need to ask him
[14:23] <bzoltan> jdstrand:  The bug #1197049 seems to be covered then. Cool
[14:23] <jdstrand> bug #1197056
[14:24] <lool> davmor2: what are you saying?  can't hear you
[14:24] <balloons> plars, yes, those failures should be gone.. we need the new version that fixed them
[14:24] <bzoltan>  jdstrand: I need to ask kalikiana.
[14:24] <jdstrand> bzoltan: the same sort of fix for 1197051 could be used there
[14:24] <plars> balloons: oh, I misread
[14:24] <plars> balloons: I thought you were asking why it *IS* running with the new package :)
[14:25] <seb128> cjwatson, how wrong would it be to list the pkgdir in the manifest? ;-) I made the code calling click pkgdir, to resolve the icons, but each call takes ~0.1s on my laptop (didn't test on the device yet), which means that resolving the icons take at least 1.5 seconds for 15 click packages installed ... aka I'm going to need to make that code async if I do that
[14:25] <asac> balloons: which version do you need?
[14:25] <balloons> plars, LOL.. no sorry.. It's still running .5.9, and the new packages is .6
[14:25] <asac> balloons: is that staged in a stack?
[14:25] <jdstrand> bzoltan: yes, please follow up with him. I unblocked him a while ago and he seemed confident at the time not only on the general approach, but also something that would be upstreamable
[14:25] <asac> ok seems sorted
[14:25] <plars> balloons: yeah, asac and I were just talking about it a minute ago actually
[14:25] <balloons> asac, plars we had this conversation yesterday about it still running the old version
[14:25] <plars> balloons: I was happy to see a lot of fixes coming in last night
[14:25] <balloons> I assumed it would be fixed today
[14:26] <jdstrand> bzoltan: as a last resort for 13.10 if we can't get it in in time, we could patch qt to change the path if UBUNTU_APPLICATION_ISOLATION is set. I mentioned this to kalikiana and he felt we shouldn't have to resort to this
[14:26] <asac> pmcgowan: just remembered what i thought earlier today on the "our test will catch this" ... we currnetly have devices forced to RW until we have cleaned up all the apt-get magic etc. from tests. so unfortunately we dont see these yet. from what i understand we try to change this next week
[14:26] <plars> balloons: did you talk to sil2100 or asac about whether it would be possible to pull it in? I guess autolanding is still off?
[14:26] <cjwatson> seb128: maybe I can make it an option
[14:27] <asac> balloons: right if you go through daily-release we will pick it up soon
[14:27] <cjwatson> seb128: file me a bug?
[14:27]  * asac waits for sil2100 
[14:27] <asac> to get off call
[14:27] <bzoltan> jdstrand:  Ok, sounds good. Thanks for the update... we did not talk about these issues recently. I will check with kalikiana
[14:27] <asac> balloons: just tell us where it is
[14:27] <mdeslaur> jdstrand: re: graphics devices...wouldn't it be better if the apparmor file would get dropped into place by the packaging, instead of the udev rule?
[14:27] <davmor2> lool, cjwatson, asac: Right phablet-flash ubuntu-system --channel=daily-proposed --revision -1 this seems to of got Version 4 now which I'm assuming  is the 20130905.1 I already have install and not the 20130905.4 which is one daily revision behind 20130906
[14:27] <mdeslaur> jdstrand: I can't help but think the udev rule would be kind of fragile
[14:27] <pmcgowan> asac, but anyone who runs the RO image would immediately see issues yes? so are there any known ones?
[14:28] <jdstrand> mdeslaur: which package?
[14:28] <balloons> asac, plars I'm just confused that other packages got updated -- for instance the clock and calendar changes showed up today
[14:28] <davmor2> can I cry now
[14:28] <lool> davmor2: you can check with system-image-cli -i
[14:28] <mdeslaur> jdstrand: whatever package the graphics driver ships in
[14:28] <asac> pmcgowan: as i said, i saw camera app freezing when it tries to save the picture earlier today
[14:28] <asac> and ogra just say something that felt like "something didnt get save"
[14:28] <davmor2> lool: I will when it comes up
[14:28] <jdstrand> mdeslaur: I had been thinking that beofre, but that doesn't really work for ports
[14:29] <jdstrand> mdeslaur: there are a gagillion things that use RUN in udev
[14:29] <lool> davmor2: I don't think we have any 05.4 left, no
[14:29] <ogra_> pmcgowan, i get the intro on every boot in the ro image ... and only on first boot in the rw one
[14:29] <lool> davmor2: check the index.json for your device to find the image you really want?
[14:29] <jdstrand> all we need to do is make sure a directory exists and create a file
[14:29] <mdeslaur> jdstrand: I don't see the difference between shipping in the udev rule that's in the device package, or shipping the apparmor file in the device package
[14:29] <asac> lool: can we please please please fix that?
[14:29] <pmcgowan> ogra_, I see so they are dropping the done this turd somewhere incorrect
[14:29] <lool> davmor2: search for "full" ones, and then count from the highest "version" to the one you want
[14:30] <asac> we need to keep the proposed builds availabvle
[14:30] <pmcgowan> ogra_, is that bugged?
[14:30] <asac> stgraber: ^^
[14:30] <lool> stgraber: ^ asac wants to keep all full images in daily-proposed
[14:30] <ogra_> pmcgowan, not yet, i wanted to wait for mterry, probably its something easy and obvious
[14:30] <balloons> plars, asac d'oh.. the build failed.. https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+sourcepub/3464570/+listing-archive-extra.
[14:30] <pmcgowan> ogra_, ack
[14:30]  * balloons inserts foot into mouth
[14:30] <asac> yes we need to... we basically parallelize processes
[14:30] <jdstrand> jjohansen: you suggested the RUN idea, do you have an opinion on what mdeslaur said ^
[14:30] <asac> and cant wait with producing a new image until we have the other all tested
[14:31] <asac> davmor2: so guess if its really gone, please do 06
[14:31] <asac> and we wait for the image to arrive
[14:31] <asac> err dashboard results
[14:31]  * asac sad
[14:31] <jjohansen> jdstrand: err, give me a sec I haven't been following the conversation
[14:31] <rah> there is a product package in my device which needs libhardware
[14:31] <rah> it's for audio
[14:31] <asac> lool: stgraber: so would be good if we could still make it available to davmor
[14:31] <asac> and then publish
[14:31] <jdstrand> mdeslaur: I kinda like the run idea, because it means that you have only the rules that are specific to your hardware
[14:31] <lool> asac: there's a change to seed qtdeclarative5-friends-plugin in my upload; it's from mhall; is this ok?
[14:32] <rah> it seems to need something from audio.h
[14:32] <asac> lool: if we cant release images its not ok to add more
[14:32] <rah> is libhardware available on Ubuntu Touch?
[14:32] <mdeslaur> jdstrand: perhaps, but now we have to make sure we add udev rules for all the known devices
[14:32] <asac> davmor2: can you get 06? does that work?
[14:32] <jdstrand> mdeslaur: the udev rules are already there
[14:33] <mdeslaur> jdstrand: oh? for all devices?
[14:33] <mdeslaur> jdstrand: what about ports?
[14:33] <jdstrand> mdeslaur: this doesn't mean you can't ship in packages
[14:33] <lool> asac: I dont completely understand the point
[14:33] <lool> asac: in the end what matter is that you test the latest pending
[14:33] <rah> hello?
[14:33] <asac> lool: how can we continue if we cant produce a good image
[14:33] <lool> Ok, it's nice sometimes to be able to go back to an older one
[14:33] <asac> and release it?
[14:33] <asac> lool: no
[14:33] <lool> asac: we fix the image and then release it?
[14:33] <asac> its not
[14:33] <jdstrand> mdeslaur: their porting will require creating a udev rule, presumably. when they do that, they just add RUN+= to it. it will be documented in the porting guide
[14:33] <asac> we have multiple images
[14:33] <asac> validate them in parallel
[14:33] <mdeslaur> jdstrand: also, won't we need to add some dependencies in the upstart jobs to make sure udev gets run first?
[14:33] <asac> now w cant validate a good one
[14:33] <asac> to release it
[14:34] <asac> and have to start from scratch
[14:34] <asac> thats not good
[14:34] <asac> for sure
[14:34] <jdstrand> mdeslaur: sure, we could instead say "and create this apparmor rules file"
[14:34] <asac> davmor2: http://system-image.ubuntu.com/daily-proposed/mako/
[14:34] <asac> there are still 4.1
[14:34] <asac> can you copy them as long as they are there?
[14:34] <lool> asac: we're not setup to test multiple candidate images at once
[14:34] <asac> davmor2: oh never mind
[14:34] <jdstrand> mdeslaur: but that means they need to know apparmor syntax. using RUN in a manner similar to what I specified means they don't
[14:34] <asac> lool: we dont want to delete
[14:34] <asac> period
[14:34] <seb128> cjwatson, https://bugs.launchpad.net/ubuntu/+source/click/+bug/1221760
[14:34] <asac> until we have a new release at least
[14:34] <lool> particularly because you'd need a separate channel to hold each set of deltas
[14:34] <asac> lool: we want to go back and forth in the poroposed pocket
[14:34] <lool> asac: we want to delete the deltas
[14:35] <asac> the previous approach worked
[14:35] <mdeslaur> jdstrand: so the udev RUN is going to rebuild the apparmor rules?
[14:35] <asac> we could easily release the image from yesterday
[14:35] <jjohansen> jdstrand: I like the dynamic creation, better than just shipping a file in the package
[14:35] <lool> we didn't have deltas
[14:35] <asac> now we cannot even test a good image because its gone
[14:35] <lool> the big difference is that the previous image matters
[14:35] <asac> i know... but i want those to be there still
[14:35] <asac> just because we do a quick respin
[14:35] <jdstrand> mdeslaur: the RUN rule will not reuild the rules. it doesn't have to. the apparmor syv initscript is what (re)loads the policy. that is way after all other upstart jobs
[14:35] <asac> doesnt mean we have to reset all our validation
[14:35] <asac> if its good it can go out
[14:36] <lool> in that case I think we should defer upgrade testing in favor of allowing this; I'll check with stgraber when he's back
[14:36] <lool> asac: well he wanted to keep the fulls
[14:36] <asac> yeah. its fine to install full from proposed
[14:36] <davmor2> root@ubuntu-phablet:/# system-image-cli -i current build number: 4 device name: maguro channel: daily-proposed
[14:36] <asac> and just upgrade from daily to daily
[14:36] <asac>  for now
[14:36] <mdeslaur> jdstrand: and how do you know you haven't started the calculator before the apparmor sysv job gets run?
[14:36] <asac> davmor2: so we dont ge the 5: build at all?
[14:37] <asac> davmor2: thats with --channel=daily-proposed?
[14:37] <jdstrand> mdeslaur: that is a different problem that we have now
[14:37] <lool> asac: so how do you validate upgrades in parallel?
[14:37] <asac> i am not sure what you mean
[14:37] <maximilian1st> Hey, you must have had dozens of the following question but I can't seem to find an archive of this irc channel... Now the ubuntu-system image is read only, how do I change the timezone to my current one? I used to "echo "America/New_York" | sudo tee /etc/timezone" and then dpkg reconfigure the thing and it worked.
[14:37] <ogra_> asac, well, we cant completely drop testing of RW images (since the community bases on them, they should at least get some QA) ... we should probably use RW for gatekeeping  if the system image setup cant offer that feature
[14:37] <lool> asac: e.g. 4 is current, 5 and 6 are in proposed, how do you validate 4 -> 5 and 4 -> 6 in parallel?
[14:37] <jdstrand> mdeslaur: it may not be a problem. I should rather say-- that is a different question that applies to now as well
[14:37] <asac> ogra_: you complained above that we didnt test the RO image properly
[14:37] <mdeslaur> jdstrand: how do you know the udev job gets run before the apparmor job?
[14:37] <asac> ogra_: now we want to test it and its not available anymore
[14:38] <ogra_> asac, well, the deltas are regenerated once a new cdimage image comes up
[14:38] <lool> ogra_: new baseline is RO image
[14:38] <asac> lool: every build has a diff to the last baseversion
[14:38] <asac> then you can upgrade to it
[14:38] <davmor2> asac: that was davmor2@boromir:~/Downloads$ phablet-flash ubuntu-system --channel=daily-proposed --revision -1
[14:38] <asac> from the last release version
[14:38] <ogra_> lool, yes, but ports will have to use RW, so we cant drop that completely
[14:38] <asac> davmor2: give up on that
[14:38] <ogra_> lool, and cdimage pffers the feature asac wants
[14:38] <jdstrand> mdeslaur: the apparmor job is not an upstart job. it is a sysv init script. that happens after the devices come up
[14:38] <stgraber> lool: we'll have more flexibility in that regard with the new import-cdimage. We should then be able to have more than one pending image in proposed each with deltas from the latest stable image in daily.
[14:38] <davmor2> asac: I can just do davmor2@boromir:~/Downloads$ phablet-flash ubuntu-system --channel=daily-proposed instead and work from that
[14:38] <asac> davmor2: drop the --revision
[14:39] <asac> davmor2: and test 06
[14:39] <asac> davmor2: the other image is gone
[14:39] <asac> wiped
[14:39] <asac> zeroed :)
[14:39] <mdeslaur> jdstrand: how do you know it happens after the devices come up?
[14:39] <asac> davmor2: so we have to finish testing before the next image comes out
[14:39] <ogra_> lool, my suggestion is simply to use cdimage as gatekeeper, once the image there is good, move up one level and test ro
[14:39] <ogra_> and then release
[14:39] <mdeslaur> jdstrand: AFAIK, they are run in parallel
[14:39] <stgraber> lool: however system-image-cli will always try to pick up the latest one, so you'd have to force flash the specific one you want (or we'd need to grow a flag to system-image-cli giving it the target version we want to reach)
[14:39] <asac> ogra_: you just complained above that we dont test RO
[14:39] <davmor2> asac: Saving to: ‘/home/davmor2/Downloads/phablet-flash/imageupdates/daily-proposed/ubuntu/ubuntu-20130906.full.tar.xz’ is now happening
[14:39] <asac> ogra_: now you ask wehsould just release without RO testing
[14:39] <asac> ogra_: so no... we test RO :)
[14:39] <asac> thats what we release
[14:39] <ogra_> asac, read my last sentence again :)
[14:39] <jdstrand> mdeslaur: aiui, there is an upstart job to run the sysv init scripts, and that already has the dependencies. perhaps we should get slangasek in on this
[14:40] <lool> stgraber: asac considers it's too critical because it's needed for his current image releasing process; what could we do to keep images?  could we turn the garbage collection off until the new import-image is done?
[14:40] <asac> ogra_: well, we can just test ro
[14:40] <asac> in your case if we test rw
[14:40] <asac> and then ro is gone
[14:40] <asac> we couldnt release either :)
[14:40] <cjwatson> seb128: thanks
[14:40] <seb128> cjwatson, thank you for considering it! ;-)
[14:40] <rah> is libhardware available on Ubuntu Touch?
[14:40] <ogra_> asac, ro will always be the delta to the last good image
[14:40] <lool> ogra_: cdimage is a bad gatekeeper; issues might show up there that don't show up on ro and vice-versa
[14:40] <stgraber> lool: nope, because of us re-using the build numbers, it's not currently possible and requires a rewrite of the importer logic
[14:40] <asac> ogra_: RO Is deleted now
[14:40] <asac> thats the point
[14:40] <asac> we dont have it :)
[14:41] <ogra_> asac, the delta was updated to have the latest bits
[14:41] <jdstrand> mdeslaur: I should also note that the file potentially not being there is only a problem the first time the system has come up with the udev rule
[14:41] <asac> ogra_: which delta?
[14:41] <stgraber> lool: however, currently there's nothing that prevents you from publishing an older one so long as it exists on cdimage, you just can't test it from daily-proposed since it's gone from there
[14:41] <asac> ogra_: the .4 delta is gone
[14:41] <asac> we only have a new 6 delta now
[14:41] <asac> the other is finito :)
[14:41] <ogra_> asac, what i'm saying is, hold back the delta generation until cdimage tests pass
[14:41] <ogra_> asac, then do a ro test
[14:41] <jdstrand> mdeslaur: after that, the file will always exist and be overwritten by the RUN rule
[14:42] <davmor2> asac: right flashing 06 now
[14:42] <asac> ogra_: i think thats all not ok. lool and stgraber will just fix it so its possible to install older images from proposed
[14:42] <mdeslaur> jdstrand: what happens if the apparmor script runs _while_ the RUN rule is rewriting the file?
[14:42] <asac> ogra_: its a good idea to workaround
[14:42] <rah> -rw-rw-r-- 2 rah rah 64747678 Sep  6 14:41 out/target/product/a1000g/cm-.zip
[14:42] <mdeslaur> jdstrand: it all seems really racy and unreliable to me
[14:42] <asac> ogra_: but ultimately our channel concept should offer that feature
[14:42] <rah> why is my tarball called "cm-.zip"?
[14:42] <asac> popey: can you pretest 06 as well?
[14:42] <rah> it looks like there's somthing missing from the file name
[14:42] <mdeslaur> jdstrand: also, won't the file date change, and force the profiles to regenerate at each reboot?
[14:42] <asac> plars: we need to poke 06 through automation as quick as possible
[14:43] <ogra_> asac, ok, if the concept offers it ... (i dont see that atm)
[14:43] <asac> :)
[14:43] <lool> stgraber: can we just run daily-proposed like we run daily?  we'll lack the proper deltas from base, but that's only needed for upgrade testing
[14:43] <plars> asac: well, it's running now, there's really nothing I can do to speed it up
[14:43] <lool> technically a regression, but should work until we have the new script
[14:43] <asac> plars: ok... just whisle then a bit :)
[14:43] <plars> asac: I'll cheer it on from the sidelines :)
[14:43] <rah> anyone?
[14:43] <asac> plars: ok and tell us when it fails
[14:43]  * ogra_ hands plars some pompoms
[14:44] <rah> Beuler?
[14:44] <asac> because then we can already stop davmor2 testing :)
[14:44] <rah> Beuler?
[14:44] <asac> and popey :)
[14:44] <rah> Beuler?
[14:44] <cwayne_> stgraber, ping
[14:44] <stgraber> lool: so long as you're fine with the published image (in daily) having a different version from that in daily-proposed and having the image re-generated when copied, yes that's possible
[14:44] <stgraber> cwayne_: pong
[14:44] <joe_b> stgraber, Is there a way to disable the over the air update if you decide to go the "/userdata/.writable_image" route and use apt-get?
[14:44] <stgraber> lool: and obviously, not having deltas
[14:44] <ogra_> rah, there is no such thing like libhardware in ubuntu i think
[14:44] <rah> ogra_: ok
[14:44] <cwayne_> stgraber, should that initrd be in today's image?  im still seeing ~/.local owned by system
[14:44] <jdstrand> mdeslaur: we could solve the date changing
[14:44] <stgraber> joe_b: no, though we don't auto-update, so just don't click the download button and you'll be fine
[14:44] <plars> asac: so far it's a lot of green on the jenkins side
[14:45] <lool> stgraber: we could copy the whole of daily-proposed to daily when we promote an image to keep numbers?
[14:45] <plars> asac: calendar seems to fail, but it failed before too
[14:45] <rah> ogra_: is "cm-.zip" an appropriate name for the output .zip file?
[14:45] <ogra_> rah, i'm pretty sure thats an android lib actually
[14:45] <davmor2> asac: yeah the new builds take forever to install
[14:45] <ogra_> rah, that up to you ... as long as its a zip file :)
[14:45] <stgraber> cwayne_: it should be in the latest daily-proposed image, yes. However it won't do the chown if the flag file is in the home directory.
[14:45] <stgraber> lool: and have the user upgrade through possibly a dozen deltas? no thanks
[14:45] <davmor2> asac: I pretty sure it will install it just takes a while :)
[14:46] <lool> stgraber: step 1, copy daily to daily-proposed, step 2, while new images come in, add them as if it was daily and compute deltas, step 3, if we promote one, copy it and deltas to daily
[14:46] <ogra_> davmor2, well, theoretically (if you are not a QA gut) you only do the installlation once
[14:46] <rah> ogra_: in that case it's no an appropriate name
[14:46] <ogra_> s/gut/guy/
[14:46] <rah> ogra_: how do I change it?
[14:46] <rah> s/no an/not an/
[14:46] <cwayne_> stgraber, flag file?
[14:46] <jdstrand> mdeslaur: so, the plan was to actually discuss this on the mailing list
[14:46] <mdeslaur> jdstrand: yeah, the more I think about it, the more I hate the udev idea
[14:46] <lool> stgraber: ok, so what happens if the ids get out sync?  can we recover easily once the new code is finished?
[14:47] <davmor2> ogra_: Yeah I guess we're just "Special" right :)
[14:47] <lool> stgraber: (do you have an ETA for new code?)
[14:47] <jdstrand> mdeslaur: you hate everything though
[14:47] <ogra_> yep
[14:47] <jdstrand> mdeslaur: :)
[14:47] <mdeslaur> jdstrand: no, only the bad ideas :)
[14:47] <mdeslaur> jdstrand: actually, yes, I hate everything by default :)
[14:47] <asac> sil2100: need you now :)
[14:47] <jdstrand> mdeslaur: you think everything is a bad idea :)
[14:47] <asac> sil2100: can you get off your call and come to me :)?
[14:47] <mdeslaur> jdstrand: until convinced otherwise :)
[14:47] <stgraber> lool: yeah, I think it'd be recoverable.
[14:48] <stgraber> lool: also, note that if the image you want to promote has been flushed from cdimage by the time you choose to promote it, that'll fail.
[14:48] <jdstrand> mdeslaur: I plan to send this up for discussion on ubuntu-devel. that should get all the necessary people involced
[14:48] <lool> asac: ^
[14:48] <lool> stgraber: that seems reasonnable
[14:48] <jdstrand> involved
[14:48] <cjwatson> we keep touch images for 7 days on cdimage at the moment
[14:48] <stgraber> lool: ETA for the new code is highly influenced by how often I get interrupted in this channel ;)
[14:48] <mdeslaur> jdstrand: cool, thanks
[14:48] <ogra_> stgraber, we keep a week of images on cdmiange for touch
[14:48] <lool> stgraber: so I'd say whatever you can finish today
[14:48] <asac> stgraber: right. that needs fixed
[14:49] <stgraber> cwayne_: /home/phablet/.customized
[14:49] <asac> so think about it
[14:49] <asac> we need a solution... not today
[14:49] <lool> stgraber: exactly; so if you could finish the new code today, then I think it's the best use of your time; otherwise, I am afraid we need to setup daily-proposed as a disconnected channel as you described
[14:49] <asac> but soonish ... we can for now just stop automatic image production
[14:49] <cwayne_> ssweeny, did you know about that flag? ^
[14:49] <asac> and only do that once we have finished the validation run
[14:49] <lool> asac: well yes, that's what I was going to suggest
[14:49] <asac> but that shouldnt be for an extended period
[14:49] <lool> asac: it was never meant to be for an extended period
[14:49] <asac> lool: stgraber: ok we go for all manual and pain :) ... and you go back to the drawing board abit :)
[14:50] <asac> thx
[14:50] <cjwatson> argh, it would be nice if click's internal APIs made sense.  I'm glad I haven't promised any kind of compatibility other than the CLI ...
[14:50]  * asac stops thinking about release channel
[14:50] <ssweeny> cwayne_, which flag?
[14:50] <lool> asac: but the plan was alrady to keep fulls in the next version of the code......
[14:50] <stgraber> asac, lool: setting up daily-proposed as a separate channel would take minutes, it's just a config flag
[14:50] <cwayne_> ssweeny, ~/.customized
[14:50] <lool> asac: ^
[14:50] <ssweeny> cwayne_, no i did not
[14:50] <stgraber> asac, lool: so I can do that, which will mean unsync version numbers between daily and daily-proposed, but daily-proposed would contain all pending images
[14:50] <lool> asac: ^
[14:51] <cjwatson> removal is in ClickSingleDB but needs to talk to ClickUser[s] which needs a ClickDB which is basically a sequence of ClickSingleDBs ... la la la
[14:51] <lool> asac: your call
[14:51] <cwayne_> ssweeny, apparently we need that set to have .local owned by phablet?
[14:51] <asac> stgraber: lool: i still feel its not a fully baked solution. i heard again that we have version changes during the copy etc. - iu would really like to see folks go back and check what we can do different
[14:51] <stgraber> asac, lool: that'll also allow people keeping their device on daily-proposed for daily work since they'll get deltas in that channel
[14:51] <mdeslaur> jdstrand: where are the udev rules currently for the touch images?
[14:51] <lool> asac: either that now, but confusing ids, or wait til Monday(?) and get a nicer version which does the right thing
[14:51] <ssweeny> cwayne_, ok
[14:51] <asac> but ultimately, i will not care about details for now
[14:51] <asac> as long as we can go back and forth
[14:51] <asac> and copy
[14:51] <asac> and still figure what we copied over
[14:52] <asac> through super easy means
[14:52] <stgraber> lool: I wouldn't count on me finishing the work until at least wed-thu, it's a massive rewrite and any test run takes 4 hours...
[14:52] <asac> take your time. rather do it right
[14:52] <asac> for now we know that we cannot overlap and go very fast
[14:52]  * cjwatson bodges it for now
[14:52] <lool> asac: can you live until Wed without a mean to install every single pending version?
[14:52] <mdeslaur> ogra_: where do the udev rules come from in the touch images?
[14:52] <lool> or thursday rather
[14:52] <ogra_> mdeslaur, all container related bits come from the lxc-android-config package
[14:53] <asac> lool: we can even live longer without it if we get a clean/recursive channel solution that just makes sense to my small brain :) ... the longer it takes the better the solution should be though :)
[14:53] <ogra_> mdeslaur, there we also override some of the default udev rules (firmware loaders etc)
[14:53] <mdeslaur> ogra_: thanks
[14:53] <stgraber> asac, lool: I think the best way for now is to setup daily-proposed as a separate channel which includes all pending versions. Have that used for testing, that'll let you test any pending version. When promoting one, the version number in daily will be different but as long as you ignore that fact, everything will be fine.
[14:53] <lool> asac: Your only requirement is that we can deploy whatever pending image as a full image, yes?
[14:54] <lool> stgraber: Ok
[14:54] <stgraber> once we get the new code in place, it'll rectify the situation and version numbers will start matching again when copying
[14:54] <lool> stgraber: Cool; let's do that
[14:54] <asac> stgraber: how can i easily find out and see in dashboard which image was which?
[14:54] <asac> if the version changes?
[14:54] <lool> it will be a bit confusing in ids though
[14:54] <asac> stgraber: this is about unpacking, changing file with version and repacking? couldnt we just make a "version log"?
[14:54] <lool> asac: we should fix the dashboard to say the ubuntu= and android= more clearly
[14:55] <cwayne_> stgraber, so if we set that flag, it will make .local owned by phablet, right?
[14:55] <stgraber> asac: the dashboard doesn't care about the daily channel, only about daily-proposed and with the change I'm proposing it'll actually make more sense since each change will show up with its unique build number
[14:55] <mdeslaur> ogra_: that's for inside the container...what about the udev rules for the graphics devices outside the container?
[14:56] <ogra_> stgraber, will there still be cdimage numbers in the version ?
[14:56] <asac> e.g. showing how the versions in the previous channels were?
[14:56] <asac> anyway. sound reasonable
[14:56] <asac> if we have an ID log
[14:56] <asac> i am all fine for now
[14:56] <ogra_> if so, i'd say its all fine
[14:56] <asac> but lets keep thinking :)
[14:56] <stgraber> asac: the confusing part is that if you publish image 7 with rootfs 20130905.1, it'll possibly appear as image 4 in the daily channel
[14:56] <stgraber> ogra_: the dashboard will be identical to what it's today, the build ID will simply be always incrementing
[14:57] <asac> stgraber: right. so for now we care about daily proposed, but i wanted to have a separate view on the same results that shows the ones that got promoted only
[14:57] <asac> if that makes sense
[14:57] <ogra_> yeah, then it is fine
[14:57] <asac> also if someone tells me my image "X": from daily is broken
[14:57] <asac> i want to go to the dashboard and find if we missed somdething
[14:57] <asac> or at least proof that it was green
[14:57] <popey> asac: hey..
[14:57] <stgraber> asac: ah, ok, well it'd be best for that view to only be created after we've switched to the new tool then, assuming you can wait a week
[14:57] <asac> stgraber: sure it can
[14:57] <asac> stgraber: but if you include a log
[14:57] <asac> during reversioning?
[14:57] <asac> is that possible?
[14:57] <popey> asac: sorry, was on an hour of hangouts, i have 06 on my phone now
[14:57] <asac> that would at least give me a way for now to easily figure out
[14:58] <asac> popey: perfect ... thats RO?
[14:58] <stgraber> asac: you can certainly extract the individual file versions from the daily channel too and compare that with daily-proposed to see which one got promoted, yes
[14:58] <popey> asac: no, you want me to test RO?
[14:58] <asac> stgraber: no i thought... if you promote an image, it gets repacked, right?
[14:58] <lool> asac: you'll have the daily-proposed versions from the dashboard and the daily versions from the channel itself
[14:58] <cwayne_> nic-doffay, ping
[14:58] <asac> stgraber: and we adjust the file inside that has the version? correct?
[14:59] <asac> at that place we could just create another file where we log the "version" evolution
[14:59] <popey> asac: / davmor2 06 has the same issue 05.4 had http://popey.com/~alan/device-2013-09-06-155921.png
[14:59] <popey> asac: / davmor2 go to apps lens, search for something, installed apps all disappear
[14:59] <asac> lool: oh you say that the meta info in daily channel still includes the old daily-proposed version?
[15:00] <asac> popey: ok thats important, butnot a regression from yesterday
[15:00] <asac> thx
[15:00] <mdeslaur> ogra_: oh, nm, found it
[15:00] <asac> popey: everything else works the same?
[15:00] <lool> asac: it will include the details of the versions (filenames)
[15:00] <stgraber> asac: from my side, the two channels will evolve completely independently. daily only published images that have been marked as tested on cdimage. daily-proposed imports everything. My code won't know that something is getting promoted.
[15:00] <popey> asac: do you want me to use RO image or usual flipped?
[15:00] <lool> asac: you wont see the actual id of the daily-proposed version in there, but you can map the files referenced there to the daily-proposed ones
[15:00] <stgraber> asac: so if you want to check, you'll have to compare version numbers of the individual files between the two channels
[15:00] <asac> lool: ah ic
[15:00] <asac> lool: so you say we see the parts still
[15:01] <stgraber> asac: or wait till I get the new code in place and then you'll have something consistent
[15:01] <asac> and refer back through that to the proposed results
[15:01] <asac> ?
[15:01] <asac> ok thats fine :)
[15:01] <asac> sorry for long brain :)
[15:01] <stgraber> ok, I'll get that change done and then get back to rewriting the script into something flexible enough for our use case.
[15:02] <lool> asac: yes
[15:02] <lool> stgraber: thanks; wishing you a longer focus time
[15:03] <davmor2> lool: is there an equivalent to -wipe on ubuntu-system?
[15:03] <lool> davmor2: yes, --no-backup
[15:03] <popey> \o/ consistency
[15:03] <davmor2> lool: thanks
[15:03] <ogra_> popey, we could merge them to --wipe-no-backup
[15:03] <lool> popey: it's completely different!
[15:03] <lool> ;-)
[15:04] <davmor2> asac: popey: right trying again I had a load of cruft in play still
[15:04] <popey> davmor2: you're going for read-only image?
[15:04] <asac> cjwatson: sergiusens: ogra_: ok, out of discussion above, for now we want to avoid interleaving builds if we currently have hot builds in validation until we know if its a GO or NO :) so lets serialize our efforts a even bit more for a while.
[15:04] <asac> :)
[15:04] <asac> just FYI
[15:04] <asac> (since you are cdimage admins i think)
[15:04] <asac> Mirv: hey
[15:04] <asac> are you there?
[15:04] <davmor2> popey: ubuntu-system
[15:05] <popey> asac: past his core hours
[15:05] <popey> he'll be in bed now ☻
[15:05] <popey> I know you like to hope everyone is around 24/7 :D
[15:06] <ogra_> there are people that arent ?
[15:06] <josepht> slackers
[15:06] <cjwatson> asac: I have no plans to build anything for a while now
[15:07] <ogra_> cjwatson, yeah, i think he means disabling crontab too
[15:07] <cwayne_> stgraber, hey, still no love with the /home/phablet/.customized flag set
[15:07] <nic-doffay> cwayne_, what's up?
[15:07]  * ogra_ will do so after his stadup meeting
[15:07] <ogra_> *standup
[15:07] <stgraber> cwayne_: what image are you running?
[15:07] <cjwatson> I don't interpret "serialise" as "disable automatic builds" so if that's what asac wants he should say so :)
[15:07]  * popey flashes
[15:08] <ogra_> yeah, asac'ish poetry :)
[15:08] <asac> i leave the interpretation to the artists I guess :) ... i guess just be smart is what we should do though
[15:08] <ogra_> s/poerty/prose/
[15:08] <asac> e..g if we are actively poking cdimage, keep automatic off
[15:08] <ogra_> well, you will definitely get rarer builds then
[15:09] <asac> ogra_: well, it was not my choice :)
[15:09] <ogra_> specifically on weekends
[15:09] <cwayne_> stgraber, the latest daily-proposed
[15:09] <asac> ogra_: on weekends automatic can run
[15:09] <asac> noone will release images ther anyway for now ;)
[15:09] <cwayne_> nic-doffay, see my convo with pete-woods  in #ubuntu-unity
[15:09] <ogra_> k
[15:09] <lool> asac: we can update the cron to run only on weekends
[15:09] <asac> ogra_: it makes stuff harder for sure, but thats life. we work around :)
[15:09] <lool> and run manually rest of the time
[15:09] <lool> doesn't seem good though
[15:10] <stgraber> cwayne_: looking in dmesg, do you see "initrd: copying custom content"?
[15:10] <ogra_> lool, nah, leave that in human hands
[15:10] <cwayne_> stgraber, nope
[15:10] <ogra_> <-- control freak
[15:10] <mdeslaur> jdstrand: so, all the device-specific udev rules live in the lxc-android-config package, and the postinst detects what the device is, and copies the appropriate file for the device
[15:10] <pete-woods> ssweeny: hi, sorry for the delayed response
[15:10] <mdeslaur> jdstrand: I think we should do something similar with the device specific apparmor rules
[15:10] <stgraber> cwayne_: so then mfisch's code in the initrd didn't run, which means the chown didn't run either
[15:11] <stgraber> cwayne_: the condition for that is: if [ -d ${rootmnt}/custom/home ] && [ ! -e ${rootmnt}/userdata/user-data/phablet/.customized ]; then
[15:11] <ssweeny> pete-woods, no worries. the convo in #ubuntu-unity is pretty much what i wanted
[15:11] <mdeslaur> jdstrand: the postinst there would copy over the udev rules for the device, and would copy over the apparmor device rules
[15:11] <cwayne_> stgraber, i have the hacked recovery to skip the signing, could that have anything to do with it?
[15:11] <mdeslaur> jdstrand: that's my proposal, we can discuss on the list
[15:11] <stgraber> cwayne_: shouldn't
[15:12] <cwayne_> stgraber, any idea why that code wouldn't be running then?
[15:13] <plars> stgraber: it looks like maybe that json file gets updated more often than 2 times... I killed the duplicate jobs earlier and now there are more in the queue, but check-latest still shows Current full image: 5 (ubuntu=20130906, mako=20130906)
[15:14] <stgraber> plars: it's not impossible it currently gets called hourly. The change I'm about to do to the daily-proposed channel should improve that
[15:14] <stgraber> s/called/changed/
[15:15] <plars> stgraber: so will it go down to just updating once?
[15:16] <stgraber> plars: it should, yes
[15:18] <asac> kenvandine: hi
[15:18] <plars> stgraber: awesome, when is that supposed to land?
[15:19] <stgraber> plars: in theory in the next hour, waiting for a current import to finish before I can land the channel config change
[15:19] <davmor2> asac: root@ubuntu-phablet:/# system-image-cli -i  current build number: 5 device name: maguro channel: daily-proposed
[15:19] <stgraber> plars: oh, not sure if you saw the lengthy discussion I had with asac and lool, but once that change lands, you'll also see incrementing build IDs in daily-proposed
[15:19] <davmor2> popey: I have apps
[15:19] <AskUbuntu> Need help to installUbuntu touch | http://askubuntu.com/q/342218
[15:19] <stgraber> plars: and those IDs won't match with daily after an image is promoted, so just ignore the daily channel for now and assume it's right.
[15:20] <plars> stgraber: oh no I didn't, even better, so we can just use the single build id and not the triplet?
[15:20] <plars> doanac, josepht, cjohnston: ^
[15:20] <stgraber> plars: you should still show the triplet because the single build id isn't terribly easy for developers to figure out what you're testing
[15:20] <davmor2> asac: no 3g here at all for me
[15:21] <ogra_> plars, we need the cdimage id for identifying the rootfs
[15:21] <stgraber> plars: but you won't see version rollback in daily-proposed anymore
[15:21] <asac> davmor2: regression?
[15:21] <asac> davmor2: from daily?
[15:21] <plars> josepht: that should at least simplify the sorting issues
[15:22] <ogra_> asac, the image with the ID 5 :)
[15:22] <davmor2> asac: yeap daily at least made an effort at 3g, showed me the logo in the indicator at least
[15:22] <mpt> oreneeshy, https://wiki.ubuntu.com/SystemSettings?action=diff&rev2=48&rev1=47
[15:22] <asac> davmor2: so the 4 RO image worked?
[15:22] <asac> ogra_: you guys uploaded ofono
[15:22] <asac> awe: ^^
[15:22] <ogra_> asac, dont look at me :P
[15:23] <slangasek> jdstrand: the apparmor sysvinit script runs in rcS, which is only run from /etc/init/rc-sysinit.conf - so after "filesystem" and "static-network-up" events.  On the phone these events actually happen quite early, but there's still no strong ordering guarantee here
[15:23] <awe> asac, yes?
[15:23] <asac> awe: can we back it out?
[15:23] <ogra_> asac, only packaging cleanup chnages
[15:23] <awe> back what out?
[15:23] <asac> hmm
[15:23] <awe> asac, context please...
[15:23] <asac> awe: ofono landing
[15:23] <asac> 3g is broken on todays images
[15:23] <ogra_> asac, see the changelog
[15:23] <ogra_> https://launchpad.net/ubuntu/saucy/+source/ofono/1.12-0ubuntu8
[15:23] <awe> asac, one sec
[15:24] <awe> mid-stand-up
[15:24] <asac> davmor2: so ...
[15:24] <ogra_> asac, its only changes to the control file
[15:24] <asac> awe: bring it up there
[15:24] <asac> davmor2: your statement above doesnt relaly sound like you had much luck with 3g before
[15:25] <ogra_> asac, there is no reason to back it out ... "Updated Standard-Version to 3.9.4 .... Update debian/compat to 9"
[15:25] <ogra_> asac, seriously, no code changes
[15:25] <davmor2> asac: I showed up in nmcli c and in ofono scripts,  just didn't connect in nm till you restarted nm.  now it isn't showing up anywhere
[15:25] <davmor2> asac: let me reboot and see if that fixes things
[15:25] <awe> cyphermox, ^^
[15:26] <awe> davmor2, did  you open a new bug?
[15:26] <cyphermox> I'm looking, but I mean, it's unclear what could be happening
[15:26] <Wellark> oSoMoN: approved-
[15:26] <davmor2> awe: nope I enabled the debugging and everything worked
[15:26] <oSoMoN> Wellark: thanks
[15:26] <Wellark> oSoMoN: but ci keeps failing
[15:26] <Wellark> I will top-approve anyway
[15:26] <awe> davmor2, but you have no 3g, correct?
[15:27] <Wellark> the autolander can figure it out
[15:27] <asac> ogra_: we also had hybris landings etc.
[15:27] <awe> if everything worked, why is asac pinging me?
[15:27] <asac> awe: read davmor2's messages
[15:27] <davmor2> awe: not on build 5 no
[15:27] <asac> for him its not working
[15:27] <asac> ogra_: can you cary into the standup
[15:27] <ogra_> asac, that would be one to worry about ... rather than a debian/control cleanup ijn ofono :)
[15:27] <cyphermox> davmor2: please reproduce the bug, file a new bug in LP and just attach /var/log/syslog, ip route, nmcli dev, nmcli con...
[15:27] <asac> ogra_: the idea of coordiating changes that are not going through daily-release with me and sil etc.?
[15:27] <asac> thx
[15:28] <davmor2> asac: that's annoying, the tutor starts on every reboot by the look of it
[15:28] <asac> davmor2: yeah thats a known issue
[15:28] <asac> mterry: ^^
[15:28] <asac> mterry: seems your thing doesnt stop starting on RO images
[15:28] <rsalveti> asac: nothing changed in ofono
[15:29] <asac> rsalveti: the build before we got hybris
[15:29] <mterry> asac, the data for AccountsService is stored in /var/lib/AccountsService/users/
[15:29] <asac> jdstrand: ^^
[15:29] <asac> mterry: you might need to change that a bit now
[15:29] <asac> mterry: check with jdstrand
[15:29] <mterry> asac, how do the RO images work?  Can we say "make this directory RW"?
[15:30] <davmor2> cyphermox: bug against ofono or nm?
[15:30] <sergiusens> ChickenCutlass: try http://bazaar.launchpad.net/~sergiusens/+junk/network/view/head:/network_gprs_provision_test.sh
[15:30] <asac> mterry: not sure. check with jdstrand. he is the architect behind this
[15:30] <asac> and can make changes or tell you what to do :)
[15:30] <sergiusens> plars: too ^^
[15:30] <lool> Ok, I've run music-app and friends-app autopilot tests before and after adding qtdeclarative5-friends-plugin, gstreamer0.10-fluendo-mp3 and gstreamer1.0-fluendo-mp3 and got all passes (2 and 4); so uploaded new meta
[15:30] <pmcgowan> lool, awesome
[15:31] <asac> davmor2: so i heard that maguro 3g is inheretently flaki
[15:31] <asac> davmor2: can you focus on the othe rfeatures like call etc.?
[15:31] <rsalveti> asac: the 3g issues was there yesterday already
[15:31] <popey> asac: mako seems good with read only 20130906
[15:31] <asac> rsalveti: for him yesterdays build was buggy, but better
[15:31] <rsalveti> and we discussed in our standup, I'd probably guess it's the same issue davmor2 had yesterday
[15:31] <asac> popey: thanks!
[15:31] <rsalveti> need logs to say what is happening
[15:31] <asac> plars: ok so lets get 06 through our dashboard
[15:31] <rsalveti> ofono package didn't break anything
[15:32] <cyphermox> davmor2: against NM, we'll reassign if necessary
[15:33] <cyphermox> so, how readonly is the readonly image?
[15:33] <cyphermox> like, how's /var ? :)
[15:33] <cyphermox> or more specifically, /var/lib
[15:33] <sergiusens> cyphermox: very, but /vcarlib/ofono and /etc/NetworkManager/system-connections is writable
[15:33] <cyphermox> ok
[15:33] <asac> rsalveti: sorry, i just try to get a clear message whether th ecurrent image has regression over the previous ones
[15:33] <asac> and hear that its completely broken and worked yesterday a bit
[15:33] <asac> so i have to follow up on that i feel :)
[15:33] <ogra_> asac, who tested it on maguro ?
[15:33] <sergiusens> asac: it's not a regression, it's a long standing bug
[15:33] <cyphermox> what about /var/lib/NetworkManager ?
[15:33] <lool> oSoMoN: Hey, do you look after libqt5webkit5?
[15:33] <ogra_> (yesterday)
[15:33] <rsalveti> asac: right, but please ask for some sort of logs as well :-)
[15:34] <cyphermox> sergiusens: ^^ this is important
[15:34] <lool> oSoMoN: I see it depends on gstreamer 0.10, but I don't know whether that relates to qtmultimedia's version or not (I assume not)
[15:34] <cwayne_> stgraber, what version of the initrd should i have?  how can i debug this?
[15:34] <plars> asac: it's mostly done on maguro, weather-app had some strange failure and needed to be restarted, but otherwise looks good so far
[15:34] <cyphermox> sergiusens: /run/NetworkManager too, but I guess that would be readwrite anyway
[15:35] <plars> asac: mako is still in progress
[15:35] <asac> plars: and mako?
[15:35] <rsalveti> lool: 5.1.1 was ported to use gst 1.0
[15:35] <asac> plars: how far?
[15:35] <plars> asac: it's on the calendar one now, about half-way down the list
[15:35] <ogra_> asac, 3g worked yesterday on mako ... nobody tested maguro ... 3g works today on mako and is broken today on maguro ... there is no regression since there was no former test
[15:35] <lool> rsalveti: ok thanks
[15:35] <oSoMoN> lool: I don’t directly look after it, though I’m interested in any issues encountered with it
[15:35] <lool> oSoMoN: gst 1.0 is all I needed to know
[15:35] <sergiusens> cyphermox: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/view/head:/etc/system-image/writable-paths
[15:36] <stgraber> cwayne_: to see the dmesg entry, any initrd from the last month should do that
[15:36] <oSoMoN> lool: I’d need to check in the code, but I don’t think it’s tied to qtmultimedia
[15:36] <plars> asac: you'll see from http://reports.qa.ubuntu.com/smokeng/saucy/image/4033/ that mako looks good so far, calendar is the first one we expect to fail at this point
[15:36] <lool> seb128: I see packagekit-backend-aptcc pulls in gst 0.10; I presume that's for automatic installation of missing codecs; what's the usual way we deal with new gst versions there?
[15:36] <oSoMoN> ah, I just saw rsalveti’s answer, sorry for the noise
[15:36] <lool> seb128: how would we go to gst 1.0 with it?  does it imply we have to switch the desktop to 1.0 (seems too late)?  or do we need to fork it?
[15:36] <cwayne_> stgraber, let me try again on a fresh build
[15:37] <lool> actually given that it's .deb, it seems it would be a matter of splitting this out in a separate package
[15:37] <sergiusens> cyphermox: hmm, missing /var/lib/ofono
[15:37] <sergiusens> stgraber:
[15:37] <stgraber> cwayne_: that's the code that gets run every time you boot: http://paste.ubuntu.com/6070846/
[15:37] <davmor2> cyphermox: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1221802
[15:37] <stgraber> cwayne_: the only change I did after our discussion was adding the chown, the rest has always been there
[15:38] <sergiusens> stgraber: /var/lib/ofono needs to persist
[15:38] <stgraber> sergiusens: ok
[15:38] <cwayne_> hm
[15:38] <sergiusens> stgraber: was it taken out? I thought it was in
[15:38] <stgraber> sergiusens: network-manager is in there but not ofono
[15:38] <cyphermox> without /var/lib/ofono, nothing of the 3G connections is likely to work
[15:39] <cwayne_> stgraber, wait, so .customized has to be set *before* we customize it?
[15:39] <ogra_> cyphermox, hmm, why does it work for popey then >
[15:39] <ogra_> (or others that use a mako)
[15:39] <cjwatson> mterry: lxc-android-config has configuration for writable paths (etc/system-image/writable-paths)
[15:39] <popey> ogra_: hmm?
[15:39] <sergiusens> ogra_: it worked for me too, which makes me confused
[15:39] <stgraber> cwayne_: no, "! -e" means "doesn't exist"
[15:40] <ogra_> sergiusens, yeah, thats very weird
[15:40] <cwayne_> ah, right
[15:40] <stgraber> sergiusens: I'll add it
[15:40] <cyphermox> ogra_: can files be written in /var/lib/ofono at all, or do they just get removed when you reboot the phone?
[15:40] <ogra_> popey, theoretically 3G shouldnt work
[15:40] <sergiusens> cyphermox: no, they can't
[15:40] <seb128> lool, hey
[15:40] <sergiusens> cyphermox: root@ubuntu-phablet:/# touch /var/lib/ofono/s
[15:40] <ogra_> irs a readonly fs
[15:40] <sergiusens> touch: cannot touch '/var/lib/ofono/s': Read-only file system
[15:41] <popey>  /ril_0     gsm               connecting (prepare)
[15:41] <cyphermox> then how could NM read files in /var/lib/ofono written by ofono, to be able to know what to activate?
[15:41] <seb128> lool, gst doesn't change often enough that we have an "usually" there, we had one transition from gst 0.8 to 0.10 in Ubuntu before that 0.10 to 1.0
[15:41] <cyphermox> sergiusens:  this leads me to believe you were not in fact using the readonly image :)
[15:41] <seb128> lool, we switched desktop to 1.0 in raring (we didn't manage to get 0.10 out of the CD though IIRC)
[15:41] <stgraber> mterry: did I understand that you also want /var/lib/AccountsService/users/ to be writable?
[15:41] <ogra_> cyphermox, dunno, but multiple people claimed they had 3G today ... with readonly images
[15:41] <stgraber> mterry: (I'm updating the list now)
[15:41] <sergiusens> cyphermox: no, I may have remounted rw to add my serviceprovider stuff and forgot to remount ro again
[15:42] <sergiusens> cyphermox: only thing I can think of
[15:42] <lool> seb128: so the codec installation feature is probably borken I guess?
[15:42] <lool> seb128: well, I guess it doesn't really matter if libgstreamer0.10-0 is pulled by packagekit on the touch image for now
[15:42] <seb128> lool, I can't tell
[15:42] <lool> it wont break anything in itself, we dont use this feature on touch right now anyway
[15:42] <seb128> lool, why would it be broken?
[15:43] <lool> seb128: well I guess it searches for 0.10 plugins instead of the 1.0 ones you'd need!
[15:43] <awe> stgraber, /var isn't write-able?
[15:43] <stgraber> awe: only subsets of it are
[15:43] <ogra_> awe, only the dirs listed in the whitelist are writable
[15:43] <ogra_> (/var isnt)
[15:43] <seb128> lool, do we use that backend?
[15:43] <sergiusens> awe: only stuff in http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/view/head:/etc/system-image/writable-paths
[15:44] <awe> and did we inspect every piece of code that's installed?  ;)-
[15:44] <cyphermox> sergiusens: I don't know. otherwise it would have to be not readonly while ofono writes provisioning data to disk and become readonly after
[15:44] <awe> fail
[15:44] <ogra_> awe, nope, we have 6 weeks to do that :P
[15:44] <lool> seb128: for click yes
[15:44] <awe> ofono
[15:44] <lool> seb128: but not for gst in touch
[15:44] <seb128> lool, well, not for codecs on the desktop
[15:44] <lool> seb128: I dont know about gst in desktop
[15:44] <seb128> lool, we use sessioninstaller
[15:44] <seb128> which is on gstreamer1.0
[15:45] <awe> ogra_, is someone going to write a tool that does this automatically?
[15:45] <seb128> lool, https://launchpad.net/ubuntu/+source/sessioninstaller/0.20+bzr134-0ubuntu4
[15:45] <lool> seb128: so should we just turn this off or something
[15:45] <ogra_> awe, that tool is called stgraber :)
[15:45] <seb128> lool, I've no idea about what click is doing with pkgkit sorry :/
[15:45] <mterry> jdstrand, whoops, got disconnected.  When you have a sec, I'd like to talk RO image stuff
[15:45] <lool> seb128: unrelated stuff; packagekit is used as the dbus service to request click intsall
[15:45] <lool> seb128: or click update, or click removal or click list
[15:45] <asac> davmor2: so i think awe and cyphermox confirmed that this 3g issue is not really a regressoin, lets focus on the rest then (call, wifi, etc.)
[15:46] <awe> ogra_, and so what if some pieces of code wants to write to /var when the date rolls at the end of the year, and we hadn't noticed it?
[15:46] <sergiusens> asac: yes
[15:46] <seb128> lool, we should disable the codec stuff or split it out in its binary I guess
[15:46] <sergiusens> asac: there is a regression
[15:46] <sergiusens> asac: /var/lib/ofono is not writable
[15:46] <asac> aha
[15:46] <awe> asac, if it's a RO image, not necessarily true
[15:46] <asac> my hero!!!
[15:46] <asac> :)
[15:46] <asac> awe: the other image doesnt matter anymore for me :)
[15:46] <asac> RO !!!
[15:46] <asac> i am only talking about RO :)
[15:47] <awe> ogra_, can you fix?  ^^
[15:47] <stgraber> ogra_: I have the fix for ofono
[15:47] <stgraber> aw^
[15:47] <stgraber> awe: ^
[15:47] <sergiusens> awe: stgraber is already fixing
[15:48] <stgraber> just waiting to hear from mterry about accountservice
[15:48] <stgraber> since it'd be stupid to do two uploads in a 5min interval
[15:48] <davmor2> asac: no 3g, messaging indicator give no signal that there is a message, with wifi enabled unless I reboot I don't see click app, using the camera Locked up the app completely (I'll carry on after a reboot)
[15:48] <mterry> stgraber, I'm just waiting on jdstrand
[15:48] <asac> davmor2: what out of that is a regresison over our 4 build?
[15:49] <awe> stgraber, what about /var/lib/dhcp?
[15:49] <lool> seb128: seems useless in Ubuntu AIUI
[15:49] <ogra_> awe, we need to notice and update the scripts
[15:49] <ogra_> awe, click apps have their own writable space and the core OS shouldnt randomly change
[15:49] <ogra_> awe, read: we need to test enough to know about such an issue in advance and preemptively take action
[15:49] <ogra_> before the user gets it
[15:49] <seb128> lool, I think so as well
[15:49] <davmor2> asac: I never used the 4 build I was on daily,  on daily the camera worked so that might be a RO issue
[15:49] <sergiusens> stgraber: can't we make all of /var writable?
[15:49] <asac> awe: stgraber: feels like revisiting everything that is in /var/lib... might be good :)
[15:50] <awe> +1
[15:50] <stgraber> awe: shouldn't be used, NM uses /var/lib/NetworkManager for that, which is already writable
[15:50] <stgraber> sergiusens: nope
[15:50] <stgraber> sergiusens: we don't support overlays, so making all of /var writable would mean copying it all to writable storage on first boot
[15:50] <asac> stgraber: i think every directory in /var/lib should be explicitley looked at
[15:50] <stgraber> sergiusens: then if something gets added or removed from the image, it'll never be copied to writable storage
[15:50] <davmor2> asac: so now the camera app just crashes clean if I try to use it I'll try and get some feedback for that after
[15:51] <sergiusens> stgraber: if its the debian packaging stuff ony, do we care?
[15:51] <jdstrand> mdeslaur: ack
[15:51] <asac> davmor2: i assume its not writing to the right directory
[15:51] <jdstrand> slangasek: thanks
[15:52] <asac> oSoMoN: can you confirm that camera app is writing to a goo dlocation on RO image?
[15:52] <jdstrand> asac: following up with mterry
[15:52] <jdstrand> mterry: what's up?
[15:52] <rsalveti> jdstrand: sorry, just saw the backlog, so will you follow the apparmor x udev in ubuntu-dev?
[15:52] <jdstrand> rsalveti: yes
[15:52] <cwayne_> stgraber, ok, so this time i did see the 'copying custom content' line in dmesg, but still owned by system:system
[15:52] <oSoMoN> asac: that’s a question for gusch_
[15:52] <asac> stgraber: mterry also wants to write to /var/lib/AccountsService/users/ from the intro
[15:52] <rsalveti> jdstrand: ok, thanks, will review/reply the ml then
[15:53] <oSoMoN> asac: do we have some documentation on what a good location is?
[15:53] <asac> jdstrand: ^^
[15:53] <jdstrand> rsalveti: will be in a bit. responding to various pings/emails/etc. you know, one's regular morning :)
[15:53] <asac> we are kind of finding a few places in /var/lib that should be writable
[15:53] <rsalveti> yeah :-)
[15:53] <asac> so lets look at all
[15:53] <rsalveti> this channel is kind of crazy
[15:53] <mterry> asac, not just intro.  Lots of things are using AS for user data
[15:53] <mterry> launcher items, system settings
[15:53] <sergiusens> oSoMoN: this is part of what a good location is http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/view/head:/etc/system-image/writable-paths
[15:53] <sergiusens> oSoMoN: then you have all the apparmor stuff
[15:53] <rsalveti> asac: so it wasn't working at all in ro :-)
[15:53] <oSoMoN> sergiusens: thx
[15:54] <asac> rsalveti: thats what i mean :)
[15:54] <gusch_> asac: camera writes to ~/Pictures and ~/Videos (in case it will be able to record videos again)
[15:54] <asac> gusch_: thats not ok i think
[15:54] <mterry> jdstrand, AccountsService uses /var/lib/AccountsService/users/ to store data about users.  But that isn't writable in the RO images.  Can we poke a hole for that directory?
[15:54] <jdstrand> mterry: people are pinging me about /var/lib/AccountsService/users/ but I am lacking context
[15:54] <jdstrand> mdeslaur: can you listen in?
[15:54] <sergiusens> oSoMoN: which is cat /usr/share/apparmor/easyprof/policygroups/ubuntu/1.0/picture_files
[15:54] <asac> gusch_: you have to use XDG_ path's
[15:54] <rsalveti> people need to be clear that when they say they are using the RO image that means they never remounted it as rw :-)
[15:54] <asac> gusch_: check with jdstrand
[15:54] <rsalveti> otherwise it's hard to track down the issues
[15:54] <mterry> jdstrand, it's used by AccountsService to store data like "has the user skipped the demo", "what are the user's launcher items", "should the welcome screen show the infographic"
[15:55] <mdeslaur> jdstrand: listen in on what?
[15:55] <ogra_> rsalveti, so many variables
[15:55] <sergiusens> asac: writing to ~/Pictures is correct from an apparmor point of view
[15:55] <sergiusens> asac: check your /usr/share/apparmor/easyprof/policygroups/ubuntu/1.0/picture_files
[15:55] <rsalveti> ogra_: yup :-)
[15:55] <awe> straber, ok... looks like /var/lib/dhcp isn't being used, but /var/lib/bluetooth is... again for settings
[15:55] <asac> sergiusens: ok so the fact that camera doesnt save files for me and hangs is a different regression?
[15:55] <asac> felt very related because it started on RO
[15:55] <sergiusens> asac: there was some talk about xdg translations that I guess jdstrand recalls more than me
[15:55] <jdstrand> mdeslaur: what mterry is talking about
[15:55] <josepht> rsalveti: I'm assuming that applies for automated testing as well? (RE: RO never mounted RW)
[15:56] <jdstrand> mterry: ok, can we back up. I have no context. what is the issue?
[15:56] <rsalveti> josepht: yup
[15:56] <gusch_> asac jdstrand camera uses QStandardPaths in fact
[15:56] <mdeslaur> mterry, jdstrand: oh, that's because the image is ro?
[15:56] <asac> gusch_: awesome ... that SHOULD be allright then ...
[15:56] <mdeslaur> mterry, jdstrand: I guess stgraber needs to poke that hole, I'm not sure how it's done
[15:56] <asac> gusch_: do you have a maguro? maybe try :)
[15:56] <asac> maybe you can see
[15:56] <davmor2> asac: video playback of sintel sucks on 5 but didn't on daily
[15:56] <jdstrand> gusch_: you need to append $app_pkgname to the standard path. $app_pkgname is "name" in the click manifest
[15:57] <mterry> mdeslaur, jdstrand: So AS (AccountsService) is a system daemon that stores some data on the user's behalf so that the greeter and the user can both set/read it
[15:57] <rsalveti> davmor2: it should suck with both
[15:57] <rsalveti> davmor2: same hardware?
[15:57] <ogra_> asac, hmm, for me it crashes the whole shell
[15:57] <jdstrand> mterry: /me nods
[15:57] <gusch_> jdstrand: camera-app is no click package
[15:57] <davmor2> rsalveti: yeap
[15:57] <ogra_> asac, taking a pic that is
[15:57] <sergiusens> jdstrand: from the apparmor camera_files profile it seems he wants $HOME/Pictures to write the images
[15:57] <mterry> mdeslaur, jdstrand: It's used for a variety of things I listed above.  Right now on the RO image we have a bug where the first-use demo keeps appearing
[15:57] <asac> ogra_: so what landed there? :)
[15:57] <ogra_> oh, and all input apparently
[15:57] <sergiusens> gusch_: it will be
[15:57] <gusch_> asac: you mean on monday? EOD is coming very close ...
[15:57] <rsalveti> davmor2: then it could be that something else is also using your cpu
[15:57] <mterry> mdeslaur, jdstrand: because AS can't write to that directory to save the fact that it should be skipped
[15:58] <stgraber> jdstrand, mterry, awe: ok, uploading lxc-android-config with /var/lib/AccountsService/users/ and /var/lib/ofono added
[15:58] <plars> rsalveti: you do realize that in the test automation, we currently have to mount the RO images as RW right?
[15:58] <rsalveti> davmor2: because in both cases it was doing software decode
[15:58] <rsalveti> plars: seriously?
[15:58] <ogra_> asac, no idea, someone (with fater internet) should try a rw image and try to confirm
[15:58] <gusch_> sergiusens: it will what?!? All apps are going to be click packages?!?
[15:58] <mdeslaur> stgraber: thanks
[15:58] <jdstrand> gusch_: mterry ah, right, just addjust lxc-android-config. looks like stgraber is doing it for you
[15:58] <plars> rsalveti: yes
[15:58] <ogra_> asac, else i'd blame ro here too
[15:58] <mterry> jdstrand, mdeslaur: And I just wanted to see if it wass OK to add the directory to the RW part
[15:58] <jdstrand> gusch_: sorry, meant for mterry
[15:58] <lool> pmcgowan, dpm: Checked 0.10 / 1.0 gst rdepends; http://paste.ubuntu.com/6070923/ is 0.10 rdepends; seems doable with qtmultimedia/mediaplayer-app from Jim and qt 5.1.x update moved to gst 1.0, only gallery app remains
[15:58] <mterry> stgraber, thanks!
[15:58] <rsalveti> plars: haha, then we're not *really* testing the ro stuff in here
[15:58] <jdstrand> mterry: seems fine to me :)
[15:58] <davmor2> rsalveti: I've gone from rw to ro I'm wondering if it was writing a cache file some where and now can't
[15:58] <rsalveti> we could face similar issues as we had with ofono
[15:59] <asac> rsalveti: we know that
[15:59] <asac> and its worked on
[15:59] <lool> pmcgowan, dpm: (and updating seeds obviously)
[15:59] <pmcgowan> lool, ack
[15:59] <lool> pmcgowan: would I push the gallery-app gst request now?
[15:59] <pmcgowan> sure
[15:59] <pmcgowan> bug it I suppose
[15:59] <jdstrand> mterry: the ro bit is more about system-image than security. granted, we get security benefit from it, but that is a side-affect
[15:59] <rsalveti> asac: right, that's important to be fixed, otherwise we can really trust the test results
[15:59] <asac> rsalveti: no need to repeat
[15:59] <asac> :)
[15:59] <stgraber> jdstrand, mterry, awe: uploaded
[15:59] <dpm> awesome, thanks lool
[16:00] <asac> rsalveti: it is prevailining my day now
[16:00] <asac> :)
[16:00] <asac> domination :)
[16:00] <rsalveti> asac: :-)
[16:00] <jdstrand> sergiusens: ok, I'm lacking context on this too. what is the question for me?
[16:00] <jdstrand> gusch_: ^
[16:00] <ChickenCutlass> asac, ogra_ 3G not working for me on RO image as well
[16:00] <asac> rsalveti: i didnt push long enough back
[16:00] <asac> i asked a month ago to fix infrastructure first
[16:00] <rsalveti> ChickenCutlass: it's broken
[16:00] <awe> ChickenCutlass, read the backlog
[16:00] <asac> :)
[16:00] <ogra_> ChickenCutlass, yeah, it was a missing rw dir
[16:00] <ChickenCutlass> ah
[16:00] <ChickenCutlass> ok
[16:00] <ChickenCutlass> lol
[16:00] <rsalveti> ChickenCutlass: stgraber is fixing it
[16:00] <ChickenCutlass> got it
[16:00] <sergiusens> asac: this is camera http://paste.ubuntu.com/6070937/
[16:00] <seb128> mpt, can you remind me who we should ping if we need system-settings assets? For the background panel we are probably going to need the images for the welcome/home screens (e.g the bits representing the greeter/dash over the images in https://wiki.ubuntu.com/Appearance?action=AttachFile&do=get&target=phone-background.mockup.png)
[16:00] <ogra_> camera-app seems to misbehave in maguro ro
[16:00] <gusch_> jdstrand: is camera-app allowed to write to ~/Pictures
[16:00] <awe> jdstrand, popular phrase these days:  "lacking context"  ;)-
[16:00] <sergiusens> jdstrand: the use of xdg dirs and translations
[16:01] <rsalveti> asac: that's fine, we'll fix it next week
[16:01] <sergiusens> gusch_: yes all apps are going to be click
[16:01] <asac> rsalveti: the RO image?
[16:01] <rsalveti> the ro testing
[16:01] <ogra_> asac, everything :)
[16:01] <ogra_> the world
[16:01] <rsalveti> as long you let us stay focused, we'll fix it :P
[16:01] <sergiusens> ogra_: http://paste.ubuntu.com/6070937/
[16:01] <ogra_> haha
[16:02] <ogra_> sergiusens, ouch, that looks like an android prob
[16:02]  * cjwatson gets click package unregistration/removal working with the exception that it doesn't yet remove user data
[16:02] <jdstrand> gusch_: regarding writing to ~/Pictures, there was some discussion about that on the list because Pictures is translatable (it is one of the xdg user dirs)
[16:02] <sergiusens> ogra_: yes
[16:02] <ogra_> rsalveti, ^^^
[16:02] <ogra_> camera service dies
[16:02] <asac> ogra_: lool: so i am tempted to say we go back to touch as our release baseline
[16:02] <jdstrand> gusch_, sergiusens: I don't recall where we landed on that
[16:02] <asac> and wait till all the issues get fixed
[16:02] <ogra_> asac, you mean rw
[16:03] <davmor2> asac: keyboard still isn't great but that was happening on daily too
[16:03] <asac> ogra_: touch == rw, yes
[16:03] <asac> touch_ro == RO
[16:03] <jdstrand> gusch_: my previous answer was regarding xdg *base* dirs, not xdg *user* dirs. sorry for the confusion
[16:03] <ogra_> heh, ok
[16:03] <sergiusens> jdstrand: I think we were going to keep ~/Pictures on fs and only change the name you view since the fs is not exposed to users ... lool tedg might recall more
[16:03] <rsalveti> sergiusens: sorry, what is that issue exactly?
[16:03] <jdstrand> gusch_, sergiusens: I can say that I plan to upload apparmor which will handle the translated directory correctly
[16:03] <sergiusens> rsalveti: http://paste.ubuntu.com/6070937/
[16:03] <ogra_> sergiusens, jdstrand, note that we ship /home/phablet/.config/user-dirs.dirs which defines the XDG_USER_DIRS
[16:03] <lool> asac: how many tests are passing with the image read-write?
[16:04] <rsalveti> sergiusens: right, but how did you get that
[16:04] <cjwatson> I thought we were doing non-translatable directories only on the grounds that the directory names won't be visible directly anyway
[16:04] <rsalveti> sergiusens: which image, instructions, what exploded, etc
[16:04] <ogra_> rsalveti, taking a pic on maguro
[16:04] <sergiusens> rsalveti: taking a picture
[16:04] <ogra_> rsalveti, latest ro image
[16:04] <asac> lool: read write is good, but RO kills dogfoodable for sure
[16:04] <asac> nothing works kind of :)
[16:04] <asac> all wireless etc.
[16:04] <sergiusens> rsalveti: let me switch to rw
[16:04] <gusch_> jdstrand: camera uses QStandardDirs to get the location
[16:04] <cjwatson> and translating directories on the fs rather than the UI layer is a horrible misdesign anyway, so ubuntu-touch is a good opportunity to get rid of it
[16:04] <asac> and i need to release to get unity landed and other stuff
[16:04] <tedg> sergiusens, lool, I don't see the question in the backlog... what's up?
[16:04] <asac> that is stalled
[16:04] <jdstrand> gusch_, sergiusens: I can also say that 'xdg-user-dir PICTURES' will give you the translated directory
[16:04] <lool> asac: wireless works for me
[16:05] <sergiusens> rsalveti: ogra_ mount -o remount,rw / allows Pictures
[16:05] <rsalveti> sergiusens: seems the camera client crashed, so it's probably our hal or app layer
[16:05] <ogra_> sergiusens, great, so its another ro issue
[16:05] <ogra_> but which :)
[16:05] <jdstrand> gusch_: that's fine, but there are *base* dirs and *user* dirs. I was referring to base dirs in my initial comment because of an earlier discussion in this channel. I just wanted to clarify my initial XDG/click comment is all
[16:06] <asac> lool: well, ofono is busted
[16:06] <sergiusens> ogra_: strace which tell
[16:06] <ogra_> yeah
[16:06] <rsalveti> seems camera is busted as well
[16:06] <sergiusens> lool: /var/lib/ofono is missing r/w
[16:07] <jdstrand> seb128: where did we land on people using xdg user dirs, like Pictures. gusch_ is using QStandardDirs to find it-- is that what he should be using? are we going to allow Pictures to be translated or use some symlink hackery-wackery to make sure apps can depend on Pictures?
[16:07] <daker> Kaleo: hi, do you have anyidea why this is happening https://plus.google.com/u/0/photos?pid=5912883833171629858&oid=101694416703170881163 ?
[16:08] <daker> Kaleo: i was thinking it's bug 1202403 but i am not really sure
[16:08] <jdstrand> seb128: note that I will be adjusting apparmor to handle translated xdg user dirs, so apparmor won't be an issue
[16:08] <seb128> jdstrand, the consensus on the list seemed to be that we would not allow names on disk to be translated anymore
[16:08] <seb128> lool: ^ that was right?
[16:08] <sergiusens> seb128: I thought so too
[16:08] <seb128> jdstrand, we control enough of the UI to be confident we are not going to "leak" the filesystem details to users
[16:08] <lool> sergiusens: does it need to be persistent?
[16:09] <jdstrand> seb128: but depending on your answer, it might influence when I land such change to apparmor ;)
[16:09] <cjwatson> seb128: \o/
[16:09] <sergiusens> lool: yes, stgraber already fixed
[16:09] <seb128> jdstrand, e.g we can handle the translations in the toolkit
[16:09] <sergiusens> lool: we are in perm loop of issues
[16:09] <sergiusens> :-)
[16:09] <seb128> cjwatson, ;-)
[16:09] <lool> erf
[16:09] <cjwatson> this is my face of utter joy at destroying translated fs names
[16:09]  * sergiusens notices no one reads the backlog
[16:09] <jdstrand> cjwatson: seriously, they are icky :)
[16:09] <lool> sergiusens: too much traffic today
[16:09] <lool> I can't keep up
[16:09] <asac> sergiusens: hehe...thats normal
[16:09] <lool> so /var/lib/ofono is uploaded
[16:10] <asac> i am also lost... do we upload fixes for /var/lib right now? or are we investigating?
[16:10] <asac> lool: rock
[16:10] <asac> :)
[16:10] <sergiusens> asac: yeah, but the ofono issue was mentioned 15 times perhaps
[16:10] <asac> thats good news
[16:10] <lool> asac: two were uploaded
[16:10] <jdstrand> lool: re traffic> I know the feeling :)
[16:10] <ogra_> lool, right, next issue is that taking a pic crashes the shell :)
[16:10] <lool> sergiusens: see asac doesn't read the backlog either  :-)
[16:10] <ogra_> lool, on readonly images
[16:10] <lool> jdstrand: BTW pingpingping!
[16:10] <lool> ;-)
[16:10] <lool> ogra_: and that's not expected behavior?
[16:10] <jdstrand> lool: pongpongpong!
[16:10] <ogra_> lool, LOL
[16:11] <asac> lool: ok, then lets continue and get another round going :)
[16:11] <asac> sil2100: can we talk the list of candidaets through?
[16:11] <lool> ogra_: I can confirm this shell thing!
[16:11] <lool> ogra_: do we know what's causing it?
[16:11] <ogra_> not yet
[16:11] <cwayne_> stgraber, what version of ubuntu-touch-generic-initrd should i have?
[16:11] <lool> the good news is that it eventually restarts
[16:11] <ogra_> but remounting / rw fixes it
[16:11] <lool> oh _usr_bin_camera-app.32011.crash
[16:11] <ogra_> lovely
[16:12] <sil2100> asac: more or less, I'm trying to resolve some stack build/release problems right now as well
[16:12] <asac> sil2100: ok so you prep that stuff would be ready
[16:12] <kdub> who got surfaceflinger running in the flipped images? (have some questions)
[16:12] <asac> sil2100: wewould like to push the main pieces soon
[16:13] <stgraber> cwayne_: 0.47 I think
[16:13] <rsalveti> kdub: what is the issue?
[16:13] <sil2100> asac: cool - from the components that are ready, we have this to release for sure: mediascanner, mir, unity-system-compositor, autopilot, u1db-qt, unity-mir
[16:13] <sergiusens> lool: rsalveti ogra_ if you remount it once rw, it is enought for it to work always :-/
[16:13] <sil2100> asac: hud and indicators are red, so no releases there
[16:13] <kdub> rsalveti, just if i stop surfaceflinger, then try to run /system/bin/surfaceflinger in the android-chroot, the executable segfaults
[16:13] <ogra_> yippie ... heisenbug
[16:13] <cwayne_> stgraber, hmm, that's what i have
[16:14] <lool> sergiusens: ah!
[16:14] <asac> sil2100: so i think mir and unity-* wait for ricmm
[16:14] <rsalveti> kdub: you need to be inside the android container to start it up again
[16:14] <asac> sil2100: so we have mediascanner and autopilot and u1db
[16:14] <rsalveti> kdub: which means you'd need to get inside the android container via it's own adb
[16:14] <asac> sil2100: hope those are safe, but owuld like to know whats in autopilot
[16:14] <cwayne_> is there any debugging i can do to get you useful information?  i see the copying custom content in dmesg, but .local is still owned by system
[16:14] <sil2100> asac: autopilot is safe to release, it has a neat fix only
[16:14] <cwayne_> ssweeny, our tarball is all owned by root now, right?
[16:14] <asac> sil2100: ok then lets do those now
[16:14] <rsalveti> kdub: android-chroot doesn't set the right pid namespace
[16:14] <ogra_> rsalveti, android-chroot should work for starting it manually
[16:14] <davmor2> popey: ha goto calendar goto any date click on create new event it's created in today rather than the day you are on :D
[16:14] <sil2100> asac: veebers added a functionality to detect infinite mouse-movement loops
[16:15] <rsalveti> ogra_: not necessarily
[16:15] <asac> sil2100: so we could pick them up in next image
[16:15] <kdub> rsalveti, i figured something about my lxc knowledge was lacking :)
[16:15] <asac> (think 1h from now)
[16:15] <jdstrand> gusch_: based on seb128's comment, it sounds like ~/Pictures will not be translated at the fs level, so you should be able to depend on it not changing based on translation. I can't speak for QtStandardPaths though (I don't know the Qt API enough to know if it will do the translating for you)
[16:15] <ogra_> rsalveti, it does for sensorservice
[16:15] <sil2100> asac: ok, I'll check one more thing in the meantime
[16:15] <jdstrand> gusch_: but wait until lool comments
[16:15] <ogra_> not sure if SF is any different
[16:15] <rsalveti> ogra_: that's why not necessarily, it depends on the service
[16:15] <rsalveti> if it needs the property system and such
[16:15] <stgraber> cwayne_: so it may be that my android rebuild didn't pick it up, which may explain what you're seeing
[16:15] <ogra_> yeah, understood
[16:15] <lool> jdstrand, gusch_: I'm all for NOT translating these
[16:16] <jdstrand> consensus! :)
[16:16] <asac> sil2100: ok let me know when copied and what was copied :)
[16:16] <lool> last time we discussed this, we didn't have a good plan for convergence, but I think we decided to keep going with untranslated filenames anyway
[16:16] <jdstrand> and so I an further delay landing the xdg user patch for apparmor :)
[16:16] <asac> rsalveti: anything you guys want to throw into the mix as well for the next RO run?>
[16:16] <asac> like a new libhyris? :)
[16:16] <ricmm> asac: sil2100 you can go ahead with release of everything that has had branches land, on my end
[16:16] <ricmm> that is unity-mir and qtubuntu
[16:16] <asac> otherwise we have the /var/lib fixes i think plus new apps
[16:16] <rsalveti> kdub: http://paste.ubuntu.com/6070990/
[16:16] <asac> ricmm: ok cool. so not MIR itself?
[16:17] <asac> that feels not used
[16:17] <ricmm> the changes there are not the Mir changes, just some other pre-reqs that are unused right now
[16:17] <jdstrand> seb128: would you mind following up on the list that this is what was decided if it isn't clear already?
[16:17] <asac> so feels safe as well ... but not sure
[16:17] <sergiusens> asac: I want to find ou`t what's wrong with the camera
[16:17] <rsalveti> asac: nothing from my side, I don't land stuff in friday
[16:17] <asac> rsalveti: ok
[16:17] <asac> you are smart :)
[16:17] <ricmm> it would certainly help to have them in the archive, for the following landings
[16:17]  * asac notes that we land thursday stuff though :)
[16:17] <asac> lol
[16:17] <ricmm> as it wont happen right now, it will just make it cleaner for the next proposals I guess
[16:17] <sil2100> ricmm: ah, so it's safe to release those without getting anything broken, yes?
[16:17] <rsalveti> thursday is fine, we have friday to fix
[16:17] <rsalveti> :P
[16:17] <popey> davmor2: http://bugs.launchpad.net/ubuntu-calendar-app ☻
[16:18] <stgraber> cwayne_: so the chown definitely is in there...
[16:18] <asac> ricmm: so double checking:                  mediascanner, mir, unity-system-compositor, autopilot, u1db-qt, unity-mir
[16:18] <asac> out of those we should pick: mir, unity-* ?
[16:18] <asac> ricmm: and we have very low likelyhood of sideeffects :)?
[16:18] <asac> nice
[16:18] <kdub> rsalveti, will give it a try
[16:18] <stgraber> cwayne_: what do you get if you do cat /etc/media-info?
[16:18] <rsalveti> kdub: that gets you in the android pid namespace properly, so you can execute whatever you want/need there
[16:18] <ricmm> asac: mir is irrelevant to me, their landing has nothing to do with our supporting effort
[16:18] <asac> ricmm: seems greyback disagrees
[16:18] <ricmm> asac: from my end, unity-mir and qtubuntu are good to go
[16:18] <ogra_> asac, i dont think mediascanner is used by anything yet, should be safe to pull in as well
[16:18] <cwayne_> stgraber, Ubuntu Saucy Salamander (development branch) - armhf (20130906)
[16:18] <ricmm> asac: uh?
[16:18] <asac> ricmm: ok... even with greybacks comment?
[16:19]  * rsalveti lunch
[16:19] <stgraber> cwayne_: hmm, that doesn't make any sense...
[16:19] <asac> ricmm: check -unity channel
[16:19] <ricmm> yes I did
[16:19] <davmor2> asac: so other than the camera and 3g and no messaging indicator changes and no...... it's a great image honest
[16:19] <cwayne_> stgraber, hm?
[16:19] <asac> davmor2: nice irony :)
[16:19] <ricmm> asac: unity-mir, qtubuntu should be safe, unity8 no
[16:19] <ricmm> asac: but if you want you can hold them all, the unity-mir qtubuntu stuff is unused anyways
[16:19] <stgraber> cwayne_: you're on the right version, I just inspected its content and the initrd is correct, so I'm really confused why it's not working
[16:19] <asac> ricmm: we dont see unity8 packages staged i think
[16:19] <ricmm> until the later branches come in play
[16:20] <asac> sil2100: so unity-mir, qtubuntu from ricmm side
[16:20] <asac> and the rest as discussed
[16:20] <cwayne_> stgraber, maybe our tarball is wrong, let me try something real quick
[16:20] <kdub> rsalveti, hmm, last command (to get the android pid namespace shell) get the 'device not found'
[16:20] <asac> sil2100: not mir itself
[16:20] <seb128> jdstrand, done
[16:20] <sil2100> ricmm: ok, well, I'll publish qtubuntu then - is it fine to release the qtubuntu bits without the unity-mir ones?
[16:20] <rsalveti> kdub: try killing adb from your host
[16:20] <stgraber> cwayne_: do you override the android tarball (mako-*.tar.xz) with something older?
[16:20] <davmor2> asac: the best is the 2 shots I took with the camera seem to be saved I'm going to pull them in a second and see if they actually were or not
[16:20] <cwayne_> stgraber, nope
[16:20] <ricmm> sil2100: yes
[16:20] <sil2100> ricmm: since sadly, I cannot easily release unity-mir without unity8, so I would hold those up until all is ready
[16:20] <arnoldkj> Hey, I've just flashed my nexus 7 to UT. I didn't have the bootloader unlocked when I first tried to run it and it soft-bricked it though. I got it back, just thought I'd report. (I know it was my own fault)
[16:21] <ricmm> sil2100: then just dont do qtubuntu either
[16:21] <kdub> rsalveti, same store
[16:21] <kdub> *story
[16:21] <ricmm> no point, they are both no-ops at the current moment
[16:21] <sil2100> asac: what about mir then? Since I got a bit confused... can I release mir as well? Mir as in Mir
[16:21] <ricmm> unused without unity8
[16:21] <ricmm> might as well hold to reduce the delta, in case other stuff breaks
[16:21] <ricmm> asac: agree?
[16:21] <rsalveti> kdub: hm, which image are you using? a recent one?
[16:21] <asac> yeah hold it
[16:21] <ricmm> sil2100: hold unity-mir, qtubuntu and mir then
[16:21] <asac> not sure about desktop testing impact and all that either
[16:22] <asac> ricmm: sorry, but better to call it a day then :)
[16:22] <ricmm> release the rest thats queued (:>
[16:22] <rsalveti> kdub: syslog should tell more if the device id did indeed change
[16:22] <kdub> rsalveti, yeah cdimage-touch from yesterday for manta
[16:22] <sil2100> ricmm, asac: ok ;)
[16:23] <sil2100> asac: I also see some click related things needing release, such as unity-scope-click and ubuntu-download-manager - I think those should be ok to release?
[16:24] <asac> davmor2: maybe you could confirm thjat the image gets better when applying the read/write fixes by lool
[16:24] <asac> ?
[16:24] <asac> that would give us some confidence :)
[16:24] <asac> sil2100: why not :)
[16:24] <asac> sil2100: download-manager? is that an application?
[16:24] <asac> not a service?
[16:24] <asac> hmm
[16:25] <asac> sil2100: those are in which stack?
[16:25] <sil2100> asac: those are in the 'click-package' stack
[16:25] <sil2100> asac: the description says: Ubuntu Download Manager - daemon
[16:25] <kdub> rsalveti, thanks for the help, i get what's going on now
[16:26] <lool> ogra_, sergiusens, asac, davmor2: Outside of ofono and accounts, were there other regressions confirmed to be specific to r/o?  camera-app might be, but not 100% sure, anything else?
[16:26] <rsalveti> kdub: one other way would be disabling the android-tools-adbd upstart job and setting the property via ssh
[16:26] <rsalveti> and see if it works better
[16:26] <rsalveti> kdub: cool
[16:26] <ogra_> lool, not that we know of
[16:26] <sil2100> asac: ah ha, I see Ken missed one more thing that's ready for release - the ubuntu-ui-toolkit ;) But I'm a bit worried to release that on Friday (even though all the tests passed)
[16:26] <rsalveti> will go for lunch, let me know if it still fails for you
[16:27] <ogra_> lool, (i bet we find ten more over the next week though,, but nothing obvious)
[16:27] <davmor2> lool: possibly the video playback on previous RW images it has been fine in RO it sucks
[16:27] <ogra_> davmor2, does it play fine for the first secs and then turn into a slideshow with sound ?
[16:28] <ogra_> if so, thats normal until we get the new gstreamer stack
[16:28] <davmor2> ogra_: no basically a slideshow from the start
[16:28] <asac> sil2100: yeah. my experience tells me ubuntu-ui-toolkit is more dangerous
[16:28] <lool> sergiusens: crash in gallery-app is from libusermetricsinput1
[16:28] <ogra_> davmor2, so it degraded a bit then ... well, i wouldnt count that a blocker
[16:28] <asac> pmcgowan: bzoltan: we have a ubuntu-ui-toolkit and felt we shouldnt push it in late on friday. agree?
[16:29] <asac> sil2100: what does the changelog say?
[16:30] <sil2100> asac: looks like an AP fix...
[16:30] <sil2100> asac: * Do not duplicate the pointer instantiation on the autopilot emulators. (LP: #1220346)
[16:30] <sil2100> Fairly safe I suppose
[16:31] <asac> sil2100: do you have the diff?
[16:31] <doanac> sergiusens: python-autopilot doesn't seem to have changed yet in touch images. Its still on1.3.1+13.10.20130830-0ubuntu1
[16:31] <asac> sil2100: the upstream code diff? i couldnt find that easily in our system... seems we strip that off
[16:31] <doanac> is there something i need to do to get the updated version included?
[16:31] <asac> only packagieng diff is there
[16:31] <sil2100> asac: yes, that's another thing on my 'would be nice to have' - https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1220346-pointing_device/+merge/183719
[16:32] <sil2100> asac: it's AP changes only
[16:32] <lool> http://paste.ubuntu.com/6071055/
[16:33] <davmor2> asac, lool: click packages work, settings in apps are stored, notes are stored so the RO isn't effecting everything at least :)
[16:34] <lool> :-)
[16:34] <lool> sergiusens: http://paste.ubuntu.com/6071055/
[16:34] <asac> sil2100: feels too risky. its not clear if that is fixing any real autopilot bugs
[16:34] <asac> sil2100: so best it can do is break test
[16:34] <asac> sil2100: i think we should punch it in before going EOD
[16:36] <lool> sergiusens: Do you know how the usermetrics stuff works?
[16:36] <asac> after we have the next image
[16:36] <asac> sil2100: so leave it, lets kick image
[16:36] <asac> then start automation and if the image isnt good
[16:36] <asac> :)
[16:36] <asac> cry
[16:36] <davmor2> asac: how do I enable rw then?
[16:36] <cwayne_> stgraber, so i made sure that my tarball was all owned by root, and now .local/share is owned by root, so the chown still didn't work
[16:36] <asac> lool: tell davmor2 about the /var/lib fixes that we uploaded
[16:36] <asac> so he can validate that they help?
[16:36] <stgraber> cwayne_: what device are you testing on?
[16:36] <asac> thanks!
[16:37] <lool> davmor2: the accounts and ofono breakage should be fixed
[16:37] <cwayne_> stgraber, mako
[16:37] <lool> when the initramfs is rebuilt and the image is rebuilt
[16:37] <sil2100> asac: I published autopilot and mediascanner from the things that I could
[16:37] <sil2100> ;)
[16:37] <cwayne_> stgraber, so everything in the tarball should be owned by root, correct?
[16:37] <stgraber> cwayne_: yep
[16:37] <lool> asac: I had indirectly mentioned it, but confirmed again
[16:37] <stgraber> cwayne_: (I'm running a test here with a minimal custom image)
[16:38] <asac> davmor2: i think its apparmor rules you have to add
[16:38] <asac> sil2100: ok stuff in?
[16:38] <ogra_> lool, you forgot the android upload :)
[16:38] <stgraber> cwayne_: ok, reproduced the issue here, now to figure it out...
[16:38] <asac> sil2100: good, so once they are in relesae pocket
[16:39] <asac> lets continue
[16:39] <sil2100> asac: yes, waiting for them, checking for the status
[16:39] <cwayne_> whew, at least i'm not crazy :)
[16:39] <asac> sil2100: what about download-manager etc.?
[16:39] <asac> that not?
[16:39] <davmor2> lool: so you are pushing a new image with the fixes then?
[16:39] <lool> davmor2: eventually, will take some time still
[16:40] <ogra_> 3h i'd guess
[16:40] <asac> lool: which package are we waiting for ?
[16:40] <asac> ogra_: come on... 1h :)
[16:40] <asac> we are agile :-P
[16:40] <lool> asac: lxc-android-config to be published in saucy, then building android
[16:40] <ogra_> asac, its a chain of packages
[16:40] <asac> respinning is cheap :-P
[16:40] <asac> oha i dont think i want to know
[16:40] <asac> just dont run away :)
[16:41] <davmor2> asac: yes we are agile, that's why we can play dodgeball, computer systems on a fixed build time not so agile :D
[16:41] <ogra_> lool, does that stuff actually end up inside the initrd ? i thought it is read by the initrd from /
[16:42] <sergiusens> lool: not sure how usermetrics worked
[16:42] <Ikarus> ugh, I wish Ubuntu Touch on semi-supported devices had a nicer installer, instead of "download obscure here" "download other stuff there", etc
[16:42] <sergiusens> Ikarus: if porters supported it you could phablet-flash community
[16:43] <davmor2> asac: no data sources available I took two photos damn you phone :D
[16:43] <lool> sergiusens: it segfaults on startup at least
[16:43] <stgraber> cwayne_: [    3.709262] /init: line 5: chown: not found
[16:43] <lool> sergiusens: trying to su to usermetrics + running it => segv
[16:43] <lool> pete-woods: Hey!
[16:44] <lool> pete-woods: Could you help us debug usermetrics?
[16:44] <Ikarus> sergiusens: I know, but it's a shame people aren't driven to it :(
[16:44] <cwayne_> stgraber, huh, that seems not great
[16:44] <sil2100> asac: those as well
[16:44] <lool> pete-woods: it seems to segfault on startpu, at least with the readonly images
[16:44] <asac> sil2100: good
[16:44] <stgraber> cwayne_: yeah, I'm vaguely surprised we don't have chown in the initrd :)
[16:44] <stgraber> cwayne_: it's easily fixable though
[16:44] <ogra_> asac, so the ofono fix should be ready without an upload chain ...
[16:45] <ogra_> i just checked the code
[16:45] <sil2100> There's nothing better than a Friday image!
[16:45] <lool> sergiusens: Ok, found the gallery-app thing
[16:45] <cwayne_> stgraber, ah, easily fixable, my favorite type of bug :)
[16:45] <jdstrand> davmor2: re the conversation between you and asac> what is broken that needs rw?
[16:46] <awe> jdstrand, /var/lib/ofono for one
[16:46] <awe> fix has been uploaded
[16:46] <stgraber> cwayne_: well, for a definition of easily fixable that'll take half a day to land in an image
[16:46] <sergiusens> jdstrand: /var/lib/ofono and /var/lib/Accounts
[16:46] <asac> jdstrand: also something for mterry where the new intro saves its configs (also uploaded i think)
[16:46] <cwayne_> stgraber, right, but that's more waiting time than working time, right??
[16:47] <ogra_> that was /var/lib/Accounts
[16:47] <jdstrand> asac, davmor2: that isn't apparmor. that is ro fs. stgraber uploaded fixes to lxc-android-config for that
[16:47] <pete-woods> lool: it tries to write to /var/usermetrics
[16:47] <sergiusens> jdstrand: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/revision/89
[16:47] <asac> right
[16:47] <pete-woods> could that be it?
[16:47] <sergiusens> jdstrand: nope
[16:47] <jdstrand> sergiusens: oh?
[16:48] <sergiusens> jdstrand: no as in, it isn't apparmor
[16:48] <sergiusens> :-)
[16:48] <jdstrand> sergiusens: ah, yes
[16:48] <sergiusens> jdstrand: I would of pinged you if it was
[16:48] <jdstrand> hehe
[16:48] <sergiusens> ;-)
[16:48] <davmor2> jdstrand: No I think apparmour was mentioned as the way to get out of RO mode
[16:48] <stgraber> cwayne_: right, just two uploads
[16:48] <cwayne_> stgraber, awesome :)
[16:48] <jdstrand> sergiusens: ack, I saw someone mention apparmor might need to be updated, so thought I'd check on it
[16:48] <cwayne_> maybe i'll just take a break until later today then :P
[16:48] <jdstrand> sergiusens: thanks for handling that for me :)
[16:49] <plars> asac: results on 20130906 should all be there for except for smem and memevent, sdk needs to rerun on mako... it got that ssl error like I saw recently
[16:50] <pete-woods> lool: is there somewhere more correct (/var/lib/... ?) that it should keep its database?
[16:51] <stgraber> pete-woods: I just uploaded a fix for /var/lib/usermetrics, should hopefully be good in the next image
[16:51] <sergiusens> rsalveti: ogra_: lool asac camera error http://paste.ubuntu.com/6071136/
[16:51] <ogra_> plars, heh, why does mako run one test less
[16:51] <plars> ogra_: see above, it got an ssl error... network seemed ok but when it tried to connect to lp it failed with that ssl error
[16:52] <lool> pete-woods: https://bugs.launchpad.net/libusermetrics/+bug/1221839
[16:52] <plars> ogra_: so it missed the sdk test
[16:52] <lool> pete-woods: No, that dir is fine
[16:52] <ogra_> plars, ah
[16:52] <plars> ogra_: it's queued up
[16:52] <lool> pete-woods: This is like low priority, we'll fix the write issue
[16:52] <ogra_> yeah, i didnt make the connnection
[16:52] <lool> pete-woods: but would be good to fix the lib not to crash if service dies and service to report something useful (per bug)
[16:52] <plars> ogra_: the sdk test doesn't actually do much though, the chances of it failing for anything to be concerned about are pretty much zero
[16:53] <ogra_> yeah
[16:53] <lool> sergiusens: camera error is found
[16:53] <lool> sergiusens: i thnk
[16:53] <sergiusens> lool: oh, good, what was it exactly?
[16:53] <pete-woods> lool: okay, cool I will improve the error reporting :)
[16:53] <lool> sergiusens: this usermetrics bt I showed you because /var/lib/usermetrics wasn't in writable_paths  :-)
[16:54] <lool> pete-woods: thanks  :-)
[16:54] <ogra_> nice !
[16:54] <sergiusens> lool: might be the same as for camera?
[16:55] <ogra_> that is for camera
[16:55] <lool> sergiusens: it is the camera one
[16:55] <lool> sergiusens: didn't you see my bt?
[16:55] <lool> sergiusens: this is from the .crash file I mentioned
[16:55] <lool> sergiusens: 18:34 < lool> sergiusens: http://paste.ubuntu.com/6071055/
[16:55] <sergiusens> lool: ah, no, sorry
[16:55] <lool> sergiusens: this is with debug symbols, it's in usermetrics
[16:56] <lool> sergiusens: it doens't like when it's dbus service dies
[16:56] <pete-woods> sergiusens: I'm going to improve the libusermetrics client library so that it handles a missing daemon more gracefully
[16:58] <lool> pete-woods: <3
[16:58] <pete-woods> :)
[16:59] <lool> ♥ even
[17:00] <ogra_> you and your utf8
[17:00] <sergiusens> what is utf8?
[17:00] <sergiusens> :-)
[17:00] <ogra_> :)
[17:00] <lool> (can't believe the compose sequence for ♥ is actually < + 3)
[17:00] <ogra_> heh
[17:00] <pete-woods> the guys who "play with bits" for a living tend to do stuff like that :)
[17:01] <lool> there must be some unicode easter eggs
[17:01]  * lool tries compose + e a s t e r e g g
[17:01] <pete-woods> I always like how a simple mask operation is sufficient to uppercase / lowercase ASCII
[17:01] <stgraber> asac, lool, plars: daily-proposed re-generation is slowly going, I expect it to be done in the next 2 hours, at which point I suspect the QA tools will freak out as they'll see 4-5 new builds showing up at once.
[17:01] <pete-woods> no mapping required
[17:01] <stgraber> all of which should be canceled except for the latest one
[17:01] <stgraber> from that point on, things should behave normally again
[17:01] <lool> stgraber: sounds good  :-)
[17:02] <plars> stgraber: ok, any way to notify when it happens? what all will be in this one?
[17:03] <stgraber> plars: I'm watching nusakan as it imports everything, so I can probably give you a heads up minutes after it's published
[17:03] <stgraber> plars: basically every single build that's been published since the last stable one will show up as their own version in daily-proposed
[17:04] <stgraber> plars: so you'll see a bunch of old builds appearing which you probably don't want to test
[17:04] <plars> stgraber: will it be a whole lot of updates quickly? or will there be quite a bit of time between each?
[17:05] <plars> stgraber: if it all happens within 5 min. or so, shouldn't be any problem except I'll need to kill off the extras
[17:05] <ogra_> stgraber, note that i dropped the cronjob for touch, so we dont get any unexpected builds and dont step on our own toes wrt manual building
[17:06] <stgraber> plars: it'll be a single index.json change showing you 3-4 new images in one shot
[17:06] <plars> stgraber: oh, that should be no problem at all then
[17:06] <stgraber> ogra_: ok. I'll probably trigger a new image myself once the re-import is done so it can pick up the initrd and lxc-android-config changes.
[17:07] <plars> stgraber: jenkins is pretty dumb about it, it just sees that the file had some kind of change, and kicks of a new test. The test is just going to phablet-flash whatever is in daily-proposed
[17:07] <ogra_> dont forget the android rebuild for the initrd :)
[17:07] <plars> but I'll keep an eye on it just in case
[17:07] <stgraber> ogra_: yep, I know, it's in my post-lunch todo list :)
[17:07] <ogra_> i dropped the note from the initramfs package ... i should probably just have changed it
[17:08]  * ogra_ thinks automated rebuilding of package chains should be a topic for next UDS
[17:09] <lool> so I'm getting debian #713032 when rebuilding gallery-app but it built fine in the archive
[17:09] <lool> not sure why
[17:10] <lool> I'll just blame it on CMake
[17:10] <asac> stgraber: can we maybe do that migration on monday? i am a bit scared :)
[17:10] <asac> and you can also have fun :)?
[17:10] <asac> i thought you said wed :)
[17:10] <asac> not today :)
[17:10] <stgraber> asac: I'm just running what we said we'd earlier with lool
[17:11] <lool> asac: he said he would finish the new code to do things completely differently wed-thursday if he can focus on it, but then he went to implement the quick and dirty interim solution for today
[17:11] <asac> oha
[17:11] <stgraber> asac: I haven't even started working on the rewritten tool (too busy answering everyone's questions in here)
[17:11] <asac> well, if you can juggle it with plars thats great
[17:11] <asac> but always keep a path to back out
[17:11] <asac> :)
[17:11] <asac> we wanted to get an image out in 3h :)
[17:11] <asac> or so
[17:11] <asac> err in 1h or so
[17:15] <eolo999> hi again
[17:16] <eolo999> maybe someone has read my help request of yesterday night (europe)
[17:17] <lool> sergiusens davmor2 : BTW, locally fixing usermetrics + running it, I can run camera-app + take pictures + return to shell + see them in gallery-app + see the count on the lock screen
[17:18] <eolo999> anyway I am victim of this error while phablet-flashing my nexus 7:
[17:18] <eolo999> ERROR:phablet-flash:Command 'adb shell mount /sdcard/' returned non-zero exit status 255
[17:18] <cwayne_> ok here's a weird bug:
[17:18] <lool> eolo999: anything prior to that?
[17:18] <davmor2> lool: so it was user metrics causing everything to die then
[17:18] <lool> davmor2: yes
[17:18] <lool> davmor2: it will likely fix other apps too
[17:19] <cwayne_> in my custom pre-session.d/ script, i make a symlink to /usr/lib/arm-linux-gnueabihf/, but once it's run ont he phone, the symlink points to /usr/lib/x86_64-linux-gnu/
[17:19] <eolo999> that was using cdimage-touch; while using ubuntu-system the error is while mountin /data
[17:20] <eolo999> INFO:phablet-flash:Restarting device... wait
[17:20] <eolo999> INFO:phablet-flash:Restarting device... wait complete
[17:20] <eolo999> error: device not found
[17:20] <eolo999> ERROR:phablet-flash:Command 'adb shell mount /sdcard/' returned non-zero exit status 255
[17:20] <eolo999> sorry for pasting here
[17:20] <lool> eolo999: it doesn't seem to be able to find the device
[17:20] <lool> eolo999: do you care to preserve what's currently on the device?
[17:20] <popey> eolo999: does "adb devices" list it?
[17:20] <eolo999> It loses connection while restarting the devices
[17:21] <eolo999> it hangs with the open droid robot
[17:21] <eolo999> :)
[17:21] <lool> eolo999: do you see the ubuntu logo in the recovery?
[17:21] <eolo999> nope
[17:23] <eolo999> what do you mean by in the recovery
[17:23] <eolo999> ?
[17:23] <eolo999> popey: it list the device before flashing
[17:25] <cwayne_> lool, ping
[17:25] <eolo999> maybe I missed something but it seems that this kind of disconnect when restarting is affecting a lot of people
[17:27] <lool> cwayne_: pong
[17:27] <cwayne_> lool, hey, i was seing a really weird bug earlier in one of my custom pre-session.d/ scripts
[17:28] <cwayne_> lool, i was trying to symling /usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu to /custom/usr/share/themes, but it was somehow uinstead setting the link to /usr/lib/x86_64-linux-gnu/
[17:28] <lool> eolo999: press volume up + volume down + power when booting, you'll get the fastboot menu; select recovery; if that doesn't show an Ubuntu logo, you want to rebootstrap, perhaps starting with android (simplest) or manually (no written instructions)
[17:28] <eolo999> ok
[17:29] <lool> cwayne_: how so?
[17:29] <cwayne_> lool, i have no idea.
[17:30] <lool> cwayne_: so were you doing this on an installed device?
[17:30] <lool> cwayne_: what image were you using and what command did you run?
[17:30] <lool> cwayne_: x86_64-linux-gnu is particularly suspicious  :-)
[17:31] <sergiusens> eolo999: adb kill-server; sudo adb start-server and start over
[17:31] <davmor2> lool yay /me goes off for tea
[17:31] <eolo999> sergiusens: I tried both with and without sudo
[17:31] <cwayne_> lool, on an installed device, and the command i ran was ln -s /usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu /custom/usr/share/themes
[17:32] <lool> cwayne_: is your goal to create a symlink in /custom/usr/share/themes that points at /usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu?
[17:32] <cwayne_> yep
[17:33] <lool> cwayne_: http://paste.ubuntu.com/6071323/
[17:33] <lool> WFM
[17:34] <cwayne_> lool, yeah i just did it again and now it worked
[17:34]  * cwayne_ is very confused, but at least it's working now :)
[17:40] <lool> cwayne_: :-)
[17:45] <sergiusens> rsalveti: ping
[18:18] <asac> lool: where do we stand :)?
[18:18] <asac> android alrewady building?
[18:18] <ogra_> https://launchpad.net/ubuntu/saucy/+source/android/20130905-0ubuntu3
[18:19] <ogra_> another 20min or so
[18:19] <ogra_> (plus proposed migration ... plus promotion)
[18:20] <asac> cool
[18:20] <rsalveti> sergiusens: pong
[18:20] <asac> ogra_: thx
[18:20] <asac> sil2100: all your stuff is all in release now?
[18:21] <davmor2> cwayne_: there is a difference between you being confused cause of the shiny shiny and it being confusing ;)
[18:21] <cwayne_> davmor2, :P
[18:23] <davmor2> cwayne_: I see you're not trying to deny it though :D
[18:23] <sergiusens> rsalveti: hey, where are we getting adbd from in recovery.img?
[18:23] <sergiusens> rsalveti: stock android build or is it being repacked?
[18:24] <jdstrand> mdeslaur, jjohansen, rsalveti, ogra_: fyi, 'Dealing with AppArmor policy for hardware-specific access to devices'. please comment if you object (a +1 would be nice too :)
[18:24] <rsalveti> sergiusens: sorry, not sure I follow, do you mean where in the code adbd is being copied as part of recovery?
[18:24] <sergiusens> rsalveti: I'm having the suspicion that adbd is compiled in host mode as logcat expect /dev/log (instead of /dev/alog) and wait-for-device doesn't work (the latter is what I want fixed)
[18:24] <jdstrand> mdeslaur, jjohansen, rsalveti, ogra_: sent to ubuntu-devel@
[18:24] <rsalveti> jdstrand: thanks
[18:25] <rsalveti> sergiusens: oh, right, let me check
[18:25] <sergiusens> rsalveti: if I fixed the latter I can get rid of the timeouts when rebooting
[18:25] <jdstrand> rsalveti: here is incentive for you. if I get a +1, then I'll assign it to myself :)
[18:25] <sergiusens> rsalveti: just run adb wait-for-device when the system is booted
[18:25] <jdstrand> rsalveti: is that bribery?
[18:25] <sergiusens> then adb reboot recovery
[18:25] <sergiusens> and run again
[18:26] <rsalveti> sergiusens: sure, I know wait-for-device works fine with our image, never tested with recovery
[18:26] <rsalveti> let me check
[18:26] <rsalveti> jdstrand: haha, sounds good
[18:26] <sergiusens> rsalveti: also try to run logcat... that will give you the ultimate hint
[18:26] <sergiusens> ogra_: do you know?
[18:26] <sil2100> asac: actually... not all, but it's ok
[18:27] <sil2100> asac: since autopilot didn't move out of -proposed since probably it's blocked, even though there's an FFe for the feature
[18:27] <sil2100> Laney: hi!
[18:27] <asac> ogra: can you check the autopilot in proposed?
[18:27] <asac> sil2100: i think it needs a beta freeze exception
[18:28] <sil2100> asac: I thought an accepted FFe was enough
[18:29] <ogra_> asac, autopilot-touch/powerpc unsatisfiable Depends: libautopilot-qt (>= 1.3)
[18:29] <ogra_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[18:29] <asac> sil2100: can you check if autopilot-qt is ftbfs on power?
[18:30] <ogra_> asac, its a binary dep
[18:30] <ogra_> not a build dep
[18:31] <ogra_> proposed migration checks binaries :)
[18:32] <Laney> sil2100: you need to check update_excuses and update_output
[18:32] <Laney> there you will see that it is not blocked
[18:33] <rsalveti> sergiusens: logcat doesn't seem to be available in recovery
[18:33] <mdeslaur> jdstrand: thanks, sent reply
[18:33] <sergiusens> rsalveti: it is
[18:33] <rsalveti> even with adb shell
[18:33] <sergiusens> rsalveti: mount /system if it isn't mounted
[18:34] <rsalveti> oh, right
[18:34] <rsalveti> not by default :-)
[18:34] <sergiusens> rsalveti: /system/bin/logcat ... it will tell you it can't open /dev/alog/main, but if you ln -s /dev/alog /dev/log it will work
[18:35] <rsalveti> sergiusens: working fine here
[18:35] <rsalveti> sergiusens: are you sure you're using our recovery?
[18:35] <rsalveti> actually, you are
[18:35] <rsalveti> because logcat in your case is looking for /dev/alog
[18:35] <rsalveti> but I have /dev/alog/ by default
[18:35] <sergiusens> rsalveti: yes... I am... I have the ubuntu logo :-P
[18:36] <jdstrand> mdeslaur: I am both surprised and not surprised you liked. On the one hand, it was your idea, on the other hand, you hate ideas :P
[18:36] <sergiusens> rsalveti: might be a maguro thing...
[18:36] <rsalveti> let me check with maguro
[18:36] <jdstrand> mdeslaur: seriously though, thanks for working through that with me
[18:36]  * jdstrand hugs mdeslaur 
[18:36] <rsalveti> but wait-for-device didn't work, so that's something to investigate
[18:36] <rsalveti> we might be missing something
[18:36] <rsalveti> would indeed be useful to have it there
[18:37] <sergiusens> rsalveti: not useful, necessary ;-)
[18:38] <sergiusens> rsalveti: hmmm... logcat worked for me now... (but I flashed the legacy image totry something)
[18:38] <mdeslaur> jdstrand: hehe, no it's always worth discussing...it happens to be the one I like best, but I'm always open to being convinced otherwise.
[18:38] <jdstrand> mdeslaur: I know you are :) I'm just kidding
[18:38] <rsalveti> sergiusens: what do you mean by legacy? ;-)
[18:38] <rsalveti> unflipped?
[18:39] <rsalveti> flipped?
[18:39] <rsalveti> sergiusens: /dev/alog is also available in maguro for me
[18:39] <jdstrand> mdeslaur: this issue has been keeping me up at nights. I will be glad to get it fixed
[18:41] <sergiusens> rsalveti: yeah, not sure what happened...
[18:42] <mdeslaur> jdstrand: yes, bundling it with the device-specific stuff instead of the main policy package is way better. You'll sleep well tonight :)
[18:42] <sergiusens> rsalveti: works for me now :-/
[18:42] <sergiusens> rsalveti: but failed once
[18:42] <mdeslaur> jdstrand: I guess it will also move it to the device-specific image?
[18:42] <rsalveti> sergiusens: well, but do you need logcat?
[18:42] <sergiusens> arg, I reset my config and now don't have eternal history
[18:43] <sergiusens> rsalveti: nope, I was just wanting to take a look
[18:43] <sergiusens> rsalveti: just in case some error was being logged for wait-for-device
[18:43] <rsalveti> right, let's just see what needs to be done to have a working wait-for-device
[18:43] <rsalveti> right
[18:43] <jdstrand> mdeslaur: I figure I would implement it in that manner like you suggested, yes
[18:45] <rsalveti> 1214        /* Allow a command to be run after wait-for-device,
[18:45] <rsalveti> 1215            * e.g. 'adb wait-for-device shell'.
[18:45] <mdeslaur> jdstrand: I haven't looked at the core/device image split at all (heck, if it's even implemented)...is it based on packages, or directories?
[18:45] <rsalveti> cool, didn't know about that
[18:45] <sergiusens> rsalveti: really? it's the best :-)
[18:45] <rsalveti> :-)
[18:45] <rsalveti> best documentation is the code
[18:45] <sergiusens> rsalveti: I discovered you can do wait-for-local wait-for-any as well
[18:45] <rsalveti> yeah, awesome
[18:54] <PLA_> To chime in with eolo999, I get "exit status 255" when running "phablet-flash ubuntu-system --no-backup". More info here: http://pastebin.ubuntu.com/6071558/
[18:57] <sergiusens> PLA_: can you adb reboot recover and then adb devices ?
[19:02] <PLA_> adb reboot recover and then adb devices works.
[19:04] <_5m0k3> PLA_: Did you try running phablet-flash ubuntu-system --no-backup a second time?  Mine worked the second go-around
[19:06] <PLA_> I've tried "phablet-flash ubuntu-system --no-backup" many times. Always ends the same: http://pastebin.ubuntu.com/6071558/
[19:07] <popey> PLA_: what device?
[19:07] <PLA_> Nexus 4
[19:08] <mhall119> wow! the Launcher lets you add icons now!
[19:08] <_5m0k3> tbh, I'm really not digging the new system images.  It just feels so... restricted
[19:09] <asac> ogra_: where are we?
[19:14] <mterry> mhall119, you've posted on G+ a few times about wallpapers.  Do you set it manually?  The system settings background panel doesn't seem to work for me
[19:14] <mterry> (in Touch)
[19:15] <AskUbuntu> Galaxy Nexus fails to boot after unsuccessful Ubuntu Touch installation | http://askubuntu.com/q/342298
[19:17] <mhall119> mterry: yeah, I manually call gsettings from the terminal-app
[19:18] <mhall119> will be much nicer when the background panel in system-settings can do it
[19:18] <mterry> mhall119, OK, cool.  Note that soonish, a branch I wrote to support a separate background on the greeter will look like a regression to you then (your greeter will revert to default background).  Let me get a command line for you to set that as you like, once that lands...
[19:19] <mterry> dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User32011 org.freedesktop.Accounts.User.SetBackgroundFile string:/usr/share/backgrounds/background_3.png
[19:19] <mterry> mhall119, ^
[19:20] <mhall119> thanks mterry, I'll tuck that away somewhere safe :)
[19:22] <ogra_> asac, i have no idea whats up with autopilot ... whikle it complains about ppc it also says "Valid Candidate"
[19:23] <balloons> can anyone with a device handy confirm this bug? Bascially, rssreader doesn't seem to let you add a new feed on a phablet device. https://bugs.launchpad.net/ubuntu-rssreader-app/+bug/1221893
[19:24] <jdstrand> mdeslaur: I don't know. I figured I'd start with lxc-android-config and go from there
[19:24] <popey> balloons: lemme see
[19:25] <yulia> Good evening guys, would any of you please have a little time to help me about unlocking the simcard on a Nexus 4?
[19:25] <balloons> popey, ty :-)
[19:26] <sergiusens> balloons: works for me
[19:27] <balloons> sergiusens, did you add a new topic as part of the creation?
[19:27] <balloons> it locks up my manta and crashes
[19:27] <sergiusens> balloons: although adding is not intuitive
[19:27] <popey> balloons: it doesnt crash here
[19:27] <sergiusens> balloons: yeah, topic is N
[19:27] <popey> it freezes
[19:27] <balloons> sergiusens, what device? popey, what device?
[19:27] <popey> n4
[19:27] <sergiusens> balloons: I added omg ubuntu wordpress something on maguro
[19:27] <sergiusens> and ro images
[19:27] <popey> ro here too
[19:28] <balloons> ok so.. I'm still on the flipped, I haven't swapped yet.. it was on the agenda for today once this was fixed :-p
[19:28] <sergiusens> balloons: might be good to state if a specific topic/feed would crash and complete the bug with more info
[19:28] <popey> +1
[19:28] <balloons> well it sounds like it's crashing for popey also? the feed doesn't matter for me
[19:29] <sergiusens> balloons: how about topic length
[19:29] <sergiusens> ?
[19:30] <balloons> sergiusens, I too did a 1 char topic.. I mean I can mess with it a bit more
[19:30] <sergiusens> balloons: ok, I tried 'n' and 'something' as topics
[19:30] <balloons> just to confirm, popey you did experience a lock-up right? did the app continue or did it lock completely?
[19:31] <popey> yes, it froze for a bit
[19:31] <balloons> popey, but it continued? you got back to the main view and could see the feed?
[19:32] <balloons> just want to update the bug accordingly.. it might just be me, heh
[19:32] <ashvani> Hi
[19:35] <popey> balloons: came back to the main view, yes
[19:35] <popey> but the feed didn't update, dunno if it's a duff feed
[19:36] <balloons> popey, k, I'll note it and keep digging
[19:36] <ashvani> can anybody help me
[19:36] <ashvani> in installing ubantu on mobile
[19:39] <AskUbuntu> What is the diference between the images of Ubuntu Touch? | http://askubuntu.com/q/342303
[19:41] <stgraber> sergiusens: any idea as to what happened to robru (ubuntu-phone mailing list)?
[19:41] <asac> ogra_: we dont need that autopiolot do we?
[19:41] <asac> the rest is in
[19:41] <asac> kick off a build
[19:41] <stgraber> sergiusens: if I had to guess, I'd go with insufficient disk space or some kind of adb disconnect while transfering the image
[19:41] <sergiusens> stgraber: let me check list
[19:42] <asac> ogra_: care most about the android changes for /var/lib
[19:43] <sergiusens> stgraber: protocol failure ... plars is the only person I know that sees that consistently
[19:43] <sergiusens> stgraber: other reasons for a protocol failure are bad cable or micro disconnects
[19:43] <stgraber> robru: do you get that error consistently?
[19:44] <plars> we see it on occasion in the automated runs
[19:44] <asac> sergiusens: in case ogra is gone you might need to give us a new image kick :)
[19:45] <karni> Hi guys. I'd like to touch /userdata/.writable_image, but there's no userdata in my /
[19:45] <sergiusens> asac: sure, like now? I'm sorry I wasn't tracking the channel to know what we are missing
[19:45] <karni> Where should I look for it?
[19:45] <stgraber> robru: try re-running phablet-flash ubuntu-system from the recovery mode (probably with -d <device name> as it'll fail to auto-detect)
[19:45] <asac> sergiusens: i dont know either...  i believe ogra thought we need to wait for autopilot
[19:45] <asac> but the rest is in
[19:45] <asac> stgraber: which packge do we need to check to see if the /var/lib rw fixes are in archive?
[19:45] <sergiusens> asac: good; lool or stgraber did we get the metric stuff in persistent mode?
[19:46] <sergiusens> asac: android-lxc-config
[19:46] <stgraber> sergiusens: I've got a lxc-android-config change and an initrd (android) change that I want in the next build
[19:46] <stgraber> sergiusens: AFAIK both should be ready now, though nusakan is busy re-importing daily-proposed at the moment so don't expect anything to publish to touch_ro for at least another hour
[19:47] <stgraber> sergiusens: so I'd say, kick the build in ~30min, that way it should finish around the time daily-proposed is done regenerating
[19:47] <asac> stgraber: i am talking about what was uploaded
[19:47] <sergiusens> stgraber: well I need to kick cdimage first
[19:47] <asac> a fwe hours ago :)
[19:47] <sergiusens> asac: it's up   https://launchpad.net/ubuntu/saucy/+source/lxc-android-config/0.89
[19:47] <stgraber> asac: sure and as I said, that's lxc-android-config and android
[19:48] <asac> ok are both in the archive?
[19:48] <asac> then lets go
[19:48] <stgraber> sergiusens: yes, that's what I meant, wait 30min before kicking the build
[19:48] <sergiusens> asac: https://launchpad.net/ubuntu/saucy/+source/android/20130905-0ubuntu3
[19:48] <asac> otherwise we wont see anyting that might have 3g fixed
[19:48] <asac> today
[19:48] <sergiusens> stgraber: ok, will wait and continue with other things
[19:48] <asac> sergiusens: wait?
[19:48] <stgraber> sergiusens: if you kick it now, it'll just end up having to wait 30min not being published while nusakan finishes catching up on the daily-proposed import
[19:48] <sergiusens> asac: lets wait 30'
[19:48] <asac> is it really important what we wait for?
[19:48] <karni>  2) Use the experimental writable flag by doing touch
[19:48] <karni>     /userdata/.writable_image and rebooting your device.
[19:48] <karni> Can someone explain this to me ? :) ↑
[19:48] <asac> sergiusens: i would prefer if i could still find someone to test the build once its ffinished :)
[19:48] <asac> and its friday
[19:49] <asac> not sure if thats realisitic anyway :)
[19:49] <asac> but given how busted the touch_ro folks are... i am not sure
[19:49] <asac> sergiusens: ah ic
[19:49] <stgraber> asac: if we build it now it won't be published for at least another hour anyway since we need nusakan to finish catching up on the daily-proposed re-import first
[19:49] <sergiusens> asac: I can corroborate the regressions are gone once the build is done
[19:49] <asac> yeah i am bad at reading
[19:49] <asac> so no way
[19:49] <asac> ok
[19:49] <asac> i hope there will be no issues
[19:50] <stgraber> asac: so we could kick it now but all it'll achieve is making nusakan even slower and making my channel re-generating take even longer :)
[19:50] <asac> sergiusens: we need to punch it through utah still
[19:50] <asac> plars that is :)
[19:50] <asac> not sure how long he can be here at all
[19:50] <sergiusens> asac: plars is an hour behind me :-)
[19:50] <asac> stgraber: your and sergiusens call... the facts are above
[19:50] <asac> ok
[19:50] <asac> so thend o what needs to do
[19:50] <asac> but dont forget :)
[19:50] <asac> i am out for 1h
[19:50] <asac> cu
[19:51] <sergiusens> asac: we'll manage with stgraber, he can kick off cdimage too I think
[19:51]  * plars is just waiting on a new image :)
[19:52] <stgraber> yep, I definitely have shell access to nusakan (otherwise it'd be a nightmare to do my system-image or ubuntu-release work :))
[19:53] <stgraber> sergiusens: I still have 7 delta images to generate, I'll kick a build once I'm half way done, that should make the timing right
[19:54] <sergiusens> stgraber: ack
[19:55] <rah> I have a bunch of .img files in out/target/product/*/
[19:56] <rah> there, for example, ramdisk.img, ramdisk-recovery.img, recovery.img, system.img, userdata.img, boot.img
[19:56] <rah> which should be flashed to which nand partitions?
[19:57] <rsalveti> jdstrand: 3) -> +1
[19:58] <rsalveti> as long we have this documented in the porting guide I'm fine
[19:58] <jdstrand> \o/
[19:58] <jdstrand> yeah
[19:58] <rsalveti> can't reply to the ml yet as I didn't yet get the email
[19:58] <rsalveti> not sure what happens with ubuntu-devel
[19:58] <jdstrand> that's weird, I accidentally sent it twice :)
[19:58] <ogra_> stgraber, thanks
[19:58] <rsalveti> seems the only list that takes a few hours/days for me to get all the emails
[20:00]  * stgraber is really quite happy with the current system-image importer performance, diffing two 1.2GB images in ~5min including compression/decompression is pretty reasonable
[20:01] <rsalveti> cool
[20:04]  * eolo999 is reinstalling restoring android :(
[20:04] <lool> stgraber: I was just checking whether I would see pxz in top, and I did  :-)
[20:04] <lool> stgraber: good to see it's put to good use on the day after it gets added
[20:06] <eolo999> sergiusens: what does your comment on https://bugs.launchpad.net/phablet-tools/+bug/1215436 means? You catched the problem?
[20:07] <lool>    android | 20130905-0ubuntu3 | saucy/multiverse | source, all
[20:07] <lool> sergiusens: Should I kick a build?
[20:07] <sergiusens> eolo999: no, we are living with a workaround for a while
[20:07] <sergiusens> lool: stgraber was going to
[20:07] <lool> ah he needs to finish the import
[20:07] <stgraber> lool: yeah, today would be a nightmare if pxz wasn't installed :)
[20:08] <sergiusens> lool: yup
[20:08] <eolo999> sergiusens: that means I can give a second try?
[20:08] <sergiusens> eolo999: it doesn't mean anything
[20:08] <eolo999> ok
[20:09] <rah> ogra_: any idea which .img files go where in a device's NAND?
[20:09] <eolo999> can you describe the workaround in brief?
[20:09] <stgraber> lool: I think that'll officially be the longest import-cdimage run though, generating 115 full tarballs and 110 deltas :)
[20:10] <lool> wow
[20:10] <lool> stgraber: so you're reimporting everything?
[20:10] <stgraber> lool: yep, daily-proposed is technically a new channel without any relation to daily, so it's re-importing absolutely everything
[20:11] <lool> stgraber: hmm now that I thin of it, we could have named it something sensical
[20:11] <lool> like daily-all or something
[20:11] <lool> and kept it
[20:11] <lool> *think
[20:12] <stgraber> lool: 0.93 tarball/minute, that's pretty good!
[20:12] <stgraber> lool: well, once I'm done with my changes, daily-proposed will containg all images, each with a delta from the latest stable
[20:13] <stgraber> lool: (I also disabled garbage collection for now, so we won't be throwing anything away until I'm done with my changes)
[20:14] <stgraber> image generation is done, starting publishing now.
[20:16] <rah> am I on ignore or what?
[20:16] <stgraber> max version of daily-proposed will move from 5 (current) to 27 (after re-import)
[20:17] <stgraber> sergiusens: I just kicked a touch build now
[20:27] <stgraber> plars: new daily-proposed has been published, current tip is 27
[20:27] <plars> ack
[20:27] <lool> cool
[20:27] <lool> plars: another image coming soon though
[20:28] <plars> stgraber: this image is just renumbered though right? no difference from 20130906?
[20:28] <stgraber> plars: right, that's 20130906
[20:28] <stgraber> plars: .1 is coming in ~30min
[20:29] <cwayne_> stgraber, i dont suppose the chown fix is in?
[20:29] <stgraber> cwayne_: .1 should have the chown fix yeah
[20:29] <cwayne_> stgraber, awesome thanks
[20:40] <sergiusens> xnox: can you try apt-get install libnotify-dev:armhf in your chroot?
[20:42] <sergiusens> xnox: this is what I get http://paste.ubuntu.com/6072019/
[20:43] <xnox> sergiusens: do you by any chance have an "rc" removed, but not purged instance of libpython2.7-minimal:amd64 ?
[20:43] <xnox> sergiusens: what's the output of "$ dpkg -l | grep python2.7-minimal" ?
[20:43] <sergiusens> xnox: hm, I didn't purge, but I did apt-get remove the bzr install that is in your original readme that brought this in
[20:43] <xnox> and probably of a different version as well?
[20:44] <asac> sergiusens: any luck on getting an image slot :)?
[20:44] <sergiusens> asac: stgraber triggered
[20:44] <asac> sergiusens: how long?
[20:44] <ogra_> asac, stgraber cares
[20:44] <asac> ah i see backlog
[20:44] <ogra_> 20min i'd say
[20:44] <asac> pi mal daumen
[20:44] <xnox> sergiusens: right, yeah, than you have config files left-overs from the previous package. Imho it's a dpkg bug and / or Multiarch spec. As the "rc" conf files are left around and are considered of a different version and thus in dpkg view of things "conflicting"
[20:44] <asac> :)
[20:45] <ogra_> jau
[20:45] <sergiusens> xnox: thanks, let me check, but that means no bzr in the schroot, right?
[20:46] <stgraber> asac: the image should be on cdimage within 10min, it'll take a bit longer for system-image to process so ogra's 20min sounds reasonable
[20:46] <stgraber> (the builder is currently in post-build cleanup)
[20:47] <ogra_> do you pull from nusakan or cdimage ?
[20:47] <stgraber> ogra_: directly from /srv on nusakan
[20:47] <xnox> sergiusens: your alternative is to do: $ apt-get install libpython2.7-minimal:amd64 libpython2.7-minimal:armhf
[20:47] <ogra_> awesome, the syncing to cdimage costs a good 5min,
[20:47] <stgraber> ogra_: all the system-image code runs under the cdimage user directly on nusakan (/srv/system-image.ubuntu.com), so reading from a mirror would be a bit stupid :)
[20:48] <xnox> sergiusens: cause you want both arches installed, configured, and same checksum conf-files.
[20:48] <sergiusens> xnox: got it, thanks
[20:48] <ogra_> stgraber, oh, i thought it runs on the new server ... heh
[20:48] <xnox> sergiusens: and then you should be able to keep bzr.
[20:48] <stgraber> ogra_: nope, the server I have for system-image is just the web server nusakan pushes to, all the actual system-image generation is done by nusakan
[20:49] <sergiusens> xnox: well I don't necessarily want it though, but thanks :-)
[20:49] <ogra_> cool
[20:50] <xnox> sergiusens: =) i'm guessing you weren't going to edit python internal config files either..... ;-)
[20:51] <asac> stgraber: yeah. i assume now that we do touch_ro, we cant flip order because system needs the other as input?
[20:51] <asac> stgraber: was the RT ticket closed?
[20:51] <asac> i think so
[20:51] <asac> something about performance that was
[20:52] <stgraber> yeah, IS finally backported pxz to precise, that's how I managed to re-import everything that quickly, otherwise it'd have taken over a day
[20:55] <asac> plars: guess slowly start prepping the lab :)
[20:55] <sergiusens> xnox: well fwiw I can't install python-minimal:amd64 and python-minimal:armhf
[20:56] <plars> asac: unless you want me to go ahead and roll out the branch we discussed earlier, I don't think there's anything I can do to prep for it right now... I was going to wait until tonight or tomorrow at the earliest to roll that out though
[20:56] <plars> asac: my plan was to wait until the testing on this image was done
[20:57] <stgraber> barry: hey, looks like system-image got confused, I'm updating my device on the daily-proposed channel, from version 4 to version 27 and for some reason it decided that the right path was 4 => 9 (looked like deltas) then 9 => 27 (full)
[20:57] <stgraber> barry: anyway, that wasn't supposed to work to begin with (since 4 is == 27) but still surprised that system-image didn't just tell me to grab the latest full :)
[20:58] <barry> stgraber: what does `system-image-cli --dry-run` say?
[20:58] <rah> what are android-boot.img and android-ramdisk.img in the output directory?
[20:59] <barry> stgraber: # system-image-cli -n -c daily-proposed
[20:59] <barry> Upgrade path is 27
[20:59] <barry>  
[20:59] <barry> # system-image-cli --info
[20:59] <barry>  
[20:59] <barry> current build number: 4
[20:59] <barry> device name: grouper
[20:59] <barry> channel: daily
[20:59] <barry>  
[20:59] <barry> stgraber: so from daily:4 -> daily-proposed:27 in one step
[21:00] <lool> 20130906.1 is up on cdimage
[21:01] <plars> stgraber: does the system-image update automatically once that happens? or do you have to kick something off? About how long after would that normally happen?
[21:02] <rah> xnox?
[21:02] <rah> asac?
[21:02] <rah> ogra_?
[21:02] <barry> plars: i think stgraber is doing it from the command line.  you have a lot more options from the cli
[21:06] <rah> :-/
[21:06] <plars> have to step away for just a bit, the tests will kick off automatically when the images show up and I'll be back shortly to monitor them
[21:07] <lool> plars: it's automatic
[21:07] <cwayne_> Kaleo, im still having some issues.. no matter what i set selected.fieldText to, the gallery app labels are always white
[21:09] <cwayne_> oops, nm
[21:10] <xnox> sergiusens: libpython2.7-minimal is multiarch and co-installable, But you can only have one python-minimal as it's normal executables and hence on one (host) arch only.
[21:11] <stgraber> looks like some were missing in the previous batch, system-image's consistency checker notice and is re-generating those now so publishing will take a bit longer than expected (probably another 10-15min)
[21:11] <stgraber> I'm quite happy that the check found those problems and solved them the right way, now I just need to figure out what happened to those files to begin with :)
[21:11] <xnox> stgraber: for grouper I get version 9 update and it's 404 =/
[21:12] <stgraber> xnox: what URL is 404 specifically?
[21:12] <xnox> rah: same what they are on android.....
[21:12] <xnox> stgraber: hm. I use the magical Updates UI which simply says ERROR 404 Retry ? button
[21:12] <xnox> (from ubuntu system settings app)
[21:13] <rah> xnox: I've never seen image files named "android-boot.img" on android, only files named "boot.img"
[21:13] <stgraber> xnox: ah, not useful then :) may be one of those files the consistency checker just noticed and fixed
[21:13] <cwayne_> Wellark, ping
[21:13] <stgraber> plars: build 28 published
[21:13] <xnox> stgraber: yeah, it's install & restart now =)
[21:13] <rah> xnox: I have "android-boot.img" and "boot.img"
[21:13] <stgraber> cwayne_: try now
[21:13] <rah> xnox: I'm asking what "android-boot.img" is
[21:14] <rah> xnox: are you maintaining that there is an "android-boot.img" file on android?
[21:14] <sergiusens> rah: it's the original android  boot.img
[21:15] <rah> sergiusens: what do you mean by "original"?
[21:15] <sergiusens> rah: it's the android boot img... we use an ubuntu one on ubuntu
[21:15] <rah> sergiusens: original implies some transition from a past state to the present state
[21:15] <rah> sergiusens: what was the past state?
[21:16] <rah> sergiusens: what was the transition?
[21:17] <rah> what's the difference between an "android" boot img and an "ubuntu" boot img?
[21:18] <sergiusens> rah: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_build.git;a=blob;f=core/Makefile;h=76eb3b87a3a881a786362e624da0c0d7f96acc9f;hb=refs/heads/phablet-saucy#l372
[21:18] <cwayne_> stgraber, doing a clean flash right now
[21:19] <rah> sergiusens: this doesn't tell me much
[21:21] <rah> this is like giving me the steps of a recipe when I asked "what's for dinner?"
[21:21] <rah> sergiusens: do you know what the difference is between the android-boot.img and boot.img files?
[21:21] <sergiusens> rah: I explained in layman terms and as verbose as can be... I call it a fail for me to explain and I'll leave it to someone else
[21:22] <sergiusens> rah: I already told you, one is the plain android boot image and the other is the ubuntu one
[21:23] <rah> that's a difference in the words you're using to describe them
[21:23] <rah> it tell me nothing
[21:23] <rah> one is "android", one is "ubuntu"
[21:23] <rah> right
[21:23] <rah> ok
[21:23] <rah> what does that mean?
[21:24] <rah> let's just leave it at fail
[21:24]  * rah -> gone
[21:26] <lool> images should be up
[21:26] <lool> I see 28 for grouper at least
[21:26] <lool> and mako
[21:31] <danielbeck> Hello! I'm the developer of the RSS Feed Reader "RamSamSam Reader" (Ubuntu App showdown). I wanted to ask for help: I want to know if the application adheres to the user interface guidelines and how I could improve the user interface.
[21:33] <xapel> I am trying to get Ubuntu touch flashed to an Asus Transformer 101 tablet. Not having much success at the moment. Can anyone help me please?
[21:38] <popey> xapel: has someone ported to the transformer?
[21:39] <cwayne_> mzanetti, ping
[21:39] <mzanetti> cwayne_: hi
[21:41] <robru> stgraber, I get "error: device not found", which is unsurprising since it won't turn on.
[21:41] <cwayne_> mzanetti, hey, so unity seems to automatically add icons to the launcher after its launched, even if its already on the launcher
[21:41] <xapel> popey: yes, I believe so. http://forum.xda-developers.com/showthread.php?t=2168473
[21:42] <Tom__> Hi there, I have just installed Ubuntu Touch on a supposedly new Galaxy Nexus, but there seems to be an issse
[21:42] <robru> stgraber, the error I quoted on the ml was from the first flash attempt, which caused the bricking. the tablet at the time displayed the recovery menu, but then it turned off and i can't get it back
[21:42] <asac> plars: thx
[21:42] <robru> stgraber, but note that I had previous flashes flipped images with great success, and many times. it's this system-image flash that hasn't worked for me
[21:42] <Tom__> ...issue with the screen and I was wondering whether it means the screen was used for a long time or something else..
[21:42] <mzanetti> cwayne_: yes. that's a bug that is fixed already, but we're having troubles with jenkins and can't release anything since 2 days
[21:42] <asac> plars: did the new image come out yet?
[21:43] <Tom__> When you set the entire screen to white, the entire surface becomes yellowish, except for the parts where the (previous) *black* Android bars were usually displayed (at the top and at the bottom of the screen). Black bars logically mean that the screen is almost unused in this area.
[21:43] <stgraber> robru: is that mako or grouper?
[21:43] <robru> stgraber, grouper
[21:44] <stgraber> robru: ok, get it to reboot, as soon as you see the google logo press both volume buttons at the same time
[21:44] <stgraber> robru: that should get you into fastboot, then using the volume buttons, select recovery mode and enter using the power button
[21:44] <robru> stgraber, oh, wait, now phablet-flash got it into recovery mode. no idea why... it just found the device this time
[21:45] <asac> which image version are we waiting for?
[21:45] <stgraber> robru: ok. When the device is in an odd state, phablet-flash might misdetect it, in such case, pass it an extra -d grouper to force it
[21:46] <asac> i guess 5:...6.1...
[21:46] <stgraber> asac: current is 28 (rootfs is 20130906.1). It's published and everything, so just waiting for QA to run
[21:46] <robru> stgraber, well, it seems to me that phablet-flash borked halfway through the flash, leaving the tablet in an unbootable state. i tried this quite a few times earlier today without any luck. i'm not sure what changed now but somehow the google bootloader screen (with the unlocked lock) just showed up and i ran phablet-flash and now it's flashing.
[21:46] <asac> plars: is it running?
[21:46] <robru> I don't want to say it's "working" because so far all I see is the recovery screen, but that is an improvement.
[21:47] <cwayne_> stgraber, seems to work :D
[21:47] <stgraber> robru: ok. If that still fails somehow, get it into recovery mode, run "adb shell rm /cache/recovery/*" to cleanup some space, then change your micro-USB cable and try again with -d grouper
[21:49] <robru> stgraber, oh, the recovery screen has an error on it. "E: Can't open /cache/something-or-other....' (it disappeared before i could read it)
[21:50] <sergiusens> robru: can open autodeploy.zip or ubuntu_commands, the former is not important for this, the latter is
[21:50] <stgraber> robru: that's normal
[21:50] <stgraber> sergiusens: well, even missing ubuntu_command is fine at that stage (copying files over)
[21:51] <sergiusens> stgraber: robru you can check what goes on from a recovery point of view by looking at /tmp/recovery.log
[21:52] <sergiusens> after it's done that's what ends up on /cache/recovery/log
[21:55] <sergiusens> xnox: what about this? dpkg: dependency problems prevent configuration of libglib2.0-dev:
[21:55] <sergiusens>  libglib2.0-dev depends on python (>= 2.7.1-0ubuntu2); however:
[21:55] <sergiusens>   Package python is not configured yet.
[21:56] <sergiusens> I know I'm just randomly shooting this stuff, but these don't look nice if the idea is to do cross building
[22:00] <lool> asac: v28
[22:00] <lool> asac: it's up, not sure whether it's in QA
[22:01]  * lool tries cross-building gallery-app
[22:02] <sergiusens> lool: just do apt-get install libnotify-dev:armhf in your build env
[22:03] <sergiusens> lool: this is the fun stuff I get ootb http://paste.ubuntu.com/6072304/
[22:03] <stgraber> wow, the dashboard could do with some improved sorting :)
[22:03] <stgraber> 28: is showing up somewhere in the middle of the page
[22:03] <lool> lol
[22:04] <lool> stgraber: didn't even think of that
[22:04] <stgraber> so far all tests are passing though
[22:04] <lool> ship it!
[22:04] <lool> sadly, asac will soon remind us that the last tests are usually the harder ones to pass
[22:05] <lool> sergiusens: will check it out, right now it churns through the bdeps
[22:06] <plars> asac: yep :)
[22:06] <sergiusens> lool: do the tests or the devices get tired of running? :-)
[22:07] <lool> sergiusens: it was painful to build on my laptop, so I figured it would be awful on the device  :-)
[22:07] <lool> that said, the phone has twice the cores of the laptop
[22:07] <lool> sergiusens: I do get the python stuff too
[22:08] <lool> sergiusens: is libnotify the reason of libgstreamer -> libglib failing?
[22:09] <sergiusens> lool: it's a builddep for the share-app
[22:09] <lool> grmpf, the only reason for python are the autopilot tests
[22:09] <asac> anyone able to confirm that 3g works now?
[22:09] <asac> :)
[22:09] <lool> /var/lib/dpkg/info/python2.7-minimal.postinst: 38: /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
[22:10] <lool> /var/lib/dpkg/info/libglib2.0-0:armhf.postinst: 44: /var/lib/dpkg/info/libglib2.0-0:armhf.postinst: /usr/lib/arm-linux-gnueabihf/glib-2.0/glib-compile-schemas: not found
[22:10] <sergiusens> lool: yeah, I get the same
[22:10] <sergiusens> lool: but http://paste.ubuntu.com/6072327/
[22:10] <sergiusens> not sure why python is a dep for libglib2.0-dev
[22:11] <lool> sergiusens: /usr/bin/gdbus-codegen
[22:11] <lool> and /usr/bin/gtester-report too
[22:11] <sergiusens> lool: shouldn't that be split out into a -tools package?
[22:11] <lool> sergiusens: I guess
[22:11] <sergiusens> oh well
[22:11] <lool> it's usually painful at this scale
[22:12] <sergiusens> lool: long way to get this in the easy to xcompile state
[22:12] <lool> yes and no
[22:12] <lool> it's not that many issues given the size of the stack
[22:13] <cwayne_> sergiusens, ping
[22:16] <lool> sergiusens: your log seems to show the same two failing (python and glib)
[22:16] <lool> and we could fix both in glib
[22:17] <lool> I dont get why python2.7-minimal is allowed though
[22:17] <sergiusens> cwayne_: pong
[22:18] <lool> I was expecting foreign
[22:18] <asac> plars: do the results look good? cant see 'em on the dash yet
[22:19] <sergiusens> lool: xnox gave some explanations above wrt to python
[22:19] <slangasek> lool: well, nothing should actually depend on -minimal anyway, so it shouldn't matter :)
[22:19] <sergiusens> slangasek: what about this one? http://paste.ubuntu.com/6072327/
[22:19] <slangasek> lool: however, the obvious counterexample for M-A: foreign is python2.7 itself
[22:20] <slangasek> sergiusens: libglib2.0-dev doesn't (shouldn't) depend on python2.7-minimal
[22:20] <cwayne_> sergiusens, is there an easy way to wipe the user data and start fresh without doing a full phablet-flash?
[22:20] <lool> slangasek: libglib2.0-dev depends on python
[22:20] <sergiusens> slangasek: no, it depends on python
[22:20] <slangasek> it depends on python, which is M-A: allowed
[22:20] <slangasek> so it should probably depend on python:any ?
[22:20] <plars> asac: yes, so far
[22:20] <sergiusens> slangasek: well I get this http://paste.ubuntu.com/6072304/
[22:21] <slangasek> sergiusens: what's the native arch?
[22:21] <sergiusens> slangasek: amd64
[22:23] <asac> can you give 3g a shot?
[22:23] <slangasek> sergiusens: that output doesn't show why python2.7-minimal isn't configured, though
[22:23] <asac> plars: ?
[22:23] <sergiusens> slangasek: I can get the full output, one sec
[22:23] <plars> asac: 3g has never worked for me
[22:23] <plars> asac: last time I talked to awe about it, there were some known issues
[22:24] <plars> asac: I did try it again earlier today, and it seems to get a connection to the network, but the carrier redirects me to some sort of nonexistant page
[22:24] <sergiusens> slangasek: not full (my history got trimmed) http://paste.ubuntu.com/6072386/ but there's Setting up python2.7-minimal (2.7.5-5ubuntu1) ...
[22:24] <sergiusens> /var/lib/dpkg/info/python2.7-minimal.postinst: 38: /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
[22:25] <awe> plars, never?
[22:25] <slangasek> sergiusens: confusing.  what's /usr/bin/python2.7?
[22:26] <plars> awe: never
[22:26] <sergiusens> slangasek: ah... ARM,
[22:26] <awe> plars, last time we discussed 3g was in reference to a device in the QA lab
[22:26] <slangasek> sergiusens: oh, well how did that happen? :)
[22:26] <awe> that had a SIM that hadn't been activated yet
[22:26] <sergiusens> slangasek: I have no idea
[22:26] <slangasek> sergiusens: ok :-)
[22:26] <sergiusens> slangasek: all I did was apt-get install libnotify-dev:armhf
[22:26] <awe> plars, I wasn't aware of any other issues you were having?
[22:26] <plars> awe: that was a completely different problem, the sim I have locally has been activated
[22:27] <slangasek> sergiusens: so nothing in that log shows /usr/bin/python2.7 being clobbered, but clearly it has been
[22:27] <plars> awe: this was the previous issues we discussed, where you said there are bugs where it takes a long time to connect to 3g (and sometimes doesn't) and other problems where you had to hand-modify files to get it to connect correctly.  You had me make some changes but it still didn't work
[22:27] <awe> plars, again this is the first I've heard of your issues.  Have you filed a bug and/or worked with anyone else on figuring out what's wrong?
[22:27] <plars> awe: you told me there were bugs for this at the time
[22:27] <awe> plars, there's been a longstanding NM problem
[22:28] <awe> the fix landed earlier this week
[22:28] <awe> I believe it landed Tue or Wed
[22:28] <plars> I can try again in just a bit... furthest I've ever got was just a bit ago (previous image today) and it seemed to want to redirect me to some sort of tmobile androidapi site, but it gives an error
[22:28] <lool> slangasek: full sbuild log http://paste.ubuntu.com/6072397/
[22:28] <plars> I haven't had a chance to mess with it since then though
[22:29] <lool> on amd64
[22:29] <awe> plars, there also was a breakage with the RO images today
[22:29] <slangasek> lool: right, that log shows it selecting python2.7:armhf, which is not what we want
[22:29] <awe> but a fix was uploaded
[22:29] <plars> right, should be in this image from what I understand
[22:29] <slangasek> so if that's pulled in by glib, the fix is to make libglib2.0-dev Depend on python:any
[22:30] <asac> plars: so i think the problem was that everything was broken now
[22:30] <asac> plars: like no carrier etc.
[22:30] <asac> so if it works the same as before it would not be  a regression
[22:31] <lool> slangasek: ack; I guess we have to iterate to try it out
[22:31] <sergiusens> slangasek: could be http://paste.ubuntu.com/6072405/
[22:31] <slangasek> sergiusens: yep, that's what I would expect to see, and should be fixed by a python:any dep
[22:32] <slangasek> haw, and the libglib2.0-dev dep is autogenerated from dh_python
[22:32] <slangasek> dh_python2
[22:32] <lool> yeah, due to tools
[22:34] <lool> sergiusens: do you know how to test video thumbnails with gallery app?
[22:34] <sergiusens> lool: the user way is to record a video with the camera app
[22:34] <lool> I get Error loading image metadata: /home/lool/Vidéos/xyz.ogg: The file contains data of an unknown image type
[22:34] <sergiusens> lool: the other way would be to drop a video in /Pictures
[22:34] <lool> Pictures!
[22:34] <lool> sergiusens: I meant on my desktop
[22:35] <sergiusens> lool: oh, never used it on desktop
[22:36] <slangasek> sadness, 'apt-get build-dep -a armhf glib2.0' doesn't work
[22:44] <lool>         if (file.suffix().compare("mp4", Qt::CaseInsensitive) == 0) {
[22:44] <lool> sergiusens: actually has to be named .mp4
[22:48] <asac> plars: dont see any dashboard results still
[22:48] <asac> plars: any idea?
[22:48] <plars> really?
[22:48] <plars> hmm
[22:48] <plars> let me look
[22:48] <asac> thx
[22:49] <lool> asac: scroll to middle
[22:50] <lool> maguro has 135 passed
[22:50] <lool> mako 144
[22:50] <plars> yeah, sorting is broken on the dashboard
[22:50] <plars> because of the version numbering
[22:50] <plars> josepht is working on a fix I think
[22:51] <plars> ok, just got it installed locally
[22:53] <plars> awe: I get the same thing I was describing that I got earlier: it redirects me to http://androidapi.t-mobile.com/apppack/mvno.html
[22:53] <lool> can't take videos on mako itself
[22:54] <plars> but in the browser, it gives a network error
[22:55] <awe> plars, can you pastebin the contents of /var/lib/ofono/<IMSI>/gprs?
[22:55] <awe> also the output of /usr/share/ofono/scripts/list-contexts?
[22:56] <awe> note <IMSI> is a directory name that's looks like a hash ( eg. 345189011... )
[22:56] <plars> awe: http://paste.ubuntu.com/6072499/
[22:56] <RobbyF> is it just me or do you have to set the time and date manually still?
[22:56] <lool> RobbyF: should be set by ntpdate when you connect to network
[22:57] <awe> plars, OK... so ofono was able to lookup your service provider correctly
[22:57] <plars> awe: dns seems to resolve ok, so *something* works
[22:57] <awe> lool, is TZ set-able yet?
[22:57] <RobbyF> I'm on a wifi only with gnexus' never updates
[22:58] <awe> plars, when you say... "it redirects me to  ______", what do you mean by "it"?
[22:58] <lool> awe: not sure
[22:58] <awe> I'm confused if it's not the browser
[22:58] <slangasek> debuild's handling of -e argument ordering is infuriating
[22:58] <plars> awe: when I open the browser app, and put in ubuntu.com, google.com, and every other thing I've tried so far, it instead tries to send me to the url above
[22:59] <lool> slangasek: like last one doesn't override more recent one?
[22:59] <asac> plars: oha ... hard to spot :)
[22:59] <asac> lool: :)
[22:59] <awe> plars, can you ping ubuntu.com from the command-line?
[22:59] <asac> so can someone plz confirm that the fatal 3g from before is gone :)?
[22:59] <slangasek> lool: like all -e options are ignored after some arbitrary point in the argument list which I haven't figured out
[22:59] <lool> slangasek: I /think/ I've seen something similar earlier today trying to override my -j2 macro with a -j0 that wasn't pickedup
[22:59] <asac> davmor2: ?
[22:59] <asac> :)
[22:59] <plars> awe: no, ping doesn't seem to work, but it gets the right ip address from dns
[22:59] <slangasek> lool: so if I do 'debuild -eCONFIG_SITE -uc -us -B -aarmhf', it works.  If I do 'debuild -uc -us -B -aarmhf -eCONFIG_SITE', it does not.
[23:00] <lool> slangasek: oh it stops considering it has any args for itself when it meets the first dpkg-bp flag
[23:00] <sergiusens> asac: I'm installing right now
[23:00] <slangasek> lool: yes, infuriating
[23:00] <sergiusens> asac: will update you as soon as it boots
[23:01] <awe> plars, can you pastebin the context of 'list-contexts'?
[23:01] <awe> I think I may know what's happening...
[23:02] <plars> awe: http://paste.ubuntu.com/6072520/
[23:03] <awe> thanks
[23:03] <awe> one last request...
[23:03] <awe> nmcli d
[23:03] <awe> and nmcli c
[23:03] <awe> and I lied
[23:03] <lool> slangasek: just checked mine, completely unrelated
[23:03] <lool> just a dpkg-bp bug it seems
[23:03] <sergiusens> awe: if you use my script you can just ask for the run of that command ;-)
[23:03] <awe> cause really there's one final request
[23:04] <lool> nothing, DEB_BUILD_OPTS is empty; -j2 sets parallel=2; -j2 -j0 sets "parallel="
[23:04] <lool> how weird
[23:04] <plars> awe: http://paste.ubuntu.com/6072526/
[23:04] <awe> please create a bug
[23:04] <plars> awe: sure, this is something new?
[23:04] <awe> yes
[23:04] <awe> the connection looks active from both ofono & NM's perspective
[23:04] <plars> awe: on the image itself? or do you think I should put it on ofono or NM?
[23:05] <awe> this could be the routing bug that popey reported
[23:05] <sergiusens> asac: /var/lib/ofono is indeed working now
[23:05] <awe> plars, just file a touch-preview-images bug
[23:05] <awe> and assign to me
[23:06] <sergiusens> asac: skip intro also working
[23:07] <sergiusens> asac: and preinstalled apps sort of working, they are there and launch but icons aren't showing up
[23:08] <awe> plars, 'netstat -rn' would be one final bit of information that would help.   It looks like the connection is active, but it also looks like you're not getting bounced to a
[23:09] <awe> plars, does the webpage you referenced above show up on the phone, or does it show a server error?
[23:09] <awe> if I try to load on my desktop, I get the latter
[23:09] <plars> awe: if it's a routing problem, I wouldn't expect it to get a response from dns
[23:09] <plars> awe: no, it returns a server error
[23:10] <awe> well, you're clearly getting redirected
[23:10] <awe> did you purchase the SIM directly from t-mobile, curious that it's redirecting you to a page about MVNO ( mobile virtual network operator )
[23:10] <awe> also have you tried the SIM in another phone and confirmed it works?
[23:11] <asac> sergiusens: thats mako?
[23:11] <sergiusens> asac: maguro
[23:11] <asac> sergiusens: can you get a connection at all?
[23:11] <asac> ok good
[23:12] <asac> so how about mako? anyone?
[23:12] <asac> plars: a few tests failed
[23:12] <asac> need retry
[23:12] <sergiusens> asac: I have to break ro to get to that point as my data isn't in the serviceproviders.xml yet so I would need to replace it... I'll replace, reboot and run my script
[23:13] <asac> hmm. ok
[23:13] <asac> maybe get your data in there :)
[23:13] <asac> lol
[23:13] <sergiusens> cjwatson: seems the icon path isn't being correctly set again
[23:13] <sergiusens> asac: I have!
[23:13] <sergiusens> asac: well I had my patch applied upstream
[23:13] <asac> ok so not back down yet
[23:13] <sergiusens> asac: waiting for it to funnel in, cyphermox's plate
[23:13] <plars> asac: I'll restart them, give me a moment to finish writing this bug up
[23:15] <robru> stgraber, ugh, lost it again. power button is unresponsive, screen black
[23:15] <sergiusens> asac: in case you want to give it a go http://bazaar.launchpad.net/~sergiusens/+junk/network/view/head:/network_gprs_provision_test.sh
[23:15] <robru> stgraber, http://paste.ubuntu.com/6072562/ buh
[23:16] <sergiusens> asac: the pastebinit are the replacements needed to make it run on utah (monday sprint task I hope)
[23:17] <sergiusens> lool: what's the fastest way to go from .crash to backtrace?
[23:17] <sergiusens> asac: data works
[23:17] <slangasek> sergiusens: apport-unpack && gdb?
[23:17] <sergiusens> slangasek: thanks
[23:17] <plars> awe: https://bugs.launchpad.net/touch-preview-images/+bug/1221969
[23:19] <awe> plars, when you say it's a "straightalk" SIM on the t-mobile, sounds pretty  much like a MVNO to me
[23:19] <awe> ;)
[23:21] <lool> sergiusens: apport-retrace -g I think
[23:21] <lool> sergiusens: that's what I used earlier today
[23:21] <lool> sergiusens: it unpacks and launched gdb binary /tmp/core
[23:21] <lool> sergiusens: I didn't find how to install the dbgsym automatically yet; I think I found this in the past
[23:21] <awe> plars, can you also grep for the for "GPRS" in /var/log/syslog and add to the bug?
[23:22] <awe> plars, do have a phone running stock Android?
[23:22] <awe> I'm curious as to whether this SIM works on Android
[23:24] <asac> sergiusens: so what you did was change the file, go back to RO and then reboot?
[23:25] <awe> plars, also can you please verify that the account has "data" minutes allocated?
[23:25] <sergiusens> asac: yes
[23:25] <asac> so now we need mako too i guess
[23:25] <sergiusens> asac: me no have mako
[23:25] <asac> sergiusens: you think thats a valid test :)?
[23:25] <sergiusens> asac: yes it is
[23:25] <plars> awe: it's supposed to be unlimited talk/message/data
[23:25] <asac> rsalveti: want to try a mako before running out? :)
[23:26] <asac> popey: guess also already in weekend fun? :)
[23:26] <awe> understood, but could you please verify from their website?  You're getting redirected to a webpage, which to me indicates that it's possibly an account setup problem.   plars, as mentioned the other thing I'd like to know is whether it works in a stock Android phone
[23:27] <awe> AFAIK, this is the first time I've heard of someone using a MVNO SIM
[23:27] <awe> so it also could be related to that
[23:28] <plars> awe: I could flash it to android and try from there, but I don't know anything about the account. For that I'd probably have to wait and talk to Larry on Monday
[23:28] <awe> plars, everything else looks correct ( ofono's APN, NM's state, routing table, ... )
[23:28] <awe> plars, so yes... let's check with Larry on Monday.
[23:28] <lool> gn everyone
[23:29] <lool> I'm sure this build will eventually pass all tests
[23:29] <awe> when I asked awhile ago about getting instructions from Larry on how to get a card that was in a weird state, I never heard back.  Perhaps you, I, and Larry could do a hangout on Monday?
[23:29] <awe> plars, ^^
[23:30] <plars> awe: I responded to you right away to that on irc, and on the bug, I assumed you had the card?
[23:30] <plars> awe: rick has one for you
[23:30] <plars> awe: I told him to make sure not to activate it
[23:31] <awe> ah, plars maybe I didn't see the bug update
[23:32] <awe> plars, is it fair to say though that all cards involved have been "straightalk" cards?
[23:32] <plars> awe: yeah, np. Rick had one that hadn't been used (or activated) yet, should be able to get it from him
[23:32] <awe> Rick ?
[23:32] <plars> awe: most likely, yes
[23:32] <plars> awe: rfowler
[23:33] <awe> ok, we can discuss Mon
[23:33] <awe> or I can order
[23:33] <awe> by the way...
[23:34] <awe> from straightalk's site
[23:34] <plars> asac: test_capture.TestCapture.test_shoot_button_disable seemed to fail on both mako and maguro
[23:36] <asac> plars: thats camera?
[23:36] <plars> asac: yes
[23:36] <asac> that wasnt failing in previous build?
[23:36] <awe> plars, from the straigttalk website ( I clicked on Shop|SIM Cards ): "In order for your phone's INTERNET... to work, you will need to update your phone's APN ( ... ) settings by following a few simple steps.  These settings can be found on our website at apn.straighttalksim.com."
[23:36] <awe> plars, did you manually edit the APN settings per these instructions?
[23:37] <plars> awe: hmm, no first I've heard of that... I'll take a look
[23:37]  * awe notes that our System Settings UI is missing the ability to edit the APN
[23:37] <asac> plars: we retried those in the past, no?
[23:38] <plars> asac: this didn't fail previously
[23:38] <plars> awe: is there a way to do it from the command line?
[23:39] <awe> you need to stop NM and ofono
[23:39] <awe> and then edit the ofono gprs settings file
[23:39] <awe> ( /var/lib/ofono/<IMSI>/gprs )
[23:39] <awe> depending on what the parameter changes are
[23:39] <awe> ( I'm looking now )
[23:41] <awe> seems I can't get the required changes without a SIM.  Can you please paste the info for your SIM from apn.straighttalk.com into the bug?
[23:42] <sergiusens> asac: camera fix didn't make it in it seems
[23:43] <sergiusens> lool: ^^
[23:44] <sergiusens> lool: /var/lib/usermetrics is there, but might not be enough
[23:44] <asac> sergiusens: thats not a regression to previous RO then?
[23:44] <asac> plars: i think camera is crashy
[23:44] <sergiusens> asac: nope, just a fix that didn't get fixed
[23:44] <sergiusens> so a non fix
[23:44] <sergiusens> asac: I need to go, will bbl
[23:44] <asac> stgraber: so which build was build 5?
[23:44] <asac> err
[23:44] <asac> build 4
[23:45] <asac> plars: i really think its crashy
[23:45] <asac> and i have seen camera crashes before
[23:45] <asac> retry plz and record
[23:45] <johnjohn101> what part of october will i be able to have an ubuntu phone?
[23:45] <plars> asac: yeah, there was a .crash file for it
[23:48] <plars> awe: updated
[23:48] <awe> thanks!
[23:49] <awe> so this really isn't a bug
[23:49] <slangasek> sergiusens: can confirm that fixing the libglib2.0-dev dep on python is sufficient to make libnotify-dev cross-installable.  Now to get dh_python2 fixed upstream...
[23:49] <awe> that said, you need to confirm that the given settings work
[23:51] <asac> plars: so retried?
[23:51] <asac> plars: i think there were often crashes
[23:51] <asac> who knows whats going on wiht this
[23:51] <asac> i dont see anything changing
[23:51] <plars> asac: yeah, it's in the queue
[23:52] <asac> plars: can you at least boot test and check that everything else works?
[23:52] <asac> on mako?
[23:52] <asac> we need someone saying that it works at all i guess in case the tests are good
[23:52] <plars> asac: I've boot tested it, been working through the 3g stuff with awe
[23:52] <asac> ah cool
[23:52] <asac> well. get a proven SIM - if any :)
[23:52] <asac> hehe
[23:53] <asac> ubuntu certified
[23:53] <awe> asac, mvno
[23:53] <awe> ;)
[23:53] <asac> reads cryptic to me
[23:54] <awe> mobile virtual network operator
[23:54] <awe> means the auto-provisioning of the parameters necessary to activate a data call will always fail
[23:54] <awe> and thus the user needs to hand configure their phone settings
[23:54] <plars> asac: the click packages that are installed don't seem to work, nor do they have an icon
[23:54] <awe> which we unfortunately have no settings UI for...
[23:55] <plars> asac: wait, they might work, just don't have icon
[23:56] <asac> plars: i only want to hear about regressions over "daily" :)
[23:56] <asac> daily has click completely not working well afaik :)
[23:57] <athairus> hello everyone, I'm new and have just installed the latest build on my verizon galaxy nexus (toro)
[23:57] <athairus> I'd like to help by reporting bugs as I see them
[23:57] <athairus> the first one I've noticed was in the browser, the swipe gestures have a very noticable lag to them
[23:57] <athairus> what's the proper way to report this?
[23:58] <plars> asac: video playback still slow, but not a regression