[00:13] <mwhudson> src/gopkg.in/mgo.v2/bson/json.go:320:7: constant 9007199254740992 overflows int
[00:13] <mwhudson> grumble
[00:15] <mwhudson> also the arch=all build failed
[00:44] <mup> PR snapcraft#1851 opened: storeapi: add docstrings to _client <Created by daniellimws> <https://github.com/snapcore/snapcraft/pull/1851>
[05:50] <mup> PR snapcraft#1835 closed: Update _desktop.py <codein> <Created by Tanesh1701> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1835>
[06:08] <mborzecki> morning
[07:40] <zyga> good morning!
[07:41]  * zyga feels much better today, maybe the weather is changing
[07:59] <mborzecki> zyga: morning
[07:59] <zyga> o/
[07:59] <kalikiana> morning
[08:05] <zyga> hey kalikiana, mvo
[08:11] <mvo> hey zyga - good morning
[08:17] <mborzecki> mvo: morning
[08:18] <mborzecki> finally openend a PR with diff output in go-check: https://github.com/go-check/check/pull/99
[08:18] <mup> PR go-check/check#99: many: return diff of stringified value when Equals/DeepEquals check fails <Created by bboozzoo> <https://github.com/go-check/check/pull/99>
[08:19] <zyga> ohhh
[08:19]  * zyga hugs mborzecki!
[08:20] <mvo> mborzecki: hey, good morning! this looks great
[08:31]  * zyga goes to reboot 
[09:10] <mvo> mborzecki: curious, did you investigate using github.com/kr/pretty ? or is that inferior/unsuited for pr (iirc we talked about this briefly)
[09:22] <mborzecki> mvo: i tried it in hope i could drop difflib, but the Diff() that's in kr/pretty is not what i wanted
[09:28] <mvo> mborzecki: thanks, was just curious
[09:31] <pedronis> mvo: I'm getting errors preparing Fedora 26 all the time but the log is not clear what is failing
[09:31] <pedronis> https://travis-ci.org/snapcore/snapd/builds/325038662?utm_source=github_status&utm_medium=notification
[09:33] <pedronis> it seems to fail installing our own built packages, but there's no error in the log
[09:35] <mborzecki> mvo: example output http://paste.ubuntu.com/26324546/ with this code: http://paste.ubuntu.com/26324547/
[09:36] <pedronis> mvo: master is red in the same way
[09:36] <pedronis> did we break something on fedora ?
[09:37] <pedronis> mmh, it's fedora preparing just taking too long?
[09:38] <mvo> pedronis: I don't know, I have not checked yet but noticed as well that something is not right
[09:43] <pedronis> no, it's failing after 239s that should be below the timeouts
[09:44] <pedronis> we already have 25 and suse on manual :(
[09:47]  * kalikiana need..more..coffee
[10:01] <mvo> pedronis: I run spread against fedora now with -debug maybe that gives me a clue
[10:03] <pedronis> ok, I'm turning it into manual in my branch for now but will make a PR that puts it back
[10:11] <Chipaca> morning! is there something wrong with fedora 26 in linode? getting failed prepares
[10:12] <mvo> Chipaca: yes, but its unclear what
[10:12] <Chipaca> :-(
[10:12] <mvo> Chipaca: it seems like dnf -q ... fails but it does not tell why
[10:12] <mvo> (maybe because of the -q ?)
[10:12] <Chipaca> i'll do a manual run and see
[10:13] <mvo> Chipaca: I am in one right now, what I see is "dnf -q -y --refresh install glibc-static" apparently failed
[10:13] <Chipaca> ah ok
[10:14] <Chipaca> mvo: network/repo issues?
[10:14] <mvo> Chipaca: I repeated the commmand manually and it worked :/
[10:15] <mvo> Chipaca: also dnf history will not show me unsuccessful runs so I don't know why the previous one failed
[10:15] <mvo> Chipaca: I guess we need to replace "dnf -q" with "quiet dnf" to get useful debug output
[10:16] <Chipaca> mvo: +1
[10:23] <mvo> it might be (wild guess) that the fedora repo is a bit overloaded due to the extra security updates pushing out for meltdown/spectre
[10:24] <mup> PR snapd#4444 opened: tests: use "quiet" helper instead of "dnf -q" to get errors on failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/4444>
[10:32] <mup> PR snapd#4392 closed: many: refresh with appropriate creds <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4392>
[10:32] <Chipaca> well that doesn't tell me much
[10:33] <pedronis> Chipaca: ?
[10:33] <Chipaca> Error: Failed to synchronize cache for repo 'updates'
[10:33] <Chipaca> is the entirety of dnf's output
[10:33] <pedronis> we have seen it before though
[10:33] <pedronis> it's a clasic
[10:33] <pedronis> classic
[10:38] <zyga> darn, is there no way to have a mock variable for a recursive function?
[10:38] <zyga> var func := impl
[10:38] <zyga> and then call func inside impl (indirectly here)
[10:38] <mvo> Chipaca: well, its much better than seeing nothing :)
[10:38] <Chipaca> mvo: yeah
[10:39] <Chipaca> zyga: ?
[10:39] <Chipaca> mvo: not much >> nothing
[10:39] <pedronis> you need a wrapper
[10:39] <zyga> mvo: guess it's one more time to jump into OFTC
[10:39] <mvo> Chipaca: and something that we can google for
[10:39] <mvo> zyga: I'm in oftc, how does that help ;)?
[10:40] <Chipaca> mvo: best answer i found so far is that we need to do 'dnf clean all' at the start
[10:40] <mvo> meh
[10:40] <Chipaca> mvo: i'm going to test that
[10:40] <zyga> mvo: go to #linode and complain
[10:40] <zyga> mvo: that their repo is periodically broken
[10:40] <mvo> zyga: oh? it could be their mirror? fwiw, it seems like it is not always broken, I just have a run that seems to be doing fine
[10:41] <zyga> yes, it is their internal mirror
[10:41] <zyga> as neal suspected is is probably failing while it syncs to the outer mirror
[10:41] <zyga> because it is removing files before, not after rsync is done
[10:41] <zyga> so you can see partially broken mirror at that time
[10:42] <mvo> maybe time to update their mirror script then?
[10:42] <mvo> ubuntu fixed this a long time ago (to be fair it  was a problem for a long time too)
[10:42] <pedronis> zyga: you are hitting an initialisation loop
[10:43] <zyga> pedronis: yes
[10:43] <zyga> ../../../go/src/github.com/snapcore/snapd/cmd/snap-update-ns/change.go:85: initialization loop:
[10:43] <zyga> ... bunch of calls
[10:43] <pedronis> I recommend just being naive
[10:43] <pedronis> have a impl that calls implRec that calls itself or something
[10:46] <pedronis> unless you really need the partial mocking, in which a func init() might help
[10:46] <pedronis> *which case
[10:48]  * zyga experiments
[10:48] <Chipaca> mvo: part of the problem is that we do a dnf call per package, and any one of them can fail this way
[10:48] <Chipaca> mvo: i'll see if i can resurface my branch that avoids this
[10:48] <mvo> Chipaca: ok
[10:49] <pedronis> zyga: these works:  https://play.golang.org/p/uihgox8C_RU
[10:50] <zyga> pedronis: thank you!
[10:52] <zyga> yep, that works for me
[11:03] <mup> PR snapd#4445 opened: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>
[11:10] <BjornT_> i get an error when trying to install the maas snap in a bionic container. any ideas on what's wrong? https://paste.ubuntu.com/26325056/
[11:11] <zyga> BjornT_: any denials?
[11:13] <Chipaca> mvo: zyga: do you guys push core to staging, or is that somebody else?
[11:14] <zyga> no idea about staging
[11:14] <zyga> (staging store I assume)
[11:15] <mvo> Chipaca: staging store ? I'm not familiar with the workflow, cachio is
[11:16] <Chipaca> ah
[11:17] <Chipaca> Facu: ^ so … the person that could do it is still on holidays i think
[11:17] <Facu> Chipaca, ack, thanks
[11:17] <Chipaca> Facu: but when he gets back, let's make updating staging part of the release workflow
[11:17] <Chipaca> Facu: (remind me?)
[11:17] <Chipaca> Facu: (or talk to him! i ain't a manager :-p )
[11:18] <Facu> Chipaca, :)
[11:19] <BjornT_> zyga: not that i can see. this is 'journalctl -xe': https://paste.ubuntu.com/26325079/
[11:19] <mvo> Chipaca: fun! pr#4444
[11:19] <mvo> (its just a number but still fun)
[11:21] <pedronis> mvo: you probably want to merge master into pr#4444 and remove the manual I just added to spread.yaml
[11:23] <Chipaca> mvo: #4445 is more fun :-p
[11:23] <mup> PR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>
[11:25] <Chipaca> mvo: why isnt 4445 even allocating a fedora? :-/
[11:26] <mvo> Chipaca: yeah, was just reviewing this one
[11:28] <Chipaca> mvo: the review of that one gets a lot easier if you add ?w=1 to the url
[11:28] <Chipaca> ('ignore whitespace')
[11:33] <zyga> BjornT_: that doesn't ring any bells, sorry :/
[11:36] <pedronis> Chipaca: I turned fedora to manual in my PR to be able to land it fwiw
[11:37] <mup> PR snapcraft#1811 closed: Add type hints cli/assertions.py module <codein> <Created by m4sk1n> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1811>
[11:37] <mup> PR snapcraft#1851 closed: storeapi: add docstrings to _client <codein> <Created by daniellimws> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1851>
[11:37] <Chipaca> pedronis: o\
[11:37] <Chipaca> pedronis: that would explain the lack of fedora in 4445 :-)
[11:37] <pedronis> Chipaca: you and mvo probably need to turn it on again on your PRs
[11:37]  * pedronis lunch
[11:38] <mvo> pedronis: ohhh, ok
[11:47] <mup> Bug #1741463 opened: Failure to install maas snap in a bionic container <Snappy:New> <https://launchpad.net/bugs/1741463>
[11:48] <BjornT_> zyga: ok, i filed a bug about it: ^^^
[11:49] <mup> PR snapd#4446 opened: snap: use stdout instead of stderr for "fetching" message <Created by mvo5> <https://github.com/snapcore/snapd/pull/4446>
[11:50] <zyga> BjornT_: thanks
[11:52] <ackk> hi, does anyone know what could be causing this error: https://paste.ubuntu.com/ ?
[11:52] <ackk> err
[11:52] <ackk> https://paste.ubuntu.com/26325221/
[11:52] <Chipaca> ackk: #1741463
[11:52] <mup> Bug #1741463: Failure to install maas snap in a bionic container <Snappy:New> <https://launchpad.net/bugs/1741463>
[11:53] <ackk> Chipaca, this is a different error, though?
[11:54] <Chipaca> ackk: ah, perhaps
[11:56] <ackk> this is in a bionic container, and the snap was built on bionic
[11:56] <Chipaca> ackk: that error looks like the maas snap has been built on the wrong libc
[11:56] <Chipaca> ackk: do not build snaps on non-xenial unless you really know why you're doing it
[11:56] <Chipaca> ackk: your snap is now trying to use bionic libc, which isn't available to it
[11:56] <Chipaca> bah, not sure if this is your snap -- the maas snap, i mean
[11:57] <ackk> Chipaca, isn't there a bionic-based core image?
[11:57] <Chipaca> ackk: no
[11:57] <Chipaca> ackk: there will be, once 18.04 is out
[11:58] <ackk> Chipaca, not even a daily build?
[11:58] <zyga> ackk: no, because lots of stuff is missing, we want to make some things different, not just refreshed
[11:59] <zyga> ackk: I think you will see 18.04 base snaps sooner but not meant for booting
[11:59] <zyga> in fact mvo did some work on that in December
[12:00] <Chipaca> ackk: when we get it working it'll be a Big Deal and announced in all the usual ways
[12:00] <ackk> I see
[12:00] <Chipaca> ackk: you're welcome to work on a 18.04 base if you want to thuogh
[12:00] <ackk> Chipaca, how do I install it?
[12:00] <Chipaca> ackk: sorry, by 'work on' i meant 'create one'
[12:00] <ackk> ah :)
[12:01] <Chipaca> ackk: why do you need 18.04 libc?
[12:01] <Chipaca> ackk: doesn't maas work on pre-18.04?
[12:01] <ackk> Chipaca, yes, but master just switched to bionic, so we're now building stuff on bionic
[12:02] <zyga> Chipaca: there is a very premature one
[12:02] <Chipaca> ackk: snapd does not yet support that; I'd disrecommend doing so until we do
[12:02] <zyga> snapcore/base-18 AFAIR
[12:02] <zyga> but super early stuff
[12:03] <Chipaca> zyga: not a public snap fwiw
[12:03] <zyga> public just not done
[12:03] <zyga> it's on github ;)
[12:03] <Chipaca> zyga: ah :-)
[12:03] <zyga> https://github.com/snapcore/base-18
[12:03] <Chipaca> right
[12:04] <Chipaca> still, not supported, and i wouldn't recommend it at all
[12:04] <zyga> yes
[12:04] <zyga> agreed
[12:04] <Chipaca> unless you really want to work on _that_ and not the thing you're working on
[12:04] <ackk> ok, thanks for the info
[12:04] <zyga> totally
[12:04] <Chipaca> if it were easy it'd be done :-D
[12:05] <mvo> ackk: we have some code for base-18, if you don't mind that things break I can push what we have to edge
[12:05] <mvo> ackk: is our WIP branch https://github.com/snapcore/base-18
[12:05] <mvo> aha, zyga said it already, sorry for the noise
[12:15] <ackk> mvo, so, if you push that base to edge, installing a bionic-built snap should work, right?
[12:15] <zyga> well
[12:15] <zyga> how do you build that bionic-based snap?
[12:15] <zyga> snapcraft probably cant because there's no real base 18 yet
[12:15] <zyga> so ... ?
[12:16] <ackk> it does build
[12:16] <zyga> on bionic itself
[12:16] <ackk> yes
[12:16] <zyga> but then it looks at the core snap to resolve libs and whatnot
[12:16] <zyga> and there's no base 18 to do that
[12:16] <zyga> so something is wrong at the build stage already
[12:18] <ackk> zyga, where does it look for the core snap?
[12:18] <zyga> ackk: to resolve libs and dependencies
[12:18] <zyga> ackk: kalikiana would know more
[12:18] <ackk> zyga, no I mean where does it look it up
[12:18] <ackk> locally or does it download it ?
[12:19] <zyga> ackk: it downloads core snap AFAIK
[12:19] <zyga> but I really don't know
[12:26] <mvo> ackk: you will need to add "base: base-18" in your snap and install it manually beforehand. you can try that now via "https://code.launchpad.net/~mvo/+snap/base-18/+build/113575/+files/base-18_very-unstable_amd64.snap"
[12:27] <ackk> ah nice
[12:27] <ackk> thanks
[12:27] <mvo> ackk: my hints cover the snapd side, snapcraft I'm not sure, but if it already builds inside a bionic env thats probably "fine"(ish) for now
[12:37] <ackk> zyga, fwiw it seems snapcraft doesn't really look the base snap up. I had typo'd the base: entry, but the snap built anyway
[12:37] <kalikiana> ackk: Snapcraft looks at /snap/core/current
[12:37] <kalikiana> And it must be installed
[12:38] <kalikiana> ackk: are you building a classic snap?
[12:38] <ackk> kalikiana, but it doesn't fail if it isn't?
[12:38] <ackk> kalikiana, no
[12:38] <zyga> kalikiana: base-18 based snap
[12:38] <ackk> so, the first time I built it, I didn't have the core snap installed
[12:38] <ackk> still, the build succeded
[12:39] <ackk> actually, that's not true
[12:39] <ackk> it was installed
[12:39] <ackk> $ sudo snap try --devmode build/dev-snap/prime/
[12:39] <ackk> error: cannot perform the following tasks:
[12:39] <ackk> - Mount snap "maas" (unset) (cannot find required base "base-18")
[12:39] <ackk> kalikiana, ^ with base: base-18
[12:39] <ackk> (and the base installed)
[12:40] <ackk> https://paste.ubuntu.com/26325400/ for reference
[12:41] <ackk> https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic is my snapcraft.yaml
[12:44] <kalikiana> ackk: I'm afraid I don't know if this is expected to work. There's no code (yet) handling the base as far as I'm aware
[12:45] <kalikiana> That is, in Snapcraft - `snap try` is not part of Snapcraft
[12:45] <ackk> right, I guess that's more a question for mvo :)
[12:45] <Chipaca> ackk: that's weird, bases work for sure
[12:46] <ackk> Chipaca, do they require any flag at installation? I justwent with snap install --dangerous
[12:48] <Chipaca> ackk: that base isn't a base! that's the problem
[12:48] <Chipaca> ackk: note it doesn't say 'base' in the Notes column
[12:48] <Chipaca> ackk: remove it, make sure it's type:base, try again
[12:49] <Chipaca> ackk: you can try bases, also
[12:50] <ackk> Chipaca, so that's a problem with the base build?
[12:51] <ackk> mvo, ^
[12:51] <ackk> Chipaca, wdym "you can try bases, also"
[12:52] <Chipaca> ackk: 'snap try' works for bases
[12:52] <Chipaca> ackk: so you can unsquash the .snap, tweak it, and don't need to repack it
[12:52] <ackk> oh
[12:52] <ackk> ok
[12:52] <Chipaca> ackk: or you can mount it by hand somewhere, bind mount a tweaked snap.yaml, and try it there, for even less io work
[12:53] <Chipaca> but that's getting weird :-)
[12:53] <ackk> frankensnap
[12:55] <zyga> Chipaca: snap-confine _may_ have issues with base snaps that are in try mode
[12:55] <zyga> Chipaca: especially the new invalidate stale base snap code
[12:55] <Chipaca> zyga: this worked for me at some point fwiw
[12:55] <Chipaca> zyga: you broke my netscape snap /o\
[12:55] <zyga> yes, it's just that specific aspect that may fail
[12:56] <Chipaca> zyga: (jk, i broke it myself before you got to it)
[12:56] <zyga> I blame weather, it's still not good IMO
[12:57] <ackk> Chipaca, would it be possible to kick another build of the base with the metadata fixed?
[13:01] <mvo> ackk: oh, so you ahve base-18 installed and it still complains? hmm, what snapd version
[13:01] <ackk> mvo, 2.30 (bionic)
[13:01] <mvo> ackk: strange, I have a look after my meeting (in a meeting right now)
[13:03] <Chipaca> pedronis: http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html might be relevant
[13:24] <ackk> mvo, ok got a different error now, after changing the base snap adding "type: base": https://paste.ubuntu.com/26325613/
[13:26]  * kalikiana going to head out for lunch
[13:30] <mvo> ackk: aha, right. iirc there is a problem with the snap build when if it is set to type: base (sorry that I did not remember that earlier)
[13:31] <ogra_> slangasek, i have a slight ubuntu-image problem ... trying to build a multi-volume image like https://paste.ubuntu.com/26325509/ (u-boot lives in /dev/mtd on that device while the rootfs is on mmc so i need two flashable img files), i end up without a writable partition
[13:31] <Chipaca> mvo: #4394 might be an easy one for you to re-review (and it's green, has one other +1, and is blocking a followup)
[13:31] <mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
[13:31] <mvo> ackk: hm, thats an interessting error, out of curiosity does it help if you add a "type: app" to the mass snap ?
[13:32] <mvo> Chipaca: oh, indeed, let me look at it again, iirc its long
[13:32] <Chipaca> mvo: +729-1
[13:32] <Chipaca> the followup is shorter but hairier
[13:33] <ogra_> slangasek, is there any way to tell u-image where to put writable (definiing it in the structure just gives me an empty ext4 partition, the rootfs doesnt get copied)
[13:33] <Chipaca> mvo: #4445's fedora thing just passed (the test overall failed because of a timeout downloading core...)
[13:33] <mup> PR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>
[13:39] <mup> PR snapd#4447 opened: tests: fix test whoami, share successful_login.exp <Created by pedronis> <https://github.com/snapcore/snapd/pull/4447>
[13:39] <pedronis> Chipaca: what you asked in the other PR  ^
[13:42] <mvo> Chipaca: nice
[13:42] <mvo> Chipaca: well, not that it fails but the fact that fedora didn't
[13:44]  * Chipaca hugs pedronis 
[13:45] <Chipaca> mvo: if 4445 passes and we agree to land it, i'll merge it into 4442 and add a rename from advice-command to advise-command to it
[13:45] <mvo> Chipaca: +1
[13:48] <mup> PR core#68 opened: hooks: fix shellcheck complains <Created by mvo5> <https://github.com/snapcore/core/pull/68>
[13:51] <mborzecki> zyga: blog-post-january :)
[13:51] <zyga> hmm?
[13:52] <mvo> resolutions for the new year ;)
[13:52] <mborzecki> looking at your blog, you've published something on Jan 02, 03, 04 :)
[13:52] <zyga> mborzecki: ah, yes, :)
[13:52] <mborzecki> zyga-daily :)
[13:52] <zyga> mvo: just feeling bad about being useless this week, at least I can blog
[13:53] <mvo> zyga: just kidding, I think thats great
[13:53] <Chipaca> - Fetch and check assertions for snap "test-snapd-tools" (5) (Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw?max-format=2: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers))
[13:53] <Chipaca> :-(
[13:53] <mborzecki> agree with mvo, very nice read
[13:54] <zyga> thanks, I'm trying to find the right balance of length/tech that can be casual to read yet useful
[13:54] <ackk> mvo, lemme try
[13:58] <mup> PR core#69 opened: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <https://github.com/snapcore/core/pull/69>
[13:58] <mvo> Chipaca: for you -^ :)
[14:01] <ackk> mvo, no difference
[14:03] <Chipaca> mvo: is that the right way? what creates command_not_found_handler given /usr/lib/command-not-found?
[14:03] <mvo> ackk: can you `snap remove maas` (if it is already installed?)
[14:03] <ackk> mvo, it's not
[14:04] <mvo> ackk: ok, let me look at the code
[14:04] <ackk> although there's a leftover symlink in /var/lib/snapd/snaps/maas_x1.snap
[14:04] <ackk> (this is something I noticed before, if snap try fails
[14:04] <mvo> Chipaca: there is /etc/bash.bashrc which creates this
[14:04] <mvo> ackk: oh, does it help if you remove that (wild guess)
[14:04] <mvo> Chipaca: i.e. its part of the default bash in ubuntu
[14:04] <ackk> mvo, no, I mean I remove it everytime otherwise snap try doesn't work the next time
[14:04] <ackk> but then it still fails
[14:05] <ackk> I think that link should be cleaned up on failures
[14:05] <mvo> Chipaca: so we could do it differently and modify /etc/bash.bashrc to call snap advise-command directly
[14:05] <Chipaca> mvo: this seems fine to me
[14:05] <mvo> ackk: yeah, sounds like something we want to fix, could you write a bugrport or forum post with reproduce instructions please?
[14:06] <mvo> ackk: I look at the code now, could you pastebin your snapcraft.yaml (or /msg it to me if its private)
[14:07] <ackk> mvo, https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic
[14:08] <ackk> mvo, bugs go in LP, right?
[14:08] <mvo> ackk: yeah
[14:08]  * mborzecki is off to pick up the kids
[14:10] <ackk> mvo, https://bugs.launchpad.net/snappy/+bug/1741486
[14:10] <mup> Bug #1741486: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>
[14:12] <mup> Bug #1741486 opened: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>
[14:12]  * zyga-ubuntu tries to unfreeze his desktop
[14:14] <mvo> ackk: ta
[14:17] <BjornT_> zyga-ubuntu: do you think you could give bug 1741463 some priority. turns out it happens in xenial containers as well, so a bit more severe than i thought
[14:17] <mup> Bug #1741463: Failure to install maas snap in a container <Snappy:New> <https://launchpad.net/bugs/1741463>
[14:17] <mvo> ackk: hm, if you `grep "type:" build/dev-snap/prime/meta/snap.yaml - does that show "type: app"? the only thing I can see is that "type" is missing (which is a snap try bug that it does not DTRT if it is missing, I'm just curious about if this maybe a workaround for you)
[14:18]  * mvo tries to build the maas snap to `snap try` it
[14:18] <ackk> mvo, ah yeah I haven't committed that, I tried locally
[14:19] <mvo> ackk: thats fine
[14:19] <mvo> ackk: I mean, did it propagate into prime/ (the type: app) setting?
[14:19]  * ackk checks
[14:19] <ackk> $ grep type build/dev-snap/prime/meta/snap.yaml
[14:19] <ackk> type: app
[14:19] <ackk> mvo, ^
[14:20] <ackk> I have seen that error before but I can't remember what was missing
[14:20] <mup> PR snapd#4447 closed: tests: fix test whoami, share successful_login.exp <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4447>
[14:21] <ackk> mvo, btw, can you add "type: base" in base-18?
[14:22] <mvo> ackk: I'm not sure I can without breaking the LP builds
[14:22] <mvo> ackk: but I will try
[14:22] <ackk> oh
[14:22] <ackk> ok
[14:22] <zyga-ubuntu> BjornT_: what was the host of the LXD container?
[14:23] <mvo> ackk: I am running `snapcraft` now for the maas snap checkout. but it seems like it is taking a long time to pull all the deps
[14:23] <ackk> yeah it does
[14:24] <jdstrand> niemeyer: hi! I noticed when looking at https://forum.snapcraft.io/t/fonts-fail-to-load-when-desktop-plug-added/3414/3 that if I click '...' I no longer see a checkbox for marking it as a solution. I can normally do this. Is this intentional?
[14:24] <zyga-ubuntu> jdstrand: note, gustavo is back next week
[14:25] <jdstrand> niemeyer: oh, I forgot you were on holiday. answer next week in backscroll and I'll see it at some point
[14:25] <jdstrand> zyga-ubuntu: thanks
[14:25] <BjornT_> zyga-ubuntu: the host is xenial
[14:28] <zyga-ubuntu> BjornT_: thanks, I can try on xenial vm tomorrow/monday
[14:29] <ackk> mvo, so, if I make my bionic container privileged I get a different error:
[14:29] <ackk> - Run configure hook of "maas" snap if present (run hook "configure": cannot perform operation: mount --rbind /snap /snap: Permission denied
[14:29] <ackk> in xenial I used to have security.privileged=true
[14:29] <BjornT_> zyga-ubuntu: cool, thanks
[14:33] <zyga-ubuntu> ackk: privileged containers == borken snapd
[14:33] <zyga-ubuntu> totally unsuportable configuration
[14:33] <ackk> it did work in xenial
[14:33] <ackk> I mean, with xenial containers
[14:33] <ackk> i've been using it for months :)
[14:33] <mvo> ackk: the remount might be interessting for zyga
[14:33] <mvo> heh
[14:33] <mvo> he replied already
[14:33] <zyga-ubuntu> ackk: by accident
[14:34] <zyga-ubuntu> ackk: in such container the host and guest share apparmor namespace
[14:34] <zyga-ubuntu> ackk: and nothing works sensibly
[14:34] <zyga-ubuntu> ackk: what-reloaded-last takes control
[14:34] <zyga-ubuntu> ackk: it's not supported but not actively detected by snapd
[14:34] <ackk> ok
[14:34] <ackk> I'm back to not-privileged
[14:34] <zyga-ubuntu> ackk: it cannot ever work reliably, in the case where host==guest it can also break in some cases when packages don't match exactly
[14:45] <mborzecki> wrapping it up for today, have a great weekend
[14:45] <kalikiana> re
[14:46] <mvo> ackk: when I run "snapcraft" from the git pull I get https://paste.ubuntu.com/26326002/ and I don't have a dir for trying AFAICT
[14:47] <ackk> mvo, which branch are you using?
[14:47] <ackk> mvo, the snap-bionic one?
[14:51] <mvo> ackk: ah, maybe that is the problem, I might be on master, let me check
[14:51] <ackk> mvo, that branch should fix the issue
[14:51] <ackk> mvo, right, checkout snap-bionic :)
[14:52] <mvo> ackk: *cough* thanks
[14:57] <mvo> ackk: thanks, I can reproduce the failure (not exactly the same though) - I need to think a bit but this may well be something that requires a couple of days to fix as the base-18 work is still very much WIP
[14:57] <ackk> mvo, cool, thanks
[14:57] <ackk> mvo, fwiw I get the same error with both snap try and snap install
[14:58] <mvo> ackk: (i.e. the issue is that no snapd/snap/snapctl/snap-exec is available inside base-18 currently, i.e. we need to mount that from snap-confine into the right places yet iirc)
[14:58] <ackk> mvo, I see
[14:59]  * mvo ponders a bit
[14:59] <zyga-ubuntu> mvo: good observation, I was thinking that we need a version of the inside-ns tools that are linked statically and available
[15:00] <zyga-ubuntu> mvo: I would not reuse the regular ones as there's no guartee those would work (snap-confine, snap-update-ns)
[15:00] <zyga-ubuntu> (snapctl perhaps)
[15:00] <mvo> zyga-ubuntu: +1 on that
[15:00] <zyga-ubuntu> mvo: alternatively a new novel way of using them from within the core snap ns
[15:00] <zyga-ubuntu> mvo: but this is problematic
[15:00] <mvo> Chipaca: btw, do you have an opinion on lp 1737197 ? you worked in this area recently
[15:00] <zyga-ubuntu> mvo: (because /run/snapd/ns)
[15:01] <zyga-ubuntu> so, my destkop is in weird state
[15:01] <zyga-ubuntu> all the software works
[15:01] <zyga-ubuntu> GUI updates
[15:01] <zyga-ubuntu> mouse moves
[15:01] <zyga-ubuntu> but, input is broken, nothing gets passed to apps
[15:01] <mvo> zyga-ubuntu: right, we should brainstorm about this monday
[15:01] <zyga-ubuntu> mvo: sounds good
[15:01] <mvo> zyga-ubuntu: sounds like something is grabing your input ?
[15:01] <zyga-ubuntu> I can ssh in and despite some high ram usage (not even swapping though)
[15:01] <zyga-ubuntu> nothing seems wrong
[15:01] <zyga-ubuntu> maybe gnome-shell
[15:02] <zyga-ubuntu> I'm reluctant to kill it
[15:02] <mvo> zyga-ubuntu: that causes havoc :)
[15:02] <zyga-ubuntu> yeah
[15:02] <zyga-ubuntu> I'll keep it asis for now, let some software running finish
[15:02] <mvo> zyga-ubuntu: in the old days, ctl-alt-f2 and then back to X helped with these
[15:02] <zyga-ubuntu> I did that, I can go back to gnome login manager
[15:02] <zyga-ubuntu> and login as myself
[15:02] <zyga-ubuntu> but then it is stuck again
[15:02] <zyga-ubuntu> (weird, right?)
[15:03] <zyga-ubuntu> (by login I mean unlock the same session)
[15:03]  * mvo nods
[15:04] <Chipaca> zyga-ubuntu: could it be the thing where your input is grabbed by the console?
[15:05] <Chipaca> or was that the other way around
[15:05] <Chipaca> something about ^C in the terminal killing the session maybe
[15:05] <zyga-ubuntu> Chipaca: console as in other vt?
[15:05] <zyga-ubuntu> I only run irssi, vim and a few man pages there
[15:05] <Chipaca> yes
[15:05] <zyga-ubuntu> and no other vt is used
[15:05] <Chipaca> https://forum.snapcraft.io/t/ctrl-c-in-terminal-logs-out-of-current-gdm-session/2162/21
[15:06] <zyga-ubuntu> I think that was fixed a while ago (by now)
[15:06] <zyga-ubuntu> but weirdly, nothing has focus
[15:06] <zyga-ubuntu> and I cannot click to focus
[15:06] <zyga-ubuntu> or alt-tab to focus
[15:10] <ackk> mvo, FTR I get the same error if "snap try" a maas snap built on xenial
[15:10] <ackk> (which of course doens't use base-18)
[15:11] <mvo> ackk: hm, hm, I wonder if something funny happend to your /var/lib/snapd/state.json - can you install anything or is it realy just maas that is unhappy?
[15:11] <ackk> mvo, I do have other snaps installed
[15:11] <mvo> ackk: (careful with sharing the content of that file, it contains e.g. macaaron data which is sensitive)
[15:11] <mvo> ackk: right, I mean, can you install other new snaps?
[15:11] <ackk> trying now
[15:12] <ackk> snap install hello-world worked
[15:12] <mvo> ackk: ok, so its not that
[15:14] <ackk> mvo, no, also I can install the stable maas snap in bionic
[15:14] <ackk> (from the store)
[15:17] <Chipaca> mvo: answered in 1737197
[15:20] <mvo> Chipaca: ta
[15:20]  * mvo steps out for some minutes
[15:33] <ackk> mvo, not sure if I mentioned it before, but I'm doing all of this in a bionic container
[15:52]  * Chipaca is >this< close to giving up on this fedora malarkey
[15:53] <nacc> Chipaca: good use of malarkey
[15:57] <kalikiana> :-D
[16:16] <ackk> what's the proper way of fixing a failed snap removal inside a container?
[16:22] <mup> PR snapd#4446 closed: snap: use stdout instead of stderr for "fetching" message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4446>
[16:24] <mup> PR snapd#4435 closed: snap: do not leak internal network errors to the user <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4435>
[16:26] <mup> PR snapd#4434 closed: tests/main/confinement-classic: enable the test on Fedora <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4434>
[16:28] <mvo> jdstrand: not sure how busy you are (super busy I guess) - if there is a spare cycle, a review for pr 4073 would be nice, only the security aspects of course. it should address the issues you outlined
[16:28] <mup> PR #4073: snap: add io.snapcraft.Settings to `snap userd` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4073>
[16:29] <ackk> mvo, fwiw https://paste.ubuntu.com/26326503/ is what I see from snapd debug
[16:34] <mvo> ackk: thanks, interessting. it looks like the type="" is just a secondary error after "2018/01/05 16:26:21.967261 task.go:303: DEBUG: 2018-01-05T16:26:21Z ERROR cannot find installed snap "maas" at revision x1" but this one is also puzzling
[16:36] <ackk> right
[16:37] <ackk> mvo, could it have to do with --devmode?
[16:38] <ackk> ISTR hitting this error before, but I can't remember how I got past it
[16:40] <mvo> ackk: not sure, sorry, I setup a proper bionic env now to test fully (so far I only build the snap under bionic but not tested it there)
[16:55] <ackk> kalikiana, if I don't specify a base: in my snap, but include all shared libs that binaries need manually, will snapcraft still look up stuff from the core snap?
[16:56] <ackk> kalikiana, (just wondering if I could not use a base and include everything so that the snap then works on bionic)
[16:56] <slangasek> ogra_: hum, it's certainly meant to be possible to define the location of writable in a multi-volume image, and have it correctly populated; so if you are seeing something different, it's perhaps a bug in un-exercised code; can you reach out to sil2100?
[16:56] <ogra_> slangasek, yeah, i would have pinged him first but he seemed to be off
[16:58] <ogra_> slangasek, oh, fun ... looking at gadget-yml.rst in the u-image source has:
[16:58] <ogra_> XXX: how do we know which volume the writable partition is supposed to be
[16:58] <ogra_> placed on?
[16:58] <ogra_> :P
[16:58] <ogra_> so obviously a missing feature
[16:59] <ogra_> i guess we need something like a "has-writable: true" option for the volumes that triggers writable to be created there
[17:00] <kalikiana> ackk: Not quite sure I grok the question. If you include all the libs that won't change how Snapcraft operates... but there will be no need to use anything from the core snap
[17:01] <slangasek> ogra_: uh, the design that we documented is that you spell out in your yaml which image gets the writable partition
[17:01] <ogra_> slangasek, yeah, seems that lacks implementation yet
[17:02] <ackk> kalikiana, I'm wondering what is snapcraft looking at the core snap for
[17:02] <ogra_> i suspect nobody needed that yet
[17:04] <kalikiana> ackk: For classic snaps it needs to link against what's in core
[17:04] <ackk> kalikiana, this is not a classic snap
[17:05] <slangasek> ogra_: we certainly don't need any 'has-writable: true'.  what does your yaml look like?  Did you set role: system-data?
[17:06] <ogra_> slangasek, ah ... no, i didnt ... this (with customer info removed) is my yaml https://paste.ubuntu.com/26325509/
[17:06] <slangasek> ogra_: 'role: system-data', documented in https://forum.snapcraft.io/t/the-gadget-snap/696
[17:06] <ogra_> i'll try with role
[17:07] <kalikiana> ackk: Hmmm I can't think of anything else right now - kyrofa, any idea?
[17:07] <ogra_> oh, wow ... that tellys you you can use an implicit fs label "or writable" ... our initrd wouldnt be happy about any other label
[17:07] <ackk> kalikiana, basically to workaround https://paste.ubuntu.com/26325221/
[17:08] <ackk> I'm wondering if we could manually include the libs we need from bionic
[17:09] <ogra_> slangasek, thanks ! i think that will do it ... i didnt read the forum post but looked at the shipped docs in the source tree ... i guess they need some updating (or just a pointer to the forum)
[17:11] <jdstrand> mvo: it's already high in the trello queue already. probably won't happen today though
[17:11] <mvo> jdstrand: thanks, no worries!
[17:12] <jdstrand> np
[17:18]  * kalikiana wrapping up for the day/ week, tho probably idling on IRC for a little while
[17:29] <mvo> ackk: with the following PR https://github.com/snapcore/base-18/pull/24 I get to https://paste.ubuntu.com/26326893/ - I suspect that maas is doing a chown to something that is not root in the configure hook? this is currently not supported unfortunately
[17:29] <mup> PR base-18#24: hooks: fixes to make it usable as a real base snap <Created by mvo5> <https://github.com/snapcore/base-18/pull/24>
[17:31] <mvo> ackk: I will also try to build with type: base, I hope lp/snapcraft support this now. sorry for this bumpy ride
[17:32] <mvo> ackk: fwiw, the pastebin above is all using bionic
[17:34] <mup> PR snapd#4448 opened: Add rules for Media API to the BlueZ D-Bus policy <Created by lhartung> <https://github.com/snapcore/snapd/pull/4448>
[17:35] <ackk> mvo, np, we're all breaking new ground :)
[17:35] <mvo> ackk: I requested a new build for base-18 but looks like the builds are very slow/busy right now (schedule in ~3h)
[17:36] <ackk> mvo, can you paste the link to the built images again?
[17:37] <Chipaca> mvo: do i have your +1 for #4445
[17:37] <mup> PR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>
[17:37] <ackk> mvo, ah, yes https://paste.ubuntu.com/
[17:37] <ackk> mvo, but that used to work before?
[17:38] <ackk> mvo, can you try commenting those out (I don't have the updated base image here)
[17:38] <mvo> Chipaca: yes
[17:38] <mup> PR snapd#4445 closed: tests: make less calls to the package manager <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4445>
[17:39] <Chipaca> :)
[17:39]  * mvo hugs Chipaca 
[17:50] <ackk> mvo, I meant https://paste.ubuntu.com/26326974/
[17:56] <blake_r> ackk: here
[17:57] <blake_r> ack: here
[17:57] <ackk> blake_r, mvo was asking about those chown in the configure hook
[17:57] <ackk> mvo, does snapd now support running as different users?
[17:57] <blake_r> that is because squid will not allow you to run as root
[17:58] <blake_r> so we spawn it with nobody:nobody
[17:58] <blake_r> we have the sample problem with postgres
[17:58] <ackk> mvo, ^
[18:00] <ackk> blake_r, how do you actually spawn it as nobody? you can't really "su" right?
[18:00] <ackk> blake_r, maybe maas should be a classic snap :)
[18:00] <blake_r> supervisord runs it
[18:00] <blake_r> ackk: no!
[18:00] <ackk> actually it probably can't
[18:01] <ackk> because other distros, right?
[18:01] <blake_r> correct
[18:01] <blake_r> it needs to go to strict
[18:01] <blake_r> just have not got that far
[18:01] <ackk> which it probably can without too much work
[18:01] <ackk> but, digressing :)
[18:01] <blake_r> yeah probably need some interfaces, but maybe its close
[18:02] <blake_r> look at snap/conf/supervisord.conf.template
[18:02] <blake_r> also we do some wierd stuff with sudo to use initdb for postgres
[18:05] <blake_r> src/maascli/snappy.py also changes to run as nobody to perform the `maas init` command that initialized the database
[18:10] <ackk> mvo, is that still suported? ^ running as nobody
[18:56] <mvo> ackk: aha, thanks. I will try devmode then if that is a known thing
[18:57] <mvo> ackk: and progress! it now fails with an error that it can't find /usr/share/distro-info/ubuntu.csv, not sure we can do much about this
[18:58] <mvo> ackk: so this is all with my updated base-18 that still has a "starts in 3h estimate "
[18:58] <ackk> mvo, I see, where can I get those builds once they're done?
[18:58] <Saviq> hi all, is installing a local snap getting stuck at "copy snap data" (when the snap barely has any data outside of $SNAP_COMMON) a known issue? it's stuck at aborting that change now
[18:58] <ackk> mvo, so you commented out the chmod?
[19:01] <mvo> ackk: I used --devode
[19:01] <mvo> ackk: here https://code.launchpad.net/~mvo/+snap/base-18
[19:03] <ackk> mvo, oh so with devmode the chown works?
[19:06] <mvo> ackk: correct
[19:06] <mvo> ackk: I was trying to install it as a strict snap, that failed
[19:06] <blake_r> mvo: ah yeah doesn't work in strict
[19:06] <ackk> mvo, is there support in snaps now to run stuff as different users?
[19:07] <blake_r> mvo: does snappy support users yet?
[19:07] <mvo> ackk: so the next stumbling block is this ubuntu.csv
[19:07] <mvo> blake_r: sorry, not yet :/
[19:07] <blake_r> mvo: I can fix that ubuntu.csv
[19:07] <mvo> blake_r: cool, thank you!
[19:07] <blake_r> mvo: we can't go to strict until thats done, timeline on users?
[19:08] <mvo> blake_r: if its trivial (the ubuntu.csv fix) then please share the diff then I can try again with the fix
[19:08] <mvo> blake_r: no timeline yet, I expect this to be a topic in cape town though
[19:08] <blake_r> mvo: okay
[19:08] <ackk> please make sudo work in snaps! :)
[19:11] <blake_r> mvo: http://paste.ubuntu.com/26327405/
[19:12] <blake_r> mvo: can't really test, but that should work
[19:12] <mvo> blake_r: ta
[19:25] <mvo> blake_r: unfortunately your diff is not enough, it appears that the distro_info python module looks into /usr/share/distro-info but this data is now located in $SNAP/usr/share/distro-info
[19:27] <mvo> blake_r: and looking at distro_info.py it appears to be hardcoded. we will soon have "layout" to remap bits of the filesystem dynamically. that will be an elegant way to fix this
[19:28] <mvo> blake_r: fixing distro_info to look at a env for its datadir is also trivial of course, probably something to talk about on monday (getting late here in my TZ :)
[19:31] <blake_r> mvo: okay we can look at it money, go enjoy your evening
[19:31] <blake_r> monday*
[19:31] <mvo> blake_r: alternatively we *could* add distro-info to base-18, but I would prefer to keep it as tiny as possible (though distro-info is tiny so maybe a worthwhile tradeoff)
[19:31] <ackk> mvo, blake_r those .csv come from the distro-info part
[19:32] <mvo> ackk: yeah, except that the python code hard-codes /usr/share/distro-info it seems
[19:32] <blake_r> mvo: it would be nice to be in the base
[19:32] <mvo> ackk: and in the snap that is not the location
[19:32] <ackk> actually, used to
[19:32] <blake_r> maybe that is why it worked on xenial
[19:32] <blake_r> as we didn't have this issue
[19:33] <mvo> blake_r: its in the range of <90kB so not too bad
[19:33] <mvo> blake_r: correct
[19:33] <mvo> blake_r: I checked, its there in the xenial based core we have today
[19:33] <blake_r> yeah placing it in the base would be helpful
[19:33] <ackk> blake_r, so we could probably kill that part altogether if it's in core
[19:33] <ackk> core/base
[19:35] <blake_r> probably need the python piece, but not the csv
[19:39] <mvo> blake_r, ackk with the disto-info added to base-18 and my other PRs merged for base-18 I can install maas with --devmode now in bionic
[19:39] <mvo> and the snap.maas.supervisor.service is up and running
[19:39] <blake_r> mvo: can you try `maas init`
[19:39] <blake_r> sudo maas init
[19:39] <mvo> sure
[19:40] <mvo> I used the defaults and it is now at "initializing database"
[19:41] <mvo> how long should I wait for "init database"?
[19:41] <blake_r> once its done
[19:41] <mvo> fwiw https://github.com/snapcore/base-18/pull/26
[19:41] <mup> PR base-18#26: hooks: also install the disto-info package in base-18 <Created by mvo5> <https://github.com/snapcore/base-18/pull/26>
[19:41] <blake_r> shouldn't take to long
[19:42] <blake_r> unless its stuck or something
[19:42] <mvo> (this is a single core bionic vm with just 1gb ram, it is still at init)
[19:42] <blake_r> ah then it might take a few
[19:43] <mvo> strace shows its in futex(... FUTEX_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME...)
[19:43] <mvo> I will leave it run for a bit and report back
[19:44] <blake_r> if it finishes run `sudo maas status` to get the status of the services inside the snap
[19:44] <blake_r> some should be off but none should be fatal
[19:53] <ackk> mvo, \o/
[19:54] <ackk> mvo, once it's all built, could that be pushed to edge?
[20:01] <mvo> ackk: yes, I think at this point thats fine
[20:02] <mvo> ackk: may take a bit, the one estimate just jumped from 3h to 8h
[20:03] <mvo> ackk, blake_r: unfortunately still at init database, I will call it a day. lets look at this again monday. have a good weekend
[20:08] <mup> PR snapcraft#1842 closed: lxd: Change "Terminating" message to debug level <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1842>
[20:08] <blake_r> mvo: have a good weekend, thanks for the help
[20:22] <remmusikm> exit
[21:05] <kyrofa> elopio, are you around? And have you ever used circle CI before?
[21:57] <maninalift> I have just installed Ubuntu Server 17.10 with snappy and set up the nextcloud snap - GREAT - really easy (which is a relief after giving up on setting up nextcloud in NixOS)
[21:57] <elopio> kyrofa I am, and I have not. Just read the guides
[21:58] <kyrofa> elopio, okay good, keep it that way. You can be the guinea pig for the tutorial I'm writing, I don't remember exactly what it looks like for new users
[21:59] <maninalift> ...however I'm not sure the best way to set up different services under different subdomains
[21:59] <wililupy> I want to add an environment variable to my application launcher. Would it be easier just to write my own wrapper or is this something that I can have set inside the snap?
[21:59] <maninalift> e..g.    cloud.mydomain.com for nextcloud
[22:00] <maninalift> and chat.mydomain.com for rocketchat
[22:02] <maninalift> if I were setting up a web-server without the snappy container stuff I'd put an nginx instance in front  to proxy to different services
[22:04] <maninalift> but I wondered whether there is a particular way I should be doing this that fits with snappy
[22:05] <maninalift> there is a clear focus on giving a really simple setup exerience and I thought there might be something that "just works" when I setup multiple services without my having to manually configure the proxy
[22:05] <maninalift> ...thanks for any help
[22:07] <Chipaca> wililupy: you can declare environemtn in the yaml
[22:08] <Chipaca> wililupy: whether it's enough for what you need  i don't know
[22:08] <Chipaca> maninalift: sounds like a question for the forum tbh
[22:09] <Chipaca> maninalift: if you could open a new topic on https://forum.snapcraft.io/ that'd be great
[22:10] <wililupy> Chipaca: are there examples of this on snapcraft.io?
[22:10] <Chipaca> wililupy: let me check
[22:10] <elopio> kyrofa: good, I'll just stay ignorant 😃
[22:11] <mcphail> maninalift: I know setting up namevirtualhosts still requires doing things the old way and then proxying. I've asked about this recently
[22:11] <wililupy> ideally, I would like to use 'snap set' to configure which configuration file to use for the device since the variable is read by the applicaation and the config file tells what port does what and how many ports there are on the device.
[22:11] <maninalift> Chipaca: OK, thanks will do
[22:12] <Chipaca> wililupy: i'm not very good at finding these things, but https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175
[22:13] <Chipaca> wililupy: that does sound like the sort of thing the config hook was made for, yes
[22:13] <Chipaca> wililupy: note 2.30 gives you the ability to stop/start services from hooks
[22:16] <wililupy> Thanks Chipaca, that is what I was looking for. Do you have a good place I can read up on the "inner workings" of snap set command?
[22:17] <Chipaca> wililupy: 'snap set' triggers the config hook; look that up -- i think kyrofa explained it in detail
[22:17] <Chipaca> wililupy: https://kyrofa.com/posts/snap-configuration-the-configure-hook ?
[22:17] <Chipaca> maybe :-p
[22:17] <wililupy> Chipaca: Cool. I check that out.
[22:18] <kyrofa> Chipaca, yeah, it's discussed there, certainly