=== benfrancis4 is now known as benfrancis | ||
_moep_ | ijohnson[m]: default value of snap refresh (I know its 4/day) | 04:23 |
---|---|---|
mardy | 'morning! | 05:48 |
mborzecki | morning | 05:58 |
_moep_ | morning^^ | 05:59 |
_moep_ | just for understanding: is it possible to get a personal-files interfaces for the snap teams from MS? | 06:00 |
pstolowski | morning | 06:28 |
_moep_ | hi^^ | 06:40 |
mborzecki | pstolowski: hey | 06:43 |
mborzecki | _moep_: from microsoft? microsoft does not issue any assertions in the snap store | 06:44 |
_moep_ | yes | 06:44 |
_moep_ | hmm damn it | 06:45 |
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:46 |
_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:47 |
_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:50 |
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:53 |
_moep_ | mborzecki: how is the way to contect the publisher? | 06:54 |
_moep_ | *contact | 06:54 |
mborzecki | _moep_: `snap info <the-snap>` there should be a `contact` url in the output | 06:55 |
mvo | hey mborzecki | 06:56 |
_moep_ | mborzecki: thx :) | 06:56 |
_moep_ | mborzecki: contact url as in store-url? | 07:06 |
mborzecki | _moep_: which snap is it? | 07:06 |
_moep_ | mborzecki: teams | 07:06 |
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:09 |
_moep_ | mborzecki: ok I check it | 07:11 |
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:36 |
zyga-mbp | hello | 07:37 |
pstolowski | abeato_: that, or snap switch ... | 07:38 |
abeato_ | ah, snap switch, right | 07:39 |
abeato_ | thanks | 07:39 |
* pstolowski physio | 07:48 | |
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:28 |
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:37 |
pstolowski | re | 08:49 |
mardy | zyga-mbp: mmm... I don't see anything weird: https://paste.ubuntu.com/p/SNkJHqbn69/ | 08:49 |
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:50 |
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:51 |
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:55 |
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:56 |
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:57 |
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 | 08:58 |
zyga-mbp | enough to let it remove cleanly | 09:00 |
mardy | zyga-mbp: it didn't help. But umounting did, so finally it's removed | 09:04 |
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:05 |
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:37 |
pedronis | mardy: in meetings, but yes I wanted to do that | 09:38 |
pedronis | mardy: done | 10:03 |
mardy | \o/ thanks pedronis! | 10:10 |
pedronis | thank you | 11:09 |
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:54 |
pedronis | mborzecki: thx, I'll see if I can get to it today or tomorrow morning | 11:56 |
mborzecki | pedronis: cool, thanks! | 11:57 |
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:22 |
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:23 |
ijohnson[m] | yeah a bit odd, but it's updated now so not a big deal | 14:24 |
ogra | perhaps the intern that operates the update crank is on vacation ... | 14:30 |
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:39 |
ijohnson[m] | cachio: the pr is https://github.com/snapcore/snapd/pull/10532 | 14:42 |
* ijohnson[m] hopes cachio didn't quit just because he saw my pr and all my bash mistakes | 14:45 | |
cachio | ijohnson[m], tx | 14:47 |
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:04 |
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:05 |
mardy | ijohnson[m]: don't bother spending toomuch time on it :-) | 15:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:23 |
mardy | ijohnson[m]: and proc/self/mounts says: tmpfs /var/snap/test-snapd-mount-control/common/ciao tmpfs rw,noatime 0 0 | 15:24 |
mardy | it never shows the real source dir for bind mounts | 15:25 |
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:26 |
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:27 |
mardy | it shows /test/wow, but it should be /tmp/test/wow | 15:28 |
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:29 |
ijohnson[m] | hmm | 15:30 |
ijohnson[m] | does umount support providing what or where ? | 15:31 |
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:37 |
mardy | ijohnson[m]: I guess it's a question for pedronis; I'll add it as a comment to the google doc | 15:42 |
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:57 |
ijohnson[m] | \o/ | 15:58 |
mvo | done | 15:58 |
ijohnson[m] | thanks mvo | 16:00 |
* cachio lunch | 16:03 | |
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:38 |
* ijohnson[m] looks for the nearest table to flip over | 16:43 | |
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:44 |
cachio | ijohnson[m], ok, makes sense | 16:46 |
cachio | I'll update the branch in that case | 16:46 |
cachio | thanks | 16:46 |
* ijohnson[m] afk for a while | 18:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!