[03:04] <mup> PR snapcraft#1925 closed: elf: cache crawled files <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1925>
[03:07] <mup> PR snapcraft#1923 closed: mypy: update to 0.560 <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1923>
[06:08] <mborzecki> morning
[06:18] <zyga> hey hey
[06:18] <mborzecki> zyga: hey
[06:19] <zyga> darn tests
[06:20] <zyga> I wish someone would go through the prepare/restore process and made restore really purge stuff
[06:20] <zyga> and made prepare install a cached copy of core
[06:20] <zyga> it feels like tests are leaking all the time
[06:20] <zyga> leaving junk around
[06:29] <mborzecki> ideally take a snapshot of filesystem before the test, restore after the test, don't know if there are tools to do that
[06:30] <zyga> mborzecki that's also interesting, yeah
[06:30] <zyga> but in all honesty, purge would be a simple approach that ought to mostly work
[06:30] <zyga> I worry about random places less than about our essential files
[06:31] <zyga> I will do an experiment, I have some old branches that did full caching of all the snaps used for testing
[06:31] <zyga> but I can simplify that to just one snap (core) and purge+install package, install core
[06:31] <zyga> I really don't like how prepare and restore are swapped in our setup
[06:31] <zyga> where restore prepares
[06:31] <zyga> and prepare does nothing much
[07:24] <mvo> zyga: hey, good morning! whats up?
[07:24] <zyga> hey
[07:25] <zyga> nothing major so far, just me being grumpy about tests that clearly run in some corrupted state
[07:25] <zyga> I'm doing code reviews
[07:25] <mvo> zyga: aha, so master is in un-happy land?
[07:25] <mvo> zyga: at random times
[07:25] <mvo> ?
[07:26] <zyga> I think master is fine but our test suite is not perfect
[07:26] <zyga> I tried to fix it a few times but without major success, I'll try to push forward slightly today
[07:26] <mvo> ok
[07:28] <zyga> mvo https://github.com/snapcore/snapd/pull/4600 needs deconflicting
[07:28] <mup> PR #4600: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
[07:28] <mvo> zyga: it needs a +1 from niemeyer about the concept
[07:29] <mvo> zyga: I mean, its not clear that we want this (and if so in what way)
[07:29] <mvo> zyga: (I personally think so but thats just me :)
[07:29] <zyga> mborzecki https://github.com/snapcore/snapd/pull/4571 has unaddressed comments but could land shortly
[07:29] <mup> PR #4571: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
[07:29] <mborzecki> zyga: i'll be coming back to it once i'm done with timer services
[07:30] <mborzecki> mvo: morning
[07:30] <zyga> thank you!
[07:31] <mvo> hey mborzecki, good morning! how are you?
[07:31] <mborzecki> mvo: grumpy, found a bug in timer schedules :)
[07:31] <zyga> oh? :)
[07:32] <mvo> mborzecki: meeeh, but better you than our users. how bad is it? (2.31.1 material?)
[07:33] <mborzecki> eg. mon1-tue2,10:00-12:00 is a window 10 to 12, from 1st monday to the 2nd tuesday, well it doesn't work this way, it skips wednesday to sunday :/
[07:36]  * mvo nods
[07:38] <mvo> mborzecki: is there a fix yet? and if so, how invasive is it?
[07:38] <mborzecki> mvo: still looking into it
[07:39] <mvo> mborzecki: ok, keep me updated please
[07:49] <zyga> mvo is trivial if you want to look https://github.com/snapcore/snapd/pull/4673 :-)
[07:49] <mup> PR #4673: interfaces/mount: generate per-user mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4673>
[07:49] <zyga> (this is chopped from the user mounts PR)
[07:51] <mvo> zyga: ok
[07:54] <kalikiana> good morning
[07:56]  * zyga -> afk for 40 minutes
[08:05] <mup> PR snapd#4668 closed: store: revert PR#4532 and do not display displayname <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4668>
[08:41] <mup> PR snapd#4674 opened: packaging: fix build on sbuild <Created by mvo5> <https://github.com/snapcore/snapd/pull/4674>
[09:08] <Chipaca> moin moin
[09:08] <Chipaca> did somebody pull the plug on the dc?
[09:20] <Chipaca> JamieBennett: mvo: I can't access anything in the dc. Is my ISP sucking at its job, or is it everybody? this thing thinks it's up: https://down.com/?q=https%3A%2F%2Fsnapcraft.io
[09:21] <JamieBennett> snapcraft.io is up for me
[09:22] <mvo> Chipaca: I can log into people.c.c so its not fully down
[09:22] <zyga> hey Chipaca
[09:22] <zyga> Chipaca works for me
[09:23] <zyga> Chipaca want to VPN through my network? ;-)
[09:23] <zyga> Chipaca thanks for the review yesterday
[09:23] <zyga> I addressed all of those and merged that one
[09:25] <Chipaca> looks like it's the vpn that's crashed
[09:25] <Chipaca> turned that off and i'm in
[09:26] <zyga> Chipaca can I quickly drag you into another review?
[09:26] <zyga> builds on the mount spec change for user mount entries
[09:27] <zyga> this time the mount backend spits out a new file based on those
[09:27] <zyga> very mechanic and shorty
[09:27] <zyga> *short
[09:27] <Chipaca> zyga: mostly (late) in the town hall
[09:27] <Chipaca> zyga: but sure
[09:27] <zyga> https://github.com/snapcore/snapd/pull/4673/files :-)
[09:27] <mup> PR #4673: interfaces/mount: generate per-user mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4673>
[09:27] <zyga> thank you!
[09:39] <Chipaca> zyga: duuuude
[09:40] <zyga> hmm?
[09:41] <Chipaca> zyga: two chunks of code that are exactly the same
[09:41] <zyga> aaaaw, ok
[09:41] <zyga> I'll dedupe it :)
[09:41] <zyga> thanks for pointing that out
[09:43] <Chipaca> zyga: you don't even need a helper, just a loop
[09:56] <zyga> Chipaca pushed, I opted to do a helper in the end, have a look
[09:56] <Chipaca> yeah, the fstab vs user-fstab would've made the loop clunky i guess
[09:56] <Chipaca> at least without a big refactor :-)
[10:00] <zyga> thanks John
[11:11] <mborzecki> mvo: one fix for schedules comint up shortly
[11:11] <mborzecki> what an annoying edge case though
[11:13] <zyga> hmm
[11:13] <zyga> + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc
[11:13] <mup> PR snapd#4675 opened: timeutil: fix scheduling on nth weekday of the month <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4675>
[11:14] <zyga> I'm wondering if we have anew problem
[11:14] <zyga> or if I broke it somehow (but unlikely since this PR is about mounts)
[11:15] <mborzecki> zyga: what's the problem?
[11:15] <zyga> + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc
[11:15] <zyga> hwclock: Unable to connect to audit system
[11:15] <zyga> hmm
[11:15] <zyga> look at https://api.travis-ci.org/v3/job/341809848/log.txt
[11:15] <zyga> I bet this is not related to my PR
[11:15] <zyga> and it is a genuine problem elsewhere
[11:16]  * mvo hugs mborzecki
[11:17] <mborzecki> zyga: seccomp?
[11:17] <zyga> yes, this is seccomp for sure
[11:17] <zyga> the bad system call thing is
[11:17] <zyga> the one about audit is more curious
[11:17] <zyga> looks like apparmor
[11:17] <zyga> which would be "bugs all over the place"
[11:18] <zyga> hmm hmm but the same debug log below shows no seccomp or apparmor issues
[11:18] <zyga> broken log?
[11:19] <mborzecki> zyga: there are no denials from apparmor though :?
[11:20] <mborzecki> zyga: what if the rtc does not work in those vms?
[11:20] <zyga> this test didn't fail before
[11:21] <mborzecki> zyga: or /dev/rtc is not a device node, showing would be useful
[11:24] <Chipaca> ooooh, my new keyboard arrived \o/
[11:25] <mvo> speaking of strange errors - https://travis-ci.org/snapcore/snapd/branches shows 2.31 broken in spectacular ways that do not make any sense at all :/
[11:25] <zyga> Chipaca what did you get?
[11:26] <zyga> mvo looking
[11:26] <zyga> + MATCH gadget - on debian 9 this makes no sense
[11:27] <zyga> should this test even run there
[11:27] <zyga> hmmm
[11:28] <mvo> zyga: also it makes no sense because the diff is very small so it can't break like this
[11:28] <mvo> ohwell
[11:28] <Chipaca> zyga: https://twitter.com/chipaca/status/964099012281487360
[11:29] <zyga> woah
[11:29] <zyga> man
[11:29] <zyga> I look forward to seeing you type on this :)
[11:29] <Chipaca> zyga: the firmware is open
[11:29] <Chipaca> zyga: …
[11:29] <Chipaca> i didn't have enough side projects
[11:29] <zyga> how come I didn't follow you yet
[11:30]  * zyga follows chipaca
[11:30] <Chipaca> zyga: probably because i was private for a while
[11:32] <mup> PR snapd#4674 closed: packaging: fix build on sbuild <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4674>
[11:34] <zyga> mborzecki posted a question on 4675
[11:34] <mup> PR snapd#4676 opened: timeutil: introduce helpers for checking it time falls inside the schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4676>
[11:37] <mup> PR snapd#4663 closed: interfaces/builtin: allow MM to access login1 <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4663>
[11:38] <mup> PR snapd#4635 closed: snap: add support for `snap run --gdb` <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4635>
[11:38] <zyga> mborzecki how are arch spread tests doing?
[11:38] <zyga> is that still on hold?
[11:38] <mborzecki> waiting :)
[11:39] <mborzecki> i want to finish timer services for 2.32 first, then come back to autotools in $(top_srcdir)/data and then arch
[11:39] <zyga> ok
[11:42] <mborzecki> zyga: right, so interface-time-control is failing in my pr too
[11:44] <mborzecki> Chipaca: does the keyboard come with the straps to attach each half to a hand? :)
[11:46] <Chipaca> mborzecki: it comes with two different length cables to connect the halves to each other, a rail to connect the two halves into a single thing at adjustable angles, two feet to stand them independently and angled any which way, a screwdriver to take it apart, and a booklet to put it back together again
[11:51] <mborzecki> Chipaca: nice, looking forward to hearing more about your impressions once you use it for a while
[11:51] <Chipaca> impression #0: it's going to have a learning curve
[11:51] <Chipaca> was currently in the zone in a bit of a refactor, put it to one side
[11:53] <mborzecki> wow, it even comes with source code and stuff
[12:17] <zyga> re
[12:17] <zyga> I'm tethered from my phone, not sure why local ISP (both of them) failed
[12:27] <mborzecki> zyga: https://paste.debian.net/1010385/
[12:28] <zyga> netlink
[12:28] <zyga> weird
[12:28] <zyga> thank you for checking that
[12:28] <mborzecki> why is it touching netlink?
[12:28] <zyga> maybe the test started to rely on netlink now
[12:28] <zyga> (for whatever reason)
[12:28] <mborzecki> actually socket(AF_NETLINK, SOCK_RAW, NETLINK_AUDIT) ?
[12:28] <zyga> is hwclock coming from systemd?
[12:28] <zyga> or maybe some nss plugin or something
[12:30] <mborzecki> zyga: just strace on host http://paste.debian.net/1010387/
[12:30] <zyga> yeah
[12:30] <zyga> no netlink
[12:30] <mborzecki> i don't see socket anywhere
[12:32] <mborzecki> zyga: ok, os here's hwclock from the core snap: https://paste.debian.net/1010389/ no clue why it does socket() call
[12:37] <zyga> mborzecki does it do this in stable?
[12:37] <zyga> or just in edge?
[12:38] <mborzecki> zyga: it's edge
[12:38] <mborzecki> let me try stable
[12:38] <zyga> yeah, try stable
[12:38] <zyga> I wonder if it's a regression
[12:38] <zyga> (^H "new feature")
[12:39] <zyga> brb, let me try normal internet again
[12:40] <Son_Goku> zyga, mborzecki, mvo: what do I need from the release/2.31 branch that isn't part of the 2.31 tagged release?
[12:41] <zyga> ok, internet is back
[12:41] <zyga> Son_Goku I think just take all of release/2.31 since that's exactly what it is for
[12:41] <zyga> mvo will do a .1 soon AFAIK
[12:41] <zyga> but you really want to ask mvo about that
[12:41] <Son_Goku> mvo, do you plan on doing a 2.31.1?
[12:43] <mborzecki> damn, random lockup, cursor moving and all, but the rest was frozen
[12:43] <zyga> mborzecki ryzen?
[12:44] <mborzecki> zyga: no, i think it's the damn wifi
[12:45] <mborzecki> it's the 2nd time this happened, and kernel backtrace shows warnings from iwlwifi
[12:46] <Chipaca> perhaps I should lunch
[12:48] <mup> PR snapcraft#1926 opened: Release changelog for 2.39.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1926>
[13:02] <mvo> Son_Goku: there will be a 2.31.1 with some small fixes, probably monday
[13:03] <Son_Goku> mvo, okay, then I won't prepare a snapd update just yet, then
[13:04] <zyga_> mborzecki, ok, I know what's causing this
[13:07] <jdstrand> mborzecki: I don't have any special insight except that the audit system sounds like ne of CAP_AUDIT_READ, CAP_AUDIT_WRITE or CAP_AUDIT_CONTROL and/or NETLINK_AUDIT
[13:08] <jdstrand> zyga_: ^
[13:08] <jdstrand> mborzecki, zyga_: *or* /dev/rtc isn't in the device cgroup
[13:09] <jdstrand> mborzecki, zyga_: no, that should be a different error
[13:13] <jdstrand> zyga: "mborzecki, ok, I know what's causing this"
[13:13] <jdstrand> zyga: what is it?
[13:13] <zyga> util-linux (2.30.1-0ubuntu4.1) artful; urgency=medium
[13:13] <zyga>   * Add --with-audit to rules file and libaudit-dev to build depenedencies.
[13:13] <zyga>     The hwclock needs audit defined in order to create audit records when
[13:13] <zyga>     time is changed. (LP: #1722313)
[13:13] <mup> Bug #1722313: Enable auditing in util-linux. <rls-aa-notfixing> <verification-done-artful> <verification-done-xenial> <verification-done-zesty> <util-linux (Ubuntu):Fix Released by j-latten> <util-linux (Ubuntu Xenial):Fix Released> <util-linux (Ubuntu Zesty):Fix Committed> <util-linux (Ubuntu
[13:13] <mup> Artful):Fix Released> <util-linux (Debian):New> <https://launchpad.net/bugs/1722313>
[13:13] <zyga>  -- Joy Latten <joy.latten@canonical.com>  Sun, 05 Nov 2017 18:14:49 -0600
[13:13] <zyga> change in util-linuxy
[13:13] <jdstrand> so it is what I thought
[13:13] <jdstrand> mborzecki: I don't have any special insight except that the audit system sounds like ne of CAP_AUDIT_READ, CAP_AUDIT_WRITE or CAP_AUDIT_CONTROL and/or NETLINK_AUDIT
[13:13] <jdstrand> zyga: ^
[13:14] <jdstrand> have it plugs netlink-audit
[13:15] <jdstrand> that won't actually give you audit_write though
[13:16] <jdstrand> time-control needs updating
[13:16] <zyga> so we need to add netlink audit snippets to that interface
[13:17] <zyga> jdstrand right?
[13:17] <jdstrand> capability audit_write,
[13:17] <jdstrand> ^ apparmor
[13:17] <zyga> + socket bits I suspect
[13:17] <zyga> but yeah
[13:17] <zyga> (I think it was getting killed by socket syscall)
[13:17] <jdstrand> bind
[13:17] <jdstrand> socket AF_NETLINK - NETLINK_AUDIT
[13:17] <jdstrand> seccomp ^
[13:18] <jdstrand> but wait a second
[13:18] <zyga> thanks!
[13:18] <zyga> jdstrand if you want just send the branch :)
[13:18] <jdstrand> it is probably going to need capability net_admin,
[13:19] <jdstrand> is this on bionic?
[13:19] <zyga> jdstrand no, it's in xenial
[13:19] <jdstrand> oh, sru
[13:19] <zyga> yep
[13:19] <zyga> and it's now present in the core snap in endge
[13:19] <jdstrand> ok. this would affect other distros btw
[13:19] <jdstrand> (if they had strict mode)
[13:19] <zyga> just run strace -e socket /snap/core/current/sbin/hwclock
[13:19] <zyga> indeed
[13:19]  * jdstrand nods
[13:20] <zyga> and compare stable and edge
[13:20] <jdstrand> ok. let me think about this. I don't want to just give out net_admin
[13:20] <zyga> yeah, it sucks
[13:20] <zyga> I wonder if we could *not* give the permission
[13:20] <zyga> so that it gets socket
[13:20] <jdstrand> yeah, that capabilities subsystem has some icky spots
[13:21] <zyga> and doesn't crash
[13:21] <jdstrand> well, I was thinking of adding netlink-audit-control
[13:21] <zyga> but doesn't audit
[13:21] <jdstrand> we want it to audit though
[13:22] <jdstrand> we could add the socket, not the cap, then add both in the -control interface
[13:22] <jdstrand> then it doesn't die, but won't audit until netlink-audit-control is added
[13:22] <jdstrand> that's pretty reasonable
[13:22]  * jdstrand adds to list
[13:23] <zyga> yes, that's very nice
[13:23] <jdstrand> I've got two other investigations to do. I'll send up a PR for this in a bit
[13:31]  * kalikiana going for lunch break, while the poor laptop will have to keep running test cases
[13:32] <mup> PR snapd#4677 opened: cmd/snap: introduce `snap run --timer` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4677>
[13:41] <mup> PR snapd#4678 opened: snap: fix `snap moo` output <Created by mvo5> <https://github.com/snapcore/snapd/pull/4678>
[13:42] <mvo> zyga: keep me updated on the --with-audit issue please
[13:42] <zyga> mvo ack, I think jdstrand is making a PR that will address it now
[13:42] <zyga> I will just review it
[13:43] <mvo> zyga: great, we will need it for 2.31.1 too
[13:43] <zyga> yes, absolutely
[13:43] <Chipaca> mvo: OMG :-)
[13:43] <cachio> mvo, hey, could you please upload the snap test-snapd-physical-memory-control ?
[13:44] <mvo> cachio: ups, forgot that, sure, let me do that now
[13:44] <cachio> mvo, tx
[13:44] <magicaltrout> my google fu is failing me
[13:45] <mvo> cachio: do you have a link
[13:45] <magicaltrout> is there a snapcraft_part_... build directory
[13:45] <mvo> cachio: is it in one of your PRs?
[13:45] <cachio> mvo, https://code.launchpad.net/~snappy-dev/snappy-hub/test-snapd-physical-memory-control
[13:45] <magicaltrout> variable I can use in a snapcraft build ?
[13:45] <mvo> cachio: thanks
[13:45] <cachio> mvo, I did not create a PR yet
[13:45] <cachio> I'm waiting for the snap :)
[14:19] <mup> PR snapd#4679 opened: systemd: add default target for timers <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4679>
[14:19] <mborzecki> trivial PR ^
[14:22] <mup> PR snapd#4680 opened: snap: pass full timer spec in `snap run --timer` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4680>
[14:25] <mborzecki> most of the timer services stuff is open for review now, still need to cut the service wrappers into smaller pieces
[14:26] <mborzecki> afk to pick up the kids
[14:27] <kalikiana> re
[14:38] <mup> PR snapd#4681 opened:  testutil: add File{Matches,Equals,Contains} checkers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4681>
[14:41] <Chipaca> now, where was I?
[14:48] <kalikiana> Chipaca: unicorns? cats?
[14:55] <Chipaca> kalikiana: por qué no los dos?
[14:59] <kalikiana> Always :-D
[15:07] <seb128> why do some of the snaps have several loop mounts?
[15:07] <ogra_> for the same snap file ?
[15:07] <seb128> seems like several revisions are active?
[15:07] <seb128> dunno what you mean by "snap file"
[15:08] <ogra_> (there should always be three revisios of each snap ... and each has a mount)
[15:08] <ogra_> a file ending in .snaop
[15:08] <ogra_> *.snap
[15:08] <seb128> oh ok
[15:08] <seb128> why 3 revisions? can I tell snap that for a particular snap 1 is enough?
[15:08] <ogra_> i dont theink we technically need all of them mounted though
[15:08] <seb128> do they end up using 3 times the space?
[15:08] <ogra_> yes
[15:09] <seb128> :(
[15:09] <ogra_> for rollback etc
[15:09] <seb128> why 3 and not 2?
[15:09] <ogra_> i dont know why 3, 2 technically are enough ... thats a niemeyer question
[15:09] <seb128> k
[15:09] <seb128> thx
[15:14] <Chipaca> 3 revisions
[15:15] <Chipaca> because it leaves you one more revert in case things go bad
[15:15] <Chipaca> seb128: if you need to make space you can remove the revisions you're not using
[15:19] <zyga> re
[15:20] <kalikiana> o/ zyga
[15:20] <zyga> hey hey
[15:21] <seb128> Chipaca, how? snap list doesn't list them
[15:21] <Chipaca> seb128: snap list --all
[15:21] <Chipaca> seb128: and then, snap remove --revision=NNNN thesnap
[15:22] <seb128> Chipaca, thx, that's non obvious as an user of the system :/
[15:22] <Chipaca> seb128: you're trying to do something out of the ordinary
[15:22] <Chipaca> seb128: i'm not sure what part is the non-obvious though
[15:23] <Chipaca> seb128: but it's not surprising that to do advanced things you need to know the advanced things
[15:23] <jdstrand> zyga, mvo: I am now, yes
[15:23] <zyga> cook
[15:23] <zyga> cool :D
[15:24] <seb128> Chipaca, I started from "it's annoying that all those loop mounts show in the "df -h" cmd output, wth is there even 3 mounts for each snap"
[15:24] <jdstrand> mvo: what is the timeframe for 2.31.1 policy updates? I'll do that one right now, but there are some others I can work on this morning
[15:24] <Chipaca> kyrofa: jdstrand: did you see gustavo's request to drop the _ from the valid versions?
[15:24] <zyga> jdstrand I think .1 is next monday
[15:24] <zyga> so sufficient time
[15:24] <jdstrand> mvo: from my perspective, none are required, but you mentioned that we could sneak some in, so asking
[15:24] <jdstrand> ah, ok.
[15:24] <Chipaca> seb128: df -h -x squashfs
[15:25] <seb128> Chipaca, which I'm probably not the only one being annoyed about, but you are right it's a different topic of revisions installed and how to uninstall somes, it just made me wonder/try to understand why it was this way (which is the non obvious part)
[15:25] <jdstrand> Chipaca: not yet, but ack
[15:25] <seb128> Chipaca, we should make that option default :)
[15:25] <Chipaca> seb128: a year ago i'd've said 'fat chance', but with everything graphical now doing that, maybe the time is right to suggest it
[15:26] <Chipaca> seb128: OTOH i don't think df has an anti-x, ie a way of undoing an -x
[15:26] <seb128> :/
[15:26] <seb128> also is there an equivalent flag for "mount"?
[15:27] <Chipaca> $ df -h -x squashfs -t squashfs
[15:27] <Chipaca> df: file system type ‘squashfs’ both selected and excluded
[15:27] <mvo> jdstrand: I plan 2.31.1 for monday
[15:27] <Chipaca> seb128: mount output is useless these days
[15:27] <ogra_> well, we should really also mount the snaps dynamically ... whats the reason for havin all three revisions permanently mounted
[15:28] <Chipaca> seb128: mount | grep -v squash | wc -l <- 41 lines
[15:28] <mup> PR snapd#4682 opened: tests: new spread test for physical-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4682>
[15:28] <zyga> seb128 I think that with the advent of cgroups and more exotic filesystems regular df stopped being for humans
[15:28] <zyga> I use pydf often for that reason
[15:28] <seb128> zyga, df works fine when you don't have snaps :)
[15:29] <ogra_> "in the old world"
[15:29] <seb128> it's the only thing I've installed that create noise here
[15:29] <ogra_> :)
[15:29] <zyga> ah, sorry, I confused df with mount
[15:29] <seb128> ogra_, you know your constant trolling is getting old
[15:29] <Chipaca> seb128: wrt mount, even mount(8) says "use findmnt(8) for listing"
[15:30] <Chipaca> seb128: and, findmount -t nosquashfs
[15:30] <Chipaca> findmnt*
[15:31] <seb128> that's better indeed :)
[15:32] <seb128> anyway thx, the noise just made me wonder why several instance of each snaps are mounted
[15:32] <seb128> I'm still unsure why the ones kept for fallback purpose needs to be mounted all time
[15:32] <Chipaca> seb128: findmnt -t nosquashfs,nocgroup
[15:32] <zyga> seb128 no reason, just work to get it not mounted
[15:32] <Chipaca> ;-)
[15:32] <zyga> seb128 e.g. snapd doesn't cache snap/meta.yaml
[15:32] <Chipaca> there was a reason for it
[15:32] <Chipaca> but i think it no longer applies
[15:33] <Chipaca> but, changing it takes work
[15:33] <Chipaca> zyga: and it's meta/snap.yaml :-p
[15:34] <zyga> snap yaml it is

