[02:42] <mup> Bug #1598656 opened: snapd doesn't close connection on 400 bad request response <Snappy:New> <https://launchpad.net/bugs/1598656>
[02:48] <mup> Bug #1598657 opened: No error id for username/password error returned from snapd <Snappy:New> <https://launchpad.net/bugs/1598657>
[03:27] <mup> Bug #1598667 opened: No snapd API for account registration / password reset <Snappy:New> <https://launchpad.net/bugs/1598667>
[06:47] <dholbach> hiya
[06:52] <didrocks> good morning dholbach!
[06:52] <dholbach> slaut didrocks
[06:52] <didrocks> how was your week-end? :)
[06:53] <dholbach> very nice - we were at a wedding in South Tyrol and I'm working from Bavaria today
[06:53] <dholbach> how was yours?
[06:53] <didrocks> dholbach: oh, sounds great! :)
[06:53] <didrocks> mine was nice as well, didn't really do a lot due to Saturday's weather, but brough Julie's painting to prepare for her expo this week in city center
[06:54] <dholbach> oh wow
[08:34] <timothy> 'morning
[08:45] <ogra_> popey, yo ... do you have any contact to brian douglass ? could we get him to rename "snappy app" to just be "snap" in uappexplorer ?
[08:45] <popey> he's on telegram
[08:46] <popey> you in the apps group? he's @bhdouglas I think
[08:46] <ogra_> nope, only ubuntu device outsiders
[08:46] <popey> also, the code is on github, do a pull request and he'll love you more, he's US so on holiday, busy throwing tea into the harbour
[08:46] <ogra_> ah, post brexit work ... k
[08:47] <ogra_> i'll take a look at the code and  do a pull request
[08:48] <ogra_> geez ... thats irritating
[08:48]  * ogra_ has lots of bugmail fom someone calling himself "Your Mom 
[08:48] <ogra_> "
[08:48] <ogra_> and itr is all serious stuff
[08:49] <ogra_> tsk
[09:24] <iliv> didrocks, thanks for you replies on AskUbuntu. Much appreciated. Although, I have to admit I found them frustrating :)
[09:24] <didrocks> iliv: sorry for this! But things are in progress and it will come down in due time. At least, you have ways to handle your services with those advice meanwhile :)
[09:25] <didrocks> (I still think the layer config approach though is the best)
[09:30] <iliv> I'm still not sure how one can put a configuration file into say $SNAP_DATA, which I understand is a system-wide area where applications (snaps) can store their data? I tried the copy: plugin but it doesn't expand $SNAP_DATA and treats it literally as a string. Is creating a wrapper script that ...
[09:30] <iliv> ... checks if a file exists in $SNAP_DATA, and if it doesn't, copies it over from say $SNAP/configs directory every time when a snap package is mounted/maid available to a system?
[09:32] <didrocks> you won't be able to ship anything at build/install time to $SNAP_DATA. So yeah, creating a wrapper script is one way, having your daemon supporting a layer approach is even better IMHO, but that's up to you :)
[09:34] <iliv> sorry if I'm being too dense, but what is this layer approach exactly that you referred multiple times already?
[09:34] <didrocks> ah, it's the idea that you have this configuration file at multiple level
[09:34] <didrocks> so:
[09:34] <didrocks> - user
[09:34] <didrocks> - system (global)
[09:34] <didrocks> - default
[09:35] <didrocks> you can find the same config file at any level
[09:35] <didrocks> user is $SNAP_USER_DATA, system is $SNAP_DATA and default is $SNAP
[09:35] <didrocks> then, if you find common keys, you always prefer the layer "up" (closer to personal configuration) than the default one
[09:35] <didrocks> for the same key = value pair
[09:41] <iliv> okay, I see. it is something that the application itself should be capable of. however, I do not understand how this is going to help with creating a system-wide configuration file upon install of the package? It's still either creating a wrapper script or putting the burden of creating the ...
[09:41] <iliv> ... configuration file on the end user. Or ... ?
[09:42] <iliv> Having read-only configuration files that reside in $SNAP makes almost no sense. I figure few applications and users wouldn't want to modify a program's configuration file.
[09:42] <didrocks> yeah, if you application isn't capable of that, the wrapper script doing what you told is totally makes sense
[09:42] <didrocks> iliv: it does, it's the default
[09:42] <didrocks> better to have them exported in the same flat file than hardcoded in the app :)
[09:43] <didrocks> but again, if you aren't in controlled of this app code, the wrapper is a good way to handle this
[09:44] <iliv> well, yes, better than hardcoded but if it is read-only it's essentially hardcoded. in a sense that a user/administrator cannot modify any seetings and thus the end result is essentially the same.
[09:45] <iliv> > but again, if you aren't in controlled of this app code, the wrapper is a good way to handle this // here's the thing. there's a ton of software out there that if attempted to be packaged will face this basic problem of wanting to install configuration and other files outside of $SNAP into at ...
[09:45] <iliv> ... least $SNAP_DATA.
[09:45] <iliv> modifying all that massive array of software is pretty much impossible
[09:46] <didrocks> on hardcoded -> yeah, it's in RO, but you have the config format to be readable by the admin to know what options are supported and so on
[09:47] <didrocks> and as a developer, you know that there is no discrepancy between default options and options that are overrideable in the config
[09:47] <didrocks> on the wrapper -> yeah, that's what we have this wrapper approach in quite some snaps, to cope with real world, as you say
[09:47] <didrocks> however, if upstream starts to adopt snaps, they will maybe then reconsider and follow best practices like this layered approach to manage config :)
[09:48] <didrocks> (but as an intermediate step, wrapper script it is! :))
[10:06] <iliv> I see
[10:07] <iliv> well, guess I will have to figure out how to do this with a wrapper script
[10:08] <iliv> :)
[10:11] <didrocks> iliv: if you need any help or need review, do not hesitate! :)
[10:11] <didrocks> it's basically a if [ ! -f $SNAP_DATA/config ]; then cp $SNAP/config; fi
[10:23] <zyga> o/
[10:23] <didrocks> hey zyga
[10:41] <ogra_> didrocks, geez, so much overhead ... [ -e "$SNAP_DATA/config" ] || cp $SNAP/config $SNAP_DATA/config
[10:41] <ogra_> (lots faster than invoking the "if" )
[12:24] <didrocks> ogra_: I wouldn't say "faster", but shorter yeah
[12:24] <ogra_> didrocks, debian did researches of that ... if is always the slowest ...
[12:24] <didrocks> ogra_: interesting
[12:25] <ogra_> case is faster ... just using a condition with "test" is slower than case but faster than if
[12:25] <didrocks> but TBH, when you need a wrapper script, I doubt the fact to have a if vs [] is the real issue :p
[12:25] <ogra_> well, depends how big your wrapper is ... after all it is your apps startup time
[12:26] <ogra_> especially for some test that is run on every startup ...
[12:26] <didrocks> ogra_: when you need to spaw a process for this and then exec, yeah, I bet this is the impact
[12:27] <ogra_> (but yeah, we talk about milliseconds indeed)
[12:27] <didrocks> (knowing that you had 3 wrappers chained up before already :p)
[12:28]  * ogra_ ponders if he should push his latest two snaps to snappy-playpen
[12:42] <niemeyer> Hello snapcrafters
[13:33] <sergiusens> good morning
[13:36] <zyga> hey sergiusens, how are you
[13:40] <sergiusens> zyga doing fine, risked it and came to a coffee shop with just my tablet
[13:40] <sergiusens> zyga so no #snappy-devel telegram avail to me :-P
[13:40] <sergiusens> zyga how was your weekend?
[13:40]  * sergiusens has been handcrafting around the house instead of snapcrafting ;-)
[13:59] <popey> didrocks: that reviewable is painful to use.
[13:59] <zyga> sergiusens: busy, my son turned crazy on making plane models
[13:59] <zyga> sergiusens: we bought lots of small pieces of wood and various tools
[14:00] <zyga> sergiusens: he's remaking the plane model from "porco rosso"
[14:00] <morphis> if I've put a snap into the edge channel of the store should I see it with `snap find`?
[14:00] <didrocks> popey: do you find it so? dholbach and I really liked it for tracking feedback and not losing any remark while doing a second or third review
[14:00] <zyga> morphis: I'm not sure
[14:01] <popey> didrocks: i fail to see how I submit comments
[14:01] <morphis> zyga: but a snap install --channel=edge tpm` should work, right?
[14:01] <didrocks> popey: you are in the reviewable interface?
[14:02] <didrocks> in it you add all your comments, answer to what you want
[14:02] <didrocks> and then hit "publish"
[14:02] <didrocks> to publish all them at the same time
[14:03] <popey> hm
[14:03] <popey> maybe that worked?
[14:03] <zyga> morphis: I think that shoud work, yes
[14:03] <morphis> hm
[14:05] <didrocks> let me look
[14:05] <didrocks> popey: yes, it did! :)
[14:38] <morphis> zyga: who can I ask about the edge channel thing?
[14:38] <ogra_> which "thing" ?
[14:39] <ogra_> morphis, ah, --channel only works with the snapd in proposed
[14:39] <morphis> ogra_: ah :-)
[14:39] <morphis> good to know
[14:40] <morphis> ogra_: do you know when that will land?
[14:40] <zyga> morphis: perhaps Chipaca
[14:40] <zyga> ah :)
[14:40] <ogra_> morphis, well, bug 1592696 indocates it might need additional work, not sure if zyga or mvo saw that
[14:40] <mup> Bug #1592696: snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Invalid> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu Xenial):New> <ubuntu-core-launcher (Ubuntu
[14:40] <mup> Xenial):Incomplete> <https://launchpad.net/bugs/1592696>
[14:40] <zyga> ogra_: you mean 2.0.10
[14:40] <ogra_> zyga, whatever is in -proposed atm
[14:41] <morphis> ogra_: sure you linked the correct bug?
[14:41] <ogra_> yes
[14:41] <ogra_> snapd takes over ubuntu-core-launcher ... see pitti's last comment
[14:42] <ogra_> or rather snap-confine does
[14:43] <ogra_> not sure whats needed there ... probably bribing with icecream is enough ;)
[14:44] <morphis> :-)
[14:45] <zyga> ogra_: hmm?
[14:45] <ogra_> zyga, see the bug above
[14:45] <ogra_> last comments
[14:46] <zyga> ah
[14:46]  * zyga looks
[14:46] <zyga> sorry I didn't see that
[14:46] <ogra_> seems he wants some extra paperwork and tests
[15:32] <morphis> ogra_: so snap 2.0.10 didn't help with installing snaps which are just in the edge channel
[15:33] <ogra_> hmm, it definitely helped here
[15:33] <ogra_> ogra@styx:~$ dpkg -l snapd|grep ii
[15:33] <ogra_> ii  snapd          2.0.10       amd64        Tool to interact with Ubuntu Core Snappy.
[15:34] <ogra_> ogra@styx:~$ sudo snap install gitter --channel=edge --devmode
[15:34] <ogra_> 89.16 MB / 89.16 MB [[15:34] <ogra_> Name    Version  Rev  Developer  Notes
[15:34] <ogra_> gitter  3.0.3-1  1    ogra       devmode
[15:34] <ogra_> works fine for me
[15:35] <morphis> ogra_: try snap install tpm --devmode=edge
[15:35] <morphis> --channel=edge I mean :-)
[15:35] <ogra_> ogra@styx:~$ sudo snap install tpm --channel=edge --devmode
[15:35] <ogra_> 1.14 MB / 1.14 MB [[15:35] <ogra_> Name  Version  Rev  Developer  Notes
[15:35] <ogra_> tpm   1.2-1    1    canonical  devmode
[15:35] <morphis> ogra_: ah
[15:35] <morphis> --devmode seems to be the key
[15:36] <ogra_> i think i also did a reboot after upgrading snapd
[15:36] <morphis> but "snap not found" is a misleading error message in that case
[15:36] <morphis> ogra_: worked now with --channel=edge --devmode
[15:36] <ogra_> good
[15:36] <ogra_> yeah, the error sounds liek a bug
[15:37] <morphis> ogra_: let me file one
[15:37] <ogra_> +1
[15:40] <morphis> ogra_: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598886
[15:40] <mup> Bug #1598886: Misleading error message when trying to install unconfined snaps from the edge channel <snapd (Ubuntu):New> <https://launchpad.net/bugs/1598886>
[15:40] <ogra_> confirmed
[16:12] <gouchi_> hi
[16:12] <gouchi_> is it plan to add this interfaces .
[16:12] <gouchi_> ?
[16:12] <gouchi_> http://www.hastebin.com/ixuyuduxaz.vhdl
[16:13] <gouchi_>  /dev/dri/card0 and /dev/dri/renderD128
[16:49] <sergiusens> elopio mind looking at https://github.com/snapcore/snapcraft/pull/623 ?
[16:49] <mup> PR snapcraft#623: Proper message when registering an already registered snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/623>
[16:50] <ogra_> gouchi_, i would have thought it is part of the opengl interface ... though perhaps /dev/dri/renderD128 is to specific, i guess zyga could tell you if he was around
[16:59] <gouchi_> ogra_: thank you
[17:07] <elopio> sergiusens: I am not totally happy with that error URL.
[17:08] <sergiusens> elopio I am thinking of removing it fwiw
[17:09] <sergiusens> elopio it is not the right one
[17:09] <sergiusens> elopio or the url itself?
[17:10] <elopio> sergiusens: we could change the error message, or the store could change the url it returns. I would prefer the URL change.
[17:11] <sergiusens> elopio well that won't happen soon
[17:14] <elopio> sergiusens: so the message could be: go to this url for more instructions.
[17:18] <sergiusens> elopio oh, the message is spec'ed, can't change the text
[17:19] <elopio> sergiusens: and replacing the url wouldn't be good. So I'm ok with the message not being totally accurate until the store fixes the bug.
[17:54] <sergiusens> joc_ mind clicking on update branch for https://github.com/snapcore/snapcraft/pull/614 (there's an example's test error and I cannot see it as it seems it got round robinned out)
[17:54] <mup> PR snapcraft#614: python3: use --root instead of --target <Created by jocave> <https://github.com/snapcore/snapcraft/pull/614>
[19:08] <mup> PR # changed: snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495
[19:08] <mup> PR # created: snapcraft#596, snapcraft#593, snapcraft#589, snapcraft#579, snapcraft#571, snapcraft#570, snapcraft#568, snapcraft#550, snapcraft#510, snapcraft#495
[19:12] <ehbello> hello, somebody can tell me how to define the 'uboot.env.in' file to build a 'uboot.env' file suitable to snapcraft to build a gadget snap?
[19:13] <ehbello> I can see some examples at lp:~snappy-hub/snappy-systems but I can't guess what I need for my gadget
[19:26] <niemeyer> ehbello: These details are not quite finalized yet.. it'll take a few more weeks before we have a proper specification for it
[19:32] <ehbello> niemeyer: I don't understand that... I mean, if there is not a proper specification for it, why are there devices as beagleblack or pi2 with this file in its snap? are not uboot.env related with uboot directly?
[19:33] <ehbello> niemeyer: I know that uboot.env is built with mkenvimage tool but I don't know what to put in uboot.env.in
[19:36] <niemeyer> ehbello: My apologies for that as I know it is a bit confusing indeed.. the whole tooling around snaps (snapd, snapcraft, etc) changed in a major way in the last few months, for the better.. for most of that time we focused on getting tools right without direct in-device development.
[19:36] <niemeyer> ehbello: So the images you will find around are either 15.04 images, or half-baked 16.04 ones that were never actually released as they're not yet ready
[19:37] <niemeyer> ehbello: If you're using 15.04, I'm sure other people in the channel will be able to give you a hand, but keep it mind that a lot of what we talk about here won't apply there
[19:44] <ehbello> niemeyer: I'm working on ubuntu 16.04 edge images generated with latest branch of ubuntu-device-flash from 'mvo' in LP and I have a partial gagdet snap... I think the only thing missing is the uboot.env file for an armhf gadget to get everything working properly :)
[19:46] <niemeyer> ehbello: That's great, glad to see the in-development code being put to test and actually working :)
[19:46] <niemeyer> ehbello: Just note it may actually break due to incompatible changes (IOW, good to play with, not good for real devices yet)
[19:47] <sergiusens> elopio help! https://travis-ci.org/snapcore/snapcraft/jobs/142285265
[19:54] <ehbello> niemeyer: I know, but I prefer to develop on an edge platform rather than a version that will becomes obsolete soon :P
[19:55] <ehbello> (sorry if I write bad english. I'm spanish :)
[19:56] <niemeyer> ehbello: Yeah, that's a good plan
[19:56] <elopio> sergiusens: my branch added -d, so when checking errors in integration, between that "Registering ..." message and "The name \'test-already-registered-snap-name\' is already taken", there is a trace
[19:57] <niemeyer> ehbello: Your English seems prefect.. I'm not a native speaker either
[19:57] <sergiusens> elopio but the register failed does a subprocess checkcall all on its own
[19:57] <elopio> sergiusens: there is no need to check the first part in the message, IMO. So I would do: assertThat(output, EndsWith(The name \'test-already-registered-snap-name\' is already ...))
[20:01] <sergiusens> elopio oh, nvm
[20:01] <sergiusens> elopio now I guess my branch will fail in integration ;-)
[20:02] <elopio> sergiusens: nop. I've just registered that name in staging. Actually, there's no need for anything we discussed in the standup.
[20:02] <elopio> with the hardcoded name and the right values in the database, it works and it's simple.
[20:02] <sergiusens> elopio don't I need to use the sleeper command though?
[20:03] <sergiusens> just switched to it just in case
[20:04] <elopio> sergiusens: yes, the sleep might be missing there. I'm not sure if the store blocks also when the registration failed, but it's likely.
[20:09] <mup> PR snapd#1475 changed: integration-tests: drop already covered refresh app test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1475>
[20:20] <mup> PR snapd#1479 changed: change API of snapstate.Get() to return a snapstate.SnapState <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1479>
[20:27] <sergiusens> elopio in any case this will fail integration tests; the expected message's claim url will be wrong
[20:31] <mup> PR snapcraft#629 opened: Bugfix/1598932/reserved name <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/629>
[20:35] <sergiusens> there, fixed
[21:25] <sergiusens> elopio for snapcraft#630 I would like to use MatchesRegex for an integration test and failing badly
[21:25] <mup> PR snapcraft#630: Report a nice error when registering too fast <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/630>
[21:25] <mup> PR snapcraft#630 opened: Report a nice error when registering too fast <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/630>
[22:16] <elopio> sergiusens: we have an example of matchesregex in snaps_tests/__init__.py
[22:16] <elopio> what's failing for you?
[22:48] <sergiusens> elopio ah, the testtool docs did not mention I could pass re flags
[22:49] <sergiusens> elopio care to look at 623 one more time, same for 629; btw I cannot login to staging to see if that last int test would work
[23:23] <mup> Bug #1574586 opened: Not able to review snaps <Snappy:New> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1574586>
[23:49] <mup> PR snapcraft#623 changed: Proper message when registering an already registered snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/623>