[00:38] gunix: yes [06:37] morning [07:04] hey diddledan [07:04] if somebody that can explain snapd to me is online, please ping me [07:04] i do not understand how this system works and it amazes me that stuff like LXD works on archlinux via snap [07:19] mvo: morning [07:25] good morning mborzecki [07:26] PR snapd#4508 closed: New spread test for hardware-random-observe interface [07:37] 4495 needs a second review [07:41] PR snapd#4425 closed: config: add support for `snap set core proxy.no_proxy=...` [07:44] 4473 also needs a second review :) [07:44] PR snapd#4476 closed: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule [08:03] good morning [08:07] hey o/ [08:08] good morning :) [08:09] good morning kalikiana pstolowski and zyga-ubuntu ! [08:09] happy monday! [08:09] mvo, hey, what is the forecast on the strace support for snaps? [08:09] koza: if somone reviews my PR at least basic support will land for 2.31 [08:09] zyga-ubuntu: pstolowski: kalikiana: morning guys [08:10] koza: we want support for custom options as well, there is a PR for that too [08:10] koza: hey [08:10] 4473 is the strace pr that needs a second review :) [08:10] koza: there is also your motd PR that we need to land for 2.31, right? [08:10] mvo, but like days, weeks, months? :) [08:11] mvo, would be nice, Thibaut commented vi email, Ill change the PR accordingly today [08:11] koza: 2.31 is scheduled for beta this week and stable in ~4 weeks [08:11] koza: ta [08:11] mvo, nice! [08:11] koza: yeah, we are quite excited about strace too, its a popular feature [08:14] mvo: i'm looking at https://bugs.launchpad.net/snapd/+bug/1744433 so far got this: https://bugs.launchpad.net/snapd/+bug/1744433 this should make the message: 'error: cannot refresh "vlc": snap "vlc" has auto-refresh in progress' [08:14] Bug #1744433: 'snap refresh' is silent about changes in progress [08:14] mborzecki: aha, you have a pr already? [08:15] mvo: no :) trying to figure out if there's a nicer way [08:15] mvo: i can open a pr with this change though [08:16] mborzecki: what is your current diff, could you pastebin this please? [08:16] mvo: https://paste.ubuntu.com/26435923/ [08:16] sorry, paste the bug link twice in the previous message [08:18] mborzecki: no worries. will that help with the original issue? afaict mark did "snap refresh" and got "all snaps up-to-date" but in fact there were not, there were refreshing. so the message should be something like "vlc is refreshing" or similar. are we running a changeConflictError when a global refresh is running and a global refresh is requested again? [08:19] mvo: the error mesage on `snap refresh vlc` would be friendly, instad of changes you'd get 'auto-refresh' and so on [08:20] mvo: I think I should update 2.30 in opensuse today [08:20] the rest i have not figured out yet [08:20] mvo: and we have some bug reports on fedora front to inspect [08:20] mborzecki: aha, ok - yeah, making this friendlier is definitely nice [08:20] zyga-ubuntu: +1 for updates [08:21] zyga-ubuntu: where do the fedora bugs come from? their bugtracker? [08:26] mvo: yes, on bugzilla [08:26] zyga-ubuntu: ok, how bad do they look? [08:26] https://bugzilla.redhat.com/show_bug.cgi?id=1536895 [08:27] uhh, ok [08:27] I wonder why we did not caught this in testing :( [08:27] yes, it's surprising to me as well [08:35] I'll be back soon, just getting some quick food [08:35] zyga-ubuntu: looks like something we fixed recently [08:57] PR snapd#4513 closed: dirs: fix snap mount dir on Manjaro [09:11] PR snapd#4514 opened: overlord/snapstate: record the 'kind' of conflicting change [09:14] whoa, quickest reviewers in the west [09:15] Chipaca: morning [09:16] mborzecki: morning :-) [09:20] do we have a pedronis again this week, or is that next week? [09:21] Chipaca: i think he mentioned he'd be on vacation until 29th [09:22] mborzecki: I laud your detailed memory [09:22] haha, yeah, my wife would disagree :) [09:22] lol@ mborzecki [09:23] hey Chipaca good morning and happy monday! [09:23] mborzecki: she holds you to a higher standard :-D [09:23] mvo: good morning! monday's looking good indeed [09:30] Chipaca: hey [09:30] Chipaca: I added i386 [09:31] Chipaca: I didn't do accounts yet but ping me if you want to play and I'll do that quickly [09:31] zyga-ubuntu: awesome. I don't think I need it right now, but very good to know. [09:31] and I will change the power adapter for the dragonboard so that it can be on 24/7 [09:31] but that's in the evening as it's not a priority for anyone today [09:38] mborzecki: 4509 has another review [09:38] zyga-ubuntu: thanks [09:38] mvo: any news on bolt, ppc and other misery? [09:41] zyga-ubuntu: not yet, I was doing a 2.30 core image respin to exclude the microcode again this morning, I will focus on 2.31 next, part of this is bolt on ppc [09:42] wonder when the new 'working' microcode will be released [09:43] mborzecki: you are not alone here [09:43] mborzecki: btw, are you looking into the "snap refresh" output as well (if there is another refresh alreaady running)? [09:44] mvo: no, i've put is aside for now, i ended up going in circles [09:45] mborzecki: "working" or working? [09:45] mborzecki: ok, no worries, just wanted to check [09:45] mborzecki: I was considering looking but had no time for it yet :/ [09:46] mvo: go ahead, i'm poking around https://bugs.launchpad.net/snappy/+bug/1741486 now [09:46] Bug #1741486: failed snap try leaves snap symlink around [09:47] mborzecki: aha, nice! thats a good one too [09:47] btw. can we close https://bugs.launchpad.net/snappy/+bug/1743504 ? this was the unlucky fellow who basically had his filesystem bail out on him [09:47] Bug #1743504: Ubuntu 16.04 snapd service not working [09:51] mborzecki: looking [09:53] mborzecki: I closed it now [09:53] mvo: great, thanks [09:53] Bug #1743504 changed: Ubuntu 16.04 snapd service not working [09:53] mborzecki: thank you! how are we actually doing with "New" bugs? how many are not confirmed/triaged currently? [09:58] (a) wooo, baby steps progress is now tangible [09:58] (b) /me -> physio [09:59] zyga-ubuntu: silly question, do we bundle on opensuse? [10:00] mvo: yes, we do [10:00] zyga-ubuntu: excellent [10:00] mvo: (it's legan now) [10:00] legal* [10:01] zyga-ubuntu: I fixed bolt on fedora by sed things back to boltdb/bolt [10:01] zyga-ubuntu: that means we just need to fix debian, I can make a patch, just need to find the upstream repo [10:01] zyga-ubuntu: eh, packaging repo [10:03] zyga-ubuntu: we really should import their packaging to make this simpler. anyway, found it and doing a patch [10:10] * Chipaca actually goes [10:13] * kalikiana moooore coffeeeee [10:17] zyga-ubuntu: working on a package for *ntoo and wondering what important stuff I am missing. manifest -> https://paste.pound-python.org/show/kHgFz1bglDwHLo89K5ZK/ [10:19] jamesb192: looking [10:19] kalikiana: you are reading my mind! [10:20] jamesb192: snap-confine is usually in /usr/lib/snapd/snap-confine or /usr/libexec/snapd/snap-confine [10:20] jamesb192: same with a host of other binaries (only snap and snapctl are on path) [10:20] jamesb192: you can drop the following systemd units: autoimport, core-fixup [10:20] snap-repair [10:20] system-shutdown [10:20] and the corresponding timer [10:21] jamesb192: you can drop the snapd autoimport servic [10:21] er [10:21] this thing: -rw-r--r-- root/root 157 2018-01-20 08:53 ./lib/udev/rules.d/66-snapd-autoimport.rules [10:21] the udev rules [10:21] those things are all files relevant for core but irrelevant elsewhere [10:21] core == not classic systems [10:21] the /opt/snapd location is curious, what made you put all those files there/ [10:21] zyga-ubuntu: you're welcome :-D [10:22] temporary holding area until I do something useful. [10:23] jamesb192: [10:24] ok, I think you will have some issues still but this looks like a good starting point, I may have missed something [10:24] I would suggest to look at debian/ubuntu/fedora packages and see if there are any files they ship that you do not [10:24] and always exclude the files I mentioned above [10:24] (they are at best no-ops on normal systems) [10:24] the end goal is to have a system that can be spread tested and that would pass our integration tests [10:25] but for now just iterate this way and run snaps on your system and see what breaks [10:26] Okay. I will do that. thank you. [10:27] jamesb192: please send update reports to the forum, I'm sure it will have wider exposure there [10:27] I can respond there as well [10:33] 4505 needs a 2nd review [10:33] ah [10:33] sorry [10:33] 4502* [10:33] not 5 [10:48] mvo: 4505 updated per your comments [10:52] PR snapd#4514 closed: overlord/snapstate: record the 'kind' of conflicting change [10:58] zyga-ubuntu: ta, one quick comment added [10:59] sure [11:00] mvo: which code reads "it" (I assume group/user name) [11:00] mvo: the switch you linked to explicitly maps specific values [11:01] zyga-ubuntu: let me double check, maybe github is playing tricks on me [11:01] mvo: the code in snap-update-ns did do name lookups AFAIR but I'm not sure it has to still [11:01] mvo: and that code is more generic as it applies to other mechanisms [11:01] mvo: this one only does layout language [11:02] zyga-ubuntu: aha, you are right, I was misreading the code [11:02] zyga-ubuntu: sorry [11:02] mvo: no worries, I wanted to check if I missed something :) thank you for askin! [11:46] joc: gentle ping about #4326 [11:46] PR #4326: interfaces/builtin: blacklist zigbee dongle [11:47] I think you know more about that than we do [11:50] mborzecki: what's the status of 4285? [11:51] zyga-ubuntu: i've put it on hold now, most of the tests were passing though, iirc the were maybe 1-2 left, one of those was /media directory [11:55] mborzecki: does it make sense to unconflict and merge this [11:56] opensuse 42.2 will be EOLed this week [11:56] we should switch to 42.3 [11:59] zyga-ubuntu: i'll merge master and push it for a travis run and we'll see how much has changed [12:01] * kalikiana taking a break [12:18] hey guys [12:18] do snaps run in containers? [12:18] gunix: hey [12:18] gunix: it depends [12:18] gunix: snaps are known to run (with some known issues) on recent versions of lxd when running on top of ubuntu [12:19] zyga-ubuntu: i just tried LXD on archlinux ... install via AUR is not working, but install via snapd is working. and this confuses me [12:19] zyga-ubuntu: and that made me ask my self how snapd is actually working [12:21] gunix: I think mborzecki will be the best to know this (he runs arch) [12:21] gunix: I can happily respond to detains about what we need from the system and how containers may break things [12:22] zyga-ubuntu: i am curious how snap is running system-agnostic apps [12:22] i don't understand how that is possible [12:22] for example, LXD needs to create a network bridge, so it needs to create specific files on the system [12:22] files which normally are not distro-agnostic [12:22] but still, it seems to work [12:23] i am can't understand how this is possible and i didn't find documentation about this online [12:24] mvo: 4399 needs a review, it's very nice and could be a 2.31 item [12:24] gunix: I cannot comment about LXD [12:24] gunix: perhaps stgraber can answer that [12:26] gunix: does the network work inside the containers? [12:27] mborzecki: yes, that's the confusing part. if you install LXC from the archlinux repos, you still have to configure networking [12:27] mborzecki: if you install LXD from aur, you can't create containers because it can't map the IDs [12:28] mborzecki: however, if you install LXD from snap (and snap gets installed from aur), you just do lxd init and everything works after that [12:28] this really looks like dark magic [12:30] oh and by default on archlinux you need to change a flag on the kernel if you want normal users to create NEWNS with clone (a.k.a. containers) ... and with the snap version of LXD, you just add the user to the lxd group and it works. [12:31] i guess you normally get people that ask why it doesn't work. not people who ask why it works. :D [12:38] mborzecki: can you please look at 4326 [12:38] gunix: the USERNS thing is already fix in arch kernel [12:39] zyga-ubuntu: uhh vendor reused vid/pid [12:39] ... [12:39] yeah [12:40] and here i thought i'd never have to see such things again [12:40] serial ports, no vid/pid, mess, usb, reuse vid/pid becaue saves 0.01$ [12:40] mess [12:40] ehehe, wonder how many devices are there with default ftdi vid/pid ;P [12:41] mvo: 4140 needs someone to decide [12:44] gunix: id mapping works differently because the snap sees the core's filesystem rather than the host's [12:47] mborzecki: are you sure? because i just installed an arch linux and you need to add the flag or install another kernel, in order to create containers when not root [12:48] gunix: which option? CONFIG_USER_NS? [12:48] mborzecki: https://wiki.archlinux.org/index.php/Linux_Containers [12:49] Enable support to run unprivileged containers (optional) [12:49] i don't know which of them because i didn't get it to work yet, i will go through all steps later today [12:50] gunix: yeah, just the kernel package + sysctl should work, iirc there was some discussion in the original bug report and the maintainer dopted patches from ubuntu or fedora [12:51] gunix: note that the lxd snap always runs as root [12:51] not as the lxd user [12:54] mvo: can you please look at https://github.com/snapcore/snapd/pull/3963 (aka oldest PR) [12:54] PR #3963: cmd/snap-confine: add support for per-user mounts [12:54] kalikiana: it still has to fix the user mapping problem [12:54] *the id mapping [12:54] gunix: did you read my previous message? [12:55] sorry, got only the one that it runs on root. reading now [12:55] no worries :-) [12:56] kalikiana: which are the core/host filesystems? [12:56] gunix: from the point of view of a snap, / comes from the core snap [12:57] not the actual / you'd expect [12:57] kalikiana: so all packages get installed in its chroot? [12:58] gunix: have a peek at /snap/core/current/ - nothing's installed there, but folders are mounted into place where things should be writable or you want to see the real contents [12:59] ok. thank you ... and in the users homefolder are only settings regarding the apps? because he also gets a .snap folder [13:00] OMW to the standup.. [13:01] hey niemeyer [13:01] gunix: those are files created by the snap, yes. home isn't accessible (unless you're using the "home" interface, and only non-hidden files even then) [13:02] you mean everything outside of /home/gunix/snap is not accessible by the application running as a snap? [13:02] kalikiana: ^ [13:07] gunix: yeah. a strict snap couldn't read, say, /home/gunix/mydocument.txt by default [13:07] kalikiana: than why was i able to change the settings of chromium to save in /home/gunix/Downloads instead of /home/gunix/snap/chromium/current/downloads ? [13:08] gunix: Have a look at `snap interfaces chromium`. You'll notice it has ":home" in the list [13:09] gunix: also try "snap interface home" [13:09] kalikiana: i have to install snap again for that, can you please paste that to bpaste? i will install snap later today, if you don't have time, so it's no rush [13:11] gunix: :home ag-mcphail,chromium,corebird,dekko,gedit,gimp,handbrake-jz,libreoffice,magic-device-tool,midori,nethack,rg,spotify,telegram-sergiusens,vlc [13:12] kalikiana: so chromium wants to use libreoffice and vlc? [13:14] gunix: Chromium uses the "home" slot, which the listed snaps plug into. Or to put it more simply, "Chromium uses the home interfaces, and all those other snaps do, too" [13:14] kalikiana: oh, so that's a list of the snaps that use the home slot, and you installed all the snaps in the above list, right? [13:15] gunix: Yes. This wouldn't show snaps that aren't installed. [13:15] kalikiana: do snaps run as containers? because i don't understand how gnome3 GUI apps would run in a container [13:16] gunix: no [13:16] gunix: and maybe [13:16] zyga-ubuntu: please explain :D [13:16] gunix: have a look at this https://new.zygoon.pl/post/poking-holes-in-cheese/ [13:17] zyga-ubuntu: haha "a look" [13:17] i will read it today or tomorrow [13:18] i also need to start working on a tripleo deployment since that is for my job, but i am too curious how snap works and i keep testing it instead of doing what i should [13:19] i always get this when i try archlinux. "yea i will just install arch on my desktop really quick and create some redhat VMs and continue my work" ... 5 days later: "ok so what if i install arch on the logical volume instead of the partition, so that i snapshot it before upgrades? hmm gotta try that" [13:23] greyback: oh right, forgot about that. in that snap, just do: something like: [13:23] name: foo [13:23] slots: [13:24] jdstrand: good morning! [13:24] x11-service: [13:24] interface: x11 [13:24] jdstrand: already figured out, with zyga's help [13:24] apps: [13:24] ... [13:24] ok, cool [13:24] hey zyga-ubuntu :) [13:24] cachio: reading 'man capabilities', it makes sense to add that cap to the policy [13:25] jdstrand: and it is working ok. Am trying to tighten up the interfaces and figure out /dev/shm usage [13:25] cachio: feel free to send up a PR and ping me for review [13:25] * kalikiana going to go for lunch in a bit [13:25] greyback: awesome! sorry again for the slow response. I'm no longer sprinting [13:25] jdstrand: no worries at all [13:25] * greyback thinks he sees the finishing line at long last [13:35] * kalikiana read that as "fishing line" and wondered if that was sarcasm [14:03] * pstolowski lunch [14:06] jdstrand, ok, I'll try that, thanks [14:21] zyga-ubuntu: I think you're misunderstanding gunix's question regarding "do snaps run inside containers?". I think gunix means something along the lines of not "if I create a container can I run a snap inside it?" and more "when I run a snap on my system, is it being executed inside a container to isolate it?" [14:23] mvo, is bug #1744584 might be worth commenting on if you have any recommendation of what snaps folder need backuping or not? [14:23] Bug #1744584: Exclude Snap .cache from Dejadup backups

