[00:04] <asac`> ok ... i am running now camera autopilot on 08 image
[00:08] <asac`>  \o/
[00:08] <asac`> popey: http://paste.ubuntu.com/5860109/
[00:08] <asac`> OK!!!!
[00:09] <asac`> camera autopilot works on 08
[00:09] <asac`> no error
[00:28] <rsalveti> Saviq: do you need someone to trigger the build job for unity8? or should we wait tomorrow's build?
[00:28] <rsalveti> asac`: nice
[00:33] <Saviq> rsalveti, it should be daily releasing now
[00:33] <Saviq> rsalveti, so nothing we can speed up, really
[00:34] <Saviq> rsalveti, should be in tomorrow's image IIUC
[00:38] <rsalveti> Saviq: cool, that's fine
[00:57] <CrusaderAD> Hello everyone! Is Ubuntu Touch in a more usable state now? Has it evolved a bit since the initial release of the preview?
[00:58] <Oranger> CrusaderAD: Ubuntu touch is more usable than tomorrow and yesterday it will be more usable than today :)
[01:00] <pmcgowan> Oranger, you are a true poet
[01:00] <dejello> *blink*
[01:02] <Oranger> Ahah ^^ pmcgowan : I feel something like irony in your words ;)
[01:02] <asac`> veebers: thomi: who of you had a device?
[01:02] <thomi> asac`: currently veebers has both devices
[01:02] <pmcgowan> not at all
[01:02] <thomi> asac`: but I can get one back as soon as he un-bricks it :)
[01:03] <CrusaderAD> It says in the wiki that nexus 7 is broken, is that still the case?
[01:03] <asac`> thomi: veebers: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdDhEUy1nM1Jab3N4VGNQS0dQR19lTFE
[01:03] <asac`> started testing the first tab
[01:03] <asac`> (canonical apps_
[01:04] <pmcgowan> CrusaderAD, nexus 7 is working with some issues related to camera and video afaik
[01:04] <asac`> thomi: i just run through the list from the pad
[01:04] <asac`> veebers: ^^
[01:04] <Oranger> Ok, it's 3 am here... Good night everyone !
[01:05] <thomi> asac`: awesome. I think veebers may be at lunch at the moment
[01:05] <CrusaderAD> ok thanks!
[01:05] <asac`> kk
[01:05] <thomi> asac`: but I'll talk to him when he gets back
[01:05] <thomi> or, I guess he'll read this
[01:05] <asac`> thomi: whats his full name? :)
[01:05] <asac`> (so i can shared)
[01:05] <thomi> Chris Lee
[01:08] <True_unReal> hello?
[01:08] <crusaderad> hi
[01:09] <True_unReal> can you helpme out?
[01:09] <crusaderad> what's wrong?
[01:10] <True_unReal> i did a build for ubuntu touch but in the out directory i get a cm10.1 zip that says unofficial and some .img files
[01:10] <True_unReal> and im not sure what to do with them
[01:11] <crusaderad> which device?
[01:11] <asac`> mhall119: awake?
[01:12] <True_unReal> the device is a p769 its another variant of the p760
[01:12] <True_unReal> Optimus L9\
[01:14] <True_unReal> so no one can help me?
[01:14] <asac`> veebers: thomi: gallery-app autopilot is odd ... undeterministic. fails sometimes 23/23
[01:14] <asac`> sometimes 5/6
[01:14] <asac`> etc.
[01:14] <asac`> seems not all tests are run
[01:14] <asac`> is that a known prob?
[01:14] <thomi> asac`: not that I know of - maybe pastebin the output?
[01:14] <asac`> (e.g. that sometimes not all apps are run
[01:14] <asac`> )
[01:15] <thomi> asac`: it should certainly run all the tests every run
[01:15] <asac`> wait
[01:15] <thomi> yeah that seems very broken :)
[01:15] <asac`> that was me being screwed :)
[01:15] <thomi> :)
[01:15] <asac`> did run a different test by hitting arrow key too many times
[01:15] <thomi> ahhh
[01:15] <True_unReal> dam
[01:15] <thomi> I do that all the time
[01:15] <pmcgowan> True_unReal, are you following the porting guide?
[01:16] <True_unReal> yea i did but its not very helpful on what to do with the files after you build
[01:16] <True_unReal> them
[01:17] <pmcgowan> True_unReal, the latest images are also not compatible with the guide and we are updating that
[01:17] <True_unReal> what do you mean?
[01:17] <pmcgowan> not sure I can help you, most of the devs are offline
[01:18] <pmcgowan> True_unReal, we made a big change to the container model
[01:18] <pmcgowan> so now we boot to ubuntu and contain android rather than vice versa
[01:19] <True_unReal> ok so the build i made was useless then?
[01:20] <pmcgowan> perhaps not but I am not sure, for sure the instructions will change
[01:20] <pmcgowan> will be revised the next couple of days
[01:20] <veebers> Hi asac`, thomi: I got the phone 'unbricked'
[01:20] <asac`> nice :)
[01:21] <rsalveti> True_unReal: not useless, can still work with our tagged images
[01:21] <asac`> veebers: can you make one device remotely accessible to thomi? so we can split the load of filing the spreadsheet?
[01:21] <thomi> veebers: or, would you like to work around here this afternoon?
[01:21] <rsalveti> and with our current unflipped ones, will just not work yet with the flipped images (ubuntu booting first)
[01:21] <asac`> (just an idea)
[01:21] <rsalveti> but the porting is still useful
[01:21] <veebers> asac`: I can do one better and hand it off in person :-)
[01:21] <rsalveti> True_unReal: so if you build them, you just need to flash it :-)
[01:21] <thomi> asac`: veebers and I live about 5 minutes away from each other
[01:21] <asac`> veebers: oh NZ is so small :) ... or are you living the "geek district"? :)
[01:22] <asac`> lol
[01:22] <rsalveti> use the cm10...zip file first (via recovery)
[01:22] <asac`> cool
[01:22] <thomi> hah. I wish we had a geek district
[01:22] <rsalveti> and then the ubuntu.zip
[01:22] <True_unReal> mmm ok but can you answer me this question i flashed the cm10.1 zip file it build with some vsauce arm file zip and it boots but the screen is just black?
[01:22] <veebers> thomi: sure, let me finish this coffee and I'll pop around
[01:22] <thomi> veebers: by the time you get here I should have closed this bug I'm working on
[01:22] <asac`> ok ... i will continue testing... note that i didnt include the logs, nor filed bugs
[01:23] <True_unReal> but what ubuntu.zip?
[01:23] <asac`> want that owners really get used to do that on their own
[01:23] <rsalveti> True_unReal: the screen is just black because you're probably missing the ubuntu zip file now (the ubuntu image)
[01:23] <rsalveti> let me find you the link
[01:23] <True_unReal> alright
[01:24] <rsalveti> True_unReal: http://cdimage.ubuntu.com/ubuntu-touch-preview/raring/monthly-06/raring-preinstalled-phablet-armhf.zip
[01:24] <True_unReal> ok thank you
[01:25] <rsalveti> this is a tagged build, so should be stable
[01:25] <rsalveti> once you get that running you can try the saucy based image
[01:25] <mhall119> asac`: for now
[01:25] <asac`> yay ... second app that has zero test failures is "share-app" :)
[01:25] <asac`> mhall119: how long?
[01:25] <mhall119> a while still, probably
[01:25] <asac`> wanna help running through a few autopilot tests to seed info
[01:25] <True_unReal> alright
[01:25] <mhall119> it's only 9:30pm
[01:25] <True_unReal> 6:25
[01:26] <True_unReal> pm
[01:27] <True_unReal>  <rsalveti>  is there a major difference between saucy and raring
[01:28] <rsalveti> True_unReal: a few things, but it's better to start with the raring based one
[01:28] <rsalveti> as it's known to be more stable
[01:28] <True_unReal> alright
[01:30] <True_unReal> is there anything else i need to flash after that?
[01:30] <rsalveti> nops
[01:31]  * rsalveti takes a break 
[01:36] <pmcgowan> rsalveti, thanks
[02:04] <thomi> asac`: colourful :)
[02:05] <asac`> scary :)
[02:05] <asac`> i will change the numbers to reflect success/total
[02:05] <asac`> currently its fail/total
[02:05] <asac`> but i think folks believe the high numbers are good
[02:13] <asac`> thomi: veebers: mhall119: i leave the "core apps tab" alone
[02:13] <asac`> continue on SDK ... feel free to split filling that out
[02:14] <asac`> i probably will drop to bed before getting to unity
[02:14] <asac`> err shell
[02:14] <thomi> asac`: ok, just getting set up
[02:14] <asac`> nice
[02:14] <asac`> i started to fill some of the application names and components in the "core apps" tab
[02:14] <asac`> but... there are more in the list in the pad ... so dont forget :)
[02:15] <asac`> also note that sometimes the component name doesnt follow the same naming scheme as all the others
[02:16] <asac`> e.g. phone-app-connected-autopilot turned out to be connected_tests rather than phone_app_connected
[02:16] <asac`> mhall119: thomi: veebers: ^^
[02:24] <Noskcaj> I'm running xubuntu saucy and whenever i open the clock app it says that the alarm part has not been made yet. is this meant to happen?
[02:44] <thomi> asac`: what build are you running?
[02:44] <thomi> asac`: This device seems to be running saucy-34
[02:49] <asac`> thomi: 08
[02:49] <asac`> that should still be /current
[02:49] <asac`> so just phablet-flash might do the right thing (TM)
[02:49] <thomi> hmmm... how come I have 34?
[02:49] <asac`> i refer to a date
[02:50] <asac`> 20130708 == 08 for me
[02:50] <asac`> i dont know about other image version scheme :)
[02:50] <thomi> asac`: ahh
[02:50] <asac`> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/
[02:50] <asac`> maybe you are still on ubuntu-touch-preview?
[02:50] <asac`> not sure what saucy-34 means :)
[02:50] <thomi> asac`: what happens when you run: cat /system/ubuntu_stamp | grep JENKINS_BUILD
[02:50] <thomi> on the device?
[02:50] <asac`> but if you know what i means i am happy :)
[02:51] <asac`> yeah... that i dont know :)
[02:51] <asac`> oh wait
[02:51] <asac`> -37
[02:51] <asac`> but i think we dont use jenkins anyway
[02:51] <asac`> so not sure if that number is meaningful still...
[02:51] <thomi> hmmm
[02:51] <thomi> ok
[02:51] <asac`> i think jenkins is only used for part of the image right now
[02:51] <asac`> (android parts)
[02:55] <asac`> thomi: veebers: mhall119: oki ... crashing for today... core apps and shell/unity tab would be nice to get more stuff in...
[02:55] <asac`> ignore indicators/mir tab for now i guess
[02:55] <asac`> they dont have matches in the pad
[02:56] <True_unReal> hey guys so you have to download the ubuntu images?
[02:56] <asac`> will check in 15 minutes before completely dropping
[02:56] <asac`> True_unReal: i just run phablet-flash ... that does the right thing with my device to upgrade to latest daily image
[02:56] <thomi> asac`: will try, but having some device issues still
[02:56] <asac`> n7 or n4?
[02:56] <True_unReal> mmm ok thanks
[02:57] <asac`> fwiw, i run that on my laptop with phone connected to it
[02:57] <thomi> both :-/
[02:57] <asac`> thomi: hmm. ok... not working after phablet-flash?
[02:57] <thomi> can't get the n7 to boot at all, suspect a battery issue, n4 needs flashing, but I'm having Internet issues with the flash process
[02:58] <thomi> asac`: I'll struggle on, and we can touch base tomorrow perhaps
[03:02] <True_unReal> hey guys any idea how to fix  bootloop
[03:15] <asac`> thomi: yeah. try n4 ... if that also fails do something else and rather check with team her etomorrow what to do
[03:15] <asac`> mhall119 might do a few of the core apps
[03:16] <asac`> and with that we already have good data for this night effort :
[03:16] <asac`> )
[03:16] <asac`> bye
[03:31] <True_unReal> got it to boot hoorah!!
[03:31] <thomi> where do I file bugs against friends-app? it doesn't have a bugtracker configured in launchpad
[03:31] <thomi> do i file against manhattan, or....?
[03:32] <thomi> mhall119: if you're still around, I guess you'd know?
[06:31] <True_unReal> hello?
[06:32] <True_unReal> hello?
[06:34] <bef0rd> hi
[06:41] <True_unReal> hello?
[06:45] <True_unReal> any one here?
[07:21] <janimo> ogra_, hi, I just phablet-flashed the latest image on the N$ and there's no display. Is this the current status with no Mir landed yet or did I do something wrong?
[07:21] <janimo> I mean N4
[07:24] <rickspencer3> hey didrocks
[07:24] <didrocks> hey rickspencer3!
[07:24] <rickspencer3> so, bug list for dog-food busting bugs?
[07:25] <rickspencer3> seems like we need to be able to identify the bugs, and have a certain person decide if they are breaking dog-fooding
[07:25] <didrocks> sounds like the most effective and immediatly actionnable plan to me (doesn't prevent adding more tests, but it's more a long term thing and take time to grow the list)
[07:25] <rickspencer3> didrocks, indeed, having more tests is not useful if we aren't fixing the bugs we are finding already ;)
[07:25] <didrocks> exactly :)
[07:26] <didrocks> rickspencer3: so agreed, then, we switch the image if we are happy with current image state
[07:26] <rickspencer3> didrocks, I thought that was the plan all along
[07:26] <rickspencer3> like the image would be pending or something
[07:26] <rickspencer3> and then when it proved itself, it would be pushed out
[07:26] <didrocks> I don't know who/how the image switch is done
[07:27] <didrocks> the most difficult part I guess is to have that list public and readable
[07:27] <didrocks> hence the small tool proposal I have done in the past (but it's not the only solution, maybe others would have better ones)
[07:27] <dholbach> good morning
[07:27] <rickspencer3> didrocks, what does the tool do, exactly?
[07:28] <didrocks> rickspencer3: producing the web pages I posted on the last email, like http://people.canonical.com/~platform/olddesign/upstream.html
[07:28] <didrocks> then, upstream can see, on their components, which bugs needs to be addressed design-wise and release-wise
[07:28] <rickspencer3> ok
[07:29] <rickspencer3> didrocks, so how do we identify "stop the line" bugs on that list?
[07:29] <didrocks> and design/release can "ack" when they confirm that the fix is working (and it cleans + archive)
[07:29] <rickspencer3> didrocks, I think a lot of these bugs are not related to design at all
[07:29] <rickspencer3> like the battery eating bug
[07:29] <didrocks> rickspencer3: see "distro priorities"
[07:29] <didrocks> (second part)
[07:30] <didrocks> so basically, we have 2 master project
[07:30] <didrocks> "design priorities"
[07:30] <didrocks> and "distro priorities"
[07:30] <didrocks> we attach that to a bug which seems important
[07:30] <didrocks> then, some people can switch to a particular status to "ack, this is something important that needs to be addressed"
[07:30] <didrocks> set a priority
[07:30] <rickspencer3> didrocks, ok, so the tooling seems good
[07:30] <rickspencer3> but who are the "people" that do the attaching
[07:31] <didrocks> once the bugs is fixed for upstream and in distro
[07:31] <rickspencer3> and how do they find out which bugs are blocking dog fooding?
[07:31] <rickspencer3> (for the Ubuntu Touch case)
[07:31] <didrocks> the "people" will ack it's fixed and switch to fix released, the bugs will be archive :)
[07:31] <didrocks> rickspencer3: it was John for design and me for Unity until now
[07:31] <didrocks> I'm happy to help, I think the foundation team should give a hand as well
[07:32] <rickspencer3> didrocks, I think it's too much to ask you to do all of Desktop and Touch
[07:32] <didrocks> rickspencer3: well, days are quite long already TBH, so yeah, can't just rely on me for sure :-)
[07:32] <rickspencer3> didrocks, so, basically, you guys dredge through bug reports on lp each day and find bugs that you think need to be addressed?
[07:32] <didrocks> rickspencer3: yeah, I have good filters in my inbox to quickly look over bugs
[07:33] <rickspencer3> so, it sounds like we a need a person or people to do the same thing for Ubuntu Touch
[07:33] <didrocks> right
[07:33] <rickspencer3> do you think anyone considers themselves to be that person already?
[07:33] <popey> didrocks: rickspencer3 the image switch is planned to happen once ogra_ and I have flashed multiple devices and done a shakedown test
[07:33]  * popey is catching up
[07:33] <rickspencer3> popey, sorry, what "image switch" are you referring to?
[07:34] <popey> pointing /current at the image du jour
[07:34] <didrocks> rickspencer3: speaking of the devil, maybe popey? he knows how to find bugs and as he's talking to the community a lot, he can see which bugs are more a priority
[07:34] <didrocks> rickspencer3: TBH, the French forum helps me a lot to see what bugs needs to be addressed
[07:34] <rickspencer3> popey, so you are saying you will look at test results, confirm that the image has been manually validated, and then throw the switch? every day?
[07:35] <popey> that was the decision we came up with yesterday after the awful image
[07:35] <rickspencer3> popey, ok good
[07:35] <popey> i think rsalveti mentioned this in the email thread
[07:35] <didrocks> (just looking at the messages and seeing the number of complains on something is a good stats to see if something went bad :p)
[07:35] <popey> as the image gets finished soon after ogra_ and I start our day
[07:35] <popey> i look at all the new bugs each morning as part of my daily routine also
[07:35] <rickspencer3> didrocks, so it sounds like popey and ogra_ are the "people" who identify the bugs
[07:35] <popey> but I don't necessarily (currently) assign priority to them, but do an initial triage/confirm
[07:36] <didrocks> yep, sounds logical to me :)
[07:36] <rickspencer3> popey, so how do we make sure that people who "broke the image" fix the issues asap?
[07:36] <popey> well initially we need some smarts to figure out what broke
[07:36] <rickspencer3> in other words, if you "made the image awful"  it needs to be your #1 priority to unaweful it
[07:37] <popey> I agree.
[07:37] <didrocks> "unaweful" -> /me marks on his dictionary :)
[07:37] <rickspencer3> popey, traditionally on the desktop that happened by going to the logical maintainer for the area that seems busted
[07:37] <rickspencer3> and then that person investigates
[07:37] <popey> I agree with the thread where it's noted we have a wide spread of people across a number of components. Pat/Olli & Bill oversee AIUI
[07:38] <rickspencer3> popey, ogra_, didrocks so how do we make unawfuling the #1 priority?
[07:38] <popey> But we're likely to find these issues 4-5 hours before any of them start
[07:38] <popey> so need to be able to reprioritse engineers when we get an awful build
[07:39] <rickspencer3> popey, first of all, I just saw via tab completion that someone has the irc nick "poutine", which is the most awesome nick ever
[07:39] <popey> Without individual engineers having numerous managers pulling in various directions
[07:39] <popey> I keep seeing pictures of poutine online, never tried it, looks delicious
[07:39] <didrocks> rickspencer3: harassing people was the only way until now, polling doesn't work… but I think the engineering manager should be the point of contact
[07:39] <didrocks> which is an issue for timely fixes
[07:39] <rickspencer3> didrocks, well, for the next 2 weeks, I am in Berlin
[07:39] <rickspencer3> so I can harass people the moment they awake ;)
[07:40] <rickspencer3> then I will trade places with asac
[07:40] <didrocks> rickspencer3: engineering manager -> I meant, direct manager :-)
[07:40] <didrocks> like x broke y, x's managers is responsible to get it fixed timely :)
[07:40] <rickspencer3> didrocks, popey experience with 12.04 suggests that having someone beating the daily quality drum early in "the day" is helpful
[07:40] <popey> +1
[07:41] <didrocks> well, that's what I did… but warning, it creates tensions :)
[07:41] <rickspencer3> I was based in France for a lot of 12.04, so I could spend my mornings doing that
[07:41] <didrocks> (especially when you enforcing tests for everything and having aggressive revert usage)
[07:42] <rickspencer3> didrocks, well, maybe someone like asac would be better for that?
[07:42] <didrocks> sounds good to me :)
[07:42] <rickspencer3> ;)
[07:42] <rickspencer3> I'll be based on the East Coast starting in August, so my schedule won't be terrible for it, like when I was West Coast
[07:45] <popey> i would like a bot in here which announces when the build is done
[07:45] <popey> we used to have that in an internal channel
[07:45] <sil2100> oSoMoN: morning!
[07:48] <didrocks> popey: btw, I think we want to discuss image build time
[07:48] <popey> duration or start/end time?
[07:48] <didrocks> popey: it should be just after we've dealt with daily releases, instead of the day after
[07:48] <didrocks> start time*
[07:48] <popey> what, so late in the eu evening?
[07:49] <didrocks> popey: I've no idea when you build the image TBH :)
[07:49] <popey> ogra_ sent a mail to the list, it happens ~9 am now
[07:49] <seb128> didrocks, "due to popular demand the daily image builds (flipped image) now run 5h
[07:49] <seb128> earlier (starting at 8:32 UTC)"
[07:49] <seb128> didrocks, ogra sent that yesterday
[07:50] <popey> I'd rather it was at least ~2 hours earlier so my first activity of the day would be flashing
[07:50] <rickspencer3> I think we should discuss that time
[07:50] <didrocks> seb128: popey: ok, I think we didn't manually publish what we can publish at that time, knowing that sil2100 is starting his day now
[07:50] <rickspencer3> I think 8:31 would be better

