[04:45] <liuxg> has anyone ever used --jailmode to install an snap? I just reported a bug at https://bugs.launchpad.net/snappy/+bug/1643419. I am not sure whether it is a valid bug report. However, it does not show the correct result. thanks
[04:45] <mup> Bug #1643419: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643419>
[04:46] <mup> Bug #1643418 opened: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643418>
[04:46] <mup> Bug #1643419 opened: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643419>
[08:01] <foxmask> bonjello
[08:04] <dholbach> good morning
[08:05] <mup> Bug #1643418 changed: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643418>
[08:05] <mup> Bug #1643419 changed: jailmode is not wroking properly <Snappy:New> <https://launchpad.net/bugs/1643419>
[08:17] <didrocks> hey dholbach, foxmask
[08:17] <zyga> o/
[08:19] <foxmask> didrocks: hi
[08:22] <dholbach> salut didrocks
[10:01] <jamespage> jdstrand, morning
[10:02] <jamespage> jdstrand, re the openvswitch interface I'm working on - what's you're preferred name? openvswitch or openvswitch-support
[10:02] <jamespage> looking at the 'libvirt' interface, that allows a snap access to libvirt on the host os (in classic server installs)
[10:03] <jamespage> so I wondered about following a similar pattern - openvswitch-support allow OVS to run from a snap, vs openvswitch allowing a snap to access openvswitch on the host
[10:03] <jamespage> I'll need to look a libvirt in a snap next anyway :)
[10:37] <xnox> Hello, I'm running $ sudo snap find -> and for various queries a bunch of snaps are returned.
[10:37] <xnox> however, when trying to install them, all of them are error not found.
[10:38] <xnox> I am on s390x architecture, and the snap find results do not appear to be filter to display snaps that are applicable to my architecture.
[10:38] <xnox> How can I search for snaps that are available for my machine type?
[11:00] <jamespage> any plans to publish snapcraft on pypi? it would make it easily consumable in openstack gate tasks
[11:46] <timp> renato__: so if you add "ubuntu-telephony-phonenumber" to your snap, it pulls in the qt dependencies even though that is in the platform snap?
[11:47] <timp> renato__: but only at build time? Or is it put in the final snap too?
[11:47] <renato__> sergiusens, Hey I have some problems with the way that snapcraft works. As timp said adding any qml modules bring the hole qt stak and all dependencies into the package.
[11:48] <renato__> sergiusens, I know that we can remove the files with " -<file-name>" but this is a huge work when the package has a lot of dependencies.
[11:48] <renato__> sergiusens, do we have a way similar to "debian" packages where you specify only the files that you want in the package?
[11:59] <timp> I think I am running into the same issue now. I'm making a snap with stage-packages: - ubuntu-ui-toolkit-examples
[11:59] <timp> all the dependencies are in the platform snap, but when creating the snap, they are still all downloaded.
[12:07] <zyga> jdstrand: hey, you may want to look at this: https://github.com/snapcore/snapd/pull/2310
[12:07] <mup> PR snapd#2310: many: fix handling of jail mode in security setup <Created by zyga> <https://github.com/snapcore/snapd/pull/2310>
[12:07] <zyga> jdstrand: it's related to --jailmode being effectively a no-op
[12:07] <zyga> jdstrand: there's a bug referenced from there
[12:08] <zyga> jdstrand: and a branch adding a small function EffectiveSecurity() that you may want to read
[12:08] <zyga> jdstrand: I added a spread test as well
[12:08] <zyga> jdstrand: (and some simple unit tests)
[12:08] <zyga> jdstrand: none of the current tests caught this because they weren't measuring applied security, just what was being claimed
[12:15] <mup> Bug #1635413 changed: newgrp doesn't work on classic <Snappy:New> <https://launchpad.net/bugs/1635413>
[12:28] <sergiusens> renato__ use a positive filtes (without the `-`)
[12:29] <sergiusens> renato__ stage-packages are to stage into the snap; if you only need it for building use build-packages
[12:29] <renato__> sergiusens, if fact I need it to execute the app. But I do not need these dependencies
[12:30] <renato__> sergiusens, if I use a positive filter it will overwrite the default behavior of adding everything?
[12:30] <sergiusens> renato__ yes for that last comment
[12:30] <renato__> sergiusens, great, thanks
[12:33] <renato__> timp, could you try that on your examples ^^^
[13:10] <renato__> didrocks, what do you think about this bug? https://bugs.launchpad.net/ubuntu-app-platform/+bug/1643220
[13:10] <mup> Bug #1643220: ubuntu terminal app (edge) Unrecognized OpenGL version <Snappy:Incomplete> <Ubuntu App Platform:New> <Ubuntu Terminal App:New> <https://launchpad.net/bugs/1643220>
[13:11] <didrocks> renato__: is it in SNAP_LIBRARY_PATH?
[13:11] <didrocks> if so, I think snapd should then export it in LD_LIBRARY_PATH rather than having every single snap having to reexport this in a wrapper
[13:12] <renato__> didrocks, this is what zyga said.
[13:12] <renato__> didrocks, sould we add it on dekstop launcher?
[13:12] <didrocks> if you have a nvidia device, please try :)
[13:12] <didrocks> see my answer
[13:12] <didrocks> 14:11:47   didrocks | if so, I think snapd should then export it in LD_LIBRARY_PATH rather than having every single snap having to
[13:12] <didrocks>                     | reexport this in a wrapper
[13:12] <didrocks> launcher is really a fallback for things snapd should support
[13:12] <renato__> didrocks, I do not have a nvidia
[13:12] <didrocks> (or snap-confine in that case)
[13:19] <mup> Bug #1624322 changed: console-conf wlan race on pi3 <Snappy:Invalid> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1624322>
[13:19] <mup> Bug #1638661 changed: Undo on failed refresh doesn't keep the previous snap intact <Snappy:Invalid> <https://launchpad.net/bugs/1638661>
[13:22] <zyga> didrocks: snap-confine or snapd won't set it but the wrappers from snapcraft use it and merge it into LD_LIBRARY_PATH
[13:24] <didrocks> zyga: thanks for the answer, so renato__, it means you should already have it exported ^
[13:27] <renato__> didrocks, I do not see the desktop-launcher using it. There is another wrapper above it?
[13:28] <didrocks> renato__: there is one created by snapcraft, indeed
[13:28] <didrocks> and from what zyga told, this one is supposed to do this override
[13:28] <didrocks> you can see it, it's at the root of your snap
[13:28] <didrocks> and has a .wrapper suffix
[13:29] <renato__> didrocks, ok got it. And it contains the SNAP_LIBRARY_PATH
[13:30] <didrocks> renato__: seems then your bug is different that this not being exported
[13:32] <zyga> renato__, didrocks: look at LD_LIBRARY_PATH at runtime and see what you have
[13:32] <zyga> renato__: perhaps the issue is that nvidia support is broken in some interesting way, I'd love to help you out to fix it
[13:33] <zyga> renato__: we don't have real CI for nvidia support at this time
[13:33] <zyga> renato__: only to parts of it, but not really to see that it works
[13:33] <zyga> renato__: also, GL has different APIs and some of those might not work (the tests may be too simplisic)
[13:33] <renato__> zyga, I do not have a nvidia too. I was just trying to help and fix the problem
[13:33] <zyga> renato__: so thank you for pushing the border
[13:34] <zyga> renato__: I can try it on my hardware, tomorrow most likely as today I'm wrapping up last week actions and working on top-priority issues
[13:35] <renato__> zyga, ok thanks. this is not a priority
[13:43] <mup> Bug #1470661 changed: Tilde allowed in version but systemd hates it <Snappy:Invalid> <Snappy 15.04:Won't Fix> <Snappy trunk:Invalid> <https://launchpad.net/bugs/1470661>
[13:45] <jdstrand> jamespage: hey, not sure if you realize, but glance can be published by pushing the 'publish' button. I just noticed it and thought I'd mention it. ignore me if you already knew this
[13:45] <renato__> zyga, I got my snap on this state: http://paste.ubuntu.com/23511705/
[13:45] <renato__> zyga, I can not install any other snap
[13:45] <timp> renato__, sergiusens: actually in my case it pulls the dependencies of a deb package that I need. I guess there is no way around that?
[13:46] <renato__> timp, ok but it pack the deps? Or it only packs the files that you specified?
[13:46] <sergiusens> timp nope, you will have to change the dep in the deb to be a recommends and SRU or propose it
[13:47] <renato__> sergiusens, the deps are necessary they must be real deps. But we do not need it on the snap since the platform will provide it
[13:47] <timp> sergiusens: the runtime dependencies in the deb are correct, but they are in the platform snap already.
[13:48] <renato__> I do not mind it pulling the deps. I just do not want it in the package
[13:50] <jdstrand> tedg: I didn't see that ping before, but I see this one
[13:51] <liuxg> kyrofa, ping
[13:53] <tedg> jdstrand: heh, okay.
[13:54] <tedg> jdstrand: can haz undefined interfaces?  😉
[13:55] <zyga> jdstrand: in go switch/case has an implicit break
[13:55] <zyga> jdstrand: classic confinement doesn't fall through and go to devmode confinement
[13:56] <zyga> jdstrand: or did I misunderstand your comment there
[13:57] <jamespage> jdstrand, yup I think that's done for the edge channel
[13:57] <liuxg> currently, I follow the link at http://docs.ubuntu.com/core/en/guides/build-device/config-hooks, if I use "snap set <snapname> username=foo pass_word=bar", I cannot get the "pass_word" in credential file due to the "_" in the "pass_word". this is a bug?
[14:00] <jdstrand> zyga: I think you misunderstood. look at case.StrictConfinement
[14:00] <zyga> jdstrand: I think I see what you mean now
[14:00] <jdstrand> zyga: if f.JailMode
[14:00] <zyga> jdstrand: I just replied
[14:00] <jdstrand> zyga: then you have a comment talking about devmode
[14:00] <zyga> jdstrand: yes, because the comment refers to the check for devmode *flag* below
[14:01] <zyga> jdstrand: if both flags are set I pick jailmode
[14:01] <jdstrand> zyga: but, we are in snap.StrictConfinement
[14:01] <jdstrand> I'll read your comment
[14:01] <zyga> jdstrand: but even in that confinement we can have either or both of the flags set
[14:04] <jdstrand> I added a new comment
[14:05] <zyga> jdstrand: sure, I'll do that; thanks
[14:06] <zyga> jdstrand: if you can also review https://github.com/snapcore/snapd/pull/2315 I could land it, it's a big mechanical change to how devmode is conveyed
[14:06] <mup> PR snapd#2315: many: use snap.ConfinementType rather than bool devmode <Created by zyga> <https://github.com/snapcore/snapd/pull/2315>
[14:08] <jdstrand> zyga: I reviewed that with a cursory review and it looked fine, but an in depth review will have to wait a bit. I'm trying to get the dbus interface up in a PR today so there is a chance of it landing before I go on holiday on wed
[14:09]  * zyga nod
[14:10] <topi`> is there a channel for Ubuntu Snappy?
[14:10] <topi`> I guess I mean Ubuntu Core
[14:14] <jdstrand> seb128, mhall119: hey, are there workking devmode snaps that are blocked on bug #1590679?
[14:14] <mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
[14:14] <jdstrand> seb128, mhall119: I've been told they should be available, but I don't know where to find them
[14:15]  * jdstrand is trying to get gnome-mahjongg into runnable state atm since that is all I have to work with atm and it fails to launch with my dbus changes
[14:15] <seb128> jdstrand, robert_ancell had a stack of GNOME ones he was working on that he didn't publish/that are blocked on that
[14:15] <seb128> what error do you get?
[14:16] <jdstrand> seb128: it segfaults. seems he stopped cause of the apparmor denial. I think it just needs the gtk desktop part
[14:16] <jdstrand> seb128: but I'm looking for a working devmode snap. did he upload any of those?
[14:17] <seb128> jdstrand, the one I pointed out in comment #18 should work
[14:17] <jdstrand> cause, you can publish to edge with devmode fine
[14:17] <seb128> right, I don't know if he did that
[14:17] <seb128> I would assume not
[14:17] <jdstrand> let me try the gnome-logs one
[14:17] <jdstrand> seb128: there is a gnome-logs in the store in strict mode. is that this?
[14:18] <seb128> I don't remember if I uploaded that by then
[14:18] <seb128> but it's probably it yes
[14:18] <jdstrand> oh it didn't pass review
[14:19] <seb128> there was some dangling symlinks or something iirc?
[14:19] <seb128> it has been a while, I don't remember the details
[14:19] <jdstrand> yes
[14:19] <jdstrand> that's fine
[14:19] <jdstrand> I think I can move forward with it
[14:19] <seb128> great
[14:20] <seb128> let me know if I can help in any way
[14:25] <mup> Bug #1642669 opened: Can't connect to SnapdLoginService from a snap <snapd-glib:Confirmed> <Snappy:New> <https://launchpad.net/bugs/1642669>
[14:26] <lazyPower> didrocks: hey there. I made some progress but as we suspected i'm blocked on loading the plugins (despite the .so files being assembled and packed in the snap)  https://github.com/chuckbutler/snap-weechat/blob/master/snapcraft.yaml
[14:27] <lazyPower> didrocks: If you have any ideas on that one, i'm keen to experiment
[14:27] <jdstrand> seb128: ok, it is working
[14:27] <seb128> jdstrand, great!
[14:33] <didrocks> lazyPower: is there any way to point weechat to the directory where the .so files are?
[14:33] <didrocks> lazyPower: I guess the only way is to dive into the code and see if that can set or patchs to be configurable :)
[14:33] <didrocks> I guess -DCMAKE_INSTALL_PREFIX=/usr is what influences it
[14:34] <lazyPower> yeah, i was surprised just defining the customopts flag forced me to set that, as it seems to be set inherently when using the flag in snapcraft.yaml (for the cmake builder)
[14:34] <didrocks> yeah, I guess we are back in the issue on projects which forces to set prefix and we don't know the prefix in advance
[14:35] <lazyPower> i'm sure there's a viable path forward here, i'm just nto familiar enough with the code base to make that call yet
[14:35] <didrocks> a workaround is to set it to /snap/<yoursnapname>/current/ but then, you will have /snap/<yoursnapname>/current/snap/<yoursnapname>/current/ directory when installed
[14:35] <didrocks> and so, you will need to move it back on that
[14:35] <lazyPower> hmm interesting
[14:36] <didrocks> seb128: I don't remember, we raised this with Gustavo, right? did we get any feedback?
[14:36] <didrocks> lazyPower: I would say experiment first that way, to see if this is coming from this, but there is big chance that's the issue
[14:38] <seb128> didrocks, right, I think that's still an unresolved one...
[14:39] <elopio> pitti: ping. To quickly solve the sudo errors on autopkgtest armhf I added needs-root to the tests. But Sergio tells me we can add a sudoer user without a password, and that confused me. How can we modify /etc/sudoers before the tests run?
[14:40] <didrocks> lazyPower: so, if that works, I would suggest that you send an email to the ML and CC Gustavo (you can tell I denounced him :p), knowing that it was already discussed
[14:41] <pitti> elopio: the test has root, so it can do anything to the testbed, including adding to /etc/sudoers.d
[14:44] <elopio> pitti: that is if the test has needs-root. I would like to run the tests as a normal user, but be able to install debs. So should I do "su normal-user" after adding normal-user to sudoers?
[14:46] <pitti> elopio: you can do that, or have a first "prepare" pseudo-test that runs as root and sets up sudoers, then the actual test can run as normal user
[14:47] <Chipaca> alex-abreu: you're welcome! :-D
[14:47] <pitti> whichever seems more appropriate
[14:47] <lazyPower> sounds reasonable didrocks. will do
[14:48] <didrocks> lazyPower: keep us posted!
[14:50] <elopio> pitti: ok, I like the pseudo-test, I will try that. And last question (for now :), to try to understand. Why do we have passwordless sudo in the amd64 runners but not on this lxc armhf ones?
[14:50] <pitti> elopio: apparently cloud-init sets up password less sudo, but lxc images don't by default
[14:51] <pitti> s/cloud-init/cloud images/
[14:52] <topi`> is there a good FAQ about the differences between Snaps and regular deb packages?
[14:52] <topi`> I know there is some kind of container involved so that the Snap only sees a part of the filesystem
[14:53] <elopio> pitti: got it. Thanks.
[14:55] <topi`> If I look at developer.ubuntu.com/snappy/start, it seems there is a bunch of "supported HW" like DragonBoard or RPi or Intel NUC, however, if I have another board like the ODROID-C2, can it be supported as well?
[14:56] <topi`> I guess what I want to ask, what's so special about these few boards?
[15:32] <mup> Bug #1473218 changed: TMPDIRs are not cleaned out/are not correctly preserved across app invocations <Snappy:Fix Released> <https://launchpad.net/bugs/1473218>
[16:07] <alex-abreu> Chipaca, mvo I updated the PR, I am not sure about the landing of this since the sections & empty find bits are still in staging AFAIK
[16:08] <Chipaca> alex-abreu: what's staging do with empty find?
[16:08] <alex-abreu> Chipaca, it changes a bit the semantics of it, it returns a list is 'featured' snaps
[16:08] <Chipaca> alex-abreu: ah, that's done already? nice
[16:09] <alex-abreu> Chipaca, yes
[16:09] <Chipaca> alex-abreu: when does it get rolled out?
[16:11] <alex-abreu> Chipaca, this is what I am trying to find out
[16:21] <alex-abreu> Chipaca, mvo ok nessita just confirmed me that all those bits are in prob already
[16:21] <alex-abreu> Chipaca, mvo I will test it now with the branch
[16:22] <alex-abreu> & add a comment
[16:22] <mvo> alex-abreu: aha, nice. so an empty find returns now the featured ones? thats great
[16:22] <Chipaca> alecu: I can confirm prod just responded as I would expect to a snap/sections query
[16:23] <alex-abreu> mvo, yes
[16:23] <mvo> \o/
[16:23] <alex-abreu> Chipaca, nice !
[16:23] <nessita> \o/
[16:23] <mvo> out of curiosity, what makes a snap featured?
[16:23] <plars> I'm trying to add a .desktop and icon for a snap that I have, as apparently that's required by the review now? I've looked at some of the playpen snaps that do it and it looks like all they do is add a gui/setup dir in the project dir with those files in it. I've done that, and the snap seems to contain the files when I'm done, but I don't see an entry for
[16:23] <plars> it when I search in unity. Should I?
[16:24] <zyga> plars: depends on what's in the desktop file
[16:24] <zyga> plars: look at /var/lib/snapd/destkop
[16:24] <zyga> plars: we rewrite those desktop files after sanitization, if the rewritten one doesn't have an Exec line you won't find it
[16:24] <plars> zyga: *sigh* apparently all I had to do was ask, because now it shows up and works perfectly, but it didn't a few minutes after I installed the snap
[16:25] <zyga> plars: ah, that might be unity then
[16:25] <plars> zyga: I'm guessing something needed to update
[16:25] <plars> yeah
[16:25] <alex-abreu> mvo, I am not sure, ...
[16:25] <plars> zyga: thanks :)
[16:25] <plars> zyga: what other sanitization do you do? All I did was add ${SNAP} to the path for the Exec and Icon lines.
[16:26] <zyga> plars: I don't recall but we effectively rewrite the file, only allowing certain keys to show up
[16:26] <mvo> alex-abreu: thanks, thats fine, just curiosity on my side
[16:26] <zyga> plars: and we're extra careful with keys that have sensitive meaning
[16:27] <Chipaca> alex-abreu: mvo: nessita: an empty search returns all
[16:27] <plars> zyga: not sure what you mean, most of the one that is normally installed is translations of the name, otherwise just the exec, Icon, etc
[16:27] <Chipaca> alex-abreu: can you make your branch keep the check for empty? then we can land the rest of it
[16:28] <Chipaca> alex-abreu: or!
[16:28] <Chipaca> hold on
[16:28] <mvo> Chipaca: aha, that is what I saw earlier today, I got e.g. test-snapd-xkcd-webserver. I assumed this was just bad timming on my part
[16:28] <Chipaca> how was this
[16:28] <mvo> (and exactly 100 results)
[16:28] <zyga> plars: there's whole zoo of keys, I don't think we allow translation yet, we mostly validate the exec line
[16:28] <mvo> so it looked very much like before
[16:28] <Chipaca> so what we want is:
[16:28] <Chipaca> empty -> list sections
[16:28] <Chipaca> no?
[16:28] <plars> zyga: ok, I'll try it and see if review chokes on the translations. If so, I can always remove those
[16:28] <Chipaca> that is, 'snap find' on its own list sections?
[16:29] <Chipaca> then 'snap find --section' does the necessary thing
[16:29] <alex-abreu> Chipaca, well no afaik, ...
[16:29] <alex-abreu> Chipaca, (sorry otp now)
[16:29] <Chipaca> hmm
[16:29] <Chipaca> oh alright
[16:29] <Chipaca> mvo: there's a "featured" section
[16:29] <Chipaca> maybe empty find implies featured?
[16:30] <mvo> Chipaca: yeah, that is what I would think
[16:30] <alex-abreu> Chipaca, that's the idea I think
[16:30] <mvo> snap find
[16:30] <mvo> cool stuff
[16:30] <Chipaca> mvo: http https://search.apps.ubuntu.com/api/v1/snaps/search X-Ubuntu-Release:16 Accept:"application/hal+json" X-Ubuntu-Architecture:amd64 X-Ubuntu-Wire-Protocol:1 section==featured | jq '..|.name?//empty'
[16:32] <Chipaca> alex-abreu: ok, if your branch can do one of those two then we'd be sorted
[16:32] <mvo> nice
[16:32] <Chipaca> alecu: one of those two == revert to blocking empty, or search featured on empty
[16:32] <Chipaca> alex-abreu: ^ you, sorry
[16:32] <Chipaca> alecu: you're awesome, but i didn't mean to distract you with this
[16:32] <alex-abreu> Chipaca, ... I'd have to reread all that, I'll do it when not otp
[16:33] <Chipaca> alex-abreu: we're signing you up for cat facts while you're distracted. Just sign here: [ ]
[16:36] <alex-abreu> Chipaca, I need to read the small prints
[17:30] <alecu> Chipaca: am I?
[17:30]  * alecu blushes...
[17:48] <zyga> lool, jdstrand: https://github.com/snapcore/snap-confine/pull/185
[17:48] <mup> PR snap-confine#185: Detach the hostfs version of /dev <Created by zyga> <https://github.com/snapcore/snap-confine/pull/185>
[17:55] <cjwatson> icey: network access during build> don't have an exact timeline but we're agreed that we're going to do it and it will be soonish
[17:56] <cjwatson> flexiondotorg: ^- FYI
[17:56]  * cjwatson hadn't quite noticed how far backlogged he was
[17:57] <kyrofa> cjwatson, excellent news :)
[17:57] <alex-abreu> Chipaca, ok so I checked the store & PR for the empty find stuff, and it does seem to work as intended and defaults to the featured snaps list ...
[17:58] <alex-abreu> Chipaca, for me, ... could you test again? or maybe I misunderstood your comments
[18:02] <jamespage> jdstrand, hey any thoughts on my openvswitch-{support} naming question from earlier today?
[18:11] <jdstrand> jamespage: sorry, I missed it. I'm looking at it. I'm wondering if this needs a separate interface. '/{,usr/}{,s}bin/nice ixr,' should be added to process-control and then you plugs: process-control. you could also plugs: network-control for sys_admin and netlink
[18:11] <jdstrand> jamespage: run-parts is possibly part of the default template
[18:11] <jdstrand> . jamespage that leaves sys_resource and @{PROC}/@{pid}/comm
[18:12] <jdstrand> and maybe a syscall or two to investigate
[18:13] <jdstrand> jamespage: I think you would then 'plugs: [ process-control, network-bind, network-control ]'
[18:13] <Chipaca> alex-abreu: sorry, didn't see this. What do you want me to look at?
[18:15] <Chipaca> alex-abreu: ah! just noticed the search without an empty q but also with an empty section returns featured
[18:15] <alex-abreu> Chipaca, when doing a snap find, I do indeed default to a featured snap find ... which ends up sending a store request like search?q=&section= that the store interprets as 'return the list of featured snaps'
[18:15] <alex-abreu> yes
[18:15] <jdstrand> jamespage: capability sys_resource could go to process-control for setting rlimits
[18:15] <Chipaca> i wish the api didn't do that, because it's very non-intuitive, but it does that, so i guess it's alright
[18:15] <alex-abreu> which is not the same as search?q=
[18:16] <alex-abreu> Chipaca, sort of agree, I talked to them about that and they seem to have specific backward compat reasons
[18:16] <Chipaca> yeah, i am aware
[18:16] <Chipaca> whine whine moan moan <-- me
[18:16] <jdstrand> jamespage: '@{PROC}/@{pid}/comm r,' goes to default apparmor template
[18:16] <zyga> jdstrand: one more https://github.com/snapcore/snap-confine/pull/186
[18:16] <mup> PR snap-confine#186: Detach the hostfs version of /proc <Created by zyga> <https://github.com/snapcore/snap-confine/pull/186>
[18:18] <jdstrand> jamespage: (use 'owner @{PROC}/@{pid}/comm r,' and put it under @{PROC}/@{pid}/cmdline)
[18:18] <jdstrand> jamespage: yes, run-parts to default template
[18:19] <jdstrand> jamespage: I think that will give you everything without needed a new interface
[18:19] <flexiondotorg> cjwatson, Thanks for confirming.
[18:29] <jdstrand> jamespage: I commented in the PR
[18:33] <mup> Bug #1643220 changed: ubuntu terminal app (edge) Unrecognized OpenGL version <Snappy:Incomplete> <Ubuntu App Platform:New> <Ubuntu Terminal App:New> <https://launchpad.net/bugs/1643220>
[18:40] <icey> cjwatson: cool! worked around it already but good news ;-)
[19:10] <alex-abreu> Chipaca, thx for the +1, not sure I understand the spread failure though ... seems to be an infra failure?
[19:11] <Chipaca> alex-abreu: yeah; restarted it
[19:11] <alex-abreu> thx
[19:17] <alex-abreu> Chipaca, does it auto lands when the PR is +1d ?
[19:24] <jdstrand> niemeyer, mhall119, seb128: fyi, https://github.com/snapcore/snapd/pull/1613 is now ready for review
[19:24] <mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
[19:39] <davmor2> Chipaca: hey dude I installed the terminal app from edge and it told me to install ubuntu-app-platform did that connected them and it still throws up the same error to install the platform and connect them is there anything I can do to check the issue?
[19:42] <davmor2> hmm snap interfaces shows the connection so now I'm confused
[19:43] <ssweeny> wasn't there some bug where if you ran an app without a content interface connected you had to reinstall the app before it would work?
[19:45] <jdstrand> tyhicks: hey, do you have 5 minutes to discuss something? if not or discussing later is totally fine
[19:45] <tyhicks> jdstrand: hey, sure
[19:46] <jdstrand> let me get you a paste
[19:46] <jdstrand> tyhicks: the context is https://github.com/snapcore/snapd/pull/1613
[19:46] <mup> PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
[19:48] <jdstrand> tyhicks: http://paste.ubuntu.com/23513083/
[19:48] <jdstrand> tyhicks: it'll be easier to look at the resulting policy
[19:48] <tyhicks> ok
[19:48] <jdstrand> tyhicks: what this paste contains is the (relevant portions of the) dbus rules for the dbus app interface
[19:49] <jdstrand> tyhicks: the context is gnome-logs slots this interface so it can bind to a well-known name. there are some classic rules and then d-feet rules which plugs the gnome-logs slot
[19:50] <jdstrand> tyhicks: the first 3 rules are what one would expect
[19:50] <jdstrand> tyhicks: the 4th is slightly interesting with this path: path="{/,/org,/org/gnome,/org/gnome/Logs}"
[19:51] <jdstrand> tyhicks: well, the 4th is a classic rule, it gets more interessting with the slot rules
[19:51] <jdstrand> tyhicks: go to line 40
[19:51] <jdstrand> tyhicks: that path has path="{/,/org,/org/gnome,/org/gnome/Logs}"
[19:51]  * tyhicks nods
[19:52] <lof_mt> Hi there. I am trying to get a gtk3 app packaged as snap. It compiles and builds the package. But when i start the snap the application complains about gsettings schemes not being installed.
[19:52] <jdstrand> tyhicks: this is a slight info leak if /org or /org/gnome had things to introspect, but it is only a leak on what the gnome-logs service might be setting up
[19:53] <jdstrand> tyhicks: ie, if gnome-logs had things to introspect on /org or /org/gnome, then d-feet could see it. it isn't a big deal. just wanted to mention it
[19:53] <lof_mt> Here the last-1 version of the snapcraft file. I added the gtk part recommended in the answer to the issue: https://github.com/jangernert/FeedReader/issues/268
[19:53] <jdstrand> tyhicks: what I really wanted you to see was the last two rules
[19:54] <tyhicks> jdstrand: I'm not too worried about the rule at line 40
[19:54] <jdstrand> tyhicks: note that one has an interface= but no path= and the other a path= but no interface=
[19:54] <jdstrand> tyhicks: yeah, me either-- it is just slightly imperfect-- a plugging client could plugs all of the gnome-logs api so it isn't a big deal
[19:55] <tyhicks> ok, thinking about those last two..
[19:55] <jdstrand> tyhicks: I don't think these last two are problematic either-- everything is bound to labels, etc, it is just a bit different that most rules
[19:56] <jdstrand> tyhicks: there reason why I did that is that apps use the org.freedesktop.* interface but with paths at /org/gnome/Logs
[19:56] <seb128> jdstrand, thanks for working on that! I'm done for today but I'm going to have a try tomorrow
[19:56] <jdstrand> tyhicks: but then I've seen a lot of apps that use '/' as the path with their foo.bar.blah interfaces
[19:56] <jdstrand> seb128: thanks!
[19:57] <jdstrand> seb128: I can promise that gnome-logs works ;)
[19:57] <seb128> :-)
[19:57] <jdstrand> tyhicks: so I was trying to allow both things in a way that still limited by well-known name
[19:57] <jdstrand> tyhicks: hence the slightly unconventional rules
[19:58] <tyhicks> jdstrand: like you said, the peer label is the most important thing
[19:59] <jdstrand> tyhicks: in other words, if I did 'interface="org.gnome.Logs{,.*}" path="/org/gnome/Logs{,/**}"' in the same rule, I was confident we'd hit stuff that would break
[19:59] <tyhicks> right
[19:59] <jdstrand> tyhicks: yes, and also, this is only a snippet from the slot implementation. the plugging side has peer labels to snap.gnome-logs-udt.gnome-logs-udt
[20:00] <jdstrand> tyhicks: so it is very tightly bound to these two snaps, but hopefully flexible enough to allow some compatibility
[20:00] <tyhicks> jdstrand: so you don't feel like you can foresee all of the possible paths that might be used?
[20:01] <jdstrand> tyhicks: oh gosh no. this interface is about "let the snap talk to that other snap's entire DBus api via that well-known name"
[20:02] <jdstrand> tyhicks: but trying to have enough rules to say 'the command can access this org.foo.bar api and this command that org.foo.baz api"
[20:02] <jdstrand> tyhicks: I think it achieves it and it is safe, but wanted to run it by you since it is slightly unconventional
[20:04] <jdstrand> the one with just the path rule is nice cause you can get and set properties but only to /org/gnome/Logs (and deeper)
[20:04] <tyhicks> jdstrand: I don't see a problem. We're just trying to restrict communication between two known endpoints and those rules do just that.
[20:04] <jdstrand> tyhicks: cool-- me either but second pair of eyes is nice :)
[20:04] <jdstrand> tyhicks: thanks!
[20:04] <tyhicks> jdstrand: thanks for running it by me
[20:05] <jdstrand> tyhicks: that might've been closer to 10 minutes, sorry :)
[20:08] <tyhicks> no worries :)
[20:39] <lof_mt> ping, flexiondotorg: https://paste.ubuntu.com/23513341/ this builds on 16.10 but lacks gsettings schemas. How do i get them in there?
[21:04] <_markfeatherston> How does an ubuntu core device get automatically updated with the latest snaps?  Does this need something like a cron job to kick off updates, or is it handled automatically some other way?
[21:06] <Chipaca> _markfeatherston: right now it's "something like a cron job"
[21:06] <Chipaca> _markfeatherston: serious, curious question: why do you care?
[21:06] <Chipaca> (asking because it might change)
[21:06] <_markfeatherston> I just added support for our TS-4900/TS-7970/TS-TPC-7990 devices.
[21:07] <_markfeatherston> I'm going to have customers asking me how this would work
[21:07] <Chipaca> _markfeatherston: systemd has timers, which is like cronjobs but rather more expressive
[21:07] <_markfeatherston> We have  few real application use cases too, as long as there is some way to control when or how often it happens that would be enough
[21:07] <Chipaca> _markfeatherston: we use that
[21:07] <_markfeatherston> Ahh, ok
[21:08] <nacc> https://developer.ubuntu.com/en/snappy/guides/autoupdate/, maybe helps?
[21:08] <nacc> not sure if that is current, but it seems like it might be for this case
[21:08] <Chipaca> nacc: that's for 15.04
[21:08] <nacc> Chipaca: ah ok
[21:08] <Chipaca> interestingly I wouldn't know that just from the url
[21:09] <nacc> right :)
[21:11] <_markfeatherston> another more basic question, after I go through the device configuration and connect through ssh is that the only way to connect to the device?
[21:11] <_markfeatherston> The serial port starts getty which has a login prompt, but I'm not sure what if any accounts allow login like that
[21:12] <_markfeatherston> I understand I can likely add my own users, I'm just trying to understand what happens by default
[21:18] <mup> PR snapcraft#922 opened: On gradle unit tests, unset the proxies <Created by elopio> <https://github.com/snapcore/snapcraft/pull/922>
[21:31] <kyrofa> _markfeatherston, man your nick is hard with the leading underscore :P
[21:32] <kyrofa> _markfeatherston, indeed, initially the only way to connect is via the SSH keys
[21:32] <kyrofa> _markfeatherston, this is to prevent marai ;)
[21:33] <_markfeatherston> lol, i'll have to look into fixing that.
[21:33] <_markfeatherston> thanks
[21:34] <_markfeatherston> Last one for now, are there any plans to facilitate remote connections behind NAT or anything to manage remote units?
[21:34] <kyrofa> _markfeatherston, I suspect this is (or will be) integrated into Landscape somehow
[21:37] <_markfeatherston> that would be useful
[22:17] <Chipaca> _markfeatherston: once you ssh in you can use 'passwd' to then use the gettys, fwiw
[22:26] <icey> how does one get the namespace (snap-package.app) removed, so that it's run at just the app name?
[22:27] <kyrofa> icey, if app name == snap name, you can just use snap name
[22:27] <kyrofa> icey, but that's the only way
[22:27] <kyrofa> icey, otherwise there's no way to prevent conflicts
[22:28] <icey> ah, so make the name the same?
[22:28] <kyrofa> icey, indeed, if snap name = foo and app name = bar, then you need to use foo.bar. But if app name = foo, then you can just use foo
[22:29] <icey> great, thanks!
[22:31] <icey> separate question, any chance for a review on https://github.com/snapcore/snapcraft/pull/908 now that tests are passing?
[22:31] <mup> PR snapcraft#908: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908>