[01:38] kallisti5: hello. Our core is 16.04. [01:38] you can install xenial, and run sudo snap install hello-world. [03:09] elopio can you `gbp buildpackage` master? === chihchun_afk is now known as chihchun [04:31] shoot, accidentally ctrl+c'd snap remove, now it won't remove the snap because "there are changes in progress". [04:31] is there a lockfile somewhere? [04:37] oh huh, seems to have fixed itself. Must have still been doing stuff. Nice. [05:54] o/ [05:54] blackout24: hey [06:04] elopio: hey! do you need anything from me? [06:05] didrocks: we were trying to land your branch yesterday, but Sergio already went to bed. [06:06] 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] elopio: yeah, I have no idea on this [06:06] didrocks: and anyway, we'll have to skip them until IS opens the proxy. [06:06] 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] making sense? [06:07] 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] elopio: yeah [06:07] sounds work, echo should be the built-in version in shell [06:08] weird* [06:18] didrocks: building the package in a lxc I'm getting this error: https://paste.ubuntu.com/16941250/ [06:18] doesn't seem critical, because the build works in the ppa. [06:20] elopio: hum, will look as well, I wonder if others path are screwed as well when building inside the container [06:21] elopio: you should probably go to bed btw :) [06:29] 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] thanks, and see you later. [06:30] elopio: thanks to you! I'm working on this test meanwhile [07:22] * zyga -> off [07:48] Morning o/ [07:50] hey davidcalle [07:53] davidcalle, nice work on the summary! [07:59] Hopefully, next week's will be much bigger thanks to the playpen :) [08:05] :-) [08:05] davidcalle, dpm, mhall119, popey: I set up https://gitter.im/ubuntu/snappy-playpen (as an experiment) [08:07] dholbach: nice! Waiting for you in there :P [08:08] thanks dholbach! === chihchun is now known as chihchun_afk [08:33] o/ [08:33] Irc from ubuntu phone :-) [08:36] tyhicks: hi! Will you be working on the issue some more or are you stuck? === chihchun_afk is now known as chihchun === FourDollars_ is now known as FourDollars === Trevinho_ is now known as Trevinho [09:04] please share: [09:04] https://plus.google.com/u/0/b/107265043789873157543/107265043789873157543/posts/PhXG5s7nBEQ [09:04] https://www.facebook.com/ubuntudev/posts/1133350713383215 [09:06] https://twitter.com/ubuntudev/status/738658113100894208 [09:25] dholbach, cool! Shared on G+ [09:26] <3 [09:44] dholbach: tuesday, midnight? :) [09:46] didrocks, it asked me for a time [09:46] the best I could do was 0:00 → 23:59 [09:47] * didrocks sends a pager to dholbach :) [09:47] 0:00 sharp! :) [10:10] !remindme telegram dholbach at 0:00 on tuesday [10:10] davidcalle: I am only a bot, please don't think I'm intelligent :) [10:10] * didrocks wants a dholbachnugger snap [10:11] nagger* === Saviq_ is now known as Saviq [10:27] didrocks, dholbachhugger you wanted to say, right? [10:27] dholbach: oh right, right, right… :) === pmp is now known as Guest76230 [11:05] 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] https://github.com/ubuntu/snappy-playpen/pull/22/files [11:23] * ogra_ has never packaged any java [11:24] i think lool has ... but quite a while ago (pre snapcraft iirc) [11:41] 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] 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] i'm not sure that is possible yet (it is definitely planned) ... zyga would know if the necessary interfaces exist already [11:51] sgclark it will be possible, not just yet. As ogra_ mentions, zyga has the timelines for that [11:51] ah ok. [11:52] I look forward to it then lol [11:56] sgclark as do we all :) [12:11] sgclark: are you talking about KDE frameworks? [12:11] mhall119: yep [12:11] if so, I think the content-sharing interface will allow us to share those libs with other snaps [12:11] but, as they said above, it's not available yet [12:12] ok cool [12:12] sgclark: for now we can just bundle them in the apps, like I did for Krita [12:12] I am breaking them out [12:13] not using archive for anything kde [12:13] 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] I split kdeframeworks and qt into separate parts [12:14] 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] I actually have that on my list of things to try with Krita to get the newest Qt [12:14] ok [12:15] yeah I tried to break out qt but it failed, needs new plugin but I could not get it sorted yet [12:15] Qt doesn't use cmake? [12:15] nope [12:16] oh, right, it's qmake isn't it [12:16] it uses it's own form of configure and autotools plugin barfed [12:16] it needs a new plugin basically. [12:16] ok [12:16] I will hack at it more. [12:17] let me know if I can help, but it sounds like you know more about this than I do [12:17] ty [12:18] sgclark: is there a specific app your working on currently? [12:18] kdevelop [12:18] oh, that's a big one [12:18] aye [12:19] got it running and all, but some usage kinks I am working out. === JanC is now known as Guest27710 === JanC_ is now known as JanC [12:19] Also I need to know where I can upload snaps for others to test [12:20] I prefer not testing in the store haha [12:20] there's actually a testing channel in the store, but I don't know if that's all working now or not [12:21] you can pretty much put the snap anywhere, even people.ubuntu.com [12:22] ok [12:24] sgclark, a qmake plugin is scheduled for the next snapcraft release [12:24] You can use a local qmake plugin temporarily until it's in place. Are you familiar with local plugins? [12:24] ah cool [12:24] yes I am familiar [12:24] Okay good deal [12:25] part/plugins/myplugin.py [12:25] Yep, you got it === hikiko is now known as hikiko|ln [12:55] zyga: I'm reading this: https://github.com/CanonicalLtd/ubuntu-image/blob/master/docs/image-yaml.rst [12:55] 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] what is it you call "an assertion" or "the model assertion" ? [12:56] not clear to me (not native speaker) [12:56] * ogra_ notes that qengho_ wears a ponytail today === qengho_ is now known as qengho [12:56] oh, chopped off ! [12:57] 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] much like we do on the phone [12:58] "Connection lost to chat.freenode.net" <- hair source [12:58] heh [13:01] ogra_: So, "One day, maybe." [13:01] yeah [13:02] 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] Hmm. 8. I bet there's some DBus thing that will do it now. [13:03] there is xdg-open as well [13:03] not sure that is considered secure enough though [13:04] xdg utils would run inside the snap and try to search for one there. [13:05] no, i mean an interface to the desktop side that would spawn xdg-open with an url you hand to it [13:06] i guess that could work [13:07] Yeah! Something could pretend to be xdg-open. xdg utils are hilariously primitive shell scripts, though. [13:08] 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] oh [13:12] i wasnt aware jospoortvliet is actually lurking here :) [13:13] ogra_, how do you think the owncloud snap started? :P [13:13] with you running after the guys in their channels :) [13:14] awesome to see him aound here === hikiko|ln is now known as hikiko [13:16] jdstrand: if a snap says confinement:devmode the user must provide either --devmode or --confined [13:16] jdstrand: (i'm implementing that now) [13:16] it's going to be ~3 branches, fwiw [13:17] ack [13:18] Chipaca: though the yaml has confinement:devmode|strict. shouldn't the flags be --devmode|--strict? [13:18] jdstrand: well, no: as a user, what does `snap install foo --strict` do? [13:19] it's --confinement={devmode,strict}, with --devmode and --confined shortcuts for those [13:19] *handwaving for things that are not implemented* [13:19] Chipaca: fair point, though, I thought --confined was the default [13:19] jdstrand: it is [13:19] when would you use --confined? [13:20] jdstrand: when you want to override the snap [13:20] Chipaca: but if it is always installed confined unless you specify --devmode? [13:20] jdstrand: if the snap specifies "confinement:devmode", asking to install it on its own will fail [13:20] basically, my understanding was that you always had to use --devmode to install in devmode [13:21] oh I see [13:21] 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] if confinement:devmode, no args, fail with msg, --devmode installs, --confined allows install [13:21] jdstrand: but still have a way for dev to override for testing or whatever [13:21] exactly [13:22] ok, that makes sense [13:22] though, --confined does feel exactly right to me, but if that is what's designed, I certainly won't block on it [13:22] doesn't* === Guest76230 is now known as pmp [13:46] ogra_, FYI, Mark invalidated #1586400. I know you weren't a huge fan [13:47] Darn pattern patching. bug #1586400 [13:47] bug 1586400 in Canonical Click Reviewers tools "Snap type: change from "os" to "core"" [Wishlist,Fix committed] https://launchpad.net/bugs/1586400 [13:47] kyrofa, well, i wasnt a fan of the rename [13:47] (teh package rename ... i dont really care about the internally used type) [13:47] Oh, okay [13:47] the package will still have to be renamed [13:47] Indeed, yes [13:48] didrocks: https://launchpadlibrarian.net/263311094/buildlog_ubuntu-xenial-amd64.snapcraft_2.9~ppa5-1_BUILDING.txt.gz [13:48] the gettour test failed /o\ [14:01] I guess the kernel/ubuntu-core fallback mechanism only works if u-boot supports the saveenv command? [14:03] elopio: seriously? (in a meeting, looking) [14:04] elopio: it did build in your ppa though? [14:04] it seems that PKGBUILDDIR wasn't expanded, any idea? [14:05] didrocks: yesterday. But if failed today, not sure what's the difference. [14:05] elopio: this code isn't enabled, we can skip it to not block release [14:05] I think PKGBUILDDIR is the name of the dir, isn't it. [14:05] yeah [14:05] didrocks: ok, let me make the PR. [14:05] normally, setup.py expands it [14:14] didrocks: sergiusens: https://github.com/ubuntu-core/snapcraft/pull/547 [14:14] 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] popey, nice one [14:16] dpm, ogra_: Re: java – there's a maven example in snapcraft (has been one of the first plugins :-) [14:16] popey, oh, can you add a line to https://github.com/ubuntu/snappy-playpen#current-project-status? [14:17] 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] 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] 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] ysionneau: I will be the one working on the issue but the problem is time [14:19] ysionneau: I've got a few too many things needing my attention today and I'm off all next week [14:21] popey: in meeting, will do next :) [14:21] dpm: maven is a build system [14:21] dpm: it might be used to build any piece of java software [14:22] 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] dholbach: done https://github.com/ubuntu/snappy-playpen/pull/25 [14:22] sorry I meant from any Java app [14:23] 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] 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] sergiusens: elopio: I'll ensure I understand what the issue is in the build system [14:25] thanks popey [14:26] 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] dholbach: np, thanks for reviewing [14:26] ysionneau, yes, but the enforced use of uboot.env makes sure that saveenv always works [14:27] ysionneau, thats one of the reasons we switched to it [14:27] 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] popey, so far the process and everything is working out quite nicely [14:27] ya [14:27] i agree [14:27] its fun [14:27] I am _starting_ to like github [14:28] good work guys [14:28] i like doing ninja inline edits directly on github.com and turning those into PRs [14:28] which is what i did for the readme [14:28] popey, if only it would support bzr :P [14:28] cvs forever! [14:28] or that ! [14:31] 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] popey: "I am _starting_ to like github" -> I remember what you told during the sprint :p [14:40] see, you are getting at it! [14:44] ogra_: so if I use default config (built in) and disable saveenv, fallback won't work [14:44] good to know [14:44] (for some reason we deactivated the uboot.env stuff) === chihchun is now known as chihchun_afk [14:44] well, just ennable it and you should be fine :) [14:44] yep [14:45] i guess snapd would fall over when you do kernel snap updates ... it actually wants to update uboot.env [14:46] fgimenez: oh I have a list! [14:47] fgimenez: let me email you. should I CC anyone? [14:47] jdstrand, great, sure elopio will be interested too [14:47] ok, let me get that to you [14:51] ofc minetest [14:52] sgclark: is your kdevelop snapcraft.yaml available somewhere for me to try? [14:56] ogra_: I could just put a fake uboot.env, that's what I do right now :p [14:57] nope, not done [14:58] mhall119: and I cannot get your sections thing to work with frameworks being parts [14:59] sgclark: are you using the nil plugin and archive packages like mine, or are you trying ot build from source? [14:59] no, I am using upstream source for frameworks [14:59] hey sgclark ! [14:59] ok, what's not working? does it compile the upstream source? [14:59] upstream source for kde* [14:59] sgclark: you back from vacation / visiting family? [15:00] hi popey :) [15:00] yeah [15:00] sponsered to work on snappy, I am a happy camper [15:00] sponsored* [15:00] \o/ [15:00] Wat! That's awesome news! [15:00] it is :) [15:00] I'm so happy for you! [15:00] ysionneau, well, there is code that calls fw_setenv in snapd [15:00] Today is a good day. [15:01] ysionneau, not sure what happens if it cant actually set the vars [15:01] ty [15:01] ysionneau, so i'd suggest to just support it [15:08] I think even "snap list" just fails without a uboot.env [15:09] how can I put a file in a directory using the gadget snap? (boot-assets) [15:09] yeah [15:09] (to both) [15:09] like creating dir_a/file_b [15:09] :) [15:09] oh [15:09] subdirs ? [15:09] not supported [15:09] so far the syntax I use is : - path: boot-assets/uboot.env [15:09] (currently) [15:09] but I don't specify the target dir [15:10] arg, too bad I needthis :x [15:10] right, everything will go into the toplevel of the vfat [15:10] file a bug please ... [15:10] on which project? [15:10] (it would help for raspberry pi overlay dtbs too) [15:10] just snappy [15:10] (see topic) [15:11] ah good, thanks [15:11] let me know the bug # ... i'll confirm it [15:12] https://bugs.launchpad.net/snappy/+bug/1588864 [15:12] Launchpad bug 1588864 in Snappy "unable to specify target directory for boot-assets in gadget snap" [Undecided,New] [15:13] thanks ! [15:13] you're welcome! [15:15] zyga, ^^^ thats technically a u-d-f limitation that we need to weed out in ubuntu-image [15:19] elopio https://github.com/ubuntu-core/snapcraft/pull/547 [15:19] elopio master is just missing that now [15:21] crazy jenkins error [15:22] sergiusens: updated, the tests are running again. [15:23] elopio rebased even? [15:23] this is good to merge as soon as the travis execution is good. [15:24] elopio sounds good [15:36] What's a good way to test from inside a snap if it's in devmode or not? [15:37] do something that would normally be confined and check the exit code ? [15:38] Yeah. Trying to pick something good. [15:54] hmmm [15:54] 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] itsearches for them in system-data/var/lib/snappy/snaps instead of system-data/var/lib/snapd/snaps [15:55] :o [15:57] 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] what could make UDF generate wrong init in the initrd? [15:58] but i have in my aa slot /run/udev/data/* r, [15:58] and / run/udev/** rw, [15:59] 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] 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] hey guys, what's the process for getting a new interface added to snappy? [16:16] mhall119, a zyga question [16:16] mhall119, this might get you part of the way there: http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html [16:18] thanks kyrofa [16:18] and am I correct in thinking that snaps can't deliver new interfaces? [16:19] they all have to builtin atm [16:19] mhall119, correctly snaps don't deliver interfaces (they're a snapd thing), but they can deliver slots for interfaces [16:19] they==interfaces in my response [16:19] s/correctly/correct/, not sure how I messed that one up [16:19] 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] Yeah, perfect candidate for an interface [16:20] 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] mhall119, there are a few options [16:23] 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] 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] 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] mhall119, though I'm a little more fuzzy on that one [16:30] mhall119, finally, we have some sort of content sharing interface planned, though not spec'd just yet. Those two things may overlap [16:30] kyrofa mhall119 the scenario you describe seems pretty similar to what kgunn did with mir [16:30] 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] the interface is added to snapd, but the implementation of a slot for that interface would be a snap [16:31] could be [16:31] mhall119, you got it [16:31] sergiusens: ack, what I was thinking [16:31] ok, cool === tyhicks` is now known as tyhicks [16:37] ogra_: I just recompiled the kernel snap and the initrd seems to be still old :o [16:38] oh ? [16:38] sergiusens, ^^ does the kernel plugin not pull the latest initrd when you re-build ? [16:39] 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] sergiusens, i assume deleting the initrd would pull it automatic ? or do you still need a manual pull ? [16:40] I deleted the snap directory and the .snap file and did "snapcraft --target-arch arm64 snap" [16:40] ogra_ same as if you deleted something from vcs [16:40] we could make it warn you [16:40] (assuming initrd is an essential part, i would expect snapcraft to make sure it is there) [16:41] yeah, we definitely should [16:41] or make it fail the build even [16:41] it wont boot without initrd ... [16:41] so there is no use in building it [16:41] except I do have an initrd :o [16:42] we have a long term plan for booting with two initrds ... the script bits would then come from the os snap [16:42] so you get the latest with an os upgrade ... (to de-couple the kernel snap ) [16:42] ogra_ the kernel plugin is experimental, so errors are allowed :-P [16:43] but thats a bit further down the roead [16:43] is there any quick thing I can do to unblock me? [16:43] 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] ;-) [16:43] sergiusens, well, we shouldnt allow building unbootable kernel snaps imho :) [16:43] ogra_ they will be unbootable as soon as the spec changes [16:43] go away ? [16:43] it will change ... why would it go away [16:43] ogra_ the need to download the generic initrd is going away [16:44] ah [16:44] well, but thats definitely post GA [16:44] so rather far out [16:44] so there is not much logic there; and we won't spend precious time on that [16:44] ok [16:44] in the meantime, don't delete files in `parts` [16:45] ysionneau to get around it, snapcraft clean is what you would need to do [16:45] kyrofa we should consider making an explicit call on a command do it again and mark what follows dirty [16:45] hmm ok, isn't it the same as removing all directories? [16:45] because I did that :o [16:46] ysionneau sort of, sometimes, depends on the directories removed [16:46] ok let's rebuild [16:47] elopio kyrofa https://github.com/ubuntu-core/snapcraft/pull/548 [16:48] 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] ysionneau, if you can use the `snapcraft clean` command it'll keep it happy [16:49] 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] ysionneau, try doing that by hand ;) === Aria|away is now known as Aria [16:51] nice! [16:51] well done [16:55] ogra_ sergiusens still using old paths in initrd [16:55] did it actually download an os snap ? [16:55] I don't think so [16:55] let me c/c [16:56] i wonder if you have an old cached os snap somewhere [16:56] http://pastebin.com/DLbSHvcy [16:56] I did a snapcraft login before, and a snapcraft pull [16:57] weird [16:57] where would this os snap be cached? [16:59] 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] yeah [17:01] well ... https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/kernel.py has [17:01] snapcraft.download( [17:01] 'ubuntu-core', 'edge', self.os_snap, self.project.deb_arch) [17:01] no idea where the snap it downloads goes though [17:01] I have snapcraft 2.8.7 [17:02] thats rather old ... [17:03] though i dont think that specific part of it changed actually [17:04] probably kyrofa knows where such downloads go [17:04] ahah [17:05] I think I got it [17:05] explicit "pull" ? [17:05] download() is downloading in .... self.sourcedir + 'os.snap' [17:05] ah [17:05] so os.snap is in my kernel source dir [17:05] which I didn't clean [17:05] and I bet snapcraft clean didn't remove it [17:05] evil [17:06] "downloading ubuntu-core" ... [17:06] o/ [17:06] yay [17:07] who was bragging about "snapcraft clean" again ? :p [17:07] lol [17:17] ogra_: IT BOOTS [17:18] \o/ [17:18] yay [17:19] let's call it a day [17:19] thanks a lot [17:19] see youhave a nice weekend [17:19] np :) [17:19] yeah, enjoy [17:19]