[00:00] <nacc> SuperJonotron: i'm not sure how that's supposed to work; my initial response would be install it as the root user, rather than as your regular user
[00:00] <nacc> SuperJonotron: but that seems less than ideal
[00:01] <SuperJonotron> that is actually how i have to install it but for some reason when you run the snap as sudo after that it doesn't work unless it's the user who calls it
[00:01] <nacc> SuperJonotron: you *may* need to pass -H to sudo? to use root's home
[00:03] <nacc> tbh, this feels like an odd corner case to me -- this doesn't sound like a normal application, if it rqeuires root
[00:03] <SuperJonotron> the software is bound to hardware, the hardware it needs access to requires root access
[00:03] <nacc> SuperJonotron: i believe normally you'd write/request an itnerface to the hardware
[00:03] <nacc> and then connect your snap to that interface
[00:03] <SuperJonotron> pass -H where in the process?  in the method calling sudo or sudo -h <snapName>
[00:04] <nacc> SuperJonotron: can you run the snap (as installed by the root user) as the root user? First run `sudo -s -H` to switch to the root user's home and then try to run the snap?
[00:04] <SuperJonotron> i'm rebuilding it now because I was trying something else, i'll test in just a sec
[00:05] <nacc> SuperJonotron: e.g., you can see for other hardware access stuff, there are interfaces at http://snapcraft.io/docs/reference/interfaces
[00:05] <nacc> my thinking is based purely on my understanding of snapcraft/snaps, not on any actual experience connecting to hardware, to beclear :)
[00:07] <SuperJonotron> even when installing the snap as root and going to it's home directory, it still say command not found
[00:08] <nacc> SuperJonotron: what ubuntu are you on?
[00:08] <SuperJonotron> 16.04
[00:08] <nacc> SuperJonotron: echo $PATH as root?
[00:08] <nacc> SuperJonotron: is /snap/bin there?
[00:10] <SuperJonotron> it is not
[00:10] <SuperJonotron> so that's probably that problem
[00:11] <SuperJonotron> I do know the bash command that is requiring the root so if you know of any of those interfaces or an equivalent non-root of dmidecode i could make this snap happy
[00:11] <nacc> SuperJonotron: so you could try running /snap/bin/<snap-name> as root
[00:13] <SuperJonotron> yup, that works but doesn't recognize dmidecode
[00:14] <nacc> SuperJonotron: right, did you put dmidecode into the snap?
[00:15] <nacc> SuperJonotron: just as quick check, do youhave /etc/profile.d/apps-bin-path.sh ?
[00:15] <nacc> SuperJonotron: that's what i believe suffixes /snap/bin into $PATH for all users
[00:15] <SuperJonotron> i definitely didn't put dmidecode into the snap
[00:16] <nacc> SuperJonotron: then your snap won't see it :)
[00:16] <nacc> SuperJonotron: your snap only has what is in the snap
[00:16] <SuperJonotron> not entirely sure wha that syntax would look like at the moment
[00:16] <nacc> SuperJonotron: e.g., you'd put stage-packages: dmidecode
[00:16] <nacc> http://snapcraft.io/docs/build-snaps/syntax
[00:16] <nacc> SuperJonotron: for a dmidecode part
[00:17] <nacc> SuperJonotron: you basically can't rely on anything in the host system being present in your snap (well, you can in some cases, but for clarity it's probably best not to)
[00:17] <SuperJonotron> yes, i do have that file
[00:17] <SuperJonotron> yeah, i've looked through the docs quite a bit
[00:18] <SuperJonotron> i just meant i don't know how to get dmidecode defined in the yaml immediately
[00:18] <SuperJonotron> I can start breaking things until i get it right
[00:19] <nacc> SuperJonotron: ok, not sure why root wouldn't pick that up -- you did `sudo -s -H` to switch to root?
[00:19] <SuperJonotron> yup
[00:20] <nacc> strange
[00:20] <nacc> let's leave it for now, separate issue :)
[00:20] <nacc> SuperJonotron: right, so you'd need to ensure that your yaml specifies dmidecode (and i guess any other dependencies you might have) are in the snap
[00:20] <SuperJonotron> switched to root, then did /snap/bin/<snapname> and can't pick up the dmidecode
[00:20] <SuperJonotron> yeah, that's the last one, just added it
[00:20] <SuperJonotron> everything else works fine
[00:21] <nacc> SuperJonotron: cool, I expect that shoudl work once it's built
[00:21] <SuperJonotron> i meant added it to the app, not the yaml
[00:21] <nacc> SuperJonotron: sorry?
[00:21] <nacc> SuperJonotron: can you pastebin your yaml?
[00:21] <SuperJonotron> added the dependency within the app, still haven't figured out how to include it in the yaml so it would exist in the snap
[00:25] <SuperJonotron> any thoughts on including that package into snappy?
[00:25] <nacc> SuperJonotron: sorry, i asked you to pastebin your yaml?
[00:25] <nacc> SuperJonotron: can't really help in the abstract :)
[00:25] <SuperJonotron> missed that, one sec
[00:27] <SuperJonotron> name: mysnap version: 1.0 summary: A snappy implementation description:   Runs my snap confinement: devmode  apps:   niagara:     command: bin/start.sh  parts:   niagara:     plugin: copy     files:       appdata: app/       start.sh: bin/
[00:27] <nacc> SuperJonotron: no
[00:27] <nacc> SuperJonotron: pastebin
[00:28] <nacc> SuperJonotron: paste.ubuntu.com, please
[00:29] <SuperJonotron> i've never used that before i pasted it in, now paste it back here?
[00:30] <nacc> SuperJonotron: ah sorry, it should provide a URL
[00:30] <nacc> SuperJonotron: paste that URL here
[00:30] <nacc> you can also do `cat snapcraft.yaml | pastebinit` if you have pastebinit installed
[00:31] <SuperJonotron> http://paste.ubuntu.com/23286932/
[00:32] <nacc> SuperJonotron: just as an fyi, i think 'application' should be 'application:' (it might just work as-is, but is non-standard)
[00:32] <nacc> SuperJonotron: ok, so add under files:
[00:32] <SuperJonotron> i modified it slightly to remove specifics of the application, the original has it
[00:32] <nacc> SuperJonotron: stage-packages: dmidecode
[00:32] <nacc> at the same level of indentation as files:
[00:32] <nacc> SuperJonotron: ah ok
[00:34] <SuperJonotron> so like this? http://paste.ubuntu.com/23286946/
[00:35] <nacc> SuperJonotron: it might be a list, so maybe [dmidecode], or
[00:35] <nacc> stage-packages:
[00:35] <nacc>   - dmidecode
[00:36] <SuperJonotron> it was the second one
[00:36] <SuperJonotron> rebuilding now to test
[00:36] <nacc> SuperJonotron: so what that will do, is ensure that the ubuntu package 'dmidecode' is installed for that 'part'
[00:36] <nacc> SuperJonotron: so it will now be part of your final snap
[00:39] <SuperJonotron> ran as sudo /snap/bin/<snapname>
[00:39] <SuperJonotron> dmidecode: command not found still
[00:39] <nacc> SuperJonotron: did you install it again?
[00:40] <SuperJonotron> yup
[00:40] <SuperJonotron> just did it again to make sure
[00:41] <SuperJonotron> same results
[00:41] <nacc> SuperJonotron: can you pastebin `unsquashfs -l <app.snap>` ?
[00:41] <nacc> SuperJonotron: how are you invoking dmidecode? (absolute path versus just cmd name?)
[00:42] <SuperJonotron> just command name
[00:42] <nacc> SuperJonotron: ok
[00:42] <SuperJonotron> what was app.snap in reference to
[00:42] <nacc> SuperJonotron: when you build a snap, a .snap file is created
[00:42] <SuperJonotron> i get a Read on filesystem failed because is a directory when i just put the app name
[00:42] <SuperJonotron> yup
[00:42] <nacc> give unsquashfs -l the path to that .snap file
[00:44] <SuperJonotron> it just goes to a blank terminal line '>'
[00:44] <nacc> SuperJonotron: unsquashfs -l /path/to/app.snap ?
[00:45] <SuperJonotron> yup
[00:45] <nacc> SuperJonotron: can you c&p the exact command you are running
[00:45] <SuperJonotron> just typed it again in case it was a type-o, worked that time
[00:45] <nacc> SuperJonotron: ok
[00:46] <nacc> SuperJonotron: and can you pastebin the current yaml file too
[00:46] <SuperJonotron> yeah, i can see the dmidecode pieces in there which i'm sure is what you wanted to see
[00:46] <nacc> SuperJonotron: well, i want to see the path, etc
[00:47] <SuperJonotron> http://paste.ubuntu.com/23286972/
[00:47] <nacc> SuperJonotron: can you update your script to call /usr/sbin/dmidecode? (Or ensure that /usr/sbin is in PATH)
[00:48] <SuperJonotron> yeah, i'll have to rebuild the application before i can rebuild the snap so it'll take a few min
[00:49] <nacc> SuperJonotron: ok
[00:55] <SuperJonotron> no luck, sudo: /usr/sbin/dmidecode: command not found
[00:56] <nacc> SuperJonotron: wait, you're runing under sudo still?
[00:56] <nacc> SuperJonotron: please run *as* root, just to be sure
[00:56] <nacc> SuperJonotron: i probably have to go soon, getting late here, just fyi
[00:57] <SuperJonotron> i can't switch to root with su
[00:57] <SuperJonotron> don't have root password
[00:57] <nacc> SuperJonotron: sudo -s -H
[00:57] <nacc> SuperJonotron: as i said earlier
[00:58] <SuperJonotron> sorry, long day here as well, switching between too many things
[00:58] <nacc> SuperJonotron: np :)
[00:58] <SuperJonotron> switched to root with sudo -s -H
[00:59] <nacc> SuperJonotron: ok and now run /snap/bin/<app>
[00:59] <SuperJonotron> did, same error
[00:59] <nacc> SuperJonotron: can you pastebin it?
[00:59] <SuperJonotron> h/o, i still had sudo in the bash script calling that
[01:00] <SuperJonotron> let's see if rebuilding without fixes
[01:01] <SuperJonotron> if this does at least allow it to run, any thoughts on fixing this for non root user?
[01:02] <nacc> SuperJonotron: not off the top of my head probably better to ask during the day US time
[01:02] <SuperJonotron> can do
[01:03] <SuperJonotron> no luck
[01:03] <nacc> SuperJonotron: can you pastebin the exact output?
[01:03] <SuperJonotron> the whole output won't mean anything to you since it's just the applictions startup output
[01:04] <nacc> SuperJonotron: the error line
[01:04] <SuperJonotron> it just prints this out: sh: 1: /usr/sbin/dmidecode: not found
[01:07] <nacc> SuperJonotron: so there are ways to add a shell option to your snap
[01:07] <nacc> https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1615163 e.g.
[01:08] <mup> Bug #1615163: shell boilerplate could be automatically added when building in devmode <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1615163>
[01:08] <nacc> SuperJonotron: and then you can run <app>.shell
[01:08] <nacc> which will put in bash running in the env of your snap
[01:08] <nacc> you could see from there if you can run the commands you expect
[01:08] <SuperJonotron> i'll bookmark that to continue testing tomorrow
[01:08] <SuperJonotron> thanks for the help
[01:09] <nacc> SuperJonotron: i'll be around again then to help
[01:09] <SuperJonotron> awesome, thanks again
[06:03] <mup> PR snapd#2113 opened: Add i2c builtin interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2113>
[06:14] <dholbach> good morning
[06:18] <didrocks> hey dholbach
[06:19] <dholbach> salut didrocks
[07:28] <dholbach> svij, taskwarrior can be removed from https://github.com/ubuntu/snappy-playpen/wiki/SandPit - right?
[07:28] <svij> dholbach: yes
[07:28] <dholbach> great, doing that now
[08:41] <mup> PR snapd#2114 opened: tests: add readme about spread's external backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2114>
[09:18] <trijntje> Hi all, I want to snap https://github.com/broadinstitute/wdltool
[09:19] <trijntje> should I build it myself, or is there a way to tell snapcraft to pull the release .jar from github directly? https://github.com/broadinstitute/wdltool/releases
[09:19] <trijntje> I don't have any experience with building .jar files myself
[10:00] <mup> PR snapcraft#859 opened: Set GOBIN in go plugin build environment <Created by tasdomas> <https://github.com/snapcore/snapcraft/pull/859>
[10:04] <john> ogra_: o/
[10:04] <john> um
[10:04] <ogra_> heh
[10:05] <Chipaca> ogra_: you know a lot more sh than I. Is there a way to make /bin/sh behave wrt signals?
[10:05] <ogra_> one sec
[10:05] <Chipaca> ogra_: case in point: a script runs a; b, you sigint, a exits on the signal, sh still runs b
[10:06] <Chipaca> bash behaves properly and will exit if a doesn't catch (or catches and reraises) the signal
[10:06] <ogra_> Chipaca, http://paste.ubuntu.com/23288279/
[10:07] <ogra_> use trap ...
[10:08] <Chipaca> that seems to be the opposite of what I want
[10:08] <Chipaca> :-)
[10:08] <stub> Anyone know if there is a way to set environment variables when invoking qmake? qmake FOO=bar doesn't seem to work, and I don't know the tool.
[10:08] <ogra_> trap b INT
[10:09] <Chipaca> ogra_: maybe I'm stating my problem wrong. Give me a while and I'll show you a testcase.
[10:09] <ogra_> (a should just exit anyway, then the trap runs b on INT)
[10:11] <stub> Or maybe this qmake project is just broken :-(
[10:12] <ogra_> stub, try prefixing qmake with the var instead ?
[10:13] <stub> yer, but I can't do that with the qmake plugin so am working around it with a custom plugin
[10:14]  * ogra_ would just use the make plugin and call qmake from the build target with all env needed
[10:14] <stub> I'm trying to ween myself off from that approach :D
[10:14] <ogra_> heh
[10:15] <stub> Although I am slightly tempted with a bash plugin, that lets you embed a shell script in the yaml.
[10:16] <cjwatson> Chipaca: WFM
[10:16] <cjwatson> $ sh -c 'sleep 5; echo a'
[10:16] <cjwatson> ^C
[10:16] <cjwatson> $
[10:16] <Chipaca> yeah. test case coming soon.
[10:16] <ogra_> stub, i think there are a few PRs on github with that approach
[10:17] <cjwatson> Chipaca: my theory is you have process A in a different process group for some reason (or is it session?  I can never remember)
[10:17] <stub> I could write a part that generates a snapcraft.yaml and calls snapcraft on it
[10:17] <cjwatson> whatever terminal signals are delivered to the whole of
[10:17]  * cjwatson waves hand vaguely at the copy of Stevens somewhere behind him
[10:23] <Chipaca> cjwatson: ogra_: so, given the following go program (could be in C, but I had the go one closer to hand): http://pastebin.ubuntu.com/23288428/
[10:23] <Chipaca> cjwatson: ogra_: and http://pastebin.ubuntu.com/23288429/
[10:23] <Chipaca> cjwatson: ogra_ there are four modes, with different behaviour
[10:23] <Chipaca> bash does the right thing as I understand it
[10:23] <Chipaca> sh does not
[10:23] <Chipaca> save 'em as /tmp/q.go and /tmp/q.sh & give it a try
[10:26] <Chipaca> the idea is, run q.sh, hit ^C when it prints the first text, observe
[10:26] <cjwatson> which particular arg demonstrates the difference?
[10:28] <Chipaca> cjwatson: with both catch and ignore, where the script should continue, it exits instead
[10:32] <ogra_> why would the script continue at all your ^C goes to the shell
[10:32] <cjwatson> I think this is often what people want for scripts, in order that they can ctrl-c something they're running interactively and not have to repeatedly hammer ctrl-c to get the whole script to exit
[10:33] <cjwatson> bash happens to ignore SIGINT itself for reasons I haven't unpicked
[10:33] <ogra_> oh
[10:33] <ogra_> i wasnt aware of that !
[10:33] <Chipaca> this is about WIFSIGNALED and WTERMSIG
[10:33] <cjwatson> but you can either do 'set -m' in sh to turn on job control, which has the effect of making it have the behaviour you're asking for
[10:33] <Chipaca> which it seems sh isn't looking at
[10:33]  * ogra_ actually hasnt used #!/bin/bash in years 
[10:34] <cjwatson> or probably do something with trap
[10:34] <cjwatson> to get sh to ignore SIGINT
[10:34] <Chipaca> ogra_: wrt why: imagine the process you launched changed the behaviour of ^C (e.g. because you launched emacs)
[10:35] <ogra_> whats emacs ?
[10:35] <ogra_> :P
[10:35] <cjwatson> no, it has nothing to do with WIFSIGNALED/WTERMSIG; the terminal-generated signal is being delivered to *both* processes (the shell and the Go program) and it's a question of what the shell does with the SIGINT signal that it receives itself
[10:35] <Chipaca> ogra_: an embedded operating system for 128-bit arm boards
[10:35] <ogra_> and i thought a backend for organist :)
[10:35] <ogra_> *organists
[10:36] <Chipaca> cjwatson: but bash isn't ignoring the ^C, it's correctly stopping the script if the process dies from the signal
[10:36] <Chipaca> cjwatson: i.e. in the other two cases
[10:37] <Chipaca> in any case, as you say "set -m" makes sh do the (imho) right thing wrt this
[10:38] <Chipaca> cjwatson: thanks!
[10:42] <cjwatson> Chipaca: I misspoke when I said "ignore"; bash installs a custom handler for SIGINT, I haven't quite unpicked exactly what it does
[10:43] <cjwatson> it's nevertheless true that the signal is delivered to the whole foreground process group
[10:44] <cjwatson> I'd suggest playing with things under "strace -I4 -f" to see more detail of what's going on
[10:44] <Chipaca> cjwatson: doesn't sh also have a handler, to wait until after the running command finishes to exit?
[10:44] <Chipaca> cjwatson: ok :-)
[10:46] <cjwatson> yeah, I guess it has slightly different semantics.  I suspect this is not well-specified: the closest I can find so far is http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_11
[10:47] <cjwatson> the relevant effect of set -m here is that the subprocess gets run in its own process group
[10:48] <cjwatson> job control is really mainly for interactive shells though; I don't recall whether there's weird behaviour from trying to use it in scripts
[10:48] <cjwatson> you'll probably get some spurious output at least
[10:49] <ogra_> hmm, i there anything special i need to do to make ubuntu-image use core instead of ubuntu-core ?
[10:49] <Chipaca> ok. Once I pop this out of academic-ish and back in to "why does systemd-activate not exit when I ^C if I'm running it via ssh" we'll see
[10:49] <Chipaca> it's been fun digging into this anyway
[10:50] <ogra_> i installed snapd and snap-confine from proposed and use the ubuntu-image trunk tree to build
[10:50] <Chipaca> cjwatson: i got here via https://www.cons.org/cracauer/sigint.html fwiw
[10:50] <Chipaca> ogra_: ubuntu-image ships its own snap
[10:50] <Chipaca> ogra_: snap-the-binary
[10:50] <Chipaca> ogra_: I suspect you're using an old ubuntu-image
[10:50] <ogra_> hrm, so how do i build rom trunk now
[10:51] <ogra_> *from
[10:51] <trijntje> Hi all, I'm trying to make a snap by downloading a .jar directly, what plugin should I use? I tried 'copy' but i get a "no handler to manage source" error
[10:51] <ogra_> Chipaca, i dont, i directly run out of trunk to get the very latest
[10:51] <Chipaca> ogra_: how does trunk compare to the edge snap?
[10:51] <ogra_> not sure
[10:52] <Chipaca> ogra_: me neither
[10:52] <ogra_> mvo didnt leave any docs, i thought using the proposed packages and latet trunk would suffice
[10:52] <Chipaca> and I'm not about to ask mvo after the week he's just had
[10:52] <ogra_> *latest
[10:52] <ogra_> yeah
[10:52] <ogra_> same
[10:52] <cjwatson> Chipaca: looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683671 too
[10:52] <Chipaca> ogra_: when you say trunk, where're you getting it from?
[10:53] <ogra_> github upstream trunk
[10:53] <Chipaca> cjwatson: heh
[10:53] <ogra_> the same thing that barry uploaded to the archive yesterday
[10:54] <Chipaca> ogra_: and what snap is that using?
[10:54] <cjwatson> Chipaca: of course there's also the underlying bug that your test shell script isn't using set -e ;-)
[10:54] <ogra_> Chipaca, whatever is on the host indeed
[10:54] <Chipaca> cjwatson: sssh :-D
[10:55] <Chipaca> ogra_: so your snap is probably pre-core
[10:55] <ogra_> well, i hopees that one was in proposed
[10:55] <ogra_> *hopd
[10:55] <Chipaca> ogra_: pre-core is like deathcore but with simpler chords?
[10:55] <ogra_> sigh
[10:55] <ogra_> this kbd didnt survive 1,5 years !
[10:55] <ogra_> half the keys dont work
[10:56] <Chipaca> ogra_: no, we've not started the SRU dance of the FF'ed snap yet
[10:56] <cjwatson> Chipaca: sigint.html is interesting, thanks
[10:56] <ogra_> Chipaca, well, given that yakkety is alreeady frozen i'd have expected that all needed bit are in there by now
[10:56] <ogra_> and likewisse in proposed in xenial
[10:57] <Chipaca> ogra_: i don't know
[10:57] <Chipaca> (literally)
[10:57] <ogra_> (else you wont be able to build images in yakkety)
[10:57] <Chipaca> ogra_: that is: I don't know if the last SRU was cut with the core change or not
[10:57] <ogra_> yeah
[10:57] <Chipaca> ogra_: it's been crazy :-)
[10:57] <Chipaca> yakkety is overrated :-p
[10:58] <ogra_> well, devs use it i guess
[10:58] <ogra_> (i dont though ... admittedly :P )
[10:59] <ogra_> the prob is that mvo actually patches the ubuntu-image snap ... but not with all patches i fear
[10:59] <Chipaca> this is the first cycle since 2008 that i haven't switched at or before the alphas, i think
[10:59] <Chipaca> (because our focus was on 16.04)
[10:59] <ogra_> iirc his version still builds 4GB images or everything
[10:59] <ogra_> *for
[11:00] <Chipaca> ogra_: if it's any help, afaik barry also can upload the snap
[11:00] <ogra_> well, he wont know either which patches are used and which arent
[11:00] <ogra_> the wondeful world of binary only packages :P
[11:02]  * ogra_ tries to find a new kbd in the house ... half the char of my password dont work ... igh
[11:10] <trijntje> How can I create a snap using an existing jar file? I keep getting "no handler to manage source"
[11:20] <Chipaca> trijntje: have you read up on the java parts?
[11:21] <Chipaca> trijntje: http://snapcraft.io/docs/build-snaps/parts#snapcraft-for-java-maven-or-ant seems to have some info
[11:22] <Chipaca> if that's not enough, hang around for a while and somebody who knows snapcraft and/or java might be able to help
[11:23] <trijntje> Chipaca: I don't want to build the .jar myself, I just want to download the .jar and put it in the snap. The project I want to use requires sbt
[11:24] <Chipaca> trijntje: I think there's a "copy" plugin, maybe that works?
[11:26] <trijntje> Chipaca: when I tried that it said it had been replaced by 'dump', but I can't get dump to do anything at all
[11:26] <trijntje> Preparing to pull wdltool
[11:26] <trijntje> Pulling wdltool
[11:26] <trijntje> no handler to manage source
[11:27] <trijntje> and the examples are not help either https://github.com/ubuntu/snappy-playpen/search?utf8=%E2%9C%93&q=dump
[11:27] <Chipaca> trijntje: and "snapcraft help dump" doesn't help?
[11:28] <trijntje> nope. I can't even find where the it supposedly pulled the .jar to
[11:29] <Chipaca> trijntje: the good news is, we're needing people new to snapcraft to find these issues
[11:30] <Chipaca> trijntje: the bad news is it's a little bit early for the people who could help you
[11:30] <trijntje> its just frustrating that there are no simple examples that make clear how that plugin works
[11:31] <trijntje> like this: https://github.com/ubuntu/snappy-playpen/blob/af7154cc9cac61d55b17c4aa9517c4d7c003a1a0/jtiledownloader/snapcraft.yaml From this, I guess dump automatically unzips stuf as well?
[11:34] <Chipaca> trijntje: i wouldn't know :-)
[11:35] <trijntje> Chipaca: yeah, me neither ;) Do you happen to know the best time to get help here?
[11:36] <Chipaca> trijntje: usually I'd say starting about now (or in half an hour tops), but it's been a crazy week so people might be taking it slower today
[11:43] <ogra_> hrm, so i have an image building now ... but that seems to hav cloud-init enabled and not configured
[11:44] <ogra_> (which means the boot takes about 5min with spilling cloud-init errors to the console)
[11:45] <ogra_> sigh
[11:45] <Chipaca> augh
[11:45] <trijntje> Chipaca: thats good to know, thanks. I'll hang around for a bit ;)
[11:46] <ogra_> i really dontz know what mvo did here :/
[11:47] <ogra_>  * live-build/ubuntu-core/hooks/22-disable-cloud-init.chroot:
[11:47] <ogra_>     - removed, the gadget.yaml now contains an "cloud.conf" file
[11:47] <ogra_>       that will create a /etc/cloud/cloud.cfg or a "cloud-init.disabled"
[11:47] <ogra_>       file (if coud.conf is missing)
[11:47] <ogra_> oh man
[11:48] <ogra_> would be helpful if he actually had published that gadget.yaml anywhere to the world
[11:48] <ogra_> (and also ... this broke all dailies ... )
[11:52] <ogra_> Chipaca, do you by chance happen to know if he publisshed that gadget somewhere ... seems to have been sideloaded into the image he published
[11:53] <ogra_> (there is nothing in the store nor in the gadget upstream tree)
[11:53] <Chipaca> ogra_: the pc gadget in the store should be like that
[11:53] <ogra_> it definitely isnt
[11:53]  * Chipaca looks
[11:53] <ogra_> ha not been changed since 4 weeks
[11:53] <ogra_> *ha
[11:53] <ogra_> *h a s
[11:54]  * ogra_ curses this kdb ... thats the last expensive one i ever bought !
[11:55] <Chipaca> ogra_: sorry, i don't follow
[11:55] <ogra_> Chipaca, the gadget in the store has not been changed in 4 weeks
[11:55] <Chipaca> ogra_: the test suite creates an image using the gadget from the store
[11:55] <ogra_> (ignore my rasmbling about my broken kbd)
[11:56] <Chipaca> ogra_: the resulting image disables cloud-init because it doesn't have a cloud.cfg
[11:56] <ogra_> Chipaca, well, that might be ... but the pc gadget in the tore doent have any magic for cloud init
[11:56] <Chipaca> ogra_: correct, the lack of magic means no cloud-init
[11:56] <ogra_> no
[11:56] <Chipaca> that's what you just pasted from that changelog
[11:56] <ogra_> th magic *disables* cloud-init
[11:57] <Chipaca> the thing you just pasted says "if no cloud.cfg, disable cloud-init"
[11:57] <ogra_> the gadget in the store doent have *any* cluld handling
[11:57] <ogra_> ince it is to old
[11:57] <Chipaca> which means cloud-init gets disabled as wanted
[11:57] <Chipaca> :-)
[11:57] <ogra_> well, it doent
[11:57] <Chipaca> hah
[11:58] <ogra_> doe that come from an ubuntu-mage ack ?
[11:58] <ogra_> ARGH
[11:58] <Chipaca> ogra_: is this still with ubuntu-image master?
[11:58] <ogra_> does that come from an ubuntu-image hack that waa not publihed ?
[11:58] <ogra_> yeh
[11:58] <ogra_> i built a local nap from mater now
[11:58] <ogra_> oh man
[12:00] <oparoz> Hello, is `$ snap-compose` on the roadmap?
[12:00]  * ogra_ wonders where these chars go when they are missing :P
[12:01] <oparoz> or should we install other snaps from the snap we install?
[12:01] <oparoz> (if that's even possible)
[12:02] <ogra_> technically it is, via the snapd-control interface i think
[12:02] <ogra_> but thats no auto-connect one
[12:03] <Chipaca> what is snap-compose?
[12:04] <oparoz> docker-compose
[12:04] <oparoz> as an analogy
[12:04] <Chipaca> what is docker-compose?
[12:04] <oparoz> For a pre-configured setup based on snaps
[12:05] <Chipaca> oparoz: is the setup at the gadget level, ie you want a system with a bunch of snaps, or at the snap leve, ie you want a snap with a bunch of building blocks?
[12:06] <oparoz> I'd like to make some snaps more flexible, so instead of shipping the database, per example, I'd like to be able to create a config file which comes with one option, but if you want another one, you modify the config file to load the other one and then re-launch the "bundle"
[12:06] <oparoz> Chipaca, because tight coupling doesn't always make sense for server apps
[12:07] <Chipaca> ogra_: ubuntu-image fails with an error from mkfs.ext4 for me
[12:07] <Chipaca> ogra_: the one from master, that is
[12:08] <ogra_> Chipaca, you need the foundations ppa
[12:09] <Chipaca> oparoz: i'm probably too obtuse right now. Are you assuming you can make snaps explicitly depend on each other? Or do you want to have, say, a blog engine that talks to either postgres or mysql?
[12:09] <ogra_> sudo add-apt-repository ppa:canonical-foundations/ubuntu-image
[12:09] <oparoz> Chipaca, the latter
[12:09] <ogra_> and add "- lib" and e2fslibs to snapcraft.yaml
[12:10] <Chipaca> oparoz: and what's stopping you from doing that today?
[12:10] <ogra_> i'm sure mvo has a good bunch of local patches for his snap
[12:10] <ogra_> sadly not in his github branch
[12:10] <oparoz> Chipaca, nothing is stopping me, but then I have to install every single snap and connect them
[12:10] <Chipaca> oparoz: (i'm still trying to understand the problem you're having, hence all these questions, sorry)
[12:11] <Chipaca> oparoz: so you want something to orchestrate your snaps?
[12:11] <oparoz> Chipaca, exactly
[12:11] <Chipaca> ah!
[12:11] <oparoz> :)
[12:11] <oparoz> Sorry
[12:12] <Chipaca> oparoz: some people were looking into that, but there's nothing promised yet afaik
[12:12] <oparoz> Chipaca, OK, that's what I wanted to know. Thank you
[12:14] <ogra_> ogra@localhost:~$ ls /snap/pc/current/meta/
[12:14] <ogra_> gadget.yaml  icon.png  snap.yaml
[12:15] <ogra_> so there is no cloud.conf in the released image in the gadget
[12:16] <ogra_> it is definitely the 4 weeks old one from the store ... so there must be some ubuntu-image bit missing
[12:18] <Chipaca> ogra_: I'm sorry, i'm still missing something
[12:18] <ogra_> error ?
[12:18] <Chipaca> ogra_: your problem is that the generated image runs cloud-init?
[12:19] <ogra_> Chipaca, yes ... and there must be code somewhere that disables it for mvo's
[12:19] <ogra_> ogra@localhost:~$ ls /etc/cloud/
[12:19] <ogra_> cloud-init.disabled
[12:19] <ogra_> i.e. something that puts this file in place
[12:19] <ogra_> it is definitely not the gadget though
[12:19] <ogra_> (like the commit above suggested)
[12:20] <ogra_> so there must be some ubuntu-image patch he didnt commit anywhere
[12:21] <Chipaca> ogra_: or maybe, maybe, the patch is in cloud-init
[12:21] <ogra_> unlikely ... then that would be in the archive or in the PPA
[12:22] <Chipaca> wait
[12:22] <Chipaca> it's in snap
[12:22] <Chipaca> ogra_: it's in snap
[12:22] <ogra_> i think i found it °
[12:22] <ogra_> https://github.com/CanonicalLtd/ubuntu-image/pull/69
[12:22] <mup> PR CanonicalLtd/ubuntu-image#69: include etc/ as well <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/69>
[12:22] <ogra_> oh man ...
[12:22] <ogra_> simply not merged
[12:23] <Chipaca> ogra_: ogra_ https://github.com/snapcore/snapd/blob/master/image/image.go#L222
[12:23] <Chipaca> ogra_: build snap from snapd master
[12:23] <Chipaca> ogra_: put it somewhere in your path
[12:23] <ogra_> snapcraft does that
[12:23] <ogra_> when rolling the snap
[12:23] <Chipaca> ah, ok
[12:23] <ogra_> the missing merge is the issue, i'm sure
[12:24] <Chipaca> ok fair enough
[12:24] <Chipaca> i'm going to go now have lunch
[12:24] <Chipaca> o/
[12:24] <ogra_> enjoy
[12:34] <jgdx> my snap is published to the edge channel, but it can't be found using snap install --channel=edge. Can be found using the beta channel, though.
[12:35] <jgdx> disregard, may have been pebkag
[12:38] <ogra_> Chipaca, hmm, still not enough ... for some reason the ect dir isnt even created
[12:39] <Chipaca> ogra_: sorry, i can't quite hear what you're saying over the delicious lunch
[12:39] <ogra_> i didnt mean to distract you from it (i was assuming you are afk :P )
[12:39] <Chipaca> I am!
[12:39] <Chipaca> i'm probably doing it wrong tho
[12:39] <ogra_> with very long arms ?
[12:40] <Chipaca> well, it's said my ancestors were good swimmers
[12:41] <Chipaca> so maybe? i'm not sure how it works
[12:41] <ogra_> heh
[12:42] <ogra_> well, i see all the snapd cloud code in my ubuntu-image tree and i have hacked the etc copying in ... but i dont end up with an etc dir at all in the image build when i keep the fragments around
[12:43] <ogra_> oh, wait ... i *do* see it
[12:43] <ogra_> ogra@anubis:~/datengrab/images/snappy$ ls workdir/unpack/image/etc/cloud/
[12:43] <ogra_> cloud-init.disabled
[12:43] <ogra_> ogra@anubis:~/datengrab/images/snappy$
[12:43] <ogra_> yet, the image i built still fires up cloud-init
[12:47]  * ogra_ goes for a break
[12:54] <rvr> https://bugs.launchpad.net/snappy/+bug/1631357
[12:54] <mup> Bug #1631357: Can run multiple configure processes in different terminals <Snappy:New> <https://launchpad.net/bugs/1631357>
[12:56] <rvr> Hi guys. I am trying to configure wifi, but nothing happens when I press Enter in "Use DHCPv4 on this interface". Any tip?
[12:57] <mup> Bug #1631357 opened: Can run multiple configure processes in different terminals <Snappy:New> <https://launchpad.net/bugs/1631357>
[13:54] <mup> PR snapd#2115 opened: tests: only stop a service if it is running or ok (eg. active (exited)) <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2115>
[14:10] <kgunn> ogra_: yo, do you know if the new dragonboard image will be ready today?
[14:10] <kgunn> re "Ubuntu Core 16 Feature Freeze" mail
[14:10] <davmor2> rvr: ^
[14:10] <ogra_> kgunn, if i ever find out which patches mvo used locally to create the images ...
[14:10] <ogra_> sadly i cant build them atm
[14:11] <kgunn> doh
[14:11] <ogra_> and mvo is off today
[14:11] <rvr> davmor2: ?
[14:11] <kgunn> nw, will camp out on the beta image a bit more
[14:11] <davmor2> rvr: there is a new image to come so that might help but pick on ogra_ now he is back, it'll all be his fault anyway ;)
[14:12] <ogra_> there is nothing to pick on me
[14:12] <rvr> davmor2: Ah, thanks
[14:12] <ogra_> i cant do much until i know what mvo did to make sure cloud-init stays turned off
[14:12]  * davmor2 hands rvr a pick and points ogra_ 
[14:13] <rvr> ogra_: Do you publish them directly on http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ ?
[14:13] <ogra_> no
[14:13] <ogra_> i will only do dailies
[14:13] <ogra_> (which are broken as well now)
[14:14] <rvr> ogra_: What exactly is broken?
[14:14] <rvr> I installed the current one
[14:14] <ogra_> ubuntu-image from master or the snap doesnt create them correctly
[14:14] <ogra_> there are bits missing
[14:14] <ogra_> mvo seems to have used some local patches that i cant find anywhere in the trees
[14:15] <ogra_> so they try to fire up cloud-init on boot and fail
[14:15] <rvr> I see
[14:16] <ogra_> (theoretically snap prepare-image (internal command that ubuntu-image uses) should disable cloud-init by default, but the files are not copied into the image that care forthis
[14:16] <ogra_> )
[14:30] <ralsina> sergiusens: I just changed the error message a couple of minutes ago, but your review comments sometimes have no 'reply' button :-P
[14:31] <sergiusens> ralsina oh, that's fine, just looking at the latest diff and in theory my comment should go away if there was a change :-)
[14:32] <ralsina> sergiusens: well,they didn't for some reason. GH reviews are just weird.
[14:32] <ralsina> sergiusens: 1st GH feature I like better on launchpad, to be honest.
[14:32] <sergiusens> ralsina all review systems have their quircks indeed
[14:33] <sergiusens> ralsina I bet it is just a bug in their "one submit with all comments" new feature
[14:36] <oSoMoN> didrocks, for your reviewing pleasure: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/12
[14:36] <mup> PR ubuntu/snapcraft-desktop-helpers#12: Install all available locales and ensure that apps can locate them <Created by oSoMoN> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/12>
[14:37] <pedronis> ogra_: as far I understood mvo had to teach ubuntu-image to copy /etc bits and not just /var from what prepare-image produces, but not sure where that patch lives
[14:37] <ogra_> pedronis, yeah, thats the patch i added ... didnt help
[14:37] <pedronis> ok
[14:37] <pedronis> then not sure at all
[14:38] <ogra_> i see /ect in the workdir if i build with "-w workdir"
[14:38] <pedronis> didn't hear of anything else
[14:38] <ogra_> but it doesnt get copied even with the patch
[14:38] <ogra_> https://github.com/CanonicalLtd/ubuntu-image/pull/69 is the one
[14:38] <mup> PR CanonicalLtd/ubuntu-image#69: include etc/ as well <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/69>
[14:39] <didrocks> oSoMoN: already in! :-)
[14:39] <didrocks> thanks ;)
[14:39] <ogra_> i use this ammd the snap i rolled definitely also has the latest snapd from master (so it does the cloud handling)
[14:39] <oSoMoN> didrocks, wow, that was fast, thanks!
[14:39] <didrocks> oSoMoN: service! :-)
[14:39] <ppisati> ogra_: you don't do any modification to initrd.img these days, don't you? i just tried to build an rpi3 image using a custom kernel snap, but it fails in some obscure way in initrd.img
 ogra@anubis:~/datengrab/images/snappy$ ls workdir/unpack/image/etc/cloud/
 cloud-init.disabled
 ogra@anubis:~/datengrab/images/snappy$
