[06:21] <Gunther_> How do I install a sideloaded x.snap with "snap" instead of "snappy"?
[06:23] <dholbach> sudo snap install <local-file.snap>
[06:42] <Gunther_> dholbach: I tried this with little success:ubuntu@localhost:~$ sudo snap install trionet-kernel_4.4.0_amd64.snap  error: trionet-kernel_4.4.0_amd64.snap failed to install: snappy package not found
[06:42] <dholbach> hohum....
[06:42] <dholbach> which version of snapd is this?
[06:43] <Gunther_> I am running mvo's allsnap amd64 image
[06:43] <dholbach> do you know if everything is up to date on the system?
[06:45] <Gunther_> I did run "snappy update"
[06:46] <Gunther_> Currently looking how to ask snapd for its version ...
[06:48] <dholbach> if nobody has an answer for you, you could just try mailing the snappy-devel mailing list
[06:49] <dholbach> if it's a bug you're facing, this should be looked at
[06:50] <Gunther_> dholbach: I will do that. First I need to find out the version of the install tools
[06:50] <dholbach> ok :)
[07:19] <netpheak> hi, guys!
[07:27] <zyga> good morning all
[07:28] <netpheak> morning
[07:47] <shuduo> mvo ogra_ hi, may i know if kernel snap for dragonboard canonical-dragon-linux is exist in edge channel?
[07:49] <Gunther_> On mvo's allsnap image: How do I find out the installed version of snap, snapd?
[07:52] <mvo> Gunther_: /usr/share/snappy/dpkg.list contains a list of deb packages
[07:52] <Gunther_> mvo: thanks
[07:53] <mvo> Gunther_: I need to do new images, they are a bit outdated right now
[07:55] <Gunther_> ok then I will wait before reporting the bugs I seem the have to see if they still exist
[07:55] <Gunther_> with the new images
[08:51] <_morphis> zyga, jdstrand: got NetworkManager now mostly working
[08:52] <zyga> _morphis: woot, great
[08:52] <zyga> _morphis: any issues (apart from 1571497)
[08:52] <_morphis> zyga: I suspect auto-connect isn't implemented yet, right?
[08:52] <zyga> _morphis: it is implemented
[08:53] <zyga> _morphis: but connection only happens on snap install time
[08:53] <zyga> _morphis: and the interface has to advertise it
[08:53] <_morphis> zyga: hm, I set https://github.com/morphis/snappy/blob/networkmanager-interface/interfaces/builtin/networkmanager.go#L390
[08:53] <zyga> _morphis: *and* the interface slot has to be on the OS snap
[08:53] <_morphis> ah
[08:53] <zyga> _morphis: look at snap/implicit.go please
[08:54] <_morphis> zyga: https://git.launchpad.net/~morphis/+git/nm-snap/tree/snapcraft.yaml#n17
[08:54] <zyga> _morphis: until those slots are in the real core snaps this is what we need to do
[08:54] <_morphis> so if I am doing something like this I don't have any chance to both apps connected
[08:54] <zyga> _morphis: no, that will not work
[08:54] <zyga> _morphis: (I guess we need to discuss how this will work)
[08:55] <_morphis> so even if I add networkmanager to snap/implicit.go I wont connect?
[08:55] <zyga> _morphis: hint, no need for the top-level plugs/slots
[08:55] <_morphis> s/I wont/it wont/
[08:55] <zyga> _morphis: correct
[08:55] <zyga> _morphis: (this is the first time we handle something like this)
[08:55] <_morphis> zyga: you mean var networkManagerPermantedSlotDBus .. ?
[08:56] <_morphis> ah I see
[08:56] <_morphis> you mean https://git.launchpad.net/~morphis/+git/nm-snap/tree/snapcraft.yaml#n11
[08:56] <zyga> _morphis: try this http://pastebin.ubuntu.com/15909347/
[08:56] <zyga> _morphis: (and I'd suggest calling the interface network-manager)
[08:56] <_morphis> zyga: that works but then I get a plug network-manager:networkmanager and a slot network-manager:networkmanager
[08:56] <zyga> _morphis: we *might* do something special if the interface name matches the snap name
[08:57] <zyga> _morphis: seems like a nice case to auto-connect everything within the snap
[08:57] <_morphis> if I now add more than one other app I have two identical plugs
[08:57] <zyga> _morphis: ahh, right
[08:57] <zyga> _morphis: and gustavo also said we cannot have plug and slot sharing the same name in one snap
[08:57] <zyga> _morphis: sorry, forget my advice please
[08:57] <_morphis> :-)
[08:57] <_morphis> zyga: but maybe we can improve the automated naming here
[08:57] <zyga> _morphis: still, feels like something we should auto-connect, just looking for a pattern
[08:58] <zyga> _morphis: yes though this needs to be discussed firstr
[08:58] <_morphis> sure
[08:59] <zyga> _morphis: any other gotchas with interfaces?
[08:59] <_morphis> just one thing which jdstrand noted on the bluez interface: https://github.com/ubuntu-core/snappy/pull/802#discussion_r59771686
[09:00] <_morphis> I just dropped peer=(label=..) checks in my policy for now
[09:00] <zyga> ah, I plan to retrun to bluez soon and make it actually understand the connections made
[09:00] <zyga> just not sure if I do that before I go and hide away from computers for a while
[09:01] <_morphis> :-)
[09:01] <_morphis> zyga: ssweeny is currently working on getting the bluez snap back working with what he implemented for the interface
[09:01] <_morphis> zyga: there are still some bits wrong in that interface: https://github.com/morphis/snappy/commit/bf2abcec0453ad8edd9bdcdeb6f16cd4f8c38b57
[09:02] <zyga> _morphis: sure
[09:02] <zyga> _morphis: are you guys blocked by anything today? I know images are in a so-so state
[09:03] <_morphis> so-so state?
[09:03] <zyga> _morphis: not working much
[09:03] <_morphis> ah
[09:03] <zyga> _morphis: we need a moment to restore images to bootable state
[09:03] <_morphis> zyga: I can develop by using your dev-tools so we're for the moment fine
[09:03] <zyga> :)
[09:03] <_morphis> publishing is a bit ahead
[09:03] <zyga> cool, that's great
[09:03] <_morphis> zyga: nice work on those dev-tools :-)
[09:03] <zyga> question: how will the interface work on the desktop
[09:04] <_morphis> zyga: for bluez and networkmanager?
[09:04] <zyga> can I make a snap that talks to n-m and have it magically work because the OS snap on the desktop will fake the interface
[09:04] <zyga> _morphis: yes, I'm trying to think about interoperability
[09:04] <_morphis> sth like that should work
[09:04] <_morphis> as long as there are no API breaks
[09:06] <_morphis> zyga: just wondering a bit what the release plan looks like
[09:07] <zyga> _morphis: fors snappy "for devices"?
[09:07] <zyga> _morphis: I guess that's going to be decided at the sprint
[09:07] <_morphis> lets say we land the networkmanager interface tomorrow, how soon can that be in an image?
[09:07] <zyga> _morphis: in daily image, the next day, in ubuntu 16.04 -- not sure
[09:08] <zyga> _morphis: we plan to SRU things all the time but we didn't go through the process to see how it works yet
[09:08] <_morphis> ok
[09:08] <zyga> _morphis: images are somewhat broken now as mvo mentioned above so I suspect this week we'll see some work on making them bootable again
[09:08] <_morphis> ok, sounds good
[09:34] <ogra_> shuduo, it is called linux-snapdragon since the switch to a 4.4 base
[09:34] <ogra_> err
[09:34] <ogra_> sorry ... canonical-snapdragon-linux
[09:57] <shuduo> ogra_: is there a way to know when it be changed? i used to encounter error like "mount: mount point /tmp/diskimage833309661/system/snap does not exist".  is it a problem happen at server side or my side?
[09:58] <ogra_> sounds more like you are using a to old ubuntu-device-flash
[10:00] <ogra_> make sure to have the latest one from mvo's all-snaps dir
[10:00] <mvo> shuduo: and use "edge" for the channel
[10:00] <mvo> shuduo: there is still a bit of breakage right now, I'm working on the fix
[10:01] <mvo> shuduo: note that the images are still alpha, the 16.04 snap desktop/server release is not yet stable for devices and the imags are still in flux
[10:10] <shuduo> mvo: after specify edge, i got "failed to install "linux-snapdragon" from "edge": linux-snapdragon failed to install: snap not found
[10:13] <shuduo> mvo: yes, i understand it's not stable. i need to make some demo or help customer to demo so unstable is acceptable. but it used to fail at generating.. :(
[10:14] <ogra_> shuduo, note that i corrected myself above
 sorry ... canonical-snapdragon-linux
