[03:50] <tgm4883> If I'm adding stuff to stage-packages, how can I create a snap without needing to rebuild the whole thing?
[03:54] <qengho> tgm4883: "snapcraft clean" takes a few arguments. -s stage is probably it.
[03:55] <tgm4883> qengho: just found this page http://snapcraft.io/create/ Currently rebuilding the whole thing, but I'll try that next
[04:03] <qengho> tgm4883: fyi, "clean" and build dependency is a little screwy this week, but usually works. You might hit a bug and have to build more than should be strictly necessary.
[04:06] <tgm4883> qengho: ok, good to know. Currently trying to move some deb packaging to snap packaging and finally got it to build with the binaries in the right directory. Now trying to fix "This application failed to start because it could not find or load the Qt platform plugin "xcb"."
[04:08] <qengho> tgm4883: ah yeah.
[04:09] <qengho> tgm4883: Do you have mention of "desktop/qt5" in your yaml?
[04:09] <tgm4883> qengho: no
[04:10] <qengho> tgm4883: Okay, I think there's a built-in wrapper for you. In your main part, use "after: [ desktop/qt5 ]"
[04:11] <qengho> tgm4883: and make your command: desktop-launch $SNAP/yourrealprogrampath
[04:11] <qengho> I *think*. This is new to me.
[04:11] <tgm4883> ok, trying now
[04:12] <tgm4883> qengho: this is what it looks like so far https://github.com/tgm4883/mythtv-snap/blob/master/snapcraft.yaml
[04:13] <qengho> tgm4883: you are a brave brave man.
[04:13] <tgm4883> qengho: heh, why is that
[04:15] <mup> Bug #1607604 opened: the user created by create-user is not a sudoer <create-user> <Snappy:New> <https://launchpad.net/bugs/1607604>
[04:16] <tgm4883> qengho: so I just did the snapcraft commands starting at stage, it seemed to pull int he desktop/qt5 stuff, but still getting the same error
[04:18] <qengho> tgm4883: huh. No idea.
[04:18] <tgm4883> I'm going to try rebuilding it again from scratch
[04:19] <qengho> tgm4883: Is the 6 line yaml of just "plugin: nil" and "stage-package: [ mythtv ]" not work?
[04:20] <tgm4883> qengho: you mean just use it to pull in the deb packages?
[04:21]  * qengho nods.
[04:22] <qengho> I like easy.
[04:22] <tgm4883> I've not tried it
[04:22] <tgm4883> I'll try it after this build
[04:23] <qengho> If it works, you owe me a beer.
[04:25] <tgm4883> heh
[04:26] <tgm4883> Would that install everything inside the snap?
[04:29] <qengho> tgm4883: that and all its deps, yes.
[04:29] <qengho> Not sure about Recommends.
[04:30] <tgm4883> qengho: so this http://paste.ubuntu.com/21368648/
[04:30] <tgm4883> that doesn't work
[04:30]  * qengho files a Pull Request for -190 line change.
[04:30] <tgm4883> nm
[04:30] <qengho> :)
[04:30] <tgm4883> stage-packageS
[04:30]  * qengho nods.
[04:30] <tgm4883> running now
[04:31] <tgm4883> So if this works, that's great and means it can run inside a snap
[04:31] <tgm4883> which gives me something to go on
[04:32] <tgm4883> I wonder if "--runprefix=/usr" is causing me issues in the other build
[04:33] <qengho> Oh, yeah, that looks suspicious.
[04:34] <ahoneybun> where is it getting the deb?
[04:34] <qengho> ahoneybun: Ubuntu repo, here.
[04:34] <tgm4883> ahoneybun: well ideally it would build from source, but for the other test it would get the deb from the ubuntu repos
[04:35] <ahoneybun> that yaml is missing that
[04:35] <qengho> tgm4883: you need a command: in that pasted YAML.
[04:36] <tgm4883> ahoneybun: this yaml  https://github.com/tgm4883/mythtv-snap/blob/master/snapcraft.yaml ?
[04:36] <tgm4883> qengho: yea I noticed that, building again
[04:36] <ahoneybun> pulling from git, nice
[04:37] <tgm4883> qengho: yea using the deb doesn't work either. Getting some permissions issues
[04:37] <ahoneybun> pastebin?
[04:37] <ahoneybun> I just started today but I'll try lol
[04:37] <tgm4883> ahoneybun: of running after using the deb package? I'd rather work out the building from source issue
[04:38] <ahoneybun> from source would help get it on other distros
[04:41] <tgm4883> what's the build variable for the install directory?
[04:44] <qengho> tgm4883: "some permissions"?
[04:44] <qengho> Are they secret?
[04:44] <tgm4883> qengho: http://paste.ubuntu.com/21369624/
[04:46] <qengho> tgm4883: peek in /snap/mythtvw/x2/usr/bin/mythfrontend and see if you can put the pidfile in a sane place and if you can get that dialog_functions to be loaded from $SNAP/...
[04:47] <qengho> ("A sane place" is probabyly under $SNAP_DATA/...
[04:47] <qengho> )
[04:48]  * qengho afk in 10 minutes.
[07:37] <mup> Bug #1607662 opened: "home" plug doesn't work with encrypted home dir <Snappy:New> <https://launchpad.net/bugs/1607662>
[07:38] <kalikiana> Question: how would a snap go about accessing build tools like the go snap?
[07:38] <kalikiana> It seems pointless to have a compiler snapped if other snaps can't use it
[07:38] <kalikiana> So I will assume there's a way somehow
[07:43] <didrocks> kalikiana: I don't think we are at the point (apart for devmode), where snap is suitted for that (yet)
[07:43] <didrocks> I think we'll get the same kind of "shell" interface that will work for this as well
[07:48] <mup> PR snapd#1602 opened: interface: add kernel-module interface for module insertion <Created by arges> <https://github.com/snapcore/snapd/pull/1602>
[07:54] <kalikiana> didrocks: Hmm would it work if my snapcraft.yaml is confinement:strict but I'd say "use --devmode if you want to access xyz?"
[07:55] <mup> Bug #1607662 changed: "home" plug doesn't work with encrypted home dir <Snappy:New> <https://launchpad.net/bugs/1607662>
[07:56] <kalikiana> Or I need to investigate some kind of distcc-like setup
[08:21] <mup> PR snapcraft#680 closed: Rewrite shebangs generated by the python plugins <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/680>
[08:31] <didrocks> kalikiana: that's possible AFAIK (with the confinement and so on)
[08:32] <didrocks> but keep in mind you have your own mount namespace, so you can have some surprises, even confined
[08:39] <mup> PR snapcraft#694 closed: Pass --root to the python3 plugin on build <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/694>
[08:41] <imexil> Hi I'm using a git repo as source but would like snapcraft to pull down a specific tag which is on a non-master branch. Simply specifying source-tag seems not to be enough. Do I have to specify the git branch as well?
[08:46] <imexil> never mind it looks like it is actually pulling down the correct tag.
[08:50] <didrocks> imexil: you have also the "source-branch" parameter if you want (snapcraft help sources)
[08:51] <imexil> didrocks: Ah thanks. It feels like finding the correct (up to date) documentation is my biggest challenge at the moment ;-)
[08:55] <didrocks> imexil: heh, yeah, we are woroking on this :)
[08:56] <imexil> didrocks: Probably not easy with snappy still being such a moving target.
[08:56] <didrocks> that's exactly the biggest issue :) but with the start of snapcraft.io and crafting codelabs, we'll get there
[08:57] <imexil> Yes I was going to say it would help already when all doc resources would be available from snapcraft.io and not some there and some on ubuntu dev pages and some on ubuntu wiki
[09:04] <sergiusens> ppisati_ https://github.com/snapcore/snapcraft/pull/689
[09:04] <mup> PR snapcraft#689: kernel plugin: kernel targets depending on debarch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/689>
[09:08] <ppisati_> sergiusens: /me tests it
[09:31] <Guest40416> Hi, I Have a simple question: I try to associate an icon to my snap, using a desktop file in /setup/gui/aa.desktop and /setup/gui/aa.png. In the examples, I saw that the path to the icon in the desktop file is ${SNAP}/meta/gui/aa.png but it does not work. My guess is that the varable ${SNAP} is not correctly interpreted ?
[09:32] <popey> does the icon get installed to /snap/yourapp/current/meta/gui ?
[09:32] <popey> and the desktop file
[09:32] <Guest40416> yes
[09:33] <popey> if you cat the desktop file what does the Icon= line look like? can you paste that one line here?
[09:33] <Guest40416> but the desktop file remains "empty"
[09:34] <popey> Icon=${SNAP}/meta/gui/openttd.png
[09:34] <popey> e.g. ^
[09:34] <popey> thats what my installed .desktop file looks like
[09:34] <popey> (well, one line of it)
[09:36] <Guest40416> Mine, is also Icon=${SNAP}/meta/gui/jimbodicomviewer.png
[09:36] <popey> you said the desktop file is empty?
[09:37] <popey> where you built the snap, look in prime/meta/gui - is the desktop file / png in there?
[09:39] <Guest40416> It is not in prime/meta/gui !!
[09:39] <Guest40416> Thanks, I will try with this
[09:45] <popey> snapcraft should put it there
[09:45]  * Odd_Bloke has just filed https://bugs.launchpad.net/snappy/+bug/1607710; could someone give it a quick triage?
[09:45] <mup> Bug #1607710: Use passwd to determine user home directory <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
[09:47] <mup> Bug #1607710 opened: Use passwd to determine user home directory <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
[09:48] <mup> PR snapcraft#697 opened: Also use INSTALLROOT for make plugin <Created by jhobbs> <https://github.com/snapcore/snapcraft/pull/697>
[09:55] <mup> PR snapd#1599 closed: asserts,client: switch snap-build and snap-revision to be indexed by snap-sha3-384 <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1599>
[10:04] <mup> PR snapd#1603 opened: overlord/snapstate: ensure calls to store are done without the state lock held <Created by chipaca> <https://github.com/snapcore/snapd/pull/1603>
[10:14] <mup> Bug #1607717 opened: no snaps installed error <Snapcraft:Invalid> <Snappy:New> <https://launchpad.net/bugs/1607717>
[10:25] <Spads> https://github.com/scummvm/scummvm/pull/795
[10:25] <mup> PR scummvm/scummvm#795: POSIX: Add $SNAP to search path if available <Created by fuzzie> <https://github.com/scummvm/scummvm/pull/795>
[10:27] <ogra_> neat !
[10:28]  * Spads is arranging meetings with that upstream over lunch soon
[10:29] <Spads> had to get over my debian packaging mentality of being a third-party maintainer and say "actually these changes should come from you folks and not have my name on them"
[10:29] <Spads> and so they can fix this stuff in the right place, which is nice
[10:30] <ogra_> yeah, definitely
[10:50] <ali1234> hmm... gstreamer isn't seeing its plugins
[10:55] <ali1234> ogra_: why do you do ">>$SNAP_DATA/log/daemon.log" - shouldn't you just let it all go to systemd?
[10:55] <ogra_> i could, yeah
[10:56] <mup> PR snapd#1604 opened: client, cmd/snap: better errors for empty snap list result <Created by chipaca> <https://github.com/snapcore/snapd/pull/1604>
[10:56] <ogra_> grmbl ... gmane being dead is really annoying
[10:57] <Chipaca> ogra_, it's not dead! it's nntp-only
[10:58] <ogra_> Chipaca, doesnt help with google links :P
[10:58] <Chipaca> until somebody picks up the nntp-to-web side of it
[10:58] <Chipaca> ogra_, little green arrow next to the link, "cached"
[10:59] <ogra_> dunno, but my google UI doesnt have that
[11:00] <Chipaca> ogra_, do you have an example search?
[11:00] <ogra_> https://www.google.de/search?client=ubuntu&channel=fs&q=IPELUAPATH%3D&ie=utf-8&oe=utf-8&gfe_rd=cr&ei=JDabV_LTN-Xj8wfnl4qYCA#channel=fs&q=IPELUAPATH%3D&pws=1
[11:00] <ogra_> second hit was what i wanted to look at
[11:01] <ogra_> oh
[11:01] <ogra_> it isnt green and its a pulldown here
[11:01] <Chipaca> ogra_, http://imgur.com/4eAk4wh
[11:01] <Chipaca> green ... ok, it's a triangle not an arrow i guess
[11:02] <ogra_> yeah, found it now
[11:02] <ogra_> thanks !
[11:02] <Chipaca> ogra_, np!
[11:02] <ogra_> that used to just be a text link
[11:02] <Chipaca> yep
[11:08] <mup> Bug #1607744 opened: "snap install <filename>" over an already installed snap doesn't copy the user data <Snappy:New> <https://launchpad.net/bugs/1607744>
[11:22] <Odd_Bloke> niemeyer: https://bugs.launchpad.net/bugs/1607710 is the bug I filed for the home directory issue.
[11:22] <mup> Bug #1607710: Use passwd to determine user home directory <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
[11:27] <mup> Bug #1607748 opened: Ability to use two registered names for the same snap <Snappy:New> <https://launchpad.net/bugs/1607748>
[11:29] <niemeyer> Odd_Bloke: Thanks!
[11:40] <slangasek> zyga: just got a bug report in Debian unstable that snapd is not buildable from source because of removal of a build-dependency (golang-pb-dev -> golang-github-cheggaaa-pb)
[11:40] <slangasek> I see no bug report in Debian explaining why this was removed
[11:41] <slangasek> but that means it's an unmaintained build-dep for Ubuntu also
[11:43] <slangasek> zyga: ah, https://bugs.debian.org/830747 , "ROM; superseded by golang-gopkg-cheggaaa-pb.v1"
[11:52] <ogra_> kyrofa, sergiusens, do you guys think we could avoid calling ldd on kernel modules in snapcraft builds ? (see the last lines of https://launchpadlibrarian.net/275652591/buildlog_snap_ubuntu_xenial_amd64_kernel-test-snap_BUILDING.txt.gz)
[11:55] <dholbach> davidcalle, do you think it'd make sense to add "newest snaps" to the report? e.g. a summary of https://twitter.com/uappexplorer?
[11:55] <didrocks> dholbach: it's already what we have (the 10 snaps of the months) on insights, right?
[11:55] <didrocks> dholbach: maybe we should ensure we don't duplicate, so only have one list
[11:56] <dholbach> didrocks, I just felt like we're getting so many snaps in that a weekly and a monthly review wouldn't hurt? :)
[11:56] <dholbach> didrocks, in the monthly one you get the best of the last four weeks ;-)
[11:56] <didrocks> dholbach: can be, at least, the efforts should be joined
[11:57] <dholbach> sure - it'd be like the research work for the monthly blog post would already be done :)
[11:59] <ppisati_> ogra_: is that a kernel snap build? how did you avoid the 'snapcraft login' problem?
[12:00] <ogra_> ppisati_, it is more than just a kernel ... lp:~ogra/+junk/kernel-test-snap ... (see the makefile) for the official kernels we need a bunch of extra stuff (and tehere will be more, like mesa, nvidia drivers etc etc)
[12:01] <ogra_> ppisati_, but it is "type: kernel" in which case i dont think snapcraft should call ldd at all on the modules dir
[12:01] <ali1234> Jul 29 12:58:53 al-desktop ubuntu-core-launcher[24053]: Ready for rendering.
[12:01] <ali1234> it works!
[12:01] <ogra_> looks ready :)
[12:01] <ogra_> congrats !
[12:02] <ali1234> ogra_: how do i delete things from your upnp server?
[12:03] <ppisati_> ogra_: oh i see
[12:03] <ogra_> ali1234, thats a bug i still havent faound the reason for ...
[12:03] <ogra_> you need to delete from commandline currently
[12:03] <ali1234> okay... workaround? go into the snap
[12:03] <ogra_> (sadly lighttpd doesnt give any errors)
[12:03] <ogra_> right, rm it from commandline
[12:03] <ali1234> where is the data?
[12:04] <ali1234> found it
[12:04] <ali1234> hmm storing the data in 1/ rather than common/ - do all my files vanish if reinstall the snap?
[12:05] <ppisati_> ogra_: btw, do you have a prebuilt amd64 image somewhere?
[12:05] <ogra_> ali1234, /snap/upnp-server/current/var/cache/lighttpd/uploads/
[12:05] <ogra_> iirc
[12:06] <ali1234> no it's in Media
[12:06] <ogra_> err, no
[12:06] <mup> Bug #1607763 opened: Interface to manage sudoers <cpc> <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1607763>
[12:07] <ogra_> ali1234, right, /var/snap/upnp-server/current/Media/
[12:07] <ogra_> ppisati_, see the mailing list, mvo announced an experimental one with the new world order yesterday
[12:07] <ali1234> hmm no mp3 decoder plugin...
[12:08] <ogra_> well, if you have a patch :)
[12:08] <ogra_> all my music is .flac ... for which i dont seem to add any extra decoders it seems
[12:08] <ogra_> *dont seem to need to
[12:08] <ali1234> the server does not need the plugin the rendered (what i am snapping) does
[12:09] <ogra_> ah, k
[12:09] <ali1234> okay it claims to be playing but i don't hear anything
[12:09] <ppisati_> ogra_: uhm nope, he just said there will be a new image, no links
[12:10] <ogra_> ppisati_,  http://people.canonical.com/~mvo/all-snaps/16/
[12:10] <ogra_> note that all package names changed (except for ubuntu-core)
[12:10] <ppisati_> ogra_: ohhh
[12:10] <ogra_> the kernel package is pc-linux now
[12:11] <ogra_> oh
[12:11] <ogra_> wrong
[12:11] <ogra_> it is pc-kernel
[12:11] <ogra_> (probably because it contains a lot more than linux :) )
[12:12]  * ogra_ would actually raher call them hw-pack or some such ... 
[12:14]  * ppisati_ tries to build an image
[12:16] <ppisati_> ogra_: is the gadget still canonical-pc or what?
[12:18] <ali1234> so how do i get audio from a snap?
[12:19] <ogra_> ppisati_, just pc now
[12:19] <ogra_> and we only have amd64 atm
[12:19] <ogra_> ali1234, currently only via the pulseaudio interface i think
[12:19] <ogra_> (and i'm not sure that fully works yet)
[12:21] <ogra_> (well, it does for the vlc snap)
[12:22] <ppisati_> uhm
[12:23] <ogra_> there are discussions about an alsa interface as well as a raw audio device one ... but pulse is the only existing one currently
[12:23] <ali1234> okay but how do i use it?
[12:23] <ppisati_> http://people.canonical.com/~ppisati/bad_snappy_image_2016-07-29_14-22-07.png
[12:23] <ogra_> you define it in your snapcraft-yaml and make sure your app uses a pulse output mode
[12:23] <ppisati_> with this command line:
[12:23] <ppisati_> sudo ./ubuntu-device-flash core 16 --channel edge --os ubuntu-core --kernel pc-kernel --gadget pc -o test.img
[12:24] <ali1234> where is it defined in the vlc snapcraft?
[12:24] <ogra_> ppisati_, yeah, the squashfs errors are weird, buti see them since a few weeks, unrelated to the new format
[12:24] <ali1234> oh i see, plugs
[12:24] <ogra_> ppisati_, it should work all fine on second boot for whatever reason
[12:29] <ogra_> ppisati_, i was wondering if it might actually be related to having squashfs built into the kernel instead of a module ... i.e. if behaviour changes then
[12:31] <didrocks> ogra_: nice timing on the ML :)
[12:32] <ogra_> :)
[12:38] <ali1234> ogra_: so it has to use pulseaudio... does that mean that pulseaudio alsa emulation does not work?
[12:38] <ogra_> it should i think, but i'm not sure what the confinement lets through
[12:38] <ogra_> yoou have to try
[12:38] <ali1234> in devmode?
[12:38] <ali1234> i get no audio in devmode...
[12:41] <ali1234> okay got it
[12:44] <ali1234> alsa emulation doesn't work, but i can tell it to use pulseaudio
[12:45] <apw> ogra_, i can see no behaviour changes when squashfs is built-in as opposed to being a modules
[12:45] <ogra_> apw, weird ... i wonder where it comes from then ... sadly i didnt build images for weeks because the world was so broken ... so i cant really ppin it down to a specific date
[12:46] <ppisati_> ATM i'm using mvo all snaps image and it works
[12:47] <ppisati_> except for all the changes in the kernel snaps, that made our kernel moot
[12:47] <ali1234> okay so if my snap is configured to run as a service then audio doesn't work
[12:50] <ogra_> but it was definitely there with my last images that were built the old way
[12:50] <ogra_> so before we changed much
[12:50] <ogra_> and it also seems gone on subsequent boots of the image
[12:51] <ogra_> ppisati_, well, we will never be able to use a plain kernel snap anyway ... you need firmware, udev rules, mesa (when graphics are desired) etc etc
[12:51] <ogra_> plain kernel snaps are for special purpose setups imho
[12:54] <ppisati_> ogra_: yeah, i agree
[12:55] <ppisati_> ogra_: but for example, now it looks for kernel.img, and without that file the image is dead
[12:55] <ogra_> you mean kernel.yaml ?
[12:56] <ppisati_> ogra_: nope, now it looks for the kernel.img file <- the kernel file
[12:56] <ppisati_> linux (loop)/kernel.img $cmdline
[12:56] <ogra_> sigh ... who came up with that
[12:56] <ppisati_> from grub.cfg
[12:57] <ogra_> ppisati_, i thought that was defined at the heidelberg sprint and you participated ?
[12:57] <ogra_> i wasnt in the particular kernel.yaml sessions
[12:57] <ogra_> onl yin gadget ...
[12:58] <ogra_> but when i asked i was told everything is fine and agreed upon
[12:58] <ppisati_> i was in the kernel session, but i don't remember that
[12:58] <ppisati_> anyhow
[12:58] <ogra_> smells fishy really :)
[12:58] <ogra_> but yeah, it is how it is
[12:59] <ppisati_> nope
[12:59] <ppisati_> it's not part of the Heidelberg notes
[12:59] <ogra_> weird
[12:59] <ogra_> and mvo is off today
[12:59] <ppisati_> we'll look into it next week
[12:59] <ogra_> yeah
[13:00] <sergiusens> ppisati_ did it work in the end?
[13:00] <ogra_> it is rather awful having to rename the binaries all the time
[13:00] <ogra_> when we used just vmlinuz before
[13:00] <ppisati_> sergiusens: yes, your patch let me do 'snapcraft --target-arch=foo'
[13:00] <ppisati_> sergiusens: and in the snapcraft.yaml i put:
[13:01] <ppisati_> kernel-image-target: {'amd64': 'bzImage', 'arm64': 'Image', 'armhf': 'zImage'}
[13:01] <ppisati_> and it worked
[13:02] <ppisati_> i tested both the string and the map case
[13:02]  * ogra_ still shudders seeing "arm64: image" 
[13:02] <ogra_> :)
[13:16] <ppisati_> ok, by renaming vmlinuz to kernel.img i can still use our vanilla kernel snap
[13:17] <ppisati_> we'll need to augment it with all the other stuff, but at least they still work
[13:43] <mup> Bug #1607796 opened: snapd-confine regression when running commands as root <Snappy:New> <https://launchpad.net/bugs/1607796>
[13:47] <timothy> stgraber: I tought snap-confine bugs should be opened on github :)
[13:48] <ogra_> that would be confusing
[13:49] <timothy> so you should disable bug opening on github for snap-confine repo like you do for snapd
[13:49] <ogra_> timothy, we want to use LP because it allows us to track bugs in other distros via bug tasks
[13:49] <timothy> ogra_: ok, but allow opening bugs on github confuses people (like me) more :P
[13:49] <ogra_> github issues cant do that
[13:49] <ogra_> well, i dont know why zyga kept it enabled for snap-confine
[13:50] <stgraber> zyga: so new snap-confine does mount /lib/modules but it also no longer defines a working $HOME for daemon (not a big deal) and more importantly, I can't run commands as root anymore because they don't have a HOME define which is a blocker for us
[13:50] <stgraber> zyga: I marked the SRU as failed since it's a clear regression
[13:52] <ogra_> stgraber, dude, this is ubuntu. use sudo
[13:52]  * ogra_ hides somewhere wher stgraber cant reach him when throwing stuff
[13:52] <ogra_> :P
[13:53] <timothy> as root user I have HOME=/root
[13:53] <ogra_> timothy, yes, but snap-confine doesnt mount /root into ubuntu-core
[13:54] <ogra_> and your snapp gets executed inside there
[13:54] <ogra_> so /root is readonly
[13:54] <ogra_> its a missing bind mount
[13:59] <stgraber> ogra_: well, it USED to work :)
[13:59] <timothy> stgraber: on which version?
[14:01] <stgraber> timothy: 1.0.27.1 to 1.0.38-0ubuntu0.16.04.3
[14:02] <stgraber> timothy: so xenial-updates to xenial-proposed as far as what's in Ubuntu
[14:16] <mup> PR snapd#1603 closed: overlord/snapstate: ensure calls to store are done without the state lock held <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1603>
[14:22] <kyrofa> ogra_, is the ldd call causing issues?
[14:24] <tkamppeter> I am snapping CUPS currently
[14:26] <tkamppeter> I have now got together some basic snap: It starts CUPS as permanently running daemon and I have made all directories to where CUPS needs to write into $SNAP_DATA.
[14:26] <seb128> I wonder if I'm the only one "priming" doesn't convey much sense to, I keep having to think about what that dir/step does
[14:27] <tkamppeter> Problem now is that the CUPS daemon starts helper programs and these helper programs do not find the libraries contained in the snap.
[14:29] <tkamppeter> How can I make programs called by the snapped CUPS daemon find the libs of the snap?
[14:49] <ogra_> seb128, it used to be calles strip ... but someone found the naming nasty
[14:49] <ogra_> *called
[14:49] <seb128> yeah
[14:49] <seb128> strip has another standard use
[14:49] <seb128> but it could have been "prepare"
[14:49] <ogra_> yeah, they even have clubs for it
[14:50] <ogra_> and indeed it could have been prepare ... but thats probably not as hip as prime :)
[14:50] <seb128> I still don't understand what "prime" is
[14:51] <seb128> it might be because it's a word I never use in english
[14:51] <ogra_> it mangles symlinks, cheks dependencies with ldd and all such stuff
[14:52] <seb128> "prepare" would have made more sense
[14:52] <seb128> oh well, it has been renamed once I guess they are not renaming it again
[14:52] <ogra_> LOL !!!
[14:52] <ogra_> hahahahahaha
[14:52] <ogra_> if i now could find my access data for the quotes page
[14:52] <seb128> I need to hint somebody that the name sucks
[14:53] <seb128> lol
[14:53] <seb128> "somebody"
[14:53] <seb128> like seems like we are going to fix "app" which also sucked
[14:53] <ogra_> nothing is as unstable as any kind of naming in the snappy world
[14:53] <seb128> so why not prime... ;-)
[14:53] <ogra_> even in a few years when the code is rock solid and proven we will still see renames of functions, variables, commands etc i bet
[14:55] <ogra_> seb128, bring it up on the ML ... renaming it now will surely be easier than renaming it later
[14:55] <seb128> I might
[14:55] <mup> Bug #1576500 opened: Plasma fails to load:  "all shell packages missing" <amd64> <apport-bug> <xenial> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576500>
[14:57]  * ogra_ sighs ... looks like i'll spend my weekend in the basement fixing the heating ... as if it wasnt warm enough already i'll have to swing wrenches in a 40°C warm room for two days (or live with cold water)
[15:10] <mup> Bug #1607796 changed: snap-confine regression when running commands as root <lxd> <Snappy Launcher:In Progress by zyga> <https://launchpad.net/bugs/1607796>
[15:35] <bull> hi guys
[15:36] <bull> can our snapped application make a call to external application which is installed on our system ?
[15:37] <bull> popey,  can our snapped application make a call to external application which is installed on our system ?
[15:38] <bull> ogra_,  hi
[15:39] <seb128> bull, hey, they would need an interface for that
[15:39] <mup> PR snapcraft#698 opened: Add option disable-parallel for autotools plugin <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/698>
[15:39] <bull> we have such interface yet ???
[15:40] <seb128> not that I know of
[15:40] <bull> seb128, you talking to me ??
[15:42] <bull> guys my app is qt based and called gsetting to change system settings i snapped my app and it became useless since it was not able to make call to gsetting
[15:43] <seb128> bull, yes I'm taling to you, it uses the gsettings command line utility and not the glib api?
[15:44] <bull> no i use glib just for showing the tray icon in collaboration with libappindicator
[15:44] <bull> and i call gsetting using Qt's Qprocess lib
[15:46] <bull> a packaging format should not effect Qt's libs an sure , in this since its a snappy app it may be calling gsetting inside the app's container
[15:46] <bull> where it cant find gsettings
[15:46] <seb128> gsettings the api?
[15:46] <seb128> ah, the command line
[15:46] <bull> seb128, you can check my code on github https://github.com/keshavbhatt/Deskie
[15:47] <seb128> well you can stage-package libglib2.0-bin
[15:47] <bull> i am able to make snap package but it become useless :(
[15:47] <bull> app runs but wont work
[15:48] <bull> its a wallpaper changer , better and much powerful then variety
[15:48] <bull> seb128,  take a look http://www.ktechpit.com/deskie-wallpaper-changer-ubuntu-linux/
[15:48] <seb128> it's not sueless, it's secure
[15:49] <seb128> just include the binary
[15:50] <bull> what u talking about
[15:50] <bull> ?
[15:50] <bull> i packaged it in debian format it works fine there
[16:15] <mup> PR snapd#1605 opened: asserts: introduce support for assertions with no authority, first pass at serial-request <Created by pedronis> <https://github.com/snapcore/snapd/pull/1605>
[16:18] <ogra_> hmm, i wish we could have a zenmity part
[16:18] <ogra_> *zenity
[16:19] <ogra_> some of my apps generate config on first start, would be nice to be able to pop up a message or bouncy progress bar when that happens
[16:32] <kyrofa> ogra_, you need an install hook, so stuff like that would be part of the installation. No?
[16:32] <ogra_> kyrofa, well, since it usually happens on first start of the app, it would be a launch wrapper
[16:33] <ogra_> it is just that the first launch typically takes longer due to that
[16:33] <kyrofa> ogra_, but if it's only the first start, isn't it really part of the installation?
[16:33] <ogra_> the installation doesnt launch the app
[16:34] <ogra_> i'm talking about apps, not services
[16:34] <imexil> Hi. Does it make sense to use boths the x11 AND the unity7 plug or is unity7 simply x11+appmenu?
[16:34] <kyrofa> ogra_, of course. I do the same thing for nextcloud, but that's only because there's no way to say "I want to do this once"
[16:35] <kyrofa> ogra_, but you want to continue doing it upon first run even if that capability exists?
[16:36] <kyrofa> imexil, I typically use them both
[16:37] <ogra_> kyrofa, well, i check if the config file exists ... my code indeed only runs iif it does not :)
[16:37] <ogra_> so usually only once on first start
[16:37] <ogra_> the check if the file exists is cheap
[16:37] <ogra_> nothing that delays the start much
[16:40] <imexil> kyrofa:  well I'm trying to isolate a problem and since my my doesn't run with x11 but partly with unity7 I was wondering what is causing this.
[17:03] <artmello> Hi. I am trying to make a snap for gallery-app. It seems to be working but QStandardPaths::PicturesLocation seems to be pointing to ~/snap/gallery-app/x1/Pictures instead of ~/Pictures
[17:03] <artmello> how can I fix that?
[19:44] <sethj> does snap find fail with connection refused for anyone else?
[19:47] <sethj> oh, reinstalling snapd fixed it.
[19:56] <Saviq> g
[20:54] <tianon> jdstrand: should I embed rules that overlap with, for example, "network-bind" functionality in the "docker" interface, or should "dockerd" just plugs: for those bits?
[20:56] <tianon> jdstrand: it seems like "docker" ought to imply everything Docker itself needs on the slot end at least
[22:01] <hades|2> can i install http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/20160728/vivid-preinstalled-core-amd64.tar.gz and update later to xenial / 16.04 using snappy update / refresh ??
[22:08] <hades|2> or i should use rather  https://people.canonical.com/~mvo/all-snaps/16/all-snaps-amd64.img.xz ? ou ubuntu server 16.04 ?
[22:11] <hades|2> ???
[22:17] <tgm4883> Is there a way to specify the $SNAP variable in the snapcraft.yaml file?
[22:17] <tgm4883> specifically, I want to pull it not set it
[22:20] <ali1234> you mean the actual value of it?
[22:21] <ali1234> i don't think so, because you can't know what it is going to be until the snap gets installed
[22:23] <tgm4883> ali1234: yea that's what I was wondering
[22:24] <tgm4883> ali1234: because I think the issue I'm having is this app can't find the libraries because it's looking in the wrong place
[22:24] <ali1234> you have to make a wrapper script then
[22:26] <hades|2> what version of ubuntu-core should i use ?
[22:27] <tgm4883> ali1234: hmm, a wrapper that adds where the libraries are?
[22:27] <ali1234> yes, like the desktop-launch one
[22:28] <tgm4883> hmm ok
[22:29] <tgm4883> ali1234: what is $SNAP in this launcher?
[22:29] <ali1234> for example: export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/dri:$LD_LIBRARY_PATH
[22:29] <ali1234> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports
[22:29] <tgm4883> Yea I'm looking at that. I pull in desktop/qt5
[22:30] <tgm4883> I don't see where $SNAP is getting set though
[22:30] <ali1234> it is set by snapd
[22:30] <ali1234> actually it is set by the script that gets generated and put in to /snap/bin
[22:31] <tgm4883> ok, let me ask a different question. Where should I be installing the app to with --prefix
[22:31] <ali1234>  /
[22:32] <tgm4883> Hmm
[22:32] <ali1234> but you shouldn't have to worry about that
[22:32] <tgm4883> I'm not sure that's write. I think I was getting permissions issues when building when using that. But let me try again
[22:32] <ali1234> you are supposed to let the build plugin figure it out
[22:33] <tgm4883> ok, that's what I did on my last build
[22:33] <tgm4883> I commented out both --prefix and --runprefix
[22:33] <hades|2> can i use latest ubuntu-core vivid and update to ubuntu-core xenial later ? yes ? no ?
[22:35] <tgm4883> ali1234: when running ldd on one of the binaries, it should point to stuff inside the install directory right?
[22:36] <tgm4883> sorry if these questions are dumb, I don't compile much
[22:37] <ali1234> what are you trying to compile?
[22:38] <tgm4883> ali1234: mythtv
[22:39] <ali1234> frontend or backend?
[22:39] <tgm4883> ali1234: I've got it compiling and installing in the snap, but when I run it I get "This application failed to start because it could not find or load the Qt platform plugin "xcb"."
[22:39] <tgm4883> ali1234: currently frontend
[22:39] <tgm4883> since I think that is the lesser of 2 hurdles
[22:39] <ali1234> okay
[22:40] <ali1234> this i know quite a bit about
[22:40] <tgm4883> you know quite a bit about mythtv?
[22:40] <ali1234> i know a little bit about mythtv and a lot about Qt platform plugins
[22:40] <tgm4883> sweet :)
[22:40] <ali1234> so the platform plugin is the graphics backend for Qt basically
[22:41] <ali1234> xcb is the X11 one
[22:41] <tgm4883> ok
[22:41] <ali1234> i assume you didn't compile Qt yourself?
[22:41] <tgm4883> nope
[22:41] <tgm4883> Here's my snapcraft.yaml file so far https://github.com/tgm4883/mythtv-snap/blob/master/snapcraft.yaml
[22:43] <ali1234> okay i have never seen this "no-security" stuff before
[22:43] <tgm4883> ali1234: In the docs it mentioned that it just disabled everything
[22:43] <tgm4883> for testing I believe
[22:43] <ali1234> i do "sudo snap install --devmode whatever.snap"
[22:43] <ali1234> that seems to have the same effect
[22:43] <tgm4883> or maybe I got that from a different snap
[22:44] <tgm4883> ok, just installed with --devmode, same error on xcb
[22:44] <ali1234> can you pastebin find inside the installed snap?
[22:44] <ali1234> will be /snap/mythtv/current or somehting
[22:44] <tgm4883> yea
[22:45] <tgm4883> http://termbin.com/9f3b
[22:45] <tgm4883> inside /snap/mythtv/current
[22:46] <ali1234> ./usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
[22:46] <ali1234> that's the xcb platform plugin it claims to be looking for
[22:47] <tgm4883> ok, so that's good that it's there. Why can't it find it?
[22:47] <ali1234> hang on i need to turn on another computer to get to my Qt snaps
[22:48] <tgm4883> Does it search all subdirectories of a path in $LD_LIBRARY_PATH? I do see $SNAP/usr/lib/x86_64-linux-gnu in the wrapper file
[22:48] <ali1234> no
[22:49] <tgm4883> hmm
[22:49] <tgm4883> I don't see that directory then unless it's in the default $LD_LIBRARY_PATH
[22:49] <tgm4883> or in $SNAP_LIBRARY_PATH
[22:52] <ali1234> how long does this take to build?
[22:53] <tgm4883> not long, under 2 minutes
[22:53] <tgm4883> on my laptop anyway
[22:53] <tgm4883> in launchpad for the deb packages, it takes like a half hour
[22:54] <tgm4883> granted it's building more there, I'm not building the frontend plugins yet
[22:54] <ali1234> okay let me build this and see what it does
[22:55] <tgm4883> ok
[23:12] <ali1234> okay it's built
[23:14] <ali1234> oh, derp
[23:14] <tgm4883> ali1234: broken for you too?
[23:14] <ali1234> tgm4883: you included the desktop/qt5 but you didn't use the launcher script it provides
[23:15] <tgm4883> oh, didn't know I needed to. That was recommended to me last night (the desktop/qt5 stuff)
[23:16] <ali1234> it still doesn';t work, but the crash is totally different now
[23:16] <tgm4883> ali1234: heh, progress is progress I suppose
[23:17] <ali1234> 2016-07-30 00:17:18.478427 C  FATAL: Unable to load the QT mysql driver, is it installed?
[23:17] <ali1234> so you need to stage that next
[23:18] <ali1234> command: desktop-launch mythfrontend
[23:18] <ali1234> is what you need to get the library paths configured properly
[23:18] <tgm4883> that's what I need for the wrapper?
[23:18] <ali1234> yeah
[23:19] <tgm4883> ok, and staging the mysql package
[23:19] <ali1234> also i don't think it is necessary to specify build-essential in the build-packages
[23:19] <ali1234> and dependencies work like normal
[23:20] <ali1234> so generally that list is quite short
[23:20] <tgm4883> so then anything that is a dependency of the deb package should be in stage packages?
[23:20] <ali1234> direct dependencies yeah
[23:21] <ali1234> deps are pulled in recursively
[23:23] <tgm4883> ok, building again
[23:28] <tgm4883> ali1234: progress
[23:28] <tgm4883> QXcbConnection: Could not connect to display :0
[23:30] <tgm4883> forgot dev mode
[23:30] <tgm4883> holy crap it loaded
[23:42] <tgm4883> ali1234: this is awesome, it launches and works a little. Need to squash some other bugs, but this is way further than I was previously. Thanks