=== sergiusens_ is now known as sergiusens [03:04] PR snapcraft#1925 closed: elf: cache crawled files [03:07] PR snapcraft#1923 closed: mypy: update to 0.560 [06:08] morning [06:18] hey hey [06:18] zyga: hey [06:19] darn tests [06:20] I wish someone would go through the prepare/restore process and made restore really purge stuff [06:20] and made prepare install a cached copy of core [06:20] it feels like tests are leaking all the time [06:20] leaving junk around [06:29] 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] mborzecki that's also interesting, yeah [06:30] but in all honesty, purge would be a simple approach that ought to mostly work [06:30] I worry about random places less than about our essential files [06:31] I will do an experiment, I have some old branches that did full caching of all the snaps used for testing [06:31] but I can simplify that to just one snap (core) and purge+install package, install core [06:31] I really don't like how prepare and restore are swapped in our setup [06:31] where restore prepares [06:31] and prepare does nothing much [07:24] zyga: hey, good morning! whats up? [07:24] hey [07:25] nothing major so far, just me being grumpy about tests that clearly run in some corrupted state [07:25] I'm doing code reviews [07:25] zyga: aha, so master is in un-happy land? [07:25] zyga: at random times [07:25] ? [07:26] I think master is fine but our test suite is not perfect [07:26] I tried to fix it a few times but without major success, I'll try to push forward slightly today [07:26] ok [07:28] mvo https://github.com/snapcore/snapd/pull/4600 needs deconflicting [07:28] PR #4600: configstate: validate known core.* options [07:28] zyga: it needs a +1 from niemeyer about the concept [07:29] zyga: I mean, its not clear that we want this (and if so in what way) [07:29] zyga: (I personally think so but thats just me :) [07:29] mborzecki https://github.com/snapcore/snapd/pull/4571 has unaddressed comments but could land shortly [07:29] PR #4571: data, cmd, packaging: use autotools to generate artifacts under data [07:29] zyga: i'll be coming back to it once i'm done with timer services [07:30] mvo: morning [07:30] thank you! [07:31] hey mborzecki, good morning! how are you? [07:31] mvo: grumpy, found a bug in timer schedules :) [07:31] oh? :) [07:32] mborzecki: meeeh, but better you than our users. how bad is it? (2.31.1 material?) [07:33] 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] mborzecki: is there a fix yet? and if so, how invasive is it? [07:38] mvo: still looking into it [07:39] mborzecki: ok, keep me updated please [07:49] mvo is trivial if you want to look https://github.com/snapcore/snapd/pull/4673 :-) [07:49] PR #4673: interfaces/mount: generate per-user mount profiles [07:49] (this is chopped from the user mounts PR) [07:51] zyga: ok [07:54] good morning [07:56] * zyga -> afk for 40 minutes [08:05] PR snapd#4668 closed: store: revert PR#4532 and do not display displayname [08:41] PR snapd#4674 opened: packaging: fix build on sbuild [09:08] moin moin [09:08] did somebody pull the plug on the dc? [09:20] 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] snapcraft.io is up for me [09:22] Chipaca: I can log into people.c.c so its not fully down [09:22] hey Chipaca [09:22] Chipaca works for me [09:23] Chipaca want to VPN through my network? ;-) [09:23] Chipaca thanks for the review yesterday [09:23] I addressed all of those and merged that one [09:25] looks like it's the vpn that's crashed [09:25] turned that off and i'm in [09:26] Chipaca can I quickly drag you into another review? [09:26] builds on the mount spec change for user mount entries [09:27] this time the mount backend spits out a new file based on those [09:27] very mechanic and shorty [09:27] *short [09:27] zyga: mostly (late) in the town hall [09:27] zyga: but sure [09:27] https://github.com/snapcore/snapd/pull/4673/files :-) [09:27] PR #4673: interfaces/mount: generate per-user mount profiles [09:27] thank you! [09:39] zyga: duuuude [09:40] hmm? [09:41] zyga: two chunks of code that are exactly the same [09:41] aaaaw, ok [09:41] I'll dedupe it :) [09:41] thanks for pointing that out [09:43] zyga: you don't even need a helper, just a loop [09:56] Chipaca pushed, I opted to do a helper in the end, have a look [09:56] yeah, the fstab vs user-fstab would've made the loop clunky i guess [09:56] at least without a big refactor :-) [10:00] thanks John [11:11] mvo: one fix for schedules comint up shortly [11:11] what an annoying edge case though [11:13] hmm [11:13] + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc [11:13] PR snapd#4675 opened: timeutil: fix scheduling on nth weekday of the month [11:14] I'm wondering if we have anew problem [11:14] or if I broke it somehow (but unlikely since this PR is about mounts) [11:15] zyga: what's the problem? [11:15] + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc [11:15] hwclock: Unable to connect to audit system [11:15] hmm [11:15] look at https://api.travis-ci.org/v3/job/341809848/log.txt [11:15] I bet this is not related to my PR [11:15] and it is a genuine problem elsewhere [11:16] * mvo hugs mborzecki [11:17] zyga: seccomp? [11:17] yes, this is seccomp for sure [11:17] the bad system call thing is [11:17] the one about audit is more curious [11:17] looks like apparmor [11:17] which would be "bugs all over the place" [11:18] hmm hmm but the same debug log below shows no seccomp or apparmor issues [11:18] broken log? [11:19] zyga: there are no denials from apparmor though :? [11:20] zyga: what if the rtc does not work in those vms? [11:20] this test didn't fail before [11:21] zyga: or /dev/rtc is not a device node, showing would be useful [11:24] ooooh, my new keyboard arrived \o/ [11:25] 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] Chipaca what did you get? [11:26] mvo looking [11:26] + MATCH gadget - on debian 9 this makes no sense [11:27] should this test even run there [11:27] hmmm [11:28] zyga: also it makes no sense because the diff is very small so it can't break like this [11:28] ohwell [11:28] zyga: https://twitter.com/chipaca/status/964099012281487360 [11:29] woah [11:29] man [11:29] I look forward to seeing you type on this :) [11:29] zyga: the firmware is open [11:29] zyga: … [11:29] i didn't have enough side projects [11:29] how come I didn't follow you yet [11:30] * zyga follows chipaca [11:30] zyga: probably because i was private for a while [11:32] PR snapd#4674 closed: packaging: fix build on sbuild [11:34] mborzecki posted a question on 4675 [11:34] PR snapd#4676 opened: timeutil: introduce helpers for checking it time falls inside the schedule [11:37] PR snapd#4663 closed: interfaces/builtin: allow MM to access login1 [11:38] PR snapd#4635 closed: snap: add support for `snap run --gdb` [11:38] mborzecki how are arch spread tests doing? [11:38] is that still on hold? [11:38] waiting :) [11:39] i want to finish timer services for 2.32 first, then come back to autotools in $(top_srcdir)/data and then arch [11:39] ok [11:42] zyga: right, so interface-time-control is failing in my pr too [11:44] Chipaca: does the keyboard come with the straps to attach each half to a hand? :) [11:46] 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] Chipaca: nice, looking forward to hearing more about your impressions once you use it for a while [11:51] impression #0: it's going to have a learning curve [11:51] was currently in the zone in a bit of a refactor, put it to one side [11:53] wow, it even comes with source code and stuff [12:17] re [12:17] I'm tethered from my phone, not sure why local ISP (both of them) failed [12:27] zyga: https://paste.debian.net/1010385/ [12:28] netlink [12:28] weird [12:28] thank you for checking that [12:28] why is it touching netlink? [12:28] maybe the test started to rely on netlink now [12:28] (for whatever reason) [12:28] actually socket(AF_NETLINK, SOCK_RAW, NETLINK_AUDIT) ? [12:28] is hwclock coming from systemd? [12:28] or maybe some nss plugin or something [12:30] zyga: just strace on host http://paste.debian.net/1010387/ [12:30] yeah [12:30] no netlink [12:30] i don't see socket anywhere [12:32] zyga: ok, os here's hwclock from the core snap: https://paste.debian.net/1010389/ no clue why it does socket() call [12:37] mborzecki does it do this in stable? [12:37] or just in edge? [12:38] zyga: it's edge [12:38] let me try stable [12:38] yeah, try stable [12:38] I wonder if it's a regression [12:38] (^H "new feature") [12:39] brb, let me try normal internet again [12:40] 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] ok, internet is back [12:41] Son_Goku I think just take all of release/2.31 since that's exactly what it is for [12:41] mvo will do a .1 soon AFAIK [12:41] but you really want to ask mvo about that [12:41] mvo, do you plan on doing a 2.31.1? [12:43] damn, random lockup, cursor moving and all, but the rest was frozen [12:43] mborzecki ryzen? [12:44] zyga: no, i think it's the damn wifi [12:45] it's the 2nd time this happened, and kernel backtrace shows warnings from iwlwifi [12:46] perhaps I should lunch [12:48] PR snapcraft#1926 opened: Release changelog for 2.39.1 [13:02] Son_Goku: there will be a 2.31.1 with some small fixes, probably monday [13:03] mvo, okay, then I won't prepare a snapd update just yet, then [13:04] mborzecki, ok, I know what's causing this [13:07] 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] zyga_: ^ [13:08] mborzecki, zyga_: *or* /dev/rtc isn't in the device cgroup [13:09] mborzecki, zyga_: no, that should be a different error [13:13] zyga: "mborzecki, ok, I know what's causing this" [13:13] zyga: what is it? [13:13] util-linux (2.30.1-0ubuntu4.1) artful; urgency=medium [13:13] * Add --with-audit to rules file and libaudit-dev to build depenedencies. [13:13] The hwclock needs audit defined in order to create audit records when [13:13] time is changed. (LP: #1722313) [13:13] Bug #1722313: Enable auditing in util-linux.

