diddledangunix: yes00:38
gunixhey diddledan07:04
gunixif somebody that can explain snapd to me is online, please ping me07:04
gunixi do not understand how this system works and it amazes me that stuff like LXD works on archlinux via snap07:04
mborzeckimvo: morning07:19
mvogood morning mborzecki07:25
mupPR 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:26
mvo4495 needs a second review07:37
mupPR 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:41
mvo4473 also needs a second review :)07:44
mupPR 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>07:44
kalikianagood morning08:03
pstolowskihey o/08:07
zyga-ubuntugood morning :)08:08
mvogood morning kalikiana pstolowski and zyga-ubuntu !08:09
mvohappy monday!08:09
kozamvo, hey, what is the forecast on the strace support for snaps?08:09
mvokoza: if somone reviews my PR at least basic support will land for 2.3108:09
mborzeckizyga-ubuntu: pstolowski: kalikiana: morning guys08:09
mvokoza: we want support for custom options as well, there is a PR for that too08:10
mborzeckikoza: hey08:10
mvo4473 is the strace pr that needs a second review :)08:10
mvokoza: there is also your motd PR that we need to land for 2.31, right?08:10
kozamvo, but like days, weeks, months? :)08:10
kozamvo, would be nice, Thibaut commented vi email, Ill change the PR accordingly today08:11
mvokoza: 2.31 is scheduled for beta this week and stable in ~4 weeks08:11
mvokoza: ta08:11
kozamvo, nice!08:11
mvokoza: yeah, we are quite excited about strace too, its a popular feature08:11
mborzeckimvo: 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
mupBug #1744433: 'snap refresh' is silent about changes in progress <snapd:Triaged> <https://launchpad.net/bugs/1744433>08:14
mvomborzecki: aha, you have a pr already?08:14
mborzeckimvo: no :) trying to figure out if there's a nicer way08:15
mborzeckimvo: i can open a pr with this change though08:15
mvomborzecki: what is your current diff, could you pastebin this please?08:16
mborzeckimvo: https://paste.ubuntu.com/26435923/08:16
mborzeckisorry, paste the bug link twice in the previous message08:16
mvomborzecki: 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:18
mborzeckimvo: the error mesage on `snap refresh vlc` would be friendly, instad of changes you'd get 'auto-refresh' and so on08:19
zyga-ubuntumvo: I think I should update 2.30 in opensuse today08:20
mborzeckithe rest i have not figured out yet08:20
zyga-ubuntumvo: and we have some bug reports on fedora front to inspect08:20
mvomborzecki: aha, ok - yeah, making this friendlier is definitely nice08:20
mvozyga-ubuntu: +1 for updates08:20
mvozyga-ubuntu: where do the fedora bugs come from? their bugtracker?08:21
zyga-ubuntumvo: yes, on bugzilla08:26
mvozyga-ubuntu: ok, how bad do they look?08:26
mvouhh, ok08:27
mvoI wonder why we did not caught this in testing :(08:27
zyga-ubuntuyes, it's surprising to me as well08:27
zyga-ubuntuI'll be back soon, just getting some quick food08:35
mborzeckizyga-ubuntu: looks like something we fixed recently08:35
mupPR snapd#4513 closed: dirs: fix snap mount dir on Manjaro <Created by mati865> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4513>08:57
mupPR snapd#4514 opened: overlord/snapstate: record the 'kind' of conflicting change <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4514>09:11
Chipacawhoa, quickest reviewers in the west09:14
mborzeckiChipaca: morning09:15
Chipacamborzecki: morning :-)09:16
Chipacado we have a pedronis again this week, or is that next week?09:20
mborzeckiChipaca: i think he mentioned he'd be on vacation until 29th09:21
Chipacamborzecki: I laud your detailed memory09:22
mborzeckihaha, yeah, my wife would disagree :)09:22
mvolol@ mborzecki09:22
mvohey Chipaca good morning and happy monday!09:23
Chipacamborzecki: she holds you to a higher standard :-D09:23
Chipacamvo: good morning! monday's looking good indeed09:23
zyga-ubuntuChipaca: hey09:30
zyga-ubuntuChipaca: I added i38609:30
zyga-ubuntuChipaca: I didn't do accounts yet but ping me if you want to play and I'll do that quickly09:31
Chipacazyga-ubuntu: awesome. I don't think I need it right now, but very good to know.09:31
zyga-ubuntuand I will change the power adapter for the dragonboard so that it can be on 24/709:31
zyga-ubuntubut that's in the evening as it's not a priority for anyone today09:31
zyga-ubuntumborzecki: 4509 has another review09:38
mborzeckizyga-ubuntu: thanks09:38
zyga-ubuntumvo: any news on bolt, ppc and other misery?09:38
mvozyga-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 ppc09:41
mborzeckiwonder when the new 'working' microcode will be released09:42
mvomborzecki: you are not alone here09:43
mvomborzecki: btw, are you looking into the "snap refresh" output as well (if there is another refresh alreaady running)?09:43
mborzeckimvo: no, i've put is aside for now, i ended up going in circles09:44
zyga-ubuntumborzecki: "working" or working?09:45
mvomborzecki: ok, no worries, just wanted to check09:45
mvomborzecki: I was considering looking but had no time for it yet :/09:45
mborzeckimvo: go ahead, i'm poking around https://bugs.launchpad.net/snappy/+bug/1741486 now09:46
mupBug #1741486: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>09:46
mvomborzecki: aha, nice! thats a good one too09:47
mborzeckibtw. can we close https://bugs.launchpad.net/snappy/+bug/1743504 ? this was the unlucky fellow who basically had his filesystem bail out on him09:47
mupBug #1743504: Ubuntu 16.04 snapd service not working <Snappy:New> <https://launchpad.net/bugs/1743504>09:47
mvomborzecki: looking09:51
mvomborzecki: I closed it now09:53
mborzeckimvo: great, thanks09:53
mupBug #1743504 changed: Ubuntu 16.04 snapd service not working <Snappy:Invalid> <https://launchpad.net/bugs/1743504>09:53
mvomborzecki: thank you! how are we actually doing with "New" bugs? how many are not confirmed/triaged currently?09:53
Chipaca(a) wooo, baby steps progress is now tangible09:58
Chipaca(b) /me -> physio09:58
mvozyga-ubuntu: silly question, do we bundle on opensuse?09:59
zyga-ubuntumvo: yes, we do10:00
mvozyga-ubuntu: excellent10:00
zyga-ubuntumvo: (it's legan now)10:00
mvozyga-ubuntu: I fixed bolt on fedora by sed things back to boltdb/bolt10:01
mvozyga-ubuntu: that means we just need to fix debian, I can make a patch, just need to find the upstream repo10:01
mvozyga-ubuntu: eh, packaging repo10:01
mvozyga-ubuntu: we really should import their packaging to make this simpler. anyway, found it and doing a patch10:03
* Chipaca actually goes10:10
* kalikiana moooore coffeeeee10:13
jamesb192zyga-ubuntu: working on a package for *ntoo and wondering what important stuff I am missing. manifest -> https://paste.pound-python.org/show/kHgFz1bglDwHLo89K5ZK/10:17
zyga-ubuntujamesb192: looking10:19
zyga-ubuntukalikiana: you are reading my mind!10:19
zyga-ubuntujamesb192: snap-confine is usually in /usr/lib/snapd/snap-confine or /usr/libexec/snapd/snap-confine10:20
zyga-ubuntujamesb192: same with a host of other binaries (only snap and snapctl are on path)10:20
zyga-ubuntujamesb192: you can drop the following systemd units: autoimport, core-fixup10:20
zyga-ubuntuand the corresponding timer10:20
zyga-ubuntujamesb192: you can drop the snapd autoimport servic10:21
zyga-ubuntuthis thing: -rw-r--r-- root/root       157 2018-01-20 08:53 ./lib/udev/rules.d/66-snapd-autoimport.rules10:21
zyga-ubuntuthe udev rules10:21
zyga-ubuntuthose things are all files relevant for core but irrelevant elsewhere10:21
zyga-ubuntucore == not classic systems10:21
zyga-ubuntuthe /opt/snapd location is curious, what made you put all those files there/10:21
kalikianazyga-ubuntu: you're welcome :-D10:21
jamesb192temporary holding area until I do something useful.10:22
zyga-ubuntuok, I think you will have some issues still but this looks like a good starting point, I may have missed something10:24
zyga-ubuntuI would suggest to look at debian/ubuntu/fedora packages and see if there are any files they ship that you do not10:24
zyga-ubuntuand always exclude the files I mentioned above10:24
zyga-ubuntu(they are at best no-ops on normal systems)10:24
zyga-ubuntuthe end goal is to have a system that can be spread tested and that would pass our integration tests10:24
zyga-ubuntubut for now just iterate this way and run snaps on your system and see what breaks10:25
jamesb192Okay. I will do that. thank you.10:26
zyga-ubuntujamesb192: please send update reports to the forum, I'm sure it will have wider exposure there10:27
zyga-ubuntuI can respond there as well10:27
zyga-ubuntu4505 needs a 2nd review10:33
zyga-ubuntunot 510:33
zyga-ubuntumvo: 4505 updated per your comments10:48
mupPR 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:52
mvozyga-ubuntu: ta, one quick comment added10:58
zyga-ubuntumvo: which code reads "it" (I assume group/user name)11:00
zyga-ubuntumvo: the switch you linked to explicitly maps specific values11:00
mvozyga-ubuntu: let me double check, maybe github is playing tricks on me11:01
zyga-ubuntumvo: the code in snap-update-ns did do name lookups AFAIR but I'm not sure it has to still11:01
zyga-ubuntumvo: and that code is more generic as it applies to other mechanisms11:01
zyga-ubuntumvo: this one only does layout language11:01
mvozyga-ubuntu: aha, you are right, I was misreading the code11:02
mvozyga-ubuntu: sorry11:02
zyga-ubuntumvo: no worries, I wanted to check if I missed something :) thank you for askin!11:02
zyga-ubuntujoc: gentle ping about #432611:46
mupPR #4326: interfaces/builtin: blacklist zigbee dongle <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4326>11:46
zyga-ubuntuI think you know more about that than we do11:47
zyga-ubuntumborzecki: what's the status of 4285?11:50
mborzeckizyga-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 directory11:51
zyga-ubuntumborzecki: does it make sense to unconflict and merge this11:55
zyga-ubuntuopensuse 42.2 will be EOLed this week11:56
zyga-ubuntuwe should switch to 42.311:56
mborzeckizyga-ubuntu: i'll merge master and push it for a travis run and we'll see how much has changed11:59
* kalikiana taking a break12:01
gunixhey guys12:18
gunixdo snaps run in containers?12:18
zyga-ubuntugunix: hey12:18
zyga-ubuntugunix: it depends12:18
zyga-ubuntugunix: snaps are known to run (with some known issues) on recent versions of lxd when running on top of ubuntu12:18
gunixzyga-ubuntu: i just tried LXD on archlinux ... install via AUR is not working, but install via snapd is working. and this confuses me12:19
gunixzyga-ubuntu: and that made me ask my self how snapd is actually working12:19
zyga-ubuntugunix: I think mborzecki will be the best to know this (he runs arch)12:21
zyga-ubuntugunix: I can happily respond to detains about what we need from the system and how containers may break things12:21
gunixzyga-ubuntu: i am curious how snap is running system-agnostic apps12:22
gunixi don't understand how that is possible12:22
gunixfor example, LXD needs to create a network bridge, so it needs to create specific files on the system12:22
gunixfiles which normally are not distro-agnostic12:22
gunixbut still, it seems to work12:22
gunixi am can't understand how this is possible and i didn't find documentation about this online12:23
zyga-ubuntumvo: 4399 needs a review, it's very nice and could be a 2.31 item12:24
zyga-ubuntugunix: I cannot comment about LXD12:24
zyga-ubuntugunix: perhaps stgraber can answer that12:24
mborzeckigunix: does the network work inside the containers?12:26
gunixmborzecki: yes, that's the confusing part. if you install LXC from the archlinux repos, you still have to configure networking12:27
gunixmborzecki: if you install LXD from aur, you can't create containers because it can't map the IDs12:27
gunixmborzecki: however, if you install LXD from snap (and snap gets installed from aur), you just do lxd init and everything works after that12:28
gunixthis really looks like dark magic12:28
gunixoh 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:30
gunixi guess you normally get people that ask why it doesn't work. not people who ask why it works. :D12:31
zyga-ubuntumborzecki: can you please look at 432612:38
mborzeckigunix: the USERNS thing is already fix in arch kernel12:38
mborzeckizyga-ubuntu: uhh vendor reused vid/pid12:39
mborzeckiand here i thought i'd never have to see such things again12:40
zyga-ubuntuserial ports, no vid/pid, mess, usb, reuse vid/pid becaue saves 0.01$12:40
mborzeckiehehe, wonder how many devices are there with default ftdi vid/pid ;P12:40
zyga-ubuntumvo: 4140 needs someone to decide12:41
kalikianagunix: id mapping works differently because the snap sees the core's filesystem rather than the host's12:44
gunixmborzecki: 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 root12:47
mborzeckigunix: which option? CONFIG_USER_NS?12:48
gunixmborzecki: https://wiki.archlinux.org/index.php/Linux_Containers12:48
gunixEnable support to run unprivileged containers (optional)12:49
gunixi don't know which of them because i didn't get it to work yet, i will go through all steps later today12:49
mborzeckigunix: 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 fedora12:50
kalikianagunix: note that the lxd snap always runs as root12:51
kalikiananot as the lxd user12:51
zyga-ubuntumvo: can you please look at https://github.com/snapcore/snapd/pull/3963 (aka oldest PR)12:54
mupPR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>12:54
gunixkalikiana: it still has to fix the user mapping problem12:54
gunix*the id mapping12:54
kalikianagunix: did you read my previous message?12:54
gunixsorry, got only the one that it runs on root. reading now12:55
kalikianano worries :-)12:55
gunixkalikiana: which are the core/host filesystems?12:56
kalikianagunix: from the point of view of a snap, / comes from the core snap12:56
kalikiananot the actual / you'd expect12:57
gunixkalikiana: so all packages get installed in its chroot?12:57
kalikianagunix: 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 contents12:58
gunixok. thank you ... and in the users homefolder are only settings regarding the apps? because he also gets a .snap folder12:59
niemeyerOMW to the standup..13:00
zyga-ubuntuhey niemeyer13:01
kalikianagunix: 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:01
gunixyou mean everything outside of /home/gunix/snap is not accessible by the application running as a snap?13:02
gunixkalikiana: ^13:02
kalikianagunix: yeah. a strict snap couldn't read, say, /home/gunix/mydocument.txt by default13:07
gunixkalikiana: 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:07
kalikianagunix: Have a look at `snap interfaces chromium`. You'll notice it has ":home" in the list13:08
zyga-ubuntugunix: also try "snap interface home"13:09
gunixkalikiana: 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 rush13:09
kalikianagunix: :home                    ag-mcphail,chromium,corebird,dekko,gedit,gimp,handbrake-jz,libreoffice,magic-device-tool,midori,nethack,rg,spotify,telegram-sergiusens,vlc13:11
gunixkalikiana: so chromium wants to use libreoffice and vlc?13:12
kalikianagunix: 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
gunixkalikiana: 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:14
kalikianagunix: Yes. This wouldn't show snaps that aren't installed.13:15
gunixkalikiana: do snaps run as containers? because i don't understand how gnome3 GUI apps would run in a container13:15
zyga-ubuntugunix: no13:16
zyga-ubuntugunix: and maybe13:16
gunixzyga-ubuntu: please explain :D13:16
zyga-ubuntugunix: have a look at this https://new.zygoon.pl/post/poking-holes-in-cheese/13:16
gunixzyga-ubuntu: haha "a look"13:17
gunixi will read it today or tomorrow13:17
gunixi 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 should13:18
gunixi 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:19
jdstrandgreyback: oh right, forgot about that. in that snap, just do: something like:13:23
jdstrandname: foo13:23
zyga-ubuntujdstrand: good morning!13:24
jdstrand  x11-service:13:24
jdstrand    interface: x1113:24
greybackjdstrand: already figured out, with zyga's help13:24
jdstrand  ...13:24
jdstrandok, cool13:24
jdstrandhey zyga-ubuntu :)13:24
jdstrandcachio: reading 'man capabilities', it makes sense to add that cap to the policy13:24
greybackjdstrand: and it is working ok. Am trying to tighten up the interfaces and figure out /dev/shm usage13:25
jdstrandcachio: feel free to send up a PR and ping me for review13:25
* kalikiana going to go for lunch in a bit13:25
jdstrandgreyback: awesome! sorry again for the slow response. I'm no longer sprinting13:25
greybackjdstrand: no worries at all13:25
* greyback thinks he sees the finishing line at long last13:25
* kalikiana read that as "fishing line" and wondered if that was sarcasm13:35
* pstolowski lunch14:03
cachiojdstrand, ok, I'll try that, thanks14:06
diddledanzyga-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:21
seb128mvo, is bug #1744584 might be worth commenting on if you have any recommendation of what snaps folder need backuping or not?14:23
mupBug #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-ubuntudiddledan: ah, perhaps14:23
zyga-ubuntugunix: ^14:23
zyga-ubuntugunix: which question was it?14:23
gunixwhen I run a snap on my system, is it being executed inside a container to isolate it?14:25
gunixdiddledan: zyga-ubuntu ^14:25
mvoseb128: thanks, looking14:25
seb128mvo, thanks :)14:25
zyga-ubuntugunix: aha, I see14:25
zyga-ubuntugunix: so my answer stands, it depends on how you understand containers; I'm inclined to say "no" more than yes14:26
zyga-ubuntugunix: because most of the security confinement comes from LSM (apparmor)14:26
zyga-ubuntugunix: though we also use some of the technology used by what people agree are containers14:26
gunixzyga-ubuntu: can't be. i am running archlinux14:26
zyga-ubuntugunix: hence the fuzzy answer14:26
zyga-ubuntugunix: right, we use a combination of things14:27
diddledanthere is a teeny bit of container-tech used, such as mount-namespaces14:27
zyga-ubuntugunix: and container is a marketing term more than a technical term today14:27
zyga-ubuntugunix: but also spiritually, we try to integrate the app with the host14:27
zyga-ubuntugunix: more than any other "containers" do14:27
* diddledan meditates14:27
gunixzyga-ubuntu: with container, i mean NEWNS flag within the clone() function.14:27
diddledanI'm spiritual14:27
gunixzyga-ubuntu: was that a marketing explanation too? :D14:28
zyga-ubuntugunix: yes, we do that14:28
zyga-ubuntugunix: that's the only thing that we do that is clearly a container tech14:28
* zyga-ubuntu gets more tea14:28
gunixzyga-ubuntu: is that default for all snaps?14:29
Chipacagetting more tea _should_ be the default for all apps14:31
* Chipaca gets more tea too14:31
diddledanI'm more a cola addict :-p14:31
diddledanpepsi max ftw (no sugar)14:31
zyga-ubuntugunix: yes, all snaps use that by default; the only exception are snaps that you install with --classic14:31
zyga-ubuntugunix: those are, like classic packages, installed directly on your system14:32
zyga-ubuntumvo: 4507 is green and has two +1s14:38
cachiojdstrand, you mean net_admin capability?14:47
cachiojdstrand, https://paste.ubuntu.com/26437642/14:49
cachioI am using this, I already modified the capability14:50
Chipacaam I missing a trick, or is it not possible to stream a file into a tar with archive/tar?14:56
Chipaca(the key being I don't know the size of the file beforehand)14:57
diddledanChipaca: you should be able to do something equivalent to `cat file | tar cf mytarfile.tar`14:57
diddledanunless you're talking about golang in which case I've done that before on an unrelated project14:58
Chipacadiddledan: golang yes14:58
* Chipaca asks the same question over in #go-nuts because he feels it's nuts that he can't :-)14:59
elopioGood morning!14:59
diddledanmy 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.go15:00
mborzeckiChipaca: iirc you need to know the size upfront so that when parsing t you can skip that much + any padding15:00
mupPR 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
cachiojdstrand, 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.go15:05
cachiojdstrand, do you think it needs any other change?15:06
=== jkridner_ is now known as jkridner
mupPR snapd#4495 closed: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4495>15:10
gunixI added snap as an installation method for LXD on the archlinux wiki: https://wiki.archlinux.org/index.php/LXD15:24
zyga-ubuntumvo: can I close core#67 now?15:25
mupPR 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
gunixsince snap works flawlessly, it deserves this15:25
zyga-ubuntugunix: thank you~!15:25
mvozyga-ubuntu: so to fix the mount unit ordering issue, what kind of test do we need?15:25
mvozyga-ubuntu: is a reboot inside the lxd container the rightonw?15:25
mvoright one?15:25
zyga-ubuntumvo: I think I had a branch with a test15:25
mupPR 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:25
zyga-ubuntumvo: just remove a snap :)15:26
mvozyga-ubuntu: inside lxd? ok15:26
zyga-ubuntumvo: yes15:26
zyga-ubuntumvo: is core#69 something that can be closed now?15:26
mupPR 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:26
mvozyga-ubuntu: yes, good point15:27
jdstrandcachio: your paste from before was for audit_read: https://paste.ubuntu.com/26412541/15:27
mupPR 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:27
zyga-ubuntuthank you!15:28
cachiojdstrand, let me create a PR with the test so you can see what I am doing15:29
kalikianagunix: niiiice :-D15:29
cachiojdstrand, #451515:30
mupPR #4515: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4515>15:30
jdstrandcachio: 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
mupPR snapd#4515 opened: tests: new spread test for netlink-audit interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4515>15:30
jdstrandcachio: since net_admin is needed for setting up a multicast socket, you probably will need both15:31
mborzeckiChipaca: have you found a way to deal with the tar issue?15:31
Chipacamborzecki: "use archive/zip instead"15:31
Chipacathis is exactly the sort of silly issue i wanted to root out by this approach to it all, so \o/15:31
mborzeckiChipaca: glad that it works with zip :)15:32
Chipacamborzecki: we'll see :-)15:32
Chipacai like your optimism though15:32
jdstrandcachio: reading that PR it isn't clear that NETLINK_AUDIT is a multicast socket15:33
mborzeckiChipaca: hmm looking at https://golang.org/src/archive/zip/writer.go#L224 looks like zip writes the header upfront too15:34
cachiojdstrand, what do you suggest to fix it?15:34
Chipacamborzecki: but AFAICT it doesn't require the size at that point15:36
Chipacamborzecki: note how close() updates the header15:37
mborzeckiChipaca: yeah, it seems to update the count on the flly (next to crc32)15:37
mvozyga-ubuntu: any idea about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1744738 ? i.e. inside lxd it seems like apparmor is not confined anymore15:38
mupBug #1744738: snapd 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
mvozyga-ubuntu: also slightly sad, but I only get 20kb for the lxd test so my ordering fix can take forever to verify15:38
zyga-ubuntumvo: looking15:39
mborzeckiChipaca: 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 my15:39
jdstrandcachio: I think that the capabilities man page implies it is multicast. I commented in the pr15:40
jdstrandmvo, zyga-ubuntu: I may have an idea on that15:41
mborzeckiChipaca: 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 :P15:41
mvojdstrand: oh, tell us more please15:41
cachiojdstrand, great, thanks15:42
jdstrandmvo: I haven't read that bug very closely, but serguisens reported an issue to me15:42
zyga-ubuntumvo: can you please cherry pick the unit test from #425815:42
mupPR #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-ubuntumvo: as for the lxd issue you just linked to15:42
jdstrandmvo: on kernels that have partial apparmor support, the apparmor policy is set to the classic template15:42
zyga-ubuntumvo: not sure yet15:42
Chipacamborzecki: I may or may not have a io.TeeReader of a io.TeeReader of a member of an archive and a hasher, and a sizer15:43
zyga-ubuntujdstrand: ah, nice catch!15:43
jdstrandmvo: this gives a glob rule like /** pix,15:43
Chipacamborzecki: dec := json.NewDecoder(io.TeeReader(metaReader, io.MultiWriter(metaHashChecker, &sz)))15:43
Chipacamborzecki: also that ^15:43
jdstrandmvo: whereas the lxd-support template has /usr/sbin/aa-exec ux, (or similar)15:43
mborzeckiChipaca: hahah15:44
jdstrandmvo: 'ix' ends up scrubbing the environment (it shouldn't, that is an apparmor bug related to limitations in the current implementation)15:44
jdstrandmvo: and 'ux' doesn't15:44
niemeyerNewly allocated one machine roundtrips a dummy run in almost exactly one minute15:44
niemeyeron spread+Linode, that is15:44
niemeyerSurprisingly good15:45
mvojdstrand: hm, why do we start to see this now?15:45
mvojdstrand: thanks for explaining that :)15:45
mvojdstrand: I wonder a) why now b) what can we do about it :)15:45
niemeyerThat includes allocation of the brand new instance, image creation, trivial task run, and machine removal15:45
jdstrandmvo: what I've seen is that on those kernels the 'lxd init' command can't find the required libraries because LD_LIBRARY_PATH is cleared15:45
jdstrandmvo: 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 reviews15:47
mvojdstrand: great, thank you! can I paste this into the open bug?15:48
jdstrandmvo: 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 support15:48
jdstrandmvo: well, no, I'm only wondering if that bug is involved15:49
mvojdstrand: aha, ok, sorry I misunderstood15:49
mvojdstrand: yes, this is all full confinement15:49
jdstrand+ lxd init --auto15:49
jdstrandLXD has been successfully configured.15:49
jdstrandthat suggests that it isn't it...15:49
jdstrandso, sorry for the noise, but fyi there is a problem with lxd snap and partial apparmor support :)15:50
mvojdstrand: heh, no worries and thanks, good (or bad) to know about this problem15:51
jdstrandmvo, 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 correctly15:55
mvojdstrand: the only change we did for was http://launchpadlibrarian.net/347640641/snapd_2.29.4.1_2.29.4.2.diff.gz15:57
zyga-ubuntumvo: it feels like something else has changed under us15:59
jdstrandmvo: it is a to regression? the bug talks about 2.28.515:59
mvojdstrand: indeed, 2.28.5 ->
mvozyga-ubuntu: same here16:00
jdstrandit could be that the kernel changed or lxd. someone should try to reproduce manually and run snap-confine in debug mode16:00
jdstrandmvo: (the diff you gave was to
mvohm, is fine with lxd for linux-meta/ on 2017-12-22 so is probably not it16:01
jdstrandistr a bug about lxd not detecting apparmor correctly16:01
* jdstrand tries to find16:01
jdstrandmvo: I wonder if it is a variation on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1743079?16:04
mupBug #1743079: apparmor exit code 123 <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1743079>16:04
jdstrandmvo: ie, snap-confine.d doesn't exist and the profile fails to load16:04
* jdstrand looks at the log more closely16:04
mvojdstrand: ohhh, that sounds likely16:04
mupPR snapd#4516 opened: spread: setup machine creation on Linode <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4516>16:04
niemeyerHEADS 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
jdstrandI don't see anything in the logs about that, but that doesn't surprise me. I doubt the logs would have lxc debug output16:05
jdstrandmvo (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-load16:11
jdstrandmvo: this autopkgtest is with a 4.13 kernel16:11
zyga-ubuntujdstrand: ouch16:11
jdstrandmvo: let me get a url for you. I don't see that a bug was filed16:11
jdstrandmvo (cc zyga-ubuntu): https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:3416:13
zyga-ubuntuthank you16:14
niemeyerAnd it works.. wow.. nice to see 26 machines coming up at once.16:14
mvojdstrand: thank you!16:14
jdstrandmvo (c zyga-ubuntu): ok, now I paid my penance for distracting you with the partial apparmor lxd bug I mentioned16:15
jdstrandhopefully this will help you zero in on it16:15
zyga-ubuntuniemeyer: it's live now?16:15
zyga-ubuntuniemeyer: do you have a KPI for the # of machines up? :D16:16
zyga-ubuntu(average/day maybe)16:16
niemeyerzyga-ubuntu: Sort of.. Travis should be working again, but new allocations won't work until I drop the 80 preallocated systems16:16
niemeyerExcept for that one PR that I tuned16:16
zyga-ubuntuniemeyer: cool, I cannot wait to see how that performs, maybe we'll finally never run out of systems!16:16
niemeyerIf 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 tests16:17
niemeyerzyga-ubuntu: Keep an eye here then: https://travis-ci.org/snapcore/snapd/builds/331879604?utm_source=github_status&utm_medium=notification16:17
niemeyerzyga-ubuntu: All 26 systems are dynamically allocated 8GB machines16:17
jdstrandmvo: 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 it16:17
zyga-ubuntulooking :)16:18
niemeyerzyga-ubuntu: Note how it took *9 seconds* between request to allocate the new machine and us having it16:19
niemeyerFor all 26 of them.. so sweet16:19
zyga-ubuntuniemeyer: 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:21
niemeyerzyga-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 all16:22
mvozyga-ubuntu: so using the bind mount /snap /snap and unshare it approach, the mount table has now two entries for each snap :/16:22
Chipacaroundtripping with zip ftw16:22
* Chipaca earned a break16:22
niemeyerzyga-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:22
zyga-ubuntumvo: ugh :/16:23
zyga-ubuntumvo: did you remove the code in snap-confine that was doing stuff in that area?16:23
zyga-ubuntuniemeyer: aha, I see16:23
mvozyga-ubuntu: I did but let me double check16:24
niemeyerzyga-ubuntu: Yeah, this is now dynamically creating the whole machine.. nothing exists before or after16:24
zyga-ubuntuniemeyer: also, no more out of disk space errors!16:24
niemeyerzyga-ubuntu: Hah, indeed.. :)16:24
mupPR snapd#4517 opened: data: add systemd unit that unshares /snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/4517>16:35
niemeyerIt's looking good.. we just need to tune a bit the number of workers on each system16:35
niemeyerIt hasn't finished, but we're down to only 6 machines16:35
niemeyerWhich means 20 already terminated their job and went away16:35
niemeyerWe're probably not making great use of the 8GB, either memory wise or CPU wise16:36
niemeyerIt's probably better to split tasks further and take smaller machines16:36
mvozyga-ubuntu: I pushed a first PR with the mount rshared thing, but its ugly due to the duplication afaict16:37
zyga-ubuntumvo: duplication?16:38
zyga-ubuntuof those entries?16:38
mvozyga-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-ubuntumvo: it only works on mount entries, yes16:40
mvozyga-ubuntu: ok, maybe we need to life with the dups then, I will see if a full snap run is happy16:43
niemeyercachio: Is there a known Fedora error right now where the test hangs on "snap install"?16:43
zyga-ubuntumvo: can you show me the code please?16:44
mvozyga-ubuntu: sure, the PR is up16:44
zyga-ubuntuah, let me refresh, thanks!16:44
cachioniemeyer, no16:44
cachioniemeyer, do you have any log?16:44
niemeyercachio: https://travis-ci.org/snapcore/snapd/builds/331879604?utm_source=github_status&utm_medium=notification16:45
niemeyercachio: Both workers hanging exactly in the same place for 10+ minutes, so not a coincidence16:45
zyga-ubuntuthose fedora boxes16:45
zyga-ubuntuniemeyer: offtopic, I was thinking about my piles of abandonware lately and I was thinking about tagging it as such16:46
zyga-ubuntuniemeyer: and I quickly made this today: https://github.com/zyga/project-status-shields16:46
mvozyga-ubuntu: adding the new units to the spec files now16:46
cachioniemeyer, I dont see any error on fedora16:47
zyga-ubuntumvo: so this is the service unit16:47
cachioniemeyer, but are delayed16:47
zyga-ubuntumvo: what happened to the snap.mount unit?16:48
niemeyercachio: Well..? :)16:48
cachioniemeyer, first time I see that butI saw similar issues that I tried to address on the spread PR16:48
cachioniemeyer, https://github.com/snapcore/spread/pull/4916:49
mupPR spread#49: send keepalive packets every 10 seconds to avoid losing the connection <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/49>16:49
zyga-ubuntumvo: reviewed16:50
cachioniemeyer, I have seen kill timeout reached the last weeks16:50
cachioniemeyer, not just for fedora16:50
niemeyercachio: Again, an entire run looking perfect except for the two Fedora workers hanging exactly on the same place is not a coincidence16:51
niemeyercachio: These are independent machines, started independently, running independently16:51
kyrofakalikiana, are you still around?16:51
kalikianahey kyrofa16:52
kalikianaYes I am :-D16:52
niemeyercachio: Have you seen where it's stuck?16:52
kyrofakalikiana, late for you! I don't suppose you have 5 minutes to meet?16:52
* zyga-ubuntu small supper & fresh tea16:52
cachioniemeyer, yes16:52
kalikianakyrofa: Indeed. I'll grab my headphones. It's fine.16:53
cachioniemeyer, but the test seem to be ok16:53
cachioniemeyer, in fact it is the first time I see this error16:53
kyrofakalikiana, about on-to by the way16:53
cachioniemeyer, perhaps it is something related to the store16:53
kalikianakyrofa: Ack16:54
niemeyercachio: Maybe, but what would justify getting stuck?16:56
cachioniemeyer, perhaps it is not stuck, spread is who is not getting the changes16:57
cachioniemeyer, I used to see that in my machine often16:57
cachiomainly when we use the quiet command16:57
niemeyercachio: Not sure I understand what you mean by that16:58
niemeyercachio: There's a "snap install" command there and no output16:58
cachioniemeyer, 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 working16:59
cachioniemeyer, that's what I saw running from localhost in different situations17:00
niemeyercachio: snap install should not hang silently like that17:00
cachioniemeyer, let me try to reproduce it here17:01
niemeyercachio: If it does it's a bug.. if you are seeing this frequently, let's please  not ignore it17:01
niemeyerAnyway, really need to run.. o/17:01
cachioI created a PR in spread for those situations17:01
cachioniemeyer, but I am not sure if this case is affected by that17:01
cachioniemeyer, I'll try to reproduce it locally17:02
cachioniemeyer,  I am already runnig this test in order to see if I can reproduce it17:03
jdstrandmvo: 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 course17:03
jdstrandmvo: 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:04
cachiomvo, the tests for beta are going really well17:07
cachiomvo, we are going to candidate soon17:08
cachioniemeyer, 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 machines17:10
cachioniemeyer, is being happening a change in linode?17:10
cachioall the machines failed because of this17:10
* cachio lunch17:14
kyrofaelopio, did you ever manage to get the bot cranking out autopkgtests again?17:19
elopiokyrofa: no, had to do it locally. But haven't checked again since thursday.17:20
kyrofaelopio, looks like we have arm again17:20
elopioI'll check in a few.17:20
kalikianaGoing to call it a day now17:23
* kalikiana waves17:23
zyga-ubuntukalikiana: o/17:23
* zyga-ubuntu EODs and marks most of his projects as abandoned17:24
kalikianazyga-ubuntu: is that a part of "live every day like it's your last day"? ;-)17:25
zyga-ubuntukalikiana: haha17:25
zyga-ubuntuno, about some thinking I was doing17:25
zyga-ubuntuon ancinent projects17:25
zyga-ubuntuand on ...17:25
kyrofaelopio, does that mean you tested snapcraft#1877 locally?17:28
mupPR snapcraft#1877: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>17:28
mupPR 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:28
kalikianazyga-ubuntu: neat17:30
elopiokyrofa: yes.17:34
kyrofaelopio, with success? :P17:44
kyrofaI'll merge that PR if so17:44
elopiokyrofa: https://autopkgtest.ubuntu.com/request.cgi still gives 500, so no way to launch them.17:49
kyrofacjwatson, do you know anything about that?17:49
elopiokyrofa: and yes, locally the tests ran. Not all of them passed, but that's not because of the refactor.17:49
kyrofaelopio, enough to give you confidence in the PR, though?17:49
cjwatsonkyrofa: (a) it's intentional until Spectre mitigation is finished (b) in general please ask Laney about autopkgtest stuff, not me17:50
elopiokyrofa: yes, because travis is running all of them and passing.17:50
kyrofacjwatson, excellent, thank you. Good to know who runs that stuff!17:50
cachioniemeyer, I could reproduce the error on fedora18:14
cachiothis is the log with the error https://paste.ubuntu.com/26438961/18:14
zyga-ubuntu            return BadRequest("cannot %s %q: %v", inst.Action, inst.Snaps[0], err)18:20
zyga-ubuntulooks like inst.Snaps is empty18:20
zyga-ubuntuChipaca: ^18:21
cachiozyga-ubuntu, did you see this error?18:24
cachioseem to be affecting fedora18:25
zyga-ubuntucachio: I looked at your log, I didn't investigate more18:26
mupPR snapd#4518 opened: tests: fix for test interface-netlink-connector <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4518>19:15
zyga-ubuntucachio: ^19:23
zyga-ubuntuI think you need to use ' ' rather than ""19:23
zyga-ubuntuit looks like invalid yaml19:23
barryhey 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 age19:23
zyga-ubuntubarry: hey19:24
barryzyga-ubuntu: hi!19:24
zyga-ubuntubarry: I think rhel7 is "soon" but nobody has championed that, perhaps someone just needs to work together with Pharaoh_Atem who maintains the fedora packages19:24
zyga-ubuntubarry: osx support is something that is a different class of problem to solve (virtualization most likely)19:25
cachiozyga-ubuntu, yes19:25
cachiozyga-ubuntu, thanks19:25
barryzyga-ubuntu: that totally makes sense re: osx19:25
zyga-ubuntubarry: I think that if you want to see rhel happen soon you should get in touch with neal (Pharaoh_Atem) and see what's missing19:26
zyga-ubuntuI heard neal made some centos packages and I'm not on top of that anymore19:26
zyga-ubuntubarry: technically I think rhel is "just packagign"19:27
cachiozyga-ubuntu, should I add net-admin capability to the ssh-keys and ssh-public-keys interface?19:33
cachiozyga-ubuntu, I mean, to avoid connecting to network-control19:33
zyga-ubuntucachio: I don't think so19:35
zyga-ubuntuthose interfaces don't say "you are network admin"19:35
zyga-ubuntucachio: perhaps just use a simpler test19:35
zyga-ubuntucachio: don't run ssh19:35
zyga-ubuntucachio: just read keys19:35
cachiozyga-ubuntu, ok, but the test is sharing ssh, that's why I using it19:36
cachiozyga-ubuntu, I mean, I am trying to cover the whole interface19:36
zyga-ubuntucachio: yes but the interface doesn't promise you can run ssh19:37
zyga-ubuntucachio: not sure if that's worth it19:37
cachiozyga-ubuntu, ok, so perhaps this line should not be included19:39
cachioin the interface /usr/bin/ssh ixr,19:39
zyga-ubuntucachio: hmm, intersting,19:40
zyga-ubuntujdstrand: ^ do you think this makes sense?19:40
zyga-ubuntussh-keys should not be about running ssh19:40
zyga-ubuntujdstrand: or if it should it should really allow it19:41
Pharaoh_Atemzyga-ubuntu: there's a few other things, like making the software install integration work19:42
zyga-ubuntuPharaoh_Atem: gnome-software?19:45
zyga-ubuntuPharaoh_Atem: what's missing there?19:45
zyga-ubuntuPharaoh_Atem: I think getting basic CLI package out there would help19:45
jdstrandcachio: please don't add network-control for testing ssh19:51
barryzyga-ubuntu: okay thanks19:52
jdstrandcachio: when I tested the interface, I did not need network-control19:52
jdstrandcachio: how are you using ssh?19:52
cachiojdstrand, https://github.com/snapcore/snapd/pull/4512/files19:53
mupPR #4512: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4512>19:53
jdstrandcachio: the interfacec doesn't claim to support everything the ssh command can do19:53
cachiojdstrand, so, which is the idea about the ssh command for that interface?19:55
cachiojdstrand, to do what?19:55
cachiojdstrand, so I can update the test19:55
jdstrandcachio: "ssh-public-keys: I was unable to determine a use for this interface" from https://github.com/snapcore/snapd/pull/410020:00
mupPR #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:00
jdstrandcachio: 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 file20:01
cachiojdstrand, ok20:02
cachiojdstrand, what about the ssh-keys?20:02
cachiojdstrand, should I test the ssh command connection?20:02
cachiojdstrand, or just the access to the keys?20:03
jdstrandcachio: "ssh-keys: I was able to login to a remote server"20:03
cachiojdstrand, I tried that and I couldn't, let me try again20:03
jdstrandcachio: 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:03
jdstrandcachio: if you can't, the ssh -V and testing if can access .pub and private keys should be enough20:04
cachiojdstrand, ok20:04
Pharaoh_Atemzyga-ubuntu: g-s is one bit, but not really the important one20:11
Pharaoh_Atemthe important one is making sure that the selinux policies apply correctly20:11
zyga-ubuntuPharaoh_Atem: and what is missing there?20:12
Pharaoh_Atemzyga-ubuntu: well, I still need to backport a bunch of patches for ensuring the paths work correctly20:14
Pharaoh_Atembasically, I need to retry with 2.30 / 2.3120:14
Pharaoh_Atemwhich I'm preparing for Fedora right now20:14
zyga-ubuntuI see, thank you!20:16
cachiojdstrand, permission denied20: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:22
cachiojdstrand, this is without network-control20:23
cachiofor the ssh-keys interface20:23
=== kennyloggins is now known as CoderEurope
jdstrandcachio: sure, you will definitely need 'network'20:34
roadmrelopio: hi! hey do you know who mans the snapcrafters e-mail address?20:34
elopioroadmr: I would guess Alan and Martin.20:35
roadmrthanks 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:35
cachiojdstrand, so, what do you prefer for the test, add network or just check keys? for the ssh-keys interface20:36
lundmarHi. 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?20:57
jdstrandcachio: I don't have a preference. I think it is sufficient to only check check the keys21:04
cachiojdstrand, ok, tx21:04
jdstrandroadmr: 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:05
noise][jdstrand - yes!21:06
roadmrjdstrand: \o/ zorch em21:07
jdstrandok thanks21:25
mupPR snapd#4518 closed: tests: fix for test interface-netlink-connector <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4518>21:37

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!