| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| stokachu | sergiusens: https://www.irccloud.com/pastebin/yctOxEI4/ | 06:43 |
|---|---|---|
| mup | PR snapd#1593 closed: asserts,many: start supporting structured headers using the new parseHeaders <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1593> | 07:05 |
| sergiusens | stokachu interesting. Seems like a simple bug | 07:09 |
| === chihchun is now known as chihchun_afk | ||
| stokachu | sergiusens: i built it locally and tried installing and the act of installing gave me the same error | 07:10 |
| sergiusens | ogra_ does josepht's branch solve your problems? | 07:10 |
| sergiusens | stokachu installing the snap or the python setup? | 07:12 |
| stokachu | installing the snap | 07:12 |
| === chihchun_afk is now known as chihchun | ||
| oparoz | I've seen that Libreoffice had been snapped, but has anybody tried to snap Libreoffice Online? | 07:33 |
| didrocks | oparoz: not that I know of, interested in doing it? | 07:34 |
| oparoz | 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 |
| qengho | oparoz: Meaning, the server component of some multiuser online libreoffice? | 07:36 |
| oparoz | qengho, correct, it's a server, opened on a specific port which a Nextcloud app connects to | 07:37 |
| qengho | oparoz: I'm hoping you just volunteered. | 07:37 |
| oparoz | 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:38 |
| oparoz | We currently have a Docker, so that could be plan B | 07:39 |
| dholbach | balloons, how's the juju snap coming along? | 07:48 |
| mup | PR snapcraft#692 opened: Use the new snapcraft mailing list as contact info <Created by seb128> <https://github.com/snapcore/snapcraft/pull/692> | 07:49 |
| === chihchun is now known as chihchun_afk | ||
| imexil | 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:04 |
| dholbach | imexil, use source-subdir | 08:07 |
| dholbach | ("snapcraft help sources" lists it among other useful things) | 08:07 |
| imexil | Thanks dholbach. So http://snapcraft.io/docs/build-snaps/syntax is not really complete at the moment? | 08:08 |
| imexil | (that's where I went looking) | 08:09 |
| dholbach | imexil, I'd agree with you that the "snapcraft help sources" bits should be on there | 08:10 |
| imexil | :-) | 08:10 |
| dholbach | probably not the plugin related bits, because some options only exist for certain plugins | 08:11 |
| dholbach | I'll file a bug | 08:11 |
| imexil | Thanks! | 08:12 |
| dholbach | https://bugs.launchpad.net/snapcraft/+bug/1607249 | 08:15 |
| mup | Bug #1607249: docs/snapcraft-syntax.md should refer to source related syntax <snap-docs> <Snapcraft:New> <https://launchpad.net/bugs/1607249> | 08:15 |
| imexil | 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 |
| mup | Bug #1607252 opened: User data is missing or lost when utilizing a snap instead of a traditional package <Snappy:New> <https://launchpad.net/bugs/1607252> | 08:26 |
| mup | Bug #1607253 opened: User data is missing or lost when utilizing a snap instead of a traditional package <Snappy:New> <https://launchpad.net/bugs/1607253> | 08:26 |
| dholbach | 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 |
| imexil | OK | 08:27 |
| imexil | Still the same :-( For what it's worth: https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml | 08:33 |
| qengho | imexil: Maybe your Makefile doesn't honor prefix and installdir and such. | 08:34 |
| imexil | yes it does. compiling it manually works fine. | 08:35 |
| qengho | imexil: does installing it work fine? "make install"? | 08:36 |
| imexil | 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:36 |
| mup | Bug #1607253 changed: User data is missing or lost when utilizing a snap instead of a traditional package <Snappy:New> <https://launchpad.net/bugs/1607253> | 08:38 |
| mup | Bug #1607265 opened: Ubuntu-core downloads before querying store for missing snap <Snappy:New> <https://launchpad.net/bugs/1607265> | 08:38 |
| imexil | qengho: yes that works | 08:38 |
| === chihchun_afk is now known as chihchun | ||
| qengho | imexil: Can you you get it to install to /tmp/imexil/ using only "make install DESTIR=/tmp/imexil"? | 08:41 |
| qengho | imexil: you might need to extend that makefile plugin, or use some "make-parameters: [ ... ]" in your YAML. | 08:43 |
| ogra_ | 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:45 |
| sergiusens | stokachu http://paste.ubuntu.com/21252582/ | 08:46 |
| imexil | 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:47 |
| qengho | imexil: It's not right. snapcraft only knows about DESTDIR. Instructions to install in /usr/local are not instructions to build a snap. | 08:51 |
| qengho | 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:52 |
| qengho | 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 |
| imexil | OK. I'll try to specify DESTDIR in addition. Thanks for the help qengho. | 08:54 |
| qengho | You can't sepcify DESTDIR in the YAML. Thats backwards. | 08:54 |
| imexil | 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:55 |
| qengho | imexil: it's because you told it to, right? You invented /usr/local in "IPEPREFIX", whatever that is. | 08:57 |
| imexil | 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:58 |
| qengho | No. You can't invent that. That belongs to snapcraft. You can't predict it. | 08:59 |
| qengho | ogra_, dholbach, help? ^ | 08:59 |
| dholbach | 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 |
| ogra_ | dholbach, https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml | 09:01 |
| qengho | 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:01 |
| dholbach | ogra_, cool - I can take a look in a bit | 09:02 |
| ogra_ | imexil, i have never used IPREFIX, but in a makefile i need to use $(DESTDIR) | 09:02 |
| imexil | thanks dholbach, ogra_ | 09:02 |
| ogra_ | (note the brackets) | 09:02 |
| ogra_ | i'm not sire how make-parameters: are used here | 09:03 |
| ogra_ | *sure | 09:03 |
| qengho | 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:06 | |
| imexil | Right. I was hoping to not have to change the Makefile since I'm not upstream | 09:07 |
| imexil | "IPEPREFIX=$(DESTDIR)" does not work btw. | 09:08 |
| mup | PR snapcraft#692 closed: Use the new snapcraft mailing list as contact info <Created by seb128> <Closed by seb128> <https://github.com/snapcore/snapcraft/pull/692> | 09:10 |
| cking | 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:11 |
| mup | PR snapcraft#693 opened: Implement "oneshot" daemon type <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/693> | 09:13 |
| cking | 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 |
| cking | it's not helping with "velocity" | 09:23 |
| ogra_ | cking, just stop using exotic interfaces :) .... most of us dont have to wait at all | 09:26 |
| cking | ogra_, ok, well, that's all my code then ;-) | 09:26 |
| seb128 | cking, if the published one is in devmode it might not be listed by snap find by installing it should still work? | 09:36 |
| seb128 | (I think from what I read) | 09:37 |
| seb128 | do you force devmode? | 09:37 |
| cking | i don't believe I did | 09:37 |
| seb128 | k, maybe you got confused by the store UI and didn't actually press the publish button? | 09:38 |
| seb128 | seem to happen to some people | 09:38 |
| seb128 | otherwise I don't know, you need somebody from the store team I guess | 09:38 |
| cking | it says "Package status is Published" | 09:38 |
| seb128 | k, dunno then, sorry | 09:39 |
| slangasek | 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:40 |
| slangasek | i.e. is my grub.cfg stale or is my grubenv stale | 09:41 |
| ogra_ | i *think* you want snap_kernel ... | 09:42 |
| ogra_ | hmm, though looking at the arm configs it seems to be snappy | 09:43 |
| ogra_ | yeah, i take that back, it should be snappy_kernel, thats used everywhere else | 09:44 |
| slangasek | hmm | 09:44 |
| slangasek | so this was changed recently? | 09:44 |
| ogra_ | abd looking at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/generic-amd64/grub.cfg the code agrees too | 09:44 |
| ogra_ | not that i'm aware | 09:45 |
| slangasek | I had this working last time I built an image, using the same version of snap supporting 'snap weld', and something has changed ;) | 09:45 |
| slangasek | ok, very confusing, I don't know where this grub.cfg is coming from | 09:46 |
| ogra_ | well, it doesnt look like the grub.cfg in the gadget has changed much since we switched to all-snap images | 09:47 |
| slangasek | yes | 09:47 |
| slangasek | I don't know where the broken grub.cfg is coming from - my problem to sort out | 09:47 |
| ogra_ | sergiusens, bah, the rust selftests fail in the PPA snapcraft build :/ | 09:47 |
| ogra_ | slangasek, do you use the right build tool ? you need to use the u-d-f-experimental from mvo currently | 09:47 |
| slangasek | ogra_: yes, I use the right build tool, it's called ubuntu-image. :P | 09:48 |
| ogra_ | lol | 09:48 |
| slangasek | :P ;) :P | 09:48 |
| ogra_ | ok | 09:48 |
| ogra_ | then i agree that it is your problem to sort :) | 09:48 |
| slangasek | hmm, there's a broken /system-data/boot/grub/grub.cfg | 09:49 |
| slangasek | so that's actually coming from snap weld, so I probably need to get fixes to that | 09:50 |
| ogra_ | well, isnt snap weld dead ? | 09:50 |
| ogra_ | i thought it already got renamed | 09:50 |
| slangasek | yes, but that's the interface we were writing to at the time | 09:50 |
| ogra_ | ah | 09:50 |
| slangasek | and I was trying to debug why my previously-working image build pipeline regressed | 09:51 |
| slangasek | 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:06 |
| ogra_ | slangasek, do you have that from the store ? | 10:07 |
| === AL_ is now known as Guest55858 | ||
| slangasek | ogra_: I have it as downloaded by 'snap weld' today, yes | 10:08 |
| slangasek | tracking edge channel (which is a prereq) | 10:08 |
| ogra_ | hmm, weird | 10:08 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | slangasek, is that on first boot ? | 10:10 |
| slangasek | ogra_: yes | 10:10 |
| ogra_ | are there probably some format options missing ? i forgot how u-d-f did the formatting ... i think we called out to sgdisk | 10:11 |
| mup | Bug #1607297 opened: Error with an example Python snap <Snappy:New> <https://launchpad.net/bugs/1607297> | 10:15 |
| slangasek | 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:16 |
| mup | PR snapd#1597 opened: tests: add hardware-observe spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1597> | 10:18 |
| ogra_ | 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:18 |
| ogra_ | # Mount and umount first to let the kernel handle | 10:19 |
| ogra_ | # the journal and orphaned inodes (much faster than e2fsck). | 10:19 |
| ogra_ | mount -o errors=remount-ro "$path" "$writable_mnt" || true | 10:19 |
| ogra_ | umount "$writable_mnt" || true | 10:19 |
| ogra_ | and then we run | 10:19 |
| ogra_ | /sbin/e2fsck -va "$path" >> "$logfile" 2>&1 || true | 10:19 |
| ogra_ | right afterwards | 10:19 |
| ogra_ | there should be a log in case you have an initrd prompt | 10:20 |
| ogra_ | under /run/initramfs/ | 10:20 |
| === chihchun_afk is now known as chihchun | ||
| stgraber | 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 |
| stgraber | 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:35 |
| stgraber | 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:36 |
| stgraber | (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 | |
| stgraber | 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:37 |
| slangasek | ogra_: /dev/vda2 has unsupported feature(s): metadata_csum | 10:38 |
| stgraber | so yeah, that's an odd case where even --devmode still breaks you :) | 10:38 |
| ogra_ | stgraber, oooh lovely ... please make it a separate interface, not buried in an lxd inetrface or so ... i want to use it :) | 10:38 |
| slangasek | ogra_: so it seems that creating a new filesystem with e2fsck in yakkety is not compatible with series 16's e2fsck, sigh :/ | 10:38 |
| stgraber | 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 | |
| ogra_ | slangasek, hooray for steady advancement of our software :P | 10:39 |
| slangasek | 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:40 |
| ogra_ | well, i'm not sure if u-d-f actually uses e2fsprogs or rather some fancy go implementation | 10:41 |
| ogra_ | http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/view/head:/diskimage/partition.go | 10:43 |
| ogra_ | looks like it actually uses parted directly | 10:43 |
| ogra_ | (which actually is a bit awkward when doing GPT stuff) | 10:44 |
| slangasek | ogra_: /I'm not using u-d-f/ | 10:48 |
| ogra_ | i know ... but it works with u-d-f | 10:48 |
| ogra_ | so you have something to compare to | 10:48 |
| slangasek | with the yakkety version of e2fsprogs? | 10:48 |
| ogra_ | 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:49 |
| ogra_ | (i personally have only tested in xenial though) | 10:50 |
| slangasek | yes, and at that point it also worked for me with ubuntu-image | 10:50 |
| slangasek | and e2fsprogs claims not to have changed since then ;) | 10:50 |
| ogra_ | i'm just not sure if parted actually uses e2fsprogs internally for its mkpart call | 10:50 |
| slangasek | it does | 10:51 |
| ogra_ | ah, k | 10:51 |
| slangasek | anything else would be layer-violating madness ;) | 10:51 |
| ogra_ | well, it doesnt call out to sgdisk for GPT partitions :) | 10:52 |
| ogra_ | so you never know :) | 10:52 |
| slangasek | yes, because it's parted and because partitions | 10:53 |
| slangasek | it's not fsed | 10:53 |
| ogra_ | (i wasnt serious ... :) ) | 10:53 |
| imexil | 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:54 |
| ogra_ | sergiusens, josepht, no change with the patch /tmp and /home/ubuntu are still having 0755 permissions and are root:root | 10:55 |
| ogra_ | err | 10:55 |
| ogra_ | wait | 10:55 |
| ogra_ | i take that back, i'm blind | 10:55 |
| === hikiko is now known as hikiko|ln | ||
| slangasek | 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:01 |
| slangasek | ogra_: so, what changed in the edge kernel snap since last week? how can I see the history of the package, etc.? | 11:02 |
| slangasek | (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 |
| lool | ogra_: hey | 11:03 |
| lool | ogra_: have you ever got: run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 1 | 11:03 |
| ogra_ | lool, yeah, old bug that is fixed since a while ... iirc apw did an SRU | 11:04 |
| apw | ogra_, right that should be fixed i beleive | 11:04 |
| ogra_ | slangasek, nothing should have changed, uploads are all manual | 11:04 |
| lool | 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:04 |
| slangasek | hmm | 11:05 |
| ogra_ | slangasek, and to my knowledge nobody uploaded a new kernel snap | 11:05 |
| slangasek | ogra_: how would I rule this out with certainty? :) | 11:05 |
| lool | - Download snap "canonical-pc-linux" from channel "stable" (revision 24 of snap "canonical-pc-linux" already installed) | 11:05 |
| lool | - Download snap "canonical-pc" from channel "stable" (revision 6 of snap "canonical-pc" already installed) | 11:05 |
| lool | so I'm fully up-to-date thre | 11:05 |
| lool | perhaps the snap isn't updated | 11:06 |
| ogra_ | 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 |
| slangasek | ogra_: mmhmm - ok, thanks for checking :) | 11:07 |
| ogra_ | apw, ppisati_, did one of you upload a canonical-pc-linux snap yesterday ? | 11:08 |
| ogra_ | (and how was the built ??) | 11:08 |
| slangasek | ogra_: fwiw if there were something usable in a channel other than 'edge' I would happily use that for prototyping instead :-) | 11:08 |
| ogra_ | slangasek, try stable | 11:08 |
| slangasek | ogra_: stable is too stable | 11:08 |
| slangasek | ;) | 11:09 |
| ogra_ | but note that has a very old ubuntu-core | 11:09 |
| slangasek | yes. too old for my purposes | 11:09 |
| slangasek | ogra_: meanwhile... maybe you could back that rev out of the edge channel? | 11:10 |
| apw | ogra_, i think that was bjf | 11:10 |
| ogra_ | slangasek, http://people.canonical.com/~ogra/snappy/canonical-pc-linux_31.snap (give it another munitee, still uploading) | 11:11 |
| ogra_ | apw, how did he build that ? there are a good bunch of packages that need to go in there | 11:12 |
| apw | ogra_, i believe the snapcrafy.yaml is on the tip of our branches | 11:12 |
| ogra_ | sigh | 11:12 |
| ogra_ | apw, that wont work | 11:12 |
| apw | ogra_, but ... i'd say you'd be better short circuiting to him direct | 11:12 |
| apw | ogra_, oh i am sure, but hey, this is how you learn :) | 11:13 |
| ogra_ | we need all that meta pulls in ... and soon also mesa and some other bits | 11:13 |
| ogra_ | apw, i have a buiolld system nearly ready for the kernel snaps | 11:13 |
| ogra_ | slangasek, uploaded, grab it :) | 11:13 |
| apw | 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:13 |
| ogra_ | 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:14 | |
| apw | ogra_, we did what ? oh perhaps i malign him, ask bjf if it was him and go from there | 11:15 |
| slangasek | apw, ogra_: I'm talking with bjf here at sprint, he tells me he did not intentionally upload anything | 11:15 |
| ogra_ | apw, well, someone uploaded canonical-pc-linux under the shared store account | 11:15 |
| ogra_ | weird | 11:15 |
| apw | ogra_, as far as i know it was not me | 11:15 |
| slangasek | and it would've had to be an upload + publish | 11:15 |
| slangasek | anyway, if we're downrevved to 31, yay | 11:16 |
| ogra_ | not for edge i think | 11:16 |
| slangasek | ah, ok | 11:16 |
| ogra_ | sigh ... so i can only unpublish the whole package (all revisions) | 11:16 |
| slangasek | ogra_: hmm but snap weld gave me 32 again. I thought the store was instantaneous! how do I manually grab 31? | 11:16 |
| ogra_ | slangasek, i dont know ... | 11:17 |
| slangasek | right | 11:17 |
| ogra_ | by default the store only gives you the latest ... and i cant mange to remove only one revision | 11:17 |
| slangasek | ogra_: who should I hunt down here to fix it? ;) | 11:17 |
| slangasek | ogra_: other option | 11:17 |
| ogra_ | i tried to uncheck the channle from the snap now ... | 11:18 |
| ogra_ | try again, probably that works | 11:18 |
| slangasek | ogra_: can you point the beta channel to 31 for canonical-pc-linux and to 138 for ubuntu-core? | 11:18 |
| slangasek | I'll try again, but it's inconveniently slow to iterate | 11:18 |
| ogra_ | done | 11:18 |
| ogra_ | 31 -> beta i mean | 11:18 |
| slangasek | sweet | 11:18 |
| slangasek | ah | 11:18 |
| slangasek | what about for ubuntu-core? I only get to pick one channel for both | 11:19 |
| ogra_ | oh, wait thats i386 | 11:19 |
| slangasek | heh | 11:19 |
| ogra_ | 30 is actually amd64 | 11:19 |
| imexil | 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 |
| ogra_ | pushed to beta too | 11:19 |
| slangasek | um ok | 11:19 |
| slangasek | thanks | 11:19 |
| slangasek | and ubuntu-core? | 11:19 |
| ogra_ | yeah, its a bit weird since each upload bumps the revision and you need one upload per arch | 11:20 |
| ogra_ | on it | 11:20 |
| slangasek | ta | 11:20 |
| ogra_ | looks like 138 and 139 are beta+edge already | 11:20 |
| ogra_ | so you should be fine | 11:20 |
| slangasek | ogra_: sweeeeet thanks! | 11:21 |
| ogra_ | 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:22 |
| ogra_ | that should then auto-upload to the store from LP snap builds | 11:23 |
| mup | PR snapd#1598 opened: Implement a fuse interface <Created by stgraber> <https://github.com/snapcore/snapd/pull/1598> | 11:24 |
| stgraber | ogra_: ^ (I won't actually need it, but hopefully it does cover the bits you need) | 11:25 |
| ogra_ | 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:25 | |
| stgraber | 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 |
| ogra_ | stgraber, i'll poke around in it once i have some time for that | 11:26 |
| bjf | ppisati_, have you uploaded a kernel snap to the store recently? | 11:30 |
| ogra_ | bjf, perhaps it was mb | 11:30 |
| bjf | ogra_, we are trying to find out who uploaded the kernel snap to the store .. was not me | 11:30 |
| ogra_ | *mvo | 11:30 |
| ogra_ | 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 | |
| ogra_ | \o/ | 11:31 |
| bjf | ogra_, hunting ... | 11:31 |
| ogra_ | sergiusens, josepht, patch verified, my os snap looks fine and i have a properly booting image | 11:32 |
| ogra_ | and on that note ... | 11:32 |
| * ogra_ is off to the dentist ... back in 1-2h | 11:32 | |
| mup | PR snapd#1595 closed: many: make seed.yaml on firstboot mandatory and include sideInfo <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1595> | 11:40 |
| dholbach | imexil, looks like stuff is not copied over from stage/ to prime/ | 11:54 |
| === hikiko|ln is now known as hikiko | ||
| imexil | 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 |
| imexil | *involved | 11:55 |
| imexil | 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:57 |
| bjf | ogra_, apw yes it was mvo | 11:58 |
| mup | PR snapcraft#693 closed: Implement "oneshot" daemon type <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/693> | 12:03 |
| mup | Bug #1607344 opened: snap gives confusing error messages if snap login was ran with sudo <Snappy:Triaged> <https://launchpad.net/bugs/1607344> | 12:10 |
| === chihchun is now known as chihchun_afk | ||
| === drizztbsd is now known as timothy | ||
| kalikiana | 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:36 |
| kalikiana | I'm not sure that snapcraft does anything "special" during the build itself. It's mostly invoking make with the variables you defined. | 12:37 |
| kalikiana | 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:39 |
| jdstrand | 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:48 | |
| jdstrand | 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 |
| ahoneybun | trying to snap the new pithos release, wish me luck lol | 12:50 |
| jdstrand | stgraber: aka, it should be named 'lxd' and docker's should be named 'docker' | 12:51 |
| dholbach | imexil, I'd suggest sending a quick mail to snapcraft@lists.snapcraft.io asking for help | 12:52 |
| ahoneybun | heyo dholbach | 12:52 |
| dholbach | hi ahoneybun | 12:53 |
| imexil | 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 |
| ahoneybun | got time to debug a snap? | 12:53 |
| stgraber | jdstrand: yeah, zyga already told me I should go with a lxd one which is effectively unconfined rather than make this generic | 12:53 |
| imexil | dholbach: Yes probably a good idea. | 12:53 |
| ahoneybun | yaml: http://pastebin.ubuntu.com/21269089/ | 12:55 |
| stgraber | 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 |
| mup | PR snapd#1598: Implement a fuse interface <Created by stgraber> <https://github.com/snapcore/snapd/pull/1598> | 12:55 |
| ahoneybun | I'm getting local source is not a directory | 12:55 |
| kalikiana | imexil: PREFIX=/usr is perfectly writable by the user as it's going to become parts/*/install/usr/ anyway | 12:55 |
| ahoneybun | most likely did something wrong with curl and tar | 12:55 |
| jdstrand | stgraber: and no, you didn't screw something up with regard to the private mount namespace | 12:55 |
| kalikiana | imexil: I don't actually know what SNAPCRAFT_STAGE is. I haven't seen that in any docs. What does it point to? | 12:56 |
| ahoneybun | ohhh | 12:58 |
| ahoneybun | it's building | 12:58 |
| ahoneybun | false alarm | 13:02 |
| ahoneybun | just some stuff from curl | 13:02 |
| jdstrand | tianon: hi! | 13:03 |
| tianon | 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:03 |
| jdstrand | tianon: boy, I was just greeting you before I responded :) Maybe you should adjust your bot :) | 13:04 |
| ahoneybun | so I changed the source to : ./ and it does something but fails | 13:04 |
| ahoneybun | autoreconf -i returns with non-zero exit status 1 | 13:04 |
| jdstrand | 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 |
| jdstrand | tianon: the server implements the 'slots' side and the client the 'plugs' side | 13:05 |
| ahoneybun | http://pastebin.ubuntu.com/21270061/ | 13:05 |
| imexil | kalikiana: it points to the stage dir. I found it described here: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-advanced-features/ | 13:05 |
| jdstrand | tianon: when a snap provides a slot-implementation, that makes available the slot to be plugged by other snaps | 13:06 |
| imexil | dholbach: Mail sent. (for moderation since I wasn't aware that it's for subsribed users only) | 13:08 |
| jdstrand | 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:08 |
| ogra_ | stgraber, zyga, i even have a shiny bug for it... bug 1603113 | 13:09 |
| mup | Bug #1603113: add fuse filesystem interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1603113> | 13:09 |
| jdstrand | 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:10 |
| jdstrand | 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:11 |
| ahoneybun | how do I tell snappy to look into parts/pithos-download/src/ ? | 13:12 |
| dholbach | thanks imexil | 13:12 |
| ahoneybun | dholbach: ^ | 13:12 |
| dholbach | ahoneybun, do you want to copy things over? or do you use some build system? | 13:13 |
| jdstrand | 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 |
| dholbach | ahoneybun, source-subdir for the latter ("snapcraft help sources" explains this) | 13:13 |
| ahoneybun | there is a autogen.sh file in there thast needs to run | 13:13 |
| ahoneybun | reading from here: https://github.com/pithos/pithos/wiki/Installing-from-Source | 13:13 |
| dholbach | ahoneybun, autotools plugin with source-subdir then | 13:13 |
| ahoneybun | source: source-subdir? | 13:14 |
| kalikiana | 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 |
| mup | PR snapcraft#694 opened: Pass --root to the python3 plugin on build <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/694> | 13:14 |
| ahoneybun | dholbach: http://pastebin.ubuntu.com/21269089/ | 13:14 |
| jdstrand | tianon: /me notes he meant to say PermanentSlotSnippet instead of PermanentSlotAppArmor/SecComp and the same for PermanentPlug* | 13:14 |
| ahoneybun | this is the current yaml | 13:14 |
| jdstrand | tianon: and ConnectedPlug* | 13:14 |
| jdstrand | tianon: the blog post and the location-observe interface should make things clear | 13:15 |
| dholbach | ahoneybun, I'm not sure... do you want me to figure this out for you now? | 13:15 |
| ahoneybun | mm help me figure it maybe | 13:15 |
| ahoneybun | does not have to be now now | 13:16 |
| dholbach | ok | 13:16 |
| ahoneybun | man snapcraft is picky about spacing | 13:27 |
| ogra_ | nessita, help ? | 13:29 |
| ogra_ | Launchpad uploaded this snap package to the store, but the store failed to | 13:29 |
| ogra_ | scan it: | 13:29 |
| ogra_ | Can not create a new package with name ubuntu-core, multiple origins for ubuntu-core are not allowed. | 13:29 |
| ogra_ | what can we do there ? | 13:29 |
| ahoneybun | making some progress dholbach | 13:31 |
| ahoneybun | thanks to the playpen I've simplifed my yaml a lot | 13:31 |
| kyrofa | ahoneybun, it has to be valid YAML :) | 13:31 |
| kyrofa | If YAML isn't spaced right it can't be parsed | 13:31 |
| ahoneybun | well I got to the point that it found the autogen.sh file | 13:32 |
| ahoneybun | it said it was missing intltoolize | 13:32 |
| nessita | ogra_, let me check | 13:33 |
| ogra_ | nessita, the ubuntu-core snap recently got changed to shared maintainership ... i could imagine that is realted | 13:33 |
| nessita | ogra_, are you uploadingas yourself, and you can collaborate with the ubuntu-core package? | 13:33 |
| ahoneybun | mm missing appstream.xml.m4? | 13:33 |
| ogra_ | nessita, yes, to both, i can manage it in myapps and i can upload it manually | 13:33 |
| ogra_ | jzst not through LP | 13:34 |
| ogra_ | *just | 13:34 |
| ahoneybun | trying again | 13:34 |
| dholbach | ahoneybun, how about this? http://paste.ubuntu.com/21272597/ | 13:35 |
| dholbach | (as you can see, I nicked the build plugin from autotools) | 13:36 |
| dholbach | and we should probably file a bug for the autotools plugin to respect autogen.sh as well | 13:36 |
| dholbach | ... or to allow specifying the build script | 13:36 |
| ahoneybun | dholbach: http://pastebin.ubuntu.com/21272663/ | 13:36 |
| ahoneybun | this going somewhere | 13:37 |
| dholbach | ahoneybun, can you try what I pasted earlier? | 13:37 |
| ahoneybun | it's priming! | 13:37 |
| dholbach | because that works for me | 13:37 |
| ahoneybun | snapping! | 13:37 |
| dholbach | what is mqtt-paho/python3 needed for? | 13:37 |
| dholbach | ok | 13:37 |
| ahoneybun | it needed python so I thought | 13:37 |
| ahoneybun | mm | 13:38 |
| ahoneybun | http://pastebin.ubuntu.com/21272895/ | 13:39 |
| ahoneybun | something about no module named gi | 13:39 |
| dholbach | python3-gi maybe? | 13:39 |
| ahoneybun | plugin? | 13:39 |
| ahoneybun | it built but | 13:40 |
| dholbach | no, in stage-packages | 13:40 |
| dholbach | http://snapcraft.io/docs/build-snaps/syntax | 13:40 |
| ahoneybun | it is in the build-packages | 13:40 |
| ahoneybun | on I saw that | 13:40 |
| * ahoneybun looks anyway | 13:40 | |
| ahoneybun | the docs are pretty good | 13:40 |
| dholbach | or check out http://snapcraft.io/docs/build-snaps/parts | 13:41 |
| dholbach | stage-packages lists the dependencies needed to actually run the contents of the snap. They’ll be packed into the final snap. Here, the requirement is for the hello-world part to download and unpack libqt5gui5 with all its dependencies. This method can reuse any of the 48000 .deb packages that traditional Ubuntu provides. It’s really that easy: just specify the packages you need embedded into your snap | 13:41 |
| ahoneybun | alright cool let me try doing that | 13:43 |
| ahoneybun | did you want me to test your yaml too? | 13:43 |
| dholbach | no worries, if yours works, go ahead and use that | 13:44 |
| ahoneybun | am I allowed to upload it to the store if it works well? | 13:44 |
| ahoneybun | or do I need permission from the developer? | 13:45 |
| dholbach | no, you can just upload | 13:45 |
| ahoneybun | alright cool | 13:46 |
| * ahoneybun needs to get his laptop charger | 13:46 | |
| ahoneybun | I'm getting a glib error | 13:49 |
| ahoneybun | mm | 13:49 |
| timothy | ahoneybun: which one? | 13:50 |
| ahoneybun | http://pastebin.ubuntu.com/21273934/ | 13:50 |
| ahoneybun | I love chrome syncing <3 | 13:51 |
| timothy | ahoneybun: it seems a wrong prefix error, since it looks for /share intead of /usr/share | 13:51 |
| seb128 | timothy, what's your snapcraft.yaml? | 13:52 |
| ahoneybun | so looking in the wrong place | 13:52 |
| timothy | seb128: not mine :P | 13:52 |
| seb128 | sorry | 13:52 |
| seb128 | ahoneybun, ^ | 13:52 |
| seb128 | ah, http://pastebin.ubuntu.com/21272663/ | 13:52 |
| seb128 | so yeah | 13:53 |
| ahoneybun | well I added a stage-package | 13:53 |
| seb128 | ahoneybun, you hit bug #1590831 | 13:53 |
| mup | Bug #1590831: having prefix='' by default is non standard and confusing <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590831> | 13:53 |
| seb128 | you can use "configflags: [--prefix=/usr]" | 13:53 |
| seb128 | comment on the bug as well to say that's you got confused by the issue | 13:53 |
| seb128 | it might help to convince kyrofa & co that it's an issue | 13:53 |
| ahoneybun | seb128: where do I put that line | 13:53 |
| seb128 | ahoneybun, under " plugin: autotools" for example | 13:54 |
| timothy | if you don't like /usr you can use prefix=/ | 13:54 |
| timothy | maybe :P | 13:54 |
| mup | PR snapcraft#695 opened: Add process-dependency-links option to Python plugins <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/695> | 13:56 |
| ahoneybun | done seb128 | 13:56 |
| ahoneybun | trying another buil | 13:56 |
| ahoneybun | *build | 13:56 |
| ahoneybun | dholbach: once it runs I'll see if I can remove mqtt-paho/python3 | 13:58 |
| zyga | stgraber: looking | 14:01 |
| ahoneybun | seb128: that is not the issue | 14:01 |
| ahoneybun | it's not in /usr/share/pithos/ either | 14:02 |
| ahoneybun | mm | 14:02 |
| ahoneybun | the heck | 14:03 |
| ahoneybun | it's in prime/user/share/pithos though | 14:03 |
| ogra_ | sergiusens, hmm, so trying to upload the new ubuntu-core to the store it fails complaining that confinement should not be set for type: os ... i guess we need another change | 14:03 |
| seb128 | ahoneybun, ah, that fun bug | 14:03 |
| ogra_ | sergiusens, i guess if i leave it out in snapcraft.yaml the build will still push it into snap.yaml in the resulting snap ? | 14:04 |
| seb128 | ahoneybun, you basically hit bug #1583250 | 14:05 |
| mup | Bug #1583250: upstream use of build-time defined DATADIR incompatible with snaps relocation <snap-desktop-issue> <Snapcraft:New> <Snappy:New> <snapcraft (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1583250> | 14:05 |
| ahoneybun | XD | 14:05 |
| kyrofa | ogra_, indeed it will | 14:05 |
| kyrofa | ogra_, I didn't know about that requirement :P | 14:05 |
| ogra_ | so we need to prevent that then | 14:05 |
| ogra_ | kyrofa, well, i blame jdstrand :) | 14:06 |
| ogra_ | 'confinement' should only be specified with 'type: app' lint-snap-v2_confinement_valid | 14:06 |
| ogra_ | i guess snapd or u-d-f dont really care about that field, so we could probably just fix it in the reviewer tools | 14:06 |
| ogra_ | (fix = ignore) | 14:07 |
| ahoneybun | any way around it seb128? | 14:07 |
| mup | PR snapcraft#696 opened: Replace 'strip' with 'prime' on intro page and step options <Created by bogdanap> <https://github.com/snapcore/snapcraft/pull/696> | 14:08 |
| seb128 | ahoneybun, you can try to --prefix=/snap/pithos/current/usr and organize: snap/pithos/current/usr: usr | 14:08 |
| ahoneybun | organize is under the prefix? | 14:08 |
| seb128 | yes | 14:10 |
| seb128 | it's a hack | 14:10 |
| seb128 | but prefix makes things installed where you point | 14:10 |
| seb128 | but snapd relocates | 14:10 |
| seb128 | so you end up having files are /snap/pithos/current /snap/pithos/current/usr if you don't reorganize | 14:11 |
| ahoneybun | I'm writing organize wrong | 14:12 |
| ahoneybun | getting validatiing issues | 14:12 |
| ahoneybun | the docs don't write an example of it | 14:13 |
| ahoneybun | oh | 14:13 |
| seb128 | organize: | 14:13 |
| seb128 | organize: [ snap/pithos/current/usr: usr ] | 14:14 |
| seb128 | I guess? | 14:14 |
| seb128 | or - snap/pithos/current/usr: usr | 14:14 |
| ahoneybun | none of those | 14:15 |
| ahoneybun | [{' ': ' '}] | 14:16 |
| seb128 | organize: | 14:16 |
| seb128 | snap/gedit310/current/usr: usr | 14:16 |
| ahoneybun | is what the error says | 14:16 |
| seb128 | try like that | 14:16 |
| seb128 | with the current name | 14:17 |
| ahoneybun | mapping valuse are not allowed here | 14:17 |
| ahoneybun | *values | 14:17 |
| seb128 | can you share your snapcraft.yaml? | 14:17 |
| ahoneybun | yea | 14:18 |
| ahoneybun | http://pastebin.ubuntu.com/21276502/ | 14:18 |
| ahoneybun | funny thing | 14:19 |
| ahoneybun | I'm making a snap using a snap | 14:19 |
| ahoneybun | XD | 14:19 |
| kyrofa | ahoneybun, "organize: snap/pithos/current/usr: usr" is not valid yaml | 14:19 |
| ahoneybun | using the Atom editier | 14:19 |
| timothy | snapception | 14:19 |
| ahoneybun | yea lol | 14:20 |
| seb128 | ahoneybun, sorry, just got on a new line for the pair | 14:25 |
| seb128 | ahoneybun, like in https://github.com/8none1/gedit310/blob/master/snapcraft.yaml#L19 | 14:25 |
| ahoneybun | so far I have not found a snap that uses organize to learn from | 14:25 |
| seb128 | ahoneybun, ^ | 14:26 |
| ahoneybun | now it can't find python3-dbus1 in the cache | 14:26 |
| ahoneybun | the heck | 14:26 |
| seb128 | weird | 14:28 |
| seb128 | can you pastebin the error? | 14:28 |
| ahoneybun | http://packages.ubuntu.com/search?suite=xenial§ion=all&arch=any&keywords=python3-dbus1&searchon=names | 14:28 |
| ahoneybun | I can't find it here either | 14:28 |
| ahoneybun | ohhh | 14:29 |
| ahoneybun | no 1 | 14:29 |
| ahoneybun | fixed | 14:29 |
| ahoneybun | I did not see the error before because of the organize thing | 14:30 |
| ahoneybun | snapping now | 14:30 |
| ahoneybun | this will be the last build for a few hours g2g out in a bit | 14:30 |
| Pharaoh_Atem | zyga: I just saw your email | 14:31 |
| ali1234 | how do i snap a service? | 14:35 |
| ahoneybun | mm why am I getting that gi module error again | 14:35 |
| ahoneybun | I have it in stage-packages | 14:35 |
| seb128 | ahoneybun, oh, my fault I guess | 14:36 |
| seb128 | the reorganize probably move it | 14:36 |
| ahoneybun | most likey | 14:36 |
| seb128 | ahoneybun, try moving stage-packages to a different part like in the gedit example I shared | 14:36 |
| ahoneybun | ok | 14:36 |
| seb128 | that's better as well because it means you can clean/rebuild pithos without redownloading all the debs every time | 14:37 |
| kalikiana | ali1234: http://snapcraft.io/create/ see "daemon: simple" | 14:37 |
| ahoneybun | different part? | 14:38 |
| ahoneybun | the deb: ? | 14:39 |
| seb128 | ahoneybun, ahoneybun like in https://github.com/8none1/gedit310/blob/master/snapcraft.yaml#L19 | 14:39 |
| seb128 | sec | 14:39 |
| ahoneybun | oh line 19 | 14:39 |
| seb128 | ahoneybun, http://paste.ubuntu.com/21278483/ | 14:40 |
| seb128 | ahoneybun, like that | 14:40 |
| seb128 | ahoneybun, it makes the deb build a different element so you don't need to redo that part every time you build the source | 14:40 |
| seb128 | also it means the reorganize is only going to apply to the pithos build | 14:41 |
| seb128 | not to the deb content | 14:41 |
| ahoneybun | what plugin nil? | 14:41 |
| seb128 | oh right | 14:41 |
| seb128 | yes | 14:41 |
| ahoneybun | yea running now | 14:42 |
| seb128 | :-) | 14:42 |
| ali1234 | kalikiana: if you make hello-world into a simple daemon, wouldn't it just start and then immediately exit indefinitely? | 14:44 |
| ogra_ | slangasek, FYI, i just re-owned the snap build for ubuntu-core to the snappy-dev team, if you go to https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core you should see a "request builds" link ... (i just noticed you are team admin for snappy-dev :) ) | 14:44 |
| ali1234 | or until init decided it was respawning too fast and then disabled it... | 14:45 |
| kalikiana | ali1234: I think the assumption is that hello-world keeps running. Otherwise it wouldn't make sense as a service. | 14:46 |
| ali1234 | it's GNU hello world | 14:46 |
| ali1234 | it just prints "hello world" and then exits | 14:46 |
| kalikiana | No that's not what it is. It's a node application. | 14:48 |
| ogra_ | depends which hello-world package you refer to :) | 14:48 |
| ogra_ | there are plenty of them in the store | 14:48 |
| kalikiana | Too many if you ask me... | 14:48 |
| ali1234 | source: http://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz | 14:48 |
| ogra_ | the canonical owned one ships a bunch of sub commands | 14:48 |
| ogra_ | hello-world.env ... hello-world.evil and hello-world.sh | 14:49 |
| kalikiana | ogra_: I do like the hello-world.env for the first steps into a snappy world. But there's no way to tell this from any of the others, let's be honest the name should've been reserved or an actually meaningful name should've been used. | 14:50 |
| ogra_ | +1 | 14:50 |
| ogra_ | but it is what it is now ... | 14:50 |
| kalikiana | And of course using two other hellos in the tutorial isn't helping | 14:50 |
| kalikiana | ali1234: For the moment, try to re-read the steps in the service section and ignore the previous GNU hello example. | 14:51 |
| kalikiana | It's unrelated. | 14:51 |
| ali1234 | steps? | 14:51 |
| kalikiana | Sentences... words... whatever is said there :-) | 14:52 |
| ali1234 | i keep reading them over and over and they aren't giving me any useful information :( | 14:53 |
| ali1234 | as far as i can tell i just define an app like normal, but i also say "daemon: simple" | 14:54 |
| ali1234 | assuming it is a simple daemon, which it is in my case | 14:54 |
| ogra_ | yeah | 14:54 |
| ogra_ | thast line tells snapd to create a systemd unit for it at install time | 14:54 |
| ali1234 | called hello-service? | 14:54 |
| ogra_ | iirc it is a bit more complext ... sanp.foo.bar.baz ... | 14:55 |
| ali1234 | can it be named the same as the app? | 14:55 |
| ogra_ | *snap. | 14:55 |
| ogra_ | check with systemctl | 14:55 |
| didrocks | Chipaca: do you know if there is any way to get the whole list of snap for my device in the store? (now search needs to have a string as a parameter) | 14:56 |
| didrocks | find* | 14:56 |
| kalikiana | 'snap find' works fine here, if you are patient | 14:59 |
| didrocks | hum, here I have "empty search query" | 14:59 |
| ogra_ | yeah | 15:00 |
| ogra_ | the latter is the latest | 15:00 |
| ogra_ | you cant search with empty string anymore | 15:00 |
| didrocks | right | 15:00 |
| didrocks | which is annoying to get a list of "snap of the months" :p | 15:00 |
| ogra_ | didrocks, https://plus.google.com/+Uappexplorer-ubuntu/posts | 15:01 |
| ogra_ | ;) | 15:01 |
| ogra_ | you can even see them roll in (semi-live ... its a bit delayed) | 15:01 |
| jibel | didrocks, you can do "snap find ." that'll return everthing apparently | 15:02 |
| didrocks | ogra_: yeah, I was thinking about using this for the coming months | 15:02 |
| didrocks | oh dot! | 15:02 |
| * didrocks hugs jibel | 15:02 | |
| didrocks | thanks! that does the trick | 15:02 |
| ogra_ | didrocks, that only returns 100 results though (hardcoded at the store side) | 15:03 |
| didrocks | how does it select what to return? | 15:03 |
| ogra_ | ogra@styx:~/Devel/branches/snapcraft$ snap find .*|wc -l | 15:03 |
| ogra_ | 101 | 15:03 |
| didrocks | it goes to x | 15:03 |
| stgraber | sergiusens: snapcraft.io says to use "upload", the command line tool says to use "push" instead, guess the website should be updated | 15:03 |
| didrocks | so just no x y z ? ;) | 15:03 |
| ogra_ | dunno, but there are more than 100 snaps | 15:03 |
| ogra_ | ... in the store | 15:03 |
| didrocks | ok, let's say it's taking ascii order | 15:03 |
| jibel | didrocks, http://paste.ubuntu.com/21281325/ | 15:09 |
| didrocks | jibel: that's "snap find ."? or juts a shell script? | 15:09 |
| didrocks | just* | 15:09 |
| jibel | didrocks, for x in a ...; find $x ... ;) | 15:10 |
| ogra_ | haha | 15:12 |
| ogra_ | quite awkward that we need such hacks instead of just having the store properly returning more than 100 | 15:13 |
| josepht | I think the intention is to not have 'snap find' return a list of "all" snaps in the store | 15:23 |
| ogra_ | yes, i understand the intention ... i just dont agree with it ;) | 15:23 |
| ogra_ | (it annoys me on the phone since i use it ... in android i can go on for hours to browse the store apps) | 15:24 |
| ogra_ | (on ubuntu it stops at 100 apps) | 15:24 |
| jibel | if only it was 100 random apps, but it returns always the same | 15:25 |
| ogra_ | i suspect that is why people always say there are no apps in ubuntu phone ... if they would see the whole list the experience would be quite different :) | 15:25 |
| josepht | ogra_: fwiw, I agree. I want to be able to aimlessly browse them all as well. | 15:26 |
| jibel | ogra_, they would discover all your webapps, that would be such an experience ;) | 15:26 |
| ogra_ | ! | 15:26 |
| ogra_ | see ! | 15:26 |
| mup | Bug #1607297 changed: Error with an example Python snap <Snapcraft:New> <Snappy:Invalid> <https://launchpad.net/bugs/1607297> | 15:33 |
| JamesTait | "< ~didrocks> how does it select what to return?" - the same way we did for Clicks: highest relevance, best ratings average, most recently updated. The fact we can't browse endlessly on the Click scope is a bug in the scope, the server has pagination but the scope doesn't use it. | 15:34 |
| didrocks | JamesTait: oh, interesting :) | 15:37 |
| JamesTait | There's also the size parameter to the API endpoint to get more than 100 results. This is all documented at https://search.apps.ubuntu.com/docs/#pagination-of-collections (formerly https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Pagination_of_Collections) | 15:39 |
| didrocks | hum, we could may be hack something around this, would be better than the shell script for now :) | 15:47 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#1599 opened: asserts,client: switch snap-build and snap-revision to be indexed by snap-sha3-384 <Created by pedronis> <https://github.com/snapcore/snapd/pull/1599> | 16:35 |
| ali1234 | well that didn't work | 16:50 |
| ali1234 | hmm i think it worked that time | 16:54 |
| ali1234 | oh wait, it didn't | 16:54 |
| ogra_ | funny monologue :) | 16:55 |
| ali1234 | http://paste.ubuntu.com/21293029/ | 16:56 |
| ali1234 | doesn't work | 16:56 |
| ali1234 | doesn't create a service file, doesn't create a command in /snap/bin, doesn't even attempt to start anything when i install it | 16:57 |
| ogra_ | plugin: nil | 16:57 |
| ogra_ | ??? | 16:57 |
| ali1234 | yes because it is already packaged | 16:57 |
| ali1234 | so i just stage it | 16:57 |
| ogra_ | and you are sure it ends up in the resulting snap ? | 16:58 |
| ali1234 | yes | 16:58 |
| ogra_ | and gmediarender is actually a daemon ? | 16:58 |
| ali1234 | meaning? | 16:58 |
| ogra_ | (i.e. it doesnt return) | 16:58 |
| ali1234 | yes, when you run it without arguments | 16:59 |
| ali1234 | http://paste.ubuntu.com/21293379/ | 16:59 |
| ali1234 | that's /snap/gmediarender/current | 16:59 |
| ali1234 | the init.d is part of the package. i don't want to use it because it doesn't work | 17:00 |
| ogra_ | kyrofa, bug #1607459 for your pleasure | 17:00 |
| mup | Bug #1607459: type:os should prevent adding "confinement" to the snap.yaml <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1607459> | 17:00 |
| kyrofa | Thanks ogra_ | 17:01 |
| ogra_ | ali1234, and when you install the snap you dont see systemd errors in the syslog ? | 17:01 |
| ali1234 | nope | 17:01 |
| ali1234 | [201393.122973] audit: type=1400 audit(1469724778.984:22): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.gmediarender.gmediarender" pid=3485 comm="apparmor_parser" | 17:02 |
| ali1234 | i see that | 17:02 |
| timothy | correct | 17:02 |
| ogra_ | well, you should also see a start attempt of the service | 17:02 |
| ali1234 | there is no service for it to start, unless it has a really cryptic name | 17:03 |
| ali1234 | i did systemctl | grep media | 17:03 |
| ali1234 | all i see is the mounts | 17:03 |
| ali1234 | bbiab | 17:03 |
| ogra_ | ogra@styx:~/Devel/branches$ systemctl |grep upnp | 17:03 |
| ogra_ | snap-upnp\x2dserver-1.mount loaded active mounted Mount unit for upnp-server | 17:03 |
| ogra_ | snap.upnp-server.minidlna.service loaded active running Service for snap application upnp-server.minidlna | 17:03 |
| ogra_ | snap.upnp-server.webdav.service loaded active running Service for snap application upnp-server.webdav | 17:03 |
| ogra_ | that is what i get for my upnp-server snap | 17:04 |
| ogra_ | so you shoudl actually see ... | 17:04 |
| ogra_ | snap.gmediarender.gmediarender.service | 17:04 |
| tianon | jdstrand: epic, that helps a lot, thanks so much! :D (I've also adjusted by over-enthusiastic naked ping script O:) I used to get folks pinging me with "tianon: hi" a _lot_ to check if I was online before asking me questions :P) | 17:17 |
| ali1234 | yeah i don't see that at all | 17:41 |
| ali1234 | ogra_: can i have your snapcraft.yaml please? | 17:44 |
| ogra_ | for the upnp-server ? thats a bit more complex, but sure ... one sec | 17:44 |
| ali1234 | i just installed it from the store and it works | 17:44 |
| ogra_ | https://github.com/ogra1/upnp-server | 17:44 |
| ogra_ | indeed it does :) | 17:44 |
| ali1234 | well at least i got some service files anyway | 17:45 |
| ali1234 | this will actually be helpful for me, since i need a media server to test with :) | 17:45 |
| ali1234 | and gmediaserver sucks | 17:45 |
| ali1234 | don't suppose you know of another media renderer? | 17:45 |
| ogra_ | you can access it via webdav to dump files into it | 17:45 |
| ogra_ | (i always use nautilus' "connect to server" with: dav://$external_ip/) | 17:46 |
| ali1234 | gvfs consistently crashes on my system | 17:47 |
| ali1234 | https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1511626 - also affects gvfs-dav | 17:47 |
| mup | Bug #1511626: gvfsd-smb crashed with signal 5 in g_settings_set_property() <amd64> <apport-crash> <vivid> <gvfs (Ubuntu):New> <https://launchpad.net/bugs/1511626> | 17:47 |
| ahoneybun | seb128: it's looking in the wrong place again | 17:48 |
| seb128 | ahoneybun, :-/ | 17:48 |
| seb128 | ahoneybun, pastebin? | 17:48 |
| ahoneybun | the glib error about .gresource | 17:48 |
| ahoneybun | let me get it | 17:48 |
| seb128 | ali1234, is that a snap or a deb? | 17:48 |
| ali1234 | seb128: which? | 17:49 |
| seb128 | ali1234, that gvfsd-smb bug is weird | 17:49 |
| seb128 | wth? | 17:49 |
| ali1234 | that's a deb. the one from the repos | 17:49 |
| ahoneybun | seb128: http://pastebin.ubuntu.com/21299368/ | 17:49 |
| ahoneybun | brb | 17:49 |
| ali1234 | nothing to do with snappy, i;m just griping | 17:49 |
| === om26er_ is now known as om26er | ||
| jdstrand | tianon: hehe - I was just trying to be friendly :) | 17:49 |
| tianon | jdstrand: indeed! :D | 17:50 |
| seb128 | ali1234, can you "$ strace -f /usr/lib/gvfs/gvfsd-smb 2>&1 | grep schemas"? | 17:50 |
| jdstrand | tianon: I can definitely relate to the motivation for that bot though. 'jdstrand: ping' just doesn't cut it :) | 17:50 |
| tianon | hahaha yeah | 17:50 |
| tianon | I get highlights on my phone too | 17:51 |
| jdstrand | oh yeah | 17:51 |
| tianon | so it's frustrating to be out somewhere and get "tianon: ping" as a notification | 17:51 |
| jdstrand | that would be rough | 17:51 |
| seb128 | ahoneybun, can you pastebin your snapcraft.yaml? I guess it's going to be easier if I have a try there, it looks better but unsure why the resource is missing | 17:51 |
| tianon | but "tianon: do you know XYZ about ABC?" is super useful and tells me whether I need to connect to irssi from my phone to reply :) | 17:51 |
| ali1234 | seb128: well lokk at that... it is opening something from /usr/local | 17:52 |
| ahoneybun | seb128: http://paste.ubuntu.com/21278483/ | 17:52 |
| ali1234 | /usr/local/share/glib-2.0/schemas/gschemas.compiled to be specific | 17:52 |
| ahoneybun | wait | 17:52 |
| seb128 | ali1234, delete that one... | 17:52 |
| seb128 | ali1234, local install bitten users since linux :p | 17:52 |
| ahoneybun | seb128: updated one | 17:53 |
| ahoneybun | http://pastebin.ubuntu.com/21299830/ | 17:53 |
| seb128 | ahoneybun, k, going to try it here | 17:53 |
| ahoneybun | cool | 17:54 |
| seb128 | ahoneybun, is the resources not installed? ls /snap/pithos/current/usr/share/pithos? do you know if that's supposed to be part of the make install or generated? | 17:54 |
| ahoneybun | it is in the prime dir | 17:54 |
| ali1234 | seb128: still crashes though | 17:55 |
| seb128 | ali1234, same bt? can you pastebin the strace cmd? | 17:56 |
| seb128 | the ouput of the cmd I mean | 17:56 |
| ali1234 | http://paste.ubuntu.com/21300282/ | 17:56 |
| seb128 | ali1234, you still have /usr/local lines, can you wipe out /usr/local/(share/)glib*? | 17:57 |
| ali1234 | i will nuke /usr/local | 17:57 |
| seb128 | or just move it away | 17:58 |
| ali1234 | still crashes, but maybe things are still in memory | 17:58 |
| ali1234 | hang on i will reboot | 17:58 |
| ali1234 | strace now says this http://paste.ubuntu.com/21300641/ | 17:59 |
| ahoneybun | any luck seb128? | 18:05 |
| mup | PR snapd#1600 opened: many: various fixes around the `create-user` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/1600> | 18:06 |
| seb128 | ahoneybun, I didn't have the debs so it took a bit to build, almost done | 18:06 |
| ahoneybun | oh ok | 18:06 |
| ahoneybun | is there any docs for the file system of snaps? | 18:07 |
| seb128 | http://snapcraft.io/ has some details | 18:07 |
| ali1234 | seb128: still crashes | 18:07 |
| ahoneybun | not much | 18:08 |
| seb128 | ali1234, interesting, does it do it if you start the process by hand from a cmdline? | 18:08 |
| seb128 | ahoneybun, what info are you after? | 18:08 |
| ali1234 | i don't know how to do that | 18:08 |
| ahoneybun | where that /snap/pithos/current/ stuff it | 18:08 |
| ahoneybun | like where to look for the file that seems to be missing | 18:09 |
| ahoneybun | it is in the prime dir | 18:09 |
| seb128 | ali1234, what if you try "/usr/lib/gvfs/gvfsd-smb --spawner :1.9 /org/gtk/gvfs/exec_spaw/7" | 18:09 |
| seb128 | yes | 18:09 |
| seb128 | it's the prime that is mounter in /snap/pithos/current | 18:09 |
| seb128 | mounted | 18:09 |
| ali1234 | it says "call_spawned_cb: Error sending a message: The name :1.9 was not provided by any .service files (g-dbus-error-quark, 2)" | 18:09 |
| ali1234 | then it just continues to run doing nothing | 18:09 |
| seb128 | ali1234, how do you trigger the crash usually? | 18:10 |
| ahoneybun | so it is in /prime/usr/share/pithos/pithos.gresource | 18:10 |
| ali1234 | open thunar and type a smb: or dav: url into the location | 18:10 |
| ali1234 | or anything else that uses gvfs | 18:10 |
| seb128 | ali1234, does that crash the process you just started? | 18:10 |
| ali1234 | this ia guaranteed crash 100% of the time | 18:10 |
| seb128 | ahoneybun, arg, sorry | 18:11 |
| seb128 | ahoneybun, I though your snap was name "pithos" | 18:11 |
| ali1234 | seb128: no | 18:11 |
| ahoneybun | well pithos-ahoneybun is the name | 18:11 |
| seb128 | ahoneybun, --prefix=/snap/pithos-ahoneybun/current/usr | 18:11 |
| seb128 | then | 18:11 |
| ahoneybun | ohhh | 18:11 |
| seb128 | same for the organize rule | 18:11 |
| ahoneybun | building now | 18:12 |
| ahoneybun | this will work! | 18:12 |
| ahoneybun | I will keep trying | 18:12 |
| seb128 | :-) | 18:12 |
| ahoneybun | Franz was a fail though | 18:12 |
| ogra_ | this will work unti you hit a distro where snaps dont get installed to /snap | 18:13 |
| ogra_ | :P | 18:13 |
| ahoneybun | one step at a time lol | 18:13 |
| seb128 | ogra_, well I raised that issue several time but seems it's not judged important enough to be discussed yet, so let's see once we get there | 18:17 |
| seb128 | I can foresee what comes though | 18:17 |
| seb128 | it's going to happen | 18:17 |
| seb128 | we are going to get online rants about snaps | 18:17 |
| seb128 | and then it's going to be a priority to address | 18:18 |
| ogra_ | yeah, and lots of fun with ad-hoc sprints and such | 18:19 |
| * ogra_ already looks forward to the traveling :P | 18:19 | |
| ogra_ | (though i must admit i have never used that hack :P ... *my* snaps will work :) ) | 18:20 |
| seb128 | yeah, you snap code from bc writen in stones :p | 18:21 |
| kyrofa | Yeah I've not run into it either | 18:22 |
| kyrofa | I suspect seb128 picks projects to snap based on whether or not this hack is needed :P | 18:22 |
| ogra_ | seb128, you mean nethack isnt a modern MMO ? | 18:23 |
| kyrofa | Hahaha | 18:23 |
| seb128 | kyrofa, I'm just helping ahoneybun here | 18:23 |
| kyrofa | seb128, I know, I'm just kidding :) | 18:23 |
| seb128 | :-) | 18:23 |
| kyrofa | seb128, it's definitely a problem | 18:23 |
| kyrofa | seb128, but the workaround that's needed is a hard one | 18:23 |
| kyrofa | So it's slow | 18:23 |
| ogra_ | there is nothing five stacked wrapper scripts cant fix :P | 18:24 |
| seb128 | ahoneybun, seems to go further, need to stage-package gir1.2-gtk-3.0 now | 18:24 |
| ahoneybun | oh | 18:24 |
| ahoneybun | I'm building still lol | 18:24 |
| kyrofa | ogra_, typically I agree, but there are really some projects that write this path into binaries | 18:24 |
| seb128 | kyrofa, the proper fix would be easy, just provide a stable location, e.g /var/lib/snap/name that point to the real mount | 18:24 |
| ahoneybun | should I cancel it and add that? | 18:24 |
| ahoneybun | seb128: ^ | 18:24 |
| seb128 | ahoneybun, yes | 18:25 |
| kyrofa | seb128, I'm not sure we can even guarantee that across distros | 18:25 |
| seb128 | why not? | 18:25 |
| ahoneybun | I keep after every build so that's what slows me | 18:25 |
| seb128 | kyrofa, just make them in XDG_RUNTIME_DIR? | 18:25 |
| seb128 | ahoneybun, looking at your build-packages you are going to need more stage-package | 18:26 |
| seb128 | ahoneybun, if there is a deb around look at its depends and add that as stage | 18:26 |
| seb128 | apt-cache show gstreamer1.0-plugins-good, gstreamer1.0-plugins-bad, python3-pkg-resources, python3-gi, python3-gi-cairo, gir1.2-gtk-3.0, gir1.2-gstreamer-1.0, gir1.2-gst-plugins-base-1.0 | 18:26 |
| seb128 | ups | 18:26 |
| seb128 | ahoneybun, ^ those | 18:26 |
| ahoneybun | I added what the github page showed | 18:27 |
| ahoneybun | that's to build no? | 18:27 |
| seb128 | no | 18:27 |
| seb128 | those ^ are runtime depends | 18:27 |
| seb128 | you need the bindings for cairo/gtk/gstreamer | 18:27 |
| ahoneybun | that was apt-cache show pithos right? | 18:28 |
| mup | PR snapd#1601 opened: partition: clear snap_try_{kernel,core} on success <Created by mvo5> <https://github.com/snapcore/snapd/pull/1601> | 18:29 |
| seb128 | ahoneybun, yes | 18:29 |
| ahoneybun | alright put it in stage-packages | 18:30 |
| kyrofa | ahoneybun, seb128 note that snapcraft will pull in libs if ldd shows them | 18:33 |
| ahoneybun | I'm getting a error about file paths in common | 18:33 |
| seb128 | kyrofa, is that true for python instrospection bindings as well? | 18:34 |
| seb128 | I guess not | 18:34 |
| ahoneybun | but different contents | 18:34 |
| seb128 | ahoneybun, pastebin? | 18:34 |
| kyrofa | seb128, probably not, I figure that stuff is dlopened | 18:35 |
| ahoneybun | http://pastebin.ubuntu.com/21305247/ | 18:35 |
| ahoneybun | most likely need desktop/gtk3 | 18:35 |
| seb128 | ahoneybun, can you share the snapcraft.yaml? | 18:36 |
| ahoneybun | http://pastebin.ubuntu.com/21305538/ | 18:37 |
| seb128 | hum | 18:38 |
| seb128 | I wonder if that got fixed in a new snapcraft | 18:38 |
| seb128 | kyrofa, ^ do you know? the file conflict thing | 18:38 |
| ahoneybun | I should have a new version | 18:38 |
| ahoneybun | the newest | 18:38 |
| kyrofa | ahoneybun, seb128 indeed, that bug was fixed in the version being SRUd now | 18:39 |
| seb128 | ahoneybun, install https://launchpad.net/ubuntu/+source/snapcraft/2.13.1/+build/10516627/+files/snapcraft_2.13.1_all.deb | 18:39 |
| kyrofa | ahoneybun, until that fix gets to you you can filter one (or both) of them out using the stage and snap keywords | 18:40 |
| ahoneybun | which are? | 18:40 |
| kyrofa | ahoneybun, https://github.com/snapcore/snapcraft/blob/master/docs/snapcraft-syntax.md | 18:40 |
| kyrofa | ahoneybun, ways to filter files out from parts | 18:41 |
| ahoneybun | so - file to exclude | 18:42 |
| ahoneybun | and * to include? | 18:42 |
| ahoneybun | not sure | 18:44 |
| seb128 | ahoneybun, just install the new snapcraft with dpkg ^ | 18:46 |
| ahoneybun | yea just did that lol | 18:46 |
| seb128 | ahoneybun, you need gir1.2-secret-1 as well | 18:46 |
| seb128 | just hit that one missing, rebuilding... | 18:46 |
| ahoneybun | oh | 18:46 |
| ahoneybun | it's priming for me | 18:47 |
| seb128 | :-/ | 18:47 |
| ahoneybun | got a error about the desktop-launch | 18:47 |
| seb128 | iterating on snapcraft is not as easy as it should | 18:47 |
| seb128 | tends to need to wipe lot of the state and restart | 18:47 |
| seb128 | oh? | 18:47 |
| seb128 | which one? | 18:47 |
| ahoneybun | well I have desktop-launch pithos | 18:48 |
| ahoneybun | but there is no executable for that | 18:48 |
| ahoneybun | to install it I think it needs to run the ./configure and then the make install | 18:49 |
| ahoneybun | so the bin is in /usr/local/bin/pithos | 18:50 |
| ahoneybun | but with our changes | 18:51 |
| ahoneybun | it should be snap/pithos-ahoneybun/current/usr/local/bin/pithos | 18:52 |
| ahoneybun | trying that now | 18:52 |
| ahoneybun | mm | 18:53 |
| ahoneybun | the geddit did it different | 18:53 |
| ahoneybun | the command desktop-launch does not exist or not executable | 18:53 |
| seb128 | ahoneybun, your snapcraft was starting the right command, we wouldn't have had the import errors from the code otherwise | 18:56 |
| ahoneybun | seb128: http://pastebin.ubuntu.com/21308132/ | 18:57 |
| ali1234 | hmm okay, my gvfs is fixed, thanks seb128! | 18:59 |
| seb128 | yw! | 18:59 |
| ali1234 | now back to snappy... | 18:59 |
| seb128 | ahoneybun, weird, is that since the snapcraft update?! | 18:59 |
| seb128 | need to go for dinner but I might be back later | 19:00 |
| seb128 | bbl | 19:00 |
| ahoneybun | I updated to 2.13.1 | 19:00 |
| ahoneybun | let me do a clean build | 19:00 |
| ali1234 | so i actually do have a service file for gmediarender | 19:00 |
| seb128 | works here | 19:00 |
| seb128 | weird | 19:00 |
| ahoneybun | it builds? | 19:00 |
| ali1234 | http://paste.ubuntu.com/21308595/ | 19:00 |
| ali1234 | but the thing is it doesn't ever show in systemctl | 19:00 |
| ali1234 | ah... i need to say "systemctl -a" | 19:01 |
| ali1234 | snap.gmediarender.gmediarender.service loaded inactive dead Service for snap application gmediarender.gmediarender | 19:02 |
| ali1234 | how do i clean up all the old snaps i have installed? | 19:08 |
| ahoneybun | snap remove | 19:24 |
| ahoneybun | snap list will show the ones installed | 19:24 |
| ali1234 | i just want to remove the old revisions | 19:27 |
| ahoneybun | I'm getting so close! | 19:38 |
| zyga | ali1234: snapd 2.11 (in proposed soon) will do this automatically | 19:39 |
| ahoneybun | now down to some gtk-warning and apparmor issue | 19:53 |
| ahoneybun | http://pastebin.ubuntu.com/21315880/ | 19:55 |
| stokachu | trying to run conjure-up -h and it just hangs https://www.irccloud.com/pastebin/KP42oVnq/ | 20:05 |
| stokachu | i did run snap install conjure-up --devmode to attempt to run conjure-up -h | 20:06 |
| stokachu | it works in snap try prime mode | 20:06 |
| ahoneybun | so running pithos runs | 20:23 |
| jdstrand | ahoneybun: the apparmor issue is bug #1590679. there is an exploratory PR. we are getting close to deciding what the final implementation should be | 20:34 |
| mup | Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679> | 20:34 |
| kyrofa | Hey jdstrand, I figure it's not a high priority, but has any progress been made on the upstream changes necessary for seccomp errno | 20:38 |
| kyrofa | ? | 20:38 |
| ahoneybun | jdstrand: I got around it some how | 20:40 |
| ahoneybun | daemon: simple fixed it | 20:40 |
| ahoneybun | no clue how | 20:40 |
| jdstrand | kyrofa: tyhicks is/will be working on it now/soon | 20:41 |
| kyrofa | jdstrand, alright thanks! | 20:42 |
| jdstrand | tyhicks: what are your thoughts on CAP_IPC_LOCK wrt interfaces? | 20:44 |
| jdstrand | tyhicks: I'm conflicted-- on the one hand, an app should be able to lock memory I think, but on the other, it could be used to keep from swapping. its sorta like the oom_score_adj/setpriority discussion (where if you raise the score of other processes with your uid, you effectively raised yours) and sorta bleeds into process-control where you can renice | 20:46 |
| jdstrand | honestly, I'm surprised we haven't seen it come up yet | 20:47 |
| tyhicks | jdstrand: we probably need to allow it (disallowing it can result in security issues) but document that it can be used to DoS other programs that try to lock memory | 20:48 |
| jdstrand | tyhicks: that is what I was thinking. I have no idea how we would sensibly mediate that | 20:49 |
| tyhicks | jdstrand: currently, we're not allowing any programs to lock memory so allowing it is an improvement even if there is some snap that (un)intentionally locks the maximum amount of memory | 20:49 |
| jdstrand | yeah, we can handle abuse through store processes | 20:50 |
| tyhicks | jdstrand: store processes is how we'll handle it today but, in the future, snap-confine could place cgroup limits, or maybe use apparmor's rlimit mlock rules, on a specific snap app that is lower than the system mlock limit | 20:53 |
| tyhicks | jdstrand: snap-confine could also call setrlimit(RLIMIT_MEMLOCK, ...) before setting the seccomp filter (assuming that we're still blocking setrlimit()) | 20:55 |
| jdstrand | tyhicks: we allow setrlimit but not CAP_SYS_RESOURCE (in safe interfaces) | 21:00 |
| jdstrand | tyhicks: but we could always arg filter RLIMIT_MEMLOCK | 21:01 |
| jdstrand | tyhicks: ok adding capability ipc_lock to default template (no idea where else to put it-- speak up if it should be somewhere else) wich comment, and created incoming card with this conversation | 21:02 |
| jdstrand | tyhicks: I guess I could create a manual connected interface | 21:03 |
| tyhicks | jdstrand: I don't think memory locking is something we should expose to users | 21:04 |
| jdstrand | yeah, that was my feeling too | 21:04 |
| === JanC is now known as Guest85214 | ||
| === JanC_ is now known as JanC | ||
| ahoneybun | what happens if a name on the snap store is taken? | 21:31 |
| kyrofa | ahoneybun, only one account can publish a given name | 21:34 |
| ahoneybun | someone is holding pithos - the name of the app I'm summiting | 21:35 |
| ahoneybun | so I got pithos-1 lol | 21:35 |
| ahoneybun | kyrofa: how do rev's work? | 21:53 |
| ahoneybun | like I just upload the same version to the store and it changes the rev ? | 21:53 |
| kyrofa | ahoneybun, they're assigned by the store when you upload | 21:53 |
| kyrofa | ahoneybun, right, the version you set is just a human-readable string | 21:53 |
| kyrofa | ahoneybun, the revision is used to determine which snap is newer than another | 21:53 |
| ahoneybun | I want to keep 1.2.0 as that is the version of the app that I packaged | 21:54 |
| kyrofa | ahoneybun, sure | 21:54 |
| ahoneybun | do you think the dev of pithos grabbed the name? | 21:55 |
| ahoneybun | hey seb128 | 21:56 |
| seb128 | hey ahoneybun, saw the backlog, congrats on getting your snap to work ;-) | 21:56 |
| ahoneybun | it seems to | 21:56 |
| ahoneybun | pithos launchs it from terminal | 21:56 |
| ahoneybun | at some times I can get it to show in Dash | 21:56 |
| ahoneybun | seb128: http://imgur.com/a/Kdrti | 21:57 |
| ahoneybun | :) | 21:57 |
| seb128 | nice! | 21:57 |
| ahoneybun | I can't seem to find it in Dash though | 21:58 |
| ahoneybun | it worked that one time | 21:58 |
| ahoneybun | but I have uninstalled it a few times | 21:58 |
| seb128 | it should work if you have a .desktop in setup/gui | 21:58 |
| ahoneybun | I do | 21:58 |
| ahoneybun | also a icon | 21:58 |
| seb128 | that gets installed in /var/lib/snap/desktop/applications | 21:58 |
| seb128 | and unity should pick it up | 21:58 |
| ahoneybun | followed dosbox | 21:59 |
| ahoneybun | from the snappy playpen | 21:59 |
| seb128 | k, unsure about that one, maybe an unity bug | 21:59 |
| seb128 | need to go though, time to sleep here | 21:59 |
| seb128 | bye | 21:59 |
| ahoneybun | it does not put a bin in /snap/bin mm | 21:59 |
| kyrofa | ahoneybun, can I see your yaml? | 22:10 |
| kyrofa | ahoneybun, as well as your desktop file? | 22:10 |
| mup | PR snapcraft#696 closed: Replace 'strip' with 'prime' on intro page and step options <Created by bogdanap> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/696> | 22:11 |
| ahoneybun | kyrofa: yaml: http://pastebin.ubuntu.com/21334564/ ; desktop: http://pastebin.ubuntu.com/21334623/ | 22:30 |
| kyrofa | ahoneybun, you're saying installing that puts nothing in /snap/bin/ ? | 22:33 |
| ahoneybun | nope | 22:34 |
| ahoneybun | funny that it is not in snap list either | 22:35 |
| ahoneybun | mm | 22:36 |
| ahoneybun | what? | 22:36 |
| kyrofa | ahoneybun, huh-- is it in /snap/ at all? | 22:36 |
| ahoneybun | ohhh | 22:36 |
| ahoneybun | it makes a dir | 22:36 |
| ahoneybun | in /snap/ | 22:36 |
| kyrofa | ahoneybun, indeed | 22:36 |
| ahoneybun | wait | 22:36 |
| kyrofa | ahoneybun, I do see a problem with the desktop file, though | 22:37 |
| kyrofa | ahoneybun, installing this snap should create a /snap/bin/pithos-ahoneybun.pithos-app binary | 22:37 |
| kyrofa | ahoneybun, the .desktop file needs to Exec=pithos-ahoneybun.pithos-app | 22:37 |
| ahoneybun | somehow I'm launching it | 22:38 |
| ahoneybun | though it is not installed though apt | 22:38 |
| ahoneybun | I built it from source | 22:38 |
| ahoneybun | not sure how to remove it though | 22:38 |
| kyrofa | ahoneybun, you mean via `make install` ? | 22:39 |
| ahoneybun | yea | 22:39 |
| kyrofa | ahoneybun, I don't suppose it also generates a `make uninstall` or `make remove` target? | 22:39 |
| ahoneybun | that worked | 22:40 |
| ahoneybun | added that to .desktop btw | 22:40 |
| ahoneybun | so I was running the source built version... | 22:42 |
| kyrofa | ahoneybun, makes sense | 22:44 |
| ahoneybun | snapping it up again with the changes | 22:51 |
| ahoneybun | still not making anything in /snap/bin | 22:52 |
| kyrofa | ahoneybun, and it shows up in snap list? | 22:53 |
| ahoneybun | so it made something in /snap though | 22:53 |
| ahoneybun | yea | 22:53 |
| kyrofa | ahoneybun, can you pastebin `ls /snap/` and `ls /snap/bin/` ? | 22:54 |
| ahoneybun | http://pastebin.ubuntu.com/21337330/ | 22:55 |
| kyrofa | ahoneybun, please also pastebin `cat /snap/pithos-ahoneybun/current/meta/snap.yaml` | 22:56 |
| ahoneybun | http://pastebin.ubuntu.com/21337591/ | 22:58 |
| kyrofa | ahoneybun, oh! It's a daemon | 22:58 |
| ahoneybun | oh | 22:58 |
| kyrofa | ahoneybun, that won't put anything in /snap/bin/, it'll generate a systemd unit file in /etc/systemd/system/ | 22:58 |
| ahoneybun | mm | 22:59 |
| ahoneybun | well it needed to do a service | 22:59 |
| kyrofa | ahoneybun, is that what you want? Those aren't launched by desktop files | 22:59 |
| ahoneybun | which AppArmor has denied | 22:59 |
| ahoneybun | kyrofa: http://pastebin.ubuntu.com/21338511/ | 23:07 |
| kyrofa | ahoneybun, as jdstrand mentioned earlier, that's bug ##1590679 | 23:08 |
| mup | Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679> | 23:08 |
| ahoneybun | yea I saw that. | 23:10 |
| ahoneybun | darn | 23:10 |
| ahoneybun | what does it mean when it fails to load canberra-gtk-module? | 23:14 |
| ahoneybun | installing it with --devmode gives me that error | 23:15 |
| wililupy | Did we change ubuntu-device-flash for gadget snaps? | 23:56 |
| wililupy | I get an error no hardware description in Gadget snap. | 23:56 |
| wililupy | trying to use --gadget=canonical-pc | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!