[01:38] <elopio> kallisti5: hello. Our core is 16.04.
[01:38] <elopio> you can install xenial, and run sudo snap install hello-world.
[03:09] <sergiusens> elopio can you `gbp buildpackage` master?
[04:31] <sethj> shoot, accidentally ctrl+c'd snap remove, now it won't remove the snap because "there are changes in progress".
[04:31] <sethj> is there a lockfile somewhere?
[04:37] <sethj> oh huh, seems to have fixed itself. Must have still been doing stuff. Nice.
[05:54] <zyga> o/
[05:54] <zyga> blackout24: hey
[06:04] <didrocks> elopio: hey! do you need anything from me?
[06:05] <elopio> didrocks: we were trying to land your branch yesterday, but Sergio already went to bed.
[06:06] <elopio> there is one error on simple fix in your branch, that's updating the debian/tests. The big problem is that it throws a bad system call.
[06:06] <didrocks> elopio: yeah, I have no idea on this
[06:06] <elopio> didrocks: and anyway, we'll have to skip them until IS opens the proxy.
[06:06] <didrocks> elopio: ok, let me repull on my PR if Sergio already went to bed and I can try having a look, just in case I can find what bad system calls it is (running in autopkgtests)
[06:07] <didrocks> making sense?
[06:07] <elopio> didrocks: sure. If you can fix it before he wakes up, awesome. Otherwise we can land it to get started and fix it in the following version.
[06:07] <didrocks> elopio: yeah
[06:07] <didrocks> sounds work, echo should be the built-in version in shell
[06:08] <didrocks> weird*
[06:18] <elopio> didrocks: building the package in a lxc I'm getting this error: https://paste.ubuntu.com/16941250/
[06:18] <elopio> doesn't seem critical, because the build works in the ppa.
[06:20] <didrocks> elopio: hum, will look as well, I wonder if others path are screwed as well when building inside the container
[06:21] <didrocks> elopio: you should probably go to bed btw :)
[06:29] <elopio> didrocks: yes, I'm done now. I just build your branch, installed the deb and verified that all looks good. This will be released for sure when Sergio gets up.
[06:29] <elopio> thanks, and see you later.
[06:30] <didrocks> elopio: thanks to you! I'm working on this test meanwhile
[07:22]  * zyga -> off
[07:48] <davidcalle> Morning o/
[07:50] <didrocks> hey davidcalle
[07:53] <dholbach> davidcalle, nice work on the summary!
[07:59] <davidcalle> Hopefully, next week's will be much bigger thanks to the playpen :)
[08:05] <dholbach> :-)
[08:05] <dholbach> davidcalle, dpm, mhall119, popey: I set up https://gitter.im/ubuntu/snappy-playpen (as an experiment)
[08:07] <davidcalle> dholbach: nice! Waiting for you in there :P
[08:08] <dpm> thanks dholbach!
[08:33] <zyga-phone> o/
[08:33] <zyga-phone> Irc from ubuntu phone :-)
[08:36] <ysionneau> tyhicks: hi! Will you be working on the issue some more or are you stuck?
[09:04] <dholbach> please share:
[09:04] <dholbach> https://plus.google.com/u/0/b/107265043789873157543/107265043789873157543/posts/PhXG5s7nBEQ
[09:04] <dholbach> https://www.facebook.com/ubuntudev/posts/1133350713383215
[09:06] <dholbach> https://twitter.com/ubuntudev/status/738658113100894208
[09:25] <ePierre> dholbach, cool! Shared on G+
[09:26] <dholbach> <3
[09:44] <didrocks> dholbach: tuesday, midnight? :)
[09:46] <dholbach> didrocks, it asked me for a time
[09:46] <dholbach> the best I could do was 0:00 → 23:59
[09:47]  * didrocks sends a pager to dholbach :)
[09:47] <didrocks> 0:00 sharp! :)
[10:10] <davidcalle> !remindme telegram dholbach at 0:00 on tuesday
[10:10]  * didrocks wants a dholbachnugger snap
[10:11] <didrocks> nagger*
[10:27] <dholbach> didrocks, dholbachhugger you wanted to say, right?
[10:27] <didrocks> dholbach: oh right, right, right… :)
[11:05] <dpm> ogra_, zyga, sergiusens, have you or would you happen to know someone who has tried snapping Java apps for the desktop? A contributor submitted a Java example for the snappy-playpen repo, and I'm wondering if we could give them a hand with getting the snap to start
[11:06] <dpm> https://github.com/ubuntu/snappy-playpen/pull/22/files
[11:23]  * ogra_ has never packaged any java
[11:24] <ogra_> i think lool has ... but quite a while ago (pre snapcraft iirc)
[11:41] <dpm> ok, thanks ogra_, I'll ask him. Or jamiebennett, do you know if someone on the team has looked at snapping java apps and could give a hand to a community member? https://github.com/ubuntu/snappy-playpen/pull/22/files
[11:42] <sgclark> hi all. I have a bunch of frameworks ( libraries ) that I would like to snap and use those snaps inside snaps rathers than rebuilding them a billion times. Is this possible? if so please point me to the docs, I cannot find them.
[11:44] <ogra_> i'm not sure that is possible yet (it is definitely planned) ... zyga would know if the necessary interfaces exist already
[11:51] <sergiusens> sgclark it will be possible, not just yet. As ogra_ mentions, zyga has the timelines for that
[11:51] <sgclark> ah ok.
[11:52] <sgclark> I look forward to it then lol
[11:56] <sergiusens> sgclark as do we all :)
[12:11] <mhall119> sgclark: are you talking about KDE frameworks?
[12:11] <sgclark> mhall119: yep
[12:11] <mhall119> if so, I think the content-sharing interface will allow us to share those libs with other snaps
[12:11] <mhall119> but, as they said above, it's not available yet
[12:12] <sgclark> ok cool
[12:12] <mhall119> sgclark: for now we can just bundle them in the apps, like I did for Krita
[12:12] <sgclark> I am breaking them out
[12:13] <sgclark> not using archive for anything kde
[12:13] <mhall119> sgclark: take a look at my final snapcraft.yaml for Krita: https://quickgit.kde.org/?p=krita.git&a=blob&h=821060a782043dd134c6975182830d29dea8e87c&hb=b11ca95c668a99e4c07c39641a0e85d5f24c3dee&f=packaging%2Flinux%2Fsnap%2Fsnapcraft.yaml
[12:13] <mhall119> I split kdeframeworks and qt into separate parts
[12:14] <mhall119> the just use archive packages now, but you could replaced the nil plugin with cmake or whatever KDE frameworks use, and point them to a git source
[12:14] <mhall119> I actually have that on my list of things to try with Krita to get the newest Qt
[12:14] <sgclark> ok
[12:15] <sgclark> yeah I tried to break out qt but it failed, needs new plugin but I could not get it sorted yet
[12:15] <mhall119> Qt doesn't use cmake?
[12:15] <sgclark> nope
[12:16] <mhall119> oh, right, it's qmake isn't it
[12:16] <sgclark> it uses it's own form of configure and autotools plugin barfed
[12:16] <sgclark> it needs a new plugin basically.
[12:16] <mhall119> ok
[12:16] <sgclark> I will hack at it more.
[12:17] <mhall119> let me know if I can help, but it sounds like you know more about this than I do
[12:17] <sgclark> ty
[12:18] <mhall119> sgclark: is there a specific app your working on currently?
[12:18] <sgclark> kdevelop
[12:18] <mhall119> oh, that's a big one
[12:18] <sgclark> aye
[12:19] <sgclark> got it running and all, but some usage kinks I am working out.
[12:19] <sgclark> Also I need to know where I can upload snaps for others to test
[12:20] <sgclark> I prefer not testing in the store haha
[12:20] <mhall119> there's actually a testing channel in the store, but I don't know if that's all working now or not
[12:21] <mhall119> you can pretty much put the snap anywhere, even people.ubuntu.com
[12:22] <sgclark> ok
[12:24] <kyrofa> sgclark, a qmake plugin is scheduled for the next snapcraft release
[12:24] <kyrofa> You can use a local qmake plugin temporarily until it's in place. Are you familiar with local plugins?
[12:24] <sgclark> ah cool
[12:24] <sgclark> yes I am familiar
[12:24] <kyrofa> Okay good deal
[12:25] <sgclark> part/plugins/myplugin.py
[12:25] <kyrofa> Yep, you got it
[12:55] <ysionneau> zyga: I'm reading this: https://github.com/CanonicalLtd/ubuntu-image/blob/master/docs/image-yaml.rst
[12:55] <qengho_> Could there any mechanism for a snappy package to open a web page in the user's browser without providing a browser, or is that philosophically outside of snaps?
[12:56] <ysionneau> what is it you call "an assertion" or "the model assertion" ?
[12:56] <ysionneau> not clear to me (not native speaker)
[12:56]  * ogra_ notes that qengho_ wears a ponytail today
[12:56] <ogra_> oh, chopped off !
[12:57] <ogra_> qengho, i'd say thats the job of an outside service ... but snappy/snapd should be able to invoke it and hand the url to it
[12:57] <ogra_> much like we do on the phone
[12:58] <qengho> "Connection lost to chat.freenode.net" <- hair source
[12:58] <ogra_> heh
[13:01] <qengho> ogra_: So, "One day, maybe."
[13:01] <ogra_> yeah
[13:02] <ogra_> well, once we switch to unity8 we'll get such stuff for free ... i guess it will only need some minor adjustments and some oof zyga's time to plumb an interface on top of the existing parts
[13:02] <qengho> Hmm. 8. I bet there's some DBus thing that will do it now.
[13:03] <ogra_> there is xdg-open as well
[13:03] <ogra_> not sure that is considered secure enough though
[13:04] <qengho> xdg utils would run inside the snap and try to search for one there.
[13:05] <ogra_> no, i mean an interface to the desktop side that would spawn xdg-open with an url you hand to it
[13:06] <ogra_> i guess that could work
[13:07] <qengho> Yeah! Something could pretend to be xdg-open. xdg utils are hilariously primitive shell scripts, though.
[13:08] <ogra_> the point is that snapd needs to trigger it through the unity7 interface or some such
[13:09]  * ogra_ has no deep insight inot interfaces or how they actually work internally though ... probably i'm on the wrong track, thats zyga land :) )
[13:12] <ogra_> oh
[13:12] <ogra_> i wasnt aware jospoortvliet is actually lurking here :)
[13:13] <kyrofa> ogra_, how do you think the owncloud snap started? :P
[13:13] <ogra_> with you running after the guys in their channels :)
[13:14] <ogra_> awesome to see him aound here
[13:16] <Chipaca> jdstrand: if a snap says confinement:devmode the user must provide either --devmode or --confined
[13:16] <Chipaca> jdstrand: (i'm implementing that now)
[13:16] <Chipaca> it's going to be ~3 branches, fwiw
[13:17] <jdstrand> ack
[13:18] <jdstrand> Chipaca: though the yaml has confinement:devmode|strict. shouldn't the flags be --devmode|--strict?
[13:18] <Chipaca> jdstrand: well, no: as a user, what does `snap install foo --strict` do?
[13:19] <Chipaca> it's --confinement={devmode,strict}, with --devmode and --confined shortcuts for those
[13:19] <Chipaca> *handwaving for things that are not implemented*
[13:19] <jdstrand> Chipaca: fair point, though, I thought --confined was the default
[13:19] <Chipaca> jdstrand: it is
[13:19] <jdstrand> when would you use --confined?
[13:20] <Chipaca> jdstrand: when you want to override the snap
[13:20] <jdstrand> Chipaca: but if it is always installed confined unless you specify --devmode?
[13:20] <Chipaca> jdstrand: if the snap specifies "confinement:devmode", asking to install it on its own will fail
[13:20] <jdstrand> basically, my understanding was that you always had to use --devmode to install in devmode
[13:21] <jdstrand> oh I see
[13:21] <Chipaca> jdstrand: it's more a ux thing, i guess: if the snap says devmode, it probably won't work without --devmode, so bail
[13:21] <jdstrand> if confinement:devmode, no args, fail with msg, --devmode installs, --confined allows install
[13:21] <Chipaca> jdstrand: but still have a way for dev to override for testing or whatever
[13:21] <Chipaca> exactly
[13:22] <jdstrand> ok, that makes sense
[13:22] <jdstrand> though, --confined does feel exactly right to me, but if that is what's designed, I certainly won't block on it
[13:22] <jdstrand> doesn't*
[13:46] <kyrofa> ogra_, FYI, Mark invalidated #1586400. I know you weren't a huge fan
[13:47] <kyrofa> Darn pattern patching. bug #1586400
[13:47] <ogra_> kyrofa, well, i wasnt a fan of the rename
[13:47] <ogra_> (teh package rename ... i dont really care about the internally used type)
[13:47] <kyrofa> Oh, okay
[13:47] <ogra_> the package will still have to be renamed
[13:47] <kyrofa> Indeed, yes
[13:48] <elopio> didrocks: https://launchpadlibrarian.net/263311094/buildlog_ubuntu-xenial-amd64.snapcraft_2.9~ppa5-1_BUILDING.txt.gz
[13:48] <elopio> the gettour test failed /o\
[14:01] <ysionneau> I guess the kernel/ubuntu-core fallback mechanism only works if u-boot supports the saveenv command?
[14:03] <didrocks> elopio: seriously? (in a meeting, looking)
[14:04] <didrocks> elopio: it did build in your ppa though?
[14:04] <didrocks> it seems that PKGBUILDDIR wasn't expanded, any idea?
[14:05] <elopio> didrocks: yesterday. But if failed today, not sure what's the difference.
[14:05] <didrocks> elopio: this code isn't enabled, we can skip it to not block release
[14:05] <elopio> I think PKGBUILDDIR is the name of the dir, isn't it.
[14:05] <didrocks> yeah
[14:05] <elopio> didrocks: ok, let me make the PR.
[14:05] <didrocks> normally, setup.py expands it
[14:14] <elopio> didrocks: sergiusens: https://github.com/ubuntu-core/snapcraft/pull/547
[14:14] <didrocks> elopio: sorry for the additional work I'll have a look to the build system later
[14:14]  * popey waves https://github.com/ubuntu/snappy-playpen/pull/24 at dholbach / didrocks  :)
[14:16] <dholbach> popey, nice one
[14:16] <lool> dpm, ogra_: Re: java – there's a maven example in snapcraft (has been one of the first plugins :-)
[14:16] <dholbach> popey, oh, can you add a line to https://github.com/ubuntu/snappy-playpen#current-project-status?
[14:17] <elopio> didrocks: no worries. I'm ok with getting all these unskipped for the next week. And the tour is looking great, so I'm happy.
[14:17] <lool> dpm, ogra_: it would need some love post xenial (moving to newer jre, allowing for oracle jre etc.) and I'm sure there are plenty of other systems which would need wrapping – I believe there's also an ant plugin
[14:18] <dpm> lool, I'm not familiar with maven, but if I understand it correctly, it does not have a GUI? The issue we've got is with getting a Java (GUI) app run on the destkop
[14:19] <tyhicks`> ysionneau: I will be the one working on the issue but the problem is time
[14:19] <tyhicks`> ysionneau: I've got a few too many things needing my attention today and I'm off all next week
[14:21] <didrocks> popey: in meeting, will do next :)
[14:21] <lool> dpm: maven is a build system
[14:21] <lool> dpm: it might be used to build any piece of java software
[14:22] <lool> dpm: I'm not sure java gui app is much different from any GUI app (outside of the interfaces you want to require)
[14:22] <popey> dholbach: done https://github.com/ubuntu/snappy-playpen/pull/25
[14:22] <lool> sorry I meant from any Java app
[14:23] <dpm> lool, assuming we're running it in devmode, I'm guessing that a Java GUI app should have its own set of fonts and X env variables, though
[14:25] <lool> dpm: X env is the same as for other GUI snaps; fonts is a good question, it depends on which java stack is being used; I would think the runtime pulls in enough by default though
[14:25] <didrocks> sergiusens: elopio: I'll ensure I understand what the issue is in the build system
[14:25] <dholbach> thanks popey
[14:26] <lool> dpm: I guess it's a case for trying it out really; we can see how to best deal with the general case from there?
[14:26] <popey> dholbach: np, thanks for reviewing
[14:26] <ogra_> ysionneau, yes, but the enforced use of uboot.env makes sure that saveenv always works
[14:27] <ogra_> ysionneau, thats one of the reasons we switched to it
[14:27] <dpm> lool, I'm not sure, I'm not familiar with Java GUI apps at all, but with the experience of having snapped a couple of Qt apps that required 40+ lines of env variables being set, I would imagine that Java GUI apps would be similar in that regard
[14:27] <dholbach> popey, so far the process and everything is working out quite nicely
[14:27] <popey> ya
[14:27] <popey> i agree
[14:27] <popey> its fun
[14:27] <popey> I am _starting_ to like github
[14:28] <dpm> good work guys
[14:28] <popey> i like doing ninja inline edits directly on github.com and turning those into PRs
[14:28] <popey> which is what i did for the readme
[14:28] <ogra_> popey, if only it would support bzr :P
[14:28] <popey> cvs forever!
[14:28] <ogra_> or that !
[14:31] <fgimenez> hey jdstrand :) iirc you were asking a few days ago about security related integration tests, if you have any test cases in mind pls let me know and i can begin writing them
[14:40] <didrocks> popey: "I am _starting_ to like github" -> I remember what you told during the sprint :p
[14:40] <didrocks> see, you are getting at it!
[14:44] <ysionneau> ogra_: so if I use default config (built in) and disable saveenv, fallback won't work
[14:44] <ysionneau> good to know
[14:44] <ysionneau> (for some reason we deactivated the uboot.env stuff)
[14:44] <ogra_> well, just ennable it and you should be fine :)
[14:44] <ysionneau> yep
[14:45] <ogra_> i guess snapd would fall over when you do kernel snap updates ... it actually wants to update uboot.env
[14:46] <jdstrand> fgimenez: oh I have a list!
[14:47] <jdstrand> fgimenez: let me email you. should I CC anyone?
[14:47] <fgimenez> jdstrand, great, sure elopio will be interested too
[14:47] <jdstrand> ok, let me get that to you
[14:51] <didrocks> ofc minetest
[14:52] <mhall119> sgclark: is your kdevelop snapcraft.yaml available somewhere for me to try?
[14:56] <ysionneau> ogra_: I could just put a fake uboot.env, that's what I do right now :p
[14:57] <sgclark> nope, not done
[14:58] <sgclark> mhall119: and I cannot get your sections thing to work with frameworks being parts
[14:59] <mhall119> sgclark: are you using the nil plugin and archive packages like mine, or are you trying ot build from source?
[14:59] <sgclark> no, I am using upstream source for frameworks
[14:59] <popey> hey sgclark !
[14:59] <mhall119> ok, what's not working? does it compile the upstream source?
[14:59] <sgclark> upstream source for kde*
[14:59] <popey> sgclark: you back from vacation / visiting family?
[15:00] <sgclark> hi popey :)
[15:00] <sgclark> yeah
[15:00] <sgclark> sponsered to work on snappy, I am a happy camper
[15:00] <sgclark> sponsored*
[15:00] <mhall119> \o/
[15:00] <popey> Wat! That's awesome news!
[15:00] <sgclark> it is :)
[15:00] <popey> I'm so happy for you!
[15:00] <ogra_> ysionneau, well, there is code that calls fw_setenv in snapd
[15:00] <popey> Today is a good day.
[15:01] <ogra_> ysionneau, not sure what happens if it cant actually set the vars
[15:01] <sgclark> ty
[15:01] <ogra_> ysionneau, so i'd suggest to just support it
[15:08] <ysionneau> I think even "snap list" just fails without a uboot.env
[15:09] <ysionneau> how can I put a file in a directory using the gadget snap? (boot-assets)
[15:09] <ogra_> yeah
[15:09] <ogra_> (to both)
[15:09] <ysionneau> like creating dir_a/file_b
[15:09] <ogra_> :)
[15:09] <ogra_> oh
[15:09] <ogra_> subdirs ?
[15:09] <ogra_> not supported
[15:09] <ysionneau> so far the syntax I use is : - path: boot-assets/uboot.env
[15:09] <ogra_> (currently)
[15:09] <ysionneau> but I don't specify the target dir
[15:10] <ysionneau> arg, too bad I needthis :x
[15:10] <ogra_> right, everything will go into the toplevel of the vfat
[15:10] <ogra_> file a bug please ...
[15:10] <ysionneau> on which project?
[15:10] <ogra_> (it would help for raspberry pi overlay dtbs too)
[15:10] <ogra_> just snappy
[15:10] <ogra_> (see topic)
[15:11] <ysionneau> ah good, thanks
[15:11] <ogra_> let me know the bug # ... i'll confirm it
[15:12] <ysionneau> https://bugs.launchpad.net/snappy/+bug/1588864
[15:13] <ogra_> thanks !
[15:13] <ysionneau> you're welcome!
[15:15] <ogra_> zyga, ^^^ thats technically a u-d-f limitation that we need to weed out in ubuntu-image
[15:19] <sergiusens> elopio https://github.com/ubuntu-core/snapcraft/pull/547
[15:19] <sergiusens> elopio master is just missing that now
[15:21] <elopio> crazy jenkins error
[15:22] <elopio> sergiusens: updated, the tests are running again.
[15:23] <sergiusens> elopio rebased even?
[15:23] <elopio> this is good to merge as soon as the travis execution is good.
[15:24] <sergiusens> elopio sounds good
[15:36] <qengho> What's a good way to test from inside a snap if it's in devmode or not?
[15:37] <ogra_> do something that would normally be confined and check the exit code ?
[15:38] <qengho> Yeah. Trying to pick something good.
[15:54] <ysionneau> hmmm
[15:54] <ysionneau> I'm generating an image with ubuntu-device-flash for my Paros board. the initrd's init fails because it cannot mount the gadget/kernel/core snaps
[15:55] <ysionneau> itsearches for them in system-data/var/lib/snappy/snaps instead of system-data/var/lib/snapd/snaps
[15:55] <ysionneau> :o
[15:57] <kgunn> jdstrand: hey, finally back to working on mir interface and it's trying to fire up now....so i'm seeing denials for aa "open" "r" on "/run/udev/data/+drm:card0-virtual1", 2,3,4
[15:58] <ysionneau> what could make UDF generate wrong init in the initrd?
[15:58] <kgunn> but i have in my aa slot /run/udev/data/* r,
[15:58] <kgunn> and / run/udev/** rw,
[15:59] <ysionneau> FYI I'm generating with : sudo ./ubuntu-device-flash --verbose core 16 -o paros.img --channel edge --gadget ../paros_1.0_all.snap --kernel ../paros_kernel/tmp/paros-kernel_3.10.67_armhf.snap --os ubuntu-core --enable-ssh
[16:02] <jdstrand> kgunn: /dev/run/** rw, would cover it. I suspect it isn't in the right part of your policy (permanent vs connected slot and permanent vs connected plug)
[16:04] <mhall119> hey guys, what's the process for getting a new interface added to snappy?
[16:16] <kyrofa> mhall119, a zyga question
[16:16] <kyrofa> mhall119, this might get you part of the way there: http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html
[16:18] <mhall119> thanks kyrofa
[16:18] <mhall119> and am I correct in thinking that snaps can't deliver new interfaces?
[16:19] <kgunn> they all have to builtin atm
[16:19] <kyrofa> mhall119, correctly snaps don't deliver interfaces (they're a snapd thing), but they can deliver slots for interfaces
[16:19] <kgunn> they==interfaces in my response
[16:19] <kyrofa> s/correctly/correct/, not sure how I messed that one up
[16:19] <mhall119> here's my use-case: ElementaryOS apps use a thing called Contractor, which is a dbus service for content-sharing between their apps, it's provided by ElementaryOS and Pantheon desktop, but not part of a stock Ubuntu
[16:19] <kyrofa> Yeah, perfect candidate for an interface
[16:20] <mhall119> kyrofa: ok, but ubuntu-core doesn't provide the actual service, so how will apps know if the system they're installed on actually has that dbus service?
[16:21] <kyrofa> mhall119, there are a few options
[16:23] <kyrofa> mhall119, first of all, while all interfaces have to be explicitly supported by snapd, there's also the concept of interface connections, i.e. there's the slot (the producer side of the interface) and a plug (the consumer side). If you install a snap with a plug for this interface, but there's no snap install providing the slot, that interface simply cannot connect
[16:24] <kyrofa> So if a snap expects this dbus service to be present but nothing is serving it, snapd won't connect them and you'll see that reflected in `snap interfaces`
[16:25] <kyrofa> mhall119, this may also fit into the new "assumes" work, which is a set of features that a snap can request of the system; if they're missing installation will fail
[16:25] <kyrofa> mhall119, though I'm a little more fuzzy on that one
[16:30] <kyrofa> mhall119, finally, we have some sort of content sharing interface planned, though not spec'd just yet. Those two things may overlap
[16:30] <sergiusens> kyrofa mhall119 the scenario you describe seems pretty similar to what kgunn did with mir
[16:30] <mhall119> kyrofa: ok, so if I understand correct, we would add a "contractor" interface to snapd, and then an actual snap that contains the dbus service and provides the "contractor" slot
[16:31] <sergiusens> the interface is added to snapd, but the implementation of a slot for that interface would be a snap
[16:31] <sergiusens> could be
[16:31] <kyrofa> mhall119, you got it
[16:31] <mhall119> sergiusens: ack, what I was thinking
[16:31] <mhall119> ok, cool
[16:37] <ysionneau> ogra_: I just recompiled the kernel snap and the initrd seems to be still old :o
[16:38] <ogra_> oh ?
[16:38] <ogra_> sergiusens, ^^ does the kernel plugin not pull the latest initrd when you re-build ?
[16:39] <sergiusens> ysionneau ogra_ just like it doesn't pull new code from the kernel sources, pulling (as stated in your message) is a pull step ;-)
[16:40] <ogra_> sergiusens, i assume deleting the initrd would pull it automatic ? or do you still need a manual pull ?
[16:40] <ysionneau> I deleted the snap directory and the .snap file and did "snapcraft --target-arch arm64 snap"
[16:40] <sergiusens> ogra_ same as if you deleted something from vcs
[16:40] <sergiusens> we could make it warn you
[16:40] <ogra_> (assuming initrd is an essential part, i would expect snapcraft to make sure it is there)
[16:41] <ogra_> yeah, we definitely should
[16:41] <ogra_> or make it fail the build even
[16:41] <ogra_> it wont boot without initrd ...
[16:41] <ogra_> so there is no use in building it
[16:41] <ysionneau> except I do have an initrd :o
[16:42] <ogra_> we have a long term plan for booting with two initrds ... the script bits would then come from the os snap
[16:42] <ogra_> so you get the latest with an os upgrade ... (to de-couple the kernel snap )
[16:42] <sergiusens> ogra_ the kernel plugin is experimental, so errors are allowed :-P
[16:43] <ogra_> but thats a bit further down the roead
[16:43] <ysionneau> is there any quick thing I can do to unblock me?
[16:43] <sergiusens> ogra_ I don't feel like adding a bunch of logic for something that is scheduled to go away, so all I can say is, hurry up!
[16:43] <sergiusens> ;-)
[16:43] <ogra_> sergiusens, well, we shouldnt allow building unbootable kernel snaps imho :)
[16:43] <sergiusens> ogra_ they will be unbootable as soon as the spec changes
[16:43] <ogra_> go away ?
[16:43] <ogra_> it will change ... why would it go away
[16:43] <sergiusens> ogra_ the need to download the generic initrd is going away
[16:44] <ogra_> ah
[16:44] <ogra_> well, but thats definitely post GA
[16:44] <ogra_> so rather far out
[16:44] <sergiusens> so there is not much logic there; and we won't spend precious time on that
[16:44] <ogra_> ok
[16:44] <sergiusens> in the meantime, don't delete files in `parts`
[16:45] <sergiusens> ysionneau to get around it, snapcraft clean is what you would need to do
[16:45] <sergiusens> kyrofa we should consider making an explicit call on a command do it again and mark what follows dirty
[16:45] <ysionneau> hmm ok, isn't it the same as removing all directories?
[16:45] <ysionneau> because I did that :o
[16:46] <sergiusens> ysionneau sort of, sometimes, depends on the directories removed
[16:46] <ysionneau> ok let's rebuild
[16:47] <sergiusens> elopio kyrofa https://github.com/ubuntu-core/snapcraft/pull/548
[16:48] <kyrofa> ysionneau, snapcraft does a lot of state tracking for the directories and files it deals with. It currently doesn't do a good job of handling your blowing stuff out from under it
[16:48] <kyrofa> ysionneau, if you can use the `snapcraft clean` command it'll keep it happy
[16:49] <kyrofa> ysionneau, for example, if you stage two parts, you can actually `snapcraft clean partA --step=stage` and it'll unstage only partA's stuff
[16:49] <kyrofa> ysionneau, try doing that by hand ;)
[16:51] <ysionneau> nice!
[16:51] <ysionneau> well done
[16:55] <ysionneau> ogra_ sergiusens still using old paths in initrd
[16:55] <ogra_> did it actually download an os snap ?
[16:55] <ysionneau> I don't think so
[16:55] <ysionneau> let me c/c
[16:56] <ogra_> i wonder if you have an old cached os snap somewhere
[16:56] <ysionneau> http://pastebin.com/DLbSHvcy
[16:56] <ysionneau> I did a snapcraft login before, and a snapcraft pull
[16:57] <ogra_> weird
[16:57] <ysionneau> where would this os snap be cached?
[16:59] <ysionneau> I also unsquafs'ed it, to modify meta/snap.yaml to adapt the architecture because of some UDF bug and then resquashfs'ed . But I doubt it is causing my issue
[16:59] <ogra_> yeah
[17:01] <ogra_> well ... https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/kernel.py has
[17:01] <ogra_>         snapcraft.download(
[17:01] <ogra_>             'ubuntu-core', 'edge', self.os_snap, self.project.deb_arch)
[17:01] <ogra_> no idea where the snap it downloads goes though
[17:01] <ysionneau> I have snapcraft 2.8.7
[17:02] <ogra_> thats rather old ...
[17:03] <ogra_> though i dont think that specific part of it changed actually
[17:04] <ogra_> probably kyrofa knows where such downloads go
[17:04] <ysionneau> ahah
[17:05] <ysionneau> I think I got it
[17:05] <ogra_> explicit "pull" ?
[17:05] <ysionneau> download() is downloading in .... self.sourcedir + 'os.snap'
[17:05] <ogra_> ah
[17:05] <ysionneau> so os.snap is in my kernel source dir
[17:05] <ysionneau> which I didn't clean
[17:05] <ysionneau> and I bet snapcraft clean didn't remove it
[17:05] <ogra_> evil
[17:06] <ysionneau> "downloading ubuntu-core" ...
[17:06] <ysionneau> o/
[17:06] <ogra_> yay
[17:07] <ysionneau> who was bragging about "snapcraft clean" again ? :p
[17:07] <ogra_> lol
[17:17] <ysionneau> ogra_: IT BOOTS
[17:18] <ysionneau> \o/
[17:18] <ogra_> yay
[17:19] <ysionneau> let's call it a day
[17:19] <ysionneau> thanks a lot
[17:19] <ysionneau> see youhave a nice weekend
[17:19] <ogra_> np :)
[17:19] <ogra_> yeah, enjoy
[17:19] <ysionneau> (shall I file a bug for os.snap being in kernel source ?à)
[17:19] <ogra_> sergiusens, kyrofa ^^ ?
[17:20] <ogra_> (sounds like a bug to me ... but might fall under the same "it will all change anyway" clause from sergiusens )
[17:20] <ysionneau> yep
[17:21] <ysionneau> afk!
[17:23] <kyrofa> ogra_, yeah, probably a sergiusens question
[17:23] <sergiusens> ysionneau kyrofa ogra_ that is easy to fix, but it is also all going away, right?
[17:25] <ogra_> sergiusens, yeah, in a few months
[17:26] <ogra_> (definitely post GA or earliest "around GA")
[17:28] <gouchi> hi
[17:28] <gouchi> can somebody test a snap package http://www.hastebin.com/jerahisuva.hs ?
[17:29] <gouchi> I can't test it because there is an issue when I try to install it on live usb
[17:49] <sergiusens> gouchi building works?
[17:49] <gouchi> sergiusens: yes
[17:49] <sergiusens> gouchi I can later today
[17:49] <gouchi> sergiusens: thank you
[17:49] <sergiusens> gouchi if not, just upload and publish to the edge channel of the store only ;-)
[17:50] <gouchi> sergiusens: I need to see if we can launch it
[17:52] <sergiusens> ok, building now, but my connection is slow
[17:54] <gouchi> sergiusens: thank you
[17:54] <gouchi> sergiusens: the software can work with drm/kms and egl
[17:55] <gouchi> sergiusens: so not sure if need x11 for interfaces, I just added it for devices running on X
[17:56] <ogra_> you surely want the gl interface
[17:56] <gouchi> ogra_: yes I put it
[18:02] <jdstrand> roadmr (cc beuno and noise): can you pull r669 into the store? I've got another couple of things I'm working on and may request another pull before that lands, but wanted to get r669 on the books as it helps with developer velocity
[18:02] <roadmr> jdstrand: will do
[18:02] <jdstrand> thanks!
[18:02] <jdstrand> roadmr: note, this isn't an emergency pull, but sooner is better
[18:03] <jdstrand> if that makes any sense
[18:03] <jdstrand> :)
[18:03] <roadmr> jdstrand: ok, I think we were looking into deploying in the next couple of days
[18:03] <roadmr> jdstrand: yea : "Not in a hurry but would prefer not to wait until next month" :)
[18:03] <jdstrand> great. also note the conversation with nessita-- the the lp team name changed from click-reviewers to store-reviewers
[18:04] <jdstrand> roadmr: ^
[18:04] <jdstrand> hehe, yeah, something like that :)
[18:04] <roadmr> jdstrand: yes, I'm aware of that (*painfully* aware... haha)
[18:04] <jdstrand> oh hrmm.. I didn't mean to cause pain. sorry
[18:05] <roadmr> jdstrand: no worries, we'll get it fixed - honestly our code/spec/infrastructure shouldn't be so vulnerable to branches moving around, so this is a good time to figure that out
[18:05] <jdstrand> I'm glad I could 'help' then :)
[18:06] <roadmr> yeah :) thanks :D
[18:10] <sethj> can anyone help me figure out why this check fails inside the snap, but works just fine when installed from a .deb? https://github.com/colinkeenan/silentcast/blob/master/genffcom#L48
[18:10] <sethj> The files are where they're supposed to be..
[18:10] <sergiusens> elopio https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+build/9858103/+files/buildlog_ubuntu-yakkety-amd64.snapcraft_2.10+16.10_BUILDING.txt.gz
[18:11] <sergiusens> I do have your test skip too
[18:12] <sergiusens> elopio it might seem like we need to remove the test modulee
[18:13] <elopio> sergiusens: hum, I don't understand.
[18:13] <kyrofa> sethj, I assume /usr/share/silentcast something that's supposed to be shipped within the project?
[18:14] <elopio> let me enable the daily on yakkety, to give it a try
[18:14] <kyrofa> sethj, but if it's contained within the snap, it's not in /usr/share
[18:14] <sergiusens> elopio sure
[18:14]  * sergiusens raises fist at didrocks :-P
[18:15] <sethj> kyrofa, I thought that was the whole point of contained, isolated, snaps?
[18:15] <kyrofa> sethj, indeed, what I mean to say is that silentcast isn't in /usr/share. It's in /snap/<snapname>/<snapversion>/usr/share (I assume)
[18:15] <kyrofa> So that's why the check is failing
[18:16] <kyrofa> sethj, snaps aren't chroots
[18:16] <sethj> ah. well I guess that is where I went wrong..
[18:16] <sethj> I was assuming they were like chroots.
[18:16] <kyrofa> sethj, nope, they're not containers, they're just confined
[18:17] <sethj> kyrofa, in which case how would I snap that app successfully then?
[18:17] <kyrofa> sethj, so you could use the $SNAP environment variable in that check
[18:17] <elopio> sergiusens: ah, I skipped the set tour. We have to skip also the get tour.
[18:17] <elopio> pff, this will never end.
[18:17] <sethj> kyrofa, doesn't seem like a successful packaging method if you have to modify the source.
[18:18] <kyrofa> sethj, not a lot you can do with hard-coded source
[18:18] <kyrofa> sethj, it'd be nice if it was more configurable
[18:18] <sethj> hehe, well blaming the source because the packaging method doesn't allow you to set it up properly seems a bit silly ;)
[18:19] <elopio> sergiusens: https://github.com/ubuntu-core/snapcraft/pull/549
[18:21] <kyrofa> sethj, you have source that is hard-coded for an FHS that doesn't apply to snaps. /usr/share is for architecture-independent data. It was created as a place where packages can place their data side-by-side without interfering with one another
[18:21] <kyrofa> sethj, however, snaps don't have to deal with that-- they're isolated
[18:22] <kyrofa> sethj, I'm not saying your source is broken, I'm saying it's making assumptions that don't apply :)
[18:24] <sethj> I'm not sure I would call it isolated if it doesn't act like a chroot.. but that's beside the point. I'm not sure the few pluses of snaps is worth the work of rewriting the app to fit your system, when it already works with the majority of the other packaging systems..
[18:25] <sethj> I liked the idea originally :/
[18:35] <kallisti5> elopio: oh... I was hoping for a minimal install we can base our product appliances on :-(
[18:35] <kallisti5> we have an agreement with ubuntu, however we're starting to look to stripping down the ubuntu install iso
[18:36] <kallisti5> a lot of the automaton on install media generation that Debian provides doesn't work with ubuntu stuff
[18:36] <kallisti5> so we're stuck manually trimming down the os install media :-\
[18:37] <elopio> kallisti5: you can create a minimal image too. We are currently working on the ubuntu-image tool that will make it easier. But you can generate an image only the three snaps: kernel, os and gadget.
[18:37] <elopio> I'm not sure if that's what you are after, though.
[18:38] <kallisti5> elopio: aahh.. that's right
[18:38] <kallisti5> I saw the tool
[18:39] <kallisti5> last time I played with it, it gave a disappointing "this doesn't work right now" :P
[18:39] <sergiusens> kallisti5 the whole image building story in in flux right now, should happen soon though
[18:39] <sergiusens> but not real soon, just soon
[18:39] <kallisti5> huh.  That seems like a pretty important story :P
[18:40] <elopio> ogra_: are you around? I don't know how to dput something to a PPA, for both xenial and yakkety. Only the xenial one appears.
[18:40] <kallisti5> anyway, not judging.
[18:40] <kallisti5> we have a hardware appliance that is BYOH
[18:40] <kallisti5> I get tired of doing battle with ubuntu preseeds :-)
[18:42] <elopio> kallisti5: I would recommend you to jump into the mailing list and explain what you want. You'll get tips of how to do it know, and you'll be able to influence how the new things will be.
[18:44] <kyrofa> kallisti5, we agree that it's a super important story! That's why we're working to make sure the underlying requirements are in place :)
[18:55] <AndyWojo> Is the snappy store live?
[18:57] <kyrofa> AndyWojo, indeed it is
[18:57] <AndyWojo> Where is it at?
[18:57] <kyrofa> AndyWojo, still undergoing development, but definitely in a usable state
[18:57] <kyrofa> AndyWojo, you can upload/publish snaps at http://myapps.developer.ubuntu.com/
[18:59] <AndyWojo> cool
[18:59] <AndyWojo> thanks
[19:00] <AndyWojo> I want to create a snap for some scripts I'm writing in ruby that will just work so the user doesn't need to worry about gems etc
[19:01] <kallisti5> kyrofa: i'd voice these in #ubuntu but I got banned long ago :-)
[19:02] <kyrofa> AndyWojo, excellent idea! You may be the first person to try a snap with ruby, I'd be very curious to see how it goes!
[19:02] <AndyWojo> kyrofa: cool.
[19:02] <AndyWojo> It's a script that is used to copy config files and log files from an OpenStack environment, in a way so you can send to support / pastebin / irc
[19:03] <kyrofa> AndyWojo, where are the config and log files typically located?
[19:04] <kyrofa> AndyWojo, /etc and /var/log ?
[19:04] <AndyWojo> yup
[19:04] <AndyWojo> also does a ps -ef
[19:04] <AndyWojo> to see what's running etc
[19:04] <AndyWojo> custom openstack commands to see whats running
[19:07] <kyrofa> AndyWojo, by default snaps can't reach outside of itself, so make sure you read up on interfaces for how to extend its capabilities: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
[19:07] <kyrofa> AndyWojo, also keep in mind that you can install with --devmode to run unconfined
[19:08] <kyrofa> (should ease development of the snap so you can worry about confinement later)
[19:09] <elopio> maybe it's not appearing because there is already a snapcraft 2.10 in the PPA. I'll wait until the changelog is landed to retry.
[19:09]  * elopio lunch.
[19:23] <sergiusens> elopio after lunch, mind going over the bugs to see if they have correct descriptions?
[19:23] <sergiusens> It shouldn't be needed in theory, but who knows.
[19:23] <elopio> sergiusens: like the SRU template? I've already done that for all 2.10
[19:24] <sergiusens> elopio really? I thought some were missing when I was tagging
[19:24] <sergiusens> I guess it is fine
[19:24] <elopio> I might have missed one, the list is big. But I went one by one. I can quickly check again.
[19:26] <elopio> yep, all good.
[19:26] <elopio> sergiusens: I put the impact under the original description, so maybe you have to scroll to see some.
[20:44] <vejmarie> ok I have been able to fix my free cad font issue
[20:44] <vejmarie> still need to fix the theme issue
[20:45] <vejmarie> and we will have a fully functional snap exactly like the original app
[20:45] <sergiusens> elopio thanks. The only problem I have now is https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=snapcraft :-P
[20:53] <elopio> well, that's a better problem to have than the others.
[20:53] <vejmarie> (the font thing is ugly, but this can help you to understand what is needed)
[21:28] <sergiusens> vejmarie when you say "you" who do you mean?
[21:29] <vejmarie> argh sorry: people who are developing snapcraft
[21:29] <vejmarie> I am trying to track down all the system file that are needed to make it work properly from a graphical perspective to either turn on AppArmor
[21:30] <vejmarie> which in some way I believe is not the right way to proceed I had rather prefer to see the applications coming with there own fonts and theming system (which is the current broken part on freecad)
[21:30] <vejmarie> )
[21:30] <vejmarie> So I am pretty closed to have everything into the snap (by everything I mean things which are needed)
[21:31] <vejmarie> I am checking the GTK theme but it shall be good by sunday night
[21:43] <erio> hello!
[21:43] <vejmarie> hello
[21:44] <erio> vejmarie: I am having a little doubt on writing the snapcraft.yaml
[21:44] <vejmarie> if this is just one it might be good ;) (I am kidding)
[21:44] <vejmarie> I am not a specialist
[21:45] <vejmarie> but let's try to see where is your issue (I am not the only one connected)
[21:45] <erio> ok! I am using plugin: python3
[21:45] <erio> damn
[21:45] <erio> ok
[21:46] <erio> I am using plugin: python3
[21:46] <erio> and there I wrote python-packages:
[21:46] <erio> but I also set a source (from github)
[21:47] <erio> my problem is that my script is getting the source and trying to build things
[21:47] <erio> instead of getting the python-packages first
[21:47] <erio> the source contains a setup.py
[21:47] <erio> and it works when I download and use `pip3 install .`
[21:53] <erio> wait... it worked.
[21:55] <erio> I forgot a dependency needed nevermind.
[22:00] <erio> the end of this tutorial should include how to install
[22:00] <erio> https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap
[22:04] <vejmarie> good to see it working ;) congrats
[22:05] <erio> yeah
[22:05] <erio> I am getting...
[22:05] <erio> Fatal Python error: Py_Initialize: Unable to get the locale encoding
[22:05] <erio> ImportError: No module named 'encodings'
[22:05] <erio> when running...
[22:06] <erio> I added locales as stage-packages
[22:23] <erio> could you guys add a python3 plugin hello world example for snapcraft.yaml somewhere?
[22:23] <erio> is Python 3 the default python inside a snap ?