[14:23] diddledan: ah, perhaps [14:23] gunix: ^ [14:23] gunix: which question was it? [14:25] when I run a snap on my system, is it being executed inside a container to isolate it? [14:25] diddledan: zyga-ubuntu ^ [14:25] seb128: thanks, looking [14:25] mvo, thanks :) [14:25] gunix: aha, I see [14:26] gunix: so my answer stands, it depends on how you understand containers; I'm inclined to say "no" more than yes [14:26] gunix: because most of the security confinement comes from LSM (apparmor) [14:26] gunix: though we also use some of the technology used by what people agree are containers [14:26] zyga-ubuntu: can't be. i am running archlinux [14:26] gunix: hence the fuzzy answer [14:27] gunix: right, we use a combination of things [14:27] there is a teeny bit of container-tech used, such as mount-namespaces [14:27] gunix: and container is a marketing term more than a technical term today [14:27] gunix: but also spiritually, we try to integrate the app with the host [14:27] gunix: more than any other "containers" do [14:27] * diddledan meditates [14:27] zyga-ubuntu: with container, i mean NEWNS flag within the clone() function. [14:27] I'm spiritual [14:28] zyga-ubuntu: was that a marketing explanation too? :D [14:28] gunix: yes, we do that [14:28] (ish) [14:28] gunix: that's the only thing that we do that is clearly a container tech [14:28] * zyga-ubuntu gets more tea [14:29] zyga-ubuntu: is that default for all snaps? [14:31] getting more tea _should_ be the default for all apps [14:31] * Chipaca gets more tea too [14:31] I'm more a cola addict :-p [14:31] pepsi max ftw (no sugar) [14:31] gunix: yes, all snaps use that by default; the only exception are snaps that you install with --classic [14:32] gunix: those are, like classic packages, installed directly on your system [14:36] re [14:38] mvo: 4507 is green and has two +1s [14:47] jdstrand, you mean net_admin capability? [14:49] jdstrand, https://paste.ubuntu.com/26437642/ [14:50] I am using this, I already modified the capability [14:56] am I missing a trick, or is it not possible to stream a file into a tar with archive/tar? [14:57] (the key being I don't know the size of the file beforehand) [14:57] Chipaca: you should be able to do something equivalent to `cat file | tar cf mytarfile.tar` [14:58] unless you're talking about golang in which case I've done that before on an unrelated project [14:58] diddledan: golang yes [14:59] * Chipaca asks the same question over in #go-nuts because he feels it's nuts that he can't :-) [14:59] Good morning! [15:00] my code is a mess, but you can see I stream a file from sftp into a tar here: https://github.com/bowlhat/sftp-client/blob/master/backup.go [15:00] Chipaca: iirc you need to know the size upfront so that when parsing t you can skip that much + any padding [15:05] PR snapd#4507 closed: advisor: use forked bolt to make it work on ppc [15:05] jdstrand, this is the interface that I am using when I see that error, https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/interfaces/builtin/netlink_audit.go [15:06] jdstrand, do you think it needs any other change? === jkridner_ is now known as jkridner [15:10] PR snapd#4495 closed: data/dbus: add AssumedAppArmorLabel=unconfined [15:24] I added snap as an installation method for LXD on the archlinux wiki: https://wiki.archlinux.org/index.php/LXD [15:25] mvo: can I close core#67 now? [15:25] PR core#67: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin [15:25] since snap works flawlessly, it deserves this [15:25] gunix: thank you~! [15:25] zyga-ubuntu: so to fix the mount unit ordering issue, what kind of test do we need? [15:25] zyga-ubuntu: is a reboot inside the lxd container the rightonw? [15:25] right one? [15:25] mvo: I think I had a branch with a test [15:25] PR core#67 closed: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin [15:26] mvo: just remove a snap :) [15:26] zyga-ubuntu: inside lxd? ok [15:26] mvo: yes [15:26] mvo: is core#69 something that can be closed now? [15:26] PR core#69: hooks: add 28-command-not-found.chroot to create c-n-f handler [15:27] zyga-ubuntu: yes, good point [15:27] cachio: your paste from before was for audit_read: https://paste.ubuntu.com/26412541/ [15:27] PR core#69 closed: hooks: add 28-command-not-found.chroot to create c-n-f handler [15:28] thank you! [15:29] jdstrand, let me create a PR with the test so you can see what I am doing [15:29] gunix: niiiice :-D [15:30] jdstrand, #4515 [15:30] PR #4515: tests: new spread test for netlink-audit interface [15:30] cachio: man 7 netlink only says that net_admin is needed for multicasting. that doesn't mean it is accurate, but your paste from last week says audit_read and 'man capabilities' says 'Allow reading the audit log via a multicast netlink socket' [15:30] PR snapd#4515 opened: tests: new spread test for netlink-audit interface [15:31] cachio: since net_admin is needed for setting up a multicast socket, you probably will need both [15:31] Chipaca: have you found a way to deal with the tar issue? [15:31] mborzecki: "use archive/zip instead" [15:31] radical [15:31] this is exactly the sort of silly issue i wanted to root out by this approach to it all, so \o/ [15:32] Chipaca: glad that it works with zip :) [15:32] mborzecki: we'll see :-) [15:32] i like your optimism though [15:33] cachio: reading that PR it isn't clear that NETLINK_AUDIT is a multicast socket [15:34] Chipaca: hmm looking at https://golang.org/src/archive/zip/writer.go#L224 looks like zip writes the header upfront too [15:34] jdstrand, what do you suggest to fix it? [15:36] mborzecki: but AFAICT it doesn't require the size at that point [15:37] mborzecki: note how close() updates the header [15:37] Chipaca: yeah, it seems to update the count on the flly (next to crc32) [15:38]