[00:58] <mup> PR snapd#7449 closed: overlord/configstate: special-case "null" in transaction Changes() <Bug> <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7449>
[02:36] <mup> PR snapd#7454 opened: interfaces: extend the fwupd slot to be implicit on classic <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7454>
[03:07] <mup> PR snapd#7455 opened: tests: moving ubuntu-core-transition tests to nightly test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7455>
[04:57] <mborzecki> morning
[05:37] <mborzecki> gorename has gone crazy since 1.13 update
[06:03] <zyga> Morning school run
[06:31] <mborzecki> zyga:  hey
[06:34] <zyga> hey
[06:34] <zyga> in the office now
[06:34] <zyga> mborzecki: can you give me +1 on https://github.com/snapcore/snapd/pull/7446
[06:34] <mup> PR #7446: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <https://github.com/snapcore/snapd/pull/7446>
[06:34] <zyga> this will unblock the whole avalanche of related PRs
[06:35] <mborzecki> zyga: started looking at it yday, but didn't finish bc of kids :/
[06:35] <zyga> mborzecki: it's super easy, just fixes  formatting of the optional fields list to contain "-"
[06:36] <zyga> thanks, I'll look at other stuff as well
[06:36] <mborzecki> while at it i just pushed some updates to #7451
[06:36] <mup> PR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
[06:37] <zyga> let's start with that
[06:38] <zyga> good morning mvo
[06:38] <mborzecki> mvo: hey
[06:39] <mborzecki> zyga: tbh wondering what the distros still shipping py2 will do next year
[06:39] <zyga> mborzecki: macos will remove python from the OS
[06:39] <zyga> it's not used by the os itself, unlike on linux
[06:39] <mborzecki> zyga: and perl i think?
[06:39] <zyga> I think others will port / remove
[06:39] <zyga> mborzecki: likewise
[06:39] <zyga> ruby, perl and python are removed
[06:39] <zyga> as is bash
[06:40] <zyga> you can install them from the upstream distributions but the OS won't have them
[06:40] <mborzecki> zyga: well, they were outdated anyway, so nobody used them?
[06:40] <zyga> mborzecki: I think they were used
[06:40] <zyga> even though outdated
[06:40] <mvo> hey zyga and mborzecki !
[06:40] <zyga> but nowadays it's docker / vms instead
[06:41] <mup> PR snapd#7446 closed: tests/mountinfo-tool: proper formatting of opt_fields <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7446>
[06:41] <mvo> tests more green today?
[06:41] <zyga> mvo: not sure
[06:42] <zyga> mvo: last night I restarted a single test like every 30 minutes
[06:42] <zyga> all day
[06:42] <zyga> so if something is green it's because blood, tears and mud
[06:42] <mborzecki> it'd be nice if we could move google:ubuntu-18.04-64:tests/main/desktop-portal-filechooser to nitghtly too :/
[06:42] <zyga> mvo: store had some issues frequently, there's lots of chatter in snapstore
[06:42] <zyga> mborzecki: I think we need a different suite
[06:43] <zyga> nightly is not a dumpster for stuff that is  broken
[06:43] <zyga> we need a fragile suite
[06:43] <zyga> nightly should never fail
[06:43] <mborzecki> zyga: deskop-dumpster suite
[06:43] <zyga> and if it fails, it's all hands on deck to fix
[06:43] <zyga> otherwise nightly will degrade to that thing that is always red so we don't care
[06:43] <mvo> yeah
[06:43] <mborzecki> zyga: you're saying nightly is where the tests go to die? :)
[06:43] <zyga> and then a real issue explodes on us and in a post-mortem someone will say, "this test failed in nightly for 3 weeks"
[06:45] <mborzecki> 72 prs
[06:45] <zyga> mvo: I commented on a related issue here https://github.com/snapcore/snapd/pull/7453
[06:46] <zyga> mvo: I think we should be very careful with changes like that
[06:46] <mup> PR #7453: tests/classic-custom-device-reg: disable on opensuse-15 and fedora-30 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7453>
[06:48] <zyga> a simple review https://github.com/snapcore/snapd/pull/7448
[06:48] <mup> PR #7448: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>
[06:48] <zyga> +2,505, -2,504
[06:48] <zyga> it's a one line diff really :)
[06:49] <mvo> zyga: yeah, we should blindly disable tests
[06:49] <mvo> zyga: hm, master is red for the last ~5 runs or so - thats not good
[06:49] <zyga> mvo: let's look at why
[06:49]  * zyga checks
[06:50] <zyga> I see LXD failure
[06:50] <zyga> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[06:50] <zyga> grep error: pattern not found, got:
[06:50] <zyga> this is something I reported a few days ago
[06:50] <zyga> that it really happens and indicates we're racing somewhere
[06:50] <zyga> or perhaps that one of the mirrors has a corrupt LXD image?
[06:51] <zyga> who knows but it's real
[06:51] <mvo> zyga: oh, I saw this too in a branch of mine
[06:51] <zyga> I'll save the log and look at past tests
[06:51] <mvo> zyga: this was the lxd PR to move to the faster mirrors
[06:51] <zyga> perhaps there's some clue there
[06:51] <mborzecki> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks still happening oocassionaly inside lxd?
[06:51] <zyga> yes
[06:52] <zyga> error: cannot fetch snap signatures/assertions: cannot add assertion account-key (BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul): failed signature verification: openpgp: invalid signature: hash tag doesn't match
[06:52] <zyga> this is another, cannot prepare suite
[06:52] <zyga> ubuntu-core assertion fetch failed because the signature was invalid
[06:53] <zyga> another error
[06:54] <zyga> error: Get https://api.snapcraft.io/api/v1/snaps/download/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "Let's Encrypt Authority X3")
[06:54] <zyga> is the store really using a let's encrypt certificate?!
[06:54] <zyga> that last error happened at least three times
[06:55] <zyga> sanity check test failed, expected log message was not found in the journal
[06:55] <zyga> mvo: I was thinking about that
[06:55] <zyga> I think our journal handling is still bad
[06:56] <zyga> and I was thinking that for the sake of robustness we could log to a file as well
[06:56] <zyga> perhaps only under testing debug mode
[06:56] <zyga> it would also help us on 14.04 where journal has weaker APIs and just doesn't do what we need many times
[06:57] <zyga> - Consider re-refresh of "test-snapd-classic-confinement" (cannot query the store for updates: got unexpected HTTP status code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh")
[06:57] <zyga> but this is when store was down
[06:57] <zyga> error: cannot install "core16": cannot get device session from store: store
[06:57] <zyga>        server returned status 503 and body "<html><body><h1>503 Service
[06:57] <zyga>        Unavailable</h1>\nNo server is available to handle this
[06:57] <zyga>        request.\n</body></html>\n"
[06:57] <zyga> we apparently print the body of responses sometimes too?
[07:03] <mvo> woah
[07:04] <mvo> zyga: also "error: cannot fetch snap signatures/assertions: cannot add assertion account-key (BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul): failed signature verification: openpgp: invalid signature: hash tag doesn't match"
[07:05] <pstolowski> morning
[07:06] <mvo> hey pstolowski
[07:06] <mvo> zyga: I mean, *sigh*
[07:06] <mvo> zyga: fwiw, the lxd error I also got in 7286
[07:07] <mvo> zyga: and from looking at the logs I was wondering if its real so that the apparomor profile is not loaded by the postinst under certain circumstance
[07:07] <zyga> Good morning Paweł
[07:07] <mvo> zyga: *but* it all does not make sense and is hard to debug so I got a bit despaired
[07:07] <zyga> pstolowski: last night Catalina update fixed VMware
[07:08] <mvo> zyga: but yeah, it looks like the store was mightly unhappy last night
[07:08] <zyga> mvo: in cases like this I would look at all the errors to see if something stands out more than others but then proceed to focus on a single case
[07:09] <zyga> It does look grim when things are failing but we are not alone :)
[07:09] <pedronis> as I said it would be good to have stasts on error frequency but it's work
[07:09] <mvo> pedronis: you mean we should have stats on our side?
[07:10] <mvo> pedronis: and good morning :)
[07:10] <pedronis> which tests/hpw fail the most
[07:10] <pedronis> *how
[07:10]  * mvo nods
[07:19] <mvo> zyga: uh - I see "Sep 11 20:27:08 sep112008-564525 snapd[16506]: Sep 11 20:27:05 sep112008-564525 systemd[1]: [/etc/systemd/system/snap-test\x2dsnapd\x2drsync-12.mount:10] Unknown lvalue 'LazyUnmount' in section 'Mount'" in the logs. a agzillion of those
[07:20] <mvo> zyga: looks like this was added in 232 but 16.04 has 229
[07:21] <pedronis> ah
[07:21] <pedronis> fun
[07:23] <mborzecki> mvo: should be harmless though
[07:23] <zyga> Oh man
[07:23] <zyga> How come nothing failed on that?
[07:24] <pedronis> we don't test for the behavior no?
[07:24] <pedronis> it's just spamming the logs
[07:24] <pedronis> I think
[07:24] <pedronis> not failing to use the unit at all
[07:24] <zyga> Should we revert it or extend it so that we perform the unmount ourselves, without involving systemd?
[07:26] <mborzecki> looking into desktop-portal-filechooser, for some reasons this keeps failing quite often on 18.04 but not on later releases
[07:28] <pedronis> mvo: I have 3 more seedwriter PRs ready (+1 very close), but they probabbly would not be helpful right now, I also the accumulated size would be scary
[07:29] <pstolowski> a simple pr - https://github.com/snapcore/snapd/pull/7390 only adds a new test and is green but needs reviews
[07:29] <mvo> pedronis: yeah, let me start looking at those
[07:29] <mup> PR #7390: tests: unit test for a refresh failing on configure hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/7390>
[07:29] <mvo> pedronis: I'm almost ready scheduling for paris
[07:52] <mvo> mborzecki: the cgroup spread failure on i386 looks real (fwiw)
[07:56] <mborzecki> mvo: do you have log?
[07:57] <pedronis> pstolowski: hi,  #7196 can be simply closed now, no? we have #7092 waiting on snapcraft
[07:57] <mup> PR #7196: packaging: use passthrough for type:snapd <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7196>
[07:57] <mup> PR #7092: packaging: use snapd type and snapcraft 3.x <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
[07:57] <mborzecki> zyga: fwiw. looking at some things on amzn2, systemd complains about LazyUnmount, StartLimitInterval and FileDescriptorName, so it's a reasonable fallback behavior by systemd
[07:58] <pstolowski> pedronis: yes, done
[07:58] <mup> PR snapd#7196 closed: packaging: use passthrough for type:snapd <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7196>
[07:59] <pedronis> mborzecki: zyga: do we still need #7198 ?
[07:59] <mup> PR #7198: tests: reboot the node when restoring after a test involving lxd <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
[08:00] <mborzecki> pedronis: nope, we can close it
[08:00] <mborzecki> let me do it
[08:00] <Chipaca> moin moin
[08:01] <pedronis> Chipaca: hi
[08:01] <mup> PR snapd#7198 closed: tests: reboot the node when restoring after a test involving lxd <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
[08:02] <mborzecki> Chipaca: hey
[08:03] <mborzecki> obviously desktop-portal-fielchooser does not fail when you try to debug what's happening :/
[08:03] <zyga> mborzecki: than you
[08:05] <pedronis> sergio has a PR about it, not sure what it does
[08:05] <pedronis> mborzecki: what about #7193 ?
[08:05] <mup> PR #7193: [WIP] cgroupsv2 spread run <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7193>
[08:06] <mup> PR snapd#7452 closed: tests: move classic-ubuntu-core-transition* to nightly <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7452>
[08:06] <mup> PR snapd#7455 closed: tests: moving ubuntu-core-transition tests to nightly test suite <Created by sergiocazzolato> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7455>
[08:08] <mborzecki> pedronis: i'd liek to keep it around to track the failing tests (also needs an update)
[08:11] <pedronis> mborzecki: ok, that's fine, just wondered
[08:16] <pedronis> Chipaca: are you aware of #7447 ?
[08:16] <mup> PR #7447: snapstate: do not allow removal of the snapd snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7447>
[08:16] <Chipaca> the jumbo jet pr
[08:17] <Chipaca> yeah let's not do it this way :-)
[08:17] <Chipaca> I'll push a replacement for it and close this one
[08:18] <Chipaca> … as soon as i can get the current one green? or should i push it stacked? or ...?
[08:21] <Chipaca> pedronis: question about canRemove: both baseInUse and coreInUse call snapstate.All, but handle failure differently: one returns false, the other returns err != ErrNoState. Which is the correct approach?
[08:22] <pedronis> Chipaca: they probably both wrong
[08:22] <Chipaca> pedronis: … go on
[08:22] <pedronis> let me look
[08:22] <Chipaca> :) ok
[08:22] <pedronis> but eating errors is never a good idea
[08:23] <Chipaca> canremove would have to start bubbling the error out, in that case
[08:25] <pedronis> Chipaca: is used in one place no?
[08:25] <Chipaca> pedronis: right now yes
[08:25] <pedronis> anyway let me look
[08:25] <Chipaca> pedronis: i don't know why disable doesn't also check this though
[08:25] <pedronis> Chipaca: disable is a use at your own peril op
[08:25] <Chipaca> disable, the oft-forgotten ugly sibling
[08:25] <pedronis> also because it's our turn it off/on again remedy tbh
[08:26] <pedronis> or has been at least
[08:30] <zyga> pstolowski: something for you
[08:30] <zyga> https://www.irccloud.com/pastebin/yrr42wg7/
[08:31] <pstolowski> zyga: uuuh
[08:31] <pstolowski> zyga: is it on your box? state.json?
[08:32] <zyga> pstolowski: https://bugs.launchpad.net/snapd/+bug/1843683
[08:32] <zyga> nope, just spread on master
[08:32] <mup> Bug #1843683: cannot unmarshal state entry for "timings" <snapd:Confirmed> <https://launchpad.net/bugs/1843683>
[08:32] <zyga> since the 4.39e+08 is there, you can just write a test to see what happens
[08:32] <pstolowski> zyga: ok, thanks, will investigate
[08:33] <zyga> thank you
[08:33] <pstolowski> zyga: is this now blocking master / happening all the time?
[08:33] <zyga> no
[08:34] <zyga> but feels dangerous since it may break state handling
[08:34] <mvo> 6404 and 6839 are green and need a second review I think
[08:34] <pstolowski> zyga: only on `snap debug timings ..`
[08:35] <zyga> ah, that's good
[08:35] <zyga> though I thought that was always on and collected?
[08:35] <zyga> but perhaps I don't know well
[08:36] <pstolowski> zyga: yes always collected but we dont' unmarshall them, only append raw messages
[08:37] <pstolowski> regardless.. i'll investiagte today
[08:41] <zyga> pstolowski: thank you!
[09:01] <ackk> hi, is this the right place for multipass questions?
[09:03] <mup> PR snapd#7456 opened: usersession/client: add a client library for the user session agent <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7456>
[09:11] <zyga> ackk: ask away, Saviq is here
[09:13] <zyga> https://github.com/snapcore/snapd/pull/7448 is green and would unblock me
[09:13] <mup> PR #7448: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <https://github.com/snapcore/snapd/pull/7448>
[09:15] <ackk> Saviq, hi, I'm getting failures when trying to build a snap in multipass at the "apt update" phase, it seems it's trying to use ipv6 but failing contact the archive over ipv6
[09:15] <Saviq> ackk: what version of Multipass?
[09:15] <ackk> Saviq, I can ping that address from the machine where multipass runs. is there something to configure in multipass itself?
[09:15] <Saviq> `multipass version`
[09:15] <ackk> Saviq, installed:   0.9.0-dev.199+g69dad0f            (1135) 169MB classic
[09:16] <ackk> and:
[09:16] <ackk> multipass  0.9.0-dev.199+g69dad0f
[09:16] <ackk> multipassd 0.9.0-dev.199+g69dad0f
[09:16] <Saviq> ackk: go back to beta, we have a networking issue on edge
[09:16] <ackk> oh, I'm on edge
[09:16] <zyga> yay for channels
[09:16] <ackk> Saviq, should I use stable or beta?
[09:16] <Saviq> :)
[09:16] <zyga> I think this is so fantastic
[09:16] <ackk> zyga, +1
[09:16] <Saviq> ackk: stable not there
[09:16] <Saviq> Coming soon
[09:16] <ackk> oh right :)
[09:16] <ackk> sorry, haven't tried in in a while
[09:17] <Saviq> zyga: even better, bisecting snap revisions ;)
[09:17]  * ackk tries beta
[09:18] <Chipaca> i need to pop round to the bank, will bbiab
[09:18] <mborzecki> off for a bit
[09:36] <ackk> sarnold, beta worked, thanks!
[09:36] <ackk> err, Saviq ^
[09:36] <Saviq> :)
[09:37] <Saviq> I'm sure sarnold will be happy, too !)
[09:47] <pedronis> mvo: I gave my +1 to 6404 and 6839 , I left a question in the latter though. They still need 2nd reviews
[09:52] <mvo> pedronis: thank you! I will check if there is a missing test in 6839
[09:55] <mup> PR snapd#7448 closed: tests: remove mount_id and parent_id from mount-ns test data <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7448>
[10:03] <mborzecki> re
[10:03] <zyga> https://github.com/snapcore/snapd/pull/7442/files shrank from 5K diff to 500 diff
[10:03] <zyga> :)
[10:03] <mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
[10:17] <pedronis> pstolowski: I did another pass on #7277
[10:17] <mup> PR #7277: overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>
[10:18] <pstolowski> pedronis: ty
[10:57] <zyga> brb
[11:06] <pstolowski> #7390 needs 2nd review, it's just a new test and green :}
[11:06] <mup> PR #7390: tests: unit test for a refresh failing on configure hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/7390>
[11:08] <pstolowski> nooo, koza is leaving
[11:12] <Chipaca> was jonathan riddel on irc? anybody know their nick?
[11:13] <pstolowski> Chipaca: the kde guy? jriddel afair, or maybe just riddel
[11:13] <Chipaca> hm
[11:15] <pstolowski> Chipaca: maybe you could take a look at #7390?
[11:15] <mup> PR #7390: tests: unit test for a refresh failing on configure hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/7390>
[11:16] <zyga> re
[11:16] <zyga> sorry, some woes with daugther
[11:16] <zyga> 10-year-olds and all that stuff
[11:17] <Chipaca> pstolowski: in a bit yes
[11:17] <mborzecki> zyga:  pffff desktop portals https://paste.ubuntu.com/p/VttStX82xQ/
[11:18] <zyga> desktop-mortal
[11:18] <zyga> jamesh: hello
[11:18] <jamesh> zyga: hi
[11:18] <zyga> are you still around by any chance? I know it's probably super late for you
[11:18] <zyga> hey!
[11:18] <zyga> mborzecki was looking at some of the failures in the xdg-desktop-portal test, specifically on 18.04
[11:19] <zyga> and concluded that it is likely that this specific version 0.11 of the portal is just buggy
[11:19] <zyga> how likely is to backport the portal stack to 18.04
[11:19] <mborzecki> zyga: jamesh: actually 1.0.3 was pushed to 18.04, but the issue persists
[11:19] <zyga> and if unlikely, should we formally support it at the current version?
[11:19] <jamesh> mborzecki: 1.0.3 is in bionic-updates
[11:20] <jamesh> oh.
[11:20] <jamesh> We'll definitely want to upgrade for the snap support improvement work I haven't started
[11:23]  * pstolowski bbiab
[11:24] <cjwatson> Chipaca: Riddell, two ls
[11:24] <Chipaca> ah
[11:24] <cjwatson> (that was their nick as well as their surname.  Dunno if they're still on IRC)
[11:24]  * Chipaca bad with names
[11:30] <jamesh> mborzecki, zyga: the only patch to the document portal FUSE code missing from the Bionic packages is this one: https://github.com/flatpak/xdg-desktop-portal/commit/c9159903e151d5aba3067dcaeb977ceb9a1a9e8b#diff-113fd392ffd1391fc2e8547af3dd1789
[11:31] <mborzecki> jamesh: so 2 problems we have now, 1. when the test code in desktop-portal-filechooser closes the fd it writes to, the content cannot be immediately read from the actual file, but after waiting for a bit it does appear there (some race with closing/flushing data in xdp in the portal)?
[11:32] <mborzecki> jamesh: then 2nd. occasionally we get OSError with -ENOSYS when the file did not exist pefore it was picked for saving-to (the same test)
[11:32] <jamesh> mborzecki: I wonder if the link count could affect that first one?
[11:33] <mborzecki> jamesh: i've started a portal separately with G_MESSAGES_DEBUG=all, replaced the one running in test user's session, but cannot reproduce the problem this way, so maybe a race again
[11:33] <zyga> perhaps all versions are buggy then?
[11:33] <zyga> mborzecki: does that test run on anything more recent than 18.04?
[11:34] <mborzecki> zyga: yes, 19.04 and 19.10, haven't really seen issues on 19.10
[11:34] <zyga> mmm
[11:34] <mborzecki> jamesh: maybe that's a data point then
[11:34] <zyga> so it's a real thing then
[11:35] <jamesh> mborzecki: It's quite possible that there is a problem outside of the xdg-desktop-portal code too
[11:35] <jamesh> mborzecki: this is the other change to document-portal-fuse.c between 1.0.3 and master: https://github.com/flatpak/xdg-desktop-portal/pull/310
[11:35] <mup> PR flatpak/xdg-desktop-portal#310: document-portal: make xdp_inode_kernel_unref check that kernel_ref_count > 0 <Created by jhenstridge> <Merged by alexlarsson> <https://github.com/flatpak/xdg-desktop-portal/pull/310>
[11:36] <jamesh> which we included in the Bionic package
[11:37] <jamesh> I don't think we ever worked out the root cause for that
[11:40] <jamesh> it is possible that it's a bug in the bionic kernel
[11:41] <mborzecki> jamesh: another data point, i can't really reproduce any of the problems by stating the portal manually, but happens regularly when it's started by user systemd
[11:53] <mborzecki> jamesh: https://paste.ubuntu.com/p/P7Jj5BVsgz/ captured when rename happens after fuse_release, so the content is not really available yet
[12:00] <jamesh> mborzecki: the kernel unref PR I mentioned earlier is something that shouldn't be necessary: it essentially means that the fuse filesystem and kernel disagree about the kernel-side reference count of an inode
[12:00] <jamesh> mborzecki: it's something I haven't been able to reproduce on any other distro release
[12:01] <jamesh> if there is some bug in the kernel-side fuse code for that release, it could very well lead to this kind of problem
[12:09] <mup> PR snapd#7390 closed: tests: unit test for a refresh failing on configure hook <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7390>
[12:11] <ackk> does snapcraft need to use the lxd snap or can it use an already set up lxd?
[12:20] <Chipaca> whoops, just spotted a bug in the model pr
[12:20]  * Chipaca pokes at it
[12:31] <mborzecki> zyga: left a coment https://github.com/snapcore/snapd/pull/7442#discussion_r323712211
[12:31] <mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
[12:32] <mborzecki> zyga: fwiw, core18 mounts seem ok, though with /usr/share/gdb you'd have just 2 entries
[12:32] <zyga> yeah, I will change that
[12:33] <zyga> I made progress on https://github.com/snapcore/snapd/pull/7421
[12:33] <mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
[12:33] <zyga> check out the pretty red diff there :)
[13:50] <zyga> re
[13:50] <zyga> mvo: sorry, daughter had existential problems related to lunch
[13:50] <zyga> mvo: needed to have a walk and talk to her
[13:50] <zyga> uh :)
[13:51] <cwayne> zyga: who doesnt have the occasional mid-lunch crisis :P
[13:54] <Chipaca> ijohnson: ah just saw your last question, and you're right i hadn't replied
[13:54] <ijohnson> np, thanks for clarifying
[13:54] <Chipaca> ijohnson: let me clarify more just in case
[13:55]  * ijohnson needs to get a cup of coffee then will read through
[13:55] <Chipaca> ijohnson: _if_ the output is yamlish, and _if_ the value needs to start with "- ", then yes use esc.dash
[13:56] <pedronis> it might be our case there
[13:57] <Chipaca> ijohnson: e.g. in 'snap info', we use esc.dash for "this channel is closed" (e.g. stable in 'snap info multipass'), but not for the - at the end of a channel line
[14:31] <ijohnson_> okay, thanks Chipaca for that explanation
[14:32] <Chipaca> ijohnson_: short answer: copy the output without the dash into http://yaml-online-parser.appspot.com/ and if it complains, change it to dash
[14:32] <ijohnson_> yes for the `snap model --verbose` we will hit that case where the output is yamlish and the value starts with "- (..."
[14:46] <mup> PR snapcraft#2708 closed: tools: make environment-setup container name and image configurable <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2708>
[15:05] <pstolowski> oh well, fun with json, i feel that https://bugs.launchpad.net/snapd/+bug/1843683 is a tip of an iceberg
[15:05] <mup> Bug #1843683: cannot unmarshal state entry for "timings" <snapd:In Progress by stolowski> <https://launchpad.net/bugs/1843683>
[15:08] <pstolowski> fun fact: the only way to unmarshall something like 4.39e+08 is to have float in struct; using DecodeWithNumber doesn't help
[15:11] <mvo> niemeyer: hey, we talked yesterday about pagination support for the spread google backend and you suggested to look into something more generic. I did that and pushed https://github.com/snapcore/spread/pull/87 - it would be great if you could have a look and tell me if that is what you had in mind. no need for a in-depth review yet, just a check. if you think this should be the path forward I will polish it a bit and add more tests. if you prefer
[15:11] <mvo>  the simpler approach in pr69 thats also fine of course :)
[15:11] <mup> PR spread#87: google: add generic pagination support on GCE results <Created by mvo5> <https://github.com/snapcore/spread/pull/87>
[15:11] <pstolowski> while i can change durations in debug timings to float64 both in timing definition and in the client to make everything happy end-to-end (and it's backward compatible change), we may have similiar problem with doing/undoing time on tasks. but what made json marshaller use 4.39e+08 out of sudden to encode int64 duration in the state is still mistery to me
[15:16]  * cachio bank
[15:16] <cachio> and lunch
[15:17] <niemeyer> mvo: Yeah, that's the direction indeed
[15:17] <niemeyer> mvo: Would be nice to avoid reflecting, but I'm not entirely sure how
[15:20] <mvo> niemeyer: yeah, the reflection is a bit ugly, I couldn't think of a better way though. I keep meditating over it :)
[15:21] <niemeyer> mvo: Sent a note in the PR
[15:21] <mvo> thanks niemeyer
[15:21] <niemeyer> mvo: One option to avoid both would be to do smoething like dofl(........, &foo.TheItemsField)
[15:22] <niemeyer> mvo: This would enable pagination and provide the field in one go.. I don't know how realistic that is, though.. I thought about it for 10 seconds only
[15:24] <mvo> niemeyer: thats fine, thanks for the suggestions! I will experiment and see how far I get and if I can eliminate reflection entirely (or mostly). no worries, I ping you again once I had a chance to update it
[15:24] <niemeyer> mvo: Yeah, entirely is probably not doable as the slice extension needs to take place, but to a good degree maybe
[15:24] <mvo> niemeyer: indeed
[16:02] <mup> PR snapd#7453 closed: tests/classic-custom-device-reg: disable on opensuse-15 and fedora-30 <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7453>
[16:21] <ijohnson_> zyga: are you planning on changing the directory to one that has less diff between core/core18 in #7442 ?
[16:21] <mup> PR #7442: tests: extend mount-ns test to handle mimics <Created by zyga> <https://github.com/snapcore/snapd/pull/7442>
[16:36] <ijohnson_> Chipaca, pedronis, for `snap model --verbose`, both brand and brand-id will be in the output, but which should come first?
[16:37] <ijohnson_> looks a little better with brand first I think
[16:43] <ijohnson_> see https://pastebin.ubuntu.com/p/Kk48mvwBMq/ for output with brand first
[16:44] <zyga> mborzecki: I will look
[16:44] <zyga> ijohnson_: yes,
[16:44] <zyga> ijohnson_: just AFK on child care
[16:44] <ijohnson_> no rush zyga, just curious if I should wait to review that
[16:44] <ijohnson_> sounds like yes wait to review
[16:44] <ijohnson_> thanks
[16:45] <zyga> ijohnson_: yeah, please wait a few hours
[16:45] <ijohnson_> np
[16:45] <zyga> thank you for checking
[17:16] <pedronis> ijohnson_: I'm not quite sure I understood that suggestion from John myself, we might have to chat with him tomorrow
[17:17] <ijohnson_> pedronis: hmm ok well do you want me to add it to the PR or leave it out for now?
[17:18] <pedronis> ijohnson_: let the code stay as however it is at the moment, we can tweak tomorrow/in a follow up
[17:18] <pedronis> also maybe Chipaca is still around
[17:18] <ijohnson_> ack
[17:18] <ijohnson_> he said he EOD in the other channel a bit ago
[17:18] <pedronis> ah ok
[17:19] <ijohnson_> it's just 4 lines of code so it's real easy to add back if desired
[17:31] <pedronis> ijohnson_: anyway I gave some input if we go there
[17:31] <ijohnson_> thanks
[17:32]  * ijohnson_ lunches
[18:13] <ardaguclu_> Is snap-failure executable deprecated?
[18:22] <mup> PR snapd#7351 closed: tests: retry checking until the written file on desktop-portal-filechooser <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7351>
[18:26] <mup> PR snapd#6404 closed: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6404>
[18:28] <mvo> zyga: mind if I do the bits that john asked for in 6174?
[18:46] <ijohnson_> hey cachio, does kill-timout for a task apply to prepare and execute? do both parts have to come in under kill-timeout or does it apply to both separately?
[18:47] <cachio> ijohnson_, kill timeout is for the whole task
[18:48] <ijohnson_> okay, I'm thinking about opening a PR changing the kill-timeout for some tasks from like 2m or 3m to double that because the tests keep getting killed while trying to download a snap from the store or something like that
[18:49] <cachio> ijohnson_, you can set kill-timeout: 60m for the task
[18:49] <cachio> let me check in the code
[18:50] <ijohnson_> cachio, no not for debugging, like permanently I was thinking
[18:50] <ijohnson_> just because it seems to be happening so much
[18:51] <cachio> ijohnson_, the idea is to have at least 5 minutes depending on the task
[18:51] <cachio> by default it is 20
[18:51] <cachio> ijohnson_, which task is timingout?
[18:52] <ijohnson_> I've seen tests/main/snap-wait, classic-custom-device-reg some of the ubuntu-core-transition tasks probably others I can't remember
[18:55] <cachio> ijohnson_, you are right kill-timeout: 2m
[18:55] <cachio> it should be at lest 5m
[18:56] <cachio> at some point I updated all the timeouts
[18:56] <cachio> to 5m
[18:56] <ijohnson_> hmm
[18:56] <cachio> this is new
[18:56] <ijohnson_> I'll submit a PR with all the ones less than 2m upped to 5m
[18:56] <cachio> also happens that in the boards it usually takes more time
[18:56] <ijohnson_> but I'll ask in SU tomorrow if there's a good reason any of the tests should be less than 5m
[18:56] <cachio> and 2m is not enough
[18:56] <ijohnson_> right
[18:57] <cachio> ijohnson_, please submit the PR
[18:57] <cachio> that's really appreciated
[18:57] <ijohnson_> ack
[18:59] <ijohnson_> cachio: it would be kind of nice if you could somehow configure the timeout to be more time on slower hardware, like perhaps a per-system or per-backend timeout
[19:09] <ijohnson_> cachio: opened PR #7457
[19:09] <mup> PR #7457: tests/main/many: increase kill-timeout to 5m <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7457>
[19:10] <mup> PR snapd#7457 opened: tests/main/many: increase kill-timeout to 5m <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7457>
[19:14] <cachio> ijohnson_, thanks taking a look
[19:15] <mfeatherston> Is there anything going on with the servers?  I'm trying to "snapcraft register-key" and keep getting "The Snap Store encountered an error while processing your request: internal server error (code 500).".  If I enter the wrong username/password it notices that, but fails with this message when I give it the correct login
[19:18] <roadmr> mfeatherston: checking, hang on
[19:21] <roadmr> mfeatherston: a favor if you can - can you run SNAPCRAFT_ENABLE_DEVELOPER_DEBUG=yes snapcraft register-key (and specify a correct login) ? that might give more info about that 500
[19:21] <roadmr> mfeatherston: I'm checking logs on my side as well
[19:23] <roadmr> mfeatherston? where'd you go?!?! 🤔
[19:25] <roadmr> mfeatherston: you can use a pastebin service to post long logs
[19:49] <Chipaca> ijohnson_: I stepped away, I hadn't _quite_ EOD'ed yet
[19:49] <Chipaca> just went for a run
[19:49] <Chipaca> but now i'm back
[19:49] <Chipaca> well, technically i was back half an hour ago also, but, eww stinky
[19:49] <ijohnson_> Chipaca: np, I mean it does seem reasonable for you to EOD when you did
[19:50] <Chipaca> soft-EOD because I had some threads still going
[19:50] <Chipaca> :)
[19:50] <Chipaca> also runs sometimes clear the head and you come back ready to break things
[19:50] <ijohnson_> true that
[19:51] <ijohnson_> so did you mean for brand and brand-id to both be displayed with `snap model --verbose` ?
[19:51] <Chipaca> ijohnson_: i suspect we need to sync with pedronis because that's what I understood _him_ to say :-) and it seemed reasonable to me
[19:51] <Chipaca> so maybe i'm missing something
[19:51] <ijohnson_> haha okay
[19:51] <Chipaca> I mean, his comment about
[19:51]  * Chipaca looks for it
[19:51] <ijohnson_> well I commented with potential outputs on the PR to look at
[19:52] <Chipaca> 'my original proposal would do this also if x.Verbose,'
[19:52] <Chipaca> the one i replied to in fact
[19:52] <Chipaca> doing that "also if x.Verbose" means printing brand-id when verbose even if not --serial
[19:53] <Chipaca> right?
[19:53] <ijohnson_> that's what I understood him to mean as well
[19:53] <Chipaca> the other thing in the if he commented on was already being printed
[19:53] <ijohnson_> I think pedronis' most recent point is fair though about if we do both brand and brand-id we should drop the `(...)` from brand if it exists
[19:55] <Chipaca> sigh :)
[19:55] <Chipaca> i think i'm going to go have a curry and let the universe think about what it's done
[21:03] <sergiusens> cachio: hey, can you tell me what this means https://travis-ci.org/snapcore/snapcraft/jobs/584308760 ?
[21:05] <mup> PR snapd#7458 opened: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfined <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7458>
[21:07] <mup> PR snapd#7459 opened: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfined - 2.41 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7459>
[21:08] <mup> PR snapd#7459 closed: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfined - 2.41 <Simple 😃> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/7459>
[21:10] <mup> PR snapd#7460 opened: interfaces/kubernetes-support: allow systemd-run to ptrace read unconfind - 2.41 <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7460>
[21:11] <mup> PR snapcraft#2713 opened: tests: completely mock bzr tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2713>