[00:01] <stgraber> sergiusens: looks good
[00:02] <sergiusens> stgraber: I tested with manta and grouper, would need to test your patch now, or do an unlink in recovery.c
[00:02] <rsalveti> sergiusens: I can test it with mako
[00:06] <RobbyF> whats with "The line where / two surfaces meet" about
[00:11] <stgraber> sergiusens: I prefer my patch because if something goes wrong during the update, we'll have the files to figure it out
[00:11] <mdeslaur> rsalveti: yeah, I know what binder is, I was wondering if we were using a binary module, or if we can always patch it
[00:12] <sergiusens> stgraber: oh, I'm going to apply it after testing
[00:12] <mdeslaur> rsalveti: what apps will we have that will directly talk to binder?
[00:12] <sergiusens> stgraber: I was thinking of an extra measure in case it never gets moved, which we can do later
[00:12] <stgraber> sergiusens: well, it gets moved pretty much as the first thing, so should be safe
[00:13] <mdeslaur> rsalveti: oh, I see your comment in the bug
[00:13] <mdeslaur> hrm
[00:14] <sergiusens> stgraber: good, building now
[00:14]  * sergiusens notices it's nice when the laptop heats up building android during winter
[00:14] <rsalveti> +1
[00:15] <rsalveti> mdeslaur: yeah, it's heavily used by us atm
[00:15] <ricmm> whats the issue with binder?
[00:17] <mdeslaur> rsalveti: unsigned min_priority:8;
[00:18] <rsalveti> ricmm: bug 1202887
[00:18] <mdeslaur> so it's automatically trying to bump priority...hrm
[00:19] <rsalveti> mdeslaur: right
[00:19] <mdeslaur> rsalveti: sorry, I'm sure you poked at all this already, I'm just catching up and talking to myself :P
[00:20] <rsalveti> mdeslaur: haha, I'm learning as well :-)
[00:22] <rsalveti> sergiusens: + This acction wipes the system'''
[00:24] <rsalveti> sergiusens: stgraber: hm, so we still need fastboot, right?
[00:24] <rsalveti> you're using that to flash recovery and boot the system
[00:24] <rsalveti> *boot recovery
[00:25] <rsalveti> would be nice to try to remove the fastboot dependency later, if possible
[00:25] <DJJeff> WIFI only tablets need OFONO removed
[00:26] <rsalveti> so this could be use by some other devices
[00:26] <mdeslaur> rsalveti: this is pretty odd: if (min_nice < 20)
[00:27] <mdeslaur> rsalveti: I wonder if the intention was for if (min_nice <= 20), but it never got noticed because the rlimits are set high
[00:27] <rsalveti> mdeslaur: that basically means that set_user_nice failed
[00:27] <rsalveti> ops, didn't fail actually
[00:27] <mdeslaur> rsalveti: it checks with the can_nice at the top, if that works it does the set_user_nice
[00:27] <rsalveti> mdeslaur: set_user_nice fails in case you give 20
[00:27] <rsalveti> it tries a minimum value
[00:28] <mdeslaur> rsalveti: that's the code path that android always takes
[00:28] <rsalveti> in case the max, as requested, is not allowed
[00:28] <mdeslaur> so if it _can_t set the nice value, it then tries to determine what the min_nice could be
[00:28] <mdeslaur> and then sets it
[00:28] <rsalveti> exactly
[00:28] <mdeslaur> but if it's 20 or over, it prints an error
[00:28] <rsalveti> but in our case the min_nice is 0, so that's why it's complaining
[00:28] <mdeslaur> but 20 is 0
[00:29] <rsalveti> argh, default nice is 0
[00:29] <rsalveti> my brain is fried already
[00:29] <mdeslaur> so I'm guessing the intention was to print the error if it couldn't set the default nice
[00:29] <mdeslaur> (which is 0)
[00:29] <rsalveti> right
[00:29] <mdeslaur> but it got < instead of <=
[00:29] <mdeslaur> and nobody ever noticed because on android it always works
[00:30] <rsalveti> well, the < is still fine
[00:30] <rsalveti> as the code wants to warn the user that rlimit wasn't set at all
[00:30] <rsalveti> and the min nice it got is the default, which is 0
[00:31] <mdeslaur> 20 = 0, 19 = 1
[00:31] <rsalveti> *as the
[00:31] <mdeslaur> so if we _lower_ the max nice value, it will stop warning
[00:31] <rsalveti> exactly
[00:31] <mdeslaur> that doesn't really make sense
[00:32] <rsalveti> that's just saying that it was able to set to a value different than the default, which means the user did set rlimit nice
[00:32] <rsalveti> that's why it first tries a value, if it can't, try at least something != than the default
[00:33] <rsalveti> so binder can have a higher priority than a "default" process
[00:33] <mdeslaur> so if it's <20, which is _less_ priority, it doesn't warn?
[00:34] <mdeslaur> I don,t understand that code at all
[00:37] <rsalveti> that would make sense if rlim_cur could be from 1..40
[00:37] <rsalveti> as it'd just invert that logic
[00:37] <rsalveti> what I don't understand is why rlim_cur is 0
[00:38] <mdeslaur> userspace is -20 to 19
[00:38] <rsalveti> I'd expect it to be 20, which is 0 for nice
[00:38] <mdeslaur> -20 being the highest priority
[00:38] <rsalveti> right, that's the nice values
[00:38] <mdeslaur> kernelspace inverts that by doing 20 - userspace
[00:38] <rsalveti> rlimit nice goes from 1-40
[00:38] <mdeslaur> so -20 userspace gets turned into 40
[00:38] <mdeslaur> and 19 userspace gets turned into 1
[00:39] <rsalveti> right
[00:39] <mdeslaur> rlim_cur is userspace 0
[00:39] <rsalveti> that's why I don't get why that's 0
[00:39] <mdeslaur> so min_nice ends up being 20
[00:40] <rsalveti> which is invalid
[00:40] <rsalveti> guess it's 0 if not set at all
[00:40] <rsalveti> which then it'd make sense
[00:41] <mdeslaur> what's invalid?
[00:41] <mdeslaur> 0 is the default for userspace apps
[00:41] <rsalveti> rlim_cur can go from 1-40, right?
[00:41] <mdeslaur> no, rlim_cur is the userspace value, it goes from -20 to 19
[00:42] <rsalveti> are you sure?
[00:42] <rsalveti> let check the set_user_nice code
[00:42] <mdeslaur> yes, that's why it's doing min_nice = 20 -
[00:42] <mdeslaur> 20 - is the conversion
[00:42] <mdeslaur> set_user_nice has if (TASK_NICE(p) == nice || nice < -20 || nice > 19)
[00:42] <rsalveti> right
[00:42] <mdeslaur> oh, wait a sec
[00:42] <mdeslaur> yeah
[00:42] <rsalveti> so it only handles -20-19
[00:43] <rsalveti> that's why rlim_cur needs to be the kernel one
[00:43] <rsalveti> that's really confusing
[00:43] <mdeslaur> but 20 - doesn't convert from kernel to userspace
[00:43] <rsalveti> right
[00:44] <mdeslaur> line 523 is completely wrong
[00:44] <mdeslaur> FAIL
[00:44] <rsalveti> that's why I think that this code would only make if rlim_cur == 0 means RLIMIT_NICE is not set at all
[00:45] <mdeslaur> I'm pretty sure rlim_cur is a userspace value though
[00:45] <rsalveti> because a real rlim_cur would only go from 1..40 :-)
[00:45] <rsalveti> set via setrlimit, right?
[00:46] <mdeslaur> rsalveti: gotta go, but that code is definitely wonky
[00:46] <rsalveti> "The actual ceiling  for the  nice  value is calculated as 20 - rlim_cur.  (This strangeness occurs because negative  numbers  cannot  be  specified  as resourcelimit  values, since they typically have special meanings.  For example, RLIM_INFINITY typically is the same as -1.)"
[00:47] <rsalveti> mdeslaur: right, will investigate a bit more just to be sure
[00:47] <mdeslaur> rsalveti: so rlim_cur is the userspace value
[00:47] <mdeslaur> which is then converted on line 523 to kernel value and put in min_nice
[00:48] <rsalveti> that can't be
[00:48] <mdeslaur> but then, by mistake, it's used with set_user_nice, which is expecting a userspace value
[00:48] <rsalveti> right, I'll check what rlim_cur really is
[00:49] <sergiusens> stgraber: patch works fine
[00:49] <mdeslaur> rsalveti: oh, hrm, 20- works to convert both ways, that had not occured to me
[00:49] <rsalveti> sergiusens: can you fix line 20, there's a typo in there
[00:50] <rsalveti> right
[00:50] <mdeslaur> rsalveti: so if min_nice is userspace, and userspace is -20 to 19
[00:50] <mdeslaur> rsalveti: how the heck can it not be < 20? :)
[00:51] <rsalveti> only if rlim_cur is 0
[00:51] <rsalveti> which is weird
[00:52] <rsalveti> sergiusens: +from phabletutils import ubuntuimage
[00:52] <rsalveti> where can I find that?
[00:55] <rsalveti> mdeslaur: #define RLIMIT_NICE     13  /* max nice prio allowed to raise to
[00:55] <rsalveti>                        0-39 for nice level 19 .. -20 */
[00:55] <rsalveti> but still, 0 would be 19 there, which is wrong
[01:02] <stgraber> rsalveti: yeah, we still use fastboot to get the new recovery in place, that could be replaced by some other way of doing it on other devices though
[01:02] <stgraber> rsalveti: after that, the upgrader takes care of any updates from that point, so fastboot isn't needed afterwards
[01:03] <rsalveti> stgraber: right
[01:21]  * dejello meeps
[01:32] <sergiusens> rsalveti: oh, need to add ...
[01:32] <treykindlinger> i'm trying to flash ubuntu on my nexus 7. followed the instructions on the ubuntu wiki, now it's bricked
[01:32] <treykindlinger> can anyone help?
[01:33] <stgraber> rsalveti: after that, the upgrader takes care of any updates from that point, so fastboot isn't needed afterwards
[01:33] <stgraber> oops, sorry about that :)
[01:34] <sergiusens> rsalveti: fixed
[01:34] <sergiusens> fastboot is just needed to flash recovery
[01:34] <sergiusens> it would be a manual step on other devices
[01:35] <rsalveti> sergiusens: right
[01:37] <treykindlinger> can anyone help? i'm stuck
[01:45] <treykindlinger> need some help. bricked a nexus 7 trying to download ubuntu touch
[01:46] <nhaines> treykindlinger: paste the error messages at http://pastebin.ubuntu.com/ and share the link here.
[01:47] <treykindlinger> Device detected as /sbin/sh: getprop: not found Unsupported device, autodetect fails device When working on flipped images, detection does not work and would require -d
[01:48] <treykindlinger> http://pastebin.ubuntu.com/5889388/
[01:48] <rsalveti> can you run phablet-flash -d grouper?
[01:50] <sergiusens> stgraber: pushed your patch and going to launch a new android build in a bit
[01:51] <sergiusens> hopefully it will make current
[01:51] <rsalveti> sergiusens: were you able to create a job for phablet-saucy as well?
[01:51] <treykindlinger> i'll try that rsalveti
[01:51] <sergiusens> rsalveti: not yet
[01:52] <rsalveti> sergiusens: that's fine, just checking :-)
[01:52] <sergiusens> rsalveti: been doing J troubleshooting...
[01:54] <rsalveti> sergiusens: http://paste.ubuntu.com/5889401/
[01:54] <rsalveti> sergiusens: the messages are quite confusing
[01:55] <rsalveti> do we actually need stuff from both cdimage and system-image?
[01:55] <rsalveti> maybe for recovery
[01:55] <treykindlinger> running phablet-flash -d grouper...hopefully that works
[01:56] <rsalveti> hm, system-image is quite slow for me here
[02:01] <sergiusens> rsalveti: yes we do
[02:01] <sergiusens> rsalveti: it is slow
[02:02] <rsalveti> /home/rsalveti/Downloads/phablet-flash/imageupdates/20130714/mako-20130718.full.tar.xz
[02:02] <rsalveti> why such differences in the date?
[02:02] <sergiusens> rsalveti: it's not the date, it's the version
[02:02] <sergiusens> which coincidentally is a data
[02:02]  * sergiusens reboots
[02:02] <rsalveti> waaaaat
[02:02] <sergiusens> *date
[02:03] <rsalveti> right, but shouldn't be the same?
[02:03] <sergiusens> rsalveti: I'm not doing the scheming there
[02:03] <rsalveti> stgraber: ^^?
[02:03] <sergiusens> rsalveti: that's a q for barry or stgraber
[02:03] <stgraber> rsalveti: the first isn't a date
[02:04] <stgraber> rsalveti: 20130714 is the 15th image published in July
[02:04] <rsalveti> oh, that's so confusing
[02:04] <stgraber> you get used to it ;)
[02:04] <rsalveti> can't we use some other id later on?
[02:04] <stgraber> an image is made of various files which each may have been produced at a different time, so that's why we needed yet another thing :)
[02:04] <rsalveti> I know for sure that people will get confused with this
[02:05] <rsalveti> right, that's fine
[02:05] <rsalveti> it's just the impression that this is a date that is confusing
[02:05] <rsalveti> so we could have 20130745 for example
[02:06] <stgraber> yep, typically on the "stable" channel we're planning to have YYYYDD00 be a scheduled build at the beginning of the month
[02:06] <stgraber> then 01 be the first bugfix or security update
[02:06] <stgraber> etc..., so 00 would be automatic and the others manually triggered when we think it's needed
[02:07] <stgraber> technically the users won't ever see those file as it's all handled behind their back by the upgrader
[02:07] <rsalveti> right
[02:07]  * rsalveti looks at the mount output
[02:07] <rsalveti> huge haha
[02:07] <stgraber> the thing we'd need to export is something like <model>-<channel>-<our build number> which we can then use to figure out exactly which version of every bit they have on their system
[02:08] <rsalveti> but it worked, which is cool
[02:08] <rsalveti> right
[02:08] <stgraber> rsalveti: haha, yeah, and I guess it'll become way longer pretty soon (as we need to add more and more persistent storage paths)
[02:09] <stgraber> rsalveti: do you have a maguro? based on what sergiusens said earlier, I think we have this tested on mako, manta and grouper but it'd be nice to have a test on maguro too before I blog about it
[02:09] <rsalveti> hm, why am I getting 'get_prop_batt_capacity: low battery charge = 7%' now in dmesg...
[02:10] <rsalveti> stgraber: right, sure
[02:10] <rsalveti> stgraber: let me flash that
[02:21] <rsalveti> stgraber: how long does it take to flash grouper?
[02:21] <rsalveti> maguro is taking quite a while
[02:21] <rsalveti> but must be because of the cpu, not just disk
[02:21] <sergiusens> rsalveti: manta was fast, grouper I don't recall
[02:23] <rsalveti> manta doesn't count
[02:23] <rsalveti> faster than my notebook
[02:23] <rsalveti> hahah
[02:31] <rsalveti> stgraber: [    8.076385] omap-rproc omap-rproc.1: rproc_loader_cont: failed to load ducati-m3.bin
[02:31] <rsalveti> stgraber: that was happening when we had the firmware udev rule as part of the initramfs
[02:31] <rsalveti> which we fixed last week I guess
[02:31] <sergiusens> rsalveti: lol
[02:32] <rsalveti> without it we can't open the camera with maguro
[02:36] <rsalveti> hm, the firmware udev rule is not part of the initrd
[02:36] <stgraber> rsalveti: right, the initrd is the same as you get on flipped, just a different code path on the mount side
[02:36] <rsalveti> right, so it shouldn't be failing because of that
[02:37] <rsalveti> it's basically failing to load the ducati firmware
[02:37] <sergiusens> rsalveti: going to bed now, if you can happrove the MR later, that would be great (even if the images don't work) as the whole idea is a call for testing ;-)
[02:38] <rsalveti> it's indeed loaded by android, but have no idea why it's failing
[02:38] <rsalveti> sergiusens: right, will happrove now
[02:38] <sergiusens> rsalveti: great, thanks
[02:39] <stgraber> rsalveti: did you grouper finally finish the unpacking? grouper is pretty quick here, the initial unpack taking maybe 5 minutes and then following updates taking just seconds
[02:39] <stgraber> bug maguro is much slower than even grouper
[02:39] <rsalveti> yeah
[02:39] <rsalveti> sergiusens: just happroved it
[02:39] <stgraber> though it must be I/O related as unfortunately we don't have pxz on those devices so the unpacking uses a single thread anyway
[02:40] <rsalveti> stgraber: yeah, wasn't using the entire cpu it seems
[02:40] <annerajb> rsalveti: how do i open a bug in launchpad against ubuntu_deploy.sh script? Like how do I know it's opened to the correct project?
[02:41] <sergiusens> annerajb: what is ubuntu_deploy.sh?
[02:41] <rsalveti> yeah, wonder which script that is
[02:41] <annerajb> the script inside raring-preinstalled-phablet-armhf.zip
[02:41] <rsalveti> annerajb: you can always open bugs against https://launchpad.net/touch-preview-images
[02:41] <rsalveti> oh, right
[02:41] <rsalveti> sergiusens: you created that script :P
[02:41] <sergiusens> ah, forgot about that :-)
[02:41] <annerajb> lol
[02:42] <sergiusens> please log above and feel free to assign to me
[02:43] <rsalveti> stgraber: should be good for your blog post
[02:43] <rsalveti> maybe it'd just be good to wait phablet-flash to land in the archive & ppa
[02:44] <vthompson> balloons, I changed the way I am testing playing of a track in music-app and got it working. I put you as the reviewer for the merge request. #test-all-the-things!
[02:45] <sergiusens> rsalveti: stgraber yo actually want to wait for the next build to get the latest recovery since it avoids the infinite reboot loop
[02:47] <stgraber> rsalveti: yeah, planning to post it tomorrow afternoon, I guess we should have new builds of the images and of phablet-flash by then
[02:47] <rsalveti> yeah
[02:49] <annerajb> rsalveti: which infinite reboot loop?
[04:02] <AskUbuntu> Ubuntu touch - can I install on an Android phone? | http://askubuntu.com/q/321739
[04:02] <AskUbuntu> Ubuntu Touch Phone Apps on Desktop | http://askubuntu.com/q/321740
[04:44] <fishcooker> welcome to the board, ubuntu-phone
[04:44] <fishcooker> LoL
[05:01] <Mingting> Is there a mailist to discuss porting ubuntu touch to a new device?
[08:11] <danwelsh> hello
[08:12] <danwelsh> can touch work on galaxy ace?
[08:33] <veebers> Hi all, I flashed my galaxy nexus to the latest (saucy-43) but I appear to be having dbus issues. Running `qdbus` shows: Could not connect to D-Bus server: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /tmp/dbus-BJdADkQarU: Connection refused
[08:34] <veebers> this is just after logging on, without restarting unity8/session and dbus session daemon is running
[08:46] <ogra_> veebers, on the nexus devices unflipped images are dead since several weeks, dont use them we havent touched them in ages (they are just around for some ports that havent been moved to flipped)
[08:47] <veebers> ogra_: oh, I thought that phablet-flash had been updated to flash flipped by default
[08:47] <veebers> ogra_: what do I need to do to fix this? I.e. install flipped
[08:47] <ogra_> yeaah, a while ago
[08:48] <ogra_> being up to date with phablet-flash should be enough
[08:48] <ogra_> by default it should pull the latest blessed image from http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/ (whatever /current links to)
[08:48] <veebers> ogra_: so I'm not sure I understand. I've used a recent (if not the most recent, just about to dist-upgrade in case) phablet-flash to install the image
[08:49] <ogra_> if you want to help testing you can call phablet-flash --pending which will then pull the image behind the /pending link)
[08:50] <popey> ogra_: is there a new image today?
[08:50] <veebers> ogra_: I'm flashing purely for testing, being on the psqa team and all :-)
[08:50] <jodh> ogra_: I'm having trouble getting the sources to build after a 'repo sync': gpg is FTBFS - known issue?
[08:50] <ogra_> popey, there will surely be :) havent checked where in the builder queue it sits ...
[08:50] <veebers> ogra_: thanks I'll flash pending and see how ti goes
[08:51] <ogra_> veebers, phablet-tools 0.15+13.10.20130712-0ubuntu1 should be recent
[08:51] <JamesTait> Good morning all, happy Friday, and happy Soyuz 14 Landing Day! :-D
[08:51] <veebers> ogra_: ack, thanks
[08:52] <ogra_> jodh, hmm, that was merged in by the system-image guys (ondra and stgraber ....  i thought we used a binary gpg as an interim solution, i'm surprised it gets attempted to be built
[08:53] <ogra_> asac, all yellow on the dashboard \o/
[08:54] <ogra_> now we can step by step move to green :)
[08:54] <asac> ogra_: yeah thats good :)
[08:54] <asac> push push
[08:54] <asac> ;)
[08:56] <rickspencer3> sounds like ogra_ is having a baby
[08:56] <ogra_> haha
[08:56] <rickspencer3> probably feels that way some days ;)
[08:56] <ogra_> yeah
[08:57] <ogra_> it was surely a painful process to squeeze that one out :)
[08:57] <jodh> ogra_: here's the error: http://paste.ubuntu.com/5890130/. Any suggestions apart from re-running phablet-dev-bootstrap in a fresh directory? Can I disable the external bits of the build without breaking other things? Just trying to set up an env to build a basic C program :|
[08:59] <ogra_> jodh, hmm, that looks like a failure with your code, not with gpg, i only see warnings from it, no errors
[08:59] <jodh> ogra_: gah - on 2nd look, I think you're right! ;)
[09:01] <ogra_> someone should fix make to still log things in order when building in multipe threads :)
[09:01]  * ogra_ thinks that since years
[09:04] <davmor2> popey, ogra_: was able to reproduce that apps page issue on both maguro and grouper screenshots attached to https://bugs.launchpad.net/touch-preview-images/+bug/1202794
[09:05] <ogra_> sounds like Saviq might be intrested in it ^^^
[09:06] <Saviq> ogra_, davmor2 thanks
[09:06] <asac> ogra_: where is todays build?
[09:06] <davmor2> Saviq: that was on 20130718 image
[09:06] <asac> is it coming?
[09:06] <ogra_> asac, in the press
[09:06] <asac> ogra_: and yes, i always wantj more until it happens everyday
[09:06] <ogra_> just checked the log, its half way through
[09:07] <ogra_> give it another 30-45 min
[09:07]  * popey gets coffee
[09:07]  * ogra_ is excitedly waiting for http://people.canonical.com/~ubuntu-archive/click_packages/ to land in it .... we have the code that installls them since a while, but the packages are in place only since yesterday
[09:08] <ogra_> cjwatson, do we have any plan how to reflect click in the seeds for building btw ?
[09:08] <davmor2> Saviq: it's really hard to explain how to reproduce it, it's basically opening using and closing a bunch of app, there seems to be no rhyme or reason to it, it will just stop at some point.  I can scroll left and right and all the other lens scroll as expected, only way to get it back is to reboot
[09:09] <cjwatson> ogra_: no
[09:09] <cjwatson> ogra_: least of my worries right now :)
[09:09] <ogra_> (or in a separate seed like thing)
[09:09] <cjwatson> ogra_: (you know that those packages won't actually link desktop files in yet, right?)
[09:09] <ogra_> yeah, i get the click_list will do for now
[09:10] <ogra_> cjwatson, well, i know that we seed most of them from the archive still
[09:10] <cjwatson> ... what's the point in installing them as click packages as well then?
[09:10] <ogra_> so they are just duplicates atm anyway
[09:10] <ogra_> well, i think sergiusen plan was to unseed once he sees them land
[09:12] <cjwatson> I've belatedly cronned click_copy.py in ~ubuntu-archive for 11 0,6,12,18 * * *
[09:12] <ogra_> great ...
[09:12] <ogra_> whats the eta for havinf .desktop files then
[09:12] <ogra_> *having
[09:13] <ogra_> i dont think they will actually run properly without --desktop_file_hint= being handed to the shell
[09:14] <ogra_> (if thats far out i'd say we back them out again until that bit is there (as soon as we know they install fine at build time))
[09:16] <cjwatson> ogra_: so, I'm currently working as hard as I can on the hook infrastructure so that it's possible at all
[09:16] <ogra_> ok
[09:16] <cjwatson> ogra_: I expect to get that done either today (time limits ...) or early next week, and for desktop file support to land shortly after that
[09:17] <ogra_> well, lets see how much space they occupy ... i dont think it does harm to have them n parallel if they dont bloat the image to much (512M is our limit)
[09:20] <ogra_> WHEE !
[09:20] <ogra_> Setting up click packages
[09:20] <ogra_> Setting up com.ubuntu.calendar_0.4_all.click
[09:20] <ogra_> 2013-07-19 09:11:54 URL:http://archive-team.internal/click_packages/com.ubuntu.calendar_0.4_all.click [74034/
[09:20] <ogra_> dpkg: warning: failed to open configuration file '/root/.dpkg.cfg' for reading: Permission denied
[09:20] <ogra_> Selecting previously unselected package com.ubuntu.calendar.
[09:20] <ogra_> \o/
[09:20] <ogra_> such a good friday :D
[09:24] <davmor2> ogra_: no good friday was months back dude just before easter infact ;)
[09:24] <ogra_> haha
[09:24] <cjwatson> Guess I should fix that warning
[09:24] <ogra_> cjwatson, well, it moves on doing what it should .... not an urgent matter i'd say
[09:25] <cjwatson> no, not at all
[09:34]  * davmor2 is trying to figure out what the tvoss_ scale is for his tvoss|benchmark_  is 1 tvoss good or bad, fast or slow, is 2 tvosses better than one ......
[09:34] <popey> Zero to espresso.
[09:36] <davmor2> popey: is that zero, instant, filtered, latte, cappuccino and espresso?
[09:38] <ogra_> didrocks, hmm, just seeing saucy-changes .... seems that all these daily built -app package enter the archive *right after* the image build every day, could we probably move that job 1-2h earlier ?
[09:39] <didrocks> ogra_: they normally enters before
[09:39] <ogra_> (mind you not urgent or anything, but i think it would make sense to have them in the daily image)
[09:39] <didrocks> ogra_: but I pinged you about the cache issue
[09:39] <ogra_> ah, k
[09:39] <didrocks> on lillypilly
[09:39] <didrocks> ogra_: and most of the time, stuff don't get released automatically because of packaging changes
[09:39] <didrocks> ogra_: and we need sil2100 to get to them/publish manually
[09:39] <ogra_> yes, and i still dont know what thats about .... what do we cache there and why ?
[09:40] <didrocks> ogra_: that why I asked you 2 weeks ago to move the clock of image building for one hour
[09:40] <didrocks> ogra_: basically the launchpadlib cache for copying from the ppa to distro was busted
[09:40] <ogra_> didrocks, hmm, i must have missed that, do you want it 1h later ?
[09:40] <ogra_> ah, that one :)
[09:41] <didrocks> ogra_: I think by 9 UTC, sil2100 would have debunked most of the manual publishing
[09:41] <ogra_> no prob i'll move it
[09:41] <didrocks> so then, time to copy from proposed -> release pocket
[09:41] <didrocks> ogra_: when it the image exactly building right now?
[09:41] <ogra_> now that we have to wait for the dashboard (which takes some hours) our testing can run in parallel to it anyway
[09:42] <didrocks> is*
[09:42] <ogra_> didrocks, 8:32 UTC
[09:42] <didrocks> yeah, seems +1h or 1h30 should be fine
[09:42] <cjwatson> https://bazaar.launchpad.net/+branch/ubuntu-cdimage/view/head:/etc/crontab
[09:42] <cjwatson> didrocks: ^-
[09:42] <ogra_> (if there is nothing in front of it that makes it end up in the queue)
[09:42] <didrocks> cjwatson: thanks!
[09:42] <didrocks> ogra_: yeah, most of the times, things are ready when sil2100 starts his day
[09:43] <ogra_> i'll move it ro 10:00 or some such
[09:43] <didrocks> ogra_: ah, that would be excellent
[09:43] <didrocks> ogra_: the only case we can miss the window is if the tests are failing or buildds are really busy
[09:43] <didrocks> which isn't a day-to-day issue for most of the stuff we deliver
[09:44] <ogra_> yeah, if we miss it one day a week thats still better than alll days i bet :)
[09:44] <didrocks> (and if the tests failing, apart from urgent fixes, that can wait next image build I guess once they are fixed)
[09:44] <ogra_> i just dont want the images to come out to late in the day so we can still see the dashboard finish at european wor hours
[09:44] <asac> ogra_: pressing finished?
[09:44] <didrocks> sil2100: agreed on the 9 UTC deadline to have everything we can publish done?
[09:45] <ogra_> asac, not yet
[09:45] <didrocks> sil2100: as you start between 7:30 to 8 UTC, this should be enough time I guess :)
[09:45] <didrocks> ogra_: yeah, completely agree
[09:45] <ogra_> asac, but should be publishing any minute
[09:45] <didrocks> ogra_: if we didn't have packaging changes that much, we won't have this manual publishing so often :)
[09:46] <ogra_> didrocks, well, most of the bits you are currently driving there are -app packages, they will all become click anyway
[09:46] <didrocks> (it's a 2 minutes thing per stack, but needs something with upload rights to "ack")
[09:46] <didrocks> we still have a lot of packaging changes in the platform itself
[09:46] <didrocks> not only apps
[09:46] <ogra_> true
[09:47] <ogra_> but your stack will shrink as soon as they become all click
[09:47]  * sil2100 calculates
[09:47] <didrocks> sil2100: we are +2 FYI ;)
[09:47] <sil2100> didrocks: then yes ;p
[09:48] <ogra_> (date -u ... ) ;)
[09:48] <didrocks> ogra_: not that much, we daily release 239 components as of today and 7 of them are becoming click packages
[09:48] <ogra_> oh ? why only 7
[09:49] <didrocks> ogra_: it's only the apps, right?
[09:49] <ogra_> all things with -app in the name will be click
[09:49] <didrocks> not indicators, platform libs
[09:49] <ogra_> no, right
[09:49] <didrocks> yeah, so 7 of them for what we daily release
[09:49] <ogra_> but we have a lot more apps already
[09:49] <didrocks> I think the others are not under dailies
[09:49] <didrocks> like core apps aren't
[09:49] <ogra_> oh, right, only 7 are seeded atm
[09:50] <didrocks> ogra_: see, I still can count \o/
[09:50] <ogra_> heh
[09:50] <didrocks> which is surprising at the end of this week TBH :p
[09:50] <ogra_> yeah, that was an insane week
[09:50] <didrocks> don't tell me…
[09:51] <seb128> you should get used to it  ;-)
[09:51]  * ogra_ actually slept 12h in a row today since i only had like 3 or 4 every other day of the week
[09:51]  * seb128 has a feeling it's not the last one
[09:51] <ogra_> my body just grabbed what it needed tonight
[09:51] <ogra_> seb128, i cant if i dont want to end up in hospital again i need to limit that to one week/month :)
[09:52] <ogra_> asac, happy flashing :)
[09:52] <seb128> yeah, don't kill yourself
[09:52] <ogra_> i wont, no worries
[09:53] <ogra_> :)
[09:53] <seb128> but it's going to be busy cycles still... ;-)
[09:53]  * ogra_ has learned his limits the hard way
[09:59] <ogra_> popey, 20130719 up ... in case you want to test
[09:59] <popey> will do
[10:00] <ogra_> no hurry, we have to wait for the dashboard in any case
[10:00] <ogra_> but i'm confident we'll at least have a new /current today
[10:00] <popey> I'm keen to have a good image for OSCON next week
[10:01] <popey> heh, no hurry, it's already pushing the zip ☻
[10:01] <ogra_> heh, you and your fast internet
[10:01] <popey> yeah, sorry ☻
[10:01] <ogra_> haha
[10:02]  * didrocks will get 300Mb/s with fiber starting Monday
[10:02] <popey> wowzers
[10:02] <didrocks> that won't change the latency and overall normal page speed, should help for downloads though
[10:02] <didrocks> and uploads :p
[10:03] <didrocks> (no I won't sponsor libreoffice every times :p)
[10:04] <cjwatson> hmm, all tests pass on my click new-hooks branch
[10:04] <cjwatson> I wonder if that means anything of interest
[10:18] <davmor2> cjwatson: well hell had to freeze over at some point, and I suppose the world is getting old and the sun is dying....Oh look 4 Men with wings on horse back
[10:20] <popey> ogra_: do we have a bug filed for the sound indicator not appearing?
[10:20] <ogra_> not appearing or not beeing filled ?
[10:20] <davmor2> cjwatson: well that or it just worked,  I prefer the sound of the second option but hey :)
[10:21] <ogra_> popey, bug 1181299
[10:21] <cjwatson> davmor2: Or my tests are incomplete. :)
[10:21] <popey> ta
[10:21] <ogra_> if it doesnt appaear at all that would be a new one
[10:22] <popey> well, 15 mins later it hasn't appeared
[10:22] <davmor2> cjwatson: but that's the obvious answer I was trying to avoid that :D
[10:23] <ogra_> popey, you mean you have no speaker icon ?
[10:23] <popey> i have a speaker icon, just no slider when i pull down
[10:23] <davmor2> popey, ogra_: have the new images landed now?  Last I heard they were 30-45 minutes away :)
[10:23] <ogra_> yeahm thats the same one then
[10:23] <popey> davmor2: 20130719 has been on my device for ~15 mins
[10:23] <ogra_> davmor2, yes, they did
[10:24] <ogra_> about 30-45min ago
[10:24] <ogra_> :P
[10:24] <davmor2> ogra_: :)  thanks
[10:24] <davmor2> popey: ta
[10:27] <asac> ogra_: image good? dashboard kicking?
[10:28] <asac> gema: i think new images came along... might need some hand holding so we get results in couple hours
[10:28] <ogra_> asac, just dione with syncing, dashboard will take until evening
[10:29] <asac> ogra_: i think if people would kick the retry button etc. it won't take that long really :)
[10:29] <ogra_> asac, ?
[10:29] <asac> if we always wait for hours then yes
[10:29] <ogra_> well, the tests take their time
[10:29] <asac> ogra_: all the tests - if they run through nicely ... will be done in 1.5h or so at max
[10:29] <ogra_> and the test runs dont kick in immediately
[10:29] <asac> if someone watches what goes on on jenkins closely
[10:29] <gema> asac: on it
[10:29] <ogra_> there is a cron job that triggers them
[10:29] <asac> as i said
[10:30] <asac> we can provide handholding
[10:30] <asac> to see how fast we can get this through :)
[10:30] <asac> i think you want those powers at some point  ogra_ :)
[10:30] <ogra_> we could just have a script that monitors when /epednign changes
[10:30] <ogra_> :P
[10:30] <popey> ogra_: 20130719 is good here.
[10:30] <asac> ogra_: what you can do is find the jobs... and then have the jenkins page open
[10:30] <asac> and if you look every 5 minutes you will notice starvation early
[10:30] <ogra_> asac, i dont want more buttons to press, i want automation :)
[10:30] <asac> ogra_: thats not a valid answer :)
[10:31] <ogra_> for the 1h dealy until the testing starts at all it surely is
[10:31] <asac> right. valid requests
[10:32] <didrocks> asac: FYI on desktop (so taking a little bit longer on phone) I guess, tests are taking:
[10:32] <asac> we just can't afford to say until that happens we just keep stuff slow and don't click buttons :)
[10:32] <didrocks> phone: 1min44
[10:32] <ogra_> gema, do you have an idea what these quesrionmark entries are ?
[10:32] <didrocks> hud: 10 min
[10:32] <ogra_> *questionmark
[10:32] <gema> ogra_: otp, one sec
[10:32] <gema> ogra_: I do
[10:32] <didrocks> apps: 15 min
[10:32] <ogra_> ok
[10:32] <didrocks> media: 4min12s
[10:32] <asac> didrocks: phone is unity8 autopilot?
[10:32] <didrocks> friends: 1min50s
[10:33] <asac> that one we dont run yet ... we only run stuff
[10:33] <didrocks> asac: no, phone-app/services
[10:33] <didrocks> sdk: 7min37s
[10:33] <didrocks> and that's it for what we run
[10:33] <asac> gema: can we maybe move the smem job to the end? or make it independent? that one seem to take lots of time and if we would run the autopilots first we would get better info sooner
[10:33] <asac> (guess not short term as it requires jenkins shuffling)
[10:34] <asac> didrocks: id dont think we have included the phone-app tests yet
[10:34] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/image/3053/
[10:34] <asac> i feel all the autopilots there
[10:34] <didrocks> asac: let me look ;)
[10:34] <asac> can be crunched in like 10-12 minutes
[10:34] <asac> especially because we only reboot between autopilot classes (e.g. shell tewam stuff will get a fresh boot, but all apps will just run in one shot)
[10:34] <didrocks> asac: a little bit more I guess (but yeah, here it's the full snapshoting as well, not all running in the same instance) ^
[10:35] <didrocks> asac: yeah, you don't run address-book-app-autopilot
[10:36] <asac> didrocks: those are in the second batch that we haven't added because noone fixed the app tests :) and we had other issues
[10:36] <didrocks> (I skipped unity/indicators/webapps that we run, that you can't on the phone)
[10:36] <didrocks> asac: it's green here, but yeah, on desktop, not on phone ;)
[10:36] <asac> we also have a bunch of core apps/community apps etc.
[10:36] <asac> yeah. once we see progress we will add more tests
[10:37] <gema> asac: we can change them for the next run, right now the devices are provisioning for all those other jobs and we may end up in weird states that takes until rfowler gets to the office if I stop them
[10:37] <asac> we will not wait infinitely :)
[10:37] <asac> gema: yeah. i think if we do that we should not do that outside of weekend
[10:37] <gema> asac: ok
[10:37] <gema> asac: we will look into that next week
[10:39] <gema> ogra_: the ? appears when the dashboard takes a wild guess at the build number
[10:39] <didrocks> asac: if you remove the snapshot, just running all the tests continuously (but again, not unity/indicators/mir/webapps), from what I see, we can estimate the run to 23 minutes (of pure autopilot) on desktop. As much of those are sleep() and waits(), I don't think you will see a big difference on phone
[10:39] <gema> ogra_: the job didn't provide media_info for parsing
[10:39] <gema> ogra_: those jobs are likely failing due to infrastructure
[10:43] <ogra_> gema, wheer would media_info come from ?
[10:43] <gema> ogra_: the images
[10:43] <ogra_> anything i can help with so you have that ?
[10:44] <ogra_> well, the only media-info we have lives inside the image
[10:44] <gema> ogra_: that's the one
[10:44] <ogra_> does the job look there ?
[10:44] <ogra_> ah
[10:44] <gema> ogra_: we extract that from the installed image
[10:44] <gema> and dump it with the logs
[10:44] <gema> ogra_: so no installed image -> no media info
[10:44] <gema> ogra_: and it is likely to be infrastructure issues involved, we look at those
[10:44] <gema> and retrigger/fix
[10:46] <ogra_> gema, yeah, great, as long as is know what it is and that i can ingnore it, all is good
[10:46] <gema> ogra_: you can ignore it
[10:46] <ogra_> :)
[10:47] <gema> ogra_: when plars is not on holidays he hides those after fixing them
[10:47] <ogra_> heh
[10:47] <gema> ogra_: so don't find strange that they disappear when they are fixed
[10:47] <ogra_> yeah, i wont
[10:53] <ogra_> LOL
[10:53] <mardy> tvoss_, Saviq: hi! I was just chatting with greyback about the transient windows feature I'd like to have
[10:54] <ogra_> the software licenses thing in system-settings is funny
[10:54] <tvoss_> mardy, shoot
[10:54] <ogra_> seb128, we really need some kind of scrollbar that can show you how far down you are
[10:55] <mardy> tvoss_, Saviq: quick recap: it's about process A invoking process B and have the window created by process B appear on top of process A's window, just as if it where a single app
[10:55] <tvoss_> mardy, I guess my point is: what means single app?
[10:55] <mardy> tvoss_: that when you go to the task switcher, you don't see two different apps
[10:55] <tvoss_> mardy, by default, on the phone, a surface is either maximized or fullscreen
[10:56] <tvoss_> mardy, what do you see in the preview of app A then?
[10:56] <mardy> tvoss_: in other words, while the window created by process B is visible, it should be impossible to the user to go back to the window created by process A
[10:56] <mardy> tvoss_: you see the B window
[10:57] <mardy> tvoss_: when you click the "back" button in window B, you go back to window A
[10:58] <mardy> tvoss_: like http://doc-snapshot.qt-project.org/qt5-stable/qtgui/qwindow.html#setTransientParent
[10:58] <tvoss_> mardy, okay, back button in window B then has to terminate process B, right?
[10:58] <mardy> tvoss_: yes, or at least to close its window
[10:59] <tvoss_> mardy, nope, it really has to quit, otherwise the shell won't transfer focus
[10:59] <tvoss_> mardy, but that's a detail
[10:59] <mardy> tvoss_: agreed, we could make it die if needed
[11:00] <tvoss_> mardy, for setTransientParent: is that wired up to the qpa somewhere?
[11:00] <mardy> tvoss_: yes
[11:00] <mardy> tvoss_: I'm quite familiar with this QPA code for XCB
[11:00] <tvoss_> mardy, mind pinging me the link?
[11:01]  * mardy hates gitorious, but will try :-)
[11:01] <tvoss_> mardy, just to clarify: we are talking about session association here, not embed
[11:01] <mardy> tvoss_: exactly, only association
[11:01] <greyback> tvoss_:  shell can easily add if child surface disappears, shell will give focus to it's parent.
[11:02] <tvoss_> greyback, sure, but what is the best way to model this in the mir client API?
[11:02] <tvoss_> greyback, A would need to hand a token to B, B needs to create surface with token from A as parent
[11:03] <mardy> tvoss_: https://qt.gitorious.org/qt/qtbase/blobs/stable/src/plugins/platforms/xcb/qxcbwindow.cpp#line638
[11:03] <greyback> tvoss_: that is indeed the issue... I'm not sure how to deal with that
[11:04] <tvoss_> greyback, the other thing is: A is most likely stopped while B is running
[11:04] <mardy> tvoss_: here is how it would work in Qt: once process B has the token (winId), it does:
[11:04] <mardy> QWindow *windowA = QWindow::fromWinId(handleOfWindowA);
[11:04] <mardy> windowB->setTransientParent(windowA);
[11:04] <mardy> tvoss_, Saviq ^
[11:06] <seb128> ogra_, yeah, licenses is fun :p
[11:06] <Saviq> tvoss_, well, since shell knows B is transient, it could not stop it
[11:06] <Saviq> it == A
[11:06] <Saviq> tvoss_, app manager not stop it, that is
[11:06] <seb128> ogra_, the issue with the scrollbar is that you need to know the height of the list to do that and we don't have it, datas are loaded on demand when scrolling down
[11:07]  * mardy is not sure why A needs to be running
[11:07] <seb128> ogra_, I tried building the full list but that was blocking the UI for 5 seconds on opening
[11:07] <ogra_> sounds like a bug :)
[11:07] <ogra_> (with the scrollbar implementation)
[11:07] <Saviq> mardy, I'd assume the two windows communicate somehow?
[11:08] <ogra_> browsers manage as well to grow/shrink the bar on demand
[11:08] <Saviq> mardy, wait, it's just one process, two windows?
[11:08] <Saviq> mardy, ok, two processes
[11:08] <mardy> Saviq: as far as my use-case is concerned, no. After B is done, it will store some info somewhere, and A will resume and read it
[11:09] <mardy> Saviq: yep
[11:09] <greyback> tvoss_: Saviq: app manager would need to know about both processes, and their connection. So if processA opened processB, then user switches to another app, both processes should be frozen
[11:09] <Saviq> greyback, +1
[11:09] <Saviq> greyback, and both should be running otherwise
[11:09] <greyback> Saviq: yep
[11:09] <Saviq> mardy, both need to run in case the transient one isn't fullscreen or is transparent
[11:09] <Saviq> mardy, so that the background one can update
[11:10] <Saviq> but that should be ok I think
[11:10] <mardy> Saviq: right; though in my use-case, the window B should appear as a page on top of window A, so it should have exactly the same size
[11:11] <mardy> Saviq: but in the general case, you are right
[11:11] <Saviq> mardy, should the size be ensured by window management?
[11:11] <Saviq> mardy, or is it ensured by process B in the general case?
[11:12] <mardy> Saviq: good question. I don't see it as essential, I think that B can figure out itself
[11:12] <Saviq> mardy, k
[11:13] <flo__> hello
[11:14] <mardy> Saviq, tvoss_: my understanding is that Mir needs to have a way to say that a surface is the child/parent of another, and expose it to the shell, who will do the decision making
[11:14] <flo__> has anyone tried installing ubuntu on a motorola defy xt320?
[11:15] <mardy> Saviq, tvoss_: so, the QPA plugin will set this information when setTransientParent is called
[11:15] <Saviq> flo__, https://wiki.ubuntu.com/Touch/Devices is the most extensive list
[11:15] <Saviq> mardy, yeah, sounds right
[11:15] <greyback> mardy: Saviq: tvoss_: also each surface needs to identify the session that it belongs to.
[11:16] <mardy> greyback: session? Maybe the shell can walk up the surface parent, and understand which one is the toplevel app
[11:18] <greyback> mardy: sorry,  in Mir terminology, session=app. Right now, Mir doesn't easily let shell determine what session/app created a particular surface
[11:18] <ogra_> gema, do you know how that percentage column is computed ? on maguro for todays image i see 11 tests passed out of 11 but it shows red and 50%
[11:19] <greyback> mardy: (which is a request I put in a week or two ago)
[11:19] <ogra_> (grouper mako and manta seem to do it right)
[11:20] <gema> ogra_: that sounds like something I discussed with rickspencer and asac last week but didn't know some of it had landed
[11:20] <gema> ogra_: there are more tests meant to run
[11:20] <gema> ogra_: can you give me a link?
[11:20] <ogra_> i know
[11:21] <ogra_> its just that maguro seems to behave different from the others
[11:21] <ogra_> gema, well, i see it on http://reports.qa.ubuntu.com/smokeng/saucy/ the detailed view would be http://reports.qa.ubuntu.com/smokeng/saucy/image/3072/
[11:21] <ogra_> oh
[11:22] <ogra_> and klicking the latter it seems the sdk test isnt well on maguro
[11:22] <ogra_>  scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -P52182 -r 'phablet@localhost:/home/phablet/workspace/results/*.yaml' .
[11:22] <ogra_> ssh_exchange_identification: Connection closed by remote host
[11:23] <ogra_> seems there is a race or something
[11:23] <gema> ogra_: yep, leave that with us for now
[11:23] <ogra_> will do
[11:27] <gema> ogra_: the device didn't get the network configuration properly
[11:27] <gema> ogra_: we'll rerun
[11:28] <ogra_> gema, thx
[11:32] <Mahendra> hi
[11:42] <Saviq> MacSlow|lunch, still the same failure http://<IP_ADDRESS>:8080/job/unity-phablet-qmluitests-saucy/707/testReport/junit/%28root%29/qmltestrunner/NotificationRendererTest__test_NotificationRenderer/
[11:53] <davmor2> hey guys currently if you hang up on a call the user receives  there is a fault please hang up and try again  I don't know if it is meant to go through to answering machine instead which is what happens on android as far as I can tell
[11:54] <davmor2> meh sorry decline a call rather than hang up
[11:54]  * popey tries that
[11:54] <popey> so dial from outside to my ubuntu phone, then hang up where? at what point?
[11:56] <davmor2> popey: in the popup for the call click on decline
[11:56] <popey> i dialled from my android phone to my ubuntu phone, and clicked "decline" on the ubuntu phone
[11:57] <popey> it went to answerphone
[11:57] <popey> however there's something not right with the indicatore
[11:58] <asac> jcollado: ogra_: gema: jobs stuck?
[11:59]  * jcollado checks
[11:59] <popey> right.
[11:59] <asac> please ensure all have run through by checking every other minute :)
[11:59] <asac> people are awaiting results eagerly
[12:00] <popey> davmor2: call your ubuntu phone, hit decline, phone it again. it diverts to answerphone. Once you decline a call you can't receive another call until you dial out
[12:00] <popey> for a while anyway
[12:03] <davmor2> popey: hmm odd it is working for me, however I'm not getting a notification for the declined call
[12:03] <popey> hmm
[12:04] <asac> jcollado: all spinning now?
[12:04] <davmor2> popey: messaging menu and conversation windows aren't listing the declined call which would make it harder to call them back
[12:05] <jcollado> asac: Many jobs for the applications seem to have failed. I can rerun them. Are you specially interested in any of them?
[12:05] <asac> jcollado: all jobs for all iamges need to be poked until we have results
[12:06] <jcollado> asac:Ok
[12:06] <asac> the smem i am not interested in
[12:06] <asac> avoiding those would probably speed up getting results as well
[12:07] <jcollado> asac: Anyway, if you're not seeing any result at all, maybe is just that the dashboard hasn't pulled them from jenkins yet.
[12:07] <asac> jcollado: they havent run
[12:07] <asac> https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-default/
[12:08] <asac> -> sdk
[12:08] <asac> -> apps
[12:08] <asac> https://jenkins.qa.ubuntu.com/job/saucy-touch-mako-smoke-default/
[12:08] <asac> -> apps
[12:08] <asac> https://jenkins.qa.ubuntu.com/job/saucy-touch-grouper-smoke-default/
[12:08] <asac> -> apps
[12:08] <asac> https://jenkins.qa.ubuntu.com/job/saucy-touch-manta-smoke-default/
[12:08] <asac> -> apps
[12:08] <asac> jcollado: guess kick them all
[12:13] <jcollado> asac: Done
[12:13] <davmor2> popey: be on a call for more than a minute and try to end the call screensaver kicks in on top of the screen blank so you have to unlock the device then hit the end button sadtrombone.com :(
[12:15] <ogra_> asac, i dont think anything is stuck, it always took between 30min and 1h before the app jobs start
[12:15] <ogra_> after default, sdk and security have run
[12:15] <pmcgowan> davmor2, theres nothing in the app framework yet to control that
[12:15] <pmcgowan> I think
[12:32] <ogra_> GRR
[12:34] <ogra_> so after having a real hard time logging in to U1 on my maguro, clicking on "music" (i actually just wanted to pull some mp3's to the phone to test the music player) i end up with a network error that points to itunes
[12:34] <ogra_> and there is no way to go back in the browser or anything, its just stuck there
[12:36] <ogra_> asac, did you propose a new string fro the browser so it isnt always identified as IOS ?
[12:37]  * ogra_ finds it pretty ironic that he cant use ubuntu services on a ubuntu phone
[12:37] <seb128> cjwatson, should I be able to install click packages from http://people.canonical.com/~ubuntu-archive/click_packages/ on saucy (still having click 0.1.7 not the new one yet)?
[12:38] <seb128> cjwatson, I get 'ValueError: Framework "ubuntu-sdk-13.10" not present on system' when I try to click install those
[12:38] <cjwatson> $ sudo click install --force-missing-framework --user=cjwatson com.ubuntu.calendar_0.4_all.click
[12:38] <cjwatson> WFM
[12:38] <cjwatson> You do need that --force-missing-framework option until the framework decl is in place
[12:38] <cjwatson> The PK client currently passes that unconditionally
[12:40] <seb128> cjwatson, great, that works thanks
[12:41] <asac> ogra_: i did that
[12:41] <asac> yes
[12:41] <asac> i propose to find our own string like mozilla suggested in the bug
[12:41] <asac> and then have per-site exceptions
[12:41] <asac> for very important stuff
[12:41] <seb128> cjwatson, do you have on opinion on making click have a sort of trigger that generate a xml (or json) "database" of the package installed with their name/installed size/icon infos?
[12:42] <ogra_> asac, yeah, well, identifying as iphone definitely doesnt cut it
[12:42] <seb128> cjwatson, I'm looking at how to best list the click packages from the system settings panel, loading an xml makes the job trivial from qml ... but I'm not sure it makes sense to generate a such .xml for only one user
[12:43] <seb128> cjwatson, the alternative is to add some cpp code to wrap around "click list" on my side
[12:43] <cjwatson> seb128: "click list --manifest" except that it doesn't have the extra installed-size/icon stuff yet
[12:43] <cjwatson> but that's the interface I intend for this
[12:44] <seb128> ok, I will add some cpp code and glue then
[12:44] <seb128> having a xml just makes things trivial for the UI since you can just use it as a list model and have qml does all the work for you
[12:44] <cjwatson> the icon info requirement is new to me.  what do you need there?
[12:44] <cjwatson> yeah, but xml makes my toes itch
[12:44] <cjwatson> can you tolerate json for this?
[12:44] <seb128> yes
[12:45] <seb128> cjwatson, http://people.canonical.com/~seb128/storage.png
[12:45] <seb128> cjwatson, the list of apps there, I need the icon/display name/size
[12:46] <ogra_> gema, didnt you re-start the sdk test on maguro ? there are still no results
[12:46] <gema> jcollado_afk: ^
[12:46] <gema> ogra_: otp
[12:47] <cjwatson> seb128: OK, added a WI for that to https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-click-package - I'll try to sort it out next week
[12:47] <seb128> cjwatson, though the size includes the datas so I'm going to have to "du" on the dirs
[12:47] <seb128> cjwatson, thanks!
[12:47] <cjwatson> seb128: as in data owned by the app but not part of its unpack dir?
[12:48] <jcollado_afk> ogra_, gema: Yes, I did
[12:48] <cjwatson> if so, yeah, can't help you with that part of it, only with the stuff click actually owns
[12:49] <seb128> cjwatson, well, that should be the space the app is using on disk, so including cached datas, etc
[12:50] <seb128> so yeah, it's not going to be a static information and something the clicks can include
[12:51] <asac> jcollado_afk: where can i see the jobs running?
[12:52] <ogra_> jcollado_afk, oh
[12:52] <ogra_> Download uri set to http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130716
[12:52] <ogra_> Download directory set to /home/ubuntu/Downloads/phablet-flash/ubuntu-touch/20130716
[12:52] <ogra_> it doesnt pull from /pending
[12:52] <ogra_> https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-sdk/32/console
[12:53] <ogra_> (that should be 20130719)
[12:56] <ogra_> oh, fun, looking at the other logs shows the same
[12:56] <timp> is there a full manual howto install the phone for daily usage, so not just development?
[12:56] <ogra_> asac, ^^^
[12:56] <ogra_> seems none of the tests ran agaunst /pending (at least for maguro)
[12:56] <sergiusens> ogra_: phablet-flash is missing the --pending arg in that log
[12:57] <timp> so 1. wipe all data, 2. install ubuntu touch, 3. references that explain how to get your contacts and data?
[12:57] <ogra_> sergiusens, in all of them it seems
[12:58] <popey> timp: not in one tidy place, needs to exist though
[12:58] <sergiusens> ogra_: so image based updates depends on the recovery in pending to be in current :-/
[12:58] <sergiusens> this may not be a happy day
[12:58] <sergiusens> :-P
[12:59] <timp> popey: the lack of that is the main reason I am not using it as my main phone now. I'd have to spend quit some time to find all the wiki pages and blog posts that tell me how to set it up
[12:59] <ogra_> sergiusens, well,, we currently mostly care for utah still
[12:59] <timp> just a collection of links would be nice to begin with
[12:59] <cjwatson> Right.  Click hooks hopefully done, with any luck sbeattie will be able to get the apparmor hook working based on this, and if nobody else does then I'll attempt to sort out the desktop hook early next week in time for the demo
[12:59] <ogra_> sergiusens, once image based updates are allowed in we will fix that bit :)
[13:00]  * cjwatson finally manages to start on his half-day holiday
[13:00] <popey> timp: ok, will do that
[13:00] <timp> popey: thank you very much :)
[13:00] <sergiusens> cjwatson: enjoy!
[13:00] <popey> np
[13:00] <pmcgowan> ogra_, yikes
[13:02] <kalikiana> popey, count me in as a guinepig if you start a site for that, although I'm doubtful I'd give it a try
[13:03] <kalikiana> hm that sounds odd: I mean, I have doubts how well it'll fare for all I need, but I'd try it for a bit
[13:03] <timp> kalikiana: how can you be a guineapig if you don't give it a try?
[13:03] <timp> ah :)
[13:03] <kalikiana> the wording was a bit strange, yeah :-D
[13:04] <timp> I need to be able to make phone calls, and send sms
[13:04] <timp> navigation and whatsapp would also be useful though :)
[13:04] <timp> I think there is a python lib for whatsapp that runs on ubuntu, just needs a qml frontend :)
[13:04] <sergiusens> timp: I've been using it as my main phone for 2-3 months
[13:05] <sergiusens> timp: thing I miss the most is gps/maps
[13:05] <sergiusens> and photo sync
[13:05] <kalikiana> sergiusens, is it usable with mobile data?
[13:05] <popey> kalikiana: just gonna put some notes together and make a very simple wiki page.
[13:05] <asac> ogra_: it is odd
[13:05] <kalikiana> popey, that'd be awesome!
[13:05] <sergiusens> kalikiana: yes, but there's not much to do with just a browser
[13:05] <sergiusens> as in, no youtube :-)
[13:05] <asac> ogra_: we saw that yesterday
[13:05] <asac> but the results get pushed with proper build id
[13:06] <asac> and that is taken from the downloaded image afaik
[13:06] <asac> but yeah
[13:06] <asac> if thats the case its a mess
[13:06] <asac> doanac: jcollado_afk: fginther: can you guys check that?
[13:06] <asac> gema: ?
[13:06] <asac> e.g. do we pull the right image... we still see the 16 image
[13:06] <asac> are we really running phjablet-flash --pending?
[13:06] <asac> do we have the right version?
[13:06] <gema> asac: we do, we are
[13:06] <sergiusens> asac: from the logs phablet-flash is missing the --pending arg
[13:06] <kalikiana> sergiusens, I can live without videos. but I use it a lot to browse feeds and blogs in the train etc
[13:07] <gema> asac: otherwise you wouldn't be seeing results for today
[13:07] <asac> gema: how do we explain the odd log output that ogra_ saw?
[13:07] <ogra_> asac, in the logs it definitely doesnt pull with --pending
[13:07] <gema> (that comes from the image media-info
[13:07] <asac> gema: check with ogra plz
[13:07] <asac> I think he found something interesting that we should at least understand
[13:07] <gema> asac: I will check with doanac
[13:07] <asac> is he online?
[13:07] <ogra_> gema, why does it download 20130716 then
[13:07] <sergiusens> + flock /tmp/phablet-flash-lock phablet-flash -s 0149BD7E0A019003
[13:07] <ogra_> could it be we see old logs but the tests are fine ?
[13:07] <timp> kalikiana: dutch trains have wifi nowadays :)
[13:07] <gema> ogra_: I saw that yesterday, then when you look at the logs it shows the right media-info
[13:08] <gema> ogra_: something is wrong, but we are definitely testing the right image
[13:08] <gema> ogra_: the dashboard doesn't make numbers up
[13:08] <gema> ogra_: it parses them from the logs
[13:08] <ogra_> ok
[13:08] <gema> ogra_: the only made up are marked with a question mark
[13:08] <sergiusens> gema: in https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-sdk/32/console the phablet-flash cmd doesn't have --pending ... is that an old log?
[13:09] <kalikiana> timp, what's the cost, though? I get unlimited data easily
[13:09] <gema> sergiusens: where did you get that link from?
[13:10] <ogra_> gema, clicking in the dashboard
[13:10] <ogra_> the console log link points to it
[13:11] <gema> ogra_: latest run?
[13:11] <sergiusens> it says 20130719
[13:11] <gema> sergiusens: look at the artifacts
[13:11] <gema> media-info is there
[13:11] <sergiusens> Jul 19, 2013 10:40:15 AM
[13:11] <gema> that's the image that was installed
[13:11] <ogra_> gema, yeah http://reports.qa.ubuntu.com/smokeng/saucy/image/3072/
[13:11] <ogra_> the sdk points to /32
[13:12] <gema> ogra_: different jenkins jobs have different run numbers
[13:12] <ogra_> err, yes
[13:12] <gema> ogra_: the dashboard groups the ones that run on the same image
[13:12] <asac> its anyway super odd
[13:12] <asac> :)
[13:12] <ogra_> yeah
[13:12] <gema> asac: agreed
[13:12] <asac> ogra_: have you checked that our 16 link is maybe pending by accident?
[13:12] <asac> :)
[13:12] <asac> maybe thats messed up on publisher side
[13:12] <ogra_> it should just point to the latest one for this build
[13:12] <asac> the webserver certainly does no redirect
[13:12] <ogra_> asac, likely just a dashboard glitch
[13:12] <asac> so its hard to say in which dir pending goes
[13:12] <asac> etc.
[13:13] <ogra_> the prob is that the colors and percentages are comuted from that
[13:13] <gema> ogra_: yesterday doanac was fixing the infrastructure, taht was a cosmetic issue to me
[13:13] <ogra_> *computed
[13:13] <gema> ogra_: we'll look at that today
[13:13] <asac> well... kin thi case phablet-flash says it downloads the 16
[13:13] <asac> thats not a cosmetic bug :)
[13:13] <timp> kalikiana: cost? wifi for free
[13:13] <ogra_> no,. thats just strange
[13:13] <gema> ogra_: agreed
[13:13] <asac> it only can mean that that URL returns the real image... or that we dont see another download that happens elsewhere adn this one is not used
[13:13] <ogra_> but it stamps the right id in the log at the end
[13:13] <gema> asac: cosmetic if it actually downloads today's
[13:13] <gema> :)
[13:14] <asac> yay ... scaringly cosmetic
[13:14]  * gema is being pragmatic
[13:14] <kalikiana> timp, neat!
[13:14] <gema> asac: indeed we'll look at it
[13:14] <asac> well, if we dont see autopilot test results improve in todays run
[13:14] <asac> we probably have to look closer
[13:14] <asac> was told quite a few of those that failed yesterday should be fixed now
[13:14] <asac> so ... lets see :)
[13:14] <asac> where do we stand with results :)
[13:15] <sergiusens> asac: gema ogra_ the stamp may be right because you are getting it from running rsync -l rsync://cdimage.ubuntu.com/cdimage/ubuntu-touch/daily-preinstalled/
[13:15] <sergiusens> grep pending
[13:16] <pitti> boiko: Hey Gustavo, how are you?
[13:16] <ogra_> oh, not from inside the image ?
[13:16] <asac> so we might not even look at the right stamp :(
[13:16] <asac> so it jmjight be a problem after all
[13:16] <ogra_> it should parse /var/log/installer/media-info
[13:16] <ogra_> from inside the installed image
[13:16] <pitti> boiko: gema told me you would be a good person to talk to wrt. automating ubuntu phone call/sms testing?
[13:16] <ogra_> thats the most reliable source we have
[13:16] <boiko> pitti: hello! I'm good thanks, and you?
[13:17] <ogra_> but indeed that requires the image to be installed first
[13:17] <pitti> boiko: quite fine, thanks!
[13:17] <boiko> pitti: yep, me, or _salem, we both work on the phone-app
[13:18] <pitti> boiko: should we perhaps have a hangout or mumble call in the next days, to sync up what we want to do, what I should teach umockdev, etc.? I think I have a reasonably clear idea now (I got a phone two days ago and did some investigations), but I'd rather like to agree on the requirements with you guys
[13:20] <boiko> pitti: yes, I would just not invest too much time on autopilot tests for this as the phone-app is being splitted into three new apps and thus the UI is going to be changed a lot
[13:20] <pitti> boiko: oh, I'm not writing autopilot tests
[13:20] <boiko> pitti: that's fine then :)
[13:20] <pitti> boiko: my task is to "virtualize" the underlying android phone stack
[13:21] <pitti> boiko: so that we can record once what the phone app and ofono do to the android stack (rild mostly), and replay that in a testbed environment, so that you (1) don't need to have the hardware/sim, (2) don't generate costs, and (3) we can do that in the DC/Jenkins/CI
[13:22] <boiko> pitti: nice!
[13:22] <pitti> boiko: we are regularly doing that for things like cameras or USB media players, and I recently got it to work with ModemManager
[13:22] <popey> timp: kalikiana https://wiki.ubuntu.com/Touch/DailyDriver - ping me if you want anything extra added or spot any errors (or fix them) :D
[13:22] <pitti> boiko: but the android phone stack is quite a bit different
[13:22] <pitti> boiko: but I'd still like to discuss what we actually want to do, etc. (preferrably in high-bandwidth communication)
[13:23] <timp> popey: great, thanks
[13:24] <boiko> pitti: ok, so you are trying to virtualize rild? maybe doing something at the ofono level would be simpler? (like taking ofono-phonesim and make it scriptable or respond to dbus commands?)
[13:24] <boiko> pitti: in any case, would you mind scheduling a hangout and include me, _salem and probably Tony Espy to talk about that?
[13:26] <pitti> boiko: we could do that, too, there's pros and cons about that
[13:26] <pitti> boiko: yes, sounds good
[13:27] <moxzie> hi
[13:27] <stgraber> ogra_: I think ondra made gpg build from source now. The binary is built statically as we don't have a linker in the recovery partition though.
[13:28] <pitti> boiko: so sometime in your morning/my afternoon? I'll try Monday or Tuesday
[13:28] <ogra_> stgraber, yea, its all fine, the error wasnt in gpg
[13:28] <stgraber> ok
[13:28] <ogra_> it was a multijob compile .... just a messed up log output
[13:29]  * ogra_ really hates that make does  ir that way
[13:30] <boiko> pitti: yep, sounds good
[13:30] <asac> sergiusens: do you understand the jenkins tools a bit?
[13:31] <sergiusens> asac: I understand jenkins but not utah itself
[13:31] <sergiusens> asac: as in how everything is deployed
[13:31] <asac> sergiusens: utah is just a small set of python scripts
[13:32] <asac> the code should be reasonably easy to understand... given the current mess, I would feel much safer if someone from phonedations would become a bit versed in that
[13:32] <asac> not sure if you agree :)
[13:32] <didrocks> asac: is friends still failing?
[13:32] <asac> otherwise we always talk and guess and stuff ... while we could just check and be happy
[13:32] <didrocks> ogra_: you got the latest friends, right?
[13:32] <sergiusens> asac: well I do see http://bazaar.launchpad.net/~utah/utah/dev/view/head:/examples/run_utah_phablet.py#L60 has the right stuff
[13:32] <ogra_> didrocks, on the image ?
[13:33] <sergiusens> asac: I have no issues with that, but I would need to have access to the servers
[13:33] <didrocks> ogra_: yep ;)
[13:33] <didrocks> ogra_: I'm sure this one is fixed
[13:33] <didrocks> ogra_: and kenvandine tested it on the device as well
[13:33] <ogra_> didrocks, 0.2.0+13.10.20130718-0ubuntu1
[13:33] <ogra_> what i see istalled
[13:33] <didrocks> so it would be a good indication :)
[13:33] <sergiusens> asac: I have no login in the jenkins instance where this runs
[13:33] <didrocks> ogra_: ah, you need 0.2.0+13.10.20130719-0ubuntu1 I guess
[13:33] <didrocks> ogra_: friends-app
[13:33] <asac> sergiusens: you cannot see the dashboard?
[13:33] <asac> sergiusens: you hav eto get a QA VPN access
[13:33] <asac> VPN
[13:33] <ogra_> didrocks, well, then it didnt make it today
[13:34] <didrocks> ogra_: apt-cache policy friends-app: 0.91.3+13.10.20130718-0ubuntu1
[13:34] <rsalveti> pitti: mind including me as well to such testing conversation?
[13:34] <didrocks> humn, weird, I maybe didn't apt-get update
[13:34] <didrocks> let me check
[13:34] <sergiusens> asac: I can see the dashboard, I have VPN and know how to get there with ssh tunneling
[13:34] <ogra_> didrocks, i think that was our timing issue (which we talked about above)
[13:34] <ogra_> didrocks, todays image was already running when i pinged you about it
[13:35] <rickyc> excuse me but when can we submit our apps to ubuntu phone?
[13:35] <sergiusens> asac: each jenkins job has a setup, in order to best find the problem I need to see how that is constructed
[13:35] <didrocks> ogra_: ah ok, I thought you rebuilt it after this
[13:35] <rickyc> I have created an app that I wish to use
[13:35] <didrocks> ogra_: yeah, so you won't see that one fixed yet
[13:35] <rickyc> submit rather
[13:35] <ogra_> didrocks, nope, utah needs to be proven working first
[13:36] <ogra_> rickyc, popey or mhall119 should be able to help you
[13:36] <rickyc> I have written it in HTML5
[13:36] <ogra_> didrocks, then i'll trigger a rebuild ... and for tomorrows job the cron will be changed
[13:36] <didrocks> ogra_: excellent! :)
[13:36] <rickspencer3> mhall119, ^ see rickyc above
[13:36] <didrocks> ogra_: I think it will be a good indicator if utah really takes the latest image or not
[13:37] <asac> ogra_: sergiusens: ok so i think we found it ... the autopilot jobs pull the latest: https://jenkins.qa.ubuntu.com/job/smoke-saucy-touch-apps-maguro/15/console
[13:37] <asac> however, default and sdk etc. have not been converted to --pending
[13:37] <ogra_> yeah
[13:37] <asac> e.g. not very nice, but doesnt mean we get wrong results on autopilot tests at least
[13:37] <ogra_> thats pretty cleatr from the log
[13:37] <sergiusens> ogra_: well that was what we were seeing from the logs
[13:37] <sergiusens> asac: ^^
[13:38] <sergiusens> not much more we can do after that without access
[13:38] <ogra_> asac, what i dont see in the utah branch is the call that is actually executed for this
[13:38] <asac> ogra_: which branch are you looking at?
[13:38] <sergiusens> ogra_: might be this http://bazaar.launchpad.net/~utah/utah/dev/view/head:/examples/run_utah_phablet.py#L60
[13:38] <ogra_> i would have an MP by now if i could find the responsible code
[13:38] <ogra_> but that doesnt seem to be there at all
[13:38] <asac> yeah. so seems that autopilot uses one code path
[13:38] <ogra_> asac, lp:utah
[13:38] <rsalveti> ogra_: so besides this issue you're discussing, anything else we need to fix right away or just waiting the results to be published? for all the test cases we have
[13:38] <asac> and the other tests (runlist) dont use the same
[13:39] <popey> hi rickyc join us in #ubuntu-app-devel please
[13:39] <sergiusens> asac: so where do we see what you are mentioning?
[13:39] <sergiusens> asac: the fact that one is updated and the other isn't, aside from the logs
[13:40] <asac> i only see it in the logs so far
[13:40] <asac> but i know that autopiulot is a big feature
[13:40] <asac> and then they have something called dynamic runlists
[13:40] <asac> thats what the security and sdk suites do
[13:40] <asac> and most likely default
[13:40] <asac> sergiusens: ^
[13:41] <ogra_> asac, autopilot is executed by run_utah_phablet.py
[13:41] <ogra_> asac, the broken code is the code that *calls* run_utah_phablet.py
[13:41] <asac> ogra_: right. but there is something else?
[13:41] <ogra_> and that doesnt seem to be in the branch anywhere
[13:41] <asac> not autopilot
[13:41] <ogra_> i dont think so
[13:42] <sergiusens> asac: ogra_ that is most likely in the jenkins configuration which we don't have access to
[13:42] <asac> right
[13:42] <ogra_> yeah
[13:42] <sergiusens> asac: ogra_ this is the runlist btw http://bazaar.launchpad.net/~canonical-platform-qa/ubuntu-test-runlists/touch-runlists/view/head:/runlists/touch-smoke-sdk.run
[13:42] <pitti> rsalveti: sure
[13:42] <ogra_> thats what i mean, a copy (or even the master) should eb shipped in the utah source tree
[13:43] <asac> sergiusens: yaeh... maybe default is just super special?
[13:43] <asac> can you see that?
[13:43] <rsalveti> pitti: thanks
[13:45] <sergiusens> asac: default might have been updated whilst the others haven't, if by default you mean the jenkins job that passes
[13:45] <asac> sergiusens: there is a special job called "default"
[13:45] <asac> that one is supposed to check if anything can work at all (e.g. console works, network works etc.)
[13:45] <asac> anyway
[13:45] <asac> not our issue
[13:45] <asac> lets wait for results
[13:46] <sergiusens> asac: well default isn't updated either if it's https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-default/55/console
[13:46] <asac> default isnt ... i know
[13:46] <sergiusens> asac: flock /tmp/phablet-flash-lock phablet-flash -s 0149BD7E0A019003
[13:46] <asac> thats the one i looked at
[13:46] <sergiusens> no --pending there
[13:46] <asac> i didnt check security and sdk
[13:46] <asac> i know that autopilots at lest have pending on maguro
[13:46] <asac> you might want to check others :)
[13:46] <sergiusens> and the build id is correct because it's being collected through a different path
[13:47] <asac> could you confirm its colleced through a wget style approach?
[13:47] <asac> in code i mean?
[13:47] <asac> or do you suspect?
[13:47] <pitti> rsalveti, boiko: tentatively added a meeting for Monday 1500 UTC, please feel free to move around
[13:47] <ogra_> well, and whatever collects it also calls run_utah_phablet.py too ... without --pending (which seems to get handed over to phablet-flash)
[13:47] <sergiusens> asac: it's collected using rsync -l uri|grep pending
[13:48] <asac> sergiusens: you were able to confirm that for autopilot tests?
[13:48] <asac> default etc. are known to be bogus
[13:48] <asac> i didnt find an autopilot test that looked wrong
[13:48] <ogra_> asac, again, autopilot us run as last step in that code chain
[13:48] <ogra_> *is run
[13:48] <asac> look at the log of an autopilot console
[13:48] <ogra_> the problem is at the start of the chain
[13:48] <ogra_> not at the end
[13:48] <asac> no
[13:48] <asac> the system is rebooted and reflashed for all autopilots
[13:49] <ogra_> (there might be one too, but thats unrelated)
[13:49] <sergiusens> asac: https://jenkins.qa.ubuntu.com/job/smoke-saucy-touch-apps-maguro/17/console has = flashing device with cmd: phablet-flash -s 0149BD7E0A019003 --pending
[13:49] <asac> https://jenkins.qa.ubuntu.com/job/smoke-saucy-touch-apps-maguro/15/?'
[13:49] <asac> thats the job for last maguro
[13:49] <asac> that looks okaish
[13:49] <ogra_> asac, no, ignore the questionmark bits
[13:49] <sergiusens> asac: 17 is the last one
[13:49] <ogra_> they are broken
[13:49] <ogra_> i discussed that with gema already
[13:49] <asac> sure but it downloads the correct one at least
[13:50] <asac> 19
[13:50] <ogra_> just ignore, dashboard wont show them anymore soon
[13:50] <sergiusens> asac: the dashboard is for managers :-)
[13:50] <sergiusens> asac: look at the end of https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-default/55/console
[13:50] <asac> i see it faile
[13:50] <asac> d
[13:50] <asac> but it downloaded the correct build
[13:51] <asac> 19
[13:51] <sergiusens> asac: those are the real jobs that are ran
[13:51] <asac> right. seems it pulled a broken image once
[13:51] <asac> needs to be removed from disk
[13:51] <asac> guess was a temporary pull
[13:51] <asac> because we dont move stuff atomically inplace on cdimage
[13:51] <asac> or network is flaky
[13:52] <sergiusens> HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable
[13:52] <asac> yeah
[13:52] <asac> that most likely means the image changed under the URL afterwards or we have network server issues or or or
[13:52] <asac> it deosnt mean it pulsl the 16th :)
[13:52] <asac> anyway
[13:52] <asac> i will not guess here
[13:52] <sergiusens> asac: it pulled the correct one
[13:52] <sergiusens> Downloading http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130719/saucy-preinstalled-touch-armhf.zip
[13:52] <asac> right. thats all i bothered about
[13:52] <ogra_> yeah
[13:52] <ogra_> but the other tests arent
[13:53] <sergiusens> ogra_: correct
[13:53] <asac> sure. but first get the current job fdinished
[13:53] <rsalveti> ppisati: we should have our daily meeting at 15utc, half hour earlier or later is better already
[13:53] <ppisati> rsalveti: nice
[13:53] <rsalveti> sorry dude :P
[13:54] <rsalveti> pitti: you sent it for 14utc
[13:54] <ppisati> rsalveti: was it for me or someone else? :)
[13:54] <ppisati> LOL :)
[13:54] <pitti> rsalveti: right, is that too early? I can't do later on Monday
[13:54] <rsalveti> was for pitti
[13:54] <rsalveti> pitti: 14 utc sounds about right :-)
[13:54] <pitti> rsalveti: sorry, typoed in my irc message above
[13:54] <boiko> pitti: I have a standup meeting every day at 14:00 UTC, can we do it on tuesday 15:00 UTC?
[13:55] <asac> doanac: there yet?
[13:55] <asac> doanac: seems the house needs you
[13:55] <ogra_> heh
[13:55] <pitti> boiko: WFM; rsalveti, Tue 15:00?
[13:55] <rsalveti> haha, and we have our stand up at 15utc
[13:55] <rsalveti> we = me + awe_
[13:55] <pitti> 13:30?
[13:55] <pitti> err, 14:30
[13:55] <sergiusens> pitti: boiko rsalveti do 14:30 and make it 30'
[13:55] <pitti> 30 mins ought to be enough, yes
[13:55] <boiko> sergiusens: deal!
[13:55] <rsalveti> yeah, 13 utc would be fine as well
[13:56] <boiko> salem_: ^
[13:56] <sergiusens> pitti: can you invite me please as well?
[13:56] <asac> rsalveti: xcan you please decide to move the stand up to hangout? :)
[13:56] <rsalveti> asac: why?
[13:56] <rsalveti> asac: we don't want you there
[13:56] <sergiusens> asac: doesn't work on ubntu arm
[13:56] <rsalveti> asac: otherwise the meeting will take at least one hour
[13:56] <sergiusens> lol
[13:56] <rsalveti> lol
[13:56] <ogra_> asac, nooooo
[13:56] <ogra_> please no hangouts
[13:57] <ogra_> we have a hard enough time to understand each other through our bad internet lines with mumble already
[13:57] <rsalveti> yeah, mumble seems fine :-)
[13:57] <asac> i want to hop in from time to time... otherwise you dont give everyone a fair chance to get to know me :)
[13:57] <ogra_> hagouts just make the voice quality worse
[13:57] <asac> and wee all know how much people miss
[13:57] <pitti> rsalveti, sergiusens, boiko: changed to Tue 14:30 UTC
[13:57] <ogra_> way to high bandwith usage and bad tone
[13:58] <ogra_> asac, jump into mumble then :)
[13:58] <asac> ... their lifes are basically useless without me :)
[13:58] <sergiusens> rsalveti: I like the idea of asac on top of others instead of me from time to time :-)
[13:58] <asac> everybody sees that in retrospect :-P
[13:58] <asac> lol
[13:58] <asac> lol
[13:58] <rsalveti> lol
[13:58] <asac> yeah... might divert some energy too
[13:58] <rsalveti> friday's joy
[13:59] <rsalveti> it's it beer'o clock already?
[13:59] <ogra_> it is always beer o'clock on the interwebs !
[13:59] <asac> i am thinkinga bout starting with whisky soon. had no time to buy new beer
[13:59] <pitti> asac: as the QA overlord^H^H^H^Hseer, do you want to join the ubuntu phone-app testing meeting?
[14:00] <pitti> asac: ah, I just sent you an invite; if you don't want to join or have no time, that's fine
[14:00] <awe_> rsalveti, context?
[14:00] <ogra_> awe_, lots of :P
[14:01] <awe_> ogra_, summary? ;)
[14:01] <ogra_> dunno, i dont have it :)
[14:01] <ogra_> (its friday ... )
[14:01] <rsalveti> that's a good start
[14:01] <rsalveti> awe_: phone-app testing discussion
[14:01] <awe_> ah cool
[14:04] <asac> pitti: when is that>?
[14:04] <asac> now
[14:04] <asac> ?
[14:05] <pitti> asac: next Tuesday at 16:30
[14:05] <asac> ah cool
[14:08] <asac> ogra_: on todays image is the OSK keyboard usable?
[14:08] <asac> e.g. nicely
[14:09] <asac> when hitting search etc.?
[14:09] <ogra_> it worked fine in the browser
[14:09] <ogra_> let me check the hud
[14:09] <ogra_> asac, yep sereems to work fine
[14:10] <kryl> hi, will you support galaxy note 2? :)
[14:11] <ogra_> kryl, i think the community does already, check the devices wikipage
[14:11] <ogra_> !devices | kryl
[14:17] <kryl> apparently it's too bugged :)
[14:17] <kryl> woops
[14:17] <kryl> but thank you
[14:17] <kryl> & good luck !
[14:23] <asac> ogra_: if i get a bzImage or uImage ... how do i get that used for boot?
[14:23] <asac> apw is giving me some binary ... guess we would like to know what form the binary should at best be
[14:23] <asac> in
[14:24] <ogra_> zImage works, neither of the others will
[14:24] <asac> and how to install it (so i can fall back at best)
[14:24] <asac> apw: so zImage it seems
[14:24] <asac> ogra_: what do i do once i have it?
[14:24] <ogra_> asac, flash-touch-kernel /path/to/zImage
[14:24] <ogra_> on the debice
[14:24] <ogra_> *device
[14:25] <apw> ogra_, i thought we could install kernels now we have flipped
[14:25] <asac> nice
[14:25] <ogra_> if you cant boot, you have to take a boot.img and update it with abootimg and then flash it with fastboot in bootloader mode
[14:25] <asac> apw: so i have now set mem=512m ... or shall i use mem=!512m or something?
[14:25] <asac> ogra_: hmm... i gyuess i want to copy off my images before then
[14:25] <apw> asac, with my patch mem=!512m, the ! prefix says zap any existing memory
[14:26] <ogra_> asac, thats a bit more tricky: dd if=$(find /dev -name "*boot*"|grep disk| head -1) of=boot.img
[14:27] <rsalveti> asac: remember that we usually don't have real 512m in a 512m based device :-)
[14:27] <ogra_> that should make a backup of your boot.img on maguro
[14:27] <asac> apw: nice
[14:27] <asac> rsalveti:  i know
[14:27] <rsalveti> afaik I had 380mb with galaxy s
[14:27] <asac> i asked richard to guess me examples of 512m SoCs
[14:27] <asac> so i can check what real GPU values we have
[14:27] <asac> i jst wanbt to see what happens with real 512m :)
[14:28] <asac> then with 386 or sometihng
[14:28] <asac> or 450'ish for 64m GPU
[14:28] <asac> man my typing needs serious fix :)
[14:30] <apw> asac, i doubt very much we will find a real system with less that 512 thees days
[14:31] <apw> achiang, http://people.canonical.com/~apw/maguro-saucy/linux-image-3.0.0-3-maguro_3.0.0-3.11~maguro201307191525_armhf.deb should contain the kernle image you wanted
[14:31] <apw> if you dpkg-deb -x that you shoudl find it in /
[14:31] <apw> if you dpkg-deb -x that you shoudl find it in /boot
[14:31] <asac> yeah thanks
[14:31] <asac> oh thats not my kernel?
[14:32] <asac> apw: did you mean achiang ? or <tab> typo?
[14:32] <ogra_> asac, file a bug that initramfs-tools-ubuntu-touch should ship a kerne/postinst,d snippet that calls flash-touch-kernel .... i'll get to it then
[14:32] <apw> i meant asac
[14:32] <nicenslow> can u pleasse redo your conversation ...i just joined  :D
[14:32] <asac> :-P
[14:32] <ogra_> that way dpkg should just work
[14:32] <ogra_> (we dont use debs at all for kernels, so i didnt find that to important)
[14:32] <nicenslow> ....and i got an N4 ,, yey ! ! ! ! !
[14:33] <asac> ogra_: so i just copy boot/vmlinuz-3.0.0-3-maguro over? run flash-touch-kernel and then set the mem=! argument?
[14:33] <ogra_> asac, grab andys deb and install it, via adb (we ship wget on the image)
[14:34] <ogra_> then just flash-touch-kernel /boot/vmlinuz.....
[14:34] <ogra_> (with the full filename indeed)
[14:34] <asac> apw: ogra_: so i have this now: http://paste.ubuntu.com/
[14:35] <asac> http://paste.ubuntu.com/5890968/
[14:35] <asac> that looks good?
[14:35] <ogra_> nicenslow, http://irclogs.ubuntu.com/2013/07/19/%23ubuntu-touch.txt ;)
[14:35] <asac> ogra_: i just copied the vmlinuz over and used your command to flash
[14:35] <asac> flash-touch-kernel /tmp/vml*
[14:35] <nicenslow> tnx!!
[14:35] <ogra_> ah, good
[14:36] <ogra_> asac, if andys patch works i'd say thats right :)
[14:36] <asac> ogra_: how can i turn off swap?
[14:36] <ogra_> remove it from fstab
[14:36] <ogra_> just comment the line
[14:36] <asac> just remove from fastab?
[14:36] <asac> yeah
[14:36] <asac> ok :)
[14:36]  * ogra_ is curious, expects that to completely break
[14:37] <ogra_> :)
[14:37] <asac> ok lets see :)
[14:37] <asac> i have low hopes
[14:37] <nicenslow> hmmm interesting...
[14:37] <nicenslow> so does anyone want to learn anything new today..or shall i go to a different room then ?
[14:38] <nicenslow> Good
[14:38] <nicenslow> I like discipline
[14:38] <nicenslow> im here to learn too ....
[14:38] <nicenslow> who's teachin n what
[14:38] <nicenslow> ?
[14:38] <mhr3> lool, did you have a chance to draft the spec?
[14:38] <nicenslow> o.0
[14:39] <nicenslow> bugger ...
[14:39] <popey> nicenslow: people are working here, what's up?
[14:40] <asac> apw: i hav:
[14:40] <asac> console=ttyFIQ0 androidboot.console=ttyFIQ0 mem=1G vmalloc=768M omap_wdt.timer_margin=30 no_console_suspend mem=!768m androidboot.serialno=0146B06319004015 androidboot.bootloader=PRIMELC03 androidboot.baseband=I9250XXLJ1 lcd_bootfb=0xbea70000 mms_ts.panel_id=18 androidboot.macaddr=
[14:40] <asac> apw: and see even more than before in free
[14:40] <asac> like 711m now
[14:40] <asac> odd
[14:41] <nicenslow> okey..sorry guys ... :)    but All the Best! Uall'r doing a great job.. :) Bye.
[14:41] <asac> apw: i have:
[14:41] <asac> Linux ubuntu-phablet 3.0.0-3-maguro #11~maguro201307191525 SMP PREEMPT Fri Jul 19 14:25:39 UTC 2013 armv7l armv7l armv7l GNU/Linux
[14:41] <asac> not sure if thats correct
[14:41] <apw> looks believeable
[14:41] <apw> as i say i don't have the h/w to test it myself
[14:41] <asac> apw: that build id looks like yours?
[14:41] <doanac> asac: looks like all the jobs held up this morning because phablet-flash hit an error downloading the image. I had to delete the file it tried by hand to get things to recover
[14:42] <asac> ok let me tune it further down
[14:42]  * ogra_ curses ... the dash just hung my chromebook
[14:42] <apw> asac, yes that build id is mine
[14:42] <doanac> is there any sort of publishing timing related issue that could cause that?
[14:42] <asac> doanac: yeah that was my reading from the log
[14:42] <asac> doanac: people just dont trust me'
[14:42] <sergiusens> asac: doanac butt he other jobs aren't using --pending
[14:42] <ogra_> and i cant reboot it bceause i will loose my livebuilder test setup :(
[14:42] <asac> apw: ok let me go further down... can i also tune vmalloc? or are you sure it has nothing to do with what i see in free?
[14:42] <apw> vmalloc has nothing to do with memory
[14:42] <asac> doanac: right. your  jobs are not using --pending ... only the autopilots (default doesnt()
[14:43] <apw> it has everything to do with space for mappings
[14:43] <apw> asac, i will put some debug in this thing and make sure it has seen your command line right
[14:43] <doanac> asac: right. the original smoke jobs paul did need "--pending"
[14:43] <doanac> i've got to figure out how to update his stuff today
[14:43] <asac> apw: right. thanks... botting with 512m lets see
[14:43] <asac> doanac: yeah not big trouble. we just want good results for autopilots for now
[14:44] <asac> good and true
[14:44] <asac> apw: it works
[14:44] <apw> it works ?
[14:44] <doanac> asac: we are starting to bring things to life. mako is stuck in jenkins and we are trying to figure out how to get a new job running for it
[14:44] <asac> apw: http://paste.ubuntu.com/5891001/
[14:44] <asac> yeah :)
[14:44] <asac> ncie
[14:44] <asac> and the ui is even usable
[14:44] <ogra_> start an app
[14:44] <asac> sure :)
[14:45] <apw> achiang, ok good
[14:45] <asac> all we need is that each app alone can run
[14:45] <asac> because second aps will be killed by lifecycle under memory pressure
[14:45] <asac> thats were tvoss comes in to make that fast and furious
[14:45] <ogra_> asac, so start with the worst and take a picture
[14:45] <ogra_> the camera app needs the most ram afaik
[14:46] <asac> ogra_: works just great
[14:46] <asac> nice and snappy
[14:46] <ogra_> nice !
[14:46] <ogra_> and pretty unbelivable
[14:46] <asac> wow its 250m in buffer still
[14:46] <asac> we have lots of space
[14:46] <asac> let me go for 386m
[14:46] <asac> thats probably the real goal for 512m SoCs anyway
[14:46] <ogra_> lets ship postgres then !
[14:46] <asac> OOO
[14:46] <asac> will come
[14:46] <ogra_> :)
[14:46] <asac> will come
[14:46] <asac> :)
[14:46] <asac> strongly
[14:46] <ogra_> lol
[14:47] <popey> how do I get rid of sample content from the phone easily?
[14:47] <popey> i.e. all the video/music icons
[14:47] <asac> it will be epic
[14:47] <asac> i start now with 386m
[14:47] <ogra_> popey, uninstall the demo-assets packages ?
[14:47] <popey> ta
[14:47] <asac> let me reboot :)
[14:47]  * ogra_ never tried
[14:47] <asac> cross your fingers
[14:48] <asac> if so we just mke lifecycle work, make compressed mem
[14:48] <asac> and then we are great
[14:48] <ogra_> compressed mem ?
[14:48] <asac> i assume gallery will be tricky and needs to be made memory smart
[14:48] <asac> like with ashmem
[14:48] <asac> tvoss_: ^^
[14:48] <asac> shell is up
[14:48] <ogra_> asac, that will eat performance
[14:49] <asac> wow with 145m buffer still
[14:49] <asac> we have lots of space
[14:49] <asac> and qt is alreadyu in mem
[14:49] <ogra_> asac, dont forget we're losing ~10% performance soon
[14:49] <tvoss_> asac, I would actually not use ashmem for that, but a pinned memory pool that we grant to the foreground app
[14:49] <lool> mhr3: sorry, no, but I'm on it  :-)
[14:49] <asac> tvoss_: well the concept of volatile mem i refer to
[14:49] <asac> whatever is easiest to get
[14:49] <tvoss_> asac, fair :)
[14:50] <mhr3> lool, np, could you just ping me and mfisch when it's up
[14:50] <lool> mhr3: yeah
[14:50] <mhr3> or you know... send a mail :)
[14:50] <ogra_> just keep an eye on performance, really :) the next architecture switch we do will be costly in that regard
[14:50] <asac> with camera on 386m: http://paste.ubuntu.com/5891012/
[14:50] <mfisch> mhall119: sorry when what's up?
[14:50] <lool> mhr3: I'll just fax it to you
[14:50] <mfisch> err, mhr3 ^^^
[14:50] <asac> i think we should really shoot for 200m :)... otherwise we run out of goals
[14:51] <mhr3> lool, awesome, and beep my pager when you fax it :P
[14:51] <asac> apw: do you think free could lie to me?
[14:51] <asac> and that we use memory not seen there? i guess not :)
[14:51] <mhr3> mfisch, the spec i mentioned 5minutes ago
[14:52] <asac> apw: can we land that fix so i can get devices that run 386m in the lab?
[14:52] <asac> :)
[14:52] <nicenslow> _|_
[14:52] <asac> apw: not super urgent, we probably would have to buy devices anyway first
[14:52] <asac> jsut wonder how hacky you did it
[14:52] <asac> and if we could even ship this in our real kernel to avoid having duplicated binaries
[14:52] <apw> asac, it is a small patch and applied to 3.0 and 3.4
[14:53] <nicenslow> Code this onto welcome screen " _|_"
[14:53] <apw> asac, can you file a bug against linux-maguro for this pls (i'll add the other tasks) so i have somethign track it with, ta
[15:01] <ogra_> asac, our minimal target is 512 though, why go below with the tests ?
[15:01] <asac> apw: can you guess whether PVR allocates its memory from the memory pool that i see in free?
[15:02] <asac> ogra_: i thought that a 512m SoC ... has 128m GPU and that eats from mem
[15:02] <asac> so i think i should run with mem=386m
[15:02] <asac> let me know if thats incorrect :)
[15:02] <ogra_> asac, but it will still do that when you use mem=512m
[15:02] <asac> ogra_: no ... if i start like that i get a free 510+ M
[15:03] <asac> so you say the GPU will be part of what i see there?
[15:03] <asac> then yes, weshould start with 512m
[15:03] <ogra_> so nopw you set 386-$(whatever the kernel decides to calim for gpu)
[15:03] <asac> lets wait for rsalveti, i think he knows the details and variants from a GPU driver dev pov
[15:03] <ogra_> well i would expect that to happen
[15:03] <asac> i guess might even be driver specific
[15:03] <asac> lets wait
[15:04] <ogra_> i.e. ducati on omap (maguro) lives in a memory hole
[15:04] <asac> so one indication that it takes the memory from what i use in mem=...
[15:04] <asac> is that i now with very low mem i see stuff like:
[15:04] <ogra_> if your max limit goes below that the hole wont move
[15:04] <asac> [  819.913970] PVR: ShrinkPagePool: Pages in pool after scan: 356
[15:04] <asac> [  819.945068] PVR: ShrinkPagePool: Number to scan: 128
[15:04] <asac> [  819.945129] PVR: ShrinkPagePool: Pages in pool before scan: 356
[15:04] <asac> [  819.945495] PVR: ShrinkPagePool: Pages in pool after scan: 228
[15:04] <asac> [  819.987945] PVR: ShrinkPagePool: Number to scan: 128
[15:04] <asac> [  819.987976] PVR: ShrinkPagePool: Pages in pool before scan: 228
[15:04] <asac> [  819.988220] PVR: ShrinkPagePool: Pages in pool after scan: 100
[15:04] <asac> and stuff gets slower - without an oops
[15:04] <asac> err oom
[15:04] <asac> ogra_: i see
[15:04] <ogra_> at least if you test on maguro you would have to move the mem hole alongside
[15:05] <asac> still doesnt tell me what to set mem=512m to if i want to mimic a typical 512 SoC
[15:05] <ogra_> does video playback work ?
[15:05] <asac> guess its not easy :)
[15:05] <asac> atm its super slow ... browser made PVR resize all mem it seems
[15:05] <asac>  :)
[15:05] <ogra_> heh
[15:05] <ogra_> no surprise :)
[15:05] <asac> that supports the theory that pvr takes out of the main mem
[15:06] <asac> robclark is not here :)
[15:06] <ogra_> it does, but that shouldnt do harm ... ducati will be broken i guess so video playback might get confused
[15:06] <ogra_> no, he is fedora now
[15:06] <asac> is there a video to watch on the device?
[15:06] <ogra_> and i doubt he still touched omap much :)
[15:06] <ogra_> yeah
[15:06] <ogra_> try sintel
[15:07] <ogra_> the first one in the video lens
[15:07] <sergiusens> asac: yes, the three frist ones on the video lens
[15:07] <sergiusens> *first
[15:07] <asac> ogra_: video works like a charm with 386m
[15:07] <asac> and doesnt eat much
[15:07] <ogra_> ok
[15:07] <asac> so seems that s outside
[15:07] <ogra_> yeah
[15:07] <asac> or just not that big of a buffer
[15:08] <ogra_> i would suspect it even ignores mem
[15:08] <asac> browser was the only app that went bazuka
[15:08] <ogra_> *mem= that is
[15:08] <ogra_> since it has a fixed memory space assigned
[15:08] <ogra_> in the binary driver
[15:08] <asac> ok ... so what does dashboard say?
[15:08] <asac> any news?
[15:08] <asac> no news == good news?
[15:08] <asac> its getting late :)
[15:08] <ogra_> the logs still show it runs without --pending
[15:09] <apw> ogra_, mem is cumulative before my patching so it doesn't work 'before' for sure, asac's testing shows it does limit kernel use of the memory, pvr who knows
[15:09] <ogra_> so i dont expect something to change
[15:09] <asac> pvr might also be just super buggy and do unreasonable things :)
[15:09] <asac> like not living in main memory, but tryuing scale based on main memory pressure
[15:09] <ogra_> apw, right, on pandas we needed to keep a memory hole because ducati (the media blob) had a fixed area of the ram assigned
[15:10] <ogra_> and iirc on pandas that starts at 512M
[15:10] <ogra_> (the hole)
[15:11] <ogra_> the maguro is pretty much a panda ... except that it isnt :)
[15:15] <cyphermox_> how can I modify init.tuna.rc for the android container from the phone?
[15:15] <cyphermox_> if I modify it, it gets back to the original on reboot or whatever
[15:15] <ogra_> cyphermox, did you read my mail about the container flip ?
[15:15] <cyphermox> ogra_: which one?
[15:15] <ogra_> it has detailed instructions for all such stuff
[15:16] <cyphermox> ok
[15:16] <cyphermox> I'll look
[15:16] <ogra_> went to -phone as well as -devel
[15:16] <ogra_> ("Ubuntu runs on top of android")
[15:20] <davmor2> popey, ogra_: are you devices registering a charge?  Mines been on charge for an hour and still say 29%  maguro that is
[15:20] <apw> asac, did i miss that bug number ?
[15:20] <ogra_> davmor2, i didnt check today, it usually does
[15:21] <asac> apw: sorry. wanted to say that i was trying to get this on your list through first finding consent amongst management that we should adjust the way we plan to go about memory budgeting
[15:21] <popey> davmor2: i log my battery state with a script
[15:21] <davmor2> ogra_, popey: nevermind it's upto 30 now I switched it to the plugged in charger instead of the one in the pc
[15:21] <popey> davmor2: http://paste.ubuntu.com/5891060/
[15:21] <asac> apw: and hoped that this process will trigger this coming back :) ...
[15:21] <popey> you can see how fast/slow it charges there
[15:22] <popey> well, you can't because it's full :D
[15:22] <apw> asac, given we have already done the owrk, it seems strange to now be asking if we can do the work
[15:22] <stgraber> sergiusens: can we get the new phablet-tools into the archive?
[15:23] <sergiusens> stgraber: certainly, didrocks, can you trigger a daily-release for phablet-tools?
[15:24] <didrocks> sergiusens: sure, any urgency on that one? :)
[15:25] <sergiusens> didrocks: ask stgraber ... but I'm guessing eh wants to publish his blog post on image based updates
[15:25] <didrocks> stgraber: I hope you didn't break it before the week-end!
[15:25] <stgraber> didrocks: I didn't touch the code myself, so no ;)
[15:26] <stgraber> didrocks: anyway, I'm supposed to blog about the --download-image stuff in a couple of hours so it'd be nice if the option actually existed by then ;)
[15:26] <didrocks> stgraber: sergiusens: building
[15:30] <rsalveti> asac: ogra_: maguro uses a fixed memory location and size for gpu/ducati
[15:31] <ogra_> yeah, i suspected so
[15:31] <rsalveti> so we should indeed use something like 380m to "simulate" a 512mb hardware
[15:31] <ogra_> so the 512M might be completely moot
[15:31] <ogra_> even 380M might :)
[15:31] <ogra_> if ducato/gpu can just allocate another 500
[15:31] <ogra_> *ducati
[15:32] <ogra_> (outside of that space)
[15:32] <rsalveti> right, but should already give us an idea of how broken we might be
[15:32] <ogra_> i guess mako testing might be cleverer
[15:33] <rsalveti> ogra_: like manta, has 2gb, but only 1.2gb for userspace
[15:33] <ogra_> yeah
[15:33] <rsalveti> as allocating a 2kx2k texture is not cheap at all
[15:33] <ogra_> we really need to find an arch that doesnt do that if we want to do such tests
[15:33] <ogra_> i know tegra doesnt
[15:34] <ogra_> but no media playback on grouper kind of makes that moot
[15:34] <rsalveti> yeah, will look on that soon
[15:34] <ogra_> tegra actually works pretty similar to intel here
[15:35] <ogra_> it will snip off from available ram
[15:38] <cyphermox> awe_: I was looking at the wikipedia pages, the Nexus 4 and Galaxy Nexus mention at least Bluetooth 3.0, and possibly 4.0 compatibility (for the gnexus)
[15:39] <cyphermox> Nexus 7 just mentions Bluetooth 3.0
[15:39] <cyphermox> I know wikipedia is a doubtful source, but it's encouraging at least ;)
[15:42] <awe_> cyphermox, yea just looking at the page too.  The big thing is that we currently only support BT3.0, not BT3.0+HS
[15:42] <awe_> I'm not sure if Android supports BT3.0+HS either...
[15:42] <cyphermox> awe_: bluez has +hs
[15:43] <awe_> bluez will route data over wi-fi?
[15:44] <cyphermox> awe_: I have no idea I never tried
[15:45] <w-flo> asac et al, just scanned the backlog.. my 512m device shows about 380m in free, so at least for my device, the GPU mem is not even visible to linux i guess
[15:45] <awe_> cyphermox, I think we should figure that out then.  ;)-
[15:48] <w-flo> 362MiB even
[15:49] <mfisch> lool: I'm going to merge my notes in with your doc
[15:55] <cyphermox> rsalveti: sergiusens: either of you have a prebuilt copy of brcm_patchram_plus for android?
[15:56] <rsalveti> cyphermox: yup, got the one built for grouper
[15:56] <rsalveti> would that be fine?
[15:57] <ogra_> did we ever remove it from the archive ?
[15:57] <ogra_> should still be in universe, no ?
[15:57] <ogra_> oh, wait, for android
[15:57] <ogra_> ignore me :)
[15:59] <rsalveti> cyphermox: if so, http://people.canonical.com/~rsalveti/brcm_patchram_plus
[15:59] <cyphermox> rsalveti: yeah, that would be great
[16:01] <cyphermox> rsalveti: thanks, looks good
[16:02] <ogra_> cyphermox, if you want to use it, put a  line that copies it in place in the pre-start script of the container (one level up from the override dir where you need to put your init.rc change)
[16:03] <cyphermox> ogra_: nah it's good, I just drop it in /system/bin
[16:03] <ogra_> wont work
[16:03] <ogra_> oh, system might actually
[16:03] <ogra_> matter of luck
[16:03] <cyphermox> yeah, it works
[16:03] <ogra_> great
[16:03] <cyphermox> I just remount it rw
[16:03] <didrocks> sergiusens: stgraber: built and copied to proposed!
[16:04] <ogra_> yup
[16:08] <stgraber> didrocks: thanks!
[16:08] <didrocks> yw ;)
[16:44] <topscrets> the UT is working on i9100 ?
[17:08] <Chocanto> mhall119: Hey ! :) Is it possible to make a special bazaar serie for the poppler-qml-plugin ? https://code.launchpad.net/ubuntu-docviewer-app
[17:10] <mhall119> Chocanto: sure
[17:10] <Chocanto> mhall119: thank you :)
[17:12] <mhall119> Chocanto: if you have a branch already, can you push it to lp:~ubuntu-docviewer-dev/ubuntu-docviewer-app/poppler-qml-plugin
[17:13] <Chocanto> mhall119: Yes I just created this branch ^^
[17:13] <mhall119> thanks, set that as the series' development focus
[17:14] <asac> tvoss_: you think you got the osk stuff under control?
[17:15] <Chocanto> mhall119: who ? Me ?
[17:21] <Chocanto> mhall119: Oh and the RC version of poppler is out... maybe they will make an RC package.. maybe...
[17:22] <mhall119> Chocanto: I've asked tsdgeos to make us a .deb package of either 0.23.3 or 0.23.4
[17:22] <Chocanto> mhall119: Yes, by mail ?
[17:33]  * cyphermox -> lunch
[17:46] <stgraber> sergiusens: hey, did you say you tested that recovery change from last night?
[17:47] <stgraber> sergiusens: I'm not sure how it ever worked ;)
[17:47] <stgraber> sergiusens: anyway, can you commit: http://paste.ubuntu.com/5891515/
[17:48] <sergiusens> stgraber: I did, I could go to recovery without dying, but didn't do too much testing afterwards, stuck in the _can't release anything_ loop
[17:48] <stgraber> COMMAND_FILE was wrong with the previous commit, so the upgrader is essentially broken in the current recovery images, so we need that fixed before I can get anyone to really use this (as the current recovery is broken people won't be able to update to the fixed one...)
[17:48] <stgraber> lool: ^
[17:48] <sergiusens> stgraber: hmmm,from your patch it seems I tested it wrong
[17:49] <stgraber> lool: I'll have to delay the blog post until we have that fix landed and new images published as anyone who updated to today's image will need to manually reflash the recovery partition :(
[17:49] <sergiusens> stgraber: there is no today's image
[17:49] <sergiusens> stgraber: we are stuck on a current from 5 days ago
[17:49] <lool> stgraber: oh wow
[17:50] <stgraber> sergiusens: we don't use current for system-image (yet)
[17:50] <lool> stgraber: that's kind of the worst bug possible
[17:50] <sergiusens> stgraber: recovery is also using system image updates?
[17:51] <stgraber> sergiusens: yeah, as soon as you trigger the recovery, it'll flash the latest android build which includes the broken recovery image :(
[17:51] <lool> stgraber: I'm a bit worried that we wont have you long enough next week to send the blog post out
[17:51] <stgraber> lool: well, if we hurry we can still do it today
[17:51] <lool> sergiusens: so we have no problem building a new image and leaving it as /pending?
[17:51] <lool> stgraber: yeah exactly
[17:52] <lool> stgraber: did you upload the fix
[17:52] <stgraber> lool: I just need sergiusens to review that change, land it, build android (takes around an hour), then rebuild an image on nusakan and have that publish to system-image
[17:52] <lool> ah sorry saw the paste
[17:52] <stgraber> should take 2-3 hours in total
[17:52] <canurabus> Hey all. I just bought a Nexus 4 and wanted to run Ubuntu Touch along side Android... (I'm interested in developing apps for Touch). I don't see a way to do though... is it possible?
[17:52] <sergiusens> stgraber: but the phablet-flash tool flashes from recovery from current
[17:53] <sergiusens> stgraber: do you overwrite that afterwards?
[17:53] <stgraber> lool, sergiusens: FWIW, I'm planning to change my cdimage importer to only import tested ("current") images but I need at least one of those to bootstrap the process and as you pointed out, the last 5 days have been bad ;)
[17:53] <stgraber> sergiusens: yes
[17:53] <stgraber> sergiusens: the mako-* file contains a recovery image which is flashed by the upgrader
[17:53] <stgraber> so the initial bootstrap works, any update after that doesn't
[17:53] <lool> stgraber: why did my upgrade work?
[17:53] <sergiusens> stgraber: ah, so anything I would of done would of been incomplete without an updated image... or I need to figure out how to create those images to test properly
[17:54] <stgraber> lool: you were upgradeing from 20130714 (working upgrader) to 20130715 (broken upgrader), so you're now stuck
[17:54] <sergiusens> lool: because the first recovery used is from cdimage perhaps?
[17:54] <lool> yeah maybe
[17:54] <lool> well no
[17:54] <lool> I rebooted into the new system, then download an update today
[17:54] <lool> ok
[17:55] <lool> Kind of a big regression, damn
[17:56] <lool> sergiusens: Could you commit + launch a build of the android images now?  I'm afraid stgraber goes on leave tonight and is the only one able to confirm 100% sure that it's fixed
[17:57] <stgraber> sergiusens: oh and once we get the new recovery images, I'm going to promote those to current (just the recovery images, nothing else) so that we do the bootstrap with the latest version, as the current one really sucks (doesn't clean after itself, doesn't do GPG, ...)
[17:58] <asac> stgraber: hey... did you check infrastructure impact for system image updates?
[17:58] <asac> and talk to infra folks what it takes to easily enable developer mode?
[17:59] <asac> btw, is there a command to enable dev mode (e.g. bring back apt etc.)?
[17:59] <sergiusens> stgraber: android build will take 10' this time
[17:59] <lool> asac: we have this on the TODO, but it's not critical for today
[17:59] <sergiusens> asac: doanac and I are going to discuss on Tuesday
[17:59] <sergiusens> asac: as well as click
[17:59] <asac> lool: yeah. just wanted to check if he did it anyway because my brain wants facts to continue thinking :)
[17:59] <lool> sergiusens: would you invite me?
[18:00] <asac> sergiusens: sounds good. so seems you are on top on what stgraber did
[18:00] <asac> good
[18:00] <sergiusens> lool: as soon as I get the invite, if you are not there, I will forward <- doanac
[18:00] <stgraber> asac: I found a few issues that sergiusens fixed which should get me past the first failure I got on Wednesday, after that, I should just have to add a "touch /userdata/.developer_mode && reboot" to the test tool which should bring us to something similar to current flipped where the tests should work
[18:00] <doanac> sergiusens: ah - i'll create an invite. sorry
[18:01] <doanac> lool: i'll add  you as well
[18:01] <asac> stgraber: that sounds good... we should make a very simple command line soon through, so we dont end up with many places with diverging code how to do that :)
[18:01] <sergiusens> stgraber: I'm sure we want to be able to test the image without leaving developer mode in some way
[18:01] <stgraber> asac: yeah, it's expected to get into system-image-cli at some point but it's not very high on barry's todolist
[18:01] <lool> asac: touch path seems pretty simple?  :)
[18:01] <asac> sergiusens: thast later
[18:01] <asac> we start with what we have
[18:01] <asac> land without breakage with dev mode etc.
[18:02] <stgraber> sergiusens: yeah, we do, any test done in developer mode will be pretty much meaningless but apparently having Jenkins be all green is more urgent than having that mean something ;)
[18:02] <sergiusens> asac: yeah, we are meeting to discuss the strategy, I like progressing in iterations and not one big sweep :)
[18:02] <asac> stgraber: if its easy we should do that first and quick.... its lots of follow up costs at stake if we start coding manual hackery on how to do that in our various infrastructure issues...
[18:02] <asac> anyway... not short term
[18:02] <asac> just REMEMBER :)
[18:03] <asac> or shortterm
[18:03] <asac> lool: then we could ship a wrapper to just do that and that can be improved..
[18:03] <sergiusens> stgraber: http://<IP_ADDRESS>:8080/job/ubuntu-touch-image/51/
[18:03] <stgraber> sergiusens: thanks!
[18:03] <asac> lool: means we need to at least touch infra one time less >:)
[18:03] <sergiusens> stgraber: I can kick off a cdimage build (I now have privs) once that's done
[18:03] <asac> anyway .. wont disturb more on friday
[18:03] <asac> otherwise we will work on sunday still
[18:04] <asac> (and i have to do slides at some point)
[18:04] <sergiusens> asac: slides are for sunday evenings ;-)
[18:04] <stgraber> sergiusens: nah, I'll do it, I have to hack the symlinks and system-image on nusakan anyway
[18:04] <lool> haha
[18:04] <sergiusens> stgraber: ack
[18:06] <sergiusens> stgraber: so far so good From git://phablet.ubuntu.com:9419/CyanogenMod/android_bootable_recovery
[18:06] <sergiusens>    160b342..c6622e0  phablet-10.1 -> phablet/phablet-10.1
[18:06] <sergiusens> c6622e0 is the hash for the commit btw
[18:16] <stgraber> sergiusens: wow, that thing really builds quickly now!
[18:17] <sergiusens> stgraber: I did a no clobber
[18:17] <sergiusens> stgraber: I do it when I know there will be no issues
[18:19] <stgraber> cool. Anyway, tested on mako and it works, so triggering a touch build now
[18:28] <om26er> wow what the... http://www.ubuntu.com/ is back to the charm thing :O
[18:34] <lool> stgraber: \o/
[18:35] <Chocanto> om26er: Yes, I saw it... why ? x)
[19:05] <rtg_> rsalveti, re: bug #1202887. Is that really a bug ? It seems to me that the container is correctly restricting the thread's ability to change caps.
[19:06] <rsalveti> rtg: the inside the container gets desired caps, as android's limit is 40 40 by default, the issue is just when we're starting something from ubuntu, which talks to the container
[19:06] <rsalveti> rtg: then binders tries to increase it's priority, and fail
[19:06] <rsalveti> because in ubuntu we're just using 0 0 (20 20) by default
[19:07] <rsalveti> that's why this connects with whatever we want to allow and do regarding binder
[19:10] <nhaines> Does anyone know how Ubuntu Touch is going to be branded, on the phone for example?  Are we going with just "Ubuntu Touch", "Ubuntu for Phones", etc?  I presume we'll have Ubuntu Phone 13.10 and so on.
[19:11] <pmcgowan> I think for the distro we stay with Ubuntu Touch, and yes there will be 13.10 version
[19:21] <linuxperia> Hi. I am a big Fan of Ubuntu Linux and a Long Year user/coder/developer since "Ubuntu Warty Warthog". I buyed recently the Android 2.2 Smart Watch Phone "Z1"
[19:21] <linuxperia> http://www.youtube.com/watch?v=stRX0URpSkw and want now to port Ubuntu Linux to this Smart Watch Phone as i use on all my other Devices Ubuntu too.
[19:21] <linuxperia> Would like to ask if anybody with experience is willing to assist, advice and help with Porting Ubuntu Linux to this great Mobile Smart Watch Phone. I have experience with porting Linux OPIE to Sony Ericsson Xperia Mobile Phones including Cross Compiling the Linux Kernel.
[19:21] <linuxperia>
[19:29] <ZDmitry> balloons, ping
[19:29] <balloons> ZDmitry, pong
[19:32] <ZDmitry> balloons, latest changes in UbuntuSDK API broke autopilot tests for the terminal. I fixed that. But pushed fixes to the same branch which is on hold.
[19:32] <ZDmitry> Branch: https://code.launchpad.net/~hiroshidi/ubuntu-terminal-app/autopilot-header-and-settings/+merge/172287
[19:32] <balloons> ZDmitry, what do you mean on hold? ahh let me look
[19:33] <balloons> ZDmitry, it looks good now.. everything pases
[19:33] <balloons> are the tests all working locally?
[19:34] <davmor2> popey: on todays image if you open the terminal can you get the esc bar up from the options menu at the bottom?
[19:35] <davmor2> popey: panels is the word I'm after
[19:42] <ZDmitry> balloons, all the tests locally works fine except one: 'test_color_scheme_changes'. But I can't find failure reason. The 'test_font_size_changes' test is similar and uses database too but it is passes with 'OK'. This is bit strange.
[19:46] <ZDmitry> balloons, about remote test. Seems there were missing dependencies, but that was fixed today: https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1202351
[19:47] <balloons> ZDmitry, awesome for fixing the dependencyu
[19:47] <balloons> ZDmitry, let me try running the tests locally to see what you mena
[19:49] <balloons> ZDmitry, I got one error.. MismatchError: 'Linux' != u'BlackOnLightYellow'
[19:50] <ZDmitry> balloons, yes.
[19:53] <ZDmitry> ballons, I'll try the same test manually, with fetching records from local storage using sqlite3.
[19:53] <chris123> is there not a daily anymore?  i have only got an update every few days now when i do "phablet-flash"
[19:53] <popey> yes, there is
[19:53] <popey> but we haven't put out one for a couple of days while some fixes are being done
[19:54] <chris123> ok.  glad that the phablet-tools update didnt break me or something silly like that
[19:59] <balloons> ZDmitry, ok, I'll hold off for a minute then
[20:07] <cyphermox> rsalveti: hey, did you look at my code for brcm_patchram_plus?
[20:07] <cyphermox> I tried to add the binary on my phone on the android container and run the old service definition from there, but even that doesn't work :(
[20:07] <rsalveti> cyphermox: sorry, not yet, in firefighing mode still
[20:07] <rsalveti> will try to take a look later today
[20:12] <asac> bfiller: the results that came out of dashboard look worse
[20:12] <asac> fginther: ^^
[20:12] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/image/3073/
[20:12] <asac> on mako
[20:12] <asac> doanac is also checking on his side, but i think more perspectives might help here
[20:12] <asac> (as there were passed tests,...)
[20:13] <bfiller> asac: working on browser tests failures
[20:13] <doanac> asac: sorry i started the question in #phablet
[20:13] <asac> ah ok
[20:13] <doanac> i'll copy/paste to here
 bfiller: starting to triage mako test results. the notes-app went from 18/19 yesterday to 4/19. Trying to see if something obvious went wrong:
 todays: https://jenkins.qa.ubuntu.com/job/saucy-touch-mako-smoke-notes-app-autopilot/14/consoleFull
 yesterdays: https://jenkins.qa.ubuntu.com/job/saucy-touch-mako-smoke-notes-app-autopilot/13/consoleFull
[20:13] <bfiller> doanac: nothing has changed in the code between yesterday and today, so don't know
[20:13] <bfiller> doanac: I'll run latest and try
[20:18] <fginther> doanac, do you know where I can find the actual results from the autopilot tests?
[20:18] <doanac> fginther: we currently just show them in that console log
[20:18] <doanac> i know that sucks
[20:19] <doanac> its just the best i could get
[20:25] <fginther> doanac, no worries, just wanted to check
[20:29] <ZDmitry> balloons, self.autopilot.pointing_device.click_object()  preform click in centre of selected item or in nearest pixel? I have feeling that emulator preform click in wrong area.
[20:30] <balloons> ZDmitry, should be the center of the object.. you feel like there is a bug?
[20:35] <ZDmitry> balloons, I prefer that it'll be only my feeling. So until anybody else get this bug I should search for mismatch in my tests.
[20:35] <balloons> ZDmitry, which testcase is causing it?
[20:35] <balloons> ZDmitry, I've seen a weird issue with the back button
[20:38] <ZDmitry> balloons, starting from line 492, def test_color_scheme_changes(self):
[20:40] <ZDmitry> balloons, line 507, self.main_window.click_value_selector_item("liSchemes",scheme) - expanding of list and click on value
[20:41] <balloons> ZDmitry, ok, let me try running just that one
[20:42] <balloons> ZDmitry, well it ran ok
[20:42] <balloons> heh.. doesn't it for you?
[20:44] <ZDmitry>  strange... just some time ago you got error on this test. And I can't pass it.
[20:49] <stgraber> sergiusens: we have a problem... now that we have an up to date recovery which actually checks what's passed to it, I'm getting:
[20:49] <stgraber> Skipping missing file: image-master.tar.xz
[20:49] <stgraber> Unknown command: image-master.tar.xz.asc
[20:49] <stgraber> Skipping missing file: image-signing.tar.xz
[20:49] <stgraber> Unknown command: image-signing.tar.xz.asc
[20:49] <stgraber> looks like the 4 keyring files aren't being copied by phablet-flash
[20:51] <sergiusens> stgraber: can you give me the logs? I did a replica from your pastebin, but I can double check
[20:51] <sergiusens> stgraber: by logs I mean the output from phablet-flash to stdout
[20:51] <stgraber> sergiusens: http://paste.ubuntu.com/5892041/
[20:52] <stgraber> sergiusens: you're missing push for image-master.tar.xz, image-master.tar.xz.asc, image-signing.tar.xz and image-signing.tar.xz.asc
[20:52] <stgraber> which makes the recovery fail immediately as all files after that point are considered as untrusted :)
[20:53] <stgraber> lool: ^ sounds like we'll have to delay that blog post some more... I'll publish tomorrow if we can get a fixed phablet-flash by then
[20:53] <sergiusens> stgraber: where do I get those from?
[20:53] <stgraber> sergiusens: https://system-image.ubuntu.com/gpg/
[20:53] <stgraber> sergiusens: I had code for that in the python script I gave you
[20:55] <sergiusens> stgraber: must of missed it, I see it now  # Grab the latest keyrings
[20:56] <sergiusens> stgraber: let me fix that and get it into the archives asap
[20:56] <stgraber> sergiusens: at least it should be easy to test now as the current recovery images will completely fail without the keyrings ;)
[20:56] <stgraber> unfortunately the version we had until then didn't care about GPG so it went unnoticed (and I didn't see the missing code in the merge request...)
[21:04] <lool> stgraber: it's ok, better to find these now
[21:12] <ZDmitry> balloons, I reverted to previous revision of tests and got 'test_color_scheme_changes' results. Now I can definitely say that something broken with latest updates.
[21:12] <balloons> the sdk updates or?
[21:13] <ZDmitry> yes
[21:16] <ZDmitry> balloons, first of, I got broken toolbar, so I changed deprecated items with new. Then I got broken test for font size changing, which was caused by changed name of thumb item of Slider. I fixed it. But seems this is not the last broken thing.
[21:17] <balloons> ZDmitry, you can keep the old version of the emulator, you don't have to update.. that said, elopio has been diligently working on getting an official version into the sdk.. It comes with tests, so it's proven out, unlike my hackery ;l-)
[21:18] <balloons> ZDmitry, so if my hackery isn't working for you, don't stress about using it.. it seems to run on my box, so I'm not sure what your seeing that I'm not
[21:19] <lool> sergiusens: going off, happy to test new phablet-flash to unbrick  :-)  have a good WE
[21:23] <ZDmitry> balloons, so what to do with broken testcase ('test_color_scheme_changes')? Can we remove (or comment out) it to approve other changes so we can add it late.
[21:24] <ZDmitry> s/./?
[21:24] <balloons> ZDmitry, you can comment out the broken parts, or even the test if you wish
[21:24] <balloons> I would agree let's get it merged ;)
[21:24] <nhaines> balloons: ooh, do you have Ubuntu Touch running on the Android emulator or QEMU?  I'm interested in hearing more.
[21:25] <balloons> nhaines, who gave you that idea?!
[21:25] <ZDmitry> balloons, ok, I'll comment out
[21:25] <nhaines> balloons: the word "emulator" and pious hope.
[21:26] <balloons> nhaines, :-p some folks have found some success.. check the ubuntu phone mailing list
[21:26] <nhaines> balloons: I'm subscribed, but haven't seen much in the way of actual progress.  Just one user complaining.  I might trace back the thread, though.
[21:28] <balloons> nhaines, last I looked no gui, but it booted
[21:29] <nhaines> Hmm.  If I had more compiling practice I'd probably be of some use, but the last programs I compiled were for MS-DOS and now I program in Python.  :)
[21:30] <sergiusens> stgraber: ok, I got it in, testing to see if I'm getting the right stuff and will have it proposed soon
[21:34] <stgraber> sergiusens: cool
[21:35] <ZDmitry> balloons, done.
[21:36] <balloons> ZDmitry, approved mate
[21:37] <ZDmitry> balloons, thanks
[21:40] <AskUbuntu> Different toolbar icons depending on active tab | http://askubuntu.com/q/322039
[21:40] <AskUbuntu> Can I develop apps for Ubuntu mobile on Lubuntu? If yes, how do I set up my pc for doing it from terminal? | http://askubuntu.com/q/322040
[22:07] <sergiusens> stgraber: barry does the upadte server not support resuming?
[22:08] <barry> sergiusens: update server?  the server is just a dumb http/https server.  the client does not support pause/resume yet, but it will when i integrate the download service
[22:10] <sergiusens> barry: ok, so that may explain this http://pastebin.ubuntu.com/5892272/
[22:11] <barry> sergiusens: that looks like a question for stgraber
[22:11] <stgraber> barry: odd, I'm not sure how the server was setup, it should be a standard http/https server similar to cdimage/archive
[22:12] <stgraber> sergiusens: ^
[22:12] <sergiusens> stgraber: is it lucid?
[22:14] <stgraber> sergiusens: I assumed it was precise but I don't know for sure, it's supposed to be a newly installed server
[22:14] <stgraber> sergiusens: all I can do on my side is rsync stuff to it from nusakan, I don't have ssh access to that machine
[22:35] <dejello> hello all
[22:35] <nhaines> dejello: _o/
[22:36] <dejello> Forgot I signed in here :P
[22:45] <sergiusens> stgraber: so now I'm http://pastebin.ubuntu.com/5892371/
[22:46] <stgraber> sergiusens: that looks good
[22:55] <sergiusens> stgraber: rsalveti https://code.launchpad.net/~sergiusens/phablet-tools/image_updates/+merge/175960
[22:55] <sergiusens> only tested on manta
[23:01] <stgraber> sergiusens: looks good, +1ed the MP
[23:15] <sergiusens> stgraber: ok, it's merging then
[23:16] <stgraber> sergiusens: cool, can you do the whole pushing to the archive thing too?
[23:16] <sergiusens> daily release is in 3, should we wait for it or do you want it now?
[23:16] <sergiusens> stgraber: I can't trigger, we need someone from https://launchpad.net/~ubuntu-unity/+members
[23:17] <stgraber> ah, I can wait 3 hours, no problem, was planning on posting the blog post tomorrow morning anyway
[23:18] <sergiusens> stgraber: ok, great... I'll try and be online in the morning
[23:18]  * sergiusens goes back to testing
[23:20] <AmEv> Hey