[09:38] <popey> on 16.04, my laptop tells me the snappy command doesn't exist anymore, and if i try to run it i get told to install snappy or ubuntu-snappy-cli - ubuntu-snappy-cli is the latest version (1.9.1.1)
[09:38] <popey> has the snappy command completely gone now?
[09:40] <davidcalle> popey: yep
[09:41] <davidcalle> popey, snappy -> snap
[09:45] <popey> ah! I see the issue
[09:46] <popey> snap install foo.snap (for sideloading) goes looking in the store.
[09:46] <popey> you have to snap install ./foo.snap
[09:46] <davidcalle> popey: indeed, on it's way to being fixed
[09:47] <davidcalle> its*
[09:48] <popey> yay
[09:57] <Gunther_> Hi everyone! May I ask the question, how to build a kernel snap if the ubuntu app store is not available and therefore the download step in the snapcraft plugins fails.
[10:01] <ogra_> Gunther_, heh, good question, i guess you would have to hack up the kernel plugin to use a local initrd.img file that you grab before building the snap
[10:01] <ogra_> sounds like a good wishlist bug :)
[10:01] <Gunther_> ogra_, I thought so ...
[10:02] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the os snaps for all arches
[10:02] <ogra_> you can either loop mount it or use unsquashfs to pull the initrd out of /boot from there
[10:03] <Gunther_> Cool. I will try to extend the kernel.py plugin with an according option
[10:04] <ogra_> you might hit bug 1569337 btw
[10:04] <ogra_> (recent initrds use lzma, the plugin hardcodes gzip)
[10:06] <Gunther_> I already patched this: https://bugs.launchpad.net/snapcraft/+bug/1569337/comments/2
[10:06] <Gunther_> but since the download fails, I cannot test iut
[10:08] <ogra_> yeah :/
[10:18] <popey> is there some magic to getting X apps to run inside a snap?
[10:18] <zyga> popey: use the 'x11' plug
[10:18] <popey> it's like it can't see the xserver, do we need to do the old export DISPLAY?
[10:18] <popey> oh, got an example zyga ?
[10:18] <zyga> popey: you shoudn't have to
[10:18] <zyga> popey: just stick this into your snapcraft.yaml
[10:18] <zyga> plugs:\n  x11:
[10:19] <zyga> and reinstall it
[10:19] <popey> okay, will try, thanks
[10:20] <popey> it doesn't like that
[10:20] <popey> argument of type 'NoneType' is not iterable
[10:21] <zyga> popey: maybe update snapcraft
[10:21] <zyga> popey: that's the right syntax
[10:21] <zyga> (this should be reported to sergio)
[10:21] <popey> i have 2.7
[10:36] <Gunther_> ogra_: thanks for your help, my prototype kernel.py with local os.snap seems to work
[10:39] <popey> zyga: odd, I can find no reference to x11 in the snapcraft source I just pulled from github
[10:39] <zyga> popey: it's a bug, it seems that the validator tries to iterate over None
[10:40] <zyga> popey: foo: (with the colon at the end) is an empty collection but it sesems it gets parsed to None
[10:40] <zyga> popey: you can try plugs:\n x11:\  interface x11
[10:40] <zyga> sergiusens: ^^
[10:40] <zyga> popey: mind the spaces (precisely)
[10:42] <popey> Issues while validating snapcraft.yaml: The 'x11' property does not match the required schema: 'interface x11' is not valid under any of the given schemas
[10:42] <popey> http://paste.ubuntu.com/15807938/ is my yaml
[10:44] <sergiusens> zyga, popey I haven't released the latest snapcraft yet; I am still waiting for a good snapd binary that works with https://github.com/ubuntu-core/snappy/pull/910 for our examples tests to pass
[10:44] <zyga> sergiusens: I see
[10:44] <sergiusens> this branch isn't merged yet https://github.com/ubuntu-core/snapcraft/pull/441
[10:44] <popey> ok
[10:44] <popey> thanks
[10:45] <sergiusens> I tried to manually test locally and it still doesn't work (given snapd in the archive doesn't work either)
[10:51] <zyga> sergiusens: what were the failures?
[10:56] <sergiusens> zyga, the one you fixed last night
[10:57] <sergiusens> zyga, I also don't have replacement logic for `snappy services`
[10:57] <zyga> sergiusens: that's rm -rf'd now
[10:57] <zyga> sergiusens: it's coming back after a redesign after release
[10:57] <zyga> sergiusens: how does snapcraft uses it?
[10:57] <sergiusens> zyga, so I don't know how to see the failures if services started or not
[10:57] <sergiusens> zyga, to see if our services started
[10:58] <sergiusens> zyga, how can I see this from the desktop for a service running inside snappy?
[10:58] <sergiusens> systemctl doesn't cut it
[10:58] <zyga> sergiusens: you'd have to use systemd yourself :/
[10:58] <sergiusens> or please upload a new ubuntu core to the store
[10:59] <sergiusens> zyga, yeah, systemctl from desktop does not list things in ubuntu-core
[10:59] <zyga> sergiusens: why is systemctl not sufficient? AFAIR that's what we used internally
[10:59] <sergiusens> so tell me how to call it
[10:59] <zyga> hmm?
[10:59]  * zyga doesn't understand something
[10:59] <zyga> are we talking about cross-host testing?
[11:02] <sergiusens> zyga, no
[11:02] <sergiusens> if you try what i say you will see
[11:03]  * sergiusens starts babysitting hour
[11:07] <Gunther_> Hmmm is it possible to build a kernel.snap from a binary linux-image-xxx.deb package?
[11:08] <ogra_> yes, it is, but you need to do it maunually
[11:09] <Gunther_> I understand
[11:10] <kyrofa_> Good morning
[11:11] <ogra_> Gunther_, line 370-595 ... http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/build (that does tarballs alongside though)
[11:11] <ogra_> you can do it withour a chroot by simply using "dpkg -x" to unpack the deb and manually create a snap.yaml and meta dir
[11:49] <Mikaela> When and how will I be able to install snaps on normal Xenial? https://insights.ubuntu.com/2016/04/13/snaps-for-classic-ubuntu forgets to mention it.
[11:50] <kyrofa_> Mikaela, by the time it's released, I'd say
[11:51] <Mikaela> I see, thanks
[11:51] <ogra_> shouldnt that work already ?
[11:51]  * ogra_ thought all bits are in place with mvo's latest landings
[11:53] <ogra_> sergiusens, your latest G+ post is private
[12:04] <mvo> Mikaela, ogra_ it is possible today :) we just don't have a lot in the store yet
[12:05] <Mikaela> nice, does it come by itself or should I install some package?
[12:06] <zyga> Mikaela: just wait a few days or apt-get install snapd
[12:06] <zyga> Mikaela: we're still making improvements
[12:06] <Mikaela> ok
[12:09] <ogra_> zyga, ubuntu-snappy-cli rather ;)
[12:10] <sergiusens> ogra_, yeah, not sure why that is the default now
[12:10] <ogra_> (that is what also was seeded recently)
[12:10] <zyga> ogra_: no? it was renamed to snapd
[12:11] <sergiusens> ogra_, mvo jdstrand btw, don't we want to rename the ubuntu-core-launcher package to snap-launcher?
[12:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$ grep snappy desktop
[12:12] <ogra_>  * (ubuntu-snappy-cli)
[12:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$ grep snappy server
[12:12] <ogra_>  * (ubuntu-snappy-cli)
[12:12] <ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$
[12:12] <ogra_> zyga, ^^^
[12:12] <ogra_> (it depends on snapd though)
[12:12] <ogra_> sergiusens, you have 8 days :P
[12:13] <zyga> hmm, I wonder what's the point of both packages
[12:13] <zyga> one still ships some directories
[12:14] <ogra_> well, if we want top rename we need to do it now ... there is no way to change the seeds after release
[12:14] <ogra_> (except by hacking meta packages directly and getting them out of sync with the world)
[12:16] <ogra_> mvo, infinioty uploaded a new livecd-rootfs ... do you need any of the changes from the PPA version ? (they will be overridden for the next image build)
[12:16] <dpm> so dholbach, popey, davidcalle, just read the omgubuntu article, captures snaps on the desktop pretty accurately and nicely :)
[12:19] <popey> yeah, i sent him a tweet. he was worried it was all over the place and untidy, i reassured him that he'd "got" it
[12:20] <popey> also, sa bdfl shared it, so it must be fine ㋛
[12:21] <dpm> popey, indeed, I think it's really good
[12:22] <dpm> dholbach, davidcalle, so as I said on the e-mail the /desktop page is published, but I've held off to publishing the subpages until the examples work
[12:24] <dholbach> dpm, sounds good
[12:24] <dholbach> dpm, yeah, it's a nice article
[12:24] <dpm> dholbach, just going through your e-mails now
[12:26] <niemeyer> zyga, jdstrand: Can we merge https://github.com/ubuntu-core/snappy/pull/802?
[12:27] <niemeyer> The idea is getting interfaces in very quickly when necessary, or rejecting them.. we cannot leave these reviews hanging around
[12:27]  * sergiusens migrates to coffee shop to re supply
[12:28] <Gunther_> Another silly question (just because looking at kernel builds is sooo boring). Is it possible to extend an existing kernel.snap with a custom kernel module? In this case a device driver for a pci measument board.
[12:28] <Gunther_> The sources for the driver are available but they are not part of the linux kernel
[12:29] <dpm> dholbach, what's the new LP team you created again?
[12:32] <jdstrand> niemeyer: I had not been looking at that very closely since my first review because interfaces code wasn't working yet and I didn't quite know how things were changing
[12:33] <jdstrand> but I can take another look
[12:33] <jdstrand> (ie, there was no way to test it)
[12:36] <jdstrand> zyga: are interfaces supposed to be autoconnecting with snapd that is in xenial now?
[12:38] <jdstrand> zyga: cause focuswriter from the desktop examples is not getting unity7 autoconnected. dholbach's doc on desktop examples also seems to have things that are not autoconnecting
[12:38] <dholbach> dpm, ~snappers
[12:38] <dpm> cool, thanks
[12:38] <zyga> jdstrand: I haven't tried packaged snapd today.
[12:39] <zyga> jdstrand: autoconnection is merged but I'm not sure when the release was cut
[12:39] <zyga> jdstrand: we're aiming for one more release today
[12:39] <zyga> jdstrand: with full control over connect/disconnect
[12:39] <jdstrand> it says '19 hours' ago
[12:40]  * zyga tries focuswriter
[12:41] <dholbach> mvo said he'd do an upload soon
[12:41] <jdstrand> I see
[12:42] <dpm> JamesTait, on bug 1555569, is this now supposed to be fixed on the store side?
[12:42] <jdstrand> zyga: if I do: 'snap interfaces', all I see is 'slot plug'. how do I connect things? (even if that is in the pending upload)
[12:42] <zyga> jdstrand: snap connect
[12:42] <zyga> jdstrand: snap disconnect
[12:42] <zyga> jdstrand: and snap interfaces
[12:42] <zyga> jdstrand: that's broken today (it has little effect)
[12:43] <zyga> jdstrand: it doesn't setup security of anything yet
[12:44] <jdstrand> zyga: so I (will) need to specify both the plug and the slot for each connection?
[12:44] <zyga> jdstrand: see --help
[12:44] <zyga> there are some shortcuts
[12:44] <zyga> jdstrand: some may not fully work but some do
[12:44] <jdstrand> ah, --help
[12:44] <zyga> jdstrand: I'll polish that and get it to spec with the first SRU release
[12:44] <jdstrand> I tried 'help' and '-h'
[12:44] <JamesTait> dpm, I don't actually know what the current state of that is - the summary field from the manifest will be surfaced directly in the API, so it won't be used as title.
[12:45] <JamesTait> dpm, nessita would probably be your best bet.
[12:45] <dpm> thanks JamesTait
[12:45] <jdstrand> zyga: is 'snap interfaces' supposed to list available interfaces or just connected interfaces?
[12:46] <zyga> jdstrand: available and connected
[12:46] <zyga> jdstrand: what do you see?
[12:46] <zyga> jdstrand: you have to snap install ubuntu-core
[12:46] <jdstrand> I literally see 'slot plug'
[12:46] <zyga> jdstrand: (it is not auto installed yet)
[12:46] <jdstrand> that is it
[12:46] <zyga> jdstrand: UX could be improved there :-)
[12:46] <jdstrand> $ sudo snap interfaces
[12:46] <jdstrand> slot plug
[12:47] <jdstrand> $
[12:47] <jdstrand> zyga: I have ubuntu-core installed
[12:47] <jdstrand> $ snap list
[12:47] <jdstrand> Name         Version    Developer
[12:47] <jdstrand> focuswriter  0.1        sideload
[12:47] <jdstrand> ubuntu-core  16.04.0-24 canonicalubuntu-core  16.04.0-24 canonical
[12:47] <zyga> jdstrand: can you restart snapd?
[12:47] <jdstrand> whoops, that pasted twice
[12:48] <jdstrand> sudo systemctl restart snapd?
[12:48] <zyga> jdstrand: anyway; that part still needs love
[12:48] <zyga> jdstrand: yep
[12:48] <jdstrand> $ sudo snap interfaces
[12:48] <jdstrand> slot plug
[12:48] <mvo> zyga: there is a git tag for 1.9.1 if you want to double check what went in and what did not
[12:48] <zyga> mvo: thanks, good idea
[12:48] <mvo> dholbach: there will be one today, maybe even two, I ask in the standup
[12:49] <zyga> jdstrand: ok, the version you have doesn't have the REST API wired to anything
[12:49] <jdstrand> that would explain that
[12:49] <zyga> jdstrand: interfaces/connect/disconnec all operate on a separate repo
[12:49]  * zyga focuses on finishing this last essential bit
[12:50] <jdstrand> zyga: is that repo going to be in mvo's upload?
[12:50] <zyga> jdstrand: yes, that has landed since
[12:50] <zyga> jdstrand: but connect/disconnect working hasn't
[12:50] <zyga> (I'm still hacking on it)
[12:50]  * jdstrand notes that he is being asked about this stuff a lot (not sure why they aren't asking here, but, there you go...)
[12:50] <zyga> jdstrand: no worries :-)
[12:51] <dholbach> mvo, go go go!
[12:51] <jdstrand> zyga: what repo should I be looking at? I need to fix confinement for a few things
[12:51] <nessita> dpm, hi!
[12:51] <jdstrand> and testing the desktop snap examples, etc, etc
[12:52] <nessita> dpm, about the title and summary, there is a thread that summaries all the details, let me get you the details
[12:52] <dpm> nessita, I'm on that thread
[12:52] <dpm> nessita, but I was wondering if the bug report needs updating
[12:52] <dpm> as by the status of it it seems no one is working on it, which from the mailing list thread, you guys are
[12:54] <nessita> dpm, have the link handy?
[12:54] <dpm> nessita, sure -> https://launchpad.net/bugs/1555569
[12:55] <oly> hi, i have just been trying out snappy for apps everything went well until i uploaded a snap
[12:55] <oly> package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks
[12:55] <nessita> dpm, basically summary is that we have completed the work on summary/description, and for title we are now using the snap name "moon-buggy", until snapcraft and snap grow capabilities for defining a Title section
[12:56] <oly> any ideas what i can do with that error ? this is a very basic python app with one dependancy on python-gi
[12:56] <zyga> jdstrand: hmm repo?
[12:56] <jdstrand> zyga: I used your word
[12:56] <zyga> jdstrand: you can just build snapd locally yourself
[12:56] <jdstrand> 07:49 < zyga> jdstrand: interfaces/connect/disconnec all operate on a separate repo
[12:56] <zyga> jdstrand: (interfaces.Repository is an internal code construct)
[12:56] <oly> also can i try and run snaps locally in a VM
[12:56] <zyga> jdstrand: use snapd from master from now
[12:56] <zyga> jdstrand: that will show you what's connected
[12:56] <jdstrand> zyga: ok, that's fine
[12:56] <zyga> jdstrand: won't let you conenct yet
[12:57] <zyga> jdstrand: you can always look at /var/lib/snapd/{apparmor,seccomp}/profiles to see what's "live"
[12:57] <jdstrand> zyga: ah, master is what I was looking for. I thought you meant some other fork/branch
[12:58] <jdstrand> zyga: well, I can manually edit /var/lib/snapd/{apparmor,seccomp}/profiles if I have to. I was trying to get a picture of how stuff works for myself, devs, etc
[12:58] <jdstrand> I guess that will have to wait a bit longer
[13:03] <vances> Q: What is the proper method to enable IP forwarding?  I did 'sudo mount -o remount,rw /' and edited '/etc/sysctl.conf' to set 'net.ipv4.ip_forward = 1'.
[13:04] <zyga> vances: hmm interesting question, you can have a snap that just toggles the /proc filesystem directly
[13:04] <zyga> vances: it would have to use one of the interfaces that allow that
[13:06] <vances> Although the above method gets the kernel parameter set after a reboot it still doesn't seem to forward IP between interfaces.
[13:06] <vances> Routing table looks fine.
[13:07] <vances> iptables is all ACCEPT
[13:07] <vances> Is there some additional security I need to deal with?
[13:10] <Mikaela> minor bug: /etc/profile.d/apps-bin-path.sh comment talks about /snaps/bin when in reality it uses /snap/bin and /snaps doesn't even exist. Should I report this or see if it's already reported or is mentioning here enough?
[13:10] <zyga> Mikaela: yes, please report it
[13:11] <Mikaela> ok, doesn't seem to be reported at https://bugs.launchpad.net/ubuntu/+source/snapd
[13:11] <zyga> vances: I'm sorry I cannot help you today
[13:11] <davidcalle> dpm: thanks for updating the /desktop page, I've pushed the new /snappy one out as well today
[13:11] <davidcalle> dpm: with great difficulty if you've seen my email
[13:14] <ysionneau> sergiusens hi! Any idea about my udf issue? https://lists.ubuntu.com/archives/snappy-devel/2016-March/001668.html
[13:14] <Mikaela> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1569892
[13:18] <dpm> davidcalle, I've seen it, good work!
[13:19] <jdstrand> dholbach: hi! B5 in your known issues should not be green as of this second.
[13:19] <jdstrand> dholbach: that is what I was just discussing with zyga
[13:19] <dpm> davidcalle, the db issue seems to be a bit of a concern. We might as well talk to upstream about it
[13:19] <Mikaela> also nmap complained about `can not find a snappy os` until I installed `ubuntu-core`, not sure how I should report it, but I assume that is known issue?
[13:19] <dholbach> jdstrand, is this a fix which landed somewhere?
[13:20] <jdstrand> dholbach: they said autoconect landed in master
[13:20] <jdstrand> dholbach: but it isn't in the archive yet
[13:20] <dholbach> ok
[13:20] <dholbach> I'll note that down then
[13:20] <dholbach> zyga, which PR was this?
[13:20] <zyga> dholbach: fix for what?
[13:20] <ogra_> Mikaela, hmm, that is supposed to happen autonmatically
[13:20] <ogra_> mvo, isnt it ? ^^^
[13:20] <Mikaela> it seems it didn't for me for some reason
[13:20] <dholbach> zyga, autoconnect
[13:21] <zyga> dholbach: I don't really remember but it was merged in 1.9.1
[13:21] <dholbach> oh...
[13:21] <dholbach> jdstrand, just said that it's in master but not in the archive yet
[13:21] <dholbach> or was it a fix for autoconnect?
[13:21] <zyga> dholbach: no, that's not the same
[13:21] <zyga> dholbach: that's connection visibility
[13:21] <ogra_> Mikaela, well, "supposed" ... i'm not sure it is there yet
[13:21] <zyga> ogra_: its not
[13:21] <davidcalle> dpm: we have a few ideas of things to try before going upstream, I'd also like Robin's advice
[13:21] <jdstrand> oh, sorry I misunderstood
[13:22] <ogra_> technically your first "snap install" should install ubuntu-core ahead of anything else
[13:22] <dholbach> zyga, jdstrand: can we add a line for this then, so we can track it separately?
[13:22] <jdstrand> dholbach, zyga: I can say 100% certain autoconnect is not in 1.9.1
[13:22] <dholbach> I'm losing track :)
[13:22] <zyga> jdstrand: hmmmmmm
[13:22] <zyga> jdstrand: and master?
[13:22] <jdstrand> zyga: unity7 is suppoosed to autoconnect?
[13:22]  * zyga cares less about 1.91
[13:22] <jdstrand> let me uninstall and install
[13:23] <zyga> jdstrand: yes
[13:23] <dholbach> can we file a bug for what exactly is not working right now and track it there?
[13:23] <zyga> dholbach: many things are not working
[13:23] <dholbach> zyga, one example we look at together :)
[13:23] <zyga> dholbach: filing abug before i'm done is not useful yet
[13:23] <zyga> dholbach: wait until today evening
[13:24] <dholbach> ok... it's just that jdstrand asked for the list of known issues to be updated and I couldn't quite figure out what exactly had changed
[13:24] <jdstrand> dholbach: I think it is sufficient to say it is not fixed in 1.9.1.1
[13:24] <dholbach> ok
[13:24] <jdstrand> I don't want to distract zyga
[13:25] <jdstrand> I just want the spreadsheet to reflect reality :)
[13:25] <jdstrand> cd
[13:25] <dholbach> wfm! :)
[13:25] <jdstrand> cd meh
[13:25] <jdstrand> heh
[13:25] <jdstrand> that kinda summarizes how I feel (cd meh :)
[13:25]  * dholbach hugs jdstrand 
[13:25]  * jdstrand steps away for a moment
[13:26]  * jdstrand hugs dholbach :)
[13:46] <Mikaela> where can I find the bug reports for specific snaps? /snap/bin/tmux returns "Bad system call" and /snap/bin/nmap is unable to resolve localhost or ping 127.0.0.1 "Socket creation in sendConnectScanProbe: Permission denied (13)". I think they are known, but I would like to follow their statuses and cannot wait for snappy to become production ready (nmap and tmux there already report being newer versions than
[13:46] <Mikaela> the Xenial repo ones)
[13:49] <ogra_> Mikaela, yxou can contact the author https://uappexplorer.com/app/nmap.joetalbott (see the "support" tab)
[13:50] <ogra_> (same goes for https://uappexplorer.com/app/tmux.shawn111 )
[13:50] <beuno_> josepht, you have a fan!
[13:50] <beuno> shawnwang, so do you
[13:50] <ogra_> it is up to the snap creator to provide a bug url in the store data
[13:50] <jdstrand> dholbach: fyi, apparmor 2.10.95-0ubuntu2 is out of proposed and should fix policy loads on reboot
[13:50] <ogra_> if they didnt, direct mail is the best bet
[13:50] <Mikaela> I see
[13:51] <ogra_> https://uappexplorer.com/apps?sort=relevance&type=snappy is pretty helpful until the store has a proper web ui on its own
[13:52] <Mikaela> I think it's probably enough that the authors were pinged on IRC :)
[13:52] <josepht> Mikaela: I'll take a look at nmap.
[13:52] <josepht> Mikaela: is that the armhf or amd64 version?
[13:52] <shawnwang> Mikaela, thanks, let me check it
[13:53] <Mikaela> amd64
[13:53]  * ogra_ assumes the security system simply changed underneath them ...
[13:56] <josepht> Mikaela: can you give me a paste of 'snappy list -v' please?
[13:56] <ogra_> josepht, no more "snappy"
[13:56] <ogra_> it is "snap" now
[13:56] <Mikaela> josepht: snap says "error: unknown flag `v'"
[13:57] <ogra_> (everything changed within the last week)
[13:57] <Mikaela> ah, so that is why everyone talks about snappy :)
[13:57] <ogra_> yeah :)
[13:57] <josepht> ogra_: did that change not come as an update?
[13:57] <ogra_> it did
[13:58] <shawnwang> Mikaela, SNAP=/snaps/tmux.sideload/current /snaps/tmux.sideload/current/command-tmux.wrapper
[13:58] <dholbach> jdstrand, excelltn
[13:59] <dholbach> jdstrand, hum... not on archive.u.c yet?
[13:59] <shawnwang> Mikaela, you can try this to avoid the launcher issue
[14:00] <Mikaela> shawnwang: zsh: tiedostoa tai hakemistoa ei ole: /snaps/tmux.sideload/current/command-tmux.wrapper
[14:00] <Mikaela> (file or directory does not exist)
[14:02] <shawnwang> Mikaela, SNAP=/snaps/tmux.shawn111/current /snaps/tmux.shawn111/current/command-tmux.wrapper
[14:02] <shawnwang> Mikaela, sorry, wrong path
[14:03] <Mikaela>  shawnwang same error even when I correct /snaps to /snap
[14:03] <jdstrand> dholbach: it is getting there: https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2
[14:03] <jdstrand> probably just need a publisher run
[14:03] <sborovkov> Hello. I am on snappy on RPI 3. With latest kernel and os snap. Previously I could install snap with this command snappy install screenly-....snap to install from file. Now that does not work. can someone tell me how I can install snap from local file now?
[14:04] <dholbach> jdstrand, cool
[14:04] <Mikaela> shawnwang: I am on Ubuntu Classic (MATE) 16.04 amd64, in case that wasn't clear and you are giving me instructions for some other platform
[14:04] <shawnwang> Mikaela, yes... I run it on Ubuntu Classic 16.04 amd64
[14:05] <Mikaela> shawnwang: is it possible that you could be missing some updates?
[14:06] <shawnwang> Mikaela, you still got "Bad system call"?
[14:06] <ogra_> sborovkov, use "snap install"
[14:06] <ogra_> the "snappy" command is gone
[14:06] <sborovkov> ogra_: I did. When I pass filename, it says snap not found
[14:06] <sborovkov> When I gave it full path it returned this error
[14:06] <Mikaela> shawnwang: with your commands I get "no such file or directory", if I run /snap/bin/tmux directly I get the bad system call
[14:07] <sborovkov> error: unable to find task with id "52c91e31-7113-26bb-1804-5980e7d74de1
[14:07] <Mikaela> shawnwang: I don't have /snaps and in /snap I see directories: bin  nmap  tmux  ubuntu-core
[14:09] <shawnwang> Mikaela, apt-cache policy ubuntu-snappy, maybe we use different version of ubuntu-snappy
[14:09] <mvo> Mikaela: if you freshly installed snapd then the $PATH is not quite correct, needs a one time login. the bad systemscall is probably because the tmux does not quite have the right security profile yet
[14:09] <mvo> Mikaela: dmesg also often has some useful information
[14:10] <Mikaela> shawnwang: if you mean snapd 1.9.1.1
[14:10]  * Mikaela reboots to see if that changes anything
[14:10] <ogra_> shawnwang, ubuntu-snappy-cli ... you do not want ubuntu-snappy installed
[14:10] <ogra_> (it was a mistake that it was seeded initially, remove it if you have it)
[14:11] <shawnwang> ogra_, Mikaela, let me upgrade my ubuntu-snappy-cli
[14:13] <Mikaela> After reboot /snap/bin/tmux and /snap/bin/nmap throw me `aa_change_onexec failed with -1. errmsg: No such file or directory`
[14:15] <shawnwang> Mikaela, could you try SNAP=/snap/tmux/current /snap/tmux/current/command-tmux.wrapper
[14:16] <Mikaela> shawnwang: works, except that it has decided that my tmux.conf has unknown option utf8 twice
[14:17] <shawnwang> Mikaela, nice
[14:17] <Mikaela> set -g utf8 & set-window-option -g utf8 on ==> I guess that if new tmux says that these options don't exist, I am just going to remove them from my tmux.conf
[14:17] <shawnwang> Mikaela, https://github.com/shawn111/tmux.snap/blob/master/snapcraft.yaml
[14:18] <shawnwang> Mikaela, here is my snapcraft.yaml
[14:18] <Mikaela> shawnwang: I fear I don't understand that as I am not a developer
[14:19] <niemeyer> jdstrand: About the bluez interface, understood.. I'm just concerned about introducing a streamlined way to introduce new interfaces
[14:19] <niemeyer> jdstrand: This is a major blocker for anyone trying to use snappy, so we need to be agile handling such requests
[14:20] <shawnwang> Mikaela, maybe I missing some config
[14:20] <niemeyer> jdstrand: It's better to introduce something basic and the polish it, than to block for an undetermined amount of time
[14:24] <shawnwang> ogra_, is it a right way to call snap command? like SNAP=/snap/tmux/current /snap/tmux/current/command-tmux.wrapper
[14:25] <shawnwang> ogra_, or, should I use /snap/bin/tmux directly?
[14:27] <zyga> dholbach: what's that snap I should try to instal
[14:27] <zyga> dholbach: I have a branch locally, I'd like to test any desktop snaps you can give me
[14:28] <dholbach> zyga, I don't know which problem you solved and which might be working now... jdstrand?
[14:28] <ogra_> shawnwang, no idea, i never run them directly since that breaks :)
[14:28] <zyga> dholbach: anything you have
[14:28] <ogra_> you need the env the ubuntu-core-launcher sets up
[14:28] <dholbach> zyga, jstrand: focuswriter from lp:snappy-desktop-examples?
[14:29] <shawnwang> ogra_, yep, like mvo mention I might miss security profile
[14:29] <zyga> dholbach: k, I'll try
[14:30] <zyga> FYI: I fixed a few bugs that would be breaking stuff earlier
[14:31] <jdstrand> niemeyer: I totally agree and we'll get there
[14:41] <jdstrand> zyga: fyi, someone mentioned you recommended modifying files to not use the launcher to work around lack of unconfined and/or developer mode. I suggest instead modifying the apparmor profile to be in complain mode and the seccomp profile.
[14:41] <josepht> I see the same issue as sborovkov when sideloading a snap or trying to install a snap from the store (ubuntu-core in this case)
[14:42] <ogra_> joyeah, seems sideloading is gone atm ...
[14:42] <zyga> jdstrand: snappy will refresh those profiles
[14:42] <ogra_> josepht, ^^^
[14:42] <zyga> jdstrand: won't refresh the wrappers
[14:42] <zyga> ogra_: sideloading is not gone, should work okay
[14:42] <ogra_> josepht, there is supposed to be a --developer-mode option to the install command ...
[14:42] <ogra_> but thats not there yet
[14:42] <ogra_> zyga, how
[14:43] <zyga> ogra_: yep, it's not there yet :/
[14:43] <zyga> (but just UX issue)
[14:43] <ogra_> :)
[14:43] <zyga> ogra_: snap instal ./path/to/some/snap.snap
[14:43] <josepht> ogra_: same happens with a store snap
[14:43] <ogra_> oh
[14:43] <ogra_> that sounds rather like a bug :)
[15:09]  * zyga has a still-crazy branch that is relatively stable for controling interfaces
[15:09] <zyga> dholbach: none of the snaps work though
[15:09] <zyga> dholbach: only cap-test
[15:09] <zyga> dholbach: I tried scummvm with home plug connected
[15:10] <zyga> dholbach: focuswriter starts but nothing shows up
[15:10] <zyga> (it doesn't crash, just has no windows)
[15:10] <dholbach> :-/
[15:11] <zyga> although...
[15:11] <zyga> kwi 13 17:10:42 zyga-thinkpad-w510 audit[11161]: SECCOMP auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=11161 comm="focuswriter" exe="/snap/focuswriter/0/usr/bin/focuswriter" sig=31 arch=c000003e syscall=55 compat=0 ip=0x7f0edad24e2a code=0x0
[15:11] <zyga> jdstrand: ^^ is that a seccomp denial?
[15:11] <ogra_> yes
[15:12] <zyga> dholbach: ^^ fix that and maybe it will run
[15:12] <zyga> that looks like getsockopt
[15:12] <zyga> missing network plug?
[15:13] <dholbach> zyga, how?
[15:13] <zyga> dholbach: identify why that syscall is not allowed, put it in an interface
[15:13]  * zyga tries with network
[15:17] <jdstrand> zyga: yes
[15:17] <jdstrand> on amd64:
[15:17] <jdstrand> $ scmp_sys_resolver 55
[15:17] <jdstrand> getsockopt
[15:18] <jdstrand> (you need to run scmp_sys_resolver on the target arch so if not amd64, run it on the device)
[15:19] <elopio> ogra_: the job that takes the os snap from cdimage is ready, triggered when the snap changes. But there are a couple of problems. The upload fails a lot because of the store, so I have to retry it like 4 times. And once it's uploaded it needs a manual review to go into the edge channel.
[15:19] <jdstrand> zyga: mvo mentioned getsockopt is needed for nvidia systems. see the thread I just responded to
[15:19] <zyga> ah
[15:19] <zyga> I have an nvidia GPU here
[15:20] <jdstrand> there you go
[15:20] <elopio> everything we could automate is already automated. So I'll be dealing daily with the manual parts for now.
[15:20] <jdstrand> you may have some other issues
[15:20] <jdstrand> (again, see thread)
[15:22] <ysionneau> hmm zyga here I get Apr 13 15:21:21 localhost kernel: [ 6322.540900] audit: type=1326 audit(1460560881.937:63): auid=1000 uid=1000 gid=1000 ses=1 pid=2081 comm="ld-linux-armhf." exe="/snaps/libshdata.sideload/LWKbJCCgHVhJ/lib/ld-linux-armhf.so.3" sig=31 arch=40000028 syscall=289 compat=0 ip=0x76ef44d6 code=0x0
[15:22] <ysionneau> is it seccomp denial?
[15:23] <ysionneau> (I'm on RPI2)
[15:23] <ysionneau> it's written audit...
[15:23] <zyga> maybe
[15:23] <ysionneau> and in the user space console logs I get 'bad syscall'
[15:23] <ysionneau> 289 is "send"
[15:23] <ysionneau> although, I've put syscalls: [send] + network-client/network-listener/network-service caps
[15:27] <zyga> ysionneau: that's not supported
[15:27] <zyga> ysionneau: that's old-security
[15:27] <zyga> ysionneau: you need plugs: [network]
[15:27] <zyga> ysionneau: or plugs: [network, network-bind]
[15:32] <ysionneau> oh, old-security isn't supported anymore?
[15:32] <ysionneau> I can still see them in the snapcraft/examples
[15:41] <pmp> hi, I'm using snappy on raspi2
[15:42] <pmp> following a snappy update yesterday it refused to boot on the newly installed kernel (4.4.0xxx vs 4.3.0)
[15:43] <pmp> this was a nice way to see snappy working well, when a kernel update has failed
[15:43] <pmp> is this expected behaviour
[15:43] <pmp> I mean the new kernel not working well?
[15:44] <pmp> It stops right after "uncompressing kernel"
[15:49] <ogra_> pmp, is that a 16.04 image ?
[15:49] <pmp> yes
[15:50] <ogra_> (it needs an updated gadget snap too, could be that your old snappy is not capable of updating that yet)
[15:50] <ogra_> so either roll back, or re-flash
[15:50] <ssweeny> zyga, hate to be a pest but is there an ETA for review of my bluez PR?
[15:50] <ogra_> snappy uis still changeing a lot ... especially the images
[15:50] <zyga> ssweeny: today
[15:50] <ssweeny> zyga, awesome :)
[15:51] <zyga> ssweeny: sorry, fighting one last fire
[15:51] <pmp> ogra_: the roll-back is done automatically, but after each boot it tries to update
[15:51] <ssweeny> zyga, no worries. just getting queries from my team since we finish a sprint today
[15:52] <pmp> ogra_: my original image dates from I'd say 4 weeks ago, is that too old?
[15:52] <ogra_> yeah, snappy was nearly completely re-done (once again) and the big changes only landed last week or are still in flux
[15:53] <pmp> ogra_: iirc I grabbed the udf from ~mvo somewhere, is that still the right place to fetch the image for rpi2?
[15:53] <ogra_> i'd actually build my own, i dont think mvo  had the time to update them
[15:54] <ogra_> but yes, you need the latest u-d-f from his dir
[15:54] <pmp> ogra_: yes that scary part: downloading a 11MB binary from somewhere and execute it
[15:54]  * pmp is fearless
[15:55] <pmp> ogra_: thx for the hint
[15:55] <ogra_> mvo is a totally trustworthy person though ... (you will notice he only takes so much from your bank account after you ran his binaries)
[15:55] <ogra_> ;)
[15:59] <zyga> zyga@zyga-thinkpad-w510:~/work/src/github.com/ubuntu-core/snappy/cmd/snap$ focuswriter.run
[15:59] <zyga> Qt: Session management error: None of the authentication protocols specified are supported
[15:59] <zyga> dholbach: ^ focuswriter
[15:59] <zyga> dholbach: closer but no idea what's next
[16:00] <zyga> kwi 13 17:59:22 zyga-thinkpad-w510 kernel: audit: type=1326 audit(1460563162.514:194): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=25780 comm="focuswriter" exe="/snap/focuswriter/0/usr/bin/focuswriter" sig=31 arch=c000003e syscall=49 compat=0 ip=0x7f983a472d37 code=0x0
[16:00] <ogra_> moar syscalls .... yay
[16:03] <zyga> sys_shmctl
[16:03] <davidcalle> mvo: ogra_ zyga, is snappy-remote still a thing?
[16:03] <zyga> davidcalle: nope
[16:03] <ogra_> nah
[16:04] <davidcalle> Thanks :)
[16:05] <davidcalle> kyrofa_: do you know when we can expect an updated https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md ? At first glance, snappy-tools, snappy try and snappy-remote need to go.
[16:05] <dholbach> zyga, thanks for looking into this
[16:05] <dholbach> I need to run now - have a good one everyone!
[16:06] <kyrofa> davidcalle, we have a bug for it-- we can crank it out pretty quickly, though aren't people using developer.ubuntu.com?
[16:07] <davidcalle> kyrofa: we import the doc from you guys :) I've just removed them from there, though, with the announcement.
[16:07] <davidcalle> https://developer.ubuntu.com/en/iot/build-apps/get-started
[16:07] <kyrofa> davidcalle, oh! I didn't know that import was up and running
[16:08] <davidcalle> kyrofa: it's not, we run a manual thing :)
[16:08] <kyrofa> davidcalle, ah :) . Yeah we'll move that one closer to the top of the pile, thanks for the reminder
[16:09] <davidcalle> kyrofa: no worries, we'll sync with you next time we manually import or land the actual importer.
[16:10] <kyrofa> davidcalle, please do, I'm looking forward to that
[18:35] <netphreak> Hi, guys!
[18:35] <netphreak> I'm having trouble getting a homebuilt snap package start after install.
[18:35] <netphreak> http://paste.ubuntu.com/15818026/
[18:38] <kyrofa> netphreak, is this on the desktop?
[18:38] <ogra_> netphreak, snap install ubuntu-core
[18:39] <ogra_> (probably sudo ;))
[18:40] <netphreak> yes, i'm on desktop
[18:45] <elopio> noise][: any news about my 401? Should I report a bug somewhere maybe?
[18:46] <netphreak> thx solved the issue ;)
[18:46] <netphreak> One step closer - i now get the following error:
[18:46] <netphreak> http://paste.ubuntu.com/15818225/
[18:47] <netphreak> my snap craft looks the following:
[18:47] <netphreak> http://paste.ubuntu.com/15818261/
[18:50] <michaelrose> so question since snappy packages are limited as far as access to the filesystem how do they manage to open your files
[18:51] <michaelrose> ex a pdf reader, suppose I could open a file via the terminal via xdg-open or via direct invocation of the program, by clicking on the pdf in my file manager, by selecting the book in calibre
[18:55] <ogra_> michaelrose: most likely similar to what happens on the phone today ... via a system service
[18:55] <ogra_> (called the content-hub on the phone)
[18:56] <ogra_> but thats not yet existing
[18:56] <ogra_> (for desktop)
[19:34] <swami_> need help on downloading kernel source from ubuntu.com and its kicking me out each time. I am behind the firewall; but has the set proxy correctly and able to download kernel.org's or some others without issue
[19:35] <swami_> anyone can help?
[19:36] <swami_> for eg: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_v3.18, how to download this using git clone? any othe settings?
[19:37] <zyga> swami_: I don't think there are any; perhaps download it without the proxy in the way
[19:39] <swami_> dont think proxy is an issue. because I am able to download others from external website. Am I missing something?
[19:39] <josepht> swami_: git clone git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git
[19:40] <zyga> swami_: works for me, try without a proxy
[19:40] <swami_> hmm, thanks zyga.
[19:40] <swami_> I tried this josepht
[19:40] <swami_> have tried git:// http:// and https://
[19:41] <swami_> is there any git/ssh settings that I should consider about?
[19:41] <zyga> swami_: it looks like your proxy is just broken
[19:42] <zyga> swami_: if it is any consent, I have never seen a corpo proxy that didn't break everything apart from websites
[19:42] <zyga> s/consent/comfort/ (I guess)
[19:42] <swami_> when I tried the above command, it shows me this:
[19:42] <swami_>  git clone git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git Cloning into 'ubuntu-vivid'... fatal: unable to connect to kernel.ubuntu.com: kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection timed out
[19:43] <swami_> got http, it shows: Cloning into 'ubuntu-vivid'... fatal: repository 'http://kernel.ubuntu.com/ppisati/ubuntu-vivid.git/' not found
[19:43] <swami_> *for
[19:44] <josepht> swami_: only git:// and https:// work for me.  I imagine http:// isn't being served.
[19:46] <swami_> for git, connection timed out. for https, below. :(
[19:46] <swami_> Cloning into 'ubuntu-vivid'... fatal: unable to access 'https://kernel.ubuntu.com/ppisati/ubuntu-vivid.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.
[19:47] <jdstrand> beuno: hey, could someone sync review tools r627? this removes old-security, fixes a couple bugs and makes sdoc stuff work ok again
[19:48] <JanC> sounds like a broken proxy indeed...
[19:49] <swami_> thanks. how to verify that proxy is working? some other ways to check
[19:55] <michaelrose> so regarding the content hub, A) what does that mean for non ubuntu machines B) does that mean that the content hub replaces xdg-open et al C) does that mean all of the above ways to open the pdf still work seamlessly or do they have to be rewritten to take it into account
[20:03] <beuno> jdstrand, sure
[20:04] <michaelrose> reading this https://developer.ubuntu.com/en/phone/platform/guides/content-hub-guide/ sort of looks like I couldn't just open a file from the filesystem with an arbitrary app seems like I would have to open the owning app, say the gallery app for pictures
[20:05] <michaelrose> and pic an app to share it with kind of android style
[20:06] <michaelrose> although the receiving app can use say the gallery app is a file picker
[20:10] <michaelrose> mostly what I'm wondering is how easy it will be to rip apart a snappy package and use it on a non ubuntu system that doesn't have content hub or any of that junk