[00:00] <mcclaw> good evening
[00:33] <mup> Bug #1639984 opened: Granting incorrect access in the shutdown interface in snapd <Snappy:New> <https://launchpad.net/bugs/1639984>
[01:03] <mup> Bug #1639988 opened: Snaps using libappindicator and unity7 plug can't show app-indicators <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1639988>
[01:03] <Trevinho> jdstrand: here it is ^
[02:37] <elfgoh> I wish to install Ubuntu Core on Beaglebone black.
[02:37] <elfgoh> I do see the beagleblack gadget snap but am unsure how to proceed
[02:37] <elfgoh> Is there some documentation that I can refer to? I am looking at Ubuntu Core 16
[02:42] <elfgoh> Most of my search results fished up earlier Ubuntu core versions, which I wasnt sure if they are relevant
[03:00] <elfgoh> Hi there, I am trying to install Ubuntu Core 16 on the Beaglebone black. Is this the right place to seek help? I cant seem to find the documentation on how to utilise the beragleblack gadget snap
[03:06] <elfgoh> Will be grateful if someone can point me to the relevant documentation
[04:14] <Tungilik> Hi, where could I find a Ubuntu Music Player snap, or really a bunch of offical dev desktop snaps from Unity 8?
[05:08] <elfgoh> test
[06:37] <mwhudson> ogra_: when does http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ get updated? the current images seem to be ~48 hours old
[07:02] <didrocks> Mirv: good morning! Did you get what I was asking about yesterday?
[07:08] <foxmask> bonjello
[07:23] <Mirv> didrocks: fix import path, fix test, but what's missing on the content side? so yes, ubuntu-app-platform/ is exported, and under it are the libraries
[07:24] <didrocks> Mirv: the read: parameter is relative to your snap
[07:24] <Mirv> and they are organized so that they include etc, usr/bin, usr/lib and three usr/share folders
[07:24] <didrocks> so you want to export your snap directory
[07:24] <didrocks> meaning .
[07:25] <didrocks> Mirv: http://paste.ubuntu.com/23445443/
[07:25] <didrocks> this is your snap directory
[07:25] <didrocks> there are 2 things:
[07:25] <didrocks> 1. you have an ubuntu-app-platform subdirectory containing etc/ and usr/
[07:25] <didrocks> I don't think you wanted that
[07:25] <Mirv> didrocks: well I didn't want, I might want :) I'm explicitly moving the certain staged files to be under ubuntu-app-platform/ (see bottom of https://git.launchpad.net/ubuntu-app-platform/tree/snapcraft.yaml )
[07:25] <didrocks> 2. and in /snap/ubuntu-app-platform/current/meta/snap.yaml you have:
[07:25] <didrocks>     read:
[07:25] <didrocks>     - ubuntu-app-platform
[07:26] <didrocks> so, you are only exporting ubnutu-app-platform subdir from your snap
[07:26] <Mirv> yes, the idea was that they don't mix with the app snap
[07:26] <Mirv> ubuntu-app-platform subdir has all the content needed
[07:26] <didrocks> right, but here, read is the path that you are exporting
[07:26] <didrocks> see, I'm only talking about your platform snap here
[07:27] <didrocks> read: specify the path you are exporting
[07:27] <didrocks> not where it's going to be mounted
[07:27] <didrocks> this is independnat
[07:27] <didrocks> what you want to export is the root of your platform snap
[07:27] <didrocks> then, this root directory will be mounted inside ubuntu-app-platform of your destination snap (the app snap)
[07:28] <didrocks> so, in a nutshell:
[07:28] <Mirv> so, is that like "it'd be nice to export the root of your platform snap" or "it's required"? I mean, since the files are organized so that only the required files are moved to be under the ubuntu-app-platform subdir of the platform snap
[07:28] <didrocks> - change read: ubuntu-app-platform to read: "."
[07:28] <didrocks> well
[07:28] <didrocks> what's the goal of your root ubuntu-app-platform directory then?
[07:28] <Mirv> didrocks: it's not about that I'm trying to decide the mount place on the slot side, but I'm trying to organize only needed files to be exported
[07:28] <didrocks> it will never be accessible to anything
[07:29] <didrocks> in that case, remove the files you don't want to be exported
[07:29] <Mirv> didrocks: it works for the test app and I can see the files in the correct places so that the launcher works
[07:29] <didrocks> but stil export the whole content
[07:29] <didrocks> I'm sure you didn't install the latest version your posted yesterday
[07:29] <didrocks> ubuntu-app-platform/ subdir only have etc/ and usr/
[07:30] <didrocks> no lib/ and such?
[07:30] <Mirv> yes, that was intended, that was what works (before integration to the desktop-helpers)
[07:30] <Mirv> lib/ doesn't seem to be needed, so I omitted it
[07:30] <Mirv> I tried to slim down everything as long as the app run
[07:30] <Mirv> (and when I'm talking about app running, I'm talking about my test app with custom launcher and not yet with the desktop helper)
[07:31] <didrocks> Mirv: ok, so if you really want to slim that down, instead of moving the content, why don't remove those files?
[07:31] <didrocks> Mirv: and export the root directory
[07:31] <Mirv> didrocks: the most obvious newbie answer is I didn't know how to :)
[07:31] <didrocks> otherwise, you are installing unused files for everyone one to install :)
[07:31] <didrocks> Mirv: oh ok, let's try to do that then!
[07:31] <didrocks> I'll dig further on why the current setup doesn't work then
[07:32] <didrocks> Mirv: so, you can create a part
[07:32] <didrocks> or even better
[07:32] <didrocks> instead of using organize
[07:32] <didrocks> use snap: []
[07:32] <didrocks> this will only snap the content your are refering
[07:32] <didrocks> http://snapcraft.io/docs/build-snaps/syntax
[07:32] <didrocks> snap (list of strings) A list of files from a part’s installation to expose in snap. Rules applying to the list here are the same as those of filesets. Referencing of fileset keys is done with a $ prefixing the fileset key, which will expand with the value of such key.
[07:33] <didrocks> Mirv: there is still an issue making it not accessing the right lib, I'm going to look at this then in 10 minutes
[07:33] <Mirv> didrocks: ok, I'll change from organize to snap directly then!
[07:33] <Mirv> thanks!
[07:34] <didrocks> yw! (and then export .)
[07:37] <Mirv> yes
[07:39] <arnav> join /help
[07:39] <arnav> help!
[07:39] <arnav> I can't login on my ubuntu core OS
[07:39] <arnav> I don't know what's the password
[07:39] <arnav> either way I can't ssh
[07:40] <arnav> I can't login on my ubuntu core OS
[07:40] <arnav> I don't know what's the password
[07:40] <arnav> either way I can't ssh
[07:40] <arnav> Is anyone there?????
[07:40] <arnav> I am panicking
[07:40] <arnav> HELP!!!!!!!!!!!!!!!!!!!!!!
[07:41] <arnav> Hello>
[07:41] <arnav> is anyone there>?
[07:42] <didrocks> arnav: insisting like that won't help people wanting to help you
[07:42] <didrocks> 1. this is IRC, it's mostly async
[07:42] <didrocks> so people answer when they are around
[07:42] <didrocks> and if they can
[07:42] <arnav> But I am panicking
[07:42] <didrocks> 2. this is not a support channel, and when asking for help, please be respectful and quiet
[07:42] <didrocks> why are you panicking? You are just testing it
[07:42] <arnav> I am sorry
[07:42] <didrocks> it's not a production machine
[07:42] <didrocks> so, please avoid multiple ? and !
[07:43] <didrocks> (and capital letters)
[07:43] <didrocks> on your question, you should first read the documentation
[07:43] <didrocks> you would have seen there that you need to create an account on the machine
[07:43] <arnav> I just setup my ubuntu core 16 on my raspberry pi
[07:43] <didrocks> did you plug a screen to it and a keyboard, then create an account?
[07:43] <arnav> now I can't ssh even though I have the correct key
[07:43] <arnav> yes
[07:44] <didrocks> ok, with that screen/keyboard, can you log in?
[07:44] <didrocks> (as it's just on the rpi2 directly, so user name and password)
[07:44] <arnav> No, that's the problem I don't know the login
[07:45] <didrocks> are you sure you are using the right login name associated with your ubuntu SSO account?
[07:45] <arnav> I tried the default ubuntu login, all my passwords
[07:45] <arnav> Yes
[07:45] <didrocks> and you have your ssh private ssh key on the machine you run ssh from?
[07:46] <arnav> Yes
[07:46] <didrocks> you should try ssh -vvv <> and pastebin the result
[07:46] <didrocks> we'll see if at least it's trying the ssh key
[07:46] <arnav> Ok just a minute please
[07:47] <arnav> so I should enter the ip address in the angular brackets?
[07:47] <didrocks> your username@ip
[07:48] <arnav> It's saying syntax error
[07:48] <didrocks> what did you try to type?
[07:48] <arnav> ssh -vvv <arnav.aghav@192.168.0.4>
[07:48] <didrocks> you don't use the <>, it was to be replaced
[07:48] <arnav> oh
[07:49] <arnav> sorry
[07:49] <didrocks> no worry
[07:49] <arnav> it's still asking me password and too many lines of result
[07:50] <didrocks> so, it means it couldn't match the ssh key
[07:50] <arnav> I am pasting it on pastebin
[07:50] <didrocks> yeah
[07:51] <arnav> http://pastebin.com/TsS1cxqu
[07:53] <didrocks> so, it did try 2 keys
[07:53] <didrocks> (private ssh keys)
[07:53] <didrocks> debug1: Offering RSA public key: /Users/aghav/.ssh/github_rsa
[07:53] <arnav> hmm
[07:53] <didrocks> debug1: Offering RSA public key: /Users/aghav/.ssh/id_rsa
[07:53] <didrocks> those were rejected, not matchin the one on the machine
[07:53] <arnav> so should re-setup it?
[07:53] <didrocks> you also have 2 others on your machine, but removed the file:
[07:53] <didrocks> debug3: no such identity: /Users/aghav/.ssh/id_ecdsa: No such file or directory
[07:53] <didrocks> debug3: no such identity: /Users/aghav/.ssh/id_ed25519: No such file or directory
[07:54] <didrocks> I would say, there are 2 cases:
[07:54] <didrocks> - either you didn't associate a public ssh key with your ubuntu sso account (or not the correct one)
[07:54] <didrocks> - either your username in ubuntu sso isn't arnav.aghav
[07:54] <arnav> mostly the first one
[07:54] <didrocks> that would be the 2 reasons it couldn't match them
[07:54] <didrocks> yeah, so, ensure you associate a key there
[07:55] <didrocks> and then, resetup the board
[07:55] <arnav> ok, thanks for the help! Sorry for my behaviour
[07:55] <didrocks> no worry! happy to help :)
[08:01] <didrocks> Mirv: I wonder how to define correctly qmlscene so that apps don't have to define it
[08:01] <Mirv> didrocks: meanwhile I noticed you fixed about two billion things in the desktop helpers... a humble thank you!
[08:01] <didrocks> because your runtime is not only for qml apps, right, it could be used for QT/C++ one
[08:01] <didrocks> Mirv: yw! :)
[08:01] <didrocks> because defining something like that would be great:
[08:01] <didrocks>         command: desktop-launch $SNAP_LAUNCHER_QMLSCENE --desktop_file_hint=unity8 $SNAP/usr/share/calendar-app/calendar.qml
[08:02] <didrocks> but $SNAP_LAUNCHER_QMLSCENE would be defined in desktop-launch
[08:02] <didrocks> oh I know, what about adding qmlscene to $PATH in desktop-launch?
[08:02] <Mirv> right, the test app I had did have C++ plugin but was qml app in essence
[08:02] <didrocks> then, people can set:
[08:03] <didrocks> command: desktop-launch qmlscene --desktop …
[08:05] <didrocks> no, same, that won't work, as $PATH will be resolved before calling desktop-launch
[08:06] <Mirv> shouldn't the qtchooser be operational as it has the config pointing to the ubuntu-app-platform too?
[08:07] <Mirv> if it would work like I thought it would, qmlscene would already be in path
[08:08] <didrocks> it's not… we can maybe add ubuntu-app-platform/usr/bin/qmlscene to PATH?
[08:09] <didrocks> Mirv: oh, it's a symlink?
[08:09] <didrocks> my PATH:
[08:09] <didrocks> /snap/ubuntu-calendar-app/x1/ubuntu-app-platform/usr/bin/:/snap/ubuntu-calendar-app/x1/usr/sbin:/snap/ubuntu-calendar-app/x1/usr/bin:/snap/ubuntu-calendar-app/x1/sbin:/snap/ubuntu-calendar-app/x1/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[08:10] <didrocks> + exec qmlscene --desktop_file_hint=unity8 /snap/ubuntu-calendar-app/x1/usr/share/calendar-app/calendar.qml
[08:10] <didrocks> qmlscene: could not exec './ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene': No such file or directory
[08:10] <didrocks> it seems that qmlscene tries to reach out ./ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene -> fails due to relative path?
[08:12] <didrocks> I don't know why, but it seems it's due to the qtchooser (it did work though for qt5 itself…)
[08:12] <Mirv> didrocks: ah.. the others were relative in the Makefile too, so I assumed it'd work
[08:12] <didrocks> Mirv: any idea? (let me push latest changesmeanwhile)
[08:12] <didrocks> yeah
[08:13] <didrocks> unsure we did test with qml apps though. I think the SDK team did
[08:13] <didrocks> Mirv: should I just bypass the qtchooser thing for now?
[08:14] <didrocks> if I do so, I'm getting + exec qmlscene --desktop_file_hint=unity8 /snap/ubuntu-calendar-app/x1/usr/share/calendar-app/calendar.qml
[08:14] <didrocks> qmlscene: error while loading shared libraries: libQt5Quick.so.5: cannot open shared object file: No such file or directory
[08:14] <Mirv> I wonder if it's somehow because the ubuntu-app-platform also has qtchooser in it
[08:14] <didrocks> so I guess it's because the other paths you set
[08:15] <didrocks> ah…
[08:15] <didrocks> could be
[08:15] <Mirv> I'll remove that from the next build
[08:15] <didrocks> so wrong qtchooser taking wrong config?
[08:15] <didrocks> what are you going to remove?
[08:15] <Mirv> well that's first in PATH, it's the wrong qtchooser at least, even though it sounds it's taking right config
[08:15] <Mirv> the qtchooser package from the staged packages in ubuntu-app-platform
[08:15] <didrocks> Mirv: hum, I think it's because if you set it, no?
[08:15] <Mirv> or well, hmm, maybe that's actually the right place to have it after all
[08:16] <didrocks> I guess it is
[08:16] <didrocks> I can add it to PATH
[08:16] <didrocks> but that doesn't fix things (and I don't know enough how it works to fix it)
[08:16] <didrocks> do you want me to push it so that you can debug?
[08:16] <Mirv> didrocks: yes, thank you
[08:18] <Mirv> ah, I see typos..
[08:18] <didrocks> Mirv: pushed
[08:18] <didrocks> oh?
[08:18] <didrocks> Mirv: here are the changes I've done to ubuntu-calendar-app: http://paste.ubuntu.com/23445545/
[08:18] <didrocks> (removing the wrapper and changed FLAVOR and such)
[08:20] <arnav> hey, I just reinstalled the OS, deleted all my keys and set a new one still asking me password
[08:21] <didrocks> arnav: maybe check with the SSO team (like nessita this afternoon) if you have a good user/password match?
[08:21] <didrocks> I'm pretty sure the issue is either the username not being the correct one or the ssh key public/private match
[08:21] <didrocks> she would be able to confirm you those
[08:22] <arnav> how can I contact them?
[08:22] <didrocks> just here
[08:22] <didrocks> but this afternoon
[08:22] <didrocks> (mid afternoon, I would say)
[08:22] <didrocks> (european time)
[08:22] <arnav> I live in India so I don't know the timezone
[08:22] <arnav> oh
[08:23] <didrocks> ah, yeah, so will be quite late for you :)
[08:23] <didrocks> I don't know if there is any contact page on ubuntu SSO?
[08:23] <Mirv> didrocks: there's no such thing as /usr/lib/$ARCH/qt5/libs - should I do pull request like http://paste.ubuntu.com/23445556/ or is the $SNAP/usr/lib/$ARCH/ already in default paths and not needed? but the Qt libraries in the shared snap are at $SNAP/ubuntu-app-platform/usr/lib/$ARCH/
[08:23] <Mirv> didrocks: ok I haven't used the calendar-app but I'll do changes to the timostestapp3
[08:23] <Mirv> didrocks: for launcher, what's known to work is https://github.com/tjyrinki/timostestapp3/blob/master/launcher
[08:24] <didrocks> Mirv: oh good catch! let me try
[08:24] <didrocks> Mirv: but you are hardcoding the qmlscene path for this
[08:24] <didrocks> maybe I can thus add $SNAP/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/bin/ to PATH (with $ARCH)
[08:25] <didrocks> and bypass thus qtchooser as you do
[08:25] <didrocks> wdyt?
[08:26] <didrocks> Mirv: hum, even with that, it doesn't want to open the shared lib
[08:26] <didrocks> ah ok, it's in /snap/ubuntu-calendar-app/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
[08:27] <Mirv> yeah I didn't have qtchooser configuration for the test app
[08:27] <didrocks> and you didn't add it to the qtappplatform chooser
[08:27] <didrocks> ok, let me fix that
[08:27] <didrocks> une sec
[08:27] <didrocks> one*
[08:28] <Mirv> the chooser's library path already is ./ubuntu-app-platform/usr/lib/$(arch_triplet) which should be correct
[08:28] <didrocks> but not libgl1
[08:28] <didrocks> there are more path when you need to add ubuntu-app-platform
[08:29] <Mirv> right, that's needed
[08:29] <Mirv> useful to compare those launchers side by side
[08:30] <Mirv> I wonder if also the LIBGL_DRIVERS_PATH and XKB_CONFIG_ROOT should be likewise defined here like in my launcher
[08:31] <didrocks> Mirv: I would going to add them, do you mind checking you are exporting them?
[08:31] <didrocks> in your platform snap
[08:31] <didrocks> (export -> having libs there)
[08:32] <Mirv> didrocks: yes, they are (my test app doesn't have them in its snap at all, but it runs). ok adding those too to the pull request.
[08:32] <didrocks> Mirv: I'm preparing one and iterating, don't worry
[08:33] <Mirv> the test app is 10MB that mostly because of just one unneeded library that I don't know how it ended up still in there, but it doesn't have most libraries
[08:33] <Mirv> didrocks: ok!
[08:33] <didrocks> ok, and so, now core dump
[08:33] <didrocks> but at least, the app tries to start :)
[08:33] <didrocks> (process:13443): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
[08:33] <didrocks> I wonder where the schemas are installed
[08:39] <didrocks> Mirv: ok, pushed my changes
[08:39] <didrocks> now, the only remaining issue is this core dump, let me check if gsettings compiled or not
[08:45] <didrocks> ok, the schema compilation issue is that there is no xml gsettings schema shipped with the app
[08:45] <didrocks> renato__: hey, this one will be for you ^
[08:45] <didrocks> (or if you are using schemas that should be shipped with the base system, ping Mirv ;))
[08:46] <didrocks> Mirv: oh, it seems as we did push similar fixes that there are some conflicts
[08:46] <didrocks> Mirv: but you still have some good addition I don't have, do you mind rebasing?
[08:52] <Mirv> didrocks: ok this diff now has the remaining things I was doing in my custom launcher https://github.com/ubuntu/snapcraft-desktop-helpers/pull/19/files
[08:52] <mup> PR ubuntu/snapcraft-desktop-helpers#19: Fix various environment variables to point to the platform snap directories <Created by tjyrinki> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/19>
[08:52] <didrocks> Mirv: already merged :)
[08:53] <didrocks> Mirv: so, the remaining issue is gsettings schema error
[08:53] <didrocks> it doesn't compile anything because there is no xml shipped
[08:53] <Mirv> didrocks: wow, that was fast :D
[08:53] <didrocks> heh ;)
[08:53] <didrocks> and the app (or qt) is using them
[08:53] <didrocks> (hence the segfault at runtime)
[08:53] <didrocks> I guess it's up to renato__ to see what gsettings schema he's using and ship them with the files
[08:54] <didrocks> or probably that's part of e-d-s
[09:13] <Mirv> using the snap: to try to include /usr/bin (or /usr/bin/*), I get "[Errno 21] Is a directory: '/home/ubuntu/qt-ubuntu/prime/usr/bin/X11'", as if the * wouldn't like subdirectories.. hmm
[09:15] <elfgoh> Hey has anyone tried the image by @ogra_? http://people.canonical.com/~ogra/snappy/all-snaps/stable/current/ubuntu-core-16-beaglebone.img.xz
[10:14] <Mirv> doh, that X11 is a symlink to "."
[10:15] <Mirv> might be a bug to error out on that? meanwhile I probably need more fine-grained usr/bin snap: directives
[10:15] <Mirv> didrocks: the subdir idea might have actually come originally from bumping into that error, I'm not sure. at the sprint I just tried to get a demo working :)
[10:16] <Mirv> but I also might simply have found about organize: before snap:
[10:16] <didrocks> Mirv: could be :) but yeah, I really think you should have a platform snap only shipping what's needed
[10:16] <didrocks> you can get to the same result with snap: than organize (or even combine both
[10:16] <didrocks> )
[10:17] <Son_Goku> sergiusens: ping
[10:21] <mup> Bug #1640114 opened: configure hook output not accessible <Snappy:New> <https://launchpad.net/bugs/1640114>
[10:51] <jdstrand> Trevinho: ack
[11:09] <Mirv> organize didn't have problem with that symlink though
[11:11] <Arnav> Hello, can someone help me?
[11:15] <ogra_> mwhudson, there are timestamps (in UTC) on the files ;)
[11:17] <ogra_> mwhudson, the cronjob kicks in at 7:30 UTC ... if you need it more often i can make it twice or three times per day
[12:00] <renato__> Mirv, didrocks, good morning. Let me read the backlog
[12:04] <Mirv> renato__: do that :) also fetch latest ubuntu-app-platform snap from https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform
[12:11] <Mirv> I can confirm that still with my custom launcher test app the newest platform snap works (that has the changes didier requested). I'm still battling with changing my test app to use cloud part instead.
[12:16] <Mirv> for one I can't figure out how the empty ubuntu-app-platform directory (to mount the shared snap to, since the mount point seems to be required to be created at this point) is not being included anymore while the _only_ changes are http://paste.ubuntu.com/23446194/ which do not touch the organize: part that has the ubuntu-app-platform/*
[12:16] <Mirv> so with that modification I just get cannot mount /snap/ubuntu-app-platform/x1 at /snap/timostestapp3/x1/ubuntu-app-platform with options bind,ro. errmsg: No such file or directory
[12:17] <Mirv> if I revert that diff and use the normal launcher, it works
[12:19] <Mirv> anyway, the latest shared snap now has this https://git.launchpad.net/ubuntu-app-platform/commit/?id=cd5f400599c83241ba6d6913246d6dcc84c4bc40
[12:20] <didrocks> Mirv: well, with my launcher, it's working as well, right?
[12:20] <didrocks> please try using that one now :)
[12:22] <didrocks> Mirv: maybe replace / instead of .
[12:22] <Mirv> didrocks: the pastebin changes http://paste.ubuntu.com/23446194/ I try to switch to the cloud part launcher, but like I said the mount does not work
[12:22] <didrocks> Mirv: well, the cloud part launcher isn't guilty for that part, those are orthogonal issues ;)
[12:22] <didrocks> Mirv: look at my comment on / vs .
[12:23] <Mirv> didrocks: the shared snap seems good (unless there is other reason to use / instead of .). it does get mounted if I use my test app without that diff that changes unrelated parts, that's the weird thing - the mount dir disappears.
[12:23] <didrocks> Mirv: your pastebin refers twice qmlscene btw
[12:23] <didrocks> command: desktop-launch qmlscene --desktop_file_hint=unity8 "$SNAP/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene" "$SNAP/qtapp2/Main.qml"
[12:23] <didrocks> I guess you want:
[12:23] <didrocks> command: desktop-launch qmlscene --desktop_file_hint=unity8 "$SNAP/qtapp2/Main.qml"
[12:23] <Mirv> ah, yes, I'd have noticed it if it would try to start
[12:24] <didrocks> Mirv: are you sure the shared snap is mounted properly?
[12:24] <didrocks> "disappearing" sounds weird
[12:25] <Mirv> didrocks: the error is the trying to mount "I just get cannot mount /snap/ubuntu-app-platform/x1 at  /snap/timostestapp3/x1/ubuntu-app-platform with options bind,ro. errmsg: No such file or directory" - and the reason is that after that pastebin diff, for some reason the ubuntu-app-platform I'm trying to include my app snap isn't anymore included, so the mount point is not there
[12:25] <Mirv> didrocks: so what disappears is from the app side, even though nothing there is being changed
[12:25] <didrocks> Mirv: why do you say then "the shared snap seems good"
[12:25] <didrocks> it's apparently not
[12:25] <didrocks> hence my suggestion to replace . by /
[12:26] <didrocks> which I think is the expected syntax
[12:26] <didrocks> (for exporting the "root" of the snap)
[12:26] <Mirv> didrocks: because, like I said, it works with my test app if I just don't try to change it to use cloud part
[12:27] <Mirv> and if I go into with --shell, the mount content also looks correct inside the app
[12:27] <didrocks> Mirv: that's weird, it's definitively working well here, the mount point doesn't "disappear"
[12:27] <Mirv> I don't say there's anything wrong with the cloud part, it's that the directory that would need to be created on the app side is not created anymore for some weird reason
[12:28] <Mirv> didrocks: regardless, do you confirm that on the app side, the app should currently have the directory ubuntu-app-platform included in its snap so that the mount works?
[12:28] <Mirv> just to get that detail right
[12:28] <didrocks> Mirv: yeah, an empty directory to create a mountpoint
[12:28] <Mirv> yep
[12:28] <didrocks> (you need a target for the bindmount to work and $SNAP is ro, so you can't create one dynamically)
[12:29] <Mirv> so I believe the shared snap works (since it does), I just have bad snap luck with my test app
[12:29] <didrocks> could be
[12:29] <Mirv> I should probably start over with new test app anyway
[12:29] <didrocks> yeah, maybe some leftover…
[12:56] <renato__> Mirv, hey could you send me the list of "deb" packages that are present on your content share snappy?
[13:07] <renato__> Mirv, didrocks, what I need to update to test the calendar app? I tried create a new package and installed the Mirv package but I still getting:
[13:07] <renato__> http://paste.ubuntu.com/23446392/
[13:09] <Mirv> renato__: list of packages http://pastebin.ubuntu.com/23446399/ though note only if the files are on certain paths like usr/lib
[13:09] <Mirv> renato__: sounds like you haven't pulled the latest snapcraft-desktop-helpers commits
[13:09] <Mirv> renato__: plus you could now use the cloud part directly instead of locally
[13:10] <renato__> Mirv, do you mean that I do not need this : http://paste.ubuntu.com/23446402/
[13:11] <renato__> Mirv, since you are installing "evolution-data-server-common" could you add the schema files present in "/usr/share/glib-2.0/schemas/"
[13:12] <stgraber> ogra_: ubuntu core question for you, is there some way to figure out what version of the core snap I'm running from looking at the filesystem? Looking at snap list shows me what was last downloaded but that isn't necessarily what I'm running?
[13:13] <Mirv> renato__: right, just the after clause for your own part. or you could fix the FLAVOR, see the latest commits in the desktop-helpers git
[13:13] <Mirv> renato__: ok, adding
[13:13] <ogra_> stgraber, you could check the "current" link in /snap/core/
[13:14] <ogra_> stgraber, and the kernel cmdline has the version in the snap_core variable ... if you want to look at a lower level
[13:14] <didrocks> renato__: sorry, got disconnected, what are you getting?
[13:15] <didrocks> did you apply the patch I pastebined above?
[13:15] <didrocks> http://paste.ubuntu.com/23446423/
[13:15] <stgraber> ogra_: cool, will look at the symlink
[13:15] <stgraber> ogra_: kernel cmdline is meaningless since I'm running ubuntu core in a container :)
[13:15] <ogra_> ah
[13:15] <didrocks> renato__: then, you should get the gsetting schema core dump, and you have to include the schema files you are using
[13:15] <renato__> didrocks, hye, Mirv told me to use the cloud part instead of local one.
[13:15] <didrocks> yep
[13:15] <renato__> didrocks, I talked with Mirv about that:
[13:16] <didrocks> renato__: sorry, the pastebin is http://paste.ubuntu.com/23446429/
[13:16] <didrocks> (I was pointing to my local launcher)
[13:17] <Mirv> renato__: ah, ok, easier if you just use didier's diff
[13:17] <renato__> didrocks, this is the log: http://paste.ubuntu.com/23446431/
[13:17] <Mirv> renato__: updated .snap with the schema files included will be later at https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/9435
[13:17] <renato__> didrocks, in resume Mirv will add "/usr/share/glib-2.0/schemas/" into the snappy package
[13:18] <renato__> Mirv, thanks
[13:18] <didrocks> renato__: sounds good, but maybe if you are using schemas yourself from your app, you should include the ones you are using
[13:18] <didrocks> (not in platform, but in your app)
[13:19] <renato__> didrocks, yes I agree but the the schemas that I am using is not from my app.
[13:19] <didrocks> so yeah, makes sense for them to be in the platform snap
[13:24] <renato__> didrocks, Can I keep my url here?
[13:24] <renato__> -        source: https://github.com/ubuntu/snapcraft-desktop-helpers.git
[13:24] <renato__> +        source: /home/didrocks/work/ubuntu-core/snapcraft-desktop-helpers
[13:24] <didrocks> renato__: yeah, please do (that was the diff with the last pastebin I gave you)
[13:24] <didrocks> it was a way for me to test without git push :)
[13:30] <renato__> didrocks, Mirv, thanks, is launching the app now. Just wait for the schema to land to see if that fix the startup crash
[13:33] <didrocks> great that we are on the same page! :)
[13:36] <renato__> didrocks, still saying no schema files found. Do we need to build it? like the gtk-launcher does?
[13:37] <didrocks> renato__: what did you do?
[13:37] <didrocks> the launcher is building them at each upgrade
[13:37] <didrocks> or install
[13:37] <didrocks> (so only the first time)
[13:38] <renato__> didrocks, I installed the new Mirv package, and tried to rum the app
[13:38] <ogra_> there is a Mirv package ?
[13:38] <didrocks> without reinstalling yours?
[13:38]  * ogra_ wants that too !
[13:38] <ogra_> a Mirv for everyone ... easily installable !
[13:38] <didrocks> renato__: so yeah, you should remove/reainstall your app
[13:38] <didrocks> first run is doing the compilation
[13:38] <renato__> didrocks, I did a shell command, and I can confirm that schemas are there: /snap/ubuntu-calendar-app/x1/ubuntu-app-platform/usr/share/glib-2.0/schemas
[13:39] <renato__> didrocks, I did that
[13:39] <renato__> didrocks, let me try again
[13:39] <renato__> didrocks, same.
[13:40] <didrocks> hum, weird, definitively working on traditional apps for me
[13:40] <didrocks> can you send me the additional packages that were stage?
[13:40] <didrocks> staged
[13:41] <renato__> didrocks, I do not have any package staged
[13:41] <didrocks> for the schemas?
[13:41] <didrocks> how can I reproduce your setup?
[13:41] <didrocks> ah, it's only the the app platform
[13:41] <renato__> didrocks, just use the latested mirv package. https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/9435
[13:41] <didrocks> can I get the new snap?
[13:41] <didrocks> good
[13:42] <didrocks> renato__: trying on my side
[13:42] <renato__> thanks
[13:42] <didrocks> so, no schemas are compiled at all, you say?
[13:42] <renato__> looks like that. How I can confirm it?
[13:47] <didrocks> you should have xml schemas in ~/snap/ubuntu-calendar-app/x1/.local/share/glib-2.0/schemas
[13:47] <didrocks> and you will have some .compiled there
[13:47] <didrocks> (gschemas.compiled)
[13:51] <didrocks> ah, got it
[13:52] <didrocks> renato__: yeah, it doesn't look for the correct source file
[13:52] <didrocks> let me fix it
[13:53] <renato__> thanks
[13:57] <Pharaoh_Atem> has anyone seen sergiusens around lately?
[13:58] <josepht> Pharaoh_Atem: he was sprinting last week but should be around this week afaik
[13:59] <ogra_> i saw him comment on bugs :)
[13:59] <ogra_> (he cant hide ! :) )
[14:09] <didrocks> renato__: ok, got if fixed, it's failing on something else but not related to the launche r:)
[14:10] <didrocks> Fail to connect with sync monitor: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name com.canonical.SyncMonitor was not provided by any .service files")
[14:10] <didrocks> renato__: let me push my change
[14:10] <renato__> ok this should not crash the app
[14:10] <renato__> is that crashing?
[14:14] <didrocks> renato__: it does (a core dump)
[14:14] <didrocks> one sec, will give you the link
[14:15] <didrocks> Mirv: FYI, I didn't notice, but check last commit, you should have done that for the launcher to be as light as possible :)
[14:15] <didrocks> renato__: pushed, you can try rebuilding your app
[14:15] <renato__> didrocks, thanks
[14:18] <renato__> didrocks, qmlscene: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
[14:18] <didrocks> renato__: are you sure you pulled latest?
[14:18] <renato__> didrocks, probably I need to update somethingelse
[14:18] <didrocks> renato__: you need to snapcraft clean && snapcraft prime
[14:18] <renato__> didrocks, let me try again. I did snapcraft clean; snapcraft
[14:19] <didrocks> hum, weird
[14:19] <didrocks> let me rebuild as well in case I did a typo
[14:20] <didrocks> renato__: you're right
[14:20] <didrocks> let me inspect (sorry)
[14:20] <renato__> :D
[14:20] <renato__> np
[14:20] <didrocks> probably a typo…
[14:21] <didrocks> but I can't see it
[14:21] <didrocks> oh, the merge with Mirv's work removed some part
[14:21] <didrocks> (probably my fault)
[14:22]  * didrocks rewrite history (shhhh)
[14:29] <didrocks> renato__: after a rebuild, it works \o/
[14:29] <didrocks> renato__: probably some other bugs, but at least, it's a start :)
[14:29] <renato__> didrocks, nice, can I build?
[14:30] <didrocks> renato__: yep!
[14:31] <renato__> yeah, we have visuals :D
[14:32] <renato__> didrocks, any hint about this one: GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
[14:33] <renato__> I am not familiar with gsettings
[14:33] <didrocks> renato__: you are missing one package
[14:33] <didrocks> this should be part of the platform snap as well I think
[14:33] <renato__> which one?
[14:34] <didrocks> dconf-gsettings-backend
[14:34] <didrocks> then, with the symlink, it should work
[14:34] <renato__> Mirv, do you agree? ^^^
[14:34] <didrocks> renato__: for next step: once you remove devmode, you need at least the home and gsettings plugs for gsettings to work
[14:35] <didrocks> (home is used to create a symlink with the user binary package, so that you can read your changes)
[14:36] <renato__> didrocks, ok I will keep that in mind. Unfortunately we can not have it confined yet due the missing interfaces. ( I am working on the interfaces too)
[14:37] <didrocks> ok, just add those 2 now to not forget about them!
[14:37] <didrocks> (the home one can be puzzling)
[14:38] <didrocks> or you will make changes in gsettings that you will never be able to read back
[14:38] <renato__> gsettings is already there
[14:38] <didrocks> (you will always read the default value)
[14:38] <didrocks> ok, just add home then!
[14:38] <renato__> doing now
[14:38] <didrocks> at least, no more wrapper for you!
[14:38] <didrocks> and just run "qmlscene"
[14:38] <didrocks> good progress
[14:39] <renato__> didrocks, yeah. Thanks a lot for that
[14:39] <didrocks> yw! :)
[14:57] <mup> PR snapcraft#890 opened: Implementing '[list-]snaps' command <Created by cprov> <https://github.com/snapcore/snapcraft/pull/890>
[15:55] <Mirv> renato__:ok, making a note to add dconf-gsettings-backend + symlinks
[16:01] <Mirv> FYI ubuntu-app-platform now in stote, beers owed to mvo who is off today
[16:01] <Mirv> but store not ready for it, needs manual review
[16:02] <Mirv> nessita: ETA for the deployment where store supports content: field for the content interface?
[16:02] <Mirv> (will read messages later)
[16:02] <didrocks> oh jdstrand, did you get a chance to update your filter? ^
[16:02] <didrocks> seems it's still not supported
[16:02] <didrocks> slot having content: field
[16:04] <nessita> Mirv, hi! hum, this is the first time I hear about that. HAve you been following that with someone else?
[16:05] <didrocks> nessita: I reported it to jdstrand some weeks ago (and repinged him at the sprint)
[16:05] <didrocks> seems like nobody tested before the end to end creation of a content interface snap (before I did)
[16:05] <nessita> didrocks, ah, so this is something to be fix in c-r-t?
[16:05] <didrocks> yep
[16:06] <didrocks> just an unknown field
[16:06] <nessita> didrocks, if it's in c-r-t trunk, let us know and we'll try to push that to prod asap
[16:06] <jdstrand> didrocks: it is committed to trunk. I mentioned that we could do a store sync to roadmr the other day, but today I will be requested another store sync
[16:06] <jdstrand> requesting
[16:06] <didrocks> great! :)
[16:06] <didrocks> jdstrand: mind reviewing Mirv's interface meanwhile
[16:06] <jdstrand> it's already fixed, just need to be pulled into the store
[16:06] <jdstrand> yes
[16:06] <roadmr> jdstrand: ok, I'll get on it right away
[16:07] <didrocks> sweet! just timely deployed
[16:07] <jdstrand> roadmr: well, hold on til I ping you for the final ping at this point
[16:07] <roadmr> jdstrand: ok :D
[16:07] <jdstrand> roadmr: I've got the full set of changes almost done
[16:07] <jdstrand> (you could've merged what was there before, but no point now)
[16:08] <roadmr> awesome! sure, just let me know which revno and we'll get that deployed
[16:08] <jdstrand> didrocks: what snap?
[16:08] <didrocks> jdstrand: should be ubuntu-app-platform
[16:12] <jdstrand> didrocks, Mirv: approved. someone should press the 'publish' button when you are ready
[16:13] <didrocks> jdstrand: excellent, thanks!
[16:14] <didrocks> and good to know the fix is getting deployed as well
[16:26] <mup> Bug #1640229 opened: error refreshing snap <Snappy:New> <https://launchpad.net/bugs/1640229>
[16:39] <kalikiana_> jdstrand: FYI I changed the client side to place the cert/key in a different place than LXD_DIR and it seems to work fine, thus nothing special needed on the lxd/interface side of things
[16:39] <jdstrand> kalikiana_: great!
[16:41] <kalikiana_> jdstrand: With regard to the snapd branch, what are going to be the next steps?
[16:41] <jdstrand> kalikiana_: I'm going to look at it again today
[16:41] <jdstrand> then we can go from there
[16:43] <ogra_> ppisati, yo ... you need to build the kernels against the ~snappy-dev/image PPA (the main archive is used anyway then) ... also to get the right initrd scripts and all
[16:54] <kalikiana_> jdstrand: Cool. Thanks!
[17:17] <roadmr> jdstrand: hello! hey, question/clarification. Should we deploy c-r-t to the store (which is currently at 761) or should I wait for your ping? (I think I should wait but we had some confusion so I thought it best to ask)
[17:18] <jdstrand> roadmr: please what
[17:18] <jdstrand> wait
[17:18] <roadmr> jdstrand: will do. Yes, that clarifies things :) thanks
[17:27] <renato__> Mirv, now we need to get it running on unity8 :D
[17:29] <renato__> Mirv, I'm not sure if we should some how integrate with kgunn shared content or add it to the plataform snappy
[17:34] <abeato> ogra_, maybe you know how local snaps are installed nowadays? --dangerous and --force-dangerous do not work anymore
[17:36] <mup> PR snapcraft#891 opened: repo: apt-mark new build-packages as automatically installed <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/891>
[17:49] <elfgoh> Hello!
[17:57] <ogra_> abeato, --dangerous definitely works for me
[17:57] <abeato> ogra_, was a silly error on my side, thanks :)
[18:07] <elfgoh> Hi all, I intend to run Ubuntu core 16 on the beaglebone black
[18:07] <elfgoh> Question: what is the difference between Ubuntu Core 16 and debian with the latest snaps installed?
[18:08] <ogra_> one uses snaps the other uses debs ? ...
[18:09] <ogra_> (compltely different approaches)
[18:12] <ogra_> elfgoh, http://people.canonical.com/~ogra/snappy/all-snaps/stable/current/ try that one and see yourself i'd say :) (you need an ubuntu one account to create the ssh login on first boot and i'd recommend an FTDI serial cable)
[18:12] <elfgoh> Sorry if this is a very basic question. Say i have a base minimal install of debian. And then I install snapd. And from then onwards, I install all packages using snap
[18:13] <ogra_> then you have a classic install that runs snaps
[18:13] <elfgoh> I see.
[18:13] <ogra_> an ubuntu core system uses snaps for everything (kernel, bootloader rootfs are all packaged as snaps)
[18:14] <elfgoh> I see. Thanks for the clarification. Then what would be technical reasons to use Ubuntu core, instead of a classical system running snaps?
[18:14] <ogra_> that means you caan use the snap features for the packages ...
[18:15] <ogra_> i.e. if you install a new kernel snap it will automatically roll back in case there is an issue with the new kernel on reboot
[18:15] <ogra_> likewise you can roll back your rootfs
[18:16] <ogra_> read: you cant really break such a system ... it will always fall back to the last working version in case something goes bad
[18:16] <elfgoh> Got it
[18:16] <elfgoh> Hmm so on a classical install running snaps, what happens if I try to install a new kernel snap?
[18:17] <ogra_> it unpacks it to disk, tells teh bootloader there is a new kernel  and tells you to reboot ...
[18:17] <ogra_> once you reboot there is a flag set by the bootloader that makes the system know that a new kernel upgrade is being verified this boot ...
[18:17] <elfgoh> Ok. So the non snap kernel will get replaced the kernel snap with no issue?
[18:17] <ogra_> if the verification succeeds,, the flag is unset again
[18:18] <ogra_> if not, the system automatically rolls back to the former kernel
[18:18] <elfgoh> *replaced by
[18:18] <ogra_> non snap ?
[18:18] <ogra_> (you asked what happens if you install a new kernel snap)
[18:18] <elfgoh> Ok hang on... i think we aren't on the same page. Let me restart again
[18:19] <ogra_> if you hack the system and inject a different vmlinuz then you are indeed on your own :)
[18:19] <elfgoh> So say I have a fresh classic debian install, which I install snapd. Now I have what you called a classic install running snap, correct?
[18:19] <ogra_> yes
[18:20] <ogra_> (you could do that with an ubuntu-server install too ... iirc the nextcloud box uses such a setup (but will switch to an all-snap system in the next iteration))
[18:22] <elfgoh> And in this type of install, after snaps is installed, there are various components such as kernel, bootloader, there are not snaps, since they came as part of the classic debian install. Correct?
[18:22] <elfgoh> *that are not snaps
[18:22] <ogra_> yes
[18:23] <ogra_> and you will need apt to update them
[18:23] <ogra_> (and wouldnt be able to manage them or configure them via the snapd REST api)
[18:24] <elfgoh> Ah. So means that snap will complain or throw an error if I try to install a kernel snap?
[18:24] <elfgoh> For this particular system?
[18:24] <ogra_> no idea, i dont think anyone ever tried that :)
[18:24] <elfgoh> LOL
[18:24] <ogra_> it would just hog space on your disk in the end
[18:24] <ogra_> i.e. it wouldnt be used in any case
[18:25] <jdstrand> roadmr: hey, can you pull r794?
[18:25] <ogra_> (weather it errors or not)
[18:25] <elfgoh> ogra_: meaning that the new kernel snap just hogs space?
[18:28] <jdstrand> roadmr: oh I forgot one teeny thing stgraber asked me to fixed (unrelated to snap declarations)
[18:28] <jdstrand> fix*
[18:28] <ogra_> elfgoh, right
[18:28] <elfgoh> ogra_: I am slightly confused as to why your Beaglebone image isn't here http://releases.ubuntu.com/ubuntu-core/16/
[18:29] <ogra_> because the bbb isnt "officially" upported
[18:29] <ogra_> *supported
[18:29] <ogra_> (we call that "community supported" ... )
[18:29] <elfgoh> Ah I see. Thanks for building a community image!
[18:29] <ogra_> heh
[18:29] <elfgoh> Much appreciated
[18:30] <ogra_> welcome :)
[18:30] <elfgoh> I booted the BB image and unless I mistakenly use another image, this is a debian?
[18:30] <elfgoh> *debian image
[18:30] <ogra_> nope, it is ubuntu-core
[18:31] <ogra_> did you hold the button of the bbb when booting off the SD ?
[18:31]  * ogra_ always forgets that and i dont really want to trash the internal MMC to not make it do that ... 
[18:32] <elfgoh> No I didn't. What does that button do?
[18:32] <ogra_> switch the HW to boot from SD instead of internal MMC
[18:32] <jdstrand> roadmr: ok, please pull r795 :)
[18:34] <elfgoh> ogra_: that is very interesting. I am not most familiar with the BBB. But I have an existing card with debian on it and it boots fine without pressing the button
[18:34] <elfgoh> But let me try what you suggested
[18:34] <ogra_> are yu sure it boots the SD not the eMMC ?
[18:34] <ogra_> you need to hold down S2, then apply power and if the LEDs are lit up release S2
[18:35] <ogra_> (very fiddly if you dont have children hands if you ask me :) )
[18:35] <barry> ubuntu-core_[0-9]+.snap got renamed to core_[0-9]+.snap recently?  i probably missed that on the mailing list
[18:36] <ogra_> barry, not recently ... that was quite some time ago
[18:36] <ogra_> images are all built using core now
[18:36] <barry> ogra_: really?  interesting that my tests are only now failing.  but okay
[18:36] <barry> thanks
[18:36] <ogra_> while ubuntu-core is still supported for desktops that have it installed ... afaik snapd has no proper migration code yet
[18:36] <ogra_> once thats there ubuntu-core will be deprecated
[18:37] <elfgoh> ogra_: Ok. let me give that a go. I had always assumed that the BBB will boot off the card by default
[18:37] <ogra_> (teh content is identical to core though)
[18:37] <ogra_> elfgoh, nope ... only if you hold down S2 ... else it boots off the MMC (unless the MMC mbr is trashed)
[18:37] <elfgoh> Btw is there a repo that I can send a PR to add a readme to your repo?
[18:38] <ogra_> you mean to http://people.canonical.com/~ogra/snappy/all-snaps/stable/current/ ?
[18:38] <ogra_> hmm, i guess having a readme would make sense, yeah ...
[18:39] <elfgoh> Yes that is what I was thinking
[18:39] <elfgoh> I will be happy to send a PR if that is helpful
[18:39] <elfgoh> Once I figure things out at my end
[18:40] <ogra_> ogra@ubuntu.com ... feel free to just mail it to me and i'll put it in place (perhaps with some adjustments)
[18:40] <ogra_> but if you dont, i'll put one in place tomorrow, i think it makes sense
[18:41] <mjbrender> Hey all - I'm running into a packaging issue on a project I maintain.
[18:41] <elfgoh> Haha. It is 2:41 am here now
[18:42] <elfgoh> I will see if I can get things figured out first
[18:42] <mjbrender> It's called Snap (snapd/snapctl) and I know that that's unfortunate.. but curious what others might advise given 16.04.1 has a conflict. Example of the challenge: https://github.com/intelsdi-x/snap/issues/1294#issuecomment-254587076
[18:42] <ogra_> 19:42 in germany ;)
[18:42] <ogra_> mjbrender, the media player ?
[18:43] <mjbrender> ogra_ nope, a telemetry framework for data centers.
[18:43] <ogra_> (we had massive issues because there is a "snap deb" in the archive for it ... )
[18:43] <ogra_> oh my
[18:43] <ogra_> the snap name is really becoming a bit over-used :)
[18:43] <mjbrender> yeah, it's no fun.
[18:43] <mjbrender> too true :)
[18:44]  * qengho files a bug to rename it to "snaaaaaaaap"
[18:44] <elfgoh> Ok another question, did you build your BBB image using the beagle black snap listed here? https://developer.ubuntu.com/en/snappy/start/gadget-snaps/
[18:44] <mjbrender> We're thinking through what to do since this took us by surprise. Major renaming is a no go, but thinking through absolute paths or similar.
[18:45] <mjbrender> haha qengho. I would rather open an ticket to rename Snappy snapd to snappyd and snapctl to snappyctl
[18:45] <mjbrender> but alas :)
[18:45] <ogra_> elfgoh, https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
[18:46] <elfgoh> Thanks!
[18:46] <mjbrender> ogra_ any advice come to mind? Curious what you learned from the media player issue and what you recommended
[18:47] <elfgoh> Speaking of naming..... I can't say that the choice of names for Snap related stuff is the best.... e.g. Ubuntu Core https://launchpad.net/~ubuntu-core-dev
[18:47] <ogra_> mjbrender, well, the mediaplayer issue was simply that there is a "snap" manpage shipped in the deb ... so snapd (who also ships a snap command and manpage) was clashing ...
[18:48] <ogra_> elfgoh, well, it got a lot better ... there used to be like 20 meanings of the term ubuntu-core in the ubuntu world ... with snappy all of them have been deprecated now ... there is only one ubuntu-core lft
[18:48] <ogra_> *left
[18:49] <ogra_> but yeah, there is still the ubuntu-core-dev team which is for people with full upload rights to the ubuntu archive ... i doubt that name will change though
[18:49] <ogra_> mjbrender, i dont really understand the issue ... why do you bother that the snapctl command exists ?
[18:50] <ogra_> mjbrender, http://paste.ubuntu.com/23447708/
[18:50] <mjbrender> snapctl, in this framework, is a utility to query the snapd server
[18:51] <ogra_> right ... but if the env var is missing something is set up wrongly already ...
[18:51] <mjbrender> before 16.04.1 we were installing in /usr/bin/snapctl and snapd
[18:51] <_markfeatherston> Hello, I'm trying to build an image for new hardware.  I have a gadget and kernel snap to try, but ubuntu-image doesn't see my snaps (error: cannot find snap "tsimx6-gadget": snap not found).  I've uploaded them to the store marked as private, but they are listed as pending review which is why I assume ubuntu-image can't see them?  Is there a better way to go about testing these?
[18:51] <mjbrender> now it conflicts and gives errors for Snappy snapctl
[18:52] <ogra_> mjbrender, well, i'd start with filing a bug
[18:53] <ogra_> i doubt anyone in the snappy core team is aware that there is another snapctl command that could clash
[18:53] <mjbrender> ogra_ great point - I'll do that now and mention what's going on. I have very realistic expectations, but want to raise the concern and work together on a smart resolution.
[18:53] <ogra_> you would normally solve that on the package level in the deb though
[18:53] <elfgoh> Btw I also saw that your mailing lists had no activity since May 2016
[18:53] <elfgoh> Is it still being used?
[18:53] <ogra_> elfgoh, link ?
[18:54] <ogra_> (there surely have been mails the last days)
[18:54] <ogra_> https://lists.ubuntu.com/mailman/listinfo/snapcraft is the official list
[18:54] <ogra_> and https://lists.snapcraft.io/mailman/listinfo/devices for porting to new hardware
[18:54] <elfgoh> https://lists.ubuntu.com/mailman/listinfo/snappy-app-devel https://lists.ubuntu.com/mailman/listinfo/snappy-devel
[18:54] <elfgoh> Ah
[18:55] <ogra_> ah, if you had gone trough the posts there,, you would have found an announcement by niemeyer that the list is being renamed :)
[18:56] <ogra_> people have been migrated automatically ... but archives havent
[18:56] <ogra_> (i think ... at least :) )
[18:57] <mjbrender> ogra_ excuse my ignorance here, but where should I file the bug? I don't see Issues available under any of the projects here: https://github.com/snapcore
[18:57] <ogra_> mjbrender, see the channel topic ;)
[18:57] <ogra_> we dont use githubs issue tracker (way to limited)
[18:58] <mjbrender> ogra_ ;)
[19:03] <elfgoh> ogra: glad to know that there is an active mailing list! I was under the impression that the project was dead xD
[19:04] <ogra_> hah, nope
[19:04] <ogra_> it is actually the future of ubuntu ;)
[19:05] <elfgoh> Truthfully, I had a lot of issues finding updated info about ubuntu core
[19:05] <elfgoh> and snappy
[19:05] <elfgoh> The hits on google are mostly the news releases
[19:05] <elfgoh> But I am glad to be proven wrong
[19:10] <sergiusens> elfgoh there are twitter and g+ handles you can follow
[19:10] <sergiusens> if that is your thing
[19:11] <elfgoh> Ah twitter please
[19:11] <ogra_> and an IRC channel ;)
[19:11] <elfgoh> Well the thing is IRC is blocked in the office :(
[19:11] <elfgoh> web.freenode.net disconnects after some time T.T
[19:11] <ogra_> use a web client like http://kiwiirc.com/
[19:12] <roadmr> jdstrand: gotcha, 795.
[19:12] <elfgoh> Wow thanks I will give kiwi irc a try when i get to office
[19:12] <elfgoh> What is the twitter handle?
[19:13] <jdstrand> roadmr: fyi, you could do r796, but it has no effect on the tools (just a sync for consistency's sake)
[19:13] <roadmr> jdstrand: sure, I can do that
[19:15] <mup> Bug #1640281 opened: Conflict - Telemetry project, Snap, uses snapd and snapctl <Snappy:New> <https://launchpad.net/bugs/1640281>
[19:17] <elfgoh> sergiusens: What is the twitter handle?
[19:18]  * ogra_ calls it a day
[19:19] <sergiusens> elfgoh snapcraftio
[19:24] <mjbrender> Thanks again for the help ogra_ -- have a good day/night all.
[19:44] <mup> PR snapd#2269 opened: update base declaration documentation and policy for on-classic and snap-type <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2269>
[20:14] <mwhudson> time to find out if i killed my dragonboard when i spilt water on it
[20:17] <mwhudson> apparently not, woo
[20:19] <jdstrand> Chipaca: hi! I'm puzzled by the autopkgtest failure in https://github.com/snapcore/snapd/pull/2269
[20:19] <mup> PR snapd#2269: update base declaration documentation and policy for on-classic and snap-type <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2269>
[20:20] <jdstrand> Chipaca: it builds fine locally... is this a known issue?
[20:20] <Chipaca> jdstrand, “just fyi - please ignore the autopkg xenial-s390x failures, pitti and I are working to make the tests reliable”
[20:20] <Chipaca> jdstrand, via mvo
[20:21] <jdstrand> Chipaca: it says 'xenial-amd64'
[20:21] <Chipaca> mwhudson, of course water doesn't harm the dragonboard, it's chinese!
[20:21] <jdstrand> I wonder if it is related...
[20:21] <jdstrand> well, I'll ask mvo when he is around
[20:21] <jdstrand> Chipaca: thanks
[20:21] <Chipaca> mwhudson, (this is a joke about chinese dragons being rules of water)
[20:21] <Chipaca> rulers*
[20:22] <Chipaca> jdstrand, ah! hm. dunno then :-/
[20:23] <Chipaca> jdstrand, I think it's part of the same thing
[20:23] <jdstrand> Chipaca: ok, thanks
[20:23] <Chipaca> jdstrand, note only the travis ones are required for merging
[20:24] <Chipaca> jdstrand, if mvo is around and it isn't next week, hit im over the head
[20:24] <jdstrand> hehe, ok :)
[20:24] <mup> PR snapcraft#870 closed: sources: Add RPM source <Created by Conan-Kudo> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/870>
[20:25] <qengho> RPM, ew.
[20:28] <Son_Goku> :D
[20:28] <Son_Goku> woohoo!
[20:30] <Chipaca> Son_Goku, ⁵!
[20:34] <mwhudson> Chipaca: :)
[20:34] <mwhudson> even better the new console-conf appears to work
[20:34] <mwhudson> although the ssid scanning doesn't work for like 30s, wonder what is up with that
[20:52] <mwhudson> oh right, need to up the interface first
[21:08] <elfgoh> Out of curiosity, anyone tried soletta or motivity on Ubuntu Core?
[21:54] <SuperJonotron> Been using snapcraft and snaps in this same configuration for a few weeks, just reinstalled an updated version and now the app can't write to the #SNAP_USER_DATA anymore
[21:54] <SuperJonotron> did something break in an update for this function?
[22:00] <SuperJonotron> Anybody know of any issues with the $SNAPPY_USER_DATA location?  having issues all of a sudden not having write access to
[22:19] <mup> PR snapcraft#892 opened: Catch PermissionError when attempting to replace contents in a readonly file. (LP: #1640305) <Created by larryprice> <https://github.com/snapcore/snapcraft/pull/892>
[23:21] <qengho> A snap with configure hooks requires some mention of it in the $SNAP/meta/snap.yaml , right?
[23:56] <qengho> Hmm, no is "implicit". At least in source tree.