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