[05:51] <mborzecki> morning
[06:09] <zyga> hey
[06:09] <zyga> mborzecki: I'm fixing the tumbleweed degraded test now
[06:09] <mborzecki> zyga: hey, it's failing?
[06:09] <zyga> yeah, some vty thing is complaining
[06:09] <zyga> nothing relevant
[06:09] <zyga> https://github.com/snapcore/snapd/pull/8596 needs a review
[06:09] <mup> PR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>
[06:10] <zyga> mborzecki: we have a problem with journal test but let's do one thing at a time
[06:10] <zyga> (and the feature, not just the test)
[06:10] <mborzecki> persistent journal test?
[06:10] <zyga> yes
[06:10] <zyga> it's soaky wet ouside, my dog will not be happy
[06:10] <zyga> mborzecki: look at the test if you are curious
[06:10] <zyga> it has some countermeasures
[06:10] <zyga> but it's a real problem
[06:11] <zyga> and they are insufficinent apparently, it failed again on the unprotected "snap set" code path at the end of the test
[06:16] <zyga> how was the long weekend?
[06:22] <mborzecki> zyga: it was ok, but felt a bit weird since everyone else had friday off and i swapped for monday ;)
[06:24] <mborzecki> zyga: btw. our fonts cache handling is broken i think, we'll need to discuss what to do about that, but the current observation is that we should not trust the font cache generated on the host to be compatible
[06:24] <zyga> mborzecki: happy to
[06:24] <zyga> mborzecki: can we stop sharing caches
[06:24] <zyga> caches belong to /var/snap/$BASE/
[06:24] <zyga> anything else is broken
[06:24] <mborzecki> hm idk, caches belog to whatever fontconfig is used
[06:25] <mborzecki> that can be base, gnome/kde/freedesktop runtime, or the snap
[06:26] <mborzecki> anyways, desktop apps render boxes or straight out segfault on fedora 32 now
[06:26] <zyga> mborzecki: I'm only talking about the fonconfig managed by snapd
[06:31] <mborzecki> zyga: but none of the bases we have ship fontconfig
[06:32] <zyga> but each of them has an associated gnome
[06:32] <mborzecki> zyga: idk, we need to think this though, it was a nice idea for an optimization, but it looks like it's misplaced and doing harm to the cross distro story
[06:32] <zyga> and derived fontconfig
[06:32] <zyga> but yeah
[06:32] <zyga> needs thought
[06:32] <mborzecki> zyga: the snap can ship a different fontconfig, or not not use the gnome runtime at all
[06:34] <zyga> mborzecki: snaps may ship it, we can just disable the shared (base) cache then
[06:34] <zyga> mborzecki: if they do the simple thing, the use the same version that's in the base
[06:34] <zyga> mborzecki: either via bundling or via content to gnome runtime
[06:34] <zyga> mborzecki: base is just the easiest sharing "key"
[06:36] <mborzecki> zyga: kenvandine had an idea for per snap cache, with fc-cache getting called in the configure hook
[06:37] <zyga> mborzecki: that will work but it it would be *very* costly IMO
[06:37] <zyga> and the cache has non-insignificant size
[06:37] <mborzecki> in the meantime, i need to think of a way to disable mounting of cache from hsot on arch and fedora, i'd rather have a longer statup than a segfaulting app
[06:37] <zyga> mborzecki: +1
[06:37] <zyga> mborzecki: that should be easy
[06:37] <zyga> mborzecki: where is the cache again?
[06:38] <mborzecki> zyga: the configure hook runs during install, so it's just the snap install that takes longer
[06:38] <zyga> mborzecki: that is true, I do like that part
[06:38] <zyga> mborzecki: but does it mean all snaps get a virtual hook
[06:38] <mborzecki> zyga: /var/cache/fontconfig and ~/.cache/fontconfig
[06:38] <zyga> mborzecki: or do they need to explicitly cooperate?
[06:39] <mborzecki> zyga: well, if we make it a gnome extention, then snaps need to be rebuilt/cooperate
[06:39] <mborzecki> mvo: hey!
[06:40] <mvo> mborzecki: good morning
[06:40] <zyga> mvo: hey
[06:40] <mvo> zyga: and good morning to you as well!
[06:41] <zyga> https://github.com/snapcore/snapd/pull/8598 <- last of the always-happening failures
[06:41] <mup> PR #8598: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8598>
[06:41] <mvo> zyga: looking
[06:41] <mup> PR snapd#8598 opened: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8598>
[06:41] <zyga> mvo, mborzecki <- please look at https://github.com/snapcore/snapd/pull/8596 as well
[06:42] <mup> PR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>
[06:43] <zyga> ok, I need to take the dog out
[06:43] <zyga> onto the rain :|
[06:43] <zyga> or maybe into the rain actually
[06:46] <mup> PR snapd#8593 closed: image: stub implementation of image.Prepare for darwin <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8593>
[06:46] <mup> PR snapd#8596 closed: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8596>
[07:02] <jamesh> zyga: re. your questions about me trying to use session-tool: https://github.com/snapcore/snapd/pull/5822#discussion_r419901621
[07:02] <mup> PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
[07:02] <pstolowski> morning
[07:11] <zyga> jamesh: good morning
[07:11] <zyga> lookijg
[07:11] <zyga> jamesh: I ported user-mounts to session-tool yesterday
[07:12] <jamesh> zyga: the problems seem to suggest that sessions are not being cleaned up between tests
[07:13] <zyga> jamesh: I think https://github.com/snapcore/snapd/pull/8596 may address this
[07:13] <zyga> which just landed
[07:13] <mup> PR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8596>
[07:13] <zyga> have a look, it's still a bit murky
[07:13] <zyga> I will look at logind changes
[07:13] <zyga> as it definitely behaves differently from one version to another
[07:13] <jamesh> zyga: okay.  I'll give it another try.
[07:14] <zyga> thanks
[07:14] <jamesh> zyga: overall, I like what you've done.
[07:15] <zyga> I think we are not quite fully there yet, with groking various quirks in session handling across time
[07:15] <zyga> but I feel we are much closer to actually running representative tests
[07:15] <zyga> and getting familiar with bugs that may also impact us
[07:16] <jamesh> hopefully we don't end up with anything that depends on systemd environment vs. login shell environment...
[07:16] <zyga> jamesh: login shell environment?
[07:16] <jamesh> zyga: the environment you get in a login shell, which could be different to the one systemd units are launched in
[07:17] <zyga> oh, it is
[07:17] <zyga> but we use runuser -l
[07:17] <zyga> which gives us /etc/pam.d/runuser-l
[07:17] <zyga> but it's a good point that we should understand that difference better and see what's different still
[07:18] <zyga> due to runuser-l we get a real logind session and we get a few more pam modules
[07:18] <jamesh> zyga: it's probably not an issue
[07:19] <jamesh> since a test can add anything extra it needs in the env
[07:19] <zyga> looking just now, I see we don't get this pam module:
[07:19] <zyga> session required        pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
[07:21] <zyga> surreal, we will have first green PR in a week, I think
[07:21] <zyga> or more perhaps
[07:34] <zyga> mvo: thank you
[07:34] <zyga> mvo: I was waiting for that green tick
[07:34] <zyga> but let's see it on ALL THE BRANCHES now :)
[07:34] <mup> PR snapd#8598 closed: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8598>
[07:35] <mvo> zyga: yeah, this looks super nice now
[07:35] <mvo> zyga: I hope we overcame most of the flakiness for now
[07:41] <zyga> checkSnapSuite.TestCheckSnapSystemUsernamesCalls fails if you have daemon users installed
[08:01] <mborzecki> zyga: slightly tweaked #8580
[08:01] <mup> PR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8580>
[08:10] <Chipaca> hehe, booting old work laptop -> log in to old irc channels
[08:11] <Chipaca> morning all
[08:11] <mborzecki> Chipaca: morning sir!
[08:11] <Chipaca> :-)
[08:13] <mborzecki> zyga: the pulseaudio test is still kinda flaky, https://github.com/snapcore/snapd/pull/8537/checks?check_run_id=645190804 recording failed on 19.10 and pulseaudio iface test failed on 18.04
[08:13] <mup> PR #8537: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>
[08:15] <pstolowski> i'm seeing new selinux denials on centos 7 & fedora, not sure if this is my branch onl
[08:15] <pstolowski> *only
[08:16] <pstolowski> howdy Chipaca!
[08:16] <Chipaca> pstolowski: how're things going?
[08:18] <pstolowski> Chipaca: red color has been dominant recently. otherwise - excellent :)
[08:44] <zyga> Chipaca: did you see my poem? :)
[08:44] <zyga> mborzecki: looking
[08:46] <zyga> mborzecki: oh, it's in the old style with manual masking and all the hacks
[08:46] <zyga> mborzecki: let me fix it
[08:46] <Chipaca> zyga: yep :) 'twas good. Also wondering what the background you were talking about looked like.
[08:46] <zyga> Chipaca: a week+ of master red
[08:47] <zyga> Chipaca: and mvo (who can override) being at a sprint
[08:47] <zyga> Chipaca: but it was good, vast majority was fixed already
[08:53] <zyga> mborzecki: testing now
[08:54] <pstolowski> mvo: hi, can the initrd PRs for early config land?
[09:00] <mvo> pstolowski: I think so
[09:01] <mvo> pstolowski: would be nice to get a review from xnox onhttps://github.com/snapcore/core20/pull/46
[09:01] <mup> PR core20#46: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/46>
[09:01] <mvo> pstolowski: but yeah, I think the code is good now
[09:04] <xnox> mvo:  looks good, two minor unresolved conversations on it.
[09:04] <mvo> xnox: aha, thank you, I will check what's missing there
[09:11] <zyga> brb
[09:39] <zyga> re
[09:39] <zyga> man, it's surely raining today
[09:40] <zyga> soaky day
[09:41] <zyga> today is a tea day
[09:46] <pedronis> mvo: hi, the travis test for core20 in your PR failed
[09:46] <mborzecki> pedronis: i've added some reviews for the bulk assertions PR, we should probably land the ones that precede #8564
[09:46] <mup> PR #8564: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8564>
[09:46] <mvo> pedronis: checking
[09:46] <mvo> pedronis: and hello :)
[09:47] <pedronis> mborzecki: yes, trying but red and queueing atm
[09:48] <pedronis> mborzecki: thanks for the reviews btw, same pstolowski
[09:49] <pstolowski> pedronis: yw. i'm keen to review the others but would be nice to land the prereqs, it was kinda confusing to review stacked PRs
[09:50] <pedronis> pstolowski: yes, agree
[09:50] <mvo> pedronis: fun "--2020-05-05 09:45:09--  http://cdimage.ubuntu.com/ubuntu-base/daily/current/focal-base-amd64.tar.gz is 404 now", I guess that needs an update first :)
[09:51] <zyga> oh about focal, mvo do you remember that bug where hardlinking on livecd used 400MB?
[09:51] <zyga> we got a comment that apparently the releaes iso shipped with that bug :|
[09:51] <zyga> so maybe something was off
[09:52] <mvo> zyga: oh, I thought we fixed this
[09:53] <zyga> we did but maybe didn't really
[09:53] <mvo> zyga: https://bugs.launchpad.net/snapd/+bug/1867415
[09:53] <mup> Bug #1867415: Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs <rls-ff-incoming> <snapd:New for mvo> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1867415>
[09:53] <zyga> mvo: comment #6
[09:53] <mvo> zyga: yeah, just saw it
[10:10] <mup> PR core20#51 opened: Makefile: updated now that focal is released <Created by mvo5> <https://github.com/snapcore/core20/pull/51>
[10:11] <mup> PR snapd#8599 opened: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8599>
[10:44] <pedronis> fwiw it seems we hit queuing quite a bit atm with actions, have things queued for many hours now
[10:45] <zyga> pedronis: result of fixing most of master annoyances
[10:45] <zyga> pedronis: I think it will clear in a few hours, let me look at the state
[10:46] <zyga> pedronis: yeah, we have a few branches queued and lots running as well
[11:19] <zyga> mvo: I got a weird email about authorization refresh
[11:19] <zyga> Launchpad failed to refresh the authorization tokens used to upload this snap package to the store:
[11:19] <zyga> (then) Provided email/password is not correct.
[11:19] <zyga> this is from test-snapd-sh-core18
[11:20] <mborzecki> zyga: got one too
[11:39] <mborzecki> zyga: do you remember a change where we checked whwether the system is going down? was that in snap run?
[11:39] <zyga> yes I do, yes it is
[11:39] <zyga> cmd_run.go
[11:39] <zyga> isSystemStopping IIRC
[11:39] <zyga> why?
[11:40] <mborzecki> zyga: if the logs ehere are to be belived: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1873550/comments/3 we may need to check if system is shutting down in snap-failure
[11:40] <mup> Bug #1873550: Snappy daemon reaches 1min30s timeout during shutdown process <focal> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1873550>
[11:40] <zyga> ha
[11:40] <zyga> fun
[11:40] <zyga> why does OnFailure trigger?
[11:41] <mborzecki> zyga: because we hit the stop timeout, there's a wait for api clients to shut down, hits a 25s timeout, then before snapd stopped systemd killed it?
[11:42] <zyga> I see
[11:42] <mborzecki> hm maybe that client shutdown timeout is too long still
[11:42] <mborzecki> 25s is pretty log for any api activity
[11:44] <mborzecki> btw. pretty lame that systemd triggers onfailure when the system is shutting down
[11:45] <mborzecki> still, why is there a 5s break between snapd logging the warning and being killed by systemd
[12:09] <zyga> mborzecki: I think systemd.exec knows
[12:10] <mborzecki> zyga: yeah, noticed a log that there's a stop action queued, so it's not going to enqueue start
[12:10] <mborzecki> anyways, one of the commenters clearly had a newer snapd version
[12:12] <zyga> hmm, nothing useful in the man page
[12:13] <zyga> there's also systemd.kill
[12:13] <zyga> maybe it's one of the defaults
[12:34] <pstolowski> ijohnson: hey, i've checked your hotplug + greedy plugs issue, replied to your bug report, does it make sense?
[12:55] <mup> PR snapcraft#3107 opened: fix yarn version url <Created by fkromer> <https://github.com/snapcore/snapcraft/pull/3107>
[12:58] <mup> PR snapd#8600 opened: tests: run smoke test with different bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8600>
[13:50] <mup> PR snapd#8580 closed: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8580>
[13:58]  * zyga -> errand
[14:13] <mup> PR snapd#8601 opened: Adds missing paths to apparmor, solves lp:1876804 <Created by sklei4> <https://github.com/snapcore/snapd/pull/8601>
[14:18] <zyga> https://github.com/snapcore/snapd/pull/8597 is green :)D
[14:19] <mup> PR #8597: tests: port user-mounts test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8597>
[14:19] <ijohnson> zyga: that's great
[14:20] <zyga> wait, is there a bzr tree of snapd?!?
[14:20] <zyga> https://bugs.launchpad.net/snapd/+bug/1876804/comments/1
[14:20] <mup> Bug #1876804:  apparmor logs filled when ubuntu store launches  <snapd:New> <https://launchpad.net/bugs/1876804>
[14:20] <ijohnson> zyga: I'm still a little confused though, does the old test really have coverage of something we care about on 14.04
[14:20] <ijohnson> zyga: haha yeah I was confused too
[14:20] <zyga> ijohnson: I'm slowly inclined to restore 14.04 support by writing a 14.04 version of session-tool
[14:20] <ijohnson> zyga: I'm fine if you want to do a followup to re-add 14.04
[14:21] <ijohnson> zyga: but I don't feel comfortable just dropping coverage for 14.04 yet as afaik the policy is don't break it if we don't have to
[14:21] <zyga> ijohnson: I think it's preferable to be able to fix issues globally by changing session-tool
[14:21] <ijohnson> zyga: maybe a followup to add  TODO to that test to say "re-add 14.04 when session-tool is updated"
[14:21] <zyga> ijohnson: sure,
[14:22] <ijohnson> ok, I will +1 your PR
[14:22] <zyga> I can bundle that with something else not to clog the pipe today
[14:22] <zyga> with the next -porting-NNN branch
[14:22] <ijohnson> right
[14:32] <pedronis> mvo: #8537, please double check but I think can probably be force landed
[14:32] <mup> PR #8537: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>
[14:34] <pstolowski> zyga: do you know what was the first good systemd version wrt to persistent journal issue?
[14:34]  * zyga is in the car
[14:34] <zyga> pstolowski: yes, one sec
[14:35] <zyga> https://github.com/snapcore/snapd/pull/8594#issuecomment-623584798
[14:35] <zyga> pstolowski: ^
[14:35] <mup> PR #8594: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8594>
[14:38] <pstolowski> zyga: thanks!
[14:38]  * zyga is in the car, delivering supplies 
[14:38] <zyga> and reading about how to send the control bugs to BTS
[14:45] <mborzecki> whcih package ships translations for snapd?
[14:45] <mborzecki> in ubuntu
[14:46] <zyga> mborzecki: ubuntu uses a special langpack system
[14:46] <zyga> apt-cache search langpack
[14:47] <ijohnson> pedronis: 8557 lgtm, thanks for the changes
[14:47] <zyga> mborzecki: translations are extracted from individual packages (in main)
[14:47] <zyga> mborzecki: and bundled into language-specific package
[14:48] <mborzecki> zyga: ok, installing bits for uk_UA
[14:48] <zyga> haraszo
[14:48] <mborzecki> haha
[14:52] <mborzecki> zyga: hmm there does not seem to be a gettext file for snap tho
[14:52] <pedronis> ijohnson: thanks
[14:53] <pedronis> #8557 needs a 2nd review, it's mostly a test refactoring
[14:53] <mup> PR #8557: c/snap-bootstrap: check mount states via initramfsMountStates <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8557>
[14:56] <mborzecki> zyga: heh, so we ignore LC_ALL and just use LC_MESSAGES and LANG (a bug then?)
[15:05] <mborzecki> haa
[15:05] <mborzecki> got it
[15:10] <mup> PR snapd#8602 opened: configcore: only reload journald if systemd is new enough <Created by stolowski> <https://github.com/snapcore/snapd/pull/8602>
[15:29] <mvo> pedronis: in various meeting, will check in a wee bit
[15:32] <zyga> mborzecki: re
[15:32] <zyga> mborzecki: there are two langpacks, base and "graphical"
[15:32] <zyga> not sure which one you checked
[15:32]  * cachio lunch
[15:52] <ijohnson> zyga: shall I merge #8599 since it's green (except unstable system) ?
[15:52] <ijohnson> I just approved it
[15:52] <mup> PR #8599: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8599>
[15:52] <zyga> looking
[15:52] <zyga> ijohnson: oh, there's a small comment
[15:52] <zyga> I guess, yes
[15:52] <zyga> I will follow up in a moment
[15:52] <zyga> thanks!
[15:52]  * ijohnson just wants to see green PR's get merged 
[15:52] <ijohnson> :-)
[15:52] <zyga> yeah, that's the spirit!
[15:53] <zyga> keep master rolling
[15:53] <zyga> wanna press the button or shall I?
[15:53] <pedronis> #8557 is completely green, incredibly, but needs a 2nd review
[15:53] <mup> PR #8557: c/snap-bootstrap: check mount states via initramfsMountStates <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8557>
[15:53] <zyga> pedronis: it feels good, right? :)
[15:53] <ijohnson> I pressed the button
[15:53] <mup> PR snapd#8599 closed: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8599>
[15:54] <zyga> \o/
[15:54] <zyga> I will read it on my way back
[15:54] <zyga> will be heading back home soon
[16:02] <mvo> pedronis: merged, sorry for the delay
[16:03] <mup> PR snapd#8537 closed: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8537>
[16:03] <pedronis> mvo: thanks, I need to deconflict the next one now
[16:06] <mup> PR snapd#8597 closed: tests: port user-mounts test to session-tool <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8597>
[16:14] <mup> PR pc-amd64-gadget#46 opened: gadget.yaml: bump edition <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/46>
[16:44] <ijohnson> mmm should we be installing snap-failure service on systems that only have the core snap ?
[16:49] <ijohnson> mvo: pedronis: should we have the snapd.failure service when only the core snap (or only the snapd distro pkg) is installed (and thus no snapd snap?)
[16:50] <ijohnson> seems like `snap-failure snapd` just no-ops if there is no snapd snap installed, so probably yes it seems
[17:38] <mup> PR snapcraft#3102 closed: build providers: prevent snap refreshing in build environment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3102>
[17:41] <mup> PR snapcraft#3104 closed: packaging: use git-based versioning for python package <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3104>
[18:32] <cachio> cmatsuoka, hey
[18:33] <cachio> cmatsuoka, for testing pi3 with uc20 do we need to use the model signed by canonical?
[18:33] <cachio> or we can use a model signed by me?
[18:33] <cmatsuoka> cachio: afaik you can use your model
[18:34] <cachio> ah, ok
[18:34] <cachio> cmatsuoka, I wanted to make sure it was not going to produce an problem with tpm/secboot
[18:35] <cmatsuoka> we don't have it in arm yet so you'll install unencrypted
[18:35] <cachio> cmatsuoka, good
[18:35] <ijohnson> cachio: we also have dangerous models signed by canonical you can use too
[18:35] <cmatsuoka> well unless you have an arm board with tpm, but we never tested that
[19:00] <cachio> ijohnson, yes
[19:01] <cachio> I'll test new images signed by me first
[19:01] <cachio> then canonical
[19:06] <jdstrand> ijohnson: I think I fixed your serial-port issue (see the bug)
[19:07] <ijohnson> jdstrand: nice! I was going to look at pawel's response and ping you about it but you saw it first, thanks!
[19:07] <ijohnson> jdstrand: re: including the snapd snap type, I'm not sure, on your system you tested it are you using the snapd snap?
[19:08] <jdstrand> ijohnson: it isn't installed, no
[19:08] <ijohnson> I have it installed, let me see if your new declaration works
[19:12] <ijohnson> jdstrand: it seems to have auto-connected anyways
[19:13] <jdstrand> I just installed it and am trying
[19:14] <jdstrand> the slot comes up as snapd:ft232serialuartic
[19:14] <ijohnson> yes I see snapd:unor3cdcacm but it still auto-connected
[19:14] <jdstrand> serial-port             arduino:serial-port      :ft232serialuartic                -
[19:14] <jdstrand> but it connected
[19:15] <jdstrand> ok. as it happens, a different store bug prevents me from specifying 'snapd' for slot-snap-type, so, glad this worked :)
[19:15] <ijohnson> jdstrand: and just to double confirm, when I disconnect the raw-usb interface and just use the serial-port hotplug interface I can upload a sketch / use the serial-port for the arduino and it works perfectly
[19:16] <ijohnson> and then disconnecting the serial-port hotplug interface, it no longer is able to upload
[19:16] <ijohnson> so this looks to "just work" when the declaration is good :-)
[19:16] <ijohnson> thanks jdstrand
[19:17] <jdstrand> ijohnson: np. sorry for the bug and thanks for reporting it. fyi, I commented on the 'snapd' slot-snap-type bits in the bug
[19:17] <ijohnson> no problem, happy to know that it was an easy thing to fix :-)
[19:18] <jdstrand> indeed! :)
[19:18] <ijohnson> I'm sure galgalesh will be happy as well (not sure if they are on IRC or not)
[19:28] <mup> PR snapd#8539 closed: tests: update encrypted partition creation test <UC20> <⛔ Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/8539>
[20:06] <mup> PR core20#52 opened: Makefile: only use focal from now on for core20 <Created by xnox> <https://github.com/snapcore/core20/pull/52>
[20:10] <mup> PR core20#51 closed: Makefile: updated now that focal is released <Created by mvo5> <Closed by xnox> <https://github.com/snapcore/core20/pull/51>
[20:10] <mup> PR core20#52 closed: Makefile: only use focal from now on for core20 <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/52>
[20:11] <mup> PR core20#46 closed: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/46>