/srv/irclogs.ubuntu.com/2021/06/02/#snappy.txt

mborzeckimorning06:10
mborzeckimvo: hey06:26
mborzeckimvo: can you take a look at https://github.com/snapcore/snapd/pull/10334 ? i've split it out from #10330 to reduce the noise there06:30
mvogood morning mborzecki 06:31
mvomborzecki: sure, looking06:31
mvomborzecki: and thanks for this, I'm sure that was hard work :/06:32
mborzeckimvo: 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 arises06:33
mvomborzecki: using the test keys was not an option?06:34
mborzeckimvo: 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 there06:35
mborzeckimvo: otoh with valid keys it just worked06:35
mvomborzecki: aha, of course06:35
mborzeckimvo: also as discussed with pedronis the end goal is to use the staging store at some point06:37
mvomborzecki: +106:37
mardy'morning all06:40
mborzeckimardy: hey06:42
pstolowskimorning07:08
mborzeckipstolowski: hey07:24
mborzeckihttps://github.com/snapcore/snapd/pull/10335 <-- a trivial pr for anyone vaguely familiar with rpms07:34
mborzeckimardy: maybe you can take a look? ^^07:34
mborzeckimvo: 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 ready08:14
mborzeckihmm new firefox 89 looks nice08:45
pedronismborzecki: pstolowski: hi,  https://github.com/snapcore/snapd/pull/10282 probably doesn't need me to be first to re-review now08:47
mborzeckipedronis: i'll take a look 08:47
pstolowskipedronis: ok08:47
mborzeckipedronis: i've split out just the model/json bits to separate PR https://github.com/snapcore/snapd/pull/1033408:48
mborzeckiand the tests are happy now08:48
jameshpedronis: I've updated https://github.com/snapcore/snapd/pull/9292 to account for your apiError changes08:48
pedronisjamesh: I saw that, thanks, I pushed one more of my PR in the series, https://github.com/snapcore/snapd/pull/1033208:49
pedronisas well08:49
pedronismborzecki: I saw that as well, thx 08:51
pstolowskii'm seeing github errors this morning (500, unicorn)08:51
mborzeckigithub is acting funny08:54
pedronispstolowski: not seen errors yet, but is not very responsive for me here08:54
mborzeckiaaand 500 yay08:54
pedronisstatus says degraded perfomance08:54
jameshhttps://www.githubstatus.com/incidents/76nv9h8pmkv4?utm_ts=162262298608:54
mborzeckiwell no performance is the same as degraded to some extent08:57
mborzeckiactions don't seem to be working either08:59
pedroniseven git push doesn't seem too happy09:01
jameshgiven that the second item in that incident log notes perf issues with API requests, everything else probably stems from that.09:09
zyga-mbpgithub seems to be broken09:27
zyga-mbpoh well09:27
jameshseems to be better than it was.09:28
jamesh(I could actually complete a review)09:28
jameshalthough I some how ended up with one comment repeated 3 times09:29
pedronisjamesh: I answered to your comments btw, thanks for the review09:36
pstolowskiyeah worked for me a few minutes ago09:38
mborzeckihmm so something got actually messed up on github, a pr is both merged and open09:52
mborzeckihttps://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 merged09:52
mborzeckiand gh actions didn't fire, ehh09:54
mvojamesh: 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:37
jameshmvo: 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:47
mvojamesh: aha, that sounds like it10:48
jameshgiven everything else that test mocks, it would probably be worth mocking the systemctl calls too10:48
jameshthe second failure looks like a version of the first, but from the other side of a D-Bus method call10:49
mvojamesh: yeah, that's excatly it10:49
mvojamesh: the second one of course is harder, maybe we just skip the test on systems without systemd?10:49
mvojamesh: it will still run in spread just won't run during package builds10:50
jameshmvo: the unit tests are all in-process.  The same MockSystemctl() approach would likely work there too10:50
mvojamesh: ok, let me try this10:50
jameshmvo: 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 cold10:51
mvojamesh: no worries, if it's trivial I do something otherwise please look at it in your morning. enjoy the excercises10:52
mborzeckipstolowski: do you remember any special task kinds that were basically a nop?11:10
mborzeckii vaguely recall we had something like this for the tests11:11
mvomborzecki: iirc cleanup was made a nop11:11
pstolowskimborzecki: like error-trigger?11:11
mborzeckipstolowski: no more like a task that does nothing, a dummy, i need to hang snapsup on something ;)11:11
mborzeckiah, i got something11:14
mardymborzecki: I don't understand what you mean in https://github.com/snapcore/snapd/pull/10282#discussion_r643782353 with "snap.app.service"11:52
mborzeckimardy: 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 well12:26
mardymborzecki: I see. I replied with more questions :-)12:54
mborzeckihaha, naming is hard12:58
=== axino is now known as ux
=== ux is now known as axino
GunnarHjpedronis: Back to the question I asked yesterday:13:46
GunnarHjhttps://irclogs.ubuntu.com/2021/06/01/%23snappy.html#t13:4513:46
GunnarHjWould be great if we could bring it to a conclusion.13:46
pedronisGunnarHj: 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 need13:49
GunnarHjpedronis: 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:55
GunnarHjpedronis: The process of fcitx5 is /usr/bin/fcitx5, not /usr/bin/fcitx.13:57
mardymborzecki: 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:12
mardyah, 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 then14:22
mborzeckiaah14:28
mborzeckiwell that sucks14:28
pedronisGunnarHj: 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 example14:36
mborzeckimvo: i've updated the readme in https://github.com/snapcore/snapd/pull/1033414:38
mvomborzecki: \o/ you rock14:39
GunnarHjpedronis: In that case, why does fcitx work on snaps while fcitx5 does not?14:39
pedronisGunnarHj: did the dbus interface/names change as well?14:40
GunnarHjpedronis: No, AFAICT it's the same.14:40
pedronisthen not sure, needs more investigation14:41
GunnarHjpedronis: 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:43
ijohnsonGunnarHj: did you get a chance to ask jamesh about the situation ?14:47
GunnarHjijohnson: Not yet, but I can do that.14:48
ijohnsonjamesh 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 stuff14:49
GunnarHjijohnson: Ok, let me ask him tomorrow then.14:50
ijohnsonpedronis: hey so because everything is terrible, the same bug around 16 exbibytes memory usage on centos 7 is also present on xenial 😭 14:53
ijohnsonso I'm pretty sure we will need the work-around if we want to support uc16 with snap quotas14:54
ijohnsoncc mvo ^14:54
mvoijohnson: thank you! if the workaround is a lot of work I think it's fine to not support this on uc16 for now14:56
ijohnsonmvo: it's the same workaround I had before14:56
ijohnsonjust expressing that it's not just amazon linux 2 and centos 7 that are broken14:57
mvoijohnson: aha, the workaround was small iirc, so yeah, that sounds fine14:58
ijohnsonmvo: yeah I don't think it's a big issue, but it was confusing so we will see15:05
ijohnsonbut right now I am still fighting the spread test in https://github.com/snapcore/snapd/pull/1033315:06
mvoijohnson: ok15:06
pstolowskitrivial, one character change https://github.com/snapcore/snapd/pull/10339 ;)15:07
mvopstolowski: nice catch15:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!