[05:54] <mborzecki> morning
[06:39] <mwhudson> https://buildd.debian.org/status/fetch.php?pkg=snapd&arch=i386&ver=2.30-3&stamp=1515462684&file=log <- is deviceMgrSuite.TestDoRequestSerialErrorsOnNoHost known flaky?
[06:53] <mup> PR snapd#4453 closed: Update README.md <Created by popey> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4453>
[06:57] <mborzecki> mwhudson: sort of, the test is supposed to use an invalid domain name, though there's been some back and forth on what an invalid domain name that would not be resolved is
[06:58] <mwhudson> hmm
[06:58] <mwhudson> time to remember how to retry builds on debian buildds i guess
[06:59] <mborzecki> mwhudson: i think there might be something special here though, we've used *.invalid, then some bogus name.com and finally settled with nowhere.test, but it seems like the resolver is actually trying to resolve it :/
[06:59] <mwhudson> mborzecki: it only failed on i386
[06:59] <mwhudson> but maybe that builder is different somehow
[07:01] <zyga-ubuntu> good morning
[07:01] <mwhudson> morning zyga-ubuntu
[07:04] <mborzecki> zyga-ubuntu: hey
[07:04] <mvo> hey zyga-ubuntu and mwhudson and mborzecki
[07:05] <mborzecki> mvo: morning
[07:06] <mwhudson> launchpad's "click a button" certainly seems clearer than https://release.debian.org/wanna-build.txt
[07:06] <mup> PR snapd#4451 closed: cmd/snap-update-ns: improve mocking for tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4451>
[07:10] <zyga-ubuntu> I'll be here soon, just finishing breakfast for kids
[07:28]  * zyga-ubuntu finishes coffee checking maikl
[07:41] <mborzecki> doing any text transformation in `snap_confine_snap_confine_debug_LDADD = $(something .. $(snap_confine_snap_confine_LDADD))` results in `snap_confine_snap_confine_debug_DEPENDENCIES = $(something .. $(snap_confine_snap_confine_LDADD))`, so the DEPENDENCIES includes -ludev -lfoo now :/
[07:58] <kalikiana> good mornin
[07:59] <mborzecki> kalikiana: morning
[08:13] <mvo> mborzecki: 4449 fails with a link error on debian, could this be related to your makefile changes or is that an unrelated issue?
[08:14] <mborzecki> mvo: related, i'm working on it, one fugly workaround for automake :/
[08:15] <mvo> mborzecki: uff, ok. good luck!
[08:15] <mborzecki> mvo: pushed just now, feel free to take a look and review :)
[08:15] <mvo> great
[08:22] <mborzecki> pstolowski: morning
[08:22] <pstolowski> good morning!
[08:26] <mvo> good morning pstolowski !
[08:27]  * pstolowski reboots
[08:36] <mborzecki> mvo: there's a conflict in #4356
[08:36] <mup> PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
[08:45] <mborzecki> is #3998 actionable now?
[08:45] <mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
[08:45] <zyga-ubuntu> mborzecki: I think it should be in the kernel by now
[08:45] <zyga-ubuntu> mborzecki: but we need to connect the dots
[08:48] <mvo> zyga-ubuntu, mborzecki iirc the problem is/was that fedora has no updated libseccomp
[08:50] <zyga-ubuntu> mvo: indeed, we may need to always allow an older version of the library to stay realistically deployable
[08:50] <mborzecki> ok, let me quickly ccheck what's the latest version in updates
[08:51] <mvo> zyga-ubuntu: yeah, iirc that is the missing bit
[08:51] <mborzecki> by the looks of it, it's 2.3.2 in f26 and f27
[08:51] <mborzecki> unless there's some specific patch that's missing
[08:51] <zyga-ubuntu> mvo: altough having said that we should not differ in behaviour for apps, we should switch to EPERM universally, just enable logging if that is implemented
[08:52] <zyga-ubuntu> mborzecki: ^
[08:52] <mborzecki> right, makes sense
[08:54] <mup> PR snapd#4456 opened:  snap: rename `snap advise-command` to `snap advise-snap --command`  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4456>
[09:12] <mup> PR snapd#4444 closed: tests: use "quiet" helper instead of "dnf -q" to get errors on failures <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4444>
[09:29]  * kalikiana coffee
[09:33]  * zyga-ubuntu tries to untangle an abstraction
[09:33] <zyga-ubuntu> sigh
[09:33] <zyga-ubuntu> so close yet a bit frustratingly not there
[09:33] <Chipaca> zyga-ubuntu: another security issue just to brighten your day: https://twitter.com/chris__martin/status/950518574589923331
[09:33] <zyga-ubuntu> what!
[09:34] <zyga-ubuntu> LOL!
[09:34] <zyga-ubuntu> beautiful
[09:34] <Chipaca> :) you're welcome
[09:37] <mup> PR snapd#4457 opened: spread: trying to re-enable tests on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4457>
[09:38] <mborzecki> Chipaca: you mentioned that you ran into some non-dnf related issues on fedora, can you describe what that was?
[09:38] <Chipaca> mborzecki: "snap: command not found", and systemctl saying snapd.service was not found
[09:39] <Chipaca> mborzecki: IOW something that looked suspiciously like snapd not being installed
[09:41] <mborzecki> interesting, i ran some tests on fedora today, haven't observed anything like this, maybe it will come up in the PR i just opened ^^
[09:44] <mborzecki> duh. wonder what conditions would have to be met to get a latex error message that makes sense
[09:45] <Chipaca> mborzecki: maybe the conditions need to exist in the observer's mind
[09:46] <mborzecki> randomly hitting x
[09:46] <Chipaca> maybe latex was all about psychoquantumdynamics
[09:47] <mborzecki> half of the 'exploit' was getting your latex toolchain to work with proper fonts and language
[10:05] <ackk> mvo, hi, do you have any suggestion on how to debug those errors on my snap install?
[10:06] <zyga-ubuntu> coffee
[10:08] <mvo> ackk: not right now, do you see apparmor or seccomp denials when you run the install? maybe zyga-ubuntu has an idea about the issue. another thing to try is see if using maas without base-18 gives the same error (removing the base: line)
[10:10] <zyga-ubuntu> hmm hmm hmm hmm
[10:10] <ackk> mvo, no, nothing
[10:13] <ackk> mhm, so there's this thing: the first time I snap try I get this error: https://paste.ubuntu.com/26352275/
[10:13] <ackk> but now I have the prime directory mounted
[10:13] <ackk> /dev/sda3 on /snap/maas/x1 type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@home/ack/canonical/src/maas/build/dev-snap/prime)
[10:13] <ackk> and I can't unmount it
[10:13] <ackk> I suspect that's messing up snapd
[10:13] <zyga-ubuntu> oh
[10:13] <zyga-ubuntu> btrfs
[10:14] <mvo> ackk: ohh, that is indeed interessting and a useful clue
[10:14] <zyga-ubuntu> I don't know if eve ever test that it works with snapd
[10:14] <mvo> and it would explain why I was not able to reproduce!
[10:14] <ackk> zyga-ubuntu, I've always used it
[10:14] <ackk> with no issue so far
[10:14] <zyga-ubuntu> ackk: sure but we never (AFAIK) use it and it's an extra layer of complexity
[10:14] <mvo> ackk: does "systemctl  status snap-maas-x1.mount" and "journalctl  -xe"" give you anything useful why it fails?
[10:14] <ackk> $ umount /snap/maas/x1
[10:14] <ackk> umount: /snap/maas/x1: umount failed: Operation not permitted
[10:14] <zyga-ubuntu> ackk: I'm not saying it doesn't work, just that it is an extra variable
[10:15] <zyga-ubuntu> ackk: anything in audit log:?
[10:15] <ackk> Process: 20922 ExecUnmount=/bin/umount /snap/maas/x1 -c (code=exited, status=32)
[10:15]  * zyga-ubuntu waits for people to try snaps on ZFS
[10:15] <ackk> but status is active (mounted)
[10:16] <ackk> mvo, nothing relevant in journalctl, just ^^ in status output
[10:17] <ackk> I'll try to reboot the container
[10:17] <zyga-ubuntu> oh,. it's a container?
[10:17] <zyga-ubuntu> ackk: wait
[10:17] <mvo> ackk: hm, exit status 32 just means "mount-failure" not very helpful, especially without any extra info
[10:17] <zyga-ubuntu> ackk: cat /proc/self/mountinfo
[10:18] <zyga-ubuntu> mvo: is it not just the "snapd fails in containers or places without rshare /" case?
[10:18] <mvo> zyga-ubuntu: it might be, I thought we had this under control :(
[10:18] <zyga-ubuntu> no, it's not fixed yet
[10:18] <zyga-ubuntu> mvo: after several attempts it's still broken
[10:18] <zyga-ubuntu> mvo: sorry about that :/
[10:18] <ackk> oh, after reboot /var/lib/snapd/snaps/maas_x1.snap became a dir :)
[10:19] <ackk> zyga-ubuntu, mvo ok, after reboot I don't have that mountpoint anymore, but same error
[10:19] <mvo> zyga-ubuntu: no worries, thanks for remembering more than I do - yeah, then its probably this
[10:19] <ackk> fwiw that error from the paste is totally reproducible the first time I "snap try"
[10:20] <ackk> zyga-ubuntu, https://paste.ubuntu.com/26352304/
[10:20] <mvo> ackk: and from installing, right? not just try?
[10:20] <ackk> mvo, snap try
[10:20] <mvo> ackk: so just try?
[10:21] <ackk> mvo, correct
[10:21]  * mvo nods
[10:21] <ackk> zyga-ubuntu, so that mountpoint was left behind somehow
[10:21] <zyga-ubuntu> -
[10:21] <zyga-ubuntu> so not shared
[10:21] <zyga-ubuntu> so proably that's the same cause as before
[10:22] <zyga-ubuntu> ackk: I cannot explain how maas_x1.snap became a directory
[10:24] <ackk> so the thing that makes me thing that snapd is confused by that mountpoint is "2018/01/09 10:23:35.075389 task.go:303: DEBUG: 2018-01-09T10:23:35Z ERROR cannot find installed snap "maas" at revision x1"
[10:24] <ackk> there's no installed maas snap
[10:24] <ackk> but it seems snapd thinks it's actually updating it
[10:24] <zyga-ubuntu> ackk: I think this is https://bugs.launchpad.net/snapd/+bug/1712930
[10:24] <mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:Confirmed for zyga> <https://launchpad.net/bugs/1712930>
[10:26] <ackk> ah the old issue with snap in lxd
[10:26] <zyga-ubuntu> ackk: indeed
[10:26] <zyga-ubuntu> ackk: can you (perhaps) try if this goes away without the container in place?
[10:26] <zyga-ubuntu> ackk: it woudl re-affirm where we are
[10:26] <zyga-ubuntu> ackk: and I promise to attack that bug again later today
[10:27] <ackk> zyga-ubuntu, sure, lemme test
[10:27] <ackk> zyga-ubuntu, ah! so, somehow now umount worked on that dir
[10:27] <ackk> and snap try went further along
[10:28] <ackk> so that seems to be the issue
[10:28] <ackk> (I'm still testing in the container)
[10:29]  * zyga-ubuntu makes some progress actually
[10:33] <ackk> zyga-ubuntu, so there's something weird, there
[10:33] <ackk> $ mount | grep snap/maas
[10:33] <ackk> /dev/sda3 on /snap/maas/x1 type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@home/ack/canonical/src/maas/build/dev-snap/prime)
[10:33] <ackk> zyga-ubuntu, ^ that's not actually a btrfs subvolume
[10:33] <ackk> is snap being confused by the underlying btrfs and trying to mount it as such?
[10:34] <zyga-ubuntu> ackk: I doubt it, snapd doesn't mount that, this is systemd, systemd is not confused either (probably); mount is confusing, this is a bind mount and mount cannot represent those
[10:34] <zyga-ubuntu> look at mountinfo
[10:34]  * kalikiana more coffee
[10:34] <zyga-ubuntu> this is a bit annoying about bind mounts, they suck for UX
[10:34] <zyga-ubuntu> nobody can make heads or tails about what's where
[10:34] <zyga-ubuntu> (and how)
[10:34] <zyga-ubuntu> because bind mount history is logical to humans but not preserved
[10:34] <zyga-ubuntu> and bind mount effects are highly confusing but that's what the kernel models and stors
[10:34] <zyga-ubuntu> *stores
[10:35] <ackk> zyga-ubuntu, so /snap/maas/x1 is a bind-mount?
[10:35] <zyga-ubuntu> ackk: look at mountinfo
[10:35] <zyga-ubuntu> ackk: and we'll see
[10:35] <zyga-ubuntu> ackk: but 99% yes
[10:35]  * zyga-ubuntu will design a bind mount t-shirt one day
[10:36] <ackk> zyga-ubuntu, https://paste.ubuntu.com/26352351/
[10:36] <Chipaca> is it bad that last night i learned how to use a package-private function from outside the package, in go?
[10:36] <Chipaca> this will make testing some things a lot simpler :-D
[10:37] <zyga-ubuntu> so /snap/maas/x1 is actually a btffs filesystem from /dev/sda3, specifically the fragment located at /@home/ack/canonical/src/maas/build/dev-snap/prime relative to that filesytem
[10:37] <zyga-ubuntu> yep, that's a bind mount
[10:38] <zyga-ubuntu> at some point I think mount stopped being useful for humans
[10:38] <jamesh> Chipaca: without modifying the package?
[10:38] <Chipaca> jamesh: yes
[10:38] <jamesh> Chipaca: care to share then?
[10:39] <Chipaca> jamesh: https://pastebin.ubuntu.com/26352358/
[10:39] <zyga-ubuntu> jamesh: hey! sorry for lagging; I'd like to arrange a call later this week between you me and gustavo; I need to do some prep work but I think we can try the day after tomorrow (assuming schedule allows)
[10:39] <zyga-ubuntu> jamesh: do you have preference for your evening vs your morning?
[10:39] <zyga-ubuntu> jamesh: gustavo and I will adapt
[10:39] <Chipaca> jamesh: the only caveat is that the package from which you do this needs to have a .s file (it can be empty)
[10:39] <Chipaca> and you need to import unsafe even if you don't use it, otherwise go:linkname refuses to woork
[10:40] <Chipaca> and you need to import the package, even if you don't use it :-)
[10:40] <jamesh> zyga-ubuntu: my evening is probably going to be the easiest to cover Australia, Europe, and Brazil
[10:40] <mup> PR snapd#4458 opened: overlord/snapstate: no refresh just for hints if there was a recent regular full refresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/4458>
[10:41] <Chipaca> jamesh: (if you want to run that as is, note modeFromTriplet isn't in master yet; grab #4394 for that)
[10:41] <mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
[10:41] <zyga-ubuntu> jamesh: ok, so today I'm trying to wrap up last year's PRsr and will jump into LXD issue but we can do day after tomorrow because I could focus on getting in-depth understanding of your work tomorrow
[10:41] <ackk> zyga-ubuntu, I get https://paste.ubuntu.com/26352371/ at the first install on the physical machine
[10:42] <ackk> actually, every time
[10:42] <zyga-ubuntu> jamesh: gustvo would like to get better understanding of where we are in anticipation of the upcoming sprint next week
[10:42] <jamesh> okay
[10:42] <zyga-ubuntu> ackk: interesting, is /var/snap present?
[10:42] <zyga-ubuntu> maybe it's a packaging issue
[10:42] <zyga-ubuntu> snap-confine doesn't create that directory
[10:42] <ackk> zyga-ubuntu, yes it is, i have also other snaps installed
[10:42] <Chipaca> mvo: i've added some tests to #4394, i think you'll like it now
[10:42] <mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
[10:43] <zyga-ubuntu> ackk: bummer, no idea then :/
[10:43] <ackk> zyga-ubuntu, FTR this is on artful
[10:43] <zyga-ubuntu> ackk: noted
[10:43] <zyga-ubuntu> ackk: ahh wait
[10:43] <zyga-ubuntu> ackk: this is with the base 18 snap, right?
[10:43] <ackk> yeah
[10:44] <zyga-ubuntu> ackk: so can you quickly look in /snap/base-18/current/var/snap
[10:44] <ackk> I get the same error on the first try on bionic, so maybe that's the root cause?
[10:44] <zyga-ubuntu> does that exist?
[10:44] <zyga-ubuntu> if no that's the problem
[10:44] <zyga-ubuntu> (needs to be in the base snap)
[10:44] <ackk> nope
[10:44] <ackk> bingo :)
[10:44] <zyga-ubuntu> good catch!
[10:44] <ackk> mvo, ^^
[10:46] <ackk> zyga-ubuntu, so just creating var/snap inside the base should work?
[10:46] <zyga-ubuntu> yes
[10:46] <zyga-ubuntu> well
[10:46] <zyga-ubuntu> one step forward
[10:46] <zyga-ubuntu> but yes
[10:46] <mup> PR snapd#4459 opened: snap: add support for `snap advice-snap pkgName` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4459>
[10:48] <mvo> ackk: thanks! a shame that LP building is not working, master is ok https://github.com/snapcore/base-18/blob/master/hooks/20-extra-files.chroot#L18 :/ I can give you an updated snap or you can hack it yourself?
[10:48] <zyga-ubuntu> woot
[10:48] <zyga-ubuntu> progress
[10:48] <zyga-ubuntu> 5 errors, but the code builds and has good structure
[10:48] <zyga-ubuntu> and errors look like string tweaks I did don't match errors in tests
[10:51] <ackk> mvo, if you have an updated one that'd be great
[10:52] <ackk> mvo, have you asked for whitelisting?
[10:54] <mvo> ackk: I asked but maybe not forceful enough. I was told things will be reenabled today once the kernel is updated
[10:56] <mvo> ackk: I updated http://people.canonical.com/~mvo/tmp/base-18_very-unstable_amd64.snap to include the dirs from master
[10:59] <mup> PR snapd#4455 closed: store, daemon/api: Rename MyAppsServer, point to dashboard.snapcraft.io instead <Created by sparkiegeek> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4455>
[11:10] <ackk> mvo, thanks, will try that one
[11:15] <ackk> mvo, there's no /var/snap inthat snap
[11:19]  * zyga-ubuntu sees green tests
[11:20] <mvo> ackk: meh, I'm sorry, pushed the wrong one :/ I repushed the right one to the same location: https://paste.ubuntu.com/26352614/
[11:20] <ackk> mvo, mvo thanks
[11:20] <zyga-ubuntu> let's see coverage]
[11:22] <BjornT_> zyga-ubuntu: if you have some time, i added some more information to bug #1741463
[11:22] <mup> Bug #1741463: Failure to install maas snap in a container on a host using nvidia drivers <Snappy:New> <https://launchpad.net/bugs/1741463>
[11:25] <ackk> mvo, next error I got is: - Run configure hook of "maas" snap if present (run hook "configure": cannot perform operation: mount --bind /snap/base-18/current//etc/alternatives /tmp/snap.rootfs_9Cushn/etc/alternatives: Permission denied)
[11:26] <zyga-ubuntu> BjornT_: thanks, this looks like a simple apparmor profile tweak
[11:26] <zyga-ubuntu> BjornT_: looking now
[11:27] <zyga-ubuntu> hmmm
[11:27] <zyga-ubuntu> BjornT_: so looking at snap-confine.apparmor.in I see a rule that looks like this:
[11:27] <zyga-ubuntu>     # Vulkan support
[11:27] <zyga-ubuntu>     /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/* w,
[11:27] <zyga-ubuntu>     mount fstype=tmpfs options=(rw nodev noexec) none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
[11:27] <zyga-ubuntu>     mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
[11:28] <zyga-ubuntu> can you look into /etc/apparmor.d/ for snap-confine.real (there may be a few) and see if those rules exist there?
[11:28] <zyga-ubuntu> (I want to check if this code is released)
[11:30] <mup> PR snapd#4460 opened: daemon: store email, ID and macaroon when creating a new user <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4460>
[11:30] <mvo> ackk: aha, let me fix that and update
[11:32] <mvo> ackk: updated on the same location as before, please let me know if that gets you further
[11:33] <ackk> thanks
[11:34] <ackk> mvo, it takes me a whilte to test since that mountpoint prevents me from reinstalling the maas snap, so i have to purge snapd, reboot and reinstall every time
[11:35] <mvo> ackk: that sounds really painful :(
[11:35] <zyga-ubuntu> ackk: inside a container or in general?
[11:35] <ackk> zyga-ubuntu, inside a container
[11:35] <ackk> because of that mount bug
[11:35] <ackk> if I try to remove a snap it's pending forever
[11:36] <zyga-ubuntu> ok
[11:39] <BjornT_> zyga-ubuntu: there's nothing about 'vulkan' in usr.lib.snapd.snap-confine.real
[11:39] <zyga-ubuntu> BjornT_: are you on 2.30/
[11:39] <zyga-ubuntu> BjornT_: that file may be older but you should be getting reexec from the core snap
[11:40] <zyga-ubuntu> so snap.core.*.usr.lib.snapd.snap-confine should have those rules
[11:40] <BjornT_> zyga-ubuntu: i'm on xenial, so 2.29.4.2
[11:41] <zyga-ubuntu> BjornT_: that's ok, but you should see 2.30 in snap version (because of core snap)
[11:41] <zyga-ubuntu> BjornT_: as a sanity check, can you switch to edge
[11:42] <zyga-ubuntu> BjornT_: and see if that fixes it
[11:42] <zyga-ubuntu> BjornT_: I believe this is fixed in master but may just not be released yet
[11:43] <mup> PR snapd#4461 opened: snap: fix missing error check when multiple snaps are refreshed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4461>
[11:44] <BjornT_> zyga-ubuntu: ah right, yes 2.30. i'll try the edge version
[11:47] <ackk> mvo, progress, I'm hitting that ubuntu.csv issue now, do you still have the change to snapcraft.yaml handy?
[11:47] <ackk> I think it's just adding distro-info-data to stage-packages
[11:48] <BjornT_> zyga-ubuntu: same error with edge core snap. or do i have to restart apparmor as well?
[11:49] <zyga-ubuntu> BjornT_: no, you shouldn't have to restart anything
[11:49] <ackk> mvo, or actually, wasn't that added to the base?
[11:51] <zyga-ubuntu> BjornT_: hmm
[11:51] <zyga-ubuntu> info="failed flags match"
[11:51] <zyga-ubuntu> this is curious
[11:51] <zyga-ubuntu> perhaps (just perhaps) the system is buggy and remount is not a real flag that works
[11:52] <zyga-ubuntu> BjornT_: can you please edit the /etc/apparmor.d/snap.core.$LATEST.usr.lib.snapd.snap-confine file
[11:52] <zyga-ubuntu> BjornT_: go to the line that describes the three vulcan entries
[11:53] <zyga-ubuntu> BjornT_: and remove the "ro" there from (remount ro)
[11:53] <zyga-ubuntu> to just (remount)
[11:53] <zyga-ubuntu> BjornT_: then use: sudo apparmor_parser -r /etc/apparmor.d/snap.core.$LATEST.usr.lib.snapd.snap-confine
[11:53] <zyga-ubuntu> and see if that fixes it
[11:56] <mvo> ackk: it was not added, there is a open pr, I can add it for you right after lunch for this one test snap
[11:57] <ackk> mvo, thanks, and enjoy lunch :)
[11:58]  * zyga-ubuntu keeps fingers crossed
[11:58] <zyga-ubuntu> and...
[11:58] <zyga-ubuntu> YESSSS
[11:58] <zyga-ubuntu> :D
[11:59] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/4452 enables all of the mechanics of layouts
[11:59] <mup> PR #4452: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4452>
[12:00] <zyga-ubuntu> now to rebase the new content interface syntax PR
[12:00] <zyga-ubuntu> and to open a new PR that takes use of the layout yaml syntax and puts it into use
[12:01] <zyga-ubuntu> at just 310 new lines and 63 removed lines
[12:01] <zyga-ubuntu> jamesh: ^^ this should be directly applicable to themes now
[12:01] <zyga-ubuntu> jamesh: I'll focus on the source syntax for content because it also enables the new union mechanics where many entries can contribute to one (spool like) directory
[12:02] <zyga-ubuntu> mvo: I added 4452 to 2.31, it's my most important addtion now
[12:02] <kalikiana> popey: ping wrt bug 1741752
[12:02] <mup> Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' <Snapcraft:New> <https://launchpad.net/bugs/1741752>
[12:03] <zyga-ubuntu> there are some unit tests missing but spread tests cover everything and I'll fill the gaps quickly (just a few lines)
[12:03] <ackk> mvo, I hacked the image adding distro-info, it works now
[12:04] <zyga-ubuntu> BjornT_: any luck, I can help if you don't know what to change
[12:11] <ackk> zyga-ubuntu, can you depend on a base from a specific channel? like base: base-18/edge?
[12:11] <mup> PR snapd#4313 closed: timeutil: refresh timer take 2 <Created by bboozzoo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4313>
[12:11] <zyga-ubuntu> ackk: no
[12:17] <mup> PR snapd#4373 closed: snap: app startup after/before validation <Created by bboozzoo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4373>
[12:21] <BjornT_> zyga-ubuntu: i removed the 'ro', but i still get the same error
[12:21] <zyga-ubuntu> BjornT_: I assume you re-compiled the apparmor profile
[12:21] <zyga-ubuntu> BjornT_: and that the revision in the file name matches the revision of the core snap
[12:22] <zyga-ubuntu> BjornT_: can you remove all of (remount, ro) next?
[12:22] <BjornT_> zyga-ubuntu: yeah, using apparmor_parser -r
[12:22] <zyga-ubuntu> ok, just checking
[12:24] <mup> PR snapd#4462 opened: progress: switch ansimeter's Spin() to use a spinner <Created by chipaca> <https://github.com/snapcore/snapd/pull/4462>
[12:24] <Chipaca> niemeyer: mvo: just for you guys ^-^
[12:28] <zyga-ubuntu> ok, feels like moment to make some food
[12:28] <zyga-ubuntu> I'll see you at the standup
[12:32] <BjornT_> zyga-ubuntu: still the same error
[12:32] <zyga-ubuntu> BjornT_: I wonder how I can test this, what setup do you use
[12:33] <zyga-ubuntu> BjornT_: if I could reproduce this locally I could fix it easier
[12:34] <BjornT_> zyga-ubuntu: the host is xenial and i've tried with both xenial and bionic containers. not sure if having the nvidia drivers is enough trigger it, though
[12:36] <zyga-ubuntu> BjornT_: which drivrs are you on ?
[12:36] <zyga-ubuntu> BjornT_: I have an artful system with old nvidia (without vulcan) but I can fake some things (perhaps) to trigger it
[12:36] <zyga-ubuntu> BjornT_: are you on xenial kernel or on some newer one?
[12:37] <BjornT_> zyga-ubuntu: i have the nvidia-384 package installed. still xenial kernel
[12:38] <zyga-ubuntu> I could use a single slot non-outdated nvidia GPU
[12:38] <zyga-ubuntu> could use it for testing
[12:38] <zyga-ubuntu> I'm all AMD on my desktop
[13:00] <mvo> ackk: updated
[13:01] <mvo> ackk: aha, reading backlog you added it already
[13:01] <mvo> ackk: and it all works? maas init too?
[13:01] <ackk> mvo, does base-18 have timezone information?
[13:01] <ackk> mvo, no, I get the following error at maas init: psycopg2.DataError: invalid value for parameter "TimeZone": "UTC"
[13:02] <ackk> mvo, still investigating if that could be caused by something missing in the base
[13:02] <ackk> mvo, are zoneinfo data there?
[13:03] <ackk> mvo, ok "SET TIME ZONE 'UTC'" fails in postgres
[13:04] <mvo> ackk: indeed, no zoneinfo
[13:04] <ackk> oh
[13:04] <ackk> so that's why
[13:04] <ackk> mvo, could those be added as well?
[13:04] <ackk> mvo, I'm sorry for this back-and-forth...
[13:05] <mvo> ackk: sure, one minute
[13:07] <mvo> ackk: please try now, I added tzdata - I have a meeting now so replies might be a bit slow
[13:07] <ackk> mvo, thanks a lot
[13:09] <mvo> ackk: thanks for all your feedback!
[13:29] <greyback> jdstrand_: hey, when you get time could you look at https://github.com/snapcore/snapd/pull/4365 - hopefully it's good to go
[13:29] <mup> PR #4365: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365>
[13:38] <ackk> zyga-ubuntu, out of curiosity, is it known what's the fix for the mount order issue causing the snap removal bug?
[13:38] <zyga-ubuntu> ackk: yes, very quite so
[13:39] <ackk> zyga-ubuntu, ah cool, can't wait to have that fixed :)
[13:39] <mvo> ackk: how are things looking with the updated base?
[13:39] <zyga-ubuntu> ackk: we iterated on that issue a few times (well, I did) and we are zeroing on something that both works and is security sane
[13:39] <Chipaca> mvo: so, i'll grab title and summary and put it in a bucket indexed by snap name, ok? (anything else you want in there?)
[13:39] <ackk> mvo, reinstalling now (had to break for lunch)
[13:39] <zyga-ubuntu> ackk: I added an action item for myself to look at that with some urgency, we should have some time next week as many people get locked at the sprint and I can work on that
[13:39] <ackk> zyga-ubuntu, great
[13:43] <mvo> Chipaca: iirc that is already (well, summary) done in my latest pr, no?
[13:44] <Chipaca> mvo: ah, i missed that, perfect
[13:45] <mvo> Chipaca: i.e. it should work end-to-end (except it does not spelling fixes yet)
[13:45] <Chipaca> mvo: yep, looks fine (almost exactly what i would've done)
[13:46] <Chipaca> i'll review in depth in a bit
[13:46]  * Chipaca -> break, first
[13:46] <zyga-ubuntu> sun is about to set and I dind't have lunch yet
[13:46] <zyga-ubuntu> tomorrow I'll schedule a walk while it's still bright
[13:47] <zyga-ubuntu> and move lunch to post-call
[13:47] <zyga-ubuntu> now food :)
[13:48] <ackk> mvo, success! init works
[13:48] <zyga-ubuntu> great work guys!
[13:48] <ackk> maas doesn't, but that's another issue
[13:48] <zyga-ubuntu> :-)
[13:49] <ackk> mvo, zyga-ubuntu, thanks for the support :)
[13:49] <zyga-ubuntu> first base-18 snap that almost runs ;)
[13:49] <ackk> mvo, do you think you can push to edge once the distro-info and zoneinfo changes are merged?
[13:49] <ackk> zyga-ubuntu, yeah :)
[13:50] <ackk> is /sbin/ip in the xenial snap?
[13:50] <zyga-ubuntu> no
[13:53] <mborzecki> guys, is there a valid case when a local client is doing a POST to /v2/login with user data *and* sets an Authorization header?
[13:53] <zyga-ubuntu> hmmm
[13:53]  * zyga-ubuntu doesn't know what authorization header does
[13:53] <zyga-ubuntu> maybe to login as someone else?
[13:53] <mborzecki> pedronis: mvo: that's probably for you ^^
[13:54] <pedronis> that's how we send the local macaroon
[13:54] <pedronis> it would help detect a re-login
[13:54] <pedronis> I suppose
[13:54] <mborzecki> hmm then the user.Email from state should be the same as in body login data, right?
[13:57] <mborzecki> some context maybe, so the user is logging in, there's a macaroon, username and an email, say foo@bar.com in ~/.snap/auth.json, then the user does snap login --email bar@bar.com, gets a macaroon, but the email in the response is foo@bar.com instead of bar@bar.com
[13:58] <pedronis> that can happen I suppose if one doesn't use their main SSO email
[13:59] <pedronis> matiasb might tell more about that
[14:00] <matiasb> mborzecki, pedronis, right, I think the email in the response is the preferred SSO email address
[14:00] <ackk> zyga-ubuntu, is something different WRT /bin and /sbin if you use a base?
[14:01] <ackk> zyga-ubuntu, what I see in the /sbin and /bin in my snap (from the prime dir) is not there if I snap run --shell
[14:01]  * pstolowski lunch
[14:01] <zyga-ubuntu> ackk: /bin and /sbin should come directly from the designated base snap (here base-18)
[14:01] <zyga-ubuntu> ackk: what do you see?
[14:01] <zyga-ubuntu> ackk: more precisely
[14:01] <ogra_> if it is in your prime dir it sould be in §SNAP/bin and $SNAP/sbin
[14:01] <zyga-ubuntu> ackk: / should be from your base snap
[14:01] <ackk> zyga-ubuntu, but can a snap add stuff to them?
[14:02] <zyga-ubuntu> ackk: with layouts, that's coming soon but not in master yet
[14:02] <ogra_> god forbid !
[14:02] <ogra_> :)
[14:02] <zyga-ubuntu> ackk: https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471
[14:02] <ackk> so what we have for xenial can't work with the base :/
[14:02] <zyga-ubuntu> ackk: can you expand/explain?
[14:02] <zyga-ubuntu> ackk: you get to choose the base you want
[14:02] <zyga-ubuntu> ackk: you switched to bionic, is that not good?
[14:03] <mvo> yeah, curious as well what is missing in base-18
[14:03] <zyga-ubuntu> mvo: I suspect ackk will want /sbin/ip
[14:03] <ackk> zyga-ubuntu, mvo yes, the maas snap installs/symlinks a lot of stuff in /bin/ and /sbin, which works in xenial
[14:03] <mborzecki> matiasb: pedronis: sorry, i probably didn't make that clear, i have a local macaroon, id and email in ~/.snap/auth.json (local for snapd), now i login with a different email address assigned to a different sso account, what I see in snapd is the local email not getting updated for the user with that ID in state.json and thus the ~/.snap/auth.json email does not get updated either
[14:03] <zyga-ubuntu> ackk, mvo: note that the base apparmor template and all the interfaces don't care (know) about bases yet so we may need to do more work to allow -18 specific or -16 specific functionality
[14:04] <zyga-ubuntu> ackk: how can it work in xenial and not in bionic based snap (I assume it's still a snap and not something else)
[14:04] <ogra_> classic ?
[14:04] <ackk> zyga-ubuntu, xenial without base and bionic with base yes
[14:04] <zyga-ubuntu> ackk: is it a classic snap?
[14:04] <ackk> no, it's --devmode
[14:04] <zyga-ubuntu> ackk: in devmode /usr/bin is still a read only squashfs
[14:04] <zyga-ubuntu> ackk: can you show me what you do?
[14:05] <ackk> zyga-ubuntu, https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic-fixes
[14:05] <zyga-ubuntu> ackk: and where do you put anything in /usr/bin or /bin?
[14:05] <pedronis> mborzecki: well,   updating makes sense only if you have a valid ID as determined by the local macaroon
[14:05] <ackk> zyga-ubuntu, stage-packages: does (specifically because iproute2)
[14:06] <zyga-ubuntu> ackk: stage packages are unpacked to $SNAP/ no to /
[14:06] <zyga-ubuntu> ackk: that hasn't changed at all
[14:06] <ackk> zyga-ubuntu, https://paste.ubuntu.com/26353268/ (from the prime/ dir)
[14:06] <zyga-ubuntu> ackk: maybe some path settings are wrong, this should not behave any different than base-18-based snap
[14:06] <zyga-ubuntu> ackk: but all of the prime dir is mounted at $SNAP (/snap/maas/1234)
[14:07] <zyga-ubuntu> ackk: you cannot add anything to real /usr/bin
[14:07] <pedronis> mborzecki: otherwise updating has no clear target
[14:07] <pedronis> but I don't know how that code looks like at all
[14:07] <zyga-ubuntu> ackk: all I'm saying is that you don't have any new limitations
[14:07] <ackk> zyga-ubuntu, mhm, then it might be a path issue
[14:07] <zyga-ubuntu> ackk: look at $PATH
[14:07] <ackk> zyga-ubuntu, I see, then I'll dig further
[14:07] <zyga-ubuntu> ackk: maybe snapcraft did something before and now you need to do it manualyl
[14:07] <zyga-ubuntu> *manually
[14:08]  * ackk checks the xenial snap
[14:14] <ackk> zyga-ubuntu, /sbin/ip *is* there in  xenaial core
[14:15] <zyga-ubuntu> ackk: indeed, my find was ... weird?
[14:15] <ackk> zyga-ubuntu, I get permission denied trying to run it with snap run --shell hello-world, but maas can since it's a devmode snap
[14:15]  * zyga-ubuntu wonders why: find /snap-core-current -name ip 
[14:15] <zyga-ubuntu> didn't see it
[14:15] <zyga-ubuntu> wehh
[14:15]  * zyga-ubuntu wonders why: find /snap/core/current -name ip 
[14:16] <sergiusens> hello
[14:17] <ackk> zyga-ubuntu, I guess we should really use $SNAP/bin/ip
[14:17] <zyga-ubuntu> yes
[14:17] <ackk> zyga-ubuntu, IOW prepend $SNAP/sbin $SNAP/bin to our paths
[14:17] <zyga-ubuntu> ackk: until you can splay $SNAP/bin/ip to /bin/ip with layouts that is
[14:21]  * mborzecki off to pick up the gkids
[14:31] <kalikiana> sergiusens: o/
[14:32]  * kalikiana going on lunch break shortly
[14:34] <matiasb> mborzecki, after taking a look, I see your point: it seems the local/state email information is not updated when you switch to a different SSO account without logout, only the auth bits are updated (ie. the macaroons); pedronis, fyi too <-
[14:48] <mup> PR core#71 opened: live-build: make /lib64/ld-linux-x86-64.so.2 a relative link <Created by mvo5> <https://github.com/snapcore/core/pull/71>
[14:53] <elopio> good morning
[15:01] <mborzecki> matiasb: right, i've made a change to update the users's email, the whole diff is something in the lines of https://paste.ubuntu.com/26353503/
[15:01] <mup> PR snapd#4460 closed: daemon: store email, ID and macaroon when creating a new user <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4460>
[15:02] <mup> Issue snapcraft#1816 closed: snapcraft update won't fetch from `SNAPCRAFT_PARTS_URI` <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1816>
[15:02] <mup> PR snapcraft#1856 closed: remote_parts: Use hashed folder based on parts URI <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1856>
[15:04] <ackk> zyga-ubuntu, mvo  after fixing hardcoded path issues with /sbin/ip, maas works!
[15:04] <ackk> quick, ship base-18! :)
[15:04] <matiasb> mborzecki, yeah, makes sense to me
[15:04] <mvo> ackk: ha! lets hope the builders get back online soon
[15:05] <mborzecki> matiasb: thanks
[15:05] <zyga-ubuntu> ackk: ahead of 18.04
[15:05] <zyga-ubuntu> that'd be a first
[15:05] <zyga-ubuntu> good work :)
[15:06] <mvo> ackk: yeah, nice job!
[15:22] <tedg> Hmm, okay. I guess builders being down is why the discord snap isn't getting built.
[15:33] <kalikiana> re
[15:34] <zyga-ubuntu> I need a break, I'm so sleepy
[15:34] <zyga-ubuntu> 16:30 - night
[15:34] <zyga-ubuntu> I hate north
[15:35] <kalikiana> zyga-ubuntu: never go to Finland :-P
[15:36] <zyga-ubuntu> kalikiana: or just in the summer
[15:36]  * kalikiana likes Finland but struggled with the lack of sun in winter
[15:44] <sergiusens> zyga-ubuntu come to South America; this was my weeked -> https://www.instagram.com/p/BdpvFoUFBVH/?taken-by=sergiusens
[15:51] <zyga-ubuntu> sergiusens: I would never leave and my wife would hate my and my kids would cry
[16:01] <Chipaca> mvo: that progress spinner doesn't look too good on a linux vt :-(
[16:14] <zyga-ubuntu> Chipaca: linux vt is a bit limited
[16:14] <zyga-ubuntu> Chipaca: you get to have 256 characters in two sets
[16:14] <Chipaca> zyga-ubuntu: i know
[16:14] <Chipaca> zyga-ubuntu: looks like if it's important, it needs to be ascii for the terminal
[16:14] <Chipaca> vt i mean
[16:15]  * Chipaca unsure what to do
[16:16] <zyga-ubuntu> Chipaca: curious, can you tweet a photo please?
[16:17] <zyga-ubuntu> Chipaca: one more question is "how do you know where you are" (which is super hard to answer actually)
[16:17] <mup> Issue snapcraft#1712 closed: Tutorial for circle-ci <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1712>
[16:17] <mup> PR snapcraft#1857 opened: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
[16:17] <Chipaca> zyga-ubuntu: it depends on what font you're using on the terminal; you might get a square, *or*, a rhombus
[16:17] <zyga-ubuntu> Chipaca: but my recommendation is to forgo any fanciness
[16:17]  * Chipaca takes his bowtie off
[16:17] <zyga-ubuntu> Chipaca: yes, though on the terminal we could actually ask and even load the right font
[16:18] <Chipaca> zyga-ubuntu: there is no font with braille :-)
[16:18] <zyga-ubuntu> Chipaca: ioctl_console(2)
[16:18] <zyga-ubuntu> Chipaca: my pet project desires me to explore that man page
[16:18] <Chipaca> zyga-ubuntu: console_ioctl but yes
[16:18] <zyga-ubuntu> Chipaca: no, it's actually ioctl_console, I have it open
[16:19] <Chipaca> zyga-ubuntu: in xenial it's console_ioctl(4)
[16:19] <zyga-ubuntu> oh, interesting
[16:19] <Chipaca> zyga-ubuntu: and there is no ioctl_console(2)
[16:19] <zyga-ubuntu> I wonder if that's just a rename
[16:19] <zyga-ubuntu> at some point systemd wanted to provide a KMS based console with real support for everything
[16:19] <zyga-ubuntu> but I think that died or at least isn't deployed
[16:20] <kalikiana> kyrofa: elopio FYI snapcraft#1639 is green now, with the revert - also snapcraft#1857 is the next piece of the puzzle for updated "on" semantics
[16:20] <mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
[16:20] <mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
[16:20] <kyrofa> kalikiana, so you don't see the weird test waffling locally anymore?
[16:20] <Chipaca> zyga-ubuntu: we could make snapd require jfbterm
[16:21] <zyga-ubuntu> Chipaca: a hard sell for servers
[16:21] <kalikiana> kyrofa: Neither locally nor on Travis (both hit it before)
[16:21] <zyga-ubuntu> Chipaca: can we just do /|\- style animation?
[16:21] <Chipaca> zyga-ubuntu: i prefer .oOo, but, yes
[16:22] <Chipaca> (mostly because it bothers me how / and \ don't have the same width)
[16:22] <zyga-ubuntu> Chipaca: the consequence of that 7 bit space with one bit of unspecified glyphs
[16:22] <zyga-ubuntu> Chipaca: I wonder if the B-set is populated?
[16:23] <Chipaca> zyga-ubuntu: showconsolefont
[16:23] <Chipaca> zyga-ubuntu: answer: yes, but `dpkg-reconfigure console-setup` is all about changing that second half
[16:23] <zyga-ubuntu> Chipaca: second half as in 9th bit?
[16:24] <zyga-ubuntu> Chipaca: I don't mean 128..255
[16:24] <zyga-ubuntu> but 256..512
[16:25] <zyga-ubuntu> I meant greetings BTW
[16:25] <Chipaca> zyga-ubuntu: it depends on what font you're loading, if you have that or not
[16:25] <zyga-ubuntu> hmm
[16:25] <Chipaca> zyga-ubuntu: but showconsolefont shows you
[16:25] <zyga-ubuntu> I'm confused now
[16:25] <zyga-ubuntu> look at the thing I tweeted
[16:26] <sergiusens> Chipaca zyga-ubuntu we took a lot of criticism for our progress bar not working correctly on emacs
[16:26] <mup> PR snapcraft#1858 opened: Import run so bin/snapcraft can work <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1858>
[16:26] <Chipaca> sergiusens: whose progress bar? when?
[16:26] <Chipaca> sergiusens: in the emacs terminal, or the emacs shell?
[16:26] <zyga-ubuntu> sergiusens: interesting, so more limitations of the vty thing that emacs supplies
[16:27] <kalikiana> elopio: Hey! Can you have a look at snapcraft#1858 ? I found myself very confused to find integration tests don't run against git anymore
[16:27] <mup> PR snapcraft#1858: Import run so bin/snapcraft can work <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1858>
[16:27] <Chipaca> zyga-ubuntu: i did test ansimeter in emacs :-)
[16:28] <zyga-ubuntu> it's good that we don't have to test it in vim ;-)
[16:28] <Chipaca> ah, dunno how to do that :-)
[16:28] <zyga-ubuntu> Chipaca: since I'm not a emacs person, how do I run emacs and open a terminal to test my stuff?
[16:28] <Chipaca> zyga-ubuntu: in emacs, M-x term opens a terminal
[16:28] <Chipaca> zyga-ubuntu: M-x shell runs a shell
[16:29] <sparkiegeek> zyga-ubuntu: snap install emacs-tealeg
[16:29] <mborzecki> M-x eshell ftw
[16:29] <sparkiegeek> TMTOWTDI :)
[16:29] <mvo> ogra_: thanks for your suggestion about arm64, what does the ld symlink looks like there?
[16:30] <zyga-ubuntu> mvo: I think snapcraft has a list of those
[16:30] <Chipaca> mborzecki: ouch, the ansimeter doesn't fare too well in eshell
[16:30] <Chipaca> it chooses to do reverse as a colour instead of reverse
[16:30] <sergiusens> zyga-ubuntu mvo linkers? yes indeed
[16:30] <zyga-ubuntu> yes
[16:31] <zyga-ubuntu> sergiusens: and learned the hard way for each arch
[16:31] <ogra_> mvo, ogra@dragonboard:~$ ls -l /lib/ld-linux-aarch64.so.1
[16:31] <ogra_> lrwxrwxrwx 1 root root 28 Jun 16  2017 /lib/ld-linux-aarch64.so.1 -> aarch64-linux-gnu/ld-2.23.so
[16:31] <ogra_> ogra@dragonboard:~$
[16:31] <sparkiegeek> show_fancy_progress = False if 'EMACS' in os.environ else show_fancy_progress
[16:31] <Chipaca> mborzecki: eshell also doesn't respect the "turn off the cursor" escape
[16:31] <sergiusens> zyga-ubuntu mvo https://github.com/snapcore/snapcraft/blob/master/snapcraft/_options.py#L31
[16:31] <Chipaca> mborzecki: booo
[16:32] <Chipaca> (neither does eterm, fwiw)
[16:32] <Chipaca> ANYhow
[16:32] <sergiusens> zyga-ubuntu mvo and here is the logic to unpack it https://github.com/snapcore/snapcraft/blob/master/snapcraft/_options.py#L226
[16:32] <zyga-ubuntu> man, I'm running emacs
[16:32]  * Chipaca hugs the braille spinner, and sends it into the void
[16:33] <mvo> ogra_: oh, this link is already relative?
[16:33] <sparkiegeek> zyga-ubuntu: you think you're running emacs, in reality, emacs is running you
[16:34] <mborzecki> well, it does have some killer features, org-mode, magit, elisp
[16:35] <mborzecki> wish it was more stable with ediff though, sometimes it just starts spinning and takes 100% cpu :/
[16:36] <sparkiegeek> mborzecki: not forgetting the builtin psychotherapist, and  M-x butterfly
[16:45] <zyga-ubuntu> what is that, I just ran it
[16:46] <Chipaca> zyga-ubuntu: it randomizes your files, for extra productivity
[16:46] <Chipaca> the butterfly effect and all that
[16:47] <elopio> kalikiana: yes, weird. I will try to bisect it to see what caused the problem.
[16:53] <mup> PR snapcraft#1859 opened: adding option to decompress tar.lzma cleanly <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1859>
[16:56] <kalikiana> elopio: Thanks!
[16:57]  * kalikiana wrapping up for today
[16:58] <ackk> mvo, I'm getting a "setlocale: No such file or directory" error message when I run virsh (although the program itself seems to works)
[16:58] <ackk> mvo, is it something that also needs adding to the base?
[16:58] <zyga-ubuntu> ackk: base snaps don't ship any locale
[16:58] <zyga-ubuntu> ackk: I'd ignore that _for now_; it's a big topic for us to explore IMO
[16:58] <zyga-ubuntu> ackk: with no (apparently) easy answers
[16:59] <ackk> I see
[17:25] <zyga-ubuntu> Pharaoh_Atem: selinux-policy now builds straight from github
[17:25] <zyga-ubuntu> maybe we could merge the snapd policy there and only keep the package for any unmerged TODOs
[17:25] <Pharaoh_Atem> maybe
[17:26] <Pharaoh_Atem> but it has to work first
[17:26] <Pharaoh_Atem> and it doesn't
[17:26] <Pharaoh_Atem> snapd still needs SELinux awareness
[17:27] <zyga-ubuntu> well, little by little, most software isn't selinux aware even if there's a selinux policy covering it
[17:27] <zyga-ubuntu> I think those are orthogonal
[17:27] <Pharaoh_Atem> in most cases, they are
[17:27] <Pharaoh_Atem> in this case, no
[17:27] <Pharaoh_Atem> snapd itself does security things itself
[17:27] <Pharaoh_Atem> my hope was that the selinux policy would be augmented by snapd itself generating policies to apply with the defined labels
[17:27] <zyga-ubuntu> yes but not with selinux so it's not a blocker in my eyes
[17:28] <zyga-ubuntu> Pharaoh_Atem: apart form the policy we need to figure out FS relableling and nobody is working on that
[17:28] <zyga-ubuntu> Pharaoh_Atem: lots of things to explore
[17:31] <Pharaoh_Atem> well, I can talk to Lukas about it
[17:32] <zyga-ubuntu> worth a try
[17:32] <zyga-ubuntu> not saying we have to
[17:32] <zyga-ubuntu> but looks like one less thing to package (eventually)
[17:32]  * Pharaoh_Atem shrugs
[17:32] <Pharaoh_Atem> we'd have to keep it for CI testing anyway
[17:33] <zyga-ubuntu> yes, I suppose so
[17:35] <zyga-ubuntu> Pharaoh_Atem: I'm feeling excited today
[17:35] <zyga-ubuntu> Pharaoh_Atem: my eternal task looks close to being done
[17:35] <zyga-ubuntu> Pharaoh_Atem: I actually wonder what I'll do next (plenty of things to do but not sure as I haven't discusse that yet0
[18:03]  * Chipaca <- stupid poo-face
[18:03] <zyga-ubuntu> what happened?
[18:03] <mup> PR snapd#4450 closed: snap: support `command-not-found` symlink for `snap advise-command` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4450>
[18:04] <Chipaca> zyga-ubuntu: twice i brought up an ubuntu-core in linode to test something, before realising that the reason it was failing in a different place than in travis was because i had some stuff lying around here that wasn't in git
[18:05] <zyga-ubuntu> doh ;)
[18:05] <Chipaca> quite
[18:06] <zyga-ubuntu> it's good that we lave linode though
[18:06] <zyga-ubuntu> imagine doing that on our laptops 24/7
[18:08] <Chipaca> zyga-ubuntu: http://i.imgur.com/eVNrdel.gifv
[18:08] <mup> PR snapd#4462 closed: progress: switch ansimeter's Spin() to use a spinner <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4462>
[18:09] <zyga-ubuntu> lol
[18:09] <zyga-ubuntu> I wonder if movie designers have a meme-ist among permanent staff
[18:10] <zyga-ubuntu> ok, I should _probably_ break now
[18:11] <zyga-ubuntu> ttyl
[18:11] <Chipaca> zyga-ubuntu: I know that a lot of regulars on /r/HighQualityGifs work in the industry
[18:13] <zyga-ubuntu> I'm glad I don't do reddit
[18:14] <zyga-ubuntu> if I did I would have even less live
[18:14] <zyga-ubuntu> life
[18:14] <zyga-ubuntu> man, see what kind of mistakes I make
[18:14] <zyga-ubuntu> Chipaca: question, do you have any magic command that shows me coverage in a browser and that updates as I edit code?
[18:15] <zyga-ubuntu> I run: ls *.go | entr -c go test
[18:15] <zyga-ubuntu> but I'd like that to do live coverage updates
[18:15] <zyga-ubuntu> I also have an alias: ggg
[18:15] <zyga-ubuntu> go test -cover -coverprofile=coverage.out && go tool cover -html=coverage.out
[18:15] <zyga-ubuntu> but that opens new tab in firefox
[18:15] <zyga-ubuntu> ideally it'd overlay in $editor (but that's fancy)
[18:17] <Chipaca> zyga-ubuntu: uh
[18:17] <Chipaca> zyga-ubuntu: maybe? not very magic though
[18:18] <Chipaca> zyga-ubuntu: go test -coverprofile .coverage/profile.out -v ./snap/squashfs/ && GOPATH=~/canonical/snappy go tool cover -o /tmp/coverage.html -html=.coverage/profile.out
[18:18] <Chipaca> zyga-ubuntu: and then i open /tmp/coverage.html in the browser
[18:18] <zyga-ubuntu> yeah but what would keep it live?
[18:19] <Chipaca> zyga-ubuntu: "keep it live" no, but it's usually fast enough
[18:19] <Chipaca> and because i'm explicitly telling it to write to that file it doesn't open a new page every time, which means it stays on the same file
[18:20] <Chipaca> beyond that, no
[18:20] <Chipaca> zyga-ubuntu: maybe goland does that?
[18:20] <Chipaca> zyga-ubuntu: (snap install goland?)
[18:20] <zyga-ubuntu> oh
[18:21] <zyga-ubuntu> I'll look, just curious
[18:21] <Chipaca> zyga-ubuntu: https://www.jetbrains.com/go/features/ says "If you run your code with a coverage instruction, the IDE collects the data and displays it in both the aggregated view and per statement in the Editor."
[18:21] <zyga-ubuntu> ooooh
[18:21] <zyga-ubuntu> man
[18:22] <zyga-ubuntu> I will probably sell vim
[18:22] <zyga-ubuntu> and get into one of those
[18:24] <Chipaca> pedronis: hah! i was wondering about that failure
[18:24] <Chipaca> pedronis: couldn't you also have fixed it by feeding jq from stdin instead of asking it to open the file?
[18:37] <zyga-ubuntu> Chipaca: which failure?:
[18:37] <sergiusens> kyrofa elopio hey, I have updated snapcraft#1850 can you please take another look?
[18:37] <mup> PR snapcraft#1850: pluginhandler: patch and handle elf files on glibc mismatch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1850>
[18:43] <pedronis> Chipaca: yes, but we do install with --devmode elsewhere
[18:49] <pedronis> what I see true is that given the change I could have simplified some other lines
[18:51] <pedronis> Chipaca: prepare.sh ,  auto-refresh/task.yaml and this have that choice to make
[18:58] <sergiusens> elopio would be nice if you follow up on snapcraft#1849
[18:58] <mup> PR snapcraft#1849: tests: add snap not found tests <codein> <Created by daniellimws> <https://github.com/snapcore/snapcraft/pull/1849>
[19:15] <nacc> should /var/lib/snapd/hostfs have contents, generally?
[19:18] <zyga-ubuntu> nacc: it dpeends on one's perspective
[19:18] <zyga-ubuntu> nacc: on your regular host it should be empty
[19:19] <zyga-ubuntu> nacc: from a snap's POV it should contain your hosts' root filesystem (with some exceptions)
[19:19] <zyga-ubuntu> nacc: naturally confinement is in the way so you won't see that unless in devmode
[19:19] <zyga-ubuntu> nacc: but some things are "brought over" from there (notably fonts)
[19:22] <nacc> zyga-ubuntu: got it
[19:50] <zyga-ubuntu> nacc: :-)
[20:03] <kyrofa> sergiusens, I'm testing out this libc branch
[20:04] <sergiusens> kyrofa great; I tried with https://pastebin.ubuntu.com/26355121/ from bionic
[20:05] <kyrofa> And I'm realizing is_linker_compatible isn't quite doing what I thought it was doing. It's comparing the version of the linker against the glibc version, which is vastly different, is it not?
[20:05] <sergiusens> kyrofa the linker is part of glibc
[20:05] <kyrofa> I ran it on zesty, which uses gcc 2.4, and it compared that against 2.23 and decided it was happy with it
[20:05] <kyrofa> Not gcc, sorry
[20:06] <kyrofa> I expected it to grab the newer glibc, but it didn't
[20:06] <sergiusens> kyrofa zesty didn't bump the glibc requirement, that's why all our adt tests still pass there :-)
[20:06] <sergiusens> you need artful or bionic to trigger this
[20:06] <kyrofa> Argh
[20:07] <sergiusens> kyrofa 2.23 linker is still good for the linker in zesty (even if the version is greater).
[20:08] <sergiusens> kyrofa if everything is correct, adt for bionic and artful will pass with glaring colours
[20:09] <kyrofa> Man, my connection to the image server is brutal today. I'm getting like 20k
[20:11] <zyga-ubuntu> curious, I saw uber-slow 90K to archive.u.c
[20:31] <sergiusens> kyrofa tough luck I guess; hope you like my approach to testing with runnables btw; I think I want us to move down that path for every other thing we have
[20:31] <kyrofa> Seems python-apt requires libdpkg-perl on artful
[20:33] <kyrofa> sergiusens, I do indeed. More work upfront, but definitely testing more
[20:49] <sergiusens> kyrofa heh, that dep rings a bell; oh, when installing from debs; probably a bad dep as well; I saw that too
[20:49]  * sergiusens will bbl later in the evening
[20:49] <kyrofa> sergiusens, I was using a venv, so we'll just need to add it to HACKING.md
[20:50] <kyrofa> Seems that it needs to access /usr/share/dpkg/no-pie-compile.specs
[21:08] <sergiusens> kyrofa yes; I ran into that as well, I recall now
[21:09]  * sergiusens decided to not leave
[21:10] <sergiusens> kyrofa the only reason I didn't move it into fixtures_setup is because it is so big and I believe it has the wrong name
[21:14] <sergiusens> kyrofa I suspect travis has kernel patches for Meltdown and is the reason for the timeouts we see now?
[21:15] <kyrofa> sergiusens, hmm, you think it has that much of an impact? That would suck
[21:15] <kyrofa> I didn't anticipate that it would be much
[21:15] <kyrofa> Also... WE don't even have mitigation yet. How do they?
[21:18] <sergiusens> kyrofa I thought GCE already patched and java took the biggest hit; coincidentally we timeout while building with ant in one task and dotnet in another (which I suspect would take a similar hit)
[21:19] <sergiusens> I haven't done any deep analysis or anything though so refuting what I say should be rather easy ;-)
[21:20] <kyrofa> Innnteresting...
[21:54] <mup> PR snapcraft#1858 closed: Import run so bin/snapcraft can work <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1858>
[21:57] <mup> PR snapcraft#1859 closed: adding option to decompress tar.lzma cleanly <Created by heesen3> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1859>
[22:59] <nacc> i forget who suggested it to me, but the idea of bind-mounting writable directories over a classic snap's filesystem is going to speed up debugging incredibly for me
[23:12] <mup> PR snapcraft#1860 opened: setup: simplify bin/snapcraft and correct tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1860>
[23:13] <sergiusens> kyrofa elopio ^
[23:14] <sergiusens> kyrofa snapcraft.tests.integration.plugins.test_ant_plugin.AntPluginTestCase.test_build_ant_plugin takes 15 minutes for me locally. Mind checking?