=== Ringtailed_Fox is now known as RingtailedFox
=== stgraber is now known as stgraber_
=== stgraber_ is now known as stgraber
[05:45] <mborzecki> morning
[05:48] <mborzecki> mardy: hey
[06:30] <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:47] <mborzecki> mardy: hmm firefox does not like this page very much
[07:04] <pstolowski> morning
[07:04] <zyga> goood morning
[07:08] <mborzecki> pstolowski: zyga: hey
[07:08] <mborzecki> pstolowski: i've updated https://github.com/snapcore/snapd/pull/10301/
[07:10] <pstolowski> looking
[07:41] <pedronis> mborzecki: pstolowski: thanks for the review, https://github.com/snapcore/snapd/pull/10305 needs a 2nd review
[07:42] <mborzecki> will do
[07:44] <pedronis> mborzecki: https://github.com/snapcore/snapd/pull/9932 doesn't have two +1
[07:45] <pedronis> ah, it does, but I think Ian asked mvo to re-review it
[07:46] <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:47] <pedronis> mborzecki: I dismissed mvo original review for clarity
[07:48] <pedronis> sorry, that one needs to wait a bit more
[08:20] <mborzecki> we're down to 80 PRs
[08:21] <ogra> is that a suggestion that more should be created ? 🙂
=== pedronis_ is now known as pedronis
[08:25] <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:26] <pstolowski> pedronis: none, let's land, thanks
[08:48] <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:49] <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
[09:00] <mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/10299 is has 3 +1 ;)
[09:02] <pstolowski> mborzecki: yeah but not green yet.. and i think i'll change it to noticef
[09:03] <mborzecki> duh, we need another patch update for sid
[09:07] <pedronis> pstolowski: I commented on https://github.com/snapcore/snapd/pull/10299
[09:08] <mborzecki> pstolowski: mardy: can you take a look at https://github.com/snapcore/snapd/pull/10312 ?
[09:10] <mborzecki> i'm thinking we should skip debian 10 in the many interfaces remove test
=== zyga is now known as zyga-mbp
[09:11] <mardy> mborzecki: sure
[09:13] <mardy> mborzecki: appoved with a nitpicky remark :-)
[09:14] <mborzecki> thx
[09:15] <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:17] <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:20] <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:21] <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:23] <pstolowski> is there a reason for a fallback at all if delta download failed?
[09:33] <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:35] <pstolowski> pedronis: no, you're right, but we don't differentiate, maybe we should (err from downloadAndApplyDelta)
[09:36] <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:37] <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:38] <pedronis> mardy: I can but in a little bit
[09:39] <mardy> no hurry
[09:40] <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:41] <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:42] <pstolowski> yeah i know the issue pre-dates the introduction of download-speed-error
[09:44] <pedronis> we are being wasteful, but in the end that download will probably fail either way
[09:49] <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:53] <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:54] <pedronis> mardy: I changed it
=== zyga_ is now known as zyga
[10:01] <pedronis> mborzecki: I merged the PR you asked me to merge
[10:03] <mborzecki> pedronis: thank you!
[10:06] <pedronis> mborzecki: is apparmor_parser -j0  something new, I don't see it in the man page here
[10:07] <mborzecki> pedronis: on 18.04?
[10:07] <pedronis> 20.04
[10:11] <pedronis> mborzecki: I commented in the PR
[10:13] <mborzecki> hmm hmm, the change was introduces 3 years ago
[10:14] <mborzecki> ehh https://gitlab.com/apparmor/apparmor/-/commit/48a32b78b189cf9e2c4d8bce8fb45c68bf4cc327 only apparmor 3 apparently
[10:15] <pedronis> mborzecki: what does it do on older apparmor  1 or auto though?  I mean the spread tests aren't failing
[10:16] <pedronis> mborzecki: it might more conservative to do -j1 on 1 cpu?
[10:16] <pedronis> or check apparmor version?
[10:17] <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:18] <mborzecki> so like -jauto
[10:18] <mborzecki> there's a JOBS_AUTO which was 0 before, but is UINT_MIN in 3.0+
[10:19] <pstolowski> var/lib/snapd/snaps/partial doesn't appear to be used anymore? can we drop it from debian/snapd.dirs?
[10:45] <woutervb> ccccccibbcgvvdubhjibifgfierdffjkdgllkgntilte
[10:48] <ogra> meow ?
[11:02] <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:03] <mborzecki> added a milestone
[11:03] <pedronis> probaly not something to add in .x release
[11:04] <pedronis> I'll look at it in the afternoon, thx for the heads up
[11:05] <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:09] <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:12] <pstolowski> pedronis: yes that's a good idea
[11:13] <mborzecki> funny debian 10 is actually sucessful in some of the spread runs
[11:42] <cachio> mborzecki, hi, about the failing test tests/main/interfaces-x11-unix-socket on tumbleweed
[11:42] <cachio> mborzecki, should we skip it?
[11:43] <cachio> mborzecki, it is failing to create the socket for x11 currently
[11:53] <mborzecki> cachio: it's a known problem i will get around to fixing that sometime
[11:54] <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:56] <pedronis> pstolowski: sorry, I wasn't clear, the command should also match the endpoint, no?
[11:56] <pstolowski> pedronis: ah, ok
[12:01] <pedronis> mborzecki: maybe 10295 can be evens impler ?
[12:01] <pedronis> simpler
[12:04] <mborzecki> heh, right, pushed now
[12:06] <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:08] <pedronis> mborzecki: I don't understand mardy comment
[12:12] <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:13] <mardy> it doesn't seem to be relevant anymore
[12:13] <pedronis> pstolowski: I pushed a nitpick to that PR, sorry
[12:14]  * rzr is watching https://libregraphicsmeeting.org/2021/en/live.html , uc to be shown tomorrow (pincab)
[12:16] <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:17] <pedronis> pstolowski: they start with (internal)
[12:17] <pstolowski> pedronis: ah indeed, ok
[12:18] <pedronis> pstolowski: btw related to this "snap debug state" short help has a final "." which shouldn't be there
[12:19] <pedronis> you can see it also in "snap help debug"
[12:20] <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:22] <pedronis> mardy: not really
[12:22] <pedronis> mardy: the confinement is from outside invocations and for services
[12:23] <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:28] <pedronis> mborzecki: it's your call whether to do something about the commit or not
[12:30] <mborzecki> landed it as i'm in favor of unbreaking sid and now we can bikeshed about the commit message all we want :)
[12:31] <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:32] <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:34] <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:35] <pedronis> mardy: yes, likely tomorrow though, not today
[12:35] <mardy> pedronis: OK
[12:36] <pedronis> mborzecki: I suppose I should try it again locally
[12:37] <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:38] <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:40] <pedronis> mardy: I put those two alternative PRs into my queue now at least
[12:40] <mardy> pedronis: thanks
[12:42] <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:43] <pedronis> thx
[13:44] <mborzecki> cachio: i've added some comments in https://github.com/snapcore/snapd/pull/10162
[13:44] <cachio> mborzecki, thanks
[13:47] <mardy> mborzecki: what is the trick you mentioned in the chat about unpacking the snap?
[13:53] <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:54] <mborzecki> you can do that for anything that does not require recompilation of the source code
[13:57] <mardy> mborzecki: thanks, this is super helpful :-)
[14:19] <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:20] <ijohnson> oh huh, let me take a look at triaging those
=== Ringtailed_Fox is now known as Ringtailedfox
=== Ringtailedfox is now known as RingtailedFox
[14:20] <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:21] <pedronis> ijohnson: cherry pick to 2.50 ?
[14:22] <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:49] <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
[15:06] <pedronis> pstolowski: was somebody waiting on https://github.com/snapcore/snapd/pull/9669 it was open for a long time and without milestone ?
[15:11] <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:12] <ijohnson> pedronis: once I have that LP bug number I have the changelog ready and can proceed with the pr
[15:15] <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:18] <pstolowski> pedronis: no, it was just a drive-by of #9627 (see this comment: https://github.com/snapcore/snapd/pull/9627#issuecomment-727919698)
[15:19] <pedronis> ok
[15:25] <ijohnson> pedronis: ok changelog prs are up
[15:26] <ijohnson> https://github.com/snapcore/snapd/pull/10314 for release/2.51 and 10313 for the placeholder for 2.51 to master
[15:32] <ijohnson> pedronis: oh wait sorry I need to change it slightly I think
=== rzr is now known as rZr
=== Ringtailed-Fox is now known as RingtailedFox
[21:10] <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`
[23:12] <ijohnson> cachio: when you get some time tomorrow can you take a look at https://github.com/snapcore/snapd/pull/10099 ?