[00:14] <nhaines> !devices > ^Manu
[00:14] <nhaines> I swear I'm going to remember that pip correctly in the future.
[00:45] <^Manu> cheers, that's where i've been. but it's over a year out of date.
[00:45] <^Manu> just thought people here might have some more up-to-date information or experience.
[02:14] <nhaines> ^Manu: unfortunately not.  That page is where porting teams are supposed to be updating about their efforts.  And if they can't even bother to do that... well...  :)
[02:15] <^Manu> reckon the experience has improved since mid last year? :)
[02:16] <^Manu> my immediate reaction to ubuntu touch; please please for the love of god support a hardware back button! don't make me go back to the travesty of ios :)
[02:16] <nhaines> Oh, it's an entirely new OS.  :)
[02:16] <nhaines> Back button is mostly standardized at the top of the screen now.
[02:17] <^Manu> 'mostly'
[02:17] <^Manu> and i argue that's the exact wrong place :P
[02:18] <^Manu> i'm right handed, the easiest access point on the screen is the bottom right. i'd be curious to see statistics, but i have a suspicion that 'back' is the most common action when using a phone by far.
[02:19] <^Manu> i press back probably 100 times more often than i press the home key, but phones always seem to have home keys.
[02:19] <^Manu> it looks good though, excited for an official release. december right?
[02:21] <^Manu> is it native code throughout?
[02:28] <^barry^> what is the ideal setup for running touch on Nexus 7 grouper?
[05:06] <Kurt_> whats up honeybun
[07:13] <compuspital> Hello everyone
[07:14] <compuspital> I have many ideas but im not sure who I need to talk to.
[07:16] <compuspital> Does anyone know?
[07:24] <anpok_> compuspital: write them down for others to read, or turn them into reality yourself
[07:26] <compuspital> okay, thank you, the thought behind some of my ideas is far too complex for me to write.
[07:28] <compuspital> but i definitely can pass them along. One would be for hardware devices.
[08:56] <tsdgeos> sergiusens: typo in https://github.com/sergiusens/network-test-session/blob/master/README.md in  netork-test-session
[09:02] <JamesTait> Good morning all; happy Frappe Day! :-D
[09:58] <popey> Saviq / mzanetti is there a plan to make the suspended app screenshots un-blurry?
[09:58] <Saviq> popey, I didn't yet file that bug ;)
[09:58] <popey> want me to?
[09:58] <Saviq> popey, feel free
[09:58] <popey> k
[10:01] <popey> done bug 1378267
[11:07] <sergiusens> tsdgeos: thanks
[11:08] <tsdgeos> sergiusens: i did the thing for mms, not sure if that was what you wanted hope it is
[11:10] <sergiusens> tsdgeos: did you piggyback on yoigo or was it using yoigo?
[11:11] <tsdgeos> sergiusens: not sure i understand the question
[11:11] <tsdgeos> i sent the message from yoigo (our phone) to pepephone (Z10 phone)
[11:11] <sergiusens> tsdgeos: you added an attachment to the 'Cannot send MMS from "Yoigo"' bug
[11:11] <sergiusens> tsdgeos: ah, then it's all good ;-)
[11:12] <sergiusens> tsdgeos: I guess you can try and send to vrruiz's number or viceversa to discard the fact it's not received on the target phones
[11:13] <sergiusens> but I don't have a strong opinion; everything is fine from the last mile PoV
[11:14] <tsdgeos> sergiusens: sure, but only being able to send mms between ubuntu phones is not what we want i guess :D
[11:15] <sergiusens> tsdgeos: of course not :-) but the stack works fine if the target device runs Android > 4.x or iOS
[11:15] <tsdgeos> i have not such devices at hand
[11:15] <sergiusens> tsdgeos: I'm mostly sure it won't work on my 2003 siemens device as MMS was crap then
[11:16] <sergiusens> tsdgeos: MMS is only good today because there are basically only two implementations :-)
[11:16] <sergiusens> but the spec is really bad
[11:16] <sergiusens> subject to interpretation everywhere and also half implemented by everyone
[11:17] <tsdgeos> FWIW i have never ever received or sent a MMS
[11:17] <sergiusens> tsdgeos: I know; over here it costs 0.50U$D per MMS... no one uses it :-/
[11:18] <sergiusens> operators really messed up there with pricing
[11:18] <sergiusens> and now they lost to all the chat apps around
[11:19] <moP9h> hey guys, is there exchange in ubuntu phone or some plans for that ?
[11:42] <TurkeyMan> some countries use MMS almost exclusively though.
[11:43] <TurkeyMan> because SMS is no good for their languages.
[11:43] <TurkeyMan> japan for instance, practically only MMS.
[11:48] <dpm> seb128, is the template for u-s-s updating correctly in Launchpad? I noticed an untranslated "Downloading" string, which I can see in: plugins/system-update/PageComponent. return i18n.tr("Downloading"); - however, it does not appear in LP as translatable
[11:49] <seb128> dpm, "lol"?
[11:49] <seb128> dpm, is that a real question? no the template is not updating by itself for project with upstream translations enabled, you for sure know about that, we discussed it several times?
[11:51] <dpm> seb128, I mean on the source package
[11:51] <seb128> dpm, well, we don't use the source package template
[11:52] <dpm> seb128, oh, I assumed that with the template being active in the source package it was being updated on upload
[11:53] <seb128> dpm, "being active"?
[11:53] <dpm> seb128, https://translations.launchpad.net/ubuntu/utopic/+source/ubuntu-system-settings/+pots/ubuntu-system-settings
[11:53] <seb128> dpm, but no, u-s-s uses upstream translations, I'm happy to change to Ubuntu translations/import the template from the source package if we can though, would be less hassle
[11:56] <dpm> seb128, there must have been at least an upload that enabled the template in the source package, so it should be doable. If I'm not mistaken, there is no need to change anything other than setting that "UseLanguagePacks: yes" thing in the package. I'd still perhaps ask if you could leave upstream auto-commits enabled, which should not affect the setup, but they help me quite a lot with the stats on http://projects.davidplanella.org/stats/utopic
[11:57] <seb128> dpm, well, sure it's doable, you just recommended against that a few monthes back
[11:57] <seb128> you said the new way was to use upstream project translations because of clicks
[11:57] <seb128> which is why we did it this way
[11:59] <dpm> seb128, I still recommend upstream translations for clicks. However, for .deb packages we've been migrating translations to touch language packs with pitti's help (where "help" is an understatement here :)
[12:03] <seb128> dpm, great, let me change that then, going it's like 15 times we go through "pot needs to be updated", having it from the ubuntu built is going to make things easier
[12:04] <dpm> seb128, sounds like a plan
[12:04] <dpm> thanks
[12:04] <seb128> yw!
[12:04] <seb128> dpm, btw do you know what's the status of content-hub and translations?
[12:04] <dpm> no, I've not been following it lately, let me check...
[12:05] <seb128> https://translations.launchpad.net/content-hub/trunk has strings and they are translated but it seems to still show in english in the ui for me
[12:05] <seb128> I didn't try debugging yet but I can have a look if you don't know
[12:11] <dpm> seb128, I think that's it http://pastebin.ubuntu.com/8514165/
[12:12] <dpm> in summary, if I'm looking at the right control file, as it's in universe "X-Ubuntu-Use-Langpack: yes" still needs to be added
[12:15] <dpm> seb128, bug 1378324
[12:15] <seb128> dpm, thanks, I've https://code.launchpad.net/~seb128/content-hub/x-ubuntu-use-langpack/+merge/236286 about that, so it's all is missing and it should work?
[12:15] <seb128> dpm, can you add the vcs to the bug? ;-)
[12:16] <seb128> dpm, I still don't get how those work, the 14.09 translation page says it shared translations with trunk
[12:16] <seb128> so I though langpacks would get the translations from trunk and things would work
[12:16] <seb128> without having to have the ubuntu side import working
[12:16] <dpm> seb128, done. Argh, I even remember now having seen your MP before
[12:17] <dpm> seb128, right, but on the source pkg side of things, there needs to be an initial package upload with a template that is then accepted before sharing works
[12:17] <seb128> dpm, ok, thanks
[12:18] <seb128> dpm, speaking of sharing, we still have evolution/e-d-s 3.10 in the langpacks, I approved the 3.12 templates but I think I did it wrong first and now there are a buggy one in the list, can those be deleted?
[12:18] <dpm> seb128, then the other thing is that content-hub upstream doesn't have auto-commits enabled, so the translations can never be shipped
[12:18] <dpm> *could
[12:18] <seb128> oh, ok
[12:19] <seb128> dpm, https://translations.launchpad.net/ubuntu/utopic/+source/evolution
[12:19] <seb128> dpm, the -3.12 seems wrong
[12:19] <dpm> let me have a look
[12:19] <seb128> dpm, also those had "share with upstream" enabled, which made the .mo not being imported, do you know why was that on? (at least wgrant said that's why we don't have .mo in the import queue)
[12:20] <seb128> dpm, I did unbind the ubuntu/upstream translations, need to do a no change upload next to get an import
[12:20] <seb128> dpm, not sure if we also need a change in langpacks for the 3.10 -> 3.12 domain?
[12:26] <dpm> seb128, ok, fixed. I removed the *-3.12 template and I checked that the domain was correct in the template that I left as active (evolution-3.12). My guess (it was a long time ago) is that I enabled translation sharing with the upstream vcs imports we used to do (I'm assuming we no longer do?)
[12:27] <dpm> seb128, that sped up the translations queue, where the translations were imported into LP directly from the upstream vcs import instead of requiring a source package upload and going through the imports queue
[12:28] <seb128> dpm, oh ok, issue is that those imports are trunk only and we are not on current-gnome-serie
[12:28] <seb128> so we import .mo that don't match our template
[12:28] <seb128> or sourcecode
[12:28] <dpm> seb128, ah, I see. Yeah, I remember now that imports bug that does not allow us to choose the upstream branch, only trunk
[12:28] <seb128> dpm, I guess we have that issue in other GNOME components as well then :/
[12:29] <seb128> since we don't follow their current serie nowadays
[12:29] <dpm> seb128, as per changes in langpacks, I think the only thing we need is for the next langpack to be a full export to install the right .mo file
[12:29] <seb128> ok
[12:29] <seb128> dpm, thanks
[12:30] <seb128> dpm, can you clean the wrong template on https://translations.launchpad.net/ubuntu/utopic/+source/evolution-data-server/ as well?
[12:30] <dpm> seb128, and as per the other gnome components, I can go through the templates, there are not that many sharing translations - If you can access that page, you'll see them https://translations.launchpad.net/ubuntu/utopic/+templates
[12:31] <dpm> (you can click on the sharing column to sort)
[12:31] <dpm> yeah, looking at e-d-s now
[12:31] <seb128> dpm, thanks, I can look at the templates if you want
[12:33] <dpm> seb128, that'd be great, as you know the gnome components best
[12:33] <dpm> it's just a matter of unsharing them
[12:34] <dpm> seb128, ok, e-d-s fixed
[12:34] <seb128> thanks, and I'm going to do the template unbinding
[12:58] <nerochiaro> bfiller: the problem you mention in this bug https://bugs.launchpad.net/gallery-app/+bug/1377767 does it appear in the album title or somewhere else ? I can't find any place where that text is cut off
[13:00] <seb128> speaking of gallery, is that known that "new album" can't be renamed?
[13:01] <nerochiaro> seb128: you can, it's just not very obvious. when you are in the list of albums long press on one of them, there's an "edit album" option poppingup
[13:02] <seb128> nerochiaro, when you create an album, it put the cursor on the text, but typing delete/chars don't change the label
[13:02] <seb128> you can edit the subtitle though
[13:02] <nerochiaro> it totally does work here on mako with yesterday's image
[13:02] <seb128> well, expect that it's covered by the osk and you can't scroll to see it
[13:03] <seb128> doesn't work on current krillin rtm
[13:03] <nerochiaro> seb128: i see what you mean, i get that when i type too much text
[13:03] <seb128> expect->except
[13:03] <nerochiaro> seb128: osk is in the way
[13:04] <nerochiaro> seb128: please file a bug
[13:04] <seb128> nerochiaro, well, it might also depends on the locale, I'm in french so by default the title is enough text to put the osk over the subtitle
[13:04] <nerochiaro> seb128: yeah, and screen resolution
[13:06] <seb128> nerochiaro, https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1378349
[13:10] <seb128> nerochiaro, ok, "fun", editing the title works in english but not in e.g french ... is there any smart logic to place the cursor before "album" or something which could go wrong when the words are in reversed order?
[13:11] <nerochiaro> seb128: i don't think so. i think the problem is really that when the text gets too long it will hide below the OSK and you can't do aynthing about it. I added this to the bug
[13:12] <seb128> nerochiaro, no, the title issue is different, in french the title is "Nouvel album photo", you can see the title on top of the osk but deleting/typing char doesn't update the string on string, it just moves the cursor
[13:12] <kenvandine> gatox, mterry: i didn't forget your reviews, yesterday was crazy, i'll do them today :)
[13:13] <seb128> kenvandine, hey
[13:13] <mterry> kenvandine, no worries
[13:13] <kenvandine> hey seb128
[13:13] <gatox> kenvandine, thanks
[13:13] <mterry> kenvandine, seb128 looked at it actually
[13:13] <seb128> kenvandine, is that ok if I do a landing for https://code.launchpad.net/~seb128/content-hub/x-ubuntu-use-langpack/+merge/236286 ?
[13:13] <kenvandine> woot
[13:13] <kenvandine> thanks seb128!
[13:13] <seb128> kenvandine, yw!
[13:13] <kenvandine> seb128, please do!
[13:13] <nerochiaro> seb128: oh, ok, let me switch to non-english and try that
[13:13] <seb128> kenvandine, thanks
[13:15] <seb128> nerochiaro, it's doing the same in spanish here btw
[13:15] <seb128> so not french specific
[13:17] <mterry> seb128, updated that wizard-refresh branch w/ comments
[13:18] <seb128> mterry, thanks, sorry for keeping bouncing things back to you
[13:18] <mterry> seb128, no it was appropriate!  :)
[13:19] <mterry> seb128, though if design has any more changes, I'd like to do them separately  :)  They keep futzing over that design
[13:19] <seb128> right
[13:19] <seb128> mterry, I just wanted to have Jane's bug fixed in there :-)
[13:20] <mterry> :)
[13:21] <seb128> nerochiaro, let me know if you can reproduce/if you want a bug report about that
[13:23] <nerochiaro> seb128: works for me in italian when running trunk. let me try spanish
[13:25] <nerochiaro> seb128: you're on krillin though, right ?
[13:25] <seb128> nerochiaro, yes, shouldn't make a different I guess?
[13:25] <seb128> or might be due to the geometry ... in which case try deutsch? ;-)
[13:27] <nerochiaro> seb128: do you have to click to start editing or does it go there automatically ?
[13:27] <seb128> nerochiaro, I've to click, the osk it's opening with an "edit album" title but no osk visible
[13:36] <bfiller> nerochiaro: when you create a new album, the editable text is not all visible
[13:36] <nerochiaro> bfiller: hidden under the OSK ?
[13:37] <bfiller> nerochiaro: no
[13:37] <bfiller> nerochiaro: create a new album
[13:37] <bfiller> nerochiaro: and the text says "New Photo" and then "Subtitle"
[13:37] <bfiller> nerochiaro: on the cover of the album
[13:38] <nerochiaro> bfiller: ok, i was confused because it happens only on krillin and i was testing on mako
[13:39] <bfiller> nerochiaro: strange it would be different, but yes I'm testing on krillin
[13:39] <nik90> Saviq: curious, during your phone dogfooding time, did you find any bugs for clock-app other than the ones you already submitted? :)
[13:39] <nerochiaro> bfiller: different screeen resolution
[13:40] <nerochiaro> bfiller: also if I fix that in English it would still be a problem with languages that are more verbose
[13:40] <Saviq> nik90, alarm didn't work for us once, but has been fine since, so no, nothing new :)
[13:40] <nik90> Saviq: yay, cool
[13:41] <nerochiaro> bfiller: and in any case if you type longer titles it will stll look wrong when you exit the editor and go back to it later, the first line will display but the rest of the long title will be still clipped
[13:41] <gatox> seb128, i have updated both branches
[13:41] <seb128> gatox, hey, thanks
[13:41] <seb128> kenvandine said he was looking at those as well
[13:41] <bfiller> nerochiaro: I'd make the font smaller to start, and perhaps the default text should just say "Title" or something brief
[13:42] <nerochiaro> bfiller: fixing the initial state isn't terribly difficult, but it's a stopgap, there are a ton of problems with that album editor as soon as you type a bit more text, as seb128 was pointing out
[13:43] <nerochiaro> bfiller: i'll start with that
[13:43] <bfiller> nerochiaro: understood, but at least the default state should be correct and visible
[13:44] <nerochiaro> bfiller: ack
[13:48] <seb128> nerochiaro, bfiller, https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1378367 is annoying as well it also describe a way to get into a buggy "add to album" view when you need to force close gallery
[13:50] <nerochiaro> bfiller: regarding bug https://bugs.launchpad.net/gallery-app/+bug/1377298 the problem I see (with yesterday's image) is that when cropping the EXIF thumbnail isn't updated. So the gallery gets confused because you have a cropped picture and non-cropped thumbnail. I can't find the old thumbnailer in silo 6 as you said, but i'm sure it did use to regenerate the thumbnail properly upon cropping
[13:50] <bfiller> nerochiaro: if we stop displaying the thumbnail in the picture view then it shouldn't be a problem, right?
[13:51] <nerochiaro> bfiller: not in that specific case, but we still use the thumb in a number of other places and they all will be wrong
[13:51] <nerochiaro> bfiller: i mean, you would fix the problem in the picture browser only
[13:51] <bfiller> nerochiaro: right
[13:52] <bfiller> nerochiaro: so the change for thumbnailer to use the exif thumbnail has been reverted
[13:52] <nerochiaro> bfiller: so if i install the most recent image I will get the non-EXIF thumbnailer ?
[13:52] <bfiller> nerochiaro: in theory it should regenerate the thumbnail if the picture changes, but if I recall we don't modify the orig but create another photo
[13:52] <bfiller> nerochiaro: yes
[13:53] <nerochiaro> bfiller: i'll test that. crop used to work just fine with thumbs we regenerated. changing the file should be picked up correctly.
[13:54] <bfiller> nerochiaro: do you have the MR to use the full size image in the viewer for gallery? I want to get that in a silo
[13:54] <nerochiaro> bfiller: https://code.launchpad.net/~phablet-team/gallery-app/do-not-upscale-thumbnail/+merge/237314 approved and ready to go
[13:55] <bfiller> nerochiaro: thanks
[14:03] <jhodapp> nerochiaro, did you ever get to ask tvoss about his thoughts on why the media-hub client never receives the EndOfStream signal from the server side?
[14:04] <nerochiaro> jhodapp: yeah, i filed a bug for him with a minimal example, he's gonna have a look tomorrow
[14:07] <jgdx> awe, ping
[14:08] <awe> jgdx, in a mtg; will ping you when I'm done
[14:08] <jgdx> awe, ack
[14:09] <oSoMoN> greyback, hey, when you have a minute, could you take a look at bug #1375556 (especially comment #3) and comment?
[14:10] <greyback> oSoMoN: your observation is correct, is something I'm just testing a fix for now. But for the unresponsive part, I've no clear idea yet
[14:12] <oSoMoN> greyback, yeah, I’m mostly interested in the resizing of the window, the unresponsiveness is most probably on the browser’s side
[14:12] <greyback> oSoMoN: really? Ok in that case, I hope to have branches up with the resize fix tomorrow noon
[14:13] <jhodapp> nerochiaro, oh ok cool, I'll assign the bug to him then
[14:13] <nerochiaro> jhodapp: thanks. and if he gets back while i'm off thu-fri please keep an eye on it in my place if you don't mind
[14:14] <jhodapp> nerochiaro, sure thing
[14:15] <oSoMoN> greyback, awesome, can you add a task to the bug for whatever component is affected and assign it to yourself?
[14:16] <oSoMoN> greyback, and link your branch(es) to the bug report, if you don’t mind?
[14:18] <greyback> oSoMoN: I commented the original bug number anyway (which is my bug) and added qtmir as affected.
[14:18] <greyback> if unresponsiveness is separate issue, perhaps it would need a separate bug?
[14:26] <nerochiaro> bfiller: https://bugs.launchpad.net/media-hub/+bug/1378311
[14:28] <oSoMoN> greyback, thanks, yeah I’ll track the unresponsiveness separately
[14:28] <greyback> oSoMoN: ok
[14:36] <seb128> nerochiaro, https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1378384 as well is weird (header translations lost when switching to picker mode)
[14:37] <seb128> nerochiaro, do you have any idea if something could unset the env or something when changing to picker?
[14:42] <kenvandine> seb128, what does this mean?  "Landed without merging branch"
[14:43] <seb128> kenvandine, that I got confused by the landing to rtm and utopic, set up the silo wrong so did a "force clean without merge or upload" to reassign a silo
[14:43] <kenvandine> seb128, ok :)
[14:43] <kenvandine> i was confused :)
[14:43] <seb128> kenvandine, refresh
[14:43] <seb128> it should be resolved
[14:43] <kenvandine> i see now, thx
[14:43] <seb128> kenvandine, sorry about that :-)
[14:44] <kenvandine> np :)
[14:44] <seb128> kenvandine, I added a sync:ubuntu-rtm line in the googledoc thinking that it would upload there as well
[14:44] <seb128> but it's the other way around
[14:44] <seb128> and it imported the current rtm version in the ppa :p
[14:44] <seb128> well, anyway, should be fine now ;-)
[14:48] <nerochiaro> seb128: that's very odd
[14:48] <nerochiaro> seb128: not really sure what's up with that one. as far as i know it's just the regular app launched with a different cmd line option
[14:49] <seb128> nerochiaro, the command line option got deprecated apparently and it's doing smart mode changing when the content-hub is detected
[14:50] <nerochiaro> seb128: hmm, i wasn't aware of that. even in that case, i don't see why it would lose track of the language
[14:50] <seb128> nerochiaro, ok, funny, adding a
[14:51] <seb128>     Component.onCompleted: {
[14:51] <seb128>         i18n.domain = "gallery-app";
[14:51] <seb128>     }
[14:51] <seb128> in PickerScreen.qml makes it work
[14:51] <seb128> nerochiaro, which is what GalleryApplication.qml is doing
[14:51] <kenvandine> nerochiaro, he also confirmed it isn't translated when gallery is already running and it just switches to pick mode
[14:51] <seb128> kenvandine, ^
[14:51] <kenvandine> that's interesting
[14:51] <seb128> I wonder why setting the domain in onCompleted like that is even needed
[14:51] <seb128> shouldn't it be set up in front?
[14:52] <kenvandine> no idea
[14:53] <kenvandine> cyphermox, how much work is required for bug 1378102 ?
[14:53] <cyphermox> not that much
[14:53] <cyphermox> it's next
[14:54] <kenvandine> bfiller, ^^
[14:54] <kenvandine> cyphermox, i'm trying to decide if we should wait for that or not
[14:54] <cyphermox> for?
[14:54] <kenvandine> apneditor
[14:55] <cyphermox> I still feel it should also be fixed in apneditor
[14:55] <cyphermox> it's quite easy to disconnect an interface before you activate a new connection
[14:55] <kenvandine> can you comment to that affect in the MP?
[14:55] <kenvandine> https://code.launchpad.net/~unity-api-team/ubuntu-system-settings/apneditor/+merge/237138
[14:56] <cyphermox> oh
[14:56] <cyphermox> wait a minute
[14:56] <cyphermox> this is specifically for the MMS APN?
[14:56] <kenvandine> no
[14:57] <kenvandine> actually the one i had a problem with was the internet apn
[14:57] <kenvandine> it activated the mms apn
[14:59] <seb128> kenvandine, nerochiaro, it looks like the Loader loose the translation domain when the source is changed
[14:59] <seb128> kenvandine, nerochiaro, if I reverse the check to load PickerScreen.qml by default and change to MainScreen.qml on import, the picker is correct translated and the normal mode not
[15:00] <nerochiaro> seb128: so the first time a source is set, the translations are picked up right, but if we change the source they get messed up ?
[15:00] <seb128> correct
[15:04] <nerochiaro> seb128: that seems very odd to me because off of the top of my head we might already be doing this in other places and I haven't seen translations getting mixed up. But maybe I'm mistaken and all our loaders just load once
[15:04] <nerochiaro> seb128: so we never bumped into this
[15:05] <seb128> nerochiaro, yeah, I don't know, just saying what I see
[15:05] <nerochiaro> seb128: would it be possible to have a minimal example of this ?
[15:12] <charles> MacSlow, ping
[15:12] <MacSlow> hey charles! what's up?
[15:13] <charles> MacSlow, there's some kind of a sizing/clipping issue with the battery icons when indicator-power notifies the user of a low battery
[15:13] <charles> MacSlow, eg, this is what gets rendered when indicator-power sends over an icon name of "battery-020"
[15:14] <charles> MacSlow, https://www.dropbox.com/s/it39shabldcwn24/2014-10-07%2010.07.54.jpg?dl=0
[15:14] <charles> see how the left and right ends of the battery icon are clipped off
[15:15] <seb128> charles, you should turn off the ubuntu-shape there btw (set the "x-canonical-non-shaped-icon" hint to true)
[15:16] <MacSlow> charles, two things I see being wrong there... first of course the clipping, secondly it should not use the UbuntuShape-masking (there's a hint that can be passed with the notification to avoid that)
[15:16] <charles> MacSlow, seb128, https://pastebin.canonical.com/118327/
[15:16] <seb128> charles, no 2fa on me to open that
[15:16] <charles> looks like this is another case of notifications not handling the boolean type for "x-canonical-non-shaped-icon", so I'll make a patch to change that to a string as I did in i-datetime
[15:17] <seb128> seems like a bug for MacSlow to fix on the server side :-)
[15:17] <charles> seb128, http://paste.ubuntu.com/8515145/
[15:19] <charles> seb128, the boolean handling is a server side bug IMO, but isn't urgent
[15:19] <MacSlow> charles, the value for "x-canonical-non-shaped-icon" needs to be passed as a string reading "true"
[15:19] <charles> I reported it at https://bugs.launchpad.net/unity-notifications/+bug/1370641, it'll keep
[15:21] <jgdx> brendand, hey, was the failure to boot issue resolved? I tried to get through fourteen pages of log, but I failed. :s
[15:21] <MacSlow> charles, why the clipping is happening I can't say off the top of my head
[15:21] <brendand> jgdx, not quite yet. another silo has to land first
[15:22] <jgdx> brendand, ack. Thanks for following that up.
[15:22] <seb128> MacSlow, why is that a string rather than a boolean?
[15:22] <seb128> nerochiaro, no, I can't reproduce with a small testcase, not sure what gallery is doing to unset the domain
[15:22] <seb128> nerochiaro, the workaround I described in the bug works though, if nobody has slots to debug properly we could add that one for rtm and see later
[15:22] <charles> MacSlow, want me to file a unity-notifications bug for you wrt the clipping?
[15:23] <MacSlow> seb128, charles: that's because in the past requirements for some hints changed (sometimes back and forth) and staying with strings made changes simpler... causing fewer places to touch.
[15:24] <MacSlow> charles, it's not unity-notifications I bet, which is the backend...
[15:24] <MacSlow> charles, but let me quickly check something...
[15:27] <MacSlow> charles, *sigh* I can't test it right now... my dbus and/or upstart is messed up somehow... need to sort that out first
[15:28] <charles> MacSlow, if unity-notifications isn't the place for this, could you file a ticket for the right people/components
[15:29] <MacSlow> charles, it's unity8 btw... the notification-renderer (frontend) is a plugin there
[15:34] <charles> MacSlow, seb128: FWIW, still clips even with the string version of non-shaped-icon: https://www.dropbox.com/s/46h0chkisqsznjn/2014-10-07%2010.33.30.jpg?dl=0
[15:36] <MacSlow> charles, I'll look into this tomorrow... this is very odd... I've never seen clipping errors like these before for any icon/image
[15:37] <nerochiaro> seb128: what's the bug number again ?
[15:37] <charles> MacSlow, thanks
[15:37] <seb128> nerochiaro, https://bugs.launchpad.net/bugs/1378384
[15:40] <MacSlow> charles, btw... just wondering... should the "Ok"-button there not use "x-canonical-private-affirmative-tint"?
[15:43] <charles> MacSlow, hmm... that's not what the Notifications UX doc indicates, but I wonder if that's an oversight
[15:44] <charles> MacSlow, I'll ask James
[15:44] <charles> MacSlow, thanks for suggesting that
[15:44] <MacSlow> charles, better ask to check... I recall examples were most of the time at least the positive action was meant to be tinted
[15:55] <charles> MacSlow, confirmed, confirmations should get the affirmative tint
[15:55] <MacSlow> charles, 1 : 0 for the gut-feeling :)
[15:55] <charles> :)
[15:56] <charles> MacSlow, I filed a LP ticket for that clipping issue, bug #1378417
[15:56] <MacSlow> charles, ok thx!
[16:06] <nerochiaro> bfiller: all is well with cropping in the latest image. looks like the problem was really in the EXIF thumbnails not getting updated
[16:08] <Dinesh_> Hey guys
[16:10] <Dinesh_> Any one?
[16:10] <bfiller> nerochiaro: ok
[16:16] <popey> !ask | Dinesh_
[16:23] <Dinesh_> Is it possible to port ubuntu touch for micromax canvas 2 plus?
[16:26] <popey> Dinesh_: we have an (outdated) porting guide linked in the /topic
[16:48] <holymac_> when is the ubuntu touch coming out?
[16:51] <Isotop7> its not officially released but you can test it on several devices or in an emulator.
[16:52] <Isotop7> later this year, a few manufacturers will release smartphones with ubuntu touch. So its likely to be officially published also later this year, holymac_
[16:53] <holymac_> i wanna buy one right now!!!
[16:53] <kenvandine> holymac_, works well on a nexus 4 :)
[16:54] <Isotop7> we all want that, but there is still some develoment and customizing to do...
[16:54] <genii> holymac_: Meizu MX4 will be coming with it, and it has also been seen running on the BQ Aquarius
[17:14] <holymac_> Meizu MX4 is going on sale in Sept 22 and has a deliver time of October?
[17:17] <genii> I think more like Dec, but could be earlier
[17:22] <seb128> kenvandine, gatox updated his code to use qml-module-ubuntu-connectivity but forgot the depends, you need to install that for testing
[17:25] <kenvandine> seb128, i have it installed
[17:25] <seb128> kenvandine, hum, so that warning is weird
[17:25] <kenvandine> it says the NetworkingStatus compoment can't be created
[17:25] <seb128> hum
[17:25] <kenvandine> i think he needs to use a connection
[17:31] <gatox> seb128, which dependency? isn't that part of the sdk?
[17:34] <kenvandine> gatox, NetworkingStatus isn't creatable
[17:34] <kenvandine> i think you need to use  a Connection
[17:34] <gatox> kenvandine, i used as it is in the documentation http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Connectivity.NetworkingStatus/
[17:40] <kenvandine> gatox, indeed, it does match the docs
[17:40] <kenvandine> it says it can't be created though
[17:41] <gatox> kenvandine, seb128 is that module working? or should i revert back to the dbusconnection again?
[17:42] <kenvandine> gatox, hang on, i have it installed let me try something
[17:43] <seb128> gatox, it should be working, I think Saviq started using it in unity8
[17:44] <kenvandine> gatox, ok, i got that working
[17:44] <kenvandine> but
[17:44] <kenvandine> 2014-10-07 13:44:05,368 - WARNING - QObject::connect: No such slot UpdatePlugin::UpdateManager::downloadUrlObtained(const QString&, const QString&)
[17:46] <kenvandine> gatox, http://pastebin.ubuntu.com/8516083/
[17:49] <gatox> kenvandine, that's weird... why should that work and not in the other way?
[17:49] <kenvandine> gatox, because apparently NetworkingStatus is registered as uncreatable in the plugin
[17:49] <kenvandine> so the docs are wrong
[17:50] <gatox> kenvandine, ok..... changes pushed..... and removed the unused connetion from downloadUrlObtained
[17:52] <kenvandine> gatox, thx
[17:54] <charles> nik90, you around?
[17:56] <nik90> charles: hey, yes
[17:57] <charles> nik90, I was going to ask if you were still seeing https://bugs.launchpad.net/indicator-datetime/+bug/1364949, but after many tests, and after pinging you, I was finally able to trigger the behavior :P
[17:58] <nik90> charles: lol, yes
[17:58] <nik90> charles: zsombor wanted to defer the bug to you since he said the SDK is saving the current alarm sound.
[17:59] <nik90> charles: also he said something about changing the alarm sound from description to audible notification. I did not understand fully, but he said the comments in the bug report should be explanatory enough for you :)
[18:00] <charles> right, it is. It looks like the tasks.ics file is correct
[18:04] <vitimiti> Hi
[18:42] <dobey> jdstrand: hi. do you think bug #1378480 should be critical/rtm14 tagged? given the location setting is under Sec/Priv, requires TOS agreement, and can result in extra battery usage, it seems like it should be to me.
[18:44] <jdstrand> dobey: oh I see that with bluetooth too. I always turn it off, but on reboot it is enabled
[18:45] <jdstrand> personally, it doesn't feel critical to me
[18:45] <jdstrand> since the indicator tells you it is on after reboot
[18:45] <jdstrand> I agree is is mildly annoyting
[18:45] <jdstrand> annoying*
[18:47] <dobey> well, the indicator only tells you it's on if you actually open the indicator
[18:47] <dobey> at least for location
[18:48] <dobey> i agree for bt it's only mildly annoying; but location detection has the implication of privacy and legal agreement to a TOS that one didn't actually agree to
[19:08] <cwayne> dobey: if you don't agree to it, you cant use it
[19:08] <cwayne> it being HERE
[19:09] <dobey> cwayne: and yet, location detection works, though i haven't agreed to it, and i disabled location detection
[19:10] <cwayne> dobey: location detection can work without HERE, the TOS is *just* for HERE
[19:10] <cwayne> so you may still get geoip or GPS fix
[19:10] <dobey> cwayne: the UI doesn't make it clear that it's not using HERE
[19:10] <dobey> cwayne: iow, there's isn't a switch for "HERE"
[19:11] <dobey> there is only a switch for location detection, and the welcome wizard associates it directly to HERE
[19:11] <dobey> cwayne: and aside from that, if i turn it off, it should stay off until i turn it on again, regardless of what it's actually using
[19:11] <cwayne> dobey: i never said it shouldnt..
[20:33] <charles> AlbertA, AlbertA2, I have a question about unity-system-compositor
[20:33] <AlbertA2> charles: sure
[20:34] <charles> AlbertA, AlbertA2, I'm debugging an indicator-datetime report that says when two alarms fire at once, the screen never goes off again
[20:34] <charles> AlbertA2, so I'm looking at the display-on and remove-display-on requests that get sent
[20:34] <charles> I see the compositor logs the requests and remove-requests to cerr
[20:34] <charles> does this wind up in a file somewhere that I can look at it?
[20:34] <charles> s/cerr/cout/
[20:35] <AlbertA2> charles: yeah it ens up in /var/log/lightdm/unity-system-compositor.log
[20:35] <charles> AlbertA2, perfect, thanks :)
[20:35] <AlbertA2> charles: no problem
[21:50] <nik90> rsalveti: hey, I noticed that the individual sound roles patch landed in utopic.
[21:50] <rsalveti> nik90: and rtm
[21:50] <nik90> rsalveti: Are more fixes incoming for that feature?
[21:51] <rsalveti> nik90: nops
[21:51]  * nik90 tests it out :)
[21:55] <nik90> rsalveti: cool it works...thnx
[21:55] <rsalveti> nik90: great
[21:55] <nik90> rsalveti: I suppose now I need to fix https://bugs.launchpad.net/ubuntu-clock-app/+bug/1376513
[21:55] <rsalveti> nik90: yeah
[21:55] <nik90> rsalveti: I got a question about that
[21:55] <rsalveti> nik90: let me know if you have any issues with that
[21:55] <rsalveti> sure
[21:56] <nik90> rsalveti: atm the clock app just sets the alarm volume which it then communicates over to indicator-datetime. i-dt then plays the alarm in that volume specified.
[21:56] <nik90> rsalveti: If clock app access the alarm-volume directly using the dbus api you mentioned in that bug report, wouldn't it conflict with i-dt?
[21:57] <rsalveti> nik90: nops, because they are not connected with each other
[21:58] <rsalveti> when playing the audio stream, pulseaudio will use the volume that was set by either the clock-app or the previous value set by the user
[21:58] <nik90> rsalveti: ah ok...
[21:58] <rsalveti> in your case all you want is changing the volume for the alarm role, and the only way to do that when there's no alarm playing, is using that dbus api
[21:58] <rsalveti> if the alarm stream is active, then just changing via indicator-sound works
[21:59] <nik90> rsalveti, charles: So now the clock app will instead of communicating the alarm volume to i-dt, will send it directly to pulseaudio via the dbus api
[21:59] <nik90> rsalveti: and i-dt will automatically pick that up anyway
[21:59] <rsalveti> yeah, you could send/store the value in i-dt if that is available as well
[21:59] <rsalveti> but not sure if that is something that is already implemented
[22:00] <rsalveti> but generally you don't need to handle the volume yourself, you can let pulse handle that
[22:01] <charles> nik90, rsalveti, so should com.canonical.indicator.datetime.AlarmProperties remove its DefaultVolume property as unneeded?
[22:02] <nik90> charles: that's what I would think...clock can now directly change the alarm volume. And i-dt listens to that by monitoring pulseaudio anyway..so its not necessary to connect clock and i-dt.
[22:02] <nik90> through the DefaultVolume property that is.
[22:03] <charles> when you say "i-dt listens to that", it sounds more to me like i-dt doesn't need to do anything at all wrt volume, it's all handled outside of i-datetime by rsalveti's change?
[22:03] <nik90> rsalveti: can I (as clock-app) play a preview audio with the volume set in the alarm audio role? This is necessary for bug 1362078
[22:03] <rsalveti> charles: if i-dt is not the only one that is able to play 'alarm' streams, then yeah
[22:03] <rsalveti> nik90: yes, anything you play as 'alarm' role will use the volume stored in pulse for that role
[22:04] <rsalveti> preview or not
[22:04] <nik90> charles: yup that's what I intended to say
[22:04] <rsalveti> that dbus api exported by pulseaudio let any app to set the volume per roles, including the alarm role
[22:04] <rsalveti> so any app playing streams with role as alarm, will use the correct volume stored there
[22:04] <nik90> rsalveti: true but how do I trigger the alarm role? By default when the clock app plays an audio, it is played using the multimedia stream and not the alarm stream
[22:04] <nik90> rsalveti: ah ok
[22:05] <rsalveti> nik90: there's a qml property for that
[22:05] <nik90> rsalveti: so I should set the stream role as alarm while playing that preview to the user
[22:05] <rsalveti> nik90: yes
[22:06] <rsalveti> nik90: from system-settings: http://paste.ubuntu.com/8517456/
[22:06] <nik90> Audio {
[22:06] <nik90>         id: previewAlarmSound
[22:06] <nik90>         audioRole: MediaPlayer.alert
[22:06] <nik90>     }
[22:06] <nik90> Here I should set it as MediaPlayer.alarm
[22:06] <rsalveti> so just put audioRole: MediaPlayer.alarm
[22:06] <rsalveti> yup
[22:06] <nik90> :)
[22:07] <nik90> and my slider changes the alarm stream volume through the dbus api...I understand now
[22:08] <nik90> rsalveti: I should be able to see the above dbus roles using dfeet on utopic?
[22:08] <nik90> I mean the different dbus interfaces
[22:09] <rsalveti> nik90: nops, because there's one specific connection for the dbus interface
[22:09] <rsalveti> nik90: and this interface is only enabled on touch, not on desktop
[22:10] <nik90> oh
[22:10] <rsalveti> we'll enable it on desktop as well, but not for now
[22:10] <rsalveti> so I guess that if you also want this to be compatible with the desktop, maybe using i-dt is better
[22:10] <rsalveti> but then the preview will not reflect the volume set by the slider
[22:11] <rsalveti> unless you use the volume property in QML (under Audio)
[22:11] <rsalveti> that also works
[22:11] <nik90> rsalveti: well not really, I mean the clock app is designed to be functional for phone only as per the design spec.
[22:11] <rsalveti> because if you set the volume on an active stream, pulse will automatically store that volume for that specific role
[22:12] <rsalveti> but the main problem is that without the dbus api from pulse there's no way to get the volume without playing anything
[22:12] <rsalveti> nik90: right
[22:12] <rsalveti> nik90: if you want to give the dbus interface a try, use that python software I described in the bug
[22:12] <rsalveti> with that you can grab and set volume per roles
[22:13] <nik90> rsalveti: okay, I will give it a shot :)
[22:31] <charles> AlbertA2, AlbertA: if you're still around, I have the easiest MP you'll see all week
[22:31] <charles> AlbertA2, AlbertA: https://code.launchpad.net/~charlesk/unity-system-compositor/lp-1365557-decrement-display-on-requests-correctly/+merge/237498
[22:35] <AlbertA2> charles: ooops...yeap..you are right
[22:58] <elopio> ted: ping. I'm testing the indicator sound silo, and I don't like one detail. You around?