[00:28] <mhall119> kgunn: if you're still around do we have an ETA on when https://bugs.launchpad.net/xmir/+bug/1192843 will be fixed?
[00:28] <mhall119> it's getting some publicity
[00:30] <nhaines> If you ask me, this sounds like the perfect multitasking solution.
[00:57] <kgunn> mhall119: checking
[00:58] <kgunn> mhall119: we have a branch up for it...and yeah...kinda heard about it
[00:59] <kgunn> mhall119: we're trying to keep it quite on trunk atm for multimon ppa creation
[00:59] <kgunn> mhall119: as soon as we have that we'll top approve...so monday-ish
[03:26] <mhall119> thanks kgunn
[03:31] <plars> asac, psivaa: https://bugs.launchpad.net/touch-preview-images/+bug/1215724 is affecting the mako images in pending pretty badly, I've emailed tony to see if I can get him to take a look
[04:31] <Notex> Hello.
[05:39] <smartboyhw> ogra_, you said that some ports are made *without* using CM. How did they do it?
[06:37] <mousepie> hello
[06:38] <mousepie> i just was wondering is the -repository ppa:hablet-team/ppa down for anyone else?  it seems its down is there way to check?
[06:40] <mousepie> it says cannot access PPA (https://lanuchpad.net/api/1.0/-phablet-team/+archive/ppa)
[06:40] <smartboyhw> mousepie, it's ppa:phablet-team/ppa
[06:41] <smartboyhw> And obviously it's not lanuchpad.net
[06:41] <smartboyhw> It's launchpad.net
[06:41] <mousepie> yes frogive my typeing long day at work
[06:41] <smartboyhw> mousepie, why will you want THAT ppa?
[06:42] <mousepie> well i was trying to test and update to the latest image
[06:42] <smartboyhw> mousepie, you need phablet-tools
[06:42] <mousepie> ah
[06:43] <smartboyhw> sudo add-apt-repository ppa:phablet-team/tools
[06:43] <smartboyhw> Not /ppa
[06:43] <mousepie> oh my mistake 'thanks
[06:47] <mousepie> what about ppa:phablet-team/ppa should i add this as well?>
[06:48] <smartboyhw> mousepie, NO
[06:52] <_polto_> hi
[06:53] <mousepie> hmm ok so it says nothing was upgraded weird
[06:53] <mousepie> upgrade
[06:54] <_polto_> I did an apt-get upgrade and the apps list is empty now. I can not launch the terminal. Only apps in the launcher on the left. Also the netwrork manager do not show up now. (but connect to my wifi)
[06:56] <mousepie> Polto did you sudo apt-get update && sudo apt-get upgrade -y ?
[06:56] <_polto_> I have SSH access, what can I try to restore the apps and the network manager ?
[06:58] <_polto_> mousepie, yes
[06:58] <mousepie> hmm weird
[07:04] <mousepie> ha cool irssi works in terminal
[07:09] <mousepie> does anyone have data working i saw that some people had it ?
[07:16] <Mondane> I have a question about Ubuntu Touch and when it's connected to a large screen (ie. desktop mode): will I be able to use my device as keyboard and/or touchpad to interact in the desktop?
[07:19] <mousepie> dont know
[07:19] <RAOF> I believe so, yes.
[07:19] <smartboyhw> dholbach, any experience to port a device without a CM port?
[07:20] <Mondane> that would be great, no need to buy a physical keyboard and mouse
[07:21] <dholbach> good morning
[07:21] <Mondane> hi
[07:21] <dholbach> smartboyhw, I personally don't have any - https://wiki.ubuntu.com/Touch/PortingFlippedInProgress might help though
[08:33] <seb128> mpt, hey, on https://wiki.ubuntu.com/SoftwareUpdates?action=AttachFile&do=get&target=phone-settings-updates-checking.png
[08:34] <seb128> mpt, the bottom option ... that widget only allow us to put text for the items, not subtext, would it make sense to change it to "On any data connection (Data changes may apply.)" in that context?
[08:35] <mpt> seb128, please ask for that to be fixed in the toolkit, Oren asked for that layout.
[08:35] <mpt> (And to be clear, I agree with Oren that it's the appropriate layout.)
[08:35] <seb128> mpt, is the second line a subtitle (e.g smaller text)?
[08:36] <mpt> seb128, a caption, which is smaller text, yes.
[08:36] <seb128> mpt, ooooh, the choses are only never/when on wi-fi, the 3rd line is a caption?
[08:36] <mpt> seb128, it's a caption for the third option, not for the whole group.
[08:37] <seb128> mpt, I see, that makes sense, thanks
[08:38] <mpt> seb128, so it should be the same size and weight and color as the "Shorter times..." text in <https://wiki.ubuntu.com/SecurityAndPrivacySettings?action=AttachFile&do=get&target=phone-security-privacy-idle.png>, for example, but it should be exactly lined up with the "On any data connection" text.
[08:39] <seb128> mpt,  got it, thanks ... I'm talking to nic-doffay about it
[08:39] <seb128> mpt, thanks
[08:39] <mpt> seb128, checkboxes and switches might similarly have a caption.
[08:39] <seb128> mpt,
 seb128, not currently, but I'm going to implement that today. There will also be support for a picture too.
[08:39] <mpt> seb128, separate topic: popey has asked for me to test System Settings today and report bugs. (a) What project/package should I report them? (b) Any areas I should avoid?
[08:39] <seb128> popey, don't do that :p
[08:40] <seb128> mpt, the project is "ubuntu-system-settings" ... and I'm not sure that's worth testing
[08:41] <seb128> mpt, there is lot missing and lot not right because we don't have the correct widgets (e.g OptionSelector still didn't land so all our selectors look weird)
[08:41] <mpt> seb128, I have three hours blocked out for it with JohnLea! There will be music and heavy drinking. And cigars.
[08:42] <seb128> lol
[08:42] <seb128> and tons of bugs reports
[08:43] <mpt> seb128, okay, let's put it another way. Are there any areas that you think *are* complete and ready for testing?
[08:43] <seb128> mpt, no
[08:43] <mpt> Poop.
[08:43] <seb128> mpt, if you read http://pad.ubuntu.com/settingsbackendsnotes from l139 down, you have the current status and blockers
[08:44] <seb128> mpt, sure you can play with it, and some of UIs are mostly done, but quite some backends are not done yet/blocked on other pieces to land
[08:46] <seb128> mpt, background sound account cellular battery date&time security&privacy updates (once didrocks branch land) are mostly UI done though, if you ignore the fact that some of widgets don't trigger the actions they should
[08:54] <seb128> mpt, ok, other question about updates
[08:54] <seb128> "If the download has started but is currently paused, a progress bar and a “Resume Downloading” button.
[08:54] <seb128> If an update is currently downloading, a progress bar, progress text, and “Pause Downloading” button. "
[08:54] <seb128> mpt, should the "progress text" placeholder remains when you change?
[08:54] <seb128> to avoid having the button moving up/down when pausing/resuming?
[09:01] <JohnLea> seb128; I'm just about to start testing the System Settings marked as 'completely done, ready for final testing' in the Delivery Dashboard.  https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ak5sFuLRpCpBdFlUTzBIVURXb05LcndoQVIxU3pIZVE#gid=3  Could you take a look at this, and if you think any of the items currently marked light green are not completely done and ready for testing could you revert the to yellow background co
[09:01] <JohnLea> lour.  thanks
[09:01] <seb128> JohnLea, hey, I don't have edit right on that google doc
[09:02] <JohnLea> seb128; you do now ;-) refresh
[09:02] <seb128> JohnLea, and none of the settings are completely done
[09:02] <JohnLea> seb128; could you revert them to yellow background colour then?
[09:03] <seb128> JohnLea, oh, you have details, it's not "completely done" ... let me double check but the greens ones should be indeed testable
[09:05] <seb128> JohnLea, are those status of the UI or of the features?
[09:05] <JohnLea> seb128; light green means "engineering thinks this item is completely done and is ready for release".  The testing at this point should only be final acceptance testing.  If that is not the status of these items e.g. there are any outstanding bugs or missing functionality that needs to be fixed connected to these use cases, please revert
[09:06] <seb128> JohnLea, most of the UIs are done but often the backends didn't land yet (like the current phone app doesn't support vibrating)
[09:06] <seb128> JohnLea, or like the settings ringtone selection is done, but the new phone app didn't land on the touch image yet
[09:07] <seb128> JohnLea, so changing the config is going to work but the result is not going to show in the actual ringtone
[09:09] <JohnLea> seb128; if there is anything outstanding (related to functionality, UI implementation or quality) for any of the use cases that are highlighted green, the choice is to either a) re-word the use case to remove the item that is not yet done, and move the incomplete item to a subsequent month b) just change the background colour back to yellow.  This sheet is supposed to track final acceptance testing, not ongoing testing and developmen
[09:09] <JohnLea> t.  This sheet is a way to track the 'totally done, ready for consumer use tomorrow' items
[09:09] <JohnLea> seb128; it's not supposed to duplicate our ongoing design and dev processes
[09:11] <seb128> JohnLea, ok, I'm not sure about online account, but none of the others is in that category
[09:11] <seb128> JohnLea, I put them yellow
[09:12] <seb128> JohnLea, we are lacking toolkit support/lightdm to land/mir to land/system image to land/etc etc etc
[09:12] <seb128> JohnLea, none of the settings is "ready for real world users" until all those stuff land
[09:12] <seb128> JohnLea, imho it's not worth your time testing it yet
[09:12] <JohnLea> seb128; cool, if there is anything not done yellow is good.
[09:12] <seb128> JohnLea, or you can comment on the UIs if you want...
[09:12] <JohnLea> seb128; thanks
[09:13] <seb128> yw
[09:13] <JohnLea> seb128; all of the designers should be commenting and reporting bugs against the UI implementation every week anyhow
[09:20] <popey> 09:40:29 < mpt> seb128, separate topic: popey has asked for me to test System Settings today and report bugs. (a) What project/package should I report them? (b) Any areas I should avoid?
[09:20] <popey> no i didnt
[09:21] <PlasticSpork> hello
[09:21] <popey> Greetings Mr Spork
[09:21] <PlasticSpork> hi!
[09:21] <popey> (Sporks are my most favourite implements)
[09:22] <PlasticSpork> They are the ultimate utensil
[09:22] <popey> Indeed they are. How can we help today?
[09:23] <PlasticSpork> I have a Galaxy S3 i9300, is there a way of setting up duel boot with Jelly Bean and Ubuntu Touch?
[09:25] <popey> Ooh, not sure about that. We don't cater for dual boot environments at all really with our tools.
[09:25] <popey> You might find someone on xda has done that, but our tools may tramp all over that as we don't test for that use case
[09:25] <PlasticSpork> oaky
[09:25] <PlasticSpork> THanks
[09:25] <PlasticSpork> Will look in to it
[09:42] <asac> cyphermox: hey ... in our lab we have problems with wifi not coming up properly. can you explain it?
[09:42] <asac> cyphermox: check out the "default" testsuite in the most recent runs in our Image tests for logs etc.
[09:42] <asac> i downloaded the build and the indicator works here somewhat
[09:43] <asac> so in general seems to be fine
[09:57] <Manner> hello guys :)
[09:58] <popey> Manner: hi
[10:00] <Manner> i have a question about ubuntu touch development. is it possible to make the phone antenna send some random data on a specific frequency?
[10:01] <popey> unlikely.
[10:02] <popey> I mean, you can probably poke the radio in various interesting ways, but we aren't developing for that use case.
[10:06] <Manner> and if i dont using the sdk but changing something in the touch source code?
[10:06] <nik90_> popey: has documentation landed for the location services API?
[10:13] <popey> Manner: perhaps, but you're constrained by the driver for the radio I suspect, it's going to limit what you can do
[10:14] <popey> nik90_: good question.. tvoss, do we have docs for qtlocation ?
[10:29] <ogra_> asac, looking at the tests, it seems that ueventd actually behaves, but systemsettle still fails due to bits and peisec doing their initialization work ...
[10:29] <ogra_> *pieces
[10:29] <ogra_> i think it should start a bit delayed
[10:33] <davmor2> Morning all
[10:37] <jounih> anyone remember the command line way to change brightness?
[10:38] <asac> ogra_: what are we waiting for for hte android packaging?
[10:38] <ogra_> asac, nothing, i need to switch cdimage
[10:38] <asac> ic
[10:39]  * ogra_ will work on that today
[10:39] <asac> cool
[10:49] <ogra_> bah
[10:49] <ogra_> the gallery app test on mako has the ueventd hang again :(
[10:51] <asac> ogra_: i assume rsalveti's patch is not in then
[10:53] <ogra_> yeah
[10:53] <ogra_> bah, no incoming calls on the pulse image still
[10:53]  * ogra_ downloads the normal one
[11:28] <sergiusens> ogra_: I see email from rsalveti with a patch, I'm looking + applying
[11:28] <ogra_> sergiusens, ah, i thought it was applied
[11:29] <ogra_> sergiusens, i'm a bit worried it could poke the devices while udevd does the same though
[11:29] <ogra_> since when it restarts the container will emit the signal to fire up udev
[11:29] <sergiusens> ogra_: it wasn't came in at 2AM, rsalveti has weird working hours ;-)
[11:30] <sergiusens> ogra_: that's all with upstart though, right?
[11:30] <ogra_> ah, well, not much different from mine :)
[11:30] <sergiusens> which we don't have
[11:30] <ogra_> yeah
[11:39] <ogra_> sergiusens, was the last pulse image supposed to have picked up bfillers changes ?
[11:39] <ogra_> i still cant take incoming calls with it
[11:39]  * ogra_ is just flashing the normal image to compare
[11:40] <sergiusens> ogra_: let me see when it built
[11:40] <ogra_> jenkins says 6:00 ... but not which TZ :)
[11:40] <ogra_> ah, must be UTC
[11:40] <sergiusens> ogra_: yeah, that sucks, I always forget jenkinses tz, but it's utc
[11:41] <ogra_> yeah, there is that "started at" timerstamp at the top right
[11:42] <sergiusens> ogra_: http://paste.ubuntu.com/6017349/
[11:42] <sergiusens> in case it's easy to compare
[11:43] <sergiusens> I saw a pulseaudio package ftb in the pa ppa
[11:43] <ogra_> hmm
[11:43] <ogra_> i dont see a recnt build of phone app in the ppa
[11:44] <ogra_> i thought that was supposed to be rebuilt
[11:44] <sergiusens> ogra_: there is no recent MR either, but was it a phone app fix or a telepathy one?
[11:44] <ogra_> well, whatever it was, bill wanted to rebuild it in the PPA
[11:45] <ogra_> and the phablet-team PPA is the only one we ship
[11:47] <ogra_> nope, no change on todays image
[11:47] <ogra_> still cant take incoming calls even on the normal image
[11:47] <ogra_> (not surprising if nothing changed)
[12:08] <popey> ogra_: is that a maguro specific thing? I can take calls on mako with 20130823
[12:10] <davmor2> popey: no it's an ogra thing I hope or I'll be re-flashing yesterday image :D
[12:11] <ogra_> popey, well, apprantly it is a phone-app issue with the new indicator code
[12:11] <pmcgowan> ogra_, was just going to say that
[12:11] <ogra_> intesting that it works for you
[12:11] <pmcgowan> its intermittent
[12:12] <pmcgowan> I had it happen after receiving a text and call, not sure what triggers it
[12:12] <popey> ah
[12:13] <davmor2> ogra_: I just made a call with todays image
[12:14] <diwic> sergiusens, don't worry about the new pulseaudio build, there are no significant changes
[12:15] <diwic> sergiusens, I've just fixed up the i386/amd64 stuff so that it doesn't FTBFS on those architectures
[12:19] <pstolowski> Saviq: ping
[12:19] <Saviq> pstolowski, pong
[12:20] <pstolowski> Saviq: can you think of anything in the shell qml that could result in empty dash when emit layoutChanged() from categories model?
[12:21] <pstolowski> Saviq: I'm emitting it with LayoutChangeHint::VerticalSortHint hint
[12:22] <ogra_> davmor2, outgoing is no issue
[12:22] <pstolowski> Saviq: and I'm not really changing anything, it seems that just emitting the signal already breaks something
[12:22] <ogra_> davmor2, do you get a popup on incoming calls ? does the phone app start ? also try the same after sending or recieving an sms
[12:23] <diwic> ogra_, sergiusens so regardless of phone calls, maybe either of you can test recording from the handset mic and see if it works?
[12:23]  * ogra_ only has the screen turning on, no phobe capabilities beyond that on incoming calls
[12:23] <ogra_> diwic, i need to re-flash first but can do that later
[12:24] <diwic> ogra_, sergiusens, just do "parecord /tmp/foo.wav", talk into the mic, press Ctrl+C to stop recording, and listen
[12:24]  * ogra_ will do
[12:24] <Saviq> pstolowski, hmm
[12:24] <Saviq> pstolowski, might be our proxy models get confused
[12:24] <Saviq> tsdgeos, ideas ↑↑↑?
[12:25] <diwic> ogra_, yeah, it's not an immediate hurry or anything, just something we have forgotten to test
[12:25] <ogra_> yup
[12:25] <diwic> On mako, it works with handset mic, but not with headset mic...don't know why :-(
[12:27] <davmor2> ogra_: I have just rung myself 3 time the only one I need to retry is if the phone is in sleep mode it told me the phone wasn't available,  while the phone was in awake mode (ie on either the welcome screen or in use everything is fine)
[12:27] <davmor2> text to myself worked fine
[12:27] <ogra_> texting on both directions works fine here ... outgoing calls too
[12:28] <ogra_> i just dont get a popup on incoming ... nor any kind of rintone
[12:28] <ogra_> *ring
[12:29] <davmor2> ogra_: I'm just waiting on the sleep
[12:35] <davmor2> ogra_, pmcgowan: so here is my list, with the phone left to sleep for a while (30 minutes or so) I got "This phone is not available please try again later" from the operator.  With  it alseep for a short while I get the popup but no ringtone, with it awake it works as expected.
[12:36] <ogra_> i dont ever get a popup
[12:36] <ogra_> for incoming calls ...
[12:36] <ogra_> or a ringtone
[12:36] <ogra_> and to be sure i just put the sim into my android phone, works all fine
[12:37] <davmor2> ogra_: yeah but your special right :D  your just meant to feel a disturbance in the force and instantly answer it right :)
[12:37] <mhr3_> pstolowski, did you try to emit rowsMoved instead?
[12:37] <mhr3_> wonder if that would work
[12:37] <pmcgowan> davmor2, ogra_ I know boiko had something in the works yesterday
[12:38] <ogra_> well, as i understood bfiller it was just a matter of rebuilding the phone-app with rolled back build deps
[12:38] <ogra_> but that didnt happen]
[12:38] <davmor2> ogra_, pmcgowan : I'm going to leave my phone till after lunch now and try ringing it again to confirm the long sleep issue
[12:40] <pmcgowan> Saviq, the close app x's never clear now, known bug?
[12:41] <pstolowski> mhr3_: i don't think it can be used, it has certatin restrictions regarding destination row (described in beginMoveRows)
[12:41] <ogra_> never ?
[12:41] <ogra_> they usually do for me when i move between lenses
[12:41] <pmcgowan> ogra_, not anymore here,
[12:41] <ogra_> oh, yeah
[12:41] <ogra_> confirmed
[12:41] <pmcgowan> not even after suspend
[12:42]  * ogra_ wants the hud close action back
[12:42] <tsdgeos> Saviq: pstolowski: what's wrong? not sure i got it
[12:44] <pstolowski> tsdgeos: when I emit layoutChanged (with VerticalSortHint hint) from the categories model, I loose all the content from the dash, even though I don't really change any of my model data.
[12:44] <mhr3_> pstolowski, i don't see any restrictions
[12:44] <mhr3_> that would make it unusable
[12:45] <pstolowski> mhr3_: "Note that if sourceParent and destinationParent are the same, you must ensure that the destinationChild is not within the range of sourceFirst and sourceLast + 1."
[12:47] <ogra_> asac, looks like the 0823 image has regressed quite a bit ... (judging by maguro, mako would still need give-backs but i dont think it will look better so we could save that work)
[12:47] <mhr3_> pstolowski, sourceFirst and Last are indices of the moved rows
[12:47] <tsdgeos> pstolowski: what is emmitting layoutChanged? dee-qt? or?
[12:48] <ogra_> 19 new failures
[12:48] <pstolowski> tsdgeos: Categories model (inherits from dee-qt)
[12:49] <tsdgeos> pstolowski: ok, but you do it from there
[12:49] <tsdgeos> which is only proxied by QLimitProxyFilter
[12:49] <pstolowski> mhr3_: sure; and it would be useful if I move one row at a time
[12:51] <tsdgeos> pstolowski: if you had a branch, i guess i can have a look at it
[12:52] <mhr3_> pstolowski, that's why i said "tried", it wraps layoutchanged, so you'd know if you're just forgetting something
[12:54] <pstolowski> tsdgeos: let me first check if proxy model can handle this
[13:01] <popey> davmor2: i left my phone for 50 mins and it still woke to take a call, *but* my phone is on usb so may not have actually slept
[13:07] <ogra_> diwic, hmm, so i tried to record, but paplay doesnt seem to work to play it back
[13:07]  * ogra_ pulls the wav over
[13:07] <diwic> ogra_, can paplay play other files ( paplay /usr/share/alsa/sounds/Front_Left.wav ) ?
[13:07] <ogra_> hmm, nothing recoerded either
[13:07] <ogra_> no
[13:08] <diwic> ogra_, I remember this was working earlier
[13:08] <ogra_> yes it was
[13:08] <ogra_> but i dont remember in what iteration, i didnt test it every image
[13:08] <ogra_> and i thinnk that test was a few ones ago
[13:08] <diwic> ogra_, what's your pacmd list right now?
[13:09] <ogra_> http://paste.ubuntu.com/6017665/
[13:10] <ogra_> note this is freshly flashed
[13:10] <ogra_> only for the parecord test
[13:11] <diwic> ogra_, that makes it even more strange
[13:11] <diwic> ogra_, have you tried making voice calls since your last reboot, if so, see if it works after a clean reboot
[13:11] <ogra_> i did with the last flashing
[13:12] <ogra_> and outgoing worked fine as usual
[13:12] <ogra_> i see some files from yesterday in /home/phablet/.config/pulse/
[13:12] <ogra_> let me wipe that dir and reboot
[13:12] <diwic> ok
[13:14] <ogra_> nope, no change
[13:14] <ogra_> no paplay
[13:15] <diwic> does paplay seem to play back but you get nothing but silence?
[13:15] <ogra_> yeah
[13:15] <diwic> like, it quits after the t
[13:15] <diwic> he amount of time that the wave length is
[13:15] <ogra_> it returns after a second
[13:15] <ogra_> or 2
[13:16] <ogra_> phablet@ubuntu-phablet:~$ time paplay /usr/share/sounds/alsa/Front_Center.wav
[13:16] <ogra_> real	0m1.551s
[13:16] <ogra_> user	0m0.008s
[13:16] <ogra_> sys	0m0.023s
[13:16] <diwic> okay, execute "pacmd set-log-level 4", then try a playback, then "grep pulseaudio /var/log/syslog"
[13:17] <ogra_> this funny pulse shell could really learn to send a final newline after the >>>
[13:17] <diwic> ogra_, it works better in PA 5.0 I've been told
[13:18] <diwic> i e, no prompt at all if you specify anything after "pacmd"
[13:18] <ogra_> http://paste.ubuntu.com/6017695/
[13:19] <diwic> ogra_, everything looks okay there
[13:21] <ogra_> diwic, aha
[13:21] <ogra_> i get output through headphones
[13:22] <diwic> ogra_, but not through speaker?
[13:22] <ogra_> yeah
[13:22] <sergiusens> plars: you around?
[13:22] <diwic> well, that's something
[13:22] <plars> sergiusens: yes
[13:23] <diwic> actually, headphones were one the things I wanted someone to test, too
[13:23] <ogra_> diwic, recording works fine through headphones as well
[13:23] <diwic> ogra_, ooh, that's nice
[13:23] <ogra_> doesnt start to work with the phone itself when i unplug though
[13:24] <ogra_> that stays quiet
[13:24] <sergiusens> plars: I'm building a mako system.img for mako with the uevent fix, can you give it a test?
[13:24] <plars> sergiusens: yes
[13:24] <diwic> ogra_, could you, using the "pactl list sinks" and "pactl list sources" commands, see if the active port toggles correctly?
[13:24] <sergiusens> plars: ack, I'll pingback as soons as it's uploaded
[13:25] <plars> sergiusens: ok, thanks
[13:25] <diwic> ogra_, the active port should toggle when you plug/unplug your headset
[13:25] <ogra_> diwic, list sinks shows the switch correctly, Active Port changes
[13:26] <diwic> ogra_, sources too?
[13:26] <ogra_> yep
[13:26] <ogra_> Hanset and Headset
[13:26] <ogra_> *Hand
[13:28] <ogra_> bah, crap
[13:29] <ogra_> i put my micro sim adapter into the GNex to not lose it ... seems i cant pull it out of the slot anymore now
[13:31] <davmor2> popey, pmcgowan, ogra_: Okay so now the call goes through I see the indicator but no ringtone, when I hangup the indicator doesn't go away you either have to select decline or answer
[13:31] <popey> works fine here
[13:31] <popey> left it 30 mins unplugged
[13:32] <davmor2> popey: might be maguro specific then
[13:33] <davmor2> popey: anyway I blame ogra_ it worked fine till he said it didn't :D
[13:33] <ogra_> lol
[13:40] <salem_> diwic, ping
[13:41] <diwic> salem_, hi
[13:43] <asac> ogra_: ofonod and download manager is crashing
[13:43] <asac> known?
[13:44] <ogra_> in a local test ?
[13:44] <salem_> diwic, hey, do I need any special package to compile telepathy-ofono + pulseaudio? I used the ones in the archive.
[13:44] <ogra_> asac, not known and i dont see ofono crash here
[13:45] <diwic> salem_, so,  what's left to do is to change the dependency from libwaudio-dev to libpulse-dev
[13:45] <diwic> salem_, in debian/control
[13:45] <ogra_> (i dont see download-manager run either though)
[13:45] <diwic> salem_, that we have to do synchronised with the other pulseaudio changes
[13:45] <salem_> diwic, yep, I did that already. I compiled the package locally.
[13:46] <diwic> salem_, and the pulseaudio image I pointed you to (at the jenkins qa lab, can you access it?) should have all other modifications necessary
[13:50] <salem_> diwic, yes, I am downloading it. thanks
[13:51] <popey> 108
[13:51] <popey> bah
[13:52] <davmor2> 109
[13:52] <davmor2> bah
[13:52] <davmor2> 110
[13:52] <davmor2> coming ready or not
[13:52] <ogra_> 111
[13:52] <psivaa> ogra_: http://reports.qa.ubuntu.com/smokeng/saucy/image/3722/unity8-autopilot/ has those crashes attached
[13:53] <ogra_> ah
[13:54] <lool> barry: around?
[13:54] <lool> barry, didrocks: I'd like to make a quick eval of where we stand WRT to new Dbus API
[13:55] <sergiusens> plars: copy http://people.canonical.com/~sergiusens/ueventd/android-ramdisk.img to /boot (overwrite the existing one in there)
[13:55] <lool> sergiusens: concerning the "high value target" of backup restore on the host, is this something in a merge proposal or some branch?  :-)
[13:56] <sergiusens> lool: need to get that in
[13:56] <lool> sergiusens: that would be good; would like to avoid announcing people will lose their userdata if they switch to new images
[13:57] <barry> lool: i am
[13:57] <lool> barry: So I think didrocks has a couple of issues with the mock, but is mostly done with his updated UI
[13:57] <lool> barry: how far are you w/ the backend?
[13:58] <lool> barry, didrocks: Basically, can we get this in the images and testable today?
[13:58] <barry> lool, didrocks has he tried the latest bzr head?  his branch is merged and more work on tests and such have been added
[13:58] <lool> barry: yeah the issues I mention are from a day or two ago; it's probably all fixed now
[13:59] <lool> sorry, I don't have the latest status, I'm asking for latest status based on the last one I heard   ;-)
[13:59] <sergiusens> lool: ok, it's not a complicated thing to do... just complicated to think of all the scenarios... I'll get something in in the following hours
[13:59] <lool> sergiusens: awesome
[13:59] <barry> lool: i think the backend is mostly done, except for some cleanup and some additional tests.  i want to fix the cli's --dbus argument, and then review the spec to make sure i haven't missed anything.  i am definitely planning on uploading a new version today, though i'd like to try to get in the channel.ini changes too.
[13:59] <plars> sergiusens: hmm, just 'fastboot flash boot android-ramdisk.img'?
[14:00] <lool> barry: we need to sync the uploads as I understand this isn't backwards compatible, right?
[14:00] <didrocks> lool: what about latest mock?
[14:00] <barry> lool: correct
[14:00] <lool> didrocks: I dont know, you tell me!  :)
[14:00] <didrocks> lool: everything is fine since yesterday :)
[14:00] <didrocks> lool: barry: so basically, seb128 reviewed my changes, from the ui side, it's done
[14:00] <lool> barry didrocks: Sorry, just ignore my first lines; I basically dont have the latest status
[14:00] <lool> cool
[14:00] <lool> so everything is done
[14:00] <didrocks> lool: barry: the only part which is faked is the description list, which can't be fixed before my holidays
[14:01] <lool> didrocks: is this in the image too?
[14:01] <didrocks> yeah, then minor adjustement
[14:01] <didrocks> lool: landed in trunk at mi-day
[14:01] <didrocks> so I guess not in the current image
[14:01] <lool> didrocks: manifest >> yeah, that's ok
[14:01] <barry> didrocks: right, i've commented out all the descriptions stuff for now, and we have that bug open on both the ui and backend for when that's fixed
[14:01] <sergiusens> plars: noooo
[14:01] <barry> didrocks: any chance you can test the ui against the live client?  (i.e. not in test mode?)
[14:02] <sergiusens> plars: adb push android-ramdisk.img /boot
[14:02] <lool> didrocks: could you add "(manifest of changes will be inserted here after LP #xxx is fixed)" in the description of the update?
[14:02] <barry> didrocks: if not, i can give it a try later today
[14:02] <didrocks> barry: is your side finished?
[14:02] <plars> sergiusens: ah, ok, I was thinking this was boot partition image
[14:02] <didrocks> lool: there is a TODO in the code
[14:02] <didrocks> barry: not sure I'll have time, wrapping up things before holidays ;)
[14:02] <barry> didrocks: mostly so.  i want to review the spec to make sure i haven't forgotten anything, review the tests for coverage, and then do a cleanup pass
[14:03] <barry> didrocks: no worries!  i'll attempt that before i release the new version.
[14:03] <didrocks> but seb128 and I tested against the mock, and the ui is behaving as expected regarding the mock
[14:03] <sergiusens> plars: it's just the android ramdisk, the boot images are ramdisk + kernel
[14:03] <didrocks> barry: sweet ;)
[14:03] <barry> mocks are mocks :)
[14:03] <lool> hmm why dont I see an update today
[14:03] <barry> didrocks: is there anything from your side preventing me from uploading a new systemimage package today?
[14:04] <didrocks> barry: nothing that I know of
[14:04] <barry> didrocks: awesome.
[14:04] <didrocks> lool: if you have the new UI with the old system service, that's expected
[14:04] <barry> lool: my guess is that the ui is speaking new-dbus, but the client is still speaking old-dbus
[14:04] <lool> didrocks: so how do I update out of that?  :-)
[14:04] <lool> I guess system-image-cli
[14:04] <barry> lool: right, that should still work
[14:05] <lool> too bad this says "no updates available"  :-)
[14:05] <didrocks> lool: right
[14:05] <lool> alright, so to summarize: didrocks is doing minor touches but these don't need upload and barry is doing final touches and will upload new API today?
[14:06] <plars> sergiusens: just rebooting several times now, as it doesn't show up every time, but I have little doubt this will address the problem
[14:06] <lool> I guess we will have to defer testing to monday
[14:06] <barry> lool: correct
[14:06] <lool> since barry's EOD is a bit late and we'd have to reroll multiple images to test updates
[14:06] <barry> lool: well, unless you're west of me :)
[14:06] <lool> if you go sufficiently west I guess I am  ;-)
[14:06] <sergiusens> plars: from the patch it seems it would though
[14:06] <barry> lool: yeah, i suppose it's all relative!
[14:06] <lool> barry, didrocks: Sounds like a plan then
[14:07] <plars> sergiusens: no, I'm saying that I believe this will fix it :)
[14:07] <lool> stgraber is working on daily-proposed, but not a blocker
[14:07] <lool> and sergiusens is working on backup / restore
[14:07] <barry> sweet.  fwiw, i am around all next week so i should be able to react quickly to any problems that crop up
[14:07] <lool> cool
[14:07] <barry> although there won't be 'cause we all know it's perfect :)
[14:07] <lool> didrocks, barry: Thanks for the updates
[14:07] <barry> np
[14:07] <didrocks> lool: barry: yw, thanks you :)
[14:08] <barry> didrocks: thank you too!
[14:08] <lool> there wont be any bugs
[14:08] <lool> fleas at worst
[14:08] <lool> (from mutt(1)  ;-)
[14:09] <plars> asac: around?
[14:09] <seb128> barry, hey, I registered https://bugs.launchpad.net/ubuntu-system-image/+bug/1215943
[14:09] <seb128> barry, where do you store the last update date atm?
[14:10] <cjohnston> I thought they only used version numbers
[14:10] <barry> seb128: with the new dbus api, i store it in a little sqlite database, and the value gets updated just before a successful reboot
[14:11] <seb128> barry, where is the db stored, stgraber suggested by then that you couldn't store it anywhere with the ro images
[14:11] <barry> it's probably not ultimately correct.  my thinking is that stgraber should probably touch a file in the recovery, and then we'd use the mtime on that
[14:11] <seb128> barry, did that change?
[14:11] <seb128> barry, lol, that's what we did/are doing (see the bug report)
[14:12] <sergiusens> stgraber: barry: what was the file with the version you used and is that stable?
[14:12] <barry> seb128: we need a db of some sort for other functionality.  right now that's stored in /var/lib/system-image/settings.db and i thought /var/lib/system-image would be rw
[14:12] <stgraber> barry: it's rw
[14:12] <stgraber> sergiusens: /etc/ubuntu-build?
[14:12] <mpt> Laney, I've corrected the text for the "Auto sleep" item in the "Battery" settings. <https://wiki.ubuntu.com/Power?action=diff&rev2=38&rev1=37>
[14:12] <Laney> thanks
[14:12] <stgraber> barry: I already touch a file in recovery
[14:13] <sergiusens> stgraber: yes, can I rely on that? as in, is it a stable interface?
[14:13] <lool> stgraber barry: system-image-cli reports no new version today; are we manually publishing now?
[14:13] <stgraber> sergiusens: yep, it'll stay there
[14:13] <sergiusens> stgraber: ack, thanks
[14:13] <stgraber> lool: we're only publishing tested images, yes
[14:13] <stgraber> barry: touch /data/.last_update || true
[14:13] <barry> stgraber: /etc/ubuntu-build?  isn't that going away (or deprecated at least) with the channels.ini file change?
[14:13] <stgraber> barry: so look at /userdata/.last_update
[14:14] <lool> asac stgraber: So now we're dependent on image publicatin to get latest fixes; no apt-get update anymore; who's giving green flag on today's image?
[14:14] <barry> stgraber: thanks, i will update the bug and make sure we get the date from that file
[14:14] <stgraber> barry: it doesn't hurt to keep ubuntu-build and it's way easier to read than the ini so I have no plan to deprecate it
[14:14] <lool> like, I'm running new images, I'd like to get to latest (today's image)
[14:14] <seb128> Laney, hum, power, do you plan to do the changes to match the spec of should I?
[14:15] <stgraber> lool: currently you can't, we need daily-proposed for that (which may be available later today).
[14:15] <lool> stgraber: Ok; quite important to get it then  :-)
[14:15] <Laney> seb128: feel free, I'm patch piloting now & national holiday on monday
[14:15] <barry> stgraber: are you going to write the build number in both places?
[14:15] <lool> stgraber: I'll let you focus on this
[14:15] <stgraber> barry: yes
[14:15]  * lool apt-get updates
[14:15] <barry> stgraber: cool
[14:15] <stgraber> barry: (I currently am)
[14:15] <seb128> Laney, oh right, enjoy the long W.E ;-)
[14:16] <Laney> seb128: I was working on accountsservice stuff but I didn't get it to work yet
[14:16] <barry> stgraber: https://bugs.launchpad.net/ubuntu-system-image/+bug/1215943/comments/1
[14:16] <cjohnston> stgraber: would it be possible to get the build number (YYYYMMDD.X) written into .last_update?
[14:16] <barry> and LP: #1214009 tracks the channel.ini work
[14:16] <Laney> seb128: shall I push it to let you have a look at that or is there no point? ;-)
[14:17] <stgraber> cjohnston: no because the system-image stuff has no idea of what that build number is
[14:17] <barry> stgraber: maybe we could add a human readable build string to channel.ini?
[14:17] <seb128> Laney, your call, if you want some feedback feel free to push, otherwise that can wait ... I'm going to be busy enough in the next that I'm likely to pick it up/do anything else than comment
[14:17] <Laney> ok
[14:17] <lool> barry, stgraber: Some cmdline to get information about the device would be good
[14:17] <mpt> Laney, so I guess there should be a piece of code that provides the "Lock when idle" item and its screen, and both S&P and Battery should call it.
[14:17] <Laney> I just didn't get accountsservice to know about it at all
[14:18] <cjohnston> stgraber: how does media-info get the build number then?
[14:18] <stgraber> barry: well, the server side code doesn't really know much more either so it'd be hard to come up with it there either
[14:18] <stgraber> cjohnston: media-info is generated by the rootfs build process
[14:18] <Laney> mpt: Sure, I guess one of them should have the code and the other can simply push that page onto the stack
[14:18] <lool> barry, stgraber: So many people are getting this wrong or asking about this, let's add a "system-image-cli whats-my-build-id" that reports versions and time of last update?
[14:18] <barry> lool: system-image-cli --channel prints the channel/device
[14:18] <lool> sounds similar
[14:19] <barry> system-image-cli --build prints the current build number (not the dotted build string)
[14:19] <cjohnston> Somewhere something with system-image stuff knows about build numbers because its published in index.json
[14:19] <lool> barry: could you pull the subnumbers into that output?
[14:19] <lool> barry: build number: 20130833, android: yyy, ubuntu: xxx
[14:19] <stgraber> ogra_: didn't you say you'd get media-info in etc or something like that a while back?
[14:20]  * lool cant find media-info on his device
[14:20] <ogra_> stgraber, get ? for what ?
[14:20] <barry> lool: "pull the subnumbers into"... what?  --build?
[14:20] <ogra_> it sits in the rootfs
[14:20] <ogra_> and is read from that place by i.e. the utah scripts
[14:20] <lool> barry: yes
[14:20] <stgraber> ogra_: move it to /etc so that it doesn't disappear when we bind-mount /var/log to writable storage
[14:21] <mpt> Laney, that would achieve 90% of it. The text of the parent item, and its summary value (the text at its right end), should be in sync too.
[14:21] <barry> lool: i could, if the information is available
[14:21] <stgraber> ogra_: IIRC we talked about moving the actual file to /etc and have a symlink in /var/log
[14:21] <ogra_> stgraber, well, i only put it there because all bug reporting tools use that file
[14:21] <cjohnston> ogra_: and that's the issue is that utah has no way to know what the "new" build number is after an upgrade
[14:21]  * ogra_ cant remember such a conversation
[14:21] <Laney> mpt: OK, that's achievable (you can inject variables when navigating the pagestack)
[14:21] <ogra_> but i have indeed no issue with moving it to etc
[14:21] <lool> barry: rather than having 20 different implement the recipe to fetch the various ids / dates from all around the image, I'd rather concentrate it in system-image (dbus and cli I guess)
[14:21] <stgraber> ogra_: ok. nevermind, I'll hack the initrd to re-copy /var/log/installer at every boot, otherwise you'll never see the version number increment :)
[14:21] <ogra_> cjohnston, yeah
[14:21] <lool> stgraber, ogra_, cjohnston: ^
[14:22] <ogra_> stgraber, let me quickly change livecd-rootfs ... its trivial
[14:22] <ogra_> i dont care where the file lives
[14:22] <stgraber> ogra_: ok, thanks
[14:22] <barry> lool: sure, that's not the problem. i think the main problem is where to get the information from.  we have build number, last-update-date, channel, device available, but the dotted build-string isn't readily available
[14:23] <lool> barry: ah it's not even in the index.json, right
[14:23] <lool> it should be in the image
[14:23] <lool> barry: nevertheless, when it's available again, having everything coming out of system-image seems a good idea to me
[14:23] <stgraber> lool: right, system-image only ships files, it doesn't care about the version of the individual bits
[14:23] <barry> there are things that *look* like that in index.json, but it's hidden in the description fields for multiple images, so 1) you can't count on it being there in the form you want; 2) there could be *several* of them for any particular update, so which do you choose?
[14:23] <lool> at least settings and QA team need to implement the same logic
[14:24] <stgraber> lool: so once ogra_'s change lands we'll be able to get /etc/ubuntu-build, /etc/media-info (or whatever it'll be called) and we'll just be missing the android version number
[14:24] <lool> stgraber: it's just a good place to provide information about your current image versions
[14:24] <barry> lool: absolutely agree that we expose what information we have via cli and dbus ;)
[14:24] <ogra_> stgraber, /etc/media-info fine ?
[14:24] <stgraber> ogra_: fine with me
[14:24] <ogra_> k
[14:24] <lool> stgraber: but rather than having system-settings poke that, doesn't it make sense to regroup the info in system-image?
[14:24] <lool> barry: cool
[14:25] <barry> ogra_, stgraber please just update LP: #1206621 with locations to get the information and i'll make sure it's exposed probably in cli and dbus
[14:25] <stgraber> lool: I guess that's fine, we're not using system-image on non-touch devices yet (or touch devices without android), once we do, we'll regret hardcoding those bits
[14:25] <lool> right
[14:26] <barry> *properly
[14:26] <lool> stgraber: very good examples of why it's a good idea to centralize this  :-)
[14:26] <lool> (IMO)
[14:26] <seb128> mterry, hey, do you know about "lock on idle", is that greeter thing? if not, do you know who might?
[14:27] <stgraber> lool: sure, so long as we don't hardcode things like ubuntu-rootfs and android in system-image either (would be a bit of a pain having to change the API once we drop android)
[14:29] <mterry> seb128, it's a powerd thing I think
[14:29] <mterry> seb128, well wait
[14:29] <mterry> seb128, you mean suspend on idle or lock -- i.e. showing greeter?
[14:29] <seb128> mterry, I mean lock
[14:29] <mterry> showing greeter is in shell/greeter
[14:29] <mterry> seb128, what's up?
[14:29] <seb128> mterry, https://wiki.ubuntu.com/SecurityAndPrivacySettings#phone-locking
[14:29] <seb128> "Whenever “Phone locking” is set to “None”:
[14:29] <seb128>     “Lock when idle” should instead read “Sleep when idle”. "
[14:30] <seb128> mterry, we have a settings for "lock after ..." and one for "suspend after ..."
[14:30] <seb128> mterry, similar to desktop screensaver and suspend time
[14:30] <seb128> mterry, e.g you might lock after 1 min idle and suspend after 3 min idle
[14:31] <mterry> seb128, fascinating.  So that'll probably be watched by shell or something similar in the session.  Then ask lightdm to lock
[14:31] <seb128> mterry, "fascinating" ... I guess the requirement was not known on your side?
[14:31] <seb128> mterry, unity8 wishlist bug I guess? ;-)
[14:31] <mterry> seb128, I hadn't reviewed all the system settings stuff yet
[14:32] <mterry> seb128, is there a question you had?
[14:33] <seb128> mterry, the question was "is there a setting/gsettings key I can write to for that already" I guess
[14:34] <mterry> seb128, ah, not yet to my knowledge.  I think gsettings makes sense for that though
[14:34] <seb128> mterry, we use "com.canonical.powerd activity-Timeout
[14:34] <seb128> for the suspend time
[14:34] <lool> stgraber, barry: Will capture in a bug report
[14:34] <seb128> mterry, that would be good yes
[14:34] <barry> lool: +1
[14:34] <seb128> mterry, anyway, https://bugs.launchpad.net/unity8/+bug/1215954
[14:35] <mfisch> lool: the LP project for customization hooks was renamed, a real rename must be done by LP admins (according to them)
[14:35] <seb128> mterry, sorry, refreshed in firefox resubmitted it, using https://bugs.launchpad.net/unity8/+bug/1215957 and closing the other one
[14:37] <lool> mfisch: cool thanks
[14:37] <sforshee> mterry, seb128: fyi, the idle timeout is planned to move out of powerd and into unity8, and that gsetting will go away
[14:38] <seb128> sforshee, why do you hate us :p
[14:38] <lool> barry, stgraber: LP #1215959
[14:38] <sforshee> seb128: I don't. We had to shove stuff into powerd to get it working "now" even though it didn't really belong there.
[14:38] <lool> seb128: sub-ing you  ;-)
[14:38] <seb128> sforshee, please don't drop the schemas when you move it, otherwise you are going to make system settings abort
[14:38] <asac> lool: i have a nothe rcall for 30 minutes
[14:38] <asac> then i can think about stuff
[14:38] <asac> i dont know what image publication means
[14:38] <seb128> sforshee, e.g let us a migration time
[14:38] <lool> asac: careful not to think while you're in that call
[14:39] <asac> todays image is too bad for pushing to /current at least
[14:39] <seb128> lool, thanks
[14:39] <sforshee> seb128: sure, we can do that
[14:39] <barry> lool: ack
[14:39] <seb128> sforshee, do you have a bug or WI to track the move of that setting to unity8?
[14:39] <sforshee> seb128: for some reason powerd can't pick up changes to the settings at runtime anyway. The code is there, but it doesn't work.
[14:40] <plars> sergiusens: looks good, I've done lots of reboots, and uevent is behaving
[14:40] <sforshee> seb128: https://blueprints.launchpad.net/ubuntu/+spec/pm-system-policy has a WI for it
[14:40] <sergiusens> plars: great, since I just applied the patch :-)
[14:40] <sergiusens> ChickenCutlass: ^^
[14:40] <seb128> sforshee, thanks
[14:40] <lool> asac: so IMO some developers here are apt-get updating instead of phablet-flashing to latest image, and so are not tracking the same baseline than /current / QA is tracking; this will be fixed with new images, but it will delay propagation of fixes to developers
[14:41] <lool> asac: especially if we wait multiple days to land stuff
[14:41] <lool> so we need to get back to being good enough for publishing every day and also think about bumping the frequency
[14:41] <lool> like building multiple times per day
[14:41] <sergiusens> it's 2x now
[14:42] <sergiusens> 2x CDs (from cdimage)
[14:42] <lool> sergiusens: oh
[14:42] <lool> that's good
[14:43] <asac> lool: so tracking pending would be good :)
[14:43] <ogra_> * UTC
[14:43] <lool> I like the 4h beat
[14:43] <ogra_> err
[14:43] <lool> asac: it will
[14:43] <ogra_> 8 UTC
[14:43] <ogra_> AM and PM
[14:43] <lool> asac: oh sorry, /current
[14:43] <lool> asac: developers wont use daily-proposed
[14:43] <lool> at least that's not what it's for
[14:43] <ogra_> we do all the time
[14:43] <asac> lool: yeah, but we can install dail-proposed
[14:43] <lool> asac: are you saying we need another channel to track pending?
[14:44] <asac> so upgrading is basically just an inefficent reinstall
[14:44] <lool> asac: you can, but then you cant upgrade from it
[14:44] <ogra_> unless daily-proposed is different from /proposed
[14:44] <lool> asac: this seems wrong
[14:44] <asac> lool: we could upgrade, which is basically a dumb reinstall because we have to get the latest /current as well
[14:44] <lool> asac: I think we need to discuss channels again; the design of daily-proposed is just for QA purposes
[14:44] <lool> but it's expected that stuff propagate fast to daily
[14:44] <seb128> mpt, is the difference between "sleep on idle" and "lock on idle" only whether the screen should be locked when sleeping? (e.g they don't have 2 different timeout configs)?
[14:44] <asac> yeah. i think it all boils down to: how often do we get /current and how can engineers see their latest development early
[14:44] <asac> on their own device
[14:45] <ogra_> lool, right, the turnwround times aree to long atm
[14:45] <lool> (/me now realizes that naming something "daily" and then adjusting the frequency was fundamentally bad  :-)
[14:45] <asac> lool: its expected but not given... especially for now we are not at a guaranteed daily rate
[14:45] <mpt> seb128, right, the time value doesn't change when you change the lock security.
[14:45] <seb128> mpt, what should the description says in https://wiki.ubuntu.com/SecurityAndPrivacySettings?action=AttachFile&do=get&target=phone-security-privacy-idle.png then
[14:45] <mpt> It's just a renaming.
[14:45] <seb128> mpt, "Sleep the device..."?
[14:45] <lool> asac: I think we want another chat about channels after release too
[14:45] <asac> lool: we could call it ubuntu-central or trunk :)
[14:45] <seb128> mpt, or Suspend..?
[14:45] <asac> and the other trunk-incoming
[14:45] <lool> asac: we haven't planned anything for post saucy
[14:45] <lool> asac: like monthly
[14:45] <mpt> oh la la
[14:45] <ogra_> seb128, "Zzzzz"
[14:45] <lool> asac: rolling!  (hahaha)
[14:45] <seb128> ogra_, ;-)
[14:46] <asac> yeah, but incoming is good. what is clear that we must be able to pretty conveniently install latest incoming
[14:46] <asac> i guess its a reinstall
[14:46] <ogra_> lool, i personally would like to see builds auto triggered as soon as a certain percentage of packages in the seed has changes vs last build
[14:46] <asac> for now, but having a on-device tool to tmake that possible might help
[14:47] <asac> and avoid rerunning phablet-flash
[14:47] <lool> asac, stgraber: How about a vUDS chat about channels we'll need on the long term?
[14:47] <ogra_> (plus on-demand builds)
[14:47] <lool> asac, stgraber: for instance for saucy release
[14:47] <lool> s#long term#in the next weeks/months#
[14:47] <asac> i think it makes sense to have such discussion
[14:48] <asac> at best someone would present what otheres are doing on channels
[14:48] <asac> and then what we could do out of that
[14:48] <asac> and how we marry that with our release/code names
[14:48] <mpt> seb128, fixing now...
[14:48] <sergiusens> lool: asac ogra_ to be perfectly honest, developers most of the people installing pending are people that modify the image, going into developer mode and thus rendering the use case sort of moot
[14:48] <asac> and how we treat incoming/proposed
[14:48] <lool> sergiusens: true
[14:48] <ogra_> sergiusens, ++
[14:49] <asac> sergiusens: can you please start calling this "system builder mode" ... developer mode is for SDK folks
[14:49] <asac> :)
[14:49] <asac> thx
[14:49] <lool> sergiusens: still, we need a plan for saucy
[14:49] <ogra_> plumber mode :)
[14:49] <lool> I mean saucy relesae
[14:49] <asac> and i am not sure about that arguement yet. It feels like a valid point
[14:49] <sergiusens> asac: I already asked stgraber to change the .developer_mode into .image_developer
[14:49] <asac> but will think over the weekend if there is a strategic trap hidden inside :)
[14:49] <seb128> mpt, thanks
[14:49] <lool> sergiusens: should I log a bug for s/.developer_mode/.image_developer/?
[14:50] <asac> sergiusens: ok sounds better.
[14:50] <asac> but we still want developer mode that enables adb and equiv
[14:50] <asac> and maybe installing sdk addons
[14:50] <asac> like -dev packages in some not-yet-defined format
[14:50] <asac> :)
[14:51] <lool> asac: Still, there's a fundamental break if your image baseline is not what developers use IMO
[14:51] <asac> sergiusens: why not call it system_builder_mode :)
[14:51] <asac> i really like that far more
[14:51] <asac> than image_developer :)
[14:51] <asac> system_hackery
[14:51] <asac> lool: i know. i am actually for the idea of having for every channel somethign special that is "-incoming"
[14:52] <ogra_> plumber_mode
[14:52] <asac> and we should indeed not invest in convenience to track that
[14:52] <lool> why not system_veränderung_möglichkeit
[14:52] <lool> that way nobody can turn it on
[14:52] <awe> lool, ping
[14:52] <asac> yeah lets use umlauts
[14:52] <lool> awe: w00t
[14:52] <stgraber> sergiusens: I'm most likely to call the flag .writable_image that way I don't have to care about what people want to call the role
[14:52]  * awe wonders what he did to warrant a w00t!  ;)-
[14:52] <lool> .I_dont_care
[14:53] <lool> awe: a ping
[14:53] <awe> lool, https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-touch-flight-mode
[14:53] <awe> not sure if it's too late to schedule for next week
[14:53] <asac> .gimme_apt_back
[14:53] <asac> :)
[14:53] <lool> awe: awe-some, thanks for setting it up
[14:53] <sergiusens> stgraber: whatever works and stops the confusion
[14:53] <awe> please note you're the approver!
[14:53] <lool> awe: does it need discussion?
[14:54] <lool> sergiusens: could we make it good enough that less people turn rw on?
[14:54] <awe> lool, well, it'd be nice if I could try and get some cycles into a more formal spec on the wiki, then we could discuss
[14:54] <lool> sergiusens: perhaps 50% of people use phablet-flash and 50% apt-get, perhaps we can make it 75% system updates, 25% rw mode
[14:54] <awe> lool, I will flesh out the work items this afternoon
[14:55] <lool> awe: I felt there was good consensus on what had to be done; we could expose the plans or discuss details, but we don't need to force ourselves to discuss it if it's just repeating agreed upon stuff I guess?
[14:55] <awe> lool, rsalveti, tvoss, one other area which hasn't had much love is 'timed'
[14:55] <awe> lool, I'm perfectly fine not creating a session for it
[14:56] <diwic> rsalveti, ping
[14:56] <awe> however the timing was such, that we *could* do a session if it felt right
[14:56] <sergiusens> lool: that's not up to me... it's upt to how much we clickify
[14:56] <awe> lool, for instance, we have a session on mms, however I'm not sure what we're going to discuss during it either
[14:56] <sergiusens> lool: which in the long run is sort of up to me...
[14:59] <rsalveti> diwic: pong
[15:00] <lool> awe: Hmm given timescale, I'm not sure it's worth covering these many projects (timed, airplane-mode, mms); I need to check with asac
[15:00] <diwic> rsalveti, I think our android-platform-headers are too old, but we can take that in the meeting
[15:00] <lool> sergiusens: I was thinking platform stuff really, but you have a point
[15:01] <AskUbuntu> erro instalação no nexus 4 | http://askubuntu.com/q/336285
[15:02] <rsalveti> diwic: interesting, it might indeed be based on 4.0.4
[15:02] <rsalveti> diwic: I got a wip package with a more recent headers, as latest hybris uses the headers from an external package
[15:02] <rsalveti> but was able to get that done before leaving my vacation
[15:02] <rsalveti> diwic: did the android hal header changed that much?
[15:02] <tvoss> awe, indeed. want to have a session on that?
[15:03] <awe> tvoss, "want" is a strong word.
[15:03] <tvoss> awe, do you feel like we should have one?
[15:03] <diwic> rsalveti, in particular, the AUDIO_DEVICE_IN_* enum was completely overhauled
[15:03] <tvoss> ;)
[15:03] <awe> our stand-up just started, perhaps we can chat about this when we finish up
[15:03] <diwic> rsalveti, none of the numbers fit
[15:03] <rsalveti> diwic: :-(
[15:03] <rsalveti> diwic: I can get that updated quickly
[15:04] <rsalveti> diwic: which headers are you consuming?
[15:04] <rsalveti> so I can double check here
[15:05] <diwic> rsalveti, https://github.com/android/platform_system_core/commit/eeeee802e9837c592b0f0f9fd183bcaa9e77732e
[15:05] <diwic> rsalveti, that's the stuff I'm looking for, I think
[15:06] <rsalveti> diwic: cool, will take a look at it
[15:08] <awe> tvoss, so... to-date neither rsalveti or I have done any work on 'timed', and I'm not sure you've put any cycles into the platform API/SDK time functions...  so, I think it would be nice to re-sync and figure out what we can realistically get done for 13.10
[15:08] <rsalveti> +1
[15:08] <rsalveti> diwic: hm, I actually imported that header file from AOSP 4.2.2_r1.2
[15:08] <awe> tvoss, whether or not this is an official session is not something I have an opinion about
[15:08] <rsalveti> but will check in more detail
[15:08] <tvoss> awe, ack, let's make it an informal session then
[15:09] <tvoss> awe, not much use in saying: yeah, we want something like that
[15:09] <tvoss> awe, we clearly want
[15:10] <diwic> rsalveti, in short; the audio HAL on mako references the AUDIO_DEVICE_BIT_IN symbol, so I assume it is compiled with a version that has that symbol included
[15:10] <diwic> rsalveti, and our current android-platform-headers does not have that symbol
[15:11] <rsalveti> ok, that helps
[15:12] <diwic> rsalveti, http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_qcom_audio.git;a=blob;f=alsa_sound/audio_hw_hal.cpp;h=ab15e2744731cb8b72f2e75527b350b880afc1df;hb=HEAD#l122 in case you want to see where it is
[15:15] <mfisch> lool: I'm looking at scopes today, mhr3_ mentioned that we'd need a way to tell dbus that we've dropped service files into /custom
[15:16] <mpt> seb128, https://wiki.ubuntu.com/SecurityAndPrivacySettings?action=diff&rev2=27&rev1=26
[15:16] <lool> mhr3 mfisch: can't we start them by hand rather than autostarting?
[15:17] <lool> I guess these are running all the time anyway, unless disabled, or they wouldn't be included
[15:17] <pstolowski> tsdgeos, mhr3_ : using beginMoveRows seems to be working for categories, I'm experiencing some weirdness/bugs but it looks like it can work, so I'll stick with that instead of layoutChanged (and it's actually good since it will only signal changes to rows that relly have to be moved)
[15:18] <tsdgeos> pstolowski: hmmmm
[15:18] <tsdgeos> pstolowski: the limit filter proxy has not code for move i think
[15:18] <tsdgeos> not sure it's a good idea
[15:18] <tsdgeos> unless you want to add that code :D
[15:18] <mhr3_> lool, nah, scopes quit when idle
[15:19] <mhr3_> tsdgeos, the categories model is not "limited", only the results models are
[15:19] <tsdgeos> ah
[15:19] <tsdgeos> oka
[15:19] <lool> Hmm apparently there's this in /etc/dbus-1/system.conf:
[15:19] <pstolowski> yup
[15:19] <lool>   <!-- We use system service launching using a helper -->
[15:19] <lool>   <standard_system_servicedirs/>
[15:19] <pstolowski> tsdgeos: and well, we need to reorder categories, we have no choice ;)
[15:20] <lool> servicedir can be used to add a directory
[15:20] <seb128> mpt, thanks
[15:21] <mhr3_> lool, i think standard_*dirs includes XDG_DATA_DIRS
[15:21] <lool> mhr3_, mfisch: Seems dropping a <servicedir>/custom/share/dbus-1/services/</servicedir> should work in system.conf
[15:21] <lool> mhr3_: oh does it
[15:21] <lool> mfisch: would you verify whether setting XDG is enough?
[15:21] <mfisch> lool: yeah I'm doing that today
[15:21] <lool> mfisch: in which case that's what we should do
[15:21] <lool> cool
[15:21] <mfisch> lool: where would we set it? the user session?
[15:21] <lool> mfisch: yeah
[15:21] <mhr3_> lool, also, we need session dbus, not system ;)
[15:21] <mfisch> or does it need to be system wide
[15:21] <mfisch> ok
[15:21] <lool> mfisch: pretty much like DCONF_PROFILE I guess
[15:21] <mfisch> ok
[15:21] <mfisch> I'll try today
[15:22] <mhr3_> mfisch, it does need to be set before session dbus is started
[15:23] <mfisch> mhr3_: ok
[15:23] <dpm> mardy, perhaps you could help this app developer? -> http://askubuntu.com/questions/336069/how-do-i-use-oauth-from-an-ubuntu-touch-app
[15:23] <awe> plars, updated https://bugs.launchpad.net/touch-preview-images/+bug/1215724
[15:23] <awe> plars, don't run system test on phones w/out SIMs
[15:24] <mhall119> Saviq: sergiusens: any idea where the network indicator has gone off to in the latest builds?
[15:24] <awe> this will be possible once emergency mode is fully implemented, but not currently
[15:24] <ogra_> mhall119, should still be there
[15:24] <sergiusens> mhall119: there was an indicator switch
[15:24] <awe> mhall119, it's there, but hidden
[15:24] <sergiusens> may be flaky
[15:24] <ogra_> mhall119, the icon is missing apparently
[15:24] <awe> mhall119, it's being worked on
[15:24] <mhall119> ogra_: no, it's just not there, not even in the tabs
[15:24] <mhall119> thanks awe
[15:24] <popey> mhall119: it disappeared for me the other day
[15:24] <awe> mhall119, if you play around with some of the other indicators, it can be triggered to appear
[15:25] <awe> mhall119, we landed the new indicator-network this week
[15:25] <Saviq> mhall119, we're just missing an icon probbaly
[15:25] <Saviq> dednick_, that correct ↑ ?
[15:25] <awe> Saviq, the icon is there
[15:25] <awe> Saviq, there's some weird race in the shell/panel code
[15:25] <Saviq> dednick_, ↑
[15:25] <mhall119> Saviq: it should be in the indicator tabs even if the icon was missing
[15:25] <awe> Saviq, tedg is also working on code to handle dual icons for an indicator
[15:26] <awe> ( so indicator-network can show wifi & telephony icons )
[15:26] <tedg> awe, Not doing the handling, I'm doing the feeding :-)
[15:26] <Saviq> awe, yeah dednick_ is doing the handling :)
[15:26] <mhall119> Saviq: I don't see the process running either
[15:26] <dednick_> Saviq: hm. i think it might be that the backend is requesting an icon we done have
[15:26]  * tedg throws a banana at dednick_ ;-)
[15:27] <dednick_> tedg:
[15:27] <Saviq> mhall119, interesting, maybe it crashed?
[15:27] <tedg> If you guys are talking about the icon, it's fixed in trunk.
[15:27] <mhall119> ah, indicator-network isn't even installed
[15:27] <dednick_> tedg, Saviq: i think it's a nm-signal-0 , nm-signal-00 issue
[15:27] <Saviq> mhall119, ah, dist-upgrade must've failed
[15:27] <tedg> dednick_, Oh, I thought it was the no-network one.
[15:28] <Saviq> dednick_, in that case mhall119 didn't even have indicator-network installed :)
[15:28] <Saviq> dednick_, so we're "good"
[15:28] <mhall119> sudo apt-get install --fix-policy
[15:28] <mhall119> didn't install it either
[15:28] <mhall119> The following packages have been kept back: ubuntu-touch
[15:28] <mhall119> could that be my problem?
[15:28] <dednick_> yeah
[15:29] <dednick_> just do manual install of ubuntu-touch and it should fix it
[15:29] <mhall119> that'll remove chewie, what is chewie?
[15:29] <ogra_> dead beef
[15:29] <mhall119> and yes, it's saying it'll install indicator-network when I do this
[15:29] <dednick_> mhall119: old network indicator
[15:29] <mhall119> ok, so maybe other people are having an issue with this too?  I didn't do anything particularly strange that would have caused this
[15:30] <ogra_> why did you uninstall ubuntu-touch in the fist place ?
[15:30] <mhall119> I didn't
[15:30] <mhall119> not manually anyway
[15:30] <ogra_> well you installed something that removed it then
[15:30] <ogra_> and allowed it to
[15:30] <mhall119> ubuntu-touch ws installed, just held back
[15:30] <ogra_> that cant be
[15:31] <ogra_> the image wouldnt build
[15:31] <mhall119> ubuntu-touch: Installed: 1.049 Candidate: 1.051
[15:31] <ogra_> ubuntu-touch is a required package
[15:31] <ogra_> ah
[15:31] <mhall119> I've been apt-get dist-upgrading
[15:31] <ogra_> you didnt run dist-upgrade then
[15:31] <dednick_> ogra_: the upgrade was held back
[15:31] <mhall119> did too :P
[15:31] <ogra_> dednick_, it cant if you run dist-upgrade
[15:31] <mhall119> I *always* run dist-upgrade on my device
[15:31] <mhall119> not just upgrade
[15:34] <seb128> pete-woods, hey, can you explain to me why we need "indicator-secret-agent" as a new source/component rather than having it in indicator-network (I've been asked to review it for NEW in the archive, but it seems a buggy approch to me)
[15:34] <mhall119> alecu: already installed apps aren't showing up in More Suggestions anymore \o/
[15:34] <mhall119> however, xda-developers is showing up twice in Installed section
[15:34] <jcollado> sergiusens: Hello. I'm trying to flash a system image with phablet-flash and it seems that it's frozen in '<waiting for device>': http://pastebin.ubuntu.com/6018189/
[15:34] <ogra_> mhall119, because it is double plus good ?
[15:35] <mhall119> well I'm not one to brag but....
[15:35] <jcollado> sergiusens: I haven't yet been able to flash a system image, so I'm wondering if there's some configuration or something that I should have done before calling phablet-flash. Any advice?
[15:36] <pete-woods> seb128: it should be its own process - it deals with passwords, so why not have it in another package?
[15:36] <pete-woods> it doesn't interact with indicator-network - it interacts with network manager and unity
[15:36] <seb128> pete-woods, because having more tarballs, vcs, sources, bug lists, etc is a pain to deal with
[15:37] <slangasek> jcollado: did you start here? https://wiki.ubuntu.com/Touch/Install#Step_2_-_Device_unlock
[15:37] <mhall119> alecu: actually, it looks like all of my Click package apps are showing up twice in the Installed section
[15:37] <seb128> pete-woods, why do we need something specific to nm passwords? should we get a some auth framework in unity8 instead that any app needing to deal with passwords need?
[15:38] <pete-woods> seb128: it will be talking to the unity8 auth dialogue, if that's what you mean?
[15:38] <pete-woods> plus the code has like 100% test coverage, and will continue to to do
[15:38] <seb128> pete-woods, I guess I don't understand what that composant is doing/needed for
[15:39] <pete-woods> something has to register itself as a password agent for nm
[15:39] <pete-woods> currently that's unity8
[15:39] <pete-woods> but the unity guys don't want it that way any more
[15:39] <jcollado> slangasek: Yes. I've flashed the device many times with touch images (phablet-flash cdimage-touch), but for some reason I'm not able to flash a system image (phablet-flash ubuntu-system).
[15:39] <seb128> shouldn't we make indicator-network provide the UI and register as an agent then?
[15:40] <pete-woods> seb128: well that's exactly what this thing does, it's just not called indicator-network
[15:40] <slangasek> jcollado: ah, ok.  I have no idea, then; that should Just Work
[15:40] <pete-woods> and it's not written in Vala
[15:40] <seb128> pete-woods, so now we have 2 different tarball/projects/bugslists/etc
[15:41] <pete-woods> seb128: is the main concern you have that it's in another package?
[15:41] <seb128> pete-woods, yes
[15:41] <seb128> as said it makes bugs a pain to track
[15:41] <seb128> you have yet another list to watch
[15:41] <seb128> yet another package to upload
[15:41] <seb128> etc
[15:42] <seb128> pete-woods, it seems to be that's not enough code to warrant being split out from indicator-network to a new project...
[15:42] <ogra_> also in tehg light of PRISM i would debate the package name
[15:43] <ogra_> having something installed that has "secret-agent" in the name etc...
[15:43] <davmor2> ogra_: call it bond instead :D
[15:43] <ogra_> ++
[15:44] <ogra_> indicator-bond ... shows the level of your oedipus complex
[15:45] <ogra_> or macho-ness ?
[15:45] <davmor2> haha
[15:45] <davmor2> or gadget levels connected to your phone
[15:47] <davmor2> ogra_: if you get to "The names Bond, James Bond" you have too many devices attached and you phone self-destructs while playing mission impossible music
[15:48] <pete-woods> seb128: I will have to ask my manager (thostr) what I should do
[15:48] <pete-woods> if he says it's okay to try and merge the codebases I will do that
[15:48] <seb128> pete-woods, thanks
[15:48] <seb128> cyphermox, tedg: ^
[15:49] <ogra_> davmor2, haha
[16:02] <alecu> mhall119: sorry, I'm not working today, I'll handle it on monday
[16:03] <mhall119> alecu: ok, no rush, it's not preventing anything
[16:03] <davmor2> ogra_, pmcgowan: Oh that's interesting.  My phone has been on the side for a while and it just rang perfectly and displayed the indicator
[16:03] <tedg> awe, What's the scale on the oFono strength?  Walked around the neighborhood and the highest I got was 26.
[16:03] <tedg> awe, I mean, not impossible... but I would have expected higher values if it was out of a hundred.
[16:03] <pmcgowan> davmor2, sun spots
[16:04] <pmcgowan> heisenbugs
[16:04] <davmor2> pmcgowan: I still blame ogra_ it worked fine till he said it didn't :)
[16:04] <awe> tedg, lemme check
[16:04] <ogra_> well, it doesnt work at all for me ... still
[16:04] <kgunn> ricmm: would your current work around life cycle potentially address the launch issue described here?
[16:04] <kgunn> https://bugs.launchpad.net/mir/+bug/1215997
[16:04] <tedg> Oh, there's a 35 :-)
[16:06] <davmor2> pmcgowan, ogra_: I'm noticed though that it rang before the indicator appeared so I'm wondering if before the indicator appeared first and so didn't ring?
[16:06] <tedg> kgunn, I think that greyback had to custom set the qt backend to get things working.
[16:07] <kgunn> tedg: thanks
[16:07] <tedg> kgunn, Apparently we can't autodetect that, which is confusing to me :-/
[16:07] <pmcgowan> davmor2, bfiller and boiko are working on it afaik
[16:09] <greyback> kgunn: looking into it.
[16:13] <sergiusens> jcollado: adb reboot bootloader, then fastboot devices
[16:13] <ogra_> sudo :)
[16:14] <awe> ted, the low-level range of GSM signal strengths is 0-31; rilmodem converts this to a 0-100 range [ signal = ((gsm_signal * 100) / 31 ) ]
[16:15] <awe> tedg, same for all the other technologies
[16:15] <awe> ( ie. 0-100 range for strength is returned _
[16:16] <tedg> awe, From NM or from oFono?
[16:16] <awe> from ofono
[16:16] <tedg> awe, I was confused by "all other technologies" part
[16:16] <awe> there's no cell signal strength from NM
[16:16] <tedg> Cool.  Apparently my neighborhood is to blame ;-)
[16:16] <awe> ;D
[16:17] <jcollado> sergiusens: Those commands seem to work. Should I run `phablet-flash ubuntu-system` again after that?
[16:17] <sergiusens> jcollado: yeah
[16:18] <sergiusens> jcollado: if you get waiting for device, just replug it
[16:21] <AskUbuntu> can use c++ write custom qml plugins in ubuntu sdk | http://askubuntu.com/q/336325
[16:30] <ricmm> greyback: whats the issue there?
[16:30]  * davmor2 is on holiday next week so I won't be around to break stuff, I hope you can manage to break stuff without me :D
[16:30] <sergiusens> davmor2: we will wait for you!
[16:31] <davmor2> haha
[17:23] <jcollado> sergiusens: After some trial and error, I've seen that if I try to flash the device using my own user it works, but if I try to do it using the jenkins user, to have the same environment as in the lab, it fails.
[17:24] <jcollado> sergiusens: Despite I've already flashed the device, I still want to use the jenkins user for that. I guess there's a permission problem somewhere, but I'm not sure where to look at.
[17:25] <jcollado> sergiusens: Do you have any advice to fix that problem?
[17:30] <ryukafalz> So with the latest images, can you safely update packages with apt rather than reflashing every time or does that not yet work?
[17:30] <popey> jcollado: is the jenkins user logged into the desktop?
[17:30] <popey> jcollado: i found that if I ssh to my laptop and flash a device it fails, but if I am signed into the desktop on the laptop and then ssh in, it works
[17:32] <sergiusens> jcollado: the udev rules allow for the user that has the seat to flash
[17:32] <sergiusens> jcollado: you can get by it by using sudo or relaxing the udev rule shipped in android-tools-fastboot and android-tools-adb
[17:33] <jcollado> sergiusens: What do you mean by "has the seat"?
[17:34] <sergiusens> jcollado: is _logged_ in
[17:35] <jcollado> sergiusens: Ok, so it's what popey suggested. Thanks.
[17:35] <jcollado> sergiusens: It's kind of strange because I've never had this problem flashing touch images.
[17:36] <sergiusens> jcollado: maybe because you never bootstrapped and might have a custom udev rule in there?
[17:38] <jcollado> sergiusens: I guess you're right
[17:47] <mfisch> lool: so far no joy on XDG_DATA_DIRS, the job isn't seen and I have an issue pre-pending in upstart since the job doesn't inherit the original value
[17:54] <TheSpirit> Hello, is Ubuntu Touch stable enough to use in every day use? I have a Nexus 7 (2nd Generation) and I would like to program in C++ in it.
[17:56] <k1l> i think some people in here use it as a daily phone (at least jono does :) ).
[17:56] <TheSpirit> Oh great. Does it have Facebook? :p
[17:56] <k1l> not the nexus7 but the gnex and nexus4
[17:58] <TheSpirit> k1l, do normal applications work properly? I would like to be using Qt Creator.
[17:59] <k1l> sorry i dont know
[18:00] <pmcgowan> TheSpirit, you can use qtcreator on your desktop and remotely access the nexus 7
[18:01] <TheSpirit> pmcgowan, I won't have access to my desktop. I'm want my device to be a portable so I can program on the day (such as when I'm at college).
[18:01] <TheSpirit> I want*
[18:02] <TheSpirit> on the go8
[18:02] <pmcgowan> TheSpirit, I see, the touch image is not really intended for that, but there has also been a desktop image for the nexus 7 that could work
[18:02] <TheSpirit> pmcgowan, do you know if it works with the second generation Google Nexus?
[18:02] <TheSpirit> And is it still maintained?
[18:02] <pmcgowan> no I dont think it does
[18:03] <TheSpirit> Ah, okay, thanks.
[18:19] <nRazor> does anybody know where I can find the group working on the port to the new nexus 7 codenamed razor?
[18:19] <nRazor> want to see if I can either contribute or if it is in a stable build yet, google isn't returning much results that are relevent
[18:21] <pmcgowan> nRazor, there was a thread on this on the mailing list, summary was waiting for the cyanogenmod to be done
[18:25] <AskUbuntu> Nexus 4 Fails to Boot After Ubuntu Touch Flash | http://askubuntu.com/q/336352
[19:26] <Sathed> I'm hoping someone can help me figure out this issue I'm running in to. I recently flashed Ubuntu Touch to my Nexus 4. Everything seems to work great except data. I'm running the latest daily build that I flashed with CWM recovery.
[19:28] <popey> Sathed: restart network manager
[19:29] <popey> as in.. "adb shell" "restart network-manager"
[19:30] <Sathed> Thanks. I'll give it a shot.
[19:42] <Sathed> Is there another way to restart the network manager? I don't have a Linux machine at work to install the touch developer tools on.
[19:44] <sergiusens> Sathed: use the terminal app
[19:50] <Zackehh> Anyone any idea why ubuntu_chroot exists in my build output, but not on the device after flashing?
[19:52] <Sathed> Okay, so I restarted the network manager, but I'm still not getting data.
[19:52] <Sathed> I restarted with: sudo service network-manager restart
[20:07] <Sathed> Any other thoughts on getting data working?
[20:11] <Ewixy> Hello all :)
[20:15] <Zackehh> Hey
[20:20] <lool> mfisch: strings =dbus-daemon|grep XDG shows that it reads them, you could try stracing perhaps?
[20:21] <lool> mfisch: or check the source code for supported cases
[20:21] <mfisch> lool: I'm also looking at dropping them into ~/
[20:21] <lool> mfisch: not sure it's a good idea to have things in ~/
[20:22] <lool> mfisch: things in ~/ are harder to update (need a startup job to update them), while things you get in custom.tgz will be static / r/o and can be updated
[20:22] <mfisch> lool: me either, but I cannot get dbus to find service files in custom, I will keep looking at code after this meeting
[20:22] <plars> awe: we now have a sim card in that mako that ran the tests without last time
[20:22] <lool> mfisch: cheers
[20:23] <awe> plars, I was just looking at the bug closer.  From the logs, it appears there was a SIM in it
[20:23] <plars> oh?
[20:23] <awe> plars, however a QUERY PIN state was failing, and ofono crashing
[20:23] <plars> I was under the impression that it just got installed today
[20:23] <awe> well the tests have today's time stamp
[20:23] <awe> ;)
[20:24] <awe> I have a bunch of separate comments re: the test output that might help improve readability
[20:24] <awe> plars, look at the jenkins output and search for "Querying PIN"
[20:24] <plars> awe: I opened the bug late last night, with the 20130822.1 image, but the datestamp may have been today since it was already today in UTC
[20:24] <awe> ofonod dies shortly thereafter
[20:25] <plars> I'll find out when it got installed though
[20:26] <awe> plars, with no SIM installed, you'll see the following messages from ofono: Version, a bunch of "Ignoring" plugin messages, [UNSOL]< UNSOL_RIL_CONNECTED
[20:26] <awe> and then "No SIM card present."
[20:27] <plars> awe: well, I was just told about the sim card getting installed today, but could be that it was actually in there last night when the tests ran
[20:27] <awe> no such error in the test run you attached to the bug
[20:27] <plars> I just didn't know at the time
[20:27] <awe> np
[20:27] <plars> if it was
[20:27] <awe> looks like it was
[20:27] <awe> ;)
[20:27] <awe> that said, there's definitely a bug being triggered, and ofono crashes repeatedly
[20:27] <awe> so I'm on it
[20:29] <awe> plars, any way you can get your hands on the ofonod crash files?
[20:30] <awe> also fyi, the download-mgr also looks like it crashed too
[20:31] <plars> awe: oh, I thought you said you had seen the .crash files
[20:31] <plars> awe: here's one from a test on today's image: https://jenkins.qa.ubuntu.com/job/saucy-touch-mako-smoke-ubuntu-clock-app-autopilot/37/artifact/clientlogs/_usr_sbin_ofonod.0.crash/*view*/
[20:31] <plars> awe: you can remove the /*view*/ to force the download
[20:32] <awe> that's nice 'cause I don't think I can read uuencoded hexadecimal crash dumps at will
[20:32] <awe> ;)
[21:11] <Luca> Hello there
[21:20] <plars> awe: ok, I got the full story from rick now... it was installed yesterday, but it wasn't activated until today
[21:21] <awe> ah.... that goes a long way to explain things
[21:21] <awe> basically, ofono saw the SIM card as present
[21:21] <awe> but it couldn't talk to the SIM
[21:21] <awe> which caused an ofono crash
[21:21] <awe> I haven't been able to get much from .crash file, other than it's a strlen crash
[21:22] <awe> I guess I can try and force the crash to happen, by hard-coding some internal state
[21:22] <awe> plars, I'm going to lower the priority, re-title, and assign to myself
[21:23] <plars> awe: sounds good, thanks
[21:24] <awe> what kind of plan?  pre-paid, normal billing?  We might want to try and reproduce this, but I'm not sure w/out getting another fresh SIM that hasn't been activated
[21:25] <plars> awe: I think it's one of the straight-talk type sims, basically month-to-month contractless
[21:25] <awe> plars, if you could get the details, I'd appreciate it
[21:26] <awe> if it's a month-to-month
[21:26] <awe> then we should get another and try the same scenario
[21:26]  * awe doesn't like crashes
[21:27] <plars> awe: if you talk to larry or rick, they may have one just like it you can try
[21:27] <plars> awe: it's month-to-month straight talk though, they think this particular one was on the AT&T network
[21:27] <plars> awe: I have one like it at home, but on tmo
[21:33] <awe> plars, who handled this particular phone?  Can you ask them to add a comment about the SIM card to the bug ( operator, plan, where purchased, ... )?
[21:33] <awe> that would be a big help
[21:33] <awe> if they have a spare that hasn't been activated, I can drive into Lex to use it
[23:09] <vadi> What happened to the Ubuntu plugins to Qt Creator in the latest 12.04 PPA updates? They seem to have removed them.
[23:54] <Sidim> Is Ubuntu touch on Nexus 4 comes with the full desktop experience when docked.


