=== bandali_ is now known as bandali
[01:58] <futuretim> I'm seeing a super strange behavior in store_download.go
[02:05] <futuretim> I think it must be around the handling/expectations of finalErr in that download loop
[02:08] <futuretim> eh, maybe not
[04:44] <mardy> 'morning
[04:59] <mborzecki> morning
[04:59] <mborzecki> mardy: hey
[05:17] <mardy> mborzecki: hi!
[05:18] <mardy> mborzecki: have you seen this failure before? https://github.com/snapcore/snapd/pull/10497/checks?check_run_id=2999820053
[05:19] <mardy> I wonder if the kernel config for bionic has changed, as this doesn't look like a random failure
[05:23] <mborzecki> mardy: hm maybe they did change something in bionic
[05:23] <mborzecki> was there a systemd update maybe?
[06:01] <mardy> mborzecki: mmm... I tried to update the test expectations, and now it failed again, but this time showing that the old expectations where correct...
[06:07] <pstolowski> morning
[06:12] <mardy> pstolowski: hi!
[06:17] <pstolowski> mardy: hi, and congratulations! ;)
[06:24] <mborzecki> pstolowski: hey
[06:42] <mborzecki> heh `Failed for "gopkg.in/retry.v1" (failed to ping remote repo): unrecognized import path "gopkg.in/retry.v1"`
[06:42] <mborzecki> in unit tests
[07:02] <mvo> mborzecki: meh, we had this before, iirc it's gustavos and he is on vac. let's hope it was just a glitch
[07:02] <mborzecki> haha 😉 ok
[07:02] <mborzecki> mvo: btw. can you bother you to take a look at https://github.com/snapcore/snapd/pull/10469 with your morning tea?
[07:09] <mvo> mborzecki: sure
[07:11] <zyga-mbp> good morning
[07:44] <mardy> mmm... my snap cannot see folders like /usr/share/libreoffice (though its apparmor profile allows that); but AFAIU we are not running the snaps in a chroot... So, why is this happening?
[07:46] <pstolowski> mardy: snap's mount namespace only sees certain folders?
[07:46]  * pstolowski physio
[07:53] <mardy> oh, it turns out my mount-control interface + snap is working fine, it's just that I was binding-mounting a directory which my snap saw as empty (not the real /usr/share/fonts/, but something else)
[07:57] <mborzecki> mardy: hm so the original directory was empty too?
[07:58] <mardy> mborzecki: yes :-D
[08:20] <zyga> mardy: snaps run in super-chroots
[08:21] <zyga> mardy: pivot_root is like chroot but "more"
[08:21] <zyga> ah ;)
[08:21] <zyga> mount things can be confusing sometimes
[08:32] <mborzecki> mvo: can you land https://github.com/snapcore/snapd/pull/10493 ?
[08:33] <mborzecki> wow, the only spread failure in https://github.com/snapcore/snapd/pull/10502 is unix socket thing on tw one we know about, otherwise it's all green
=== pedronis_ is now known as pedronis
[08:49] <mborzecki> a trivial one: https://github.com/snapcore/snapd/pull/10503
[08:54] <pstolowski> re
[09:00] <mvo> mborzecki: I landed the PR
[09:03] <mborzecki> mvo: thanks!
[09:08] <jamesh> pstolowski: Does the info in https://forum.snapcraft.io/t/a-desktop-notifications-client-api-for-snapd/25063/4?u=jamesh cover what you needed for icons in desktop notifications? Sorry for not getting back to you about it sooner.
[09:13] <pstolowski> jamesh: thanks, that's perfect. and no worries, i've been working on a few other things, wasn't blocked on that one
[10:28] <pstolowski> mborzecki: a simple PR https://github.com/snapcore/snapd/pull/10504, i wonder if there was a reason for this / something planned?
[10:32] <mborzecki> pstolowski: hm don't recall anything, maybe ian will
[10:32] <mborzecki> pstolowski: or maybe it was just missed during review ;)
[10:47] <mvo> mardy: 10375 has a conflict currently
[10:56] <pedronis> pstolowski: I don't remember, that code is quite convoluted, but not really at the top of things to clean up (so far)
[11:00] <pstolowski> pedronis: sure
[11:13] <mardy> mvo: it's expected, I'll fix them now
[11:14] <mvo> mardy: nice, thank you
[11:31] <pstolowski> mvo: could you please land https://github.com/snapcore/snapd/pull/10479 ? unrelated failures, been trying to land it since this morning
[11:44] <mvo> mardy: also thanks for your suggestions in 10482!
[12:02] <pstolowski> pedronis: i've been pondering asserts pool changes wrt conflict checks on CommitTo(); does using existing checkers mechanism on .Add() seem like a good direction to you?
[12:03] <pedronis> pstolowski: bit confused, I don't think we want that be bit to go as deep as asserts
[12:03] <pedronis> pstolowski: I mean I expect this part to be a problem of assertstate
[12:04] <pstolowski> pedronis: ok, i probably misunderstood this from our discussion
[12:05] <pedronis> pstolowski: we might need help, but my point is the call to CommitTo is assertstate, so it's more of decision to call it or not, vs having CommitTo decide, am I missing something?
[12:08] <mardy> pedronis: hi! the "snapctl mount" command, should it be in the "nonRootAllowed" list?
[12:08] <mardy> I guess not, but double-checking
[12:09] <pedronis> mardy: no, not initially for sure
[12:10] <zyga-mbp> mardy, pedronis: it feels like it should not but remember that snaps can trivially gain root and expose confined root to unconfined user via a socket 
[12:10] <zyga-mbp> so this is only a cosmetic distinction 
[12:11] <mardy> zyga-mbp: can I read more about this "trivially"? :-)
[12:12] <pedronis> any snap can define services and those run as root
[12:12] <zyga-mbp> mardy: put a snap in the store that runs a service that accepts input from anyone 
[12:12] <pstolowski> pedronis: i understand the high level concept. but one detail i'm struggling to understand now is: i've current db and a set of incoming (resolved) asserts in the pool, I now need a "combined" database of both to check if no conflicts arise, no? but maybe i'm confused
[12:12] <zyga-mbp> it's good that mount-control is not going to be granted to anyone
[12:12] <mardy> zyga-mbp: last famous words ;-)
[12:12] <zyga-mbp> but keep in mind that snapctl root-only list is not a strong protection system
[12:12] <zyga-mbp> s/anyone/just anyone/
[12:13] <mardy> zyga-mbp: good to know, thanks
[12:13] <zyga-mbp> right, I just wanted to make sure you know this :)
[12:15] <pedronis> pstolowski: maybe we should have a quick chat, you might need a way to access the Backstore inside the pool
[12:16] <pstolowski> pedronis: ok, maybe after standup?
[12:16] <pedronis> yes
[12:18] <ogra`> zyga-mbp, you mean putting duct tape over a keyhole is not a safe security mechanism ?
[12:24] <zyga-mbp> ogra` it's not a duct tape, it's a "please do not enter" sign on an open dor
[12:24] <zyga-mbp> *door
[12:24] <ogra`> hahaha
[13:32] <futuretim> Good <insert your time of day here> all! My snapd keeps trying to get the account key for "wrfougkz3Huq2T_KklfnufCC0HzG7bJ9wP99GV0FF-D3QH3eJtuSRlQc2JhrAoh1" which is very familiar but I can't remember why and I couldn't answer the question online. Does anyone know what account key that is?
[13:41] <futuretim> I guess it's generic-classic related.
[13:43] <futuretim> Does the sign-key for generic-classic change often?
[13:45] <futuretim> Ah- it's the serials assertion for generic. Right.
[13:45] <futuretim> Ah- it's the serials (account-key) assertion for generic. Right.
[14:02] <pedronis> it can change at any point, snapd usually gets the signing key when getting any assertion in case it doesn't have it yet or has been updated
[14:02] <pedronis> except for the few in the trusted set
[14:04] <mvo> if someone could review the 2.51.2 changelog (pr#10506) that would be great
[14:08] <pedronis> mvo: reviewed
[14:15] <mvo> pedronis: thanks, I can update the "do not visit same halt..." text if you want, what do you want there?
[14:16] <pedronis> mvo: put something there
[14:17] <mvo> ta
[14:20] <mvo> pedronis: thanks, pushed again
[14:31] <ijohnson[m]> pedronis: I pushed again to https://github.com/snapcore/snapd/pull/10437
[14:33] <pedronis> ijohnson[m]: thx, I'll see if I can get to it today, working on something else atm
[14:33] <ijohnson[m]> sure, np thanks for the reviews
[14:38]  * cachio afk
[14:55] <mvo> a review for 10507 would be great
[14:57] <futuretim_> Why are some checks failing acceptable? 
[14:58] <mvo> futuretim it's not in general
[14:59] <mvo> futuretim there are sometimes infrastructure failures (503 from e.g. store registration service) where I may override the failure if it's absolutely clearly not related to the PR. is that what you were asking aobut? or did I misunderstand?
[14:59] <futuretim_> That PR has 12 commits that had failing checks.
[15:00] <mvo> futuretim PR#10437?
[15:00] <futuretim_> Just getting somewhat acclimated to the workings, so just asking questions
[15:00] <futuretim_> no 10507
[15:00] <ijohnson[m]> mvo: reviewing that pr now
[15:01] <futuretim_> or am I mistaken?
[15:02] <mvo> futuretim oh, sorry, I see now what you mean. I think (without having looked at the individual ones) that those are intermediate commits that may have had issues, we do not squash those (most of the time) so this can happen. as long as the aggregation is ok it should be fine
[15:02] <futuretim_> OK, that makes sense. Thanks.
[15:02] <mvo> yw :) 
[15:03] <ijohnson[m]> yeah github if it knows it ran checks for a given commit as part of another PR, it will show the results of that run next to the commit even if the commit is in another PR
[15:04] <ijohnson[m]> futuretim_:  also that particular little UI thing (the red X next to a commit) is basically always red since we have 1-2 tests on opensuse tumbleweed that fail 100% of the time that we haven't fully figured out yet (IIRC it's related the cloud kernel used in the tumbleweed images that we don't control), but those checks are not "required" to land the PR so it's "okay" that those opensuse failures are happening
[15:05] <futuretim_> ijohnson[m]: thanks for explaining! 
[15:08] <ijohnson[m]> np
[15:08] <futuretim_> Also, the testing is impressive in snapd.
[15:09] <ijohnson[m]> thanks! 🙂
=== benfrancis2 is now known as benfrancis
[16:04] <DWD> Hello, I've been asked if there is a way to override environment variables in Snaps at runtime (i.e not when building).  Is there such a feature?
[16:05] <ijohnson[m]> DWD: you mean to change something that the snap is setting ? No unfortunately there is not
[16:06] <DWD> Yes, that is my understanding of their question.  Thank you for your help
[16:06] <ijohnson[m]> np
[16:13] <DWD> My friend has informed me that the Snap is one which performs some computational work that could be delegated to their GPU by setting "__NV_PRIME_RENDER_OFFLOAD=1 and __GLX_VENDOR_LIBRARY_NAME=nvidia" .Assuming the snap does not set these, could they be passed in?
[16:14] <ijohnson[m]> DWD: yes if the snap does not already set values for those in the snap.yaml or as part of any wrapper scripts, you could just set those in your environment and run the appropriate command
[16:15] <DWD> Thanks very much, I'll forward this.  My friend also passes their thanks to you
[16:16] <DWD> enjoy your evening/ day :)
[17:06] <cachio> ijohnson[m], hey
[17:06] <cachio> about the comment https://github.com/snapcore/snapd/pull/10409#discussion_r664947561
[17:06] <cachio> there is not MATCH implementation in snapd
[17:07] <cachio> it is a fake function
[17:07] <cachio> so it is not possible to copy that 
[17:08] <cachio> not sure if it is possible to copy the function which is in the scipt which is executed in runtime
[17:08] <cachio> that should be ideal
[17:12] <cachio> You mean to use type for that right?
[17:16] <cachio> ijohnson[m], I think I have it 
[17:16] <cachio> it was much easier
[17:16] <cachio> thanks for the comment
[18:25] <cachio> ijohnson[m], updated #10409
[18:28] <ijohnson[m]> cachio: cool I'll have a look when I'm back in a bit
[18:38] <cachio> ijohnson[m], thanks
[20:40] <cachio> ijohnson[m], that approach does not work
[20:41] <cachio> because using type I get the match implementation which is empty 
[20:41] <cachio> perhaps getting this in the spread.yaml could work
[20:45] <cachio> I see we already are doing type MATCH | tail -n +2 > "$TESTSLIB"/spread-funcs.sh
[20:45] <cachio> while we prepare the project
[21:01] <cachio> ijohnson[m], it is fixed now
=== jdstrand_ is now known as jdstrand
[23:48] <futuretim> is there a branch or work being done to convert snapd to Go modules yet?