| kyrofa | dasjoe, that's probably a question for ogra_, but he's probably EOD by now (he's in Germany) | 00:17 |
|---|---|---|
| kyrofa | 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:17 |
| dasjoe | 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 | 00:44 |
| === JerryKao is now known as JerryKao_QTR | ||
| liuxg | in devmode, do we still need to do manually connect for platform interface? | 04:33 |
| liuxg | 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. | 04:34 |
| liuxg | timp, recently, I just noticed that platform interface can be automatically connected. is this true？ | 06:01 |
| liuxg | 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:03 |
| lutostag | 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... | 06:55 |
| mup | PR snapd#2996 opened: interfaces: fix default content attribute value (#2994) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2996> | 07:13 |
| mup | PR snapd#2997 opened: hookstate: run the right "snap" command in the hookmanager (#2992) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2997> | 07:14 |
| mup | PR snapd#2998 opened: tests: do not nuke the entire snapd.conf.d dir when changing store settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/2998> | 07:35 |
| mup | PR snapd#2999 opened: snapstate: revert PR#2958, run configure hook again everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/2999> | 07:43 |
| mup | PR snapd#3000 opened: snapstate: revert PR#2958, run configure hook again everywhere (2.23) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3000> | 07:43 |
| mup | PR snapd#2991 closed: packaging: add opensuse permissions files <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2991> | 07:47 |
| mup | PR snapd#3001 opened: partition: deal with grub{,2}-editenv in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3001> | 07:56 |
| mup | PR snapd#2989 closed: many: some opensuse patches that are ready to go into master <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2989> | 07:58 |
| ogra_ | 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:18 |
| mup | PR snapd#3002 opened: Add support for dbus::ObjectManager session paths <Created by vosst> <https://github.com/snapcore/snapd/pull/3002> | 08:46 |
| mup | PR snapd#2999 closed: snapstate: revert PR#2958, run configure hook again everywhere <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2999> | 09:12 |
| mup | PR snapd#2998 closed: tests: do not nuke the entire snapd.conf.d dir when changing store settings (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2998> | 09:13 |
| mup | PR snapd#3003 opened: packaging, tests: use "systemctl list-unit-files --full" everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/3003> | 09:54 |
| Son_Goku | meep | 09:55 |
| Son_Goku | mvo, left feedback on https://github.com/snapcore/snapd/pull/3001 | 09:57 |
| mup | PR snapd#3001: partition: deal with grub{,2}-editenv in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3001> | 09:57 |
| mvo | Son_Goku: \o/ | 10:06 |
| mvo | Son_Goku: makes perfect sense, I will fix it | 10:07 |
| Son_Goku | the joys of GRUB, eh? | 10:07 |
| Son_Goku | :P | 10:07 |
| Son_Goku | we just dropped GRUB Legacy as an option for fresh installs in Mageia, so I *know* this can be a problem :/ | 10:07 |
| Son_Goku | for whatever reason, some people seem to think GRUB Legacy is better than GRUB 2 :( | 10:08 |
| mup | PR snapd#3000 closed: snapstate: revert PR#2958, run configure hook again everywhere (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3000> | 10:08 |
| kalikiana_ | liuxg: Can you elaborate? What has changed? | 10:19 |
| liuxg | kalikiana_, it seems to be that the platform interface is automatically connected. | 10:19 |
| liuxg | kalikiana_, just take a look at https://bugs.launchpad.net/snappy/+bug/1670371 | 10:20 |
| mup | Bug #1670371: Configure hook breaks content interface plug <Snappy:Confirmed> <https://launchpad.net/bugs/1670371> | 10:20 |
| kalikiana_ | liuxg: So what exactly is the question here? Does the configure hook change the connection behavior of the ubuntu-app-platform? | 10:23 |
| kalikiana_ | The comments in the bug seem contradictory to me, so I feel I'm missing some context | 10:24 |
| liuxg | 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 |
| mup | PR snapd#3004 opened: tests: do *not* nuke the entire snapd.conf.d dir when changing store settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/3004> | 10:24 |
| kalikiana_ | liuxg: That snap has no hooks... so it's an unrelated change then? | 10:25 |
| liuxg | kalikiana_, yes, this one does not have the hooks. but it shows the change. | 10:25 |
| kalikiana_ | liuxg: So you can install it for the first time and it automatically connects? | 10:26 |
| mup | PR snapd#2997 closed: hookstate: run the right "snap" command in the hookmanager (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2997> | 10:26 |
| kalikiana_ | liuxg That didn't work like 2 weeks ago I'm pretty sure | 10:26 |
| liuxg | kalikiana_, yes, that is the case.. | 10:26 |
| kalikiana_ | liuxg: Did you by chance check if it also works if uap isn't installed? | 10:27 |
| liuxg | 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:27 |
| liuxg | kalikiana_, what is uap? | 10:28 |
| liuxg | kalikiana_, http://paste.ubuntu.com/24137373/ | 10:28 |
| kalikiana_ | liuxg: ubuntu-app-platform | 10:28 |
| liuxg | kalikiana_, yes, it is installed.. | 10:29 |
| kalikiana_ | liuxg: That's pretty cool then | 10:29 |
| kalikiana_ | Will have to try it here | 10:30 |
| liuxg | kalikiana_, what do you mean? so this is a designed feature for it? or it is a bug? | 10:30 |
| liuxg | kalikiana_, ok. thanks | 10:30 |
| Mirv | liuxg: those modules are in both Qt and u-a-p remote parts | 10:30 |
| Mirv | 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:30 |
| liuxg | Mirv, but when I compiled my Qt app, it complains that the modules are not there. | 10:31 |
| liuxg | Mirv, I have install the overlay for sure.. | 10:31 |
| liuxg | Mirv, I did it in a container, let me show you the result of it. | 10:31 |
| Mirv | liuxg: qtdeclarative5-dev should have qml/quick development files | 10:31 |
| Mirv | liuxg: however you need to specify whether you are using u-a-p or qt57/qt58 remote parts, which are different | 10:32 |
| liuxg | Mirv, oh really? sorry, I do not know that. | 10:32 |
| kalikiana_ | liuxg: That's what was planned for a while, content iface snaps should be connected and downloaded automatically if needed | 10:32 |
| liuxg | Mirv, what are the differences? | 10:32 |
| Mirv | 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:32 |
| Mirv | liuxg: u-a-p has lots of Ubuntu specific things like UI Toolkit, qt57/qt58 are for pure Qt applications | 10:33 |
| liuxg | Mirv, for my case, it is a ubuntu phone app | 10:33 |
| liuxg | Mirv, so what should be the right thing to use? how to use it? | 10:34 |
| liuxg | Mirv, this is the output from building my project http://paste.ubuntu.com/24137400/ | 10:36 |
| liuxg | Mirv, the source code is at https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app | 10:36 |
| liuxg | Mirv, just take the final version of it https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app/final | 10:37 |
| Mirv | liuxg: for phone app, indeed use u-a-p (runtime) and install whatever is needed from overlay PPA when compiling, including qtdeclarative5-dev | 10:38 |
| liuxg | Mirv, but the qml and quick are not there. I installed the phone overlay for sure. | 10:39 |
| Mirv | 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 |
| Mirv | (on 16.04 LTS + overlay PPA) | 10:39 |
| liuxg | Mirv, I used a 16.04 LTS container to build it. Inside it, I installed the overlay ppa | 10:41 |
| Mirv | zbenjamin: ^ if you want to help | 10:41 |
| Mirv | liuxg: ok | 10:42 |
| liuxg | 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:42 |
| Mirv | 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 |
| mup | PR snapd#3003 closed: packaging, tests: use "systemctl list-unit-files --full" everywhere <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3003> | 10:43 |
| zbenjamin | liuxg: i assume you did run apt update and apt dist-upgrade after adding the overlay? | 10:44 |
| liuxg | zbenjamin, I did | 10:44 |
| liuxg | zbenjamin, I just did it once again, and it showed me the same error.. | 10:46 |
| zbenjamin | what error | 10:46 |
| liuxg | zbenjamin, http://paste.ubuntu.com/24137400/ | 10:47 |
| liuxg | zbenjamin, basically, it complains that the qml and quick modules are not there.. | 10:48 |
| liuxg | zbenjamin, the source code is at https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app/final | 10:48 |
| zbenjamin | liuxg: try installing ubuntu-sdk-qmake-extras | 10:48 |
| liuxg | 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:49 |
| liuxg | 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:50 |
| Mirv | 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:51 |
| zbenjamin | 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 |
| zbenjamin | you still need to tell snapcraft the build deps | 10:52 |
| liuxg | Mirv, if I understand correctly, the remote part will help to install some needed packages to the development environment, right? | 10:52 |
| Mirv | 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:52 |
| Mirv | liuxg: no, it does not install needed packages | 10:53 |
| mup | PR snapcraft#1175 opened: demo files for snaping the bitcoin-qt client <Created by torusJKL> <https://github.com/snapcore/snapcraft/pull/1175> | 10:53 |
| liuxg | Mirv, didrocks, what do you think? | 10:53 |
| liuxg | 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:54 |
| Mirv | 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:56 |
| liuxg | Mirv, for qt apps, qml + quick are just the basic modules. if they can be include, that would be the best :) | 10:57 |
| Mirv | liuxg: basically all or nothing. so yes if can be added, also those will be added and everything that is included in the runtime. | 10:58 |
| liuxg | Mirv, I have seen some modules are already there. but for the qml app support is not much. | 11:00 |
| Mirv | liuxg: no actually there's nothing currently, only stage-packages | 11:01 |
| liuxg | Mirv, will stage-packages be finally installed onto the development environment? | 11:02 |
| liuxg | Mirv, if it works, can we add them into the stage-packages? | 11:02 |
| liuxg | 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:05 |
| Mirv | liuxg: no, they are all in the stage-packages already, and nothing there helps in building the project | 11:07 |
| Mirv | 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:07 |
| liuxg | Mirv, how is it different from ubuntu-sdk-qmake-extras? | 11:08 |
| liuxg | 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:09 |
| Mirv | liuxg: you can check both packages and see what they are, they are not related | 11:10 |
| liuxg | Mirv, just now zbenjamin pointed that it was the ubuntu-sdk-qmake-extras. so, I just wanted to know the difference. | 11:10 |
| liuxg | Mirv, do you mean that stage-packages will not install the packages into the development env? | 11:15 |
| Mirv | liuxg: he was just thinking if you have missing dependencies locally, but it's not related | 11:15 |
| liuxg | 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:16 |
| Mirv | 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 |
| liuxg | Mirv, sorry, I got wrong. I mean the build-pacakges :) | 11:18 |
| liuxg | Mirv, clearly, qml+quick now are not in the build packages. | 11:19 |
| Mirv | 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:21 |
| liuxg | Mirv, thanks for helping.. we need the build packages for building apps :) | 11:22 |
| liuxg | Mirv, once you get it done, please let me try it. | 11:22 |
| Mirv | liuxg: ok | 11:22 |
| liuxg | Mirv, thanks a lot! | 11:22 |
| liuxg | 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:25 |
| Mirv | liuxg: that is unfortunately a snap bug, you need to ping zyga for the status of the bug | 11:31 |
| Mirv | liuxg: it sometimes doesn't work correctly | 11:31 |
| liuxg | Mirv, yes, it is very annoying | 11:31 |
| Mirv | liuxg: I only find bug #1652369 now but I've seen a similar more visibly tracked bug too | 11:32 |
| mup | Bug #1652369: Cannot connect to ubuntu-app-platform package on consecutive installs <Snappy:New> <https://launchpad.net/bugs/1652369> | 11:32 |
| Mirv | liuxg: I agree | 11:32 |
| Mirv | liuxg: right, this is the actual bug, in progress by zyga: https://bugs.launchpad.net/snappy/+bug/1645731 | 11:32 |
| mup | Bug #1645731: Fail to access the shared content if app starts before connect interface <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:In Progress by zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731> | 11:32 |
| liuxg | Mirv, yeah, I know the bug. it affects my creating of tutorial :( | 11:33 |
| mup | Bug #1652369 changed: Cannot connect to ubuntu-app-platform package on consecutive installs <Snappy:New> <https://launchpad.net/bugs/1652369> | 11:35 |
| mup | Bug #1671062 opened: Cannot open rocketchat-server on a VM <Snappy:New> <https://launchpad.net/bugs/1671062> | 11:35 |
| kalikiana_ | liuxg: Do you know the namespace work-around? At least that lets you fix it without re-installing the snap | 12:04 |
| liuxg | kalikiana_, yes, I know the workaround. I still need to reinstall the snap,right? | 12:05 |
| liuxg | anyway, I just make sure everything is right. remove clear install | 12:05 |
| kalikiana_ | liuxg: No you don't, that's the point | 12:06 |
| liuxg | kalikiana_, ? | 12:07 |
| zyga | o/ | 12:07 |
| kalikiana_ | liuxg: You don't reinstall, that is the point of the work-around ;-) | 12:07 |
| liuxg | kalikiana_, the solution is not stable sometimes. | 12:07 |
| mup | PR snapd#3004 closed: tests: do *not* nuke the entire snapd.conf.d dir when changing store settings (2.23) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3004> | 12:11 |
| didrocks | 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 |
| didrocks | Mirv: remote parts are not for runtime, they are at build time | 12:25 |
| didrocks | Mirv: so basically, you can specify such -dev packages (you already specify qtbase5-dev btw) | 12:26 |
| Mirv | didrocks: yeah I just got got confused by the discussion spreading in many directions, you have a pull request already | 12:26 |
| didrocks | Mirv: oh great! Didn't get to that yet. Thanks :) | 12:27 |
| didrocks | Mirv: merged, many thanks! | 12:28 |
| === tinwood_swap is now known as tinwood | ||
| mup | PR snapd#2996 closed: interfaces: fix default content attribute value (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2996> | 12:44 |
| mup | PR snapd#3005 opened: packaging, tests: use "systemctl list-unit-files --full" everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/3005> | 12:45 |
| Mirv | thanks! | 12:52 |
| jdstrand | ogra_: thanks :) | 13:02 |
| zyga | jdstrand: hello | 13:06 |
| jdstrand | hey zyga :) | 13:15 |
| mup | PR snapd#3005 closed: packaging, tests: use "systemctl list-unit-files --full" everywhere <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3005> | 13:28 |
| mup | PR snapcraft#1172 closed: demos, tests: add the mount-observe plug to be able to run godd <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1172> | 13:35 |
| Son_Goku | damn it zyga, you can't hide from me! :P | 13:41 |
| mup | PR snapd#3006 opened: interfaces browser-support,mir,opengl,unityy: updates for mir-kiosk <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3006> | 14:38 |
| jdstrand | pmcgowan: good news, ^ | 14:39 |
| jdstrand | 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:39 |
| pmcgowan | jdstrand, listening | 14:40 |
| lutostag | anybody got an idea how to fix https://launchpadlibrarian.net/310093787/buildlog_snap_ubuntu_xenial_amd64_juju-crashdump_BUILDING.txt.gz ? | 14:41 |
| jdstrand | 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 |
| jdstrand | pmcgowan: notice how if the script finds SNAP_USER_DATA, it removes a bunch of stuff | 14:41 |
| pmcgowan | jdstrand, thats odd, I am not seeing that with y latest version | 14:42 |
| jdstrand | 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 |
| jdstrand | pmcgowan: this is in strict mode | 14:42 |
| jdstrand | for both sides | 14:43 |
| pmcgowan | ah ok, so I need to see | 14:43 |
| jdstrand | pmcgowan: but there are no denials, so it is weird | 14:43 |
| jdstrand | pmcgowan: the other thing is that webdemo wants to save stuff in XDG_RUNTIME_DIR. snapd correctly sets this to /run/user/<uid>/snap.$SNAP_NAME, but snappy doesn't create that directory | 14:44 |
| ogra_ | just rename the demo to suicidal-browser ... done ... | 14:44 |
| jdstrand | pmcgowan: so webdemo tries to mkdir -p $XDG_RUNTIME_DIR | 14:44 |
| pmcgowan | jdstrand, where does it do that? | 14:45 |
| jdstrand | pmcgowan: and while the policy correctly allows creation of /run/user/<uid>/snap.$SNAP_NAME, it (correctly) does not allow creation of /run/user/<uid>/, in this case /run/user/0 | 14:45 |
| jdstrand | pmcgowan: some library | 14:45 |
| jdstrand | it's a freedesktop thing | 14:45 |
| jdstrand | pmcgowan: so, the snap dies trying to create /run/user/0 | 14:46 |
| jdstrand | 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 |
| pmcgowan | jdstrand, but where is it that needs that folder? | 14:47 |
| jdstrand | 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 |
| pmcgowan | jdstrand, is that just a snap bug? | 14:47 |
| jdstrand | pmcgowan: I don't know the specific library. it is a standard xdg thing. Somewhere in Qt | 14:48 |
| pmcgowan | jdstrand, it seems to make a snap folder there, which hass nothing in it | 14:48 |
| pmcgowan | not really getting how thats a qt thing | 14:48 |
| jdstrand | 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 |
| pmcgowan | ok | 14:49 |
| jdstrand | 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 |
| mup | PR snapd#3007 opened: merge the 2.23.1 release back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3007> | 14:50 |
| jdstrand | pmcgowan: but it isn't limited to qt. this is needed by some gnome stuff. eg, dconf | 14:50 |
| pmcgowan | jdstrand, ok but not clear to me why it needs it? or is it just that it may need it | 14:50 |
| jdstrand | 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 |
| pmcgowan | right | 14:51 |
| jdstrand | it is being overly helpful in this case | 14:52 |
| jdstrand | normally, /run/user/<uid> is going to be created by something in the user's session | 14:52 |
| jdstrand | that is not confined | 14:52 |
| pmcgowan | 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 |
| ogra_ | cant youjust point it to /tmp as workaround ? | 14:52 |
| jdstrand | but we don't have a concept of user sessions in core, so nothing is doing that, so snappy needs to | 14:53 |
| pmcgowan | ok | 14:53 |
| jdstrand | pmcgowan: you could adjust the wrapper script to do: | 14:54 |
| jdstrand | export XDG_RUNTIME_DIR=/tmp | 14:54 |
| jdstrand | like ogra_ said | 14:54 |
| pmcgowan | jdstrand, in the latest snapd/core, can I try to run confined or do you have more to land? | 14:55 |
| pmcgowan | jdstrand, I am using a shared helper so not sure I can override it | 14:55 |
| jdstrand | 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:55 |
| jdstrand | pmcgowan: that's a bit unwieldy ;) | 14:56 |
| pmcgowan | wow | 14:56 |
| jdstrand | pmcgowan: you can test it yourself let me get you a paste | 14:57 |
| jdstrand | pmcgowan: http://paste.ubuntu.com/24139271/ | 15:05 |
| jdstrand | pmcgowan: note, snapd will periodically regenerate the profiles so you might have to re-add the apparmor rules | 15:06 |
| pmcgowan | 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 |
| jdstrand | pmcgowan: also, be sure to use a new enough core | 15:06 |
| pmcgowan | jdstrand, stable core ok? | 15:06 |
| jdstrand | pmcgowan: yes, all of this is presupposing 'daemon: simple' | 15:07 |
| jdstrand | (that's why <uid> is 0 in /run/user/<uid> ) | 15:07 |
| pmcgowan | ah of course | 15:07 |
| jdstrand | 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:08 |
| pmcgowan | jdstrand, I assume you added browser-support to the list of plugs? | 15:09 |
| jdstrand | pmcgowan: oh yes, I did | 15:09 |
| jdstrand | pmcgowan: and pulseaudio | 15:09 |
| pmcgowan | jdstrand, yeah I saw why pulse? | 15:09 |
| jdstrand | pmcgowan: it was trying to use it so I put it there | 15:10 |
| jdstrand | pmcgowan: this is my snapcraft.yaml: http://paste.ubuntu.com/24139303/ | 15:10 |
| pmcgowan | ok, prolly a browser things | 15:10 |
| jdstrand | pmcgowan: wc.wrapper is in bin/wc.wrapper and is http://paste.ubuntu.com/24139053/ (chmod 755) | 15:11 |
| jdstrand | pmcgowan: yeah | 15:11 |
| Rumple | How do you get a --classic snap into the stable branch> | 15:11 |
| Rumple | ? | 15:12 |
| pmcgowan | 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 |
| jdstrand | 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 |
| pmcgowan | jdstrand, thanks a lot for hammering on it | 15:12 |
| jdstrand | 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 |
| pmcgowan | jdstrand, I thought there were two possible paths depending | 15:13 |
| jdstrand | pmcgowan: so it is set in stone for series 16 | 15:13 |
| pmcgowan | oh | 15:13 |
| jdstrand | there is a second unprivileged one somewhere that is exposed when you have a session like unity8 | 15:14 |
| pmcgowan | right I think thats what I recall | 15:14 |
| jdstrand | but the kiosk scenario found and used that one | 15:15 |
| jdstrand | (/run/mir_socket that is) | 15:15 |
| pmcgowan | yep, so I will add it with some comments | 15:15 |
| jdstrand | 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 |
| jdstrand | err, /run/mir_socket | 15:16 |
| jdstrand | pmcgowan: right, /run/user/<uid>/mir_socket is what was used on Touch | 15:19 |
| jdstrand | pmcgowan: but for kiosk, it is /run/mir_socket. we probably need to adjust the interface to use /run/user/<uid>/mir_socket, perhaps as an attribute, for things like the unity8-session snap (cc mterry and tedg) ^ | 15:20 |
| tedg | jdstrand: Oh, we changed that for you :-) | 15:21 |
| tedg | That way the mir interface would be generic. | 15:21 |
| jdstrand | tedg: oh. please give details and I'll update the comment in the interface | 15:21 |
| tedg | jdstrand: So the idea was that there was a standard mir interface, I think an attribute or something would work. | 15:23 |
| tedg | jdstrand: I think the change we made was to move it out of the unity8-session subdirectory as well. | 15:23 |
| tedg | jdstrand: Though if it was an attribute, we could keep it there. | 15:23 |
| jdstrand | tedg: I think I misunderstood. this is future stuff, not today stuff? (in terms of snapd) | 15:24 |
| jdstrand | tedg: sorry, if you responded, I missed it | 15:29 |
| tedg | jdstrand: No, I saw you disconnected, so I waited :-) | 15:29 |
| tedg | 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 |
| tedg | 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 |
| tedg | (on connection) | 15:30 |
| tedg | 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:31 | |
| jdstrand | tedg: heh, ok, cool, we are on the same page then. when unity8-session slots mir, we can discuss the attribute | 15:35 |
| cjwatson | didrocks: do you know if there's something special required to make snaps work that want to make HTTP requests using GIO? | 15:42 |
| cjwatson | 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 |
| cjwatson | ... have the modules it needs to talk to that particular kind of GFile | 15:44 |
| didrocks | 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:47 |
| didrocks | sounds like it's in gvfs-backends | 15:48 |
| cjwatson | aha, that could be, I was thinking of gio rather than gvfs | 15:49 |
| didrocks | yeah, but IIRC, it's using gvfs to transparently map to a file system access | 15:49 |
| didrocks | which… I doubt strongly will work easily with snaps | 15:49 |
| didrocks | (daemons outside, providing a path on the system…) | 15:49 |
| didrocks | do you want me to have a deeper look as time permits? | 15:50 |
| cjwatson | I *thought* that gio was supposed to be able to talk HTTP itself without gvfs | 15:51 |
| cjwatson | but it's been a while since I imported that stuff into my brain | 15:51 |
| didrocks | it's possible that my memory is blurry and you are right. I would need to dig into the glib code | 15:51 |
| cjwatson | 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:51 |
| cjwatson | or things that aren't yet snaps but could be | 15:52 |
| didrocks | yeah, I guess | 15:52 |
| didrocks | ok, adding to my list :) | 15:52 |
| cjwatson | cheers | 15:52 |
| didrocks | yw! I'll keep you posted (probably next week) | 15:52 |
| cjwatson | sure, np | 15:52 |
| mup | PR snapd#3008 opened: testutils: address review feedback from PR#2997 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3008> | 16:10 |
| popeytest | hello world | 16:32 |
| kyrofa | popeytest, that appears successful | 16:32 |
| owen_ | *sigh* | 16:45 |
| benjamin_ | Curious | 16:46 |
| HumbleBeaver | Is anyone here using tpaws blender snap? | 16:52 |
| kyrofa | HumbleBeaver, I'm not using it anyway-- is something wrong? | 16:53 |
| HumbleBeaver | kyrofa, It has a massive slow down when working with larger files. Like its not accessing the GPU | 16:54 |
| HumbleBeaver | 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 |
| kyrofa | HumbleBeaver, hmm, yeah I'm not sure | 16:58 |
| ogra_ | probably GPU related ... we used to have issues with nvidia and the GL interface in the past | 16:58 |
| ogra_ | (not sure if all bits have been sorted yet) | 16:58 |
| kyrofa | HumbleBeaver, I'd suggest logging a bug against the snap in question, but the URL in the snap seems to be invalid | 17:00 |
| kyrofa | HumbleBeaver, looks like this might be it: https://github.com/TPaw/TPawSnaps | 17:01 |
| kyrofa | HumbleBeaver, and it's README seems to confirm your suspicions: https://github.com/TPaw/TPawSnaps/tree/master/snaps/blender | 17:02 |
| kyrofa | At least... I think that's what is meant by SoftwareGL mode | 17:03 |
| HumbleBeaver | Thanks, kyrofa, I'll send him a request for an update. | 17:05 |
| lutostag | 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 |
| mup | Bug #1662357: Can't use lsb_release on Ubuntu Core 16 <lsb:Confirmed> <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662357> | 17:23 |
| kyrofa | lutostag, builds on LP don't happen within Ubuntu Core | 17:24 |
| lutostag | so its still calling lsb_release -a on the xenial system as a whole which is seemingly falling over | 17:24 |
| kyrofa | lutostag, indeed, perhaps cjwatson has some insight there | 17:25 |
| cjwatson | lutostag: no idea why that would fail; it should work. have you tried it in snapcraft cleanbuild on a non-Ubuntu-Core system? | 17:30 |
| lutostag | cjwatson: yeah local builds are 100% fine | 17:31 |
| lutostag | yakkety on xenial lxds | 17:31 |
| lutostag | (yakkety host) w/ xenial lxds | 17:31 |
| cjwatson | lutostag: I guess file a bug on launchpad-buildd to start with, though not quite sure when I'll find time :-/ | 17:32 |
| lutostag | 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:33 |
| cjwatson | you can deploy a Launchpad builder unit using https://jujucharms.com/u/launchpad/launchpad-buildd (for some reason you have to be logged into the charm store to see that URL), but working out how to operate it is still a bit of a chore | 17:35 |
| cjwatson | (that's not how real builders are deployed, but it's good enough for most purposes) | 17:36 |
| mup | PR snapd#3009 opened: interfaces/builtin: small refactor of dbus tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3009> | 17:43 |
| kyrofa | Hey kgunn, I need some qmake advice if you have a sec? | 17:59 |
| nacc | stokachu: did you end up doing the conjure-up transition from deb to snap? istr you talking about it in here a while ago | 18:27 |
| stokachu | nacc: yea we're full on snap now | 18:28 |
| stokachu | nacc: if you see documentation that still mentions the ppa way to install lemme know | 18:28 |
| stokachu | needs to be updated | 18:29 |
| nacc | stokachu: oh i was just curious if you did packaging changes to transition / how you went about it | 18:29 |
| nacc | stokachu: as in, did you forcibly install the snap via a postinst of the dummy package or something? | 18:29 |
| stokachu | nacc: yea i basically put a postinst in the deb package to say "remove this, snap install conjure-up" | 18:29 |
| stokachu | i still had them run the snap install commands, i just errored | 18:29 |
| nacc | stokachu: ah, in the PPA version? or in the published version | 18:30 |
| stokachu | yea in the ppa version | 18:30 |
| nacc | stokachu: ok, thanks! is there a reason you didn't transition them for you (beyond it being a bit abnormal) | 18:30 |
| nacc | *them for them | 18:30 |
| nacc | I guess you would have to ensure you can install snaps, etc. (user could have removed snapd) | 18:30 |
| stokachu | nacc: yea | 18:33 |
| stokachu | nacc: if they run snap install and it fails to find snap they get directed to apt-get install snapd :) | 18:33 |
| stokachu | that's what i rely on for making sure they can install snaps | 18:33 |
| stokachu | brb lunch | 18:33 |
| nacc | stokachu: ah ok -- thanks! | 18:33 |
| jdstrand | kyrofa: hey, is this supported: http://paste.ubuntu.com/24141235/ | 20:11 |
| kyrofa | jdstrand, that grammar is only supported for stage-packages | 20:11 |
| jdstrand | kyrofa: basically, on amd64 I need those packages to use the preload part, but libc6-dev-i386 only exists on amd64, not say, armhf | 20:12 |
| jdstrand | kyrofa: hmm, is that a missing feature or should I do this differently? | 20:12 |
| kyrofa | jdstrand, so can this even be built on armhf? | 20:13 |
| jdstrand | kyrofa: yes | 20:14 |
| kyrofa | jdstrand, but with a different set of build-packages? | 20:14 |
| jdstrand | I didn't test it yet, but I have https://myapps.developer.ubuntu.com/dev/click-apps/7180/rev/5/ | 20:14 |
| jdstrand | kyrofa: if I remove the build-packages, it builds on everything but amd64 | 20:15 |
| kyrofa | jdstrand, I think you're the first person who has run into this for build-packages. All the previous requests were for stage-packages. So yeah, I say log a bug | 20:15 |
| jdstrand | kyrofa: for amd64 I used build-packages with those 4. I was wanting to then add those 4 for only amd64 | 20:15 |
| jdstrand | ok | 20:15 |
| jdstrand | kyrofa: fyi, https://bugs.launchpad.net/snapcraft/+bug/1671238 | 20:20 |
| mup | Bug #1671238: please support selectors in build-packages too <Snapcraft:New> <https://launchpad.net/bugs/1671238> | 20:20 |
| kgunn | kyrofa: hay back, sorry...lunch and then super distracted helping my 18 yo with his laser etching project involving inkscape ;) | 20:20 |
| kyrofa | Thanks jdstrand, I'll bring that up in standup | 20:20 |
| kyrofa | kgunn, ooo, that sounds like a fun project! | 20:20 |
| kgunn | what advice can i help with? | 20:21 |
| * kgunn worries about kyrofa asking me for advice :) | 20:21 | |
| kyrofa | kgunn, we got https://bugs.launchpad.net/snapcraft/+bug/1670146 logged against the qmake plugin snapcraft | 20:21 |
| mup | Bug #1670146: QMake plugin should allow specifying custom Qt paths <Snapcraft:New> <https://launchpad.net/bugs/1670146> | 20:21 |
| * kgunn reads | 20:22 | |
| kyrofa | kgunn, do you have any thoughts about how to best approach that? Does my comment sound promising? | 20:22 |
| pmcgowan | kyrofa, what is simpler than what example [1] there is doing? | 20:27 |
| pmcgowan | just use the existing qt part for the version you need? | 20:28 |
| pmcgowan | or he may be using the qt lite stuff to make a custom one | 20:28 |
| kyrofa | pmcgowan, and using QTDIR? Is that the best way to do this? | 20:28 |
| kyrofa | pmcgowan, would we need to set QMAKESPEC and QT_PLUGIN_PATH as well? Not sure if there are others | 20:29 |
| pmcgowan | kyrofa, Mirv is the best one to ask | 20:31 |
| Olympionex | Does anyone know what is required to be running inside a docker container in order for snap to install the core image? I have snapd running inside the docker, but when I try to install core it downloads fine but fails to mount. I'm just trying to build a classic confinment snap inside a docker image, but it looks like snapcraft needs the core image for linking in libs. | 20:33 |
| kgunn | kyrofa: pmcgowan ...ah his issue is, it's a local part, but he's wanting to use the system provided plugin..is that the issue? | 20:33 |
| Olympionex | sorry, didn't mean to interrupt right there | 20:33 |
| kgunn | don't apologize...it's always messy on irc :) | 20:34 |
| kyrofa | kgunn, pmcgowan indeed, the problem is that the system plugin (shipped in snapcraft) only supports qt from the system, and _specifically_ only qt4 and qt5 | 20:34 |
| kgunn | right | 20:34 |
| kgunn | so he's kind of wanting to "override" that with his local stuff | 20:34 |
| kyrofa | kgunn, at least, that's what's happening in [1] on the bug. Not sure what the deal is with [2], but it looks like it's available somewhere on the system | 20:35 |
| kgunn | to me, i don't think it's completely wrong to say...copy over the plugin and modify it | 20:35 |
| pmcgowan | oh I see | 20:36 |
| kgunn | i used to do that with qt stuff for mir-kiosk in early days | 20:36 |
| kyrofa | Olympionex, I don't think running snaps inside docker is supported | 20:36 |
| kyrofa | kgunn, yeah that's always an option if there's no easy way to make this work | 20:37 |
| kyrofa | Olympionex, you're right in that snapcraft needs the core snap, but it supports a magical flag for exactly your situation | 20:38 |
| kyrofa | Olympionex, try `SNAPCRAFT_SETUP_CORE=1 snapcraft` | 20:38 |
| Olympionex | awesome, i'll try it | 20:39 |
| kyrofa | Olympionex, and it'll download the core snap itself and unpack it instead of expecting it to be mounted into place | 20:39 |
| kgunn | kyrofa: in the second one, he's also modified the plugin...basically to build local | 20:39 |
| kgunn | so...that might be a reasonable request like.... | 20:39 |
| kgunn | plugin will do qt4, qt5 or custom qt setup local to your snap | 20:40 |
| kgunn | at this point, it's prolly a Mirv proposal we'd want on how exactly to do that... | 20:40 |
| kgunn | not sure who originally wrote the qmake plugin? | 20:40 |
| kyrofa | kgunn, me, with your testing. You don't remember that? | 20:41 |
| kyrofa | kgunn, that's why you're my qmake guy! | 20:41 |
| kgunn | lol | 20:41 |
| kyrofa | Teach you to help me | 20:41 |
| kgunn | ah...so all my complaints ended up on your desk...oops | 20:41 |
| kyrofa | kgunn, pmcgowan alright, thank you both for your help! It's super late for Mirv so I'll get in contact with him | 20:44 |
| pmcgowan | jdstrand, I am back to testing ont he dragonboard and of course nothing works like it did on amd64, I am getting all sorts of denials in devmode | 20:45 |
| pmcgowan | and I dont see my configure hook run | 20:46 |
| === ddstreet_away is now known as ddstreet | ||
| Olympionex | thanks very much kyrofa! | 20:47 |
| kyrofa | Olympionex, did that work out okay? | 20:48 |
| Olympionex | kyrofa: yeah, doing final testing, but seemed to start it building | 20:49 |
| kyrofa | Olympionex, good deal. And yeah, don't apologizing for jumping in-- you'd never get a word in sometimes if you didn't! | 20:49 |
| kgunn | kyrofa: you bet.... i was still noodling inthe background...kind of wonder if there's not a way to do the override from within his yaml | 20:50 |
| kgunn | like isn't there a configflags: field | 20:50 |
| kyrofa | kgunn, options, yeah | 20:50 |
| kgunn | then just looking at this | 20:50 |
| mup | PR snapcraft#1128 closed: tests: support bzr branches for external tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1128> | 20:50 |
| kgunn | http://doc.qt.io/qt-5/qmake-variable-reference.html | 20:50 |
| Olympionex | thanks | 20:51 |
| kgunn | a-la "DEFINES += USE_MY_STUFF" | 20:51 |
| kgunn | anyhoo..just an idea | 20:51 |
| kyrofa | kgunn, that would end up being handed to the compiler though, right? | 20:53 |
| kgunn | yes | 20:53 |
| kyrofa | kgunn, the "application type" is interesting, though: "The target is a Qt application or library and requires the Qt library and header files. The proper include and library paths for the Qt library will automatically be added to the project. This is defined by default, and can be fine-tuned with the \l{#qt}{QT} variable." | 20:53 |
| kgunn | but my presumption is, he's just wanting to point to his local Qt like a tool for the qmake to run | 20:53 |
| kyrofa | kgunn, if he uses a precompiler definition, he'd have to somehow handle that in his code, no? That won't actually affect qmake, unless I'm misunderstanding | 20:55 |
| kgunn | ah, i think you might be right | 20:56 |
| * kgunn thinks some more | 20:56 | |
| mup | PR snapcraft#980 closed: sources: add optional "source-checksum" property <Created by pachulo> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/980> | 21:02 |
| mup | PR snapcraft#1176 opened: demos, tests: remove the tomcat demo snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1176> | 21:11 |
| mup | PR snapcraft#1177 opened: sources: update documentation for source-subdir <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1177> | 21:29 |
| === JanC_ is now known as JanC | ||
| pmcgowan | kyrofa, is there a way to reinit the snapctl config for a snap, to work around that bug | 21:44 |
| kyrofa | pmcgowan, I think you need to stop snapd, then update that json file, then start snapd again | 21:44 |
| pmcgowan | oy | 21:44 |
| pmcgowan | kyrofa, thanks | 21:45 |
| kyrofa | Any time | 21:45 |
| mup | Bug #1671266 opened: rfkill should be included in the core snap <Snappy:New> <https://launchpad.net/bugs/1671266> | 22:43 |
| mup | PR snapcraft#1163 closed: docs: update the directory where the API pages are generated <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1163> | 23:02 |
| kyrofa | nessita, noise][ we are having some terrible connectivity issues with the store right now that's wreaking havoc with CI. status.snapcraft.io looks clear... are there any known issues? | 23:04 |
| kyrofa | Lots of "Connection reset by peer" | 23:05 |
| elopio | kyrofa nessita noise][: this bug https://bugs.launchpad.net/snapstore/+bug/1666061 | 23:13 |
| mup | Bug #1666061: snapcaft tests that download the core snap fail sometimes <tests> <Snapcraft:New> <Snap Store:New> <https://launchpad.net/bugs/1666061> | 23:13 |
| kyrofa | elopio, WAY more than 1 out of 10 today. It's been like 8/10 for me | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!