[02:29] <Caelum> zyga: let me know how it goes with the factory submission
[02:57] <Son_Goku> zyga, your SR got declined again: https://build.opensuse.org/request/show/601690
[02:58] <Son_Goku> also, your SRs *will* be declined if you don't provide useful information in the changes entry about the new releases
[02:58] <Son_Goku> at the minimum, changes entries need to be fixed to mention what versions they bumped to, and highlights of each release
[02:59] <Son_Goku> zyga: for example: https://build.opensuse.org/package/view_file/openSUSE:Factory/dnf/dnf.changes?expand=1
[05:59] <zyga> Good morning
[06:01] <jamesh> hi zyga
[06:08] <zyga> I’m taking the dog for a walk, will be back soon
[07:05] <pstolowski> morning
[07:06] <zyga> re
[07:07] <mup> PR snapd#5114 closed: release: 2.32.6 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5114>
[07:07] <zyga> jamesh, pstolowski: good morning
[07:17] <jamesh> zyga: so as far as user-mounts is concerned, there were two unresolved issues from niemeyer's review: each of which I'm addressing in subsequent PRs.  Would it be okay to merge the first PR?
[07:17] <jamesh> the issues are (1) the Secure.BindMount only being used on directories, and (2) snap-update-ns using the value of $XDG_RUNTIME_DIR from the environment
[07:18] <jamesh> the PR for (1) is ready, and I'm just finishing up (2) today
[07:20] <zyga> jamesh: do you have the code ready?
[07:20] <zyga> if so yes, let's merge it and then propose the other two
[07:21] <jamesh> zyga: https://github.com/snapcore/snapd/pull/3963 is ready, and the CI tests passed when you restarted them on Friday
[07:21] <mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
[07:21] <jamesh> zyga: https://github.com/snapcore/snapd/pull/5082 is ready for review, but the diff will probably make more sense after the first is merged
[07:21] <mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
[07:22] <jamesh> I'll have the third proposed soon.
[07:22] <zyga> ok, let me merge the first branch then
[07:22] <zyga> thank you for pushing it this far :)
[07:23] <zyga> it is in
[07:23] <jamesh> yay
[07:24] <mup> PR snapd#3963 closed: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3963>
[07:27] <zyga> jamesh: please merge master into your other PRs
[07:31] <jamesh> will do
[07:41] <snapuser52533> Hi
[07:42] <snapuser52533> I have a question about snap and apparmor
[07:42] <zyga> hey snapuser52533
[07:42] <zyga> I can gladly answer that
[07:42] <snapuser52533> Hi Zyga
[07:42] <snapuser52533> I've installed pac-sv via snap
[07:43] <snapuser52533> this is a ssh connection manager
[07:43] <snapuser52533> now apparmor denies access to my ssh key
[07:44] <snapuser52533> apparmor="DENIED" operation="open" profile="snap.pac-vs.pac-vs" name="/home/xxx/.ssh/id_rsa.pub" pid=11492 comm="ssh" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[07:44] <snapuser52533> I added this in the profile:
[07:44] <snapuser52533> owner @{HOME}/.ssh/ r,
[07:45] <snapuser52533> and reloaded the profile
[07:45] <snapuser52533> but it still gives me denied
[07:45] <zyga> because you gave it access to read the contents of the directory
[07:45] <zyga> nothing more
[07:45] <zyga> but anyway, you don't need any of that
[07:45] <zyga> you want to use the ssh-keys or ssh-public-keys interface
[07:45] <zyga> snap interface ssh-keys
[07:45] <zyga> :-)
[07:46] <zyga> just add a plug to your snap and connect
[07:46] <zyga> note that it will not auto-connect for obvious reasons
[07:46] <snapuser52533> oh didn't know the plugin
[07:46] <snapuser52533> i'm very new to snap
[07:47] <snapuser52533> so, I undo my changes, reload the profile and install the plugin
[07:47] <snapuser52533> just a sec
[07:49] <snapuser52533> I still got the denied
[07:52] <Chipaca> moin moin
[07:53] <Chipaca> zyga: I've got an interesting day today -- might not be *here* here for much of the morning
[07:53] <Chipaca> zyga: (just a heads up)
[08:00] <zyga> Chipaca: ack
[08:00] <zyga> I hope it is the good kind of interesting
[08:01] <Chipaca> zyga: 50/50 :-)
[08:01] <Chipaca> zyga: care to review #5111?
[08:01] <mup> PR #5111: cmd/snap: update install/refresh help vs --revision <Created by pedronis> <https://github.com/snapcore/snapd/pull/5111>
[08:01] <zyga> sure
[08:03] <zyga> FYI 2.32.6 is in beta
[08:03] <zyga> we will try to fast-track it to stable
[08:04] <mup> PR snapd#5111 closed: cmd/snap: update install/refresh help vs --revision <Simple> <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5111>
[08:06] <mup> PR snapd#5103 closed: tests: shellcheck spread tasks <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5103>
[08:06] <Chipaca> hmm
[08:06]  * Chipaca hmms in the PR where it'll lead to something
[08:08] <jamesh> zyga: https://github.com/snapcore/snapd/pull/5082 shows a reasonable diff now.  I'm still testing the second branch, which enables document portal support in the desktop interface
[08:08] <mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
[08:27] <Chipaca> ok, afk
[08:59] <mup> PR snapd#5113 closed: cmdstate: add missing test for default timeout handling <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5113>
[09:31] <zyga> uh, need to power off for a moment
[10:08] <zyga> re
[10:08] <zyga> that was longer than expected
[10:08] <zyga> my desk wiring was faulty
[10:09] <zyga> I tweaked it to be more robust and also cleaned all the surfaces (that was dusty!)
[10:09] <zyga> and re-wired everything
[10:09] <zyga> back to work :)
[10:17] <mup> PR snapd#5098 closed: Makefile: add initial makefile with live-check command <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5098>
[10:27] <zyga> jamesh: reviewed
[10:28] <Chipaca> zyga: looking at #5090
[10:28] <mup> PR #5090: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090>
[10:28] <zyga> Thank you!
[10:29] <Chipaca> zyga: in ensureSource, if the osLstat err is nil, and the kind is not one of the ones listed, what happens?
[10:29] <jamesh> zyga: awesome.  Just getting ready to submit the second PR
[10:29] <jamesh> it takes a while to locally test spread tests
[10:29] <zyga> Chipaca: nothing smart I suspect let me look
[10:30] <Chipaca> jamesh: updating and tweaking (pre-installing) the deps for the test suite on the images helps with that
[10:30] <zyga> jamesh: do you have access to the google backend?
[10:30] <zyga> it is far faster (network speed)
[10:30] <jamesh> zyga: I've just been using the local kvm backend
[10:31] <zyga> Chipaca: so if you think about symlink, it is specifically left out
[10:31] <jamesh> I don't think I've got access to the google backend
[10:32] <zyga> jamesh: ask gustavo for a key, it is x10 faster than running locally on slow network
[10:33] <zyga> about https://github.com/snapcore/snapd/pull/5096 -- mvo is sprinting this week, let's pick it up, fix things and push
[10:33] <mup> PR #5096: snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/5096>
[10:33] <Chipaca> zyga: i'll do that
[10:33] <jamesh> zyga, Chipaca: it'd be really useful to have a "spread best practices" document on the forum or somewhere.  I'm still working off some tips zyga gave me on IRC months ago, and I'm not sure how a new contributor would get started
[10:33] <zyga> awesome, thanks Chipaca
[10:34] <zyga> jamesh: I can do that, can you remind me what I told you?
[10:34] <Chipaca> zyga: "blame gustavo"
[10:34] <Chipaca> :-D
[10:38] <jamesh> zyga: looking at my notes, it was to copy one of your VM images to ~/.spread/qemu, then run "SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/$test_name"
[10:40] <zyga> jamesh: ack, thanks
[10:41] <greyback> anyone understand how snapcraft knows where to go to locate the remote "desktop-gtk2" part?
[10:41] <zyga> there's a wiki page
[10:41] <zyga> but maybe it moved
[10:41] <zyga> I mean
[10:41] <zyga> snapcraft literally used wiki to locate remote parts
[10:41] <greyback> yeah, I'm guessing there's a server somewhere
[10:41] <mup> PR snapd#5115 opened: interfaces: add xdg-document-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5115>
[10:41] <greyback> I'll grep hte source for a url
[10:41] <greyback> zyga: ta
[10:42] <greyback> https://wiki.ubuntu.com/snapcraft/parts for the record
[10:45] <jamesh> zyga: here's the document-portal PR: https://github.com/snapcore/snapd/pull/5115
[10:45] <mup> PR #5115: interfaces: add xdg-document-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5115>
[10:47] <Chipaca> zyga: I'll merge #5096 once it's green
[10:47] <mup> PR #5096: snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/5096>
[10:49] <zyga> jamesh: partial review on 5115
[10:52] <jamesh> zyga: I can separate out the fonts stuff.  I just started working on the AddUpdateNS stuff for desktop interface and it seemed like an obvious change that was touching the same code paths
[10:54] <zyga> jamesh: yeah, +1 on that but please push that in a separate PR, it can land very quickly IMO
[11:07] <jamesh> zyga: here's the second PR: https://github.com/snapcore/snapd/pull/5116 -- it is the first few commits on the other PR
[11:07] <mup> PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
[11:08] <zyga> ack
[11:08] <mup> PR snapd#5116 opened: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116>
[11:17] <zyga> jamesh: 5116 reviewed
[11:28] <greyback> anyone have thoughts on https://bugs.launchpad.net/snapd/+bug/1767372 ? I'd give it a go if someone suggested an approach
[11:28] <mup> Bug #1767372: /dev/dri/card0 only available to root <snapd:New> <https://launchpad.net/bugs/1767372>
[11:43] <zyga> greyback: looking
[11:44] <zyga> uh, sadly this is a bigger nut to crack
[11:44] <zyga> let me pull the docs
[11:44] <zyga> hey mvo
[11:44] <zyga> good morning
[11:44] <greyback> zyga: ok, it's not urgent
[11:44] <mvo> hey zyga
[11:44] <greyback> zyga: part of that users/groups plan I guess?
[11:45] <zyga> https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461
[11:46] <zyga> yes
[11:46] <zyga> there's a reference to ACLs there
[11:46] <greyback> ack
[12:03] <jdstrand> popey: hey, where are the sources for Signal-Desktop? looking at https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/14
[12:03] <popey> https://github.com/signalapp/Signal-Desktop
[12:04] <jdstrand> popey: thanks
[12:14] <zyga> jdstrand: hey, how is the sprint
[12:32] <jdstrand> zyga: hey, so far fine :)
[12:37] <jdstrand> popey: oh, heh, that was in the build script
[12:39] <zyga> Afk for post office
[12:39] <zyga> I can join the call from my phone
[12:43] <Chipaca> zyga: are we doing a standup? i think it's just you, me, and pstolowski
[12:43] <pstolowski> yeah.. let's skip
[12:46] <Intruder777> hi guys. ho do I run some service (which was installed via snap) as non-root user?
[12:52] <zyga> Lets have the call
[12:52] <zyga> Even of brief
[12:52] <zyga> Intruder777: can you vice us an example please
[12:52] <mup> PR core#87 opened: snapcraft.yaml: update stage-packages during build <Created by mvo5> <https://github.com/snapcore/core/pull/87>
[12:52] <Intruder777> zyga: let's say I have installed rocketchat-server via snap
[12:53] <Intruder777> so now the rocketchat-server processes are running from root user
[12:53] <Intruder777> how do I make them run from some custom low privilege user?
[12:57] <zyga> This is not supported
[12:57] <zyga> Note that it runs confined in a sandbox where the root is strongly limited
[12:58] <zyga> Does anyone know if Sergio is working today?
[13:00] <jdstrand> zyga: sergiusens? if so, I can see him across the room
[13:00] <zyga> No, the other one
[13:02] <zyga> Chipaca, pstolowski lets talk for 3 min please
[13:02] <Chipaca> ztinw
[13:02] <jdstrand> popey: do you know anything about npm run build-release? it seems to be cleaning up prime and I'd like to manipulate what it does
[13:02] <pstolowski> ok
[13:03] <popey> jdstrand: not really
[13:03] <popey> jdstrand: magic black box to me
[13:04] <jdstrand> I see that it pulls down appimage and has mksquashfs binaries down in ./.cache/electron-builder/appimage/appimage-9.1.0/linux-x64/
[13:04] <popey> ah, i patch out the building of appimage
[13:04] <popey> appimages are built by default in electron-builder
[13:04] <popey> unless you override it
[13:04] <jdstrand> I wonder if it is using those binaries for the snap build under the hood
[13:05]  * jdstrand just finds it curious and wants to investigate
[13:19] <zyga> re
[13:19] <zyga> taxes filed
[13:19] <zyga> man, so so so hot today
[13:19] <zyga> 30C in the shade
[13:20] <zyga> who needs Spain when Central Europe is melting away
[13:20] <pstolowski> :)
[13:22] <zyga> jdstrand: can you please look at https://github.com/snapcore/snapd/pull/5107 during a coffee break
[13:22] <mup> PR #5107: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5107>
[13:22] <zyga> it's a trivial PR adding mode,uid,gid options to tmpfs
[13:26] <Chipaca> zyga: I've had to turn the heating on again
[13:26] <zyga> WAT
[13:26] <zyga> is it this cold in UK?
[13:27] <popey> yes, buggering freezing
[13:27] <zyga> man that's weird, we could call this July easily now
[13:27] <Chipaca> I can't confirm that, but I can confirm it's quite cold
[13:27] <Chipaca> so I do envy your 30C :-)
[13:27] <Chipaca> that's what I call 'nice'
[13:28]  * Chipaca really enjoyed the 2 days of summer this year
[13:29] <mup> PR snapcraft#2111 opened: repo: rollback to using dpkg-deb for deb extraction <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2111>
[13:39]  * zyga goes to make ice coffee
[13:50] <mup> PR snapd#5117 opened: interfaces/apparmor: enable apparmor, even if partial <Created by zyga> <https://github.com/snapcore/snapd/pull/5117>
[13:57] <mup> PR snapd#5118 opened: packaging/opensuse: build with apparmor support <Created by zyga> <https://github.com/snapcore/snapd/pull/5118>
[14:01] <mup> PR snapd#5119 opened: dirs: on opensuse store apparmor profiles in /etc/apparmor.d <Created by zyga> <https://github.com/snapcore/snapd/pull/5119>
[14:14] <jdstrand> popey: ah: execute command           args=[/home/ubuntu/.cache/electron-builder/appimage/appimage-9.1.0/linux-x64/mksquashfs /home/ubuntu/tmp.0mPdLJ0eNz/latest/release/__snap-x64 /home/ubuntu/tmp.0mPdLJ0eNz/latest/release/signal-desktop_1.9.0-beta.1_amd64.snap -no-progress -quiet -all-root -no-duplicates -no-recovery] path=/home/ubuntu/.cache/electron-builder/appimage/appimage-9.1.0/linux-x64/mksquashfs
[14:14] <popey> wow
[14:14] <jdstrand> then later
[14:14] <jdstrand> Appending to existing 4.0 filesystem on /home/ubuntu/tmp.0mPdLJ0eNz/latest/release/signal-desktop_1.9.0-beta.1_amd64.snap, block size 131072
[14:14] <jdstrand> All -b, -noI, -noD, -noF, -noX, no-duplicates, no-fragments, -always-use-fragments,
[14:15] <jdstrand> -exportable and -comp options ignored
[14:15] <zyga> hmm
[14:15] <zyga> what is appimage doing there?
[14:15] <jdstrand> so it appears they are calling mksquashfs in an incompatible way, then appending to it in a roughly compatible way
[14:15] <jdstrand> zyga: it isn't. electron-builder is reusing some appimage code to build the snap
[14:16] <jdstrand> "If appending is not wanted, please re-run with -noappend specified!"
[14:16] <zyga> heh, weird but ok :)
[14:16] <jdstrand> let's try that for giggles
[14:17]  * zyga goes to snap vim properly
[14:19] <ogra_> strict ?!?
[14:19] <popey> why? core ships with vi
[14:19] <popey> should make a snap of emacs or nano if anything :)
[14:19] <ogra_> i like cursor keys and syntax highlighting ;)
[14:22] <popey> i like anything other than vi
[14:22] <popey> but on my core system i have to keep running "sudo classic" to get any kind of decent editor
[14:24] <ogra_> echo "set nocompatible" >>~/.vimrc
[14:24] <ogra_> (and you have normal vim mode)
[14:28] <Chipaca> ogra_: you seem to think "anything other than vi" means vim is ok
[14:28] <ogra_> totally !
[14:28] <ogra_> who needs more than vim !
[14:28] <Chipaca> o/
[14:29] <kyrofa> zyga, I'm in lxc, any idea what this is? error: cannot perform the following tasks:
[14:29] <kyrofa> - Run configure hook of "nextcloud" snap if present (run hook "configure": cannot remount /tmp/snap.rootfs_vLM0cV/var/lib/snapd/lib/vulkan as read-only: Permission denied)
[14:30] <kyrofa> (trying to install a new snap)
[14:30] <zyga> this looks like an older snapd
[14:30] <zyga> whats the version?
[14:30] <kyrofa> $ snap --version
[14:30] <kyrofa> snap    2.32.5
[14:30] <kyrofa> snapd   2.32.5
[14:30] <kyrofa> series  16
[14:30] <kyrofa> ubuntu  16.04
[14:30] <kyrofa> kernel  4.4.0-121-generic
[14:30] <kyrofa> Xenial, both apt and snap are up to date (tracking stable)
[14:31] <zyga> hmmm
[14:31] <zyga> can you show me the denial you have
[14:31] <zyga> I will investigate
[14:33] <kyrofa> zyga, no denial, it seems, just this: Apr 30 14:32:29 nextcloud-snap-test snapd[369]: 2018/04/30 14:32:29.792734 handlers.go:372: Reported install problem for "nextcloud" as 5066946e-4c83-11e8-b6b2-fa163e8d4bab OOPSID
[14:33] <zyga> nothing in dmesg?
[14:33] <kyrofa> A bunch of appamor STATUSs
[14:34] <zyga> hmm, let's see
[14:37] <zyga> kyrofa: can you look at the apparmor profile of snap-confine
[14:37] <zyga> and look for
[14:37] <zyga> mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
[14:38] <kyrofa> zyga, hmm.... where is it?
[14:38] <zyga> in /etc/apparmor.d
[14:38] <kyrofa>  /var/lib/snapd/apparmor/snap-confine/ is empty
[14:38] <zyga> look at each one you find
[14:38] <kyrofa> Ah
[14:40] <mup> PR snapd#5120 opened: interfaces:interface-hooks for refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/5120>
[14:40] <kyrofa> zyga, I see this: # Vulkan support
[14:40] <kyrofa>     /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/{,*} w,
[14:40] <kyrofa>     mount fstype=tmpfs options=(rw nodev noexec) none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
[14:40] <kyrofa>     mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
[14:40] <kyrofa> Darn, shoulda pastebinned that
[14:40] <zyga> that's fine
[14:41] <zyga> that corresponds to the error you saw
[14:41] <zyga> but it's allowed there
[14:41] <zyga> so ... no idea
[14:42] <zyga> but also the only MS_REMOUNT in the tree
[14:42] <zyga> so maybe bugs are present
[14:59] <sveinse> With Ubuntu 18.04 I'm given a choice if I should install docker via apt or via snap. What is the arguments for getting docker via snap?
[15:25] <zyga> sveinse: the snap is updated by docker inc at their own pace
[15:25] <zyga> sveinse: the deb comes from the ubuntu archive and will not be updated apart from security updates
[15:27] <sveinse> zyga: Snap adds another container layer on top of everything, doesn't it? So it has some overhead, right?
[15:28] <zyga> What kind of overhead?
[15:28] <sveinse> zyga: Does't it run in a jail?
[15:28] <ogra_> it does ... but not "in a container"
[15:29] <zyga> Snaps really just run the software as is, with a different mount namespace to let the thing use libraries independent from the host
[15:29] <ogra_> it is confined through apparmor, seccomp, napespaces ...
[15:29] <ogra_> *name
[15:29] <zyga> Is that a container? Yes but not much more overhead imo
[15:30] <ogra_> not sure, i always thinka container is closer to a full VM here than what snapd does :)
[15:31] <sveinse> not quite sure about that, docker is somewhat inbetween all that. It certainly is not a full VM, but it can abstract some of the fs bits
[15:32] <sveinse> So in my simplistic view I don't really see the difference from docker containers and snaps, but that snaps are built to be accessible from outside
[15:32] <zyga> There are many differences
[15:33] <zyga> But those require one to understand what both tools are doing
[15:33] <zyga> A lot of the kernel tech is shared
[15:34] <zyga> But also they do different things without correspondence to each other
[15:35] <sveinse> I have a small server that I'm trying to decide on how to run the services: Either Ubuntu bare-metal (or whatever you want to call a "normal" server these days) or by using docker. And if docker, should it run from apt, given the standard location of the containers or from snap, where it is being updated more frequently. For snap one needs to handle the snap-specific locations of docker.
[15:36] <zyga> Try the snap and report back on usability please
[15:36] <zyga> For containers you can also use lxd
[15:36] <zyga> It all depends on what you want to run inside
[15:38] <sveinse> zyga: since I'm considering running the server bare-metal (keyword small server), I suppose the only added reason for doing containment is the added protection in case of internet breach. Doing a full VM is not an option.
[15:38] <sveinse> For the record I have no experience with lxd
[15:39] <zyga> None of those things use full virtualization
[15:39] <sveinse> right
[15:39] <zyga> Lxd runs machine containers
[15:39] <zyga> Unlike docker which typically runs process or a single app with few cooperating processes
[15:40] <sveinse> which is impacts the system less?
[15:41] <zyga> It is not about impact imo
[15:41] <zyga> And it all depends son what you mean
[15:41] <zyga> Those are all different tools building on the same set of kernel features
[15:41] <om26er> Hi! Is there a way to check the download size of a snap refresh ?
[15:42] <om26er> One of my snap was updated automatically and I want to know the download size and if the delta update actually worked.
[15:42] <om26er> s/updated/refreshed
[15:43] <zyga> om26er: not as an end-user AFAIK
[15:43] <sveinse> Yeah, I think I see the difference when reading on linuxcontainers.org/lxd/ and I think I'm aiming at docker type. One machine, multiple services. More abstraction than that, i.e. machine is not necessary
[15:43] <sveinse> Thanks, zyga. I have something I'd like to test
[15:45] <om26er> zyga: when the delta is downloaded, is that deleted after being applied ? (maybe I could check the delta size locally if possible)
[15:49] <zyga> om26er: AFAIK yes
[15:49] <zyga> om26er: it is deleted
[15:49] <zyga> it is only kept to reconstruct the image
[15:53]  * om26er will wait for blr to come online to inquire the delta size as its worrying android-studio snap may be re-downloading the whole thing with each update.
[15:53] <mup> PR snapd#5121 opened: interfaces:minor autoconnect cleanuo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5121>
[16:07] <Chipaca> om26er: if you've got SNAPD_DEBUG enabled you can read all about deltas in the lgos
[16:07] <Chipaca> logs*
[16:08] <Chipaca> om26er: also SNAPD_DEBUG_HTTP=3 would help (or even =7 if you're into reading json)
[16:08] <om26er> Chipaca: its not enabled currently, will adding SNAPD_DEBUG=7 to /etc/environments suffice ?
[16:08] <Chipaca> SNAPD_DEBUG=1 (or =true)
[16:09] <Chipaca> SNAPD_DEBUG_HTTP=3 (or 7)
[16:09] <om26er> then I can probably check on next update if the delta worked.
[16:09] <Chipaca> om26er: is it your snap?
[16:09] <Chipaca> om26er: if so, if you're logged in, you can 'snap install yoursnap --revision=theoldrevno' and then sanp refresh
[16:09] <om26er> Chipaca: kind of: its owned by snapcrafters team but I am collaborator.
[16:09] <Chipaca> om26er: that is: if you can push to it, you can do the above
[16:11]  * om26er tries
[16:15] <Chipaca> zyga: any idea what's up with the "no output received" things?
[16:19] <popey> om26er: ping if you need something from me, obviously :)
[16:24] <om26er> popey: thanks, no need, seems I was already able to test what Chipaca suggested.
[16:24] <om26er> and the good news is: delta updates are indeed working :)
[16:24] <om26er> Chipaca: where exactly can I see those logs ?
[16:26] <Chipaca> om26er: journalctl  -u snapd
[16:26] <om26er> ah, snapd.service: Ignoring invalid environment assignment 'export SNAPD_DEBUG=1': /etc/environment
[16:27] <om26er> https://paste.ubuntu.com/p/vYJTQ8gX4w/
[16:31] <mup> PR snapcraft#2112 opened: repo: fix all python shebangs in stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2112>
[16:39] <om26er> so the delta was downloaded, saved more than 600+ megabytes. VICTORY.
[16:39] <om26er> Thank you guys.
[16:39] <popey> nice!
[16:40] <Chipaca> maybe snapd should brag about that a bit
[16:40] <Chipaca> I'm sure people would complain about it polluting the logs etc etc
[16:40] <Chipaca> ¯\_(ツ)_/¯
[16:40] <zyga> No idea
[16:41] <Chipaca> maybe we should have a BRAG log level :-D
[16:41] <zyga> Maybe heat wave and slow VMs?
[16:41] <Chipaca> zyga: dude, poland is the only place with a heat wave
[16:41] <Chipaca> zyga: have you checked your nuclear reactors lately?
[16:41] <zyga> We don’t have any
[16:42] <zyga> Coincidence? I don’t think so ;-)
[16:42]  * Chipaca shudders remembering chernobyl residents going to the roof of their buildings to enjoy the nice warm air
[16:42] <zyga> I’m going for a beer with kissiel
[16:42] <Chipaca> zyga: dang
[16:42] <zyga> To celebrate bionic
[16:42] <Chipaca> i'm on meds, can't have beer
[16:42] <zyga> But first I have to get there on a bike
[16:42] <zyga> I got bike crazy
[16:43] <zyga> I plan to take non alcoholic
[16:43] <zyga> To ride back
[16:43] <Chipaca> ah, i was about to tell you off
[16:43] <zyga> Sorry to hear that though
[16:43] <zyga> Are you ok?
[16:43] <zyga> I’m walking to the bike station
[16:43] <Chipaca> zyga: yep! big teeth thing
[16:43] <zyga> Ah
[16:43] <zyga> It will heal
[16:43] <Chipaca> yep
[16:44] <Chipaca> just two more days
[17:53] <ogra_> zyga, do yu happen to know if michael will be back on wed. ?
[17:53] <ogra_> (or did he take off the whole week)
[18:42] <mup> PR snapd#5096 closed: snap: improve error for snaps not available in the given context <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5096>
[18:45] <zyga> ogra_: i think he will be back next week, he is sprinting
[18:46] <ogra_> ah, crap crap crap ... k
[19:03] <Saviq> hey guys, any idea about snapcraft just spinning at 100% CPU after "Preparing to build desktop-qt5", seemingly permanently?
[19:25] <popey> it does take a while, yeah
[19:25] <popey> but it does move on usually
[19:26] <seb128> Saviq, popey, same issue than vlc is hitting, Sergio looked at it today, it's due to the switch from dpkg-deb to use the python binding they did, he said he's going to revert that change
[19:27] <popey> ah okay
[19:27] <popey> That's new to me, thanks.
[19:27] <seb128> the reason that motivated the change isn't true anymore
[19:27] <seb128> yw
[19:29] <seb128> Saviq, popey, bug #1767119
[19:29] <mup> Bug #1767119: snapcraft prime takes considerably more time on unpacking stage packages than before <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1767119>
[19:29] <seb128> he put up a PR today
[19:32] <Intruder777|1> guys, so running snap apps services as root is no security issue, right?
[19:33] <Chipaca> Intruder777|1: strictly-confined snap apps, correct
[19:34] <Chipaca> (we will support users anyway, at some point, but it should be fine for now)
[19:36] <Intruder777|1> Chipaca: thanks
[19:37] <Chipaca> ogra_: what did you nead a michael for?
[19:37] <Chipaca> Intruder777|1: np, hth
[19:37] <ogra_> Chipaca, approval tp potentially see dmsetup (needed for full-disk-encryption)
[19:37] <ogra_> *to potentially seed
[19:37] <popey> add gnu screen while you're there ;)
[19:38] <Chipaca> ogra_: telegram; he's sprinting, not vacationing :-)
[19:38] <Chipaca> and +1 to scren
[19:38]  * Chipaca goes off to write an app call 'scren' just to not be wrong
[19:38] <Chipaca> called
[19:38] <Chipaca> gawd
[19:38] <ogra_> i'm still researching why systemd misbehaves so badly all of a sudden (we have FDE working since a while and suddenly systemd creats random mount usins for the backing device)
[19:38]  * Chipaca just take more pills and go to sleep
[19:38] <ogra_> <- cant type anymore
[19:39] <ogra_> popey, definitely not for this customer :P (there every byte counts ... super cut down device)
[19:40] <Chipaca> popey: that's ogra_-speak for "if you can find something to remove that's the same size or bigger, sure"
[19:40]  * Chipaca is helpful
[19:40]  * popey runs ncdu /snap/core/current
[19:41] <ogra_> popey, though you will be pleased to hear that i managed to implement the encrypted rootfs generic enough that we can also later have interactive passwd prompts or SD card keys (needs extra implementation indeed, but adding different key handlers should eb easy in my implementation)
[19:41] <popey> so, tell me why we have perl in core :)
[19:41] <ogra_> popey, some dependency of some low level package
[19:42] <Chipaca> popey: now ask him about usr/share/X11/xkb
[19:42] <popey> hah
[19:42] <ogra_> Chipaca, michael added that for something yu demanded IIRC
[19:43]  * Chipaca whistles innocently
[19:43] <ogra_> support for non US keyboards in console-conf ?? yeah, i think that was it
[19:43] <ogra_> that puls in a ton of stuff
[19:43] <Chipaca> ogra_: is initrd supposed to be in core btw?
[19:43]  * Chipaca forgets how that dance is
[19:44] <ogra_> Chipaca, with split initrd it is loaded directly from the core snap ...
[19:44] <ogra_> without it we theoretically wouldnt need it
[19:44] <popey> do people need pppd in 2018?
[19:44] <ogra_> (but we use split-initrd now in some customer setups)
[19:44] <ogra_> popey, for GSM
[19:44] <Chipaca> popey: yes :-) whether it should be in core is another question
[19:44] <Chipaca> but, given it's setuid, probably
[19:45] <ogra_> yeah
[19:45] <ogra_> iirc that was the reason
[19:45] <popey> python2.7 debconf.py
[19:45] <popey> (I like this game)
[19:45] <Chipaca> perl is probably there for debconf
[19:45] <Chipaca> debconf is probably there for consoleconf or somesuch
[19:46] <ogra_> perl is there for a ton of stuff thats used during build
[19:46] <Chipaca> (pero is also not that big iirc?)
[19:46] <Chipaca> perl*
[19:46] <ogra_> the question is if any of this is also used at runtime (and it is really hard to tell without a detailed audit of every script and tool)
[19:46] <Chipaca> 2.9M    ./usr/lib/x86_64-linux-gnu/perl-base
[19:46] <Chipaca> hm
[19:46] <ogra_> yeah, it is quite big
[19:47] <Chipaca> hopefully for core18 we can do it the other way around
[19:47] <Chipaca> :-)
[19:47] <Chipaca> and build it up instead of down
[19:47] <ogra_> anyway, back to my dmsetup problem
[19:47]  * Chipaca can dream
[19:47] <ogra_> well
[19:47] <ogra_> the question is if you use debs ...
[19:47] <ogra_> as long as you do you will always have a bunch of unwanted deps pulled in
[19:48] <ogra_> ad with our policy to use binaries from the archive it is hard to work around using debs
[19:48] <popey> organize:
[19:48] <popey>  - -usr/bin/foo
[19:48] <ogra_> the prob is always: "how much can you cut down without harming the functionality of a package"
[19:48] <Chipaca> umm
[19:48] <popey> Indeed, that's the fun bit!
[19:49] <ogra_> you theoretically need to knwo each package in and out to judge that you can remove some dep
[19:49] <Chipaca> popey: is it just the screen binary you need, or does it have more deps?
[19:49] <popey> just the binary and a 777 directory /var/run/screen
[19:49] <Chipaca> popey: because we're shipping ./usr/lib/python2.7/dist-packages/debconf.py … and no python 2
[19:49] <ogra_> huh ?
[19:49] <popey> screen is 425K uncompressed though
[19:49] <ogra_> we surel ship python2
[19:50] <Chipaca> ogra_: python 3, yes
[19:50] <Chipaca> 2? what for?
[19:50] <popey> (see 5 mins ago where I mentioned this) :D
[19:50] <ogra_> Chipaca, in 16.04 ?
[19:50] <ogra_> i thought we still had 2 there
[19:50] <Chipaca> ogra_: in core
[19:50] <Chipaca> 16.04, yes
[19:50] <Chipaca> core, nope \o/
[19:51] <Chipaca> at least that is what my friend 'find' says
[19:51] <ogra_> ogra@acheron:~$ apt-cache show python-minimal|grep ^Depends
[19:51] <ogra_> Depends: python2.7-minimal (>= 2.7.12-1~), dpkg (>= 1.13.20)
[19:51] <ogra_> Depends: python2.7-minimal (>= 2.7.11-1~), dpkg (>= 1.13.20)
[19:51] <ogra_> we install python-minimal
[19:51] <ogra_> (in core)
[19:52] <ogra_> (and nly to make subiquity happy ... i wish we could just rip it out)
[19:53] <Chipaca> ogra_: https://pastebin.ubuntu.com/p/HwVrYcdbMT/
[19:53] <ogra_> oh, interesting
[19:53] <Chipaca> ogra_: something's ripping it out :)
[19:54] <ogra_> might be that we switched to python3-minimal and i forgot
[19:57] <popey> how much close to getting screen does that get us? :)
[19:57] <ogra_> removing python ?
[19:58] <popey> 6kb!
[19:58] <ogra_> just add 10 screens :)
[19:58] <ogra_> removing python would clean up 5-10MB
[19:59] <popey> how, it's not actually there
[19:59] <Chipaca> ogra_: what uses dh-python in core?
[19:59] <mup> PR snapcraft#2111 closed: repo: rollback to using dpkg-deb for deb extraction <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2111>
[19:59] <ogra_> Chnothing
[19:59] <ogra_> ^^ Cip
[19:59] <ogra_> bah
[19:59]  * Chipaca hugs ogra_ 
[20:00] <ogra_> yeah, systemd is giving me a really bad day
[20:00] <ogra_> trying to be clever ...
[20:00] <Chipaca> ogra_: i'll let you get back to that
[20:00] <Chipaca> need to go anyway
[20:00] <ogra_> i'm totally not eager to :)
[20:50] <mup> PR snapcraft#2113 opened: sources: don't clean target for FileBase sources <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2113>
[23:27] <mup> PR snapcraft#2112 closed: repo: fix all python shebangs in stage-packages <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2112>
[23:30] <mup> PR snapcraft#2113 closed: sources: don't clean target for FileBase sources <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2113>