[02:29] zyga: let me know how it goes with the factory submission [02:57] zyga, your SR got declined again: https://build.opensuse.org/request/show/601690 [02:58] also, your SRs *will* be declined if you don't provide useful information in the changes entry about the new releases [02:58] at the minimum, changes entries need to be fixed to mention what versions they bumped to, and highlights of each release [02:59] zyga: for example: https://build.opensuse.org/package/view_file/openSUSE:Factory/dnf/dnf.changes?expand=1 [05:59] Good morning [06:01] hi zyga [06:08] I’m taking the dog for a walk, will be back soon === pstolowski|eow is now known as pstolowski [07:05] morning [07:06] re [07:07] PR snapd#5114 closed: release: 2.32.6 [07:07] jamesh, pstolowski: good morning [07:17] 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] 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] the PR for (1) is ready, and I'm just finishing up (2) today [07:20] jamesh: do you have the code ready? [07:20] if so yes, let's merge it and then propose the other two [07:21] zyga: https://github.com/snapcore/snapd/pull/3963 is ready, and the CI tests passed when you restarted them on Friday [07:21] PR #3963: cmd/snap-confine: add support for per-user mounts [07:21] 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] PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files [07:22] I'll have the third proposed soon. [07:22] ok, let me merge the first branch then [07:22] thank you for pushing it this far :) [07:23] it is in [07:23] yay [07:24] PR snapd#3963 closed: cmd/snap-confine: add support for per-user mounts [07:27] jamesh: please merge master into your other PRs [07:31] will do [07:41] Hi [07:42] I have a question about snap and apparmor [07:42] hey snapuser52533 [07:42] I can gladly answer that [07:42] Hi Zyga [07:42] I've installed pac-sv via snap [07:43] this is a ssh connection manager [07:43] now apparmor denies access to my ssh key [07:44] 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] I added this in the profile: [07:44] owner @{HOME}/.ssh/ r, [07:45] and reloaded the profile [07:45] but it still gives me denied [07:45] because you gave it access to read the contents of the directory [07:45] nothing more [07:45] but anyway, you don't need any of that [07:45] you want to use the ssh-keys or ssh-public-keys interface [07:45] snap interface ssh-keys [07:45] :-) [07:46] just add a plug to your snap and connect [07:46] note that it will not auto-connect for obvious reasons [07:46] oh didn't know the plugin [07:46] i'm very new to snap [07:47] so, I undo my changes, reload the profile and install the plugin [07:47] just a sec [07:49] I still got the denied [07:52] moin moin [07:53] zyga: I've got an interesting day today -- might not be *here* here for much of the morning [07:53] zyga: (just a heads up) [08:00] Chipaca: ack [08:00] I hope it is the good kind of interesting [08:01] zyga: 50/50 :-) [08:01] zyga: care to review #5111? [08:01] PR #5111: cmd/snap: update install/refresh help vs --revision [08:01] sure [08:03] FYI 2.32.6 is in beta [08:03] we will try to fast-track it to stable [08:04] PR snapd#5111 closed: cmd/snap: update install/refresh help vs --revision [08:06] PR snapd#5103 closed: tests: shellcheck spread tasks [08:06] hmm [08:06] * Chipaca hmms in the PR where it'll lead to something [08:08] 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] PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files [08:27] ok, afk [08:59] PR snapd#5113 closed: cmdstate: add missing test for default timeout handling [09:31] uh, need to power off for a moment [10:08] re [10:08] that was longer than expected [10:08] my desk wiring was faulty [10:09] I tweaked it to be more robust and also cleaned all the surfaces (that was dusty!) [10:09] and re-wired everything [10:09] back to work :) [10:17] PR snapd#5098 closed: Makefile: add initial makefile with live-check command [10:27] jamesh: reviewed [10:28] zyga: looking at #5090 [10:28] PR #5090: cmd/snap-update-ns: poke holes when creating source paths for layouts [10:28] Thank you! [10:29] zyga: in ensureSource, if the osLstat err is nil, and the kind is not one of the ones listed, what happens? [10:29] zyga: awesome. Just getting ready to submit the second PR [10:29] it takes a while to locally test spread tests [10:29] Chipaca: nothing smart I suspect let me look [10:30] jamesh: updating and tweaking (pre-installing) the deps for the test suite on the images helps with that [10:30] jamesh: do you have access to the google backend? [10:30] it is far faster (network speed) [10:30] zyga: I've just been using the local kvm backend [10:31] Chipaca: so if you think about symlink, it is specifically left out [10:31] I don't think I've got access to the google backend [10:32] jamesh: ask gustavo for a key, it is x10 faster than running locally on slow network [10:33] about https://github.com/snapcore/snapd/pull/5096 -- mvo is sprinting this week, let's pick it up, fix things and push [10:33] PR #5096: snap: improve error for snaps not available in the given context [10:33] zyga: i'll do that [10:33] 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] awesome, thanks Chipaca [10:34] jamesh: I can do that, can you remind me what I told you? [10:34] zyga: "blame gustavo" [10:34] :-D [10:38] 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] jamesh: ack, thanks [10:41] anyone understand how snapcraft knows where to go to locate the remote "desktop-gtk2" part? [10:41] there's a wiki page [10:41] but maybe it moved [10:41] I mean [10:41] snapcraft literally used wiki to locate remote parts [10:41] yeah, I'm guessing there's a server somewhere [10:41] PR snapd#5115 opened: interfaces: add xdg-document-portal support to desktop interface [10:41] I'll grep hte source for a url [10:41] zyga: ta [10:42] https://wiki.ubuntu.com/snapcraft/parts for the record [10:45] zyga: here's the document-portal PR: https://github.com/snapcore/snapd/pull/5115 [10:45] PR #5115: interfaces: add xdg-document-portal support to desktop interface [10:47] zyga: I'll merge #5096 once it's green [10:47] PR #5096: snap: improve error for snaps not available in the given context [10:49] jamesh: partial review on 5115 [10:52] 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] jamesh: yeah, +1 on that but please push that in a separate PR, it can land very quickly IMO [11:07] 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] PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface [11:08] ack [11:08] PR snapd#5116 opened: interfaces: move host font update-ns AppArmor rules to desktop interface [11:17] jamesh: 5116 reviewed [11:28] anyone have thoughts on https://bugs.launchpad.net/snapd/+bug/1767372 ? I'd give it a go if someone suggested an approach [11:28] Bug #1767372: /dev/dri/card0 only available to root [11:43] greyback: looking [11:44] uh, sadly this is a bigger nut to crack [11:44] let me pull the docs [11:44] hey mvo [11:44] good morning [11:44] zyga: ok, it's not urgent [11:44] hey zyga [11:44] zyga: part of that users/groups plan I guess? [11:45] https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461 [11:46] yes [11:46] there's a reference to ACLs there [11:46] ack [12:03] 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] https://github.com/signalapp/Signal-Desktop [12:04] popey: thanks [12:14] jdstrand: hey, how is the sprint [12:32] zyga: hey, so far fine :) [12:37] popey: oh, heh, that was in the build script [12:39] Afk for post office [12:39] I can join the call from my phone [12:43] zyga: are we doing a standup? i think it's just you, me, and pstolowski [12:43] yeah.. let's skip [12:46] hi guys. ho do I run some service (which was installed via snap) as non-root user? [12:52] Lets have the call [12:52] Even of brief [12:52] Intruder777: can you vice us an example please [12:52] PR core#87 opened: snapcraft.yaml: update stage-packages during build [12:52] zyga: let's say I have installed rocketchat-server via snap [12:53] so now the rocketchat-server processes are running from root user [12:53] how do I make them run from some custom low privilege user? [12:57] This is not supported [12:57] Note that it runs confined in a sandbox where the root is strongly limited [12:58] Does anyone know if Sergio is working today? [13:00] zyga: sergiusens? if so, I can see him across the room [13:00] No, the other one [13:02] Chipaca, pstolowski lets talk for 3 min please [13:02] ztinw [13:02] 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] ok [13:03] jdstrand: not really [13:03] jdstrand: magic black box to me [13:04] 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] ah, i patch out the building of appimage [13:04] appimages are built by default in electron-builder [13:04] unless you override it [13:04] 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] re [13:19] taxes filed [13:19] man, so so so hot today [13:19] 30C in the shade [13:20] who needs Spain when Central Europe is melting away [13:20] :) [13:22] jdstrand: can you please look at https://github.com/snapcore/snapd/pull/5107 during a coffee break [13:22] PR #5107: cmd/snap-update-ns,tests: mimic the mode and ownership of directories [13:22] it's a trivial PR adding mode,uid,gid options to tmpfs [13:26] zyga: I've had to turn the heating on again [13:26] WAT [13:26] is it this cold in UK? [13:27] yes, buggering freezing [13:27] man that's weird, we could call this July easily now [13:27] I can't confirm that, but I can confirm it's quite cold [13:27] so I do envy your 30C :-) [13:27] that's what I call 'nice' [13:28] * Chipaca really enjoyed the 2 days of summer this year [13:29] PR snapcraft#2111 opened: repo: rollback to using dpkg-deb for deb extraction [13:39] * zyga goes to make ice coffee [13:50] PR snapd#5117 opened: interfaces/apparmor: enable apparmor, even if partial [13:57] PR snapd#5118 opened: packaging/opensuse: build with apparmor support [14:01] PR snapd#5119 opened: dirs: on opensuse store apparmor profiles in /etc/apparmor.d [14:14] 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] wow [14:14] then later [14:14] 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] All -b, -noI, -noD, -noF, -noX, no-duplicates, no-fragments, -always-use-fragments, [14:15] -exportable and -comp options ignored [14:15] hmm [14:15] what is appimage doing there? [14:15] so it appears they are calling mksquashfs in an incompatible way, then appending to it in a roughly compatible way [14:15] zyga: it isn't. electron-builder is reusing some appimage code to build the snap [14:16] "If appending is not wanted, please re-run with -noappend specified!" [14:16] heh, weird but ok :) [14:16] let's try that for giggles [14:17] * zyga goes to snap vim properly [14:19] strict ?!? [14:19] why? core ships with vi [14:19] should make a snap of emacs or nano if anything :) [14:19] i like cursor keys and syntax highlighting ;) [14:22] i like anything other than vi [14:22] but on my core system i have to keep running "sudo classic" to get any kind of decent editor [14:24] echo "set nocompatible" >>~/.vimrc [14:24] (and you have normal vim mode) [14:28] ogra_: you seem to think "anything other than vi" means vim is ok [14:28] totally ! [14:28] who needs more than vim ! [14:28] o/ [14:29] zyga, I'm in lxc, any idea what this is? error: cannot perform the following tasks: [14:29] - 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] (trying to install a new snap) [14:30] this looks like an older snapd [14:30] whats the version? [14:30] $ snap --version [14:30] snap 2.32.5 [14:30] snapd 2.32.5 [14:30] series 16 [14:30] ubuntu 16.04 [14:30] kernel 4.4.0-121-generic [14:30] Xenial, both apt and snap are up to date (tracking stable) [14:31] hmmm [14:31] can you show me the denial you have [14:31] I will investigate [14:33] 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] nothing in dmesg? [14:33] A bunch of appamor STATUSs [14:34] hmm, let's see [14:37] kyrofa: can you look at the apparmor profile of snap-confine [14:37] and look for [14:37] mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/, [14:38] zyga, hmm.... where is it? [14:38] in /etc/apparmor.d [14:38] /var/lib/snapd/apparmor/snap-confine/ is empty [14:38] look at each one you find [14:38] Ah [14:40] PR snapd#5120 opened: interfaces:interface-hooks for refresh [14:40] zyga, I see this: # Vulkan support [14:40] /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/{,*} w, [14:40] mount fstype=tmpfs options=(rw nodev noexec) none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/, [14:40] mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/, [14:40] Darn, shoulda pastebinned that [14:40] that's fine [14:41] that corresponds to the error you saw [14:41] but it's allowed there [14:41] so ... no idea [14:42] but also the only MS_REMOUNT in the tree [14:42] so maybe bugs are present [14:59] 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] sveinse: the snap is updated by docker inc at their own pace [15:25] sveinse: the deb comes from the ubuntu archive and will not be updated apart from security updates [15:27] zyga: Snap adds another container layer on top of everything, doesn't it? So it has some overhead, right? [15:28] What kind of overhead? [15:28] zyga: Does't it run in a jail? [15:28] it does ... but not "in a container" [15:29] 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] it is confined through apparmor, seccomp, napespaces ... [15:29] *name [15:29] Is that a container? Yes but not much more overhead imo [15:30] not sure, i always thinka container is closer to a full VM here than what snapd does :) [15:31] 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] 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] There are many differences [15:33] But those require one to understand what both tools are doing [15:33] A lot of the kernel tech is shared [15:34] But also they do different things without correspondence to each other [15:35] 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] Try the snap and report back on usability please [15:36] For containers you can also use lxd [15:36] It all depends on what you want to run inside [15:38] 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] For the record I have no experience with lxd [15:39] None of those things use full virtualization [15:39] right [15:39] Lxd runs machine containers [15:39] Unlike docker which typically runs process or a single app with few cooperating processes [15:40] which is impacts the system less? [15:41] It is not about impact imo [15:41] And it all depends son what you mean [15:41] Those are all different tools building on the same set of kernel features [15:41] Hi! Is there a way to check the download size of a snap refresh ? [15:42] One of my snap was updated automatically and I want to know the download size and if the delta update actually worked. [15:42] s/updated/refreshed [15:43] om26er: not as an end-user AFAIK [15:43] 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] Thanks, zyga. I have something I'd like to test [15:45] zyga: when the delta is downloaded, is that deleted after being applied ? (maybe I could check the delta size locally if possible) [15:49] om26er: AFAIK yes [15:49] om26er: it is deleted [15:49] 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] PR snapd#5121 opened: interfaces:minor autoconnect cleanuo [16:07] om26er: if you've got SNAPD_DEBUG enabled you can read all about deltas in the lgos [16:07] logs* [16:08] om26er: also SNAPD_DEBUG_HTTP=3 would help (or even =7 if you're into reading json) [16:08] Chipaca: its not enabled currently, will adding SNAPD_DEBUG=7 to /etc/environments suffice ? [16:08] SNAPD_DEBUG=1 (or =true) [16:09] SNAPD_DEBUG_HTTP=3 (or 7) [16:09] then I can probably check on next update if the delta worked. [16:09] om26er: is it your snap? [16:09] om26er: if so, if you're logged in, you can 'snap install yoursnap --revision=theoldrevno' and then sanp refresh [16:09] Chipaca: kind of: its owned by snapcrafters team but I am collaborator. [16:09] om26er: that is: if you can push to it, you can do the above === pstolowski is now known as pstolowski|off [16:11] * om26er tries [16:15] zyga: any idea what's up with the "no output received" things? [16:19] om26er: ping if you need something from me, obviously :) [16:24] popey: thanks, no need, seems I was already able to test what Chipaca suggested. [16:24] and the good news is: delta updates are indeed working :) [16:24] Chipaca: where exactly can I see those logs ? [16:26] om26er: journalctl -u snapd [16:26] ah, snapd.service: Ignoring invalid environment assignment 'export SNAPD_DEBUG=1': /etc/environment [16:27] https://paste.ubuntu.com/p/vYJTQ8gX4w/ [16:31] PR snapcraft#2112 opened: repo: fix all python shebangs in stage-packages [16:39] so the delta was downloaded, saved more than 600+ megabytes. VICTORY. [16:39] Thank you guys. [16:39] nice! [16:40] maybe snapd should brag about that a bit [16:40] I'm sure people would complain about it polluting the logs etc etc [16:40] ¯\_(ツ)_/¯ [16:40] No idea [16:41] maybe we should have a BRAG log level :-D [16:41] Maybe heat wave and slow VMs? [16:41] zyga: dude, poland is the only place with a heat wave [16:41] zyga: have you checked your nuclear reactors lately? [16:41] We don’t have any [16:42] 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] I’m going for a beer with kissiel [16:42]