[00:17] dasjoe, that's probably a question for ogra_, but he's probably EOD by now (he's in Germany) [00:17] dasjoe, if you come by a few hours earlier tomorrow he'll probably be around, or you can send an email to the list [00:44] kyrofa: I see. We're pulling an all-nighter to get some stuff done. Oh well, I'll stick to netboot.tar.gz for now === JerryKao is now known as JerryKao_QTR [04:33] in devmode, do we still need to do manually connect for platform interface? [04:34] I am having a problem here. in devmode, even if the platform (Qt libs content sharing) interface is disconnected, my app still can run well. It really confuses me. [06:01] timp, recently, I just noticed that platform interface can be automatically connected. is this true？ [06:03] kalikiana_, is there any change on the platform interface? I find that now I do not need to manually connect the platform (qt content sharing interface) interface [06:55] I'm hitting https://launchpadlibrarian.net/310093787/buildlog_snap_ubuntu_xenial_amd64_juju-crashdump_BUILDING.txt.gz if anyone can help me debug that would be appreciated... [07:13] PR snapd#2996 opened: interfaces: fix default content attribute value (#2994) [07:14] PR snapd#2997 opened: hookstate: run the right "snap" command in the hookmanager (#2992) [07:35] PR snapd#2998 opened: tests: do not nuke the entire snapd.conf.d dir when changing store settings [07:43] PR snapd#2999 opened: snapstate: revert PR#2958, run configure hook again everywhere [07:43] PR snapd#3000 opened: snapstate: revert PR#2958, run configure hook again everywhere (2.23) [07:47] PR snapd#2991 closed: packaging: add opensuse permissions files [07:56] PR snapd#3001 opened: partition: deal with grub{,2}-editenv in tests [07:58] PR snapd#2989 closed: many: some opensuse patches that are ready to go into master [08:18] jdstrand, thanks for digging into it ... i'm traveling this week but will look into why the dragonboard does this once i'm home [08:46] PR snapd#3002 opened: Add support for dbus::ObjectManager session paths [09:12] PR snapd#2999 closed: snapstate: revert PR#2958, run configure hook again everywhere [09:13] PR snapd#2998 closed: tests: do not nuke the entire snapd.conf.d dir when changing store settings (2.23) [09:54] PR snapd#3003 opened: packaging, tests: use "systemctl list-unit-files --full" everywhere [09:55] meep [09:57] mvo, left feedback on https://github.com/snapcore/snapd/pull/3001 [09:57] PR snapd#3001: partition: deal with grub{,2}-editenv in tests [10:06] Son_Goku: \o/ [10:07] Son_Goku: makes perfect sense, I will fix it [10:07] the joys of GRUB, eh? [10:07] :P [10:07] we just dropped GRUB Legacy as an option for fresh installs in Mageia, so I *know* this can be a problem :/ [10:08] for whatever reason, some people seem to think GRUB Legacy is better than GRUB 2 :( [10:08] PR snapd#3000 closed: snapstate: revert PR#2958, run configure hook again everywhere (2.23) [10:19] liuxg: Can you elaborate? What has changed? [10:19] kalikiana_, it seems to be that the platform interface is automatically connected. [10:20] kalikiana_, just take a look at https://bugs.launchpad.net/snappy/+bug/1670371 [10:20] Bug #1670371: Configure hook breaks content interface plug [10:23] liuxg: So what exactly is the question here? Does the configure hook change the connection behavior of the ubuntu-app-platform? [10:24] The comments in the bug seem contradictory to me, so I feel I'm missing some context [10:24] kalikiana_, you may try a test app at https://github.com/ubuntu/snap-tutorials-code/tree/master/webapp-ubuntu/final. it does use the platform interface. It seems that I do not need to manually connect the interface [10:24] PR snapd#3004 opened: tests: do *not* nuke the entire snapd.conf.d dir when changing store settings [10:25] liuxg: That snap has no hooks... so it's an unrelated change then? [10:25] kalikiana_, yes, this one does not have the hooks. but it shows the change. [10:26] liuxg: So you can install it for the first time and it automatically connects? [10:26] PR snapd#2997 closed: hookstate: run the right "snap" command in the hookmanager (2.23) [10:26] liuxg That didn't work like 2 weeks ago I'm pretty sure [10:26] kalikiana_, yes, that is the case.. [10:27] liuxg: Did you by chance check if it also works if uap isn't installed? [10:27] Mirv, I am now developing a Qt tutorial. in the app, it needs to use qml and quick module. would you please add it the qt remove part? thanks The modules should be commonly used. [10:28] kalikiana_, what is uap? [10:28] kalikiana_, http://paste.ubuntu.com/24137373/ [10:28] liuxg: ubuntu-app-platform [10:29] kalikiana_, yes, it is installed.. [10:29] liuxg: That's pretty cool then [10:30] Will have to try it here [10:30] kalikiana_, what do you mean? so this is a designed feature for it? or it is a bug? [10:30] kalikiana_, ok. thanks [10:30] liuxg: those modules are in both Qt and u-a-p remote parts [10:30] liuxg: with u-a-p however you'll need to have the overlay PPA versions installed on your local machine to build, u-a-p is runtime only [10:31] Mirv, but when I compiled my Qt app, it complains that the modules are not there. [10:31] Mirv, I have install the overlay for sure.. [10:31] Mirv, I did it in a container, let me show you the result of it. [10:31] liuxg: qtdeclarative5-dev should have qml/quick development files [10:32] liuxg: however you need to specify whether you are using u-a-p or qt57/qt58 remote parts, which are different [10:32] Mirv, oh really? sorry, I do not know that. [10:32] liuxg: That's what was planned for a while, content iface snaps should be connected and downloaded automatically if needed [10:32] Mirv, what are the differences? [10:32] liuxg: if your tutorial is about app targeting Ubuntu Personal, you should probably be using u-a-p. if not targeting Ubuntu Personal, then maybe qt57/qt58 [10:33] liuxg: u-a-p has lots of Ubuntu specific things like UI Toolkit, qt57/qt58 are for pure Qt applications [10:33] Mirv, for my case, it is a ubuntu phone app [10:34] Mirv, so what should be the right thing to use? how to use it? [10:36] Mirv, this is the output from building my project http://paste.ubuntu.com/24137400/ [10:36] Mirv, the source code is at https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app [10:37] Mirv, just take the final version of it https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app/final [10:38] liuxg: for phone app, indeed use u-a-p (runtime) and install whatever is needed from overlay PPA when compiling, including qtdeclarative5-dev [10:39] Mirv, but the qml and quick are not there. I installed the phone overlay for sure. [10:39] liuxg: if you have qtdeclarative5-dev package installed, then I can't think of a reason it wouldn't find them when compiling. it works for me. [10:39] (on 16.04 LTS + overlay PPA) [10:41] Mirv, I used a 16.04 LTS container to build it. Inside it, I installed the overlay ppa [10:41] zbenjamin: ^ if you want to help [10:42] liuxg: ok [10:42] Mirv, if I manually install them, I can build it through. I just want to have it there from the remote part. that would be the best.. [10:43] liuxg: the remote part is for runtime, it's not related to build time. that why you need to install the dependencies where you build. [10:43] PR snapd#3003 closed: packaging, tests: use "systemctl list-unit-files --full" everywhere [10:44] liuxg: i assume you did run apt update and apt dist-upgrade after adding the overlay? [10:44] zbenjamin, I did [10:46] zbenjamin, I just did it once again, and it showed me the same error.. [10:46] what error [10:47] zbenjamin, http://paste.ubuntu.com/24137400/ [10:48] zbenjamin, basically, it complains that the qml and quick modules are not there.. [10:48] zbenjamin, the source code is at https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app/final [10:48] liuxg: try installing ubuntu-sdk-qmake-extras [10:49] zbenjamin, Mirv the problem is that it would be good to have it in the remote part so that developers do not worry to put the packages as build-packages in the snapcraft.yaml. [10:50] zbenjamin, Mirv, we can install the packages manually to resole the problem. the intention is to have it in the remote part. what do you think? [10:51] liuxg: you just said it's working for you when you install qtdeclarative5-dev. like I said, remote part is for runtime, it's not related to your local development environment. [10:52] liuxg: forget the remote part for build time... it has nothing to do with that. The remote part is just there to provide your modules at runtime [10:52] you still need to tell snapcraft the build deps [10:52] Mirv, if I understand correctly, the remote part will help to install some needed packages to the development environment, right? [10:52] liuxg: that is, currently remote part cannot specify extra build-package from what I know. if you want to contribute such a feature to snapd, that'd be great. [10:53] liuxg: no, it does not install needed packages [10:53] PR snapcraft#1175 opened: demo files for snaping the bitcoin-qt client [10:53] Mirv, didrocks, what do you think? [10:54] zbenjamin, didrocks, Mirv, I know. qml and quick module are so commonly used. I think it would be good idea to inclu.de it in the remote part as a dependence so that it can be installed automatically [10:56] liuxg: the 16.04 + overlay PPA requirement do make it quite manual anyway, but yes if adding to remote part works then not only those but everything included in runtime should be added [10:57] Mirv, for qt apps, qml + quick are just the basic modules. if they can be include, that would be the best :) [10:58] liuxg: basically all or nothing. so yes if can be added, also those will be added and everything that is included in the runtime. [11:00] Mirv, I have seen some modules are already there. but for the qml app support is not much. [11:01] liuxg: no actually there's nothing currently, only stage-packages [11:02] Mirv, will stage-packages be finally installed onto the development environment? [11:02] Mirv, if it works, can we add them into the stage-packages? [11:05] Mirv, it is just for building the project. I think it is not part of the runtime, am I right? having them in the stage-packages should be fine. what do you think? [11:07] liuxg: no, they are all in the stage-packages already, and nothing there helps in building the project [11:07] liuxg: what you might be missing is that there's "ubuntu-sdk-libs" in stage packages which means everything Qt you can think of [11:08] Mirv, how is it different from ubuntu-sdk-qmake-extras? [11:09] Mirv, in the error message, it says that the qml and quick are missing. build-packages is designed for setting up the build env, right? [11:10] liuxg: you can check both packages and see what they are, they are not related [11:10] Mirv, just now zbenjamin pointed that it was the ubuntu-sdk-qmake-extras. so, I just wanted to know the difference. [11:15] Mirv, do you mean that stage-packages will not install the packages into the development env? [11:15] liuxg: he was just thinking if you have missing dependencies locally, but it's not related [11:16] Mirv, OK. my question is whether stage-packages help to install the needed debian pacakges into the development env. if yes, we can add the packages for qml+quick [11:18] liuxg: no, it should be build-packages, and not in ubuntu-app-platform but in snapcraft-desktop-helpers. I think thought in the latter it could be expanded. [11:18] Mirv, sorry, I got wrong. I mean the build-pacakges :) [11:19] Mirv, clearly, qml+quick now are not in the build packages. [11:21] liuxg: yep, but it's indeed the snapcraft-desktop-helper where those are missing, not u-a-p. anyway, technical details to you, check again tomorrow, there might be something improved by then. [11:22] Mirv, thanks for helping.. we need the build packages for building apps :) [11:22] Mirv, once you get it done, please let me try it. [11:22] liuxg: ok [11:22] Mirv, thanks a lot! [11:25] Mirv, one more thing. I using uap for my qt/website apps. it shows the platform is connected, however, it always shows an error like http://paste.ubuntu.com/24137751/ [11:31] liuxg: that is unfortunately a snap bug, you need to ping zyga for the status of the bug [11:31] liuxg: it sometimes doesn't work correctly [11:31] Mirv, yes, it is very annoying [11:32] liuxg: I only find bug #1652369 now but I've seen a similar more visibly tracked bug too [11:32] Bug #1652369: Cannot connect to ubuntu-app-platform package on consecutive installs [11:32] liuxg: I agree [11:32] liuxg: right, this is the actual bug, in progress by zyga: https://bugs.launchpad.net/snappy/+bug/1645731 [11:32] Bug #1645731: Fail to access the shared content if app starts before connect interface [11:33] Mirv, yeah, I know the bug. it affects my creating of tutorial :( [11:35] Bug #1652369 changed: Cannot connect to ubuntu-app-platform package on consecutive installs [11:35] Bug #1671062 opened: Cannot open rocketchat-server on a VM [12:04] liuxg: Do you know the namespace work-around? At least that lets you fix it without re-installing the snap [12:05] kalikiana_, yes, I know the workaround. I still need to reinstall the snap,right? [12:05] anyway, I just make sure everything is right. remove clear install [12:06] liuxg: No you don't, that's the point [12:07] kalikiana_, ? [12:07] o/ [12:07] liuxg: You don't reinstall, that is the point of the work-around ;-) [12:07] kalikiana_, the solution is not stable sometimes. [12:11] PR snapd#3004 closed: tests: do *not* nuke the entire snapd.conf.d dir when changing store settings (2.23) [12:25] Mirv: not sure what you mean, but if yu add build-packages: it's part of the build definitions and it will installed what's needed [12:25] Mirv: remote parts are not for runtime, they are at build time [12:26] Mirv: so basically, you can specify such -dev packages (you already specify qtbase5-dev btw) [12:26] didrocks: yeah I just got got confused by the discussion spreading in many directions, you have a pull request already [12:27] Mirv: oh great! Didn't get to that yet. Thanks :) [12:28] Mirv: merged, many thanks! === tinwood_swap is now known as tinwood [12:44] PR snapd#2996 closed: interfaces: fix default content attribute value (2.23) [12:45] PR snapd#3005 opened: packaging, tests: use "systemctl list-unit-files --full" everywhere [12:52] thanks! [13:02] ogra_: thanks :) [13:06] jdstrand: hello [13:15] hey zyga :) [13:28] PR snapd#3005 closed: packaging, tests: use "systemctl list-unit-files --full" everywhere [13:35] PR snapcraft#1172 closed: demos, tests: add the mount-observe plug to be able to run godd [13:41] damn it zyga, you can't hide from me! :P [14:38] PR snapd#3006 opened: interfaces browser-support,mir,opengl,unityy: updates for mir-kiosk [14:39] pmcgowan: good news, ^ [14:39] pmcgowan: I was able to get the dragonboard setup and work through some policy issues. there are a couple of things you should be aware of though [14:40] jdstrand, listening [14:41] anybody got an idea how to fix https://launchpadlibrarian.net/310093787/buildlog_snap_ubuntu_xenial_amd64_juju-crashdump_BUILDING.txt.gz ? [14:41] pmcgowan: the first is that something in the webdemo snap is making it so that the first run succeeds, but all subsequent runs segfault. this is not caused by security policy denials. I resorted to doing this in webdemo: http://paste.ubuntu.com/24139053/ [14:41] pmcgowan: notice how if the script finds SNAP_USER_DATA, it removes a bunch of stuff [14:42] jdstrand, thats odd, I am not seeing that with y latest version [14:42] pmcgowan: I don't know which of those things is the problem, but something is saved so that the next time a different code path is taken (I think it starts to think X is around) and then it segfaults [14:42] pmcgowan: this is in strict mode [14:43] for both sides [14:43] ah ok, so I need to see [14:43] pmcgowan: but there are no denials, so it is weird [14:44] pmcgowan: the other thing is that webdemo wants to save stuff in XDG_RUNTIME_DIR. snapd correctly sets this to /run/user//snap.$SNAP_NAME, but snappy doesn't create that directory [14:44] just rename the demo to suicidal-browser ... done ... [14:44] pmcgowan: so webdemo tries to mkdir -p $XDG_RUNTIME_DIR [14:45] jdstrand, where does it do that? [14:45] pmcgowan: and while the policy correctly allows creation of /run/user//snap.$SNAP_NAME, it (correctly) does not allow creation of /run/user//, in this case /run/user/0 [14:45] pmcgowan: some library [14:45] it's a freedesktop thing [14:46] pmcgowan: so, the snap dies trying to create /run/user/0 [14:47] pmcgowan: if you do 'sudo mkdir -m 0700 /run/user/0' then start the snap, and have the policy from the above PR, then it all works in strict mode [14:47] jdstrand, but where is it that needs that folder? [14:47] pmcgowan: so, we had code for creating XDG_RUNTIME_DIR properly in a PR, but it was backed out. I need to track that down [14:47] jdstrand, is that just a snap bug? [14:48] pmcgowan: I don't know the specific library. it is a standard xdg thing. Somewhere in Qt [14:48] jdstrand, it seems to make a snap folder there, which hass nothing in it [14:48] not really getting how thats a qt thing [14:49] pmcgowan: it is just a snap bug. snappy should be doing it. zyga had concerns with how it was being done and that part of the XDG_RUNTIME_DIR PR was reverted. I don't recall the details, but I'll chase it down [14:49] ok [14:50] pmcgowan: it's a qt thing because how these libs are written is that if XDG_RUNTIME_DIR is not set, it uses a default value, if it is set, it uses that value. if the value doesn't exist, it creates it [14:50] PR snapd#3007 opened: merge the 2.23.1 release back into master [14:50] pmcgowan: but it isn't limited to qt. this is needed by some gnome stuff. eg, dconf [14:50] jdstrand, ok but not clear to me why it needs it? or is it just that it may need it [14:51] pmcgowan: I don't think it does need it (I never saw anything in there), it is just Qt making sure it is there in case your app needs it [14:51] right [14:52] it is being overly helpful in this case [14:52] normally, /run/user/ is going to be created by something in the user's session [14:52] that is not confined [14:52] jdstrand, I really want to retest once all the content interface issues are fixed as I am never sure if we are hitting those [14:52] cant youjust point it to /tmp as workaround ? [14:53] but we don't have a concept of user sessions in core, so nothing is doing that, so snappy needs to [14:53] ok [14:54] pmcgowan: you could adjust the wrapper script to do: [14:54] export XDG_RUNTIME_DIR=/tmp [14:54] like ogra_ said [14:55] jdstrand, in the latest snapd/core, can I try to run confined or do you have more to land? [14:55] jdstrand, I am using a shared helper so not sure I can override it [14:55] pmcgowan: yes, that content bug was annoying. I found myself doing this: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.webdemo-jdstrand.webdemo ; sudo service snap.webdemo-jdstrand.webdemo stop ; sudo /usr/lib/snapd/snap-discard-ns webdemo-jdstrand ; sudo service start snap.webdemo-jdstrand.webdemo [14:56] pmcgowan: that's a bit unwieldy ;) [14:56] wow [14:57] pmcgowan: you can test it yourself let me get you a paste [15:05] pmcgowan: http://paste.ubuntu.com/24139271/ [15:06] pmcgowan: note, snapd will periodically regenerate the profiles so you might have to re-add the apparmor rules [15:06] jdstrand, thanks I will try it later on, I updated my snap to run as a daemon again and support a configure script [15:06] pmcgowan: also, be sure to use a new enough core [15:06] jdstrand, stable core ok? [15:07] pmcgowan: yes, all of this is presupposing 'daemon: simple' [15:07] (that's why is 0 in /run/user/ ) [15:07] ah of course [15:08] pmcgowan: which brings me to my final point. there is a check in the review tools aboug using browser-support with 'daemon'. I'll be fixing that [15:09] jdstrand, I assume you added browser-support to the list of plugs? [15:09] pmcgowan: oh yes, I did [15:09] pmcgowan: and pulseaudio [15:09] jdstrand, yeah I saw why pulse? [15:10] pmcgowan: it was trying to use it so I put it there [15:10] pmcgowan: this is my snapcraft.yaml: http://paste.ubuntu.com/24139303/ [15:10] ok, prolly a browser things [15:11] pmcgowan: wc.wrapper is in bin/wc.wrapper and is http://paste.ubuntu.com/24139053/ (chmod 755) [15:11] pmcgowan: yeah [15:11] How do you get a --classic snap into the stable branch> [15:12] ? [15:12] jdstrand, ok will play around with it, did you need that mir-socket loop? I haent had an issue, and I worry about defining the socket path since the wrapper figures that out [15:12] pmcgowan: in all, I think kiosk with oxide is in really good shape in terms of snappy with that pr (XDG_RUNTIME_DIR notwithstanding, but that is easily worked around) [15:12] jdstrand, thanks a lot for hammering on it [15:13] pmcgowan: I just did it as a precaution. note that hardcoding it is basically ok cause the mir interface only allows that path [15:13] jdstrand, I thought there were two possible paths depending [15:13] pmcgowan: so it is set in stone for series 16 [15:13] oh [15:14] there is a second unprivileged one somewhere that is exposed when you have a session like unity8 [15:14] right I think thats what I recall [15:15] but the kiosk scenario found and used that one [15:15] (/run/mir_socket that is) [15:15] yep, so I will add it with some comments [15:16] pmcgowan: it might be worth double checking with the mir team if in the kiosk scenario /run/socket is what should be used. kgunn wrote this interface with kiosk in mind, so I suspect this is all correct [15:16] err, /run/mir_socket [15:19] pmcgowan: right, /run/user//mir_socket is what was used on Touch [15:20] pmcgowan: but for kiosk, it is /run/mir_socket. we probably need to adjust the interface to use /run/user//mir_socket, perhaps as an attribute, for things like the unity8-session snap (cc mterry and tedg) ^ [15:21] jdstrand: Oh, we changed that for you :-) [15:21] That way the mir interface would be generic. [15:21] tedg: oh. please give details and I'll update the comment in the interface [15:23] jdstrand: So the idea was that there was a standard mir interface, I think an attribute or something would work. [15:23] jdstrand: I think the change we made was to move it out of the unity8-session subdirectory as well. [15:23] jdstrand: Though if it was an attribute, we could keep it there. [15:24] tedg: I think I misunderstood. this is future stuff, not today stuff? (in terms of snapd) [15:29] tedg: sorry, if you responded, I missed it [15:29] jdstrand: No, I saw you disconnected, so I waited :-) [15:30] jdstrand: so I'm not sure what "future" and "today" is. But I'd be all for the mir interface having an attribute for the socket path. I think it'd give us good flexibility. [15:30] jdstrand: We really need interface hooks to apply it though, as apps would need to be able to turn that property into a MIR_SOCKET variable. [15:30] (on connection) [15:31] What's awesome about that is that an application switches from kiosk mode to unity8 mode based on who its mir interface is connected to. [15:31] * tedg has a dream of a calculator kiosk to compete with the TI-81 ;-) [15:35] tedg: heh, ok, cool, we are on the same page then. when unity8-session slots mir, we can discuss the attribute [15:42] didrocks: do you know if there's something special required to make snaps work that want to make HTTP requests using GIO? [15:44] didrocks: I have a silly little snap (http://paste.ubuntu.com/24139502/) that I've got as far as being able to show a UI, but when it tries to make any requests it says stuff like "** (telegnome:20336): WARNING **: http.vala:63: Unable to fetch 'http://www.ceefax.tv/cgi-bin/gfx.cgi?page=100_0&font=big&channel=bbc1': Operation not supported", which I think is GIO's way of saying that it doesn't ... [15:44] ... have the modules it needs to talk to that particular kind of GFile [15:47] cjwatson: hum, I didn't try this, but yeah, I bet that the warning is a consequence of a missing module for GIO, like gvfsd-http maybe? [15:48] sounds like it's in gvfs-backends [15:49] aha, that could be, I was thinking of gio rather than gvfs [15:49] yeah, but IIRC, it's using gvfs to transparently map to a file system access [15:49] which… I doubt strongly will work easily with snaps [15:49] (daemons outside, providing a path on the system…) [15:50] do you want me to have a deeper look as time permits? [15:51] I *thought* that gio was supposed to be able to talk HTTP itself without gvfs [15:51] but it's been a while since I imported that stuff into my brain [15:51] it's possible that my memory is blurry and you are right. I would need to dig into the glib code [15:51] yeah, if you have any time to have a look I'd appreciate it - it's totally not urgent for my thing which is unimportant, but maybe it affects other snaps too? [15:52] or things that aren't yet snaps but could be [15:52] yeah, I guess [15:52] ok, adding to my list :) [15:52] cheers [15:52] yw! I'll keep you posted (probably next week) [15:52] sure, np [16:10] PR snapd#3008 opened: testutils: address review feedback from PR#2997 [16:32] hello world [16:32] popeytest, that appears successful [16:45] *sigh* [16:46] Curious [16:52] Is anyone here using tpaws blender snap? [16:53] HumbleBeaver, I'm not using it anyway-- is something wrong? [16:54] kyrofa, It has a massive slow down when working with larger files. Like its not accessing the GPU [16:58] Was curious if anyone else was using it on a daily basis, I don't have the same issue with the non-snaped version. [16:58] HumbleBeaver, hmm, yeah I'm not sure [16:58] probably GPU related ... we used to have issues with nvidia and the GL interface in the past [16:58] (not sure if all bits have been sorted yet) [17:00] HumbleBeaver, I'd suggest logging a bug against the snap in question, but the URL in the snap seems to be invalid [17:01] HumbleBeaver, looks like this might be it: https://github.com/TPaw/TPawSnaps [17:02] HumbleBeaver, and it's README seems to confirm your suspicions: https://github.com/TPaw/TPawSnaps/tree/master/snaps/blender [17:03] At least... I think that's what is meant by SoftwareGL mode [17:05] Thanks, kyrofa, I'll send him a request for an update. [17:23] I'm guessing this bug https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1662357 is causing the launchpad build to fail for https://launchpadlibrarian.net/310093787/buildlog_snap_ubuntu_xenial_amd64_juju-crashdump_BUILDING.txt.gz, is that correct or am I off base? [17:23] Bug #1662357: Can't use lsb_release on Ubuntu Core 16 [17:24] lutostag, builds on LP don't happen within Ubuntu Core [17:24] so its still calling lsb_release -a on the xenial system as a whole which is seemingly falling over [17:25] lutostag, indeed, perhaps cjwatson has some insight there [17:30] lutostag: no idea why that would fail; it should work. have you tried it in snapcraft cleanbuild on a non-Ubuntu-Core system? [17:31] cjwatson: yeah local builds are 100% fine [17:31] yakkety on xenial lxds [17:31] (yakkety host) w/ xenial lxds [17:32] lutostag: I guess file a bug on launchpad-buildd to start with, though not quite sure when I'll find time :-/ [17:33] cjwatson: yeah I thought it was a borked core-16 release build w/ lsb_release, but if that's not the case not an 'easy' fix, will file [17:35]