[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?


[03:47] <holstein_too> akgraner: ping
[12:33] <Pendulum> akgraner: I've got the 2 links in the google doc done for summaries. I may not be around most of the day, however, as my brother just got home for a few days and the weather is messing with my fingers and my computer
[16:48] <akgraner> Good Morning!  Hey I just got back from OSCON at about 1am this morning  - flight delays and all that good stuff
[16:50] <akgraner> I still need to pick up my kids and get some food in the house since Pete and I have both been gone for a week  - so do what you can with your parts of the newsletter and I'll work on it some more tonight but I'll probably publish Monday Morning just so you all know
[16:50] <akgraner> internalkernel, nigelb Pendulum scott_ev cjohnston holstein ^^^^^
[16:52] <internalkernel> akgraner: sounds good to me - I dumped a ton of links into the Gdoc over the week, so I'll write up summaries for them later today and then ping you
[16:52] <internalkernel> the lady and I are going to see a movie in a bit, so I probably wont be able to get to any of it until later today anywyas...
[16:52] <akgraner> Thank you!
[16:52] <akgraner> yep it was a crazy week on my end as well
[16:55] <Pendulum> akgraner: I've done summaries for the ITB things that are in the google doc, but not added any links. I'm not sure I'll have time to either due to a combination of my brother being home and computer problems
[16:56] <akgraner> Pendulum, no worries :-)  I appreciate all the time you have already given to this week's issue  - you rock!
[16:56] <akgraner> I just wanted to give everyone a heads up!
[16:56] <akgraner> :-)  Thanks everyone!!!
[16:57] <nigelb> akgraner: sounds good.  getting to work on it!
[16:57] <akgraner> If someone wants to go back through this week's planet feeds that would be great
[16:57] <akgraner> If not I'll do that tonight
[16:58] <highvoltage> I'll be contributing next week, the last week has just been too hectic for me (I still even haven't had chance to *read* the last UWN!)
[16:58] <akgraner> planet feeds can go into many categories from ITB, Planet, ION, and LoCo as well As GCN - but if you want to just pull them and summarize them  - I can move them around later
[16:58] <akgraner> highvoltage, thanks!
[17:00] <nigelb> highvoltage: heh :) Moving can be tough :)
[17:02] <highvoltage> nigelb: that, and my boss(es) are going on leave for the next 2 weeks so I've been piled with work
[17:02] <highvoltage> but while they're away I can be super-productive :)
[17:02] <nigelb> highvoltage: haha
[19:17] <YoBoY> hi
[19:18] <zkriesse> Hello YoBoY
[19:18] <YoBoY> the next deadline to team reports is the next sunday, right?
[19:18] <YoBoY> helle zkriesse :)
[19:18] <zkriesse> I've no idea for team reports
[19:19] <zkriesse> the person to ask is akgraner who's away at the moment
[19:19] <YoBoY> ^^
[19:20] <YoBoY> she's highlighted now :p
[19:20] <zkriesse> well yeah
[19:20] <zkriesse> Not that she'll respond...she's probably relaxing as it's sunday for here
[19:20] <zkriesse> "her
[19:20] <YoBoY> for me too :)
[19:21] <zkriesse> cool
[19:36] <nhandler> YoBoY: Team Reports should idealy be in by the end of this coming Saturday
[19:36] <nhandler> YoBoY: Early sunday morning at the latest
[19:36] <nhandler> zkriesse: I handle the team reports for UWN :)
[19:37] <YoBoY> ok, i need to do the page
[19:37] <YoBoY> write the page
[19:37] <zkriesse> nhandler: Oh I didn't know that
[19:50] <holstein> akgraner: i see your message
[19:50] <holstein> glad your home safe :)
[19:50] <holstein> im around later tonite, and i'll finish up then
[19:59] <scott_ev> akgraner:
[20:49] <scott_ev> upcoming meetings & events is done


