[04:36] <zyga> Hi
[05:07] <mborzecki> morning
[05:29] <mup> PR snapd#6884 opened: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[05:29] <zyga> mborzecki: I've opened a draft PR above
[05:29] <zyga> and I'm rushing to the car to take Iza to the new school
[05:30] <zyga> ttyls :)
[05:30] <mborzecki> zyga: ok, i'll take a look
[05:30] <zyga> I'll get rid of other bits from that branch
[05:30] <zyga> namely defer patches
[05:30] <zyga> and various other changes that can be broken out
[05:30] <zyga> the essence of the main thing is there
[05:30] <zyga> I'm not 100% sure about one part though
[05:31] <zyga> https://github.com/snapcore/snapd/pull/6884/files#diff-f54c331654290afe84ce29593d97a871R94
[05:31] <mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[05:31] <zyga> I need to make the test more clear so that the relationship (peer groups) is clearly visible
[05:33] <zyga> mborzecki: the mountinfo-tool program can probably land in tests/lib somewhere
[05:38] <zyga> On my way to the new school now
[05:40] <zyga> mborzecki: darn, I committed the broken version that was going to work on older python
[05:40] <zyga> Well, let’s fix that
[05:42] <mborzecki> btw. totally forgot about the draft PRs, maybe should open one for all of gadget update code
[05:43] <zyga> yeah!
[05:46] <zyga> force pushed
[05:47] <zyga> some weird gnome bug
[05:47] <zyga> with x11 I have no desktop background
[05:47] <zyga> with wayland I do but lots of other things are broken
[05:48] <zyga> some error messages about using freed object in gnome shell
[05:48] <zyga> eh
[06:10] <zyga> Daughter is now at the new school
[06:11] <zyga> Apart from the fact that we cannot leave because someone parked next to our car all is good
[06:53] <zyga> mborzecki: trivial https://github.com/snapcore/snapd/pull/6885
[06:53] <mup> PR #6885: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6885>
[06:54] <mup> PR snapd#6885 opened: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6885>
[07:03] <zyga> hey pedronis
[07:03] <mvo> hey zyga, pedronis and mborzecki
[07:03] <zyga> hey mvo, didn't see  you join earlier
[07:04] <mvo> zyga: no worries, reading PRs and reporting bugs :)
[07:04] <zyga> how are you doing? I have a very eventful day but I'm hoping to make progress
[07:04] <mborzecki> pedronis: mvo: hey
[07:06] <mborzecki> zyga: +1 on the PR, i think we had a note about that somewhere earlier in s-c code
[07:07] <zyga> oh, I'll check
[07:07] <zyga> thanks!
[07:07] <pstolowski> morning
[07:10] <zyga> good morning pawel
[07:13] <zyga> mborzecki: one more similar change: https://github.com/snapcore/snapd/pull/6886  -- I'm shaving the main branch to have other tweaks separate so that they don't cloud the non-trivial review of the main part
[07:13] <mup> PR #6886: cmd/snap-update-ns: use "none" for propagation changes <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6886>
[07:13] <mup> PR snapd#6886 opened: cmd/snap-update-ns: use "none" for propagation changes <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6886>
[07:32] <mvo> zyga: we have this mount propagation bug that we want in 2.39.1, right? I'm looking into doing 2.39.1 soon(ish) and just wanted to check whats missing
[07:38] <zyga> mvo: yes, I'm shaving the branch for that now, there's a draft PR with some cruft still
[07:39] <zyga> mvo: and one test that I mentioned yesterday that fails in the restore phase (fuse mounts, so related)
[07:39] <mvo> ok
[07:39] <zyga> mvo: the essence of the fix is https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07
[07:39] <mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[07:39] <zyga> (though as I said the diff will still shrink slightly)
[07:40] <mvo> zyga: woah, thats big - reading
[07:41] <zyga> mvo: it's not *that* big, mostly verbose diff in test changes
[07:41] <zyga> mvo: the non-test code changes are tiny
[07:41] <mvo> zyga: yeah, lots of test changes
[07:41] <zyga> mvo: the essence of the idea builds from ...
[07:41] <zyga> https://github.com/zyga/mimic-bug/blob/master/bug.sh
[07:42] <zyga> mvo: what we were missing is MS_SHARED so that ns:snap events  propagate to ns:user
[07:42]  * mvo nods
[07:42] <zyga> mvo: interestingly, due to inheritance of sharing flags, bulk of the changes are in snap-confine bootstrap
[07:42] <zyga> mvo: the only other changes are to mimic construction code:
[07:42] <zyga> https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-4480ffd44957efa3395867c929f88014R488
[07:42] <zyga> here
[07:42] <mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[07:42] <zyga> literally one line :)
[07:43] <zyga> mvo: the change makes the stash used during mimic construction private
[07:43] <zyga> because due to the sharing that is now everywhere, events made during mimic construction would clobber it, this essentially makes the mimic behave as  it did before sharing was added on the outer layer
[07:44] <zyga> mvo: on top  of this I wrote a tool like findmnt
[07:44] <zyga> https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-427083700c87c7cd79d1ac50787fab0fR1
[07:44] <mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[07:44] <zyga> it's just a think wrapper around mountinfo
[07:44] <zyga> but has two properties: it shows propagation flags better than findmnt
[07:44] <zyga> and it has good renumbering features so that it works well in tests
[07:44] <zyga> it's also great for interactive use
[07:45] <zyga> using that tool I crafted some new tests
[07:45] <zyga> https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-f54c331654290afe84ce29593d97a871R70
[07:45] <mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[07:46] <zyga> that check how things behave with content initially connected, initially disconnected and finally connected then disconnected and reconnected
[07:46] <zyga> there's a smilar one for layout
[07:46] <zyga> and I will still replicate that for parallel instances
[07:46] <zyga> there's a chance parallel instances are still broken because the failure I observed is exactly in that scenario
[07:47] <zyga> I wrote the test in defer style because it was way faster
[07:47] <mvo> zyga: ok
[07:47] <zyga> but I will remove defer from this patch
[07:47] <zyga> so that it can land  separately
[07:47] <zyga> mvo: one interesting thing is this existing test
[07:47] <zyga> https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-a6e200ddb24754df8611a002020deccdR1
[07:47] <mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[07:47] <zyga> that used to be broken and is now fixed
[07:48] <zyga> it essentially captures the fact that layouts *can* correctly change from revision to revision, now, with this fix
[07:49] <zyga> mvo: it needs careful review
[07:50] <zyga> and anyone doing so needs to readhttps://lwn.net/Articles/159077/ and https://lwn.net/Articles/159092/
[07:53] <mvo> zyga: maybe worth linking to that in the PR description(?)
[07:53] <mvo> zyga: thank you for the link!
[07:53] <zyga> mvo: great idea, I will do so
[07:56] <mvo> ta
[08:01] <mup> PR pc-amd64-gadget#15 opened: add .travis.yml to enable basic smoke testing <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/15>
[08:12] <mup> PR pc-amd64-gadget#16 opened: add .travis.yml to enable basic smoke testing (18) <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/16>
[08:13] <mup> PR pc-amd64-gadget#17 opened: add .travis.yml to enable basic smoke testing (20) <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/17>
[08:17]  * zyga is back home
[08:29] <mup> PR snapd#6885 closed: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6885>
[08:29] <Chipaca> pedronis: https://gopenpgp.org/ !
[08:33] <pedronis> Chipaca: bookmarked
[08:34] <pedronis> Chipaca: does my answer in the download topic makes sense?
[08:37] <popey_> zyga: is there a bug open for content snaps not being connected sometimes, causing apps to fail?
[08:37] <popey_> zyga: I suspect this kde calc bug is a snapd bug https://bugs.kde.org/show_bug.cgi?id=407234
[08:37] <zyga> popey_: perhaps many
[08:37] <popey_> zyga: as it can't find libqtcore which is in the kde frameworks snap
[08:37] <zyga> yeah
[08:37] <zyga> this is all coming together in https://github.com/snapcore/snapd/pull/6884
[08:37] <zyga> it will be in 2.39.1
[08:37] <mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[08:38] <zyga> just shaving the yak so that it can land
[08:38] <zyga> it fixes a bug where connect/disconnect would be broken for desktop apps
[08:38] <popey_> thanks
[08:39] <zyga> popey_: that was one tricky bug
[08:39] <zyga> popey_: sorry for taking so long to nail it
[08:39] <popey_> I can only imagine!
[08:39] <popey_> np, glad it's on the radar
[08:39] <zyga> popey_: reading the test here https://github.com/snapcore/snapd/pull/6884/files#diff-f54c331654290afe84ce29593d97a871R50 should show you what is ensured to work correctly now
[08:39] <mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
[08:39] <zyga> the key is that this test runs both as root and as non-root user
[08:40] <zyga> that's where the bug has been mostly lurking
[08:40] <zyga> root users are OK
[08:40] <zyga> ironically all our tests run as root by default
[08:40] <popey_> hah!
[08:40] <pedronis> ironically wouldn't be the word I use
[08:41] <popey_> There are many adjectives that could be used here. But we're a family friendly channel ;)
[08:41] <pedronis> I always thought it was just problems waiting to happen
[08:41] <mvo> mborzecki: silly question - do we use the ":role" yaml property in any of our gadgets? just looking at ubuntu-image
[08:41] <pedronis> though is convenient
[08:41] <zyga> pedronis: I agree
[08:41] <zyga> pedronis: when I was coding this test I ran it locally as user and coded most of the test to use sudo
[08:41] <mborzecki> mvo: we should be, type: mbr is supposed to be legacy, we ought to have role: mbr there instead
[08:42] <zyga> pedronis: I think I would not stumble onto that part of the problem otherwise
[08:42] <Chipaca> pedronis: yes indeed
[08:42] <mvo> mborzecki: aha, I see - I have not seen role: system-boot/system-data in the wild I think(?)
[08:42] <mvo> mborzecki: we probably need system-recovery here in the future :)
[08:42] <mborzecki> mvo: neither did i
[08:42] <mborzecki> mvo: we can add a new role
[08:42] <mvo> mborzecki: maybe a case of YAGNI? anyway
[08:42] <mborzecki> mvo: system-recovery fwiw
[08:42]  * mvo adds a note to the trello
[08:43] <mborzecki> mvo: probably better to have a new role in case there's actually someone using system-{boot,data}
[08:43] <mborzecki> mvo: oh, and system-data may be used implicitly when a rootfs paritition is added automatically
[08:43] <mvo> mborzecki: yeah, given that its already docuemtned and used in the wild I think you are right
[08:43] <mvo> mborzecki: yeah, I need to look at this and make it not-automatic but maybe not for v0
[08:44]  * mvo adds it to trello
[08:45] <mborzecki> mvo: i should be albe to dump the whole gadget update branch as a draft work-in-progress pr, it includes the tool for building images
[08:47] <mvo> sergiusens silly question - running snapcraft in travis now blocks with "Support for 'LXD' needs to be set up. Would you like to do that [y/N]" - do you have an example for a .travis.yml with snapcraft3/base: core18 that just builds the snap ? (or maybe popey knows?)
[08:48] <popey_> Oh, maybe I do. I'll see if I can find one
[08:48] <mvo> mborzecki: nice, yeah, I may be able to get away with a hack - marking the system-recovery partition with role: system-data so ubuntu-image will not create writable and will also put the files into the right place on disk
[08:49] <mvo> mborzecki: its a bit of a fugly hack but maybe enough to get me one step further
[08:49] <mvo> popey_: that would be lovely
[09:03] <mup> PR snapcraft#2570 opened: cli: do not prompt when there is no tty available on stdin <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2570>
[09:07] <Chipaca> pedronis: I'll be working on the users as soon as i've deconflicted the cohort refresh one
[09:07] <pedronis> Chipaca: sounds good
[09:09] <albertosottile> pedronis sorry to bother you, I saw that you found some time to address the pending forum tags... could you give a look at our request too? https://forum.snapcraft.io/t/classic-confinement-request-syncplay/11189/5 Thanks
[09:12] <zyga> mvo: https://github.com/snapcore/snapcraft/pull/2570/files#r286389212
[09:12] <mup> PR snapcraft#2570: cli: do not prompt when there is no tty available on stdin <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2570>
[09:16] <mvo> zyga: thank you!
[09:19] <zyga> mvo: socket activation when daemon goes off doesn't work; systemd stops snapd.socket too
[09:19] <zyga> (totally offtopic)
[09:20] <Chipaca> pedronis: in the cohort refresh pr I added an UpdateOptions struct
[09:20] <Chipaca> pedronis: should device ctx be part of that?
[09:20] <zyga> mvo: the test squashfs we mount on snapd startup briefly flashes in unity launcher, I think we are missing the mount option that makes the launcher ignore it
[09:20] <Chipaca> pedronis: or is it being separate (like userID is separate) better?
[09:20] <mvo> zyga: oh? meh, that will need some investigation then
[09:22] <Chipaca> x-nothing-to-see-here
[09:23] <cjwatson> Chipaca: Re your code import question on #launchpad, LP staff can edit existing code imports
[09:24] <Chipaca> cjwatson: hi :) i think i probably broke something, or don't understand how any of it works as the whole ppa vanished now afaict
[09:24] <cjwatson> ... PPA?
[09:24] <cjwatson> you mean import?
[09:24] <Chipaca> there was a ppa and a recipe and an import
[09:24] <Chipaca> the import was failing, the recipe wasn't reciping and the ppa was stale
[09:25] <Chipaca> but the gnu parallel people reply to "where's instructions for ubuntu" with "john lenton has a ppa"
[09:25] <cjwatson> Changing a code import will not delete a PPA under any circumstances
[09:25] <Chipaca> so i thought rather than try to convince gnu people that they're being bottom sombreros, i'd get it working again, but i probably broke something along the way
[09:25] <Chipaca> cjwatson: never underestimate the power of a sleepy chipaca
[09:25] <cjwatson> Right, *you* might :)(
[09:25] <cjwatson> :)
[09:26] <cjwatson> https://code.launchpad.net/~chipaca/parallel/+git/parallel looks promising now though
[09:26] <Chipaca> yep yep
[09:26] <Chipaca> cjwatson: that's a new one i made last night (trying to import the same thing to bzr failed with a credentials error?)
[09:27] <Chipaca> something about the host name not matching the cert
[09:27] <Chipaca> anyway
[09:27] <Chipaca> cjwatson: I'll pick this up again on the weekend, there is no real urgency to it
[09:27] <cjwatson> Chipaca: power tip: if you're quick then you might be able to use https://staging.launchpad.net/~chipaca as a reference for resurrecting deleted config, since staging is only restored from production weekly
[09:27] <Chipaca> cjwatson: I do appreciate you reaching out though :)
[09:27] <cjwatson> Chipaca: but you will need to do that before the weekend as it will vanish early on Saturday
[09:29] <Chipaca> cjwatson: ack. I guess it's material for tonight then :) thanks!
[09:32] <Chipaca> - Run install hook of "fwupd" snap if present (run hook "install": install: cannot create regular file '/usr/share/polkit-1/rules.d/org.freedesktop.fwupd.rules': No such file or directory)
[09:42] <mup> PR snapd#6887 opened: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6887>
[09:42] <zyga> mborzecki: one more bit of yak shave https://github.com/snapcore/snapd/pull/6887
[09:43] <mup> PR #6887: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6887>
[09:49] <mup> Bug #1829558 changed: Unable to install fwupd <Snappy:Invalid> <https://launchpad.net/bugs/1829558>
[09:53] <pedronis> Chipaca: no, it should be kept separate, it might also be that once we pass context.Context everywhere we might need to use it less deeply, but we will see.
[09:54] <Chipaca> ok
[10:16] <mup> PR snapd#6886 closed: cmd/snap-update-ns: use "none" for propagation changes <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6886>
[10:22] <zyga> Thanks!
[10:22] <mup> PR snapd#6888 opened: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
[10:31] <zyga> pstolowski: is snap unset implemented now?
[10:33] <pstolowski> zyga Im just about to propose it in a series of PRs
[10:34] <zyga> great, looking forward to use it :)
[10:34] <zyga> brb for quick coffee
[10:48] <cachio> mvo, hey
[10:49]  * zyga had a great idea
[10:49] <zyga> brb
[10:53] <zyga> re
[10:57] <zyga> we live in interesting times for sure: https://www.bbc.com/news/technology-48363772
[11:06] <Chipaca> sigh
[11:07] <Chipaca> we have a test that waits for a condition in a limited loop, and then checks for the condition on exit
[11:07] <Chipaca> which sounds fine and correct
[11:07] <Chipaca> except those two conditions? not the same one
[11:07] <Chipaca> so guess what :)
[11:17] <popey_> i have a system where core18 won't install. It fails at the mount step. What info do I need to get from it?
[11:24] <mborzecki>  5 files changed, 2256 insertions(+)  <-- guess nobody will the code now :(
[11:24] <mborzecki> at least that 1639 lines are tests
[11:25]  * zyga is happy about this: >
[11:25] <zyga> mountinfo-tool on core18 :) https://www.irccloud.com/pastebin/J8uVY9P4/
[11:27] <mup> PR snapd#6889 opened: tests/main/auto-refresh-retry: fix loop/break condition <Created by chipaca> <https://github.com/snapcore/snapd/pull/6889>
[11:28] <Chipaca> popey_: depends :)
[11:28] <Chipaca> popey_: _how_ does it fail at the mount step?
[11:28] <popey_> https://forum.snapcraft.io/t/core18-fails-to-install-mount/11472
[11:28] <popey_> yes
[11:30] <mup> PR snapd#6890 opened: gadget: mounted filesystem writer & updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6890>
[11:31] <Chipaca> popey_: anything interesting about this system? is it running /var off nfs from a server in antartica, for example?
[11:32] <popey_> nope, it's an hp microserver in my house
[11:32] <popey_> it has a few snaps installed
[11:33] <popey_> huh, I can't even remove snaps either
[11:36] <Chipaca> hmm
[11:36] <Chipaca> popey_: what does dmesg say?
[11:37] <Chipaca> sounds like something nasssty
[11:37] <popey_> nothing out of the ordinary
[11:38] <Chipaca> popey_: what does it say when you try to remove a snap? also a timeout from mount?
[11:38] <popey_> yeah, added to the forum post
[11:38] <popey_> repeatedly
[11:38] <popey_> (every 3 mins)
[11:38] <Chipaca> hmmm
[11:39] <Chipaca> popey_: ^C should abort that cleanly fwiw
[11:39] <Chipaca> zyga: want to have fun? ^
[11:39] <zyga> Chipaca: I always want to have fun
[11:39] <Chipaca> ikr
[11:40] <Chipaca> meanwhile I'll go have lunch instead
[11:40] <zyga> popey_: can you look at dmesg to see any suspicious kernel messages?
[11:41] <popey_> I'm tailing it and see nothing out of the ordinary, just a bunch of the usual apparmor stuff
[11:41] <zyga> popey_: when something survives SIGKILL it is either 1) kernel recycled processes and systemd is confused or 2) the process is in an uninterruptible part of the kernel and cannot be killed
[11:41] <zyga> popey_: run top, any process with "D" state?
[11:41] <popey_> hmm, yes
[11:42] <popey_> might be io blocked
[11:42] <pedronis> Chipaca: did another pass on 6564, thanks for the work there, fear a couple more nitpicks though
[11:42] <Chipaca> pedronis: :'( but also agreed with you
[11:47] <Chipaca> pedronis: fwiw #6816 is defonclicted and green
[11:47]  * Chipaca tries to actually go have lunch
[11:47] <mup> PR #6816: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>
[11:48] <pedronis> Chipaca: yes, next on my list
[11:48] <pedronis> thank you
[11:59] <mvo> hey cachio !
[12:00] <mvo> cachio: thanks for the update on the stable core release!
[12:00] <mvo> cachio: all makes sense now :)
[12:01] <mup> PR snapd#6887 closed: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6887>
[12:02] <cachio> mvo, hey
[12:02] <cachio> mvo, yesterday we were waiting until last hour to do the promotion but finally we couldnt
[12:02] <zyga> mvo: thank you
[12:03] <cachio> mvo, do you prefer to make it after the stand up? or now?
[12:09] <mvo> cachio: either way is fine
[12:09] <mvo> cachio: now is ok
[12:17] <popey_> zyga: Chipaca a reboot """fixed""" it ;)
[12:17] <popey_> sorry for the noise
[12:18] <Chipaca> pedronis: cachio: oops, yes 6889 and 6883 address the same issue
[12:19] <cachio> Chipaca, :)
[12:20] <Chipaca> cachio: what does the 'ip netns delete testns' accomplish?
[12:20] <Chipaca> cachio: wondering whether i should merge yours into mine or viceversa :)
[12:21] <cachio> Chipaca, if you execute twice the same test, the "ip netns add testns" fails
[12:21] <cachio> because it is not deleted during the restore
[12:21] <Chipaca> cachio: ah
[12:21] <cachio> the test was leaving the namespace created
[12:21] <Chipaca> cachio: wrt your fix for the loop thing, i like mine more because it uses a variable for the string (no dupe string), and doesn't print out the failure in a loop
[12:22] <Chipaca> cachio: but yours has more fixes than just that
[12:23] <Chipaca> cachio: i'll close mine
[12:23] <cachio> Chipaca, nice, thanks :)
[12:24] <mup> PR snapd#6889 closed: tests/main/auto-refresh-retry: fix loop/break condition <Simple 😃> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6889>
[12:33] <pedronis> Chipaca: commented on #6816, I think we need to agree on the func signatures/Options
[12:33] <mup> PR #6816: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>
[12:42] <Chipaca> pedronis: the way i split it, UpdateOptions had everything that was about the update, whereas outside were things about how/where the update run (so state, user id, context would be outside of options, but name and flags would be inside)
[12:42] <Chipaca> pedronis: not sure what the rationale would be to split out name and flags
[12:44] <pedronis> Chipaca: because you can craft an options and use it with many names, we don't support it or want but in theory you could pass it in UpdateMany as well
[12:45] <pedronis> Chipaca: about flags, it's already a struct. I don't think the goal is to have functions that take one struct. The goal is to bundle things reasonably
[12:46] <pedronis> Chipaca: anyway my strong opinion at the moment is about name and the order of userID
[12:49] <pedronis> Chipaca: st, name, options, userID, flags  seems a decent signature from where we stand atm
[12:49] <Chipaca> pedronis: and device context?
[12:49] <pedronis> yes
[12:49] <Chipaca> pedronis: at the end?
[12:50] <pedronis> there are different functions taking that
[12:50] <pedronis> yes, at the end
[12:50] <Chipaca> I could just do like I did in install, and multiply the functions
[12:51] <Chipaca> leave the struct for later
[12:51] <pedronis> that is a problem too, multiple styles
[12:51] <Chipaca> but when i did install we said yeah do it via options so i did so i now i need to do over
[12:52] <pedronis> Chipaca: we agree to do options, not exactly how they would look like
[12:52] <mup> Issue core18#129 opened: Multiarch isn't working <Created by xordspar0> <https://github.com/snapcore/core18/issue/129>
[12:52] <zyga> mup still has the typo "issues" (good) vs "issue" (broken)
[12:52] <pedronis> Chipaca: I mean, doing a refactor and a feature in one commit/PR is a risky move
[12:54] <pedronis> Chipaca: anyway, it's probably personal but this snapstate.Update(st, 0, &snapstate.UpdateOptions{Name: "foo", Channel: "stable"}) looks weird to me
[12:54] <pedronis> the 0 position, and the name inside
[12:54] <pedronis> it might also be that I don't feel the name is an option here
[12:55] <pedronis> is the main thing we act on
[12:55] <pedronis> being in the struct means you can also swap it around
[12:56] <pedronis> &snapstate.UpdateOptions{Channel: "stable", Name: "foo"}
[12:56] <pedronis> again not a clear win to be able to do that
[12:56]  * zyga watches spread cycles cycle
[12:57] <pedronis> Chipaca: maybe I'm sounding unreasonable, hope not
[12:58] <Chipaca> pedronis: it seems arbitrary, but that might be on me
[12:59] <pedronis> Chipaca: maybe your reference point it the store methods, SnapInfo / Find
[12:59] <pedronis> not a fan of them, but they are fairly different, in terms of what they take or not
[13:00] <Chipaca> both of these seem to be trying hard not to be SomeOperation{ the stuff it needs }.Do()
[13:00]  * Chipaca hides
[13:00] <Chipaca> maybe go needs named arguments a la python
[13:00]  * Chipaca hides even more
[13:00] <pedronis> Chipaca: maybe it does
[13:01] <mvo> pedronis, Chipaca standup :) ?
[13:01] <Chipaca> ops
[13:01] <Chipaca> yes
[13:01] <pedronis> Chipaca: but I invite to consider the differences between name for Update vs Query in Find
[13:01] <mborzecki> zyga: standup?
[13:01] <pedronis> Chipaca: also notice that at the moment SnapSpec is just Name
[13:01] <zyga> sorry, joining
[13:01] <pedronis> which is funny
[13:02] <pedronis> in its own way
[13:02] <pedronis> Chipaca: so maybe it merits the reverse treatment at some point
[13:44] <mup> Bug #1830051 opened: Fails to recognize UTF-8 locale <Snappy:New> <https://launchpad.net/bugs/1830051>
[13:44] <mup> Bug #1830052 opened: Ellipsis printed in UTF-8 regardless of locale <Snappy:New> <https://launchpad.net/bugs/1830052>
[13:55] <mborzecki> running ediff on hexl views of partition tables, fun :)
[14:07] <cachio> mvo, core 2.39 is in stable now
[14:27] <cachio> mvo, snapd 2.39 also promoted to stable
[14:29] <mvo> cachio: \o/ thank you!
[14:40] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
[14:41] <kenvandine> woot
[14:41] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
[14:55] <cachio> mvo, yaw
[15:00] <zyga> mvo: core20 kickof URL?
[15:00] <pedronis> mvo: are we using the same hangout as yesterday?  or something else
[15:00] <mvo> zyga, pedronis sorry, added a url to the invite now
[15:00] <mvo> silly me
[15:00] <sergiusens> pedronis: not to let the conversation on the forum cold (wrt tracks, content interface, stage-snaps), I am not sure what you are asking. Also, I am not +1 nor -1 the request at all.
[15:01] <mvo> sergiusens: hey, did you see my earlier question about how to run snapcraft 3 in travis ?
[15:02] <sergiusens> mvo: no, sorry, it is a bit involved and it is what I said we would fix with travis in the coming days but I can give you something that would work today
[15:03] <mvo> sergiusens: waiting some days is fine
[15:03] <sergiusens> mvo: by involved, I mean 8 lines instead of 2, something like this works https://github.com/snapcrafters/gimp/blob/use-use-lxd/.travis.yml
[15:04] <sergiusens> although I would put most of the lxd scaffolding in the `install` stanza for travis instead of `script`
[15:08] <mvo> sergiusens: thanks! I'm in a meeting right now but have a look once this is over
[15:09] <mvo> sergiusens: looks very reasonable, thank you!
[15:09] <mvo> sergiusens: out of curiosity, how will it look soon?
[15:17] <sergiusens> mvo: travis has a concept of actions and another one I cannot recall the name for now... regardless of that implementation detail, you will be able to say you want to have an environment that is correct for snapcraft and then just call `snapcraft --use-lxd`
[15:17] <sergiusens> this is one of the work items we have for the Montreal Summit
[15:19] <sergiusens> mvo: if you tell me where you want to build snaps on travis, I am happy to do a PR and as a side effect of that write up some documentation
[15:20] <sergiusens> but right right now, I need to go and pickup my kid from school, I will be able to look into it an hour and a bit from now
[15:28] <mvo> sergiusens: nice,thanks for this update
[15:28] <mvo> sergiusens I think I know all I need to know
[15:33] <mup> PR snapd#6884 closed: WIP LP:#1828354 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6884>
[15:33] <mup> PR snapd#6891 opened: many: make new mount points MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
[15:33] <zyga> replaced one WIP branch with one that's much like the real thing
[15:33] <zyga> mborzecki: hey still around?
[15:34]  * cachio lunch
[15:35] <zyga> mborzecki: in case you are https://github.com/snapcore/snapd/pull/6888
[15:35] <mup> PR #6888: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
[15:52] <cmatsuoka> zyga: script fixed, the problem was the cpio format
[16:13] <pedronis> mvo: pstolowski: this how it works ATM btw just to confirm (that's a snap with a no-op configure): https://pastebin.ubuntu.com/p/YJMd5KDMDZ/
[16:15] <pstolowski> pedronis: ack, good, ty
[16:47] <pedronis> Chipaca: +1 to 6564 with a question
[17:27] <sergiusens> mvo: pedronis is it correct to assume that if I want 2.39 today I need to install core?
[17:27] <sergiusens> it does seem so in practice
[17:33] <jdstrand> roadmr: hi! are we to the point of doing git pulls for the review-tools? if so, can you pull 20190522-1231UTC?
[17:34] <jdstrand> roadmr: I was going to do YYYMMDD but then I realized I sometimes ask you to do a second in the same day, so went out to the minute
[17:39] <pedronis> mvo: cachio: what's the process for the snapd snap, it has a version like 2.39+git48.g1ae2fb7 for stable
[17:39] <pedronis> which is not nice
[17:40] <pedronis> sergiusens: you mean whether it's SRUd? seems not
[17:42] <sergiusens> pedronis: just connecting the dots... if I move snapcraft to core18 and have an assumes on snapd239 it would not be satisfied until snapd is offered as a snap or the deb SRUed
[17:43] <sergiusens> if SRUing is in plans, all is good though, there is no urgency, I am just aligning the order of work
[17:45] <jdstrand> pedronis, ogra: hey, remind me, as the owner of an Ubuntu Core system (ie, *not* the gadget publisher, etc), is it possible for me to adjust the kernel command line? My understanding is 'no'
[17:46] <pedronis> sergiusens: you probably need mvo for the timings
[18:04] <cachio> pedronis, mvo defined that but it is following the same format since long time
[18:05] <cachio> pedronis, I agree on that it is not nice
[18:06] <cachio> pedronis, I think we never discussed a version pattern for snapd snap, we just did it for core18 snap
[18:07] <pedronis> I think for stable at least it should be just 2.39 or 2.39.x etc
[18:07] <pedronis> but sounds we need to talk with mvo
[18:07] <cachio> pedronis, yes
[18:29] <sergiusens> pedronis: I suspect your version setting will do the right thing if you go with an annotated tag instead of a normal git tag
[18:47] <ogra> ARGH !
[18:48] <ogra> did we just have a core update ?
[18:48] <ogra> https://imgur.com/a/QgwRKo5
[18:48]  * ogra knew running his 3D printer on UC16 wasnt a good idea !
[18:49] <ogra> jdstrand, well, you can surely manually edit the cmdline parameters ...
[18:50] <jdstrand> ogra: so, I can update grub on a core device? I'm just thinking through sepculative execution and in particular hyperthreading (nosmt)
[18:51] <jdstrand> ogra: grub in this case since I'm thinking about intel, but more generally it could be armhf/arm64 so uboot/whatever
[18:52] <ogra> jdstrand, there is a grub.cfg file somewhere in /boot/grub that carries the default cmdline
[18:52] <mup> PR snapd#6564 closed: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6564>
[18:52] <ogra> on arm it is usually nside the uboot.env ... which you can edit with the fw_setenv/fw_getenv tools from the shell (only UC16) or from the uboot shell
[18:53] <ogra> (arm not being the rpi :P ... there it is in /boot/uboot/cmdline.txt)
[18:54] <jdstrand> I see. so yes, the owner of the device can edit these things if desired. ok, thanks!
[18:54] <ogra> as long as you have a login or serial access at least
[18:55]  * jdstrand nods
[18:56]  * ogra goes and starts over with the printer ... hoping there wont be an emergency point release today :P
[19:03]  * cachio afk
[19:07] <mup> PR # closed: pc-amd64-gadget#10, pc-amd64-gadget#11, pc-amd64-gadget#14, pc-amd64-gadget#15, pc-amd64-gadget#16, pc-amd64-gadget#17
[19:08] <mup> PR # opened: pc-amd64-gadget#10, pc-amd64-gadget#11, pc-amd64-gadget#14, pc-amd64-gadget#15, pc-amd64-gadget#16, pc-amd64-gadget#17
[19:19] <kyrofa> jdstrand, zyga we can specify autoconnections in the gadget now, right? Do we have docs for that?
[19:22] <mup> PR snapd#6834 closed: daemon: pass the model to the create known user helpers (instead of full Overlord) <Remodel :train:> <Created by pedronis> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6834>
[19:32] <kyrofa> ogra, HAHAHAHAHA
[19:33] <kyrofa> zyga, that "please don't update me, I'm busy" functionality we've talked about should probably also apply to core updates/reboots ^
[19:41] <kyrofa> roadmr, you around? Can you confirm that these docs are up to date and good to go for the snap proxy? https://docs.ubuntu.com/snap-store-proxy/en/
[19:42] <roadmr> kyrofa: I am around but I'm not the best person to confirm that - sparkiegeek, bloodearnest, twom might be better candidates. They're UK timezone so probably asleep now
[19:42] <jdstrand> kyrofa: we can, yes. there should be docs. I don't know otoh which page it is
[19:43] <kyrofa> jdstrand, hmm. Not on the gadget page anyway
[19:43] <roadmr> kyrofa: if you want to use the snap-store-proxy yourself the docs should be reasonably accurate and you can always ask us for help. If it's for sharing with a third party, it'd be best to wait for confirmation from the above mentioned folks 😄
[19:43] <bloodearnest> those docs are current
[19:43] <kyrofa> roadmr, yeah, it's for sharing
[19:43] <kyrofa> bloodearnest, thank you!
[19:44] <roadmr> thanks bloodearnest 🌃
[19:44] <jdstrand> roadmr: hey, did you see my request for a review-tools pull?
[19:44] <jdstrand> kyrofa: perhaps degville knows?
[19:44] <roadmr> jdstrand: I did! oooh fun! let's try this
[19:45] <roadmr> perfect chance to adapt my fire-and-forget script too
[19:45] <mvo> sergiusens sorry for the delay, we should have released the snapd snap today as well (2.39), let me check
[19:46] <jdstrand> roadmr: cool. thanks. no rush, just wanted to make sure you saw it. if it works then I will stop using the bzr branch immediately
[19:47] <mvo> cachio: (just reading backlog) there should be a 2.39 snapd snap and that is what we need to promote and test, it might get superseeded from beta when there is a new commit to 2.39 but thats the one we should promote to candidate/stable (the 2.39) "snapcraft history snapd" has the exact revision, its around 3289. it is slightly different from the way core is getting to beta, happy to talk about this tomorrow before the HO (for the details)
[19:54] <degville> kyrofa / jdstrand: they are the latest (and only) docs that I know of for snap store proxy.
[19:54] <kyrofa> degville, sorry, we had two conversations going at once. The question for you was: have we documented gadget interface auto-connection anywhere?
[20:22] <degville> kyrofa: ah, right, no worries. re: gadget auto-connections, no - I don't think we've added anything to the docs to cover this. I can sync with zyga tomorrow and get back to you.
[20:22]  * zyga is around but a bit too late to jump into new topics
[20:22] <zyga> sorry kyrofa, degville
[20:23] <degville> no problem zyga! it's getting dark :)
[20:23] <mup> PR snapd#6892 opened: tests: reuse the image created initially for nested tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6892>
[20:55] <kyrofa> degville, zyga thank you, that would be helpful for some stuff I'm writing
[21:47]  * zyga gets the last part of the bug
[21:47]  * zyga EODs
[21:47] <zyga> ttyl