[02:10] <mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[02:10] <mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
[02:10] <mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
[02:11] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[02:11] <mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
[02:11] <mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
[04:45] <DarrenRStarr> Hello good people. I was wondering. Is there an example/boilerplate for making a kernel module snap?
[05:21] <mborzecki> morning
[05:39] <mup> PR snapd#5468 opened: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5468>
[06:29] <mup> PR snapd#5463 closed: Optimize snap install time 1 <Created by alfonsosanchezbeato> <Closed by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5463>
[06:32] <mup> PR snapd#5469 opened: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[06:43] <mup> PR snapd#5464 closed: vendor: switch to latest bson <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5464>
[06:46] <mvo> mborzecki: thanks for the merge
[06:51] <mborzecki> mvo: hi, would it be possible to pick #5468 for 2.34?
[06:51] <mup> PR #5468: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5468>
[06:51] <mvo> 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] <mvo> mborzecki: sure thing
[06:52] <mborzecki> that os-release thing is a bit messy unfortunately
[06:53] <mvo> mborzecki: make sure to tag for 2.32
[06:53] <mvo> 2.34
[06:54] <mborzecki> it's tagged (labeled) for 2.34 already
[06:54] <mvo> mborzecki: great
[07:08] <sil2100> mvo: sure! I'm having my SRU shift today so I'll look at it for sure
[07:10] <mvo> sil2100: thank you
[07:11] <pstolowski> heyas
[07:16] <abeato> hm, systemd-activate is not in bionic anymore
[07:16] <abeato> which is the alternative for it?
[07:16] <abeato> ha, systemd-socket-activate must be
[07:17] <mup> PR snapd#5468 closed: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5468>
[07:40] <pstolowski> zyga: hey, can you take a look at https://github.com/snapcore/snapd/pull/5416 ?
[07:40] <mup> PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>
[07:40] <zyga> pstolowski: yes, sorry for not reviewing that last evening
[07:46] <mvo> 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] <mborzecki> mvo: looking
[07:47] <mvo> 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] <mvo> mborzecki: and since we check before restarting snapd we will be back at the same bug we are fixing, no?
[07:48] <mborzecki> mvo: if grep -c fails, then the output is empty, so -gt tests will fail
[07:49] <mvo> mborzecki: also in the "refreshes_before=" assignment ?
[07:49] <mborzecki> mvo: yes, test "" -gt "" fails in such case
[07:49] <zyga> pstolowski: have a look
[07:50] <mborzecki> mvo: haha it fails in zsh
[07:50] <mborzecki> test "" -gt ""
[07:50] <mborzecki> bash: test: : integer expression expected
[07:50] <mvo> mborzecki: grep -c will print "0", no?
[07:50] <mvo> mborzecki: I mean, refrehes_before will be zero with the new and the old code
[07:51] <mvo> 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] <mborzecki> mvo: but it's in a subshell
[07:52] <mborzecki> mvo: see it now, pff let me fix it
[07:54] <mborzecki> mvo: simple || true should do the trick
[07:54] <mvo> mborzecki: http://paste.ubuntu.com/p/6DbZ8m5xZN/ if you want to play. thanks !
[07:54] <mvo> mborzecki: yeah, that will also work
[07:56] <mvo> mborzecki: feel free to merge once the grep -c is fixed, the PR looks fine
[07:58] <mvo> 5460 is an easy win
[07:59] <mborzecki> mvo: pushed, will wait for it to get green and merge
[08:00] <mup> PR snapd#5460 closed: tests: use grep to avoid non-matching messages from MATCH <Simple> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5460>
[08:03] <mvo> mborzecki: ta
[08:16] <zyga> pstolowski: is that sensible?
[08:16] <zyga> sorry, waking up much too late here
[08:17] <mup> PR snapd#5470 opened: tests: fixes for the autopkgtest failures in cosmic <Created by mvo5> <https://github.com/snapcore/snapd/pull/5470>
[08:20] <pstolowski> 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] <zyga> 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] <pstolowski> zyga: ok, np, thanks for the review
[08:22] <Chipaca> mwhudson has all the fun
[08:22] <Chipaca> I too want to skip the office and go whalewatching
[08:22] <zyga> Chipaca: whales of fun
[08:22] <Chipaca> only whalewatching i could do is at the mall though, so maybe i'll pass
[08:23] <zyga> Chipaca: I was doing hornethunting instead of whalewhatching
[08:24] <Chipaca> zyga: hornets, or F/A-18 hornets?
[08:25] <Chipaca> zyga: or even hawker hornets
[08:25] <Chipaca> those are cool
[08:27] <zyga> Chipaca: my odds would be poor with those :)
[08:31] <mborzecki> zyga: probably the same as against japanese hornets :P
[08:37] <Chipaca> did we have a testutil for 'this looks like a timestamp'?
[08:43] <zyga> mmmm, not that I recall
[08:46] <Chipaca> nm, fixed it by not having the timestamp in the first place
[08:46] <Chipaca> in fact i'm questioning the whole 'send the timestamp' idea
[08:47] <sil2100> 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] <mvo> sil2100: oh, good point, let me quickly check if the bad kernel hit xenial as well
[08:49] <mvo> sil2100: yes it did, so probably a good idea to have the fix in xenial too
[08:49] <sil2100> I think the same bits were in the -hwe kernel I published on Monday
[08:49] <sil2100> Ok then!
[08:49] <mvo> sil2100: nice catch!
[08:52] <ogra_> 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] <zyga> ogra_: oh, nice, how does it work?
[08:55] <ogra_> zyga, config.txt allows filters per-device since a while
[08:55] <ogra_> nobody ever tried them ...
[08:56] <ogra_> ... 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] <ogra_> (thats what i meant by "accidentially" ;) )
[08:58] <zyga> neat
[08:59] <ogra_> 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] <mvo> ogra_: interessting.
[09:00] <mvo> ogra_: one complication is upgrades, on an upgrade the current thinking is that you get a new core18 model assertion
[09:01] <ogra_> mvo, right, but i was assuming we change gadget names anyway and need an upgrade path for the naming
[09:01] <mvo> 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] <ogra_> so we could as well turn everyone to a universal pi gadget in that step
[09:01] <mvo> ogra_: so far we had no need to change the gadget names for 18
[09:02] <mvo> ogra_: we can/could, its definitely a compelling option
[09:02] <ogra_> 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] <ogra_> the feature actually got added a few commits before the tag we use in core 16 so that should be safe
[09:03] <mvo> ogra_: great
[09:05] <mup> PR snapd#5462 closed: many: use extra "releases" information on store "revision-not-found" errors to produce better errors (2.34) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5462>
[09:06] <mup> PR snapd#5471 opened: dirs: fix antergos typo <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5471>
[09:06] <mborzecki> silly typo fix ^^
[09:07] <mborzecki> had to stare at the screen for a while to spot the difference
[09:09] <ogra_> pedronis, (and probably sil2100 ) https://bugs.launchpad.net/ubuntu-image/+bug/1780217
[09:09] <mup> Bug #1780217: new connections: stanza causes validation error in ubuntu-image <Ubuntu Image:New> <https://launchpad.net/bugs/1780217>
[09:15] <sil2100> ogra_: yeah, indeed, the connections: part wasn't around when we had the parser prepared
[09:16] <ogra_> yeah
[09:16] <ogra_> it's pretty new (i think i'm actually the first one to try using it)
[09:17] <mvo> 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] <mvo> sil2100: or even just warn about unknown options by default instead of hard failing
[09:17] <ogra_> doesnt snapd have a parser that u-image could call out to ?
[09:18] <ogra_> seems awkward that validation needs to be maintained in two places
[09:19] <mvo> 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] <ogra_> oh, right ... gadget.yaml is special
[09:20] <sil2100> mvo: good idea, we didn't really think about future changes to the gadget.yaml spec it seems ;)
[09:21] <sil2100> Anyway, let me get these things fixed today-ish
[09:22] <ogra_> 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] <zyga> jdstrand: please enqueue https://github.com/snapcore/snapd/pull/5469
[09:24] <mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[09:25] <mwhudson> Chipaca: turns out the midwinter fireworks might get canceled because of this whale
[09:26] <mwhudson> so i don't get _all_ the fun
[09:27] <ogra_> neither does the whale (who knows probably he'd appreciate fireworks :) )
[09:32] <Chipaca> mwhudson: I am unconvinced
[09:33] <Chipaca> mvo: i just got the MATCH bug on core18 :-)
[09:39] <zyga> mwhudson: is the whale something special where you live?
[09:40] <zyga> Chipaca: did you bring any MATCHes
[09:40] <zyga> Chipaca: do you have a debug shell?
[09:40] <Chipaca> zyga: this was from travis so no
[09:40] <zyga> in the end working on software is fun because of MATCH like bugs
[09:40] <zyga> where we look at a 3 liner
[09:40] <Chipaca> zyga: but am now trying to repro it with debug
[09:40] <zyga> and then look at the error
[09:40] <zyga> and then say WAT
[09:40] <zyga> and are awed by the eventual understanding
[09:41] <pedronis> mvo: hi, thanks for merging that backport, there is also #5442
[09:41] <mup> PR #5442: many: expose publisher's validation throughout the API (2.34) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5442>
[09:41] <mvo> pedronis: aha, looking
[09:43] <mup> PR snapd#5442 closed: many: expose publisher's validation throughout the API (2.34) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5442>
[09:46] <mwhudson> zyga: yeah, it's pretty unusual
[09:46] <mwhudson> zyga: dolphins, seals, even orca are somewhat normal, but a baleen whale?
[09:53] <pedronis> mvo: thanks
[09:55]  * zyga wrote pretty lengthy review for a one liner: https://github.com/snapcore/snapd/pull/5466 
[09:55] <mup> PR #5466: tests: remove extra ' which breaks interfaces-bluetooth-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5466>
[09:55] <zyga> mwhudson: nice, I never saw a whale
[09:56] <mwhudson> zyga: me neither until today!
[09:56] <zyga> 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] <mwhudson> i've never been around when the orca are in the harbour
[09:56] <zyga> mwhudson: imagine how it must feel to dive next to such a creature!
[09:57] <mwhudson> zyga: i thought the paddle boarders were being quite brave enough
[09:57] <mwhudson> zyga: have you seen the bbc series 'the blue planet'?
[09:57] <zyga> is the whale stuck there or just passing by?
[09:57] <zyga> mwhudson: yes, I have it on BD
[09:58] <mwhudson> one of the making of segments has a diver getting a bit too close to a whale + calf
[09:58] <zyga> watching that makes me think I made some bad life decisions by working on computers all day long
[09:58] <zyga> too close? maybe I missed that part
[09:58] <mwhudson> as far as anyone can tell the whale is just hanging out
[09:58] <mwhudson> it's been here for three days now?
[09:59] <zyga> did you take that photo with your phone?
[09:59] <mwhudson> i can't imagine there's a lot of krill in the harbour but what do i know
[09:59] <zyga> or with a telelens?
[09:59] <mwhudson> yeah
[09:59] <mwhudson> doesn't the terrible unsharp mask give it away? :)
[09:59] <zyga> haha, well, maybe this is a smoker whale who likes the smell of oil and gasoline ;-)
[09:59] <zyga> haha, kind of :D
[10:00] <zyga> if you have a camera now would be a great time to take some time off and photograph it
[10:00] <zyga> maybe that could go to the community showcase
[10:00]  * mvo seconds that
[10:00] <mwhudson> i guess it was ~300 metres away when i saw it
[10:00] <zyga> ubuntu wacky whale anyone :D
[10:00] <mwhudson> well unsurprisingly there are billions of much better photos on twitter & fb etc
[10:00] <zyga> yeah, that is how the times are
[10:01] <mwhudson> https://www.facebook.com/photo.php?fbid=10155927798194830&set=a.383547374829.165096.535824829&type=3&theater
[10:01] <zyga> 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] <mwhudson> for example
[10:01] <zyga> but then I learned one of the heavyweights did just that
[10:01] <zyga> (forgot which now)
[10:01] <zyga> woah
[10:01] <niemeyer> Mornings
[10:01] <zyga> fantastic photo
[10:01] <zyga> hey Gustavo :)
[10:01] <niemeyer> mborzecki: Some comments in #5459
[10:01] <mup> PR #5459: cmd/snap: add 'debug paths' command <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5459>
[10:03] <mborzecki> niemeyer: hey, thanks for the review!
[10:03] <niemeyer> mborzecki: Heya, np
[10:04] <mup> PR snapd#5471 closed: dirs: fix antergos typo <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5471>
[10:05] <mborzecki> niemeyer: given your comemnt, that would be SNAP_MOUNT,  SNAP_BIN, SNAPD_LIBEXEC
[10:05] <zyga> fatal: unable to access 'https://github.com/kardianos/govendor/': Failed to connect to github.com port 443: Connection timed out
[10:05] <zyga> I wonder if there's something simple we can pass to govendor to retry those
[10:06] <mborzecki> zyga: that's go get
[10:06] <zyga> aha
[10:07] <zyga> seems not
[10:07] <zyga> we could grep
[10:07] <zyga> but :/
[10:07] <zyga> mvo: do you think we should grep for "Failed to connect" and retry?
[10:11] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/5457
[10:11] <mup> PR #5457: many: lessen the use of core-support <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5457>
[10:11] <niemeyer> mborzecki: Not sure I get the question
[10:11] <mup> PR snapd#5466 closed: tests: remove extra ' which breaks interfaces-bluetooth-control test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5466>
[10:11] <zyga> mborzecki: now that https://github.com/snapcore/core/pull/92 has landed we need this
[10:11] <mup> PR core#92: Remove core-support plug <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/core/pull/92>
[10:11] <zyga> CC mvo
[10:12] <niemeyer> 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] <mborzecki> 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] <mvo> zyga: I looked at this one, no?
[10:17] <zyga> mvo: yes just letting you know we need to merge it :)
[10:17] <niemeyer> mborzecki: The review provides the exact background for $SNAP_ vs. $SNAPD_.. did you read it? :)
[10:17] <zyga> mvo: or tests will complain about missing core-support-plug
[10:19] <zyga> mvo: looking at core PRs I'd suggest to look at and close https://github.com/snapcore/core/pull/38
[10:19] <mup> PR core#38: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[10:19] <pstolowski> zyga: addressed your feedback to https://github.com/snapcore/snapd/pull/5416
[10:19] <mup> PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>
[10:19] <zyga> pstolowski: perfect, looking
[10:20] <niemeyer> 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] <mup> PR core#91 closed: hooks: add a check to ensure that the image is build with ppa:snappy-dev/image <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/91>
[10:21] <zyga> pstolowski: reviewed
[10:21] <niemeyer> 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] <niemeyer> mborzecki: The mount dir of a snap is actually at /snap/<snap name>/<revision>
[10:23] <niemeyer> Which we call $SNAP for the snap
[10:25] <niemeyer> mborzecki: snap.Info.MountDir also returns /snap/<snap>/<rev>, not /snap
[10:25] <zyga> drat, I don't have my opensuse account password here
[10:25] <zyga> I'll ask my wife later today
[10:29] <mborzecki> 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] <niemeyer> 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] <niemeyer> mborzecki: $SNAP_COMMON, $SNAP, $SNAP_DATA, ...
[10:31] <niemeyer> mborzecki: While SNAPD_* is for snapd.. $SNAPD_DEBUG, ...
[10:31] <mborzecki> ack
[10:32] <niemeyer> 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] <niemeyer> zyga: COmment on #5457
[10:39] <mup> PR #5457: many: lessen the use of core-support <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5457>
[10:44] <zyga> looking
[10:46] <zyga> niemeyer: replied
[10:48] <niemeyer> zyga: Replied the reply...
[10:48] <niemeyer> I wish GH would notify instead of us using IRC that way :)
[10:48] <zyga> haha, yes
[10:50] <zyga> niemeyer: replied again
[10:51] <zyga> 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] <niemeyer> 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] <zyga> no, you misunderstand
[10:52] <zyga> that is not what is tested
[10:52] <niemeyer> Man.. do I need to copy & paste the test? :)
[10:52] <niemeyer>  details: |
[10:52] <niemeyer>      The "snap interface" command displays a listing of used interfaces
[10:52] <niemeyer>  execute: |
[10:52] <niemeyer> -    snap interface | MATCH 'core-support\s+ special permissions for the core snap'
[10:52] <zyga> snap interface lists interfaces that are _present_ in the system as plugs or slots
[10:52] <zyga> it doens't list interfaces that are known but not present as plugs or slots
[10:53] <niemeyer> Ah.. okay, that's what I missed
[10:53] <zyga> 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] <niemeyer> zyga: And what about this:
[10:53] <niemeyer> -    snap interface core-support > out.yaml
[10:53] <niemeyer> +    snap interface network > out.yaml
[10:53] <niemeyer> -    diff -u out.yaml snap-interface-core-support.yaml
[10:53] <zyga> and hence used the network interface instead
[10:54] <zyga> this just shows how plugs and slots are reported by "snap interface IFACENAME"
[10:54] <niemeyer> zyga: Do we have other tests for it?
[10:54] <zyga> this is why I also added the test snap to have a connection
[10:54] <zyga> for the core-support test, no I don't believe we do
[10:54] <zyga> it used to be tested by various core configuration test
[10:54] <zyga> *tests
[10:55] <zyga> but those stopped exercising that code
[10:55] <zyga> from my POV that interface is stuck as-is until we can understand why some snaps are abusing it
[10:55] <zyga> and shift them away from it
[10:55] <niemeyer> So we're back to the same point
[10:55] <niemeyer> We should either remove the interface, or tes it
[10:55] <niemeyer> test it
[10:55] <zyga> well, I disagree, I didn't remove an existing test for the functionality of this interface since we didn't have one
[10:55] <zyga> 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] <zyga> I hope you agree about this point specifically
[10:57] <zyga> FYI, I clarified my last comment
[10:57] <zyga> (on GH)
[10:59] <niemeyer> zyga: I see.. the test goal was just checking "snap interface" itself, not the core one specifically
[10:59] <zyga> yes
[10:59] <zyga> exactly so
[10:59] <pstolowski> 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] <mborzecki> pstolowski: mount isuse?
[11:00] <niemeyer> zyga: We probably have tests for that interface originally, but they were about the hook which don't need the interface anymore
[11:00] <pstolowski> mborzecki: yes
[11:00] <zyga> niemeyer: yes, I think so as well
[11:00] <niemeyer> zyga: So why do we need the interface again?
[11:00] <pstolowski> mborzecki: can i restart or do you want to take a look at the log?
[11:00] <mborzecki> pstolowski: go ahead and restat
[11:00] <pstolowski> k
[11:00] <zyga> niemeyer: we found that one of our customers has a snap declaration for using it on some of their snaps
[11:00] <zyga> niemeyer: they are probably using it for the unconfined systemctl access
[11:01] <zyga> niemeyer: I believe we are trying to get in touch with them to discuss this
[11:01] <pstolowski> mborzecki: is this test flakiness or something deeper?
[11:01] <zyga> 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] <mborzecki> pstolowski:  no clue yet, there's a forum topic tracking this problem
[11:01] <mborzecki> pstolowski: it's usually associated with I/O errors on loop devices
[11:01] <niemeyer> zyga: Well, that's definitely not what this is supposed to do
[11:02] <zyga> niemeyer: interesting observation, no? I think this is something to learn from
[11:02] <zyga> niemeyer: yeah but I don't think we should pull the rug from under their feet without asking first
[11:02] <niemeyer> zyga: How's that not blocked with the declaration?
[11:02] <niemeyer> zyga: Pretty sure jdstrand wouldn't hand that off
[11:02] <mvo> 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] <zyga> niemeyer: they have their store, they just signed a declaration that grants this
[11:03] <niemeyer> zyga: Okay, let's just drop this then
[11:03] <zyga> mm?
[11:03] <zyga> drop the interface you mean?
[11:04] <niemeyer> zyga: Drop the permissions granted by the interface
[11:04] <zyga> keep the interface but make it empty or remove it entirely?
[11:04] <niemeyer> zyga: Keep the interface, drop permissions
[11:04] <zyga> ok
[11:04] <zyga> can we land this PR then, I will open a new one that drops the actual permissions
[11:04] <zyga> we need this PR because we removed core-support-plug from core
[11:05] <niemeyer> zyga: Yeah, the PR is fine
[11:05] <niemeyer> zyga: Who's the contact on our end?
[11:05] <zyga> thanks! sorry for not including more context in the PR itself
[11:05] <zyga> niemeyer: I think lool
[11:05] <niemeyer> lool: ping
[11:06] <niemeyer> zyga: I'll also revive the conversation about the fact people granting arbitrary permissions like that for their devices is completely bogus
[11:06] <zyga> niemeyer: but I need to re-check, pedronis noticed this as he helped to find this
[11:06] <zyga> niemeyer: thank you
[11:06] <zyga> niemeyer: we may have some extra constraint on interface policy
[11:06] <niemeyer> zyga: np, thanks for the info
[11:06] <pedronis> niemeyer: we didn't ping anybody so far,  I wanted to mention it in the standup yesterday
[11:06] <zyga> niemeyer: that really limits it to specific snaps in a way that cannot be forced from the store
[11:06] <zyga> niemeyer: so that in the future things like that don't happen
[11:06] <niemeyer> zyga: No, the bug here is people being able to sign snap-declarations blindly
[11:07] <zyga> niemeyer: snice this ties our hands as to what we can do for internal bits
[11:07] <zyga> niemeyer: I see, ok
[11:07] <pedronis> niemeyer: about the blocking of this self-granting, we will have more control as part  of the work planned in this cycle
[11:07] <zyga> niemeyer: without counter signature and review?
[11:07] <niemeyer> zyga: Exactly
[11:07] <zyga> yeah, this makes sense
[11:07] <niemeyer> pedronis: Okay, I'll try to put something on the agenda for the sprint
[11:07] <zyga> ok, I'll prepare another PR now
[11:07] <pedronis> niemeyer: I need to resync with jdstrand on that
[11:08] <niemeyer> pedronis: We need to act on this.. we discuss it as high-priority a few times, but we didn't really get any work items on the schedule yet
[11:08] <niemeyer> *discussed
[11:08] <pedronis> niemeyer: we do
[11:08] <niemeyer> pedronis: Oh?
[11:08] <pedronis> one sec
[11:10] <pstolowski> zyga: hmmm. gnome-calculator stopped working on 18.04, it wants me to connect gnome interface (which somehow got disconnected at some point); I reconnected it and it is connected per 'snap interfaces', but apparmor says: audit: type=1400 audit(1530788803.989:110): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.gnome-calculator.gnome-calculator"
[11:10] <pstolowski> pid=22099 comm="apparmor_parser
[11:11] <zyga> the STATUS is just spam, it doesn't say anything bad
[11:11] <zyga> pstolowski: can you tell me how this happened
[11:11] <zyga> I know of one other case but we didn't manage to either reproduce it or figure out how it came to be
[11:11] <zyga> pstolowski: please tell me all you know
[11:12] <pstolowski> zyga: i've no idea. i'm running stable. i've just made a copy of state.json before reconnecting, so i can try to find something there. there were no 'snap changes' reported
[11:13] <zyga> was this in a VM with random tests running or on your machine?
[11:13] <zyga> can you look at logs from snapd (all of them)
[11:13] <pstolowski> zyga: so this must have happened some time ago, i just didn't notice until i tried to use gnome-calculator today
[11:13] <zyga> aha
[11:13] <zyga> what is your uptime?
[11:13] <pstolowski> zyga: 3 days
[11:14] <pstolowski> zyga: and it's not VM, it's my main box
[11:14] <zyga> hmmm hmm
[11:14] <zyga> can you please collect fstab files for that snap
[11:14] <Chipaca> grr grr MATCH grr
[11:14] <zyga> the two, one in /var/lib/snapd/mount and the other in /run/snapd/ns
[11:15] <zyga> pstolowski: also, since you have a mount namespace, can you please collect the mountinfo from that namespace (ping if you need aid)
[11:16] <zyga> pstolowski: my only theory is as follows
[11:17] <zyga> pstolowski: oh one more detail please, collect timestamps from all the files, including the .mnt file
[11:17] <zyga> pstolowski: content connections are non-fatal, if you conncet but we fail to mount, we just carry on
[11:17] <zyga> pstolowski: we do mark the thing as not mounted though
[11:17] <zyga> pstolowski: something is either causing that to unmount
[11:18] <zyga> pstolowski: or the logic is wrong and we thing we mounted (I need to ensure this is strictly tested)
[11:18] <zyga> pstolowski: I wonder if refreshing content snap is doing the right thinh
[11:18] <zyga> *thing
[11:18] <zyga> I will look into this soon
[11:18] <zyga> pstolowski: please collect this in the forum, I suspect there's one thread about this but if no, make one
[11:18] <pstolowski> zyga: re namespaces, you need mount output after sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt ?
[11:19] <zyga> cat /proc/self/mountinfo
[11:19] <pstolowski> ok
[11:19] <zyga> but yes
[11:20] <diddledan> ergh. SNAPCRAFT_BUILD_ENVIRONMENT=lxd has always been a pain for me when running `snapcraft clean ...` the pull step seems to pull the parts' sources as uid 1000 which doesn't seem to be mapped properly to my host userid and thus clean cannot delete the files
[11:20] <mup> PR snapd#5470 closed: tests: fixes for the autopkgtest failures in cosmic <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5470>
[11:21] <zyga> niemeyer: can you please approve 5457
[11:23] <niemeyer> zyga: Sorry, just working on the side effects of this mess
[11:23] <zyga> niemeyer: sure, no worries :)
[11:23] <diddledan> paste of an affected source tree on my host: http://paste.ubuntu.com/p/XPW37s4gTq/ and within the build container: http://paste.ubuntu.com/p/hvPFZQqGMz/
[11:23] <zyga> niemeyer: this is the follow up https://github.com/snapcore/snapd/pull/5472
[11:24] <mup> PR #5472: interfaces: make core-support a no-op interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5472>
[11:24] <mup> PR snapd#5472 opened: interfaces: make core-support a no-op interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5472>
[11:24] <niemeyer> zyga: Too late, but this was abusing "many:"
[11:24] <zyga> Thank you!
[11:24] <zyga> :-)
[11:24] <niemeyer> zyga: This was actually a single directory
[11:25] <zyga> ah, sorry, I probably kept the name from earlier branch
[11:25] <zyga> yep
[11:25] <mup> PR snapd#5457 closed: many: lessen the use of core-support <Core18> <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5457>
[11:25] <zyga> ok little by little :) core 18 here we come
[11:28]  * Chipaca ~> lunch
[11:28] <niemeyer> zyga: Follow up LGTM except for summary (comments there)
[11:29] <zyga> thanks!
[11:30] <pstolowski> zyga: https://forum.snapcraft.io/t/gnome-calculator-suddenly-disconnected-from-gnome-platform-snap-reconnecting-doesnt-help/6256
[11:31] <zyga> pstolowski: looking
[11:31] <pstolowski> zyga: let me know if there is anything else to capture; i'll look into state in a moment
[11:31] <zyga> pstolowski: please add fstab files
[11:31] <zyga> they are essential
[11:31] <zyga> and timestamps on all the three files
[11:31] <zyga> and snap changes for the content snap (if any)
[11:32]  * diddledan twiddles his thumbs
[11:32] <zyga> pstolowski: also snap list --all would help, for the inactive revisions
[11:32] <zyga> diddledan: hey, sorry for not being able to help you
[11:32] <zyga> I saw your question but I don't know enough about snapcraft to help
[11:32] <diddledan> :-)
[11:33] <pstolowski> zyga: sure, doing
[11:33] <zyga> thanks
[11:36] <pstolowski> zyga: updated
[11:38] <zyga> pstolowski: you missed /run/snapd/ns/
[11:38] <zyga> that has more fstab files :)
[11:38] <zyga> (and the important one is there)
[11:41] <pstolowski> aha. ok
[11:42] <pstolowski> zyga: how about now?
[11:44] <pstolowski> pedronis: disconnect-hooks PR is ready for re-review.. it grew a bit unfortunately. changes worth nothing are: individual disconnects, a "automatic-disconnect" flag on disconnect tasks, handling of undo (connect-* hooks run if disconnect hooks are undone).
[11:46] <niemeyer> zyga: #5454 also +1d with a trivial
[11:46] <mup> PR #5454: interfaces: prefer "snapd" when resolving implicit connections <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5454>
[11:46] <niemeyer> zyga: Thanks for the nice breakdown of those issues, btw
[11:47] <Chipaca> niemeyer: reminder to take a look at #1779859 when you can
[11:47] <mup> Bug #1779859: tracks should be ordered <Snap Store:Confirmed> <https://launchpad.net/bugs/1779859>
[11:48] <zyga> niemeyer: thank you!
[11:49] <zyga> pstolowski|lunch: ah, you've gone for lunch
[11:49] <zyga> after you are back, please run snap-update-ns on that snap
[11:49] <zyga> I'm super curious what the result will be
[11:49] <zyga> guys, I need to run, my dog makes it crystal clear what I should be doing now (not hacking)
[11:53] <PLA1> Hi. I have two 18.04 machines both up-to-date. One has snap version 2.32.9+18.04 and the other snap version 2.33.1. How can I get the other machine up to 2.33.1? I've tried `apt install snap`. Having a boot issue with the other machine and wonder if it is affected by this https://forum.snapcraft.io/t/snapd-service-delays-startup-in-ubuntu-18-04-with-4-15-0-24/6205 Thanks.
[11:53] <Chipaca> PLA1: how are you checking the versions of snapd?
[11:54] <PLA1> snap version
[11:54] <niemeyer> Chipaca: Done!
[11:54] <Chipaca> niemeyer: taw
[11:55] <Chipaca> PLA1: do you have snaps installed in the one that says 2.32.9+18.04?
[11:55] <PLA1> I don't think there are any snaps installed on either machines. What is that command to list?
[11:55] <Chipaca> PLA1: try 'snap list core'
[11:56] <PLA1> The 2.33.1 has core installed the other does not.
[11:57] <Chipaca> PLA1: that's your answer: install core (snap install core) to get 2.33.1 in the other one as well
[11:57] <PLA1> OK. Thanks.
[11:58] <PLA1> Both at 2.33.1 now. Lets see if that fixes his boot problem. Thanks!
[12:04] <zyga> re
[12:04] <zyga> wow, I can work from here :)
[12:08] <zyga> pstolowski|lunch: one more idea to explore once you are back
[12:09] <Chipaca> zyga: where's 'here'?
[12:09] <zyga> Chipaca: hop into standup
[12:09] <zyga> hhh
[12:09] <zyga> darn
[12:09] <zyga> I didn't take my token :P
[12:09] <zyga> let me ask my son for help
[12:12] <Chipaca> most boring standup EVAR
[12:14] <Chipaca> featuring me having lunch like a caveman
[12:14] <zyga> hahah
[12:15] <zyga> pstolowski|lunch: run journalctl | grep 'Unmounted Mount unit for gnome-*'
[12:16] <zyga> pstolowski|lunch: this will show us some history of the mount units
[12:16] <zyga> this can eliminate any chance that event propagation caused this
[12:16] <zyga> thanks, I'll tend to other tasks until you are back
[12:20] <lool> niemeyer: pong
[12:20]  * zyga tunes in 
[12:21] <zyga> Chipaca: I'll ping you once my kids arrive with the token :P
[12:21] <mup> PR snapd#5473 opened: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>
[12:22] <jdstrand> zyga: re https://github.com/snapcore/snapd/pull/5469> ok
[12:22] <mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[12:22] <Chipaca> zyga: the byzantine generals needed kids, clearly
[12:23] <mup> PR snapd#5474 opened: many: finish sharing a single TaskRunner with all the the managers <Created by pedronis> <https://github.com/snapcore/snapd/pull/5474>
[12:23] <zyga> Chipaca: how many do I need for the minimal algorithm to wokr?
[12:23] <zyga> *work
[12:24] <Chipaca> zyga: 3, but uniformly 3 levels deep
[12:24] <zyga> Chipaca: drat
[12:24] <zyga> Chipaca: well, I can perhaps say that now :)
[12:24] <zyga> Chipaca: 3rd is on the way now
[12:24] <zyga> Chipaca: I'm in the standup if you want to chat
[12:24] <Chipaca> zyga: congrats!
[12:25] <mup> PR snapd#5416 closed: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5416>
[12:25] <mup> PR snapd#5475 opened: Remove unneeded calls to daemon-reload <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5475>
[12:25] <Chipaca> zyga: you're not in the standup
[12:27] <PLA1> Snap had nothing to do with the problem. Not sure what it is but I moved the other box from LightDM to GDM. Good to go. Thanks again.
[12:28] <mup> PR snapd#5476 opened: snapstate: make sure all *link-*snap tasks carry a snap type and further hints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5476>
[12:29] <zyga> thanks John
[12:29] <Chipaca> zyga: np
[12:32] <zyga> niemeyer: this is not urgent but could you please append https://github.com/snapcore/snapd/pull/5307 to your review list
[12:32] <mup> PR #5307: cmd/snap-confine: allow hard-coded mounts to be optional <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
[12:35] <zyga> pstolowski|lunch: were those messages from pre-reboot? we only need the one from _this_ boot
[12:36] <pstolowski|lunch> zyga: added journalctl output, looks totally fine
[12:36] <niemeyer> zyga: The comment I made there earlier still seems relevant.. this PR is unused and untested.
[12:36] <niemeyer> zyga: Can we please have these changes together with the tests that demonstrate how this is supposed to work?
[12:36] <lool> zyga: what's the PR we're considering? lots of PR discussed  :-)
[12:36] <zyga> niemeyer: I specifically explained why that is, those are tested in the two follow-up PRs, that code doesn't have any more tests and adding them here would be non trivial
[12:37] <zyga> niemeyer: there is a spread test at the end, I believe
[12:37] <zyga> pstolowski|lunch: yes, but was it from all the boots or just from the current one?
[12:37] <niemeyer> zyga: No, no tests
[12:37] <zyga> niemeyer: I can put the remaining patches into this PR, sure
[12:38] <zyga> niemeyer: I missed this when reading: zyga: Can we please have these changes together with the tests that demonstrate how this is supposed to work?
[12:38] <zyga> thanks!
[12:38] <niemeyer> zyga: Breaking down independent PRs is nice, but it feels a bit over the limit to be pushing logic that is completely untouched by anything
[12:40] <jdstrand> mvo: re core16> ack. I manually approved r1. for r2-r6, please request a manual review and I'll approve
[12:42] <ogra_> jdstrand, the process-control interface allows me to send signals to processes, but doesnt allow me to exec kill or pkill from the core snap, couldnt we allow these two commands so one doesnt need to ship them in the snap ?
[12:43] <jdstrand> niemeyer (cc pedronis): fyi, the brand store declaration work is on the spreadsheet for this cycle already
[12:43] <pedronis> jdstrand: yes, pointed that out on a different channel
[12:44] <jdstrand> ah yes, I see that now
[12:50] <zyga> mvo: I'm re-working the last patch of the set, I think this will correctly handle all the edge cases, transitions and what not
[12:51] <mvo> zyga: \o/
[12:51] <zyga> mvo: I will share a little while after the standup as I'm making some more changes based on experiments and some thinking
[12:51] <mvo> zyga: can't wait to see/try it
[12:51] <mvo> zyga: sure
[12:51] <zyga> mvo: let's HO then to discuss if this is sane
[12:51] <mvo> ok
[12:58] <mup> PR snapd#5454 closed: interfaces: prefer "snapd" when resolving implicit connections <Core18> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5454>
[13:00] <niemeyer> zyga, mvo, all: Won't attend the standup.. have a conflict today
[13:00] <mup> PR snapd#5472 closed: interfaces: make core-support a no-op interface <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5472>
[13:01] <mvo> niemeyer: ta
[13:01] <mvo> 708947
[13:01] <mvo> niemeyer: thanks for the heads up
[13:07] <ogra_> hmm, how can snap and snapd be at different versions in "snap version" output .. thats weird https://forum.snapcraft.io/t/creating-a-python-daemon-to-interact-with-gpio/6177/10
[13:08] <ahoneybun> wow :     1min 38.255s snapd.seeded.service
[13:09] <jdstrand> ogra_: added to the list for the next batch of updates
[13:09] <ogra_> ahoneybun, pfft ... try on an arm board
[13:09] <ogra_> jdstrand, thanks, thats really helpful i think
[13:10] <ogra_> ahoneybun, i have an image seeding 2 snaps (mir-kiosk and chromium-mir-kiosk) that takes 20+ minutes for the first boot (15 of that just seeding chromium)
[13:10] <ogra_> i'd *love* to have an 1:38 firstboot :)
[13:16] <Chipaca> ogra_: they can get out of sync if somebody has cobbled together the system out of random bits they found on the internet
[13:17] <ogra_> Chipaca, well, this seems to be a dell customer with an edge gateway (the caracalla gadget seems to be in use, there are interfaces called caracalla)
[13:17] <Chipaca> ogra_: this is a core system, so no re-exec
[13:17] <ogra_> right
[13:17] <Chipaca> ogra_: because you're supposed to already be booting from core
[13:18] <ogra_> no re-exec but also snap and snapd come from the same core snap usually
[13:18] <Chipaca> ogra_: so I'd first inquire how they built or otherwise obtained the system
[13:18] <Chipaca> ogra_: e.g. if they copied it in some weird way
[13:19] <Chipaca> ogra_: i mean: if all were ok, it's impossible
[13:19] <Chipaca> ogra_: so something is not ok
[13:19] <Chipaca> ogra_: i'd start with #0: users lie
[13:19] <Chipaca> ogra_: and go from there :-)
[13:21] <ogra_> yeah, i asked if he tinkered with the install in some form
[13:23] <jdstrand> roadmr: hi! can you pull r1093 of the review tools?
[13:23] <jdstrand> mvo: that has the core16 override adjustments ^
[13:23] <roadmr> jdstrand: hello! certainly, I'll start the usual paperwork
[13:25] <roadmr> jdstrand: when time permits, could you help reply to this folk: https://forum.snapcraft.io/t/my-snap-lbe-device-management-was-rejected-on-the-store/6242/2 Also we were wondering if there's like a boilerplate text (perhaps more detailed than what the review tools say) we could use for people requesting snapd-control. If what the tools reply is enough in your opinion, that works as well
[13:27] <jdstrand> roadmr: I thought your answer was great. there is boilerplate in the wiki: "The snapd-control interface is reserved for snaps that require device ownership and the ability to control all aspects of snaps on the system and is not usually needed for typical snaps. If the access is required, consider using a brand store or create a forum topic at https://forum.snapcraft.io/ using the 'store' category if this can be discussed in public or the 'sensitive
[13:28] <jdstrand> roadmr: I can adjust the review-tools too. let me try to do something for r1094 real quick
[13:29] <roadmr> jdstrand: yes, that's pretty much what the tools say, which I thought was clear
[13:29] <roadmr> in that respect, what this person did was correct, he came to the forum, and in there we can explain in more detail and discuss with them
[13:33] <jdstrand> roadmr: it isn't clear who should respond. really, this is a brand store question
[13:34] <jdstrand> roadmr: I'll ping kyleN in the topic
[13:35] <roadmr> jdstrand: right... well in a sense it's not a brand store question since his snap exists in the global store. So if he doesn't make a good case for that, a simple "denied but you can register a snap name to your brand store and do it there - don't have one? talk to Kyle!" might be good.
[13:38] <jdstrand> roadmr: Ok, I'll adjust the wiki then
[13:38] <roadmr> thanks jdstrand
[13:38] <mvo> jdstrand: \o/
[13:45] <pstolowski> zyga: what was the command you wanted me to try?
[13:47] <pstolowski> Trevinho: ping
[13:58] <zyga> pstolowski: sudo /usr/lib/snapd/snap-update-ns gnome-calculator
[13:58] <zyga> mvo: re, I'm back home now, it was too hot in the sun
[13:58] <zyga> mvo: I'm mid-way through lunch (which doubles as bfast)
[13:58] <zyga> mvo: I'll give you an update soon
[14:00] <roadmr> brunch. What even is brunch?
[14:01] <jdstrand> roadmr: how is this: https://paste.ubuntu.com/p/DbWDvmQGyG/ ?
[14:02] <niemeyer> mvo: Do you have sec for a quick call?
[14:02] <niemeyer> pedronis: You too if you have a moment
[14:04] <roadmr> jdstrand: great, looks good! more informative about the prospect of brand stores
[14:08] <mvo> niemeyer: sure
[14:08] <niemeyer> mvo, pedronis: https://meet.google.com/dob-pjfr-rkz
[14:10] <pstolowski> zyga: this didn't help
[14:11] <pstolowski> willcooke: ping
[14:13] <zyga> pstolowski: that's consistent with what I suspected then
[14:13] <zyga> pstolowski: thank you
[14:18] <mborzecki> https://www.reddit.com/r/linux/comments/8waf37/ubuntu_1804_linux_kernel_update_causes_boot/
[14:21] <pstolowski> zyga: np
[14:22] <willcooke> pstolowski, hey
[14:23] <pstolowski> willcooke: hey, who is the best person to talk about gnome-calculator snap (and other gnome- snaps)?
[14:23] <willcooke> pstolowski, kenvandine
[14:23] <pstolowski> willcooke: great, thanks
[14:24] <willcooke> pstolowski, he's travelling this week to GUADEC, so he might not be active on IRC - if you get stuck drop an email our way
[14:24] <kenvandine> pstolowski, i'm arround, but in a meeting
[14:24] <kenvandine> pstolowski, and email would be best
[14:27] <pstolowski> kenvandine: sure
[14:29] <roadmr> jdstrand: pardon the silliness, where's the wiki with the text you pastebinned earlier?
[14:31] <jdstrand> roadmr: https://wiki.canonical.com/AppStore/Reviews
[14:32] <roadmr> jdstrand: thanks! We'll keep it as reference for the future
[14:33] <jdstrand> roadmr: I suggest also subscribing to the page
[14:33] <roadmr> Done! good idea jdstrand, thanks
[14:35] <pedronis> niemeyer: was afak having a break
[14:36] <niemeyer> pedronis: No worries, all good, we can sync tomorrow in the standup if we don't have an earlier opportunity
[14:36] <zyga> mvo: still iterating over this
[14:36] <zyga> mvo: I think the idea is sound but maybe not the direct implementation I went for
[14:36] <zyga> mvo: (large and boring change)
[14:42] <mvo> zyga: ok
[14:45] <zyga> mvo: tests are not failing anymore, let me see if spread works
[14:49]  * zyga -> coffee and more shade
[14:49] <zyga> my laptop is super hot from the sun
[14:50]  * genii slides zyga a fashionable parasol
[14:53] <roadmr> genii: it's for the laptop, I bet zyga is happy to get some sunshine after the long polish winter :)
[14:53] <mvo> pedronis: are you ok with the current state of 5422, i.e. does the todo capture the plan correctly?
[14:56] <mvo> niemeyer: your opinion on 5440 would be great, no need for an in-depth code review (also that is welcome as well of course), more the question in the PR description. in a nutshell the question is: right now if refresh.timer is set we ignore refresh.schedule. should we do the same if "reresh.schedule=managed" is set? because in the old code we look at this special "managed" propoerty first before looking at refresh.timer/sc
[14:56] <mvo> hedule. it means we *might* break people with refresh.schedule=managed but refresh.timer=some-thing-else (hope the question make sense, the PR also explain it slightly more verbosely)
[14:57] <niemeyer> The question makes sense, but it's not clear what "should we do the same" means in this context
[14:58] <niemeyer> It could mean two different things: 1) Respect refresh.schedule=managed; 2) Respect refresh.timer=managed
[14:58] <mup> PR snapd#5458 closed: tests: check catalog refresh before and after restart snapd <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5458>
[14:58] <mup> PR snapd#5467 closed: tests: stop restarting journald service on prepare <Blocked> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5467>
[15:00] <niemeyer> mvo: I think we should keep the invariant: if we set refresh.timer, the value of the old setting doesn't matter anymore, whatever its value
[15:00] <zyga> roadmr: yes, this year the summer has really arrived early, with the exception of last week it's a record-breaking year in many cases
[15:00] <roadmr> zyga: like my neighbor says, "the weather is all f**d up"
[15:01] <niemeyer> mvo: Then, we should respect "managed" in the new setting, in a way equivalent to how we respected it in "refresh.schedule" before
[15:01] <roadmr> record heat, then record cold... ti's all insane
[15:02] <Chipaca> roadmr: add more energy to a system and you're going to see more extremes to any oscillations you saw before (as long as you don't break it)
[15:02]  * Chipaca crosses fingers
[15:02] <roadmr> Chipaca: oh we're well on our way to break it :(
[15:03] <Chipaca> roadmr: eh, probably not
[15:03] <Chipaca> roadmr: i mean, we might all die, but it looks like earth'll be just fine
[15:04] <Chipaca> we should start burying stuff for non-human archeologists of the future just to mess with them though
[15:04] <mvo> niemeyer: the PR implements the behavior that if refresh.timer is set the setting of refresh.schedule is ignored, so it seems the PR is fine and my questions is answered
[15:04] <roadmr> Chipaca: https://wiki.canonical.com/Quotes#A_matter_of_rates
[15:05] <pstolowski> zyga: as expected, nothing interesting in my state.json wrt gnome-calc issue
[15:07] <niemeyer> mvo: Cool, I can review this afternoon it if you want, or LGTM if you think that's good enough info
[15:07] <mup> PR snapd#5430 closed: tests: enable new fedora image with test dependencies installed <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5430>
[15:07] <mup> PR snapd#5448 closed: tests: start using the new opensuse image with test dependencies <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5448>
[15:08] <zyga> pstolowski: can you corelate the mount/unmount logs you gave from journalctl with your reboot to check if _any_ of those happened since your last boot
[15:08] <mup> PR snapd#5399 closed: tests: moving install of dependencies to pkgdb helper <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5399>
[15:08] <zyga> pstolowski: I believe you can do this with journalctl -b -1
[15:08]  * zyga checks
[15:09] <zyga> hmm
[15:09] <zyga> run journalctl --list-boots
[15:10] <zyga> actually it's just journalctl -b 0
[15:10] <zyga> pstolowski: ^
[15:14] <pstolowski> zyga: here you go, not sure if it's interesting:
[15:14] <pstolowski> https://www.irccloud.com/pastebin/aUJvZDwq/
[15:14] <mup> PR snapd#5242 closed: tests: new test for joystick interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5242>
[15:14] <pstolowski> zyga: and my system was started on Jul 1, 20:48
[15:16] <mvo> pedronis: 5197 looks good, I would love a test tweak but I'm inclinded to merge just to get it into 2.34 - or is there a reason not to have it there?
[15:17] <pedronis> mvo: afaik  the text  hasn't been finalized
[15:18] <pedronis> mvo: sparkiegeek should know more
[15:18] <mvo> pedronis: aha, I see he added a coment ~1h ago
[15:19] <mvo> pedronis: there is an updated text, I can update/push if you want. I readded blocked for now to ensure it does not get in prematurely
[15:20] <pedronis> mvo: ah, I missed that, yes we have a message, yes please update
[15:20] <zyga> pstolowski: so according to this your system has booted on the 1st, started the two units and never stopped them
[15:20] <zyga> pstolowski: that is useful, thank you
[15:20] <mvo> pedronis: will do, thank you
[15:21] <zyga> pstolowski: I will do some experiments, this is all I needed now
[15:21]  * zyga forgot about the coffee and left it on the fire for too long
[15:21]  * Chipaca ~> cuppa tea
[15:21] <mvo> pedronis: are you ok with the current state of 5422, i.e. does the todo capture the plan correctly? (not sure if you saw this or if I missed the reply)
[15:22] <pstolowski> zyga: np. i'll keep it in the state it is now for some time in case we want to check something else
[15:23] <pedronis> mvo: yes
[15:24] <mvo> pedronis: thanks
[15:28] <pedronis> mvo: are you going to cut a new 2.34 tomorrow?
[15:28] <mvo> pedronis: yes, thats my plan, do final 2.34 tomorrow to ensure it can be tested over my vacation in beta/candidate
[15:28] <mvo> pedronis: anything from your side that should be in it?
[15:29] <pedronis> mvo: I'm discussing with Chipaca about:  https://forum.snapcraft.io/t/showing-edge-and-beta-in-search-results/4004/9
[15:29] <AuroraAvenue> Is there a list of games that are snaps on ubuntu on the net sommewhere ?
[15:29] <mvo> reviews for 5440, 5422 would be great
[15:29] <mvo> pedronis: thanks, let me look
[15:30] <pedronis> mvo: we don't have a PR yet,  it would be small, once we know what exactly needs to go in it
[15:31] <mvo> pedronis: ok
[15:31] <mvo> pedronis: it should be fine if its done until tomorrow evening
[15:33] <mvo> pedronis: 5197 is updated
[15:33] <cachio> mborzecki, to use amazon linux image
[15:33] <cachio> https://paste.ubuntu.com/p/Jt3fhhgYgP/
[15:34] <cachio> you can build spread based on the PR
[15:34] <cachio> until it is merged
[15:38] <zyga> mvo: there?
[15:40] <mvo> zyga: yes
[15:40] <zyga> sorry, my reverse-i-search foo is rusty
[15:40] <zyga> what is the suite to run core18 tests against?
[15:42] <zyga> I want to run the suite that shows core18 with snapd.snap and try interfaces and see what is broken now
[15:42] <mvo> zyga: spread -v google:ubuntu-core-18-64 but you need to enable it in spread.yaml first, one sec
[15:43] <mvo> zyga: http://paste.ubuntu.com/p/pz2ksT63jw/
[15:43] <zyga> thanks
[15:44] <Chipaca> what's a snap that's not devmode, but not in stable? if you know of one offhand
[15:45] <zyga> mmm
[15:45] <mvo> zyga: I get dinner but please keep me updated, I will read backlog
[15:46] <mvo> Chipaca: test-snapd-eds
[15:46] <mvo> Chipaca: only available for i386/amd64 though if that matters
[15:46] <zyga> mvo: ack
[15:47] <Chipaca> mvo: cheers
[15:47] <mvo> yw
[15:49] <zyga> [m]vo: tests are running now
[15:49] <mvo> zyga: woooooooooooooo
[15:49] <mvo> zyga: can't wait for results
[15:49] <zyga> haha, the point of [m]vo is so that you _dont_ read now, enjoy your dinner :)
[15:49] <mvo> zyga: once the interfaces tests work and are pushed I will push a new core18-all-tests-all-fixes PR so that we can run this in gce
[15:50] <mvo> zyga: ;)
[15:50] <zyga> ack
[15:50]  * mvo really goes now
[15:50] <mvo> zyga: or you can do that (push that PR), I don't mind :)
[16:18] <zyga> [m]vo: made some tweaks and re-started, I think it's a bit or a rabbit hole though, I stashed some changes that were going too deep
[16:37] <mup> PR snapd#5311 closed: tests: start active system units on reset <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5311>
[16:48] <zyga> my network is not happy today
[16:48] <zyga> I ran out of my LTE plan
[16:50] <zyga> well, maybe not too bad
[17:05] <ogra_> use buckets
[17:07] <zyga> this ISP has unlimited LTE that's just capped
[17:08] <zyga> but capping at 5Mbit is not that terrible actually
[17:08] <zyga> I will buy a new connection tomorrow as the contract is running out already
[17:08] <zyga> and the new one has an outdoor all-year antenna
[17:08] <zyga> and much better plan
[17:09] <zyga> with enough steel rod I can go above the treeline
[17:10] <zyga> (though not super sure about that as trees are up to 30m tall
[17:10] <zyga> (a bit tall)
[17:11] <zyga> 30-40 meters according to wikipedia
[17:11] <zyga> maybe not above treeline then
[17:12] <zyga> ran core18 tests and didn't notice I stashed the change with main re-enabling
[17:13] <zyga> running with those now
[17:22] <mup> PR snapd#5477 opened: tests: change the poll interval used by the network-bind-consumer snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5477>
[17:22] <zyga> mvo: hmm
[17:23] <zyga> https://www.irccloud.com/pastebin/63my3N4t/
[17:23] <zyga> any ideas?
[17:24] <zyga> snap changes 11 (install basic snap) https://www.irccloud.com/pastebin/zcHdhpuE/
[17:25] <zyga> mvo: other tests are running, I'll let you know once they finish
[18:07] <mvo> zyga: yes, snap install basic needs some of my core18 PRs, the problem is that the fake store does not have core and that is not installed by defalt on core18
[18:07] <mvo> zyga: don't worry aobut this one, its understood and under control
[18:08]  * mvo would love reviews for 5197 5440 5422
[18:55] <zyga> mvo: with my patches I got this far
[18:56] <zyga> hmm
[18:56] <zyga> some pastebin failures
[18:59] <mvo> zyga: how far?
[18:59] <mvo> zyga: awsome, push it
[20:16]  * cachio afk
[20:52] <mup> PR snapd#5478 opened: many: run core18 tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5478>
[22:51] <mup> PR snapcraft#2176 opened: [WIP] tests: use pytest as test runner <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2176>
[23:13] <mup> PR snapd#5479 opened: store, daemon, client, cmd/snap: expose "scope", default to wide <Created by chipaca> <https://github.com/snapcore/snapd/pull/5479>