[04:52] <mborzecki> morning
[05:04] <zyga> Good morning
[05:05] <mborzecki> zyga: kids already at school, yay ;)
[05:15] <zyga> mborzecki: oldest just went to school
[05:15] <zyga> mborzecki: middle one finished breakfast
[05:15] <zyga> mborzecki: youngest one plays with her toys :)
[05:15] <zyga> mborzecki: our son is 170 now
[05:15] <zyga> he's not even 13
[05:15] <zyga> mborzecki: easy landing for the morning https://github.com/snapcore/snapd/pull/7218#pullrequestreview-272716535
[05:16] <zyga> mborzecki: I added the extra checks you asked for
[05:16] <mup> PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
[05:16] <mborzecki> and it's green :)
[05:17] <zyga> woot, thankyou
[05:17] <zyga> another easy ish is https://github.com/snapcore/snapd/pull/7392
[05:17] <mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
[05:17] <zyga> needs 2nd +1
[05:17] <zyga> also green
[05:17] <mup> PR snapd#7218 closed: tests: measure behavior of the device cgroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7218>
[05:29] <zyga> mborzecki: one more kid to walk to school, ttyl
[06:00] <zyga> back now
[06:30] <mborzecki> mvo: morning
[06:32] <mvo> hey mborzecki
[06:36] <zyga> good morning mvo
[06:36] <zyga> mvo: one more review if I can grab your attention :)
[06:36] <zyga> https://github.com/snapcore/snapd/pull/7392
[06:36] <mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
[06:37] <zyga> mborzecki: let's start chopping your classic mount namespace PR as we discussed in private
[06:37] <zyga> it will help with the review and will help with figuring out what is wrong
[06:37] <mvo> hey zyga
[06:38] <zyga> :-)
[06:39] <zyga> mvo: do you know who is the upstream of command-not-found nowadays?
[06:42] <mvo> zyga: foundations, why?
[06:42] <zyga> mvo: I have some patches
[06:47] <mborzecki> mvo: zyga: #7393 really simple
[06:47] <mup> PR snapd#7393 opened: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
[06:47] <mup> PR #7393: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
[06:48] <zyga> mborzecki: +1
[06:48] <mborzecki> thx
[06:58] <mup> PR snapd#7394 opened: tests: move debug section after restore <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7394>
[07:05] <pstolowski> morning
[07:05] <zyga> good morning pawel!
[07:11] <pedronis> pstolowski: hi, what's the status of #7277 ?
[07:12] <mup> PR #7277: [RFC] overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>
[07:12]  * zyga goes to read https://github.com/snapcore/snapd/pull/7381
[07:12] <mup> PR #7381: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7381>
[07:13] <zyga> great for rainy morning focus :)
[07:23] <pstolowski> pedronis: hi, i've addressed your feedback but not yet happy about some aspects, i need to revisit this PR, i haven't looked at it for a while
[07:26] <mborzecki> pstolowski: pedronis: hi
[07:26] <pedronis> pstolowski: it's the last bit of https://trello.com/c/9Clql0BE/299-first-boot-fixes , considering that the initramfs/grub stuff is more nice to have
[07:26] <pedronis> and also not great time given uc20 work
[07:28] <pstolowski> pedronis: ack, going to look at it today
[07:32] <zyga> is it just me or is github not responding very well now?
[07:38] <mup> PR snapd#7393 closed: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
[07:43]  * zyga short break
[07:49] <mup> PR snapd#7394 closed: tests: move debug section after restore <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7394>
[08:38] <Chipaca> zyga: ping
[08:38] <zyga> hey
[08:39] <Chipaca> zyga: hiya
[08:40] <Chipaca> zyga: what's the purpose of osutil.MountOptsToFlags ?
[08:40] <Chipaca> it seems very sensible, but it's not used -- instead, the unchecked MountOptsToCommonFlags is used
[08:41] <zyga> let me look
[08:41] <Chipaca> k
[08:41] <Chipaca> not going to change it, but it caught my attention
[08:41] <Chipaca> (i'm fixing compilation on darwin)
[08:42] <zyga> ah,
[08:42] <zyga> I see it now
[08:42] <zyga> it's the layer on top of common flags that understands x-snapd and filters them out but errors on unknown flags
[08:42] <zyga> let me look at that
[08:42] <zyga> thanks!
[08:43] <Chipaca> zyga: np! tbh it looks like the Common one should be private, if i understand the difference
[08:44] <zyga> if you look at how it is used, common is the one being used because we acknowledge there are flags we don't understand that we just pass to mount
[08:44] <mup> PR snapd#7395 opened: cmd/snap-confine: apply global mount namespace initialization for confined and classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7395>
[08:44] <zyga> so I think the strict version is just unused and could be removed
[08:50] <pstolowski> zyga: any thoughs on https://bugs.launchpad.net/snapd/+bug/1841137 ?
[08:50] <mup> Bug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:Triaged> <https://launchpad.net/bugs/1841137>
[08:53] <zyga> pstolowski: oooh
[08:53] <zyga> interesting
[08:54] <pstolowski> zyga: garbage collection gone wrong?
[08:54] <zyga> there's no garbage collection, it's explicitly managed malloc/free style
[08:54] <zyga> the deleted aspect is super puzzling!
[08:55] <pstolowski> zyga: i mean gc in the sense of removing old revisions automatically
[08:55] <zyga> pstolowski: nitpick: triaged literally means: we know the severity
[08:55] <zyga> setting it to triaged without setting one is weird
[08:55] <zyga> pstolowski: normally mount does that
[08:55] <zyga> pstolowski: libmount removes loopback devices
[08:56] <Chipaca> agreed about triaged
[08:56] <zyga> since I just rebooted
[08:56] <Chipaca> if you don't know the severity it's confirmed, not triaged :-)
[08:56] <zyga> can everyone with a longer uptime run: sudo losetup | grep deleted
[08:56] <zyga> and see if it shows anything
[08:56] <Chipaca> nothing right now but i have seen them before
[08:57] <Chipaca> that's when they appear in unity
[08:57] <Chipaca> i didn't know it was noteworthy :-)
[08:57] <zyga> that's super curious
[08:57] <zyga> I wonder if that's another lowlevel bug in kernel/libmount/systemd
[08:57] <zyga> normally systemd doesn't handle those so more likely in libmount
[08:57] <pstolowski> Chipaca, zyga noted, thanks :)
[08:57] <Chipaca> what snap is it? here it's always been core when i've looked
[08:58] <zyga> mvo, pedronis, mborzecki ^ perhaps you? (sudo losetup | grep deleted)
[08:58] <pstolowski> Chipaca: btw thanks for updating yesterday's bug ;)
[08:58] <zyga> Chipaca: those that refresh
[08:58] <zyga> Chipaca: I will look at adding a test for this though
[08:58] <zyga> Chipaca: refresh tree times
[08:58] <zyga> Chipaca: maybe that's exactly what I saw in the core 18 leak detector
[08:58] <Chipaca> pstolowski: :)
[08:58] <zyga> I saw deleted revisions
[08:58] <pstolowski> Chipaca: there are more snaps than just core there
[08:58] <zyga> so maybe it's a real bug that just doesn't get measured because refreshes are not 10 a day
[08:58] <zyga> pstolowski: thank you!
[08:59] <pedronis> zyga: a bunch for core
[08:59] <zyga> can you check the changes for those if you still have them
[08:59] <zyga> pedronis: I assume you have high uptime
[08:59] <zyga> but that's great, it's probably easy to reproduce then
[08:59] <pedronis> I doubt, they are actuall old revisions
[09:00] <mvo> zyga: none here it seems
[09:00] <pedronis> < 7700
[09:00] <zyga> thanks guys!
[09:00] <mvo> (just ran your command)
[09:00] <zyga> thank you
[09:00] <zyga> pstolowski: thanks for sharing, I was working on this anyway without realizing it is not limited to our test suite
[09:01] <pedronis> zyga: https://pastebin.ubuntu.com/p/wwXft5wyDg/
[09:01] <zyga> pedronis: 18.04?
[09:01] <pedronis> yes
[09:01] <zyga> perfect, thank you
[09:03] <mborzecki> zyga: isn't this because of preserved mount namespaces?
[09:03] <zyga> no
[09:03] <zyga> well
[09:03] <zyga> I don't think so
[09:03] <zyga> it's more involved
[09:03] <zyga> the most surprising part is the deleted element
[09:03] <zyga> but let me write a test first
[09:04] <mborzecki> zyga: deleted seems fine to me, iirc association of a file with a loopback device is done using a file descriptor
[09:04] <zyga> mborzecki: it's not fine
[09:04] <zyga> IMO
[09:04] <zyga> but let's check out little by litte
[09:05] <zyga> it only happens when the parent dentry is removed AFAIR
[09:05] <pedronis> zyga: is this the highest priority thing on your plate?
[09:05] <zyga> pedronis: in terms of wrapping up, it's what I was doing anyway but I was chasing logs from runs, this gives me an idea for a test to write, maybe it will uncover the bug more directly
[09:07] <pedronis> mborzecki: they are not mounted anywhere
[09:08] <zyga> though there are two separate sides here, losetup deleted vs mountinfo deleted
[09:08] <pstolowski> Chipaca: do you know what's the status of https://bugs.launchpad.net/snapd/+bug/1804245 ?
[09:08] <mup> Bug #1804245: empty response from store when throttled allows switch to nonexistent track <snapd:New> <https://launchpad.net/bugs/1804245>
[09:09] <Chipaca> pstolowski: I think i fixed that one :-) updated the bug to reflect
[09:09] <pstolowski> good :)
[09:10] <Chipaca> i just need to confirm
[09:11] <Chipaca> i was wrong i think
[09:11] <Chipaca> digging
[09:13] <pstolowski> zyga: this can be closed? https://bugs.launchpad.net/snapd/+bug/1805866
[09:13] <mup> Bug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866>
[09:14] <zyga> pstolowski: no, why?
[09:14] <zyga> it's a real bug IMO
[09:16] <pstolowski> zyga: ok, it's very old, i assumed it was fixed as otherwise we would probably see it more?
[09:16] <zyga> pstolowski: we don't really boot that often with services, not on classic systems
[09:16] <pstolowski> ok, fair enbough
[09:18]  * pstolowski is stepping down from triaging job for now
[09:23] <jamesh> zyga: is there anything else needed to get https://github.com/snapcore/snapd/pull/6767 merged?
[09:23] <mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
[09:24] <zyga> jamesh: no, just need to finish my review
[09:24] <jamesh> zyga: okay, thanks.
[09:27] <Chipaca> pstolowski: confirmed, fixed in 6ce906f7df2
[09:27] <pstolowski> Chipaca: ty!
[09:27] <Chipaca> updating the bug
[09:40] <mup> PR snapd#7396 opened: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
[09:52] <zyga> pstolowski: I replied to https://github.com/snapcore/snapd/pull/7392#discussion_r320176487 -- let me know if that's okay in your eyes
[09:52] <mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
[09:52] <zyga> pstolowski: I'm happy to have a follow up
[09:57] <pstolowski> zyga: ty, replied
[09:57] <zyga> woot, thanks.
[09:58] <mup> PR snapd#7392 closed: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7392>
[10:08] <zyga> is there anything we could retry that would help us?
[10:08] <zyga> snap install from the store perhaps
[10:08] <zyga> any ideas?
[10:09] <zyga> though that retries internally so perhaps no
[10:09] <zyga> pstolowski: I cannot immediately reproduce the error with leaking loopback device
[10:09] <zyga> I was wondering if being base is somehow more special
[10:10] <zyga> but then the bug report did include telegram-desktop
[10:10] <zyga> it may also be a more recent-ish environment (a rolling distro)
[10:10] <zyga> I'll run my test on 16.04 and look at finishing some of reviews instead
[10:16] <zyga> pstolowski: ^ quiet in 7397
[10:16] <mup> PR snapd#7397 opened: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
[10:17] <pstolowski> zyga: right, i couldn't repro loopback issue either. perhaps we need to observe our systems more close for some time
[10:17] <pstolowski> zyga: thanks for 7397!
[10:17] <zyga> it means we are missing something though :)
[10:17] <zyga> it's going to be good when we finally understand what it was
[10:21] <zyga> pstolowski: I updated https://github.com/snapcore/snapd/pull/7256
[10:21] <mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
[10:23] <mup> PR snapd#7398 opened: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398>
[10:24] <mup> PR snapd#7399 opened: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399>
[10:26] <zyga> pstolowski: replied on https://github.com/snapcore/snapd/pull/7397#discussion_r320200634
[10:26] <mup> PR #7397: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
[10:31] <mborzecki> pstolowski: zyga: when that happens, aren't those devices listed in nautilus sidebar too?
[10:31] <zyga> mborzecki: I have *never* seen that in my sidebar on TW
[10:32] <zyga> but I did see some wonkiness in unity a while ago while using a 16.04 vm
[10:32] <mborzecki> zyga:  i have, i recall asking someone during last sprint about that :)
[10:33] <zyga> mmmm
[10:33] <zyga> more interesting to see what causes it
[10:35] <mup> PR snapd#7400 opened: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
[10:36] <zyga> mborzecki: speaking of mounting https://github.com/snapcore/snapd/pull/7400
[10:36] <mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
[10:36] <zyga> I'm reviving that MS_SHARED bugfix but this is something I found in that branch
[10:37] <zyga> it's a bit unusual in the sense that it is a fix for something that was hidden by lack of sharing
[10:37] <zyga> but I proposed it ahead of actual sharing
[10:37] <zyga> I explain why in the PR
[10:37] <zyga> I should break for coffee and then really return to reviews or I will never get them done
[10:38]  * Chipaca takes a break
[10:42] <zyga> mborzecki, pstolowski: https://github.com/snapcore/snapd/pull/7397#discussion_r320206281
[10:42] <pstolowski> mborzecki: i think the reporter of that bug mean that when he said gnome file manager
[10:42] <mup> PR #7397: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
[10:43] <mborzecki> pstolowski: nautilus?
[10:43] <pstolowski> mborzecki: on my 18.04 box i only have cli so can't verify; on full-blown 19.04 i couldn't reproduce in my short tests
[10:43] <pstolowski> mborzecki: yes, nautilus
[10:44] <mborzecki> woo, it's called files now :/
[10:44] <zyga> files :)
[10:44] <zyga> nice
[10:44] <mborzecki> and i keep on typing nau.. in the search
[10:44] <zyga> until it becomes folders ;)
[10:44] <zyga> after coffee / reviews I'll change my test to refresh bases while running various apps
[10:44] <zyga> and see what happens then
[10:46] <zyga> pstolowski: trivial quickie https://github.com/snapcore/snapd/pull/7399
[10:46] <mup> PR #7399: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399>
[10:46] <zyga> this is also pretty obvious but I was unsure if there are any side effects
[10:46] <zyga> https://github.com/snapcore/snapd/pull/7396
[10:46] <mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
[10:46] <zyga> though it feels like the original code was just buggy anyway
[10:47] <zyga> mborzecki: is my reasoning correct? https://github.com/snapcore/snapd/pull/7396#discussion_r320208075
[10:47] <mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
[10:48] <zyga> mvo: can you please finish the review of https://github.com/snapcore/snapd/pull/7362
[10:48] <mup> PR #7362: cmd: unify die() across C programs <Created by zyga> <https://github.com/snapcore/snapd/pull/7362>
[11:00]  * zyga breaks
[11:08] <pstolowski> good idea
[11:08]  * pstolowski lunch
[11:39] <pstolowski> pedronis: #7092 seems to be happy
[11:39] <mup> PR #7092: packaging: use snapd type and snapcraft 3.x <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
[11:44]  * Chipaca goes for lunch
[11:48] <mvo> 6705 needs a second review now
[11:49] <mvo> zyga: will do after lunch
[11:54] <mborzecki> zyga: updated #7387
[11:54] <mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
[11:57] <pedronis> Chipaca: comment on #7398
[11:57] <mup> PR #7398: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398>
[11:57] <pedronis> *commented
[12:13] <mborzecki> zyga: duh, mounts do not look nice when there's more snaps installed https://paste.ubuntu.com/p/BHvpFx7P3X/
[12:23] <mborzecki> zyga: ok, updated #7302 too
[12:23] <mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
[12:36] <mup> PR pc-amd64-gadget#19 closed: UC20 spike changes <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/19>
[12:37] <cachio> mvo, pedronis  I need to skip the standup, perhaps arriving late but not sure, forgot I had a meeting in the school
[12:37] <zyga> mborzecki: seeing double :)
[12:37] <zyga> mborzecki: I have an idea about that
[12:37] <zyga> mborzecki: but in the evening after round of reviews
[12:37] <zyga> mborzecki: for tomorrow, ok?
[12:58] <ogra> jdstrand, i have a problem ... trying to use a DHT11 sensor (temp/humidity) and output to an OLED display on a Pi3 with https://github.com/adafruit/Adafruit_Python_DHT ... i end up with https://paste.ubuntu.com/p/Z7PDBTCjkb/ ... could we add these paths to "hardware-observe" ?
[12:59] <Chipaca> pedronis: interesting comments
[13:17] <rbasak> I'm using Docker to run snapcraft inside Travis. Is there anything I need to do to switch to using core18?
[13:17] <rbasak> Currently I'm doing: docker run -v $(pwd):$(pwd) -t snapcore/snapcraft sh -c "apt-get update -qq && apt-get install -qq git && cd $(pwd) && snapcraft"
[13:17] <rbasak> I'm wondering if I need to use a different Docker image based on Bionic?
[13:17] <Chipaca> rbasak: use core18 for what?
[13:17] <Chipaca> does snapcraft in docker not use multipass?
[13:18]  * Chipaca doesn't know
[13:18] <Chipaca> i imagine not, in which case yeah you'd need a bionic image
[13:19] <rbasak> Chipaca: to base my snap on core18 I mean. Ie. "base: core18" in snapcraft.yaml AIUI. Yes - that's what I was thinking.
[13:19] <rbasak> Is there a published snapcraft-that-uses-bionic image?
[13:26] <Chipaca> rbasak: I don't know. Maybe sergiusens does?
[13:51] <zyga> cmatsuoka: can this land? https://github.com/snapcore/snapd/pull/7266
[13:51] <mup> PR #7266:  recovery: update run mode variable name <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7266>
[13:52] <cmatsuoka> zyga: on the uc20 branch, yes
[13:52] <cmatsuoka> zyga: thanks
[14:00] <zyga> cachio: hey, I pushed into the XDG branch of yours
[14:00] <zyga> cachio: I also opened something small for your consideration: https://github.com/snapcore/snapd/pull/7396
[14:00] <mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
[14:00] <cachio> zyga, nice, thanks
[14:00] <jdstrand> ogra: it is likely fine. they are binary files. add to the list for the next round. thanks!
[14:01] <jdstrand> added*
[14:01] <zyga> jdstrand: hello :)
[14:01] <jdstrand> zyga: hi :)
[14:01] <ogra> jdstrand, thanks !
[14:02] <ijohnson> rbasak: there is not, you will need to roll your own docker image
[14:03] <ijohnson> rbasak: if you're building on travis, it is probably much easier for you to just build with lxd and call snapcraft from your job definition directly, travis supports running snapcraft as a snap and lxd as a snp
[14:06] <rbasak> ijohnson: OK, thanks.
[14:06] <rbasak> ijohnson: do you know of any examples?
[14:06] <ijohnson> rbasak, sure one minute
[14:07] <ijohnson> rbasak: take a look at one of the snapcrafters snaps at https://github.com/snapcrafters/sdlpop/blob/master/.travis.yml
[14:08] <rbasak> ijohnson: that's great. Thank you!
[14:13] <cachio> zyga, #7256 needs a +1
[14:13] <mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
[14:13] <cachio> pstolowski, could you please take a quick look to #7256
[14:15] <pstolowski> cachio: yes
[14:15] <cachio> pstolowski, tx
[14:16] <pstolowski> cachio: looks good but as i said in earlier comment i think we should wait for it to fail again an see if #7336 shows anything interesting
[14:16] <mup> PR #7336: tests: add debug section to interfaces-contacts-service <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7336>
[14:22] <roadmr> jdstrand: hi are you around? I have a question :) {"docker": {"allow-auto-connection": "true"} <- this implies allow-installation, right? so a snap with this in the plugs section should automatically pass review, not be held with human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (docker, docker)
[14:23] <cachio> pstolowski, ok, I'll try to force the error
[14:24] <cachio> pstolowski, otherwise it will take too much time
[14:24] <pstolowski> cachio: force how?
[14:24] <cachio> pstolowski, retrying execution
[14:24] <cachio> until it fails
[14:24] <pstolowski> cachio: ok
[14:25] <cachio> and praying
[14:25] <cachio> heheehe
[14:25] <pstolowski> heh
[14:25] <jdstrand> roadmr: it does not imply allow-installation
[14:26] <roadmr> jdstrand: ah, ok. That makes sense
[14:26] <pedronis> it does for snapd
[14:26] <jdstrand> roadmr: in snapd, auto-connection, connection and installation are all separate from each other. the review-tools only look at auto-connection and installation for when to manual review
[14:26] <roadmr> jdstrand: did this change? did it imply installation?
[14:26] <pedronis> it doesn't respect the conventions though
[14:27] <jdstrand> roadmr: nothing has changed for months
[14:27] <roadmr> jdstrand: (context, someone is saying that a snap for which they have the above used to pass automated review but then started failing
[14:27] <roadmr> )
[14:27] <jdstrand> roadmr: right, months ago it was discovered that we weren't prompting for manual review for the docker interface when we should have. it changed then
[14:28] <jdstrand> roadmr: there were a handful of snaps that were affected. they must not have uploaded anything in a while
[14:28] <roadmr> jdstrand: like, 2 months ago? we narrowed the transition down to "2019-06-17 13:55 - 2 months, 2 weeks ago"
[14:28] <roadmr> jdstrand: perfect, that explains it :) do you mind if I give them allow-installation? this is a snap in a brand store and they'd been using docker previously
[14:29] <jdstrand> roadmr: 693121ef4ad15a0642967d5f7af69e52c1b8969d. Feb 15
[14:29] <roadmr> oh that's more than 2 months ago :)
[14:31] <jdstrand> pedronis: I guess it makes sense that allow-auto-connection implies installation as a practical matter, but that is not how we initially designed the feature. do you recall when that changed?
[14:32] <nessita> roadmr, the date would be relevant for our bump of review tools though, not necessarily when the review tools changed
[14:32] <nessita> (hi all!)
[14:32] <pedronis> jdstrand: it's always been like this
[14:33] <jdstrand> pedronis: oh, you mean because if it has nothing to say about installation, it is allowed
[14:33] <pedronis> yes
[14:33] <roadmr> nessita: indeed, but the gap is still puzzling - we certainly updated the tools between February and June, so it's weird this only started happening in June if the change was in the tools since Feb
[14:33] <nessita> roadmr, right
[14:34] <nessita> roadmr, have you, by any chance, downloaded the two revisions to compare if they changed anything in their manifest?
[14:35] <roadmr> nessita: nope
[14:35] <jdstrand> pedronis: right. that is different than auto-connection affecting installation if something does have something to say about it, which is what I meant
[14:35] <jdstrand> anyhoo, yes
[14:38] <jdstrand> roadmr: can you paste me their snap.yaml?
[14:38] <roadmr> jdstrand: sure, incoming
[14:39] <roadmr> jdstrand: https://pastebin.canonical.com/p/WJyNTTKQ8X/
[14:39] <ackk> hi, testing with the confined maas snap and snapd 2.41, I'm getting https://paste.ubuntu.com/p/cJxN7B4KpP/ all of a sudden, what could it be related to?
[14:40] <zyga> ackk: woah
[14:40] <zyga> ackk: is it /root?
[14:40] <ackk> zyga, what is?
[14:40] <zyga> I think it might be confused by root :)
[14:40] <zyga> ackk: there's a check that $HOME is not something crazy
[14:40] <zyga> ackk: but it may not capture /root
[14:40] <ackk> zyga, yeah "maas --help" works but "sudo maas --help" doesn't
[14:40] <zyga> Chipaca: ^ is that us?
[14:41] <zyga> Chipaca: if so that's a regression
[14:41]  * jdstrand notes that when to manual review is a different question than when to apply at install time
[14:41] <zyga> mvo: ^
[14:41] <ackk> zyga, oddly, I had just run "sudo maas init" a little before, and that must have worked
[14:41] <zyga> huh
[14:41] <zyga> that's more mysterious
[14:41] <ackk> lemme try a reproducer
[14:41] <mvo> zyga: thanks, in a meeting
[14:41] <zyga> ack
[14:41] <Chipaca> ackk: what distro?
[14:41] <zyga> ackk: thank you
[14:41] <ackk> Chipaca, bionic
[14:41] <mvo> zyga: but thanks for the heads up, please keep me updated about your finidings
[14:42] <Chipaca> sudo's path should have /snap/bin on it
[14:42] <mvo> might be the new systemd generator?
[14:42] <Chipaca> (some distros have it in bash but not in sudo which is weird)
[14:42] <Chipaca> ugh
[14:42] <zyga> https://github.com/snapcore/snapd/blob/fa465e97df3b159f18c77786cdc540d2cdcd29d5/cmd/snap-confine/user-support.c#L44
[14:42] <mvo> which went in with 2.41 but only in the debs
[14:42] <ackk> Chipaca, I'm pretty sure cloud images don't
[14:42] <Chipaca> ackk: don't what?
[14:42] <ackk> Chipaca, I'm in a lxd
[14:43] <ackk> don't have /snap/bin in path
[14:43] <ackk> at least, not for root
[14:43] <ackk> oh actually it seems they do now
[14:43] <Chipaca> ackk: in 'sudo visudo', you should see /snap/bin in 'secure_path'
[14:43] <zyga> I just shut down my desktop
[14:43] <zyga> but https://github.com/snapcore/snapd/commit/634a17c85718f15babe9fbe3cd85a36225bcfdd3
[14:44] <zyga> it could be a good attempt to add a /root home directory there to see what happenns (in spread test)
[14:44] <Chipaca> ackk: maybe you installed snapd, and didn't re-login?
[14:44] <ackk> Chipaca, it's there
[14:44] <ackk> Chipaca, nope, that's not a fresh container
[14:44] <ackk> I'm testing now in a fresh one, see if I can reproduce
[14:46] <jdstrand> roadmr: because of that ^ the tools look at the slots side for both *for slots that specifiy an installation constraint in the base decl*. the base decl convention for docker here is that a slot implementation may provide a so-called superprivileged interface but another impl of the same slot might not. again, change was intentional
[14:47] <roadmr> jdstrand: ah ok - got it
[14:47] <ackk> Chipaca, I did relogin just now fwiw, no difference
[14:48] <jdstrand> roadmr: oh, and the review-tools error is correct for that snap.yaml
[14:48] <jdstrand> s/correct/expected/
[14:49] <roadmr> awesome :) yes, just looks like behavior changed here and we didn't update the PD - I'll add allow-installation for them
[14:49] <roadmr> (behavior changed expectedly as you explained)
[14:49] <jdstrand> cool, thanks
[14:49] <roadmr> thank you for explaining :)
[14:50] <roadmr> I mean, it was pretty clear we needed to add allow-installation, the message says as much and fwiw I usually add both anyway - just wanted to understand why this changed
[15:06] <jdstrand> roadmr: speaking of the review-tools, can you pull 20190829-1435UTC? not urgent. only meaningful change for the store is sr_lint.py: improve error message with invalid Icon paths
[15:06] <roadmr> jdstrand: sure thing!
[15:07] <jdstrand> thanks :)
[15:19] <ppd1990> jdstrand: Hi, I'd be glad if you could weigh in on #7366 in the near future :) Am still in the office for a few hours with a little spare time for possible changes
[15:19] <mup> PR #7366: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <https://github.com/snapcore/snapd/pull/7366>
[15:20]  * cachio lunch
[15:21] <doko> mvo: snapcraft autopkg test regressions in eoan
[15:23] <jdstrand> ppd1990: yes, it is on my list for today. note there is some history that I need to dig up for why it is the way it is
[15:29] <mvo> doko: hey, thanks for the heads up - sergiusens will take care of it I'm sure!
[15:32] <doko> mvo: well, it would be nice if the snappy team would notice these regressions on their own  by default ...
[15:34] <mvo> doko: right, I hear you and we try to be responsive. snapcraft is a different team though,
[15:40] <popey_> sergiusens: ^ see comments from doko
[15:43] <mvo> second review for 6705 would be great btw
[15:59] <mvo> ackk, zyga, Chipaca still in meetings - is there a tl;dr on this potential regression?
[16:00] <zyga> mvo: no, I took a break but I just stopped and writing a quick regression test
[16:00] <ackk> mvo, I don't have a clean reproducer but it seems related to the fact that I was ending up running snapcraft --destructive-mode with the snap mounted from the prime dir, so maybe that ends up confusing snapd?
[16:00] <mvo> ta
[16:01] <mvo> thanks! please keep me updated, if it turns out to be a regression I want to know as soon as possible
[16:01] <zyga> mvo: understood, sorry for lagging
[16:03] <mvo> zyga: no worries! it was not meant as being pushy :)
[16:04] <rbasak> What's the production status of core18? https://forum.snapcraft.io/t/ubuntu-core-18/5169 suggests it's experimental?
[16:04] <popey_> rbasak: that's a very old post
[16:04] <rbasak> It's the second hit for "snap core18" on Google.
[16:05] <rbasak> The first hit goes to the store page which doesn't answer my question.
[16:05] <pedronis> mvo: I will look at #6705 in my morning, slightly surprised by Chipaca's comments on it
[16:05] <rbasak> I can't find any announcement that says that core18 is production now?
[16:05] <mup> PR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>
[16:06] <Chipaca> I will go for a run now and stop surprising people
[16:06] <mvo> Chipaca: enjoy!
[16:06] <zyga> Chipaca: +1
[16:07] <mvo> pedronis: I will fix the things that john mentioned, its a good point
[16:07] <mvo> (good points)
[16:07] <zyga> ackk: hey
[16:07] <zyga> still around?
[16:08] <zyga> ackk: what does "sudo env" say in that machine where it happened?
[16:08] <zyga> ackk: feel free to paste in private if sensitive
[16:09] <cwayne> rbasak: https://ubuntu.com/blog/ubuntu-core-18-released-for-secure-reliable-iot-devices
[16:09] <cwayne> top of https://ubuntu.com/core too
[16:09] <rbasak> cwayne: great. Thanks!
[16:09] <cwayne> np :)
[16:10] <mup> PR snapd#7399 closed: tests: verify retry-tool not retrying missing commands <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7399>
[16:11] <ackk> zyga, https://paste.ubuntu.com/p/gDNq93zrPC/
[16:11] <zyga> ackk: can you walk me through a case
[16:12] <zyga> ackk: this is inside a container, correct?
[16:12] <ackk> zyga, yes
[16:12] <zyga> ackk: how do you access the host of the container, via ssh?
[16:12] <zyga> ackk: when you access the container, how do you "jump into" it, via lxc shell?
[16:13] <ackk> zyga, via ssh, but I have my home bind-mounted in the container, so I ssh with the same user
[16:13] <zyga> ackk: bind mounted from the host of the container?
[16:13] <zyga> ackk: so you ssh into (guest) from (host) or from a different machine?
[16:13] <ackk> zyga, https://paste.ubuntu.com/p/XNq6w2sVGQ/
[16:14] <ackk> zyga, no, ssh from my laptop to the lxd on it
[16:14] <zyga> ackk: so (3rd computer) -> (guest) directly, via ssh?
[16:16] <ackk> zyga, why 3rd computer? the containres are on my laptop as well
[16:16] <zyga> ah, I understand now
[16:17] <zyga> so you ssh from the laptop, which is the host, directly into the container
[16:17] <ackk> zyga, correct
[16:17] <zyga> ackk: and inside the container, so in (guest), the user ack exists because it was added manually?
[16:18] <ackk> zyga, yes
[16:18] <zyga> ackk: and when you run sudo maas, snap-confine complains and quits
[16:19] <zyga> ackk: this is on 2.41 from the archive?
[16:19] <ackk> zyga, 2.41 snapd snap
[16:19] <ackk> from beta
[16:19] <zyga> aha, the snapd snap
[16:19] <zyga> ok, thank you
[16:19] <zyga> let me check stuff
[16:19] <zyga> can you run one simple test
[16:19] <zyga> snap install snapd-hacker-toolbelt
[16:19] <zyga> and see if that works
[16:19] <zyga> it's just a busybox snap
[16:20] <ackk> zyga, so, also the issue doesn't happen right away as I mentioned before. I have the snap installed via snap try, but was then running a sync target which ended up calling snapcraft again
[16:20] <ackk> zyga, sure
[16:20] <ackk> zyga, just run it?
[16:20] <zyga> yeah
[16:20] <zyga> so maas is in try mode?
[16:21] <ackk> zyga, yes
[16:21] <zyga> what is a sync target?
[16:21] <ackk> zyga, (that snap works fwiw)
[16:22] <zyga> ackk: can you try to unsquashfs snapd-hacker-toolbelt, edit it anyway you like (it's a static binary),
[16:22] <zyga> ackk: install it in try mode
[16:22] <ackk> zyga, so we have a makefile target that updates the prime/ dir based on the tree, so you can change code and have it copied. but that because of a recent change ended up calling "snapcraft --destructive-mode prime" again
[16:22] <zyga> and see if you can reproduce the issue somehow
[16:22] <ackk> zyga, it seems after that the snap had the issue
[16:23] <zyga> so there are two aspects
[16:23] <zyga> the message we saw indicates that we failed
[16:23] <zyga> the details only change the error message printed
[16:23] <zyga> so even if /root was handled in that logic, it would at most affect the failure message
[16:24] <zyga> the reason we saw that particular message is that we got EROFS
[16:24] <zyga> so we attempted to create a directory but got an EROFS error from the system
[16:24] <zyga> we can strace that to see what exactly failed
[16:24] <zyga> ackk: actually
[16:24] <zyga> ackk: if you can still reproduce it
[16:24] <zyga> please set SNAP_CONFINE_DEBUG=yes
[16:24] <zyga> and run that command again
[16:24] <ackk> zyga, where in the calling shell?
[16:24] <zyga> that will tell us all the details without the need of strace
[16:24] <zyga> ackk: after sudo
[16:25] <zyga> sudo SNAP_CONFINE_DEBUG=yes maas --help
[16:25] <ackk> oh ok, I don't have it right now but will try to reproduce tomorrow
[16:25] <zyga> ackk: so whatever really happened, it seems something has switched your home directory, or /root to read only mode
[16:55] <mup> PR snapcraft#2695 closed: spread tests: install package marker into ament index <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2695>
[17:47] <jdstrand> roadmr: sorry, can you pull 20190903-1746UTC? not terribly urgent, just an update to an override for core20
[17:48] <jdstrand> xnox: fyi ^
[18:13] <roadmr> jdstrand: sure, her it goes
[19:31] <jdstrand> roadmr: thanks!
[20:05] <sergiusens> doko: mvo I did an upload last week and it was all green
[20:08] <mup> PR snapcraft#2697 opened: Neon extension <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2697>
[20:18] <mup> PR snapd#7401 opened: tests: add unstable stage for travis execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
[22:10] <diddledan> yootoobe: https://youtu.be/cWlYe0CE2iU
[22:15] <mup> PR snapd#7402 opened: daemon, client, cmd/snap: include architecture in 'snap version' <Created by chipaca> <https://github.com/snapcore/snapd/pull/7402>