mup | Bug #1598656 opened: snapd doesn't close connection on 400 bad request response <Snappy:New> <https://launchpad.net/bugs/1598656> | 02:42 |
---|---|---|
mup | Bug #1598657 opened: No error id for username/password error returned from snapd <Snappy:New> <https://launchpad.net/bugs/1598657> | 02:48 |
mup | Bug #1598667 opened: No snapd API for account registration / password reset <Snappy:New> <https://launchpad.net/bugs/1598667> | 03:27 |
dholbach | hiya | 06:47 |
didrocks | good morning dholbach! | 06:52 |
dholbach | slaut didrocks | 06:52 |
didrocks | how was your week-end? :) | 06:52 |
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:53 |
dholbach | oh wow | 06:54 |
=== chihchun_afk is now known as chihchun | ||
timothy | 'morning | 08:34 |
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:45 |
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:46 |
ogra_ | i'll take a look at the code and do a pull request | 08:47 |
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:48 |
ogra_ | tsk | 08:49 |
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:24 |
didrocks | (I still think the layer config approach though is the best) | 09:25 |
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:30 |
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:32 |
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:34 |
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:35 |
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:41 |
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:42 |
didrocks | but again, if you aren't in controlled of this app code, the wrapper is a good way to handle this | 09:43 |
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:44 |
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:45 |
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:46 |
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:47 |
didrocks | (but as an intermediate step, wrapper script it is! :)) | 09:48 |
iliv | I see | 10:06 |
iliv | well, guess I will have to figure out how to do this with a wrapper script | 10:07 |
iliv | :) | 10:08 |
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:11 |
=== dholbach_ is now known as dholbach | ||
=== LarreaMikel1 is now known as LarreaMikel | ||
zyga | o/ | 10:23 |
didrocks | hey zyga | 10:23 |
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" ) | 10:41 |
=== 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 | ||
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:24 |
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:25 |
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:26 |
ogra_ | (but yeah, we talk about milliseconds indeed) | 12:27 |
didrocks | (knowing that you had 3 wrappers chained up before already :p) | 12:27 |
* ogra_ ponders if he should push his latest two snaps to snappy-playpen | 12:28 | |
niemeyer | Hello snapcrafters | 12:42 |
=== hikiko|ln is now known as hikiko | ||
sergiusens | good morning | 13:33 |
zyga | hey sergiusens, how are you | 13:36 |
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:40 | |
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 | 13:59 |
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:00 |
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:01 |
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:02 |
popey | hm | 14:03 |
popey | maybe that worked? | 14:03 |
zyga | morphis: I think that shoud work, yes | 14:03 |
morphis | hm | 14:03 |
didrocks | let me look | 14:05 |
didrocks | popey: yes, it did! :) | 14:05 |
morphis | zyga: who can I ask about the edge channel thing? | 14:38 |
ogra_ | which "thing" ? | 14:38 |
ogra_ | morphis, ah, --channel only works with the snapd in proposed | 14:39 |
morphis | ogra_: ah :-) | 14:39 |
morphis | good to know | 14:39 |
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:40 |
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:41 |
ogra_ | or rather snap-confine does | 14:42 |
ogra_ | not sure whats needed there ... probably bribing with icecream is enough ;) | 14:43 |
morphis | :-) | 14:44 |
zyga | ogra_: hmm? | 14:45 |
ogra_ | zyga, see the bug above | 14:45 |
ogra_ | last comments | 14:45 |
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 | 14:46 |
=== genii_ is now known as genii | ||
=== Tristit1a is now known as Tristitia | ||
morphis | ogra_: so snap 2.0.10 didn't help with installing snaps which are just in the edge channel | 15:32 |
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:33 |
ogra_ | ogra@styx:~$ sudo snap install gitter --channel=edge --devmode | 15:34 |
ogra_ | 89.16 MB / 89.16 MB [===========================================================================] 100.00 % 4.86 MB/s | 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:34 |
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 [===========================================================================] 100.00 % 295.36 KB/s | 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:35 |
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:36 |
morphis | ogra_: let me file one | 15:37 |
ogra_ | +1 | 15:37 |
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 | 15:40 |
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:12 |
gouchi_ | /dev/dri/card0 and /dev/dri/renderD128 | 16:13 |
=== chihchun is now known as chihchun_afk | ||
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:49 |
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:50 |
=== JanC is now known as Guest28478 | ||
=== JanC_ is now known as JanC | ||
gouchi_ | ogra_: thank you | 16:59 |
elopio | sergiusens: I am not totally happy with that error URL. | 17:07 |
sergiusens | elopio I am thinking of removing it fwiw | 17:08 |
sergiusens | elopio it is not the right one | 17:09 |
sergiusens | elopio or the url itself? | 17:09 |
elopio | sergiusens: we could change the error message, or the store could change the url it returns. I would prefer the URL change. | 17:10 |
sergiusens | elopio well that won't happen soon | 17:11 |
elopio | sergiusens: so the message could be: go to this url for more instructions. | 17:14 |
sergiusens | elopio oh, the message is spec'ed, can't change the text | 17:18 |
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:19 |
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> | 17:54 |
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:08 |
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:12 |
ehbello | I can see some examples at lp:~snappy-hub/snappy-systems but I can't guess what I need for my gadget | 19:13 |
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:26 |
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:32 |
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:33 |
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:36 |
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:37 |
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:44 |
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:46 |
sergiusens | elopio help! https://travis-ci.org/snapcore/snapcraft/jobs/142285265 | 19:47 |
ehbello | niemeyer: I know, but I prefer to develop on an edge platform rather than a version that will becomes obsolete soon :P | 19:54 |
ehbello | (sorry if I write bad english. I'm spanish :) | 19:55 |
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:56 |
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 ...)) | 19:57 |
sergiusens | elopio oh, nvm | 20:01 |
sergiusens | elopio now I guess my branch will fail in integration ;-) | 20:01 |
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:02 |
sergiusens | just switched to it just in case | 20:03 |
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:04 |
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:09 |
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:20 |
sergiusens | elopio in any case this will fail integration tests; the expected message's claim url will be wrong | 20:27 |
mup | PR snapcraft#629 opened: Bugfix/1598932/reserved name <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/629> | 20:31 |
sergiusens | there, fixed | 20:35 |
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> | 21:25 |
elopio | sergiusens: we have an example of matchesregex in snaps_tests/__init__.py | 22:16 |
elopio | what's failing for you? | 22:16 |
sergiusens | elopio ah, the testtool docs did not mention I could pass re flags | 22:48 |
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 | 22:49 |
mup | Bug #1574586 opened: Not able to review snaps <Snappy:New> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1574586> | 23:23 |
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> | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!