[02:10] PR core-build#11 closed: remove cruft from the writable-paths [02:10] PR core-build#22 closed: unit testing for sync_dir() [02:10] PR core-build#26 closed: move most of the customization into the core snap build [02:11] PR core-build#11 opened: remove cruft from the writable-paths [02:11] PR core-build#22 opened: unit testing for sync_dir() [02:11] PR core-build#26 opened: move most of the customization into the core snap build [04:45] Hello good people. I was wondering. Is there an example/boilerplate for making a kernel module snap? [05:21] morning [05:39] PR snapd#5468 opened: dirs: improve distro detection for Antegros [06:29] PR snapd#5463 closed: Optimize snap install time 1 [06:32] PR snapd#5469 opened: interfaces/apparmor: (un)load profiles in one apparmor_parser call [06:43] PR snapd#5464 closed: vendor: switch to latest bson [06:46] mborzecki: thanks for the merge [06:51] mvo: hi, would it be possible to pick #5468 for 2.34? [06:51] PR #5468: dirs: improve distro detection for Antegros [06:51] sil2100: you are in the SRU team, right? if you could look at my bionic snapd upload with a tiny fix for the boot dealy workaround, that would be great. the xenial version of this can be rejected, I think xenial is not affected by this bad kernel update [06:51] mborzecki: sure thing [06:52] that os-release thing is a bit messy unfortunately [06:53] mborzecki: make sure to tag for 2.32 [06:53] 2.34 [06:54] it's tagged (labeled) for 2.34 already [06:54] mborzecki: great [07:08] mvo: sure! I'm having my SRU shift today so I'll look at it for sure [07:10] sil2100: thank you === pstolowski|afk is now known as pstolowski [07:11] heyas [07:16] hm, systemd-activate is not in bionic anymore [07:16] which is the alternative for it? [07:16] ha, systemd-socket-activate must be [07:17] PR snapd#5468 closed: dirs: improve distro detection for Antegros [07:40] zyga: hey, can you take a look at https://github.com/snapcore/snapd/pull/5416 ? [07:40] PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo [07:40] pstolowski: yes, sorry for not reviewing that last evening [07:46] mborzecki: quick question on 5458 - cachio says "grep -c" exits 1 when no result is found - so is your change (to use it) safe? [07:47] mvo: looking [07:47] mborzecki: I mean, with "wc -l" last we never have the last command in the pipeline failing, with grep -c it *might* happen [07:48] mborzecki: and since we check before restarting snapd we will be back at the same bug we are fixing, no? [07:48] mvo: if grep -c fails, then the output is empty, so -gt tests will fail [07:49] mborzecki: also in the "refreshes_before=" assignment ? [07:49] mvo: yes, test "" -gt "" fails in such case [07:49] pstolowski: have a look [07:50] mvo: haha it fails in zsh [07:50] test "" -gt "" [07:50] bash: test: : integer expression expected [07:50] mborzecki: grep -c will print "0", no? [07:50] mborzecki: I mean, refrehes_before will be zero with the new and the old code [07:51] mborzecki: the risk is that if grep -c returns an exit 1 then the last command in the pipe failed and that causes set -e to kick in and abort (unless I'm reading this wrong) [07:51] mvo: but it's in a subshell [07:52] mvo: see it now, pff let me fix it [07:54] mvo: simple || true should do the trick [07:54] mborzecki: http://paste.ubuntu.com/p/6DbZ8m5xZN/ if you want to play. thanks ! [07:54] mborzecki: yeah, that will also work [07:56] mborzecki: feel free to merge once the grep -c is fixed, the PR looks fine [07:58] 5460 is an easy win [07:59] mvo: pushed, will wait for it to get green and merge [08:00] PR snapd#5460 closed: tests: use grep to avoid non-matching messages from MATCH [08:03] mborzecki: ta [08:16] pstolowski: is that sensible? [08:16] sorry, waking up much too late here [08:17] PR snapd#5470 opened: tests: fixes for the autopkgtest failures in cosmic [08:20] zyga: re Object and DevPath - happy to drop Object, just not 100% sure they're alyways the same, that's the only reason i've both, not to close any doors (although, it's easy to add it back if needed) [08:20] pstolowski: ok, let's drop it for now under the assumption that they are indeed the same; if we find this is wrong we need to re-think some stuff [08:21] zyga: ok, np, thanks for the review [08:22] mwhudson has all the fun [08:22] I too want to skip the office and go whalewatching [08:22] Chipaca: whales of fun [08:22] only whalewatching i could do is at the mall though, so maybe i'll pass [08:23] Chipaca: I was doing hornethunting instead of whalewhatching [08:24] zyga: hornets, or F/A-18 hornets? [08:25] zyga: or even hawker hornets [08:25] those are cool [08:27] Chipaca: my odds would be poor with those :) [08:31] zyga: probably the same as against japanese hornets :P [08:37] did we have a testutil for 'this looks like a timestamp'? [08:43] mmmm, not that I recall [08:46] nm, fixed it by not having the timestamp in the first place [08:46] in fact i'm questioning the whole 'send the timestamp' idea [08:47] mvo: accepted the snapd bionic upload o/ As for xenial, in theory we do have the -hwe kernels in xenial that are 4.15 based, will those not cause problems? [08:48] sil2100: oh, good point, let me quickly check if the bad kernel hit xenial as well [08:49] sil2100: yes it did, so probably a good idea to have the fix in xenial too [08:49] I think the same bits were in the -hwe kernel I published on Monday [08:49] Ok then! [08:49] sil2100: nice catch! [08:52] mvo, i "accidentially" created a universal pi gadget that boots all pi's from one gadget ... and was wondering, i assume we are changing names for core18 images, so we could probably use that unified approach in 18 by default ? https://github.com/ogra1/pi-kiosk-gadget/commit/24ce020e094447abbad4d37a2856e23483b281dd [08:55] ogra_: oh, nice, how does it work? [08:55] zyga, config.txt allows filters per-device since a while [08:55] nobody ever tried them ... [08:56] ... i'm actually working on a universal browser-kiosk image atm and got tired to always have to build two gadgets, so i tried it out ;) [08:56] (thats what i meant by "accidentially" ;) ) [08:58] neat [08:59] zyga, http://people.canonical.com/~ogra/snappy/kiosk/pi-kiosk.img.xz in case you want to try (sadly seeding the giant chromium-mir-kiosk snap on firstboot takes 15-20min so one needs to be patient) [08:59] ogra_: interessting. [09:00] ogra_: one complication is upgrades, on an upgrade the current thinking is that you get a new core18 model assertion [09:01] mvo, right, but i was assuming we change gadget names anyway and need an upgrade path for the naming [09:01] ogra_: but as part of the upgrade logic we could put in the new config.txt - I assume this is backward compatible too? i.e. the old uboot.bin from the current gadget understands this too? [09:01] so we could as well turn everyone to a universal pi gadget in that step [09:01] ogra_: so far we had no need to change the gadget names for 18 [09:02] ogra_: we can/could, its definitely a compelling option [09:02] i'm using the same source tag of the upstream tree that all core16 image use for the blobs, so yeah, fully compatible to todays gadgets [09:03] the feature actually got added a few commits before the tag we use in core 16 so that should be safe [09:03] ogra_: great [09:05] PR snapd#5462 closed: many: use extra "releases" information on store "revision-not-found" errors to produce better errors (2.34) [09:06] PR snapd#5471 opened: dirs: fix antergos typo [09:06] silly typo fix ^^ [09:07] had to stare at the screen for a while to spot the difference [09:09] pedronis, (and probably sil2100 ) https://bugs.launchpad.net/ubuntu-image/+bug/1780217 [09:09] Bug #1780217: new connections: stanza causes validation error in ubuntu-image [09:15] ogra_: yeah, indeed, the connections: part wasn't around when we had the parser prepared [09:16] yeah [09:16] it's pretty new (i think i'm actually the first one to try using it) [09:17] sil2100: maybe add a switch --ignore-unknow or something to make the parser more accepting stuff that is unknown so that people can easier experiment [09:17] sil2100: or even just warn about unknown options by default instead of hard failing [09:17] doesnt snapd have a parser that u-image could call out to ? [09:18] seems awkward that validation needs to be maintained in two places [09:19] ogra_: there is separation of concern here, snapd ignore most of the partitioning bits but u-i needs to parse that. conversely u-i can ignore stuff like connections or snaps because snapd will handle that [09:19] oh, right ... gadget.yaml is special [09:20] mvo: good idea, we didn't really think about future changes to the gadget.yaml spec it seems ;) [09:21] Anyway, let me get these things fixed today-ish [09:22] sil2100, i'm not in a hurry (i have hacks for my test images that help with the issue) so no need to drop something else for it or some such [09:24] jdstrand: please enqueue https://github.com/snapcore/snapd/pull/5469 [09:24] PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call [09:25] Chipaca: turns out the midwinter fireworks might get canceled because of this whale [09:26] so i don't get _all_ the fun [09:27] neither does the whale (who knows probably he'd appreciate fireworks :) ) [09:32] mwhudson: I am unconvinced [09:33] mvo: i just got the MATCH bug on core18 :-) [09:39] mwhudson: is the whale something special where you live? [09:40] Chipaca: did you bring any MATCHes [09:40] Chipaca: do you have a debug shell? [09:40] zyga: this was from travis so no [09:40] in the end working on software is fun because of MATCH like bugs [09:40] where we look at a 3 liner [09:40] zyga: but am now trying to repro it with debug [09:40] and then look at the error [09:40] and then say WAT [09:40] and are awed by the eventual understanding [09:41] mvo: hi, thanks for merging that backport, there is also #5442 [09:41] PR #5442: many: expose publisher's validation throughout the API (2.34) [09:41] pedronis: aha, looking [09:43] PR snapd#5442 closed: many: expose publisher's validation throughout the API (2.34) [09:46] zyga: yeah, it's pretty unusual [09:46] zyga: dolphins, seals, even orca are somewhat normal, but a baleen whale? [09:53] mvo: thanks [09:55] * zyga wrote pretty lengthy review for a one liner: https://github.com/snapcore/snapd/pull/5466 [09:55] PR #5466: tests: remove extra ' which breaks interfaces-bluetooth-control test [09:55] mwhudson: nice, I never saw a whale [09:56] zyga: me neither until today! [09:56] mwhudson: I think I saw a dolphin as a child when one was (rarely) spotted near to where I was at the seaside here [09:56] i've never been around when the orca are in the harbour [09:56] mwhudson: imagine how it must feel to dive next to such a creature! [09:57] zyga: i thought the paddle boarders were being quite brave enough [09:57] zyga: have you seen the bbc series 'the blue planet'? [09:57] is the whale stuck there or just passing by? [09:57] mwhudson: yes, I have it on BD [09:58] one of the making of segments has a diver getting a bit too close to a whale + calf [09:58] watching that makes me think I made some bad life decisions by working on computers all day long [09:58] too close? maybe I missed that part [09:58] as far as anyone can tell the whale is just hanging out [09:58] it's been here for three days now? [09:59] did you take that photo with your phone? [09:59] i can't imagine there's a lot of krill in the harbour but what do i know [09:59] or with a telelens? [09:59] yeah [09:59] doesn't the terrible unsharp mask give it away? :) [09:59] haha, well, maybe this is a smoker whale who likes the smell of oil and gasoline ;-) [09:59] haha, kind of :D [10:00] if you have a camera now would be a great time to take some time off and photograph it [10:00] maybe that could go to the community showcase [10:00] * mvo seconds that [10:00] i guess it was ~300 metres away when i saw it [10:00] ubuntu wacky whale anyone :D [10:00] well unsurprisingly there are billions of much better photos on twitter & fb etc [10:00] yeah, that is how the times are [10:01] https://www.facebook.com/photo.php?fbid=10155927798194830&set=a.383547374829.165096.535824829&type=3&theater [10:01] I kept saying that someone should make an app for finding photos made at the time / place where one was with juts their phone [10:01] for example [10:01] but then I learned one of the heavyweights did just that [10:01] (forgot which now) [10:01] woah [10:01] Mornings [10:01] fantastic photo [10:01] hey Gustavo :) [10:01] mborzecki: Some comments in #5459 [10:01] PR #5459: cmd/snap: add 'debug paths' command [10:03] niemeyer: hey, thanks for the review! [10:03] mborzecki: Heya, np [10:04] PR snapd#5471 closed: dirs: fix antergos typo [10:05] niemeyer: given your comemnt, that would be SNAP_MOUNT, SNAP_BIN, SNAPD_LIBEXEC [10:05] fatal: unable to access 'https://github.com/kardianos/govendor/': Failed to connect to github.com port 443: Connection timed out [10:05] I wonder if there's something simple we can pass to govendor to retry those [10:06] zyga: that's go get [10:06] aha [10:07] seems not [10:07] we could grep [10:07] but :/ [10:07] mvo: do you think we should grep for "Failed to connect" and retry? [10:11] mborzecki: can you look at https://github.com/snapcore/snapd/pull/5457 [10:11] PR #5457: many: lessen the use of core-support [10:11] mborzecki: Not sure I get the question [10:11] PR snapd#5466 closed: tests: remove extra ' which breaks interfaces-bluetooth-control test [10:11] mborzecki: now that https://github.com/snapcore/core/pull/92 has landed we need this [10:11] PR core#92: Remove core-support plug [10:11] CC mvo [10:12] mborzecki: ... there's no SNAP_BIN there, only SNAPD_BIN, and the suggested entries match exactly the ones in the PR in the same order and with almost the same names [10:16] niemeyer: yeah, so i'm wondering if we should use SNAP_MOUNT instead, since we refer to the path as snap mount dir elsewhere (and SNAP_BIN for that matter) [10:17] zyga: I looked at this one, no? [10:17] mvo: yes just letting you know we need to merge it :) [10:17] mborzecki: The review provides the exact background for $SNAP_ vs. $SNAPD_.. did you read it? :) [10:17] mvo: or tests will complain about missing core-support-plug [10:19] mvo: looking at core PRs I'd suggest to look at and close https://github.com/snapcore/core/pull/38 [10:19] PR core#38: Add another pi-config option [10:19] zyga: addressed your feedback to https://github.com/snapcore/snapd/pull/5416 [10:19] PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo [10:19] pstolowski: perfect, looking [10:20] mborzecki: It's of course okay to disagree.. but it sounds like you didn't read it.. what do you think of these points? [10:20] PR core#91 closed: hooks: add a check to ensure that the image is build with ppa:snappy-dev/image [10:21] pstolowski: reviewed [10:21] mborzecki: I'm usually much more careful when I need to expose such names to the external world via an API than when it just sits inside our code which can easily change [10:22] mborzecki: The mount dir of a snap is actually at /snap// [10:23] Which we call $SNAP for the snap [10:25] mborzecki: snap.Info.MountDir also returns /snap//, not /snap [10:25] drat, I don't have my opensuse account password here [10:25] I'll ask my wife later today [10:29] niemeyer: sry, kids are around, what i meant is that the tests and configure flags and the `dirs` package variable name is some premuation of snap mount dir,, that's why i found SNAPD_(MOUNT|BIN) a bit confusing [10:31] mborzecki: Sure, and that's what the comment in the review addresses.. in other cases we generally try to leave SNAP_* for snap-specific namespaces [10:31] mborzecki: $SNAP_COMMON, $SNAP, $SNAP_DATA, ... [10:31] mborzecki: While SNAPD_* is for snapd.. $SNAPD_DEBUG, ... [10:31] ack [10:32] mborzecki: Inside the code we have both.. dirs.SnapMountDir, and snap.Info.MountDir.. the first maps to SNAPD_MOUNT, while the latter is snap-specific and exposed as $SNAP [10:39] zyga: COmment on #5457 [10:39] PR #5457: many: lessen the use of core-support === sabdfl_ is now known as sabdfl [10:44] looking [10:46] niemeyer: replied [10:48] zyga: Replied the reply... [10:48] I wish GH would notify instead of us using IRC that way :) [10:48] haha, yes [10:50] niemeyer: replied again [10:51] I wonder why github shows me someone is typing but then doesn't show me the actual post. I need to refresh the page... wierd [10:51] zyga: You say it's not removing the testing of the interface, which is a bit ironic given that the comment is under a line removed that tested the existence of the interface :) [10:52] no, you misunderstand [10:52] that is not what is tested [10:52] Man.. do I need to copy & paste the test? :) [10:52] details: | [10:52] The "snap interface" command displays a listing of used interfaces [10:52] execute: | [10:52] - snap interface | MATCH 'core-support\s+ special permissions for the core snap' [10:52] snap interface lists interfaces that are _present_ in the system as plugs or slots [10:52] it doens't list interfaces that are known but not present as plugs or slots [10:53] Ah.. okay, that's what I missed [10:53] I could change that to say "snap interface --all | MATCH" but that was not the point of the test so I changed it slightly [10:53] zyga: And what about this: [10:53] - snap interface core-support > out.yaml [10:53] + snap interface network > out.yaml [10:53] - diff -u out.yaml snap-interface-core-support.yaml [10:53] and hence used the network interface instead [10:54] this just shows how plugs and slots are reported by "snap interface IFACENAME" [10:54] zyga: Do we have other tests for it? [10:54] this is why I also added the test snap to have a connection [10:54] for the core-support test, no I don't believe we do [10:54] it used to be tested by various core configuration test [10:54] *tests [10:55] but those stopped exercising that code [10:55] from my POV that interface is stuck as-is until we can understand why some snaps are abusing it [10:55] and shift them away from it [10:55] So we're back to the same point [10:55] We should either remove the interface, or tes it [10:55] test it [10:55] well, I disagree, I didn't remove an existing test for the functionality of this interface since we didn't have one [10:55] we cannot remove the interface, I can add a test for the interface but this is orthogonal to the change I made here [10:55] I hope you agree about this point specifically [10:57] FYI, I clarified my last comment [10:57] (on GH) [10:59] zyga: I see.. the test goal was just checking "snap interface" itself, not the core one specifically [10:59] yes [10:59] exactly so [10:59] mborzecki: google:arch-linux-64:tests/main/interfaces-content-default-provider failure on arch - https://api.travis-ci.org/v3/job/400340808/log.txt [11:00] pstolowski: mount isuse? [11:00] zyga: We probably have tests for that interface originally, but they were about the hook which don't need the interface anymore [11:00] mborzecki: yes [11:00] niemeyer: yes, I think so as well [11:00] zyga: So why do we need the interface again? [11:00] mborzecki: can i restart or do you want to take a look at the log? [11:00] pstolowski: go ahead and restat [11:00] k [11:00] niemeyer: we found that one of our customers has a snap declaration for using it on some of their snaps [11:00] niemeyer: they are probably using it for the unconfined systemctl access [11:01] niemeyer: I believe we are trying to get in touch with them to discuss this [11:01] mborzecki: is this test flakiness or something deeper? [11:01] niemeyer: I would have removed it a few days ago but jdstrand suggested we do a store-side search to ensure it is really unused [11:01] pstolowski: no clue yet, there's a forum topic tracking this problem [11:01] pstolowski: it's usually associated with I/O errors on loop devices [11:01] zyga: Well, that's definitely not what this is supposed to do [11:02] niemeyer: interesting observation, no? I think this is something to learn from [11:02] niemeyer: yeah but I don't think we should pull the rug from under their feet without asking first [11:02] zyga: How's that not blocked with the declaration? [11:02] zyga: Pretty sure jdstrand wouldn't hand that off [11:02] jdstrand: hey, I created a core16 base snap, it is essentially core without snapd, exactly the same build etc. could you please whitelist that in the store so that people can start using it? sergio was keen to use it for his latest snapcraft work [11:02] niemeyer: they have their store, they just signed a declaration that grants this [11:03] zyga: Okay, let's just drop this then [11:03] mm? [11:03] drop the interface you mean? [11:04] zyga: Drop the permissions granted by the interface [11:04] keep the interface but make it empty or remove it entirely? [11:04] zyga: Keep the interface, drop permissions [11:04] ok [11:04] can we land this PR then, I will open a new one that drops the actual permissions [11:04] we need this PR because we removed core-support-plug from core [11:05] zyga: Yeah, the PR is fine [11:05] zyga: Who's the contact on our end? [11:05] thanks! sorry for not including more context in the PR itself [11:05] niemeyer: I think lool [11:05] lool: ping [11:06] zyga: I'll also revive the conversation about the fact people granting arbitrary permissions like that for their devices is completely bogus [11:06] niemeyer: but I need to re-check, pedronis noticed this as he helped to find this [11:06] niemeyer: thank you [11:06] niemeyer: we may have some extra constraint on interface policy [11:06] zyga: np, thanks for the info [11:06] niemeyer: we didn't ping anybody so far, I wanted to mention it in the standup yesterday [11:06] niemeyer: that really limits it to specific snaps in a way that cannot be forced from the store [11:06] niemeyer: so that in the future things like that don't happen [11:06]