=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:43] sergiusens: https://www.irccloud.com/pastebin/yctOxEI4/ [07:05] PR snapd#1593 closed: asserts,many: start supporting structured headers using the new parseHeaders [07:09] stokachu interesting. Seems like a simple bug === chihchun is now known as chihchun_afk [07:10] sergiusens: i built it locally and tried installing and the act of installing gave me the same error [07:10] ogra_ does josepht's branch solve your problems? [07:12] stokachu installing the snap or the python setup? [07:12] installing the snap === chihchun_afk is now known as chihchun [07:33] I've seen that Libreoffice had been snapped, but has anybody tried to snap Libreoffice Online? [07:34] oparoz: not that I know of, interested in doing it? [07:36] dirdocks, well, actually, Nextcloud is interested in including it in an image along with the Nextcloud snap, but that's end of the year stuff, so I haven't looked at the implementation details yet [07:36] oparoz: Meaning, the server component of some multiuser online libreoffice? [07:37] qengho, correct, it's a server, opened on a specific port which a Nextcloud app connects to [07:37] oparoz: I'm hoping you just volunteered. [07:38] qengho, well, I'll definitely investigate how doable the project is and will probably get in touch with the person who has snapped Libreoffice since LO uses that source code [07:39] We currently have a Docker, so that could be plan B [07:48] balloons, how's the juju snap coming along? [07:49] PR snapcraft#692 opened: Use the new snapcraft mailing list as contact info === chihchun is now known as chihchun_afk [08:04] Hi I'm trying to create my first snap. Its a "make" project and I'm struggling to find out how to tell snapcraft to go into the "src/" directory of the tarball in order to execute make command. Any pointers? [08:07] imexil, use source-subdir [08:07] ("snapcraft help sources" lists it among other useful things) [08:08] Thanks dholbach. So http://snapcraft.io/docs/build-snaps/syntax is not really complete at the moment? [08:09] (that's where I went looking) [08:10] imexil, I'd agree with you that the "snapcraft help sources" bits should be on there [08:10] :-) [08:11] probably not the plugin related bits, because some options only exist for certain plugins [08:11] I'll file a bug [08:12] Thanks! [08:15] https://bugs.launchpad.net/snapcraft/+bug/1607249 [08:15] Bug #1607249: docs/snapcraft-syntax.md should refer to source related syntax [08:26] OK almost there. I get a "install: cannot remove '/usr/local/lib/libipe.so.7.2.5': Permission denied" on the make install part when simply running "snapcraft build". Why would building the snap need sudo permissions on my system? [08:26] Bug #1607252 opened: User data is missing or lost when utilizing a snap instead of a traditional package [08:26] Bug #1607253 opened: User data is missing or lost when utilizing a snap instead of a traditional package [08:27] imexil, it shouldn't - I assume something went wrong in one of the steps before - you could try to run snapcraft clean && snapcraft [08:27] OK [08:33] Still the same :-( For what it's worth: https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml [08:34] imexil: Maybe your Makefile doesn't honor prefix and installdir and such. [08:35] yes it does. compiling it manually works fine. [08:36] imexil: does installing it work fine? "make install"? [08:36] Basically I followed https://github.com/otfried/ipe-wiki/wiki/Downloading,%20Compiling,%20and%20Installing%20Ipe#debian-ubuntu-mint and am now trying to convert that into a snap [08:38] Bug #1607253 changed: User data is missing or lost when utilizing a snap instead of a traditional package [08:38] Bug #1607265 opened: Ubuntu-core downloads before querying store for missing snap [08:38] qengho: yes that works === chihchun_afk is now known as chihchun [08:41] imexil: Can you you get it to install to /tmp/imexil/ using only "make install DESTIR=/tmp/imexil"? [08:43] imexil: you might need to extend that makefile plugin, or use some "make-parameters: [ ... ]" in your YAML. [08:45] sergiusens, josepht it looks like it could help, i need to do a PPA build and try an os snap build with it ... it still does a lot directory walking and permission checking thought, why not just do the equivalent of mv for the top level dir [08:46] stokachu http://paste.ubuntu.com/21252582/ [08:47] qengho: OK so this is strange. I've changed in the make-parameters "IPEPREFIX=/usr/local" to "IPEPREFIX=/tmp/imexil" and this works. Why would snapcraft want to install on my /usr/local whilst building the snap? [08:51] imexil: It's not right. snapcraft only knows about DESTDIR. Instructions to install in /usr/local are not instructions to build a snap. [08:52] imexil: I have only a trickle of bandwidth here, so I can't read much, but I'm sure someone else can tell you if it's possible to YAML that sets IPEPREFIX to the temporary directory that snapcraft is expecting the result to land in. [08:54] imexil: you told it ot put it in /usr/local . That's why it's trying to write to /usr/local/ . snapcraft doesn't want the result in /usr/local/ . [08:54] OK. I'll try to specify DESTDIR in addition. Thanks for the help qengho. [08:54] You can't sepcify DESTDIR in the YAML. Thats backwards. [08:55] Yes just noticed that this is not working. Still I don't get why snapcraft build would try to write to /usr/local on the file system [08:57] imexil: it's because you told it to, right? You invented /usr/local in "IPEPREFIX", whatever that is. [08:58] qengho: OK got your note with /usr/local. Since the original makefile expects to have IPEPREFIX to be set (it won't compile otherwise) I guess I can just set it to some tmp folder? [08:59] No. You can't invent that. That belongs to snapcraft. You can't predict it. [08:59] ogra_, dholbach, help? ^ [09:01] I'm about to hop on a call - can you pastebin your current snapcraft.yaml somewhere so I can take a look in a bit? [09:01] dholbach, https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml [09:01] gist: wonky Makefile project expects "IMEPREFIX" instead of "DESTDIR". There's no way to use YAML here, right? No variable expenasion in make-parameters: [ IMEPREFIX=$destdir ] [09:02] ogra_, cool - I can take a look in a bit [09:02] imexil, i have never used IPREFIX, but in a makefile i need to use $(DESTDIR) [09:02] thanks dholbach, ogra_ [09:02] (note the brackets) [09:03] i'm not sire how make-parameters: are used here [09:03] *sure [09:06] imexil: You're going to have to change the Makefile to use DESTDIR instead of IMEPREFIX, or make a new snapcraft plugin that runs "make install IMEPREFIX=installdir". See /usr/lib/python3/dist-packages/snapcraft/plugins/make.py . [09:06] * qengho afk. [09:07] Right. I was hoping to not have to change the Makefile since I'm not upstream [09:08] "IPEPREFIX=$(DESTDIR)" does not work btw. [09:10] PR snapcraft#692 closed: Use the new snapcraft mailing list as contact info [09:11] hiya, stress-ng is a published snap, yet I can't find it with snap find and hence I can't install it from the store. Not sure what's gone wrong. [09:13] PR snapcraft#693 opened: Implement "oneshot" daemon type [09:23] also, I have smemstat that's been pending review for a while, can somebody review that? I'm kinda blocked by the human processes involved in getting my snaps uploaded [09:23] it's not helping with "velocity" [09:26] cking, just stop using exotic interfaces :) .... most of us dont have to wait at all [09:26] ogra_, ok, well, that's all my code then ;-) [09:36] cking, if the published one is in devmode it might not be listed by snap find by installing it should still work? [09:37] (I think from what I read) [09:37] do you force devmode? [09:37] i don't believe I did [09:38] k, maybe you got confused by the store UI and didn't actually press the publish button? [09:38] seem to happen to some people [09:38] otherwise I don't know, you need somebody from the store team I guess [09:38] it says "Package status is Published" [09:39] k, dunno then, sorry [09:40] ogra_: I've gotten myself into a strange situation where I have a grub.cfg looking for $snap_kernel variable and snapd is writing $snappy_kernel variable instead... which of these is the right variable? [09:41] i.e. is my grub.cfg stale or is my grubenv stale [09:42] i *think* you want snap_kernel ... [09:43] hmm, though looking at the arm configs it seems to be snappy [09:44] yeah, i take that back, it should be snappy_kernel, thats used everywhere else [09:44] hmm [09:44] so this was changed recently? [09:44] abd looking at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/generic-amd64/grub.cfg the code agrees too [09:45] not that i'm aware [09:45] I had this working last time I built an image, using the same version of snap supporting 'snap weld', and something has changed ;) [09:46] ok, very confusing, I don't know where this grub.cfg is coming from [09:47] well, it doesnt look like the grub.cfg in the gadget has changed much since we switched to all-snap images [09:47] yes [09:47] I don't know where the broken grub.cfg is coming from - my problem to sort out [09:47] sergiusens, bah, the rust selftests fail in the PPA snapcraft build :/ [09:47] slangasek, do you use the right build tool ? you need to use the u-d-f-experimental from mvo currently [09:48] ogra_: yes, I use the right build tool, it's called ubuntu-image. :P [09:48] lol [09:48] :P ;) :P [09:48] ok [09:48] then i agree that it is your problem to sort :) [09:49] hmm, there's a broken /system-data/boot/grub/grub.cfg [09:50] so that's actually coming from snap weld, so I probably need to get fixes to that [09:50] well, isnt snap weld dead ? [09:50] i thought it already got renamed [09:50] yes, but that's the interface we were writing to at the time [09:50] ah [09:51] and I was trying to debug why my previously-working image build pipeline regressed [10:06] ogra_: ok, now the problem I'm getting is that the initramfs scripts in canonical-pc-linux_32.snap are failing to remount the filesystem after fsck.... [10:07] slangasek, do you have that from the store ? === AL_ is now known as Guest55858 [10:08] ogra_: I have it as downloaded by 'snap weld' today, yes [10:08] tracking edge channel (which is a prereq) [10:08] hmm, weird === chihchun is now known as chihchun_afk [10:10] slangasek, is that on first boot ? [10:10] ogra_: yes [10:11] are there probably some format options missing ? i forgot how u-d-f did the formatting ... i think we called out to sgdisk [10:15] Bug #1607297 opened: Error with an example Python snap [10:16] ogra_: no idea, I'm getting no output from that bit of the initramfs script... it just tells me it's /trying/ to fsck [10:18] PR snapd#1597 opened: tests: add hardware-observe spread test [10:18] well, our fsck is actually not a real fsck ... (well, it is, but we mount -o remount before which commits the journal ... thats a lot faster to fsck) [10:19] # Mount and umount first to let the kernel handle [10:19] # the journal and orphaned inodes (much faster than e2fsck). [10:19] mount -o errors=remount-ro "$path" "$writable_mnt" || true [10:19] umount "$writable_mnt" || true [10:19] and then we run [10:19] /sbin/e2fsck -va "$path" >> "$logfile" 2>&1 || true [10:19] right afterwards [10:20] there should be a log in case you have an initrd prompt [10:20] under /run/initramfs/ === chihchun_afk is now known as chihchun [10:35] zyga, jdstrand: Hey, so I have an interesting issue with the LXD snap. I'm running two daemons, one is lxcfs, the other is lxd. lxcfs runs a fuse filesystem which lxd must have access to. [10:35] zyga, jdstrand: the problem is that because snapd creates one mount namespace per process, lxd can't actually see the filesystem that lxcfs mounted, it just sees an empty directory [10:36] zyga, jdstrand: any chance we can alter the way this works to re-use the existing namespace (setns into it if it exists, instead of unsharing a new one) [10:37] (I may also be wrong and maybe the launcher already does that and I screwed something up in my setup) [10:37] * ogra_ is surprised you can fuse-mount anything at all from inside a snap ... i tried sshfs and failed due to no /dev/fusectl access [10:37] ogra_: running devmode right now. I have a fuse interface implemented here but need a bunch more things for lxcfs to be happy (it needs to create its own mount namespace, mount a bunch of kernel filesystems, ...) [10:38] ogra_: /dev/vda2 has unsupported feature(s): metadata_csum [10:38] so yeah, that's an odd case where even --devmode still breaks you :) [10:38] stgraber, oooh lovely ... please make it a separate interface, not buried in an lxd inetrface or so ... i want to use it :) [10:38] ogra_: so it seems that creating a new filesystem with e2fsck in yakkety is not compatible with series 16's e2fsck, sigh :/ [10:39] ogra_: yeah, the fuse one I have separate. lxd itself will use a new "unconfined" interface because well, we need unconfined apparmor and unconfined seccomp to run :) [10:39] * stgraber -> lunch [10:39] slangasek, hooray for steady advancement of our software :P [10:40] ogra_: and I don't know how this regressed, either, because e2fsprogs hasn't changed in yakkety since 6/30, so that *should* have been the version I used for my previous round of testing [10:41] well, i'm not sure if u-d-f actually uses e2fsprogs or rather some fancy go implementation [10:43] http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/view/head:/diskimage/partition.go [10:43] looks like it actually uses parted directly [10:44] (which actually is a bit awkward when doing GPT stuff) [10:48] ogra_: /I'm not using u-d-f/ [10:48] i know ... but it works with u-d-f [10:48] so you have something to compare to [10:48] with the yakkety version of e2fsprogs? [10:49] well, i know mvo tests his builds before pushing a change to u-d-f ... assuming he runs yakkety locally i would guess it has worked two weeks ago when he did the last u-d-f [10:50] (i personally have only tested in xenial though) [10:50] yes, and at that point it also worked for me with ubuntu-image [10:50] and e2fsprogs claims not to have changed since then ;) [10:50] i'm just not sure if parted actually uses e2fsprogs internally for its mkpart call [10:51] it does [10:51] ah, k [10:51] anything else would be layer-violating madness ;) [10:52] well, it doesnt call out to sgdisk for GPT partitions :) [10:52] so you never know :) [10:53] yes, because it's parted and because partitions [10:53] it's not fsed [10:53] (i wasnt serious ... :) ) [10:54] I think I got the snap build and installed but how can I make sure the snap version of an application is run and not the apt installed version? [10:55] sergiusens, josepht, no change with the patch /tmp and /home/ubuntu are still having 0755 permissions and are root:root [10:55] err [10:55] wait [10:55] i take that back, i'm blind === hikiko is now known as hikiko|ln [11:01] ogra_: the fsck failure was a red herring and must have always been there. I've adjusted the mkfs.ext4 options in u-i, it now succeeds, and the rw remount still fails to happen [11:02] ogra_: so, what changed in the edge kernel snap since last week? how can I see the history of the package, etc.? [11:03] (or even retrieve an older version for comparison, since I didn't keep the old working dir around, thinking I was done with it!) [11:03] ogra_: hey [11:03] ogra_: have you ever got: run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 1 [11:04] lool, yeah, old bug that is fixed since a while ... iirc apw did an SRU [11:04] ogra_, right that should be fixed i beleive [11:04] slangasek, nothing should have changed, uploads are all manual [11:04] ogra_: I took https://people.canonical.com/~mvo/all-snaps/amd64-all-snap.img.xz did sudo snap refresh ubuntu-core (couldn't refresh canonical-pc as it fails with a pcspkr module loading error) and rebooted, then lost network (this is under KVM) because eth0 was ens3 [11:05] hmm [11:05] slangasek, and to my knowledge nobody uploaded a new kernel snap [11:05] ogra_: how would I rule this out with certainty? :) [11:05] - Download snap "canonical-pc-linux" from channel "stable" (revision 24 of snap "canonical-pc-linux" already installed) [11:05] - Download snap "canonical-pc" from channel "stable" (revision 6 of snap "canonical-pc" already installed) [11:05] so I'm fully up-to-date thre [11:06] perhaps the snap isn't updated [11:07] slangasek, uh.oh ... so pobviously there was a kernel snap upload yesterday, i dont know where it comes from, my new kernel snapping isnt ready yet and i wouldnt know who else uploads under the shared store account [11:07] ogra_: mmhmm - ok, thanks for checking :) [11:08] apw, ppisati_, did one of you upload a canonical-pc-linux snap yesterday ? [11:08] (and how was the built ??) [11:08] ogra_: fwiw if there were something usable in a channel other than 'edge' I would happily use that for prototyping instead :-) [11:08] slangasek, try stable [11:08] ogra_: stable is too stable [11:09] ;) [11:09] but note that has a very old ubuntu-core [11:09] yes. too old for my purposes [11:10] ogra_: meanwhile... maybe you could back that rev out of the edge channel? [11:10] ogra_, i think that was bjf [11:11] slangasek, http://people.canonical.com/~ogra/snappy/canonical-pc-linux_31.snap (give it another munitee, still uploading) [11:12] apw, how did he build that ? there are a good bunch of packages that need to go in there [11:12] ogra_, i believe the snapcrafy.yaml is on the tip of our branches [11:12] sigh [11:12] apw, that wont work [11:12] ogra_, but ... i'd say you'd be better short circuiting to him direct [11:13] ogra_, oh i am sure, but hey, this is how you learn :) [11:13] we need all that meta pulls in ... and soon also mesa and some other bits [11:13] apw, i have a buiolld system nearly ready for the kernel snaps [11:13] slangasek, uploaded, grab it :) [11:13] ogra_, don't panic, i am sure we are not expecting it to work currently, he is likley working out how to join all the bits up [11:14] apw, well, it would be nice if you could upload it under a separate name then ... you just killed the edge channel for eveyone :) [11:14] * ogra_ tries to find out how to unpublish a single revision [11:15] ogra_, we did what ? oh perhaps i malign him, ask bjf if it was him and go from there [11:15] apw, ogra_: I'm talking with bjf here at sprint, he tells me he did not intentionally upload anything [11:15] apw, well, someone uploaded canonical-pc-linux under the shared store account [11:15] weird [11:15] ogra_, as far as i know it was not me [11:15] and it would've had to be an upload + publish [11:16] anyway, if we're downrevved to 31, yay [11:16] not for edge i think [11:16] ah, ok [11:16] sigh ... so i can only unpublish the whole package (all revisions) [11:16] ogra_: hmm but snap weld gave me 32 again. I thought the store was instantaneous! how do I manually grab 31? [11:17] slangasek, i dont know ... [11:17] right [11:17] by default the store only gives you the latest ... and i cant mange to remove only one revision [11:17] ogra_: who should I hunt down here to fix it? ;) [11:17] ogra_: other option [11:18] i tried to uncheck the channle from the snap now ... [11:18] try again, probably that works [11:18] ogra_: can you point the beta channel to 31 for canonical-pc-linux and to 138 for ubuntu-core? [11:18] I'll try again, but it's inconveniently slow to iterate [11:18] done [11:18] 31 -> beta i mean [11:18] sweet [11:18] ah [11:19] what about for ubuntu-core? I only get to pick one channel for both [11:19] oh, wait thats i386 [11:19] heh [11:19] 30 is actually amd64 [11:19] dholbach: FYI I changed the IPEPREFIX to $SNAPCRAFT_STAGE. Now the snap builds but the resulting snap package is not working. Basically it is not clear where the binary end up etc. Latest state is https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml [11:19] pushed to beta too [11:19] um ok [11:19] thanks [11:19] and ubuntu-core? [11:20] yeah, its a bit weird since each upload bumps the revision and you need one upload per arch [11:20] on it [11:20] ta [11:20] looks like 138 and 139 are beta+edge already [11:20] so you should be fine [11:21] ogra_: sweeeeet thanks! [11:22] apw, https://code.launchpad.net/~ogra/+junk/kernel-test-snap ... that is what you actually need for a working kernel snap (amd64 only currently, i'm about to add all other arches til EOW) ... i guess it makes sense if you guys take that over once i have it done [11:23] that should then auto-upload to the store from LP snap builds [11:24] PR snapd#1598 opened: Implement a fuse interface [11:25] ogra_: ^ (I won't actually need it, but hopefully it does cover the bits you need) [11:25] crap, the gadget in the store is also broken ... so i cant do the final test for josepht's fix :/ [11:25] * ogra_ hugs stgraber [11:26] ogra_: given that my use case needs a lot more things and I'll be just running everything using a lxd interface, I didn't really get to test this so much. It may be that you need to add a few bits to the seccomp part maybe. Anyway, that's certainly a start and should work for some fuse fs. [11:26] stgraber, i'll poke around in it once i have some time for that [11:30] ppisati_, have you uploaded a kernel snap to the store recently? [11:30] bjf, perhaps it was mb [11:30] ogra_, we are trying to find out who uploaded the kernel snap to the store .. was not me [11:30] *mvo [11:31] bjf, seems someone also uploaded a gadget called just "pc" so it seems someone is working on that ... try to hunt down mvo [11:31] * ogra_ dances [11:31] \o/ [11:31] ogra_, hunting ... [11:32] sergiusens, josepht, patch verified, my os snap looks fine and i have a properly booting image [11:32] and on that note ... [11:32] * ogra_ is off to the dentist ... back in 1-2h [11:40] PR snapd#1595 closed: many: make seed.yaml on firstboot mandatory and include sideInfo [11:54] imexil, looks like stuff is not copied over from stage/ to prime/ === hikiko|ln is now known as hikiko [11:55] Yes. But I'm a bit at a loss since my lack of understanding of the internals. I assumed replicating the typical compiling workflow would be good enough. But looks like creating snaps is much more evolved. [11:55] *involved [11:57] I couldn't find any debug flags to turn on to see what is or is not done during building the snap. Are there any "verbose" switches? [11:58] ogra_, apw yes it was mvo [12:03] PR snapcraft#693 closed: Implement "oneshot" daemon type [12:10] Bug #1607344 opened: snap gives confusing error messages if snap login was ran with sudo === chihchun is now known as chihchun_afk === drizztbsd is now known as timothy [12:36] imexil: Did you look through parts/*/install where the files are? That's the first step I take if something appears to be missing [12:37] I'm not sure that snapcraft does anything "special" during the build itself. It's mostly invoking make with the variables you defined. [12:39] imexil: A basic fault could be that the default PREFIX is something inconvenient, like usr/local which isn't where you expect binaries in the final package - the convention is the same as a typical Linux-based distro, /usr/ or / [12:48] stgraber (and zyga): personally, I would be ok with the shared-within-a-snap mount namespace because that would also solve the "/tmp shouldn't be separate" bug and conform to our design goal of "everything within a snap should be able to work together". That said, there has been resistance to that approach, so I'll let others comment [12:48] * apw has just built the same snap in a xenial environment and in a yakkety environment (simple hello-world.c test) and the X one is 4k and the Y one is 600K [12:50] stgraber: as for 'unconfined', we can discuss that in the PR but I don't think we'll want it to be named that based on previous design goals. the policy needs to be what it needs to be, but 'unconfined' won't be the name of the interface [12:50] trying to snap the new pithos release, wish me luck lol [12:51] stgraber: aka, it should be named 'lxd' and docker's should be named 'docker' [12:52] imexil, I'd suggest sending a quick mail to snapcraft@lists.snapcraft.io asking for help [12:52] heyo dholbach [12:53] hi ahoneybun [12:53] kalikiana: The problem is that the PREFIX can not be anything that is not writeable by user. I've now used $SNAPCRAFT_STAGE and after running `snapcraft` the dir structure looks like: http://zb.dwe.no/?113bba383c80bdb9#gYrjz3cktMYOrRDu9OOmh62aQxN9YK0LyTManzrP978= [12:53] got time to debug a snap? [12:53] jdstrand: yeah, zyga already told me I should go with a lxd one which is effectively unconfined rather than make this generic [12:53] dholbach: Yes probably a good idea. [12:55] yaml: http://pastebin.ubuntu.com/21269089/ [12:55] zyga: so I just sent https://github.com/snapcore/snapd/pull/1598 (as mentioned before, we won't actually need it but ogra_ apparently has a use case for it :)) [12:55] PR snapd#1598: Implement a fuse interface [12:55] I'm getting local source is not a directory [12:55] imexil: PREFIX=/usr is perfectly writable by the user as it's going to become parts/*/install/usr/ anyway [12:55] most likely did something wrong with curl and tar [12:55] stgraber: and no, you didn't screw something up with regard to the private mount namespace [12:56] imexil: I don't actually know what SNAPCRAFT_STAGE is. I haven't seen that in any docs. What does it point to? [12:58] ohhh [12:58] it's building [13:02] false alarm [13:02] just some stuff from curl [13:03] tianon: hi! [13:03] jdstrand: http://blogs.gnome.org/markmc/2014/02/20/naked-pings/ (this is an automated contentless pong to mirror your contentless ping - please provide more information and I'll respond when I'm around and have a minute) [13:04] tianon: boy, I was just greeting you before I responded :) Maybe you should adjust your bot :) [13:04] so I changed the source to : ./ and it does something but fails [13:04] autoreconf -i returns with non-zero exit status 1 [13:05] tianon: anyway, re docker> you technically can do two interfaces (one for client and one for server) but snappy is designed for an interface to have two sides: a 'slots' side and a 'plugs' side [13:05] tianon: the server implements the 'slots' side and the client the 'plugs' side [13:05] http://pastebin.ubuntu.com/21270061/ [13:05] kalikiana: it points to the stage dir. I found it described here: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-advanced-features/ [13:06] tianon: when a snap provides a slot-implementation, that makes available the slot to be plugged by other snaps [13:08] dholbach: Mail sent. (for moderation since I wasn't aware that it's for subsribed users only) [13:08] tianon: in this case, you'd write a patch to snapd that implements the 'docker' interface. Then the docker snap would 'slots: [ docker ]'. when a user installs the docker snap, then 'snap interfaces' would show it as available and a client snap could 'plugs' it. eg, a client snap might 'plugs: [ docker ]' [13:09] stgraber, zyga, i even have a shiny bug for it... bug 1603113 [13:09] Bug #1603113: add fuse filesystem interface [13:10] tianon: more concretely, the docker snap's daemon command would 'slots: [ docker ]' and the docker interface implementation would put the apparmor rules needed for the daemon to run in PermanentSlotAppArmor and the daemon's seccomp rules in PermanentSlotSecComp [13:11] tianon: then you put the rules for the client to connect to the server in ConnectedPlug[AppArmor|SecComp] and the rules for the server to connect to the client in ConnectedSlot[AppArmor|SecComp] [13:12] how do I tell snappy to look into parts/pithos-download/src/ ? [13:12] thanks imexil [13:12] dholbach: ^ [13:13] ahoneybun, do you want to copy things over? or do you use some build system? [13:13] tianon: if you haven't already, I suggest you read zyga's blog series: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html and take a look at the the location-observe interface (interfaces/builtin/location_observe*.go) [13:13] ahoneybun, source-subdir for the latter ("snapcraft help sources" explains this) [13:13] there is a autogen.sh file in there thast needs to run [13:13] reading from here: https://github.com/pithos/pithos/wiki/Installing-from-Source [13:13] ahoneybun, autotools plugin with source-subdir then [13:14] source: source-subdir? [13:14] imexil: Hmm thanks. Should "ipe" have an install target? Do the logs show its installing anything at all? I notice plugin: make but no *Makefile in parts/ipe/build [13:14] PR snapcraft#694 opened: Pass --root to the python3 plugin on build [13:14] dholbach: http://pastebin.ubuntu.com/21269089/ [13:14] tianon: /me notes he meant to say PermanentSlotSnippet instead of PermanentSlotAppArmor/SecComp and the same for PermanentPlug* [13:14] this is the current yaml [13:14] tianon: and ConnectedPlug* [13:15] tianon: the blog post and the location-observe interface should make things clear [13:15] ahoneybun, I'm not sure... do you want me to figure this out for you now? [13:15] mm help me figure it maybe [13:16] does not have to be now now [13:16] ok [13:27] man snapcraft is picky about spacing [13:29] nessita, help ? [13:29] Launchpad uploaded this snap package to the store, but the store failed to [13:29] scan it: [13:29] Can not create a new package with name ubuntu-core, multiple origins for ubuntu-core are not allowed. [13:29] what can we do there ? [13:31] making some progress dholbach [13:31] thanks to the playpen I've simplifed my yaml a lot [13:31] ahoneybun, it has to be valid YAML :) [13:31] If YAML isn't spaced right it can't be parsed [13:32] well I got to the point that it found the autogen.sh file [13:32] it said it was missing intltoolize [13:33] ogra_, let me check [13:33] nessita, the ubuntu-core snap recently got changed to shared maintainership ... i could imagine that is realted [13:33] ogra_, are you uploadingas yourself, and you can collaborate with the ubuntu-core package? [13:33] mm missing appstream.xml.m4? [13:33] nessita, yes, to both, i can manage it in myapps and i can upload it manually [13:34] jzst not through LP [13:34] *just [13:34]