[07:50] <didrocks> so if there are packaging changes, we won't get latest
[07:51] <seb128> right, that's good for things that autoland
[07:51] <seb128> it's too early to get things that europeans need to land
[07:51] <seb128> I don't know how long an image build takes
[07:52] <seb128> the issue by pushing it later is that we don't have the images early in the day
[07:52] <didrocks> seb128: yeah, but I think things that don't daily release (please stop use the term autolanding, everyone is confused by it :p) are less impacting/have big changes
[07:52] <seb128> like popey says, it's already late for him
[07:52] <didrocks> popey: yeah, but you need latest content and if we are in manual publishing mode…
[07:52] <seb128> didrocks, we should maybe start thinking about bi-daily release?
[07:52] <didrocks> you will get an extra day of daily
[07:57] <seb128> one in the u.s end of day
[07:57] <seb128> and one in the european morning?
[07:57] <seb128> so u.s end of day ones would have most of the day changes and be on the image
[07:57] <didrocks> seb128: that doesn't change for manual publishing if nobody is here to manual publishing changes
[07:57] <seb128> well, the u.s guys would be
[07:57] <didrocks> they aren't right now, so first, ensuring they can
[07:57] <didrocks> and bi-daily release means that upstream has less time to land conflicting changes
[07:57] <didrocks> (see my email about backward compatibility)
[07:57] <didrocks> telling "everything should land in a coherent piece for 00 UTC" is already hard to get respected
[07:57] <didrocks> so twice a day, not sure how it will plan
[07:57] <didrocks> but in any case, it's not a power issues, daily release can still bi-daily, it's more a process/ensuring that everyone's on board issue
[07:57] <didrocks> s/still/be/
[07:57] <popey> surely if it's building at ~5am for a 7am UTC test start nobody is up at 5am (sorry Aus/NZ) doing anything just prior to that are they?
[07:57] <popey> or are we waiting on stuff building from 10pm utc the day before?
[07:57] <didrocks> popey: the issue is not building, it's when they are packaging changes or a stack failed
[07:57] <didrocks> the deal with daily release and other distro maintainers is to block publication if we have packaging changes
[07:57] <popey> right, but nobody would look at that till you guys wake anyway
[07:57] <didrocks> and someone with upload rights review the packaging diff
[07:57] <didrocks> and "ack" by publishing it to distro
[07:57] <didrocks> popey: exactly, and that's the issue
[07:58] <didrocks> or a stack failing: for instance, the apps stack isn't published right now because we are getting 28 autopilot tests failing
[07:58] <didrocks> (I guess that's why sil2100 is pinging oSoMoN ;))
[07:58] <popey> ☻
[08:00] <sil2100> Yes ;) Seems like some change in the UI toolkit I guess
[08:00] <sil2100> Since there's an invalid assert going on with transperancy now
[08:00] <didrocks> we really need the sdk to run apps AP tests
[08:01] <ogra_> morning  ...
[08:02] <AskUbuntu> Ubuntu touch на TurboPad 720 | http://askubuntu.com/q/318404
[08:02] <popey> Good morning ogra_
[08:02] <didrocks> hey ogra_!
[08:02] <ogra_> rickspencer3, "unawfulling" would work if *any* tests would happen :)
[08:04] <ogra_> theoretically freshly built images are supposed to come out at cdimage.u.c/$product/$type/pending .... where some automated tool is supposed to pick them up, run tests and if these are successful /pending should be moved to /current
[08:06] <ogra_> it is kind of a coincidence that we had a broken shell at the same time i moved the images earlier .... but it showed flaws in the process
[08:07] <ogra_> so until the QA side actually happens popey and i will do manual smoketests (does it boot to shell, are all things i should see on the screen, can i start an app) .... with the hope that this automated testing starts to happen soon
[08:09] <ogra_> i wouldnt mind to have bi-dailies (or even one every two hours or so) *if* the automation is in place and *if* we can get a dedicated livefs builder
[08:10] <ogra_> at the point where we drop apt (soon), fixes will not get in through package updates anymore but your fix will have to do a whole turnaround through the whole process of landing in an image, that means fixes will take significantly longer to reach the user, doing more image builds definitely helps here
[08:13] <didrocks> ogra_: the issues are that there isn't this backward compatibility/don't break ABI/API culture, so we need to be really careful in the way we builds and lands things
[08:14] <didrocks> ogra_: which is what dailies are doing, ensuring we don't start building if everything that it build-deps on didn't finish to build
[08:14] <ogra_> popey, i'd liked it 2h earlier too, but there are other builds running at that time, and we would just end up sitting in a queue
[08:14] <didrocks> and not landing automatically if anything more on the "front" of the queue didn't land
[08:14] <didrocks> (so every 2 hours is not feasable with those constraints)
[08:15] <ogra_> didrocks, it is feasible if the CI jobs run in such a manner too
[08:16] <didrocks> ogra_: CI doesn't pick latest of other changes and that won't fly with "we need to land those breaking changes together"
[08:16] <ogra_> i would even go further and say trigger an image build every time an upload lands that closes a bug with critical status on LP
[08:16] <oSoMoN> sil2100: hey, sorry I was out for an errand, what’s up?
[08:17] <ogra_> didrocks, hold them back until they are unbroken then
[08:17] <ogra_> can CI run in a constant loop and if all tests pass release ?
[08:17] <ogra_> *do a release
[08:17] <didrocks> ogra_: I don't think it can do that, and CI doesn't build with ppas, distro builders, only daily releases does it
[08:18] <didrocks> ogra_: but yeah, I would be happy if we have that, but it means that upstream needs to stop breaking API and not being backward compatible
[08:18] <sil2100> oSoMoN: hi! hm, I already poked the UI toolkit guys and it seems to be a problem in the toolkit
[08:18] <didrocks> which isn't the target AFAIK for now at least
[08:18] <sil2100> oSoMoN: since we're getting a lot of touch failures on apps stack
[08:18] <ogra_> so with the no-packages model that means that i might have to wait two days for a fix  ?
[08:18] <ogra_> even a critical one ...
[08:19] <sil2100> oSoMoN: a lot in webbrowser - but it's due to a rounding error in the UI toolkit, so I guess we need the guys to fix that...
[08:19] <oSoMoN> sil2100: can you point me to those failures, so I can have a look, just for my info?
[08:22] <didrocks> ogra_: that's orthogonal with package/no-package, isn't it?
[08:22] <ogra_> no
[08:23] <sil2100> oSoMoN: righto
[08:23] <ogra_> once the android packages are in the archive (this month) you would be able to just dist-upgrade immediately once the fix lands
[08:23] <sil2100> oSoMoN: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/395/testReport/
[08:23] <sil2100> oSoMoN: MismatchError: After 10.0 seconds test on Suggestions.opacity failed: 1 != dbus.Double(0.9999999999641627, variant_level=1)
[08:23] <sil2100> Is the issue everywhere
[08:24] <didrocks> ogra_: but the android packages are not daily releasing, so not linked to the current discussion?
[08:24] <ogra_> with the no package model it will take the CI time and then i still have to wait for a new image build
[08:24] <ogra_> it adds up
[08:24] <ogra_> the android packages will be re-build per change
[08:24] <didrocks> ogra_: defines CI, a lot of people means daily release or upstream merger or "autolanding"
[08:25] <True_unReal> hey guys can i ask a question?
[08:25] <oSoMoN> sil2100: huh, that’s weird indeed, is it confirmed that it’s an issue in the toolkit?
[08:25] <ogra_> if either something in the android git or in platform-api/hybris happens they will be rebuilt
[08:25] <sil2100> oSoMoN: so it seems! Michał just now put up a bug: https://launchpad.net/bugs/1199662
[08:26] <sil2100> oSoMoN: since there have been some modifications made yesterday
[08:26] <didrocks> but you agree that for that, we need to have all components not breaking API or ABI and having some kind of backward compatibility, right?
[08:26] <oSoMoN> ok
[08:26] <ogra_> didrocks, well, i refer to "run once a day to build PPA packages that i dump in the archive once i know the deps and tests pass"
[08:26] <True_unReal> guys how do you fix a bug?
[08:27] <ogra_> didrocks, imho the "once a day" needs to be switched to "at every change (or at a bunch of these)" somehow
[08:27] <didrocks> 10:26:09     didrocks | but you agree that for that, we need to have all components not breaking API or ABI and having some kind
[08:27] <didrocks>                       | of backward compatibility, right?
[08:27] <didrocks> ogra_: ^
[08:27] <sil2100> True_unReal: depends on what bug you have in mind, usually you find the problem causing the bug in the code and fix it there
[08:27] <True_unReal> wifi and network radio
[08:28] <ogra_> and i would love to have the image builds triggered automatically each time some package (or a certain amount of them) from the manifest has been changed
[08:28] <ogra_> that way we could get the sortest turnaround time for getting fixes out to the user
[08:28] <didrocks> ogra_: can you answer my question? As I told, we all agree on this. However, seeing how this is handled, it's not pratical or doable now as long as this requirement isn't met
[08:28] <ogra_> *shortest
[08:29] <ogra_> didrocks, what does the tournaround time have to do with backwards compatibility ?
[08:29]  * ogra_ doesnt understand the connection here .... thats a code thing 
[08:29] <didrocks> ogra_: because as people are breaking ABI and not ensuring backward compatibility
[08:29] <didrocks> they do a change in x
[08:29] <didrocks> y and z needs to be changed for working with new x
[08:30] <didrocks> and new x breaks y and z
[08:30] <ogra_> if packages build, the deps arent broken and they pass their testsuite, they are fine
[08:30] <didrocks> yeah, and then, how to deal with that situation? ^ if you don't have a "per stack validation" you are not able to handle that case ^
[08:30] <ogra_> so the API/ABI check must be part of the testsuite
[08:30] <didrocks> because you need the 3 of them
[08:30] <didrocks> ogra_: it's not that it's broken by accident, it's because they don't want to keep it stable
[08:31] <ogra_> right, so hold the set back until all three are uploaded
[08:31] <didrocks> when I'm arguing about it I see buzzword as "agile" :p
[08:31] <didrocks> ogra_: so you need to have a notion of sets
[08:31] <didrocks> (which are the stacks)
[08:31] <ogra_> well, what we are currently doing is snailing, not agile :P
[08:31] <didrocks> at least, we ensure we are not breaking where we have tests :)
[08:32] <ogra_> didrocks, right, i see that we need the tests, i just debate that we should run these tests only once a day
[08:32] <didrocks> and being able to handle the "I don't care about previous versions"
[08:32] <ogra_> they should run constantly all the time
[08:32] <ogra_> and if the whole set passes, realease
[08:32] <didrocks> ogra_: I agree with that, I'm just debating about "we can land whenever we want"
[08:32] <ogra_> i never said that :)
[08:32] <didrocks> that's not true, you can't just think in term of isolated components
[08:32] <didrocks> we needs to have sets landing together
[08:33] <ogra_> i just want to get away from the scheduled bits throughout the whole process
[08:33] <ogra_> each step should be conditionally driven by the tests
[08:33] <ogra_> and if it succeeds immediately start over the testing
[08:33] <didrocks> we are pragmatically quite away from that :)
[08:33] <ogra_> until it passes again and releases etc etc
[08:34] <didrocks> we can dicuss starting the tests as soon as possible, but first, we need them to be reliable and in good number enough
[08:34] <ogra_> well, this is definitely stuff we need to have in place once we have an actual userbase
[08:34] <ogra_> i.e. imho that should be ready by 14.04
[08:35] <didrocks> ogra_: for that, we need upstream to have better practice in term of retrocompatibility and be able to organize the sets
[08:35] <didrocks> this idea of "stacks" is just because:
[08:35] <didrocks> - we don't have good tests granularity
[08:35] <didrocks> like we have no idea which tests only impacts indicator-x
[08:35] <ogra_> i dont say we have to do it now, but having a plan and possibly even have some bits moved to such a model by 13.10 would really be needed
[08:35] <didrocks> (integration tests I mean)
[08:36] <didrocks> - there is no culture of not breaking things and keep the old things working
[08:36] <didrocks> (indicators again changed their protocol for example)
[08:36] <didrocks> so needed to land a bunch of things together to keep it working
[08:36] <ogra_> well, dont care about upstream :)
[08:36] <ogra_> do care about your tests
[08:36] <didrocks> ogra_: you have the good role :)
[08:37] <ogra_> if your testsuite covers that behavior you can just constantly run it in a loop
[08:37] <ogra_> my point is that once we have phone customers we really cant do all that scheduled shit anymore ... be it CI tests or ikmage builds
[08:37] <didrocks> but then, you need to have clever algorithm to grow the suite of dependends
[08:38] <ogra_> right :)
[08:38] <didrocks> until you know "ok, I need to land x, y, z, w, p all together to have the tests passing"
[08:38] <ogra_> well, you have that info
[08:38] <ogra_> in your packages
[08:38] <didrocks> how come?
[08:38] <didrocks> well, not really
[08:38] <ogra_> you do
[08:38] <didrocks> let's say we change the dbus protocol for indicators
[08:38] <ogra_> if a dep is missing your tests will have to fail
[08:38] <didrocks> a dep missing?
[08:39] <didrocks> we still have old y for instance
[08:39] <ogra_> <until you know "ok, I need to land x, y, z, w, p all together>
[08:39] <didrocks> but dbus api change
[08:39] <didrocks> and no soname bump
[08:39] <ogra_> that needs to be properly reflected in the package deps
[08:39] <didrocks> so they need to version their protocole with a virtual package
[08:39] <ogra_> worst case by hard versioned deps
[08:39] <didrocks> or they need to use breaks:
[08:40] <didrocks> which is what I'm getting flammed at while writing this: https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI
[08:40] <didrocks> "because it's too complicated and I want to break something without having all the breaks"
[08:41] <ogra_> give them a script :)
[08:41] <didrocks> doesn't fly for external customers having their own components using that lib/protocol
[08:41] <ogra_> dh_update_abi ;)
[08:42] <ogra_> i dont care about external customers, they wouldnt use any of that at all, they will use the released images and whats on them
[08:42] <didrocks> well, once they refresh their image, they will have their "shell implementation" not working anymore
[08:43] <ogra_> have some tooll that, at source package creation, asks the uploader to define the proper hard dependecies and versions
[08:43] <ogra_> use these hard depped versions in your jobs and be sure to have the right ABI in all of the packages .-.. easy :)
[08:44] <didrocks> better to statically link then :p
[08:44] <ogra_> thats what click packages might do ...
[08:44] <didrocks> as we are recreating a similar system adding more hard time to handle this
[08:44] <ogra_> which is what your third party guys will likely use anyway
[08:46] <ogra_> we need to get from a schedule based system to an event triggered one to actually be "agile" ... (unless you mean agile should be "wait two days for a fix to land on my phone") and we should start planning this now to have something ready by LTS
[08:47] <didrocks> ogra_: agreed, but I don't think that you should put the quality issues on that
[08:47] <didrocks> ogra_: and it's not 2 days, when things are passing builds and tests, it's the next day if the phone image schedule was right :)
[08:48] <ogra_> the image schedule wasnt suitable
[08:48] <didrocks> ogra_: we went from a system which took 1, 2, 3… weeks to get a release, to releasing everyday, it's already an improvment
[08:48] <didrocks> ogra_: well, then new one isn't as well…
[08:48] <ogra_> thats why there was agreed at the sprint that we need to move the image builds earlier
[08:48] <ogra_> or even have multiple builds
[08:49] <didrocks> ogra_: but in accordance with the daily build schedule if I remember the sprint discussion
[08:49] <JamesTait> Good morning all, happy Don't Step On A Bee Day! :-D
[08:50] <ogra_> didrocks, we wnet from a system where i only had to watch the publisher to have my (locally tested) upload in the archive after at most 30min to a system where a unity8 fix took 2 days to land in todays image
[08:50] <didrocks> ogra_: well, you had no integration tests running at the time though
[08:50] <ogra_> it just happens, its broken and we cant get the fix in ... right now today
[08:51] <ogra_> no, the time i refer to we didnt have any tests indeed
[08:51] <didrocks> ogra_: and you landed a lib change to a ppa which can potentially breaks the rest
[08:51] <ogra_> and it was really bad at the beginning of this cycle ...
[08:51] <didrocks> ogra_: the 2 days is because of the new schedule I guess
[08:51] <ogra_> but the publisher is now event triggered
[08:51] <didrocks> and the "point of sync" was "build the image"
[08:51] <ogra_> and runs per package upload
[08:51] <ogra_> which shoved off about 1-1.5h
[08:52] <didrocks> as we have points of sync with daily release
[08:52] <ogra_> we need to get the other systems to that point too
[08:52] <didrocks> ogra_: what about having image starting to build everytime a stack is published?
[08:52] <didrocks> as we can have stack rebuild on demand, in case of urgency, that can help
[08:52] <ogra_> didrocks, the fix wasnt even remotely on the horizon at 13:32 yesterday
[08:53] <ogra_> it wouldnt have changed a thing if the image schedule hadnt changed
[08:53] <ogra_> we would still sit here and wait for it
[08:53] <ogra_> it would just not have been noticed that early
[08:53] <didrocks> ogra_: you are talking about unity8 fix?
[08:53] <didrocks> can we look at this, it's weird?
[08:54] <ogra_> yes
[08:54] <didrocks> so which commit rev id exactly?
[08:54] <ogra_> https://code.launchpad.net/~saviq/unity8/fix-mock-scopes/+merge/173698
[08:54] <didrocks> Approved by:Michael Zanetti 10 hours ago
[08:55] <Saviq> it's merged
[08:55] <didrocks> how can it be merged 2 days ago?
[08:55] <Saviq> released, even
[08:55] <ogra_> Saviq, yeah
[08:55] <didrocks> ogra_: ? ^
[08:55] <ogra_> didrocks, during our testing popey and i found the shell is broken
[08:55] <didrocks> the fix wasn't even remotely *approved* on the horizon at 13:32 yesterday
[08:55] <ogra_> we talked to Saviq who had a code fix a short while later
[08:56] <ogra_> then itr took 6h for someone to notice that there is a CI job that has to be manually triggered
[08:56] <ogra_> which then happened
[08:56] <Saviq> didrocks, yeah, we had tragic jenkins issue yesterday
[08:56] <ogra_> and showed that there were fixes needed
[08:56] <didrocks> but it's not daily release issues?
[08:56] <Saviq> didrocks, no
[08:56] <ogra_> which then took another few hours
[08:56] <didrocks> why ogra_ is pushing on daily releases dealying for 2 days then?
[08:56] <ogra_> well, one day, sorry
[08:56] <didrocks> I don't understand…
[08:56] <ogra_> still not "agile"
[08:56] <Saviq> ogra_, it wasn't daily release fault
[08:57] <ogra_> the fix was ready a few hours later
[08:57] <Saviq> ogra_, it was CI / autolanding that we had a fair with yesterday
[08:57] <ogra_> but didnt reach the archive
[08:57] <mhr3> seb128, ping?
[08:57] <True_unReal> hey guys where would i go to fix wifi?
[08:57] <Saviq> ogra_, we could've (I wanted to) pushed a release during the day
[08:57] <seb128> mhr3, hey
[08:57] <didrocks> ogra_: the fix was in trunk 9 hours ago
[08:57] <ogra_> Saviq, my point is the "pushed"
[08:57] <Saviq> ogra_, but CI / autolanding issues made it merge almost at 0000UTC
[08:57] <didrocks> ogra_: rev 93
[08:57] <mhr3> seb128, morning, how is it going?
[08:58] <didrocks> then, 4 hours later, the daily publish it
[08:58] <seb128> mhr3, good, thanks! you?
[08:58] <didrocks> ogra_: I don't see either 2 days nor a day turnaround…
[08:58] <didrocks> ogra_: I don't really follow you…
[08:58] <mhr3> seb128, not too bad :)
[08:58] <ogra_> Saviq, this needs to happen automatically after you uploaded without anyone "pushing" or having to wait for something scheduled
[08:58] <ogra_> didrocks, 24h ago a broken image was built
[08:58] <didrocks> ogra_: give real examples instead of spreading some "2 days" FUD :/
[08:58] <ogra_> thats a day in my book
[08:58] <didrocks> ogra_: well, we can't fix the image before the fix is merged in upstream trunk
[08:58] <mhr3> seb128, i wanted to ask about the settings app, some time ago you were asking about how to get all the info in qml, how did you end up solving that? a plugin?
[08:59] <didrocks> sorry, not that magic, daily release don't write code…
[08:59] <ogra_> and the fix only happens to be building right now
[08:59] <Saviq> ogra_, but the fix wasn't even merged for like 16 hrs later
[08:59] <True_unReal> guys you know where i need to go to fix the wifi in what folder
[08:59] <Saviq> ogra_, releasing every commit isn't an option, IMO
[08:59] <ogra_> whys not ?
[08:59] <seb128> mhr3, yes, a plugin for some stuff, qtsystems helped as well (getting vendor/model/disk space/imei number/...)
[08:59] <didrocks> ogra_: it seems you are totally targetting the wrong target for justifying something else being broken
[08:59] <ogra_> it is exactly what we did before
[09:00] <Saviq> ogra_, not true
[09:00] <didrocks> ogra_: and advancing bad infos isn't the right way to get stuff evolving
[09:00] <Saviq> ogra_, we haven't had releases for weeks at a time
[09:00] <ogra_> Saviq, we released every time someone tagged an upload before
[09:00] <Saviq> ogra_, we only pushed quickfixes (and manually) when needed
[09:00] <mhr3> seb128, is the plugin something that's generally usable by other apps as well? what can it do exactly?
[09:00] <ogra_> not every commit
[09:00] <Saviq> ogra_, that was a manual effort just the same
[09:00] <True_unReal> =(
[09:00] <Saviq> ogra_, releasing daily, with optional release in between for quickfixes
[09:00] <seb128> mhr3, no, it's not ... what "plugin", it's just a piece of cpp exposed to qml
[09:01] <ogra_> didrocks, calm down please, i'm not attacking you, i just want to improve things
[09:01] <Saviq> ogra_, is much better than what we had before, then
[09:01] <seb128> mhr3, we opted to have a plugin by panel when needed (most will not need one)
[09:01] <didrocks> ogra_: yeah, but please provide good arguments, not wrong ones or justifying bad timing, that's more constructive
[09:01] <ogra_> Saviq, you mean when i could do an upload right after a fix and had the binary deb about 1h later on my disk ?
[09:01] <seb128> mhr3, it's trivial to add one to your app or whatever you are writing, and you can do anything you want in cpp there
[09:01] <didrocks> ogra_: you can still do that for urgent fix, ask for a daily for that component to be triggered once merged in trunk
[09:02] <ogra_> didrocks, well, the fact is that it took 24h (and will still take some more hours) to get that fix out to users
[09:02] <mhr3> seb128, ah i see, i was just wondering whether there's some new component that other apps can use
[09:02] <ogra_> didrocks, thats not the same
[09:02] <didrocks> ogra_: right, but not because of dailies, we need to give time to upstream to fix those…
[09:02] <didrocks> ogra_: why?
[09:02] <ogra_> i know that i can force fast-path everything
[09:02] <seb128> mhr3, no, we didn't made that public/to share
[09:02] <ogra_> i want the fast-path for everything :)
[09:03] <mhr3> seb128, ok, sounds reasonable, thx for the update
[09:03] <seb128> mhr3, if you need something that is useful for apps etc you should probably consider add a proper api to some of our lib and do bindings around
[09:03] <seb128> mhr3, yw
[09:03] <didrocks> as Saviq told, there was no release per commit and realistically, this can't be done until we are 100% in our tests
[09:03] <Saviq> ogra_, I'm not sure how long a push through daily release takes, didrocks?
[09:03] <seb128> mhr3, let me know if you need to do the same thing and need help getting started
[09:03] <ogra_> Saviq, so every time i set debian/changelog from UNRELEASED to the distro name and do a debcommit in my bzr branch we do a release ... thats how it worked in the past in many distro packages
[09:03] <didrocks> Saviq: can tell you for the unity8 stack case, one sec
[09:04] <mhr3> seb128, not atm, just my curiosity :)
[09:04] <ogra_> Saviq, and imho a similar process of doing the release should still happen, but then the whole process should be triggered by that event and be automatic
[09:04] <didrocks> Saviq: 49 minutes for yesterday's one
[09:04] <ogra_> i'm not proposing a per commit model
[09:05] <Saviq> ogra_, so really what you're proposing is to replace "ask someone" with "put a release changelog entry in"
[09:05] <Saviq> ogra_, that I could agree with
[09:05] <didrocks> but then, you will have some components not releasing for days
[09:05] <ogra_> didrocks, does daily bypass the archive britney tests ? (else add 2h to that for britney and a publisher run)
[09:05] <didrocks> (or weeks)
[09:05] <Saviq> didrocks, no, no
[09:05] <Saviq> didrocks, daily should happen all the same
[09:05] <didrocks> ogra_: no, it doesn't AFAIK
[09:05] <Saviq> didrocks, but if there's a release changelog entry, it could be fast-tracked
[09:05] <ogra_> didrocks, getting the mails in your inbox doesnt mean the binary is downloadable
[09:06] <didrocks> Saviq: that's similar to "run manually the daily" then
[09:06] <ogra_> there is significant delay after that
[09:06] <Saviq> didrocks, yeah, the only thing would be the lack of manual intervention
[09:06] <didrocks> ogra_: well, not something I can help on though, and not sure cjwatson wants dailies to bypass britney
[09:06] <ogra_> i didnt say it should
[09:06] <didrocks> Saviq: it's still manual as it's a tag?
[09:06] <Saviq> didrocks, sure, but manual by dev
[09:06] <Saviq> didrocks, not manual by your team
[09:07] <Saviq> I can't comment on the speed of things, though
[09:07] <ogra_> didrocks, but you claimed that a unity8 fix would be in in 49min above
[09:07] <didrocks> Saviq: yeah, it's part of a bigger change I want to make: https://docs.google.com/a/canonical.com/document/d/12IlT4zsDzuV1cDsLiO2dOQMWTq0pVAe_PgdzAkOkSZg/edit
[09:07] <cjwatson> didrocks: they definitely must not
[09:07] <didrocks> ogra_: this is the daily release part
[09:07] <ogra_> it took 49min to get through the daily stuff ...
[09:07] <didrocks> cjwatson: I agree :)
[09:07] <ogra_> right
[09:07] <cjwatson> didrocks: but proposed-migration slows things down less than people think, especially given the last week's work
[09:07] <ogra_> cjwatson, yeah,. it gotf awesomely faster
[09:08] <didrocks> Saviq: the system needs to be more "friendly for upstream" though, I don't want you to have to learn how the jenkins workflow is used
[09:08] <cjwatson> the baseline overhead that you can actually attribute to proposed-migration now is under half an hour, I believe
[09:08] <ogra_> cjwatson, what i'm proposing is to make all bits we can event based like that
[09:08] <cjwatson> ogra_: Please stop quoting 2h for proposed-migration plus publisher run - that's very out of date!
[09:08] <didrocks> cjwatson: same for daily releases as I heard of 48 hours when it was 4 on that case :)
[09:08] <cjwatson> quoting excessive numbers makes problems for me
[09:08] <ogra_> instead of having things run once a day by a scheduker
[09:08] <Saviq> didrocks, sure, I think that us adding a "release" entry that would then be mangled by daily release and released could be ok
[09:09] <Saviq> didrocks, only problem there is potential conflicts
[09:09] <didrocks> Saviq: you will still have to wait for "upstream stacks" to be built if they run
[09:09] <Saviq> didrocks, sure, but that, as you said, is 49 mins?
[09:09] <Saviq> that will probably grow quite a bit, though :/
[09:09] <didrocks> yep :/
[09:09] <didrocks> 49 minutes is only the unity8 stack
[09:09] <cjwatson> ogra_: the publisher generally takes under 20 minutes now, or more like 5 if it only has work to do in saucy-proposed, and it tries to run every 5 minutes if there isn't another run in progress
[09:09] <didrocks> but let's say a dependent stack is running
[09:09] <didrocks> like indicators
[09:09] <ogra_> cjwatson, right
[09:10] <didrocks> as there is no ABI/dbus protocol garantee
[09:10] <didrocks> we have to wait for it to finish first
[09:10] <ogra_> cjwatson, and i would like to see *all* other bits behave like that
[09:10] <ogra_> cjwatson, including image builds ... CI  and whatever is in the loop
[09:11] <didrocks> ogra_: I think image builds reacting as soon as a stack is published (but in fact, move to the release pocket) would be a first step
[09:11] <didrocks> instead of being time triggered
[09:11] <ogra_> cjwatson, my issue is that we have things running from cron in many places, moving one piece around breaks the process or makes it extremely long
[09:11] <didrocks> then, we can work upstream and have that dailies triggered by upstream
[09:11] <ogra_> didrocks, i would go further
[09:12] <cjwatson> ogra_: cron isn't necessarily bad in itself; the publisher is still from cron but I would argue that it is no longer a problem
[09:12] <didrocks> but still respecting the synchronization between stacks
[09:12] <cjwatson> didrocks: that'll take a while - we need to make their build resource handling saner first
[09:12] <ogra_> as soon as any package from the former manifest changes an image build should be triggered (unless there is one running already)
[09:12] <didrocks> ogra_: starting working on that? :-)
[09:13] <ogra_> cjwatson, no cron in itself isnt, multiple pieces in a complicated process running by cron and depending on each other is
[09:13] <didrocks> if one is running, you append a new build (otherwise, you won't have that important-last-fix)
[09:13] <ogra_> didrocks, happy to, but it will be moot if we dont also work on all other bits that run scheduled
[09:14] <ogra_> all i want us is to stop talking about "agile" if it really isnt :)
[09:14] <didrocks> ogra_: well, what you propose with Saviq for dailies are: scheduled-base + a way to relaunch some stacks on demand (being a tag in the changelog or something else)
[09:14] <ogra_> lets make it behave "agile" instead :)
[09:15] <didrocks> which is basically what it does, the only missing part is to be upstream friendly to enable them to relaunch the stacks on demand (they have to ask us for now)
[09:15] <Saviq> didrocks, I think what ogra_ would like, too, would be to reduce the time it takes to go through daily machineryt
[09:15] <ogra_> didrocks, no i'm proposing a change triggered model that doesnt involve schedules :)
[09:16] <ogra_> Saviq, yeah
[09:16] <ogra_> !
[09:16] <didrocks> ogra_: so, we'll end up with some components not releasing for days
[09:16] <cjwatson> ogra_: only if the frequency is too low
[09:16] <ogra_> didrocks, if there were no changes, why should they release ?
[09:16] <didrocks> ogra_: even if they have changes
[09:16] <ogra_> then the model would be broken :)
[09:16] <didrocks> as you don't want (understandbly) per commit trigger
[09:16] <didrocks> as the discussion above ^
[09:16] <ogra_> a change needs to trigger a build and publishing of the stack
[09:16] <didrocks> but having upstream tag
[09:17] <didrocks> ogra_: that's not what Saviq and you were discussing
[09:17] <ogra_> ?
[09:17] <cjwatson> also I thought the point of giving more of you image build access was so that you could make more intelligent decisions about building when appropriate
[09:17] <cjwatson> honestly, at the moment I think that's better than bluesky discussions about refactoring the image build process ...
[09:17] <ogra_> cjwatson, its not the image build process ... thats only one small part
[09:18] <didrocks> 10:59:37        Saviq | ogra_, releasing every commit isn't an option, IMO
[09:18] <ogra_> my concern is the scheduling all over the place
[09:18] <didrocks> ogra_: ^
 Saviq, so every time i set debian/changelog from UNRELEASED to the distro name and do a debcommit in my bzr branch we do a release ... thats how it worked in the past in many distro packages
 Saviq, and imho a similar process of doing the release should still happen, but then the whole process should be triggered by that event and be automatic
