[00:38] <flexiondotorg> nessita, I'm talking with the HexChat upstream lead dev.
[00:38] <flexiondotorg> They are working on a snap.
[00:38] <flexiondotorg> They should be filing a name dispute form anytime now, can you keep an eye out for it please?
[00:39] <flexiondotorg> It will be filed by https://launchpad.net/~tingping
[02:19] <Chris___> Question, I am stuck booting ubuntu core 16 the screen says  core 16 on ip number
[02:19] <Chris___> Then it asks for local host login but nothing works
[07:23] <foxmask> bonjello
[07:23] <zyga> o/
[07:35] <nullx9> morning
[08:13] <sil2100> Hey guys! Where can I get info about snappy store packages from the edge channel?
[08:16] <mvo> sil2100: snapd 2.18 from last night has the groundwork for this, there is a new snap info command
[08:16] <mvo> sil2100: what info do you need?
[08:16] <mvo> sil2100: is this for a dev project? I can give you rest api if that helps
[08:22] <sil2100> mvo: sometimes it's nice to be able to search for those, and then check for instance what versions are available (or what's the latest one) - and/or for what archs the snap is available
[08:24] <sil2100> For instance, I would now need to know those things about the mir-libs snap
[08:25] <mvo> sil2100: snap find won't search in edge, but I think the use case of "snap info --edge mir-libs" sounds sensible. chipaca is working on snap info currently
[08:25] <sil2100> mvo: can I somehow make that API call directly?
[08:25] <sil2100> In the meantime?
[08:27] <mvo> sil2100: `http --pretty=format --print b https://search.apps.ubuntu.com/api/v1/snaps/details/mir-libs X-Ubuntu-Series:16 channel==edge` should work
[08:28] <mvo> sil2100: or http --pretty=format --print b https://search.apps.ubuntu.com/api/v1/snaps/details/mir-libs X-Ubuntu-Architecture:i386 X-Ubuntu-Series:16 channel==edge if you want different arches
[08:30] <sil2100> mvo: thanks
[08:32] <mvo> yw
[08:58] <flexiondotorg> Morning
[09:11] <mup> PR snapd#2356 opened: cmd/snap: have some completers <Created by chipaca> <https://github.com/snapcore/snapd/pull/2356>
[09:28] <davidcalle> zyga: hi, I've noticed I have both ubuntu-core and core installed (snapd on 16.10), is that supposed to happen?
[09:30] <zyga> davidcalle: no, I don't think that's supposed to happen
[09:30] <zyga> mvo: ^^
[09:30] <mvo> davidcalle: what version of snapd do you have installed?
[09:31] <mvo> davidcalle: apt list snapd
[09:31] <davidcalle> 2.16+16.10ubuntu1.2
[09:31] <davidcalle> mvo ^
[09:31] <davidcalle> (yakkety-updates)
[09:40] <mvo> davidcalle: hmm, anything in "snap changes" that looks like it might brought in core?
[09:43] <davidcalle> mvo: I installed it manually, but is it not supposed to replace ubuntu-core?
[09:44] <mvo> davidcalle: not yet, thats still something we need to make happen
[09:47] <mup> PR snapd#2357 opened: cmd/snap: document 'snap list --all' <Created by zyga> <https://github.com/snapcore/snapd/pull/2357>
[09:51] <timp> mvo: hello
[09:51] <timp> mvo: there is a new ubuntu-app-platform candidate. How do we promote that to stable?
[09:56] <mvo> timp: iirc timo has fully access to myapps.ubuntu.com and he has delegate access furth and also select channels. or am I misunderstanding?
[10:01] <timp> mvo: I am trying to do it without Timo now, he is on parental leave. I am trying to do it by clicking "Manage this package in the store" on https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/11369 but then I get Access Forbidden.
[10:01] <timp> maybe I am trying to manage it in the wrong place, or I don't have the permissions
[10:02] <mvo> timp: https://myapps.developer.ubuntu.com/dev/click-apps/6271/ is the right place
[10:02] <mvo> timp: but it looks like you don't have permission
[10:03] <timp> indeed
[10:03] <mvo> timp: lets talk about it
[10:49] <mup> PR snapd#2358 opened: tests: decrease the number of expected featured apps <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2358>
[10:51] <mup> PR snapcraft#929 opened: WIP: Snap snapcraft (based on pylxd branch) <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/929>
[11:12] <nessita> flexiondotorg, ack! is still not there, but will keep an eye on it
[11:15] <flexiondotorg> nessita, Thanks.
[11:34] <tptr> hi, I am trying to disable the automatic snap refresh happening daily but have not found a docu on his so far. Any hint?
[11:39] <rvr> fgimenez: With candidate channel, dragonboard boots fine
[11:49] <gerry_> hi when I run snappy-debug I get this suggestion "* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON" I also get one for write, any suggestions on how I can deal with this?
[12:03] <flexiondotorg> mvo I was experimenting with snap a memory usage reporting utility last night.
[12:04] <flexiondotorg> In order to confine it the system-observe interface needs some new rules.
[12:04] <flexiondotorg> I'd like to prepare a pull-request but want to make sure I'm approaching this the correctly.
[12:04] <zyga> flexiondotorg: do it, file a bug with the snapd-interface tag and we'll reviwe it
[12:04] <zyga> review it*
[12:05] <flexiondotorg> OK.
[12:09] <mup> PR snapd#2357 closed: cmd/snap: document 'snap list --all' <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2357>
[12:10] <mup> PR snapd#2355 closed: cmd/snap: add tests for section completion; fix bugs <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2355>
[12:13] <fgimenez> rvr, yes, the suite is passing here with this patch https://github.com/snapcore/snapd/pull/2358/files
[12:13] <mup> PR snapd#2358: tests: decrease the number of expected featured apps <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2358>
[12:13] <fgimenez> rvr, what about pi3, did you try it with candidate?
[12:15] <tvoss> mvo: ping
[12:17] <gerry_> hi when I run snappy-debug I get this suggestions: http://pastebin.com/ds8g1jSk how do I cure them?
[12:19] <rvr> fgimenez: I only have one external monitor :) Still waiting for dragonboard test results.
[12:20] <zyga> gerry_: try connecting the home plug to your apps
[12:20] <zyga> gerry_: this will give you (partial) access to home
[12:20] <zyga> gerry_: except for dot files, so it won't help in this particular case I'm afraid
[12:23] <mup> Bug #1644810 opened: snapd system-observe interface is missing rules to allow memory usage analysis <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1644810>
[12:24] <gerry_> zyga : yes I have the home plug already but thank you for looking
[12:25] <fgimenez> rvr, ok thx! :)
[12:33] <timp> mvo: is there a policy which snaps should be published under the canonical account?
[12:34] <timp> I'm thinking where to publish an ubuntu-ui-toolkit-examples snap. I cannot register that with my own account ('tim'), I guess snaps starting with "ubuntu" are special.
[12:35] <zyga> timp: ownership can be changed later
[12:36] <timp> zyga: right, but I tried to register 'ubuntu-ui-toolkit-examples' and it is currently pending review. I was asked to use either a special Ubuntu SDK Team account (which we don't have), or the canonical account
[12:38] <zyga> timp: in that case someone from the store needs to sort this out for you
[12:40] <timp> I talked with them, and I was asked to figure out if it should go on the canonical account. If not, we should create an SDK team account
[12:43] <mup> PR snapd#2359 opened: spread: add boilerplate for Linode delta uploads <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2359>
[12:48] <gerry_> hi I get these two suggestion when I run snappy-debug not sure how to write the lines that I think my wrapper script needs?
[12:49] <gerry_> sorry these two suggestions: http://pastebin.com/gjnFMS98
[12:53] <gerry_> my program runs fine with these suggestions but I thought it might be an answer to my real problem which is it crashes when I run it with sudo in dangerous install
[13:04] <rvr> fgimenez: http://paste.ubuntu.com/23532177/
[13:27] <gerry_> hi when I run snappy debug I get these suggestions http://pastebin.com/gjnFMS98 it works fine but when I install it as dangerous and try to run it with sudo it crashes ?
[13:29] <sergiusens> zyga ^
[13:39] <zyga> sergiusens: I looked yesterday, no idea
[13:41] <sergiusens> zyga feels like a conlict with $HOME
[13:51] <zyga> sergiusens: well, $HOME is redefined so whatever is going on, the app looks at the real home explicitly
[14:56] <qengho> gerry_: I see "java" in that name. Java constructs its idea of user home from things other than the HOME environment variable. Does your wrapper set the java.home variable (or whatever it's named)?
[15:04] <gerry_> gengho: here is a copy of my wrapper : http://pastebin.com/k69QiwnD
[15:07] <mup> PR snapd#2360 opened: Fix prefix search query; Fix empty query search; Find doc <Created by AlexandreAbreu> <https://github.com/snapcore/snapd/pull/2360>
[15:08] <qengho> gerry_: You probably need to be setting the user.home Java property at startup.
[15:10] <gerry_> gengho: ok sorry I am very newb how would I do that?
[15:11] <qengho> gerry_: $  man java    Then search for "property", see -Dproperty=value, add the parameter to your wrapper where you run java.
[15:14] <gerry_> gengho: ok I will try thank you for your help
[15:18] <alex-abreu> mvo, ping
[15:19] <Chipaca> alex-abreu: o/
[15:21] <Chipaca> alex-abreu: did you actually test the change you're proposing in #2360 IRL?
[15:22] <alex-abreu> Chipaca, yes ... why?
[15:22] <Chipaca> alex-abreu: because it won't work as described?
[15:22] <alex-abreu> Chipaca, did I miss something? I checked with the store guys yesterday and made sure that I got the semantics right
[15:22] <alex-abreu> Chipaca, what do you mean?
[15:22] <alex-abreu> Chipaca, it doesn't work?
[15:22] <Chipaca> alex-abreu: but you're not changing the client of the store, you're changing the client of snapd
[15:23] <alex-abreu> Chipaca, yes I know
[15:23] <Chipaca> which is why i ask, did you test the change
[15:23] <Chipaca> because snapd treates name=foo as a request for an exact match
[15:23] <alex-abreu> Chipaca, so the answer is yes, ...
[15:24] <Chipaca> that is, name=foo on snapd hits the store details endpoint, not the search endpoint
[15:24] <Chipaca> name=foo* gets the * removed and hits the search endpoint with name=foo
[15:28] <alex-abreu> Chipaca, ah I see what you mean, ... sorry yes, I missed the findOne bit, I'll update the PR
[15:29] <alex-abreu> Chipaca, one thing that I want to do is cleanup the snapd client API, ... the semantics is not clear, it overloads a bit the store search options
[15:30] <alex-abreu> Chipaca, from the store's perspective, all searches are "prefix searches", ... but you can control if the search is limited on the snap names  or on all the fields, this is not reflected on the snapd client api side, which overloads the Prefix term
[15:30] <alex-abreu> Chipaca, if you see what I mean
[15:32] <Chipaca> alex-abreu: I think I do
[15:32] <Chipaca> alecu: but let's discuss changes before you implement them please
[15:32] <Chipaca> alex-abreu: ^
[15:32] <Chipaca> alecu: you too :-p
[15:32] <alex-abreu> Chipaca, sure
[15:32] <alex-abreu> :)
[15:33] <alex-abreu> Chipaca, let's use the branch as a basis for discussion :)
[15:33] <alex-abreu> Chipaca, do you want to have a quick ho chat for that?
[15:34] <Chipaca> alex-abreu: there's also a lot of duplication in client that could and should be dropped now that the role and separation of things is clearer
[15:34] <Chipaca> alex-abreu: I'd rather discuss here tbh
[15:34] <alex-abreu> Chipaca, agree, this is what triggered my PR
[15:34] <alex-abreu> Chipaca, np
[15:35] <mvo> alex-abreu: pong (or did Chipaca already take of everything?)
[15:35] <alex-abreu> mvo, no I wanted to talk to you about a separate thing :)
[15:35] <mvo> alex-abreu: aha, ok
[15:36] <alex-abreu> mvo, what did you have in mind to improve the sections discoverability from the snap cmd's perspective? something like "snap find sections"
[15:36]  * Chipaca feels a little guilty now
[15:37] <mvo> alex-abreu: I was thinking about it but did not came up with a nice cli interface yet
[15:37] <mvo> alex-abreu: snap find --sections without an argument could list them all maybe
[15:37] <Chipaca> alex-abreu: OS had a google doc about the sections UX; have you seen it?
[15:37] <mvo> alex-abreu: or `snap find --section` could return "no section specified, please select one of "a,b,c""
[15:37] <alex-abreu> Chipaca, so basically I want to kind of keep the store's semantics clear, in that ALL the searches are prefix searches, and that you can control the extent of the fields searches (name or all), ...
[15:37] <Chipaca> nessita might even have a url somewhere
[15:38] <mvo> Chipaca: aha, great, so the cli was already speced? brilliant
[15:38] <alex-abreu> Chipaca, did you have something specific in mind when you talked about the cleanups necessary?
[15:38] <Chipaca> mvo: I don't remember if this aspect of it was
[15:38] <Chipaca> mvo: because I am not a good repository of urls :-)
[15:39] <alex-abreu> Chipaca, ah  the Friday guilty feeling :)
[15:39] <nessita> Chipaca, how can I help?
[15:39] <Chipaca> alex-abreu: my cleanups seem to be orthogonal to yours
[15:39] <Chipaca> nessita: do you remember the sections ux doc?
[15:39] <Chipaca> alex-abreu: but I wonder what exactly you mean about all searches being prefix searches
[15:40] <nessita> Chipaca, yes, one sec
[15:40] <alex-abreu> Chipaca, mvo https://docs.google.com/document/d/19HJFQo1Zpz_LgYFzcdBfbRJk3OX3DsjhHyGgkfKNkzY/edit#heading=h.vhukcea9ynk1
[15:40] <alex-abreu> mvo, Chipaca but there is nothing about sections discoverability the only thing that I could find and implemented is the tab completion
[15:40] <Chipaca> nessita: ^
[15:40] <Chipaca> nessita: thanks
[15:40] <alex-abreu> this is why I did it this way
[15:40] <Chipaca> agh, 2fa
[15:40] <alex-abreu> there is a piece missing
[15:41] <Chipaca> hmm, there might be another doc?
[15:41] <nessita> Chipaca, pasting on a private channel
[15:41] <Chipaca> or this one has evolved a lot since i saw it
[15:41] <Chipaca> thanks
[15:42] <alex-abreu> Chipaca, what i mean is that there is no way to have an exact search as of now in the store, ... either through the name= or q= fields, ... there is no exact search
[15:42] <nessita> alex-abreu, that is intentional given the defined semantics for snap find
[15:42] <alex-abreu> Chipaca, nessita maybe there is another doc indeed
[15:42] <Chipaca> nessita: alex-abreu: seems it's about the same; just tabs
[15:43] <alex-abreu> nessita, sure I am not saying that it isn't ... just decribing the situation :)
[15:43] <Chipaca> so one approach would be to list sections at the bottom of the empty snap find output
[15:43] <Chipaca> alex-abreu: but if I search q=foo, it'll search for foo all over the place, not just as a prefix
[15:44] <alex-abreu> Chipaca, the issue is that it overloads a bit the cmd, ... instead of hitting the right endpoint from the store
[15:45] <Chipaca> alex-abreu: there you lost me
[15:45] <mup> PR snapd#2347 opened: overlord: flag required-snaps from model as required and prevent removing them <Created by pedronis> <https://github.com/snapcore/snapd/pull/2347>
[15:45] <alex-abreu> Chipaca, yes, maybe we dont have the same understanding of the word prefix :) ... what I mean is when I search foo it will return snaps 'foobar', 'foofoo', 'foo' etc. and that you can restrict the search to only names or all fields through name= or q=
[15:45] <Chipaca> alex-abreu: that's not true
[15:45] <Chipaca> I mean
[15:46] <Chipaca> alex-abreu: if you search q=hello it'll look for hello anywhere in certain fields
[15:46] <alex-abreu> Chipaca, well this is what the store guys told me yesterday, and what I could see from the command line
[15:46] <Chipaca> it might give prefixes more weight, but it can occur anywhere
[15:46] <alex-abreu> Chipaca, yes this is what I was saying
[15:46] <nessita> Chipaca, alex-abreu so is prefix anywhere in a given set of fiels
[15:46] <alex-abreu> :)
[15:46] <nessita> this means that a search for "foo"
[15:46] <nessita> will return hits for snaps with descriptions:
[15:46] <Chipaca> alex-abreu: no, you're saying "prefix", which means it starts with that
[15:47] <nessita> this amazing fooontastic snap
[15:47] <nessita> is prefix on words
[15:47] <Chipaca> oh! i didn't know that
[15:47] <Chipaca> that sucks, but ok
[15:48] <alex-abreu> Chipaca, well this is what seems to happen, curl 'https://search.apps.ubuntu.com/api/v1/snaps/search?name=a' -H 'X-Ubuntu-Series: 16' | jq .
[15:48] <Chipaca> alex-abreu: nessita: can we at least agree that the general search only searching for prefixes is an implementation detail of CPI, and it shouldn't really leak?
[15:48] <alex-abreu> Chipaca, yes
[15:48] <alex-abreu> so all is a prefix search
[15:49] <alex-abreu> you can only restrict the fields being searched
[15:49] <mup> PR snapd#2351 closed: tests: add set -e to the prepare ssh script <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2351>
[15:49] <alex-abreu> Chipaca, CPI?
[15:49] <Chipaca> (nessita: thank you; don't feel you need to carry on being part of the discussion unless you want to)
[15:50] <Chipaca> alex-abreu: search.apps.ubuntu.com
[15:50] <alex-abreu> Chipaca, ah, well ... it something that the user might care, and have a broader search so the distinction matters imo
[15:51] <Chipaca> alex-abreu: have a broader search?
[15:51] <alex-abreu> it might not be reflected atm in the 'snap' cmd
[15:51] <alex-abreu> Chipaca, yes, like search on names or search on description, ... the snap names might be very confusing sometimes, I dont know
[15:52] <alex-abreu> mvo, Chipaca (sorry for the crossed discussions) about the sections discoverability, ... I was thignking about a specific snap find --sections (as mvo said) that would specifically hit the appropriate store end point
[15:54] <Chipaca> --sections instead of --section to list them all?
[15:55] <Chipaca> that goes against using tab completion to discover them, fwiw
[15:55] <Chipaca> not sure how bad that is though
[15:56] <Chipaca> snap find --sec<tab><space><tab> isn't that much worse than snap find --sec<tab><tab>
[15:56] <Chipaca> on the other hand maybe it's worth having "snap sections"
[15:57] <Chipaca> I don't know
[15:57] <Chipaca> going back to find, if what you're proposing is that snapd know about, and the client api expose, all the search options that CPI provides, I'd say no
[15:57] <giminni> installed snappy ubuntu core for raspi3 still cannot login using a SSO account with dsa key
[15:57] <Chipaca> not without a clear use case
[15:58] <Chipaca> the more api we offer, the less we can adapt
[15:58] <Chipaca> giminni: is network working?
[15:58] <giminni> yes
[15:58] <giminni> it is reproducable
[15:59] <Chipaca> giminni: maybe we've disabled dsa keys? (i don't remember if that was a thing?)
[15:59] <alex-abreu> Chipaca, (sections) yes I am not sure how bad things are atm, ... and if people would complain, we might leave it for later
[15:59] <Chipaca> alex-abreu: right now in 2.18 things aren't good, but 2.19 should improve on it :-)
[15:59] <Chipaca> we were a little hasty in taking the completion thing as it stood
[16:00] <giminni> @chipaca: this is the only way to login, as explained in the first boot section
[16:00] <nothal> giminni: No such command!
[16:00] <alex-abreu> Chipaca, (find) the gist of what I am saying is that the snapd client api is a bit misleading, the prefix is ... knowing that all the searches are prefix based, ...
[16:00] <Chipaca> giminni: do you tried a key that isn't dsa?
[16:01] <Chipaca> alex-abreu: so renaming that option would be fine
[16:01] <Chipaca> alecu: or reworking the find options struct to make more sense also
[16:01] <alex-abreu> Chipaca, (find) I sam saying that from a consumer's perspective from snapweb, ... atm I can either use the Prefix and then I end up with a findone, of have a very broad (q=) based prefix search
[16:01] <Chipaca> gaah! stupid xchat completing whatever it wants to! sorry alecu
[16:01] <alex-abreu> ahah :)
[16:02] <alex-abreu> Chipaca, alecu gets more attention
[16:02] <Chipaca> alex-abreu: search is not very good, and it needs to get better, yes
[16:02] <nessita> Chipaca, ak, currently in the bi-weekly call so a little spotty
[16:02] <giminni> @chipaca: no I'll try an rsa key, atm I hack extrausers/etc/shadow and put a password for the user :-(
[16:02] <nothal> giminni: No such command!
[16:03] <not-alex-abreu> Chipaca: does that help?
[16:03]  * Chipaca hugs not-alex-abreu 
[16:03] <alex-abreu> not-alex-abreu, ahah !
[16:03]  * not-alex-abreu hugs Chipaca back
[16:03] <Chipaca> of course now it wants me to talk to alesage
[16:03] <alex-abreu> ahah ...
[16:03] <alex-abreu> Chipaca, prefix searches again !! :)
[16:04]  * alesage is not as handsome as alex-abreu 
[16:04] <Chipaca> alex-abreu: what I mean is: if the search results are bad for snapweb it's because the search results are bad
[16:04] <Chipaca> alex-abreu: that needs fixing on the server
[16:04] <Chipaca> alex-abreu: it most certainly does *not* want fixing on the client
[16:04] <Chipaca> and doubly-especially not on just one of the clients
[16:05] <alex-abreu> Chipaca, what I want is have a clear exposure to the 3 bits: prefix snap name search, prefix snap information (broad) search, exact search (through findOne atm)
[16:05] <Chipaca> alex-abreu: the only reason foo* ends up doing a search with name=foo is to support tab completion
[16:05] <alex-abreu> I have access to 2 atm, and Prefix is misleading as a name
[16:05] <alex-abreu> alesage, :))
[16:06]  * __chip__ is also "special"
[16:06] <__chip__> giminni: please report back on how it went
[16:07] <alex-abreu> Chipaca, from snapweb the searches are bad because we cannot search by snap name (which is what I think the snapweb search is about)
[16:07] <__chip__> you totally can search by snap name
[16:07] <alex-abreu> __chip__, yes but I mean by snap name *only*
[16:07] <__chip__> alex-abreu: I don't understand. In what sense can't you?
[16:08] <__chip__> that is explicitly supported
[16:08] <giminni> @chipaca: BTW ubuntu one explanation is for dsa AND rsa key anyway...
[16:08] <nothal> giminni: No such command!
[16:09] <alex-abreu> since in find (from snapd client) Prefix=false means q= search (which searches all over the place not only in the snap names) and Prefix=true searches for the exact snap name (special semantics of snapd)
[16:09] <__chip__> alex-abreu: yeah, I think it should work, but I don't know (and the people i'd ask are on holiday today)
[16:09] <alex-abreu> __chip__, ^
[16:09] <__chip__> alex-abreu: Prefix=true does *not* search for exact name
[16:09] <__chip__> alex-abreu: except with your branch, which breaks the feature
[16:10] <alex-abreu> __chip__, argh yes ... sorry wrong way to put it, ...
[16:11] <__chip__> alex-abreu: I'm a patient person. I'll wait.
[16:12] <__chip__> giminni: yeah, I think it should work, but I don't know (and the people i'd ask are on holiday today)
[16:13] <__chip__> alex-abreu: (if you read that as addressed to you and were confused, my apologies)
[16:13] <__chip__> I've gotten out of practice of tracking multiple threads on irc. Bad chipaca.
[16:14] <alex-abreu> Chipaca, the patient thing ?
[16:14] <Chipaca> alex-abreu: no, the "i think it should work" which was about dsa keys
[16:14] <alex-abreu> Chipaca, ah :)
[16:15] <Chipaca> alex-abreu: the "patient" was because you made an incorrect statement, which I corrected, and then you said it was the "wrong way to put it", meaning that you hadn't been wrong in your statement but expressed your still-correct idea in a suboptimal way. So I'm waiting for you to restate it.
[16:16] <Chipaca> but I have already spent an hour on this. Just sayin'
[16:17] <alex-abreu> Chipaca, not sure what you mean by that, am I wasting your time?
[16:17] <Chipaca> alex-abreu: spent, not wasted. I hope it's not wasted!
[16:18] <alex-abreu> Chipaca, I can send an email it would ease up the load ...
[16:18] <alex-abreu> Chipaca, I dont think so  but lets stop there since I think that the conversation is starting to be on the wasted side, I'll send an email
[16:18] <Chipaca> alex-abreu: rather: now that i have some idea of what you're thinking, maybe iterate on that branch?
[16:19] <Chipaca> otherwise, sure, email works
[16:21] <alex-abreu> yes a better way to keep a happy tone
[16:22] <giminni> @chipaca: with rsa it work! please correct https://login.ubuntu.com/ssh-keys text "Import new SSH key  Insert the contents of your public key (usually ~/.ssh/id_dsa.pub or ~/.ssh/id_rsa.pub)."
[16:22] <nothal> giminni: No such command!
[16:24] <Chipaca> jjohansen: do you know if logging in to core with dsa keys disabled for some reason?
[16:24]  * Chipaca remembered we have a non-US security person in the channel
[16:25] <kyrofa> didrocks, national holiday yesterday, so both jdstrand and myself were off. Did you manage to sort the configure hook issue?
[16:27] <didrocks> kyrofa: yeah! Well, there is a bug report on the denial creating by snapctl :)
[16:27] <didrocks> kyrofa: but at least, it's not blocking setting/getting the values
[16:27] <didrocks> thanks for checking back though :)
[16:28] <didrocks> if interesting, the bug is https://bugs.launchpad.net/bugs/1644573
[16:28] <mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
[16:32] <kyrofa> didrocks, ah, interesting. But no adverse effects of the denial?
[16:32] <giminni> @chipaca:better change doc temporarily at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ with "2. Import an SSH Key into your Ubuntu SSO account on this page"
[16:32] <nothal> giminni: No such command!
[16:32] <didrocks> kyrofa: no, the values are gettable (I didn't use set in the hook, but I don't think that would be different)
[16:33] <Chipaca> giminni: first I want to find out if this is supposed to happen, or if it's a bug we're all having, or if you're an especially unlucky snowflake
[16:33] <giminni> @chipaca: yes of course.
[16:33] <nothal> giminni: No such command!
[16:35] <Chipaca> giminni: but it does look like we won't know until next week. Hopefully using a rsa key works for you until then.
[16:35] <giminni> chipaca: FYI: I installed the latest rpi3 file from 3rd november and tried dsa-key login repeatedly. For now rsa works, thx for pointing to the right direction.
[16:58] <alex-abreu> Chipaca, email sent :)
[16:59] <mup> PR snapd#2361 opened: snap: fix try command when daemon linie is added <Created by stolowski> <https://github.com/snapcore/snapd/pull/2361>
[17:41] <fandango> hi all.
[17:43] <fandango> I have server with 2 ip adresses. Apache (snap, nextcloud) bind server on both IP. How i can set only one IP for snap ?
[17:43] <fandango> plz help me )
[17:58] <zyga> fandango: hey, I don't think you can do that just yet but we're working on something that will let you do this with network namespaces
[17:58] <zyga> fandango: let me look if there's a bug tracking that
[17:59] <zyga> fandango: please keep track of https://bugs.launchpad.net/snappy/+bug/1624675
[17:59] <mup> Bug #1624675: Please add network-namespace interface <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1624675>
[18:00] <zyga> fandango: with this feature you will be able to create arbitrary network settings for each snap
[18:02] <fandango> ok, thanks
[18:04] <fandango> Can i unpack snap stored in /var/lib/snapd/snaps  - modify file, and pack  :) ?
[18:06] <zyga> fandango: yes
[18:06] <zyga> fandango: though they will no longer validate and match your assertions
[18:06] <zyga> fandango: you will have to install a modified snap with --dangerous