[02:42] Bug #1598656 opened: snapd doesn't close connection on 400 bad request response [02:48] Bug #1598657 opened: No error id for username/password error returned from snapd [03:27] Bug #1598667 opened: No snapd API for account registration / password reset [06:47] hiya [06:52] good morning dholbach! [06:52] slaut didrocks [06:52] how was your week-end? :) [06:53] very nice - we were at a wedding in South Tyrol and I'm working from Bavaria today [06:53] how was yours? [06:53] dholbach: oh, sounds great! :) [06:53] 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] oh wow === chihchun_afk is now known as chihchun [08:34] 'morning [08:45] 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] he's on telegram [08:46] you in the apps group? he's @bhdouglas I think [08:46] nope, only ubuntu device outsiders [08:46] 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] ah, post brexit work ... k [08:47] i'll take a look at the code and do a pull request [08:48] geez ... thats irritating [08:48] * ogra_ has lots of bugmail fom someone calling himself "Your Mom [08:48] " [08:48] and itr is all serious stuff [08:49] tsk [09:24] didrocks, thanks for you replies on AskUbuntu. Much appreciated. Although, I have to admit I found them frustrating :) [09:24] 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] (I still think the layer config approach though is the best) [09:30] 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] ... 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] 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] sorry if I'm being too dense, but what is this layer approach exactly that you referred multiple times already? [09:34] ah, it's the idea that you have this configuration file at multiple level [09:34] so: [09:34] - user [09:34] - system (global) [09:34] - default [09:35] you can find the same config file at any level [09:35] user is $SNAP_USER_DATA, system is $SNAP_DATA and default is $SNAP [09:35] then, if you find common keys, you always prefer the layer "up" (closer to personal configuration) than the default one [09:35] for the same key = value pair [09:41] 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] ... configuration file on the end user. Or ... ? [09:42] 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] yeah, if you application isn't capable of that, the wrapper script doing what you told is totally makes sense [09:42] iliv: it does, it's the default [09:42] better to have them exported in the same flat file than hardcoded in the app :) [09:43] but again, if you aren't in controlled of this app code, the wrapper is a good way to handle this [09:44] 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] > 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] ... least $SNAP_DATA. [09:45] modifying all that massive array of software is pretty much impossible [09:46] 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] and as a developer, you know that there is no discrepancy between default options and options that are overrideable in the config [09:47] 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] 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] (but as an intermediate step, wrapper script it is! :)) [10:06] I see [10:07] well, guess I will have to figure out how to do this with a wrapper script [10:08] :) [10:11] iliv: if you need any help or need review, do not hesitate! :) [10:11] it's basically a if [ ! -f $SNAP_DATA/config ]; then cp $SNAP/config; fi === dholbach_ is now known as dholbach === LarreaMikel1 is now known as LarreaMikel [10:23] o/ [10:23] hey zyga [10:41] didrocks, geez, so much overhead ... [ -e "$SNAP_DATA/config" ] || cp $SNAP/config $SNAP_DATA/config [10:41] (lots faster than invoking the "if" ) === hikiko is now known as desrt_ === desrt_ is now known as hikiko === hikiko is now known as hikiko|ln === dpm_ is now known as dpm [12:24] ogra_: I wouldn't say "faster", but shorter yeah [12:24] didrocks, debian did researches of that ... if is always the slowest ... [12:24] ogra_: interesting [12:25] case is faster ... just using a condition with "test" is slower than case but faster than if [12:25] but TBH, when you need a wrapper script, I doubt the fact to have a if vs [] is the real issue :p [12:25] well, depends how big your wrapper is ... after all it is your apps startup time [12:26] especially for some test that is run on every startup ... [12:26] ogra_: when you need to spaw a process for this and then exec, yeah, I bet this is the impact [12:27] (but yeah, we talk about milliseconds indeed) [12:27] (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] Hello snapcrafters === hikiko|ln is now known as hikiko [13:33] good morning [13:36] hey sergiusens, how are you [13:40] zyga doing fine, risked it and came to a coffee shop with just my tablet [13:40] zyga so no #snappy-devel telegram avail to me :-P [13:40] zyga how was your weekend? [13:40] * sergiusens has been handcrafting around the house instead of snapcrafting ;-) [13:59] didrocks: that reviewable is painful to use. [13:59] sergiusens: busy, my son turned crazy on making plane models [13:59] sergiusens: we bought lots of small pieces of wood and various tools [14:00] sergiusens: he's remaking the plane model from "porco rosso" [14:00] if I've put a snap into the edge channel of the store should I see it with `snap find`? [14:00] 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] morphis: I'm not sure [14:01] didrocks: i fail to see how I submit comments [14:01] zyga: but a snap install --channel=edge tpm` should work, right? [14:01] popey: you are in the reviewable interface? [14:02] in it you add all your comments, answer to what you want [14:02] and then hit "publish" [14:02] to publish all them at the same time [14:03] hm [14:03] maybe that worked? [14:03] morphis: I think that shoud work, yes [14:03] hm [14:05] let me look [14:05] popey: yes, it did! :) [14:38] zyga: who can I ask about the edge channel thing? [14:38] which "thing" ? [14:39] morphis, ah, --channel only works with the snapd in proposed [14:39] ogra_: ah :-) [14:39] good to know [14:40] ogra_: do you know when that will land? [14:40] morphis: perhaps Chipaca [14:40] ah :) [14:40] morphis, well, bug 1592696 indocates it might need additional work, not sure if zyga or mvo saw that [14:40] Bug #1592696: snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied

