[00:38] <diddledan> gunix: yes
[06:37] <mborzecki> morning
[07:04] <gunix> hey diddledan
[07:04] <gunix> if somebody that can explain snapd to me is online, please ping me
[07:04] <gunix> i do not understand how this system works and it amazes me that stuff like LXD works on archlinux via snap
[07:19] <mborzecki> mvo: morning
[07:25] <mvo> good morning mborzecki
[07:26] <mup> PR snapd#4508 closed: New spread test for hardware-random-observe interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4508>
[07:37] <mvo> 4495 needs a second review
[07:41] <mup> PR snapd#4425 closed: config: add support for `snap set core proxy.no_proxy=...` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4425>
[07:44] <mvo> 4473 also needs a second review :)
[07:44] <mup> PR snapd#4476 closed: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4476>
[08:03] <kalikiana> good morning
[08:07] <pstolowski> hey o/
[08:08] <zyga-ubuntu> good morning :)
[08:09] <mvo> good morning kalikiana pstolowski and zyga-ubuntu !
[08:09] <mvo> happy monday!
[08:09] <koza> mvo, hey, what is the forecast on the strace support for snaps?
[08:09] <mvo> koza: if somone reviews my PR at least basic support will land for 2.31
[08:09] <mborzecki> zyga-ubuntu: pstolowski: kalikiana: morning guys
[08:10] <mvo> koza: we want support for custom options as well, there is a PR for that too
[08:10] <mborzecki> koza: hey
[08:10] <mvo> 4473 is the strace pr that needs a second review :)
[08:10] <mvo> koza: there is also your motd PR that we need to land for 2.31, right?
[08:10] <koza> mvo, but like days, weeks, months? :)
[08:11] <koza> mvo, would be nice, Thibaut commented vi email, Ill change the PR accordingly today
[08:11] <mvo> koza: 2.31 is scheduled for beta this week and stable in ~4 weeks
[08:11] <mvo> koza: ta
[08:11] <koza> mvo, nice!
[08:11] <mvo> koza: yeah, we are quite excited about strace too, its a popular feature
[08:14] <mborzecki> 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] <mup> Bug #1744433: 'snap refresh' is silent about changes in progress <snapd:Triaged> <https://launchpad.net/bugs/1744433>
[08:14] <mvo> mborzecki: aha, you have a pr already?
[08:15] <mborzecki> mvo: no :) trying to figure out if there's a nicer way
[08:15] <mborzecki> mvo: i can open a pr with this change though
[08:16] <mvo> mborzecki: what is your current diff, could you pastebin this please?
[08:16] <mborzecki> mvo: https://paste.ubuntu.com/26435923/
[08:16] <mborzecki> sorry, paste the bug link twice in the previous message
[08:18] <mvo> 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] <mborzecki> mvo: the error mesage on `snap refresh vlc` would be friendly, instad of changes you'd get 'auto-refresh' and so on
[08:20] <zyga-ubuntu> mvo: I think I should update 2.30 in opensuse today
[08:20] <mborzecki> the rest i have not figured out yet
[08:20] <zyga-ubuntu> mvo: and we have some bug reports on fedora front to inspect
[08:20] <mvo> mborzecki: aha, ok - yeah, making this friendlier is definitely nice
[08:20] <mvo> zyga-ubuntu: +1 for updates
[08:21] <mvo> zyga-ubuntu: where do the fedora bugs come from? their bugtracker?
[08:26] <zyga-ubuntu> mvo: yes, on bugzilla
[08:26] <mvo> zyga-ubuntu: ok, how bad do they look?
[08:26] <zyga-ubuntu> https://bugzilla.redhat.com/show_bug.cgi?id=1536895
[08:27] <mvo> uhh, ok
[08:27] <mvo> I wonder why we did not caught this in testing :(
[08:27] <zyga-ubuntu> yes, it's surprising to me as well
[08:35] <zyga-ubuntu> I'll be back soon, just getting some quick food
[08:35] <mborzecki> zyga-ubuntu: looks like something we fixed recently
[08:57] <mup> PR snapd#4513 closed: dirs: fix snap mount dir on Manjaro <Created by mati865> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4513>
[09:11] <mup> PR snapd#4514 opened: overlord/snapstate: record the 'kind' of conflicting change <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4514>
[09:14] <Chipaca> whoa, quickest reviewers in the west
[09:15] <mborzecki> Chipaca: morning
[09:16] <Chipaca> mborzecki: morning :-)
[09:20] <Chipaca> do we have a pedronis again this week, or is that next week?
[09:21] <mborzecki> Chipaca: i think he mentioned he'd be on vacation until 29th
[09:22] <Chipaca> mborzecki: I laud your detailed memory
[09:22] <mborzecki> haha, yeah, my wife would disagree :)
[09:22] <mvo> lol@ mborzecki
[09:23] <mvo> hey Chipaca good morning and happy monday!
[09:23] <Chipaca> mborzecki: she holds you to a higher standard :-D
[09:23] <Chipaca> mvo: good morning! monday's looking good indeed
[09:30] <zyga-ubuntu> Chipaca: hey
[09:30] <zyga-ubuntu> Chipaca: I added i386
[09:31] <zyga-ubuntu> Chipaca: I didn't do accounts yet but ping me if you want to play and I'll do that quickly
[09:31] <Chipaca> zyga-ubuntu: awesome. I don't think I need it right now, but very good to know.
[09:31] <zyga-ubuntu> and I will change the power adapter for the dragonboard so that it can be on 24/7
[09:31] <zyga-ubuntu> but that's in the evening as it's not a priority for anyone today
[09:38] <zyga-ubuntu> mborzecki: 4509 has another review
[09:38] <mborzecki> zyga-ubuntu: thanks
[09:38] <zyga-ubuntu> mvo: any news on bolt, ppc and other misery?
[09:41] <mvo> 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] <mborzecki> wonder when the new 'working' microcode will be released
[09:43] <mvo> mborzecki: you are not alone here
[09:43] <mvo> mborzecki: btw, are you looking into the "snap refresh" output as well (if there is another refresh alreaady running)?
[09:44] <mborzecki> mvo: no, i've put is aside for now, i ended up going in circles
[09:45] <zyga-ubuntu> mborzecki: "working" or working?
[09:45] <mvo> mborzecki: ok, no worries, just wanted to check
[09:45] <mvo> mborzecki: I was considering looking but had no time for it yet :/
[09:46] <mborzecki> mvo: go ahead, i'm poking around https://bugs.launchpad.net/snappy/+bug/1741486 now
[09:46] <mup> Bug #1741486: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>
[09:47] <mvo> mborzecki: aha, nice! thats a good one too
[09:47] <mborzecki> 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] <mup> Bug #1743504: Ubuntu 16.04 snapd service not working <Snappy:New> <https://launchpad.net/bugs/1743504>
[09:51] <mvo> mborzecki: looking
[09:53] <mvo> mborzecki: I closed it now
[09:53] <mborzecki> mvo: great, thanks
[09:53] <mup> Bug #1743504 changed: Ubuntu 16.04 snapd service not working <Snappy:Invalid> <https://launchpad.net/bugs/1743504>
[09:53] <mvo> mborzecki: thank you! how are we actually doing with "New" bugs? how many are not confirmed/triaged currently?
[09:58] <Chipaca> (a) wooo, baby steps progress is now tangible
[09:58] <Chipaca> (b) /me -> physio
[09:59] <mvo> zyga-ubuntu: silly question, do we bundle on opensuse?
[10:00] <zyga-ubuntu> mvo: yes, we do
[10:00] <mvo> zyga-ubuntu: excellent
[10:00] <zyga-ubuntu> mvo: (it's legan now)
[10:00] <zyga-ubuntu> legal*
[10:01] <mvo> zyga-ubuntu: I fixed bolt on fedora by sed things back to boltdb/bolt
[10:01] <mvo> zyga-ubuntu: that means we just need to fix debian, I can make a patch, just need to find the upstream repo
[10:01] <mvo> zyga-ubuntu: eh, packaging repo
[10:03] <mvo> 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] <jamesb192> 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] <zyga-ubuntu> jamesb192: looking
[10:19] <zyga-ubuntu> kalikiana: you are reading my mind!
[10:20] <zyga-ubuntu> jamesb192: snap-confine is usually in /usr/lib/snapd/snap-confine or /usr/libexec/snapd/snap-confine
[10:20] <zyga-ubuntu> jamesb192: same with a host of other binaries (only snap and snapctl are on path)
[10:20] <zyga-ubuntu> jamesb192: you can drop the following systemd units: autoimport, core-fixup
[10:20] <zyga-ubuntu> snap-repair
[10:20] <zyga-ubuntu> system-shutdown
[10:20] <zyga-ubuntu> and the corresponding timer
[10:21] <zyga-ubuntu> jamesb192: you can drop the snapd autoimport servic
[10:21] <zyga-ubuntu> er
[10:21] <zyga-ubuntu> this thing: -rw-r--r-- root/root       157 2018-01-20 08:53 ./lib/udev/rules.d/66-snapd-autoimport.rules
[10:21] <zyga-ubuntu> the udev rules
[10:21] <zyga-ubuntu> those things are all files relevant for core but irrelevant elsewhere
[10:21] <zyga-ubuntu> core == not classic systems
[10:21] <zyga-ubuntu> the /opt/snapd location is curious, what made you put all those files there/
[10:21] <kalikiana> zyga-ubuntu: you're welcome :-D
[10:22] <jamesb192> temporary holding area until I do something useful.
[10:23] <zyga-ubuntu> jamesb192:
[10:24] <zyga-ubuntu> ok, I think you will have some issues still but this looks like a good starting point, I may have missed something
[10:24] <zyga-ubuntu> 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] <zyga-ubuntu> and always exclude the files I mentioned above
[10:24] <zyga-ubuntu> (they are at best no-ops on normal systems)
[10:24] <zyga-ubuntu> the end goal is to have a system that can be spread tested and that would pass our integration tests
[10:25] <zyga-ubuntu> but for now just iterate this way and run snaps on your system and see what breaks
[10:26] <jamesb192> Okay. I will do that. thank you.
[10:27] <zyga-ubuntu> jamesb192: please send update reports to the forum, I'm sure it will have wider exposure there
[10:27] <zyga-ubuntu> I can respond there as well
[10:33] <zyga-ubuntu> 4505 needs a 2nd review
[10:33] <zyga-ubuntu> ah
[10:33] <zyga-ubuntu> sorry
[10:33] <zyga-ubuntu> 4502*
[10:33] <zyga-ubuntu> not 5
[10:48] <zyga-ubuntu> mvo: 4505 updated per your comments
[10:52] <mup> PR snapd#4514 closed: overlord/snapstate: record the 'kind' of conflicting change <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4514>
[10:58] <mvo> zyga-ubuntu: ta, one quick comment added
[10:59] <zyga-ubuntu> sure
[11:00] <zyga-ubuntu> mvo: which code reads "it" (I assume group/user name)
[11:00] <zyga-ubuntu> mvo: the switch you linked to explicitly maps specific values
[11:01] <mvo> zyga-ubuntu: let me double check, maybe github is playing tricks on me
[11:01] <zyga-ubuntu> mvo: the code in snap-update-ns did do name lookups AFAIR but I'm not sure it has to still
[11:01] <zyga-ubuntu> mvo: and that code is more generic as it applies to other mechanisms
[11:01] <zyga-ubuntu> mvo: this one only does layout language
[11:02] <mvo> zyga-ubuntu: aha, you are right, I was misreading the code
[11:02] <mvo> zyga-ubuntu: sorry
[11:02] <zyga-ubuntu> mvo: no worries, I wanted to check if I missed something :) thank you for askin!
[11:46] <zyga-ubuntu> joc: gentle ping about #4326
[11:46] <mup> PR #4326: interfaces/builtin: blacklist zigbee dongle <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4326>
[11:47] <zyga-ubuntu> I think you know more about that than we do
[11:50] <zyga-ubuntu> mborzecki: what's the status of 4285?
[11:51] <mborzecki> 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] <zyga-ubuntu> mborzecki: does it make sense to unconflict and merge this
[11:56] <zyga-ubuntu> opensuse 42.2 will be EOLed this week
[11:56] <zyga-ubuntu> we should switch to 42.3
[11:59] <mborzecki> 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] <gunix> hey guys
[12:18] <gunix> do snaps run in containers?
[12:18] <zyga-ubuntu> gunix: hey
[12:18] <zyga-ubuntu> gunix: it depends
[12:18] <zyga-ubuntu> gunix: snaps are known to run (with some known issues) on recent versions of lxd when running on top of ubuntu
[12:19] <gunix> 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] <gunix> zyga-ubuntu: and that made me ask my self how snapd is actually working
[12:21] <zyga-ubuntu> gunix: I think mborzecki will be the best to know this (he runs arch)
[12:21] <zyga-ubuntu> gunix: I can happily respond to detains about what we need from the system and how containers may break things
[12:22] <gunix> zyga-ubuntu: i am curious how snap is running system-agnostic apps
[12:22] <gunix> i don't understand how that is possible
[12:22] <gunix> for example, LXD needs to create a network bridge, so it needs to create specific files on the system
[12:22] <gunix> files which normally are not distro-agnostic
[12:22] <gunix> but still, it seems to work
[12:23] <gunix> i am can't understand how this is possible and i didn't find documentation about this online
[12:24] <zyga-ubuntu> mvo: 4399 needs a review, it's very nice and could be a 2.31 item
[12:24] <zyga-ubuntu> gunix: I cannot comment about LXD
[12:24] <zyga-ubuntu> gunix: perhaps stgraber can answer that
[12:26] <mborzecki> gunix: does the network work inside the containers?
[12:27] <gunix> mborzecki: yes, that's the confusing part. if you install LXC from the archlinux repos, you still have to configure networking
[12:27] <gunix> mborzecki: if you install LXD from aur, you can't create containers because it can't map the IDs
[12:28] <gunix> 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] <gunix> this really looks like dark magic
[12:30] <gunix> 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] <gunix> i guess you normally get people that ask why it doesn't work. not people who ask why it works. :D
[12:38] <zyga-ubuntu> mborzecki: can you please look at 4326
[12:38] <mborzecki> gunix: the USERNS thing is already fix in arch kernel
[12:39] <mborzecki> zyga-ubuntu: uhh vendor reused vid/pid
[12:39] <zyga-ubuntu> ...
[12:39] <zyga-ubuntu> yeah
[12:40] <mborzecki> and here i thought i'd never have to see such things again
[12:40] <zyga-ubuntu> serial ports, no vid/pid, mess, usb, reuse vid/pid becaue saves 0.01$
[12:40] <zyga-ubuntu> mess
[12:40] <mborzecki> ehehe, wonder how many devices are there with default ftdi vid/pid ;P
[12:41] <zyga-ubuntu> mvo: 4140 needs someone to decide
[12:44] <kalikiana> gunix: id mapping works differently because the snap sees the core's filesystem rather than the host's
[12:47] <gunix> 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] <mborzecki> gunix: which option? CONFIG_USER_NS?
[12:48] <gunix> mborzecki: https://wiki.archlinux.org/index.php/Linux_Containers
[12:49] <gunix> Enable support to run unprivileged containers (optional)
[12:49] <gunix> 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] <mborzecki> 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] <kalikiana> gunix: note that the lxd snap always runs as root
[12:51] <kalikiana> not as the lxd user
[12:54] <zyga-ubuntu> mvo: can you please look at https://github.com/snapcore/snapd/pull/3963 (aka oldest PR)
[12:54] <mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
[12:54] <gunix> kalikiana: it still has to fix the user mapping problem
[12:54] <gunix> *the id mapping
[12:54] <kalikiana> gunix: did you read my previous message?
[12:55] <gunix> sorry, got only the one that it runs on root. reading now
[12:55] <kalikiana> no worries :-)
[12:56] <gunix> kalikiana: which are the core/host filesystems?
[12:56] <kalikiana> gunix: from the point of view of a snap, / comes from the core snap
[12:57] <kalikiana> not the actual / you'd expect
[12:57] <gunix> kalikiana: so all packages get installed in its chroot?
[12:58] <kalikiana> 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] <gunix> ok. thank you ... and in the users homefolder are only settings regarding the apps? because he also gets a .snap folder
[13:00] <niemeyer> OMW to the standup..
[13:01] <zyga-ubuntu> hey niemeyer
[13:01] <kalikiana> 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] <gunix> you mean everything outside of /home/gunix/snap is not accessible by the application running as a snap?
[13:02] <gunix> kalikiana: ^
[13:07] <kalikiana> gunix: yeah. a strict snap couldn't read, say, /home/gunix/mydocument.txt by default
[13:07] <gunix> 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] <kalikiana> gunix: Have a look at `snap interfaces chromium`. You'll notice it has ":home" in the list
[13:09] <zyga-ubuntu> gunix: also try "snap interface home"
[13:09] <gunix> 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] <kalikiana> gunix: :home                    ag-mcphail,chromium,corebird,dekko,gedit,gimp,handbrake-jz,libreoffice,magic-device-tool,midori,nethack,rg,spotify,telegram-sergiusens,vlc
[13:12] <gunix> kalikiana: so chromium wants to use libreoffice and vlc?
[13:14] <kalikiana> 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] <gunix> 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] <kalikiana> gunix: Yes. This wouldn't show snaps that aren't installed.
[13:15] <gunix> kalikiana: do snaps run as containers? because i don't understand how gnome3 GUI apps would run in a container
[13:16] <zyga-ubuntu> gunix: no
[13:16] <zyga-ubuntu> gunix: and maybe
[13:16] <gunix> zyga-ubuntu: please explain :D
[13:16] <zyga-ubuntu> gunix: have a look at this https://new.zygoon.pl/post/poking-holes-in-cheese/
[13:17] <gunix> zyga-ubuntu: haha "a look"
[13:17] <gunix> i will read it today or tomorrow
[13:18] <gunix> 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] <gunix> 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] <jdstrand> greyback: oh right, forgot about that. in that snap, just do: something like:
[13:23] <jdstrand> name: foo
[13:23] <jdstrand> slots:
[13:24] <zyga-ubuntu> jdstrand: good morning!
[13:24] <jdstrand>   x11-service:
[13:24] <jdstrand>     interface: x11
[13:24] <greyback> jdstrand: already figured out, with zyga's help
[13:24] <jdstrand> apps:
[13:24] <jdstrand>   ...
[13:24] <jdstrand> ok, cool
[13:24] <jdstrand> hey zyga-ubuntu :)
[13:24] <jdstrand> cachio: reading 'man capabilities', it makes sense to add that cap to the policy
[13:25] <greyback> jdstrand: and it is working ok. Am trying to tighten up the interfaces and figure out /dev/shm usage
[13:25] <jdstrand> 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] <jdstrand> greyback: awesome! sorry again for the slow response. I'm no longer sprinting
[13:25] <greyback> 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] <cachio> jdstrand, ok, I'll try that, thanks
[14:21] <diddledan> 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] <seb128> mvo, is bug #1744584 might be worth commenting on if you have any recommendation of what snaps folder need backuping or not?
[14:23] <mup> Bug #1744584: Exclude Snap .cache from Dejadup backups <Déjà Dup:Triaged> <Snappy:New> <deja-dup (Ubuntu):Triaged> <https://launchpad.net/bugs/1744584>
[14:23] <zyga-ubuntu> diddledan: ah, perhaps
[14:23] <zyga-ubuntu> gunix: ^
[14:23] <zyga-ubuntu> gunix: which question was it?
[14:25] <gunix> when I run a snap on my system, is it being executed inside a container to isolate it?
[14:25] <gunix> diddledan: zyga-ubuntu ^
[14:25] <mvo> seb128: thanks, looking
[14:25] <seb128> mvo, thanks :)
[14:25] <zyga-ubuntu> gunix: aha, I see
[14:26] <zyga-ubuntu> gunix: so my answer stands, it depends on how you understand containers; I'm inclined to say "no" more than yes
[14:26] <zyga-ubuntu> gunix: because most of the security confinement comes from LSM (apparmor)
[14:26] <zyga-ubuntu> gunix: though we also use some of the technology used by what people agree are containers
[14:26] <gunix> zyga-ubuntu: can't be. i am running archlinux
[14:26] <zyga-ubuntu> gunix: hence the fuzzy answer
[14:27] <zyga-ubuntu> gunix: right, we use a combination of things
[14:27] <diddledan> there is a teeny bit of container-tech used, such as mount-namespaces
[14:27] <zyga-ubuntu> gunix: and container is a marketing term more than a technical term today
[14:27] <zyga-ubuntu> gunix: but also spiritually, we try to integrate the app with the host
[14:27] <zyga-ubuntu> gunix: more than any other "containers" do
[14:27]  * diddledan meditates
[14:27] <gunix> zyga-ubuntu: with container, i mean NEWNS flag within the clone() function.
[14:27] <diddledan> I'm spiritual
[14:28] <gunix> zyga-ubuntu: was that a marketing explanation too? :D
[14:28] <zyga-ubuntu> gunix: yes, we do that
[14:28] <zyga-ubuntu> (ish)
[14:28] <zyga-ubuntu> gunix: that's the only thing that we do that is clearly a container tech
[14:28]  * zyga-ubuntu gets more tea
[14:29] <gunix> zyga-ubuntu: is that default for all snaps?
[14:31] <Chipaca> getting more tea _should_ be the default for all apps
[14:31]  * Chipaca gets more tea too
[14:31] <diddledan> I'm more a cola addict :-p
[14:31] <diddledan> pepsi max ftw (no sugar)
[14:31] <zyga-ubuntu> gunix: yes, all snaps use that by default; the only exception are snaps that you install with --classic
[14:32] <zyga-ubuntu> gunix: those are, like classic packages, installed directly on your system
[14:36] <kalikiana> re
[14:38] <zyga-ubuntu> mvo: 4507 is green and has two +1s
[14:47] <cachio> jdstrand, you mean net_admin capability?
[14:49] <cachio> jdstrand, https://paste.ubuntu.com/26437642/
[14:50] <cachio> I am using this, I already modified the capability
[14:56] <Chipaca> am I missing a trick, or is it not possible to stream a file into a tar with archive/tar?
[14:57] <Chipaca> (the key being I don't know the size of the file beforehand)
[14:57] <diddledan> Chipaca: you should be able to do something equivalent to `cat file | tar cf mytarfile.tar`
[14:58] <diddledan> unless you're talking about golang in which case I've done that before on an unrelated project
[14:58] <Chipaca> 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] <elopio> Good morning!
[15:00] <diddledan> 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] <mborzecki> Chipaca: iirc you need to know the size upfront so that when parsing t you can skip that much + any padding
[15:05] <mup> PR snapd#4507 closed: advisor: use forked bolt to make it work on ppc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4507>
[15:05] <cachio> 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] <cachio> jdstrand, do you think it needs any other change?
[15:10] <mup> PR snapd#4495 closed: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4495>
[15:24] <gunix> I added snap as an installation method for LXD on the archlinux wiki: https://wiki.archlinux.org/index.php/LXD
[15:25] <zyga-ubuntu> mvo: can I close core#67 now?
[15:25] <mup> PR core#67: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin <Created by mvo5> <https://github.com/snapcore/core/pull/67>
[15:25] <gunix> since snap works flawlessly, it deserves this
[15:25] <zyga-ubuntu> gunix: thank you~!
[15:25] <mvo> zyga-ubuntu: so to fix the mount unit ordering issue, what kind of test do we need?
[15:25] <mvo> zyga-ubuntu: is a reboot inside the lxd container the rightonw?
[15:25] <mvo> right one?
[15:25] <zyga-ubuntu> mvo: I think I had a branch with a test
[15:25] <mup> PR core#67 closed: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/67>
[15:26] <zyga-ubuntu> mvo: just remove a snap :)
[15:26] <mvo> zyga-ubuntu: inside lxd? ok
[15:26] <zyga-ubuntu> mvo: yes
[15:26] <zyga-ubuntu> mvo: is core#69 something that can be closed now?
[15:26] <mup> PR core#69: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <https://github.com/snapcore/core/pull/69>
[15:27] <mvo> zyga-ubuntu: yes, good point
[15:27] <jdstrand> cachio: your paste from before was for audit_read: https://paste.ubuntu.com/26412541/
[15:27] <mup> PR core#69 closed: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/69>
[15:28] <zyga-ubuntu> thank you!
[15:29] <cachio> jdstrand, let me create a PR with the test so you can see what I am doing
[15:29] <kalikiana> gunix: niiiice :-D
[15:30] <cachio> jdstrand, #4515
[15:30] <mup> PR #4515: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4515>
[15:30] <jdstrand> 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] <mup> PR snapd#4515 opened: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4515>
[15:31] <jdstrand> cachio: since net_admin is needed for setting up a multicast socket, you probably will need both
[15:31] <mborzecki> Chipaca: have you found a way to deal with the tar issue?
[15:31] <Chipaca> mborzecki: "use archive/zip instead"
[15:31] <mborzecki> radical
[15:31] <Chipaca> this is exactly the sort of silly issue i wanted to root out by this approach to it all, so \o/
[15:32] <mborzecki> Chipaca: glad that it works with zip :)
[15:32] <Chipaca> mborzecki: we'll see :-)
[15:32] <Chipaca> i like your optimism though
[15:33] <jdstrand> cachio: reading that PR it isn't clear that NETLINK_AUDIT is a multicast socket
[15:34] <mborzecki> Chipaca: hmm looking at https://golang.org/src/archive/zip/writer.go#L224 looks like zip writes the header upfront too
[15:34] <cachio> jdstrand, what do you suggest to fix it?
[15:36] <Chipaca> mborzecki: but AFAICT it doesn't require the size at that point
[15:37] <Chipaca> mborzecki: note how close() updates the header
[15:37] <mborzecki> Chipaca: yeah, it seems to update the count on the flly (next to crc32)
[15:38] <mvo> zyga-ubuntu: any idea about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1744738 ? i.e. inside lxd it seems like apparmor is not confined anymore
[15:38] <mup> Bug #1744738: snapd 2.29.4.2 ADT test tests/main/lxd failure with linux-hwe 4.13.0-30.33~16.04.1 <snapd (Ubuntu):New> <https://launchpad.net/bugs/1744738>
[15:38] <mvo> zyga-ubuntu: also slightly sad, but I only get 20kb for the lxd test so my ordering fix can take forever to verify
[15:39] <zyga-ubuntu> mvo: looking
[15:39] <mborzecki> Chipaca: so there's a fileWriter https://golang.org/src/archive/zip/writer.go#L317 and a countWriter https://golang.org/src/archive/zip/writer.go#L384 oh my
[15:39] <zyga-ubuntu> hmm
[15:40] <jdstrand> cachio: I think that the capabilities man page implies it is multicast. I commented in the pr
[15:41] <jdstrand> mvo, zyga-ubuntu: I may have an idea on that
[15:41] <mborzecki> Chipaca: we had a running joke at my previous company that all problems are solved by adding another reader/writer, in that case we had a file upload through POST which was repacking the data, checksumming, encrypting and uploading to s3 from one of the intermediate steps :P
[15:41] <mvo> jdstrand: oh, tell us more please
[15:42] <cachio> jdstrand, great, thanks
[15:42] <jdstrand> mvo: I haven't read that bug very closely, but serguisens reported an issue to me
[15:42] <zyga-ubuntu> mvo: can you please cherry pick the unit test from #4258
[15:42] <mup> PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258>
[15:42] <zyga-ubuntu> mvo: as for the lxd issue you just linked to
[15:42] <jdstrand> mvo: on kernels that have partial apparmor support, the apparmor policy is set to the classic template
[15:42] <zyga-ubuntu> mvo: not sure yet
[15:43] <Chipaca> mborzecki: I may or may not have a io.TeeReader of a io.TeeReader of a member of an archive and a hasher, and a sizer
[15:43] <zyga-ubuntu> jdstrand: ah, nice catch!
[15:43] <jdstrand> mvo: this gives a glob rule like /** pix,
[15:43] <Chipaca> mborzecki: 	dec := json.NewDecoder(io.TeeReader(metaReader, io.MultiWriter(metaHashChecker, &sz)))
[15:43] <Chipaca> mborzecki: also that ^
[15:43] <jdstrand> mvo: whereas the lxd-support template has /usr/sbin/aa-exec ux, (or similar)
[15:44] <mborzecki> Chipaca: hahah
[15:44] <jdstrand> mvo: 'ix' ends up scrubbing the environment (it shouldn't, that is an apparmor bug related to limitations in the current implementation)
[15:44] <jdstrand> mvo: and 'ux' doesn't
[15:44] <niemeyer> Newly allocated one machine roundtrips a dummy run in almost exactly one minute
[15:44] <niemeyer> on spread+Linode, that is
[15:45] <niemeyer> Surprisingly good
[15:45] <mvo> jdstrand: hm, why do we start to see this now?
[15:45] <mvo> jdstrand: thanks for explaining that :)
[15:45] <mvo> jdstrand: I wonder a) why now b) what can we do about it :)
[15:45] <niemeyer> That includes allocation of the brand new instance, image creation, trivial task run, and machine removal
[15:45] <jdstrand> mvo: what I've seen is that on those kernels the 'lxd init' command can't find the required libraries because LD_LIBRARY_PATH is cleared
[15:47] <jdstrand> mvo: I have a todo to file both an apparmor bug and a snapd bug. I'm evaluating how to fix this in snapd. this came up at the sprint so I couldn't chase it down further. was going to look at it after the layouts reviews
[15:48] <mvo> jdstrand: great, thank you! can I paste this into the open bug?
[15:48] <jdstrand> mvo: now, like I said, I haven't looked at the aforementioned bug closely, but I wonder if something with the partial support is affecting this? it *shouldn't* if I understand that bug after looking at it a little-- seems this should all be happening on a xenial kernel with full apparmor support
[15:49] <jdstrand> mvo: well, no, I'm only wondering if that bug is involved
[15:49] <mvo> jdstrand: aha, ok, sorry I misunderstood
[15:49] <mvo> jdstrand: yes, this is all full confinement
[15:49] <jdstrand> + lxd init --auto
[15:49] <jdstrand> LXD has been successfully configured.
[15:49] <jdstrand> that suggests that it isn't it...
[15:50] <jdstrand> so, sorry for the noise, but fyi there is a problem with lxd snap and partial apparmor support :)
[15:51] <mvo> jdstrand: heh, no worries and thanks, good (or bad) to know about this problem
[15:55] <jdstrand> mvo, zyga-ubuntu: with that bug, it seems that the container doesn't have the snap-confine loaded or snap-confine is not detecting that it is loaded correctly
[15:57] <mvo> jdstrand: the only change we did for 2.29.4.2 was http://launchpadlibrarian.net/347640641/snapd_2.29.4.1_2.29.4.2.diff.gz
[15:59] <zyga-ubuntu> mvo: it feels like something else has changed under us
[15:59] <jdstrand> mvo: it is a 2.29.4.1 to 2.29.4.2 regression? the bug talks about 2.28.5
[15:59] <mvo> jdstrand: indeed, 2.28.5 -> 2.29.4.2
[16:00] <mvo> zyga-ubuntu: same here
[16:00] <jdstrand> it could be that the kernel changed or lxd. someone should try to reproduce manually and run snap-confine in debug mode
[16:00] <jdstrand> mvo: (the diff you gave was 2.29.4.1 to 2.29.4.2)
[16:01] <mvo> hm, 2.29.4.2 is fine with lxd for linux-meta/4.4.0.105.110 on 2017-12-22 so 2.29.4.2 is probably not it
[16:01] <jdstrand> istr a bug about lxd not detecting apparmor correctly
[16:01]  * jdstrand tries to find
[16:04] <jdstrand> mvo: I wonder if it is a variation on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1743079?
[16:04] <mup> Bug #1743079: apparmor exit code 123 <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1743079>
[16:04] <jdstrand> mvo: ie, snap-confine.d doesn't exist and the profile fails to load
[16:04]  * jdstrand looks at the log more closely
[16:04] <mvo> jdstrand: ohhh, that sounds likely
[16:04] <mup> PR snapd#4516 opened: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516>
[16:05] <niemeyer> HEADS UP: I just "broke" spread on Travis.. it will fail to allocate machines if something gets pushed *right now* as I'm testing the machine allocation with the new feature (PR above)
[16:05] <jdstrand> I don't see anything in the logs about that, but that doesn't surprise me. I doubt the logs would have lxc debug output
[16:11] <jdstrand> mvo (cc zyga-ubuntu): there was talk last week about artful kernels breaking lxd in that profiles were not loaded with 4.13 kernels due to the container check in /lib/apparmor/profile-load
[16:11] <jdstrand> mvo: this autopkgtest is with a 4.13 kernel
[16:11] <zyga-ubuntu> jdstrand: ouch
[16:11] <jdstrand> mvo: let me get a url for you. I don't see that a bug was filed
[16:13] <jdstrand> mvo (cc zyga-ubuntu): https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:34
[16:14] <zyga-ubuntu> thank you
[16:14] <niemeyer> And it works.. wow.. nice to see 26 machines coming up at once.
[16:14] <mvo> jdstrand: thank you!
[16:15] <jdstrand> mvo (c zyga-ubuntu): ok, now I paid my penance for distracting you with the partial apparmor lxd bug I mentioned
[16:15] <jdstrand> hopefully this will help you zero in on it
[16:15] <zyga-ubuntu> niemeyer: it's live now?
[16:16] <zyga-ubuntu> niemeyer: do you have a KPI for the # of machines up? :D
[16:16] <zyga-ubuntu> (average/day maybe)
[16:16] <niemeyer> zyga-ubuntu: Sort of.. Travis should be working again, but new allocations won't work until I drop the 80 preallocated systems
[16:16] <zyga-ubuntu> k
[16:16] <niemeyer> Except for that one PR that I tuned
[16:16] <zyga-ubuntu> niemeyer: cool, I cannot wait to see how that performs, maybe we'll finally never run out of systems!
[16:17] <niemeyer> If this one works well, and by now I see no reason why it wouldn't, I will drop the preallocations and then everybody can enjoy faster tests
[16:17] <niemeyer> zyga-ubuntu: Keep an eye here then: https://travis-ci.org/snapcore/snapd/builds/331879604?utm_source=github_status&utm_medium=notification
[16:17] <niemeyer> zyga-ubuntu: All 26 systems are dynamically allocated 8GB machines
[16:17] <jdstrand> mvo: if you verify profile-load is actually the issue, I guess file a bug against apparmor with steps to reproduce and we can look at how to fix it
[16:18] <zyga-ubuntu> looking :)
[16:19] <niemeyer> zyga-ubuntu: Note how it took *9 seconds* between request to allocate the new machine and us having it
[16:19] <niemeyer> For all 26 of them.. so sweet
[16:21] <zyga-ubuntu> niemeyer: has something changed on linode? AFAIK last time you said that it doesn't matter if the machines are on or off, they cost the same; I understand that those are machines added and removed to the pool/account but is that a new feature on linode or just us making use of it?
[16:22] <niemeyer> zyga-ubuntu: It doesn't matter if the machine is on or off, but it does matter if you have the machine or not have it at all
[16:22] <mvo> zyga-ubuntu: so using the bind mount /snap /snap and unshare it approach, the mount table has now two entries for each snap :/
[16:22] <Chipaca> roundtripping with zip ftw
[16:22]  * Chipaca earned a break
[16:22] <niemeyer> zyga-ubuntu: In other providers (Amazon, GCE) you pay only when the machine is on, even if you have the whole metadata of the machine associated with it still (configuration, disks, etc)
[16:23] <zyga-ubuntu> mvo: ugh :/
[16:23] <zyga-ubuntu> mvo: did you remove the code in snap-confine that was doing stuff in that area?
[16:23] <zyga-ubuntu> niemeyer: aha, I see
[16:24] <mvo> zyga-ubuntu: I did but let me double check
[16:24] <niemeyer> zyga-ubuntu: Yeah, this is now dynamically creating the whole machine.. nothing exists before or after
[16:24] <zyga-ubuntu> niemeyer: also, no more out of disk space errors!
[16:24] <niemeyer> zyga-ubuntu: Hah, indeed.. :)
[16:35] <mup> PR snapd#4517 opened: data: add systemd unit that unshares /snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/4517>
[16:35] <niemeyer> It's looking good.. we just need to tune a bit the number of workers on each system
[16:35] <niemeyer> It hasn't finished, but we're down to only 6 machines
[16:35] <niemeyer> Which means 20 already terminated their job and went away
[16:36] <niemeyer> We're probably not making great use of the 8GB, either memory wise or CPU wise
[16:36] <niemeyer> It's probably better to split tasks further and take smaller machines
[16:37] <mvo> zyga-ubuntu: I pushed a first PR with the mount rshared thing, but its ugly due to the duplication afaict
[16:38] <zyga-ubuntu> mvo: duplication?
[16:38] <zyga-ubuntu> of those entries?
[16:40] <mvo> zyga-ubuntu: yes, everything under /snap it seems, I wonder if there is a different way to archive the --make-rshared. but I guess this only works on mounts not dirs?
[16:40] <zyga-ubuntu> mvo: it only works on mount entries, yes
[16:43] <mvo> zyga-ubuntu: ok, maybe we need to life with the dups then, I will see if a full snap run is happy
[16:43] <niemeyer> cachio: Is there a known Fedora error right now where the test hangs on "snap install"?
[16:44] <zyga-ubuntu> mvo: can you show me the code please?
[16:44] <mvo> zyga-ubuntu: sure, the PR is up
[16:44] <zyga-ubuntu> ah, let me refresh, thanks!
[16:44] <cachio> niemeyer, no
[16:44] <cachio> niemeyer, do you have any log?
[16:45] <niemeyer> cachio: https://travis-ci.org/snapcore/snapd/builds/331879604?utm_source=github_status&utm_medium=notification
[16:45] <niemeyer> cachio: Both workers hanging exactly in the same place for 10+ minutes, so not a coincidence
[16:45] <zyga-ubuntu> those fedora boxes
[16:45] <zyga-ubuntu> yeah
[16:46] <zyga-ubuntu> niemeyer: offtopic, I was thinking about my piles of abandonware lately and I was thinking about tagging it as such
[16:46] <zyga-ubuntu> niemeyer: and I quickly made this today: https://github.com/zyga/project-status-shields
[16:46] <mvo> zyga-ubuntu: adding the new units to the spec files now
[16:47] <cachio> niemeyer, I dont see any error on fedora
[16:47] <zyga-ubuntu> mvo: so this is the service unit
[16:47] <cachio> niemeyer, but are delayed
[16:48] <zyga-ubuntu> mvo: what happened to the snap.mount unit?
[16:48] <niemeyer> cachio: Well..? :)
[16:48] <cachio> niemeyer, first time I see that butI saw similar issues that I tried to address on the spread PR
[16:49] <cachio> niemeyer, https://github.com/snapcore/spread/pull/49
[16:49] <mup> PR spread#49: send keepalive packets every 10 seconds to avoid losing the connection <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/49>
[16:50] <zyga-ubuntu> mvo: reviewed
[16:50] <cachio> niemeyer, I have seen kill timeout reached the last weeks
[16:50] <cachio> niemeyer, not just for fedora
[16:51] <niemeyer> cachio: Again, an entire run looking perfect except for the two Fedora workers hanging exactly on the same place is not a coincidence
[16:51] <niemeyer> cachio: These are independent machines, started independently, running independently
[16:51] <kyrofa> kalikiana, are you still around?
[16:52] <kalikiana> hey kyrofa
[16:52] <kalikiana> Yes I am :-D
[16:52] <niemeyer> cachio: Have you seen where it's stuck?
[16:52] <kyrofa> kalikiana, late for you! I don't suppose you have 5 minutes to meet?
[16:52]  * zyga-ubuntu small supper & fresh tea
[16:52] <cachio> niemeyer, yes
[16:53] <kalikiana> kyrofa: Indeed. I'll grab my headphones. It's fine.
[16:53] <cachio> niemeyer, but the test seem to be ok
[16:53] <cachio> niemeyer, in fact it is the first time I see this error
[16:53] <kyrofa> kalikiana, about on-to by the way
[16:53] <cachio> niemeyer, perhaps it is something related to the store
[16:54] <kyrofa> Weekly?
[16:54] <kalikiana> kyrofa: Ack
[16:56] <niemeyer> cachio: Maybe, but what would justify getting stuck?
[16:57] <cachio> niemeyer, perhaps it is not stuck, spread is who is not getting the changes
[16:57] <cachio> niemeyer, I used to see that in my machine often
[16:57] <cachio> mainly when we use the quiet command
[16:58] <niemeyer> cachio: Not sure I understand what you mean by that
[16:58] <niemeyer> cachio: There's a "snap install" command there and no output
[16:59] <cachio> niemeyer, what I say is that it could be different thinks, either the snap command got stuck or spread did not received any other output but after a time snap install continued working
[17:00] <cachio> niemeyer, that's what I saw running from localhost in different situations
[17:00] <niemeyer> cachio: snap install should not hang silently like that
[17:01] <cachio> niemeyer, let me try to reproduce it here
[17:01] <niemeyer> cachio: If it does it's a bug.. if you are seeing this frequently, let's please  not ignore it
[17:01] <niemeyer> Anyway, really need to run.. o/
[17:01] <cachio> I created a PR in spread for those situations
[17:01] <cachio> niemeyer, but I am not sure if this case is affected by that
[17:02] <cachio> niemeyer, I'll try to reproduce it locally
[17:03] <cachio> niemeyer,  I am already runnig this test in order to see if I can reproduce it
[17:03] <jdstrand> mvo: fyi, jjohansen has been working on artful kernel for the autopkgtest failure. it seems like this will go to artful then the hwe kernel will get it in due course. in other words, if you can demonstrate that the test failure is due to the profiles not loading, then the bug will be fixed in due course
[17:04] <jdstrand> mvo: that came out a little weird-- he has a kernel to fix lxd, which I think will fix the autopkgtest failure (he isn't looking at the snappy autopkgtest failure)
[17:07] <cachio> mvo, the tests for beta are going really well
[17:08] <cachio> mvo, we are going to candidate soon
[17:10] <cachio> niemeyer, 2018-01-22 16:12:58 Cannot allocate linode:debian-9-64: no powered off servers in Linode account and no plan to allocate new machines
[17:10] <cachio> niemeyer, is being happening a change in linode?
[17:10] <cachio> all the machines failed because of this
[17:11] <cachio> https://travis-ci.org/snapcore/snapd/builds/331880011?utm_source=github_status&utm_medium=notification
[17:14]  * cachio lunch
[17:19] <kyrofa> elopio, did you ever manage to get the bot cranking out autopkgtests again?
[17:20] <elopio> kyrofa: no, had to do it locally. But haven't checked again since thursday.
[17:20] <kyrofa> elopio, looks like we have arm again
[17:20] <elopio> I'll check in a few.
[17:23] <kalikiana> Going to call it a day now
[17:23]  * kalikiana waves
[17:23] <zyga-ubuntu> kalikiana: o/
[17:24]  * zyga-ubuntu EODs and marks most of his projects as abandoned
[17:25] <kalikiana> zyga-ubuntu: is that a part of "live every day like it's your last day"? ;-)
[17:25] <zyga-ubuntu> kalikiana: haha
[17:25] <zyga-ubuntu> no, about some thinking I was doing
[17:25] <zyga-ubuntu> on ancinent projects
[17:25] <zyga-ubuntu> and on ...
[17:25] <zyga-ubuntu> https://github.com/zyga/project-status-shields
[17:28] <kyrofa> elopio, does that mean you tested snapcraft#1877 locally?
[17:28] <mup> PR snapcraft#1877: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>
[17:28] <mup> PR snapcraft#1878 closed: repo: use debian.arfile instead of dpkg-deb <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1878>
[17:30] <kalikiana> zyga-ubuntu: neat
[17:34] <elopio> kyrofa: yes.
[17:44] <kyrofa> elopio, with success? :P
[17:44] <kyrofa> I'll merge that PR if so
[17:49] <elopio> kyrofa: https://autopkgtest.ubuntu.com/request.cgi still gives 500, so no way to launch them.
[17:49] <kyrofa> cjwatson, do you know anything about that?
[17:49] <elopio> kyrofa: and yes, locally the tests ran. Not all of them passed, but that's not because of the refactor.
[17:49] <kyrofa> elopio, enough to give you confidence in the PR, though?
[17:50] <cjwatson> kyrofa: (a) it's intentional until Spectre mitigation is finished (b) in general please ask Laney about autopkgtest stuff, not me
[17:50] <elopio> kyrofa: yes, because travis is running all of them and passing.
[17:50] <kyrofa> cjwatson, excellent, thank you. Good to know who runs that stuff!
[18:14] <cachio> niemeyer, I could reproduce the error on fedora
[18:14] <cachio> this is the log with the error https://paste.ubuntu.com/26438961/
[18:20] <zyga-ubuntu>             return BadRequest("cannot %s %q: %v", inst.Action, inst.Snaps[0], err)
[18:20] <zyga-ubuntu> looks like inst.Snaps is empty
[18:21] <zyga-ubuntu> Chipaca: ^
[18:24] <cachio> zyga-ubuntu, did you see this error?
[18:25] <cachio> seem to be affecting fedora
[18:26] <zyga-ubuntu> cachio: I looked at your log, I didn't investigate more
[19:15] <mup> PR snapd#4518 opened: tests: fix for test interface-netlink-connector <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4518>
[19:23] <zyga-ubuntu> cachio: ^
[19:23] <zyga-ubuntu> I think you need to use ' ' rather than ""
[19:23] <zyga-ubuntu> it looks like invalid yaml
[19:23] <barry> hey folks, sorry to ping here but i have a quick question which i didn't seem to find answered on the forum.  what is the roadmap for official rhel7 support?  any thoughts on osx support?  i'm betting rhel6 is completely infeasible due to its age
[19:24] <zyga-ubuntu> barry: hey
[19:24] <barry> zyga-ubuntu: hi!
[19:24] <zyga-ubuntu> barry: I think rhel7 is "soon" but nobody has championed that, perhaps someone just needs to work together with Pharaoh_Atem who maintains the fedora packages
[19:25] <zyga-ubuntu> barry: osx support is something that is a different class of problem to solve (virtualization most likely)
[19:25] <cachio> zyga-ubuntu, yes
[19:25] <cachio> zyga-ubuntu, thanks
[19:25] <barry> zyga-ubuntu: that totally makes sense re: osx
[19:26] <zyga-ubuntu> barry: I think that if you want to see rhel happen soon you should get in touch with neal (Pharaoh_Atem) and see what's missing
[19:26] <zyga-ubuntu> I heard neal made some centos packages and I'm not on top of that anymore
[19:27] <zyga-ubuntu> barry: technically I think rhel is "just packagign"
[19:33] <cachio> zyga-ubuntu, should I add net-admin capability to the ssh-keys and ssh-public-keys interface?
[19:33] <cachio> zyga-ubuntu, I mean, to avoid connecting to network-control
[19:35] <zyga-ubuntu> cachio: I don't think so
[19:35] <zyga-ubuntu> those interfaces don't say "you are network admin"
[19:35] <zyga-ubuntu> cachio: perhaps just use a simpler test
[19:35] <zyga-ubuntu> cachio: don't run ssh
[19:35] <zyga-ubuntu> cachio: just read keys
[19:36] <cachio> zyga-ubuntu, ok, but the test is sharing ssh, that's why I using it
[19:36] <cachio> zyga-ubuntu, I mean, I am trying to cover the whole interface
[19:37] <zyga-ubuntu> cachio: yes but the interface doesn't promise you can run ssh
[19:37] <zyga-ubuntu> cachio: not sure if that's worth it
[19:39] <cachio> zyga-ubuntu, ok, so perhaps this line should not be included
[19:39] <cachio> in the interface /usr/bin/ssh ixr,
[19:40] <zyga-ubuntu> cachio: hmm, intersting,
[19:40] <zyga-ubuntu> jdstrand: ^ do you think this makes sense?
[19:40] <zyga-ubuntu> ssh-keys should not be about running ssh
[19:41] <zyga-ubuntu> jdstrand: or if it should it should really allow it
[19:42] <Pharaoh_Atem> zyga-ubuntu: there's a few other things, like making the software install integration work
[19:45] <zyga-ubuntu> Pharaoh_Atem: gnome-software?
[19:45] <zyga-ubuntu> Pharaoh_Atem: what's missing there?
[19:45] <zyga-ubuntu> Pharaoh_Atem: I think getting basic CLI package out there would help
[19:51] <jdstrand> cachio: please don't add network-control for testing ssh
[19:52] <barry> zyga-ubuntu: okay thanks
[19:52] <jdstrand> cachio: when I tested the interface, I did not need network-control
[19:52] <jdstrand> cachio: how are you using ssh?
[19:53] <cachio> jdstrand, https://github.com/snapcore/snapd/pull/4512/files
[19:53] <mup> PR #4512: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4512>
[19:53] <jdstrand> cachio: the interfacec doesn't claim to support everything the ssh command can do
[19:55] <cachio> jdstrand, so, which is the idea about the ssh command for that interface?
[19:55] <cachio> jdstrand, to do what?
[19:55] <cachio> jdstrand, so I can update the test
[20:00] <jdstrand> cachio: "ssh-public-keys: I was unable to determine a use for this interface" from https://github.com/snapcore/snapd/pull/4100
[20:00] <mup> PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4100>
[20:01] <jdstrand> cachio: people wanted that interface to only allow the public keys, so that is what it does. probably the best test is ssh -V and testing if can access the .pub file
[20:02] <cachio> jdstrand, ok
[20:02] <cachio> jdstrand, what about the ssh-keys?
[20:02] <cachio> jdstrand, should I test the ssh command connection?
[20:03] <cachio> jdstrand, or just the access to the keys?
[20:03] <jdstrand> cachio: "ssh-keys: I was able to login to a remote server"
[20:03] <cachio> jdstrand, I tried that and I couldn't, let me try again
[20:03] <jdstrand> cachio: if you can do it without network-control, then I say go for it. I don't know why it is asking for that...
[20:04] <jdstrand> cachio: if you can't, the ssh -V and testing if can access .pub and private keys should be enough
[20:04] <cachio> jdstrand, ok
[20:11] <Pharaoh_Atem> zyga-ubuntu: g-s is one bit, but not really the important one
[20:11] <Pharaoh_Atem> the important one is making sure that the selinux policies apply correctly
[20:12] <zyga-ubuntu> Pharaoh_Atem: and what is missing there?
[20:14] <Pharaoh_Atem> zyga-ubuntu: well, I still need to backport a bunch of patches for ensuring the paths work correctly
[20:14] <Pharaoh_Atem> basically, I need to retry with 2.30 / 2.31
[20:14] <Pharaoh_Atem> which I'm preparing for Fedora right now
[20:16] <zyga-ubuntu> I see, thank you!
[20:22] <cachio> jdstrand, permission denied
[20:22] <cachio> [  497.497832] audit: type=1400 audit(1516652364.412:57): apparmor="DENIED" operation="create" profile="snap.test-snapd-ssh-keys.ssh" pid=19379 comm="ssh" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
[20:23] <cachio> jdstrand, this is without network-control
[20:23] <cachio> for the ssh-keys interface
[20:34] <jdstrand> cachio: sure, you will definitely need 'network'
[20:34] <roadmr> elopio: hi! hey do you know who mans the snapcrafters e-mail address?
[20:35] <elopio> roadmr: I would guess Alan and Martin.
[20:35] <roadmr> thanks elopio ! (I wrote there to double-check a couple of snap transfers, just wanted to check if it's not a black hole heh)
[20:36] <cachio> jdstrand, so, what do you prefer for the test, add network or just check keys? for the ssh-keys interface
[20:57] <lundmar> Hi. I need to stage libqt5charts5 but this package is not available in the official Xenial repo. I've found an unoffical .deb package I want to use. Is there a plugin that can install remote .deb packages by URL?
[21:04] <jdstrand> cachio: I don't have a preference. I think it is sufficient to only check check the keys
[21:04] <cachio> jdstrand, ok, tx
[21:05] <jdstrand> roadmr: istr noise][ reporting at the sprint that snap v1 is gone. does that mean I can finally remove click and snap v1 from the review tools?
[21:06] <noise][> jdstrand - yes!
[21:07] <roadmr> jdstrand: \o/ zorch em
[21:25] <jdstrand> ok thanks
[21:37] <mup> PR snapd#4518 closed: tests: fix for test interface-netlink-connector <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4518>