=== benfrancis4 is now known as benfrancis
[04:23] <_moep_> ijohnson[m]: default value of snap refresh (I know its 4/day)
[05:48] <mardy> 'morning!
[05:58] <mborzecki> morning
[05:59] <_moep_> morning^^
[06:00] <_moep_> just for understanding: is it possible to get a personal-files interfaces for the snap teams from MS?
[06:28] <pstolowski> morning
[06:40] <_moep_> hi^^
[06:43] <mborzecki> pstolowski: hey
[06:44] <mborzecki> _moep_: from microsoft? microsoft does not issue any assertions in the snap store
[06:44] <_moep_> yes
[06:45] <_moep_> hmm damn it
[06:46] <mborzecki> _moep_: the publisher of the teams snap can request personal-files, but if something does not work for you as an end user, you can reach out to the publisher and file bug
[06:47] <_moep_> mborzecki: I have n desktop clients which uses teams via *.deb and now I want to switch to snap without configure all settings again
[06:47] <mborzecki> _moep_: also why personal-files? isn't home enough for teams?
[06:50] <_moep_> mborzecki: no. the *.json files with the config stuff are stored in /snap/teams/5/.config/Microsoft/Microsoft Teams/preauth.json but I can copy the old from /home/user/.config/Microsoft/Mircosoft Teams/
[06:50] <_moep_> *can't
[06:53] <mborzecki> _moep_: i see, i think you should reach out to the team snap publisher and describe how you would see the migration process work
[06:53] <mborzecki> mvo: hey
[06:54] <_moep_> mborzecki: how is the way to contect the publisher?
[06:54] <_moep_> *contact
[06:55] <mborzecki> _moep_: `snap info <the-snap>` there should be a `contact` url in the output
[06:56] <mvo> hey mborzecki 
[06:56] <_moep_> mborzecki: thx :)
[07:06] <_moep_> mborzecki: contact url as in store-url?
[07:06] <mborzecki> _moep_: which snap is it?
[07:06] <_moep_> mborzecki: teams
[07:09] <mborzecki> _moep_: ayy, the store page doesn't really list anything useful, htps://aka.ms/microsoftteams redirects to https://www.microsoft.com/en-US/microsoft-teams/group-chat-software tbh I have no clue, maybe there's something in the teams app help?
[07:11] <_moep_> mborzecki: ok I check it
[07:36] <abeato_> hey, one question I have, what can trigger a switch to a new channel for a snap? would that happen only if you do "snap refresh <snap> --channel=<new_channel>"?
[07:37] <zyga-mbp> hello
[07:38] <pstolowski> abeato_: that, or snap switch ...
[07:39] <abeato_> ah, snap switch, right
[07:39] <abeato_> thanks
[07:48]  * pstolowski physio
[08:28] <mardy> mmm... what did I do wrong to get into this situation? 2021-07-15T10:26:57+02:00 ERROR cannot remove snap file "test-snapd-mount-control", will retry in 3 mins: unlinkat /snap/test-snapd-mount-control/x1/bin: read-only file
[08:37] <zyga-mbp> mardy: can you show /proc/self/mountinfo
[08:37] <zyga-mbp> my guess is that /snap/ is a self-bind mount
[08:37] <zyga-mbp> and it got mounted after /snap/test-snapd-mount-control/x1
[08:37] <zyga-mbp> mardy: so you shadowed (in a way) that mount by the bind mount around /snap
[08:37] <zyga-mbp> mardy: but I'm just guessing for now, with the file we can be sure
[08:49] <pstolowski> re
[08:49] <mardy> zyga-mbp: mmm... I don't see anything weird: https://paste.ubuntu.com/p/SNkJHqbn69/
[08:50] <zyga-mbp> mardy: looking
[08:50] <zyga-mbp> it looks good so far
[08:50] <zyga-mbp> that is weird
[08:50] <zyga-mbp> so whatever is going on, we try to remove x1/bin
[08:50] <zyga-mbp> which is weird
[08:50] <zyga-mbp> we should never do that
[08:51] <zyga-mbp> it looks like snap remove not unmounting the mount point
[08:51] <zyga-mbp> and then ignoring the error
[08:51] <zyga-mbp> and then trying to remove recursively /snap/$SNAP_INSTANCE
[08:51] <zyga-mbp> mardy: do you have the log from snapd?
[08:55] <mardy> zyga-mbp: here it is: https://paste.ubuntu.com/p/Wf8wsMxkmx/
[08:55] <zyga-mbp> interesting
[08:55] <zyga-mbp> what's with x2? the mount table had x1 mounted, no?
[08:56] <zyga-mbp> 158 31 7:10 / /snap/test-snapd-mount-control/x1 ro,nodev,relatime shared:89 - squashfs /dev/loop10 ro
[08:56] <zyga-mbp> does snap list --all show x1, x2 or both?
[08:56] <mardy> zyga-mbp: yes, x1 is the only one mounted
[08:57] <zyga-mbp> but you did have x2 at some point
[08:57] <mardy> test-snapd-mount-control  1.0        x1     -              -                  disabled
[08:57] <zyga-mbp> are you using snap try?
[08:57] <mardy> test-snapd-mount-control             x2     -              -                  disabled,broken
[08:57] <mardy> nope
[08:57] <zyga-mbp> or snap install --local?
[08:57] <mardy> no, I do a "snap pack", then install with --dangerous
[08:57] <zyga-mbp> right
[08:58] <zyga-mbp> whatever happened, the state is a bit messed up
[08:58] <zyga-mbp> you can try to mount x3
[08:58] <zyga-mbp> s/x3/x2/
[08:58] <zyga-mbp> and remove it again
[08:58] <zyga-mbp> but I'm not exactly sure what happened there 
[08:58] <mardy> you mean manually?
[08:58] <zyga-mbp> yeah
[09:00] <zyga-mbp> enough to let it remove cleanly
[09:04] <mardy> zyga-mbp: it didn't help. But umounting did, so finally it's removed
[09:05] <zyga-mbp> ha
[09:05] <zyga-mbp> right
[09:05] <zyga-mbp> unmounted (broken) snaps are easier to remove
[09:05] <zyga-mbp> but check if it left any junk behind
[09:37] <mardy> pedronis: I think that the failures in https://github.com/snapcore/snapd/pull/10438 are not related to my changes, can you please double-check and merge (please do squash the commits)?
[09:38] <pedronis> mardy: in meetings, but yes I wanted to do that
[10:03] <pedronis> mardy: done
[10:10] <mardy> \o/ thanks pedronis!
[11:09] <pedronis> thank you
[11:54] <mborzecki> pedronis: https://github.com/snapcore/snapd/pull/10510 has been updated with the changes we discussed, i think i got all of them, also added that unit test for repeated set-model execution whcih should mimic what happens after reboot
[11:54] <mborzecki> and that test was super annoying to write in a way that i can still change the status of the task
[11:56] <pedronis> mborzecki: thx, I'll see if I can get to it today or tomorrow morning
[11:57] <mborzecki> pedronis: cool, thanks!
[14:22] <ijohnson[m]> degville: how often does https://snapcraft.io/docs/snapd-roadmap get synced back with https://forum.snapcraft.io/t/the-snapd-roadmap/1973 ? I just made some changes to the forum post last night and they haven't appeared yet today in the docs site
[14:23] <ijohnson[m]> oh well now it's updated
[14:23] <degville> ijohnson[m]: it's usually just a few minutes. But I've noticed the same thing over the last few days.
[14:24] <ijohnson[m]> yeah a bit odd, but it's updated now so not a big deal
[14:30] <ogra> perhaps the intern that operates the update crank is on vacation ... 
[14:39] <cachio> ijohnson[m], which is the pr to fix the error in snapd-refresh-vs-services-reboots test?
[14:39] <cachio> is it already merged?
[14:42] <ijohnson[m]> cachio: the pr is https://github.com/snapcore/snapd/pull/10532
[14:45]  * ijohnson[m] hopes cachio didn't quit just because he saw my pr and all my bash mistakes
[14:47] <cachio> ijohnson[m], tx
[15:04] <ijohnson[m]> cachio: also why you couldn't reproduce that error locally is that it only shows up when both variants of the test are run on the same system
[15:04] <ijohnson[m]> if you set workers to 1 for uc18 system in spread.yaml, and then run spread --debug google:ubuntu-core-18-64:tests/core/snapd-refresh-vs-services you can reproduce it 100%
[15:04] <cachio> ah, ok
[15:04] <ijohnson[m]> but it should be fixed by this PR
[15:05] <cachio> yes, already reviewed the PR
[15:05] <cachio> thanks for creating it
[15:05] <ijohnson[m]> np, I'm testing the suggestion from mardy I had to modify it slightly to make shellcheck happy
[15:15] <mardy> ijohnson[m]: don't bother spending toomuch time on it :-)
[15:16] <ijohnson[m]> ah it's just running in the background while I work on other things, it's not costing me any time at the moment
[15:16] <mardy> any idea why "systemctl show" returns What=tmpfs instead of What=/tmp/real/path of a mount unit?
[15:16] <mardy> the mount unit file has the correct What
[15:16] <ijohnson[m]> mardy: I would expect the Where= to be /tmp/real/path no ?
[15:17] <ijohnson[m]> i.e. I do locally `mount -t tmpfs tmpfs /tmp/real/path`
[15:17] <mardy> ijohnson[m]: yes, Where is the correct mount point. But what about the mount source?
[15:17] <ijohnson[m]> the mount source for a tmpfs doesn't really exist, it's just a tmpfs
[15:17] <mardy> ijohnson[m]: I did mount /tmp/real/path /somehere/else
[15:18] <ijohnson[m]> mardy: hmm and /tmp/real/path is a tmpfs ?
[15:18] <ijohnson[m]> I'm confused, were you trying to do a bind mount of /tmp/real/path to /somewhere/else ?
[15:18] <mardy> ijohnson[m]: well, /tmp is a tmpfs
[15:18] <mardy> ijohnson[m]: yes
[15:19] <ijohnson[m]> so you need to specify that it is a bind mount
[15:19] <ijohnson[m]> also just because /tmp is a tmpfs does not mean that /tmp/real/path is a tmpfs
[15:20] <mardy> ijohnson[m]: yes, sorry for not specifying it, but I did it, and it works fine. Now the question is about getting the right information about this mount unit from systemd
[15:21] <ijohnson[m]> mardy: so when you created the bind mount from /tmp/real/path to /somewhere/else, was that specified as a bind mount? if it was then it should show up with the proper what and where in systemctl show
[15:21] <ijohnson[m]> mardy: basically I'm wondering did you create a bind mount or did you accidentally mount _another_ tmpfs at /somewhere/else
[15:21] <ijohnson[m]> mardy: if you have the output of /proc/self/mounts from inside that mount namespace that might be helpful
[15:23] <mardy> ijohnson[m]: so, I created this unit file: https://paste.ubuntu.com/p/fJHZ8GYSXv/
[15:23] <mardy> ijohnson[m]: then I started it
[15:24] <mardy> ijohnson[m]: and proc/self/mounts says: tmpfs /var/snap/test-snapd-mount-control/common/ciao tmpfs rw,noatime 0 0
[15:25] <mardy> it never shows the real source dir for bind mounts
[15:26] <mardy> I have a couple of them on my home, and it only shows the source *device* (i.e., /dev/sdb1) and not the precise dir
[15:26] <ijohnson[m]> ah yeah you're right I see that now
[15:26] <ijohnson[m]> hmm for what it's worth I see it in /proc/self/mountinfo as showing the "real" source
[15:27] <mardy> I *almost* see the real source:
[15:27] <mardy> 1095 31 0:47 /test/wow /var/snap/test-snapd-mount-control/common/ciao rw,noatime shared:63 - tmpfs tmpfs rw
[15:28] <mardy> it shows /test/wow, but it should be /tmp/test/wow
[15:29] <mardy> ijohnson[m]: anyway, the reason why I'm doing this is to implement support for "snapctl umount <what-or-where>":
[15:29] <mardy> if I pass the "where", it works fine; if I pass "what", it does not find anything in this case
[15:29] <mardy> but maybe it's acceptable?
[15:30] <ijohnson[m]> hmm
[15:31] <ijohnson[m]> does umount support providing what or where ? 
[15:37] <mardy> ijohnson[m]: systemd-umount does, at least according to the docs; umount(8) doesn't
[15:37] <mardy> I mean, umount(8) supports only where
[15:37] <ijohnson[m]> are we just trying to have feature parity or is there a reason we can't be like umount and just support where ? 
[15:42] <mardy> ijohnson[m]: I guess it's a question for pedronis; I'll add it as a comment to the google doc
[15:57] <ijohnson[m]> pedronis: mvo #10519 is green (mostly), has 2 +1s and will unbreak the delta-refresh tests which are failing on master, can one of y'all land it please?
[15:57] <mvo> ijohnson[m]: sure
[15:58] <ijohnson[m]> \o/
[15:58] <mvo> done
[16:00] <ijohnson[m]> thanks mvo
[16:03]  * cachio lunch
[16:38] <cachio> ijohnson[m], new error https://github.com/snapcore/snapd/pull/10409/checks?check_run_id=3078069760#step:5:1538
[16:38] <cachio> it is related to cloud init
[16:38] <cachio> have you seen that before?
[16:43]  * ijohnson[m] looks for the nearest table to flip over
[16:44] <ijohnson[m]> cachio: no I haven't seen that, I really question the utility of cloud-init for ubuntu core
[16:44] <ijohnson[m]> cachio: but anyways I think the right thing is to just make all calls to cloud-init be wrapper in retry 
[16:46] <cachio> ijohnson[m], ok, makes sense
[16:46] <cachio> I'll update the branch in that case
[16:46] <cachio> thanks
[18:13]  * ijohnson[m] afk for a while