Artful):Fix Released> [13:13] -- Joy Latten Sun, 05 Nov 2017 18:14:49 -0600 [13:13] change in util-linuxy [13:13] so it is what I thought [13:13] 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] zyga: ^ [13:14] have it plugs netlink-audit [13:15] that won't actually give you audit_write though [13:16] time-control needs updating [13:16] so we need to add netlink audit snippets to that interface [13:17] jdstrand right? [13:17] capability audit_write, [13:17] ^ apparmor [13:17] + socket bits I suspect [13:17] but yeah [13:17] (I think it was getting killed by socket syscall) [13:17] bind [13:17] socket AF_NETLINK - NETLINK_AUDIT [13:17] seccomp ^ [13:18] but wait a second [13:18] thanks! [13:18] jdstrand if you want just send the branch :) [13:18] it is probably going to need capability net_admin, [13:19] is this on bionic? [13:19] jdstrand no, it's in xenial [13:19] oh, sru [13:19] yep [13:19] and it's now present in the core snap in endge [13:19] ok. this would affect other distros btw [13:19] (if they had strict mode) [13:19] just run strace -e socket /snap/core/current/sbin/hwclock [13:19] indeed [13:19] * jdstrand nods [13:20] and compare stable and edge [13:20] ok. let me think about this. I don't want to just give out net_admin [13:20] yeah, it sucks [13:20] I wonder if we could *not* give the permission [13:20] so that it gets socket [13:20] yeah, that capabilities subsystem has some icky spots [13:21] and doesn't crash [13:21] well, I was thinking of adding netlink-audit-control [13:21] but doesn't audit [13:21] we want it to audit though [13:22] we could add the socket, not the cap, then add both in the -control interface [13:22] then it doesn't die, but won't audit until netlink-audit-control is added [13:22] that's pretty reasonable [13:22] * jdstrand adds to list [13:23] yes, that's very nice [13:23] 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] PR snapd#4677 opened: cmd/snap: introduce `snap run --timer` [13:41] PR snapd#4678 opened: snap: fix `snap moo` output [13:42] zyga: keep me updated on the --with-audit issue please [13:42] mvo ack, I think jdstrand is making a PR that will address it now [13:42] I will just review it [13:43] zyga: great, we will need it for 2.31.1 too [13:43] yes, absolutely [13:43] mvo: OMG :-) [13:43] mvo, hey, could you please upload the snap test-snapd-physical-memory-control ? [13:44] cachio: ups, forgot that, sure, let me do that now [13:44] mvo, tx [13:44] my google fu is failing me [13:45] cachio: do you have a link [13:45] is there a snapcraft_part_... build directory [13:45] cachio: is it in one of your PRs? [13:45] mvo, https://code.launchpad.net/~snappy-dev/snappy-hub/test-snapd-physical-memory-control [13:45] variable I can use in a snapcraft build ? [13:45] cachio: thanks [13:45] mvo, I did not create a PR yet [13:45] I'm waiting for the snap :) [14:19] PR snapd#4679 opened: systemd: add default target for timers [14:19] trivial PR ^ [14:22] PR snapd#4680 opened: snap: pass full timer spec in `snap run --timer` [14:25] most of the timer services stuff is open for review now, still need to cut the service wrappers into smaller pieces [14:26] afk to pick up the kids [14:27] re [14:38] PR snapd#4681 opened: testutil: add File{Matches,Equals,Contains} checkers [14:41] now, where was I? [14:48] Chipaca: unicorns? cats? [14:55] kalikiana: por qué no los dos? [14:59] Always :-D [15:07] why do some of the snaps have several loop mounts? [15:07] for the same snap file ? [15:07] seems like several revisions are active? [15:07] dunno what you mean by "snap file" [15:08] (there should always be three revisios of each snap ... and each has a mount) [15:08] a file ending in .snaop [15:08] *.snap [15:08] oh ok [15:08] why 3 revisions? can I tell snap that for a particular snap 1 is enough? [15:08] i dont theink we technically need all of them mounted though [15:08] do they end up using 3 times the space? [15:08] yes [15:09] :( [15:09] for rollback etc [15:09] why 3 and not 2? [15:09] i dont know why 3, 2 technically are enough ... thats a niemeyer question [15:09] k [15:09] thx [15:14] 3 revisions [15:15] because it leaves you one more revert in case things go bad [15:15] seb128: if you need to make space you can remove the revisions you're not using [15:19] re [15:20] o/ zyga [15:20] hey hey [15:21] Chipaca, how? snap list doesn't list them [15:21] seb128: snap list --all [15:21] seb128: and then, snap remove --revision=NNNN thesnap [15:22] Chipaca, thx, that's non obvious as an user of the system :/ [15:22] seb128: you're trying to do something out of the ordinary [15:22] seb128: i'm not sure what part is the non-obvious though [15:23] seb128: but it's not surprising that to do advanced things you need to know the advanced things [15:23] zyga, mvo: I am now, yes [15:23] cook [15:23] cool :D [15:24] 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] 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] kyrofa: jdstrand: did you see gustavo's request to drop the _ from the valid versions? [15:24] jdstrand I think .1 is next monday [15:24] so sufficient time [15:24] mvo: from my perspective, none are required, but you mentioned that we could sneak some in, so asking [15:24] ah, ok. [15:24] seb128: df -h -x squashfs [15:25] 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] Chipaca: not yet, but ack [15:25] Chipaca, we should make that option default :) [15:25] 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] seb128: OTOH i don't think df has an anti-x, ie a way of undoing an -x [15:26] :/ [15:26] also is there an equivalent flag for "mount"? [15:27] $ df -h -x squashfs -t squashfs [15:27] df: file system type ‘squashfs’ both selected and excluded [15:27] jdstrand: I plan 2.31.1 for monday [15:27] seb128: mount output is useless these days [15:27] well, we should really also mount the snaps dynamically ... whats the reason for havin all three revisions permanently mounted [15:28] seb128: mount | grep -v squash | wc -l <- 41 lines [15:28] PR snapd#4682 opened: tests: new spread test for physical-memory-control interface [15:28] seb128 I think that with the advent of cgroups and more exotic filesystems regular df stopped being for humans [15:28] I use pydf often for that reason [15:28] zyga, df works fine when you don't have snaps :) [15:29] "in the old world" [15:29] it's the only thing I've installed that create noise here [15:29] :) [15:29] ah, sorry, I confused df with mount [15:29] ogra_, you know your constant trolling is getting old [15:29] seb128: wrt mount, even mount(8) says "use findmnt(8) for listing" [15:30] seb128: and, findmount -t nosquashfs [15:30]