| mup | PR snapcraft#2490 closed: test: test-beta <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2490> | 00:15 |
|---|---|---|
| mwhudson | hmm trying to use the fakestore and failing | 02:39 |
| mwhudson | just get http 418s from everything | 02:39 |
| mwhudson | anyone around? | 02:39 |
| mwhudson | i guess i'll ask in the forum | 02:39 |
| mborzecki | morning | 06:15 |
| mborzecki | brb kernel update | 06:26 |
| zyga | Hey guys! I will be in the office in 20 minutes. Doing some babysitting now. | 07:09 |
| mborzecki | arch package update pushed | 07:12 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:52 |
| pedronis | pstolowski: hi, mvo created this: https://trello.com/c/h3v4bN13/172-fix-build-failure-on-armhf-in-edge-ppa | 08:10 |
| pedronis | is that a new test? or associated with recent changes? seems it's failing in the armhf builders | 08:10 |
| pedronis | timing? | 08:10 |
| pstolowski | pedronis: hey, yes, i got email from trello, investigating, reproduced locally by running in a loop, seems like a race | 08:10 |
| pedronis | pstolowski: ok, thank you, and yes it's a priority given it's stopping us from producing edge builds for arm | 08:11 |
| pstolowski | pedronis: i don't think it's because yesterday's changes, this landed last week | 08:11 |
| pedronis | pstolowski: not quite sure when the error appeared | 08:11 |
| pstolowski | pedronis: more worrying is the amd64 failure in same ppa on TestHotplug | 08:13 |
| pedronis | pstolowski: ok | 08:13 |
| pstolowski | pedronis: looks like something got stuck on udev monitor, might be something build env specific, hard to tell | 08:14 |
| pstolowski | but also, not related to yesterday's change i think, that test was landed long time ago | 08:14 |
| pedronis | pstolowski: ok, let me know how it goes | 08:23 |
| pstolowski | pedronis: sure | 08:25 |
| mborzecki | rpm triggers for downgrade suck | 08:30 |
| pstolowski | pedronis: ok, i got it, PR coming | 08:32 |
| mup | PR snapd#6550 opened: daemon/tests: fix race in the disconnect conflict test <Simple 😃> <⚠Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6550> | 08:39 |
| pstolowski | pedronis: ^ | 08:39 |
| pstolowski | pedronis: the amd64 failure on 14.04 is unclear atm, not sure why we didn't see it before; the udev mon test run for 10 minutes and got killed, i'll see if i can reproduce on 14.04 | 08:41 |
| pedronis | pstolowski: +1 on the first fix | 08:43 |
| Chipaca | moin moin | 09:09 |
| pedronis | Chipaca: hi | 09:24 |
| Chipaca | pedronis: 'sup | 09:24 |
| mborzecki | hmm rpm triggers are most interesting, semi-useless documentation, only thing you can really do is experiment :/ | 09:41 |
| pedronis | Chipaca: how's the tweaking of 6356 ? | 09:45 |
| Chipaca | pedronis: nearly done, just the reRefreshUpdateMany rename pending | 09:46 |
| Chipaca | pedronis: problem is I either make it _the_ update many, or fix it with a comment | 09:48 |
| Chipaca | dithering too much on that | 09:48 |
| pedronis | Chipaca: can I help? but I'm not understanding those last two comments | 09:48 |
| Chipaca | pedronis: I'll let you know :-) | 09:49 |
| zyga | uh, re | 09:57 |
| zyga | hey | 09:57 |
| zyga | sorry, tough night, tough morning | 09:57 |
| zyga | pstolowski: I see you know about the card mvo made | 09:58 |
| zyga | we discussed it last night and he asked me to relay that you have a look | 09:58 |
| pstolowski | zyga: yep, https://github.com/snapcore/snapd/pull/6550 | 09:58 |
| mup | PR #6550: daemon/tests: fix race in the disconnect conflict test <Simple 😃> <⚠Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6550> | 09:58 |
| zyga | pstolowski, pedronis: should we do a .5 with this or is it sufficient to just patch master? | 10:00 |
| pedronis | zyga: as far as I understand it was affecting edge | 10:00 |
| pedronis | not 2.37 | 10:00 |
| zyga | pedronis: the failure was reported on .4 build | 10:01 |
| zyga | https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages | 10:01 |
| zyga | on line three there | 10:01 |
| pedronis | then mvo explained himself badly | 10:02 |
| zyga | let me check the state of beta | 10:02 |
| zyga | pedronis: I think we're good, I see .4 in beta across all architectures | 10:04 |
| Chipaca | zyga: hella good | 10:05 |
| zyga | Chipaca: :-) hey, how are you doing? | 10:06 |
| Chipaca | zyga: hating names | 10:06 |
| zyga | oh? | 10:06 |
| zyga | what's wrong? | 10:06 |
| Chipaca | :-) | 10:06 |
| Chipaca | zyga: nothing unusual there though | 10:06 |
| pstolowski | google:ubuntu-14.04-64:tests/main/snapd-reexec failed on my PR (unrelated to the PR), and lots of aborts again | 10:24 |
| pedronis | pstolowski: yes, lots of aborts | 10:27 |
| pedronis | in many PRs | 10:27 |
| pedronis | pstolowski: spread error output about aborts is always hard to chase | 10:35 |
| pstolowski | uhm | 10:36 |
| pedronis | usually is allocating machines? | 10:37 |
| pedronis | pstolowski: zyga: ah, 2019-02-28 07:08:49 Cannot allocate google:opensuse-tumbleweed-64: cannot find any Google image matching "opensuse-tumbleweed-64" on project "computeengine" or "opensuse-cloud" | 10:38 |
| pstolowski | uh | 10:38 |
| pedronis | we should disable it until cachio can debug | 10:38 |
| pedronis | it worked yesterday once or so | 10:38 |
| pedronis | pstolowski: add a manual:true in its stanza (as we have for others) | 10:40 |
| pedronis | in your PR | 10:40 |
| pstolowski | pedronis: you mean in #6491? | 10:42 |
| mup | PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491> | 10:42 |
| pedronis | pstolowski: ? | 10:42 |
| pedronis | pstolowski: the easy one | 10:43 |
| pedronis | pstolowski: #6550 | 10:43 |
| mup | PR #6550: daemon/tests: fix race in the disconnect conflict test <Simple 😃> <⚠Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6550> | 10:43 |
| pedronis | pstolowski: the other needs a review process no? | 10:44 |
| pedronis | pstolowski: we need a PR that we want to land and can land soon | 10:45 |
| pstolowski | pedronis: yes sure the other PR needs reviews; ok, will set opensuse-tumbleweed to manual for now | 10:49 |
| * Chipaca brb | 10:56 | |
| pedronis | mborzecki: could you review #6356 when you have some time? | 11:04 |
| mup | PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356> | 11:04 |
| pedronis | pstolowski: thanks | 11:04 |
| mborzecki | pedronis: sure, gladly, got quite fed up with the rpm crap | 11:05 |
| mborzecki | heh, i cannot use snap-mgmt to do the patching of mount units and we'll have to ship a separate script, otherwise downgrade to pre selinux-aware snapd won't work | 11:06 |
| zyga | 2.37.4 panic in unit tests | 11:09 |
| zyga | https://www.irccloud.com/pastebin/Ky7i9Vr5/ | 11:09 |
| mup | PR snapd#6499 closed: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6499> | 11:12 |
| zyga | I added a trello card | 11:14 |
| pedronis | zyga: about ? | 11:14 |
| zyga | about that failure, so that I don't forget to look at it later today | 11:14 |
| zyga | going through the release process now | 11:14 |
| pedronis | zyga: when does it happen? 2.37 is green | 11:14 |
| pedronis | on GH | 11:14 |
| zyga | pedronis: it seems like a race, it happened in 2.37.4 unit tests during package build | 11:15 |
| pedronis | ok, weird | 11:15 |
| pedronis | I would those tests don't need to do weird racy things | 11:15 |
| pedronis | but what do I know | 11:15 |
| zyga | yeah :( | 11:15 |
| pedronis | the test is probably complicated | 11:15 |
| pedronis | zyga: no, I fear a real bug | 11:19 |
| pedronis | the manip of the counter is wrong | 11:20 |
| pedronis | will send a fix after lunch | 11:26 |
| Chipaca | pedronis: somebody at the sprint said that when we remove a snap we forget all connections, but it was in the middle of a bigger discussion and I didn't correct them even though I don't think that's right | 11:31 |
| Chipaca | pedronis: that wasn't you was it? | 11:31 |
| Chipaca | we so don't forget them, you can ask for connections of snaps that aren't even installed | 11:31 |
| zyga | that was me | 11:33 |
| zyga | when we remove the last revision we add one more task | 11:33 |
| Chipaca | zyga: I'm not theorising, I'm looking at it on my system | 11:34 |
| zyga | oh | 11:34 |
| zyga | so bug :) | 11:34 |
| Chipaca | zyga: is it though | 11:34 |
| Chipaca | zyga: I've heard it described as a feature | 11:34 |
| Chipaca | it does feel at least partially buggy in that connections only accumulate | 11:35 |
| Chipaca | e.g. I iterated on the connections on icdiff, and my snapd remembers all the names as separate things | 11:35 |
| Chipaca | even more interestingly, 'snap connections' lists it as connected even though the snap is removed | 11:36 |
| Chipaca | which sounds like fun :-) | 11:36 |
| zyga | uh | 11:36 |
| zyga | can you add a card please | 11:36 |
| zyga | I'll look | 11:36 |
| Chipaca | pedronis: can you comment on this behaviour, wrt whether we want it one way or another please | 11:37 |
| mup | PR snapd#6550 closed: daemon/tests: fix race in the disconnect conflict test <Simple 😃> <⚠Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6550> | 11:40 |
| pstolowski | pedronis: ^ merged | 11:40 |
| pedronis | Chipaca: we have a thing called discard-conns | 11:41 |
| pedronis | isn't it called | 11:41 |
| pedronis | ? | 11:41 |
| Chipaca | pedronis: no | 11:41 |
| Chipaca | that was an easy grep | 11:41 |
| pedronis | Chipaca: ? | 11:42 |
| Chipaca | pedronis: it's not called | 11:42 |
| Chipaca | pedronis: grep -r --include \*.go --exclude \*_test.go discard-conns | 11:42 |
| pedronis | Chipaca: it was at some point | 11:42 |
| pedronis | have we lost it? | 11:42 |
| pedronis | addHandler("discard-conns", m.doDiscardConns, m.undoDiscardConns) | 11:43 |
| pedronis | ifacestate does define it | 11:43 |
| popey | Is there some way to do a "snap why <snap>" to find out why a particular snap is installed? e.g. "snap why core18" might tell me opentoonz is why i have it installed? | 11:43 |
| Chipaca | pedronis: yes we lost it | 11:43 |
| pedronis | Chipaca: how, when? | 11:43 |
| pstolowski | pedronis: yes i think we last it when we switched to running disconnects | 11:43 |
| pstolowski | *lost | 11:44 |
| pedronis | pstolowski: but disconnect should remove conns? | 11:44 |
| pedronis | but Chipaca says conns are there | 11:44 |
| pedronis | there is bug | 11:44 |
| Chipaca | pedronis: dc290cac8b548ec7369433dda75c9cdd6d71e271 | 11:44 |
| pedronis | Chipaca: anyway, yes it's bug, we don't want to keep conns around for removed snaps | 11:45 |
| Chipaca | ok | 11:45 |
| Chipaca | we do :-) | 11:45 |
| pedronis | we are not supposed to | 11:45 |
| pedronis | would be good to find out how | 11:45 |
| pedronis | because disconnect should remove them | 11:45 |
| pedronis | at least one by one | 11:45 |
| Chipaca | popey: we don't currently track that though | 11:46 |
| pedronis | Chipaca: anyway sounds like we are missing a test somewhere | 11:46 |
| pedronis | or is more complicated | 11:46 |
| pedronis | and we don't lose them only sometimes | 11:46 |
| pstolowski | pedronis: yes we do delete(conns, cref.ID()), although its condition on auto flags etc, so maybe that's wrong | 11:46 |
| pedronis | pstolowski: ? | 11:46 |
| pstolowski | *conditional | 11:46 |
| pedronis | ah | 11:46 |
| Chipaca | ah, maybe we only don't forget manual ones | 11:46 |
| pstolowski | pedronis: in doDisconnect | 11:46 |
| pedronis | something seems off | 11:47 |
| pedronis | discard-conns removed everything | 11:47 |
| pedronis | anyway depends which auto flag | 11:47 |
| pstolowski | Chipaca: do you see undesired:true on those connections? | 11:48 |
| Chipaca | pstolowski: in the state itself? | 11:48 |
| pstolowski | Chipaca: yes | 11:49 |
| pedronis | pstolowski: the code seems right to me tough | 11:49 |
| pedronis | it always delete | 11:49 |
| Chipaca | pstolowski: "icdiff:personal-files core:personal-files":{"interface":"personal-files","plug-static":{"read":["$HOME/.gitconfig"]}} | 11:50 |
| pedronis | unless it's a autodisconnect | 11:50 |
| pedronis | it's not a auto-disconnect | 11:50 |
| pedronis | are we setting that flag wrong? | 11:50 |
| pstolowski | doAutoDisconnect: // "auto-disconnect" flag indicates it's a disconnect triggered as part of snap removal, in which case we want to skip the logic of marking auto-connections as 'undesired' and instead just remove them | 11:52 |
| pstolowski | and we set it there | 11:53 |
| pedronis | exactly | 11:53 |
| pstolowski | i looked at disconnect() as well, the flag is carried there, looks sane | 11:55 |
| pedronis | we are missing a test and/or not understanding what happens/happened on Chipaca's system | 11:56 |
| cachio | pedronis, lokking this problem | 11:56 |
| Chipaca | pedronis: pstolowski: what happens to connections on refresh? if a snap's connections change, in particular | 11:57 |
| Chipaca | I imagine there it's sane to keep them all | 11:57 |
| Chipaca | on removal, do we only look at the 'current' connections? | 11:58 |
| * Chipaca should look at the code | 11:58 | |
| * Chipaca should also try to reproduce this from scratch | 11:58 | |
| pedronis | zyga: fix https://github.com/snapcore/snapd/pull/6551 | 11:58 |
| mup | PR #6551: systemd: decrease the checker counter before unlocking otherwise we can get spurious panics <Created by pedronis> <https://github.com/snapcore/snapd/pull/6551> | 11:58 |
| Chipaca | anyway, first to go back to reviewing connections | 11:58 |
| mup | PR snapd#6551 opened: systemd: decrease the checker counter before unlocking otherwise we can get spurious panics <Created by pedronis> <https://github.com/snapcore/snapd/pull/6551> | 11:58 |
| pedronis | Chipaca: we don't keep connections per revision, so there is no current | 12:00 |
| pstolowski | Chipaca: you might be onto something with this question, doSetupProfiles/setupProfilesForSnap looks a bit suspicious and it relies - again - on reloadConnections (which was wrongly uses on core transition and i was fixing it last week) | 12:02 |
| pstolowski | pedronis: ^ | 12:02 |
| pstolowski | did we run discard-conns on refreshes before switching to new revision? | 12:03 |
| pedronis | no | 12:03 |
| pedronis | it was strictly for full removal of snaps | 12:03 |
| pedronis | only | 12:04 |
| pstolowski | ok | 12:04 |
| pstolowski | so yes, a test with refresh to a revision with less connections may give an answer | 12:06 |
| pedronis | pstolowski: but those I think fully remove the snap from repo in a refresh | 12:06 |
| pedronis | pstolowski: there's a DisconnectSnap and RemoveSnap in those | 12:08 |
| pedronis | before adding it back and reloading connections | 12:08 |
| pstolowski | pedronis: yes, but where do we update conns be in sync with repo? | 12:09 |
| pstolowski | *to be | 12:09 |
| pedronis | pstolowski: ? | 12:09 |
| pedronis | we drop everything from repo | 12:09 |
| pedronis | pstolowski: Chipaca: but there is code that would keep around connections for unknown slots/plugs | 12:11 |
| pstolowski | pedronis: yes, but don't we have the same problem we had with ubuntu-core transition? we need to keep conns in sync with repo, but reloadConnections only adds connections from conns in state, never removes | 12:11 |
| pedronis | pstolowski: we DisconnectSnap and RemoveSnap | 12:12 |
| pedronis | on repo | 12:12 |
| pedronis | that should remove everything | 12:12 |
| pedronis | then we add back | 12:12 |
| pedronis | in reloadConnections | 12:12 |
| pedronis | pstolowski: we reset the repo first or that's the intention at least | 12:13 |
| zyga | yes | 12:13 |
| pstolowski | pedronis: yes, but DisconnectSnap/RemoveSnap remove in memory only | 12:13 |
| pedronis | pstolowski: ? | 12:13 |
| zyga | pstolowski: what else would it remove? | 12:13 |
| pedronis | pstolowski: we keep the same conns | 12:13 |
| pedronis | if what you are asking | 12:13 |
| pedronis | because of the code in reloadConnections | 12:13 |
| pedronis | that ignore some errors | 12:14 |
| pedronis | but that has nothing to do with sync with repo | 12:14 |
| pedronis | repo should be a clean slate at that point | 12:14 |
| zyga | pedronis: I'm wondering if we should change things so that repo is only constructed from state on demand | 12:14 |
| zyga | pedronis: repo is very useful | 12:14 |
| zyga | pedronis: but the mental model of how to sync it is non trivial | 12:15 |
| zyga | pedronis: RepoFromState(st *state.State) (*interfaces.Repository, error) | 12:15 |
| zyga | then work on repo all you want | 12:15 |
| pedronis | maybe | 12:15 |
| zyga | and then some sort of commit/abort to change state again | 12:15 |
| pedronis | seems a bit unrelated to the problem here | 12:15 |
| zyga | yes | 12:16 |
| pstolowski | pedronis: i mean: when we refresh to a snap with less connections, we remove all connections from repo with RemoveSnap/DisconnectSnap, but they stay intact in conns. Then we re-add snap to repo and reloadConnections so we have them back in repo. back we're left with an extra connection in state (conns), no? | 12:16 |
| zyga | just thinking about the reasoning about what reload does | 12:16 |
| pstolowski | s/back/but/ | 12:16 |
| pedronis | pstolowski: they are not back in repo because you cannot connect things that don't exist | 12:16 |
| pedronis | pstolowski: what happens is this: https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/helpers.go#L311 | 12:16 |
| pedronis | which maybe is what John hit or not | 12:17 |
| pstolowski | pedronis: yes, i understand this. we're left with a stray connection in conns, that's it | 12:17 |
| pedronis | we don't have stray connections in repo | 12:17 |
| pedronis | as such | 12:17 |
| pedronis | or shouldn't | 12:17 |
| zyga | we cannot | 12:17 |
| pstolowski | it's not ending up in repo | 12:17 |
| pstolowski | yes | 12:17 |
| zyga | but AFAIK we do keep those in state | 12:18 |
| pstolowski | yes | 12:18 |
| pstolowski | that's the issue | 12:18 |
| pstolowski | and I think it explains those stray connections problem we observed long time ago (which we didn't understand), for which we added that "unknown plug/slot" logic in reload (to ignore them) | 12:18 |
| pedronis | well, there's a comment that says we don't know what to do from ago | 12:19 |
| pedronis | but yes then we added removeStaleConnections | 12:19 |
| pedronis | only on startup | 12:19 |
| pedronis | but that considers snaps | 12:19 |
| pedronis | not plug/slots | 12:20 |
| pedronis | anyway still unclear if this what John hit or something else | 12:20 |
| cachio | pedronis, I am creating a new tumbleweed image | 12:24 |
| Chipaca | I need to step out, but I just finished the review on connections, I can look at reproducing this from scratch if it'll help | 12:24 |
| Chipaca | I'm not sure what's needed, from all the above, though | 12:25 |
| cachio | pedronis, I don't know what happened with the previous one but it is not registered anymore | 12:25 |
| * Chipaca bbiab | 12:25 | |
| pedronis | cachio: fascinating | 12:26 |
| pedronis | cachio: thanks, I suppose we should a day to see if this one sticks around before turning the tests back on | 12:26 |
| pedronis | *should wait | 12:26 |
| cachio | pedronis, I see some errors related to lack of permissions in the logs | 12:27 |
| cachio | pedronis, perhaps that could be the cause | 12:28 |
| cachio | I'll continue researching | 12:28 |
| cachio | but what I see is that the image is not in out pool anymore and it was not manually deleted | 12:29 |
| pedronis | Chipaca: did you change the name of the plug at some point? | 12:32 |
| pedronis | pstolowski: is it on you queue to look at the comments by mvo on #6322 ? | 12:32 |
| mup | PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322> | 12:33 |
| mup | PR snapd#6552 opened: ifacestate/tests: fix/improve udev mon test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6552> | 12:33 |
| pstolowski | pedronis: ah, thanks, that one went under a radar a bit due to other things, i'll revisit it today | 12:34 |
| cachio | pedronis, tumbleweed image is ready again | 12:36 |
| pedronis | pstolowski: that test you fixed, the accesses were, you have channels but you the things you access could be mutated by next loop of the monitor | 12:41 |
| pedronis | while you were checking them | 12:41 |
| pedronis | *were racy | 12:41 |
| pstolowski | pedronis: i kinda had a gut feeling about that, thanks | 12:41 |
| pedronis | pstolowski: you can try go test -race , sometimes it useful | 12:42 |
| pstolowski | pedronis: will do, thanks! | 12:42 |
| pedronis | pstolowski: here on master it detects are race on remInfo for example | 12:43 |
| pstolowski | pedronis: right, i can confirm, works great! and doesn't report it anymore on my PR | 12:46 |
| pstolowski | cachio: opensuse will need to be enabled back as I disabled it in the PR that landed earlier | 12:49 |
| pstolowski | cachio: I'll prepare a PR | 12:52 |
| cachio | pstolowski, yes, thanks, I am trying to understand what happened | 12:53 |
| mup | PR snapd#6553 opened: tests: enable opensuse tumbleweed back <Created by stolowski> <https://github.com/snapcore/snapd/pull/6553> | 12:54 |
| pstolowski | cachio: ^ | 12:54 |
| pedronis | let's see how it goes, probably we shouldn't merge it until tomorrow | 12:55 |
| cachio | pstolowski, pedronis I think the problem is a bug in the google lib | 12:56 |
| Chipaca | pedronis: I did change the name of the plug, yes | 13:08 |
| pedronis | Chipaca: ok | 13:09 |
| Chipaca | pedronis: am i evil | 13:09 |
| pedronis | we need to be a bit more clever in that code | 13:09 |
| mborzecki | off to pick up the kids | 13:09 |
| mup | PR snapd#6551 closed: systemd: decrease the checker counter before unlocking otherwise we can get spurious panics <âš Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6551> | 13:10 |
| zyga | pedronis: that feels like a real bug | 13:11 |
| zyga | pedronis: I was thinking we should do a .5 | 13:12 |
| pedronis | zyga: I poked mvo about that | 13:12 |
| zyga | and keep the 2.37 branch around as an LTS, with regular security updates and serious bug fixes | 13:12 |
| pedronis | ? | 13:12 |
| zyga | it's the idea I was talking to mvo about a few times already | 13:12 |
| zyga | we move too fast and too slow | 13:13 |
| zyga | we should not release to the world on day one of 2.38 | 13:13 |
| zyga | server should stay behind on 2.37 until we had a few cycles of 2.38 desktop feedback | 13:13 |
| pedronis | we cannot do that without tracks | 13:13 |
| pedronis | anyway it's probably not a discussion to have this week | 13:14 |
| zyga | yeah, we'd have to do something to change how we release | 13:14 |
| zyga | but I think it's a good candidate for a starting point | 13:14 |
| pedronis | given that mvo is not really around | 13:14 |
| pedronis | also not sure that bug is good candidate for that logic, is probably not very likely to hit in the field | 13:15 |
| pedronis | often | 13:15 |
| Chipaca | zyga: pedronis: listen to the wind! ☆cﾟa.n*a･r｡iﾟe.sﾟ | 13:15 |
| zyga | it's not that bug | 13:15 |
| zyga | is the polishing effort that goes into 2.37 | 13:15 |
| pedronis | Chipaca: anyway if the plug was renamed, is not a regression, we had this kind of behavior since a long time | 13:17 |
| pedronis | probably day 0 of the stuff | 13:17 |
| Chipaca | pedronis: a zero-day bug! /o\ | 13:19 |
| * Chipaca promotes headless chickens | 13:19 | |
| pedronis | zyga: I'm not particularly against or pro, I'm not sure an LTS as usual fits, also notice that the biggest non security issue with 2.37 was on servers | 13:19 |
| pedronis | it was on people CI pipelines | 13:19 |
| === ricab is now known as ricab|lunch | ||
| zyga | we will never prevent all regressions but think we should consider this move as it may fix our credibility on stability where people really seriously depend on snaps for day-to-day work | 13:20 |
| zyga | we could also use lts on ubuntu lts desktops | 13:21 |
| zyga | and use non-lts on devel releases | 13:21 |
| zyga | but those are just ideas, I'd like to raise it as a topic next week when we are back in full set | 13:21 |
| pedronis | at some point we will just reduce the pool of testing to the point where we will hit the same issues but later | 13:21 |
| Chipaca | zyga: seriously, canarying is for this, or am I missing the point | 13:22 |
| pedronis | if anything our issue is that people don't use beta/candidate enough | 13:22 |
| zyga | Chipaca: how would canarying prevent what we saw during 2.37? | 13:22 |
| Chipaca | zyga: depends on what you mean by "what you saw" | 13:23 |
| zyga | Chipaca: the point is simple, now we release almost synchronously all around the planet | 13:23 |
| Chipaca | "what we saw" i mean | 13:23 |
| pedronis | we try not to really | 13:23 |
| zyga | Chipaca: I'd like to change that because we cannot maintain quality for production workloads | 13:23 |
| Chipaca | zyga: and how is that _not_ canarying? | 13:23 |
| zyga | Chipaca: perhaps I misunderstand but canarying is not a separate release schedule | 13:24 |
| zyga | it's just a pool of machines that say yes or no automatically | 13:24 |
| zyga | that's not the same in my eyes | 13:24 |
| pedronis | anyway it's super unclear that the people that hit our bugs would have not run lts | 13:24 |
| Chipaca | zyga: canarying is where, say, 1% of the installed base gets a new revision | 13:24 |
| pedronis | and then back to square one | 13:24 |
| Chipaca | zyga: if nothing breaks, 5%, 10, … etc | 13:25 |
| zyga | Chipaca: breaking 1% of server people IMO too much; I also don't trust in the automated aspect and holding that back; it feels like a good additional system but not a replacement for what LTSes are | 13:25 |
| Chipaca | zyga: if something breaks, you rollback | 13:25 |
| zyga | Chipaca: I don't disagree on that, just that the set of times you have to roll back burns our credibility and we should avoid that | 13:26 |
| zyga | Chipaca: we should do better in all the ways we can, including in how we release | 13:26 |
| zyga | anyway | 13:26 |
| zyga | I think we should discuss next week | 13:26 |
| zyga | just wanted to explain my point of view over canarying | 13:26 |
| pedronis | zyga: as I said, no strong opinion right now, I just have the impression that this will just delay when we see the bugs | 13:27 |
| pedronis | and that's it | 13:27 |
| * pstolowski off to the doctor | 13:32 | |
| * zyga breaks and goes for a late walk | 13:33 | |
| zyga | I'll skip standup today: my update is short, started late after rough night, releasing .4 everywhere; | 13:34 |
| zyga | one unusual aspect is that I filed bugs to help include snapd in opensuse | 13:34 |
| zyga | that's all | 13:34 |
| pedronis | zyga: thx for the update | 13:41 |
| mborzecki | re | 13:45 |
| Son_Goku | zyga: erk: https://koji.fedoraproject.org/koji/buildinfo?buildID=1217519 | 13:52 |
| Son_Goku | did you accidentally chop the changelog entry up? | 13:52 |
| Son_Goku | Michael's name is missing from the changelog entry and it looks like it was squished with the 2.37.4 release entry | 13:53 |
| zyga | There was no changelog entry this time | 13:53 |
| Son_Goku | I see one here? https://github.com/snapcore/snapd/commit/af063cbb045a1e232bfb5131683657f78b0cd7ad | 13:53 |
| Son_Goku | err. https://github.com/snapcore/snapd/commit/af063cbb045a1e232bfb5131683657f78b0cd7ad#diff-29bff6a81f0669dfd7375cb5e5f13a89 | 13:54 |
| zyga | Oh? When I looked I saw TBD | 13:54 |
| zyga | maybe stale view | 13:54 |
| zyga | I took entries from the release page | 13:54 |
| Son_Goku | Michael puts them in as part of the tag-release commit | 13:55 |
| Son_Goku | so they're usually there | 13:55 |
| zyga | I am afk but when I looked at the Fedora spec it had a placeholder only | 13:56 |
| * Son_Goku shrugs | 13:56 | |
| Son_Goku | I'll fix it in dist-git | 13:56 |
| Son_Goku | no worries | 13:56 |
| zyga | Thanks! | 13:57 |
| Son_Goku | zyga, thanks for doing the update stuff anyway :) | 14:00 |
| pedronis | Chipaca: pstolowski: standup? | 14:01 |
| Chipaca | yep, omw | 14:01 |
| zyga | My pleasure :-) | 14:01 |
| Son_Goku | zyga, new snapd packages are building | 14:07 |
| Chipaca | mborzecki: https://www.youtube.com/watch?v=OZpgnYhzdkI | 14:07 |
| Son_Goku | when you get a moment, go ahead and file them as updates after they've been built | 14:08 |
| zyga | Yep | 14:08 |
| zyga | I’m heading home slowly | 14:09 |
| zyga | Hashtag baby hashtag walk | 14:09 |
| cwayne | Hashtag babywalk? | 14:09 |
| Chipaca | popey: where can I find an Evan these days? (I know not IRC) | 14:19 |
| * cachio afk 15 mins | 14:20 | |
| cory_fu | sergiusens: Do you have a moment to assist with a snap build issue I'm having? | 14:32 |
| === ricab|lunch is now known as ricab | ||
| pstolowski | re | 14:53 |
| pstolowski | pedronis: sorry, i had an eye check today, i mentioned that yesterday during standup | 15:14 |
| Chipaca | pstolowski: and via the forum | 15:17 |
| zyga | re | 15:17 |
| zyga | jdstrand: hello | 15:18 |
| zyga | jdstrand: could you please look at a suggestion we got from the suse security team: https://bugzilla.opensuse.org/show_bug.cgi?id=1127366#c3 | 15:19 |
| sergiusens | cory_fu: what version? Also /join #snapcraft instead | 15:19 |
| zyga | the idea is to make snap confine ownership: snap-confine 6750 root:snapd | 15:19 |
| zyga | this way you can use snaps if you are a member of the group snapd | 15:19 |
| zyga | though I worry about setgid aspect of snap-confine (group root) | 15:20 |
| zyga | doing this would speed up entry to suse | 15:20 |
| zyga | Pharaoh_Atem: did you run another round of builds | 15:23 |
| zyga | Pharaoh_Atem: or shall I before I send stuff to bodhi? | 15:23 |
| zyga | pedronis: CC on the message to jdstrand | 15:24 |
| jdstrand | zyga: I'm not opposed to the idea, though it may complicate the priv-dropping code in snap-confine somewhat. it will definitely cause usability issues on suse since only people in the snapd group would be able to use snaps | 15:27 |
| jdstrand | pedronis: ^ | 15:27 |
| zyga | jdstrand: right | 15:27 |
| zyga | jdstrand: I understand the plan is to use this to simplify the review | 15:27 |
| zyga | jdstrand: and ship snapd in kubic OS by suse | 15:28 |
| zyga | jdstrand: where the users will have the permission by default | 15:28 |
| zyga | jdstrand: can you explain how it would complicate the priv dropping code? | 15:28 |
| pedronis | jdstrand: don't we have also issues with reexec and the fact that we have one core | 15:29 |
| pedronis | respectevely snapd snap | 15:29 |
| jdstrand | zyga: it would have to be reviewed-- it may not, but it may. I recall we very precisely drop uid and gid | 15:29 |
| zyga | yeah | 15:29 |
| jdstrand | s/drop/drop, raise, drop/ | 15:30 |
| zyga | I can attempt that to see what happens (just chmod/chown it on my system) | 15:30 |
| zyga | I suspect we may need a patch on snap-run | 15:30 |
| zyga | to say "please add the users to snapd group" or something alike | 15:30 |
| zyga | and some changes to snap-confine (there are probably three places that manipulate uid thre) | 15:30 |
| zyga | *there | 15:30 |
| pedronis | jdstrand: my question how can we have snap-confine have different perms on different distros while keeping one core snap | 15:31 |
| zyga | pedronis: I think we are not using snap-confine from core/snapd on suse / fedora | 15:32 |
| zyga | so perhaps in those places as a special case? | 15:32 |
| jdstrand | pedronis: it wouldn't work in the reexec case | 15:43 |
| pedronis | jdstrand: but then it means people can circumvent that check by turning reexec on | 15:44 |
| jdstrand | I mean, it could theoretically work if you get the same gid for snapd in all the distros and your distro packaging adds the group with that gid and the snap also uses that gid, but yikes, hard to coordinate | 15:45 |
| jdstrand | pe | 15:45 |
| jdstrand | pedronis: yes | 15:45 |
| pedronis | we would need to hardwire somehow no reexec | 15:45 |
| zyga | I think kubic would not allow reexec, | 15:45 |
| zyga | pedronis: we do that today | 15:45 |
| zyga | there's no reexec on suse | 15:45 |
| jdstrand | zyga: but a user could set the env var, certainly | 15:46 |
| pedronis | I thought we always respected the env var | 15:46 |
| zyga | jdstrand: it is ignored on suse | 15:46 |
| zyga | I ... don't know | 15:46 |
| pedronis | heh | 15:46 |
| zyga | worth checking :) | 15:46 |
| zyga | but I think it does nothing | 15:46 |
| zyga | because it doesn't function | 15:46 |
| jdstrand | interesting | 15:46 |
| zyga | things just don't work in many ways still | 15:46 |
| zyga | different paths etc | 15:46 |
| zyga | I'd love to be able to turn it on | 15:46 |
| zyga | have a default that distros agree with | 15:46 |
| zyga | but a knob the user can toggle | 15:46 |
| zyga | it's just that we're not there yet | 15:47 |
| pedronis | but we they ask for this | 15:47 |
| pedronis | we cannot turn it on | 15:47 |
| pedronis | the two things feels a bit incompatible | 15:47 |
| jdstrand | snapd could disable reexec if the sgid bit was set on snap-confile | 15:47 |
| zyga | I agree | 15:47 |
| jdstrand | snap-confine | 15:47 |
| zyga | jdstrand: I would have it as a first class concept: no reexec mode set at build time | 15:47 |
| zyga | then there's simpler way to control this | 15:47 |
| zyga | it's just off | 15:47 |
| zyga | though for now I think that's premature, we should just check what happens with the different group and see if we'd be happy with that mode during review (and land any extra changes before this goes in) | 15:48 |
| zyga | Pharaoh_Atem: updates posted to bodhi :) | 16:42 |
| zyga | you have to tell me one day how to do sets so that all the three updates can be in one big set | 16:43 |
| === pstolowski is now known as pstolowski|afk | ||
| Pharaoh_Atem | zyga: it's not a thing sadly | 17:37 |
| Pharaoh_Atem | when we moved from Bodhi 1.0 to Bodhi 2.0, the ability to push a single update across multiple distributions went away | 17:37 |
| Pharaoh_Atem | or are you referring to a set of packages per update? | 17:37 |
| zyga | Pharaoh_Atem: ah, I confused that | 17:41 |
| zyga | I thought it was a thing | 17:41 |
| zyga | but that's okay | 17:41 |
| Pharaoh_Atem | anyway, I gave karma to everything | 17:41 |
| mup | PR snapcraft#2491 opened: Fix and enable multipass spread tests <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2491> | 17:41 |
| Pharaoh_Atem | so it'll push out in the next 48 hours | 17:41 |
| zyga | Pharaoh_Atem: thank you | 17:46 |
| zyga | Pharaoh_Atem: say, what about manjaro | 17:46 |
| zyga | should we do something there? | 17:47 |
| Pharaoh_Atem | hm? | 17:47 |
| zyga | is snapd in manjaro? | 17:47 |
| Pharaoh_Atem | I believe so | 17:48 |
| zyga | do you have any contacts there? | 17:48 |
| zyga | someone we could talk to in case we need to release urgently? | 17:48 |
| Pharaoh_Atem | nope | 17:49 |
| Pharaoh_Atem | I don't know anyone in Manjaro anymore | 17:49 |
| zyga | ok, thank you | 17:49 |
| zyga | we're doing our best where we can | 17:49 |
| zyga | I will work on suse concept for some more time and then EOD | 17:49 |
| Pharaoh_Atem | if it works out with the reworked packaging for SUSE, we can look at integrating those changes into the Fedora packaging and tweaking it to build for SUSE distributions too | 17:50 |
| zyga | Pharaoh_Atem: I already started :) | 18:03 |
| zyga | Pharaoh_Atem: I need to finish selinux support in snapd.k | 18:03 |
| zyga | .mk | 18:03 |
| zyga | it's not a priority for me this week but I expect to switch more and more packaging over to it | 18:03 |
| Pharaoh_Atem | be careful, though | 18:03 |
| Pharaoh_Atem | I still need to be able to build it everywhere | 18:04 |
| zyga | it has not lost any features | 18:04 |
| zyga | it should really be just less repetition without any other effects | 18:04 |
| Pharaoh_Atem | and having a way to ensure things like the golang build flags are passed in are important | 18:04 |
| zyga | yep, that's part of why this is not ready yet | 18:04 |
| zyga | I'm just saying it's important for me to get this done to simplify packaging work | 18:04 |
| Pharaoh_Atem | sure | 18:05 |
| Pharaoh_Atem | I'd like it to be simpler too | 18:05 |
| Pharaoh_Atem | it's a big part of why I hate Go so much :/ | 18:05 |
| * zyga EODs | 19:06 | |
| mwhudson | pedronis: thanks for the answers about the fake store | 20:04 |
| mwhudson | hm | 21:41 |
| mwhudson | snap seeding appears to be completely hung in this image | 21:41 |
| mwhudson | i've probably broken something but how can i diagnose? | 21:41 |
| zyga | mwhudson: set SNAPD_DEBUG=1 in snapd.service override, hack the image to have serial tty, | 21:44 |
| mwhudson | i have a tty | 21:44 |
| mwhudson | and i think that env var is set | 21:44 |
| mwhudson | yeah it is | 21:44 |
| mwhudson | it is complaining about not being able to find a snap-declaration | 21:45 |
| mwhudson | ah whoops killed vm by mistake | 21:45 |
| zyga | well, good luck :) | 21:49 |
| tylerscheuble | Hey, I'm trying to build a snap with a custom plugin, and I'm getting a "/bin/sh: 29: snapcraftctl: not found" on the pulling step. snapcraftctl isn't in the source of any of my files. | 21:50 |
| tylerscheuble | Any ideas? Thanks | 21:50 |
| mwhudson | ah the fakestore can make a declaration too | 21:51 |
| mwhudson | omg it lives | 22:06 |
| RalphBa | hi all | 22:10 |
| RalphBa | short question, is there an equivalent to flatpak's --user? | 22:10 |
| RalphBa | for unpriviliged and formost userlocal installations | 22:10 |
| RalphBa | so installed into their home, system state stays unalterd | 22:11 |
| mwhudson | now just the api/v1/snaps/auth/nonces thing | 22:11 |
| roadmr | RalphBa: no :) (short answer) | 22:11 |
| RalphBa | ok, and how is an app behaving when used by 2 users? | 22:12 |
| RalphBa | say two users use nextcloud snap | 22:18 |
| RalphBa | nextcloud-client | 22:19 |
| kyrofa | RalphBa, no differently than the deb installed once and used by both users. Settings are stored in a user-specific area | 22:23 |
| RalphBa | kyrofa: so all the data downloaded from nextcloud server is stored somewhere in /home/user directory? Where? | 22:24 |
| kyrofa | RalphBa, you said nextcloud-client, perhaps we're misunderstanding each other | 22:24 |
| RalphBa | the snap nextcloud-client available in store | 22:25 |
| RalphBa | I can access its data via the current directory | 22:25 |
| kyrofa | But yes-- the nextcloud client syncs stuff from client to server, and its settings are stored per-user. Where the stuff it syncs is located shouldn't really matter | 22:25 |
| RalphBa | but where is it stored?`and why is it available via /snap | 22:25 |
| RalphBa | it matters because I have multiple paritions for multiple stuff | 22:26 |
| RalphBa | I have a backup concept | 22:26 |
| RalphBa | I need to know where stuff is | 22:26 |
| kyrofa | RalphBa, what I mean to say is: where stuff syncs is up to the user(s). It has no bearing on whether or not multiple users can use it | 22:27 |
| RalphBa | default setting of that snap is to store data in some shady mount thing | 22:27 |
| RalphBa | how said, I access that data via /snap/.../current | 22:27 |
| kyrofa | The snap itself is installed into /snap like any other snap. That's not a shady mount thing, it's a squashfs image. That's what a snap is | 22:27 |
| kyrofa | It doesn't store anything there though. It's read-only | 22:28 |
| kyrofa | It just executes from there | 22:28 |
| RalphBa | Nextcloud downloadded 3 GB, the squashfs image had 87MB | 22:28 |
| kyrofa | Just like, if it was a deb, it'd probably be in /usr/bin/ | 22:28 |
| RalphBa | hm... | 22:29 |
| RalphBa | this was the path ~/snap/nextcloud-client/current/Nextcloud o /snap/nextcloud-client/current/Nextcloud | 22:29 |
| RalphBa | and also /... | 22:29 |
| RalphBa | the symlink pointed to snap/nextcloud-client/10 | 22:30 |
| RalphBa | which was the mountpoint of that .snap file | 22:30 |
| kyrofa | /snap/nextcloud-client/* is the snap installation path. ~/snap/nextcloud-client/current/ is the user-specific path where it might store user-specific settings (and yes, it can sync there as well, although I don't recommend it) | 22:30 |
| RalphBa | ok, but where is that user specific stuff? | 22:31 |
| RalphBa | if I want to put that file on a tape, where to find it? | 22:31 |
| kyrofa | Uh. Which file? | 22:31 |
| RalphBa | "user-specific path where it might store user-specific settings" << the file or the files in there | 22:32 |
| RalphBa | in the current directory | 22:32 |
| RalphBa | ok, where is a good technical documentation? | 22:33 |
| kyrofa | Anything in ~/snap/nextcloud-client/current/ falls under that category... I'm not quite sure what you're looking for | 22:33 |
| RalphBa | ~/snap/nextcloud-client/current/ is just a symlink to a mount point | 22:33 |
| kyrofa | No, it's a symlink to a directory | 22:34 |
| kyrofa | /snap/nextcloud-client/current IS a symlink to a mountpoint though | 22:34 |
| kyrofa | The one in $HOME is different | 22:34 |
| RalphBa | hm | 22:34 |
| RalphBa | oh | 22:36 |
| RalphBa | ok, got it | 22:36 |
| RalphBa | that was the point, I thought ~/snap/.../10 is a mount point | 22:37 |
| RalphBa | seems not to be the case | 22:37 |
| kyrofa | Indeed not, perhaps that explains both of our confusion :) | 22:38 |
| RalphBa | :-D thanks for that one | 22:39 |
| RalphBa | just one to come, can I move /snap to /data/snap and symlink it? | 22:39 |
| kyrofa | Snaps have a few defined places where they can always write-- that's one of them (SNAP_USER_DATA). This might enlighten you further: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data/762405#762405 | 22:39 |
| kyrofa | I doubt it, snapd will want to be able to update it etc. | 22:40 |
| RalphBa | hmmm... I really would like to get the installed stuff out of the base system | 22:40 |
| RalphBa | deb for system stuff, snap and flatpak for application stuff | 22:40 |
| RalphBa | might it tolerate /snap beeing an own mount point? | 22:41 |
| kyrofa | RalphBa, I'm afraid I don't know, that's a question for the snapd devs, who are all probably gone for the day. I suggest coming back earlier tomorrow to ask | 22:43 |
| mwhudson | hmm so now when i try to refresh from the fake store i get a complaint about mismatched revisions | 22:46 |
| mwhudson | the assertion says rev 2 but somehow the snap has revision 1? | 22:47 |
| mwhudson | but i don't understand how a snap has a revision that is different from what the assertion says... | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!