[05:09] <pitti> Good morning
[05:28] <didrocks> good morning
[05:30] <flocculant> morning pitti didrocks
[05:30] <pitti> bonjour didrocks et flocculant !
[05:31] <didrocks> good morning flocculant, pitti!
[05:34] <flocculant> not sure about good - it's certainly early - woke up at 4 couldn't get back to sleep ...
[05:36] <didrocks> urgh
[08:17]  * didrocks is really annoyed by xnox's pkgconfig merge with debian for his tests :)
[08:17] <didrocks> (finally got the time to have a look at this issue that only happened on "desktop", where pkg-config is installed
[08:17] <didrocks> not like my builders or autopkgtests setup :p
[08:43] <Trevinho> Good morning!
[08:43] <didrocks> hey Trevinho, how are you?
[08:44] <pitti> didrocks: oh, something broken there? the merge happened a month ago already
[08:44] <Trevinho> didrocks: I can say quite well, finally.
[08:44] <Trevinho> didrocks: you?
[08:45] <didrocks> pitti: yeah, the issue is that when you install pkg-config, you have a dpkg hook installed now
[08:46] <didrocks> pitti: and this hook doesn't work well when you use dpkg --root
[08:46] <didrocks> I'm unsure if dpkg --root shouldn't look at the hooks config in the usual dirs
[08:46] <didrocks> or if the hook should be fixed to not mixed with real installation when --root is used
[08:46] <didrocks> Trevinho: I'm good thanks!
[08:47] <pitti> didrocks: interesting, I wasn't aware of this mechanism even
[08:47] <didrocks> pitti: it's passing in builders and autopkgtests because I don't install pkg-config here, so I don't have the guilty hook
[08:47] <didrocks> yeah, I'm doing funky stuff to test adding an architecture and such in my tests :)
[08:48] <didrocks> and the hook hardcode the path, so I can't even just "discare it"
[08:48] <pitti> didrocks: could you just remove the hook for the tests?
[08:48] <pitti> if you don't care about cross-building
[08:49] <didrocks> pitti: how come? It's on the system itself in /etc/dpkg…
[08:49] <didrocks> pitti: so it means running those tests are root
[08:50] <didrocks> (and so, running those as root on my machine… :/)
[08:50] <pitti> didrocks: oh, I thought it breaks your tests
[08:50] <didrocks> it does
[08:50] <pitti> didrocks: ah, for that; so at least you want something nondestructive like sudo mount -o bind /dev/null /usr/share/pkg-config-dpkghook
[08:50] <didrocks> I can't run small tests locally on my machine itself now
[08:50] <pitti> which will make the test -x fail
[08:50] <didrocks> pitti: yeah, but this will require root as well, no?
[08:51] <pitti> didrocks: yes, it does
[08:51] <pitti> didrocks: oh, you call dpkg as user in a temp dir?
[08:51] <didrocks> yep
[08:51] <didrocks> (with fakeroot to install package)
[08:51] <didrocks> and --root=<path>
[08:52] <didrocks> local repo, everything locally brewed :)
[08:52] <pitti> didrocks: so why doesn't that take the dpkg config files from that fakeroot as well?
[08:52] <didrocks> pitti: yeah, I think that's the dpkg bug, it should IMHO
[08:53] <pitti> didrocks: you mean fakechroot bug?
[08:53] <didrocks> no
[08:53] <pitti> oh, fakeroot, not fakechroot
[08:53] <didrocks> fakeroot only
[08:53] <didrocks> I'm still using system dpkg and such
[08:53] <didrocks> just faking hiding dpkg with "dpkg --root…"
[08:53] <didrocks> s/faking//
[08:55] <didrocks> pitti: basically: https://github.com/ubuntu/ubuntu-make/blob/master/tests/small/test_requirements_handler.py#L59
[08:55] <didrocks> maybe there is a DPkg::<something> directive
[08:55]  * didrocks looks
[09:04] <didrocks> argh, it's a linked list when added
[09:04] <didrocks>   /* Add the new hook at the tail of the list to preserve the order. */
[09:04] <didrocks>   **hook_tail = hook_new;
[09:04] <didrocks>   *hook_tail = &hook_new->next;
[09:15] <Trevinho> didrocks: with new unity/launcher integration, we've a dbus dependency with nautilus (not that without it it wont' work, but still)... I was wondering whether. So should I add it to reccomends?
[09:18] <didrocks> pitti: filed a new upstream dpkg bug FYI
[09:19] <didrocks> Trevinho: what happens if nautilus isn't installed?
[09:19] <Trevinho> didrocks: well, launcher icons (the trash and devices one) won't be illuminated, or wont' control any window. They should work as they used to work before
[09:20] <Trevinho> didrocks: so only as a shortcut to open stuff
[09:20] <didrocks> Trevinho: ok, recommends sounds right then
[09:20] <didrocks> Trevinho: btw, not sure if you noticed, be the student updated his patch: https://code.launchpad.net/~mcintire-evan/unity/add_screenshot_shortcut_hints/+merge/280671
[09:21] <didrocks> Trevinho: I'm not sure we have any category matching well where to put this, but I guess, we don't want to expand with another one (and fighting with nux layouting ;))
[09:22] <Trevinho> yeah, I agree
[09:22] <Trevinho> also there's the thing that adding too many stuff might pretend the view to be shown in low resolutions (by low also <= 1366x768)
[09:23] <didrocks> Trevinho: yeah, so I guess where he added it is fine
[09:24] <didrocks> Trevinho: mind reviewing it once more? Will be nice to have it merged before EOW if possible :)
[09:25] <Trevinho> didrocks: yeah, I'd love to do an unity landing before xmas, but not sure it's sane. As I won't be back till 12nd...
[09:25] <larsu> good morning!
[09:26] <Trevinho> didrocks: and well, you might revert in case, but...
[09:26] <didrocks> Trevinho: well, I can consider the "approval" to be +1 for his code in task
[09:26] <didrocks> Trevinho: so, just approve if you feel so, already :)
[09:26] <didrocks> hey larsu
[09:26] <Trevinho> (old Trevinho would have merged it any day, but he's getting more responsible :PO)
[09:28] <larsu> hi didrocks!
[09:30] <didrocks> Trevinho: just review it, if it's good, tell me and I can close the task :)
[09:33] <Trevinho> didrocks: sure, I was in the meeting with kylin before... I'll do that shortly
[09:36] <didrocks> thx
[09:51] <didrocks> hum, one test become racy (only on xenial), seeing the diff, apt 1.1.5 sounds like a good guilty guy
[09:55] <didrocks> mvo: hey, is that expected with new apt that I can (not always), having multiple times the same status reported by the apt binding?
[09:56] <didrocks> mvo: this doesn't happen 100% of the time (with the same test), but if you look at<EMAIL_ADDRESS>I'm installing one package, one bit, I get twice:
[09:56] <didrocks> 2015-12-17 07:58:38,914 [umake.network.requirements_handler] DEBUG: ['testpackage'] download update: 0.0% of 1
[09:56] <didrocks> 2015-12-17 07:58:38,924 [umake.network.requirements_handler] DEBUG: ['testpackage'] download update: 0.0% of 1
[09:56] <didrocks> (I would expect to have progress triggers only if the percentage changes, even slightly)
[10:03]  * didrocks changed his test to be more resilient against this
[10:14] <mvo> didrocks: the way this works internally is that it call the progress callback periodically so that you don't need your own mainloop (if you set the timeout low enough). this has the side-effect that it will also report non-changes just so that you can refresh your ui
[10:18] <didrocks> mvo: ok, do you confirm that wasn't the case before or I just good lucky over the past 2 years?
[10:19] <didrocks> mvo: changing the tests to take that into account is quite easy for me, just wanted to know if I wasn't dreaming :)
[10:50] <xnox> didrocks, ? =)
[12:31] <didrocks> xnox: see my discussion with pitti about the dpkg trigger and --root suport
[13:00] <flocculant> didrocks can have 1 cookie, (I'll keep the one for 32 bit warm still, that failed to build) - thanks for fixing that :)
[13:05] <didrocks> flocculant: yw! happy to have found it :)
[13:06] <didrocks> flocculant: bonus: the initramfs is smaller than before the plymouth merge :)
[13:06] <flocculant> :)
[13:31] <xnox> didrocks, i keep wondering to make the 2x plymouth theme the default.
[13:31] <xnox> not because there are more high-dpi screens than normal, but because both are usable with 2x theme.
[13:33] <cyphermox> xnox: is the current plymouth theme unusable on high-dpi?
[13:33] <cyphermox> I mean, I would agree it likely is quite small, but still
[13:33] <ricotz> hi, could someone sponsor automake-1.15 merge -- https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/5781864/+listing-archive-extra
[13:33] <cyphermox> (I have no idea how it looks on high-dpi mind you)
[13:34] <didrocks> xnox: I don't know if there is any info from the script exported for this
[13:34] <didrocks> xnox: part of the issue is that the script will really need a complete rewrite, there is a lot of dead code in the ubuntu logo one
[13:36] <xnox> cyphermox, not usable at all. hence a while back i added a "2x" theme too, which one can manually opt into using update-alternatives.
[13:37] <xnox> didrocks, there are two scripts/themes packaged - 1x and 2x.
[13:38] <xnox> didrocks, is there any api to query screen dpi/scale factor these days as root? e.g. I could query gsettings or somesuch in postinst and automatically opt into 2x theme....
[13:40] <didrocks> xnox: no api AFAIK, (that's why we have the scale thingy in Unity)
[13:40] <didrocks> but query user's info gsettings key (user info) in postinst (root)
[13:40] <didrocks> hem… ;)
[13:40] <cyphermox> xnox: guess from xdpyinfo?
[13:40] <cyphermox> wait nvm, same issue
[14:02] <desrt> good morning, peeps
[14:03]  * ogra_ wonders in that light if leaning back and watching IRC scroll by then counts as peepshow
[14:04] <didrocks> good morning desrt
[14:07] <desrt> didrocks: what are you up to today?
[14:11] <didrocks> desrt: working on moving from jenkins to autopkgtests for ubuntu make tests
[14:11] <didrocks> as the jenkins infra is going down
[14:11] <didrocks> what about you?
[14:11] <desrt> doing my dance back and forth between dconf and glib.  did the dconf release yesterday, so back to glib today to add some new APIs that i can use from the next dconf release :)
[14:12] <didrocks> handy!
[14:12] <desrt> kinda ugly, in fact
[14:12] <desrt> i'm really increasing the coupling of dconf and glib here
[14:12] <desrt> oh well
[14:13] <desrt> in a way the coupling was already there insofar as all GSettingsBackend implementations are expected to be dconf-like
[14:13] <desrt> which is more complicated than it sounds
[14:36] <desrt> so i just got an email from asustor's RT-equivalent
[14:36] <desrt> i filed a ticket about missing files in their GPL package
[14:36] <desrt> i got zero reply from anyone
[14:36] <desrt> and now the system is telling me the ticket is being automatically closed due to inactivity
[14:36] <desrt> suggestions?
[14:36] <desrt> i'd prefer to avoid hiring a lawyer
[15:03] <bzoltan_> Mirv:  is there a known problem with the CI infra?
[15:05] <didrocks> Trevinho: the MP was updated
[15:05] <didrocks> oh you approved \o/
[15:05] <didrocks> rocking
[15:05] <Trevinho> didrocks: yeah :)
[15:29] <didrocks> pitti: probably a stupid question, but I don't find any answer on http://packaging.ubuntu.com/html/auto-pkg-test.html or https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure. What's the directory where I should push artefacts to be saved in swift? (or even with a local adt-run, if they can be stored outside the vm…)
[15:30] <pitti> didrocks: that's in https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html aka /usr/share/doc/autopkgtest/README.package-tests.*
[15:30] <pitti> didrocks: put them into  $ADT_ARTIFACTS/
[15:30] <didrocks> pitti: ah, excellent, thanks for the pointer :)
[15:30] <didrocks> ok!
[15:31] <didrocks> pitti: good news: docker tests run inside the vm without any trickery contrary to jenkins!
[15:31] <pitti> didrocks: with --output-dir=X they will appear in X/artifacts/
[15:31] <pitti> didrocks: nice! with trickery you mean the ssh -tt?
[15:31] <didrocks> yep!
[15:31] <pitti> didrocks: ah, same issue that we had back then
[15:31] <didrocks> indeed :)
[15:31] <didrocks> pitti: the only issue I have is that the testbed is set to something in /tmp (and I have a tmpfs limited to 2G here)
[15:32] <didrocks> so large tests don't run, need to find a way to tell "use the disk, son" ;)
[15:32] <pitti> didrocks: with VM?
[15:33] <pitti>  -o OVERLAY_DIR, --overlay-dir OVERLAY_DIR
[15:33] <pitti>                         Temporary overlay directory (default: in /tmp)
[15:33] <pitti> didrocks: ^ you want that then? perhaps /var/tmp/
[15:33] <pitti> didrocks: 2GB! you only have 4 GB?
[15:33] <didrocks> pitti: I have 8GB, but I like having enough for the browser and such
[15:33] <pitti> ah
[15:34] <didrocks> used 4.5GB here
[15:34] <pitti> didrocks: anyway, so adt-run [...] --- qemu -o /var/tmp/ yourimage.img
[15:34] <didrocks> pitti: excellent, thanks a bunch! :)
[15:35] <didrocks> pitti: I guess I'll be able to do everything is needed on my side. I guess the last things we will check is what's available through the proxy and if sourcing /etc/environment really works for docker
[15:35] <didrocks> (but that can wait January)
[15:36] <pitti> didrocks: right, but that shouldn't be an issue as long as you run tests locally?
[15:36] <didrocks> yep!
[15:36] <didrocks> at least, I'll have a reproduceable local system :)
[15:39] <pitti> Laney: yay prodstack troubles again (IS  knows)
[15:39] <pitti> Laney: I can't ssh into stuff, and all workers died
[15:40] <didrocks> hopefully, Laney is on holidays and won't see that :)
[15:53] <flocculant> I'll screenshot it for him
[15:54] <didrocks> poor Laney :p
[15:55]  * desrt observes the start of the eoy slowdown
[15:59]  * didrocks doesn't feel any slowdown with google code in :p
[16:29] <didrocks> pitti: the testbed isn't kept between tests? It would mean I need to put all tests in the same scripts (as I think we don't want to install ubuntu-desktop 4 times ;))
[16:29] <pitti> didrocks: depends
[16:30] <pitti> didrocks: the test bed is reset if
[16:30] <pitti>  - the current test declares "breaks-testbed", or
[16:30] <pitti> - the current test has Depends: which the next test does not have
[16:30] <didrocks> ahhhh
[16:30] <pitti> didrocks: and yeah, you really want to pre-prepare an image with u-desktop for taht
[16:30] <didrocks> so I need to keep the same Depends list
[16:30] <pitti> didrocks: same, or only add to it
[16:30] <didrocks> ok, let me try this
[16:31] <pitti> didrocks: but I suppose you'll run this more than once
[16:31] <didrocks> yeah :)
[16:31] <pitti> didrocks: so, cp the VM, start it, install u-desktop, and save that
[16:31] <didrocks> pitti: I have the desktop one, but I'm doing a little bit more in setup that just installing u-desktop
[16:31] <didrocks> I was using that just as an example
[16:32] <pitti> didrocks: well, sure -- if it's "cheap" setup that doesn't hurt, but installing u-desktop on a minimal cloud image sucks
[16:32] <didrocks> pitti: yeah, we discussed that, and agreed, we'll need to do something about it :)
[16:32] <didrocks> but let's try to get something ready first
[16:36] <pitti> didrocks: once we run that in production I can work on building desktop-ish images, this is just for not making you weep too much when running locally :)
[16:37] <didrocks> pitti: yeah, I'm already doing that with pleasure when I see that apt install -y ubuntu-desktop is just upgrading ubuntu-desktop package :p
[17:31] <didrocks> time to go, see you tomorrow guys!
[20:21] <alexarnaud> Good evening everyone !