[00:06] <marcoceppi> do I just include setup/gui/fceux.desktop in the tree?
[00:25] <wililupy> When building a kernel snap, I now have to create a symbolic link named kernel.img to vmlinuz in my parts/kernel/install directory before I ran snapcraft stage/prime/snap. Is this something new or should I just rename vmlinuz to kernel.img?
[01:55] <sergiusens> marcoceppi gpsd uses scons (which that plugin was built for)
[01:55] <sergiusens> doesn't have many miles/km on it yet
[01:56] <marcoceppi> sergiusens: I didn't see anything in snappy playpen, which is where I searched for scons usage
[01:57] <marcoceppi> sergiusens: where's the snapcraft yaml for gpsd?
[01:58] <sergiusens> marcoceppi here's the part definition https://bugs.launchpad.net/snapcraft/+bug/1587289
[01:58] <mup> Bug #1587289: Bad includes generated by snapcraft scons plugin <Snapcraft:Invalid by sergiusens> <https://launchpad.net/bugs/1587289>
[02:02] <marcoceppi> sergiusens: well I got it working eventually, this is what the yaml looks like now
[02:02] <marcoceppi> sergiusens: http://paste.ubuntu.com/23066003/
[02:03] <marcoceppi> sergiusens: this line just feels weird to me
[02:03] <marcoceppi>     scons-options:
[02:03] <marcoceppi>       - --prefix=../install/usr
[02:03] <sergiusens> marcoceppi so your SConstruct does not support using DESTDIR?
[02:03] <marcoceppi> sergiusens: not mine, not sure
[02:04] <sergiusens> does using that --prefix make any assumtions about runtime?
[02:04] <sergiusens> you probably want --prefix=$SNAPCRAFT_PART_INSTALLDIR (not implemented yet)
[02:04] <marcoceppi> sergiusens: so far, does not appear so
[02:04] <marcoceppi> since it works
[02:04] <marcoceppi> sergiusens: I'd love to use a variable like that ;)
[02:05] <marcoceppi> sergiusens: here is there SConstruct file http://paste.ubuntu.com/23066005/
[02:05] <mup> PR snapcraft#737 opened: Release changelog for 2.15 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/737>
[02:06] <marcoceppi> prefix seems to be used only during the installation phase
[02:06] <marcoceppi> (thankfully)
[02:12] <sergiusens> marcoceppi usually code that builds on Windows has location independent code... usually
[02:12] <sergiusens> good luck with that
[02:13] <marcoceppi> sergiusens: well, that must be from when the win32 and SDL code was in the same repo, that's split a while ago but still seems to hold true
[02:13] <marcoceppi> my only problem now is audio with strict confinement, but that seems to be a snappy isue
[02:53] <sergiusens> robert_ancell hey, thanks for updating the PR, there is one minor issue in there still if you don't mind fixing (whitespace between method/function and ())
[02:54] <robert_ancell> sergiusens, fixed, thanks
=== chihchun_afk is now known as chihchun
=== PatrizioQON is now known as pbek
[07:06] <mup> PR snapd#1693 opened: tests: add qemu to our spread.yaml and update README <Created by mvo5> <https://github.com/snapcore/snapd/pull/1693>
[08:21] <zyga> o/
[08:35] <zyga> Son_Goku: hey, didn't you menition that FHS standard is at 3.0 now
[08:35] <Son_Goku> yes
[08:36] <zyga> Son_Goku: I'm looking at http://www.pathname.com/fhs/ and I see 2.3 released in 2004
[08:36] <Son_Goku> https://wiki.linuxfoundation.org/lsb/fhs-30
[08:36] <Son_Goku> it moved to LF
[08:36] <zyga> aha
[08:36] <zyga> thanks
[08:36]  * zyga hates dead pages like that
[08:53] <Son_Goku> zyga: don't we all?
[09:30] <ogra_> sigh
[09:30] <ogra_> so my daily upgrade on 16.04 gets completely stuck in the apparmor postinst
[09:30] <zyga> ogra_: what's up?
[09:30] <zyga> ogra_: anything in syslog?
[09:30] <ogra_> well, it looks for upstart
[09:31] <Son_Goku> :/
[09:31] <Son_Goku> there's so much sad right there
[09:31] <zyga> ogra_: what do you mean specifically?
[09:31] <ogra_> http://paste.ubuntu.com/23066846/
[09:32] <zyga> well, there you have it update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
[09:32] <ogra_> sure
[09:32] <zyga> all postinst scripts are evil
[09:32] <zyga> because they are never perfect
[09:32] <ogra_> zyga, tell that to a million or two of our users who can not upgrade their LTS installs anymore
[09:33] <ogra_> this is a normal 16.04 ... no PPAs or fancy hacks ... just using the daily update-manager run
[09:33] <zyga> ogra_: aha, that's more severe then
[09:33] <seb128> does it hang or just take time?
[09:33] <ogra_> seb128, well, i killed update-manager after 20min the first run ...
[09:33] <Son_Goku> ogra_ this must be what my colleague at work was grumbling about
[09:34] <Son_Goku> it somehow magically worked after apt upgrade twice, the apt-get install -f, then install -f again
[09:34] <seb128> no report of that issue so far, doesn't look like it impact everyone or we would have read more about it
[09:34] <Son_Goku> which makes zero sense
[09:35] <ogra_> (admittedly this machine was upgraded 12.04->14.04->16.04 ... so perhaps something on the way hasnt been cleaned up properly, ut this is my desktop, i dont do any os level changes or hackery on it )
[09:36] <seb128> the box I'm using was upgraded all the way every cycle since 2011
[09:36] <seb128> no such issue
[09:36] <ogra_> every cycle != LTS->LTS
[09:36] <seb128> right
[09:36] <ogra_> so this might be related
[09:36] <seb128> but it's usually enough to stack cruft as well
[09:37] <ogra_> it gets more developer attention :)
[09:37] <seb128> did you get a bt or details about the hanging process?
[09:37] <seb128> seems worth a bug report in any case
[09:37] <ogra_> yeah
[09:42]  * ogra_ filed bug 1614459
[09:42] <mup> Bug #1614459: daily upgrade on 16.04 hangs <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1614459>
[09:42] <ogra_> funnily i cant ctrl-C out of the hanging process
[09:48]  * ogra_ comments the update-rc.d call in the postinst
[09:50] <ogra_> hrm ... loooks like the upstart thing isnt actually the issue ... it still hangs ... just without any error now
[10:02] <zyga> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1367825#c11
[10:02] <Son_Goku> zyga, did you run spectool -g on the specfile first?
[10:03] <Son_Goku> it does work, but you have to download the tarball with the right name
[10:03] <Son_Goku> spectool -g snapd.spec
[10:04] <zyga> yes
[10:04] <zyga> it doesn't work because that url is 404
[10:04] <zyga> ther'es no such thing on github apparently
[10:04] <zyga> Son_Goku: look at https://github.com/snapcore/snapd/releases/tag/2.11
[10:05] <zyga> the tarball URL is https://github.com/snapcore/snapd/archive/2.11.tar.gz
[10:05] <Son_Goku> I tried this: https://github.com/snapcore/snapd/archive/2.11/snapd-2.11.tar.gz
[10:05] <Son_Goku> that worked
[10:07] <zyga> odd, I just ran spectool
[10:07] <zyga> let me check again
[10:07] <zyga> Son_Goku: btw, about directory ownership, did you have something like this on your mind? http://paste.ubuntu.com/23066917/
[10:07] <Son_Goku> yeah
[10:08] <Son_Goku> it essentially mimics how libvirt is set up in /var/lib/libvirt
[10:08] <Son_Goku> in this case, /var/lib/snapd/snaps is where the snaps go
[10:08] <Son_Goku> as opposed to /snap
[10:09] <zyga> Son_Goku: odd, now spectool downloads the file, ...., anyway, let me commit that
[10:09] <zyga> Son_Goku: as for /snap that's a separate issue :-) I'm working on that
[10:10] <zyga> Son_Goku: ok pushed again, have a look
[10:12] <zyga> Son_Goku: essentially right now as of 2.11 that won't work without several major patches, I'm open to the conversation but you already know that :)
[10:14] <zyga> Son_Goku: the %dir entries make rpmbuild choke, those things are only made at runtime, should I just mkdir them in install?
[10:15] <Son_Goku> mkdir and install them
[10:15] <Son_Goku> err, mkdir in %install
[10:15] <zyga> right, tring
[10:15] <zyga> trying*
[10:16] <Son_Goku> as for the directories not working right now without patches, I'm not worried about that at the moment, as you *can* patch it
[10:17] <zyga> Son_Goku: well, the patch'd better be something that upstream can support over time, it's a major change that has to be architected correctly
[10:17] <Son_Goku> yes
[10:17] <zyga> Son_Goku: I don't want to break existing snaps
[10:17] <Son_Goku> but you're upstream :)
[10:17] <Son_Goku> you can also make the legacy packaging migrate the data around as needed
[10:17] <Son_Goku> s/legacy/debian/
[10:17] <zyga> Son_Goku: yes but has to be planned and executed, I'm not a one-man team
[10:18] <Son_Goku> yes
[10:18] <Son_Goku> this was an issue that was brought up at the sprint
[10:18] <zyga> Son_Goku: heh, github just broke
[10:18] <zyga> remote: ruby-jemalloc: symbol lookup error: /data/github/current/vendor/gems/2.1.7/ruby/2.1.0/gems/json-1.8.3/lib/json/ext/generator.so: undefined symbol: rb_data_typed_object_alloc
[10:19] <zyga> I get this on each push
[10:19] <Son_Goku> O.o
[10:19] <Son_Goku> that's...
[10:19] <zyga> I'll just commit and scp to fedorapeople
[10:19] <Son_Goku> yeah
[10:20] <zyga> I guess github is not using snaps ;)
[10:21] <zyga> and they pushed some partial updates
[10:21] <Son_Goku> github does jenkins deploys
[10:21] <Son_Goku> it's very ugly stuff
[10:21] <Son_Goku> I've heard rumors that people describe the codebase as duct tape and silly string
[10:21] <zyga> are they public about about the deploy process?
[10:22] <zyga> I read some cool and nice things about them on their blog
[10:22] <zyga> (~100 deploys a day)
[10:23] <Son_Goku> not really
[10:23] <Son_Goku> they've talked about it at a high level
[10:23] <Son_Goku> but never in detail
[10:37] <zyga> Son_Goku: I've updated snapd to 2.12, no change on /snap yet but I'll do all the things I can today
[10:37] <zyga> (exception request and patches)
[10:38] <Son_Goku> okay
=== hikiko is now known as hikiko|ln
[10:50] <mup> Bug #1614212 changed: Invalid character in ubuntu-core mount name breaks etckeeper <Snappy:New> <https://launchpad.net/bugs/1614212>
[10:57] <mup> PR snapcraft#738 opened: nodjs, gulp plugins: use http_proxy to connect npm registry <Created by m-shibata> <https://github.com/snapcore/snapcraft/pull/738>
=== chihchun is now known as chihchun_afk
[11:08] <mrCyborg> hey! I am heaving a strange issue, when I run `snapcraft snap` I get the following error while it is at the building part: "[Errno 39] Directory not empty: '/home/cyborg/Code/webtorrent-desktop-snap/parts/webtorrent-desktop/install'". content of snapcraft.yaml: https://gist.github.com/nloomans/5d87feb430901a0d1130be9d32bffd9f
[11:20] <mup> PR snapd#1694 opened: tests: adapt to new spread version <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1694>
[11:27] <mup> PR snapd#1695 opened: tests: first iteration on all-snap image tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/1695>
[11:30] <cjwatson> I'm struggling to build my local version of snapd.  Can somebody help?  The instructions in README.md appear to build the code downloaded from GitHub, not my local tree.
[11:31] <cjwatson> Oh, never mind, symlink in the right place under $GOPATH seems to do the trick.
[11:32] <mup> PR snapd#1696 opened: interfaces: add hidraw-device interface <Created by jocave> <https://github.com/snapcore/snapd/pull/1696>
[11:44] <mrCyborg> I've figured out that the problem only exist when I use a stage-package... can anyone help?
=== hikiko|ln is now known as hikiko
[11:53] <ogra_> GAH !
[11:53] <ogra_> so my laptop hangs the same way when updating apparmor
[12:03] <niemeyer> mrCyborg: sergiusens will be online in a short while and should be able to give you a hand
[12:05] <mrCyborg> nieweyer: tnx, I will wait
[12:26] <sergiusens> niemeyer mrCyborg I am online now :-)
[12:26] <ogra_> sergiusens, hmm, how would the macaroon affect logging in ?
[12:26] <sergiusens> oh, you have been hit by a bug
[12:27] <ogra_> do we hack around in pam ?
[12:27] <sergiusens> mrCyborg 2.15 should solve that
[12:27] <sergiusens> ogra_ I totally missed the ubuntu:ubuntu thing!
[12:27] <ogra_> :)
[12:27] <ogra_> smells like image corruption or some such
[12:28] <sergiusens> ogra_ there
[12:28] <ogra_> (though i'm waiting for the version answer ... if thats 16.04 all-snaps it might simply be an experimental image )
[12:28] <sergiusens> ogra_ what about the first user setup that is being put in place?
[12:29] <ogra_> well, we put it in place at image build time ... then cloud-init mangles it on first boot
[12:29] <sergiusens> mrCyborg it is currently making its way into the archives
[12:31] <mrCyborg> <sergiusens>: good to know it's a bug, is there a beta I can test, or is the patch not jet written?
[12:31] <sergiusens> mrCyborg it is being released; do you know how to run from sources?
[12:32] <mrCyborg> yes
[12:32] <sergiusens> mrCyborg or alternatively install the snapcraft deb from https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+build/10630457
[12:33] <sergiusens> mrCyborg if sources is your cup of tee, just make sure master is up to date and run snapcraft from /<path to source>/bin/snapcraft
[12:34] <mrCyborg> sergiusens: I will install the daily form launchpad
[12:35] <jcastro> niemeyer: is the snapcraft list moderated? I fear my message might be stuck in a queue somewhere.
[12:37] <sergiusens> jcastro when I posted with my wrong email I got a reply for it
=== oparoz is now known as Guest51779
=== oparoz_ is now known as oparoz
[12:45] <mrCyborg> sergiusens: It solved that issue, but now I'm getting a bunch of "unable to chown" errors... "unable to chown /home/cyborg/Code/webtorrent-desktop-snap.bak/prime/usr/lib/x86_64-linux-gnu/libXtst.so.6: [Errno 1] Operation not permitted: '/home/cyborg/Code/webtorrent-desktop-snap.bak/prime/usr/lib/x86_64-linux-gnu/libXtst.so.6'", any idea?
[12:46] <sergiusens> mrCyborg does it fail the build or is it just printed out?
[12:47] <mrCyborg> just a warn, the build doesn't fail
[12:47] <sergiusens> mrCyborg great then; those are system imported libs but we do some _link_or_copy smarts to make things go faster
[12:47] <sergiusens> I need to filter out those errors
[12:50] <sergiusens> josepht mind taking care of what mrCyborg mentions?
[12:50] <sergiusens> mrCyborg mind logging a bug against snapcraft against the launchpad project?
[12:52] <mrCyborg> serguisens: About what? I thought this one was fixed? Still heaving some issues tho but I beleve the problem is on my side.
[12:54] <sergiusens> mrCyborg about the messages :-)
[12:55] <mrCyborg> serguisens: oh, sure
[12:58] <mrCyborg> serguisens I think I just found another but tho, dumping an (online) zip doesn't seem to respect file permissions.
=== oparoz is now known as Guest69224
=== oparoz_ is now known as oparoz
[12:58] <josepht> sergiusens: sure, it's just a warning and is expected to fail unless snapcraft is run as root (i.e. for an os snap)
[13:04] <jdstrand> ratliff, tyhicks: fyi, bug #1614459 (ogra saw an oops on two machines)
[13:04] <mup> Bug #1614459: daily upgrade on 16.04 hangs <regression-update> <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1614459>
[13:05] <ogra_> jdstrand, i still have  the update-manager sitting here in hanging state in case anyone needs more info
[13:06] <ratliff> ack jdstrand, thanks
[13:10] <mrCyborg> serguisens: issue submitted!
[13:11] <josepht> mrCyborg: thank you
[13:25] <cwayne> sergiusens: how do i tell the dump plugin where to put the files?
[13:25] <stokachu> cwayne: https://github.com/conjure-up/conjure-up/blob/master/snapcraft/snapcraft.yaml#L59
[13:27] <cwayne> stokachu: thanks
[13:28] <stokachu> np
[13:28] <cwayne> stokachu: do you know if it accepts globs
[13:28] <cwayne> like can i copy everything from launchers/ to bin/
[13:29] <stokachu> cwayne: yea it should
[13:29] <stokachu> filesets do accept globs so it should apply the same here as well
[13:31] <mup> PR snapd#1557 closed: many: introduce an assertstate task handler to fetch snap assertions <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1557>
[13:50] <marcoceppi> so, USB inputs and stuff, what's the TL;DR on that?
=== oparoz_ is now known as oparoz
[13:57] <mup> PR snapcraft#737 closed: Release changelog for 2.15 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/737>
[14:17] <tyhicks> jdstrand, ratliff: see #ubuntu-devel for my response
[14:17] <jdstrand> yep, thanks
[14:17] <jdstrand> tyhicks: I didn't realize you were pinged there. I only saw the reference here
[14:17] <tyhicks> no problem
[14:22] <mup> PR snapd#1697 opened: allow bind() in the network client interface <Created by tych0> <https://github.com/snapcore/snapd/pull/1697>
[14:29] <mup> PR snapd#1695 closed: tests: first iteration on all-snap image tests <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1695>
[14:30] <mup> PR snapcraft#670 closed: Remove .la files generated by autotools <Created by robert-ancell> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/670>
[14:39] <mup> PR snapcraft#739 opened: Only show chown warnings with --debug <Created by josepht> <https://github.com/snapcore/snapcraft/pull/739>
[14:45] <mup> PR snapd#1698 opened: tests: add all-snap spread image tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/1698>
[14:46] <mrCyborg> hey! I was wondering why ~/snap is used for user data, instead of ~/.snap.
[14:52] <mup> PR snapd#1690 closed: partition: ensure that snap_{kernel,core} is not overriden with an empty value <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1690>
[14:54] <Pharaoh_Atem> mrCyborg: dot folders are evil
[14:54] <Pharaoh_Atem> :P
[14:55] <Pharaoh_Atem> zyga: golang(gopkg.in/macaroon.v1) will sync out to the repos as soon as the latest updates mash runs
[14:55] <Pharaoh_Atem> as will snap-confine
[14:56] <zyga> Pharaoh_Atem: I saw
[14:56] <zyga> Pharaoh_Atem: I need to update the golang something mux package, it's slightly out of date it seems
[14:57] <Pharaoh_Atem> gorilla/mux?
[14:59] <Pharaoh_Atem> zyga: like most golang packages that are docker deps, it's maintained by jchaloup
[14:59] <Pharaoh_Atem> you can ask him to update it and to become a comaintainer
[14:59] <Pharaoh_Atem> it might even be a good idea to just ask to become a comaintainer for all snapd deps
[15:15] <jdstrand> niemeyer: hey, would now be an ok time to discuss bug 1611444? I think it can be covered in a short hangout (probably less than 10 minutes)
[15:15] <mup> Bug #1611444: Cannot share a namespace between apps in a SNAP <Snappy:Confirmed> <https://launchpad.net/bugs/1611444>
[15:16] <jdstrand> niemeyer: if not, I can schedule something for later today
[15:16] <zyga> Pharaoh_Atem: yep, that's my plan
[15:16] <niemeyer> jdstrand: It's lunch time, so probably best to schedule it for the afternoon
[15:16] <jdstrand> ah, sorry, sure thing
[15:27] <popey> https://github.com/PowerShell/PowerShell who's up for snapping that :)
[15:32] <marcoceppi> so, USB inputs and stuff, what's the TL;DR on that? does it work is there a plug for it?
[15:33] <popey> marcoceppi: we discussed this here yesterday. it's not fully designed yet, so no, not implemented AIUI
[15:33] <marcoceppi> ta, must have missed it
[15:33] <mup> Bug #1614587 opened: unable to run snap on ubuntu 14.04 (ZOE error) <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1614587>
[15:34] <arges> sergiusens: hi. When I type snapcraft. why does it not rebuild sources if any of the source files have been modified?
[15:35] <arges> i've been working around this by snapcraft clean && snapcraft, but seems like it should detect changes in source (timestamps changed for local source, git commits for remote source)
[15:36] <sergiusens> arges because we have not implemented those smarts yet
[15:36] <sergiusens> it is in the queue
[15:36] <sergiusens> but there are just too many things to do
[15:37] <arges> sergiusens: ok that's cool. Yup understand! it was mostly a question if I should file a bug, or if you had already thought about it
[15:37] <sergiusens> arges already in queue, so no need ;-)
[15:37] <arges> awesome
[15:50] <mup> PR snapd#1699 opened: introduce the "lxd" interface <Created by tych0> <https://github.com/snapcore/snapd/pull/1699>
[16:00] <mup> PR snapd#1700 opened: add mir to implicit for running gui snaps on unity8 classic desktop <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1700>
[16:01] <popey> mhall119: meeting time?
[16:06] <elopio> kyrofa: do we have a desktop client snap for next cloud?
[16:06] <kyrofa> elopio, only the owncloud one right now: https://software.opensuse.org/download/package?project=isv:ownCloud:desktop&package=owncloud-client
[16:33] <sergiusens> kyrofa but you were working on a client, right?
[16:33] <kyrofa> sergiusens, ohh, wow I need to read the complete question
[16:34] <kyrofa> sergiusens, yeah I was working on it, but I put it on hold due to the indicator stuff
[16:37] <mup> PR snapd#1697 opened: allow bind() in the network client interface <Created by tych0> <https://github.com/snapcore/snapd/pull/1697>
[16:38] <mhall119> zyga: if you have a brain-dump for the content-sharing interface you can share with popey and I, we can get started with just that
[16:42] <zyga> mhall119: I'll write my blog post today, just let me get off the call :)
[16:52] <sergiusens> elopio 2.15 is in xenial-proposed; get your chain saw ready ;-)
[16:58] <popey> zyga: thanks
[16:58] <mhall119> thanks zyga
=== JanC is now known as Guest7844
=== JanC_ is now known as JanC
[17:21] <qengho> On all-snaps images, how does that /writable partition work for things in "/etc" ?
[17:36] <mrCyborg> hey! I'm trying to snap a gtk package, but I get the error `Gtk-Message: Failed to load module "overlay-scrollbar"` when trying to run it, to resolve the issue I tried adding `overlay-scrollbar` to `stage-packages`, but that didn't seem to help... any ideas?
[17:42] <qengho> mrCyborg: I do not think that is fatal. Is it working anyway?
[17:46] <mrCyborg> qengho: It is fatal, that wasn't the only package missing, it was just an example
[17:48] <mrCyborg> qengho: It fails to load overlay-scrollbar, gail, atk-bridge, unity-gtk-module, and canberra-gtk-module.
[17:49] <qengho> mrCyborg: what is your "command" in YAML?
[17:51] <mrCyborg> qengho: gist: https://gist.github.com/nloomans/5d87feb430901a0d1130be9d32bffd9f
[17:55] <mup> PR snapcraft#739 closed: Only show chown warnings with --debug <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/739>
[17:57] <qengho> mrCyborg: Ah, thx. I think you should use the wrapper that sets up the environment for gtk2 apps. In parts, webtorrent-desktop, add  after: [ desktop/gtk2 ]  and change your command to  command: desktop-launcher $SNAP/WebTorrent
[18:03] <mrCyborg> qengho: tnx for the help, but now I get the flowing error: "The specified command 'desktop-launcher' defined in the app 'webtorrent-desktop' does not exist or is not executable"
[18:04] <qengho> Sorry. `desktop-launch`
[18:08] <mvo> ogra_: hey, the fix for the upgrade problem has landed, let me create new images for you so that we can verify it
[18:09] <qengho> Who's in charge of the parts yaml on the web?
[18:15] <mrCyborg> qengho: Thanks a lot, that works now! I really should have asked for help earlier...
[18:25] <qengho> mrCyborg: welcome!
[18:37] <elopio> sergiusens: ack. I'll test after lunch.
[18:37] <mup> PR snapcraft#740 opened: Allow debugging cleanbuild runs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/740>
[19:05] <ahoneybun> mm
[19:05] <ahoneybun> 'no mobule 'gi'
[19:08] <qengho> There's a lot wrong there.
[19:11] <ahoneybun> XD
[19:28] <om26er> Hi! I am not able to apt-get anything on all-snaps latest in classic mode, it gives me: cat: standard output: Permission denied
[19:33] <om26er> actually sudo classic.create gives me:
[19:33] <om26er> chroot: failed to run command ‘/var/lib/classic/enable.sh’: No such file or directory
[19:34] <om26er> ogra_, ^
[19:38] <qengho> The images are the big bad ignored part of snappy. There's no build system. There's no bug tracker. It's untethered to any kind of quality control.
[19:39] <qengho> We should be saying "We have no images", instead of hoping these ad-hoc ones are good enough.
[20:03] <mup> PR snapd#1681 closed: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1681>
[20:04] <kyrofa> qengho, we aren't hoping that. The all-snap images aren't done yet, these are pre-releases
[20:06] <kyrofa> qengho, also, they are indeed tethered to a QA process, but perhaps that could be more transparent
[20:06] <qengho> kyrofa: I'm not saying they should be good enough for release. I'm saying they're not good enough for testing. I emailed my own "bug report" yesterday, into the void.
[20:07] <kyrofa> Which void?
[20:07] <qengho> I
[20:08] <qengho> I'm not picking on him, but the owner of the personal file I used to flash.
[20:08] <qengho> http://people.canonical.com/~mvo/all-snaps/16/all-snaps-pi2.img.xz
[20:09] <kyrofa> Where was that announced as being available?
[20:10] <qengho> I asked here, "What should I be installing on my rpi3"?
[20:13] <qengho> kyrofa: if you know of daily builds and a bug tracker, I would be happy to know of it.
[20:16] <mup> PR snapcraft#741 opened: Make it easy to setup a pre-commit hook <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/741>
[20:16] <qengho> kyrofa: In any case, I'm not new to this. It's om2`6er of 45 minutes ago who has a new bug to report.
[20:17] <qengho> I don't know where to send himher.
[20:18] <kyrofa> qengho, mvo has made those just for testing purposes. They are unofficial. Until they are, all you can really do is talk to mvo (and maybe ogra_)
[20:31] <mup> PR snapcraft#742 opened: Handle missing source type packages in the parser <Created by josepht> <https://github.com/snapcore/snapcraft/pull/742>
=== beisner is now known as beisner-biab
[21:27] <mup> Bug #1614730 opened: dpkg: dependency problems prevent configuration of snapd -  snapd depends on ubuntu-core-launcher (>= 1.0.23) <oil> <Snappy:New> <https://launchpad.net/bugs/1614730>
=== beisner-biab is now known as beisner