[05:43] <mborzecki> morning
[06:31] <mborzecki> ehh some random failures on arch
[06:31] <mborzecki> mvo: morning
[06:32] <mvo> mborzecki: good morning
[06:52] <mborzecki> mvo: can you use your superpowers to merge https://github.com/snapcore/snapd/pull/9246 ?
[06:52] <mup> PR #9246: boot: handle canceled update <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9246>
[06:53] <mvo> mborzecki: sure thing
[06:53] <mborzecki> mvo: thanks!
[06:53] <zyga-kaveri> good morning
[06:53] <mvo> mborzecki: done
[06:53] <mvo> zyga-kaveri: good morning
[06:53] <mborzecki> mvo: yay, thanks!
[06:53] <mborzecki> zyga-kaveri: hey
[06:56] <mup> PR snapd#9246 closed: boot: handle canceled update <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9246>
[07:03] <pstolowski> morning
[07:06] <mup> PR snapd#9258 closed: devicestate: add tests around logging in RequestSystemAction <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9258>
[07:12] <mborzecki> pedronis: i'll rebase #9264 on top of master now that Canceled has landed
[07:12] <mup> PR #9264: [RFC] many: introduce ContentChange for tracking gadget content in observers <Needs security review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9264>
[07:12] <pedronis> mborzecki: thx
[07:14] <mvo> mborzecki: I addressed your comments in 9210, I think this is ready for another look
[07:16] <mup> PR snapd#9268 opened: daemon: add API for checking and installing available theme snaps <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9268>
[07:21] <mup> PR snapd#9257 closed: bootloader: retrieve boot chains from bootloader <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9257>
[07:21] <mup> PR snapd#9269 opened: devicestate: rename "mockLogger" to "logbuf" <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9269>
[07:31] <mup> PR snapd#9267 closed: many: fix partion vs partition typo <Simple 😃> <Created by cmatsuoka> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9267>
[08:13] <mborzecki> hm i think i found a subtle bug in gadget updates handling of new files on rollback when there's an unexpected reboot in between
[08:16]  * zyga-kaveri will really start at 11:00, but is wondering if this is a good long-term model
[08:16] <mborzecki> zyga-kaveri: probably not
[08:17] <zyga-kaveri> mborzecki: PT interferes but fortunately I do at-home PT today
[08:45] <pedronis> mborzecki: I re-commented in 9264
[08:46] <pedronis> mborzecki: also maybe, silly idea, could backupOrCheckpointFile return the ContentChange or nil directly? or doesn't it have the right info?
[08:48] <mborzecki> pedronis: hm good point, it should have all the data, and != nil means somethign will be written
[08:48] <pedronis> yes
[09:00] <mborzecki> pedronis: pushed now
[09:01] <pedronis> thx, I have a meeting now
[09:05] <zyga> heh, lucy is just now sleeping, as my wife is back
[09:05] <zyga> anyway
[09:05]  * zyga focuses on coding 
[09:07] <zyga> hmm, some issue with spread
[09:10] <zyga> _hmm_
[09:13] <zyga> pstolowski: offtopic, I think we have a bug in services
[09:13] <zyga> https://pastebin.ubuntu.com/p/mWNXbsyt2f/
[09:14] <zyga> pstolowski: look at those days
[09:14] <zyga> dates
[09:14] <zyga> Undoing  2020-05-06  2020-05-06  Stop snap "lxd" services
[09:15] <pstolowski> looking
[09:15] <zyga> perhaps lxd's special arrangement with services makes our code ineffective
[09:15] <zyga> I rebooted the machine as it was stuck using lots of cpu as lxd was in a weird state
[09:15] <zyga> but I think this change should have progressed somehow
[09:15] <zyga> either by failing
[09:15] <zyga> or by continuing with lxd services not stopped
[09:15] <zyga> note that this is the undo path
[09:15] <zyga> so maybe it's a less prominent bug
[09:16] <zyga> I rebooted that device
[09:17] <zyga> ha
[09:17] <zyga> it's rebooted and in the same state?!
[09:18] <pstolowski> zyga: i don't understand what's going on, but 2020-05-13  and 2020-05-06 looks werid
[09:18] <zyga> https://paste.ubuntu.com/p/VVbp4k44sF/
[09:18] <zyga> yeah
[09:18] <zyga> it's like this for a long time
[09:18] <zyga> look at this now
[09:19] <zyga> anything else I can provide?
[09:20] <zyga> I can refresh snapd
[09:20] <zyga> it's not the latest by far
[09:20] <zyga> but I wonder why didn't it refresh by itself
[09:21] <zyga> is it the lxd change in flight?
[09:21] <zyga> I didn't set any refresh schedules or anything like that
[09:23] <zyga> pstolowski: lxd is also in a funny state: https://paste.ubuntu.com/p/w69fpSx3df/
[09:23] <zyga> this keeps showing up over and over
[09:24] <zyga> zyga@pi3-2:~$ sudo snap stop lxd
[09:24] <zyga> error: snap "lxd" has "auto-refresh" change in progress
[09:24] <zyga> hmmm
[09:29] <zyga> I stopped both the lxd.activate and lxd.dameon services
[09:30] <zyga> and the machine is no longer spinning like crazy
[09:30] <zyga> and now all the tasks have finished
[09:30] <zyga>     restart-condition: on-failure
[09:30] <zyga> lxd will restart forever when it is broken
[09:31] <zyga> pstolowski: what happens when:
[09:31] <zyga> pstolowski: a snap has a service which has restart-condition: on-failure
[09:32] <zyga> pstolowski: snap has more than one service, one that talks to a socket (like activate) and causing socket-activation, and another one that is broken
[09:32] <zyga> pstolowski: will we ever manage to stop that?
[09:35] <pstolowski> zyga: would be good to have a simple reproducer as a spread test (without lxd), i don't know from top of my head
[09:35] <zyga> now store assertions service times out
[09:35] <zyga> - Fetch and check assertions for snap "core18" (1889) (Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-revision/i_FldUJXgbUZueGCJo8M5l_yJeF-i1p9ienjEtN3SRfRmi8Wpckx_ZI8qm-r5Mdg?max-format=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers))
[09:35] <zyga> pstolowski: yeah, I agree
[09:36] <zyga> eh, it sucks we throw away a snap download when assertions fail
[09:36] <zyga> I'm re downloading core and snapd again
[09:36] <zyga> isn't there a cache we have?
[09:36] <pstolowski> zyga: you're probably onto something but this is a bit complicated to reason about without a test
[09:36] <mup> PR snapd#9270 opened: wrappers, systemd: allow empty root dir and conditionally do not pass --root to systemctl <Run nested> <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9270>
[09:37] <zyga> pstolowski: I can review that
[09:37] <pstolowski> zyga: thanks
[09:37] <zyga> I think we could try to fetch assertions before the download
[09:37] <pstolowski> zyga: i guess failed assertion means we cannot trust cache?
[09:37] <zyga> that's probably not a high cost in code
[09:37] <zyga> pstolowski: not really, we can keep an incomplete cache of downloads
[09:37] <pstolowski> zyga: ah, ok, it's downloading assertions
[09:38] <pstolowski> zyga: so yeah, probably
[09:38] <zyga> if I break network at 90% of a huge snap
[09:38] <zyga> it's really silly to throw that away
[09:38] <zyga> even before we have any assertions
[09:38] <pstolowski> zyga: i marked that PR RFC/draft
[09:38] <zyga> and it failed again!
[09:39] <zyga> pedronis: is the store assertion service broken?
[09:39] <zyga> - Fetch and check assertions for snap "snapd" (8792) (Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-revision/eZZ56DeorGzQUHotTBqlJ_T4LLyZKnAA0IkKn9YISRHfkTjiCENUBpcH5flV-kCA?max-format=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers))
[09:39] <mvo> zyga: he is in a meeting, maybe someone from the store knows?
[09:39] <zyga> I see
[09:43] <zyga> for context, this fails when doing this:
[09:43] <zyga> - Fetch and check assertions for snap "snapd" (8792) (Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-revision/eZZ56DeorGzQUHotTBqlJ_T4LLyZKnAA0IkKn9YISRHfkTjiCENUBpcH5flV-kCA?max-format=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers))
[09:43] <zyga> er
[09:43] <zyga> Consider re-refresh of "core18", "pi", "lxd", "htop", "snapd", "pi-kernel"                                                                                                                                                                    |
[09:43] <zyga> it's re-refreshing a handful of snaps
[09:44] <zyga> and probably fails because of that
[09:44] <zyga> yep, failed again
[09:44] <zyga> and re-refresh fails the whole change
[09:48] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/9270#pullrequestreview-481676543
[09:48] <mup> PR #9270: [RFC] wrappers, systemd: allow empty root dir and conditionally do not pass --root to systemctl <Run nested> <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9270>
[09:52] <pstolowski> zyga: thank you, i think's a new ctor is a good idea, although i think NewInChroot is confusing
[09:53] <zyga> pstolowski: New vs NewChroot or something similar
[09:56] <zyga> spread workers will be back shortly
[09:56] <pstolowski> zyga: i would just avoid "Chroot" in the name, but yes
[10:02] <pedronis> pstolowski: New and NewUnderRoot ?
[10:03] <pstolowski> pedronis: yes, works for me
[10:04] <mborzecki> heh, cancelling github action jobs is kind of flaky
[10:04] <mborzecki> pretty sure i canceled the right one, but a different run failed?
[10:04] <mborzecki> all in the same PR
[10:08] <zyga> mborzecki: spread refuses to be cancelled
[10:08] <zyga> mborzecki: it works if the process cooperates
[10:08] <zyga> mborzecki: I had to restart workers so that's expected
[10:08] <mborzecki> zyga: wouldn't the worker send SIGTERM at some point?
[10:09] <zyga> mborzecki: spread ignores that
[10:09] <zyga> mborzecki: it's a known bug
[10:09] <mborzecki> uh meant SIGKILL
[10:09] <zyga> mborzecki: ah, no it doesn't do that
[10:09] <zyga> compilers usually behave
[10:09] <mborzecki> well, you can run arbitrary commands there
[10:10] <mborzecki> do actual deployments and so on
[10:10] <zyga> I know but usually tools take SIGINT just fine
[10:12] <zyga> ok, we should have a bit more stability now, there's some extra ram for excessive spiky loads
[10:16] <mborzecki> well, you can run arbitrary commands there
[10:16] <mborzecki> duh, wrong window
[10:16] <zyga> ls ;)
[10:25] <clmsy> Hi Everyone, is there any date in mind for this milestone release ? https://launchpad.net/snapd/+milestone/2.46
[10:25] <clmsy> the fixes has been committed for a while
[10:25] <zyga> mvo: ^^^
[10:31]  * zyga changes hosts
[10:40] <pstolowski> zyga-kaveri: can you report a bug for that lxd services issue and collect all the info there?
[10:42] <mup> PR snapd#9271 opened: boot: keep track of the original asset when observing updates  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9271>
[10:48] <pedronis> pstolowski: shouldn't most places keep New, and just very few use UnderRoot? are you not doing that because of tests?
[10:51] <pstolowski> pedronis: yes, i just wanted to limit changes to the minimum I know was problematic for services PR. i can do it all if you prefer that way?
[10:52] <pedronis> pstolowski: I think we need to have a chat so I understand what's the final state we want
[10:52] <zyga-kaveri> pstolowski: yes, on it
[10:54] <pedronis> pstolowski: can we have a chat after standup? or ealier if you want?
[10:54] <pstolowski> pedronis: sure, anytime works for me
[10:59] <pstolowski> pedronis: i'll have a lunch break now, so maybe before or after standup, let me know
[10:59] <pedronis> ok, I have a meeting noew
[10:59] <pstolowski> ok
[11:06] <cachio> zyga, hi
[11:06] <cachio> zyga, I need last review for #9098
[11:06] <mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
[11:07] <cachio> zyga, could you please take a look today?
[11:10] <zyga-kaveri> cachio: sure
[11:10] <cachio> zyga-kaveri, thanks
[11:51] <pedronis> pstolowski: I scheduled something
[11:52] <pstolowski> pedronis: thanks
[12:02] <mup> PR snapd#9262 closed: configcore: rework how console-conf is disabled <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9262>
[12:08] <zyga-kaveri> cachio: https://github.com/snapcore/snapd/pull/9098#pullrequestreview-481741540
[12:08] <mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
[12:10] <cachio> zyga-kaveri, o makes good compression, I'll put there the values , give me 10 minutes
[12:12] <zyga-kaveri> cachio: cool, thanks
[12:12] <zyga-kaveri> that is not a blocker
[12:12] <zyga-kaveri> the few issues are real blockers
[12:12] <zyga-kaveri> once those are done we can merge and iterate
[12:29] <cachio> zyga-kaveri, I updated the function names
[12:30] <cachio> zyga-kaveri, the changes you told me about core revert test, I don't see the same thing than you
[12:31] <zyga-kaveri> cachio: about !?
[12:31] <zyga-kaveri> cachio: function names were not a blocker
[12:31] <cachio> this test has been already with the others, could be that one cached for you?
[12:31] <zyga-kaveri> ?
[12:31] <zyga-kaveri> cachio: cached?
[12:31] <zyga-kaveri> are we talking about the use of negation?
[12:33] <cachio> zyga-kaveri, this one https://github.com/snapcore/snapd/pull/9098#discussion_r482923838
[12:33] <mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
[12:33] <cachio> for example
[12:34] <zyga-kaveri> I didn't read your comments there
[12:34] <zyga-kaveri> but do you understand the fundamental problem with sh, functions, set -e and if / while / !?
[12:34] <zyga-kaveri> you cannot use all three at the same time
[12:35] <zyga-kaveri> set -e; hello() { false; echo "blah" }; if ! hello; then echo "unreachable"; fi
[12:35] <zyga-kaveri> false does not break execution of hello
[12:36] <cachio> I am not talking about the negation
[12:36] <zyga-kaveri> cachio: replace `if` with `while/until` and `!`
[12:36] <zyga-kaveri> ok, let me read your comments
[12:37] <cachio> you see variables like CORE_REFRESH_CHANNEL but I dont
[12:38] <zyga-kaveri> that's not what I'm referring to
[12:38] <cachio> I know
[12:38] <zyga-kaveri> I was only referring to the usage of functions inside control statements
[12:38] <zyga-kaveri> so?
[12:39] <cachio> 1 sec, let me check github code
[12:40] <zyga-kaveri> are we in agreement what is the problem with those functions?
[12:40] <zyga-kaveri> I'm confused if we are talking about the same thing
[12:40] <cachio> I think github is doing something wrong
[12:41] <zyga-kaveri> what?
[12:42] <cachio> it shows in the main page of the pr some comments but then if I go to the file I see the real one
[12:42] <cachio> it is like an overlap
[12:43] <cachio> I think it was caching here
[12:43] <cachio> now I see well
[12:44] <cachio> about the negations, we allways used the ! and not for execute_remote, in this PR I just updated the name
[12:45] <cachio> zyga-kaveri,
[12:45] <zyga-kaveri> so?
[12:45] <zyga-kaveri> it's still wrong :)
[12:45] <zyga-kaveri> not lalalalal is true
[12:45] <zyga-kaveri> not function_not_command is always true
[12:45] <zyga-kaveri> that part was not testing anything real
[12:46] <zyga-kaveri> ! function is very very fragile
[12:46] <zyga-kaveri> unless the function is coded for it
[12:46] <zyga-kaveri> it will misbehave
[12:46] <zyga-kaveri> while function and if function are equally fragile
[12:50] <zyga-kaveri> cachio: don't get me wrong, those do not have to be fixed in this pr
[12:50] <zyga-kaveri> cachio: they are wrong though
[12:51] <cachio> zyga-kaveri, ok, I'll open a new pr with that
[12:51] <cachio> zyga-kaveri, we should organize all the changes needed for nested
[12:51] <zyga-kaveri> yeah, let's fix the small things here and work towards fixing the rest
[12:51] <cachio> I am creating a todo list
[12:51] <zyga-kaveri> I'm not sure how to fix it yet
[13:02] <mup> PR snapd#9272 opened: configcore: "service.console-conf.disable" is gadget defaults only <Created by mvo5> <https://github.com/snapcore/snapd/pull/9272>
[13:59] <mborzecki> off to pick up the kids
[14:02] <pedronis> #9264 needs 2nd reviews
[14:02] <mup> PR #9264: many: introduce ContentChange for tracking gadget content in observers <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9264>
[14:02] <mup> PR snapd#9273 opened: [RFC]  boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>
[14:03] <mborzecki> cmatsuoka: can you take a look at 9264 maybe?
[14:03] <cmatsuoka> mborzecki: sure
[14:03] <mborzecki> cmatsuoka: thanks!
[14:04]  * mborzecki really leaves this time to pick up the kids, bbl
[14:11] <cmatsuoka> mborzecki: done
[14:29] <ijohnson> cachio: have you seen this journal-state failure before ? https://pastebin.ubuntu.com/p/zqGBMpPxgF/
[14:30]  * zyga-kaveri focuses on coding
[14:33] <mup> PR snapd#9264 closed: many: introduce ContentChange for tracking gadget content in observers <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9264>
[14:33] <ijohnson> mvo: pedronis: we can just land #9269 now and I can merge master into my PR
[14:33] <mup> PR #9269: devicestate: rename "mockLogger" to "logbuf" <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9269>
[14:33] <ijohnson> I need to merge master into my PR anyways
[14:33] <pedronis> ijohnson: ok, if that works for you
[14:33] <ijohnson> yeah that's fine
[14:34] <ijohnson> I +1d it, not sure if we want a 2nd +1 on the PR, it's quite simple
[14:34] <cachio> ijohnson, cheking
[14:35] <pedronis> ijohnson: I merged it
[14:35] <cachio> ijohnson, mmm, no
[14:36] <cachio> but at some point we added that retry to avoid an error
[14:36] <cachio> I'll try to reproduce it
[14:38] <mup> PR snapd#9269 closed: devicestate: rename "mockLogger" to "logbuf" <Simple 😃> <Skip spread> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9269>
[14:39] <ijohnson> thanks pedronis
[14:39] <ijohnson> cachio: yeah I just saw it once, I don't think it's happening all the time
[14:41] <pedronis> ijohnson: mvo: I commented here: https://github.com/snapcore/snapd/pull/9253/files#r483024347
[14:41] <mup> PR #9253: sysconfig/cloudinit.go: add AllowCloudInit and use GadgetDir for cloud.conf <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9253>
[14:42] <ijohnson> pedronis: I responded, I think returning right now is the right thing
[14:42] <ijohnson> pedronis: but eventually returning right there is not what we want
[14:44] <pedronis> ijohnson: we are setting CloudInitSrcDir only for dangerous atm, right?
[14:44] <ijohnson> pedronis: yes
[14:44] <pedronis> so we don't strictly need to return
[14:45] <pedronis> we might want to add a comment about that and vs the TODO though
[14:45] <ijohnson> pedronis: do you think the existing TODO I have is sufficient or should I add another TODO ?
[14:46] <pedronis> ah, I was confused you have already a return nil
[14:47] <pedronis> that return nil needs its own TODO, about the fact that combining cloud.conf and renumbering / filtered seed data should be ok
[14:47] <mvo> can I interesst someone in a review for 9210 maybe :) ? would unblock the "snap reboot" command
[14:48] <ijohnson> mvo: I can take a look in my PM
[14:48] <mvo> \o/
[14:48] <ijohnson> queued it up
[14:54] <pedronis> ijohnson: #9273 is also something you should look (I don't know if I'll get to it myself today)
[14:54] <mup> PR #9273: [RFC]  boot: mark successful with boot assets  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9273>
[15:03] <ijohnson> pedronis: ack I will add it to the queue, also #9253 is updated again
[15:03] <mup> PR #9253: sysconfig/cloudinit.go: add AllowCloudInit and use GadgetDir for cloud.conf <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9253>
[15:05] <pedronis> ijohnson: +1
[15:06] <ijohnson> thanks
[15:10] <pedronis> mvo: I merged master into #8920
[15:10] <mup> PR #8920: interfaces: update cups-control and add cups for providing snaps <Needs Samuele review> <Squash-merge> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>
[15:11] <pedronis> pstolowski: #9245 doesn't need to target 2.46 anymore, right?
[15:11] <mup> PR #9245: o/snapstate, features: add feature flags for disk space awareness <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9245>
[15:12] <pstolowski> pedronis: yes, cleared, thank you
[15:12] <pedronis> thx
[15:15] <mup> PR snapcraft#3269 closed: spread tests: remove references of core16 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3269>
[15:20] <pedronis> pstolowski: maybe I'm confused but now  TestRemoveDiskSpaceForSnapshotNotCheckedWhenSnapshotsDisabled and TestRemoveDiskSpaceCheckDisabled are the same test basically? so we should keep only one?
[15:20] <pstolowski> let me check
[15:21] <pedronis> or one is about the default?
[15:23] <pedronis> yes, one of the two is about the default vs explicitly disabling, maybe they should share some code, and need better names
[15:25] <pedronis> pstolowski: sorry, maybe I'm distracting you, I thought that one would be an easy win
[15:30] <mvo> pedronis: looking at cups in a sec
[15:30] <pstolowski> pedronis: np, i was just checking, yes, one is about not doing a snapshot becuase of ErrNothingToDo, the other is about feature flag but it has a mistake and is not really testing the flag becuase it also hits ErrNothingToDo
[15:31] <pstolowski> pedronis: thanks for spotting, i'll fix that
[15:48]  * cachio lunch
[16:01] <ijohnson> mvo: could you use your superpowers on #9266 ? the only failed test is on 16.04, and it's a known failure that is not related to the PR
[16:01] <mup> PR #9266: tests/lib/nested.sh: reset the TPM when we create the uc20 vm <Bug> <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9266>
[16:03] <mvo> ijohnson: sure
[16:03] <ijohnson> thanks
[16:03] <mvo> ijohnson: done
[16:03] <ijohnson> \o/
[16:05] <pstolowski> pedronis: done with https://github.com/snapcore/snapd/pull/9274 ; 3 tests share same code now
[16:06] <mup> PR #9274: tests: simplify and fix tests for disk space checks on snap remove <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9274>
[16:08] <mup> PR snapd#9266 closed: tests/lib/nested.sh: reset the TPM when we create the uc20 vm <Bug> <Run nested> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9266>
[16:08] <mup> PR snapd#9274 opened: tests: simplify and fix tests for disk space checks on snap remove <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9274>
[16:13] <ijohnson> cachio: zyga-kaveri: is it likely that we can land 9098 today or will that take some more work to refactor things
[16:14] <ijohnson> I have some other (simple) nested changes I need to propose, just wondering if I should wait for that to land or just propose them as-is now
[16:18] <mup> PR snapd#9275 opened: tests/main: mv core specific tests to core suite <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9275>
[16:36] <cachio> ijohnson, I see all the jobs for 9098 -> Queued — Waiting to run this check...
[16:36] <ijohnson> cachio: ah yeah might need to close and re-open the PR to trigger them
[16:36] <cachio> ijohnson, and it has conflicts
[16:36] <ijohnson> I see that on my PR's as well
[16:36] <ijohnson> ah ok I didn't know it has conflicts too
[16:37] <ijohnson> cachio: is it ok if I propose a small improvement to nested.sh today then ?
[16:38] <cachio> zyga-kaveri, could you please give last review to 9098?
[16:38] <zyga-kaveri> cachio: in 1-2 hours
[16:38] <zyga-kaveri> focused on coding now
[16:38] <zyga-kaveri> but before EOD
[16:39] <cachio> zyga-kaveri, nice, thanks
[16:49] <cachio> ijohnson, I am colleting all the comments for the following PRs
[16:57] <ijohnson> thanks
[17:53] <cachio> zyga-kaveri, is there any easy way to skip an invariant check?
[17:53] <cachio> I need to skip it for new desktop run
[17:53] <zyga-kaveri> hmm?
[17:54] <zyga-kaveri> not really
[17:54] <zyga-kaveri> can you tell me more
[17:54] <zyga-kaveri> maybe we need to extend it
[17:54] <zyga-kaveri> is it the dbus check?
[17:54] <cachio> because in my desktop image we have more dbus-sessions running
[17:54] <cachio> and the invariant fails
[17:54] <zyga-kaveri> right
[17:55] <zyga-kaveri> is it for the gdm user?
[17:55] <cachio> let me check, I think it is power user
[17:56] <zyga-kaveri> please add an exception to the invariant to allow those users on certain backends
[17:57] <cachio> tests.invariant: more than one dbus-daemon running
[17:57] <cachio> pid:1200 cmdline:/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
[17:57] <cachio> pid:1387 cmdline:/usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
[17:58] <zyga-kaveri> what user runs those?
[17:59] <cachio> tit is hte ubuntu user
[17:59] <cachio> it is another user in the system
[18:00] <cachio> which is hte default user for this desktop
[18:00] <cachio> zyga-kaveri, so perhaps for classic desktop we should allow this
[18:00] <cachio> because we allways have at least 1 extra user
[18:03] <cachio> I'll update now the invariant to support the ubuntu user which will be our default for desktop
[18:03] <cachio> zyga-kaveri, does it make sense?
[18:04] <zyga-kaveri> cachio: why is the ubuntu user logged in>
[18:05] <cachio> zyga-kaveri, it is beacuse I created that in the zfs machine
[18:05] <cachio> as default user
[18:05] <zyga-kaveri> so?
[18:05] <zyga-kaveri> why is it logged in?
[18:05] <zyga-kaveri> I don't understand
[18:05] <zyga-kaveri> is it running our tests?
[18:05] <zyga-kaveri> are you logged in interactively?
[18:06] <cachio> nI ran the snapd suite
[18:06] <cachio> It is a desktop machine
[18:06] <cachio> the ubuntu user is not logged in afaik
[18:06] <zyga-kaveri> so if it is not logged in, why is there a session for it?
[18:07] <zyga-kaveri> I don't mind adding exceptions if it makes sense
[18:07] <zyga-kaveri> so far we are missing something
[18:07] <zyga-kaveri> are pid 1200 and 1387 both owned by that user>
[18:07] <cachio> I yes
[18:07] <zyga-kaveri> does loginctl list-sessions shows a session for that user?
[18:08] <cachio> dont know why are those pid running, I already rebooted the machine before running the tests
[18:08] <zyga-kaveri> perhaps it has auto-login enabled
[18:08] <cachio>  2 1000 ubuntu   seat0 tty2
[18:08] <zyga-kaveri> so ubuntu is logged in
[18:08] <cachio> yes
[18:09] <zyga-kaveri> is the auto-login enabled for that user in gdm?
[18:09] <cachio> no
[18:10] <zyga-kaveri> I believe this is stored in /etc somewhere but I don't recall the details
[18:10] <cachio> I just checked that in the systemd info
[18:10] <zyga-kaveri> cachio: so if you reboot that machine, tty2 has ubuntu logged in?
[18:10] <zyga-kaveri> not linger
[18:10] <zyga-kaveri> auto-login is a gdm feature
[18:10] <zyga-kaveri> it's not related to systemd
[18:10] <cachio> I'll reboot again the machine and systems
[18:10] <cachio> sorry
[18:11] <cachio> not systemd
[18:11] <cachio> systems settings
[18:12] <cachio> ok, I'll run it again
[18:12] <cachio> after a reboot
[18:12] <cachio> I'll login with the external user
[18:13] <cachio> and validate there is not any user session for ubuntu user
[18:14] <zyga-kaveri> thanks
[18:14] <zyga-kaveri> I'm sure there's something
[18:17] <cachio> zyga-kaveri, what about this one? c1  125 gdm      seat0 tty1
[18:17] <zyga-kaveri> yes, gdm should be allowed
[18:17] <zyga-kaveri> it's easy to filter by user
[18:17] <cachio> zyga-kaveri, ah, ok, nice
[18:26] <mup> PR snapcraft#3148 closed: specifications: environment-manager datastore <specification> <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3148>
[18:47] <ijohnson> pedronis: should we update `snap model` to mention the grade in the default output?
[18:47] <ijohnson> seems like a nice thing to have
[18:48] <ijohnson> also grade is not in --verbose, it should at least be there
[18:49] <pedronis> ijohnson: yes, but also we need to support "snaps"  (vs required-snaps) at some point in verbose
[18:49] <ijohnson> pedronis: ah yeah good point
[18:49] <ijohnson> pedronis: I will throw up a quick PR adding grade to the default model output (if the assertion has it of course), and we can deal with snaps later I think
[18:54] <zyga> cachio I'll review your branch now
[18:54] <cachio> thanks
[18:59] <mup> PR snapd#9252 closed: osutil: add ExchangeFiles <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/9252>
[19:07] <zyga-mbp> cachio: some comments are not replied to or acked
[19:07] <cachio> zyga-mbp, I collected that for the following PR
[19:08] <zyga-mbp> cachio: this is wrong now: https://github.com/snapcore/snapd/pull/9098#pullrequestreview-482124277
[19:08] <mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
[19:08] <zyga-mbp> I mean, it's fine to collect stuff for another PR that requires more work
[19:08] <zyga-mbp> this is a variable with wrong name
[19:08] <zyga-mbp> next to a local with different name
[19:08] <zyga-mbp> so we set a global instead
[19:08] <pedronis> cmatsuoka: I looked again and there is work for us vs using PCR 4, it's done magically by secboot
[19:08] <zyga-mbp> maybe it's correct but it looks fishy
[19:08] <pedronis> cmatsuoka: it's *not* done magically
[19:09] <zyga-mbp> follow-ups are for more complex work or for non-broken things that need tweaks (like the execute -> exec rename) for consistency
[19:10] <cmatsuoka> pedronis: oh ok, let's do it then
[19:10] <pedronis> cmatsuoka: as I said let's finish what we have, but you can start looking atm we are using AddEFISecureBootPolicyProfile, right?
[19:11] <pedronis> (that uses PCR 7)
[19:11] <cmatsuoka> pedronis: yes, we are
[19:11]  * cmatsuoka checks
[19:11] <cachio> zyga-mbp, ok, I'll fix it in a moment
[19:11] <pedronis> cmatsuoka: there's a new AddEFIBootManagerProfile as well in secboot (based on PCR 4) that we need to use as well
[19:12] <cmatsuoka> pedronis: mm ok, I'll have a look
[19:13] <pedronis> it takes the same kind of params
[19:14] <pedronis> not sure if there is something we need to pay particular attention combining things, if it's not obvious we should chat with chris
[19:24] <mup> PR snapd#9276 opened: tests: new backend for desktop and external classic <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9276>
[19:41] <cachio> zyga-kaveri, done
[19:41] <cachio> went 1 by 1
[19:41] <cachio> answered all hte comments
[19:41] <cachio> some of the improvements like the negation one will be included in the following pr
[19:42] <cachio> zyga-kaveri, hold on
[19:42] <cachio> I have to push something else
[19:43] <cachio> github was hidding more comments
[19:46] <cachio> zyga-kaveri, now it is complete for real
[19:46] <cmatsuoka> pedronis: it could be something as simple as PR #9277, but I don't know if there are other constraints there such as order or something like that
[19:46] <mup> PR #9277: secboot: add boot manager profile to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9277>
[19:47] <cachio> zyga-kaveri, there were some comments that github was hidding me so I didn't see those and for that raeson I didnt answer and fixed those
[19:49] <mup> PR snapd#9277 opened: secboot: add boot manager profile to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9277>
[19:58] <zyga-mbp> cachio https://github.com/snapcore/snapd/pull/9098#pullrequestreview-482158127
[19:58] <mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
[20:03] <ijohnson> zyga-mbp: cachio: any objections to squash-merging 9098 ?
[20:04] <ijohnson> it has 58 commits now
[20:04] <zyga-mbp> no, please squash
[20:04] <zyga-mbp> good idea
[20:04] <ijohnson> great yes let's squash
[20:05] <zyga-mbp> vs code + remote extension == bliss
[20:05] <zyga-mbp> this is so amazing
[20:05] <zyga-mbp> microsoft made the best editor
[20:06] <ijohnson> nice, I have been meaning to test out the remote extension but haven't gotten around to it just yet
[20:06] <cachio> zyga-mbp, ijohnson thanks guys
[20:06] <zyga-mbp> the only downside is the proprietary nature which limits the set of architectures
[20:06] <zyga-mbp> so no riscv or ppc builds
[20:07] <zyga-mbp> the real value is in the excellent non-free extensions
[20:07] <ijohnson> I do really like some of the other extensions they have for it, the github one is really good with one kinda big deal-breaker for me which is the lack of the ability to respond to comments in pr's, you just leave a comment generally on the pr, not in response to someone's comment
[20:07] <ijohnson> zyga-mbp: which part is proprietary ? you mean the extensions ?
[20:07] <zyga-mbp> oh, I didn't try that part
[20:07] <zyga-mbp> virtually all microsoft extensions are non-free
[20:08] <zyga-mbp> the editor itself is
[20:08] <zyga-mbp> but the superb extensions are not
[20:08] <ijohnson> ah interesting I didn't realize that
[20:21] <cachio> ijohnson, zyga-kaveri is degraded test failing on your PRs for groovy?
[20:21] <zyga> cachio I saw that failure, yes
[20:22] <ijohnson> cachio: I see it fail sometimes but other times it passes
[20:22] <zyga> we discussed this a few days ago, something related to DBX updates?
[20:22] <ijohnson> yeah dbx related
[20:22] <cachio> zyga, ijohnson I was trying to reproduce it the whole day and I couldn't
[20:23] <ijohnson> cachio: yeah I haven't seen that one fail today actually, but earlier this week I saw it fail, perhaps it was fixed upstream in groovy
[20:24] <cachio> tests errors try to avoid me
[20:24] <cachio> hehhe
[20:24] <ijohnson> haha yeah sounds about right
[20:26]  * zyga EODs but will work on code tomorrow, the export manager is close to doing its job now
[20:40] <bdx> hello, quick question about ulimits and snapped processes
[20:41] <bdx> system level ulimit configuration doesn't seem to apply to my snapped process, is there some additional work I must do in order to ensure the snapped process gets the desired ulimit settings?
[20:41] <bdx> I found https://forum.snapcraft.io/t/how-to-customize-systemd-service-created-by-snapd/18397/2
[20:42] <bdx> which makes me think that I need to apply my ulimit commands at the app level inside of the snap in that case, using a command-chain
[20:43] <bdx> about to start diving in and testing some things, but I thought someone might have a bit of input that will make my journey easier
[20:43] <bdx> :) thx
[20:44] <mup> PR snapd#9275 closed: tests/main: mv core specific tests to core suite <Simple 😃> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9275>