[00:56] Bug #1676244 opened: Environment keyword not parsed correctly === chihchun_afk is now known as chihchun [03:01] does this package python stuff also? Im confused === Eleventh_Doctor is now known as Pharaoh_Atem [07:04] in snap apps, is there any environment variable get the path like /home//Pictures? thanks [08:10] liuxg: $SNAP_DATA is what is normally used for user data. [08:11] liuxg: Or use $HOME. In 'normal' snaps it is the same as $SNAP_DATA, and in 'classic' snaps it is the real $HOME [08:48] PR snapd#3085 opened: .travis.yml: remove travis matrix and do a single sequential run [09:07] PR snapd#3002 closed: interfaces: add support for location-observe for dbus::ObjectManager session paths [09:07] PR snapd#3086 opened: interfaces: fix for access denied of opengl interface [09:18] PR snapd#3087 opened: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now [10:26] PR snapd#3069 closed: snapstate: restart as needed if we undid unlinking aka relinked core or kernel snap [10:39] mardy, hey, i'm about to update your online-accounts interface branch for snapd for the latest API changes; do you have any changes you want to commit first? [11:20] pstolowski: no, I cannot think of anything [11:24] it seems that ubuntu make (classic confinement) rev 2, 3 & 4 were accepted, but rev 1 was leftover which is amd64, can someone from the store team review it? [11:32] mardy, ack, thanks [11:35] Pharaoh_Atem: is "Request Approveacls" on https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-go-tomb-tomb/ what I want to get co-maintainership for that package? [11:48] PR snapd#3088 opened: snapstate: restart as needed if we undid unlinking aka relinked core or kernels snap [12:08] Pharaoh_Atem: one step closer: https://bugzilla.redhat.com/show_bug.cgi?id=1435616 [13:53] kyrofa: hey, sorry I missed you. I don't have experience writing gadget snaps, but can say that I susepect those need to be strings, yes, but there may also be a problem surrounding serialDeviceNodePattern is serial_port.go [13:54] kyrofa: is /dev/kobuki a symlink or the actual device name? if a symlink, what does it point to? [13:54] kyrofa: also serialUdevSymlinkPattern may get in the way [13:55] kyrofa: it might work as is if you change to strings and use 'name: /dev/serial-port-kobuki' instead [13:56] you might not need to change to strings [13:58] Bug #1670749 changed: classic confinement requires manually setting PATH and PYTHONPATH [13:58] Bug #1672872 changed: error while loading shared libraries: libpython2.7.so.1.0 [14:40] PR snapd#3088 closed: snapstate: restart as needed if we undid unlinking aka relinked core or kernels snap (2.23) === chihchun is now known as chihchun_afk [15:12] jdstrand, thanks for the insight! I'll try that. I was under the impression that /dev/kobuki would be created as a symlink to the actual device [15:12] kyrofa: it will, but /dev/kobuki doesn't match the serialUdevSymlinkPattern regex [15:13] try /dev/serial-port-kobuki and see if that works [15:13] Will do [15:21] morphis: you want to request approveacls and commit acls [15:32] Pharaoh_Atem: aye [15:32] Pharaoh_Atem: however we got the package updated in rawhide [15:32] Pharaoh_Atem: and I am still waiting for my package requests to get approved [15:32] morphis: you should request it to be backported to F26 and F25 [15:33] oh nevermind [15:33] he's already doing it [15:33] Pharaoh_Atem: were do you see that? [15:33] just saw the bug report update [15:34] https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb [15:34] ah [15:34] nice [15:53] jdstrand: hey! [15:53] morphis: hey :) [15:53] jdstrand: regarding https://github.com/snapcore/snapd/pull/3086 [15:53] PR snapd#3086: interfaces: fix for access denied of opengl interface [15:53] is mvo back yet? [15:54] morphis: I commented a bit earlier [15:54] jdstrand: my fear is that if we only update the opengl interface we break other apps already in the store [15:54] so we have to better update all interfaces all-together to use udev-tagging [15:54] and do this in a single snapd release to not cause any regression [15:56] morphis: I'm fine with that approach too (in fact I prefer it) [15:56] jdstrand: me too, and we will do that work afterwards [15:56] already have a story for our next sprint [15:57] morphis: at first I was thinking that this would affect few snaps, but I think your instinct is corrent. I suspect the vlc snap would break cause it uses opengl with optical-drive (for example) [15:57] yeah [15:57] correct* [15:57] something like this, we could get a list from the store about used combinations etc. [15:57] but that still has the chance of breaking unasserted snaps installed by people [15:57] jdstrand: https://trello.com/c/bK7u2g7s [15:59] morphis: it shouldn't break unasserted snaps. core gets updated and all the security policy (include the /etc/udev/rules.d files) get regenerated [15:59] gets* === JanC_ is now known as JanC [15:59] * jdstrand is talking about if all the interfaces are updated [15:59] jdstrand: yeah meant the case where we just update opengl [16:00] jdstrand: so you're ok with updating just opengl for now with access to /dev/fb* and adjusting all interfaces in a second snap to use udev tagging? [16:00] I guess you meant 'second step' there === dpb1_ is now known as dpb1 [16:00] ah yeah .. too much 'snap' these days :-) [16:01] I really don't like adding /dev/fb* to opengl. opengl is autoconnected and framebuffer is not. /dev/fb gives privileged access to the console framebuffer [16:02] and adding it to opengl will give all snaps that plugs it additional access that they shouldn't have. it is autoconnected so that is a security issue. then, while phase 2 is being worked out there might be a snap that depends on /dev/fb* in opengl and we break it with the next core update [16:03] I think the snap that is affected by the snap should remove framebuffer from its yaml and wait for the proper fix [16:03] and/or use devmode in the meantime [16:03] by the bug* [16:04] jdstrand, good news so far, changing the symlink to conform with that regex makes the slot show up in snap interfaces now, and the symlink is created [16:04] jdstrand, do you know the rational behind that regex? It seems somewhat arbitrary [16:06] kyrofa: it is so that the symlinks in /dev are namespaced in predictable ways. This was something niemeyer thought through and I agree with the approach. consider if we didn't have the regex and two interfaces could create /dev/something and a gadget (or with hotplugging, core) has both [16:06] kyrofa: snapd can't really resolve that intelligently [16:08] jdstrand, doesn't it just mean that we have the same problem with /dev/serial-port-something now? [16:08] Less of an issue admittedly [16:08] jdstrand, anyway, not a big deal to me so much as the total lack of feedback when I didn't match it [16:08] I'm logging a bug for that [16:09] kyrofa: that is within the same interface though. a gadget snap author can avoid that. it is possible that core and gadget could conflict when hotplugging is supported, but that is something that will need to be thought through in the hotplugging design [16:09] jdstrand, fair enough, thanks for the explanation! [16:10] kyrofa: note that the naming isn't arbitrary. the convention is '-' [16:10] jdstrand, indeed, that makes more sense [16:30] PR snapd#3086 closed: interfaces: fix for access denied of opengl interface === lazyPower is now known as lp|Kubecon [17:32] davidcalle, if I saw an issue with a codelab on tutorials.ubuntu.com, where would I log a bug? [17:32] davidcalle, unping, you very nicely include a link there that answers my question [20:58] Bug #1676614 opened: snap install canonical-livepatch fails on system with nvidia driver [21:22] jdstrand: hey, r852 is now in production [23:00] PR snapcraft#1171 closed: beta