| 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> | 00:58 |
|---|---|---|
| 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> | 02:36 |
| 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> | 03:07 |
| mborzecki | morning | 04:57 |
| mborzecki | gorename has gone crazy since 1.13 update | 05:37 |
| zyga | Morning school run | 06:03 |
| mborzecki | zyga: hey | 06:31 |
| 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:34 |
| 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:35 |
| 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:36 |
| zyga | let's start with that | 06:37 |
| zyga | good morning mvo | 06:38 |
| mborzecki | mvo: hey | 06:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| mborzecki | 72 prs | 06:45 |
| zyga | mvo: I commented on a related issue here https://github.com/snapcore/snapd/pull/7453 | 06:45 |
| 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:46 |
| 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:48 |
| 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:49 | |
| 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:50 |
| 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:51 |
| 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:52 |
| zyga | another error | 06:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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? | 06:57 |
| mvo | woah | 07:03 |
| 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:04 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:05 |
| mvo | hey pstolowski | 07:06 |
| mvo | zyga: I mean, *sigh* | 07:06 |
| mvo | zyga: fwiw, the lxd error I also got in 7286 | 07:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| mvo | pedronis: and good morning :) | 07:10 |
| pedronis | which tests/hpw fail the most | 07:10 |
| pedronis | *how | 07:10 |
| * mvo nods | 07:10 | |
| 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:19 |
| mvo | zyga: looks like this was added in 232 but 16.04 has 229 | 07:20 |
| pedronis | ah | 07:21 |
| pedronis | fun | 07:21 |
| mborzecki | mvo: should be harmless though | 07:23 |
| zyga | Oh man | 07:23 |
| zyga | How come nothing failed on that? | 07:23 |
| 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:24 |
| mborzecki | looking into desktop-portal-filechooser, for some reasons this keeps failing quite often on 18.04 but not on later releases | 07:26 |
| 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:28 |
| 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:29 |
| mvo | mborzecki: the cgroup spread failure on i386 looks real (fwiw) | 07:52 |
| mborzecki | mvo: do you have log? | 07:56 |
| 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:57 |
| 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:58 |
| 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> | 07:59 |
| mborzecki | pedronis: nope, we can close it | 08:00 |
| mborzecki | let me do it | 08:00 |
| Chipaca | moin moin | 08:00 |
| 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:01 |
| mborzecki | Chipaca: hey | 08:02 |
| mborzecki | obviously desktop-portal-fielchooser does not fail when you try to debug what's happening :/ | 08:03 |
| zyga | mborzecki: than you | 08:03 |
| 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:05 |
| 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:06 |
| mborzecki | pedronis: i'd liek to keep it around to track the failing tests (also needs an update) | 08:08 |
| pedronis | mborzecki: ok, that's fine, just wondered | 08:11 |
| 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:16 |
| Chipaca | yeah let's not do it this way :-) | 08:17 |
| Chipaca | I'll push a replacement for it and close this one | 08:17 |
| Chipaca | … as soon as i can get the current one green? or should i push it stacked? or ...? | 08:18 |
| 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:21 |
| 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:22 |
| Chipaca | canremove would have to start bubbling the error out, in that case | 08:23 |
| 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:25 |
| pedronis | or has been at least | 08:26 |
| zyga | pstolowski: something for you | 08:30 |
| zyga | https://www.irccloud.com/pastebin/yrr42wg7/ | 08:30 |
| pstolowski | zyga: uuuh | 08:31 |
| pstolowski | zyga: is it on your box? state.json? | 08:31 |
| 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:32 |
| zyga | thank you | 08:33 |
| pstolowski | zyga: is this now blocking master / happening all the time? | 08:33 |
| zyga | no | 08:33 |
| 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:34 |
| 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:35 |
| pstolowski | zyga: yes always collected but we dont' unmarshall them, only append raw messages | 08:36 |
| pstolowski | regardless.. i'll investiagte today | 08:37 |
| zyga | pstolowski: thank you! | 08:41 |
| ackk | hi, is this the right place for multipass questions? | 09:01 |
| 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:03 |
| zyga | ackk: ask away, Saviq is here | 09:11 |
| 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:13 |
| 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:15 |
| 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:16 |
| Saviq | zyga: even better, bisecting snap revisions ;) | 09:17 |
| * ackk tries beta | 09:17 | |
| Chipaca | i need to pop round to the bank, will bbiab | 09:18 |
| mborzecki | off for a bit | 09:18 |
| ackk | sarnold, beta worked, thanks! | 09:36 |
| ackk | err, Saviq ^ | 09:36 |
| Saviq | :) | 09:36 |
| Saviq | I'm sure sarnold will be happy, too !) | 09:37 |
| pedronis | mvo: I gave my +1 to 6404 and 6839 , I left a question in the latter though. They still need 2nd reviews | 09:47 |
| mvo | pedronis: thank you! I will check if there is a missing test in 6839 | 09:52 |
| 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> | 09:55 |
| 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:03 |
| 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:17 |
| pstolowski | pedronis: ty | 10:18 |
| zyga | brb | 10:57 |
| 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:06 |
| pstolowski | nooo, koza is leaving | 11:08 |
| Chipaca | was jonathan riddel on irc? anybody know their nick? | 11:12 |
| pstolowski | Chipaca: the kde guy? jriddel afair, or maybe just riddel | 11:13 |
| Chipaca | hm | 11:13 |
| 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:15 |
| zyga | re | 11:16 |
| zyga | sorry, some woes with daugther | 11:16 |
| zyga | 10-year-olds and all that stuff | 11:16 |
| Chipaca | pstolowski: in a bit yes | 11:17 |
| mborzecki | zyga: pffff desktop portals https://paste.ubuntu.com/p/VttStX82xQ/ | 11:17 |
| 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:18 |
| 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:19 |
| jamesh | oh. | 11:20 |
| jamesh | We'll definitely want to upgrade for the snap support improvement work I haven't started | 11:20 |
| * pstolowski bbiab | 11:23 | |
| 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:24 | |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| jamesh | which we included in the Bionic package | 11:36 |
| jamesh | I don't think we ever worked out the root cause for that | 11:37 |
| jamesh | it is possible that it's a bug in the bionic kernel | 11:40 |
| 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:41 |
| mborzecki | jamesh: https://paste.ubuntu.com/p/P7Jj5BVsgz/ captured when rename happens after fuse_release, so the content is not really available yet | 11:53 |
| 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:00 |
| 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:01 |
| 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:09 |
| ackk | does snapcraft need to use the lxd snap or can it use an already set up lxd? | 12:11 |
| Chipaca | whoops, just spotted a bug in the model pr | 12:20 |
| * Chipaca pokes at it | 12:20 | |
| 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:31 |
| 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:32 |
| 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 :) | 12:33 |
| === ricab is now known as ricab|lunch | ||
| 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:50 |
| cwayne | zyga: who doesnt have the occasional mid-lunch crisis :P | 13:51 |
| 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:54 |
| * 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:55 |
| pedronis | it might be our case there | 13:56 |
| 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 | 13:57 |
| === ricab|lunch is now known as ricab | ||
| ijohnson_ | okay, thanks Chipaca for that explanation | 14:31 |
| 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:32 |
| 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> | 14:46 |
| 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:05 |
| 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:08 |
| 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:11 |
| * cachio bank | 15:16 | |
| cachio | and lunch | 15:16 |
| 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:17 |
| mvo | niemeyer: yeah, the reflection is a bit ugly, I couldn't think of a better way though. I keep meditating over it :) | 15:20 |
| 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:21 |
| 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:22 |
| 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 | 15:24 |
| === clobrano_ is now known as clobrano | ||
| 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:02 |
| 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:21 |
| === pstolowski is now known as pstolowski|afk | ||
| ijohnson_ | Chipaca, pedronis, for `snap model --verbose`, both brand and brand-id will be in the output, but which should come first? | 16:36 |
| ijohnson_ | looks a little better with brand first I think | 16:37 |
| ijohnson_ | see https://pastebin.ubuntu.com/p/Kk48mvwBMq/ for output with brand first | 16:43 |
| 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:44 |
| zyga | ijohnson_: yeah, please wait a few hours | 16:45 |
| ijohnson_ | np | 16:45 |
| zyga | thank you for checking | 16:45 |
| pedronis | ijohnson_: I'm not quite sure I understood that suggestion from John myself, we might have to chat with him tomorrow | 17:16 |
| ijohnson_ | pedronis: hmm ok well do you want me to add it to the PR or leave it out for now? | 17:17 |
| 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:18 |
| ijohnson_ | it's just 4 lines of code so it's real easy to add back if desired | 17:19 |
| pedronis | ijohnson_: anyway I gave some input if we go there | 17:31 |
| ijohnson_ | thanks | 17:31 |
| * ijohnson_ lunches | 17:32 | |
| ardaguclu_ | Is snap-failure executable deprecated? | 18:13 |
| 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:22 |
| 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:26 |
| mvo | zyga: mind if I do the bits that john asked for in 6174? | 18:28 |
| 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:46 |
| cachio | ijohnson_, kill timeout is for the whole task | 18:47 |
| 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:48 |
| cachio | ijohnson_, you can set kill-timeout: 60m for the task | 18:49 |
| cachio | let me check in the code | 18:49 |
| ijohnson_ | cachio, no not for debugging, like permanently I was thinking | 18:50 |
| ijohnson_ | just because it seems to be happening so much | 18:50 |
| 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:51 |
| 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:52 |
| cachio | ijohnson_, you are right kill-timeout: 2m | 18:55 |
| cachio | it should be at lest 5m | 18:55 |
| 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:56 |
| cachio | ijohnson_, please submit the PR | 18:57 |
| cachio | that's really appreciated | 18:57 |
| ijohnson_ | ack | 18:57 |
| 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 | 18:59 |
| 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:09 |
| mup | PR snapd#7457 opened: tests/main/many: increase kill-timeout to 5m <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7457> | 19:10 |
| cachio | ijohnson_, thanks taking a look | 19:14 |
| 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:15 |
| roadmr | mfeatherston: checking, hang on | 19:18 |
| 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:21 |
| roadmr | mfeatherston? where'd you go?!?! 🤔 | 19:23 |
| roadmr | mfeatherston: you can use a pastebin service to post long logs | 19:25 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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 | 19:55 |
| sergiusens | cachio: hey, can you tell me what this means https://travis-ci.org/snapcore/snapcraft/jobs/584308760 ? | 21:03 |
| 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:05 |
| 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:07 |
| 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:08 |
| 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:10 |
| mup | PR snapcraft#2713 opened: tests: completely mock bzr tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2713> | 21:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!