[05:12] morning [05:22] hey mborzecki, good morning [05:29] Good morning [05:30] zyga: good morning to you as well [05:35] zyga: mvo: hey [05:51] I will be at my desk shortly [06:20] and back [06:20] man, it's such a hot day already [06:20] it will easily be +30C [06:22] Coffee and reviews [06:42] mvo: interesting thing that may affect us soon: https://github.com/systemd/systemd/issues/8221 [06:43] zyga: thanks [06:45] pstolowski|afk: ^ this is also related to your work closely [06:55] I cannot believe how terrible udev scripting is [06:55] it's the least sensible syntax [06:55] used an virtually all the linux machiens [06:55] *machines [06:56] eh [06:57] zyga: tried cmake? :) [06:57] yes, I hate it too but at least it's a language with regular-ish syntax [06:57] (except for that crazy upper-case madness) [06:57] but udev is really the assembly [06:57] line oriented [06:57] obscure [06:57] lowercase works too [06:58] still the syntax garbage [06:58] if udev rules were like pascal it would be a huge improvement [06:58] and that says a lot [06:58] heh [06:58] so after growing up on Pascal someone made a crappy hand-crafted line "parser" [06:58] because that's the best we can do? [06:58] eh [06:58] wish we made more use of tcl historically [06:59] one of the nicer 'glue' languages i used [07:00] 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 === pstolowski|afk is now known as pstolowski [07:03] good morning! [07:18] mborzecki: is https://github.com/snapcore/snapd/pull/5199 good for landing now? [07:18] PR #5199: many: expose AppStream IDs (AKA common ID) [07:19] zyga: got some comments from niemeyer, fixing them atm [07:20] zyga: i think we can land #5203 [07:20] PR #5203: interfaces/joystick: also support modern evdev joysticks and gamepads [07:20] mborzecki: jamie said he would write a test [07:20] though it can probably land separately [07:25] zyga: +1 [07:25] (for landing the joystick thing) [07:26] done [07:27] PR snapd#5203 closed: interfaces/joystick: also support modern evdev joysticks and gamepads [08:14] #5091 can be merged when it's green [08:14] * zyga -> breakfast [08:14] PR #5091: many: hold refresh when on metered connections [08:14] mborzecki: where you talking about it before or #5199 ? [08:14] PR #5199: many: expose AppStream IDs (AKA common ID) [08:15] s/where/were/ [08:15] pedronis: yeah, mistook it for 5091 (i was fixing it), 5199 should can be landed now [08:15] (removed blocked tag) [08:16] mborzecki: was the new test snap transfered? [08:16] not a blocker for landing as such [08:17] pedronis: yes [08:17] cool, thx [08:18] pushed some fixes to #4700, still neds a re-review from jdstrand but at least it should be passing tests now [08:18] PR #4700: interfaces/builtin: add the dvb-video interface [08:18] PR snapd#5215 opened: Improved error handling when creating autoconnect tasks [08:24] mborzecki: hey, question about arch packaging [08:25] mborzecki: will #5198 make arch automatically get the service script? [08:25] PR #5198: data/systemd: add snapd.apparmor.service [08:25] and the corresponding service? [08:26] mvo: is this expected? https://github.com/snapcore/snapd/pull/5198/files#r191143359 [08:26] you added the snapd.seeded.service unit [08:26] PR #5198: data/systemd: add snapd.apparmor.service [08:28] pedronis: hey! would you like to discussus conflict stuff & connect? [08:28] 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] newbee: where are you running your application? on classic system or on a all-snap/core device? [08:29] newbee: serial ports are only supported on the latter type for now [08:30] I running it on a snap core.. [08:30] newbee: ok, what do you mean by "but still in my snap it didn't list the serial port" [08:31] Ubuntu 16.04 LTS. [08:31] ? [08:31] ubuntu 16.04 LTS is a classic system, serial port is not useful there yet [08:31] zyga: we have a new snapd.seeded which is used as a sync point. should be fine to have this on opensuse [08:31] zyga: or am I missing something? [08:32] mvo: I'm wondering why tests passed before, how is that unit installed? [08:32] mvo: it appears as before that unit was not installed at all [08:32] it's fairly recent [08:32] newbee: after installing your snap check `snap change --last=install`, any errors there re your plug? [08:33] zyga: yes, on arch it's just make -C data install ... [08:33] zyga: you probably need to rm -f it like you do for fedora [08:33] mborzecki: thanks [08:33] ideally I would connect that to the --without-apparmor [08:33] but it's not easy [08:34] zyga: I don't know why it is working right now, let me look at master [08:34] yeah, you'd have to build data from the same setup as cmd is built, we've had 2 attempts already [08:34] PR snapd#5091 closed: many: hold refresh when on metered connections [08:34] @pstolowski there is no error listed.. [08:34] 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] zyga: we install snapd.seeded.service for opensuse in master [08:35] zyga: maybe you need to merge master? [08:35] zyga: (into your PR) [08:35] mvo: hmm, AFAIK I did but I will re-check [08:37] @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] how does your program know which port to open? [08:39] zyga: I need to choose that manually on my application. In net-beans it works clearly. [08:40] 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] newbee: but anyhow that does not work on classic systems because they don't have any serial port slot definitions [08:41] newbee: only core systems (those that only ship snap packages) use gadget snaps to define serial ports (e.g. raspberry pi) [08:41] @Zyga thanks. is there any examples for that? [08:41] newbee: of which part specifically? [08:42] @zyga gadget snaps to define serial ports? how to create that file? [08:43] 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] you can find examples on GitHub.com/snapcore/ e.g. the pi2 gadget [08:43] @Zyga ok thank you.. [08:43] but you cannot make one and install it on your system, it must come pre-made with a device [08:44] 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] in the end it will work exactly the same (for apps) as it does on core [08:44] you define one or more plugs of type "serial-port" on your snap [08:45] (you can name each one to match the indented function for the user) [08:45] you install that snap on some system [08:45] 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] and using interface hooks your application is notified of each such operation and can store local state [08:45] (or notify a running service) [08:46] Ok I will try and let you know the result.. [08:46] once connected the application process that has those plug definitions will get permissions to open those specific serial ports that are connected [08:46] it's not a simple set of things to happen but that's how it is designed to work [08:46] but again, on a classic system you cannot do that yet [08:46] you may try on a core device that defines a serial port statically for now [08:49] 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] pedronis: sure, let me try to do that [08:51] pedronis: should be there now [08:52] mvo: thank you [09:09] * zyga -> small break [09:09] * zyga has some fuzzy sight today [09:13] 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] mvo: they are signed with the key in asserts/assertstest [09:17] pedronis: thank you! that was the missing piece :) [09:18] I used a small go program to sign them [09:18] 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] mvo: one sec [09:19] pedronis: sure, thank you! [09:20] mvo: I'll share a gist of what I have, less spoffy [09:20] pedronis: also lol@removing the "simple" label from 5213 (its true, it started simple and it got downhill from there) [09:20] pedronis: yeah, gist is fine [09:22] mvo: something like this, this how I signed the -w-config one, https://gist.github.com/pedronis/256ac00d78c8f075614df3ff5c21e478 [09:23] pedronis: thank you [09:24] pstolowski: hi, sorry, was already having a different discussion somewhere else [09:25] pedronis: np, let me know whe you have some time [09:39] anyone needs help gooming PRs? [09:41] mvo: pedronis: metered connections are 2.34 material right? [09:42] mborzecki: 2.33 is still early if it merges cleanly I'm fine pulling it in there [09:42] ok, let me check [09:51] mvo: looks like i'll need to cherry-pick individual commits [09:52] mborzecki: how many are there? [09:53] mvo: 12 [09:53] there were additional 2 merges in the original branch === ubott2 is now known as ubottu === juliank_ is now known as juliank === AndyWojo_ is now known as AndyWojo === diddledan_ is now known as diddledan [10:07] PR snapd#5216 opened: many: backport holding refresh on metered connections to 2.33 [10:32] * zyga tries to debug a test failire [10:44] anyone wants to take one last look at #5199? [10:44] PR snapd#5217 opened: asserts,image: add support for models with bases [10:44] PR #5199: many: expose AppStream IDs (AKA common ID) [10:50] mborzecki: go for it [10:50] ads20000: hey :) [10:50] mvo: reviewed 5217 [10:51] zyga: woah, that was quick! [10:51] I'm trying to debug autopkgtest-buildvm-ubuntu-cloud hanging [10:51] it's very frustrating [10:51] I needed a break [10:51] PR snapd#5199 closed: many: expose AppStream IDs (AKA common ID) [10:52] zyga: hey zyga :) hope you're doing OK! [10:52] zyga: yeah, I get some lunch now as well [10:52] yes, although I miss air conditioning today :) [10:52] haha xD [10:55] mvo: do I have to do anything special with snapd 2.32.8 to get my own build base snap to work? [10:56] morphis_: classic or core? [10:56] was building the snap with `type: base` but still get the core snap mounted as / when I install it [10:56] zyga: classic [10:56] morphis_: hmm [10:57] 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] right, but I have my base foo and it has apps defined [10:57] bases cannot have apps [10:57] at least not yet [10:57] so I do a `snap run --shell foo.bar` [10:57] mvo: ^ [10:57] ah [10:58] I remember I experimented with that in the past [10:58] unless we broke validation you may say in B, base: B [10:58] and ... you know [10:58] but this is not something we support yet [10:59] https://git.launchpad.net/~morphis/+git/canonical-iot-stack/tree/snap/snapcraft.yaml is something I did back in Sep last year [10:59] and it was working well at that time [10:59] but don't remember if that was with an experimental snapd from edge [10:59] that's surprising, I don't recall any code that would make that work [11:00] so maybe this was never released [11:01] 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] pedronis: its not base coming from the store, self-built and installed with --dangerous [11:02] s/base/a base/ [11:04] mborzecki: mvo: do you we want to port to 2.33 also the common-id stuff? [11:05] pedronis: i think so, doing some reviews atm, but i can open a 2.33 branch in a while [11:09] PR snapd#5218 opened: many: expose AppStream IDs (AKA common ID) (2.33) [11:27] 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] *system snap === pstolowski is now known as pstolowski|lunch [11:40] pedronis: interesting, yes [11:40] which snap should hold those [11:41] * cachio_ afk [11:41] the bootable base snap? [11:41] I suppose so [11:41] if that code can look at assertions we could check [11:41] ? [11:43] I mean if implicit.go there could just check if a snap is a bootable base we'd be good [11:43] we haven't decided how one is marked as such [11:44] btw [11:44] mmm, I assumed that we could check by looking at the model assertion [11:44] but yeah [11:44] maybe we could just use an attribute? [11:44] but what if a snap is both a base and bootable but _not_ booting a system? [11:44] well that code has always been problematic [11:44] if you forget to call it [11:44] => bugs [11:45] so maybe time to rethink [11:45] but we need to do something [11:45] because otherwise core18 => no system interfaces atm [11:52] perhaps we just want to attach them to something virtual [11:53] it doesn't have to be a real snap after all [11:56] could we use system for that? [11:56] after all, we have system configuration [11:56] it could be a system "snap" that provides implicit plugs/slots [11:57] fg [12:20] PR snapd#5219 opened: packaging/opensuse: Refactor packaging to support all openSUSE targets [12:22] 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] pedronis: and once we have that I think its time for the interfaces [12:23] zyga, your wish is my command (Cf snapd#5219) [12:23] PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets [12:23] Son_Goku: thank you :) [12:25] PR snapd#5209 closed: packaging: add packaging for openSUSE Tumbleweed [12:30] Son_Goku: are you still making changes? [12:30] should be done now [12:30] I had discovered a couple of logic bugs based on local scratch build runs [12:31] oh, one last thing [12:31] the stupid gopath thing [12:39] mborzecki: thanks for your review for 5217 === pstolowski|lunch is now known as pstolowski [12:54] zyga, I added a control for the snap mount dir now [12:58] one sec [13:15] PR snapd#5198 closed: data/systemd: add snapd.apparmor.service [13:15] Son_Goku: can you please merge master, I'm sorry for making a conflict there [13:15] moo [13:15] fine [13:22] PR snapd#5220 opened: tests: moving test helpers from sh to bash [13:24] zyga, done: https://github.com/snapcore/snapd/pull/5219 [13:24] PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets [13:24] thank you [13:24] also, adapted AppArmor changes accordingly [13:25] we'll merge it when green [13:25] I wonder if we could use this packaging for the system:snappy package as well, I need to see what's there [13:25] but I suspect the current master packaging is slightly more correct than the one that is maintained on OBS [13:25] yes [13:25] actually to some extent, both are wrong [13:25] yes, I agree [13:26] I would love if some of the badness could go away [13:26] but that's a rabbit hole to fill [13:26] aside from Ubuntu, I think only Fedora actually works correctly [13:26] what do you mean? [13:26] I keep dist-git and upstream git in sync [13:26] so we're actually doing the correct evaluations and tests [13:27] and as things change, I adapt them [13:27] I've also taken great pains to make the Fedora spec multi-distro safe [13:27] so that it can be used to support more than Fedora [13:27] I see what you mean, yes, the packaging in OBS doesn't benefit from spread [13:28] 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] I think I'll actually pull in that new %snap_mount_dir macro I made for openSUSE packaging into Fedora [13:29] that would make it easy to trivially retarget for Amazon Linux or even openSUSE using the same spec [13:29] yes, that's a good idea [13:29] thank you! [13:29] since I have the day off today, I can finally catch up on so much crap [13:33] Son_Goku: yay for amzn linux! [13:34] what reminds me that i should probably revisit that pr [13:34] obviously, it'll default to the "good" path /var/lib/snapd/snap [13:34] 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] Son_Goku: nmap netcat is a 3rd one yet? [13:45] yes [13:45] pfff [13:46] Ubuntu ships all three :) [13:46] Fedora only ships nmap-netcat [13:46] i have just 2 :) bsd and gnu [13:46] we dropped the others [13:46] i can reword that comment to something in the lines of 'non-BSD netcat' :) [13:47] what is it that makes it so BSD netcat is required? [13:47] nc -U basically [13:48] https://www.mankier.com/1/ncat#-U [13:48] that's in nmap-netcat [13:48] Son_Goku: nope, -q [13:48] Son_Goku: https://paste.ubuntu.com/p/vFh6dM6rBm/ [13:49] odd, no -q here: http://man.openbsd.org/nc [13:49] zyga, so, we need a Tumbleweed image on google right? [13:49] cachio_: yes, very much please :) [13:49] cachio_: how does it work, can I help you somehow> [13:50] Son_Goku: maybe some other *BSD [13:50] cachio_: tumbleweed is like arch, one image that we need to refresh periodically [13:50] zyga, let me check if there is something already created [13:50] not yet [13:50] openSUES project is working on it now [13:50] *openSUSE [13:50] ah, ok [13:50] do you know when they are going to push that? [13:51] btw, zyga, have you considered asking Fedora Server folks about official GCE images? [13:51] 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] 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] cachio_, ~6 months or so from now [13:52] they're working through all the cloud providers one by one [13:52] ok [13:53] as it is, they don't build VM images at all for Tumbleweed [13:53] zyga, Son_Goku in that case it is better to create our own image [13:55] zyga, I'll make a try [13:55] zyga, I'll keep you updated [13:55] cachio_: thank you [14:02] cachio_, I'm working on gce packages now for Fedora [14:02] Son_Goku, great!! thanks [14:02] Son_Goku, just ping me when I can test them [14:12] pedronis: do you have an opinion on https://github.com/snapcore/snapd/pull/5217#discussion_r191175426 ? (not urgent, just curious) [14:13] PR #5217: asserts,image: add support for models with bases [14:21] mvo: added a couple of comments and answered === pbek_ is now known as pbek === Eleventh_Doctor is now known as Pharaoh_Atem [14:41] cachio_, building now: https://copr.fedorainfracloud.org/coprs/ngompa/gce-oslogin/build/759564/ [14:41] Son_Goku, awesome [14:41] it needed patching to work correctly with fedora :/ [14:41] it has hardwired definitions for specific distros :( [14:42] so hopefully this should work [14:44] Son_Goku, good, I'll make a try today [14:44] and yay, python3 :) [14:48] PR snapd#5221 opened: [RFC] snap: parse connect instructions in gadget.yaml === stgraber_ is now known as stgraber [15:15] * zyga -> grocery shopping and kid after-class drop-off, back to mount business in 2 hours [15:39] mvo: did you see my comment in #5217 about not allowing base: if classic: true [15:39] PR #5217: asserts,image: add support for models with bases [15:50] 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] 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] .. and if the individual apps all get the superset of permissions then why allow individual assignments at all?! === pstolowski is now known as pstolowski|afk [16:42] diddledan: hey, I can explain that [16:43] I will be home soon where it is more comfortable to type [16:43] If you ask this on the forum please send me a link [16:43] It will be easier for others to understand as well, ok? [16:57] zyga, we have a instance [16:58] opensuse-tumbleweed-64-v20180528 [16:58] zyga, I created it manually because I had to deal with some dependenciy issues [16:58] then I'll create a script to create/update it automaticalle [17:09] Super nice, I will test it in half an hour [17:09] Thank you! [17:21] I’m 2km from home now. Just stuck in traffic [17:23] zyga, great, np, just ping me in case something is not working [17:26] hi [17:26] i've read many thread about gtk theme support for snaps [17:27] and i'm wondering if i can start to play with https://github.com/snapcrafters/gtk-common-themes [17:27] anyone knows ? [17:32] re [17:32] b_b: hey, [17:33] I think you can start playing with them but you need to look at what they "do" [17:33] hey zyga [17:33] if you look at https://github.com/snapcrafters/gtk-common-themes/blob/master/snap/snapcraft.yaml#L13 [17:33] thx for the info, since my snap is stil on edge channel i think i can take the risk :p [17:33]