[10:16] <shuduo> mvo: btw, i have used the script of https://launchpad.net/~mvo/snappy/mksnap-os-kernel for kernel snap generating. but snappy-tools package seems not available in xenial, so the command "snappy build" will be replaced by "snapcraft snap", right?
[10:16] <mvo> shuduo: yes, snapcraft snap .
[10:16] <mvo> shuduo: snapcraft snap targetdir
[10:19] <shuduo> ogra_: sorry i missed it.  canonical-snapdragon-linux is downloading. back to my question, how I know which kernel name is correct if  it be changed? can i find it from somewhere by myself? just in case i meet problem but you are not on irc or timezone problem. thanks.
[10:19] <ogra_> sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-snapdragon-linux --gadget canonical-dragon -o test.img
[10:20] <ogra_> all official kernels are canonical-$arch-linux nowadays ... where $arch is one of pc, snapdragon, raspi2
[10:21] <ogra_> non official ones can indeed be named as the like
[10:21] <zyga> shuduo: you can use my ubuntu-image script, while images are kind of broken today I keep it up-to-date with ongoing changes needed to build an image
[10:21] <ogra_> zyga, whyx do you say this all the time ... images arent broken :)
[10:22] <zyga> ogra_: with snappy 2.0?
[10:22] <ogra_> the dropped config bit makes it a bit harder to set thjem up ... and none of the snaps from the store work
[10:22] <ogra_> well, they worked on friday
[10:22] <zyga> ogra_: I suspect they are broken now, we're discussing how to fix that (firstboot et all)
[10:23] <ogra_> the images themselves are fine though
[10:23] <zyga> ogra_: shades of gray
[10:23] <ogra_> heh
[10:23] <zyga> ogra_: but thanks for telling me :)
[10:23] <ogra_> if they are broiken now, it must be the punishment for mvo not spending his weekend with the family :P
[10:25] <zyga> ogra_: and the solution is to not spend time with the family again to fix them :-(
[10:25] <shuduo> zyga: pls let me know where i can download your ubuntu-image script. thanks.
[10:26] <mvo> ogra_: snap list is empty right now too, the images boot though
[10:26] <zyga> shuduo: github.com/zyga/devtools
[10:26] <ogra_> zyga, yeah, its a doom loop
[10:32] <zyga> ogra_: part of the solution is to snap doom so that we can get some R&R
[10:33] <ogra_> +1 !!
[10:37] <shuduo> zyga, cool! :)
[10:38] <shuduo> ogra_: that means all snapdragon family SoC be supported by a single kernel, right?
[10:39] <shuduo> ogra_: i'm working on a board with APQ8074 but the kernel is 3.10. So if current kernel already support this chip, only adjustment could  be partition layout in gadget snap (if need). that will be awesome!
[10:54] <popey> is SNAP_APP_DATA_PATH still correct or has its name changed recently?
[11:14] <popey> (specifically - what's the environment variable which points to the writable area?
[11:15] <ogra_`> SNAP_DATA
[11:15] <ogra_`> iirc
[11:16] <popey> aha!
[11:16] <popey> yes, thanks.
[11:17] <Gunther_> Is it possible that a daemon in a snap container is able to access /bin/systemctl to restart itself? (I am getting apparmor denied)
[11:21] <kyrofa> Good morning
[11:26] <zyga> Gunther_: no
[11:26] <_morphis> zyga: one other thing I see is that installing a snap some times doesn't work after I had it already installed: https://paste.ubuntu.com/15911281/
[11:26] <zyga> Gunther_: but you should be albe to send a signal to the daemon from using an app from the same snap
[11:27] <zyga> _morphis: looking
[11:35] <popey> $ sudo snap remove mame
[11:35] <popey> error: can't remove "mame": snap "mame" has changes in progress
[11:35] <popey> what does that mean?
[11:37] <Gunther_> zyga: thanks
[11:38] <Gunther_> zyga: I assumed I have to
[11:38] <ogra_`> popey, someone broke into your system and is secretly playing pacman ?
[11:38]  * ogra_` has no clue :)
[11:38] <daker> ogra_`: i have snappy ubuntu core running on rpi2, how can i apt snapcraft 1.x ?
[11:39] <ogra_`> dayou can only use snapcraft 1.x in pre-xenial systems
[11:39] <ogra_`> but the 15.04 snappy did not have the classic shell ... so you would need a chroot
[11:39] <popey> i can't add or remove anything
[11:39] <ogra_`> (or lxc container or so)
[11:40] <zyga> popey: it means that there are changes operating on that snap now, can you please pastebin "$ snap changes"
[11:40] <popey> http://paste.ubuntu.com/15911444/
[11:40] <popey> zyga: ^
[11:40] <zyga> popey: thanks, can you report a bug with this information
[11:40] <popey> sure, where?
[11:41] <zyga> popey: is that on 2.0?
[11:41] <zyga> popey: launchpad.net/snappy please
[11:41] <daker> ogra_: i didn't manage to run an armhf lxc container
[11:41] <popey> up to date 16.04
[11:41] <popey> ok
[11:42] <ogra_`> daker, then grab a tarball from http://cdimage.ubuntu.com/ubuntu-core/releases/15.04/release/ ... scp it to your snappy ... unpack it in a dir, copy resov.conf in place and you can chroot into it
[11:43] <ogra_`> (or use the 15.10 tarball ... probably easier to get a newer snapcraft with that)
[11:43] <zyga> popey: can you try snap abort "snap abort" the changes related to those snaps?
[11:43] <popey> zyga: https://bugs.launchpad.net/snappy/+bug/1571614
[11:44] <popey> zyga: what change ID do I use?
[11:50] <Gunther_> What is the essential apparmor config needed for a custom kernel? I am getting ailed to load AppArmor policy for trionet-srv: exit status 1 :Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
[11:50] <ogra_`> well, recent mainline should have all you need
[11:51] <ogra_`> for older kernels the security team has backported patches ... but only for a certain set
[11:52] <ogra_`> https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels might help
[11:52] <Gunther_> ogra_`: thanks
[11:52] <ogra_`> (note that snappy needs at least 3.10 though ... forget about the 3.4 patches :) )
[11:54] <Gunther_> I am using the kernel sources from 	url = git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git 	fetch = +refs/tags/Ubuntu-4.4.0-14.30:refs/tags/Ubuntu-4.4.0-14.30
[11:54] <ogra_`> that should have all patches
[11:54] <Gunther_> ok
[11:55] <ogra_`> (read, your issue is most likely a config thing)
[11:55] <Gunther_> I just looking for the correct "essential" configuration :)
[11:56] <zyga> popey: thanks
[11:56] <daker> ogra_`: if i want to use my actual snappy installation(without touching anything), i just need to use snapcraft 2.x ?
[11:56] <zyga> popey: those of the changes related to the snap you were trying to install/remove
[11:57] <ogra_`> daker, on a 16.04 snappy image you call "sudo snap enable-classic", then you can "snap shell classic" to get into an apt ebaled environment
[11:58] <popey> zyga: error: cannot abort change 3 with nothing pending
[11:58] <popey> zyga: there's a bunch on Hold.
[11:58] <daker> ogra_`: when the 16.04 image is going to be available :) ?
[11:59] <ogra_`> the first alpha should be available soon
[11:59] <ogra_`> until then you need to use the inofficial ones
[11:59] <daker> ogra_`: where can i find one ?
[12:00] <ogra_`> http://people.canonical.com/~mvo/all-snaps/
[12:00] <daker> of course you have one :D
[12:00] <ogra_`> and for pi3 http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
[12:01] <daker> rpi2-all-snap.img.xz is the one i am looking for ?
[12:01] <ogra_`> yes
[12:01] <daker> ok thanks! i'll test that
[12:01] <zyga> ogra_`: oh, can I patch ubuntu-image for pi3?
[12:02] <ogra_`> zyga, well, the pi2 image should work as is atm .... if you build from the store
[12:02] <zyga> ogra_`: ok
[12:02] <zyga> ogra_`: I'll patch the script today
[12:02] <ogra_`> (i'll have to change that though, unless ppisati has found a fix for the uboot serial issue on the pi2 with that uboot binary)
[12:03] <ogra_`> i'll most likely introduce a canonical-pi3 gadget
[12:04] <zyga> ogra_`: yep, that would be good
[12:04] <zyga> ogra_`: even if the only different thing is a name
[12:04] <ogra_`> well, then we cant easily do a 64bit image
[12:05] <ogra_`> i would really like to have a generic pi image that works on both for 32bit
[12:06] <netpheak> Ogra: When is an official RPI3 release expected?
[12:07] <ogra_`> netpheak, with the offical snappy 16.04 release
[12:07] <netpheak> ok, thx ;)
[12:07] <ogra_`> in a month or two or so
[12:08] <popey> zyga: is it easier to nuke everything and start again? If so, how do I nuke all of snap?
[12:08] <zyga> popey: yes; sudo servicectl stop snapd; sudo  umount /snap/*/*; sudo rm -rf /var/lib/snapd
[12:08] <zyga> popey: give that a try
[12:09]  * zyga will add nuke-state to devtools
[12:11] <mvo> zyga, ogra_`: fwiw, I pushed a new u-d-f
[12:11] <ogra_`> so the archive ?
[12:11] <ogra_`> *to
[12:11] <mvo> which brings back mounted snaps on boot
[12:11] <mvo> to my people page for now
[12:11] <popey> zyga: ok
[12:12] <ogra_`> ok
[12:12] <mvo> and I have a branch up for discussion to sync state on firstboot so snap list actually has something
[12:12] <mvo> *if* that branch is accepted we may have images tomorrow that are in much better shape than todays
[12:12]  * mvo crosses fingers
[12:20] <zyga> mvo: thanks
[12:22] <daker> ogra_`: error: Unknown command `enable-classic'.
[12:22] <ogra_`> thats on a 16.04 image ?
[12:22] <daker> yes Xenial
[12:22] <ogra_`> on your rpi ?
[12:23] <ogra_`> weird
[12:23] <daker> yes
[12:23] <daker> rpi2
[12:23] <ogra_`> the images are old though ... try if the snappy command still exists thetre
[12:24] <oparoz> daker no dash
[12:25] <oparoz> daker, never mind
[12:25] <Gunther_> FYI allsnaps (amd64): snappy install custom_kernel.snap works (boots!) (Yeah)
[12:26] <ogra_`> congrats !
[12:26] <Gunther_> but snappy remove custom_kernel.snap leaves grub in a state trying to boot the custom kernel
[12:26] <Gunther_> it does not recover ...
[12:38] <netpheak> ogra: where can i find the latest RPI3 image?
[12:39] <zyga> _morphis: FYI https://github.com/ubuntu-core/snappy/pull/1034
[12:39] <zyga> _morphis: could you give that a practical spin?
[12:39] <zyga> _morphis: just git checkout that in your tree and use devtools as usual
[12:40] <ogra_`> netpheak, just build a pi2 image from the latest store snaps using u-d-f
[12:40] <ogra_`> the ony in my rpi3 dir is very outdated
[12:40] <_morphis> zyga: sure, thanks!
[12:42] <ogra_`> mvo, hmm, that new udf is very noisy
[12:43] <ogra_`> http://paste.ubuntu.com/15912226/
[12:45] <Gunther_> another one: I tried to add an udef rule to my kernel.snap (it is in the snap, I see the directory/file /etc/udev/rules.d/some.rule). But its not visible on the system the kernel.snap is installed then.
[12:45] <Gunther_> but rules.d seems to be a mount point
[12:45] <ogra_`> it would need to be defined in snappy
[12:46] <ogra_`> iirc it only mounts stuff to /lib/firmware|modules atm
[12:48] <Gunther_> ogra_`: ok. Currently I have just daemons (root) accessing the device. But I would like to give normal apps the access too
[12:48] <Gunther_> ogra_`:  I will put this on the wishlist
[12:49] <ogra_`> Gunther_, kernel and gadget snaps are effectively being re-designed from scratch the next weeks
[12:50] <zyga> Gunther_: you'd have to make an interface for that
[12:50] <zyga> Gunther_: I can guide you but I'm AFK for the next 30 min
[12:50] <Gunther_> zyga: thanks.
[12:51] <ogra_`> zyga, seriously ? for a kernel snap ?
[12:51]  * Gunther_ has to get information about interfaces
[12:51] <primobasilio> Hi guys. I'm using: $ snapcraft --version
[12:51] <primobasilio> 2.8.1
[12:51]  * ogra_` thinks that a bunch of dirs should simply be supported by default ... 
[12:51] <primobasilio> I can't use configFlags in the new version, right?
[12:51] <ogra_`> like udev/rules.d or the GL search path
[12:52] <primobasilio> Issue while loading plugin: [...] Additional properties are not allowed ('configFlags' was unexpected)
[12:52] <primobasilio> So, please, how should I pass parameters to ./configure
[12:52] <ogra_`> (and /etc/modprobe.d ...)
[12:54] <_morphis> zyga: any idea about the reinstall problem already?
[12:57] <popey> Can someone help me with an app I have snapped? lp:snappy-playpen -> mame/mamedeb . Once snapped and installed, if I try and run it, it just fails with a "not found" message, but I can run the exact same command (outside of apparmor/snap) fine. No apparmor denials. It's doing my head in.
[12:57] <popey> this is the output when it's run via "mame.run":-
[12:57] <popey>  /snap/mame/100001/bin/launcher: 16: exec: /snap/mame/100001/usr/games/mame -v -inipath /snap/mame/100001 : not found
[12:57] <mariogrip> why cannot i run snappy apps on 16.04? i get "can not find a snappy os. errmsg: No such file or directory"
[12:58] <popey> mariogrip: sudo snap install ubuntu-core
[12:58] <mvo> ogra_`: thanks, will fix in a sec
[12:58] <mvo> or two
[12:58] <mariogrip> popey: I tried, but i get "error: can't install "ubuntu-core": snap "ubuntu-core" has changes in progress"
[12:58] <popey> ah, i had the same
[12:58] <ogra_`> mbvbeyond that snap list and snap find seem to work fine on the dragonboard here
[12:58] <popey> mariogrip: bug 1571614
[12:58] <popey> I had to nuke the entire world
[12:59] <ogra_`> mvo, what hap0pened to "enable-classic" though ?
[12:59] <popey> so I'd say you've reproduced that bug, could you please mark it so. zyga ^
[12:59] <zyga> _morphis: no, not yet
[12:59] <ogra_`> mvo, was the option dropped ? that will make itr very hard to get the arm64 bug fixed before 16.04 release
[13:00] <_morphis> zyga: ok
[13:00] <mariogrip> popey: is there a workaround?
[13:00] <popey> mariogrip: nuke from orbit.
[13:00] <popey> mariogrip: http://paste.ubuntu.com/15911812/
[13:00] <zyga> popey: reproduce this bug?
[13:01] <mariogrip> is there some logs that will help debug that I can collect before nuking?
[13:01] <popey> zyga: mariogrip has the same issue I had.. snap "ubuntu-core" has changes in progress
[13:02] <zyga> ah, ok
[13:02] <zyga> marcoceppi: can you add the same info to the bug please
[13:02] <zyga> marcoceppi: snap changes (pastebin that)
[13:03] <mariogrip> zyga: was that for me?
[13:03] <zyga> mariogrip: ys, sorry
[13:03]  * zyga hates tab-complete in polair
[13:03] <zyga> marcoceppi: (sorry)
[13:04] <ogra_`> xchat has fixes for that ;)
[13:04] <ogra_`> (moves the person you last talked to to the top of the tab completion list)
[13:06] <mariogrip> zyga: done :)
[13:07] <davmor2> ogra_`: s/xchat/hexchat :P
[13:08] <zyga> mariogrip: thank you
[13:08] <zyga> mariogrip: I'll check it out after our standup
[13:09] <ogra_`> davmor2, depends what you use ... xenial isnt released yet ;)
[13:14] <zyga> popey: did you reslve your problem with mame?
[13:14] <popey> zyga: no
[13:14] <zyga> popey: what's the current state?
[13:14] <zyga> popey: (as in where are you, what works, what doens't)
[13:14] <popey> see 57 mins past
[13:14] <popey> above
[13:15] <mariogrip> popey: I how do i remove /snap? it's read only
[13:15] <popey> mariogrip: sudo ? :)
[13:15] <zyga> mariogrip: on a device you don't have to
[13:15] <mariogrip> popey: tried
[13:15] <zyga> mariogrip: just umount all the stuff inside and rm -rf all the dirs
[13:16] <mariogrip> zyga: how do i unmount a sideloaded snap?
[13:16] <zyga> mariogrip: just unmount the squasfs
[13:16] <zyga> mariogrip: sudo umount /snap/*/*
[13:16] <popey> yeah, mount | grep snap
[13:17] <popey> and unmount all those things
[13:17] <zyga> mariogrip: try this http://paste.ubuntu.com/15911812/
[13:17] <zyga> I'll improve that and add it to devtools
[13:18] <mariogrip> zyga: it worked thanks
[13:18] <dpm> so the recent change from /snaps to /snap on the desktop seems to have broken previously installed apps. I reinstalled ubuntu-core and ubuntu-clock-app, but now on launching it, I get:
[13:18] <dpm> $ ubuntu-clock-app.clock
[13:18] <dpm> appname ubuntu-clock-app.clock not allowed
[13:18] <mariogrip> zyga: btw, umount /var/lib/snapd/snaps/* || true does not works for sideloaded snaps
[13:18] <dpm> any ideas how to fix it? I think somehow the launcher is still seeing the old clock app in /snaps
[13:18] <zyga> mariogrip: ah, thanks
[13:18] <zyga> mariogrip: where are they located?
[13:19] <dpm> which incidentally I don't know how to uninstall
[13:19] <popey> dpm: maybe look in /snap/bin ?
[13:19] <mariogrip> zyga: I have no idea
[13:19] <zyga> dpm: nuke your state
[13:19] <zyga> dpm: and reinstall
[13:19] <popey> yeah, seems the message of today is "Nuke from orbit"
[13:19] <zyga> with the orbital ion canoon
[13:19] <zyga> canon*
[13:19] <dpm> zyga, what can I nuke the state?
[13:19] <dpm> argh, can't type
[13:19] <zyga> dpm: give me a moment, I'm writing a script for that
[13:20] <dpm> *how, I meant
[13:20] <dpm> ok, thanks zyga
[13:20] <dholbach> dpm,
[13:20] <dholbach> sudo umount /var/lib/snappy/snaps/*
[13:20] <dholbach> sudo rm /etc/systemd/system/snaps-*.mount
[13:20] <dholbach> rm -r ~/snaps
[13:20] <dholbach> but there might be more involved than that
[13:20] <dholbach> it's what I noted down at some stage
[13:20] <mariogrip> zyga popey damn, still "error: can't install "ubuntu-core": snap "ubuntu-core" has changes in progress
[13:20] <mariogrip> " after the nuke
[13:21] <zyga> mariogrip: systemctl stop snapd;
[13:21] <zyga> mariogrip: rm -rf /var/lib/snapd/state.json
[13:21] <zyga> that will erase all state
[13:21] <dpm> thanks dholbach. I guess the snaps PATH should be updated too?
[13:21] <ogra_`> ppisati, hmm, did you test the latest raspi2 kernel with the pi3 ? seems i cant get mine to boot anymore
[13:21] <zyga> dpm: they are on the desktop
[13:21] <dholbach> dpm, where?
[13:22] <dholbach> dpm, you might have to rebuild/reinstall the snap, and after installing the new snapd/u-core-launcher/etc probably reboot
[13:22] <dpm> ok
[13:22] <mariogrip> zyga: thanks, it works now
[13:22]  * zyga is lost with various support requests
[13:23] <zyga> it would be great if each person having an issue mentioned if they are on the desktop or a pure-snap image
[13:24] <zyga> _morphis: can you report the bug you had with sideloading please?
[13:25] <_morphis> zyga: sure
[13:25] <zyga> _morphis: I'm afraid most people will just crash quickly today and take some time off
[13:25] <zyga> _morphis: but I don't want to lose track of this
[13:26] <_morphis> zyga: sure
[13:26] <mhall119> how can I edit my snap app's files in place? they're all readonly even for sudo
[13:27] <mariogrip> mhall119: remount -o rw,remount /snap/*/* test if that works
[13:27] <zyga> mhall119: you cannot
[13:27] <zyga> mhall119: those are on a squashfs
[13:27] <mariogrip> not remount use mount
[13:28] <_morphis> zyga: btw. on other thing I noticed with your dev-tools is that copying snap to $HOME breaks snapd or any snap from creating $HOME/snap as directory which is now where $SNAP_USER_DATA is
[13:29] <_morphis> zyga: can propose a PR to fix that but wasn't sure where to put the new snap binary then
[13:29] <zyga> _morphis: ahh, yes
[13:29] <zyga> _morphis: I'll fix that, I saw it too
[13:29] <zyga> _morphis: I just forgot about it
[13:29] <zyga> _morphis: maybe devtools.$1
[13:29] <_morphis> zyga: named it snap-1 for me
[13:29] <zyga> _morphis: e.g. devtools.snap devtools.snapd
[13:29] <_morphis> sounds good!
[13:30] <zyga> would be a clear indication of someone uses that when hacking and reports problems
[13:30] <zyga> _morphis: I'll patch devtools for better desktop support
[13:30] <zyga> _morphis: thanks for looking into this
[13:30] <_morphis> zyga: np
[13:32] <mhall119> mariogrip: didn't work
[13:33] <mhall119> zyga: if I can't make them rw, what's the easiest way to debug a failing python app launch?
[13:33] <zyga> jdstrand: we should plan some work for the support tool for snap developers that adds advice ofr particular interfaces
[13:33] <zyga> mhall119: you cannot because squashfs is inherently read only
[13:33] <zyga> mhall119: what do you see?
[13:33] <zyga> mhall119: I'd suggest adding a shell app
[13:34] <zyga> mhall119: (like in hello-world)
[13:34] <zyga> mhall119: that will let you inspct the state and play around more easily
[13:34] <mhall119> zyga: there are multiple wrapping shell scripts already
[13:34] <zyga> jdstrand: (I'm sorry I forgot the name)
[13:34] <zyga> mhall119: I mean an interactive one
[13:34] <zyga> jdstrand: and add REST API that gives snippets and lists interfaces
[13:34] <mhall119> yeah, I'll inject a pdb call
[13:35] <zyga> mhall119: that's useful too :)
[13:35] <zyga> mhall119: one more thing
[13:35] <zyga> mhall119: snap install --devmode
[13:35] <zyga> mhall119: you can use that to install your snap with non-enforcing confinement
[13:36] <mhall119> it's still using unconfined in snapcraft.yaml
[13:36] <zyga> mhall119: that's useless
[13:37] <zyga> mhall119: it doesn't do anything
[13:37] <zyga> mhall119: can you pastebin your snapcraft.yaml
[13:37] <oparoz> zyga, unknown flag `devmode' Is that on edge only?
[13:37]  * zyga feels he should blog about interfaces
[13:37] <zyga> oparoz: that's in 2.0
[13:37] <zyga> oparoz: (images are somewhat broken today)
[13:37] <zyga> oparoz: we're fixing that to make building new images possible
[13:37] <oparoz> Thanks zyga
[13:38] <mhall119> zyga: well it builds a snap I can sideload, my problem right now is that setuptools and pkg_resources can't find the script to launch my app
[13:38] <mhall119> zyga: but http://paste.ubuntu.com/15913016/ if you want to look at it
[13:39] <zyga> mhall119: can you please pastebin some output?
[13:39] <zyga> ah
[13:39] <zyga> :D
[13:39] <zyga> sorry
[13:40] <zyga> mhall119: drop the no-security plug
[13:40] <zyga> mhall119: add unity7 plug
[13:40] <zyga> mhall119: debug snapcraft issues with sergio
[13:40] <zyga> mhall119: I can help with runtime
[13:41] <daker> ogra_: the snappy command is still in the image
[13:41] <zyga> mhall119: you can use setup/ to create a desktop file and icon
[13:41] <zyga> (later)
[13:41] <ogra_> daker, then there might also still be the "enable-classic" option to it
[13:41] <zyga> daker: images are somewhat broken, not based on snappy 2.0
[13:41] <daker> ogra_: yes snappy enable-classic it working now
[13:41]  * zyga stops saying that over
[13:42] <ogra_> good ... better dont upgrade then :)
[13:42] <ogra_> zyga, he is not using a 2.0 image
[13:42] <zyga> right
[13:42] <daker> zyga: no problem, i just want to produce an armhf snap for snapcraft 1.x
[13:42] <ogra_> good enough to get a classic shell
[13:42] <zyga> yep
[13:43] <_morphis> zyga, jdstrand: https://github.com/ubuntu-core/snappy/pull/1036
[13:44] <mhall119> zyga: I don't think these are snapcraft issues specifically
[13:44] <zyga> mhall119: can you be more specific please? can you pastebin the error you're seeing?
[13:44] <sergiusens> hey, just finally reconfigured my `shout` snap
[13:44] <mhall119> I think it's a python2/setuptools issue
[13:45] <zyga> ah
[13:45] <sergiusens> what errors are you mhall119 and zyga talking about?
[13:45] <zyga> mhall119: I can help with that as well
[13:45] <sergiusens> oh
[13:45] <sergiusens> carry on
[13:45] <zyga> _morphis: nice!
[13:45] <sergiusens> -)
[13:45] <zyga> sergiusens: no no, you can take over
[13:45] <zyga> I should do this "sleep" thing that people say is good for your health
[13:45] <mhall119> zyga: http://paste.ubuntu.com/15913119/
[13:45] <mhall119> sergiusens: ^^
[13:45] <sergiusens> zyga no, I'm preparing a final snapcraft release
[13:46] <sergiusens> no can do
[13:46] <zyga> ok
[13:46] <_morphis> zyga, jdstrand: policy wise there is still room for improvements and I am not sure if I did everything the right way
[13:46] <zyga> mhall119: can you share the setup.py file?
[13:46] <zyga> _morphis: I'll check it out, thanks, nice work :)
[13:47] <_morphis> zyga: thanks :-)
[13:47] <_morphis> zyga: and I must say, it didn't took me as long as I suspected
[13:47] <mhall119> zyga: http://paste.ubuntu.com/15913162/
[13:48] <mhall119> zyga: I just pushed my local bzr changes to lp:~mhall119/hello-unity/snap
[13:49] <zyga> mhall119: can you psatebin the content of the squashfs file
[13:49] <zyga> k
[13:49] <ogra_> beuno, or mvo, can one of you approve https://myapps.developer.ubuntu.com/dev/click-apps/4870/rev/1/ ?
[13:49] <mhall119> zyga: the what now?
[13:49] <mhall119> my .snap is 101MB
[13:49] <zyga> mhall119: just wait one sec, branching
[13:50] <mhall119> zyga: my snapcraft project files are all in lp:snappy-playpen too
[13:51] <daker> ogra_: http://pastebin.ubuntu.com/15913217/
[13:51] <ogra_> daker, snappy shell classic
[13:51] <daker> ah
[13:52] <daker> ogra_: sudo: no tty present and no askpass program specified
[13:52] <daker> when running sudo apt-get install snapcraft
[13:53] <ogra_> bug 1564369
[13:53] <ogra_> (has a workaround)
[13:53] <beuno> ogra_,
[13:53] <beuno> checksums do not match. Please ensure the snap is created with either 'snapcraft snap <DIR>' or 'mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs' security-snap-v2_squashfs_repack_checksum
[13:53] <daker> ok
[13:53] <beuno> ogra_, I'd double check that one
[13:53] <ogra_> beuno, oh, come on
[13:53] <beuno> ogra_, I don't make the rules!
[13:53] <ogra_> ()it is the same script i use for all gadgets )
[13:54]  * ogra_ re-works 
[13:55] <ogra_> beuno, i dont need to bump the version anymore, right ?
[13:55] <beuno> ogra_, correct
[13:57] <ogra_> beuno, https://myapps.developer.ubuntu.com/dev/click-apps/4870/rev/2/ now ...
[13:59] <beuno> ogra_, approved
[13:59] <ogra_> thx
[14:02] <popey> zyga: when you're free, if you have any ideas about my mame issue I'd appreciate a look, thanks.
[14:03] <zyga> popey: still checking the problem for mhall119
[14:03] <popey> okay
[14:03] <popey> damn you mhall119 for jumping the queue!
[14:04] <ogra_> popey, calm down ... he's not british
[14:04] <mhall119> USA! USA! USA!
[14:04] <popey> Oh I'm calm. tutting under my breath as I drink tea
[14:05] <mhall119> that's british rage right there
[14:06] <ogra_> because the words "tutting" and "tea" are in the same sentence ?
[14:07] <popey> http://3.bp.blogspot.com/-w_4ts9QQ7Bc/TmgikmOhonI/AAAAAAAAAOk/kzDF0596rf4/s1600/anarchy-in-the-uk.jpg
[14:07] <mhall119> it's basically what cursing and whiskey is in the USA
[14:07] <mhall119> popey: lol
[14:07] <ogra_> hah
[14:10] <jdstrand> zyga (fyi, mvo): bug #1571675
[14:11] <zyga> mmm
[14:12] <jdstrand> mvo: is 'snap list' supposed to not show the os and gadget snaps any more?
[14:13] <jdstrand> mvo: is it no longer possible to see if there is a newer snap available? to run the equivalent of 'snappy update'?
[14:14] <zyga> jdstrand: replied
[14:14]  * zyga is hammering his cpu with mksquashfs
[14:14] <zyga> jdstrand: it shows all snaps
[14:14] <zyga> jdstrand: snap refresh (except store bugs)
[14:14] <mvo> jdstrand: devices are all broken currently
[14:14] <jdstrand> zyga: snap list does not show the os snap
[14:14] <zyga> jdstrand: then it is not installed
[14:14] <mvo> jdstrand: and snap refresh is not working the same way it was before
[14:14] <jdstrand> zyga: it has to be
[14:14] <zyga> jdstrand: images are broken
[14:14] <mvo> jdstrand: sorry, those will be fixed soon
[14:14] <jdstrand> I used udf and booted it :)
[14:14] <mvo> jdstrand: images also have branches up
[14:15] <jdstrand> ok
[14:15] <mvo> jdstrand: yeah, it boots that is about it ;)
[14:15] <jdstrand> I see
[14:15] <jdstrand> is there a bug for that?
[14:15] <zyga> jdstrand: not sure
[14:15] <mvo> jdstrand: hopefully (once my branch gets reviewed) it will be good again
[14:15] <jdstrand> I'd like to follow it so I don't bother you guys
[14:15] <mvo> jdstrand: https://github.com/ubuntu-core/snappy/pull/1033 this is the best bet right nw
[14:16] <jdstrand> mvo: curious, is the equivalent of 'snappy service' coming back or is it dead?
[14:16] <mvo> jdstrand: I am not sure, I personally really want it back as its so much nicer than systemctl, but it was not discussed in a wider group yet
[14:16] <ogra_> sprint topic ;)
[14:16] <jdstrand> mvo: I was thinking exactly the same thing
[14:17] <jdstrand> systemctl is quite low level
[14:17] <zyga> mhall119: that's a snapcraft bug
[14:17] <zyga> mhall119, sergiusens: http://pastebin.ubuntu.com/15913598/
[14:18] <zyga> that's the content of the script in the snap
[14:18] <zyga> note the shebangline #!/tmp/foo/parts/hello-unity/install/usr/bin/python2
[14:18] <zyga> mhall119: I'll stop working on this now
[14:18] <zyga> mhall119: please report this to sergiusens
[14:18] <zyga> I can share the small modifications I made to make this easier to work with
[14:20] <daker> ogra_: from time to time it seems to me that i lost the ssh session
[14:21] <ogra_> hmm
[14:21] <daker> the console doesn't seems to responds or it takes seconds for the characters to appear
[14:21] <daker> maybe a network lag ?
[14:21] <ogra_> sunds like a network issue
[14:24] <daker> ok, just want to confirm it's not an issue with in ubuntu core
[14:24] <ogra_> i dont see it here
[14:25] <zyga> popey: re
[14:27] <mhall119> zyga: I don't think the hashbang line is being used
[14:29] <mhall119> zyga: /snap/hello-unity/current/bin/hello-unity calls `usr/bin/python $SNAP/usr/bin/hello-unity` so it's using the the python executable from /snap/hello-unity/current/usr/bin/python
[14:30] <mhall119> the shebang is still wrong, but it's not the cause of my problems
[14:30] <zyga> mhall119: ah, I didn't use the wrapper script, just the tree and the snapcraft file you've pasted
[14:31] <mhall119> the cause is somewhere in pkg_resources, the right version of that is being called, but it's not finding the script
[14:33] <sergiusens> mhall119 zyga setup_tools replaces it; we make it proper in the wrapper script but it has to be declared in `apps`
[14:33] <sergiusens> with a `command`
[14:49] <mhall119> sergiusens: are you talking about the shebang?
[14:50] <sergiusens> yes
[14:50] <mhall119> I still don't think that's my problem, unless that will cause pkg_resources.call_script to ignore it
[14:50] <sergiusens> zyga that shebang modification is hard coded into python core libs
[14:51] <zyga> sergiusens: I see
[14:51] <zyga> sergiusens: does that happen with entry points as well?
[14:52] <sergiusens> zyga entry points if not part of `apps/<app>/commands` will not work
[14:52] <zyga> sergiusens: right, I always assume there's an app entry
[14:52] <sergiusens> zyga blame crappy python's lack of easy distribution
[14:53] <ysionneau> sergiusens: hi! sorry to insist about this topic but do you have any idea about my image generation issue (the mailing list thread)? Do you need more information from me?
[14:55] <sergiusens> ysionneau which one was it?
[14:55] <sergiusens> ysionneau it might be many things, as many thing changed this past week; mvo iirc put up a new u-d-f even
[14:56] <ysionneau> I'll try with the new one then!
[14:56] <ysionneau> sergiusens: it was this thread https://lists.ubuntu.com/archives/snappy-devel/2016-March/001668.html
[14:57] <mvo> ysionneau: https://github.com/ubuntu-core/snappy/pull/1033 needs to land before images work again
[15:00] <ysionneau> ok I guess this is "another" issue, since I already had issues even before the 2.0 was out
[15:00] <ysionneau> right?
[15:01] <ogra_> there are plenty of issues
[15:13] <sborovkov> Hi. I built snappy for RPI with latest kernel/os snap. It does not load - on RPI 3 it shows gradient on whole screen and nothing else happens. On Rpi 2 it prints some progress until message with `Starting kernel...` - and stops at that. Any ideas what could be wrong?
[15:14] <ogra_> sborovkov, hmm, i just built an image, works fine
[15:14] <sergiusens> ysionneau well I never saw that reply :-)
[15:15] <ogra_> sborovkov, using:  sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi2 -o test.img
[15:15] <sergiusens> ysionneau but as ogra_ pointed out; there is some cleanup that needs to happen
[15:15] <ogra_> or sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi3 -o pi3-test.img
[15:16] <ogra_> sborovkov, both with the latest ubuntu-device-flash from http://people.canonical.com/~mvo/all-snaps/
[15:20] <sborovkov> ogra_: hmm, may be I have something outdated in my files. I will try that, thanks.
[15:21] <primobasilio> Anyone can point me out a good source of documentation on how should I use --target-arch for autotools. At least, I would like to use i386 and AMD64.
[15:21] <ogra_> sborovkov, note that the pi2 has some issues with the serial console currently ... (working on that this week)
[15:22] <ogra_> you might not get a login prompt on serial, even though the device boots fine
[15:30] <sborovkov> ogra_: is gadget snap for rpi3 not compatible with rpi2? I remember loading with gadget snap for rpi2 on rpi3 like a week ago
[15:31] <ogra_> sborovkov, until end of this week it will be ... i'm just changing that because we cant make the serial consiole work on the pi2 with the uboot that would support both
[15:32] <sborovkov> Got it, thanks
[15:32] <daker> ogra_: \o/ : Snapped micropython_1.7.1_armhf.snap
[15:32] <ogra_> yay !
[15:33] <daker> i still need to figure out ssh session freeze
[15:33] <daker> i suspect the sdcard becomes slow
[15:49] <mariogrip> I have added the mount_observe interface, but apparmor still denied r to /proc/9955/mount
[15:55] <daker> ogra_: got some wired stuff here http://pastebin.ubuntu.com/15915224/ :D
[15:56] <ogra_> daker, you probably want to ship your own libc and libm then
[15:56] <ogra_> seems it tries to use the system libm there
[15:58] <mhall119> sergiusens: so either pkg_resources is looking in the wrong place, or setuptools is installing things into the wrong place
[15:59] <mhall119> sergiusens: pkg_resourcs is looking for /snap/hello-unity/100001/usr/lib/python2.7/dist-packages/hello_unity-0.4.egg-info/scripts/hello-unity
[15:59] <mhall119> but setuptools puts it in /snap/hello-unity/100001/usr/lib/python2.7/dist-packages/hello_unity-0.4-py2.7.egg/EGG-INFO/scripts/hello-unity
[16:00] <daker> ogra_: :/
[16:02] <mariogrip> I see why, pid 9955 is python2 but the apps pid id 9954. then how do i set mount_observe for python2?
[16:03] <mhall119> sergiusens: even after fixing that, it doesn't look like the python GObject Introspection stuff is there
[16:09]  * mhall119 tries adding python-gi to snapcraft.yaml
[16:12] <ysionneau> ok thanks ogra_ and sergiusens
[16:13] <ysionneau> another question, is it possible when writing a snap containing a service : to provide the systemd unit file
[16:13] <ysionneau> to provide the activation socket for instance
[16:14]  * kyrofa snags ogra_'s hug from the backscroll
[16:14] <kyrofa> ogra_, I take it the bug was fixed?
[16:14] <ogra_> s390x builds fine at least :)
[16:15] <kyrofa> ogra_, good to hear! :)
[16:15] <mhall119> `snap install <local.snap>` spit out:
[16:15] <mhall119> error: change finished in status "Hold" with no error message
[16:17] <ysionneau> ah I see there is a "socket" keyword
[16:17] <mhall119> and `snap remove <package>` now gives me:
[16:17] <mhall119> error: can't remove "hello-unity": snap "hello-unity" has changes in progress
[16:18] <jdstrand> mariogrip: you don't have to worry about the particular pid. mount_observe is not 'autoconnected' so you'll need to manually connect after install
[16:18] <jdstrand> zyga would be the person to ask about manual connecting. It wasn't working as of friday (for me), but several updates came in over the weekend
[16:19] <jdstrand> that said, all connecting may be broken due to bug #1571675
[16:19] <jdstrand> (and that is being worked on AIUI)
[16:26] <mariogrip> jdstrand: yeah, but I have a python2 app, but apparmor denies python to access /proc/*/mounts
[16:27] <mariogrip> jdstrand: python2 has a different pid then my main app,
[16:30] <jdstrand> mariogrip: I understand. the mount_observe has something like this: '/proc/*/mounts r,' so the actual pid doesn't matter. the problem is that the rule I just mentioned isn't added to your policy
[16:31] <jdstrand> so you have to manually connect it
[16:32] <mariogrip> jdstrand: in https://github.com/ubuntu-core/snappy/blob/master/interfaces/builtin/mount_observe.go it says  @{PROC}/@{pid}/mounts r
[16:32] <jdstrand> yes
[16:32] <jdstrand> @{pid} turns into '{[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}'
[16:32] <nothal> jdstrand: No such command!
[16:33] <jdstrand> which is similar to a glob
[16:33] <jdstrand> point is, you don't have to worry about the pid number
[16:33] <mariogrip> ah, ok
[17:21] <roadmr> jdstrand, beuno : click-reviewers-tools r630 is now live on myapps
[17:21] <roadmr> beuno: I also fixed that "Is a valid click package" thing, that's also up now
[17:32]  * beuno hugs roadmr 
[17:38] <jdstrand> thanks!
[17:42] <wililupy_> Question: I updated my xenail build machine today, and it removed ubuntu-snappy so I don't have the snappy command anymore, is this in a different package now? apt-cache says snappy is in the snappy package, but that is not the correct snappy for building snaps :)
[17:44] <ogra_> wililupy, the command was renamed to snap ... the package is snapd iirc
[17:45] <ogra_> (but that is for executing snaps ... for bulding snaps you use snapcraft ;) )
[17:45] <ogra_> s/executing/managing/
[17:46] <kyrofa> wililupy, were you using `snappy build`?
[17:47] <jcastro> error: can't remove "shout": snap "shout" has changes in progress
[17:47] <jcastro> how do I resolve these kind of errors?
[17:47] <jcastro> I think my snappy is in some kind of weird state
[17:47] <wililupy> yes
[17:47] <wililupy> ogra_ yes
[17:49] <wililupy> ogra_ My script for building a snap was fakeroot snappy build --squashfs unpack-kernel so that I could install custom modules for my kernel snap.
[17:49] <ogra_> snappy buuld is deprecated
[17:50] <ogra_> use snapcraft snap
[17:53] <kyrofa> wililupy, indeed, what ogra_ said. You can use snapcraft to build the entire thing, or you can just use `snapcraft snap <directory>` the way you're using `snappy build` now
[17:55] <wililupy> kyrofa: I'll try that. I have my kernel dirctory all open and I have my modules put in place, I'll try to snapcraft snap 4.4.0-18-im and see what happens :)
[17:56] <kyrofa> wililupy, should work as long as your meta/ directory is good
[17:56] <kyrofa> wililupy, I do suggest you investigate building your kernel with snapcraft when you're able
[17:56] <kyrofa> wililupy, might simplify your workflow
[18:00] <netpheak> Tried installing the http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ubuntu-snappy-armhf+rpi2.img.xz image on my RPI3, but all i get is a a block of rainbow colors on the screen.
[18:01] <wililupy> kyrofa, ogra_: http://pastebin.ubuntu.com/15918217/
[18:01] <kyrofa> wililupy, ah, this is ollld
[18:01] <kyrofa> wililupy, 15.04 must be your target?
[18:02] <wililupy> no, 16.04
[18:02] <genii> The pi3 has an A53
[18:02] <kyrofa> wililupy, then yeah, you're a bit out of date. This has since moved to snap.yaml, and the syntax has changed
[18:02] <kyrofa> wililupy, I do strongly suggest you begin using snapcraft then
[18:04] <kyrofa> wililupy, something like this: https://github.com/ubuntu-core/snapcraft/blob/master/examples/96boards-kernel/snapcraft.yaml
[18:05] <genii> netpheak: Have you tried http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ubuntu-snappy-amd64.img.xz instead?
[18:05] <genii> Sorry, wrong one
[18:05] <genii> The arm64
[18:05] <wililupy> kyroga, I have tried that one, but it doesn't run depmod on my custom modules so when the system starts up, I have to insmod them everytime...
[18:06] <netpheak> Hmm.. didn't know the PI3 already had 64 bit support?
[18:07] <netpheak> I think the 64bit one is for the dragonboard
[18:09] <kyrofa> wililupy, ah, okay. Might be a bug in the kernel plugin?
[18:10] <kyrofa> wililupy, you can get around it by making a custom kernel plugin for your local snap, or do what you're doing now, and learning the new snappy 16 syntax
[18:11] <wililupy> kyrofa, not sure. I tried to build the modules from source using snapcraft and then using the kernel plugin to build and install the new kernel, but it would build against the kernel headers on my system and not the ones I wanted to use in Snappy. So I decided to precombile them and use the copy plugin to put them in the lib/modules/* directories I needed, but it doesn't run depmod so I have to insmod after a reboot.
[18:12] <wililupy> kyrofa, what I could do is create a script that will run when I start my application snap to run insmod to make sure that the modules are loaded before starting. Can be a work around until I can figure out how to build and install the customer modules using snapcraft.
[18:13] <kyrofa> wililupy, you'll probably run into confinement issues with that, though I suspect you're running unconfined?
[18:16] <wililupy> kyrofa, yes.
[18:18] <kyrofa> wililupy, so I imagine your ideal workflow would be to have a kernel part, and a modules part that runs after the kernel part using that kernel's headers, and then it would be smart enough to call depmod. Would you agree with that (I know it doesn't work that way right now)?
[18:19] <wililupy> kyrofa: yes. Or, just be able to make a kernel snap from .deb :)
[18:20] <wililupy> kyrofa: I can compile and build everything fine, and then create a deb with all of this done already. If I could just create a kernel snap from my deb package, that would be much easier. I have a "feature request" bug in lp for this :)
[18:21] <ogra_> netpheak, grab ubuntu-device-flash from http://people.canonical.com/~mvo/all-snaps/
[18:21] <ogra_> netpheak,  sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi3 -o pi3-test.img
[18:21] <wililupy> lp: 1565058
[18:22] <ogra_> (and make sure to have a network cable attached when booting, there seems to be some bug with the NIC when not)
[18:23] <netpheak> ogra_: where do the kernel, gadget etc come from?
[18:23] <ogra_> the store
[18:25] <wililupy> kyrofa: http://pastebin.ubuntu.com/15918492
[18:26] <kyrofa> wililupy, your kernel source is '.'. I remember talking about the possibility of placing your modules within the kernel source itself-- did you ever try that?
[18:28] <wililupy> kyrofa, I did, and it failed to build. I tried puting them in staging and modifying the Kconfig, but becuase some modules have the same name, it failed to build.
[18:33] <wililupy> kyrofa, I tried two different ways. I like tha idea of a kernel snap, and then a module snap. I wonder how hard it would be to create a modifed kernel plugin. I am looking at /usr/lib/python3/dist-packages/snapcraft/plugins/kernel.py and kbuild.py right now.
[18:46] <netpheak> Is there any way to setup an image, to enable drive encryption?
[19:04] <netpheak> ogra_: how do i enable classic mode?
[19:04] <netpheak> snappy enable-classic does not work
[19:42] <kgunn> sergiusens: hey what was the snap tool arg was it "--devmode"?
[19:43] <kgunn> e.g. snap install --devmode *.snap?
[19:43] <kgunn> to ignore interfaces for a moment
[19:45] <kgunn> jdstrand: ^ ?
[19:45] <jdstrand> --dev-mode is what was typed into the chat
[19:45] <jdstrand> I haven't tried it yet
[19:45] <jdstrand> hmm
[19:46] <jdstrand> snap install --help
[19:46] <jdstrand> it says '--devmode'
[19:48] <kgunn> jdstrand: also, is the ubuntu-core  different than if i stitch an image with u-d-f?
[19:48] <kgunn> snap install --help doesn't say anything there...
[19:48] <kgunn> SDoC is ahead of devices?
[19:50] <jdstrand> kgunn: udf will pull from the store by default. If you grabs snaps from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ they will be newer most of the time
[19:50] <jdstrand> grab*
[19:50] <jdstrand> I don't know if there are up-to-date downloadable images available yet
[19:50] <jdstrand> I think they are being worked on? ogra_ would know best I think
[19:52] <kgunn> jdstrand: but i'm just talking about the snap cli
[19:53] <kgunn> i just built an ubuntu-core-image from moments ago
[19:53] <kgunn> would think it's basically what's in archive
[19:53] <kgunn> but maybe not...i suppose the snaps there take a bit to update
[19:53] <kgunn> i see...
[19:53] <kgunn> what you mena
[19:56] <jdstrand> fyi, I'm stepping into a meeting and may be unresponsive for a bit
[20:11] <almejo> hi! I have a question about snappy for desktop. I now I can create snap packages in 16.04. But how can i test them. Should i upload to the store? or can i install it with the command line
[20:12] <primobasilio> almejo: you can install them using the command line. Even inside a clean Ubuntu Core kvm image.
[20:24] <ogra_> kgunn, jdstrand, to get the very latest you wuld have to use the cdimage snaps ... they are not auto-submitted to the store yet
[20:25] <ogra_> so there is delay until someone manually uploads them
[20:29] <daker> ogra_: so, if i want to snap package libc & libm, how can i automagically do that ?
[20:29] <ogra_> i'd use the copy plugin
[20:30] <ogra_> put them into stage-packages and copy them into your snap dir
[20:30] <daker> ogra_: any example to do that ?
[20:31] <daker> or i just need to check the snapcraft examples
[20:31] <daker> ?
[20:31] <ogra_> no up to date one in my packages atm
[20:31] <ogra_> so yeah, the examples are probably best
[20:31] <daker> ok i'll check them
[20:55] <daker> ogra_: if i understand correctly, i need to the .so from /lib/arm-linux-gnueabihf/ to the snap dir
[20:55] <daker> to copy*
[20:57] <daker> but how can i tell the snap to take account of the new libm/libc and not the system ones
[21:02]  * daker is confused
[21:05] <jdstrand> ogasawara: right-- how often are they generated?
[21:06] <jdstrand> err
[21:06] <jdstrand> ogasawara: nm
[21:06] <jdstrand> ogra_: ^
[21:06] <ogasawara> :)
[21:06] <jdstrand> :)
[21:12] <skypce> hell
[21:12] <skypce> hello
[21:13] <skypce> ca i install snappy package in ubuntu 16.04 beta 1?
[21:13] <skypce> how can i do  it?*
[21:13] <skypce> i want test it
[21:13] <skypce> :)
[21:46] <ogra_> jdstrand, daily
[21:46] <ogra_> like isos :)
[21:50] <jdstrand> right, that is what I though. thanks! :)
[22:09] <roadmr> Are https://people.canonical.com/~mvo/all-snaps/ going to be updated? If not, where to get a suitably up-to-date image?
[22:09] <ogra_> best is to build your own using the ubuntu-device-flash from there
[22:10] <roadmr> thanks ogra_! will do
[22:10] <ogra_> udo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pc-linux --gadget canonical-pc -o my-shiny-snappy.img
[22:10] <ogra_> something like that
[22:11] <roadmr> awesome :) (sudo)
[22:33] <daker> ogra_: almost there :D
[22:43] <wililupy> Ok, so I downloaded 4.4.0-18-generic source using apt-get source linux-image-4.4.0-18-generic, it installed in the linux-4.4.0 directory in my home directory. I build the snap with snapcraft snap, it builds, but for some reason, it builds /lib/modules/4.4.6? Am I missing something from my snapcraft.yaml or should I modify the source image name?
[22:44] <wililupy> Also, uname -r in snappy says 4.4.6
[23:15] <MichaelTunnell> will Snappy work with GNOME Software in 16.04?
[23:15] <MichaelTunnell> I know that it could in the future because of the plugin structure of the app but just curious if that will be included
[23:24] <sergiusens> ok, I am now finally on irc after a `snap install shout` on Digital Ocean :-)
[23:25] <sergiusens> oh and with letsencrypt
[23:27] <MichaelTunnell> whats shout
[23:35] <sergiusens> MichaelTunnell http://shout-irc.com/
[23:38] <MichaelTunnell> dang, no dark mode puts me out instantly
[23:38] <MichaelTunnell> I could make one sure but meh
[23:39] <sergiusens> MichaelTunnell there are dark themes fwiw
[23:40] <sergiusens> jdstrand can you help me out with http://paste.ubuntu.com/15922408/
[23:40] <sergiusens> please ? :-)