=== tyhicks` is now known as tyhicks === chihchun_afk is now known as chihchun === shuduo-afk is now known as shuduo === Guest12521 is now known as devil_ [06:21] How do I install a sideloaded x.snap with "snap" instead of "snappy"? [06:23] sudo snap install [06:42] 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] hohum.... [06:42] which version of snapd is this? [06:43] I am running mvo's allsnap amd64 image [06:43] do you know if everything is up to date on the system? [06:45] I did run "snappy update" [06:46] Currently looking how to ask snapd for its version ... [06:48] if nobody has an answer for you, you could just try mailing the snappy-devel mailing list [06:49] if it's a bug you're facing, this should be looked at === chihchun is now known as chihchun_afk [06:50] dholbach: I will do that. First I need to find out the version of the install tools [06:50] ok :) === chihchun_afk is now known as chihchun [07:19] hi, guys! [07:27] good morning all [07:28] morning [07:47] mvo ogra_ hi, may i know if kernel snap for dragonboard canonical-dragon-linux is exist in edge channel? [07:49] On mvo's allsnap image: How do I find out the installed version of snap, snapd? [07:52] Gunther_: /usr/share/snappy/dpkg.list contains a list of deb packages [07:52] mvo: thanks [07:53] Gunther_: I need to do new images, they are a bit outdated right now [07:55] ok then I will wait before reporting the bugs I seem the have to see if they still exist [07:55] with the new images === jibel_ is now known as jibel [08:51] <_morphis> zyga, jdstrand: got NetworkManager now mostly working [08:52] _morphis: woot, great [08:52] _morphis: any issues (apart from 1571497) [08:52] <_morphis> zyga: I suspect auto-connect isn't implemented yet, right? [08:52] _morphis: it is implemented [08:53] _morphis: but connection only happens on snap install time [08:53] _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] _morphis: *and* the interface slot has to be on the OS snap [08:53] <_morphis> ah [08:53] _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] _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] _morphis: no, that will not work [08:54] _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] _morphis: hint, no need for the top-level plugs/slots [08:55] <_morphis> s/I wont/it wont/ [08:55] _morphis: correct [08:55] _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] _morphis: try this http://pastebin.ubuntu.com/15909347/ [08:56] _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] _morphis: we *might* do something special if the interface name matches the snap name [08:57] _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] _morphis: ahh, right [08:57] _morphis: and gustavo also said we cannot have plug and slot sharing the same name in one snap [08:57] _morphis: sorry, forget my advice please [08:57] <_morphis> :-) [08:57] <_morphis> zyga: but maybe we can improve the automated naming here [08:57] _morphis: still, feels like something we should auto-connect, just looking for a pattern [08:58] _morphis: yes though this needs to be discussed firstr [08:58] <_morphis> sure [08:59] _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] ah, I plan to retrun to bluez soon and make it actually understand the connections made [09:00] 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] _morphis: sure [09:02] _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] _morphis: not working much [09:03] <_morphis> ah [09:03] _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] :) [09:03] <_morphis> publishing is a bit ahead [09:03] cool, that's great [09:03] <_morphis> zyga: nice work on those dev-tools :-) [09:03] question: how will the interface work on the desktop [09:04] <_morphis> zyga: for bluez and networkmanager? [09:04] 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] _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] _morphis: fors snappy "for devices"? [09:07] _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] _morphis: in daily image, the next day, in ubuntu 16.04 -- not sure [09:08] _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] _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] shuduo, it is called linux-snapdragon since the switch to a 4.4 base [09:34] err [09:34] sorry ... canonical-snapdragon-linux [09:57] 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] sounds more like you are using a to old ubuntu-device-flash [10:00] make sure to have the latest one from mvo's all-snaps dir [10:00] shuduo: and use "edge" for the channel [10:00] shuduo: there is still a bit of breakage right now, I'm working on the fix [10:01] 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] mvo: after specify edge, i got "failed to install "linux-snapdragon" from "edge": linux-snapdragon failed to install: snap not found [10:13] 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] shuduo, note that i corrected myself above [10:14] sorry ... canonical-snapdragon-linux [10:16] 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] shuduo: yes, snapcraft snap . [10:16] shuduo: snapcraft snap targetdir [10:19] 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] sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-snapdragon-linux --gadget canonical-dragon -o test.img [10:20] all official kernels are canonical-$arch-linux nowadays ... where $arch is one of pc, snapdragon, raspi2 [10:21] non official ones can indeed be named as the like [10:21] 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] zyga, whyx do you say this all the time ... images arent broken :) [10:22] ogra_: with snappy 2.0? [10:22] the dropped config bit makes it a bit harder to set thjem up ... and none of the snaps from the store work [10:22] well, they worked on friday [10:22] ogra_: I suspect they are broken now, we're discussing how to fix that (firstboot et all) [10:23] the images themselves are fine though [10:23] ogra_: shades of gray [10:23] heh [10:23] ogra_: but thanks for telling me :) [10:23] if they are broiken now, it must be the punishment for mvo not spending his weekend with the family :P [10:25] ogra_: and the solution is to not spend time with the family again to fix them :-( [10:25] zyga: pls let me know where i can download your ubuntu-image script. thanks. [10:26] ogra_: snap list is empty right now too, the images boot though [10:26] shuduo: github.com/zyga/devtools [10:26] zyga, yeah, its a doom loop === davmor2_ is now known as davmor2 [10:32] ogra_: part of the solution is to snap doom so that we can get some R&R [10:33] +1 !! [10:37] zyga, cool! :) [10:38] ogra_: that means all snapdragon family SoC be supported by a single kernel, right? [10:39] 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] is SNAP_APP_DATA_PATH still correct or has its name changed recently? === Trevinho_ is now known as Trevinho === davidcalle__ is now known as davidcalle_ === mjl_ is now known as mjl [11:14] (specifically - what's the environment variable which points to the writable area? [11:15] SNAP_DATA [11:15] iirc [11:16] aha! [11:16] yes, thanks. [11:17] 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] Good morning [11:26] 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] Gunther_: but you should be albe to send a signal to the daemon from using an app from the same snap [11:27] _morphis: looking [11:35] $ sudo snap remove mame [11:35] error: can't remove "mame": snap "mame" has changes in progress [11:35] what does that mean? [11:37] zyga: thanks [11:38] zyga: I assumed I have to [11:38] popey, someone broke into your system and is secretly playing pacman ? [11:38] * ogra_` has no clue :) [11:38] ogra_`: i have snappy ubuntu core running on rpi2, how can i apt snapcraft 1.x ? [11:39] dayou can only use snapcraft 1.x in pre-xenial systems [11:39] but the 15.04 snappy did not have the classic shell ... so you would need a chroot [11:39] i can't add or remove anything [11:39] (or lxc container or so) [11:40] popey: it means that there are changes operating on that snap now, can you please pastebin "$ snap changes" [11:40] http://paste.ubuntu.com/15911444/ [11:40] zyga: ^ [11:40] popey: thanks, can you report a bug with this information [11:40] sure, where? [11:41] popey: is that on 2.0? [11:41] popey: launchpad.net/snappy please [11:41] ogra_: i didn't manage to run an armhf lxc container [11:41] up to date 16.04 [11:41] ok [11:42] 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] (or use the 15.10 tarball ... probably easier to get a newer snapcraft with that) [11:43] popey: can you try snap abort "snap abort" the changes related to those snaps? [11:43] zyga: https://bugs.launchpad.net/snappy/+bug/1571614 [11:43] Launchpad bug 1571614 in Snappy "Can't add or remove snaps 'snap "mame" has changes in progress'" [Undecided,New] [11:44] zyga: what change ID do I use? [11:50] 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] well, recent mainline should have all you need [11:51] for older kernels the security team has backported patches ... but only for a certain set [11:52] https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels might help [11:52] ogra_`: thanks [11:52] (note that snappy needs at least 3.10 though ... forget about the 3.4 patches :) ) [11:54] 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] that should have all patches [11:54] ok [11:55] (read, your issue is most likely a config thing) [11:55] I just looking for the correct "essential" configuration :) [11:56] popey: thanks [11:56] ogra_`: if i want to use my actual snappy installation(without touching anything), i just need to use snapcraft 2.x ? [11:56] popey: those of the changes related to the snap you were trying to install/remove [11:57] 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] zyga: error: cannot abort change 3 with nothing pending [11:58] zyga: there's a bunch on Hold. [11:58] ogra_`: when the 16.04 image is going to be available :) ? [11:59] the first alpha should be available soon [11:59] until then you need to use the inofficial ones [11:59] ogra_`: where can i find one ? [12:00] http://people.canonical.com/~mvo/all-snaps/ [12:00] of course you have one :D [12:00] and for pi3 http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/ [12:01] rpi2-all-snap.img.xz is the one i am looking for ? [12:01] yes [12:01] ok thanks! i'll test that [12:01] ogra_`: oh, can I patch ubuntu-image for pi3? [12:02] zyga, well, the pi2 image should work as is atm .... if you build from the store [12:02] ogra_`: ok [12:02] ogra_`: I'll patch the script today [12:02] (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] i'll most likely introduce a canonical-pi3 gadget [12:04] ogra_`: yep, that would be good [12:04] ogra_`: even if the only different thing is a name [12:04] well, then we cant easily do a 64bit image [12:05] i would really like to have a generic pi image that works on both for 32bit [12:06] Ogra: When is an official RPI3 release expected? [12:07] netpheak, with the offical snappy 16.04 release [12:07] ok, thx ;) [12:07] in a month or two or so [12:08] zyga: is it easier to nuke everything and start again? If so, how do I nuke all of snap? [12:08] popey: yes; sudo servicectl stop snapd; sudo umount /snap/*/*; sudo rm -rf /var/lib/snapd [12:08] popey: give that a try [12:09] * zyga will add nuke-state to devtools [12:11] zyga, ogra_`: fwiw, I pushed a new u-d-f [12:11] so the archive ? [12:11] *to [12:11] which brings back mounted snaps on boot [12:11] to my people page for now [12:11] zyga: ok [12:12] ok [12:12] and I have a branch up for discussion to sync state on firstboot so snap list actually has something [12:12] *if* that branch is accepted we may have images tomorrow that are in much better shape than todays [12:12] * mvo crosses fingers === mhall119_ is now known as mhall119 [12:20] mvo: thanks [12:22] ogra_`: error: Unknown command `enable-classic'. [12:22] thats on a 16.04 image ? [12:22] yes Xenial [12:22] on your rpi ? [12:23] weird [12:23] yes [12:23] rpi2 [12:23] the images are old though ... try if the snappy command still exists thetre [12:24] daker no dash [12:25] daker, never mind [12:25] FYI allsnaps (amd64): snappy install custom_kernel.snap works (boots!) (Yeah) [12:26] congrats ! [12:26] but snappy remove custom_kernel.snap leaves grub in a state trying to boot the custom kernel [12:26] it does not recover ... [12:38] ogra: where can i find the latest RPI3 image? [12:39] _morphis: FYI https://github.com/ubuntu-core/snappy/pull/1034 [12:39] _morphis: could you give that a practical spin? [12:39] _morphis: just git checkout that in your tree and use devtools as usual [12:40] netpheak, just build a pi2 image from the latest store snaps using u-d-f [12:40] the ony in my rpi3 dir is very outdated [12:40] <_morphis> zyga: sure, thanks! [12:42] mvo, hmm, that new udf is very noisy [12:43] http://paste.ubuntu.com/15912226/ [12:45] 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] but rules.d seems to be a mount point [12:45] it would need to be defined in snappy [12:46] iirc it only mounts stuff to /lib/firmware|modules atm [12:48] ogra_`: ok. Currently I have just daemons (root) accessing the device. But I would like to give normal apps the access too [12:48] ogra_`: I will put this on the wishlist [12:49] Gunther_, kernel and gadget snaps are effectively being re-designed from scratch the next weeks [12:50] Gunther_: you'd have to make an interface for that [12:50] Gunther_: I can guide you but I'm AFK for the next 30 min [12:50] zyga: thanks. [12:51] zyga, seriously ? for a kernel snap ? [12:51] * Gunther_ has to get information about interfaces [12:51] Hi guys. I'm using: $ snapcraft --version [12:51] 2.8.1 [12:51] * ogra_` thinks that a bunch of dirs should simply be supported by default ... [12:51] I can't use configFlags in the new version, right? [12:51] like udev/rules.d or the GL search path [12:52] Issue while loading plugin: [...] Additional properties are not allowed ('configFlags' was unexpected) [12:52] So, please, how should I pass parameters to ./configure [12:52] (and /etc/modprobe.d ...) [12:54] <_morphis> zyga: any idea about the reinstall problem already? [12:57] 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] this is the output when it's run via "mame.run":- [12:57] /snap/mame/100001/bin/launcher: 16: exec: /snap/mame/100001/usr/games/mame -v -inipath /snap/mame/100001 : not found [12:57] 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] mariogrip: sudo snap install ubuntu-core [12:58] ogra_`: thanks, will fix in a sec [12:58] or two [12:58] popey: I tried, but i get "error: can't install "ubuntu-core": snap "ubuntu-core" has changes in progress" [12:58] ah, i had the same [12:58] mbvbeyond that snap list and snap find seem to work fine on the dragonboard here [12:58] mariogrip: bug 1571614 [12:58] bug 1571614 in Snappy "Can't add or remove snaps 'snap "mame" has changes in progress'" [Undecided,New] https://launchpad.net/bugs/1571614 [12:58] I had to nuke the entire world [12:59] mvo, what hap0pened to "enable-classic" though ? [12:59] so I'd say you've reproduced that bug, could you please mark it so. zyga ^ [12:59] _morphis: no, not yet [12:59] 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] popey: is there a workaround? [13:00] mariogrip: nuke from orbit. [13:00] mariogrip: http://paste.ubuntu.com/15911812/ [13:00] popey: reproduce this bug? [13:01] is there some logs that will help debug that I can collect before nuking? [13:01] zyga: mariogrip has the same issue I had.. snap "ubuntu-core" has changes in progress [13:02] ah, ok [13:02] marcoceppi: can you add the same info to the bug please [13:02] marcoceppi: snap changes (pastebin that) [13:03] zyga: was that for me? [13:03] mariogrip: ys, sorry [13:03] * zyga hates tab-complete in polair [13:03] marcoceppi: (sorry) [13:04] xchat has fixes for that ;) [13:04] (moves the person you last talked to to the top of the tab completion list) [13:06] zyga: done :) [13:07] ogra_`: s/xchat/hexchat :P [13:08] mariogrip: thank you [13:08] mariogrip: I'll check it out after our standup [13:09] davmor2, depends what you use ... xenial isnt released yet ;) [13:14] popey: did you reslve your problem with mame? [13:14] zyga: no [13:14] popey: what's the current state? [13:14] popey: (as in where are you, what works, what doens't) [13:14] see 57 mins past [13:14] above [13:15] popey: I how do i remove /snap? it's read only [13:15] mariogrip: sudo ? :) [13:15] mariogrip: on a device you don't have to [13:15] popey: tried [13:15] mariogrip: just umount all the stuff inside and rm -rf all the dirs [13:16] zyga: how do i unmount a sideloaded snap? === josepht` is now known as josepht [13:16] mariogrip: just unmount the squasfs [13:16] mariogrip: sudo umount /snap/*/* [13:16] yeah, mount | grep snap [13:17] and unmount all those things [13:17] mariogrip: try this http://paste.ubuntu.com/15911812/ [13:17] I'll improve that and add it to devtools [13:18] zyga: it worked thanks [13:18] 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] $ ubuntu-clock-app.clock [13:18] appname ubuntu-clock-app.clock not allowed [13:18] zyga: btw, umount /var/lib/snapd/snaps/* || true does not works for sideloaded snaps [13:18] any ideas how to fix it? I think somehow the launcher is still seeing the old clock app in /snaps [13:18] mariogrip: ah, thanks [13:18] mariogrip: where are they located? [13:19] which incidentally I don't know how to uninstall [13:19] dpm: maybe look in /snap/bin ? [13:19] zyga: I have no idea [13:19] dpm: nuke your state [13:19] dpm: and reinstall [13:19] yeah, seems the message of today is "Nuke from orbit" [13:19] with the orbital ion canoon [13:19] canon* [13:19] zyga, what can I nuke the state? [13:19] argh, can't type [13:19] dpm: give me a moment, I'm writing a script for that [13:20] *how, I meant [13:20] ok, thanks zyga [13:20] dpm, [13:20] sudo umount /var/lib/snappy/snaps/* [13:20] sudo rm /etc/systemd/system/snaps-*.mount [13:20] rm -r ~/snaps [13:20] but there might be more involved than that [13:20] it's what I noted down at some stage [13:20] zyga popey damn, still "error: can't install "ubuntu-core": snap "ubuntu-core" has changes in progress [13:20] " after the nuke [13:21] mariogrip: systemctl stop snapd; [13:21] mariogrip: rm -rf /var/lib/snapd/state.json [13:21] that will erase all state [13:21] thanks dholbach. I guess the snaps PATH should be updated too? [13:21] ppisati, hmm, did you test the latest raspi2 kernel with the pi3 ? seems i cant get mine to boot anymore [13:21] dpm: they are on the desktop [13:21] dpm, where? === ogra_` is now known as ogra_ [13:22] dpm, you might have to rebuild/reinstall the snap, and after installing the new snapd/u-core-launcher/etc probably reboot [13:22] ok [13:22] zyga: thanks, it works now [13:22] * zyga is lost with various support requests [13:23] it would be great if each person having an issue mentioned if they are on the desktop or a pure-snap image [13:24] _morphis: can you report the bug you had with sideloading please? [13:25] <_morphis> zyga: sure [13:25] _morphis: I'm afraid most people will just crash quickly today and take some time off [13:25] _morphis: but I don't want to lose track of this [13:26] <_morphis> zyga: sure [13:26] how can I edit my snap app's files in place? they're all readonly even for sudo [13:27] mhall119: remount -o rw,remount /snap/*/* test if that works [13:27] mhall119: you cannot [13:27] mhall119: those are on a squashfs [13:27] 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] _morphis: ahh, yes [13:29] _morphis: I'll fix that, I saw it too [13:29] _morphis: I just forgot about it [13:29] _morphis: maybe devtools.$1 [13:29] <_morphis> zyga: named it snap-1 for me [13:29] _morphis: e.g. devtools.snap devtools.snapd [13:29] <_morphis> sounds good! [13:30] would be a clear indication of someone uses that when hacking and reports problems [13:30] _morphis: I'll patch devtools for better desktop support [13:30] _morphis: thanks for looking into this [13:30] <_morphis> zyga: np [13:32] mariogrip: didn't work [13:33] zyga: if I can't make them rw, what's the easiest way to debug a failing python app launch? [13:33] jdstrand: we should plan some work for the support tool for snap developers that adds advice ofr particular interfaces [13:33] mhall119: you cannot because squashfs is inherently read only [13:33] mhall119: what do you see? [13:33] mhall119: I'd suggest adding a shell app [13:34] mhall119: (like in hello-world) [13:34] mhall119: that will let you inspct the state and play around more easily [13:34] zyga: there are multiple wrapping shell scripts already [13:34] jdstrand: (I'm sorry I forgot the name) [13:34] mhall119: I mean an interactive one [13:34] jdstrand: and add REST API that gives snippets and lists interfaces [13:34] yeah, I'll inject a pdb call [13:35] mhall119: that's useful too :) [13:35] mhall119: one more thing [13:35] mhall119: snap install --devmode [13:35] mhall119: you can use that to install your snap with non-enforcing confinement [13:36] it's still using unconfined in snapcraft.yaml [13:36] mhall119: that's useless [13:37] mhall119: it doesn't do anything [13:37] mhall119: can you pastebin your snapcraft.yaml [13:37] zyga, unknown flag `devmode' Is that on edge only? [13:37] * zyga feels he should blog about interfaces [13:37] oparoz: that's in 2.0 [13:37] oparoz: (images are somewhat broken today) [13:37] oparoz: we're fixing that to make building new images possible [13:37] Thanks zyga [13:38] 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] zyga: but http://paste.ubuntu.com/15913016/ if you want to look at it [13:39] mhall119: can you please pastebin some output? [13:39] ah [13:39] :D [13:39] sorry [13:40] mhall119: drop the no-security plug [13:40] mhall119: add unity7 plug [13:40] mhall119: debug snapcraft issues with sergio [13:40] mhall119: I can help with runtime [13:41] ogra_: the snappy command is still in the image [13:41] mhall119: you can use setup/ to create a desktop file and icon [13:41] (later) [13:41] daker, then there might also still be the "enable-classic" option to it [13:41] daker: images are somewhat broken, not based on snappy 2.0 [13:41] ogra_: yes snappy enable-classic it working now [13:41] * zyga stops saying that over [13:42] good ... better dont upgrade then :) [13:42] zyga, he is not using a 2.0 image [13:42] right [13:42] zyga: no problem, i just want to produce an armhf snap for snapcraft 1.x [13:42] good enough to get a classic shell [13:42] yep [13:43] <_morphis> zyga, jdstrand: https://github.com/ubuntu-core/snappy/pull/1036 [13:44] zyga: I don't think these are snapcraft issues specifically [13:44] mhall119: can you be more specific please? can you pastebin the error you're seeing? [13:44] hey, just finally reconfigured my `shout` snap [13:44] I think it's a python2/setuptools issue [13:45] ah [13:45]