[06:10] <ePierre> hi there!
[06:11] <ePierre> I am trying Snappy on a KVM virtual machine, and I would like to have more free space in the image HDD in order to install more snaps. How can I do that? I tried to follow this guide: http://itsignals.cascadia.com.au/?p=28 but when I start gparted live, I have a kernel panic message
[07:38] <dholbach> good morning
[07:38] <zyga> good morning, hey dholbach :)
[07:39] <dholbach> hey zyga
[07:45] <ePierre> morning zyga  :)
[07:45] <ePierre> and dholbach :)
[07:45] <ePierre> zyga, you may have an idea about this:
[07:45] <ePierre> I am trying Snappy on a KVM virtual machine, and I would like to have more free space in the image HDD in order to install more snaps. How can I do that? I tried to follow this guide: http://itsignals.cascadia.com.au/?p=28 but when I start gparted live, I have a kernel panic message
[07:46] <dholbach> hi ePierre
[07:57] <zyga> ePierre: just make a bigger disk
[07:57] <zyga> ePierre: then snappy expands on first boot
[07:57] <zyga> ePierre: my recommendation is to use -snapshot all the time
[07:58] <zyga> ePierre: so each reboot gives you identical environment
[07:58] <zyga> ePierre: then script any post-boot activities,
[07:58] <zyga> ePierre: this is great for testing
[08:01] <ePierre> zyga, let me try this
[08:05] <ePierre> zyga, hm so I followed everything up to step 8 of that page: http://itsignals.cascadia.com.au/?p=28 ; which supposedely makes my .img file much bigger
[08:05] <ePierre> zyga, yet when I boot I still have 0 free space
[08:06] <fgimenez> good morning
[08:06] <ePierre> Filesystem      Size  Used Avail Use% Mounted on
[08:06] <ePierre>  /dev/sda6       471M  461M     0 100% /home
[08:42] <ePierre> zyga, to follow up, my disk is bigger, but snappy won't expand automagically
[08:42] <ePierre>  /dev/sda6  6569984 19427327 12857344  6.1G Linux filesystem
[08:48] <zyga> ePierre: try latest images, I think this happens automatically now (it did for me)
[09:41] <JamesTait> Good morning all; happy Thursday, and happy Wright Brothers Day! ✈
[10:15] <fgimenez> Chipaca, hello! i'm getting http://paste.ubuntu.com/14072304/ in 15.04/edge, don't know if you are the right person to ask about this
[10:16] <Chipaca> fgimenez: that's interesting
[10:16] <Chipaca> fgimenez: what happens if you disable autopilot using config?
[10:17] <fgimenez> Chipaca, sorry, how can i do that?
[10:17] <Chipaca> fgimenez: rolling: echo 'config: {ubuntu-core: {autoupdate: off}}' | sudo snappy config ubuntu-core -
[10:18] <Chipaca> fgimenez: 15.04: echo 'config: {ubuntu-core: {autopilot: off}}' | sudo snappy config ubuntu-core -
[10:18] <Chipaca> fgimenez: in fact
[10:18] <Chipaca> fgimenez: echo 'config: {ubuntu-core: {autopilot: off, autoupdate: off}}' | sudo snappy config ubuntu-core - | grep auto
[10:18] <Chipaca> fgimenez: should work for both
[10:18] <Chipaca> for now :-)
[10:19] <Chipaca> (we're going to break this on rolling at some point in the new year)
[10:22] <fgimenez> Chipaca, "echo 'config: {ubuntu-core: {autopilot: off}}' | sudo snappy config ubuntu-core -" works  (config doesn't give the "invalid unit status error" afterwards) but i'm not able to reenable it http://paste.ubuntu.com/14072341/
[10:23] <Chipaca> fgimenez: echo 'config: {ubuntu-core: {autopilot: off, autoupdate: on}}' | sudo snappy config ubuntu-core - | grep auto
[10:23] <Chipaca> fgimenez: or, try mask/unmask instead of enable/disable if you need to do it through systemctl
[10:23] <Chipaca> fgimenez: (fwiw i think this is new, and if the change broke stuff you should blame mvo)
[10:24] <Chipaca> fgimenez: (mostly because blaming mvo is always fun)
[10:24] <Chipaca> ahm
[10:24] <Chipaca> fgimenez: i meant to change both 'off's to 'on's, not just one, fwiw
[10:25] <Chipaca> elopio: wrt https://github.com/ubuntu-core/snappy/pull/232
[10:25] <Chipaca> elopio: i don't care whether you use a url or python to make sure the json is valid, but one of the two needs to happen
[10:27] <mvo> Chipaca, fgimenez: hm, I think you now need to mask/unmask
[10:28] <Chipaca> mvo: the 'invalid unit status' thing is probably a bug though
[10:28] <fgimenez> Chipaca, mvo, ok thanks, to continue using systemctl it seems that "sudo systemctl disable snappy-autopilot.timer" is now equivalent to "sudo systemctl disable snappy-autopilot.timer && sudo systemctl mask snappy-autopilot.timer", right?
[10:28] <Chipaca> mvo: makes me think some people will see breakage on upgrade to this
[10:29] <Chipaca> fgimenez: no, just mask
[10:29] <mvo> Chipaca: oh, yeah, for upgrades it is indeed a bug. well, maybe, I think part of the problem is that a disable will not survie a reboot because it gets copied up again :)
[10:32] <fgimenez> Chipaca, mvo ok, just mask works great, thanks!
[10:32] <Chipaca> mvo: good point :)
[10:34] <mvo> Chipaca: sorry for being a smartass, I'm just a bit tired this morning
[10:36] <Chipaca> mvo: your transgression has been duly noted
[10:50] <stevebiscuit|awa> Chipaca, zyga, elopio: I've noted the decision to not separate the REST-wrangling client code
[10:50] <Chipaca> stevebiscuit|awa: *for now* :-) yes
[10:52] <stevebiscuit> Chipaca: if others want to contribute to fleshing out the client lib then I'm all for it :)
[10:53] <stevebiscuit> Chipaca: ripping out all the snappy code from webdm will take a while but it'll be worth it
[10:53] <Chipaca> stevebiscuit: i'll take another pass at your branches in a bit
[10:53] <Chipaca> --- there are a few others ahead of yours in my pile, is all :-)
[10:53] <stevebiscuit> Chipaca: appreciated!
[11:43] <Chipaca> stevebiscuit: you need two +1s to land on master though
[11:43] <Chipaca> stevebiscuit: (just in case you weren't aware)
[11:44] <Chipaca> ah! you already have them
[11:44] <Chipaca> go go go
[11:44] <Chipaca> merged
[11:44] <stevebiscuit> Chipaca: gentleman and a scholar, ta!
[11:45]  * Chipaca straightens his monocle
[11:45] <Chipaca> indeed
[11:45] <stevebiscuit> :D
[12:44] <stevebiscuit> so the concept of a port for a snap service is going to go away?
[12:46] <stevebiscuit> "fyi TODO we have removed the concept of ports." << from code review by Sergio
[12:46] <Chipaca> stevebiscuit: i think sergio misused the word 'concept' there
[12:46] <Chipaca> the *concept* didn't go away
[12:46] <Chipaca> the plan is to expose it in a different way, probably
[12:47] <Chipaca> and the underlying problem of actually doing something with the intent expressed in the ports declaration is still present
[12:47] <Chipaca> but the change should make it feasible to do that something
[12:47] <Chipaca> we're talking post-16.04 stuff now
[12:48] <stevebiscuit> Chipaca: ok, so the data will still be available
[12:50] <pedronis> it's going to be trough capabilities afaiu
[12:50] <Chipaca> stevebiscuit: if i remember correctly, it'll be an attribute of a capability
[12:50] <Chipaca> stevebiscuit: but that's a zyga question i think
[12:50] <Chipaca> he was paying more attention than i
[12:51] <Chipaca> (because he's the caps guy)
[12:51] <stevebiscuit> ah, so the service will need the capability to listen on a specif port, makes sense
[14:39] <jdstrand> beuno, pindonga: hey, I'm getting a 503 when trying to install hello-world in a vm
[14:39] <beuno> jdstrand, yes
[14:39] <jdstrand> hello-world failed to install: received an unexpected http response code (503) when trying to download https://public.apps.ubuntu.com/anon/download/canonical/hello-world.canonical/hello-world.canonical_1.0.18_all.snap
[14:39] <beuno> prodstack going through some heavy turbulance atm
[14:39] <jdstrand> ok
[14:40] <kyrofa> elopio, I'm sorry I completely lost track of time
[14:40] <kyrofa> elopio, do you have power today? :P
[16:09] <frecel> can someone tell me what oem snaps are supposed to be?
[16:14] <ogra_> currently they define the hardware and ship all bootloader related bits
[16:52] <frecel> ogra_: can I put a kernel in an oem snap?
[16:53] <ogra_> no
[16:53] <ogra_> today you need a device tarball ...
[16:53] <ogra_> soon this will all change ...
[16:53] <ogra_> and you need a kernel snap ...
[16:53] <ogra_> the oem snap is going away and the bootloader will go into that kernel snap ...
[16:54] <ogra_> the HW description moves to a so-called gadget snap then
[16:54] <frecel> oh interesting
[16:54] <ogra_> today you still need a device tarball and an oem snap though
[16:54] <frecel> I'm trying to get an image for intel edison
[16:56] <frecel> ogra_: is there a documentation on what a proper oem snap is supposed to look like?
[16:56] <frecel> or should I just look at the pi2 snap and try to figure it out
[16:59] <ogra_> https://developer.ubuntu.com/en/snappy/guides/oem/
[17:00] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
[17:00] <ogra_> have fun :)
[17:08] <kyrofa> jdstrand, mvo my take on a fix for bug #1466234: https://github.com/ubuntu-core/snappy/pull/264
[17:09] <kyrofa> Well, as far as snappy itself goes anyway
[17:14] <frecel> ogra_: I think https://developer.ubuntu.com/en/snappy/guides/porting/ should link to that oem guide
[17:15] <ogra_> true
[17:26] <jdstrand> mvo: hi!
[17:27] <jdstrand> mvo: can you think of why my last comment in https://github.com/ubuntu-core/snappy/pull/264 is happening?
[17:27] <jdstrand> mvo: ubuntu-core/rolling/edge doesn't have the newest ubuntu-core-security-* packages installed
[17:29] <jdstrand> mvo: it has 16.04.2, which is from Nov 12, but 16.04.7 is available in xenial
[17:32] <mvo> jdstrand: is that maybe a xenial vs xenial-proposed thing? without having looked at it
[17:32] <jdstrand> mvno. 16.04.7 is in xenial release
[17:32] <jdstrand> err
[17:33] <jdstrand> mvo: no 16.04.7 is in xenial release
[17:33] <jdstrand> mvo: since Dec 2
[17:33] <mvo> hmmm
[17:33] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-amd64.manifest
[17:33] <ogra_> i see 16.04.7
[17:34] <jdstrand> well that's weird
[17:34] <jdstrand> my vm doesn't have it
[17:34] <jdstrand> and it claims it is up to date
[17:34] <jdstrand> mvo: ok, seems to be a local thing
[17:34]  * jdstrand blows it away and regenerates
[17:36] <ogra_> jdstrand, and it actually landed on dec 3rd in the image http://people.canonical.com/~ogra/core-image-stats/20151203.changes
[17:36] <mvo> jdstrand: scary - the buildlog also has it
[17:37] <ogra_> another delta generation issue ?
[17:37] <mvo> it might be :/
[19:16] <mine_field> what is this? o_O https://uappexplorer.com/app/canonical-linux-pc.canonical
[19:24] <ogra_> well, what the description says :)
[19:25] <mine_field> no description :D
[19:25] <mine_field> i understand nothing :(
[19:25] <mine_field> but is very late so i must sleep now :P
[19:26] <ogra_> it is the new kernel snap
[19:26] <mine_field> oh 4.3.0-2-2
[19:26] <mine_field> got it :d
[19:26] <ogra_> (currently snappy still uses the system-image technology from the phone for upgrades ... this will change ... all parts of the OS will become snap packages)
[19:27] <mine_field> skynet 0.1 got it :D
[19:27] <mine_field> thanks! good night all! ogra_
[19:53] <Rob1507> Hi there. Can anyone help me with something now?
[19:59] <kyrofa> jdstrand, I just made a new VM off of 15.04 stable and I'm still getting apparmor denials to /root/apps. Did I misunderstand you when I thought that would be fixed?
[20:06] <kyrofa> Rob1507, ask away!
[20:07] <Rob1507> kyrofa, I want to snap NodeJS app but I get error
[20:07] <Rob1507> Failed doing build for webchat: Command '['/bin/sh', '/tmp/tmp36flb68n', 'npm', 'install', '-g']' returned non-zero exit status 2
[20:08] <kyrofa> Rob1507, using snapcraft?
[20:08] <Rob1507> kyrofa, yes
[20:09] <kyrofa> Rob1507, can you put the code somewhere so I can take a look? And make a pastebin of the entire output from snapcraft
[20:09] <kyrofa> Rob1507, also, what version of ubuntu are you running?
[20:09] <jdstrand> kyrofa: is that for an existing app?
[20:09] <Rob1507> 14.04 LTS
[20:09] <kyrofa> jdstrand, no just a test case (roscore running as a service)
[20:10] <kyrofa> jdstrand, but I can tar it up if you want it
[20:10] <Rob1507> kyrofa, I am snapping one of the examples - shout. Send code or not needed?
[20:10] <kyrofa> jdstrand, or simplify it
[20:10] <jdstrand> kyrofa: what is the output of dpkg -l|grep ubuntu-core-security-apparmor
[20:11] <kyrofa> Rob1507, you're saying a snapcraft example isn't snapping correctly?
[20:11] <kyrofa> jdstrand, ubuntu-core-security-apparmor 15.04.12~ppa14
[20:11] <Rob1507> http://pastebin.com/ev5Esfv4
[20:11] <Rob1507> kyrofa, this is output
[20:11] <kyrofa> jdstrand, just downloaded the 15.04 stable image and ran snappy update followed by a reboot, no more updates available
[20:12] <jdstrand> kyrofa: that should have it. did you install your snap prior to snappy update/reboot? (that is what I was trying to ask before)
[20:12] <kyrofa> jdstrand, oh I see. And no, I updated and rebooted before I tried installing anything
[20:13] <jdstrand> kyrofa: what is the output of grep HOME /usr/share/apparmor/easyprof/templates/ubuntu-core/15.04/default?
[20:13] <kyrofa> jdstrand, http://pastebin.ubuntu.com/14077787/
[20:14] <kyrofa> Rob1507, are you using the snappy-tools ppa to get snapcraft on trusty?
[20:15] <jdstrand> ok, that's good
[20:15] <jdstrand> kyrofa: can you paste the denial?
[20:16] <kyrofa> jdstrand, http://pastebin.ubuntu.com/14077817/
[20:16] <kyrofa> jdstrand, hmm
[20:16] <kyrofa> jdstrand, actually that looks like a snappy problem huh
[20:16] <kyrofa> jdstrand, it's trying to create /root/apps
[20:17] <jdstrand> kyrofa: indeed
[20:17] <kyrofa> jdstrand, I'm sorry, I just saw a denial on /root and came to you, I should have investigated further
[20:17] <kyrofa> jdstrand, so my PR should probably fix that, eh?
[20:17] <kyrofa> jdstrand, hmm... wonder how to best do that in a systemd conf
[20:18] <jdstrand> it should, but I thought the launcher was already doing that
[20:18] <jdstrand> oh, this is in a service, not a binary?
[20:18] <kyrofa> jdstrand, yes a service
[20:18] <jdstrand> hmmm
[20:19] <jdstrand> I'm not sure the best way to handle that
[20:19] <jdstrand> kyrofa: I think most would probably say that a service should be using SNAP_APP_DATA_PATH and not SNAP_APP_USER_DATA_PATH
[20:19] <kyrofa> jdstrand, I agree, but that's not always possible
[20:20] <kyrofa> jdstrand, not to mention having an environment variable point to a dir that doesn't exist seems wrong anyway
[20:21] <kyrofa> jdstrand, some apps just log to HOME/something, and the person making the .snap can't always change that
[20:21] <jdstrand> it does
[20:21] <jdstrand> does it make sense for SNAP_APP_USER_DATA_PATH to point to SNAP_APP_DATA_PATH?
[20:21] <jdstrand> HOME/something is weird for a service though
[20:22] <kyrofa> jdstrand, agreed, in the case of a service, I think that would be fine. That's more of an mvo question though
[20:22] <jdstrand> yes
[20:23] <kyrofa> jdstrand, okay thanks for trouble-shooting with me :)
[20:25] <jdstrand> np
[20:34] <dPragmatist> snapcraft init
[20:36] <kyrofa> dPragmatist, that may not result in what you'd hoped in this window
[20:40] <dPragmatist> ha, too many open windows kyrofa
[20:41] <kyrofa> dPragmatist, haha, it's happened to all of us
[20:43] <kyrofa> mvo, are you around? It might be a bit late for you