[00:23] <Trevinho> jdstrand: it took some time (sorry, I had to rewrite some parts), but here it is: https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes
[00:27] <Trevinho> mhall119: you might see that as well ^ (MP at https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858)
[01:14] <niemeyer_> Would anyone have a snapcraft.yaml example that has a qt application working?
[01:15] <niemeyer_> Trying to snap something and suffering at the moment
[01:17] <niemeyer_> Got as far as realizing I needed to stage libqt5gui5 to get the plugins manually, and setting the appropriate enviornment variable to find these
[01:19] <Trevinho> niemeyer_: I think you can get some at https://github.com/kyrofa/qt-example-snaps
[01:20] <Trevinho> sergiusens: I know it's dirty (and probably ugly too :-)), but what you think of this: https://bugs.launchpad.net/snapcraft/+bug/1551716/comments/5 ?
[01:21] <niemeyer_> Trevinho: Thanks!
[04:14] <mhall119> Trevinho: thanks, but it's not working for me, can we work on it together tomorrow?
[07:38] <zyga> o/
[08:51] <morphis> zyga: morning!
[09:27] <zyga> morphis: good morning :)
[09:27] <morphis> zyga: hey!
[09:27] <morphis> zyga: I've just pushed new changes to the network-manager interface PR
[09:28] <zyga> morphis: shall we land it? :)
[09:28] <morphis> zyga: please :-)
[09:28] <zyga> morphis: I'll review it in a sec
[09:28] <morphis> thanks!
[11:45] <Trevinho> mhall119: it runs fine here, but you've to install it as --devmode for now
[11:45] <Trevinho> or do you get issues while snapcrafting it?^
[12:05] <sborovkov> Hi. Is it possible to allow snap to change config.txt on RPI? Which is a part of gadget snap
[12:05] <ogra_> not yet, no
[12:05] <ogra_> you will have to use an editor for now
[12:06] <sborovkov> ogra_: is this a planned feature/is there a bug?
[12:06] <ogra_> niemeyer, ^^^ did we actually plan an interface for that that other snaps can consume ?
[12:07] <sborovkov> also we were told before in the time of old security that perhaps we should create script that can execute root commands (so that we can reboot device for instance). is that possible to do now?
[12:10] <Olh> Hi guys! I have a question: I am working at scientific facility and we are switching soon to Ubuntu16 from Ubuntu12, and the thing is: do you think snappy can be a good approach to package management in the "industrial environment"?
[12:11] <ogra_> definitely
[12:12] <Olh> because from what I see it looks a little bit more like an end-user package management
[12:13] <ogra_> snappy started completely focused on embedded and IoT ... it only grew into the other spaces over time
[12:14] <ogra_> having snap support on the desktop enables you to actually test your development there very easily (beyond extending the delivery focus to endusers too)
[12:16] <Olh> I see, ok, thanks, I have to test it out and see for myself if it's doing the job ;)
[12:16] <ogra_> yeah
[12:18] <sborovkov> ogra_: do you know about what I asked further up, about running root commands from the snap or do you know who I could ask about that? Thanks :)
[12:19] <ogra_> Olh, there is also some marketing material if you like such stuff ;)  https://insights.ubuntu.com/2015/10/21/snappy-core-unlocks-iot-value-within-the-dell-edge-gateway-5000-series/
[12:20] <ogra_> sborovkov, zyga perhaps ... he works on interfaces between snaps ... that would likely be something the ubuntu-core snap would have to provide
[12:24] <Olh> @ogra_ thanks!
[12:24] <nothal> Olh: No such command!
[12:24] <Olh> ogra_ thanks! ;D
[12:24] <ogra_> heh
[12:24] <ogra_> welcome
[12:32] <sborovkov> ogra_: understood, thanks. zyga: Hi, do you know if it's possible to run root commands in snap? can it be done somehow at all currently?
[12:42] <morphis> zyga: ping
[12:49] <zyga> morphis: pong
[12:50] <morphis> zyga: you had time to look into the PR for network-manager?
[12:52] <zyga> morphis: somewhat, I need to merge it and release
[12:52] <zyga> morphis: I think we've switched to a weekly SRU now
[12:52] <morphis> zyga: so from a review perspective no further comments?
[12:53] <zyga> morphis: looks okay
[12:53] <morphis> zyga: ok, do we want a last review from jdstrand on the desktop-side bits?
[12:53] <zyga> morphis: you could run update-pot so that it's all green there
[12:54] <zyga> morphis: I suspect he will anyway
[12:54] <zyga> morphis: I think it's better to ship it now and iterate
[12:54] <zyga> morphis: perfect security is a perfect enemy of usability :)
[12:54] <jdstrand> hey now
[12:54] <morphis> zyga: :-)
[12:54] <morphis> jdstrand: hey!
[12:54] <zyga> jdstrand: hey
[12:55] <morphis> jdstrand: if you didn't saw the mails yet, I've updated desktop-support to the network-manager interface
[12:55] <jdstrand> I'm not saying not to merge it
[12:55] <jdstrand> but we have to be awfully careful shipping stuff that is too wide open
[12:56] <jdstrand> just like we don't want to ship interfaces cause we can't take them away, we can't ship too open policy because we can't take those accesses away easily
[12:57] <morphis> jdstrand: yeah
[12:57] <zyga> jdstrand: I think that's a fine line, we should be just smart when we do, we can fix security bugs caused by initially too-wide-open things if there's no other choice
[12:57] <jdstrand> there is a choice here
[12:57] <jdstrand> you said you'd just merge it and that security is the enemy of usability
[12:58] <jdstrand> the choice is, let me review it with the updated changes :)
[12:58] <zyga> jdstrand: I didn't mean to merge it before :)
[12:58] <zyga> jdstrand: I mean ultimately when we don't see holes we should just merge it
[12:58] <jdstrand> ah, ok, then I misunderstood :)
[12:58] <zyga> perhaps there are more holes
[12:59] <jdstrand> of course
[12:59] <jdstrand> I thought we were skipping a step is all
[12:59] <jdstrand> I see now that I was wrong
[12:59] <zyga> sorry, I'm still a bit jetlagged
[12:59] <zyga> I mean well
[12:59] <jdstrand> nw, sorry that I misunderstood
[12:59] <morphis> :-)
[12:59] <jdstrand> :)
[13:00] <morphis> jdstrand: I've marked the line I've added for desktop support
[13:00] <morphis> there might be a few things missing in terms of functionality but we will resolve those as we go
[13:00] <jdstrand> morphis: ok, I'll be reviewing that today. I was going to review the previous changes but then saw that the desktop ones were requested so thought I'd wait
[13:01] <jdstrand> I was most interested to see if we were going to ship different policy for desktop and core
[13:01] <jdstrand> but I'll see that soon enough when I take a look at it
[13:02] <morphis> jdstrand: thanks
[13:07] <jdstrand> sborovkov: you can ship anything you want in your snaps, including stuff you want to run as root, but they will be subject to the security policy as defined by the connected interfaces when running as a service or from /snap/bin. it is possible for you to ship scripts that you run directly as the user under sudo (ie, sudo /snap/foo/current/bin/bar) outside of confinement
[13:08] <jdstrand> sborovkov: but it sounds more like you would like interfaces for reboot and perhaps other things. If so, please file a bug and use the 'snapd-interface' tag
[13:08] <jdstrand> sborovkov: then it/they can be discussed
[13:09] <sborovkov> jdstrand: understood, thanks. Basically we need reboot, but since we are going in beta and don't know if something else might be required.
[13:09] <sborovkov> jdstrand: is there already some interface for reboot specifically?
[13:11] <jdstrand> sborovkov: no
[13:12] <ysionneau> hi
[13:12] <jdstrand> Trevinho: re https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes: thanks! :)
[13:13] <ysionneau> it seems now the ubuntu-core-launcher is directly running the target binary instead of what was done before : running a shell wrapper which was exporting PATH and LD_LIBRARY_PATH
[13:13] <ysionneau> so now the snap binary cannot use shared library from its own snap?
[13:13] <Trevinho> jdstrand: np, I've noticed that also unconfined the sound indicator integration is not properly working, but for the rest it should work
[13:14] <jdstrand> cool
[13:14] <ysionneau> I've done my own wrapper ... but this was working before :o
[13:31] <ngaio> ubuntu-calculator-app.calculator gives me an libGL error and fails
[13:34] <morphis> zyga: one other thing I wanted to talk with you about is the pulseaudio interface
[14:21] <zyga> morphis: yes?
[14:22] <zyga> morphis: for native snap, I assume
[14:22] <ssweeny> zyga, have you had a chance to look at https://github.com/ubuntu-core/snappy/pull/1118#discussion_r62386799 yet?
[14:23] <morphis> zyga: so I am going to implement the slot side of this now, what is the current state of your PR? still being stalled on the trust-store discussion?
[14:24] <zyga> morphis: I think that's something I need to ask jdstrand again about
[14:24] <zyga> morphis: I'd like to land it
[14:24] <zyga> morphis: because we have no other way, we can improve it next week or the week after
[14:25] <zyga> ssweeny: looking
[14:25] <zyga> ssweeny: I didn't read it yet, just catching up with jetlag today
[14:25] <morphis> zyga: I think we shouldn't release it in a state where it allows audio recording
[14:26] <zyga> morphis: this was discussed at the sprint briefly, if it takes us a lot of time to make it safer we should release it now
[14:26] <zyga> morphis: because the alternative is --devmode anyway
[14:26] <zyga> morphis: and this is better than nothing
[14:26] <morphis> zyga: so releasing only with a change to pulseaudio to deny audio recording would be my vote
[14:26] <zyga> morphis: apparently that's the whole trust store
[14:27] <zyga> morphis: or if we can look at the apparmor label from p-a then yes, I agree
[14:27] <zyga> morphis: it all depends on our ability to patch this and SRU
[14:27] <morphis> zyga: not necessarily, we could start with simply denying audio for every request coming from a snap basing on the snap.* apparmor label
[14:28] <zyga> morphis: +1000
[14:28] <zyga> morphis: let's do it
[14:28] <zyga> morphis: you have my support and I'm sure jdstrand will agree
[14:29] <morphis> ok
[14:29] <morphis> zyga: I can prototype something real quick in pa
[14:30] <zyga> morphis: fantastic
[14:30] <zyga> morphis: I have little knowledge of pa and yet less ability to patch it quickly
[14:30] <morphis> zyga: ok
[14:32] <niemeyer_> ogra_: About config.txt in the RPi, we didn't settle down on a design yet.. we know at least the gadget snap will be able to conveinently tap onto it
[14:32] <ogra_> yeah, thats what i was remembering, there was no specific design yet
[14:33] <ogra_> sborovkov, so for now an editor it is ...
[14:33] <HollyRain> how does snappy is related to LXD? Are they complementary technologies or the opposite?
[14:33] <zyga> HollyRain: different I would say :)
[14:34] <HollyRain> zyga, If I understand both technologies,if you use a server with snappy then don't need LXD, right?
[14:35] <ogra_> snaps do not run in containers by default ...
[14:35] <zyga> HollyRain: I think they are orthogonal really
[14:35] <zyga> HollyRain: as ogra_ just said, snappy doesn't put a container around apps
[14:35] <ogra_> i.e. they run natively but in a guarded native environment ...
[14:35] <ogra_> and they have to ship all their dependencies inside ...
[14:36] <ogra_> you *can* use lxd in a snap if you feel like (or docker) ... but a normal snap is just a natively installed thing
[14:36] <HollyRain> ok, then snappy is going to kill lxd, at least in servers
[14:36] <ogra_> no
[14:37] <ogra_> imagine a snap that simply uses multiple containers ... spawns them on demand etc ...
[14:37] <jdstrand> morphis: I think I suggested something rather similar. I guess you are aware of the touch overlay pulseaudio that has identified the mediation points and reaches out to trust-store?
[14:38] <morphis> jdstrand: yes
[14:38] <morphis> jdstrand: I had a discussion with tvoss about this last week
[14:38] <ogra_> just using ldx for a single instance is surely just over-engineering things ... but lxd definitely has its use in snaps
[14:38] <ogra_> *lxd
[14:38] <jdstrand> morphis, zyga: I'm totally fine with first iteration mic is blocked if connecting process has label starting with 'snap.'
[14:38] <morphis> jdstrand: we have some kind of a plan in our heads how we could implement trust-store in snappy but that needs more time and discussion
[14:38] <morphis> so blocking all snaps from mic is the best first thing we can do
[14:39] <jdstrand> morphis: cool-- I pointed tvoss at my ideas in one of the PRs, glad people are discussing it :)
[14:39] <morphis> jdstrand: I think your comment was the starting point for this :-)
[14:40] <jdstrand> \o/
[14:40] <jdstrand> :)
[14:40] <sborovkov> ogra_: editor is not a possibility :-( Devices will be only remotely available. And without ssh
[14:41] <ogra_> hmm, sounds risky, why/what do you need to edit ?
[14:42] <ogra_> (i mean ... why on the fly)
[14:42] <sborovkov> ogra_: Overscan might need to be enabled/disabled. Or for instance hdmi_mode and hdmi_group - in my case I connect monitor which has DVI only, no HDMI, rpi does not detect proper resolution
[14:43] <ogra_> hmm, is there no sysfs interface that you could use after boot
[14:44] <sborovkov> AFAIK it's all done with changing config.txt.
[14:44] <sborovkov> Also let's say user wants to rotate screen
[14:44] <sborovkov> that also needs chaning config.txt
[14:54] <morphis> jdstrand: you have some code anywhere how I can determine the apparmor label for a given pid?
[14:56] <tedg> morphis: man aa_gettaskcon
[14:56] <morphis> tedg: thanks!
[14:56] <tedg> morphis: Oh, just aa_getcon, then gettaskcon is there
[14:57] <morphis> so something like aa_gettaskcon(my_app_pid, &out_label, &out_mode)?
[14:57] <morphis> do I need any context init or so?
[14:58] <tedg> No, I believe it just is a syscall to the kernel
[14:58] <tyhicks> morphis: no context init is needed
[14:59] <tedg> FWIW, adding this to UAL so that we can interpret between Click and Snap labels. As they're different.
[14:59] <tyhicks> morphis: but keep in mind that using a pid to look something up is almost always racy
[14:59] <tedg> (not sure what you're working on)
[14:59] <morphis> tyhicks, tedg: just trying to pull the security label from within pulseaudio to deny audio recording for any snap app
[14:59] <morphis> and the only thing I get upon connection is the pid
[15:00] <tyhicks> morphis: perfect - you want to use aa_getpeercon() instead
[15:00] <tyhicks> morphis: it is in the same man page
[15:00] <morphis> tyhicks: ok
[15:00] <tyhicks> morphis: it takes the socket fd as input instead of the pid
[15:01] <zyga> tyhicks: o/
[15:01] <tyhicks> hi zyga :)
[15:01] <tyhicks> zyga: is there a feature bug covering bind mount support for interfaces?
[15:02] <tedg> morphis: How are we doing the trust store integration with clicks? Is that a PA module?
[15:02] <morphis> tedg: yes
[15:02] <niemeyer_> jdstrand: Heya
[15:02] <morphis> tedg: https://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/tree/debian/patches/0409-Trust-store-patch.patch?h=ubuntu
[15:02] <zyga> tyhicks: nope, not yet
[15:03] <niemeyer_> jdstrand: Do you have some input for that "Making a snap of an icon theme" thread?
[15:03] <ysionneau> someone has the link to launchpad to the rpi2 kernel snap.yaml?
[15:03] <niemeyer_> jdstrand: It's strange that the logs are showing denials despite the snap being in devmode
[15:03] <niemeyer_> jdstrand: There are separate issues about making gsettings happy, but that on itself sounds awkward and worth looking
[15:04] <tedg> morphis: Cool, thanks!
[15:05] <sborovkov> Hi. Let's say I install snap in devmode - is it possible to lock them down remotely later? remove devmode with newer version of snap
[15:06] <zyga> ysionneau: I may
[15:06] <morphis> tyhicks: hm, need to see if I can unwrap the actual connection fd from within my pulse module
[15:07] <zyga> ysionneau: https://wiki.ubuntu.com/SnappyHackerUsefulLinkCollection
[15:07] <morphis> tyhicks: so when does retrival through the pid becomes racy? when the security label isn't yet assigned but the client has already connected to pulse?
[15:07] <ysionneau> thanks zyga !
[15:08] <tyhicks> niemeyer_, jdstrand: I just responded to the icon theme thread
[15:09] <tyhicks> niemeyer_, jdstrand: AFAICT, the gsettings issue problems in devmode aren't caused by confinement
[15:10] <tyhicks> zyga: seb128 was wanting to follow along with the progress - once one of us files a bug, we need to subscribe him
[15:11] <seb128> zyga, tyhicks, thanks ;-)
[15:14] <zyga> tyhicks: I can do it now
[15:14] <tyhicks> zyga: that'd be good (I need to call into a meeting)
[15:16] <Trevinho> jdstrand: you got hello-unity working?
[15:16] <jdstrand> not yet, I've been arguing in #ubuntu-desktop
[15:17] <jdstrand> and about to head to a meeting
[15:17] <jdstrand> but after that, I will be looking at it
[15:17] <Trevinho> jdstrand: ok
[15:19] <jdstrand> morphis (fyi tyhicks): see https://trello.com/c/ftSp1Ogp/649-implement-aa-query-file-fd-to-fix-toctou-issues-with-using-aa-query-file-path for how to do it safely until the new api is in place
[15:19] <jdstrand> actually, I can paste that
[15:19] <tyhicks> jdstrand: that's a different problem
[15:20] <jdstrand> http://paste.ubuntu.com/16475967/
[15:20] <jdstrand> ah, ok
[15:20] <morphis> jdstrand: thanks!
[15:20] <tyhicks> morphis: that's for a different issue
[15:20] <morphis> ah
[15:22] <sborovkov> Is it possible to go from --devmode to usual settings with snap update? Without doing anything manually?
[15:22] <tyhicks> morphis: sorry I missed your question earlier
[15:22] <tyhicks> morphis: the use of the pid can be racy if you pull the AA context of the pid, using aa_gettaskcon(), decide that it should be allowed, and then that pid exits and gets reused
[15:23] <morphis> tyhicks: ah
[15:23] <tyhicks> morphis: the new process may not have the same AA context
[15:23] <morphis> tyhicks: as long as we don't store the decision things should be fine then, right?
[15:24] <tyhicks> morphis: probably so
[15:24] <morphis> as with the implementation I did so far the label is retrieved again for any new request to record audio based on the pid and checked than if it starts with snap.
[15:24] <tyhicks> morphis: that sounds ok
[15:25] <morphis> tyhicks: thanks
[15:26] <tyhicks> morphis: how are you getting the pid?
[15:28] <morphis> tyhicks: pulse is handing it in on a connection attempt, need to check how it retrieves it but I guess it checks the credentials of the connecting peer
[15:34] <zyga> tyhicks: https://bugs.launchpad.net/ubuntu-core-launcher/+bug/1582781
[15:38] <tyhicks> zyga: thanks! I'll do a brain dump of what I intend to implement in the launcher
[15:38] <zyga> tyhicks: thanks!
[15:39] <zyga> tyhicks: can we actually bind mount /usr/share/fonts over /usr bind mounted from os snap?
[15:39] <zyga> tyhicks: I was thinking that it might be tricky :)
[15:40] <tyhicks> zyga: that'll work but we need to get the ordering correct
[15:41] <tyhicks> zyga: snapd will need to output the default classic bind mounts at the top of the fstab file
[15:41] <zyga> tyhicks: what is the right order? /usr bind mount will hide /usr/share/fonts, no?
[15:41] <tyhicks> zyga: /usr needs to be bind mounted first, then /usr/share/fonts can be bind mounted
[15:41] <zyga> but, from where?
[15:41] <zyga> that's the problem
[15:41] <zyga> source is gone
[15:42] <tyhicks> zyga: oh, I see
[15:42] <zyga> could be tricky
[15:42] <tyhicks> zyga: agreed
[15:43] <zyga> we could create an empty / somewhere, populate it
[15:43] <zyga> and chroot
[15:43] <zyga> anyway
[15:43] <zyga> "left as an exercise to the reader"
[15:43] <tyhicks> yes
[15:43] <tyhicks> I'll give it some thought (still in meeting)
[15:43] <zyga> sure, no worries
[16:10] <morphis> awe, zyga: first draft on the pulseaudio-snappy-policy impl: https://paste.ubuntu.com/16476981/
[16:10] <morphis> not tested yet
[16:10] <awe> thanks morphis
[16:11] <morphis> awe: ah, I meant jdstrand :-)
[16:11] <morphis> awe: but feel free to have a look too
[16:11] <awe> haha
[16:11] <morphis> more gaining pulseaudio knowledge is always what we look for :-D
[16:18] <morphis> jdstrand, zyga: will test and finish this tomorrow, packages are at https://requests.ci-train.ubuntu.com/#/ticket/1428
[17:36] <zyga> morphis: you should free the label obtained from aa
[17:37] <zyga> morphis: around line 129 in the diff
[17:37] <zyga> morphis: otherwise this leaks memory
[17:41] <Facu> hello! I'm failing to understand how to connect an app to an interface, I'm kind of lost about what is a plug and what is a slot (specially because the "connect" section in "man snap" doesn't mention the app at all)
[17:41] <zyga> Facu: hey
[17:42] <Facu> hola zyga
[17:42] <zyga> Facu: plug is the "using/consuming" side of an interface
[17:42] <zyga> Facu: slot is the "providing" side
[17:42] <zyga> Facu: you can use: snap connect snap-name:plug snap-name:slot
[17:42] <zyga> Facu: to connect the plug to a slot, the snap names are typically different
[17:43] <Facu> zyga, ok; so I do "sudo snap interfaces", and under the slot column there is ":home", but which snap provides that?
[17:43] <zyga> Facu: ubuntu-core
[17:43] <zyga> Facu: that will be quite a lot easier soon, just not in sru-2
[17:44] <Facu> zyga, and how do I get from the app to the plug? my app is named  spongeshaker.sha3sum, but I tried  "sudo snap connect spongeshaker.sha3sum:home ubuntu-core:home"  and it tells me that:  cannot connect plug "home" from snap "spongeshaker.sha3sum", no such plug
[17:45] <zyga> Facu: you don't connect apps, you connect snaps
[17:45] <zyga> Facu: put the home interface on the appropriate apps in your snap
[17:45] <zyga> Facu: then connect with: sudo snap connect spongeshaker:home ubuntu-core:home
[17:46] <zyga> Facu: plug name is "snap-name.plug-name" not ".app-name"
[17:46] <Facu> zyga, when you say to "put the home interface on the appropiate apps", that is in the .yaml before building the snap?
[17:47] <zyga> Facu: yes
[17:48] <zyga> Facu: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
[17:48] <zyga> Facu: http://www.zygoon.pl/2016/04/snappy-interfaces-plugs-slots-connections.html
[17:48] <zyga> Facu: that should help you
[17:49] <Facu> zyga, awesome, thanks! I was reading here and didn't find anything regarding interfaces: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/
[17:50] <zyga> Facu: we're working on making developer.ubuntu.com docs much better
[17:51] <jdstrand> morphis: nice! (though shouldn't line 122 be PA_HOOK_CANCEL? that's a scary conditional to say ok to)
[17:52] <Facu> zyga, ah, ahora I see the plug listed in "snap interfaces", awesome
[18:46] <mhall119> Trevinho: are you still around?
[18:54] <jdstrand> tyhicks: how is this text: http://paste.ubuntu.com/16480381/
[18:55] <HollyRain> at snapcraft, there a plugin for 'go', could be passed any argument to go compiler?
[19:01] <tyhicks> jdstrand: sounds great
[19:02]  * jdstrand posts
[19:02] <jdstrand> tyhicks: thanks
[19:40] <thomi> Hello everyone, does anyone know who I should talk to about debugging / fixing  https://bugs.launchpad.net/snapcraft/+bug/1582513 ?
[19:42] <thomi> sergiusens: perhaps you know? ^^
[19:44] <jdstrand> Trevinho: I finally tried hello-unity and commented in the MP
[19:45] <davidcalle> Facu: zyga: the Interfaces doc is located here: https://developer.ubuntu.com/en/snappy/guides/interfaces/
[19:46] <Facu> davidcalle, thanks, found the .md in the repository for that :)
[19:46] <davidcalle> Ok :)
[19:46] <Facu> thomi, I just created a snap using python3, and it worked
[19:47] <thomi> Facu: hmmmm. Any ideas what the issue might be? A virtualenv created for the same source doesn't pull in that library...
[19:48] <Facu> thomi, I got the example from here: https://github.com/ubuntu-core/snapcraft/tree/master/examples/py3-project
[19:48] <Facu> thomi, maybe you can try that one, and if it fails is something from your installation (or something from mine that luckily made it work ok)
[19:49]  * thomi clones
[19:55] <Facu> thomi, the snapcraft building worked ok; the example is useless because it doesn't declare the :home plug, but that's another issue
[19:55] <thomi> Facu: are you willing to try the snapcraft.yaml file from the bug? I'm building the example now
[19:56] <Facu> thomi, just put that alone in a dir and run snapcraft?
[19:57] <thomi> Facu: yup
[19:57] <thomi> Facu: iiiinteresting, the py3-project example pulls in that lib for me too
[19:57] <thomi> https://www.irccloud.com/pastebin/7MXh7bMs/for%20example%3A%20
[20:00] <Facu> thomi, http://linkode.org/FYzDlwbz8TbhilmWVO1nL7
[20:00] <thomi> Facu: what does "find . -name "libmvec.*"" show?
[20:00] <thomi> Facu: I can build the snap, but it fails review since it contains a symlink to that library for some reason
[20:03] <Facu> thomi, http://linkode.org/FYzDlwbz8TbhilmWVO1nL7/4tbXGNxYHXnthEO6RbG5a2
[20:04] <thomi> Facu: same as me. I bet if you try and upload the snap it'll be rejected :(
[20:04] <Facu> thomi, upload through where?
[20:05] <Facu> thomi, the web ui?
[20:05] <thomi> Facu: yeah - but it'll fail since the name is registered to me.
[20:05] <Facu> thomi, I can try staging
[20:06] <thomi> ahh, good idea
[20:24] <Facu> thomi, I think it all worked ok... it's public, you can see this AFAIK: https://myapps.developer.staging.ubuntu.com/dev/click-apps/681/
[20:25] <thomi> Facu: nope, I get 403 - it worked though? That's odd - maybe I should try re-uploading it to prod
[20:26] <Facu> thomi, you should be able to search for it, in staging, right?
[20:27] <thomi> Facu: hmmm, how? The UIs all changed since i last looked.
[20:29] <mhall119> sergiusens: ping
[20:59] <Facu> thomi, so, upload fails for me too, as we saw
[21:00] <Facu> thomi, that said, the snap works!
[21:00] <thomi> yeah, any idea who I should ping about this?
[21:00] <Facu> thomi, I mean, the example one, I installed and used it
[21:00] <Facu> thomi, so it probably is not the snap that is wrongly built, but the automatic reviewer?
[21:00] <thomi> Facu: that's part of sca, right?
[21:05] <roadmr> thomi, Facu : jdstrand could tell you why the click-reviewers-tools script is failing a particular package
[21:12] <thomi> jdstrand: I'm seeing lint-snap-v2:external_symlinks fail, both for my own python3 snap (http://paste.ubuntu.com/16482061/) as well as the py3-project example from the snapcraft repo
[21:13] <thomi> jdstrand: the symlink it's complaining about is libmvec
[21:13] <Facu> jdstrand, note that I built the py3-project example, installed locally, and it works
[21:13] <Facu> thomi, roadmr ↑
[21:14] <jdstrand> may I see the review tools error?
[21:14] <thomi> jdstrand: sure, one sec
[21:14] <Facu> jdstrand, "package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks"
[21:14] <thomi> beat me to it :D
[21:15] <jdstrand> right
[21:15] <jdstrand> that indicates a real problem with your snap
[21:15] <jdstrand> it is pointing to something outside of itself
[21:15] <thomi> jdstrand: this is using the example py3-project snap from the snapcraft repo
[21:16] <jdstrand> sounds like a bug in the snapcraft repo
[21:16] <thomi> jdstrand: any idea who to talk to about that?
[21:16] <jdstrand> kyrofa (cc sergiusens (just for bacscroll, stay away on holiday)): ^
[21:20] <Facu> jdstrand, thomi, I opened the snap: it looks like there are a lot of symlinks pointing to outside: http://linkode.org/y6AKZ3Iq9Hzsoi0Ic0nui4
[21:20] <jdstrand> iirc, some are required
[21:21] <jdstrand> there is a list and the review tools won't complain about ones in that list
[21:21] <Facu> in any case, the libmvec looks like pointing outside, indeed:  libmvec.so -> /lib/x86_64-linux-gnu/libmvec.so.1
[21:22] <Facu> so, snapcraft is building badly the .snap
[21:22] <jdstrand> but the libmvec.so might need to be one of those
[21:22] <jdstrand> I see that it is part of libc6
[21:23] <jdstrand> can one of you file a bug against snapcraft and add a click-reviewers-tools task?
[21:23] <thomi> I'll add a test to https://bugs.launchpad.net/snapcraft/+bug/1582513
[21:24] <thomi> jdstrand: done
[21:24] <jdstrand> thanks
[21:26] <thomi> thanks for your help Facu , jdstrand
[21:27] <Facu> thomi, thank you!
[21:27] <Facu> jdstrand, roadmr, thank you too :)
[21:28] <thomi> Hopefully we can find a solution soon, I really want to upload my snap to the store :D
[21:47] <roadmr> I did nothing :)