[06:10] <mborzecki> morning
[06:26] <mborzecki> mvo: hey
[06:30] <mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/10334 ? i've split it out from #10330 to reduce the noise there
[06:31] <mvo> good morning mborzecki 
[06:31] <mvo> mborzecki: sure, looking
[06:32] <mvo> mborzecki: and thanks for this, I'm sure that was hard work :/
[06:33] <mborzecki> mvo: the upside is that it's using valid keys now, although it's my key ;) but it should be easy to update developer-id and re-sign the assertions if such need arises
[06:34] <mvo> mborzecki: using the test keys was not an option?
[06:35] <mborzecki> mvo: i needed to obtain a serial, so i tried using fakedevicesvc, but that only worked until i tried a remodel, since the device got a serial assertion it would try to validate the model with the store, but fake keys were not there
[06:35] <mborzecki> mvo: otoh with valid keys it just worked
[06:35] <mvo> mborzecki: aha, of course
[06:37] <mborzecki> mvo: also as discussed with pedronis the end goal is to use the staging store at some point
[06:37] <mvo> mborzecki: +1
[06:40] <mardy> 'morning all
[06:42] <mborzecki> mardy: hey
[07:08] <pstolowski> morning
[07:24] <mborzecki> pstolowski: hey
[07:34] <mborzecki> https://github.com/snapcore/snapd/pull/10335 <-- a trivial pr for anyone vaguely familiar with rpms
[07:34] <mborzecki> mardy: maybe you can take a look? ^^
[08:14] <mborzecki> mvo: i've opened https://github.com/bboozzoo/snapd-amazon-linux/pull/5 i'll verify it once the github job is finished and will ping you when the repo update is ready
[08:45] <mborzecki> hmm new firefox 89 looks nice
[08:47] <pedronis> mborzecki: pstolowski: hi,  https://github.com/snapcore/snapd/pull/10282 probably doesn't need me to be first to re-review now
[08:47] <mborzecki> pedronis: i'll take a look 
[08:47] <pstolowski> pedronis: ok
[08:48] <mborzecki> pedronis: i've split out just the model/json bits to separate PR https://github.com/snapcore/snapd/pull/10334
[08:48] <mborzecki> and the tests are happy now
[08:48] <jamesh> pedronis: I've updated https://github.com/snapcore/snapd/pull/9292 to account for your apiError changes
[08:49] <pedronis> jamesh: I saw that, thanks, I pushed one more of my PR in the series, https://github.com/snapcore/snapd/pull/10332
[08:49] <pedronis> as well
[08:51] <pedronis> mborzecki: I saw that as well, thx 
[08:51] <pstolowski> i'm seeing github errors this morning (500, unicorn)
[08:54] <mborzecki> github is acting funny
[08:54] <pedronis> pstolowski: not seen errors yet, but is not very responsive for me here
[08:54] <mborzecki> aaand 500 yay
[08:54] <pedronis> status says degraded perfomance
[08:54] <jamesh> https://www.githubstatus.com/incidents/76nv9h8pmkv4?utm_ts=1622622986
[08:57] <mborzecki> well no performance is the same as degraded to some extent
[08:59] <mborzecki> actions don't seem to be working either
[09:01] <pedronis> even git push doesn't seem too happy
[09:09] <jamesh> given that the second item in that incident log notes perf issues with API requests, everything else probably stems from that.
[09:27] <zyga-mbp> github seems to be broken
[09:27] <zyga-mbp> oh well
[09:28] <jamesh> seems to be better than it was.
[09:28] <jamesh> (I could actually complete a review)
[09:29] <jamesh> although I some how ended up with one comment repeated 3 times
[09:36] <pedronis> jamesh: I answered to your comments btw, thanks for the review
[09:38] <pstolowski> yeah worked for me a few minutes ago
[09:52] <mborzecki> hmm so something got actually messed up on github, a pr is both merged and open
[09:52] <mborzecki> https://github.com/bboozzoo/snapd-amazon-linux/pull/5 still open, but latest commit https://github.com/bboozzoo/snapd-amazon-linux/commit/7c5a722725f3e86841acdb795cc62d4fc06b1be5 says it's merged
[09:54] <mborzecki> and gh actions didn't fire, ehh
[10:37] <mvo> jamesh: hey, I see build failures in trusty in the userd code during the sbuild/deb building. https://paste.ubuntu.com/p/Cqpg3dqcnj/ has hte error. annoyingly I can reproduce it when running the tests/unit/go tests under spread. any idea what might be triggering this?
[10:47] <jamesh> mvo: the first looks like it is coming from the systemd.Version() command.  It doesn't look like that test tries to mock systemctl, so maybe that binary is not present on the test system?
[10:48] <mvo> jamesh: aha, that sounds like it
[10:48] <jamesh> given everything else that test mocks, it would probably be worth mocking the systemctl calls too
[10:49] <jamesh> the second failure looks like a version of the first, but from the other side of a D-Bus method call
[10:49] <mvo> jamesh: yeah, that's excatly it
[10:49] <mvo> jamesh: the second one of course is harder, maybe we just skip the test on systems without systemd?
[10:50] <mvo> jamesh: it will still run in spread just won't run during package builds
[10:50] <jamesh> mvo: the unit tests are all in-process.  The same MockSystemctl() approach would likely work there too
[10:50] <mvo> jamesh: ok, let me try this
[10:51] <jamesh> mvo: I can put together a PR tomorrow morning if you like.  It's getting a bit late here, and I'd like to get out for some exercise before it gets too cold
[10:52] <mvo> jamesh: no worries, if it's trivial I do something otherwise please look at it in your morning. enjoy the excercises
[11:10] <mborzecki> pstolowski: do you remember any special task kinds that were basically a nop?
[11:11] <mborzecki> i vaguely recall we had something like this for the tests
[11:11] <mvo> mborzecki: iirc cleanup was made a nop
[11:11] <pstolowski> mborzecki: like error-trigger?
[11:11] <mborzecki> pstolowski: no more like a task that does nothing, a dummy, i need to hang snapsup on something ;)
[11:14] <mborzecki> ah, i got something
[11:52] <mardy> mborzecki: I don't understand what you mean in https://github.com/snapcore/snapd/pull/10282#discussion_r643782353 with "snap.app.service"
[12:26] <mborzecki> mardy: the Services fields carries expanded names, snap.foo.service, the new field is name ExplicitServices so I would expect it to have the expanded service names as well
[12:54] <mardy> mborzecki: I see. I replied with more questions :-)
[12:58] <mborzecki> haha, naming is hard
=== axino is now known as ux
=== ux is now known as axino
[13:46] <GunnarHj> pedronis: Back to the question I asked yesterday:
[13:46] <GunnarHj> https://irclogs.ubuntu.com/2021/06/01/%23snappy.html#t13:45
[13:46] <GunnarHj> Would be great if we could bring it to a conclusion.
[13:49] <pedronis> GunnarHj: if you need changes to apparmor proper you need to involve the security team, if you think our base template or the desktop interface need apparmor additions additions please list somewhere what new access you think they need
[13:55] <GunnarHj> pedronis: Ok.. Let's leave the more complex ibus thing for now then. As regards fcitx5 I think we need new abstractions similar to the already present fcitx and fcitx-strict. It's <https://launchpad.net/bugs/1928360>.
[13:57] <GunnarHj> pedronis: The process of fcitx5 is /usr/bin/fcitx5, not /usr/bin/fcitx.
[14:12] <mardy> mborzecki: this commit https://github.com/snapcore/snapd/pull/10282/commits/460e5f9be90edc31c8de770876d5c64dd05456a5 breaks the spread tests (https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/27231/signedlogcontent/87), do you have any idea why?
[14:22] <mardy> ah, I see, snap.AppInfo.String() does some special handling when the app name is the same as the snap name. I'll revert the commit then
[14:28] <mborzecki> aah
[14:28] <mborzecki> well that sucks
[14:36] <pedronis> GunnarHj: I don't see anything in our current interfaces about the fcitx process itself, the only thing I see is dbus access in some interfaces. I don't see references to abstractions for example
[14:38] <mborzecki> mvo: i've updated the readme in https://github.com/snapcore/snapd/pull/10334
[14:39] <mvo> mborzecki: \o/ you rock
[14:39] <GunnarHj> pedronis: In that case, why does fcitx work on snaps while fcitx5 does not?
[14:40] <pedronis> GunnarHj: did the dbus interface/names change as well?
[14:40] <GunnarHj> pedronis: No, AFAICT it's the same.
[14:41] <pedronis> then not sure, needs more investigation
[14:43] <GunnarHj> pedronis: My simple test with the Chromium snap did not result in a single DENIED entry in the log, i.e. Chromium seems to not know about the existence of fcitx5.
[14:47] <ijohnson> GunnarHj: did you get a chance to ask jamesh about the situation ?
[14:48] <GunnarHj> ijohnson: Not yet, but I can do that.
[14:49] <ijohnson> jamesh is probably EOD at this point, but I think he might be able to at least identify what the underlying problem is, he has helped before on a lot of font stuff
[14:50] <GunnarHj> ijohnson: Ok, let me ask him tomorrow then.
[14:53] <ijohnson> pedronis: hey so because everything is terrible, the same bug around 16 exbibytes memory usage on centos 7 is also present on xenial 😭 
[14:54] <ijohnson> so I'm pretty sure we will need the work-around if we want to support uc16 with snap quotas
[14:54] <ijohnson> cc mvo ^
[14:56] <mvo> ijohnson: thank you! if the workaround is a lot of work I think it's fine to not support this on uc16 for now
[14:56] <ijohnson> mvo: it's the same workaround I had before
[14:57] <ijohnson> just expressing that it's not just amazon linux 2 and centos 7 that are broken
[14:58] <mvo> ijohnson: aha, the workaround was small iirc, so yeah, that sounds fine
[15:05] <ijohnson> mvo: yeah I don't think it's a big issue, but it was confusing so we will see
[15:06] <ijohnson> but right now I am still fighting the spread test in https://github.com/snapcore/snapd/pull/10333
[15:06] <mvo> ijohnson: ok
[15:07] <pstolowski> trivial, one character change https://github.com/snapcore/snapd/pull/10339 ;)
[15:45] <mvo> pstolowski: nice catch