[14:39] <ppisati> ogra_: i alread tried the beta and edge channel FWIW
[14:39] <ogra_> and it even creates everything ...
[14:39] <ppisati> ogra_: http://pastebin.ubuntu.com/23289082/
[14:40] <ogra_> ppisati, /bin/date: invalid date 'n/a'
[14:40] <ogra_> thats the issue ...
[14:41] <ogra_> there was a ga where the wrong initramfs-tools was added to ubuntu-core for a few hours ... but during that time no ubuntu-core should have been built
[14:41] <ogra_> weird that you get the broken initrd
[14:42] <zyga> morphis__: I could use some testing and review on https://github.com/snapcore/snap-confine/pull/168
[14:42] <mup> PR snap-confine#168: Rework mount namespace support <Created by zyga> <https://github.com/snapcore/snap-confine/pull/168>
[14:42] <zyga> jdstrand: ^^
[14:42]  * zyga lseep
[14:42] <zyga> sleep
[14:42] <morphis__> ssweeny: ^^ can you look into that?
[14:42] <morphis__> zyga: I am out full next week but ssweeny will have a look
[14:43] <pedronis> ogra_: did you see this:  https://github.com/CanonicalLtd/ubuntu-image/pull/69  that's all I see there
[14:43] <mup> PR CanonicalLtd/ubuntu-image#69: include etc/ as well <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/69>
[14:43] <ssweeny> morphis: sure
[14:43] <zyga> morphis__: I'm out next week but I'll get it done tomorrow
[14:43] <zyga> morphis__: gustavo helped me find an easy way to test this
[14:43] <ogra_> pedronis, yes,, see above ... my ubuntu-image snap has that
[14:43] <zyga> morphis__: so just first thing tomorrow, now time to sleep
[14:44] <pedronis> ogra_: ok, definitely need mvo at this point
[14:44] <morphis__> zyga: great!
[14:47]  * zyga -> sleep
[14:48] <ogra_> it obviously creates the /etc/cloud dir
[14:48] <ogra_> just doesnt copy the content
[14:55] <ogra_> aha, i thik i found the issue ... the patch is wrong
[14:56] <ogra_> shutil.move(os.path.join(src, 'etc'), os.path.join(dst, 'etc')) should be shutil.move(os.path.join(src, 'etc'), os.path.join(dst, 'etc'), copy_function=copytree)
[14:56] <ogra_> (i think)
[14:56] <SuperJonotron> when I try to copy data out of the SNAP(read only area) into the SNAP_DATA area from within the snaps start process, I am receiving a permission denied response
[14:57] <SuperJonotron> does a snap not have permissions to it's own file space?
[14:57] <nacc> SuperJonotron: heya, were you able to get further today?
[14:58] <ogra_> SuperJonotron, SNAP_DATA is definitely writable, but usually lives in a space where only root can write
[14:58] <nacc> SuperJonotron: right so there's SNAP_DATA and SNAP_USER_DATA
[14:58] <ogra_> what are you trying?
[14:58] <SuperJonotron> ncc, for the time being, I removed the admin requirement for now
[14:58] <nacc> SuperJonotron: ah ok :)
[14:58] <SuperJonotron> will likely double back when time isn't as tight for this project
[14:58] <nacc> SuperJonotron: makes sense :)
[14:59]  * ogra_ sighs ... copytree didnt help 
[14:59] <SuperJonotron> so my application needs to load a license file, the application needs to have it in a specific folder that is unchangeable (confirmed with manufacturer)
[14:59] <SuperJonotron> this means I have to essentially  move the entire app from the read only space to the SNAP_DATA space and run from there
[14:59] <SuperJonotron> so i need to move it during start
[15:00] <mup> Bug #1631407 opened: ugly error when failed to sign because of wrong password <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1631407>
[15:01] <SuperJonotron> was trying cp -R -n so it essentially only happens the first time a new version gets installed
[15:01] <ogra_> well, that will only work if you start it as root
[15:01] <SuperJonotron> and will likely eventually  move the license to the common space
[15:01] <ogra_> a normal user cant write to SNAP_DATA
[15:01] <SuperJonotron> can you install data there via the yaml file initially to prevent needing to run as root?
[15:02] <ogra_> nope
[15:03] <abeato> jdstrand, hi, I have removed the seccomp calls you mention in the review, and now ofono gets killed when doing getsockopt(). Maybe the default template you mention only applies on tip of master branch?
[15:03] <ogra_> what you could do is create a daemon (service) ... that runs some script
[15:03] <SuperJonotron> ogra, so if only a root can access SNAP_DATA, how does a snap application run not as root have any write access?
[15:03] <ogra_> and does the copying only if the license doesnt exist in the target
[15:04] <ogra_> and for a license you probably also want SNAP_COMMON
[15:04] <ogra_> SuperJonotron, user apps write to SNAP_USER_DATA
[15:04] <ogra_> thats not different to any normal linux ...
[15:05] <ogra_> as a user you wont be able to write to a sibdir in /var usually
[15:05] <SuperJonotron> I can move it to common only after I move the whole application because I can't create a link in the read only area but I do plan on figuring that out once I get the app in a writable area to do that
[15:05] <ppisati> ogra_: ok, by reusing the initrd.img from the pi2-kernel.snap, now i can make an image that boots fine
[15:05] <ogra_> well, write a small script that you declare as daemon in snapcraft,.yaml
[15:06] <ppisati> ogra_: actually i ripped that snap apart and replaced the different pieces
[15:06] <SuperJonotron> ogra, so if i get the snap to run as a daemon, it will have access to SNAP_DATA then?
[15:06] <ogra_> have that script check if you need to copy something ... if so, copy it ...
[15:06] <ogra_> right
[15:07] <ogra_> ppisati, i fear mvo released an ubuntu-core that has the broken script
[15:07] <SuperJonotron> ogra, thanks, i'll see what I can do to make my app a daemon
[15:07] <ogra_> SuperJonotron, no, dont ... just write a small shell script, dont make the whole app a daemon
[15:07] <ogra_> only for the copying
[15:08] <abeato> jdstrand, nm, my fault
[15:08] <SuperJonotron> that's what I am doing now on the start command of the app, but your saying, break that out into a separate app within the yaml that is the setup portion versus the start of the app?
[15:08] <SuperJonotron> and that setup is a daemon?
[15:08] <ogra_> right
[15:08] <nacc> SuperJonotron: yeah, i think so, and that part will run as daemon (root)
[15:09] <nacc> and by part, snapcraft terminology would be 'app'
[15:09] <SuperJonotron> ogra, i think i got it, i'll start on that and see if I can get it to work
[15:09] <ogra_> have a small script ... say "initialize.sh" ... make it a daemon and just check if SNAP_DATA is populated ... if it is, exit 0 ... if it isnt, copy $SNAP to $SNAP_DATA
[15:10] <ogra_> or to SNAP_COMMON
[15:10] <SuperJonotron> ogra, that sounds like what I was going to do so I think i'm on the same page
[15:10] <ogra_> good :)
[15:15] <ogra_> oh !
[15:15] <ogra_> so for some reason the patched file doesnt end up in my ubuntu-image snap
[15:17] <ogra_> argh !
[15:17]  * ogra_ curses setup.py
[15:23] <jdstrand> zyga: ack-- that'll have to wait til next week (working on snap declarations in review tools)
[15:24] <ogra_> ogra@anubis:~/datengrab/images/snappy$ ls workdir/root/system-data/etc/cloud/
[15:24] <ogra_> cloud-init.disabled
[15:24] <ogra_> \o/
[15:25] <ogra_> silly snapcraft !!!!
[15:27] <ogra_> pedronis, thanks for trying to help ... in the end the issue was in snapcraft,yaml of ubuntu-image ("source-type: git", even when you have set "source: ." still pulls from the remote branch and overwrites all local changes ... )
[15:33] <mup> PR snapcraft#857 closed: Document the grade option <Created by dholbach> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/857>
[15:35]  * ogra_ dances and finally creates a set of working dailies again
[15:36] <ogra_> kgunn, in about 30min there should be a new daily that you can use
[15:36] <SuperJonotron> http://paste.ubuntu.com/23289279/
[15:36] <SuperJonotron> ogra, added a second app as a daemon and I can run the original app by name but can't get the daemon to run, here is the part of the yaml it's defined in
[15:37] <ogra_> should be identical to the beta (just a little newer)
[15:37] <SuperJonotron> am i missing some simple command to make it run?
[15:37] <ogra_> SuperJonotron, what do you mean ? the daemon runs on snap install or on boot usually ... from a systemd unit snapcraft creates
[15:38] <ogra_> there should be nothing you need to do
[15:38] <SuperJonotron> ah yes, it does do that, i knew i was forgetting something as I'd gotten a snappy daemon to work a while ago
[15:43] <SuperJonotron> ogra, still ended up having to run the app as root since it needed write access to generate and save the license file
[15:43] <kgunn> very cool
[15:47] <ogra_> SuperJonotron, oh, i thought you have the license and want to copy it
[15:47] <ogra_> you should then rather use SNAP_USER_DATA or SNAP_USER_COMMON
[15:47] <ogra_> cant you teach the app itself to read/write the license in one of these ?
[15:48] <ogra_> via config or so
[15:48] <SuperJonotron> I think I will end up doing one of those, thanks
[15:48] <ogra_> withouth even having to copy the world around
[15:49] <SuperJonotron> I discussed with the manufacturer of the application i'm "snappifying" and they don't expose that capability yet
[15:49] <SuperJonotron> discussed as a future release option
[15:50] <ogra_> ah, k
[15:51] <SuperJonotron> is SNAP_COMMON also root access only?
[15:51] <ogra_> yep
[15:51] <SuperJonotron> damn, trying not to make the snap too user specific
[15:51] <ogra_> same thing as SNAP_DATA ... just one levelö up in the fs
[15:51] <ogra_> but there is SNAP_USER_COMMON
[15:52] <SuperJonotron> i'll have to use one of them, just not sure which yet
[15:52] <nacc> SuperJonotron: http://snapcraft.io/docs/reference/env
[15:52] <nacc> SuperJonotron: if you haven't seen it already
[15:53] <SuperJonotron> nacc, i have a similar doc up actually with a few more variables defined, just trying to figure out what's root and what's not and what I can get away with
[15:54] <nacc> ogra_: i wonder if that page should be updated to say not just "writable" but writable as whom?
[15:54] <ogra_> well, the window at the bottom shows the hypothetical target dirs
[15:55] <nacc> ogra_: ah that's true, and i guess you would know /var is not user-writable
[15:55] <ogra_> from that it should be rather clear where a user can write and where she cant
[15:55] <nacc> ogra_: it "should" be versus is .... i think clarity is better :)
[15:55] <ogra_> indeed
[15:55] <nacc> implicit vs. explicit, etc
[15:55] <SuperJonotron> from the developer page though, it is not https://developer.ubuntu.com/en/snappy/guides/security/
[15:57] <stub> This application failed to start because it could not find or load the Qt platform plugin "xcb".
[15:58] <stub> This is why I do backend.
[15:59]  * stub looks for examples to cargo cult
[16:00] <ogra_> kgunn, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has a freshly baked set of images (now using the "core" snap, not "ubuntu-core" anymore ... and all the other goodness the beta has)
[16:01]  * ogra_ prefers to not do backend ... 
[16:01] <ogra_> i rather do weekend ;D
[16:08] <SuperJonotron> ogra, just changed my daemon to copy from $SNAP to $SNAP_USER_COMMON but when I go to /home/user/snap/app, it's just the versions, no common folder exists.  Should the copy be moved back out of a daemon now that it's user specific?
[16:09]  * ogra_ wonders why rvr attaches a wifi dongle to a dragonboard in bug 1631357
[16:09] <mup> Bug #1631357: Can run multiple configure processes in different terminals <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1631357>
[16:09] <ogra_> :P
[16:09] <ogra_> SuperJonotron, i think you need to mkdir ... iirc there was a bug
[16:10] <rvr> ogra_: I was following some instructions
[16:10] <ogra_> heh
[16:10] <rvr> ogra_: But I reproduced that without the dongle
[16:10] <ogra_> well, the dragonboard has onboard wifi ... no need for a dongle
[16:10] <SuperJonotron> ogra, will do
[16:11] <ogra_> rvr, yeah, it is a subiquity (console-conf) bug ... it should put a flag file somewhere when an instance has been started or so ...
[16:11] <ogra_> rvr, some work for cyphermox or mwhudson
[16:12] <rvr> ogra_: Ack
[16:30] <dobey> any go hackers know how to force GODEBUG=cgocheck=0 from inside main() or in the source file, rather than having to set it in the env?
[17:10] <oparoz_> snapd has been broken for over a week now on ARM, should I open a bug to escalate this?
[17:27] <ogra_> oparoz_, ?
[17:27] <ogra_> works fine here
[17:27] <ogra_> ogra@pi3:~$ snap version
[17:27] <ogra_> snap    2.16+ppa36-1
[17:27] <ogra_> snapd   2.16+ppa36-1
[17:27] <ogra_> series  16
[17:28] <ogra_> ogra@pi3:~$ snap list ubuntu-core
[17:28] <ogra_> Name         Version  Rev  Developer  Notes
[17:28] <ogra_> ubuntu-core  16.04.1  838  canonical  -
[17:28] <ogra_> oparoz_, you should always file bugs if unsure though ... it isn hard to invalidate them ;)
[17:30] <mup> PR snapcraft#847 closed: Implementing channel-closing <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/847>
[17:36] <mup> PR snapcraft#848 closed: `sign-build` to prompt users for key selection <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/848>
[17:38] <pmcgowan> ogra_, hey, where can I find the 2.17 release? the usual places not working for me
[17:38] <pmcgowan> the only place I see new images is you page
[17:43] <oparoz_> ogra_, it's the bug we talked about, here, last week. snapd-confine is broken and the fixes need to be backported
[17:43] <oparoz_> ogra_, when people install a snap it doesn't start
[17:44] <oparoz_> one which fails per example is snapweb if you installed it this week
[17:44] <oparoz_> And ogra, you must be on edge or something to have such high release numbers :P
[17:51] <mup> PR snapcraft#858 closed: python plugin: allow usage of bzr <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/858>
[18:00] <mup> PR snapcraft#860 opened: In the downloader demo test, use https <Created by elopio> <https://github.com/snapcore/snapcraft/pull/860>
[18:01] <pedronis> ogra_: not the place you would expect problems to come from, I see
[18:07] <ogra_> oparoz_, yes, indeed i am ... but today edge is nearly equal to beta ... it will take a while til they diverge again
[18:07] <sborovkov> oparoz_: is not that bug classic only. everything is working on core? but idk for sure
[18:07] <oparoz_> sborovkov, could be that core is not affected
[18:07] <ogra_> pmcgowan, 2.17 ? what do you mean by that ?
[18:08] <sborovkov> oparoz_: at least if i am thinking about the same issue... go arm architecture stuff...
[18:08] <oparoz_> sborovkov, exactly that one
[18:08] <sborovkov> thankfully I had some image from few weeks ago.
[18:08] <sborovkov> afraid to ever upgrade again now...
[18:08] <oparoz_> ver 42 fixes the bug which is in version 38 I think
[18:09] <oparoz_> sborovkov, the other workaround is to install snap-confine from yakketi
[18:09] <sborovkov> oh alright. I tried xenial-proposed but that did not work
[18:09] <oparoz_> The problem is that people using snapweb to install snaps won't understand why nothing works...
[18:10] <ogra_> pmcgowan, i dont think there is any snapd 2.17 yet ... (in case you refer to snapd)
[19:06] <pmcgowan> ogra_, ok maybe I am confused, jamie's last update refered to the release of 2.17 and images being on the server later that day
[19:11] <cmars> is it possible to install snapcraft on 14.04, just to build snaps?
[19:30] <mup> PR snapcraft#861 opened: python plugin: install from wheel for local setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/861>
[20:09] <dobey> how do i build and run snapd from in tree to test a change?
[22:42] <zyga> o/
[23:23] <SuperJonotron> having an issue with installing a snap on 16.04 server that works on desktop version
[23:23] <SuperJonotron> desktop accepts --force-dangerous and server doesn't recognize it
[23:23] <SuperJonotron> that's the only difference in the two other than desktop vs server
[23:24] <SuperJonotron> snap is run as root on both instances
[23:25] <nacc> SuperJonotron: are they running the same version of snapd, etc?
[23:25] <nacc> SuperJonotron: just wondering if one picked up an update and one didn't?
[23:26] <SuperJonotron> possibly, how do you update snapd from snappy?
[23:26] <nacc> SuperJonotron: these both sound like classic systems, so i meant `apt update; apt upgrade` on both
[23:27] <SuperJonotron> server isn't classic, no apt-get
[23:27] <SuperJonotron> only snappy
[23:27] <nacc> SuperJonotron: ah, that i'm not sure then :)
[23:27] <nacc> SuperJonotron: you might try --dangerous rather than --force-dangerous
[23:27] <nacc> iirc, there was some disucssion about this
[23:28] <SuperJonotron> nacc, no go
[23:29] <nacc> SuperJonotron: although i'm not sure how that plays into the core images
[23:29] <nacc> SuperJonotron: sorry, out of my depth :/
[23:29] <SuperJonotron> i'm not even sure if lacking that flag is causing my issue
[23:29] <SuperJonotron> i just know thats the difference and one runs fine and the other runs with security issues so...
[23:37] <SuperJonotron> anybody familiar with the use of --force-dangerous during install and why it doesn't seem to be accepted on server edition?
[23:46] <SuperJonotron> what's the latest release of snap?
[23:46] <SuperJonotron> and/or snapd?
[23:52] <SuperJonotron> anybody know what the snappy equivalent to apt udpate is?