[15:36] <mvo> Chipaca: iirc back in the day we would use systemds automunt feature but we kept things mounted for simplicity
[15:36] <zyga> mvo did we really try to do that?
[15:37] <zyga> but even if we did auto-mount on demand it wouldn't be enough to be sane
[15:37] <Chipaca> mvo: there was something we needed to do that required it to be mounted, but i lose the details
[15:37] <zyga> as "snap list" will mount everything
[15:37] <Chipaca> seb128: ooooh, findmnt has --df
[15:37] <Chipaca> seb128: and the circle is complete
[15:37] <zyga> I would say that if we kept snap meta-data in cache elsewhere
[15:37] <zyga> and not mount anything
[15:37] <zyga> we could even have snap run do the mounting (via api call to snapd)
[15:38] <mvo> zyga: well, snap list would mount it and after some inactivity it would go away
[15:38] <pedronis> well, we always said we don't want to call snapd from snap run
[15:38] <pedronis> so at least current needs to be mounted
[15:38] <zyga> yeah but 1) silly 2) silly 3) lots of IO/memory
[15:38] <zyga> 4) silly
[15:38] <zyga> pedronis well, yes,
[15:39] <zyga> but we also do things like wait for snapd to generate seccomp profiles from snap-confine
[15:39] <zyga> so ... hmm
[15:39] <zyga> I think the idea that app doesn't need to be mounted is useufl
[15:39] <pedronis> well
[15:39] <zyga> *useful
[15:39] <zyga> and for sure, not for the inactive revisions
[15:39] <pedronis> trade offs
[15:39] <Chipaca> hmm, is the timecontrol failure known, or are things broken?
[15:39] <zyga> this makes the discussion simpler, inactive revisions could be unmounted
[15:39] <pedronis> Chipaca: it's known
[15:39] <zyga> Chipaca it's known
[15:39] <Chipaca> ah, that's the one about netlink
[15:39] <zyga> it's being fixed by jdstrand
[15:39] <Chipaca> ?
[15:39] <zyga> yes
[15:39] <Chipaca> right
[15:40] <Chipaca> teh suck
[15:40] <pedronis> audit netlink that stuff
[15:46] <mup> PR snapd#4671 closed: tests: adding new test to validate the raw-usb interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4671>
[15:49] <mup> PR snapcraft#1906 closed: remote_parts: handle connection errors <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1906>
[16:07] <niemeyer> Now Linode is reporting spam in one of our machines.. except the machine was not in our account by the time the spam was sent.. :)
[16:12] <mup> PR snapd#4683 opened: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4683>
[16:14] <zyga> oohh
[16:14] <zyga> looking
[16:15] <zyga> jdstrand offtopic, linux "sockets" are a pile of historic mess :/
[16:17] <zyga> jdstrand reviewed
[16:17] <mup> PR snapd#4685 opened: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4685>
[16:18] <jdstrand> zyga: and there is one for 2.31 ^
[16:18] <jdstrand> zyga: note, I didn't create netlink-audit-control because reading netlink-audit, it was always meant to allow writes
[16:18] <zyga> makes sense
[16:20] <jdstrand> zyga: it is arguably not a typo since it is 'plugs' in the yaml
[16:20] <jdstrand> zyga: I can fix it right now if you want
[16:20] <zyga> "should use plugs"
[16:20] <zyga> I think "should plugs" just sounds unnatural
[16:20] <zyga> not sure, not a native speaker
[16:20] <zyga> I will leave that up to you
[16:21] <jdstrand> it is unnatural and wrong for the verb, yes. but using the yaml definition as a verb, no
[16:21] <jdstrand> I'll fix
[16:21] <zyga> I thinbk there's no verb in that sentence,
[16:21] <zyga> that's what's bugging me about it
[16:22] <jdstrand> I'm using 'plugs' as a verb just like people use 'facebook' as a verb these days
[16:22] <jdstrand> again, I'm fixing it
[16:22] <zyga> ah, I see
[16:22] <zyga> I should have googled it ;)
[16:23] <jdstrand> well, I was making up language there, but, fixed
[16:24] <zyga> I was joking with "google" being a verb nowadays :)
[16:24] <jdstrand> oh haha. I totally missed that. nice :)
[16:24]  * jdstrand was multitasking
[16:25] <zyga> it's interesting how we caught a change in the core snap this way
[16:25] <zyga> it's certainly unusual and a result of unique things that snapd does
[16:25] <jdstrand> yeah
[16:26] <jdstrand> it is too bad that a change in an SRU regressed edge. it would be interesting to think about running the spread tests as part of SRU
[16:26] <niemeyer> cachio: The workaround for the corruption bug is now pushed to spread's master
[16:26] <jdstrand> but, it is edge, so no one was affected, and it did catch it, so that's good
[16:27] <jdstrand> if the SRU was bad enough, we could file bugs to have it reverted/fixed and the broken core would never make it to stable
[16:27] <jdstrand> basically, testing is a great thing :)
[16:27] <zyga> real men used to test in production on floppy disks
[16:27] <zyga> but I'm glad we're not there anymore
[16:28] <jdstrand> hee
[16:28] <mup> PR snapd#4299 closed: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4299>
[16:29] <Chipaca> jdstrand: mvo: maybe edge should include -proposed
[16:29] <Chipaca> or is it -updates
[16:29] <Chipaca> i always forget the name
[16:29]  * Chipaca thinks it's -proposed
[16:29] <jdstrand> Chipaca: it has -updates
[16:29] <jdstrand> Chipaca: so I think you meant -proposed
[16:29] <zyga> yeah,
[16:29] <zyga> -proposed is really teh edge
[16:29] <zyga> but then it's confusing
[16:29] <jdstrand> but I don't think it should, unless you never promote from edge -> beta
[16:29] <zyga> because we don't want to test edge with proposed and beta with -updates
[16:29] <zyga> exactly :)
[16:30] <Chipaca> lots of red fish
[16:33] <zyga> I wish travis had a way to "bless" a branch
[16:33] <zyga> this branch unbreaks master
[16:33] <zyga> block all CI until it lands
[16:34] <zyga> "halt and stop fire" could be a nice name
[16:57] <cachio> niemeyer, great, tx
[17:07]  * zyga goes for some grocery shopping
[17:41] <blackboxsw> pedronis: thanks for the meeting, I updated retracted comments on https://github.com/snapcore/snapd/pull/4599
[17:41] <mup> PR #4599: many: send  new Snap-CDN header with none or with cloud instance placement info as needed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4599>
[17:42] <pedronis> blackboxsw: thank you
[17:53] <mup> PR snapd#4686 opened: daemon: make the ast-inspecting test smarter; drop 'exceptions' <Created by chipaca> <https://github.com/snapcore/snapd/pull/4686>
[17:54]  * Chipaca couldn't resist that one
[17:54]  * Chipaca has low resistance
[18:32] <elopio> snappy-m-o autopkgtest 1926 xenial:armhf
[18:32] <snappy-m-o> elopio: I've just triggered your test.
[18:32] <elopio> sergiusens: ^
[18:33] <sergiusens> snappy-m-o: autopkgtest 1926 xenial:amd64 xenial:arm64
[18:34] <snappy-m-o> sergiusens: I've just triggered your test.
[18:34]  * cachio afk
[19:36] <zyga> re
[19:36] <zyga> 3 hours and still pending. :(
[19:37] <zyga> crap
[20:26] <jdstrand> davidcalle: ping re https://docs.snapcraft.io/deprecation-notices/dn5
[20:26] <jdstrand> davidcalle: any nm, it is fixed now
[20:26] <jdstrand> s/any/ahh/
[20:27] <davidcalle> ;-)
[20:27] <jdstrand> davidcalle: thanks! :)
[21:31] <zyga> oh,
[21:31] <zyga> jdstrand you pushed just before I pushed :)
[21:38] <jdstrand> :)
[21:39] <jdstrand> diddledan: hey, I just tried to connect to you on wired. trying to look into https://forum.snapcraft.io/t/wire-snap-fails-to-use-the-network/3845
[21:39] <jdstrand> diddledan: not able to reproduce yet
[21:39] <diddledan> ello
[21:40] <diddledan> it only occurs once the call is acccepted
[21:40] <jdstrand> ok
[21:40] <jdstrand> I can create a second account then
[21:40] <jdstrand> diddledan: thanks!
[21:40] <diddledan> np :-)
[21:42] <mup> PR snapcraft#1927 opened: catkin plugin: extract Wstool into its own module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1927>
[22:54] <mup> PR snapcraft#1928 opened: tests: remove duplicate tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1928>
[23:07] <mup> PR snapd#4683 closed: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit <Critical> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/4683>
[23:35] <mup> PR snapd#4687 opened: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4687>