Xenial):Incomplete> [14:40] ogra_: you mean 2.0.10 [14:40] zyga, whatever is in -proposed atm [14:41] ogra_: sure you linked the correct bug? [14:41] yes [14:41] snapd takes over ubuntu-core-launcher ... see pitti's last comment [14:42] or rather snap-confine does [14:43] not sure whats needed there ... probably bribing with icecream is enough ;) [14:44] :-) [14:45] ogra_: hmm? [14:45] zyga, see the bug above [14:45] last comments [14:46] ah [14:46] * zyga looks [14:46] sorry I didn't see that [14:46] seems he wants some extra paperwork and tests === genii_ is now known as genii === Tristit1a is now known as Tristitia [15:32] ogra_: so snap 2.0.10 didn't help with installing snaps which are just in the edge channel [15:33] hmm, it definitely helped here [15:33] ogra@styx:~$ dpkg -l snapd|grep ii [15:33] ii snapd 2.0.10 amd64 Tool to interact with Ubuntu Core Snappy. [15:34] ogra@styx:~$ sudo snap install gitter --channel=edge --devmode [15:34] 89.16 MB / 89.16 MB [===========================================================================] 100.00 % 4.86 MB/s [15:34] Name Version Rev Developer Notes [15:34] gitter 3.0.3-1 1 ogra devmode [15:34] works fine for me [15:35] ogra_: try snap install tpm --devmode=edge [15:35] --channel=edge I mean :-) [15:35] ogra@styx:~$ sudo snap install tpm --channel=edge --devmode [15:35] 1.14 MB / 1.14 MB [===========================================================================] 100.00 % 295.36 KB/s [15:35] Name Version Rev Developer Notes [15:35] tpm 1.2-1 1 canonical devmode [15:35] ogra_: ah [15:35] --devmode seems to be the key [15:36] i think i also did a reboot after upgrading snapd [15:36] but "snap not found" is a misleading error message in that case [15:36] ogra_: worked now with --channel=edge --devmode [15:36] good [15:36] yeah, the error sounds liek a bug [15:37] ogra_: let me file one [15:37] +1 [15:40] ogra_: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598886 [15:40] Bug #1598886: Misleading error message when trying to install unconfined snaps from the edge channel [15:40] confirmed [16:12] hi [16:12] is it plan to add this interfaces . [16:12] ? [16:12] http://www.hastebin.com/ixuyuduxaz.vhdl [16:13] /dev/dri/card0 and /dev/dri/renderD128 === chihchun is now known as chihchun_afk [16:49] elopio mind looking at https://github.com/snapcore/snapcraft/pull/623 ? [16:49] PR snapcraft#623: Proper message when registering an already registered snap [16:50] 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 === JanC is now known as Guest28478 === JanC_ is now known as JanC [16:59] ogra_: thank you [17:07] sergiusens: I am not totally happy with that error URL. [17:08] elopio I am thinking of removing it fwiw [17:09] elopio it is not the right one [17:09] elopio or the url itself? [17:10] sergiusens: we could change the error message, or the store could change the url it returns. I would prefer the URL change. [17:11] elopio well that won't happen soon [17:14] sergiusens: so the message could be: go to this url for more instructions. [17:18] elopio oh, the message is spec'ed, can't change the text [17:19] 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] 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] PR snapcraft#614: python3: use --root instead of --target [19:08] 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] PR # created: snapcraft#596, snapcraft#593, snapcraft#589, snapcraft#579, snapcraft#571, snapcraft#570, snapcraft#568, snapcraft#550, snapcraft#510, snapcraft#495 [19:12] 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] I can see some examples at lp:~snappy-hub/snappy-systems but I can't guess what I need for my gadget [19:26] 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] 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] 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] 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] 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] 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] 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] ehbello: That's great, glad to see the in-development code being put to test and actually working :) [19:46] ehbello: Just note it may actually break due to incompatible changes (IOW, good to play with, not good for real devices yet) [19:47] elopio help! https://travis-ci.org/snapcore/snapcraft/jobs/142285265 [19:54] niemeyer: I know, but I prefer to develop on an edge platform rather than a version that will becomes obsolete soon :P [19:55] (sorry if I write bad english. I'm spanish :) [19:56] ehbello: Yeah, that's a good plan [19:56] 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] ehbello: Your English seems prefect.. I'm not a native speaker either [19:57] elopio but the register failed does a subprocess checkcall all on its own [19:57] 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] elopio oh, nvm [20:01] elopio now I guess my branch will fail in integration ;-) [20:02] sergiusens: nop. I've just registered that name in staging. Actually, there's no need for anything we discussed in the standup. [20:02] with the hardcoded name and the right values in the database, it works and it's simple. [20:02] elopio don't I need to use the sleeper command though? [20:03] just switched to it just in case [20:04] 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] PR snapd#1475 changed: integration-tests: drop already covered refresh app test [20:20] PR snapd#1479 changed: change API of snapstate.Get() to return a snapstate.SnapState [20:27] elopio in any case this will fail integration tests; the expected message's claim url will be wrong [20:31] PR snapcraft#629 opened: Bugfix/1598932/reserved name [20:35] there, fixed [21:25] elopio for snapcraft#630 I would like to use MatchesRegex for an integration test and failing badly [21:25] PR snapcraft#630: Report a nice error when registering too fast [21:25] PR snapcraft#630 opened: Report a nice error when registering too fast [22:16] sergiusens: we have an example of matchesregex in snaps_tests/__init__.py [22:16] what's failing for you? [22:48] elopio ah, the testtool docs did not mention I could pass re flags [22:49] 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] Bug #1574586 opened: Not able to review snaps

[23:49] PR snapcraft#623 changed: Proper message when registering an already registered snap