| === Ringtailed_Fox is now known as RingtailedFox | ||
| === stgraber is now known as stgraber_ | ||
| === stgraber_ is now known as stgraber | ||
| mborzecki | morning | 05:45 |
|---|---|---|
| mborzecki | mardy: hey | 05:48 |
| mardy | mborzecki: hi! | 06:30 |
| mardy | this is not as helpful as I hoped it would be: https://www.dumels.com/diagram/68044f98-992d-43bc-a0f3-03f0f808681e :-D | 06:30 |
| mborzecki | mardy: hmm firefox does not like this page very much | 06:47 |
| pstolowski | morning | 07:04 |
| zyga | goood morning | 07:04 |
| mborzecki | pstolowski: zyga: hey | 07:08 |
| mborzecki | pstolowski: i've updated https://github.com/snapcore/snapd/pull/10301/ | 07:08 |
| pstolowski | looking | 07:10 |
| pedronis | mborzecki: pstolowski: thanks for the review, https://github.com/snapcore/snapd/pull/10305 needs a 2nd review | 07:41 |
| mborzecki | will do | 07:42 |
| pedronis | mborzecki: https://github.com/snapcore/snapd/pull/9932 doesn't have two +1 | 07:44 |
| pedronis | ah, it does, but I think Ian asked mvo to re-review it | 07:45 |
| jamesh | mup on freenode seems really unhappy. It tries to join #snappy, finds itself in ##snappy, leaves and tries again | 07:46 |
| pedronis | jamesh: only Gustavo has control on that | 07:46 |
| pedronis | mborzecki: I dismissed mvo original review for clarity | 07:47 |
| pedronis | sorry, that one needs to wait a bit more | 07:48 |
| mborzecki | we're down to 80 PRs | 08:20 |
| ogra | is that a suggestion that more should be created ? 🙂 | 08:21 |
| === pedronis_ is now known as pedronis | ||
| pedronis | pstolowski: any reason not to merge https://github.com/snapcore/snapd/pull/9669 ? it got some stuck tests but I reopened it just now | 08:25 |
| pstolowski | pedronis: none, let's land, thanks | 08:26 |
| mardy | pedronis: Hi! I don't know if you saw the discussion yesterday, but there was the question whether plugs specifying an attribute should also be autoconnected: | 08:48 |
| mardy | kubernetes-support microk8s:k8s-journald - - | 08:48 |
| mardy | kubernetes-support microk8s:k8s-kubelet - - | 08:48 |
| mardy | kubernetes-support microk8s:k8s-kubeproxy - - | 08:48 |
| mardy | kubernetes-support microk8s:kubernetes-support :kubernetes-support - | 08:48 |
| mardy | pedronis: in other words, the above situation, is it a bug, or the expected behaviour? | 08:48 |
| pedronis | mardy: I answered, it's expected | 08:48 |
| mardy | pedronis: ah, then I missed it | 08:49 |
| pedronis | unless they don't want this, in which case the snap-declaration needs changes | 08:49 |
| mardy | pedronis: I'll check with them | 08:49 |
| mborzecki | pstolowski: https://github.com/snapcore/snapd/pull/10299 is has 3 +1 ;) | 09:00 |
| pstolowski | mborzecki: yeah but not green yet.. and i think i'll change it to noticef | 09:02 |
| mborzecki | duh, we need another patch update for sid | 09:03 |
| pedronis | pstolowski: I commented on https://github.com/snapcore/snapd/pull/10299 | 09:07 |
| mborzecki | pstolowski: mardy: can you take a look at https://github.com/snapcore/snapd/pull/10312 ? | 09:08 |
| mborzecki | i'm thinking we should skip debian 10 in the many interfaces remove test | 09:10 |
| === zyga is now known as zyga-mbp | ||
| mardy | mborzecki: sure | 09:11 |
| mardy | mborzecki: appoved with a nitpicky remark :-) | 09:13 |
| mborzecki | thx | 09:14 |
| mardy | pedronis: the fact that you cannot give more than one plug to "snap connect ...", is it a design decision, or because of some technical limitation? | 09:15 |
| pedronis | mardy: I suspect mostly that the CLI gets unwieldy in the general case, but the API also doesn't support more than one connection at a time ATM | 09:17 |
| pedronis | as well | 09:17 |
| pstolowski | ok, i think we have an issue with downloads (but probably unrelated to refresh getting stuck), and it's kinda made worse by introduction of download-speed measurement | 09:20 |
| pstolowski | deltas are downloaded using same downloadImpl, and if we fail on delta because of download-too-slow error, we fallback to regular download which is pointless in this case | 09:21 |
| pstolowski | is there a reason for a fallback at all if delta download failed? | 09:23 |
| pedronis | pstolowski: delta can also fail applying, in that case it makes sense to fallback to full download | 09:33 |
| pedronis | but maybe we are talking different levels here | 09:33 |
| pstolowski | pedronis: no, you're right, but we don't differentiate, maybe we should (err from downloadAndApplyDelta) | 09:35 |
| pedronis | pstolowski: what's the issue anyway? you said it's pointless , that doesn't sound a bug to me, also always unclear what is pointless or not | 09:36 |
| pstolowski | pedronis: on a sketchy network it can only get worse if we retry fail due to network error when downloading a delta and fallback to full download | 09:36 |
| pstolowski | d/retry/ | 09:37 |
| pedronis | pstolowski: do we know it's a sketchy network? | 09:37 |
| mardy | if someone here has permissions to change labels on the forum posts, I think that the label on https://forum.snapcraft.io/t/connect-multiple-interfaces-in-a-single-command/24493 should be changed to "snapd" | 09:37 |
| pedronis | mardy: I can but in a little bit | 09:38 |
| mardy | no hurry | 09:39 |
| pstolowski | pedronis: i don't know about the reported issues; but while trying to reproduce it in a VM with network shaping I hit this case (cannot download or apply deltas: network too slow..) | 09:40 |
| pstolowski | so we downloaded quite a bit of xdelta file and then gave up on it and switched to full download when network was too slow | 09:41 |
| pedronis | pstolowski: sorry if I'm a bit resistent but you asking to add even more code there, so unless there's a clear win or we really take the time to rework the whole thing, I'm a bit reluctant, especially because it doesn't seem related to the stuck case | 09:41 |
| pstolowski | yeah i know the issue pre-dates the introduction of download-speed-error | 09:42 |
| pedronis | we are being wasteful, but in the end that download will probably fail either way | 09:44 |
| pstolowski | yes but i'm also wondering if 'getting stuck' is real or just a perception with big download and slow network which would be made worse by the above; otoh one week in auto-refresh is a lot and would result in 'download too slow errors', and we didn't see those | 09:49 |
| pedronis | pstolowski: having a way to inspect the internal state of the download still seems the best approach to try to understand something here | 09:53 |
| pedronis | mardy: I changed it | 09:54 |
| === zyga_ is now known as zyga | ||
| pedronis | mborzecki: I merged the PR you asked me to merge | 10:01 |
| mborzecki | pedronis: thank you! | 10:03 |
| pedronis | mborzecki: is apparmor_parser -j0 something new, I don't see it in the man page here | 10:06 |
| mborzecki | pedronis: on 18.04? | 10:07 |
| pedronis | 20.04 | 10:07 |
| pedronis | mborzecki: I commented in the PR | 10:11 |
| mborzecki | hmm hmm, the change was introduces 3 years ago | 10:13 |
| mborzecki | ehh https://gitlab.com/apparmor/apparmor/-/commit/48a32b78b189cf9e2c4d8bce8fb45c68bf4cc327 only apparmor 3 apparently | 10:14 |
| pedronis | mborzecki: what does it do on older apparmor 1 or auto though? I mean the spread tests aren't failing | 10:15 |
| pedronis | mborzecki: it might more conservative to do -j1 on 1 cpu? | 10:16 |
| pedronis | or check apparmor version? | 10:16 |
| mborzecki | pedronis: looks like we should be using -j1 to have it work on older versions too | 10:17 |
| pedronis | mborzecki: yea | 10:17 |
| mborzecki | pedronis: and -j0 would just trigger the default behavior as if there's no -j at all | 10:17 |
| mborzecki | so like -jauto | 10:18 |
| mborzecki | there's a JOBS_AUTO which was 0 before, but is UINT_MIN in 3.0+ | 10:18 |
| pstolowski | var/lib/snapd/snaps/partial doesn't appear to be used anymore? can we drop it from debian/snapd.dirs? | 10:19 |
| woutervb | ccccccibbcgvvdubhjibifgfierdffjkdgllkgntilte | 10:45 |
| ogra | meow ? | 10:48 |
| mborzecki | pedronis: this probably needs a pass from you https://github.com/snapcore/snapd/pull/9897 otherwise it looks good to land (with unrelated test failures) | 11:02 |
| mborzecki | also maybe worthy of cherry pick to 2.50 too | 11:02 |
| mborzecki | added a milestone | 11:03 |
| pedronis | probaly not something to add in .x release | 11:03 |
| pedronis | I'll look at it in the afternoon, thx for the heads up | 11:04 |
| pstolowski | pedronis: i've been looking at out http client setup, timeout and use of DialContext and i'm not sure our setup is sound due to use of context.TODO() | 11:05 |
| pedronis | pstolowski: as it doesn't respect the timeout? can you write a failing test? | 11:09 |
| pstolowski | looking at DialContext implementation in https://golang.org/src/net/dial.go, afaict it may need a real context (even though DialContext.Timeout is set) for timeout to work on dial | 11:09 |
| pstolowski | pedronis: yes that's a good idea | 11:12 |
| mborzecki | funny debian 10 is actually sucessful in some of the spread runs | 11:13 |
| cachio | mborzecki, hi, about the failing test tests/main/interfaces-x11-unix-socket on tumbleweed | 11:42 |
| cachio | mborzecki, should we skip it? | 11:42 |
| cachio | mborzecki, it is failing to create the socket for x11 currently | 11:43 |
| mborzecki | cachio: it's a known problem i will get around to fixing that sometime | 11:53 |
| pstolowski | pedronis: can https://github.com/snapcore/snapd/pull/10297 land? | 11:54 |
| mborzecki | cachio: but no, we should not skip the test as it's useful there too | 11:54 |
| cachio | mborzecki, ok | 11:54 |
| cachio | thanks | 11:54 |
| pedronis | pstolowski: sorry, I wasn't clear, the command should also match the endpoint, no? | 11:56 |
| pstolowski | pedronis: ah, ok | 11:56 |
| pedronis | mborzecki: maybe 10295 can be evens impler ? | 12:01 |
| pedronis | simpler | 12:01 |
| mborzecki | heh, right, pushed now | 12:04 |
| mborzecki | i'll land https://github.com/snapcore/snapd/pull/10312 with 1 review since it's so trivial, unless someone else wants to take a look? | 12:06 |
| pedronis | mborzecki: I don't understand mardy comment | 12:08 |
| mardy | pedronis: it's about the text in the patch: "Upstream snapd uses an elaborate hack to bundle squashfuse under the | 12:12 |
| mardy | name snapfuse, and built as a fake go package. | 12:12 |
| mardy | " | 12:12 |
| mardy | it doesn't seem to be relevant anymore | 12:13 |
| pedronis | pstolowski: I pushed a nitpick to that PR, sorry | 12:13 |
| * rzr is watching https://libregraphicsmeeting.org/2021/en/live.html , uc to be shown tomorrow (pincab) | 12:14 | |
| pstolowski | pedronis: that's fine, but we have lowercase elsewhere (debug model, seeding, validate seed..) | 12:16 |
| pedronis | pstolowski: those are hidden though | 12:16 |
| pedronis | pstolowski: look at snap help debug | 12:16 |
| pedronis | pstolowski: they start with (internal) | 12:17 |
| pstolowski | pedronis: ah indeed, ok | 12:17 |
| pedronis | pstolowski: btw related to this "snap debug state" short help has a final "." which shouldn't be there | 12:18 |
| pedronis | you can see it also in "snap help debug" | 12:19 |
| mardy | when a program inside a snap executes another app from the same snap (having different plugs), the second app will be executed under its own confinement, right? | 12:20 |
| pedronis | mardy: not really | 12:22 |
| pedronis | mardy: the confinement is from outside invocations and for services | 12:22 |
| pedronis | mardy: internal snap calls are usually in the confinement on the caller, because as snap can't call a snap app as from outside, normally | 12:23 |
| pedronis | *of the caller, because a snap can't call a snap app... | 12:23 |
| pedronis | mborzecki: it's your call whether to do something about the commit or not | 12:28 |
| mborzecki | landed it as i'm in favor of unbreaking sid and now we can bikeshed about the commit message all we want :) | 12:30 |
| mardy | pedronis: interesting, thanks. | 12:31 |
| mborzecki | hm still surprising how debian 10 is passing sometimes | 12:31 |
| mborzecki | maybe something changed in the image again | 12:31 |
| mardy | mborzecki: now everytime that I'll see a failure on Debian I'll blame it on that commit message ;-) | 12:32 |
| mborzecki | pedronis: any further thoughs on https://github.com/snapcore/snapd/pull/10082 ? | 12:32 |
| mborzecki | (and we're down to 76 PRs) | 12:32 |
| mardy | pedronis: also if you let me know which one between https://github.com/snapcore/snapd/pull/10292 and https://github.com/snapcore/snapd/pull/10282 you like more (or dislike less), then I can close the other one | 12:34 |
| pedronis | mardy: yes, likely tomorrow though, not today | 12:35 |
| mardy | pedronis: OK | 12:35 |
| pedronis | mborzecki: I suppose I should try it again locally | 12:36 |
| mardy | about the previous question, is there any way for a snap to execute one of its apps under the proper confinement for that app? The use case is that the microk8s snap offers a microk8s shell wrapper to execute the various tools, and if there isn't a way to execute them under their own confinment this wrapper will end up having pretty much all permissions of the universe :-) | 12:37 |
| pedronis | mardy: not without some specific support that we don't have yet | 12:38 |
| mardy | snapctl run ...? :-) | 12:38 |
| pedronis | mborzecki: I put 10082 back into my queue | 12:38 |
| mborzecki | thanks | 12:38 |
| pedronis | mardy: I put those two alternative PRs into my queue now at least | 12:40 |
| mardy | pedronis: thanks | 12:40 |
| pedronis | pstolowski: could you merge master into https://github.com/snapcore/snapd/pull/9669 ? | 12:42 |
| pedronis | I hoped it would mostly pass but the errors are obscure so it would need another anyway | 12:42 |
| pstolowski | sure, doing | 12:42 |
| pedronis | thx | 12:43 |
| mborzecki | cachio: i've added some comments in https://github.com/snapcore/snapd/pull/10162 | 13:44 |
| cachio | mborzecki, thanks | 13:44 |
| mardy | mborzecki: what is the trick you mentioned in the chat about unpacking the snap? | 13:47 |
| mborzecki | mardy: if you only want to chage a shell script or something similar in the snap, you can `unsquashfs -d <some-dir> <file>.snap`, do the necessary edits, and then `snap pack <somedir>` | 13:53 |
| mborzecki | you can do that for anything that does not require recompilation of the source code | 13:54 |
| mardy | mborzecki: thanks, this is super helpful :-) | 13:57 |
| ijohnson | pedronis: we can chat during our meeting, but I only see #9932 and #9292 as marked for 2.51, nobody particularly has asked for 9932, so I think we can push that out to 2.52 and then it's just up to you if you want 9292 for 2.51 | 14:19 |
| pedronis | ijohnson: we have also some things still marked 2.50 | 14:19 |
| ijohnson | oh huh, let me take a look at triaging those | 14:20 |
| === Ringtailed_Fox is now known as Ringtailedfox | ||
| === Ringtailedfox is now known as RingtailedFox | ||
| ijohnson | pedronis: also I have cherry-pick permission so I am going to cherry pick some of the things milestoned for 2.51 that have landed recently like #10297 just FYI | 14:20 |
| pedronis | ijohnson: cherry pick to 2.50 ? | 14:21 |
| pedronis | anyway let's chat in a bit | 14:22 |
| ijohnson | pedronis: oh right we haven't branched | 14:22 |
| ijohnson | nvm me yeah I will hold off on doing anything until our meeting | 14:22 |
| ijohnson | pedronis: hmmm somehow we again missed merging/updating the changelog for 2.50 + 2.50.1 to packaging/ubuntu-16.04/changelog, they are still both placeholders on master, my PR to release/2.50 will include the real changelogs for those too | 14:49 |
| pedronis | ijohnson: mmh, ok | 14:49 |
| ijohnson | it seems when I did the merge for #10280, I somehow didn't pick up the 16.04 file changes | 14:49 |
| pedronis | pstolowski: was somebody waiting on https://github.com/snapcore/snapd/pull/9669 it was open for a long time and without milestone ? | 15:06 |
| ijohnson | pedronis: oh I forgot to ask, mvo didn't mention this, but there is a LP bug placeholder for SRU's and such, I assume for a major version I should file a new one ? | 15:11 |
| ijohnson | like for example this one that was opened for 2.47 ? | 15:11 |
| ijohnson | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1895929 | 15:11 |
| ijohnson | pedronis: once I have that LP bug number I have the changelog ready and can proceed with the pr | 15:12 |
| pedronis | ijohnson: I suppose so (about the SRU) | 15:15 |
| ijohnson | pedronis: ok, I will file one with the same template that mvo used there, but for 2.51 obviously | 15:15 |
| pstolowski | pedronis: no, it was just a drive-by of #9627 (see this comment: https://github.com/snapcore/snapd/pull/9627#issuecomment-727919698) | 15:18 |
| pedronis | ok | 15:19 |
| ijohnson | pedronis: ok changelog prs are up | 15:25 |
| ijohnson | https://github.com/snapcore/snapd/pull/10314 for release/2.51 and 10313 for the placeholder for 2.51 to master | 15:26 |
| ijohnson | pedronis: oh wait sorry I need to change it slightly I think | 15:32 |
| === rzr is now known as rZr | ||
| === Ringtailed-Fox is now known as RingtailedFox | ||
| bandali | hi, i'm curious what the criteria is for a package appearing in tab completions for `snap install blah` | 21:10 |
| bandali | say 'blah' is a new package on snapcraft.io, i'm wondering how long it would take or what would need to happen on a user's computer for it to become available as a completion candidate for `snap install` | 21:10 |
| ijohnson | cachio: when you get some time tomorrow can you take a look at https://github.com/snapcore/snapd/pull/10099 ? | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!