[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