[04:22] <df00z> Is multipass based on anything, like lxd, or is it it's own thing entirely?
[04:34] <jamesh> df00z: it is a frontend for various virtualisation systems.  On Linux, it will generally create kvm/qemu VMs
[04:34] <df00z> On ubuntu for snap?  I dont have qemu or kvm installed
[04:34] <df00z> it seems to be launching some sort of container though
[04:35] <jamesh> it launches a VM
[04:35] <jamesh> kvm is the kernel support for virtualisation
[04:35] <df00z> oh so it'll integrate with KVM directly, dont need qemu?
[04:36] <df00z> it seems like a weird black box is all
[04:36] <jamesh> most KVM based virtualisation systems use qemu
[04:36] <jamesh> you need more than just a virtual CPU to run a VM
[04:36] <df00z> when you use base: core18 in a snapcraft yaml file though it uses multipass, i dont have qemu installed
[04:36] <df00z> i dont know how its launching a vm though i see it is
[04:37] <df00z> unless they built qemu into the snapcraft snap, very well they could have
[04:38] <jamesh> there is a copy of qemu in the multipass snap
[04:41] <df00z> ah-ha, cool.
[04:49] <df00z> im actually trying to build a snappy for qemu + libvirt, wondering if i am going to have to use classic security
[04:51] <df00z> confinement
[04:53] <df00z> that whole steam\wine debacle with ubuntu, couldnt they just release it with snapcraft
[04:54] <df00z> other distros support multiarch, and snap
[05:17] <mborzecki> morning
[05:36] <mborzecki> super simple PR: https://github.com/snapcore/snapd/pull/7034
[05:46] <mborzecki> got a quick errand to run, bbiab
[05:49] <jamesh> df00z: there is a kvm interface that should let a strict confined snap use virtualisation.  I don't know whether that will be enough for what you want to do or not though.  Probably the best way forward is to create a strict confinement snap, install in devmode (which turns access denials into warnings) and check the logs
[06:11] <zyga> Good morning
[06:36] <mborzecki> re
[06:36] <mborzecki> zyga: hey, already in spain? is it colder than back here? :)
[07:03] <fnordahl> jdstrand: no worries, I was aware of the summit and figured you got busy.  Thx for the response, I'll propose a PR for the fstype thing.  I would be interested in a ``fuse-control`` interface, not quite sure where to start though.
[07:08] <pstolowski> mornings
[07:10] <zyga> Hey Paweł
[07:11] <mborzecki> pstolowski: heya
[07:11] <zyga> mborzecki: yeah, it is colder
[07:11] <zyga> I’m just taking the dog out, sorry for the late start
[07:17] <zyga> Last night I slept for 10 hours or more
[07:17] <zyga> Just felt so tired
[07:41] <zyga> re
[07:41] <zyga> finally working
[07:48] <zyga> I'm using some open wifi I found here, feels dirty
[07:48] <zyga> like finding a rj45 port in the public bathroom and connecting to it
[07:52] <mborzecki> zyga: remember about protection
[08:03] <zyga> brb
[08:36] <zyga> re
[09:07] <Chipaca> did I accidentally wake up in a word that is just as strange but more dystopian?
[09:08] <zyga> Chipaca: what happened?
[09:09] <Chipaca> zyga: it probably involves purple giraffes
[09:09] <zyga> whaat?
[09:28] <mborzecki> zyga: do you know if there are any ubuntu specific apparmor patches for samba too?
[09:28] <zyga> mborzecki: I don't know, let me look quickly
[09:29] <zyga> mborzecki: nope
[09:29] <mborzecki> Chipaca: do the giraffes move their heads to follow the mouse cursor?
[09:29] <zyga> mborzecki: nothing related to apparmor in any of the patches
[09:30] <mborzecki> zyga: thanks, idk if you've seen https://forum.snapcraft.io/t/manjaro-apparmor-kernel-patches-create-issues-with-smbd/12024
[09:31] <zyga> mborzecki: that's what I mentioned yesterday, I was expecting this post to be published
[09:31] <zyga> mborzecki: what I find possible is that on debian samba is not confined
[09:31] <mborzecki> zyga: mhm
[09:31] <zyga> not sure where the profile is coming from on manjaro
[09:32] <mborzecki> zyga: it's from the aa package, i have it too i believe
[09:32] <zyga> I don't have those
[09:32] <mborzecki> zyga: yup, it's there, idk why it jsut called 'smbd' in aa-status output though
[09:34] <zyga> mborzecki: smbd because that's the executable name
[09:35] <mborzecki> zyga: i expected /usr/sbin/smbd or usr.sbin.smbd, unless it's magically amtches when a binary smbd is executed from whatver location
[09:36] <zyga> ah, I understand what you meant now
[09:36] <zyga> not sure
[09:59] <mborzecki> 34C in shade :/
[10:12]  * Chipaca laughs in 17C
[10:16] <Chipaca> jamesh: thank you for #7036 !
[10:17] <jamesh> Chipaca: no problem.  It's nice when PRs have more minuses than pluses
[10:17] <Chipaca> yuss
[10:17] <mborzecki> need 2nd +1 on this thing to unblock master and jdstrand's PRs: https://github.com/snapcore/snapd/pull/7034
[10:17] <Chipaca> jamesh: I'm proud to be friends with this guy: https://mobile.twitter.com/perrito666/status/1143659952793370624
[10:18] <Chipaca> mborzecki: looking
[10:18] <Chipaca> mborzecki: io_uring sounds nephrological
[10:18] <mborzecki> Chipaca: > I am going full Marie Kondo on this code.
[10:18] <mborzecki> Chipaca: well, it's upstream's doing :)
[10:19] <mborzecki> Chipaca: fwiw there's liburing too
[10:19] <Chipaca> is it uring-complete
[10:19] <Chipaca> sorry i had to
[10:19] <jamesh> Chipaca: but are those 186 lines really necessary?
[10:20] <Chipaca> jamesh: wc -l /usr/share/common-licenses/* says … maybe
[10:20] <Chipaca> jamesh: anyway the question should be 'do they bring joy', surely
[10:20] <Chipaca> or is it spark joy
[10:23] <pstolowski> mborzecki: 7030 +1 with a suggestion
[10:34] <zyga> mborzecki: 30C here but the sea makes it nicer
[10:37]  * zyga reviewed https://github.com/snapcore/snapd/pull/7032/files
[10:44]  * pstolowski lunch
[10:45]  * zyga coffee
[10:52] <zyga> actually getting up to get the coffee now
[10:53] <mborzecki> zyga: https://forum.snapcraft.io/t/manjaro-apparmor-kernel-patches-create-issues-with-smbd/12024/5 dbus & AA blocking samba?
[10:56] <Chipaca> jamesh: if you're still around, can you merge master (or rebase, your call) so it doesn't fall over the missing syscalls?
[10:56] <Chipaca> jamesh: if you're not around I'll merge master myself
[10:57] <Chipaca> I mean into 7036 fwiw
[10:58] <zyga> back
[10:59] <zyga> mborzecki: looking at sfdisk pathces
[10:59] <zyga> *patches
[11:13] <jdstrand> fnordahl: I have it on my list to create. at what priority do you need it?
[11:17] <zyga> jdstrand: hello
[11:18] <zyga> mborzecki: hot, isn't it?
[11:18] <fnordahl> jdstrand: that's great!  I suspect the main consumer of the snap will be a charm, so installing it in devmode will be hidden from the end user for now.  It would be great to be able to have a good end user cli experience without --devmode at some point though.
[11:19] <mborzecki> zyga: it's so hot the dogs don't care when i open a fridge anymore
[11:20] <zyga> hot dogs? :D
[11:20] <mborzecki> heh
[11:27] <jdstrand> mborzecki, zyga: I commented in the manjaro/smbd topic
[11:28] <zyga> mmm
[11:29] <zyga> thanks, that is very reasonable advice
[11:30] <jdstrand> mborzecki: also, https://github.com/snapcore/snapd/pull/7034/files#r297615888
[11:31] <jdstrand> fnordahl: ok, based on that feedback, it'll stay on the list for 2.41
[11:32] <jdstrand> zyga, mborzecki: whoops, I fixed a typo just now s/before it can be used in complain mode/before it can be used in enforce mode/
[11:32] <fnordahl> jdstrand: sweet, do not hesitate to reach out if you need a hand for testing or more information
[11:33] <jdstrand> man that had a bunch of typos :\
[11:33]  * jdstrand fixed
[11:44] <mborzecki> jdstrand_: thanks for the suggestion, https://github.com/snapcore/snapd/pull/7037
[11:44] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7030#pullrequestreview-254541735
[11:45] <zyga> more reviews ahead
[11:45] <jdstrand_> mborzecki: thanks! approved
[11:46] <mborzecki> jdstrand: fwiw, now we know that the test works :P
[11:47] <mborzecki> zyga: i'll double check without the `device :` bit, last time i tried it manually sfdisk failed (or segfauled for that matter), but it's quite wonky in general so the reason might have been something else
[11:48] <mborzecki> zyga: a nice example, a partition like this makes sfdisk segfault: `1 : start=2048, size=2048, type=21686148-6449-6E6F-744E-656564454649, name="BIOS Boot"foobar` xD
[11:49] <zyga> mborzecki: really? I used it a few times without any issues
[11:49] <zyga> so... hot...
[11:49] <mborzecki> zyga: notice how `name="BIOS Boot"foobar` is formatted
[11:49] <zyga> ah
[11:49] <zyga> I see
[11:49] <zyga> well
[11:49] <zyga> C
[11:49] <mborzecki> or not C
[11:49] <zyga> lack of good parser libs
[11:50] <jdstrand> mborzecki: so, remind me, that list now has the io_uring syscalls, but no released libseccomp has them. why isn't something more needed?
[11:50] <mborzecki> jdstrand: we just track which syscalls libseccomp (upstream) know of, so that we can interrogate the host lib
[11:51] <mborzecki> jdstrand: it's part of the shenanigans for snap-seccomp recompiling bpf when a profile or the local libseccomp got changed
[11:53] <jdstrand> mborzecki: right, versioninfo. but, libseccomp *didn't* change. just syscalls.SeccompSyscalls
[11:53] <jdstrand> (libseccomp as linked into snap-seccomp that is)
[11:53] <mborzecki> jdstrand: yup, that's correct
[11:54] <jdstrand> mborzecki: so we are going to get a recompile, but for no reason afaict. I'm trying to understand/remember what is achieved here
[11:56] <mborzecki> jdstrand: it's just for the purpose of knowing what syscalls to ask the host lib for, in case that's changed we know that the lib has changed, even though x.y.z version reported by the lib is the same
[11:56] <mborzecki> jdstrand: as in case of distro patches, bc libseccomp releases are infrequent
[11:57] <jdstrand> I think I forgot about the mechanism for 'ask the host lib for'
[11:58]  * jdstrand reads
[11:58] <mborzecki> jdstrand: oh, and snap-seccomp from core is statically linked iirc, but fedora/arch/suse are not
[12:00] <jdstrand> mborzecki: ok, duh. I forgot that versionInfo() iterates over the list and tries seccomp.GetSyscallFromName. ok, it all makes perfect sense (again)
[12:00] <jdstrand> mborzecki: thanks!
[12:00] <mborzecki> jdstrand: yw
[12:03] <zyga> jdstrand: hey, could you please look at https://github.com/snapcore/snapd/pull/7026 -- it's a priority for LXD team
[12:04] <zyga> jdstrand: I'll iterate through existing comments
[12:07] <mborzecki> zyga: updated the sfdisk PR
[12:08] <zyga> great, let's see
[12:08] <jdstrand> zyga: ack
[12:08] <zyga> looks great, thanks
[12:17] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/7025#pullrequestreview-254570960
[12:20] <pstolowski> re
[12:30] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/7019#pullrequestreview-254577278
[12:36] <Chipaca> zyga: yeah it's tempting but no
[12:39] <valentind> Is there a way to enable full confinement on Debian? It says I have only devmode.
[12:39] <zyga> valentind: hello
[12:39] <valentind> Hello
[12:39] <zyga> valentind: not at present, I have this on my scope to fix for the next release
[12:40] <zyga> I was just reading the freedesktop thread about this btw
[12:40] <zyga> valentind: where full confinement is not really a thing we can enable,
[12:40] <zyga> valentind: but we will enable more confinement than we do now
[12:40]  * jdstrand notes that what zyga has is enabling everthing that is available, but the kernel may not allow full strict mode. not sure what valentind is interested in
[12:41] <zyga> jdstrand: I bet file rules are what he is after now
[12:41] <zyga> jdstrand: based on the thread
[12:41] <jdstrand> (eg, cause the Debian kernel doesn't have af_unix or network compat)
[12:41] <jdstrand> ah, ok. I didn't read the thread
[12:41] <valentind> I want to make it fail. For now I can call lzip from the runtime.
[12:41] <jdstrand> ah right
[12:42] <zyga> valentind: perhaps in a day or two,
[12:43] <jdstrand> zyga: I wonder if a temporary thing could be an env var or a snap experimental setting to force it
[12:43] <zyga> valentind: I need to sort out some things that piled up recently
[12:43] <zyga> jdstrand: I think we should just do it in edge
[12:43] <jdstrand> zyga: oh, I thought be 'next release' you meant farther out
[12:43] <zyga> jdstrand: and add the extra "what it means" command before release
[12:43]  * jdstrand butts out cause he is clearly confusing things :)
[12:43] <zyga> jdstrand: ideally 2.40 but perhaps the extra command is 2.41
[12:44] <zyga> jdstrand: is it so hot for you as well? europe is melting
[12:44] <zyga> that doesn't help my mind to recover from the 6-day-long road trip
[12:44] <jdstrand> zyga: it has been very hot and humid. we've gotten some rain this week that kept the temp down a bit a couple of days
[12:45] <zyga> forecast here is: sunlight and 0 rain for the foreseable future :(
[12:45] <zyga> and no clouds as well
[12:45] <jdstrand> yikes
[12:46] <jdstrand> it is super cloudy atm. seems like it might rain again
[12:59] <valentind> Found it in the journal: apparmor is enabled but some kernel features are missing: dbus, network
[13:02] <mborzecki> cachio: standup?
[13:07] <zyga> valentind: that's caused by the delta between upstream kernel and ubuntu apparmor kernel
[13:07] <zyga> valentind: it should be all merged in 5.3
[13:07] <zyga> valentind: but we can do better on older kernels
[13:09] <valentind> OK. Then I will try to find the patches on the ubuntu kernel and apply them locally to my debian
[13:09] <zyga> valentind: which kernel do you use now>
[13:10] <valentind> 5.0
[13:10] <ogra> i wonder if you could just run the binary deb right away on debian
[13:10] <zyga> https://www.irccloud.com/pastebin/emj4SlFQ/
[13:10] <ogra> (saves from patching and recompiling)
[13:10] <zyga> we have some presets for 5.1 but not for 5.0
[13:11] <valentind> OK
[13:11] <valentind> Maybe I should just have a virtual machine with ubuntu.
[13:11] <zyga> I believe that if you look at the 5.2 tree there is really only one patch that is relevant to snapd
[13:11] <zyga> the rest are nice but not something we actively test for
[13:12] <valentind> What is the plan for apparmor configuration for other bases?
[13:12] <zyga> valentind: we discussed a while ago that perhaps a base should define the base apparmor template but this has not gone anywhere yet
[13:12] <zyga> valentind: it would need to be handled in snapd explicitly
[13:14] <valentind> Is there anything I can do to help this?
[13:22] <zyga> valentind: not much I'm afraid, just upstreaming work on one end and snapd hacking on another end
[13:22] <zyga> if you want to get involved in snapd hacking we'll gladly welcome you on board
[13:22] <zyga> but it will be a while before your patches can land into master and make it out to users
[13:22] <zyga> I will likely change the apparmor usage in snapd well before that
[13:38]  * zyga switches to PR hacking
[13:38] <zyga> please ping me about PRs you want to get reviewed but I didn't get to yet
[13:38] <zyga> I'll continue down the list tomorrow
[13:47] <zyga> Lunch
[14:05] <mborzecki> zyga: friendly reminder https://github.com/snapcore/snapd/pull/6922
[14:09] <zyga> mborzecki: ack
[15:09]  * zyga -> dog walk
[15:57] <valentind> Something I did not know about snap are the layout. Nice surprise. Unfortunately, it seems that it does not allow executing from bound paths.
[15:58] <valentind> It seems that the apparmor snippet generated by bind mounts is missing allowing execution.
[16:00] <zyga> re
[16:01] <zyga> valentind: hey, can you provide an example?
[16:01] <zyga> valentind: it should be working correctly, if not there's a bug
[16:02] <valentind> Oh wait. My bad.
[16:02] <valentind> I will try again.
[16:02] <valentind> No no. It was working fine. I misread the error message.
[16:02] <valentind> Permission denied was not for the execution.
[16:03] <valentind> That is good. We can bind /app for compatibility with flatpak.
[16:04] <zyga> valentind: you should check this out:  ...
[16:04] <zyga> https://forum.snapcraft.io/t/snapcraft-summit-2019-montreal-a-snapd-perspective/11905
[16:04] <zyga> search for nix
[16:07] <valentind> Ok
[16:08] <zyga> 27C and  *falling*
[16:08] <zyga> my mind is recovering
[16:10] <valentind> What are they using as base image for Nix? I suppose ld.so does not come from /nix.
[16:13] <zyga> it does!
[16:13] <zyga> it's a snap with pretty much nothing in it, snap download nix-base
[16:13] <zyga> download and look around
[16:13] <zyga> it only has /nix so that a layout can put everything there
[16:14] <valentind> Well, that should break ABI, can Nix run binaries built from other ditributions?
[16:14] <valentind> nix-base, ok
[16:14] <zyga> valentind: nix base doesn't ship ld.so
[16:14] <zyga> valentind: apps ship it
[16:14] <zyga> valentind: each snap built out of nix contains everything it requires, literally so
[16:14] <valentind> Yes, I understand.
[16:15] <valentind> But the path is supposed to be absolute.
[16:15] <zyga> valentind: it is, download hello-nix and look at what it does
[16:16] <zyga> note that on nixos some more things happen
[16:16] <zyga> but in snap world, that's enough
[16:18] <valentind> I do not find hello-nix
[16:20] <zyga> oh, sorry,
[16:20] <zyga> it's not in the store!
[16:20] <zyga> I only have it because I got it at a snapcraft summit
[16:20] <zyga> valentind: my point there was:
[16:21] <zyga> https://www.irccloud.com/pastebin/0hgCLMlj/
[16:21] <zyga> nix links everything with absolute paths using hashes of the content as directory element
[16:26] <valentind> So, I could just make applications to provide all the runtime and bind it in the right place.
[16:27] <zyga> yes
[16:27] <zyga> if that makes sense that is
[16:27] <valentind> I still need to make a base with empty directories.
[16:28] <zyga> what do you need?
[16:28] <zyga> do you need /app?
[16:28] <valentind> I need /bin /usr /lib /lib64
[16:28] <valentind> And /app for the application
[16:28] <valentind> I will try that.
[16:29] <zyga> you may need some more for snapd to work
[16:29] <valentind> Core could also be done like that. Just shipped in the applications.
[16:29] <zyga> download the nix base snap and  just rename nix to app
[16:29] <zyga> and see what you need
[16:29] <valentind> Sure I already have the list of directories I need somewhere to make it work.
[16:30] <valentind> But those were path were I would bind the Freedesktop SDK.
[16:32] <valentind> Actually I need only /usr to be bind mounted. The rest should be symlinks.
[16:32] <zyga> you need to provide some non-symlink directories
[16:33] <valentind> Sure, those for snap.
[16:45] <valentind> Well, now it is re-building firefox like that. I will try it when it is built.