[01:35] <olympionex>  I'm having trouble running 'snap try' with snap/snapd vs 2.21 on 16.04.  The confinement is specified as classic and when I run 'snap try --classic' or 'snap try --devmode', I still get the error that it requires consent to use classic confinement
[03:05] <telelaci> quit
[03:05] <telelaci> exit
[03:05] <telelaci> help
[03:05] <telelaci> ?
[03:06] <telelaci> shit
[03:09] <mup> Bug #1659719 opened: ssh can't call a binary from a snap without the full path <Snappy:New> <https://launchpad.net/bugs/1659719>
[03:51] <mup> Bug #1659724 opened: Feature request: give applications unrestricted access to d-bus services provided by the same snap <Snappy:New> <https://launchpad.net/bugs/1659724>
[06:45] <ubuntunoddy> how to convert nodejs app to snap app
[07:01] <mup> PR snapd#2729 closed: tests: use test snap <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2729>
[07:03] <mup> PR snapd#2731 opened: store: always log retry summary when SNAPPY_TESTING is set <Created by mvo5> <https://github.com/snapcore/snapd/pull/2731>
[07:07] <mup> PR snapd#2722 closed: tests: set SNAPPY_USE_STAGING_STORE in su call <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2722>
[07:19] <mup> Bug #1659744 opened: Classic snaps 'not found' if --classic argument is missing <Snappy:New> <https://launchpad.net/bugs/1659744>
[08:05] <mup> PR snapd#2732 opened: snapenv: do not append ":" to the SNAP_LIBRARY_PATH <Created by mvo5> <https://github.com/snapcore/snapd/pull/2732>
[08:47] <mup> PR snapd#2733 opened: tests: make the debugging of c-unit-tests more useful <Created by zyga> <https://github.com/snapcore/snapd/pull/2733>
[08:51] <mup> PR snapcraft#1082 closed: project: new plugin directory location <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1082>
[10:18] <mup> PR snapd#2730 closed: snap: be more helpful in the `snap install <already-installed>` error message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2730>
[10:45] <mup> PR snapcraft#1083 opened: project: support for gui in snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1083>
[10:45] <mup> PR snapd#2734 opened: debian/tests: drop stale autopkgtest dependencies <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2734>
[11:03] <mup> Bug #1637299 changed: sudo snap login "Password:" prompt unclear what password to type <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1637299>
[11:27] <mup> Bug #1633230 opened: snap ack doesn't indicate which assertions are good or bad <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1633230>
[11:27] <mup> Bug #1633261 opened: snap ack should provide a summary of the assertions status <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1633261>
[11:39] <mup> PR snapcraft#1084 opened: make: add support for cwd path to make() function <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1084>
[12:00] <mup> PR snapcraft#1085 opened: snapcraft: fix or ignore PEP8 static errors <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1085>
[12:09] <mup> PR snapcraft#1086 opened: print snapcraft's version on startup when running with --debug <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1086>
[12:21] <mup> PR snapd#2721 closed: tests: integration test  for system reload <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2721>
[12:23] <popey> I have a build which is failing in launchpad. Seems the 'sudo chroot' bit at the bottom barfs.. https://launchpadlibrarian.net/304085507/buildlog_snap_ubuntu_xenial_amd64_openbazaar_BUILDING.txt.gz
[12:23] <popey> one for cjwatson perhaps ^ ?
[12:24] <cjwatson> package context: unrecognized import path "context" (import path does not begin with hostname)
[12:24] <cjwatson> that's the actual failure
[12:24] <cjwatson> the rest is just consequential errors
[12:24] <cjwatson> popey: ^-
[12:25] <cjwatson> and that's something in your snap
[12:27] <popey> hm
[12:27] <popey> thanks for looking.
[12:43] <mup> Bug #1658909 changed: lsb_release fails in classic (arm64) <Snappy:Confirmed for ogra> <lsb (Ubuntu):Invalid> <lsb-release (Ubuntu):Invalid> <https://launchpad.net/bugs/1658909>
[13:35] <Elleo> I'm getting some very odd behaviour with gsettings under confinement, when the snap starts it reads them fine, but it seems to be unable to change them or to get notified of changes if I modify the gsettings manually (but it will pick up the changes after being restarted), anyone have any ideas what might be happening?
[13:35] <Elleo> (it works fine when in devmode)
[14:15] <mup> PR snapd#2482 closed: store: retry auth-related requests <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2482>
[14:26] <morphis> ogra_: there?
[14:43] <zyga> Elleo: do you get any apparmor denials
[14:43] <zyga> Elleo: apparmor controls all dbus traffic
[14:43] <zyga> Elleo: and notification is a distinct signal from read/write calls
[14:43] <zyga> Elleo: dmesg | grep DENIED
[14:43] <zyga> Elleo: and report that as a bug please
[14:43] <jdstrand> I think it is something else
[14:44] <zyga> jdstrand: hey :)
[14:44] <zyga> jdstrand: what do you think?
[14:44] <jdstrand> I suspect it is the bug where HOME is set to ~/snap/SNAP_NAME/SNAP_REVISION and the global dconf is in ~/.config/dconf. the policy allows it, but dconf is having trouble finding it
[14:45] <mup> PR snapd#2733 closed: tests: make the debugging of c-unit-tests more useful <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2733>
[14:45] <jdstrand> I think a symlink from  ~/snap/SNAP_NAME/SNAP_REVISION/.config/dconf to ~/.config/dconf would workaround it. my memory may be hazy. I think seb128 has the details
[14:46] <jdstrand> zyga: nad hi :)
[14:53] <Elleo> zyga: no denials, monitoring the gsetting it seems it does get written to, but then immediately gets changed back for some reason :/
[14:54] <Elleo> zyga: unless I change it manually via gsettings, in which case it stays fine but doesn't get notified
[14:56] <Elleo> popey: /32
[14:57] <Elleo> popey: that bucklespring is a bit worrying :P
[14:57] <Elleo> popey: isn't it basically exploiting the fact that x11 has zero security and acting like a keylogger?
[14:57] <zyga> jdstrand: thanks for the review on the snap-update-ns draft; I'll fix the things you pointed out and focus on figuring out what is broken in the kernel
[14:58] <ogra_> morphis, i'm back now
[14:58] <zyga> jdstrand: while we don't hit that particular issue here (I suspect because we are not starting from a namespace already) I think that you are right in first having a clear understanding of what is at play
[14:59] <seb__> Hi! Does any one know if it's possible to get the mac current out of the USB ports on a Raspberry pi 2? Used to do it with "usb_max_current=1"
[15:00] <zyga> ogra_: ^
[15:01]  * ogra_ doesnt know ...
[15:01] <morphis> ogra_: great :-)
[15:01] <ogra_> seb__, where do you put that usually ? config.txt ? cmdline.txt ?
[15:02] <zyga> seb__: let me grep one thing
[15:02] <seb__> config.txt usually. New to snappy core
[15:03] <ogra_> well, confi.txt is there, you can just edit it as needed ... it is mounted under /boot/uboot/
[15:03] <seb__> really?!, ohh damn. Gotte go check that
[15:03] <ogra_> (or directly if you plug the SD into your PC ... in the system-boot partition)
[15:04] <ogra_> just make sure you dont drop anything of the existing options that are set there
[15:04] <ogra_> else something might break
[15:04] <seb__> Understood
[15:09] <popey> Elleo: pfffft, you worry too much :S
[15:10] <popey> Elleo: it uses X11 and pulse, no network...
[15:12] <seb__> It worked! Thank you for your help :D
[15:24] <cjwatson> popey: oh, while I remember, it'd be low-priority, but maybe a bug on launchpad-buildd to ask us to have a clean error message rather than a noisy traceback in this case would be good
[15:24] <cjwatson> you'd probably have noticed the actual error if it hadn't been followed by a pile of barf
[15:39] <roadmr> jdstrand: tools r833 is in prod! yay, I left them ready for deploy yesterday and they seem to have piggybacked on an impromptu deployment that happened just before midnight.
[15:39] <popey> cjwatson: good point
[15:50] <mup> PR snapd#2734 closed: debian/tests: drop stale autopkgtest dependencies <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2734>
[15:54] <rvr> ogra_: Do you do anything special to enable the serial console on the Pi?
[15:55] <ogra_> rvr, whats missing ?
[15:55] <ogra_> rvr, we set enable_uart in config.txt and we have a console= arg in cmdline.txt for serial
[15:56] <rvr> ogra_: I got a USB TTL serial adapter and I don't get anything in the console
[15:56] <zyga> jdstrand: I have a question about the mount/unmount helpers
[15:56] <zyga> jdstrand: about conditionality of logging
[15:56] <ogra_> did you wire it up correctly ?
[15:56] <rvr> ogra_: What's the speed? 115200
[15:56] <zyga> jdstrand: qemu:ubuntu-16.04-64:tests/main/op-remove
[15:56] <ogra_> yeah
[15:56] <rvr> ogra_: I think so, RX->TX, TX->RX
[15:56] <zyga> jdstrand: if you can answer that one quickly I will do the rest of the changes
[15:57] <ogra_> i usually use: screen /dev/ttyUSB0 115200
[15:58] <ogra_> rvr, and only gnd/rx/tx ... not 5V connected, right ?
[15:58] <rvr> ogra_: 5V connected
[15:58] <rvr> ogra_: And HDMI
[15:58] <ogra_> (connecting the red 5V cable can damage the board)
[15:58] <rvr> ogra_: Oh, I see
[15:59] <ogra_> hdmi shouldnt matter ... the two consoles are separate ... you get consoles on both tty's usually
[16:01] <jdstrand> zyga: I'm not sure what you are linking to. can you give a full url?
[16:02] <zyga> jdstrand: sorry, sure
[16:03] <zyga> https://github.com/snapcore/snapd/pull/2658
[16:03] <mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
[16:03] <zyga> jdstrand: let's just discuss it here
[16:03] <zyga> jdstrand: do you want me to make a debug version of snap-confine
[16:03] <zyga> jdstrand: that can do logging
[16:03] <zyga> jdstrand: and have all the log (and support code) compile to nothing in the regular build?
[16:04] <zyga> jdstrand: and (since we're talking), about the static vs dynamic buffer; originally I implemented this to use a dynamically allocated buffer
[16:04] <zyga> jdstrand: but the snappy team -1 the change as too complex
[16:04] <zyga> jdstrand: so I changed that to a "good enough" static buffer
[16:05] <jdstrand> zyga: I'd prefer that debug* is compiled out on production builds, yes
[16:05] <jdstrand> zyga: I gave another option to the static buffer that would not be complex
[16:05] <zyga> jdstrand: do you have a plan on how we'd be assisting people in debugging issues?
[16:05] <zyga> jdstrand: the N-variant of scpcpy?
[16:06] <zyga> jdstrand: IMHO both approaches are equally non-complex (I don't see malloc as particularly complex in this case, there are exactly two places that call those functions)
[16:07] <jdstrand> zyga: re variant> you call debug_mount_cmd(), it does 'char cmd[BUF_SIZE]' then pass that into your function
[16:07] <stokachu> so with latest snapcraft i saw a commit about merging snap and snapcraft directory
[16:07] <stokachu> can i put everything under /snap directory and all is well?
[16:07] <jdstrand> zyga: it isn't the on the stack bit I cared about, it was 'static'
[16:08] <stokachu> sergiusens, ^
[16:08] <zyga> jdstrand: ah, I see
[16:08] <zyga> jdstrand: that's easy enough
[16:08] <stokachu> also does the store support reading the /snap/setup/gui directory?
[16:09] <zyga> jdstrand: (I still prefer dynamic but I don't think this is an issue)
[16:09] <zyga> jdstrand: though in practice this function will move that buffer from one place to another
[16:09] <zyga> jdstrand: and with the _must approach it won't be any more reusable
[16:09] <zyga> (you either get the buffer size right or you don't)
[16:09] <mup> PR snapd#2726 closed: interfaces/builtin: rework core-support to only allow full access to systemctl <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2726>
[16:10] <pedronis> zyga: for what it worth, when I said static I meant static sized,  so what jdstrand is suggesting
[16:10] <pedronis> I don't know what the other meant
[16:10] <zyga> pedronis: static char[100]; vs char[100] vs char * (and malloc)
[16:11] <pedronis> the 2nd
[16:11] <zyga> pedronis: thanks for clarifying that
[16:12] <pedronis> sorry, C has that kind of static, I know, but might brain almost never think of it, it's rarely a good idea
[16:12] <zyga> static has many meanings, unfortunately
[16:12] <pedronis> yea
[16:12] <pedronis> C++ adds a couple more
[16:13] <zyga> indeed
[16:13] <zyga> keywords are hard to add to a language
[16:13] <zyga> anyway
[16:13] <jdstrand> zyga: as for test plan, I would say they get to compile a snap-confine with debugging. putting it behind an env variable doesn't help with protection for someone attack snap-confine. the attacker will set the env var. if we checked if realuid == euid then honoring the variable is maybe ok
[16:13] <zyga> jdstrand: hmm
[16:14] <zyga> jdstrand: we might compile snap-confine-debug and make it not setuid root
[16:14] <zyga> the people that know how to do it could then use it
[16:14] <jdstrand> I just don't want scores of string handling code in the setuid code
[16:14] <jdstrand> (on production)
[16:15] <jdstrand> granted, snap-confine has an apparmor profile, but it is allowing a good bit that would be fun to attack
[16:15] <jdstrand> (it has to)
[16:15] <zyga> jdstrand: I think string handling is unavoidable, must_snprint is not a panacea for everything, I'd rather just bite the bullet and do it corretly
[16:15] <zyga> jdstrand: but I won't object if you feel that's wrong
[16:16] <jdstrand> zyga: I want both :)
[16:16] <zyga> jdstrand: so what's the next step on this: drop the static char[100] buffers, have the callers pass this in (along with size) and code it 100% defensively?
[16:16] <jdstrand> hence, must_strncat() suggestion
[16:16] <jdstrand> zyga: yes
[16:16] <zyga> jdstrand: well, I had grow_string earlier
[16:16] <zyga> jdstrand: that did realloc
[16:17] <rvr> ogra_: http://paste.ubuntu.com/23875465/
[16:17] <zyga> jdstrand: I guess this is the root of the issue, static vs dynamic memory allocation,
[16:17] <jdstrand> zyga: in general, I liked the intent and most of the branch, it was just these couple bits. getting rid of that boilerplate code will help with coding, clarity and reviews, so thanks
[16:17] <ogra_> rvr, great
[16:17] <rvr> ogra_: It does not boot Ubuntu Core
[16:18] <ogra_> well, because you did hit a key
[16:18] <zyga> jdstrand: right, that was my intent, cut the copy-pasted code and ensure the debug logs are accurate and not hand-crafted
[16:18] <jdstrand> zyga: note that I didn't review the dynamic bits. if they were done right, I wouldn't have cared. some projects actually prefer heap vars over stack
[16:18] <zyga> jdstrand: let me show that, it's still in the history:
[16:19] <jdstrand> zyga: well, it won't matter if the other reviewers are going to nak it :)
[16:19] <jdstrand> I was just pointing out that I don't have a fundamental issue with either heap or stack
[16:19] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/2658/commits/e2ab995067ae382372198c264abacc90872ae7d1
[16:19] <mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
[16:20] <zyga> jdstrand: ah, I see
[16:20] <zyga> jdstrand: (the error message is corrected in the next commit if you spot the error there)
[16:21] <zyga> jdstrand: and this is the use: https://github.com/snapcore/snapd/pull/2658/commits/c007979aaec28469046ecf3f5c54e0a522e31e39
[16:21] <mup> PR snapd#2658: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
[16:26] <axino> hi
[16:26] <axino> is it possible to have a daemon started by a snap run under a non-root user ?
[16:26] <ogra_> not yet
[16:27] <axino> ogra_: ok thanks !
[16:27] <ogra_> (but why would you want that anyway given it is fully snadboxed)
[16:27] <axino> ogra_: I don't know, running stuff as root that doesn't need to be makes me incomfortable
[16:27] <rvr> ogra_: It does nothing when pressing Enter :-/
[16:28] <ogra_> rvr, what should it do ?
[16:28] <rvr> ogra_: Boot Ubuntu Core?
[16:28] <ogra_> (aprt from giving you a newline)
[16:28] <rvr> ogra_: I'm stuck in that screen from the paste
[16:28] <ogra_> well, you obviously stopped the autoboot (whihc only happens if you hit a key in the serial console)
[16:29] <rvr> hmm
[16:29] <ogra_> so uboot now gives you a command shell
[16:29] <ogra_> just reset the board
[16:29] <ogra_> (either by typing reset and hitting enter on the shell prompt or my re-plugging power)
[16:29] <rvr> Just replugged
[16:29] <ogra_> good
[16:29] <rvr> ogra_: Does screen flashes you?
[16:30] <ogra_> nope
[16:30] <rvr> Hmm
[16:30] <ogra_> are you on a mac ?
[16:30] <ogra_> there was a bug about screen misbehaving on macs
[16:30] <ogra_> though that was under macos
[16:30] <rvr> I'm in a Mac, but in Linux
[16:30] <ogra_> right, thats what i remembered
[16:31] <rvr> minicom doesn't flash
[16:31] <ogra_> well, screen doesnt flash for me on either my laptop or my desktop PC
[16:31] <rvr> Weird
[16:32] <rvr> ogra_: But I can't see booting either
[16:32] <rvr> ogra_: Do you use a Pi 3 or Pi 2?
[16:32] <ogra_> https://bugs.launchpad.net/bugs/1659523
[16:32] <mup> Bug #1659523: console-conf doesn't work well if using screen on Mac <Snappy:New> <https://launchpad.net/bugs/1659523>
[16:32] <ogra_> i wonder if it is actually some HW thing
[16:33] <ogra_> given he also claims that minicom works just fine
[16:33] <ogra_> rvr, both ... and a BBB and a dragonboard
[16:33] <ogra_> nothing flashes for me
[16:33] <ogra_> and they all boot just fine
[16:34] <rvr> Hmm... it boots fine with HDMI and without the serial console
[16:34] <ogra_> well, seems something send key presses
[16:34] <ogra_> thats the only way to make the boot stop where you showed it
[16:34] <ogra_> *sends
[16:35] <mup> PR snapd#2735 opened: interfaces/builtin: add missing syscalls to core-support needed for systemctl <Created by morphis> <https://github.com/snapcore/snapd/pull/2735>
[16:39] <ogra_> rvr, with minicom you can also see it properly boot ?
[16:39] <ogra_> ... like ... serial output and all
[16:39] <rvr> ogra_: I unplugged the TX wire and boots ok
[16:40] <ogra_> right, but you wont be able to type anthing into it now
[16:40] <rvr> At least it says that it is booting the kernel
[16:41] <rvr> ogra_: Nope, it wasn't booting with either screen or minicom
[16:42] <ogra_> sounds like some HW issue then ... if even minicom sends keystrokes
[16:48] <rvr> ogra_: Booting fine with a reflashed card and without TX :P
[16:49] <ogra_> well, but that doesnt help using your serial console :)
[16:49] <ogra_> are you sure your tx is actually plugged into the right place ?
[16:49] <rvr> I'm happy to see it at least booting :D
[16:49] <ogra_> heh
[16:50] <ogra_> as long as you dont want to interact with it :)
[17:02] <rvr> ogra_: Re-wired carefully, and with screen I can type now
[17:02] <rvr> ogra_: Thanks :)
[17:02] <ogra_> yay
[17:02] <ogra_> enjoy :)
[17:02] <rvr> I can finally use the screen for the desktop!
[17:04] <rvr> Everytime I had to check the images, I couldn't use my screen :(
[17:11] <axino> ogra_: the thing is, it appears that when run as root, my app can't read stuff in $SNAP_USER_COMMON
[17:11] <kyrofa> axino, that's because your "user" is now root
[17:12] <kyrofa> axino, which means $SNAP_USER_COMMON is now in /root/snap/<snapname>/<snapversion>
[17:12] <axino> kyrofa: correct
[17:12] <axino> kyrofa: the snap can't read there
[17:12] <kyrofa> axino, can you duplicate that with `sudo snap run --shell <appname>`?
[17:13] <axino> ($SNAP_USER_COMMON is /root/snap/<snapname>/common, to be precise)
[17:13] <kyrofa> axino, right, sorry, I gave SNAP_DATA
[17:14] <axino> kyrofa: yes
[17:15] <kyrofa> axino, that sounds like a bug
[17:16] <mup> PR snapd#2736 opened: Initial unity8 interface <Created by mikix> <https://github.com/snapcore/snapd/pull/2736>
[17:17] <mup> PR snapd#2737 opened: tests: add more debug if ubuntu-core-upgrade fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/2737>
[17:18] <stokachu> i realize i brought this up the other day but if i have a snap that is already defined as a classic it would be much cleaner to then ahve the user not have to pass --classic during a snap install
[17:19] <stokachu> ive had a couple people ask me why they have to pass that option in
[17:24] <kyrofa> stokachu, that would be akin to a devmode snap being automatically installed as devmode
[17:24] <kyrofa> stokachu, they users need to understand that this is not a snap confined normally
[17:25] <stokachu> kyrofa, yea that makes sense, i guess from my perspective sudo snap install --classic conjure-up is a lot to type
[17:25] <kyrofa> stokachu, I hear you
[17:25] <stokachu> didnt know if it was worth taking to the mailing list for discussion
[17:26] <kyrofa> stokachu, oh please feel free, but I suspect that's the response you'll get
[17:26] <stokachu> i totally understand why we do it
[17:27] <stokachu> i guess cosmetically is it better to pass in --classic or show a prompt that this snap is a classic snap do you want to continue
[17:27] <stokachu> and --classic would just act as a -y in apt world
[17:29] <stokachu> ill just throw it out there and see what comes of it
[17:31] <axino> kyrofa: I got it
[17:31] <kyrofa> stokachu, I actually quite like that idea myself
[17:31] <kyrofa> stokachu, send that email
[17:31] <axino> kyrofa: I rsynced the files from my user to /root/snap/foo, so root wasn't the owner, which apparmor doesn't like
[17:31] <stokachu> ok cool :) ill write it up now
[17:32] <kyrofa> axino, ahh, yep that'll do it
[17:34] <kyrofa> Hey jdstrand, I'm writing a utility in the Nextcloud snap to install one's own key/cert for HTTPS, but I've hit a bit of an issue. The utility itself needs to run as root, since it's doing stuff in SNAP_DATA. My first cut used the home interface, so as long as the certs are in $HOME the utility can pick them up (as command-line args). Of course, though, running as sudo, the utility can't access the user's $HOME
[17:35] <kyrofa> What is the best way to write this utility?
[17:35] <kyrofa> Saying "First put your certs in /root/ somewhere" isn't super friendly
[17:36] <kyrofa> I'm trying to think of some way to pipe them in without having a terrible interface
[17:38] <ogra_> axino, didnt you say you package a daemon ? why would that have any user dirs at all ... just use SNAP_DATA or SNAP_COMMON
[17:39] <mup> PR snapd#2738 opened: spread: remove state tar on project restore <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2738>
[17:39] <ogra_> (i dont think /root/snap/<snap> is a great idea either ... SNAP_DATA will properly put stuff into /var without being bound to any user)
[17:39] <axino> ogra_: I don't know, I considered a config file to be user data, not system data
[17:39] <ogra_> well, that would make /etc obsolete on most linux installs ;)
[17:39] <kyrofa> axino, is it user-specific? Can users have their own?
[17:40] <kyrofa> axino, if not, then it's a system-wide config living in some random user's home dir
[17:40] <axino> kyrofa: yes, you could say that
[17:40] <stokachu> kyrofa, ok sent lets see what happens!
[17:40] <kyrofa> axino, how would a user make a system-wide service use their own config without effecting the service for other users?
[17:41] <axino> kyrofa: well it's a daemon, it's snapd which makes it system-wide automatically !
[17:41] <kyrofa> Haha, fair enough
[17:41] <axino> kyrofa: presumably, several users could run it with different config - even thought that's not how I'm going to use it
[17:42] <ogra_> i'd make it use SNAP_DATA as default and have a wrapper that takes a look if there is a config in SNAP_USER_DATA ... if the latter is true, read it and override it
[17:43] <ogra_> like it would be on a normal system
[17:43] <ogra_> i.e. if you have have a bip (irc proxy) snap that uses a default config but can be run by a user too ...
[17:43] <axino> ha yes
[17:44] <axino> that could work
[17:50] <axino> ogra_: the issue is, if it's configured as a daemon, then there's no binary for users to run
[17:51] <kyrofa> axino, you could declare one, if the binary is happy running multiple times
[17:51] <ogra_> you could define one ... but yeah. if it is a daemon you have a systemd started instance alongside alll the time
[17:51] <axino> indeed I coul
[17:51] <axino> could*
[17:56] <Chipaca> kyrofa, o/
[17:56] <Chipaca> kyrofa, i just saw the integration tests failures :-)
[17:56] <kyrofa> Hey Chipaca! Haha
[17:56] <Chipaca> kyrofa, do those tests need to run with debug?
[17:57] <Chipaca> i mean
[17:57] <kyrofa> Chipaca, some of them do, but not all (and in fact, some don't)
[17:57] <Chipaca> i can fix the tests by expecting (and skipping) the version line, or by debug=False
[17:57] <Chipaca> but i don't know enough to know which is which tbh :-/
[17:57] <kyrofa> Chipaca, I think the biggest reason we use debug=True there is because upon failure, the suite adds the entire dump to the output log so we can see what happened
[17:58] <Chipaca> kyrofa, any guideline?
[17:58] <kyrofa> Chipaca, hold on, let me take a quick look
[17:58] <Chipaca> ah, true
[17:58] <Chipaca> might as well just fix them to expect the version line then
[17:58] <ogra_> just leave them as is and call them alternate facts
[17:59] <Chipaca> kyrofa, also in the integration tests, i saw it uses version 'devel', making the version line mention 'vdevel'. Maybe i should drop the v?
[17:59] <kyrofa> Chipaca, yeah but... a one-line change causing this many failures means our suite is fragile
[17:59] <kyrofa> Chipaca, you'll get devel when running from source
[18:00] <kyrofa> Chipaca, perhaps removing the v would look better, yeah
[18:00] <Chipaca> also it was *two* lines, not one :-p
[18:00] <kyrofa> :P
[18:03] <kyrofa> Chipaca, yeah our tests are just super fragile. I think we need to change the assertEquals to a assertThat([...], Contains())
[18:04] <kyrofa> Chipaca, but that's not a tiny amount of work. We can take it if you like
[18:05] <Chipaca> kyrofa, I can take a stab at it for the ones affected by this change
[18:05] <kyrofa> Chipaca, alright. Note that there are 29 of them, sure appreciate that
[18:06] <kyrofa> Chipaca, but yeah, please do use the testtools matchers where you can
[18:13] <mup> PR snapcraft#1087 opened: Don't wait for lxd networking in cleanbuild test <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1087>
[18:16] <jdstrand> kyrofa: if the utility needs to run as root, you don't want to have it using non-root certificates. use sudo -H and then HOME is /root
[18:18] <kyrofa> jdstrand, well, I sort of do. Otherwise I require users to place certs in /root first, which seems a hoop to jump through just to say "take my certs"
[18:19] <kyrofa> jdstrand, I might as well not use the home plug at all and say "put them in /root/snap/nextcloud/current/
[18:19] <kyrofa> "
[18:19] <KristijanZic> Hi! Is there some web api for snaps like there is for clicks like https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex  ? I had some free time and have developed some ubuntu webstore in Angular just need to connect it to something if there is an api.
[18:20] <kyrofa> jdstrand, but yeah, that was all I had too. Maybe I'll rewrite it to have them paste cert contents in instead
[18:22] <jdstrand> kyrofa: if the tool needs to run as root, then the certs need to be put in a place owned by root, otherwise root would be trusting certs from unprivileged users. They have to put the certs somewhere anyway, right? can just use 'sudo cp ...' instead of 'cp ...'
[18:23] <kyrofa> jdstrand, the utility I was writing is what put the certs somewhere
[18:23] <kyrofa> (it copies them off to where they need to go)
[18:24] <Chipaca> kyrofa, the tests that use pexpect are going to need to check for the version string explicitly
[18:25] <kyrofa> Chipaca, ah, are there a lot of those? The ones I looked at were just assertEqualing the output. But I guess pexpect is used in the suite setup itself huh
[18:25]  * Chipaca apologises for the context switch
[18:26] <Chipaca> kyrofa, not to worry, i'll sort it
[18:27] <kyrofa> jdstrand, I'm not meaning to argue by the way, I understand the reasoning behind this, I just wanted to make sure I wasn't missing anything
[18:29] <kyrofa> KristijanZic, yes there is. Chipaca where is the snapd REST API documented these days?
[18:29] <kyrofa> Oh wait-- Chipaca nevermind
[18:29] <Chipaca> well, I wouldn't call that a web api
[18:29] <kyrofa> KristijanZic, you don't want that, you want the store-side stuff
[18:29] <Chipaca> KristijanZic, note that wiki page is outdated (it says as much up there)
[18:29] <Chipaca> KristijanZic, in the updated document there's a snaps section
[18:30] <KristijanZic> kyrofa: I just want to list snaps if possible that are in the current Ubuntu snap store.
[18:30] <jdstrand> kyrofa: sure. so, HOME we really have to have 'owner' match (we can't say 'owner or root' in apparmor atm) in order to enforce multiuser
[18:30] <Chipaca> KristijanZic, OTOH maybe you want to talk to snapd, not the store
[18:30] <jdstrand> kyrofa: but, there is this rule<EMAIL_ADDRESS>mrwlkix,
[18:31] <jdstrand> kyrofa: that doesn't have owner match. of course, you have to put them there and if you are going to put them there you may as well use sudo cp to the place you want it
[18:31] <KristijanZic> Chipaca, where are the docs for that? Is that the way uappexplorer does it?
[18:31] <ogra_> KristijanZic, https://github.com/bhdouglass/uappexplorer that has options for listing snaps
[18:31] <Chipaca> KristijanZic, sorry, which 'that'?
[18:31] <ogra_> heh
[18:32] <kyrofa> jdstrand, indeed. It just means more documentation, heh
[18:32] <jdstrand> kyrofa: I'm still not sure why 'sudo cp' needs to be wrapped in a tool...
[18:32] <Chipaca> KristijanZic, uappexplorer talks to CPI
[18:32] <kyrofa> jdstrand, because I want where they go to be under my control
[18:32] <KristijanZic> Chipaca, snapd api?
[18:32] <kyrofa> jdstrand, otherwise I need to document it, keep it up to date, and migrate accordingly
[18:32] <Chipaca> KristijanZic, https://github.com/snapcore/snapd/wiki/REST-API
[18:32] <ogra_> but that needs a local snapd instance
[18:33] <ogra_> if you dont want that CPI is the better option i guess
[18:33] <jdstrand> kyrofa: you could say 'sudo cp foo $SNAP_DATA ; sudo yoursnap.register foo'
[18:33] <KristijanZic> ogra, any docs for cpi?
[18:33] <Chipaca> KristijanZic, that wiki page you pasted is the old CPI docs
[18:34] <Chipaca> KristijanZic, it links to the new ones
[18:34] <ogra_> KristijanZic, i'd just use the uappexplorer source as base for your queries ... and the wiki.ubuntu.com pages
[18:34] <Chipaca> ogra_, dude, it's fully documented in its own section in the new docs
[18:35] <ogra_> code talks !
[18:35] <ogra_> :P
[18:35] <KristijanZic> Chipaca, ok, thanks. ogra, sure
[18:37] <Chipaca> KristijanZic, https://search.apps.ubuntu.com/docs/#snap-specific-endpoints-errors
[18:38] <Chipaca> took me a bit because in the middle of fixing the tests before, didn't want to look at the browser :-)
[18:39] <KristijanZic> Oh, great! Thank you :D
[18:44] <Chipaca> kyrofa, I was wrong. Everything went better than expected.
[18:44] <Chipaca> I think it's a sign I should EOF right here.
[18:44] <kyrofa> Chipaca, ah! Excellent, I agree. I'm jealous you're so far ahead of me
[18:45] <Chipaca> kyrofa, no you're not -- not unless you really wanted to start work nine hours ago
[18:45] <kyrofa> Yeah... you got me :P
[18:52] <stokachu> kyleN, bugs.launchpad.net/snappy is the place for bugs these days? i know github issues got moved
[18:52] <stokachu> sorry kyrofa
[18:53] <kyrofa> stokachu, good question, hold on
[18:54] <stokachu> gustavo told me but it was in passing
[18:54] <kyrofa> stokachu, you probably want to log against snapd
[18:54] <kyrofa> stokachu, https://launchpad.net/snapd
[18:54] <stokachu> ok cool thanks ill do that now
[18:58] <mup> Bug #1659924 opened: Snap failures in 16.04 <Snappy:New> <https://launchpad.net/bugs/1659924>
[19:00] <kyrofa> stokachu, guess we're not the only ones, good thread ;)
[19:00] <stokachu> kyrofa, yea it worked out pretty great, thanks for the push
[19:04] <stokachu> though sergio mentioned about snapd 2.22 without the use of sudo, does that mean we aren't requiring people to snap login anymore?
[19:06] <kyrofa> stokachu, honestly I'm not quite sure what he meant by that
[19:42] <Chipaca> kyrofa, i haven't actually gone, and there's a failing test i'm fixing :-/
[19:42] <kyrofa> Chipaca, :(
[19:50] <Chipaca> kyrofa, fixed, pushed, and happy about it
[19:51] <mup> PR snapd#2735 closed: interfaces/builtin: add missing syscalls to core-support needed for systemctl <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2735>
[20:22] <mup> PR snapcraft#1083 closed: project: support for gui in snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1083>
[20:25] <mup> PR snapcraft#1081 closed: local source: preserve symlinks to directories <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1081>
[20:25] <mup> PR snapcraft#1087 closed: Don't wait for lxd networking in cleanbuild test <Created by OddBloke> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1087>
[20:42] <jdstrand> davidcalle: hey. I just noticed that https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ has the old version of the whitepaper. is that the most current link?
[20:43] <mup> PR snapcraft#1088 opened: Release changelog for 2.26 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1088>
[21:07] <mup> PR snapd#2739 opened: tests: remove (some) garbage files found by restore cleanup analysis <Created by zyga> <https://github.com/snapcore/snapd/pull/2739>
[21:09] <kirkland> who approves/denies requests to own reserved package names?
[21:09] <kirkland> (I submitted a couple)
[21:28] <sergiusens> marcoceppi_, hey, sorry for asking again, bt I lost your quick instructions, mind sending them my way again?
[21:30] <marcoceppi_> sergiusens: hey, no problem https://github.com/juju-solutions/charm-pkg
[21:30] <kyrofa> kirkland, talk to nessita and/or noise][
[21:31]  * kirkland waves at nessita and noise][
[21:32] <noise][> kirkland: hey, what's up?
[21:32] <noise][> name regs...
[21:32] <kirkland> noise][: howdy, I have a few snap package name registrations I'm pushing through
[21:32] <noise][> just got the notif, 1m
[21:32] <kirkland> noise][: yeah, i have a few more coming
[21:33] <kirkland> noise][: actually just do those two, and we're good for today ;-)
[21:33] <sergiusens> marcoceppi_, then charm <what>; charm <what-now> ? :-)
[21:33] <noise][> ok
[21:33] <marcoceppi_> sergiusens: oh, `charm version; charm create foo; cd foo; charm build`
[21:33] <noise][> kirkland: done
[21:34] <DedSec> hey, iam running into this strange issue on ubuntu server 16.04 when i try to run snap install of any app, snap tries to download the ubuntu core file and then gives the following error once the core file has finished downloading. error: cannot perform the following tasks:
[21:34] <DedSec> - Mount snap "core" (888) ([start snap-core-888.mount] failed with exit status 1: Job for snap-core-888.mount failed. See "systemctl status snap-core-888.mount" and "journalctl -xe" for details.
[21:34] <DedSec> )
[22:16] <mup> PR snapd#2685 closed: interfaces/builtin: add account-control interface <Created by teknoraver> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2685>
[22:17] <mup> PR snapd#2703 closed: many: make ubuntu-core-launcher mostly go away <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2703>
[22:22] <kirkland> noise][: thanks, uploaded;  who does the review?
[22:55] <mup> PR snapd#2740 opened: releasing snapd version 2.22 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2740>
[23:00] <noise][> kirkland: reviews of the uploads are security team