[09:18] <didrocks> ogra_: which is the same than tagging
[09:18] <ogra_> didrocks, ^^ that was a few lines above
[09:19] <didrocks> and we'll end up with components not releasing for days
[09:19] <ogra_> didrocks, right (debcommit actually tags)
[09:19] <didrocks> because the state of components X will not be good enough for releasing right now
[09:19] <didrocks> and so, nobody will release anymore
[09:19] <didrocks> we'll have even fewer new components per day
[09:19] <ogra_> how do you handle that today ?
[09:19] <cjwatson> ogra_: you keep dodging me :)
[09:19] <didrocks> the scheduling is taking anything that has new relevant diff
[09:20] <ogra_> obviously someone needs to fix componentX in both models
[09:20] <cjwatson> ogra_: we can only fix anything by focusing on each specific element of the pipeline
[09:20] <didrocks> and have an optional "on demand" model for urgency stuff
[09:20] <cjwatson> so it doesn't help to dodge comments about specific elements by saying you meant the whole thing ...
[09:20] <didrocks> it seems you want to remove the schedule part
[09:20] <didrocks> and only be "on demand"
[09:20] <didrocks> but I can ensure you in the end, you will have a lot less "on demand"
[09:21] <ogra_> cjwatson, right but i want us to agree that event based should replace scheduled (scheduled can be a fallback, but shouldnt be the default if you have multiple steps depend on each other)
[09:21] <cjwatson> I don't agree with that as a rule for everything.  In many cases it makes sense
[09:22] <ogra_> cjwatson, there is obviously a requirement for bi-daily touch image builds ... when seb128 proposed that and i agreed didrocks said that wont work due to the daily process only running once a day on a schedule
[09:23] <cjwatson> I am in favour of people who understand each part of the pipeline having a mandate to make it go as fast as possible, and the flexibility to do whatever makes sense for them.  Event-based triggering of very long processes can actually slow things down in net terms because you batch less efficiently
[09:23] <didrocks> ogra_: as I told, it can be twice a day if upstream agrees to land stuff coherently twice a day
[09:23] <cjwatson> (Where "very long processes" includes human QA, too)
[09:23] <didrocks> ogra_: it's the only blocker, and as I told, it's more a social/process issues than anything else
[09:23] <ogra_> didrocks, and thats the wrong apparoach imho ... the tool should cope not the human :)
[09:23] <didrocks> ogra_: well, if they don't do that and the test coverage is good, the stuff just won't release as tests are failing :)
[09:24] <didrocks> so, let's say the sdk breaks their API
[09:24] <didrocks> most of the components won't release
[09:24] <didrocks> because they didn't handle the transition in one shot
[09:24] <ogra_> cjwatson, well, i dont say we should blindly go through the stack and ignore individual reqs :)
[09:24] <didrocks> ogra_: you should work more with upstreams to understand the concerns :)
[09:24] <ogra_> if a step needs to be different it has to be different
[09:25] <ogra_> didrocks, the tests will pass at the point wheer someone fixed the issue .,... and if upstream gets mail bombed by a test running in a loop they better do their fix :P
[09:26] <ogra_> thats not a matter of scheduled vs unscheduled
[09:26] <didrocks> ogra_: yeah, the "coherence" is just for "ensure that everything is in place at the same time to not blocking landing of our components"
[09:26] <didrocks> it is
[09:26] <ogra_> if it is not passin in scheduled it wont release either
[09:26] <didrocks> yep
[09:26] <ogra_> its is the same thing, just faster :)
[09:26] <didrocks> but again, unscheduled is in a per demand basis
[09:27] <didrocks> which is already supported
[09:27] <didrocks> in the current model
[09:27] <didrocks> the only difference is that upstream will trigger it instead of the desktop team
[09:27] <didrocks> (this on demand)
[09:27] <ogra_> right, i would like to get rid of having to use manual triggers :)
[09:28] <didrocks> but tagging the changelog *is* a manual trigger…
[09:28] <didrocks> and that's what you are proposing…
[09:28] <ogra_> i mean any manual triggers beyond that
[09:28] <didrocks> same than "launching a stack"
[09:28] <ogra_> sure, you need exactly one event to start the process
[09:28] <didrocks> the only difference is you debcommit instead of running another command
[09:28] <didrocks> which are both one event
[09:28] <ogra_> but there shouldnt need to be any other step
[09:29] <didrocks> you just argue over what needs to be starting something manually, it's one command vs one command
[09:29] <ogra_> one element of the process should trigger the next
[09:29] <ogra_> instead of having more or less well adjusted schedules
[09:29] <didrocks> yeah, so you need the image to rebuild once something in the manifest lands in the release pocket
[09:30] <didrocks> and having daily release once upstream wants it
[09:30] <didrocks> (being debcommitting the changelog or something else)
[09:30] <didrocks> which are way fewer changes to the current model
[09:30] <ogra_> well preferably i want no human interaction after committing the change to debian/changelog
[09:31] <ogra_> (the change that triggers my release)
[09:31] <didrocks> but still, I'm sure you will end up with way less releases
[09:31] <ogra_> and i dont want any scheduler involvement either :)
[09:31] <didrocks> when we had on demand release for unity, we end up with 3 months without any release because "nothing is ready"
[09:31] <didrocks> and we end up with broken trunks at runtime
[09:32] <didrocks> because they know they can fix it later on
[09:32] <ogra_> i might end up with less releases but my fix will reach the user a lot faster
[09:32] <didrocks> once they "tag for release"
[09:32] <ogra_> and changing one single element in the setup wont break the whole process
[09:32] <didrocks> I can ensure you it will diminish overall trunk quality
[09:32] <ogra_> i dont see how
[09:33] <didrocks> experience with unity/compiz/nux…?
[09:33] <ogra_> if it is broken today it wont release either
[09:33] <didrocks> because trunk isn't sacred
[09:33] <didrocks> yep, but there is no more pressure to fix it
[09:33] <didrocks> "I can break trunk now, and fix it later on"
[09:33] <ogra_> well
[09:33] <didrocks> as it will only release when I tag for release
[09:33] <didrocks> I can ensure you it's working like that
[09:34] <ogra_> "i get tired of getting that nagging mail every ten minutes, i better fix what holds up the others"
[09:34] <didrocks> filters seems to work well :)
[09:34]  * didrocks had FTBFS and all upstream filtered them to not receive them
[09:34] <ogra_> well, managers ranting at you too :P
[09:35] <didrocks> I can just ensure that daily quality will go down for individual trunks
[09:35] <didrocks> and we'll end up with big chunk of code landing at once
[09:35] <ogra_> make a rule :) trunk can break but not longer than x hours :)
[09:35] <didrocks> then -> regression -> no idea which of the 50 commits is the culpurit
[09:35] <ogra_> seriously, as a packager i have to follow some rules
[09:35] <didrocks> ogra_: acceptance criterias are "trunk never breaks"
[09:35] <ogra_> i dont see why an upstream dev cant too
[09:36] <didrocks> because they don't care about integration?
[09:36] <ogra_> you just said trunk isnt sacred
[09:36] <didrocks> I can clearly see that in ABI handling :)
[09:36] <didrocks> ogra_: I said if we just switch to on demand, they won't see it as sacred
[09:36] <ogra_> why ?
[09:36] <ogra_> they dont even see the change we do
[09:36] <didrocks> the last 20 lines? ^
[09:36] <ogra_> it happens after their involvement
[09:37] <didrocks> no, because they know it won't even try to build or release
[09:37] <didrocks> as they won't tag it
[09:37] <didrocks> and nothing will try to trigger it
[09:37] <ogra_> well so make a rule that they have to tag once the stuff is ready
[09:37] <ogra_> cant be that hard really
[09:37] <didrocks> ogra_: I'm still unsure what you want, you have schedule + on demand today
[09:37] <didrocks> you just want on demand
[09:37] <didrocks> which will result in less releases
[09:38] <ogra_> i want on demand by default :)+
[09:38] <didrocks> so you want less releases than current model?
[09:38] <didrocks> not more :)
[09:38] <ogra_> no
[09:38] <ogra_> i want faster releases than the current model
[09:38] <ogra_> no matter what the frequency is
[09:38] <didrocks> so you expect upstream tagging multiples times a day their trunk?
[09:38] <didrocks> to tell "release commit 1"
[09:38] <didrocks> "release commit 2…"
[09:39] <ogra_> well thats what i do since years ... if i work on a specific feature set it might involve multiple uploads of the same package per day
[09:40] <ogra_> and i see others doing the same
[09:40] <didrocks> I think you are not hearing me when I keep telling you that on demand is already possible, so we have a better model IMHO with regular + on demand :)
[09:40] <ogra_> i dont get why that cant be true for bzr branches
[09:40] <didrocks> the only thing I think we need to cover is "upstream can directly ask for the on demand"
[09:40] <didrocks> which is what I plan, but need some work
[09:40] <ogra_> i would like to drop the "ask" here :)
[09:41] <didrocks> ogra_: ask is a ping on IRC, ask will become a command
[09:41] <ogra_> again, what i'm proposing is on-demand by default ... across the whole process from merging to releasing the image
[09:41] <didrocks> yeah, and it's dangerous IMHO to only have that
[09:41] <ogra_> didrocks, it shoudl just monitor the changelog ...
[09:41] <ogra_> nobody should need to ask or go on IRC
[09:42] <didrocks> ogra_: patch welcomed :)
[09:42] <ogra_> if i tag the changelog, the process should just start without me worrying
[09:42] <ogra_> and in say 3h i should see an update notification on my phone
[09:42]  * popey notes 20130710 is on cdimage
[09:43] <ogra_> ah, let me re-locate
[09:43] <didrocks> popey: well, as told, the fix was in distro 4 hours after the fix was merged upstream :)
[09:43] <popey> i was more raising awareness so me and ogra_ can do our morning flashing
[09:44] <didrocks> (I'll assume the wrong the 4*8* hours time was just a typo, not an exageration :p)
[09:44] <popey> damnit, lenovo engineer here to fix my screen
[09:44] <popey> back in a bit
[09:48] <ogra_> ... our morning flashing ... that sounds so wrong ...
[09:52] <popey> ogra_: ☻
[09:52] <ogra_> :)
[09:52] <ogra_> sigh still 20min to download ...
[09:55] <popey> flashing here
[09:55] <ogra_> lucky you ...
[09:55]  * ogra_ watches bytes drip through his 2M line
[09:55] <popey> heh
[09:56] <popey> i used to have ADSL, where the upstream was often faster than the downstream
[09:56] <popey> switched to cable
[09:56] <ogra_> i have SDSL (which is my problem, no proper offer here to upgrade)
[09:57] <ogra_> the house has a to old phone system, so i have a specific line for the SDSL ... SDSL isnt a product other providers offer ... to get ADSL or VDSL in a high speed i would have to pull new wires from the street to the house
[09:59] <popey> \o/ fixed laptop
[09:59] <popey> thats 15 mins from arriving at my door to leaving, having changed the display and wrist rest on my x220!
[09:59] <popey> he's fast!
[10:01] <popey> shell looks better
[10:01] <popey> apps start
[10:03] <ogra_> great
[10:03] <ogra_> still 2 min for me
[10:04] <popey> http://popey.com/~alan/device-2013-07-10-110347.png
[10:04] <ogra_> rfect
[10:04] <ogra_> +pe
[10:04] <popey> rfectpe!
[10:04] <ogra_> :)
[10:09] <popey> mako also looks good.http://popey.com/~alan/device-2013-07-10-110922.png
[10:10] <AskUbuntu> Error setting 3G connection on Ubuntu Touch | http://askubuntu.com/q/318451
[10:10] <ogra_> yeah
[10:10] <popey> 3g doesn't start still
[10:11] <popey> Error: Connection activation failed: The connection was not supported by oFono.
[10:11] <popey> that used to work
[10:16] <ogra_> argh !
[10:16] <popey> step on some lego?
[10:16]  * ogra_ blindly fired off his sync script ... indeed it pulls from /current 
[10:17] <ogra_> another 20min ... sigh
[10:21] <popey> do we have ways to debug 3g connectivity issues?
[10:22] <davmor2> Morning all
[10:22] <ogra_> well, essentially it is just another NM connection
[10:22] <davmor2> popey: only by the minute
[10:22] <ogra_> so i guess the normal NM debug procedure applies
[10:22] <ogra_> and general netwroking stuff indeed
[10:25] <popey> oh
[10:25] <popey> it _is_ working
[10:26] <ogra_> :)
[10:26] <ogra_> what was the issue ?
[10:26] <popey> http://paste.ubuntu.com/5861195/
[10:26] <popey> i am not mad, that's working isnt it?
[10:26] <popey> not sure, I didnt do anything
[10:26] <popey> i have a script I run to bring 3g up, it gave me that error above which I've never seen before
[10:26] <popey> do we bring 3g up automagically now?
[10:27] <ogra_> Gateway:         0.0.0.0
[10:27] <ogra_> it clearly owns the default route
[10:27] <ogra_> yes, there was a mail about that ...
[10:28] <popey> and it works given I just pastebinit'ed from it and did an apt-get install of pastebinit first
[10:28] <ogra_> "Ubuntu Touch Summary (week 26)" ... and the followup mails
[10:28] <popey> ta
[10:40] <Mirv> ogra_: could you perhaps check out https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.saucy.add_documentation/+merge/173659
[10:45] <ogra_> Mirv, np, will merge soon
[10:46] <Mirv> danke schön
[10:54] <ogra_> popey, maguro works too ... moving to /current
[10:55] <popey> cool
[10:55] <popey> phablet-flash pulls from where by default?
[10:55] <popey> we had this conversation yesterday i suspect
[10:55] <ogra_> so i wonder if QA is actually working on fixing the issue
[10:56] <davmor2> ogra_: pick on balloons till he tells you ;)
[10:56] <ogra_> hmm, well, i asked sergiusens  and he said "it is easy to make it pull from /current"
[10:56] <ogra_> so i suspect it doesnt yet
[10:56] <popey> ok
[10:56] <ogra_> davmor2, for automated testing ?
[10:56]  * ogra_ thought thats rather plars
[10:56] <davmor2> ogra_: ah gema_ is possibly your best bet then
[10:57] <ogra_> yeah
[11:02] <Chipaca> hey all
[11:02] <Chipaca> I'm finally getting around to writing an ubuntu touch app :)
[11:03] <Chipaca> following http://developer.ubuntu.com/resources/tutorials/getting-started/currency-converter-phone-app/
[11:03] <Chipaca> but there's no “Projects > Ubuntu > Simple Touch UI” in qtcreator
[11:04] <Chipaca> and that was launching qtcreator, as nothing turns up in the dash when searching for 'ubuntu sdk'
[11:05] <Chipaca> not sure what i'm missing :)
[11:05] <netcurli> Chipaca: what ubuntu version do you use?
[11:05] <Chipaca> netcurli: saucy
[11:09] <netcurli> and you have installed ubuntu-sdk from the ppa?
[11:10] <Chipaca> netcurli: no; the ppa says it's not necessary for saucy
[11:11] <netcurli> Mirv: can you help with this? ^^
[11:11] <Chipaca> “Ubuntu 13.10 has Qt 5.x, Ubuntu UI Toolkit and SDK uploads directly to the archives during the development cycle.”
[11:13] <Mirv> netcurli / Chipaca: sorry, an updated Qt Creator is the only piece missing from archive, and it's hopefully finally coming this week. for now apt-add-repository ppa:ubuntu-sdk-team/ppa gives a newer Qt Creator (with the new templates among else)
[11:13] <Chipaca> Mirv: ah, ok
[11:13] <Mirv> the toolkit and others are all in the daily release, but Qt Creator is manually uploaded
[11:13] <Chipaca> Mirv: but just that ppa, not the qt5-edgers' one
[11:14] <Chipaca> right-o
[11:14] <Mirv> Chipaca: yep, just that, there's nothing of interest in the qt5-proper for saucy
[11:14]  * Chipaca dances the ppa dance
[11:15] <davmor2> so ogra_ is it safe for me to flash my galaxy nexus now?
[11:15] <Chipaca> and the apps dash now knows about 'ubuntu sdk' :)
[11:17] <Chipaca> Mirv: still no "ubuntu" visible in the new project thing
[11:19] <Chipaca> Mirv: is that bit outdated? should i just create a "qt gui application"?
[11:19] <Mirv> Chipaca: and 'ubuntu-sdk' is installed? (which pulls qtcreator-plugin-ubuntu)
[11:19] <Mirv> Chipaca: then it might be the Qt Creator configuration that is botched
[11:20] <Chipaca> Mirv: yes, ubuntu-sdk is installed
[11:20] <Mirv> Chipaca: depending on how much custom configuration you have, you could either delete the current Qt Creator configuration or take a backup
[11:20] <Mirv> Chipaca: see https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1164504
[11:20] <Chipaca> and i can run qmlscene on an ubuntu qml app without it throwing a hissy fit
[11:20] <Chipaca> i can nuke qtcreator's config no problem :)
[11:20] <Chipaca> it's not like my .emacs :-)
[11:20] <Mirv> there have been situations where people have something in the Qt Creator configuration files which prevents stuff from showing up, but everything works after nuking the config
[11:20] <Mirv> :)
[11:22] <Chipaca> now yes
[11:22] <ogra_> davmor2, it is
[11:23] <davmor2> ogra_: excellent
[11:30] <xnox> ogra_: do we have a bug tracker?
[11:30] <xnox> ogra_: for android packaging..... i have a things.
[11:40] <xnox> ogra_: how I am going to depend on linux-image-mako:armhf to build the bootimg? or does cdimage construct bootimg?
[11:51] <davmor2> popey: where is this ubuntu logo meant to be?
[11:52] <popey> what?
[11:54] <ogra_> xnox, envsetup should do it ...
[11:54] <xnox> ogra_: not without network connectivity =)
[11:55] <xnox> ogra_: colin gave me a hint on how to fetch debs from the archive at build time.
[11:55] <xnox> =)
[11:58] <ogra_> xnox, well, you can indeed build depend on all kernels
[11:59] <xnox> ogra_: how? my current thought it so poke internal mirror and fetch .deb from there, instead of doing pull-lp-bin.
[11:59] <ogra_> oh, and while currently cdimage creates the bootimg, that should indeed move into the android build again, the current setup is rather an interim solution
[12:00] <xnox> ogra_: i'm cross-building, so the arch:all build will be on :i386 needing to fetch :armhf packages.
[12:00] <xnox> ogra_: right, that will mean full android source rebuild just to get a new kernel.....
[12:00] <ogra_> xnox, you build dep on it for the all package, then change the build scripts to just cp the kernel (and modules) into the right place in your build tree
[12:01] <ogra_> oh
[12:01] <ogra_> i see what you mean now
[12:01] <xnox> ogra_: cjwatson pointed to me the grub2-signed solution http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/grub2-signed/saucy/view/head:/download-grub2
[12:02] <ogra_> right, you definitely have archive access
[12:02] <xnox> it's a full, non-split mirror. so i could initiate new cache with armhf & fetch armhf packages.
[12:03] <ogra_> yeah
[12:03] <xnox> ogra_: but do we really want to rebuild full android to get the new kernel into system & bootimage.... well i guess at the moment we are changing a lot of bits....
[12:03] <ogra_> do you do actual cross building or do you have a fakechroot you build in ?
[12:04] <ogra_> i think the latter would be easier so you could just apt-get install what you need ... but indeed the above will wrok
[12:04] <xnox> ogra_: yeah, it's cross-compile of everything. But kernel is pre-build.
[12:04] <xnox> ogra_: right I'll file a bug.
[12:04] <ogra_> right, yeah, then you need to fetch the deb from pool
[12:05] <xnox> ogra_: ideally those kernels would be somehow shipped as arch:all packages as well.
[12:05] <ogra_> thats tricky, they are native builds
[12:05] <xnox> yeah...
[12:05] <ogra_> the meta could become arch all probably
[12:05] <ogra_> but that doesnt help you if you cant access the arch at all
[12:06] <ogra_> you could indeed use a fakechroot as a side thing
[12:07] <ogra_> just to pull the packages and copy the binaries over as needed
[12:08] <ogra_> but that would use qemu-debootstrap, which in turn needs to update binfmt handling of the build host, not sure that can work
[12:44] <janimo`> ogra_, hi, is N4 not booting into a GUI with the image flashed this morning a known issue?
[12:45] <ogra_> janimo`, well it was tested and worked
[12:45] <janimo`> ogra_, hmm I must need to do something other than just plain phablet-flash then
[12:45]  * janimo` will try again
[12:46] <janimo`> maybe I did not use the latest phablet tools thinking there's no need for a PPA if on saucy
[12:47] <ogra_> there isnt
[12:47] <janimo`> ogra_, good to know. Then this is out of date
[12:47] <janimo`> https://wiki.ubuntu.com/Touch/Install
[12:48] <janimo`> "The PPA has the tools and dependencies to support Precise, Quantal, Raring and Saucy. Add the Ubuntu Touch PPA by adding the following custom source "
[12:48] <ogra_> mind to fix that ?
[12:49] <janimo`> ogra_, so not needed for saucy but needed for all previous ones?
[12:49] <janimo`> I did not fix as I do not know the situation
[12:49] <ogra_> yeah
[12:51] <janimo`> ogra_, oh weird. I looked at the phone again after a few hours of leaving it and it has a GUI
[12:51] <janimo`> most strange
[12:51] <ogra_> heh
[12:51] <ogra_> slow boot
[12:51] <ogra_> :)
[12:51] <janimo`> it hung at the Google logo and only adb worked this morning
[12:52] <janimo`> we need to improve boot itme by 3 orders of magnitude then :)
[12:52] <pmcgowan> there are certainly races at boot
[12:52] <pmcgowan> especially on first flash
[12:52] <ogra_> janimo`, we need Mir and lightdm before working on that
[12:53] <janimo`> pmcgowan, if it is something that can occur on first boot it's ok by me. I just did not try UTouch in a couple months and I thought I may be way out of sync with the install procedures
[12:53] <ogra_> pmcgowan, races are being worked on
[12:53] <pmcgowan> indeed
[12:53] <janimo`> ogra_, so is Mir replacing SF this week?
[12:54] <ogra_> haha
[12:54] <ogra_> this month if we are lucky
[12:54] <janimo`> ogra_, just because I heard that would happen Real Soon Now two months ago as well :)
[12:55] <ogra_> it will happen *real soon* !! in the light of the age of the galaxy
[12:58] <pmcgowan> cyphermox_, whats the networking behavior now with 3g data on by default? there is a thread on how to control it
[12:58] <cyphermox_> where is that?
[12:58] <cyphermox_> on the mailing list?
[12:58] <pmcgowan> yes
[12:58] <pmcgowan> cyphermox_, re the weekly update
[13:03] <Saviq> ogra_, uh oh "WARN: / is world writable!\nWARN: / is group writable!"??
[13:04] <ogra_> Saviq, where do you get that
[13:04] <Saviq> ogra_, freshly flashed maguro
[13:04] <ogra_> no, i mean what spits that warning ?
[13:04] <Saviq> ogra_, apt-get install ssh
[13:04] <Saviq> ogra_, manta, too
[13:04] <ogra_> well just ignore
[13:04] <popey> yeah
[13:05] <ogra_> thats the current setup ... wll change soon
[13:05] <Saviq> ogra_, ok, simply didn't see that before
[13:05] <ogra_> wasnt there on unflipped for sure :)
[13:06] <Saviq> ogra_, I don't think it was there before today, but might be wrong there :)
[13:06] <ogra_> well, / is world writable since we flipped
[13:07] <cyphermox_> pmcgowan: I can answer as how to control it, but I don't know about when things land
[13:07] <cyphermox_> pmcgowan: landing an UI control is dependent on renato's branch
[13:08] <Saviq> ogra_, ok, never noticed that before, sorry for the noise, then
[13:08] <pmcgowan> cyphermox_, I thinkt he question is what folks should do today
[13:08] <cyphermox_> use nmcli.
[13:08] <cyphermox_> just like before to connect the mobile data, except you don't need to explicitly connect it
[13:09] <esigolo> cyphermox_: what do you mean by that ?
[13:09] <popey> i have two scripts in my home directory, up.sh and down.sh which just use nmcli to do it
[13:09] <ogra_> add ril0 to /etc/network/interfaces
[13:09] <cyphermox_> esigolo: by what?
[13:09] <cyphermox_> ogra_: not really
[13:09] <esigolo> cyphermox_> just like before to connect the mobile data, except you don't need to explicitly connect it
[13:09] <ogra_> cyphermox_, that wont make NM ignore it ?
[13:09] <cyphermox_> esigolo: cf. my response on the mailing list
[13:10] <cyphermox_> ogra_: maybe, but that's not the right way to do it ;)
[13:10] <cyphermox_> esigolo: basically, you can use nmcli to control everything NM does
[13:10] <ogra_> cyphermox_, thats a quick hack for people that dont want 3G
[13:10] <cyphermox_> esigolo: instead of having to manually connect, now it just brings up the connection automatically like it should
[13:11] <esigolo> cyphermox_: ahh sorry
[13:11] <ogra_> i didnt mean to provide something proper :)
[13:11] <esigolo> I thought that now he would connect himself with a connection available
[13:11] <cyphermox_> esigolo: however you will need to disconnect manually if you want to disconnect
[13:11] <cyphermox_> ogra_: probably works well as a quick hack, yeah
[13:12] <cyphermox_> esigolo: that is what happens -- if there is an available APN to connect to, and you're registered to the network and have GPRS, then you'll get connected
[13:12] <cyphermox_> renato_: around? can we discuss fixing your indicators-client branch today to get people a nicer UI ? :)
[13:13] <esigolo> cyphermox_:would by helpfull if i compile some config files for connections?
[13:13] <esigolo> cyphermox_: to use as example?
[13:13] <cyphermox_> esigolo: not really, it depends on a package named mobile-broadband-provider-info
[13:14] <esigolo> cyphermox_: sure. :)
[13:14] <rickspencer3> hey all, do we still need to create a nm config on our desktops and copy to our phones and all that to get data working?
[13:15] <cyphermox_> rickspencer3: not if you have the right provider information on your desktop without modifying the files
[13:15] <rickspencer3> cyphermox_, not sure what you mean
[13:15] <cyphermox_> rickspencer3: normally you shouldn't, but it depends on what is in mobile-broadband-provider-info and if ofono is able to figure out the provider for you
[13:16] <ogra_> rickspencer3, it should just connect now
[13:16] <rickspencer3> cyphermox_, how should I test out if I need to do the whole create the config and copy it over thing?
[13:17] <cyphermox_> rickspencer3: if it doesn't successfully connect as you boot the phone (or within 5 minutes), then check the files under /var/lib/ofono/*/gprs
[13:17] <ogra_> thats the point you shouldnt need to anymore
[13:18] <rickspencer3> cyphermox_, ok, so I bought a new SIM with data
[13:18] <rickspencer3> popped it in
[13:18] <rickspencer3> no connection
[13:18] <cyphermox_> new SIM is probably not known in the database
[13:18] <rickspencer3> got back the apartment, it connected to my wifi (which I configured yesterday)
[13:18] <rickspencer3> I disconnected the wifi
[13:18] <rickspencer3> no data (so far as I can see)
[13:19] <davmor2> rickspencer3: what happens if you do a flash with the new sim in?
[13:19] <cyphermox_> rickspencer3: could you ship me the contents of /var/lib/ofono by email?
[13:19] <cyphermox_> rickspencer3: and I'll need to know what provider you use, to check if the settings are correct
[13:20] <rickspencer3> cyphermox_, ok
[13:20] <rickspencer3> cyphermox_, should I update first?
[13:21] <rickspencer3> my image is from Monday morning
[13:22] <popey> rickspencer3: todays image is good AFAICT
[13:23] <rickspencer3> hmmm
[13:23] <rickspencer3> I can't figure out how to input international numbers :/
[13:23] <rickspencer3> trying to text the US :/
[13:23] <rickspencer3> Send button stays insensitive :(
[13:24] <davmor2> 001 for us iirc
[13:25] <rickspencer3> ah, an extra 0
[13:25]  * rickspencer3 tries
[13:25] <rickspencer3> no love
[13:26] <popey> nope
[13:26] <popey> +(countrycode) (area) number
[13:26] <popey> is the GSM standard for numbers, no need for additional zeroes
[13:26] <popey> so +1 555 1234 or whatever ☻
[13:27] <rickspencer3> popey, does that work when you compose a message?
[13:27] <popey> I haven't tried, will try now
[13:27] <popey> if it doesn't it's a bug
[13:28] <cyphermox_> Rick, I also can't text for some reason
[13:28] <popey> the phone app is really laggy / unresponsive for me
[13:29] <rickspencer3> popey, so, I can't tell how to enter phone numbers so that they work with international texting
[13:29] <rickspencer3> unless I am doing it correctly and the messaging app is horked
[13:29] <popey> hold down 0 for +
[13:29] <popey> yeah, I can't figure that out either
[13:29] <rickspencer3> popey, that's only available in the dialer
[13:29] <popey> right, so you want to text someone who isn't a contact..
[13:30] <popey> got it
[13:30] <popey> conversations, swipe up from bottom, compose
[13:30] <popey> in the To: field, type +1 nnn nnnn
[13:31] <popey> tap compose field, type your message, press send.
[13:31] <sergiusens> popey: rickspencer3 you have the full keyboard, so you could just go to the symbols part
[13:31] <rickspencer3> and I don't want to manually enter every international number I try
[13:31] <rickspencer3> so, the scenario is, I have in Germany, with a German SIM, and I want to text my wife, who is in my contacts, and has a US number
[13:31] <rickspencer3> I can't figure out the UI for this
[13:31] <popey> rickspencer3: http://popey.com/~alan/device-2013-07-10-143127.png  <- thus
[13:32] <popey> edit her contact rickspencer3
[13:32] <popey> change her contact so it's +1 nnnnnn
[13:32] <popey> on android/ios I _always_ store contacts in that format, so it works when roaming with no effort
[13:38] <rtg> jdstrand, how are the ufw tests with todays touch image ?
[13:39] <jdstrand> rtg: grouper, mako and manta are all fine. something failed on maguro, let me see what it is
[13:41] <jdstrand> rtg: actually, maguro is fine too. the first test run seems to have been aborted, but the second passed (though the highlevel report shows it as failed)
[13:41] <jdstrand> rtg: in others words: we're good! :)
[13:41] <rtg> jdstrand, hey, that works for me.
[13:41] <rtg> apw, ^^
[13:43] <jdstrand> gema_: hey
[13:43] <jdstrand> gema_: if I look at http://reports.qa.ubuntu.com/smokeng/saucy/, it shows maguro as '75%'
[13:43] <esigolo> who is taking care about calendar app?
[13:44] <jdstrand> gema_: however, if I click through to http://reports.qa.ubuntu.com/smokeng/saucy/image/2909/, I see that the security test failed at 2013/07/10 06:07, but then passed at 2013/07/10 11:07. shouldn't http://reports.qa.ubuntu.com/smokeng/saucy/ show as 100% since a later test passed?
[13:44] <apw> rtg ... yay
[13:46] <gema_> jdstrand: let me see
[13:47] <gema_> jdstrand: no it shouldn't, the reason it was designed like that is because we didn't want to hide any past failures under the carpet
[13:47] <gema_> jdstrand: now your tests are passing so you are good
[13:47] <gema_> jdstrand: did the previous run fail due to environment?
[13:47] <jdstrand> gema_: I see. ok, if its intended, fine
[13:48] <jdstrand> gema_: re previous failure> it looks like it never ran the tests, it failed before
[13:48] <gema_> jdstrand: ok, so there is no bug attached to it or real reason for the failure
[13:48] <jdstrand> gema_: https://jenkins.qa.ubuntu.com/job/saucy-touch-maguro-smoke-security/18/console - looks like scp failed
[13:49] <jdstrand> gema_: so yeah, not my problem :)
[13:49] <gema_> jdstrand: we have ways of hiding runs if they are very problematic, I'd say leave this one there and let's keep an eye on that scp
[13:49] <gema_> jdstrand: just in case there is something in the environment htat needs fixing
[13:49] <gema_> or in the lab
[13:50] <popey> ogra_: is there some magic update to adb to make it not need root?
[13:50] <gema_> jdstrand: maguro seems to be a bit unstable
[13:50] <jdstrand> gema_: on an unrelated note, should I file a bug for adding these security tests to the desktop and server smoke tests? I realize it might not be a high priority, but I'd like for it to not be forgotten either
[13:50] <popey> the old issue we had where we had to start the adb server under sudo
[13:50] <ogra_> popey, we somply start it as root
[13:50] <gema_> jdstrand: let me find you a blueprint for that
[13:50] <ogra_> popey, oh, you mean the PC side
[13:50] <popey> yes
[13:50] <ogra_> might need fixes to the udev rules
[13:51] <popey> is there a bug for it?
[13:51] <ogra_> i thik they dont match properly anymore
[13:51] <popey> on precise it seems broken still
[13:51] <gema_> jdstrand: I am going to add it to our backlog (https://blueprints.launchpad.net/ubuntu/+spec/qa-s-backlog)
[13:51] <ogra_> popey, not sure, sergiusens would know i guess ... worst case just file a new one
[13:51] <jdstrand> gema_: may I just add a work item?
[13:51] <popey> ok
[13:52] <gema_> jdstrand: I am adding two for you
[13:52] <gema_> trying to figure out who should do it
[13:52] <jdstrand> awesome, thanks :)
[13:52] <esigolo> Anyone knows if we are going to use google maps or we another option for maps?
[13:52] <gema_> jdstrand: I gave them to plars, he'll dispatch them if needed
[13:52] <jdstrand> much appreciated :)
[13:52] <ogra_> esigolo, someone was working on a port of navit
[13:52]  * ogra_ doesnt remember who
[13:53] <esigolo> ogra_: great
[14:03] <Mirv> seb128: FYI I found myself some time to check the qtsystems a bit, and reported my findings at the bug report I noticed being talked about https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1197542
[14:06] <Mirv> mterry: you were btw also talking about some patch last week if I recall correctly, but I didn't hear anything more of that
[14:07] <Mirv> mterry: related to that qtsystems
[14:07] <mterry> Mirv, looks like it won't be necessary after all
[14:07] <seb128> Mirv, thanks
[14:07] <mterry> Mirv, it was a bug, but I'll just try to get it upstream, no need to rush yet with a distro patch
[14:08] <esigolo> ogra_: qemu is already working?
[14:08] <ogra_> not for touch images, no
[14:08] <pete-woods-lunch> mhall119: hi - I was looking to publish the docs from the library I'm working on in the same way as mir does - is this something you can help me with?
[14:08] <esigolo> :(
[14:08] <rickspencer3> mhall119 would know
[14:08] <Mirv> mterry: ok, thanks
[14:08] <rickspencer3> mhall119 how do I send a text to an international number
[14:09] <rickspencer3> i.e. text a US phone from Germany
[14:09] <ogra_> +01 $number
[14:09] <ogra_> should theoretically work
[14:09] <rickspencer3> ogra_, I have tried that so many times
[14:09] <rickspencer3> the send button stays insensitive
[14:09] <ogra_> oh
[14:09] <ogra_> sounds like a UI bug
[14:09] <rickspencer3> ogra_, don't forget, this is a text, so I don't get the dial pad
[14:09] <rickspencer3> I have to use the "+" from the osk
[14:10] <ogra_> yeah
[14:10] <rickspencer3> I have no idea if it's the right character, etc...
[14:10] <rickspencer3> I'll update the image and try again
[14:10]  * ogra_ still has no company SIM to test such stuff
[14:10] <mhall119> pete-woods: what documentation do you want up there?
[14:11] <mhall119> rickspencer3: Sorry, I have no experience with that, as I have a CDMA phone which doesn't even work overseas
[14:11] <pete-woods> mhall119: so I'm working on https://launchpad.net/libusermetrics - one of the unity APIs
[14:11] <pete-woods> and we want to get people making data sources for the greeter infographic
[14:11] <pete-woods> and figured getting the docs online would be sensible
[14:11] <pmcgowan> ogra_, bye a sim
[14:11] <ogra_> :)
[14:11] <mhall119> pete-woods: would this make more sense to go on developer.u.c?
[14:11] <pmcgowan> happroved
[14:12] <ogra_> ok
[14:12] <ogra_> will do
[14:12] <pete-woods> mhall119: err, what's developer.u.c?
[14:12] <pete-woods> oh
[14:13] <pete-woods> mhall119: d'oh :$ yeah, that would be good too!
[14:20] <popey_> victorp: i just enabled developer mode on my nexus 7 using ubuntu sdk, only bug 1199804 hit me, but i worked around that, and don't think that's what you hit.
[14:20] <popey_> victorp: also created sample app and sent to device and it's running
[14:21] <victorp> popey_, mmm, oh well. Must be my set up
[14:21] <victorp> popey_, thank you for checking it out
[14:21]  * didrocks saw libusermetrics
[14:21] <didrocks> pete-woods: if you want your branch still building on saucy, you will need: https://code.launchpad.net/~didrocks/libusermetrics/build-new-gmock/+merge/173945
[14:22] <pete-woods> didrocks: okay, will grab it :)
[14:22] <didrocks> pete-woods: I have nothing against a review + approve btw (just ensure you have google-mock 1.6.0+svn437-0ubuntu1) :)
[14:23] <pete-woods> didrocks: well I'll probably move the stuff back out into a FindLocalGMock.cmake module
[14:23] <pete-woods> instead of having it all inline
[14:24] <didrocks> pete-woods: want me to do that, and just include it?
[14:24] <didrocks> pete-woods: for all the other components, we have done that inline, but I have nothing against the internal module approach :)
[14:25] <pete-woods> didrocks: that'd be cool :)
[14:25] <pete-woods> I guess we want this done quickly, as otherwise I'll start blocking the indicator stack releases
[14:26] <didrocks> pete-woods: exactly (as soon as you have a new commit pending in it)
[14:26] <didrocks> pete-woods: one sec, doing that + a sanity rebuild
[14:26] <pete-woods> cool
[14:31] <didrocks> pete-woods: rev 93 pushed, builds fine, tests pass
[14:31] <pete-woods> didrocks: woot!
[14:36] <pete-woods> didrocks: could you change it so that the module doesn't force include_directories? - i.e. move the include_directories lines outside the module
[14:39] <didrocks> pete-woods: ok, so you want that including the module itself not being enough, but an explicit include_directories in test/CMakeLists.txt, right?
[14:40] <pete-woods> didrocks: yeah, so that it behaves like a standard FindThingy.cmake module
[14:40] <didrocks> pete-woods: something like that: http://paste.ubuntu.com/5861813/?
[14:40] <pete-woods> didrocks: exactly!
[14:41] <didrocks> pete-woods: ok, committed and pushed (rev 94) :)
[14:42] <dpm> tmoenicke, for some days I've been unable to use the search feature on the Apps scope to find apps on my device: whenever I type a character, the keyboard hides and the character is not recorded. Is this a known bug? And if not, where can I report it?
[14:43] <tmoenicke> dpm: yep I have a fix for that, should land soon
[14:43] <dpm> ok, cool, good to know you're on it, thanks tmoenicke
[14:44] <sil2100> tvoss_: hi!
[14:44] <pete-woods> didrocks: fantastic, will pull your branch now!
[14:44] <didrocks> pete-woods: sweet ;)
[14:44] <tvoss_> sil2100, hey, how goes?
[14:45] <sil2100> tvoss_: pretty well - I have been wondering about the ubuntu-platform-api-headers package from platform-api
[14:45] <sil2100> tvoss_: it's a transitional package, yes?
[14:46] <sil2100> tvoss_: since I'm trying to build qtvideo-node, it requires ubuntu/ui/config.h but can't find it even though I have libplatform-api-headers and ubuntu-platform-api-headers installed
[14:47] <sil2100> (on i386)
[14:47] <sil2100> (or amd64 even)
[14:48] <tvoss_> sil2100, that header was removed in a recent mp
[14:49] <sil2100> Oh, what about applications that use that?
[14:49] <didrocks> tvoss_: btw, did you see my ping for https://code.launchpad.net/~didrocks/mir/use-system-googlemock/+merge/173008? would be good to get that action done :)
[14:51] <didrocks> pete-woods: I see you merge directly to trunk, it seems though you have the upstream merger setup, don't you?
[14:52] <pete-woods> didrocks: yeah, I just didn't want to wait for breaking anybody
[14:52] <didrocks> pete-woods: ok, the changelog will have wrong author, but I don't care ;)
[14:52] <didrocks> (as long as it's building fine as done locally ;))
[14:52] <pete-woods> yepp!
[14:54] <rickspencer3> bfiller, who would be the right person to write a test to confirm that sending a text to an international number works and keeps working?
[14:54] <tvoss_> sil2100, yes, saw the ping, but it's failing ci
[14:58] <didrocks> tvoss_: not sure if you wanted to speak to sil2100 or me, but if it's me, the failing ci is before the new gmock was in distro
[14:58] <didrocks> as you can see by the date :)
[14:59] <sil2100> tvoss_: I was asking about the removed header ;p
[14:59] <sil2100> tvoss_: did you bump upstream version? Since a header removal is an API break, hope all projects that use it are ready for re-writing
[15:01] <tvoss_> sil2100, I *think* I did :)
[15:05] <didrocks> tvoss_: no worry, I'll find someone to do the Mir review, it seems you are busy
[15:06] <tvoss_> didrocks, that would help me
[15:09] <davmor2> popey: if you open notes do you get 2 app preview windows in the apps lens?
[15:09] <popey> davmor2: yes
[15:09] <ogra_> these are backup notes :)
[15:09] <ogra_> j/k
[15:09] <sil2100> tvoss_: from where should I now fetch the info about UBUNTU_USE_GLES ?
[15:10] <popey> RAIN (Redundant Array of Inexpensive Note-taking-apps)
[15:10] <popey> or something
[15:10] <tvoss_> sil2100, I don't think you need that
[15:10] <tvoss_> sil2100, should work perfectcly fine without the macro
[15:11] <sil2100> tvoss_: what should I use instead? Since in qtvideonode this macro was used in an #if
[15:11] <tvoss_> sil2100, mind pinging me the branch again?
[15:11] <sil2100> tvoss_: which one ;) ?
[15:11] <tvoss_> sil2100, the qtvideonode :)
[15:12] <sil2100> tvoss_: https://code.launchpad.net/~phablet-team/qtvideo-node/trunk
[15:12] <sil2100>  lp:qtvideo-node
[15:12] <sil2100> ;)
[15:12] <sil2100> http://bazaar.launchpad.net/~phablet-team/qtvideo-node/trunk/view/head:/src/shadervideomaterial.cpp <- here is the usage
[15:12] <tvoss_> sil2100, looking
[15:13] <bfiller> rickspencer3: boiko probably
[15:15]  * xnox ponders to use ccache while building x4 images =))))
[15:16] <tvoss_> sil2100, a question though: isn't qtvideo node built by the daily release machinery?
[15:17] <sil2100> tvoss_: yes, it is
[15:18] <sil2100> tvoss_: but there hasn't been much development recently, so we didn't know it doesn't build
[15:18] <sil2100> tvoss_: and now it no longer builds
[15:21] <tvoss_> sil2100, hmmm, where can I see the build status in general?
[15:22] <sergiusens> xnox: watch out with ccache, it may fail to build with weird reasons, so wipe it after every repo sync (or similar)
[15:22] <xnox> sergiusens: yeah, and it's not parallel safe.
[15:22] <xnox> sergiusens: i am thinking to create a bank cache: build 4 images, wipe cache. Should help a lot on the latter 3 images.
[15:24] <sil2100> tvoss_: I was building it locally, since it was last built 2013-06-07
[15:24] <sil2100> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4649996
[15:24] <sil2100> tvoss_: building locally fails because ubuntu/ui/config.h is missing
[15:24] <swordfish> Hello popey! I'm sorry to bother you but I just wanted to tell that yesterday i pushed some big changes to my minesweeper application. I think you should update the collection ppa... Thanks!..
[15:24] <sil2100> When I remove that include, it works, but I guess on armhf it might fail then
[15:24] <tvoss_> sil2100, sure
[15:24] <popey> ok swordfish will do!
[15:25] <popey> thanks!
[15:25] <swordfish> you're welcome!... Today i officially finished my exams, so I will dedicate more time to the cause :D ....
[15:39] <RoTec> hi everyone I have a quick question. on the wiki it says that the grouper images aren't working properly. is that still true? I bought a grouper (wifi, 32GB) a few days ago and was just about to flash the daily when I remembered that
[15:44] <ogra_> RoTec, works for me
[15:44] <ogra_> could be snappier but works
[15:45] <davmor2> popey: weirdly I see no networks once I connect to the wifi is that because it doesn't know how to display being connected to 2 currently?
[15:46] <RoTec> awesome thanks. I'll try it later
[15:48] <rtg> rsalveti, do you know of any gcc-4.8 changes that might have changed whether a bootable kernel can be built ? I was just reviewing bugs against the Nexus kernels and stumbled across bug #1176255 (which reminded me that _none_ of Nexus the kernels are built with the standard compiler).
[15:49]  * davmor2 puts ogra_ 's n7 in a crocodile , there you go that should be much snappy for you :)
[15:50] <ogra_> yay !
[15:50]  * ogra_ likes living on the edge
[15:51] <mfisch> sfeole`: okay, so what exactly is happening on the n4?
[15:53] <mfisch> sfeole: you have the screen off, not suspended, and the on/bright request doesn't turn it back on?
[15:53] <sfeole> mfisch: via powerd-cli , I can issue requested states such as "powerd-cli display on dim"  a cookie is issued but the display still remains off.  Prior to doing this I made sure in a separate window that I issued an active request, "powerd-cli active"
[15:53] <mfisch> sfeole: okay let me try it here
[15:53] <sfeole> mfisch: this works on the N7 but not the N4
[15:53] <mfisch> give me 1 minute to finish up another test
[15:55] <rsalveti> rtg: no, didn't investigate that further
[15:56] <rsalveti> I can take another look into that, got the uart cable for n4 here now
[15:56] <mfisch> rsalveti: where is the code that makes the power button bring up the welcome screen?
[15:56] <rsalveti> but I guess you can boot the broken kernel once, and reboot to recovery later, and check last_kmsg
[15:57] <rsalveti> mfisch: Saviq might knkow better
[15:57] <rtg> rsalveti, I'll give that a try.
[15:57] <Saviq> mfisch, lp:unity8/Shell.qml:122
[15:58] <mfisch> Saviq: is that a design decision? pmcgowan filed a bug on it against powerd
[15:59] <mfisch> sfeole: well, it works for me :(
[15:59] <mfisch> sfeole: can you get me the contents of tail -f /var/log/syslog | grep powerd when you do it?
[15:59] <Saviq> mfisch, the fact that it animates on power press?
[16:00] <mfisch> Saviq: let me give you a use case. You're on a call, the screen times out because you don't hit anything. You press power to get the screen back. You see the call screen, but then the Welcome screen animates over top
[16:00] <mfisch> pmcgowan was saying that pressing the power button in that case to turn the screen on should just take you back to the call
[16:00] <Saviq> mfisch, yeah, that's wrong obviously
[16:00] <Saviq> mfisch, I mean the current behaviour
[16:01] <mfisch> Saviq: since powerd is not doing it, I wanted to move the bug to someehwere it would get attention
[16:01] <Saviq> mfisch, but it's a shell bug rather than a powerd one
[16:01] <mfisch> agreed ;)
[16:01] <Saviq> mfisch, unity8
[16:01] <mfisch> Saviq: thanks
[16:01] <Saviq> mfisch, we actually already have a similar bug (but obviously I can't find it...)
[16:01] <sfeole> mfisch: working on it here, 1 sec
[16:01] <sforshee> Saviq, mfisch: about display requests not working ...
[16:02] <sforshee> sorry, I meant sfeole, not Saviq
[16:02] <Saviq> got it! bug 1186256
[16:02] <Saviq> sforshee, 's fine
[16:02] <sforshee> anyway, if the screen is turned off using the power button that acts as an override of the requested screen state
[16:02] <mfisch> Saviq: shall I dupe?
[16:02] <mfisch> here's this one: https://bugs.launchpad.net/unity8/+bug/1187545
[16:03] <mfisch> sforshee: I think sfeole was just letting the screen timeout
[16:03] <mfisch> sforshee: but that sounds like another good test case
[16:03] <sfeole> sforshee: if the requested screen state is overridden via a power button does it kill off that old screen state?
[16:04] <Saviq> mfisch, powerd won't send SysPowerStateChange when on a call,right?
[16:04] <Saviq> mfisch, so assuming we listen to that we should be golden?
[16:04] <mfisch> Saviq: no, we will not suspend
[16:04] <mfisch> Saviq: I think so
[16:04] <Saviq> mfisch, k, dupe'ing, then
[16:05] <sfeole> mfisch: working for me now, i may have pressed the power button 1 first attempt
[16:05] <mfisch> sfeole: ok, thats a good test case to add then
[16:05] <andrewhaigh_cell> hi all, i have a Qt Creator/ubuntu SDK question: The debugger doesnt work for me, I get "Unable to read JIT descriptor from remote memory!" . I know its a gdb bug, but does anyone know the solution/why I get it?
[16:37] <WebbyIT> Hi mzanetti. I have to implement a TimePicker for ubuntu-calendar-app, and oSoMoN said me to talk with you
[16:38] <mzanetti> WebbyIT: oSoMoN is right :)
[16:38] <mzanetti> WebbyIT: one sec
[16:38] <mfisch> sfeole: we need to talk when you get back
[16:38] <sfeole> mfisch: i'm here
[16:38] <mfisch> andrewhaigh_cell: You may get a better answer on the mailing list if nobody here knows
[16:39] <mfisch> sfeole: sorry bro, I mean sforshee
[16:39] <andrewhaigh_cell> mfisch: ok, thank you
[16:39] <sfeole> mfisch: np bronski
[16:39] <mfisch> we need to limit this channel to 52 people, 1 for each capital and lowercase letter
[16:39] <mzanetti> WebbyIT: here's a video: http://notyetthere.org/?p=217
[16:40] <mzanetti> WebbyIT: and here's the code: https://github.com/mzanetti/fahrplan/tree/master/src/gui/ubuntu/components
[16:40] <ogra_> mfisch, thats cool, and each can be OP for exactly one week then
[16:41] <WebbyIT> mzanetti: awesome! Can I use it?
[16:41] <mzanetti> WebbyIT: ofc
[16:41] <WebbyIT> mzanetti: thanks you :)
[16:42] <mfisch> sfeole: can you help me test something?
[16:43] <sfeole> mfisch: sure
[16:47] <esigolo> popey: I'm trying to buy an oppo! Hard to find it here (Brazil) :(
[16:54] <mfisch> rsalveti: can you answer a hybris question since Chicken is out?
[16:54] <rsalveti> mfisch: sure
[16:54] <mfisch> rsalveti: android_input_stack_stop() is hanging when powerd tries to exit
[16:55] <mfisch> rsalveti: any ideas on how to track that down further?
[17:04] <mfisch> rsalveti: it seems to not hang if we abort our startup (which happens when a 2nd copy is running)
[17:04] <mfisch> rsalveti: so maybe we have something still in-use that causes this
[17:05] <rsalveti> mfisch: hm, right
[17:05] <rsalveti> let me see
[17:07] <rsalveti> Stskeeps: hey, do know you if we have any other upstream for timed besides http://gitorious.org/meego-middleware/timed?
[17:07] <rsalveti> Stskeeps: we're also investigating what is needed to use that, and want to make sure we're using what ever is more recent and upstream :-)
[17:07] <Stskeeps> github.com/nemomobile/timed , has qt5 port
[17:08] <rsalveti> Stskeeps: awesome, thanks
[17:13] <fredoust> balloons, http://paste.ubuntu.com/5862263/
[17:13] <fredoust> I got this error on installing this packages
[17:13] <balloons> fredoust, did you add the ppa?
[17:14] <fredoust> yes
[17:14] <balloons> also, what distro are you running?
[17:14] <balloons> quantal, raring, saucy/
[17:14] <balloons> precisE?
[17:15] <balloons> fredoust, ^^
[17:16] <fredoust> sorry trying something
[17:16] <fredoust> 12.04.2 LTS
[17:16] <fredoust> precise
[17:17] <balloons> fredoust, ahh that's the trouble. The new stuff needs raring or saucy
[17:18] <fredoust> ok thanks I will update
[17:19] <balloons> fredoust, a VM works fine if you wish
[17:19] <fredoust> Yes I am on a VM
[17:19] <rsalveti> mfisch: global_state->input_reader_thread->requestExitAndWait();
[17:19] <rsalveti> that's probably the reason
[17:20] <rsalveti> tvoss_: hey, we want to call android_input_stack_stop without getting stuck
[17:21] <esigolo> rsalveti: flashing the last  image here (mako) any test needed? :)]
[17:22] <rsalveti> esigolo: ofono should be working better on this one, you might only get bug 1199575
[17:22] <fredoust> thanks again balloons
[17:22] <rsalveti> awe_: mind sending one email to ubuntu-touch announcing how to manually unlock the sim card?
[17:22] <rsalveti> that will help people in europe it seems
[17:22] <rsalveti> ogra_: ^^^
[17:22] <rsalveti> in case you want to test that as well
[17:22] <ogra_> ++
[17:22] <ogra_> !
[17:23] <esigolo> rsalveti: okay !
[17:26] <mfisch> rsalveti: I've been waiting 10 minutes, I don't think that thread is going to exit
[17:26] <rsalveti> mfisch: even after pressing the button again?
[17:27] <mfisch> rsalveti: this happens when powerd shuts down, nothing to do with a button
[17:27] <rsalveti> mfisch: right, just trying to compare with the behavior in test_input
[17:28] <rsalveti> but that uses android_input_stack_start_waiting_for_flag instead
[17:28] <mfisch> sforshee: android_input_stack_stop()
[17:28] <rsalveti> check from libhybris soruce
[17:28] <mfisch> sforshee: android_input_stack_stop() gets hung when we try to shutdown
[17:28] <rsalveti> hybris/tests/test_input.c
[17:28] <mfisch> rsalveti: looking
[17:31] <tvoss_> rsalveti, need dinner, drop me a mail with the issue please
[17:31] <rsalveti> mfisch: ^
[17:31] <rsalveti> tvoss|dinner is the one that created that compat layer
[17:32] <mfisch> rsalveti: pressing the power button allows powerd to die
[17:32] <mfisch> sforshee: ^
[17:32] <rsalveti> right, so it seems it waits for at least one more input
[17:32] <rsalveti> we need to be able to exit before that
[17:33] <sforshee> mfisch: so I'd guess the input thread is stuck in epoll()
[17:33] <rsalveti> yeah
[17:33] <mfisch> is that an issue in hybris?
[17:34] <rsalveti> mfisch: well, in the input compat layer
[17:34] <mfisch> rsalveti: okay, but not in how powerd uses it
[17:34] <mfisch> rsalveti: I'd like to move this bug out of powerd, where is the input compat bucket?
[17:35] <rsalveti> mfisch: you can file the bug against libhybris, and assign that to tvoss|dinner
[17:35] <mfisch> rsalveti: will do
[17:36] <rsalveti> wonder if that would work better if we use requestExit() instead of requestExistAndWait
[17:37] <esigolo> rsalveti: what is the point to requestExistAndWait ? wait for?
[17:38] <rsalveti> wait for the thread to exist
[17:38] <pmcgowan> rsalveti, unity8 is running twice
[17:38] <rsalveti> *exit
[17:38] <pmcgowan> rsalveti, htop must be reporting each core
[17:38] <rsalveti> pmcgowan: oh, how that?
[17:38] <pmcgowan> I must be reading this wrong
[17:38] <rsalveti> maybe something crashed and made ubuntu-touch-session restart itself
[17:38] <sforshee> rsalveti, mfisch: I don't see a need to wait
[17:39] <pmcgowan> htop shows lots of double entries
[17:39] <rsalveti> sforshee: yeah
[17:39] <rsalveti> mfisch: let me get you a binary with that change
[17:39] <mfisch> rsalveti: https://bugs.launchpad.net/libhybris/+bug/1199897
[17:39] <mfisch> rsalveti: thanks
[17:40] <mfisch> rsalveti: after you do that can we get your opinion on an upstart change to powerd?
[17:40] <rsalveti> mfisch: sure, what do you need to change there?
[17:40] <pmcgowan> rsalveti, tell em whats up with this https://pastebin.canonical.com/94132/
[17:40] <mfisch> rsalveti: we want to clean-up all the cruft, ping me after you have a minute
[17:41] <awe_> rsalveti, ack
[17:41] <pmcgowan> rsalveti, gonna reboot and see what it looks like
[17:41] <pmcgowan> before my phone melts
[17:41] <rsalveti> mfisch: sure
[17:42] <ogra_> pmcgowan, bah, 2fa
[17:42] <rsalveti> pmcgowan: that's weird
[17:43] <rsalveti> mfisch: http://people.canonical.com/~rsalveti/libis_compat_layer.so into /system/lib/libis_compat_layer.so
[17:43] <rsalveti> reboot and test it again
[17:43] <rsalveti> brb, ~20 min
[17:43] <mfisch> rsalveti: thanks
[17:43] <ogra_> wow, weird, indeed
[17:44] <AskUbuntu> How to build ubuntu touch for unofficial cyanogenmod device | http://askubuntu.com/q/318595
[17:48] <mfisch> sforshee / rsalveti: well, _stop works now,  but _shutdown hangs
[17:48] <awe_> rsalveti, when you tested pin support, did you use the script from ofono-scripts, or dbus-send per my MR instructions?  I wasn't able to get the right syntax for the ofono-script
[17:50] <mfisch> ogra_: can we remove the powerd.override upstart file?
[17:50] <mfisch> ogra_: there are changes it is missing and more changes it will be missing, along with some massive cleanup
[17:50] <ogra_> mfisch, could we merge them ? (or at least move some fixes over from there)
[17:51] <mfisch> ogra_: we have all your fixes I think
[17:51] <mfisch> ogra_: like the start on dbus
[17:51] <ogra_> and the proper exec call
[17:51] <mfisch> ogasawara: and respawn I just added today
[17:51] <mfisch> sorry leann
[17:51] <ogra_> :)
[17:51] <ogra_> she still steals my pings :)
[17:51] <ogasawara> :)
[17:52] <mfisch> ogra_: actually you can weigh in on the changes here: https://code.launchpad.net/~mfisch/powerd/lp1195800/+merge/174000
[17:52] <mfisch> ogra_: its much cleaner now
[17:52] <mfisch> ogra_: as far as I call tell all those variables are not useful
[17:53] <ogra_> yeah, they come from pre=flipped i think
[17:54] <ogra_> mfisch, could we turn off debugging by default ? it produces gigantic upstart logs
[17:54] <mfisch> ogra_: that makes sense
[17:54] <mfisch> ogra_: we log to syslog now
[17:54] <mfisch> ogra_: for a few weeks now, but we could probably turn it off
[17:54] <mfisch> comment it out anyway
[17:55] <mfisch> sforshee: any opinions on turning the DEBUG off by default?
[17:55] <ogra_> but yeah, if the MP above works fine i'm happy to drop the override
[17:55] <sforshee> mfisch, ogra_: I'm okay with dropping debug by default. Might mean a little more work for bug reporters though ;-)
[17:56] <mfisch> sforshee: we can put it on our wiki page
[17:56] <ogra_> yeah
[17:57] <mfisch> sforshee: code review updated
[18:01] <sforshee> mfisch: I'm +1 on the MR but would still like to get rsalveti's feedback on the upstart job changes
[18:01] <mfisch> ok
[18:01] <mfisch> jenkins is off doing something atm anyway
[18:02] <sforshee> jenkins is such a slacker
[18:03] <mfisch> ogra_: once this lands can you remove the override file? and actually it doesn't seem to be functional anyway
[18:03] <mfisch> not sure why
[18:03] <ogra_> hmm, it is used on my image here
[18:04] <ogra_> but yeah, i'll remove it
[18:04] <mfisch> I have debug messages here with my copy, and that flag is not set in the override file
[18:06] <ogra_> if i set the flag i get about 300 messages per second ... if i unset it there is one line per second ... not sure thats the upstart job actually
[18:08] <mfisch> ogra_: well the flag will be usnet in my MR
[18:09] <ogra_> yeah
[18:09] <mfisch> but I need to retest with your override out of the way
[18:09] <ogra_> no, i mean i suspect there is something that sneaks through even if the variable is unset, are you sure its not that what you are seeing ?
[18:10] <mfisch> "ofono_proxy_connect_cb succeeded", for example, that should only happen with debug enabled, right sforshee ?
[18:10] <sforshee> mfisch: anything printed via powerd_debug should only print with debug enabled
[18:11] <ogra_> root@ubuntu-phablet:/# grep powerd_debug /var/log/syslog
[18:11] <ogra_> root@ubuntu-phablet:/#
[18:11] <ogra_> ok, then it is quiet here
[18:11] <mfisch> ogra_: grep for powerd
[18:11] <sforshee> ogra_: that's not part of the printout
[18:11] <sforshee> yes
[18:11] <mfisch> not powerd_debug
[18:11]  * mfisch sneaks in a "HI OGRA!" debugu statement into his MR
[18:11] <ogra_> only some messages from the first start
[18:11] <ogra_> Jul 10 10:52:14 ubuntu-phablet powerd[393]: Using backlight at /sys/devices/omapdss/display0/backlight/s6e8aa0
[18:11] <ogra_> Jul 10 10:52:35 ubuntu-phablet kernel: [   29.741668] init: powerd main process (393) killed by SEGV signal
[18:11] <ogra_> Jul 10 10:52:35 ubuntu-phablet kernel: [   29.741760] init: powerd main process ended, respawning
[18:11] <ogra_> Jul 10 10:52:35 ubuntu-phablet powerd[930]: Using backlight at /sys/devices/omapdss/display0/backlight/s6e8aa0
[18:12] <mfisch> ogra_: okay those are NOT debug messages
[18:12] <mfisch> Using backlight is an "info" message
[18:12] <ogra_> the rest are matches against the kernels powerdomain messages
[18:12] <mfisch> so thats what we should have once this MR goes
[18:12] <ogra_> well, thats what i have with todays image
[18:12] <sforshee> ogra_: believe me, if debug was enabled you'd see a lot more messages
[18:12] <mfisch> ogra_: so that is using your override, which means all is well with the world
[18:13] <mfisch> sforshee: if you restest my upstart change, be sure to move ogra's override somewhere
[18:13] <ogra_> sforshee, yes, i was only wondering why the override doesnt work for mfisch
[18:13] <mfisch> ogra_: I have a theory, let me try it
[18:13] <sforshee> the override definitely works for me, because I always have to change it
[18:13] <ogra_> let me rip that out right now :0
[18:13] <ogra_> so you dont have to move it away
[18:13] <mfisch> ogra_: I think before I must have been manually starting it, I didn't know about the override until 20 minutes ago ;)
[18:14] <mfisch> this one day a week on powerd tends to leave me behind
[18:14] <ogra_> oh, sorry for causing confusion then :)
[18:16] <mfisch> sforshee: _shutdown hanging makes little sense to me
[18:16] <mfisch> its just 1 line
[18:16] <ogra_> uploaded
[18:17] <mfisch> thanks ogasawara
[18:17] <mfisch> dang it!
[18:17] <mfisch> thanks ogra_
[18:17] <ogra_> haha
[18:18] <sforshee> mfisch: which package provides android_input_stack_shutdown?
[18:18] <mfisch> sforshee: hybris: https://github.com/libhybris/libhybris
[18:18] <mfisch> there's probably a version in bzr also
[18:18] <sforshee> I like git better anyway :-)
[18:18] <mfisch> the code has 1 statement: global_state = NULL;
[18:19] <mfisch> well git may not be whats running on here
[18:19] <sforshee> true
[18:21] <mfisch> we can ask rsalveti where the source is when he comes back
[18:23] <sforshee> mfisch: there are two versions of that function in the code I'm looking at
[18:23] <sergiusens> sforshee: mfisch if it's hybris it's bzr branch ubuntu:hybris (or libhybris)
[18:23] <ogra_> https://launchpad.net/libhybris
[18:23] <ogra_> and https://code.launchpad.net/~rsalveti/libhybris/trunk
[18:24] <sergiusens> ah, yeah, https://launchpad.net/libhybris is the packaging branch
[18:25] <mfisch> sforshee: show me?
[18:25] <sforshee> mfisch: hybris/input/is.c
[18:25] <sforshee> is the other version
[18:25] <rsalveti> hey
[18:25]  * rsalveti back
[18:25] <sforshee> which just tries to call some dynamically linked symbol
[18:26] <rsalveti> awe_: I used the python script
[18:26] <awe_> rsalveti, would you mind sending me the command you used?  I had trouble with the python arg formatting...
[18:27] <awe_> and thus used dbus_send
[18:28] <mfisch> rsalveti: this is the MR we wanted your opinion on, specifically the upstart changes: https://code.launchpad.net/~mfisch/powerd/lp1195800/+merge/174000
[18:28] <rsalveti> awe_: just lock/unlock "pin" code
[18:28] <rsalveti> sforshee: the packaging branch is https://code.launchpad.net/~ubuntu-core-dev/libhybris/ubuntu
[18:28] <rsalveti> but better just grab the source package
[18:29] <rsalveti> got a bunch of patches in there
[18:29] <rsalveti> mfisch: will see
[18:29] <rsalveti> mfisch: hang on shutdown makes no sense
[18:30] <rsalveti> sforshee: and the compat part needs to be built as part of the android image
[18:31] <awe_> rsalveti, hmmm...  I thought "type" was required
[18:31] <sforshee> rsalveti: okay, so the one powerd calls finds the corresponding call in the android part, and the call in the android part just sets global_state=NULL. Is that right?
[18:31] <rsalveti> awe_: well, type is "pin"
[18:31] <rsalveti> sforshee: yes
[18:31] <awe_> yea...and it may be that I didn't figure that out before moving to dbus_send
[18:32] <awe_> the errors messages weren't too clear
[18:32] <rsalveti> mfisch: did it really get stuck in the shutdown part?
[18:32] <rsalveti> or later on?
[18:32] <mfisch> rsalveti: let me confirm
[18:32] <awe_> rsalveti, I'll retry later before sending the email
[18:32] <rsalveti> awe_: ok
[18:33] <awe_> rsalveti, did the upstart expect fix land?
[18:33] <rsalveti> mfisch: and also, please confirm if pressing power releases the process again
[18:33] <rsalveti> awe_: you mean that respawn issue we had?
[18:33] <awe_> rsalveti, ie. the bug that was causing shutdown to hang waiting for ofono?
[18:33] <rsalveti> sure, that landed last week
[18:33] <awe_> because upstart lost it's pid
[18:33] <awe_> ok, cool
[18:33] <mfisch> I had a few more prints after
[18:33] <awe_> meant to ask you earlier
[18:33] <mfisch> let me try
[18:35] <mfisch> rsalveti: it's hanging on shutdown and power button press frees is
[18:35] <mfisch> frees it, I mean
[18:38] <True_unReal> hello?
[18:39] <marcellux> hi. I'm getting soon a HTC One X and I was following some lists of supported devices and it was on it. Anyway, I visited some forums and there are many things not working yet. the forums were not so fresh, I must say. Is it possible to install Ubuntu on that device?
[18:40] <WebbyIT> Any possibility to have u-touch on S4?
[18:43] <rsalveti> mfisch: mind trying http://people.canonical.com/~rsalveti/libis_compat_layer.so-2 ?
[18:43] <rsalveti> put it at /system/lib/libis_compat_layer.so
[18:43] <mfisch> rsalveti: k
[18:43] <rsalveti> then please also paste me the output of /system/bin/logcat after you tried that
[18:45] <mfisch> okay
[18:45] <mfisch> well
[18:45] <mfisch> rsalveti: now it works
[18:45] <mfisch> did you change anything besides printfs?
[18:45] <rsalveti> mfisch: also removed the exit and wait from the class destructor
[18:46] <mfisch> rsalveti:
[18:46] <mfisch> E/InputStackCompatibilityLayer( 2575): ANDROID INPUT STACK: Stopping
[18:46] <mfisch> E/InputStackCompatibilityLayer( 2575): ANDROID INPUT STACK: Shutting down
[18:46] <mfisch> E/InputStackCompatibilityLayer( 2575): ANDROID INPUT STACK: DONE
[18:46] <mfisch> rsalveti: well it's fixed now
[18:46] <rsalveti> great
[18:46] <mfisch> we stop pretty much instantly
[18:46] <rsalveti> mfisch: I'll push that fix in hybris later today then
[18:46] <mfisch> rsalveti: thanks
[18:47] <nik90> tvoss|dinner: would you recommend moving the stopwatch code (which calculates the new time and other calculators) to a workerScript in QML? I believe workerscript are the only way of creating another thread to do something.
[18:47] <mfisch> rsalveti: this is the bug #1199897
[18:47] <nik90> tvoss|dinner: This would mean that the stopwatch calculations will be in the workerscript while the ui is all done in the QML timer itself.
[18:47] <mfisch> rsalveti: any objections to the upstart change in that review?
[18:47] <rsalveti> mfisch: thanks
[18:48] <rsalveti> mfisch: do we need powerd_warn at all?
[18:48] <rsalveti> I think you should just print that message to sterr instead
[18:48] <rsalveti> and return the error
[18:49] <mfisch> rsalveti: if it happens in the main instance, I'd like it to be logged
[18:49] <awe_> rsalveti, mfisch, powerd's not using syslog, correct?
[18:49] <sforshee> awe_: it is using syslog
[18:49] <mfisch> it is using syslog
[18:49] <awe_> ok
[18:50] <awe_> rsalveti, then why print to stderr?
[18:50] <rsalveti> it should
[18:50] <mfisch> this is a special case that debuggers run into
[18:50] <rsalveti> awe_: https://code.launchpad.net/~mfisch/powerd/lp1195800/+merge/174000
[18:50] <mfisch> where you start powerd manually to test something and its running in upstart
[18:50] <mfisch> so just for that case I log it and print it
[18:50] <mfisch> seth and I have hit it a few times
[18:50] <sforshee> for this case stderr makes even more sense than syslog, imho
[18:50] <awe_> ah, k
[18:51] <rsalveti> can we make exit return an error code somehow
[18:51] <rsalveti> otherwise it'll look like it's returning successfully I guess
[18:51] <mfisch> thats a good idea
[18:51] <rsalveti> sforshee: +1
[18:51] <sforshee> mfisch: make powerd_exit take an exit code
[18:51] <mfisch> yep
[18:51] <mfisch> already done
[18:51] <rsalveti> so I'd have just one print, to stderr and return an exit code meaning error
[19:19] <asac> awe_: whats the ETA of SIM/PIN support?
[19:19] <asac> i am right now in the US and have a prepaid sim and enjoy my phone very mich .... but once i come back my sim will again be locked
[19:20] <asac> (note: not saying fastpath this ... just wondering)
[19:20] <asac> cyphermox: maybe thats on your plate rather? ^^
[19:21] <sergiusens> asac: I think awe_ already landed it and just needs to post instructions on how to enable
[19:21] <cyphermox> asac: awe deals with it, yeah. though there will certainly be a need to hook this up to UI
[19:27] <awe_> asac, yes should be landed as of today.  requires command-line magic till it's hooked up in the greeter ui
[19:27] <awe_> asac, I'll be sending an email to the ML later today
[19:27] <asac> nice ...
[19:27] <asac> i might ask for a private instructor lesson if the mail is too complicated :)
[19:28] <asac> lol
[19:28] <asac> but i am not back until next week
[19:28] <awe_> k
[19:31] <True_unReal> hello?
[19:38] <True_unReal> can anyone help me  out?
[19:39] <cyphermox> True_unReal: with what
[19:40] <cyphermox> you should just ask your question, someone will see it and answer :)
[19:40] <True_unReal> i wanted to ask how do i fix bugs where do i go?
[19:41] <esigolo> True_unReal: what kind ?
[19:41] <True_unReal> well wifi and i dont get any network signal either
[19:42] <esigolo> True_unReal: so do you want to solve a problem not a bug right ?
[19:43] <True_unReal> oh my bad yes
[19:43] <esigolo> True_unReal: wich model and touch version do you have
[19:43] <esigolo> ?
[19:44] <True_unReal> sorry for being such a noob but im not sure what you mean by that...
[19:45] <esigolo> True_unReal: I mean is it a Nexus 4 ? 7 galaxy Nexus or other phone?
[19:45] <esigolo> :)
[19:45] <True_unReal> its another phone
[19:45] <True_unReal> to be exact a Optimus L9
[19:46] <esigolo> True_unReal: there is a broken flag on Wifi https://wiki.ubuntu.com/Touch/Devices/P760
[19:46] <True_unReal> yes i know but that dev gave up on the project
[19:48] <djjeff> Ubuntu uses Xorg what does Ubuntu-Touch use?
[19:48] <esigolo> cyphermox: would be a problem if i tell  he will have to w8 to another person ! carry on the project?
[19:48] <esigolo> True_unReal: i'm asking because as far i know the dev team are focused on Nexus devices right now
[19:49] <cyphermox> esigolo: I know about wifi
[19:49] <djjeff> why are they missing the NEXUS S
[19:49] <esigolo> cyphermox: :)
[19:49] <djjeff> NEXUS S is a great phone
[19:49] <cyphermox> True_unReal: have you copied any firmware files you may need to bring up wifi, for instance, do you actually get a wlan devices?
[19:50] <cyphermox> djjeff: someone has to work on it. Feel free to start a git tree if you have a nexus S
[19:50] <esigolo> cyphermox: thanks :)
[19:50] <cyphermox> (personally I certainly don't, and I don't have spare money for yet one more device :)
[19:50] <True_unReal> i havent tried copying files because im not even sure where to copy it to
[19:51] <esigolo> djjeff: yes it is
[19:51] <cyphermox> True_unReal: you should take a look at the cyanogenmod tree for the Optimus L9, there should be a script that grabs the files for you from the phone before you flash Ubuntu on it
[19:53] <esigolo> i'm trying to buy a oppo find 5 to use as my main phone ! until i'm using my n 4 to work on ubuntu touch
[19:53] <True_unReal> This one ? "./extract-files.sh"
[20:00] <lool> 123
[20:07] <diogobaeder> Hi guys! Is anyone aware of some web page that might contain a list of apps that are already available for Ubuntu Phone?
[20:09] <Noize> How do i partition my device so i can dual boot current rom and ubuntu Touch?
[20:09] <zoktar> multirom
[20:09] <pmcgowan> diogobaeder, I dont think there is one list, but good question
[20:10] <zoktar> multirom just got support for ubuntu touch
[20:10] <Noize> any others that have had support for a longer term?
[20:11] <zoktar> iv been using it since ubuntu desktop for n7, works great
[20:11] <diogobaeder> pmcgowan, is there, at least, something like a preliminar list? Like, a number of apps that were already ported?
[20:11] <pmcgowan> mhall119, or popey do we have a consolidated apps list?
[20:11] <Noize> ok thank you zoktar :)
[20:12] <Noize> zoktar, is there multirom for N4?
[20:12] <zoktar> Noize, think so search on xda
[20:13] <tassadar_> no, there isn't
[20:13] <mhall119> pmcgowan: of non-core-apps?
[20:13] <Noize> damn
[20:13] <pmcgowan> mhall119, one list of all the apps, ours, core, installable, ....
[20:13] <tassadar_> but I would think there is some dual-boot solution for n4 on XDA
[20:14] <mhall119> pmcgowan: not a definitve list, no
[20:14] <pmcgowan> mhall119, we should make one
[20:14] <mhall119> pmcgowan: we have https://wiki.ubuntu.com/Touch/Collection but it hasn't been kept up to date
[20:14] <pmcgowan> right and its all the optional sort of apps
[20:14] <mhall119> it's impossibble to have a complete list of all 3rd party development
[20:14] <pmcgowan> mhall119, take that page and add the installed ones and core ones
[20:15] <Noodle> Anyone running ubuntu-touch on the N7 (WiFi) successfully? Saw the note about the Grouper release of Saucy not working properly and was wondering if this was still the case.
[20:15] <mhall119> pmcgowan: what would be the purpose of this list?
[20:17] <pmcgowan> mhall119, see in one place all the available applications
[20:17] <mhall119> Noodle: it mostly works
[20:17] <mhall119> Noodle: you don't get audio or camera, but everything else works
[20:17] <pmcgowan> diogobaeder was just asking for such a thing
[20:17] <pmcgowan> there is also https://wiki.ubuntu.com/Touch/CoreApps
[20:17] <tassadar_> Noodle: I'm running yesterday's build, it's okay
[20:17] <mhall119> pmcgowan: "available" meaning installable?
[20:17] <pmcgowan> mhall119, it seems weird to have a page for core apps but not the ones canonical authored
[20:17] <Noodle> Just grabbed today's build and I'm having very strange UI issues and couldn't seem to get the wifi turned on..
[20:17] <pmcgowan> mhal
[20:17] <mhall119> pmcgowan: well the ones canonical made are listed on the Launchpad project group: https://launchpad.net/ubuntu-touch-preview
[20:17] <pmcgowan> mhall119, rather than have a core apps wiki page, lets have an apps page with everything
[20:18] <pmcgowan> thats too hard to figure out
[20:18] <mhall119> pmcgowan: ok, we'll need to still have a core apps wiki page, we use that for our regular project management, but we could put together a page that listed everything
[20:19] <diogobaeder> pmcgowan, mhall119 , thanks!
[20:19] <zoktar> Noodle, installed today on n7, you can setup the wifi if you get the keyboard up, then just reboot and should work.
[20:21] <zoktar> Noodle, you get a Empty! after you enter password, just reboot.
[20:22] <Noodle> zoktar: Funny thing is that it's picking up the networks around me but when I select one, it just puts an orange check mark next to it and then doesn't seem to do anything else.
[20:26] <zoktar> Noodle, try pushing on the name or on the wifi icon, donno if thatl help, what i do.
[20:30] <Noodle> zoktar: If I go to "System Settings > Wi-Fi" all I see is a white screen. I feel like I have the wrong ROM or something...
[20:30] <mfisch> awe_: tony, sforshee mentioned some emergency call work. What special stuff does powerd need to do when someone dials 911?
[20:31] <Noodle> My "Last Updated" also says 2013-04-09 That can't be right.
[20:32] <zoktar> Noodle, dont do it from system settings, do it from the topside icon thingy
[20:34] <awe_> mfisch, prevent the call from being cutoff
[20:34] <mhall119> Noodle: in the System Settings app?
[20:34] <mhall119> Noodle: the system settings is in the early stages of development, a lot of things in there aren't implemented yet or are using hard-coded placeholder data
[20:35] <mfisch> awe_: sounds like what we do for a regular call
[20:35] <Noodle> Yea. I think I found my error though. Following the guide on Ubuntu wiki site lead me to install "saucy-preinstalled-touch-armhf" rather than the one meant specifically for Grouper
[20:35] <awe_> mfisch, I haven't spent much time on emergency calls yet, was just giving sforshee a heads-up
[20:35] <awe_> mfisch, this might even trump low-battery shutdown
[20:35] <mfisch> awe_: ah, so there's a special case then
[20:35] <mfisch> once we enable low battery shutdown ;)
[20:35] <awe_> mfisch, and there are other instances where the flag might be raised due to a network initiated request
[20:36] <awe_> so in general, it's something power should  monitor
[20:36] <awe_> mfisch, that said, I'm pretty sure there's more work to do on my end... so still to come
[20:36] <mfisch> ok
[20:39] <rsalveti> sergiusens: https://code.launchpad.net/~rsalveti/phablet-tools/remove_hybris_checkout/+merge/174052
[20:52] <esigolo_> ow lord !
[20:53] <esigolo_> nickserv not working and i'm not able to ghost my nick
[20:56] <esigolo> -.-
[20:56] <esigolo> ahuauhha
[21:02] <esigolo> rsalveti: Do you know when we will have a ubuntu hour São Paulo?
[21:09] <rsalveti> aloisiojr: alright, pushed
[21:09] <aloisiojr> rsalveti: tks :)
[21:13] <mhall119> bzoltan: http://askubuntu.com/questions/318666/qt-creator-html5-project-lsqlite3
[21:14] <mhall119> looks like there might be a missing dependency for the html5 template
[21:15] <pmcgowan> alex-abreu, ^^
[21:15] <pmcgowan> must be the sample app needs it, may want to do it differently
[21:15] <cyphermox> rsalveti: uploaded NM with the fixes
[21:38] <rsalveti> cyphermox: awesome, will test
[21:41] <alex-abreu> pmcgowan, mmmh werird though ..
[21:43] <pmcgowan> alex-abreu, I just tried and it works fine for me
[21:47] <pmcgowan> mhall119, I installed the music app, seems its not compatible somehow
[21:48] <pmcgowan> shell locked up
[21:49] <pmcgowan> alex-abreu, I have that package, though
[21:51] <popey> pmcgowan: our music app on the latest build on nexus 4?
[21:51] <pmcgowan> alex-abreu, removed it and it still works so who knows
[21:52] <pmcgowan> popey, yes
[21:52]  * popey gets his n4
[21:53] <popey> you sure you're not using the cardboard cutout?
[21:54] <popey> i just "adb shell" and then "apt-get install music-app" and it pulls in ours (I have the PPAs enabled)
[21:54] <pmcgowan> popey, yep deleted that before loading
[21:54] <popey> hmmm
[21:54] <pmcgowan> log says it starts music app
[21:54]  * popey takes a look
[21:54] <pmcgowan> popey, working for you?
[21:54] <popey> not yet, wasnt installed
[21:54] <popey> i had the cardboard one
[21:56] <popey> sorry, its slow, i think it's defaulting to 3g
[21:56] <mhall119> pmcgowan: do you have a lot of music in /home/phablet/Music ?
[21:56] <pmcgowan> popey, I just tried again and it worked
[21:56] <pmcgowan> popey, something more to it then
[21:57] <popey> bah, networking a bit borked for me
[21:57] <pmcgowan> now I need to load some music
[21:57] <pmcgowan> popey, so nm, its related to something else I did first
[21:57] <popey>   Something wicked happened resolving 'ppa.launchpad.net:http' (-11 - System error)
[21:57] <mhall119> pmcgowan: it may have been it's sub-optimal media scanner just consuming a lot of CPU
[21:57] <popey> that error needs to die in a fire
[21:58] <popey> hmm, i appear to have a zillion gsm connections
[21:58] <popey> http://paste.ubuntu.com/5863046/
[22:01] <pmcgowan> mhall119, hmm added music files but dont see em
[22:01] <popey> known bug possibly
[22:02] <popey> https://bugs.launchpad.net/music-app/+bug/1193633
[22:02] <pmcgowan> all at top level
[22:03] <popey> it doesnt find files at top level for me either
[22:03] <RobbyF> just got a samsung sIII SGH-I747, I hope i can run daily's on it
[22:03]  * popey tries trunk music app
[22:06] <popey> yay!
[22:06] <popey> trunk works
[22:07] <pmcgowan> popey, whats trunk
[22:07] <popey> http://popey.com/~alan/device-2013-07-10-230704.png
[22:07] <popey> looks like that
[22:07] <popey> so I did a bzr branch of the bzr trunk and build a deb
[22:07] <popey> which will land in the ppa once jenkins does its stuff
[22:08] <pmcgowan> oh
[22:08] <pmcgowan> duh
[22:08] <popey> http://popey.com/~alan/music-app_0.3_all.deb
[22:09] <popey> wget that on the device then dpkg -i music-app_0.3_all.deb
[22:09] <popey> if you want to try it right now
[22:09] <popey> plays audio too ☻
[22:10] <Well> hi peoples ?
[22:10] <popey> hello Well
[22:10] <AskUbuntu> differences between ubuntu touch and ubuntu-touch-preview | http://askubuntu.com/q/318684
[22:10] <popey> and still plays after the screen blanks
[22:11] <Well> I need a hint, I want to install ubuntu on my phone xperia j
[22:11] <popey> is it listed at https://wiki.ubuntu.com/Touch/Devices ?
[22:11] <pmcgowan> very nice
[22:11] <popey> working for you pmcgowan ?
[22:11] <pmcgowan> popey, it does
[22:12] <popey> great!
[22:12] <pmcgowan> now I eod for a while
[22:12] <popey> some UI issues
[22:12] <pmcgowan> yep
[22:12] <popey> will file bugs ☻
[22:12] <pmcgowan> may not be worth bugs yet
[22:12] <pmcgowan> ui seems not done
[22:12] <Well> can someone give me a hint, I will get will be? ?
[22:12] <popey> true
[22:13] <popey> Well: if someone ports Ubuntu Touch to your device....
[22:14] <Well> I'm from Brazil. I've been reading the wiki but it does not have a legal support in Portuguese. so I came here.
[22:14] <alex-abreu> pmcgowan, I'll play w/ it a bit ...
[22:14] <pmcgowan> alex-abreu, ok but seems fine to me, who knows what he did
[22:14] <alex-abreu> yeah
[22:14] <alex-abreu> I don't really any specific connection
[22:15] <alex-abreu> at first I though it was somehow pulled out by something like localstorage but no it doesn't make sense
[22:15] <alex-abreu> pulled in
[22:15] <pmcgowan> he must have run a different project, thats easy in qtc
[22:15] <alex-abreu> yeah
[22:44] <ax562> Sup mbm?
[22:45] <ax562> How is the ubuntu touch forefront?
[22:46] <ax562> Is this past preview ed yet?
[23:28] <murrayuk> hey guys, I'm just putting Ubuntu touch on my N4 now and in bootloader downloading the boot.img, etc I got an error while executing adb push. I can only get into the bootloader now and nowhere else and my device isn't showing in adb. Not really sure where to go from here... any ideas?
[23:29] <sergiusens> murrayuk: there is no adb in the bootloader, that could explain your issue
[23:29] <murrayuk> ah okay. How do I get ubuntu fully installed from here then? Since I can't go anywhere else?
[23:30] <sergiusens> murrayuk: your description of what you've done seems pretty vague, so can you start by clearly stating what you did, I'm assuming you did this manually.
[23:32] <popey> murrayuk: you using our instructions? https://wiki.ubuntu.com/Touch/Install ?
[23:32] <murrayuk> I did it through the guide on the ubuntu webside. Did everything through terminal that it said, all went well. it rebooted into bootloader and started installed everything then I got an error while executing adb push of the autodeploy.zip.
[23:32] <popey> what error?
[23:32] <murrayuk> I'll put it into a pastebin. one second.
[23:33] <murrayuk> http://pastebin.com/78Tcw0qE
[23:33] <popey> does "adb devices" show the device?
[23:33] <sergiusens> murrayuk: so you are indeed in recovery and not in the bootloader
[23:33] <murrayuk> It didn't go into the recovery
[23:34] <murrayuk> my phone powered off afterwards
[23:34] <murrayuk> It shows in adb devices if its powered off
[23:37] <murrayuk> I'm guessing something went wrong and I should reflash android back onto it and try again?
[23:38] <sergiusens> murrayuk: powered off? just reboot into recovery and run phablet-flash -d mako
[23:40] <murrayuk> I tried going into recovery last time and it just rebooted but its worked this time funnily enough. Just ran the command and it seems to be doing something... Thanks :)
[23:40] <popey> great
[23:41] <fangli> hello guys! Do you think it's worth to move from Android to Ubuntu on my LG Nexus 4?
[23:53] <murrayuk> is there a way to go back? can't seem to figure it out :p
[23:57] <popey> murrayuk: figure what out?
[23:58] <murrayuk> how to back inside the os
[23:58] <popey> murrayuk: we have this process quite well documented on the wiki https://wiki.ubuntu.com/Touch/Install
[23:58] <popey> what have you done?
[23:59] <murrayuk> got stuck on a network error screen. You know how android has a back button in the bottom left? How do I do that on ubuntu touch.