[05:08] <mborzecki> morning
[06:11] <zyga> Hello
[06:11] <dot-tobias> good morning (not sure if last one went through)
[06:12] <zyga> I’m not well today. I had fever yesterday and I seem to have some sort of inflammation that is killing my back
[06:13] <zyga> I will work from bed, skip on video calls
[06:14] <zyga> Unfortunately I don’t have my laptop this week so I’ll work from one of the old thinkpad I have at home.
[06:17] <mborzecki> zyga: hey
[06:21] <zyga> Hi
[06:23] <zyga> Fedora 30 is my host today
[06:28] <mup> Bug #1822535 opened: Unable to install apps via snapweb <Snappy:New> <https://launchpad.net/bugs/1822535>
[06:34] <zyga> snapweb?
[06:34] <zyga> darn, no token near bed
[06:36] <zyga> mborzecki: how are you doing?
[06:37] <zyga> mborzecki: can you do a few reviews please
[06:37] <mborzecki> zyga: heh, caught cold, had a runny nose all weekend :/
[06:37] <zyga> mborzecki: I have https://github.com/snapcore/snapd/pull/6643 that is now non-embargoed
[06:37] <mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
[06:37] <zyga> mborzecki: same here, I was rinding the bike at night and ended up sick
[06:37] <mborzecki> zyga: will do, now trying to figure out why google-cloud-sdk breaks the tests
[06:38] <zyga> thanks!
[06:38] <zyga> I need to fetch my google sdk token
[06:38] <zyga> mborzecki: I left my macbook for servicing :/
[06:38] <zyga> perfect timing
[06:39] <mborzecki> zyga: must be something funny, i removed google-cloud-sdk early in spread.yaml and still prepare failed
[06:39] <mborzecki> zyga: saw your tweet, the keyboard right?
[06:39] <zyga> mborzecki: can I be your garden gnome
[06:39] <zyga> mborzecki: what is breaking and how do you think it is related to the sdk?
[06:40] <zyga> mborzecki: yes, the space bar but mostly keys started repeating themselves
[06:40] <zyga> mborzecki: the spacebar got stuck
[06:47]  * zyga logged into lp.net
[06:49] <mup> Bug #1822535 changed: Unable to install apps via snapweb <Snappy:Won't Fix> <https://launchpad.net/bugs/1822535>
[06:56] <zyga> mvo: hello
[06:58] <mvo> hey zyga
[06:59] <zyga> mborzecki: so about those failures
[06:59] <zyga> mborzecki: what do you know?
[06:59] <mborzecki> mvo: morning
[07:01] <mvo> hey mborzecki
[07:01] <mvo> more failures?
[07:02] <mborzecki> zyga: it breaks right after cache_snaps
[07:02] <zyga> mborzecki: I know little about this, can you tell me like you would to a garden gnome
[07:03] <mborzecki> haha garden gnome :P
[07:03] <mvo> haha
[07:03]  * mvo hugs zyga
[07:04] <zyga> haha :)
[07:04] <zyga> I'm sick today, sorry
[07:04] <zyga> I'll work from bed
[07:04] <zyga> riding at night was a bit silly in hindsight
[07:04] <zyga> I had fever all yesterday
[07:04] <mup> PR snapd#6667 opened: tests: enable tests that write /etc/{hostname,timezone} on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6667>
[07:04] <zyga> today I'm better but my back is killing me, I cannot stand up normally
[07:05] <zyga> mvo: ^ reviewed
[07:05] <mvo> zyga: thank you
[07:07] <zyga> mvo: I need some reviews
[07:07] <mborzecki> mvo: you did look into this on friday didn't you?
[07:07] <zyga> https://github.com/snapcore/snapd/pull/6597
[07:07] <zyga> https://github.com/snapcore/snapd/pull/6502
[07:07] <mup> PR #6597: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6597>
[07:07] <mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
[07:07] <zyga> those two are most pressing
[07:07] <zyga> both need a 2nd review
[07:14] <mvo> zyga: looking at 6597 now
[07:14] <mvo> zyga: whish me luck that I don't get distracted
[07:14] <zyga> thank you, any reviews you do will help me a lot
[07:15] <mborzecki> hmm it breaks earlier than i thought
[07:15] <zyga> mborzecki: tell me more
[07:15] <zyga> mborzecki: today I might to classic mount namespace behind a feature flag
[07:15] <zyga> mborzecki: feels like something I want to do
[07:16] <mborzecki> zyga: that'd be great, ping if you want to chat about it
[07:18] <zyga> mborzecki: I will do the simple stuff for now, let's sync closer to standup to know more
[07:18] <mborzecki> ok
[07:19] <zyga> mborzecki: darn, fedora with 2.38 is not usable for snapcraft yet
[07:19] <zyga> mborzecki: 2.39 will be selinux ok?
[07:19] <mborzecki> zyga: try with multipass
[07:19] <mborzecki> you'll probably need setenforce 0 for now too
[07:19] <zyga> mborzecki: I was trying to build core81
[07:20] <zyga> it doesn't work with multipass yet
[07:20] <mborzecki> zyga: even if you force snapcraft to use multipass?
[07:21] <zyga> not sure I know how to
[07:21] <zyga> that's fine, I'll work on this now
[07:21] <mborzecki> zyga: SNAPCRAFT_BUILD_ENVIRONMENT=multipass
[07:21] <zyga> mborzecki: maybe 2.38.1 with fedora fixes should be made?
[07:26] <pstolowski> mornings
[07:28] <mvo> hey pstolowski
[07:29] <zyga> pstolowski: hello :)
[07:33] <mvo> zyga: I reviewed 6597, one of my comments is hidden under something marked as resolved
[07:33] <mvo> zyga: not sure we it wasn't "unresolved" by the comment but oh well
[07:33] <zyga> mvo: can you link to it please?
[07:34] <zyga> I think I see it
[07:34] <zyga> mvo: the answer to both questions: I didn't want to reorder patches, just split the big chunk in half
[07:35] <zyga> I wanted to limit the possibility of breaking what used to work to to
[07:35] <mvo> zyga: ok, lets merge and see what the second part of the PR brings
[07:35] <zyga> mvo:you can see the rest, it's already on github
[07:35] <zyga> though it needs more work now that some of the things here changed the interface a little
[07:35] <mvo> zyga: oh, ok
[07:36]  * mvo nods
[07:36] <zyga> https://github.com/zyga/snapd/commits/feature/user-mount-ns-20.9-split
[07:36] <zyga> e.g. this is the locking function https://github.com/zyga/snapd/commit/6525b925e6c3d299e6ce77a1885932c0ef0f2bef
[07:41] <mborzecki> hmm, idk, looks like when removing snapd package we don't remove state.json for some reason
[07:41] <mborzecki> though postrm has rm -rf /var/lib/snapd
[07:42] <zyga> mborzecki: that's on purge
[07:42] <zyga> mborzecki: perhaps purge vs remove?
[07:43] <mborzecki> zyga: apt log shows we're doing --purge
[07:43] <mborzecki> zyga: fwiw the mount units are stopped and removed
[07:43] <zyga> odd
[07:45] <mborzecki> heh, and out prepare project does: distro_purge_package snapd || true we won't notice if that fails
[07:46] <zyga> fun
[07:50] <zyga> mvo: can we postpone our 1-2-1? I don't have chrome here and I don't believe firefox on fedora even works with google meet
[07:51] <mvo> zyga: sure, no problem
[07:53] <mborzecki> zyga: mvo: https://paste.ubuntu.com/p/Q7f6wtG4mr/ hmm that's project prepare
[07:53] <zyga> looking
[07:54] <zyga> output status 100?
[07:54] <zyga> why is that
[07:54] <mvo> rm: cannot remove '/var/cache/snapd/aux': Is a directory
[07:54] <mvo> fun
[07:54] <mborzecki> heh
[07:54] <mborzecki> yeah
[07:54] <zyga> aha
[07:54] <zyga> aux
[07:54] <mvo> mborzecki: the same bug from last week
[07:54] <zyga> mborzecki: reexec creates aux
[07:54] <zyga> mborzecki: snapd postrm doesn't know about it
[07:54] <zyga> mborzecki: we discussed this
[07:54] <zyga> either reexec must create better postrm
[07:55] <zyga> or postrm must be more rm -rf
[07:55] <mvo> mborzecki: on what system do you see this? fwiw I just saw two PRs failing on 18.04
[07:55] <zyga> either way
[07:55] <mvo> zyga: yeah, postrm is fixed iirc
[07:55] <mborzecki> mvo: 18.04
[07:55] <mvo> zyga: just not in the older version
[07:55] <mvo> mborzecki: looking
[07:56] <mborzecki> ok, so maybe extra rm -rf /var/lib/snapd/ right after purge will be fine
[07:56] <mvo> mborzecki: I am pushing a PR
[07:57] <mborzecki> mvo: ok
[08:00] <mup> PR snapd#6668 opened: tests: add workaround for missing cache reset on older snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6668>
[08:01] <zyga> mborzecki: classic mount namespace is interesting, somewhat more work than I thought
[08:01] <zyga> because we need to use snap-update-ns there as well
[08:01] <zyga> and we need to preserve the mount namespace
[08:01] <zyga> it's progressing well but just wanted to highlight that it's more than I thought initially
[08:03] <mborzecki> mvo: should we push out an update to 2.37 that does rm -rf /var/cache/snapd/* ?
[08:06] <mborzecki> ll
[08:06] <mborzecki> wrong window
[08:15]  * zyga spawned tests and tries to make a coffee
[08:25] <pedronis> zyga: hi, sorry you are sick, weren't there bugs to look into?  instead of starting on classic mountspace
[08:25] <zyga> pedronis: yes, there are bugs to look at
[08:25] <zyga> pedronis: perhaps I should work on those hmmm
[08:26] <zyga> I wasn't thinking much in the morning, just wanted to something
[08:26] <mvo> mborzecki: the rm -rf was added in feb so I think 2.37 already has it
[08:27] <mvo> mborzecki: ha! it does not apparently
[08:27] <mvo> mborzecki: yeah, that is unfortunate
[08:27] <mborzecki> mvo: the version that was installed is 2.37.4
[08:27] <mvo> mborzecki: indeed
[08:27] <dot-tobias> ogra / zyga or someone else who knows: Am I correct in the assumption that only option to set a NTP time server is by overwriting /etc/systemd/timesyncd.conf (like in ogra's ntpcontrol example snap https://github.com/ogra1/ntpcontrol/blob/be16c59cc24d473f22baa89f534f993d553aa6aa/ntpcontrol#L33), and that the timeserver-control interface allows access to this file (https://github.com/snapcore/snapd/blob/71bdfa33d159509164b614e69d59d0b244db3c62
[08:27] <dot-tobias> /interfaces/builtin/timeserver_control.go#L43)? I checked the timedated DBus docs and it doesn't look like there's a method to set a time server: https://www.freedesktop.org/wiki/Software/systemd/timedated/
[08:28] <mvo> mborzecki: :/ that is annoiny, would have been easy to include in .4 if we were aware
[08:42] <mborzecki> #6637 is green, can we land it even before postrm workaround?
[08:42] <mup> PR #6637: interfaces: deal with the snapd snap correctly for apparmor 2.13 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6637>
[08:43] <mborzecki> the spread job ran successfuly 4 days ago for that PR
[08:44] <mvo> is it just me or is running snapd from inside cmd/snapd and ./snapd broken rught now?
[08:44] <mborzecki> mvo: it is, due to snap-seccomp
[08:44] <mvo> mborzecki: yeah, I noticed
[08:44] <mborzecki> mvo: can you build snap-seccomp there too?
[08:45] <mvo> mborzecki: is there a "fix" pending?
[08:45] <mvo> mborzecki: I can symlink it
[08:45] <mup> PR snapd#6637 closed: interfaces: deal with the snapd snap correctly for apparmor 2.13 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6637>
[08:45] <mvo> mborzecki: no super strong opinion, its just my workflow, I can change it if we decide it not worth supporting running out of a git checkout
[08:45] <mborzecki> mvo: i can look into it, but the last time i tried, the solution was rather fugly
[08:45] <mvo> mborzecki: *nod*
[08:46] <mvo> mborzecki: don't worry for now
[08:46] <pedronis> mvo: mborzecki: wouldn't 6602 make it work  (assuming the system one does have version-info) ?
[08:47] <mvo> pedronis: yeah, I was wondering the same
[08:48] <mborzecki> yeah, that's the fugly solution as far as i'm concerned
[08:48] <mvo> mborzecki: heh
[08:48] <mborzecki> mvo: fwiw, 6602 could use a 2nd review :)
[08:49] <mvo> pstolowski: I'm looking at 6660 right now, what can I do to get nested timings? just want to see what the output looks like
[08:49] <mvo> mborzecki: yeah, its on my list which keeps growing instead of shrinking
[08:49] <mvo> mborzecki: but I hope to get to it this morning
[08:52] <zyga> pedronis: I'm adding tests for core -> core18 migration
[08:54] <pstolowski> mvo: at the moment we only collect the new timings in ifacemgr around setting up profiles - see the output in the description of the PR; also we filter out those that are fast
[08:55] <mborzecki> mvo: #6668 failed, looking at the log
[08:55] <mvo> pstolowski: thank you, I will play around a bit with the output
[08:55] <mvo> mborzecki: /o\
[08:55] <mup> PR #6668: tests: add workaround for missing cache reset on older snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6668>
[08:56] <mborzecki> ah, ok, purge may fail if snapd is not installed on some distros
[08:56] <mborzecki> mvo: i can take over this if you don't mind
[08:57] <mborzecki> fwiw, ubuntu is the only distro that comes with snapd preinstalled
[09:00] <mvo> mborzecki: go for it
[09:00] <mborzecki> mvo: ack
[09:00] <mvo> mborzecki: I did not add a purge, did I? I mean, my only change was to rm -rf the aux dir, no?
[09:00] <mvo> mborzecki: so I'm confused how this breaks things - but I will wait for your PR :)
[09:01] <mborzecki> mvo: you dropped || true from purge
[09:01] <mvo> (or your push to it)
[09:01] <mvo> mborzecki: silly me
[09:01] <mvo> mborzecki: well, makes sense to drop it in some way because it masked the earlier error
[09:01] <mvo> mborzecki: but yeah, that explains things :)
[09:01] <mborzecki> that's fine, we expect it to succeed on system where it 'does' things
[09:04] <mborzecki> btw. #6602 pick up wrong path libexecdir path on amazon for some reason
[09:04] <mup> PR #6602: cmd,interfaces: replace local helpers with cmd.InternalToolPath <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6602>
[09:06] <pedronis> mborzecki: doesn't that come dirs?  is the code always been buggy and we didn't notice?
[09:06] <pedronis> *come from dirs
[09:07] <mborzecki> pedronis: yes, that's from dirs, and it should be ok, /etc/os-release should check out as 'fedora'
[09:18] <zyga> pedronis: so, sanity check question
[09:18] <zyga> pedronis: what should happen when a snap changes base
[09:18] <zyga> pedronis: should we force all apps to down
[09:18] <zyga> pedronis: should we discard namespaces?
[09:18] <zyga> pedronis: should we refuse (like in refresh app awareness work)?
[09:21] <pedronis> zyga: when we have implemented app awareness we will have that, no?  so the questio is what we can do quickly to deal with the bug?
[09:21] <zyga> pedronis: yes, we will
[09:21] <mborzecki> mvo: pushed
[09:21] <zyga> pedronis: perhaps we should discard the namespace when bases change
[09:22] <zyga> pedronis: this would at least be less broken
[09:22] <zyga> pedronis: when we have enduring services we should perhaps also discard the namespace
[09:22] <pedronis> zyga: that's my thinking as well
[09:22] <zyga> pedronis: to esure that apps run on top of the base they designated
[09:22] <zyga> *ensure
[09:22] <zyga> pedronis: I will get to it, thanks!
[10:03] <mborzecki> heh that InternalToolPath is tricky
[10:04] <mup> PR snapd#6669 opened: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6669>
[10:05] <mborzecki> #6668 is green
[10:05] <mup> PR #6668: tests: add workaround for missing cache reset on older snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6668>
[10:06] <mborzecki> mvo: can you take a quick look at that last patch I pushed?
[10:12] <mvo> mborzecki: sure, was in a meeting
[10:12] <mvo> mborzecki: but free now
[10:13] <mvo> mborzecki: its *green*
[10:13]  * mvo hugs mborzecki 
[10:13] <mborzecki> yeah
[10:13] <mvo> mborzecki: merged, I did not even look at it
[10:13] <mvo> mborzecki: (ok, the last part of not true ;)
[10:13] <mborzecki> haha fine :)
[10:14] <mup> PR snapd#6668 closed: tests: add workaround for missing cache reset on older snapd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6668>
[10:14] <mvo> mborzecki: thanks for it and your change looks fine
[10:15] <mborzecki> mvo: great!
[10:15] <mborzecki> need to push a little fix for InternalToolPath, libexecdir is a mess to handle
[10:18] <pstolowski> mvo, Chipaca thanks for the review of snap debug timings; i'm happy to tweak the output, perhaps pedronis wants to comment on this?
[10:22] <zyga> mborzecki: hey selinux question
[10:22] <mvo> pstolowski: yeah, if we don't find anything that appeals to everyone we should probably have a HO or something
[10:23] <zyga> mborzecki: how can I relabel a binary done in make hack
[10:23] <zyga> mborzecki: shall I restorecon?
[10:23] <mborzecki> zyga: yes
[10:23] <mborzecki> zyga: try restorecon -V <path>
[10:23] <zyga> is it recursive?
[10:23] <mborzecki> -V should be verbose
[10:23] <mborzecki> -R
[10:24] <mborzecki> or -v was verbose
[10:55] <mup> PR snapd#6664 closed: cmd/snap,client,daemon,store: layout and sanity tweaks for find/search options <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6664>
[10:58] <mup> PR snapd#6597 closed: cmd/snap-update-ns: refactor of profile application (1/N) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6597>
[10:59] <zyga> mvo: thank you, I will prepare the next batch
[11:00] <alan_g> ogra_, obviously you sometimes use vt.handoff. So does this make sense for mir-kiosk? https://github.com/MirServer/mir-kiosk/pull/26
[11:00] <mup> PR MirServer/mir-kiosk#26: Workaround for Mir not starting if the gadget snap sets 'vt.handoff' <Created by AlanGriffiths> <https://github.com/MirServer/mir-kiosk/pull/26>
[11:05] <mvo> zyga: ta
[11:31] <zyga> pedronis: I've implemented the discard, it works ok, I will add some missing unit tests for new C code and send the patches
[11:31] <pedronis> zyga: thx
[11:38] <mborzecki> no suitable *util package to put normalizeYamlValue in
[11:39] <mborzecki> yamlutil?
[11:39] <pedronis> mborzecki: is this because of making gadget a package?
[11:40] <mborzecki> pedronis: yes
[11:43] <mborzecki> pedronis: we have jsonutil, so yamlutil isn't that bad
[11:48] <pedronis> mborzecki: yes, though jsontuil is already border line, it has two functions in it
[11:48] <pedronis> mborzecki: also is the first time I notice netutil,  why was it not called nmutil ?
[11:49] <mborzecki> pedronis: in case there are ways to get the metered status from other sources than nm
[11:51]  * Chipaca wanders off in search of sustenance
[11:53] <pedronis> mborzecki: I see, the problem is that current name make it sounds a companion to the go net package
[11:54] <pedronis> mborzecki: anyway  I would prefer to call the new package  metautil,  with some description about utilities for working with snap metadata
[11:54] <mborzecki> ack, metautil sounds ok
[11:59] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6670
[11:59] <mup> PR #6670: tweak: fix "make hack" on Fedora <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6670>
[11:59] <mup> PR snapd#6670 opened: tweak: fix "make hack" on Fedora <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6670>
[12:00]  * zyga runs one more test before proposing the fixes
[12:09] <mup> PR snapd#6671 opened: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/6671>
[12:10] <mborzecki> off to pick up the kids
[12:11] <zyga> ondra, Saviq: ^ one of the core16 -> core18 issues that affects you
[12:12] <ondra> zyga yeah! o/
[12:12] <zyga> please have a look at the spread test in the PR for details
[12:12] <zyga> d'oh
[12:12] <zyga> that's the stale test before the fix :D
[12:13]  * zyga looks at git status
[12:20] <zyga> mborzecki: ./spread-shellcheck:120: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
[12:36] <pedronis> pstolowski: I left a high-level comment in #6660
[12:36] <mup> PR #6660: [RFC] cmd/debug: integrate new task timings with "snap debug timings" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6660>
[12:39] <pstolowski> pedronis: yes i saw it, thanks!
[13:01]  * zyga goes to the standup
[13:02] <zyga> oh
[13:02] <zyga> standup is in one hour
[13:02] <zyga> :D
[13:02] <zyga> time changed again
[13:03] <mborzecki> hm?
[13:03] <mborzecki> drat
[13:04] <mborzecki> can we move that to 2pm or 3pm like it was before?
[13:04] <zyga> I'd prefer that
[13:04] <zyga> mvo: ^
[13:07] <Chipaca> zyga: mborzecki: person to check with is cachio
[13:08] <Chipaca> and cmatsuoka
[13:08] <mvo> zyga: in a meeting
[13:09] <mvo> mborzecki: what is missing on 6634 ? can this land?
[13:09] <mborzecki> mvo: is it green now?
[13:09] <mvo> zyga, mborzecki, Chipaca my plan was to discuss meeting time in the standup in 51 min :)
[13:09] <mvo> mborzecki: I think it is
[13:09] <mborzecki> ah, perfect, landing it
[13:09] <mvo> mborzecki: \o/
[13:10] <mup> PR snapd#6634 closed: snap: add validation of gadget.yaml <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6634>
[13:27] <ogra> alan_g, well, i'm fine doing a kiosk specific gadget for that ... so dont worry about me
[13:29] <Chipaca> zyga: https://i.imgur.com/98wirsn.jpg
[13:29] <zyga> Chipaca: little blue men
[13:30] <alan_g> ogra, I wasn't so much worrying about you, but wanting your opinion of avoiding the potential problem this way. (Before someone out there hits it and get confused.)
[13:32] <sergiusens> mvo: hey there, can you comment on https://forum.snapcraft.io/t/snap-try-messaging-and-user-experience/10667 ?
[13:33] <mvo> sergiusens: sure, looking
[13:34] <mvo> sergiusens: I like the first part of your comment already :)
[13:35] <mup> PR snapd#6670 closed: tweak: fix "make hack" on Fedora <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6670>
[13:36] <sergiusens> mvo: thanks, will be looking forward to the feedback there :-)
[13:36] <cmatsuoka> zyga, mborzecki: that's 3pm in what timezone?
[13:36] <zyga> cmatsuoka: CET
[13:36] <zyga> I suspect
[13:37] <zyga> whoever created the event "carries" it with the timezone they inhabit
[13:37] <cmatsuoka> so is it UTC+2 i believe?
[13:37] <mvo> pstolowski: thanks for 6660 - <3
[13:38] <cmatsuoka> I'm in UTC-3, so that would be... 10am here, one hour earlier than the regular 11am
[13:39] <cmatsuoka> I would have to change one meeting, but that's feasible
[13:41] <pstolowski> mvo: sure, thanks for the ideas
[13:45] <mborzecki> cmatsuoka: hm isn't there a time change in your location too within the next 2 weeks or so?
[13:46] <cmatsuoka> mborzecki: the last one was a few weeks ago with end of daylight saving time
[13:46] <cmatsuoka> mborzecki: we went from UTC-2 to UTC-3
[13:47] <cmatsuoka> I believe cachio is in UTC-4 now?
[13:48] <cachio> cmatsuoka, I am in UTC-3
[13:48] <cachio> but we don't change time
[13:51] <mborzecki> wow, that sounds like uber mess :P
[13:51] <mborzecki> afaik in 2021 we also stop changing tz
[13:51] <mborzecki> well not tz, just time
[13:53] <cmatsuoka> there are some talks about stopping it here as well
[13:54] <ogra> alan_g, well, the vt_handoff simply hides the text (in case there is no boot splash) by forcing a tty switch to a definitely black tty
[13:54] <ogra> if you havent seen any scrolling text and if mir did start fine, we're good i think
[13:57] <alan_g> ogra, what happens today on RPi3 isn't fine: i.e. Mir doesn't start.
[13:58] <alan_g> I know I've a PR up that will fix it (once the image updates) but it seems fragile.
[13:58] <ogra> alan_g, you mean mir doesnt start even if you remove the vt.handoff ?
[13:58] <ogra> i thought that was your issue
[13:59] <alan_g> ogra, yes, removing it does avoid the problem (that's the PR).
[14:00] <ogra> alan_g, right ... and if the splash still works fine and you dont all of a sudden see scrolling text then we're good
[14:03] <alan_g> So you don think I should be concerned about someone adding vt.handoff (or using Mir on the current RPi image)?
[14:04] <ogra> i was told by vorlon a while ago that vt.handoff= would be deprecated anyway in the main distro so i think its not a bad move to drop it if you pdont see regressions
[14:15] <mup> PR snapd#6672 opened: metautil, snap: extract yaml value normalization to a helper package <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6672>
[14:28] <__chip__> pstolowski: is #1802339 addressed as part of your timing work, or is that for later?
[14:28] <mup> Bug #1802339: Tasks should carry separate timestamps for undo paths <snapd:Confirmed> <https://launchpad.net/bugs/1802339>
[14:29] <pstolowski> __chip__: for later, it is something else and not directly useful for timings. we're interested in durations and we have them for do and undo already
[14:50]  * zyga iterates on tricks that speed up local spread qemu runs
[14:55] <Chipaca> degville: do you have the 'this is work in progress' block for docs somewhere handy?
[15:06] <zyga> Chipaca: question for you sir, could we move /var/lib/snapd/cache to /var/cache/snapd/
[15:11] <Chipaca> zyga: what for?
[15:11] <niemeyer> Hello snappyers
[15:11] <Chipaca> zyga: I think it'd be a bad idea :-)
[15:11] <niemeyer> (see what I did there, Chipaca)
[15:11] <Chipaca> niemeyer: hiya
[15:12] <zyga> Chipaca: why?
[15:12] <Chipaca> niemeyer: I did, I did
[15:12] <Chipaca> niemeyer: I approve
[15:12] <niemeyer> :)
[15:12] <niemeyer> I'm pretty much done with go-yaml v3
[15:12] <niemeyer> Are there any pet peeves that you'd like me to look into before I put it in the wild and need to hold compatibility
[15:12] <niemeyer> ?
[15:12] <Chipaca> niemeyer: lest I refer you to https://www.urbandictionary.com/define.php?term=snapper
[15:12] <Chipaca> niemeyer: whitespace control!
[15:13] <niemeyer> Chipaca: Indentation?  Is in
[15:13] <Chipaca> niemeyer: hmm... will that let me align the values in a map output?
[15:13] <niemeyer> Chipaca: Hmm.. probably not
[15:13] <niemeyer> Chipaca: No it won't
[15:13] <niemeyer> Chipaca: I think that'll need some extra fiddling
[15:14] <Chipaca> niemeyer: can I tell it to use "\t" for indentation, and then have it write to a tabwriter?
[15:14] <Chipaca> zyga: in particular I think it's a bad idea because we depend on being able to hardlink things from var/lib/snapd/cache to var/lib/snapd/snaps
[15:14] <niemeyer> Chipaca: No, as that's the \t makes for invalid yaml.. :(
[15:15] <Chipaca> zyga: if those are on different volumes we lose
[15:15] <zyga> Chipaca: mmm
[15:15] <niemeyer> Chipaca: I think the map alignment would be a nice stock feature
[15:15] <zyga> Chipaca: it's not that the current directory prevents that from happening
[15:15] <niemeyer> Chipaca: And *probably* not hard
[15:15] <niemeyer> Chipaca: There's already good "what column am I in?" control in the encoder
[15:16] <Chipaca> nice
[15:16] <niemeyer> Chipaca: It's also easy to do in a compatible way, so not a blocker for v3
[15:16] <niemeyer> Chipaca: The indentation piece is in
[15:20] <Chipaca> niemeyer: 👍
[15:20]  * zyga lunch
[15:21] <Chipaca> zyga: you misspelled "dinner"
[15:23] <roadmr> use the common galactic spelling: omnomnom
[15:24] <Chipaca> roadmr: is that a pokémon
[15:25] <Chipaca> roadmr: i think it's one of these https://deathbulge.com/comics/343
[15:25] <roadmr> hehe :) maybe!
[15:31] <zyga> Chipaca: it's not dinner if I only had breakfast but ... yeah
[15:39]  * cachio lunch
[15:56] <mup> PR snapd#6663 closed: cmd: make fmt <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6663>
[16:04] <mup> PR snapd#6671 closed: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6671>
[16:28] <zyga> heh
[16:28] <zyga> I have a file that indent is not stable on
[16:28] <zyga> you run indent, you get a change
[16:28] <zyga> you run indent
[16:28] <zyga> you get ... another change
[16:28] <zyga> you run indent
[16:28] <zyga> you are back to 1st change
[16:28] <zyga> and so on
[16:47] <mup> PR snapd#6673 opened: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/6673>
[17:11]  * zyga is preparing some timing data for before/after speed-up patches for spread
[17:11]  * Chipaca EODs
[17:11] <zyga> Chipaca: I still didn't have that lunch
[17:11] <zyga> but I guess it should be dinner now
[17:11]  * Chipaca EODs even harder
[17:11] <Chipaca> zyga: I'm going to go make pascualina
[17:11] <Chipaca> zyga: I could post you some
[17:12] <zyga> I will probably look at what I can find in the kitchen
[17:12] <zyga> Chipaca: about that cache directory, I know it's hard but I think we should rethink that, not urgent
[17:12] <zyga> Chipaca: I have some ideas on how to make things faster and it is simpler with that
[17:12] <Chipaca> zyga: tomorrow
[17:12] <zyga> Chipaca: one last question
[17:12] <Chipaca> because, EOD
[17:12] <Chipaca> zyga: go on
[17:12] <zyga> Chipaca: is there a query I can do to tell me snap name for a hash we keep in the cache?
[17:13] <Chipaca> zyga: snap info
[17:13] <zyga> snap info ... what?
[17:13] <zyga> on the file?
[17:13] <Chipaca> zyga: yes
[17:13] <zyga> ah, super
[17:13] <zyga> thanks!
[17:13] <zyga> enjoy your evening :)
[17:13] <Chipaca> zyga: sudo snap info because 0600
[17:13] <Chipaca> but yes
[17:13] <Chipaca> o/
[18:00] <popey> jdstrand: hi. i have a snap which tries to access /dev/shm/ring-buffer-foo, which fails in strict confinement, and works in devmode. Is patching the upstream source the only option?
[18:06] <jdstrand> popey: hey, snapcraft-preload might also work
[18:06]  * popey tries snapcraft-preload
[18:06] <popey> :)
[18:21] <mup> PR snapcraft#2444 closed: snap: move to core18 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2444>
[18:21] <popey> jdstrand: snapcraft-preload breaks more than it fixes.
[18:22] <popey>     command: snapcraft-preload  desktop-launch $SNAP/b2
[18:22] <popey> wonder if I need desktop-launch before snapcraft-preload
[18:24] <mup> PR snapcraft#2445 closed: Add core18 support to dotnet plugin <Created by ed10vi> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2445>
[18:27] <mup> PR snapcraft#2504 closed: cli: validate plugin schema before provider <Created by cmatsuoka> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2504>
[18:28] <jdstrand> popey: I think the ordering is important, yes. I think one of the two parts mentions which should be first
[18:30] <mup> PR snapcraft#2463 closed: Pass --work-dir param for out-of-tree builds <Created by abitrolly> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2463>
[18:33] <mup> PR snapcraft#1649 closed: add stage/usr/local/lib to cmake library path <Created by diddledan> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1649>
[18:33] <mup> PR snapcraft#1875 closed: Remove deprecated 'snap' recommendation <Created by ted-gould> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1875>
[18:33] <mup> PR snapcraft#2020 closed: elf: set no-default-lib for all elf files if patching <bug> <enhancement> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2020>
[18:36] <mup> PR snapcraft#2493 closed: cli: specify default expiration for export-login <Created by felicianotech> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2493>
[18:41] <popey> jdstrand: yes, changing order fixed the new problem, but doesn't sort the /dev/shm/ring-buffer issue :(
[18:56] <zyga> mvo: https://github.com/snapcore/snapd/pull/6674 :)
[18:56] <mup> PR #6674: tests: use apt via eatmydata <Created by zyga> <https://github.com/snapcore/snapd/pull/6674>
[18:56] <mup> PR snapd#6674 opened: tests: use apt via eatmydata <Created by zyga> <https://github.com/snapcore/snapd/pull/6674>
[19:06] <mup> PR snapcraft#2135 closed: Add gradle support for task other than just 'jar' <Created by bsutton> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2135>
[19:20] <popey> jdstrand: worked around the issue by disabling some features in the upstream code
[19:23] <zyga> jdstrand: ello
[19:23] <mup> PR snapd#6675 opened: cmd/snap-confine: allow using tools from snapd snap <Created by zyga> <https://github.com/snapcore/snapd/pull/6675>
[19:23] <zyga> jdstrand: could you please look quickly at https://github.com/snapcore/snapd/pull/6675
[19:23] <mup> PR #6675: cmd/snap-confine: allow using tools from snapd snap <Created by zyga> <https://github.com/snapcore/snapd/pull/6675>
[19:23] <zyga> jdstrand: it's a two line change to s-c apparmor profile
[19:23] <zyga> jdstrand: I need it for another fix as a prerequisite
[19:26] <jdstrand> zyga: hey, done
[19:26] <zyga> jdstrand: thank you!
[19:27] <zyga> jdstrand: how are you doing btw? :)
[19:27] <jdstrand> zyga: I'm ok. I actually think I'm coming down with something. the daemon user work as progressed a bit. still a bit more to do
[19:28] <jdstrand> zyga: how are you?
[19:29] <zyga> jdstrand: I had a cold and fever yesterday; I kept pushing myself all last week doing biking after dark when it was getting too cold
[19:29] <zyga> jdstrand: I'm better today though I will take this week slowly
[19:30] <jdstrand> zyga: hope you feel all better soon
[19:30] <zyga> jdstrand: I'm progressing on refresh app awareness
[19:30] <jdstrand> nice
[19:30] <zyga> jdstrand: though this week is mostly bugfixes fore core18 and mount related things
[19:30] <zyga> jdstrand: I took a stab at classic confinement mount namespace and I have a better understanding of what is required, I will try to do that after the bugfix weke
[19:30] <zyga> *week
[19:32] <zyga> jdstrand: I'll be EODing soon, ttyl! :)
[19:32] <zyga> thank you for the quick review!
[20:23] <cachio> but we don't change time
[20:42] <popey> jamesh: hello. should gtk2 themes work as expected in https://forum.snapcraft.io/t/improving-theme-support-for-gtk-2-apps/7693
[20:42] <popey> https://usercontent.irccloud-cdn.com/file/Uu05iOmL/Screenshot_20190401_213955-2.png
[20:43] <popey> Mine still looks like a gtk2 app from the past
[20:43] <popey> https://paste.ubuntu.com/p/89rw9srv8H/ is my yaml
[20:44] <popey> gtk-common-themes:gtk-2-themes gtk-common-themes:icon-themes gtk2-common-themes:gtk-2-engines are all connected