[05:12] <mborzecki> morning
[05:22] <mvo> hey mborzecki, good morning
[05:29] <zyga> Good morning
[05:30] <mvo> zyga: good morning to you as well
[05:35] <mborzecki> zyga: mvo: hey
[05:51] <zyga> I will be at my desk shortly
[06:20] <zyga> and back
[06:20] <zyga> man, it's such a hot day already
[06:20] <zyga> it will easily be +30C
[06:22] <zyga> Coffee and reviews
[06:42] <zyga> mvo: interesting thing that may affect us soon: https://github.com/systemd/systemd/issues/8221
[06:43] <mvo> zyga: thanks
[06:45] <zyga> pstolowski|afk: ^ this is also related to your work closely
[06:55] <zyga> I cannot believe how terrible udev scripting is
[06:55] <zyga> it's the least sensible syntax
[06:55] <zyga> used an virtually all the linux machiens
[06:55] <zyga> *machines
[06:56] <zyga> eh
[06:57] <mborzecki> zyga: tried cmake? :)
[06:57] <zyga> yes, I hate it too but at least it's a language with regular-ish syntax
[06:57] <zyga> (except for that crazy upper-case madness)
[06:57] <zyga> but udev is really the assembly
[06:57] <zyga> line oriented
[06:57] <zyga> obscure
[06:57] <mborzecki> lowercase works too
[06:58] <mborzecki> still the syntax garbage
[06:58] <zyga> if udev rules were like pascal it would be a huge improvement
[06:58] <zyga> and that says a lot
[06:58] <mborzecki> heh
[06:58] <zyga> so after growing up on Pascal someone made a crappy hand-crafted line "parser"
[06:58] <zyga> because that's the best we can do?
[06:58] <zyga> eh
[06:58] <mborzecki> wish we made more use of tcl historically
[06:59] <mborzecki> one of the nicer 'glue' languages i used
[07:00] <zyga>  the other side of udev is also weird, why on earth is the "state" a zoo of files in /run
[07:00]  * zyga stops ranting
[07:03] <pstolowski> good morning!
[07:18] <zyga> mborzecki: is https://github.com/snapcore/snapd/pull/5199 good for landing now?
[07:18] <mup> PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
[07:19] <mborzecki> zyga: got some comments from niemeyer, fixing them atm
[07:20] <mborzecki> zyga: i think we can land #5203
[07:20] <mup> PR #5203: interfaces/joystick: also support modern evdev joysticks and gamepads <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5203>
[07:20] <zyga> mborzecki: jamie said he would write a test
[07:20] <zyga> though it can probably land separately
[07:25] <mvo> zyga: +1
[07:25] <mvo> (for landing the joystick thing)
[07:26] <zyga> done
[07:27] <mup> PR snapd#5203 closed: interfaces/joystick: also support modern evdev joysticks and gamepads <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5203>
[08:14] <mborzecki> #5091 can be merged when it's green
[08:14]  * zyga -> breakfast
[08:14] <mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
[08:14] <pedronis> mborzecki: where you talking about it before or #5199 ?
[08:14] <mup> PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
[08:15] <pedronis> s/where/were/
[08:15] <mborzecki> pedronis: yeah, mistook it for 5091 (i was fixing it), 5199 should can be landed now
[08:15] <mborzecki> (removed blocked tag)
[08:16] <pedronis> mborzecki: was the new test snap transfered?
[08:16] <pedronis> not a blocker for landing as such
[08:17] <mborzecki> pedronis: yes
[08:17] <pedronis> cool, thx
[08:18] <mborzecki> pushed some fixes to #4700, still neds a re-review from jdstrand but at least it should be passing tests now
[08:18] <mup> PR #4700: interfaces/builtin: add the dvb-video interface <Created by ThyMYthOS> <https://github.com/snapcore/snapd/pull/4700>
[08:18] <mup> PR snapd#5215 opened: Improved error handling when creating autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5215>
[08:24] <zyga> mborzecki: hey, question about arch packaging
[08:25] <zyga> mborzecki: will #5198 make arch automatically get the service script?
[08:25] <mup> PR #5198: data/systemd: add snapd.apparmor.service <Created by zyga> <https://github.com/snapcore/snapd/pull/5198>
[08:25] <zyga> and the corresponding service?
[08:26] <zyga> mvo: is this expected? https://github.com/snapcore/snapd/pull/5198/files#r191143359
[08:26] <zyga> you added the snapd.seeded.service unit
[08:26] <mup> PR #5198: data/systemd: add snapd.apparmor.service <Created by zyga> <https://github.com/snapcore/snapd/pull/5198>
[08:28] <pstolowski> pedronis: hey! would you like to discussus conflict stuff & connect?
[08:28] <newbee> I am trying to package an applications which uses a serial port as a Snap.  From the documentation I gathered that I should add the 'serial-port' plug and then connect it, But still in my snap it didn't list the serial-port. Help me to solve this.
[08:29] <zyga> newbee: where are you running your application? on classic system or on a all-snap/core device?
[08:29] <zyga> newbee: serial ports are only supported on the latter type for now
[08:30] <newbee> I running it on a snap core..
[08:30] <zyga> newbee: ok, what do you mean by "but still in my snap it didn't list the serial port"
[08:31] <newbee> Ubuntu 16.04 LTS.
[08:31] <zyga> ?
[08:31] <zyga> ubuntu 16.04 LTS is a classic system, serial port is not useful there yet
[08:31] <mvo> zyga: we have a new snapd.seeded which is used as a sync point. should be fine to have this on opensuse
[08:31] <mvo> zyga: or am I missing something?
[08:32] <zyga> mvo: I'm wondering why tests passed before, how is that unit installed?
[08:32] <zyga> mvo: it appears as before that unit was not installed at all
[08:32] <pedronis> it's fairly recent
[08:32] <pstolowski> newbee: after installing your snap check `snap change --last=install`, any errors there re your plug?
[08:33] <mborzecki> zyga: yes, on arch it's just make -C data install ...
[08:33] <mborzecki> zyga: you probably need to rm -f it like you do for fedora
[08:33] <zyga> mborzecki: thanks
[08:33] <zyga> ideally I would connect that to the --without-apparmor
[08:33] <zyga> but it's not easy
[08:34] <mvo> zyga: I don't know why it is working right now, let me look at master
[08:34] <mborzecki> yeah, you'd have to build data from the same setup as cmd is built, we've had 2 attempts already
[08:34] <mup> PR snapd#5091 closed: many: hold refresh when on metered connections <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
[08:34] <newbee> @pstolowski  there is no error listed..
[08:34] <zyga> newbee: can you tell me how your application is making use of the serial port? which port is it opening? how does it know? what's the expected use-case?
[08:35] <mvo> zyga: we install snapd.seeded.service for opensuse in master
[08:35] <mvo> zyga: maybe you need to merge master?
[08:35] <mvo> zyga: (into your PR)
[08:35] <zyga> mvo: hmm, AFAIK I did but I will re-check
[08:37] <newbee> @zyga  I need to connect the one of the listed serial port for transmitting the data. In my program i use the gnu.io jar to list the serial-port in system.
[08:37] <zyga> how does your program know which port to open?
[08:39] <newbee> zyga: I need to choose that manually on my application. In net-beans it works clearly.
[08:40] <zyga> newbee: ideally you would use interface hooks to get notified of connection and disconnection of the serial-port interface (or interfaces, you may have many) and do the right thing inside your application
[08:41] <zyga> newbee: but anyhow that does not work on classic systems because they don't have any serial port slot definitions
[08:41] <zyga> newbee: only core systems (those that only ship snap packages) use gadget snaps to define serial ports (e.g. raspberry pi)
[08:41] <newbee> @Zyga thanks. is there any examples for that?
[08:41] <zyga> newbee: of which part specifically?
[08:42] <newbee> @zyga  gadget snaps to define serial ports? how to create that file?
[08:43] <zyga> newbee: are you planning on making your own device? gadget snaps are a special type of snap that is only installed on a core device (all-snap system without classic packages) that is prepared by the device maker
[08:43] <zyga> you can find examples on GitHub.com/snapcore/ e.g. the pi2 gadget
[08:43] <newbee> @Zyga ok thank you..
[08:43] <zyga> but you cannot make one and install it on your system, it must come pre-made with a device
[08:44] <zyga> for classic systems (e.g. a laptop or desktop) that either have some built in serial ports (rare) or use usb-attached serial ports you need to wait for support for hot-plug that pstolowski is working on
[08:44] <zyga> in the end it will work exactly the same (for apps) as it does on core
[08:44] <zyga> you define one or more plugs of type "serial-port" on your snap
[08:45] <zyga> (you can name each one to match the indented function for the user)
[08:45] <zyga> you install that snap on some system
[08:45] <zyga> and then connect each plug on your snap to one of the serial port slots defined by the system (either statically or via hot-plug devices)
[08:45] <zyga> and using interface hooks your application is notified of each such operation and can store local state
[08:45] <zyga> (or notify a running service)
[08:46] <newbee> Ok I will try and let you know the result..
[08:46] <zyga> once connected the application process that has those plug definitions will get permissions to open those specific serial ports that are connected
[08:46] <zyga> it's not a simple set of things to happen but that's how it is designed to work
[08:46] <zyga> but again, on a classic system you cannot do that yet
[08:46] <zyga> you may try on a core device that defines a serial port statically for now
[08:49] <pedronis> mvo:  hi, can we create the 2_34 tag on the forum, for example for https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001
[08:50] <mvo> pedronis: sure, let me try to do that
[08:51] <mvo> pedronis: should be there now
[08:52] <pedronis> mvo: thank you
[09:09]  * zyga -> small break
[09:09]  * zyga has some fuzzy sight today
[09:13] <mvo> pedronis: quick question> for the prepare-image work with bases I will need a new test model that is signed with the developer1.account. I saw that you created developer1-pc.model and developer1-pc-w-base.model. I need one based on http://paste.ubuntu.com/p/V4HqpTCySv/  - whats the best way to do this?
[09:17] <pedronis> mvo: they are signed with the key  in asserts/assertstest
[09:17] <mvo> pedronis: thank you! that was the missing piece :)
[09:18] <pedronis> I used a small go program to sign them
[09:18] <mvo> pedronis: I was about to ask about this, do you think you could share the program or just sign http://paste.ubuntu.com/p/V4HqpTCySv/  got me?
[09:19] <pedronis> mvo: one sec
[09:19] <mvo> pedronis: sure, thank you!
[09:20] <pedronis> mvo: I'll share a gist of what I have, less spoffy
[09:20] <mvo> pedronis: also lol@removing the "simple" label from 5213 (its true, it started simple and it got downhill from there)
[09:20] <mvo> pedronis: yeah, gist is fine
[09:22] <pedronis> mvo: something like this,  this how I signed the -w-config one,  https://gist.github.com/pedronis/256ac00d78c8f075614df3ff5c21e478
[09:23] <mvo> pedronis: thank you
[09:24] <pedronis> pstolowski: hi,  sorry, was already having a different discussion somewhere else
[09:25] <pstolowski> pedronis: np, let me know whe you have some time
[09:39] <mborzecki> anyone needs help gooming PRs?
[09:41] <mborzecki> mvo: pedronis: metered connections are 2.34 material right?
[09:42] <mvo> mborzecki: 2.33 is still early if it merges cleanly I'm fine pulling it in there
[09:42] <mborzecki> ok, let me check
[09:51] <mborzecki> mvo: looks like i'll need to cherry-pick individual commits
[09:52] <mvo> mborzecki: how many are there?
[09:53] <mborzecki> mvo: 12
[09:53] <mborzecki> there were additional 2 merges in the original branch
[10:07] <mup> PR snapd#5216 opened: many: backport holding refresh on metered connections to 2.33 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5216>
[10:32]  * zyga tries to debug a test failire
[10:44] <mborzecki> anyone wants to take one last look at #5199?
[10:44] <mup> PR snapd#5217 opened: asserts,image: add support for models with bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5217>
[10:44] <mup> PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
[10:50] <zyga> mborzecki: go for it
[10:50] <zyga> ads20000: hey :)
[10:50] <zyga> mvo: reviewed 5217
[10:51] <mvo> zyga: woah, that was quick!
[10:51] <zyga> I'm trying to debug autopkgtest-buildvm-ubuntu-cloud hanging
[10:51] <zyga> it's very frustrating
[10:51] <zyga> I needed a break
[10:51] <mup> PR snapd#5199 closed: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
[10:52] <ads20000> zyga: hey zyga :) hope you're doing OK!
[10:52] <mvo> zyga: yeah, I get some lunch now as well
[10:52] <zyga> yes, although I miss air conditioning today :)
[10:52] <ads20000> haha xD
[10:55] <morphis_> mvo: do I have to do anything special with snapd 2.32.8 to get my own build base snap to work?
[10:56] <zyga> morphis_: classic or core?
[10:56] <morphis_> was building the snap with `type: base` but still get the core snap mounted as / when I install it
[10:56] <morphis_> zyga: classic
[10:56] <zyga> morphis_: hmm
[10:57] <zyga> morphis_: if you have base B and app snap A then A's apps will use B iff you specify "base: B" in A
[10:57] <morphis_> right, but I have my base foo and it has apps defined
[10:57] <zyga> bases cannot have apps
[10:57] <zyga> at least not yet
[10:57] <morphis_> so I do a `snap run --shell foo.bar`
[10:57] <zyga> mvo: ^
[10:57] <morphis_> ah
[10:58] <morphis_> I remember I experimented with that in the past
[10:58] <zyga> unless we broke validation you may say in B, base: B
[10:58] <zyga> and ... you know
[10:58] <zyga> but this is not something we support yet
[10:59] <morphis_> https://git.launchpad.net/~morphis/+git/canonical-iot-stack/tree/snap/snapcraft.yaml is something I did back in Sep last year
[10:59] <morphis_> and it was working well at that time
[10:59] <morphis_> but don't remember if that was with an experimental snapd from edge
[10:59] <zyga> that's surprising, I don't recall any code that would make that work
[11:00] <morphis_> so maybe this was never released
[11:01] <pedronis> zyga: morphis_: there's a bug in the store such that bases get the wrong type, so that might be part of the issue
[11:02] <morphis_> pedronis: its not base coming from the store, self-built and installed with --dangerous
[11:02] <morphis_> s/base/a base/
[11:04] <pedronis> mborzecki: mvo: do you we want to port to 2.33 also the common-id stuff?
[11:05] <mborzecki> pedronis: i think so, doing some reviews atm, but i can open a 2.33 branch in a while
[11:09] <mup> PR snapd#5218 opened: many: expose AppStream IDs (AKA common ID) (2.33) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5218>
[11:27] <pedronis> mvo: btw: we will need to think what to do about overlord/ifacestate/implicit.go  which assumes the the system snaps is an os snap, also we discussed in the past that should be done when we load the snap info, or do yet something completely different
[11:27] <pedronis> *system snap
[11:40] <zyga> pedronis: interesting, yes
[11:40] <zyga> which snap should hold those
[11:41]  * cachio_ afk
[11:41] <zyga> the bootable base snap?
[11:41] <pedronis> I suppose so
[11:41] <zyga> if that code can look at assertions we could check
[11:41] <pedronis> ?
[11:43] <zyga> I mean if implicit.go there could just check if a snap is a bootable base we'd be good
[11:43] <pedronis> we haven't decided how one is marked as such
[11:44] <pedronis> btw
[11:44] <zyga> mmm, I assumed that we could check by looking at the model assertion
[11:44] <zyga> but yeah
[11:44] <zyga> maybe we could just use an attribute?
[11:44] <zyga> but what if a snap is both a base and bootable but _not_ booting a system?
[11:44] <pedronis> well that code has always been problematic
[11:44] <pedronis> if you forget to call it
[11:44] <pedronis> => bugs
[11:45] <pedronis> so maybe time to rethink
[11:45] <pedronis> but we need to do something
[11:45] <pedronis> because otherwise core18  => no system interfaces atm
[11:52] <zyga> perhaps we just want to attach them to something virtual
[11:53] <zyga> it doesn't have to be a real snap after all
[11:56] <zyga> could we use system for that?
[11:56] <zyga> after all, we have system configuration
[11:56] <zyga> it could be a system "snap" that provides implicit plugs/slots
[11:57] <zyga> fg
[12:20] <mup> PR snapd#5219 opened: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
[12:22] <mvo> pedronis: implicit> yeah, we need to think about it. its on the list in the forum post (I think, will double check) but I have not thought about it yet. the next step I want to tackle is to set snap_try_core= when the boot-base gets updated
[12:22] <mvo> pedronis: and once we have that I think its time for the interfaces
[12:23] <Son_Goku> zyga, your wish is my command (Cf snapd#5219)
[12:23] <mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
[12:23] <zyga> Son_Goku: thank you :)
[12:25] <mup> PR snapd#5209 closed: packaging: add packaging for openSUSE Tumbleweed <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5209>
[12:30] <zyga> Son_Goku: are you still making changes?
[12:30] <Son_Goku> should be done now
[12:30] <Son_Goku> I had discovered a couple of logic bugs based on local scratch build runs
[12:31] <Son_Goku> oh, one last thing
[12:31] <Son_Goku> the stupid gopath thing
[12:39] <mvo> mborzecki: thanks for your review for 5217
[12:54] <Son_Goku> zyga, I added a control for the snap mount dir now
[12:58] <zyga> one sec
[13:15] <mup> PR snapd#5198 closed: data/systemd: add snapd.apparmor.service <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5198>
[13:15] <zyga> Son_Goku: can you please merge master, I'm sorry for making a conflict there
[13:15] <Son_Goku> moo
[13:15] <Son_Goku> fine
[13:22] <mup> PR snapd#5220 opened: tests: moving test helpers from sh to bash <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5220>
[13:24] <Son_Goku> zyga, done: https://github.com/snapcore/snapd/pull/5219
[13:24] <mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
[13:24] <zyga> thank you
[13:24] <Son_Goku> also, adapted AppArmor changes accordingly
[13:25] <zyga> we'll merge it when green
[13:25] <zyga> I wonder if we could use this packaging for the system:snappy package as well, I need to see what's there
[13:25] <zyga> but I suspect the current master packaging is slightly more correct than the one that is maintained on OBS
[13:25] <Son_Goku> yes
[13:25] <Son_Goku> actually to some extent, both are wrong
[13:25] <zyga> yes, I agree
[13:26] <zyga> I would love if some of the badness could go away
[13:26] <zyga> but that's a rabbit hole to fill
[13:26] <Son_Goku> aside from Ubuntu, I think only Fedora actually works correctly
[13:26] <zyga> what do you mean?
[13:26] <Son_Goku> I keep dist-git and upstream git in sync
[13:26] <Son_Goku> so we're actually doing the correct evaluations and tests
[13:27] <Son_Goku> and as things change, I adapt them
[13:27] <Son_Goku> I've also taken great pains to make the Fedora spec multi-distro safe
[13:27] <Son_Goku> so that it can be used to support more than Fedora
[13:27] <zyga> I see what you mean, yes, the packaging in OBS doesn't benefit from spread
[13:28] <zyga> I would like to get that fixed, I just said in the standup that I need to work with cachio_ on a tumbleweed image for testing
[13:28] <Son_Goku> I think I'll actually pull in that new %snap_mount_dir macro I made for openSUSE packaging into Fedora
[13:29] <Son_Goku> that would make it easy to trivially retarget for Amazon Linux or even openSUSE using the same spec
[13:29] <zyga> yes, that's a good idea
[13:29] <zyga> thank you!
[13:29] <Son_Goku> since I have the day off today, I can finally catch up on so much crap
[13:33] <mborzecki> Son_Goku: yay for amzn linux!
[13:34] <mborzecki> what reminds me that i should probably revisit that pr
[13:34] <Son_Goku> obviously, it'll default to the "good" path /var/lib/snapd/snap
[13:34] <Son_Goku> but defining a different path on the command-line would be all that's necessary to build differently
[13:38]  * zyga cooks some food for himself and the dog
[13:45] <mborzecki> Son_Goku: nmap netcat is a 3rd one yet?
[13:45] <Son_Goku> yes
[13:45] <mborzecki> pfff
[13:46] <Son_Goku> Ubuntu ships all three :)
[13:46] <Son_Goku> Fedora only ships nmap-netcat
[13:46] <mborzecki> i have just 2 :) bsd and gnu
[13:46] <Son_Goku> we dropped the others
[13:46] <mborzecki> i can reword that comment to something  in the lines of 'non-BSD netcat' :)
[13:47] <Son_Goku> what is it that makes it so BSD netcat is required?
[13:47] <mborzecki> nc -U basically
[13:48] <Son_Goku> https://www.mankier.com/1/ncat#-U
[13:48] <Son_Goku> that's in nmap-netcat
[13:48] <mborzecki> Son_Goku: nope, -q
[13:48] <mborzecki> Son_Goku: https://paste.ubuntu.com/p/vFh6dM6rBm/
[13:49] <Son_Goku> odd, no -q here: http://man.openbsd.org/nc
[13:49] <cachio_> zyga, so, we need a Tumbleweed image on google right?
[13:49] <zyga> cachio_: yes, very much please :)
[13:49] <zyga> cachio_: how does it work, can I help you somehow>
[13:50] <mborzecki> Son_Goku: maybe some other *BSD
[13:50] <zyga> cachio_: tumbleweed is like arch, one image that we need to refresh periodically
[13:50] <cachio_> zyga, let me check if there is something already created
[13:50] <Son_Goku> not yet
[13:50] <Son_Goku> openSUES project is working on it now
[13:50] <Son_Goku> *openSUSE
[13:50] <cachio_> ah, ok
[13:50] <cachio_> do you know when they are going to push that?
[13:51] <Son_Goku> btw, zyga, have you considered asking Fedora Server folks about official GCE images?
[13:51] <mborzecki> Son_Goku: hmm, checked both netbsd and freebsd, none have -q, wth? yet, it's there in my manpage (and ubuntu manpages for that matter too)
[13:52] <zyga> Son_Goku: no, I'm trying to wrap my head around existing bugs, I'd rather get the work started on the image building machinery for base snap
[13:52] <Son_Goku> cachio_, ~6 months or so from now
[13:52] <Son_Goku> they're working through all the cloud providers one by one
[13:52] <cachio_> ok
[13:53] <Son_Goku> as it is, they don't build VM images at all for Tumbleweed
[13:53] <cachio_> zyga, Son_Goku in that case it is better to create our own image
[13:55] <cachio_> zyga, I'll make a try
[13:55] <cachio_> zyga, I'll keep you updated
[13:55] <zyga> cachio_: thank you
[14:02] <Son_Goku> cachio_, I'm working on gce packages now for Fedora
[14:02] <cachio_> Son_Goku, great!! thanks
[14:02] <cachio_> Son_Goku, just ping me when I can test them
[14:12] <mvo> pedronis: do you have an opinion on https://github.com/snapcore/snapd/pull/5217#discussion_r191175426 ? (not urgent, just curious)
[14:13] <mup> PR #5217: asserts,image: add support for models with bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5217>
[14:21] <pedronis> mvo: added a couple of comments and answered
[14:41] <Son_Goku> cachio_, building now: https://copr.fedorainfracloud.org/coprs/ngompa/gce-oslogin/build/759564/
[14:41] <cachio_> Son_Goku, awesome
[14:41] <Son_Goku> it needed patching to work correctly with fedora :/
[14:41] <Son_Goku> it has hardwired definitions for specific distros :(
[14:42] <Son_Goku> so hopefully this should work
[14:44] <cachio_> Son_Goku, good, I'll make a try today
[14:44] <Son_Goku> and yay, python3 :)
[14:48] <mup> PR snapd#5221 opened: [RFC] snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
[15:15]  * zyga -> grocery shopping and kid after-class drop-off, back to mount business in 2 hours
[15:39] <pedronis> mvo: did you see my comment in #5217 about not allowing base: if classic: true
[15:39] <mup> PR #5217: asserts,image: add support for models with bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5217>
[15:50] <diddledan> so.. if you can assign plugs to individual app sections in the snapcraft.yaml why are those individual assignments not shown in `snap interfaces`?
[15:53] <diddledan> e.g. with this yaml which plugs are going to be shown? and why are they not individualised to explain the command that each is assigned to? it would show afaict, in `snap interfaces` as `plug-example` having plugs `plug`, `plug2`, and `plug3` but not explaining the differences between `app1` and `app2` https://www.irccloud.com/pastebin/Fz2zdeyX/
[15:56] <diddledan> .. and if the individual apps all get the superset of permissions then why allow individual assignments at all?!
[16:42] <zyga> diddledan: hey, I can explain that
[16:43] <zyga> I will be home soon where it is more comfortable to type
[16:43] <zyga> If you ask this on the forum please send me a link
[16:43] <zyga> It will be easier for others to understand as well, ok?
[16:57] <cachio_> zyga, we have a instance
[16:58] <cachio_> opensuse-tumbleweed-64-v20180528
[16:58] <cachio_> zyga, I created it manually because I had to deal with some dependenciy issues
[16:58] <cachio_> then I'll create a script to create/update it automaticalle
[17:09] <zyga> Super nice, I will test it in half an hour
[17:09] <zyga> Thank you!
[17:21] <zyga> I’m 2km from home now. Just stuck in traffic
[17:23] <cachio_> zyga, great, np, just ping me in case something is not working
[17:26] <b_b> hi
[17:26] <b_b> i've read many thread about gtk theme support for snaps
[17:27] <b_b> and i'm wondering if i can start to play with https://github.com/snapcrafters/gtk-common-themes
[17:27] <b_b> anyone knows ?
[17:32] <zyga> re
[17:32] <zyga> b_b: hey,
[17:33] <zyga> I think you can start playing with them but you need to look at what they "do"
[17:33] <b_b> hey zyga
[17:33] <zyga> if you look at https://github.com/snapcrafters/gtk-common-themes/blob/master/snap/snapcraft.yaml#L13
[17:33] <b_b> thx for the info, since my snap is stil on edge channel i think i can take the risk :p
[17:33] <zyga> you will see that the snap provides several content slots, each with a different name and content type (which is implicitly the same as slot name)
[17:34] <b_b> 'k
[17:34] <zyga> I would recommend that you ask about this on the forum
[17:34] <zyga> and ask James who wrote this
[17:34] <b_b> on the way to use this snap  ?
[17:34] <CustosLimen> hi
[17:34] <zyga> yes
[17:34] <CustosLimen> I installed snapd on fedora
[17:34] <zyga> I suspect desktop helpers will use it somehow
[17:34] <CustosLimen> and installed vlc via snap
[17:35] <b_b> 'k
[17:35] <CustosLimen> but not sure where to get the vlc binary that was installed
[17:35] <zyga> but I'm not in the loop as for the fine details
[17:35] <zyga> CustosLimen: hey
[17:35] <b_b> i've searched a lot about it but didn't find any revelant info
[17:35] <zyga> I suspect it may still be in the head of the few people working on this
[17:35] <zyga> asking is the greatest way to pull this knowledge out into the light
[17:36] <b_b> claro que si
[17:36] <zyga> vale!
[17:36] <b_b> ;)
[17:38] <CustosLimen> nvm found it /var/lib/snapd/snap/bin/vlc
[17:38] <CustosLimen> somehow it cannot access my disks though
[17:38] <zyga> CustosLimen: you want to "snap run vlc"
[17:38] <zyga> CustosLimen: after you log out and back in it should be on PATH
[17:38] <zyga> and should show up in your application list
[17:39] <CustosLimen> okay
[17:39] <CustosLimen> how do I run vlc in classic confinement ?
[17:40] <zyga> vlc is not made to work with classic confinement
[17:40] <CustosLimen> so how do I get everything under normal locations in vlc?
[17:40] <zyga> which normal locations? it depends
[17:40] <zyga> usually you need to connect (some are auto-connected) a few interfaces and you should be fine
[17:42] <CustosLimen> zyga, file /a/b/c on my system shows up as /var/lib/snapd/hostfs/a/b/c under snap vlc
[17:42] <CustosLimen> zyga, can I somehow get it to show up normally?
[17:42] <zyga> CustosLimen: is /a/b/c the real path? I really meant for the real real path you want to use because it does matter
[17:42] <zyga> CustosLimen: if by normally you mean exactly at /a/b/c then no
[17:42] <zyga> but for certain paths they do show up normally
[17:42] <zyga> hence my earlier question
[17:42] <CustosLimen> zyga, if I just cksum /a/b/c without using snap I can see fine
[17:43] <CustosLimen> zyga, if I run snap run vlc /a/b/c vlc cannot find file
[17:43] <zyga> yes, because from vlc's point of view /a/b/c doesn't exist
[17:43] <CustosLimen> zyga, this is mounted disk under /srv/filesystems/something
[17:43] <zyga> I see
[17:43] <zyga> The /srv tree is not supported in snaps
[17:44] <zyga> you must mount (or bind mount) it somewhere where you'd typically see content (e.g. to your home somewhere)
[17:45] <CustosLimen> zyga, it is actually bind mounted under /var/opt/ also - but also nothing there
[17:45] <Son_Goku> CustosLimen, you can't use that tree either
[17:45] <Son_Goku> you're restricted to FHS 2.3/3.0 /usr tree, basically
[17:45] <CustosLimen> can I not configure it somehow ?
[17:45] <Son_Goku> nope
[17:45] <zyga> CustosLimen: /var/opt is not supported either
[17:46] <CustosLimen> okay
[17:46] <CustosLimen> thanks for info
[17:46] <Son_Goku> eventually, there'll be layouts, but that's more intended to be used to define base FHS for various base snaps
[17:46] <zyga> you _can_ you can bind mount /a/b/c or _whatever_ you want to your /home/user/
[17:46] <zyga> layouts are snap internal feature, users don't care about them actually
[17:47] <CustosLimen> zyga, yeah
[17:47] <CustosLimen> I will maybe do that
[17:47] <CustosLimen> this works fine btw /var/lib/snapd/hostfs/a/b/c
[17:47] <cachio_> Son_Goku, No match for argument: google-compute-engine-oslogin
[17:47] <CustosLimen> for stuff under /svr/ and /var/opt
[17:47] <cachio_> do I need to import any repo?
[17:48] <CustosLimen> but anyway the snap for vlc does not solve issue I have with rpmfusion vlc anyway
[17:48] <CustosLimen> I just wanted to confirm it is wider issue
[17:48] <Son_Goku> cachio_, did you do "dnf -y copr enable ngompa/gce-oslogin" first?
[17:48] <cachio_> no
[17:48] <cachio_> tx
[17:48] <CustosLimen> is there some way I can list older versions ?
[17:48] <CustosLimen> I would like to install vlc 2.x if it is available
[17:48] <CustosLimen> but not sure what versions there are
[17:49] <CustosLimen> info shows newer versions
[17:55] <zyga> snap info vlc
[17:56] <zyga> CustosLimen: note that the developers of vlc decide which versions are installable
[17:58] <CustosLimen> zyga, okay
[17:58] <CustosLimen> zyga, but older versions not listed there are not installable ?
[17:59] <zyga> that's correct
[17:59] <CustosLimen> ok thanks for info
[19:15] <b_b> see u ++
[20:18] <diddledan> zyga: https://forum.snapcraft.io/t/why-are-interfaces-shown-in-aggregate-not-per-app-in-the-yaml/5647
[21:05] <cachio_> Son_Goku, fedora 28 image added
[21:05] <cachio_> scripts added too
[21:05] <cachio_> I'll make a PR to run the tests on fedora 28 now
[21:42] <Son_Goku> cachio_: cool