[04:10] <mup> PR snapd#9510 opened: tests: new system-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9510>
[05:08] <zyga> good morning
[05:08] <zyga> amurray hey
[05:08] <zyga> I saw your PR, it looked good, I will review it now
[05:08] <zyga> amurray did you hit any bumps on the way? anything that I could have mentioned to make it easier?
[05:08] <amurray> hey zyga  - thanks - I notice the test I added fails on arch - is there an easy way for me to try and debug this locally?
[05:09] <zyga> amurray sadly no, we don't have qemu images of arch
[05:09] <amurray> zyga: no you were really helpful - thanks again
[05:09] <zyga> perhaps mborzecki - who is off for a family wedding today - could help
[05:09] <zyga> you can debug that locally if you have a GCE credentials
[05:09] <zyga> then you can run spread commands locally easily
[05:09] <zyga> I will look at the arch failure now
[05:10] <amurray> I tried to create one locally but I don't have much experience with arch and have spent an hour or so trying to create an image without much success so can't justify much more on that approach...
[05:10] <zyga> amurray btw, can you rebase on master, I think mvo merged some more fixes so we could see a better (more complete) run this time
[05:10] <zyga> yeah, it's hopeless
[05:10] <zyga> there are some helpers
[05:10] <zyga> like the systemd mkosi thing
[05:10] <zyga> but I have not tried using it
[05:10] <zyga> but it'd be my best bet if I were to try
[05:11] <zyga> the problem is that everyone on the core team has google cloud credentials so there's no incentive to improve local testing
[05:11] <zyga> amurray https://wiki.archlinux.org/index.php/Mkosi
[05:13] <amurray> zyga: oh nice - I'll give it a go :)
[05:13] <zyga> amurray it can create various images
[05:13] <zyga> some more easily than others
[05:13] <zyga> but systemd is using it for testing itself
[05:13] <zyga> so it must work somehow: )
[05:13] <amurray> also I just rebased it on master
[05:14] <zyga> thanks!
[05:14] <zyga> eh
[05:14] <zyga> tests are not in a happy place today
[05:14] <zyga> E: Failed to fetch https://packages.microsoft.com/ubuntu/16.04/prod/dists/xenial/main/binary-amd64/Packages  Writing more data than expected (934716 > 934130)
[05:14] <zyga> 66
[05:14] <zyga> oh well, I'll just review what I can
[05:14] <zyga> and thank you so much for the spread test
[05:15] <zyga> that is really really valuable
[05:16] <amurray> that spread test is failing on arch but I fixed it on core-16/18 (and was able to generate a local core-18 qemu image for testing so that was handy)
[05:17] <zyga> amurray btw, why did you use daemon: simple for the apps?
[05:17] <amurray> so they would run automatically on install of the snaps
[05:17] <zyga> it's usually easier to just have apps you run directly
[05:17] <zyga> and observe the failures
[05:17] <amurray> oh ok that makes more sense.. I'll change it then
[05:18] <zyga> in addition, daemon: simple apps are restarted by systemd on failure, no?
[05:18] <zyga> anyway, I'll leave a comment
[05:18] <amurray> perhaps... another good point then for why I should change that :) thanks
[05:25] <zyga> amurray I know why the test failed on arch
[05:25] <zyga> I'll add a comment about that
[05:26] <amurray> zyga: thanks - I couldn't see how to get extra details for it from the github actions output.. is it hidden somewhere?
[05:27] <zyga> you should normally see the full log
[05:27] <zyga> but again, may be limited to committers, I don't know
[05:30] <zyga> amurray please have a look at https://github.com/snapcore/snapd/pull/9509#pullrequestreview-510102726
[05:30] <mup> PR #9509: multipass/docker-support: Mount /etc/apparmor* from the base snap <Created by alexmurray> <https://github.com/snapcore/snapd/pull/9509>
[05:30] <zyga> I'll grab some food and return in 30
[05:31] <zyga> amurray arch didn't work because it doesn't have /snap
[05:31] <zyga> :)
[05:33] <amurray> thanks zyga
[05:52] <zyga> re
[05:53] <zyga> eh, forgot to clean the kitchen last night
[05:53] <zyga> anyway, just coffee
[05:53] <zyga> amurray the test I meant in that comment about base refreshing is more tricky
[05:53] <zyga> amurray you must keep an app running (typically via systemd run for best containment) and then refresh the base (core)
[05:53] <zyga> so that core moves from x1 to x2
[05:54] <zyga> then the mount profile should be different (and we should measure that)
[05:54] <zyga> and ideally, we'd measure that snap-update-ns did not fail, though that is harder
[05:54] <zyga> repackaging core to add a canary file would be easiest but more time consuming at runtime
[05:55] <zyga> but this kind of test will regularly happen for people running multipass, in practice, as bases refresh
[05:55] <zyga> so I'd like to see what we can do
[05:55] <amurray> yep... ok I'll address the other comments and then will come back to that later - can you please put these hints etc in a comment on the PR so I don't forget :)
[05:55] <zyga> amurray sounds good
[05:55] <zyga> amurray yeah, I may try to push that test myself
[05:55] <zyga> so please don't worry about it
[05:55] <zyga> I'm just pointing out why I think it is relevant
[05:55] <zyga> if that part is broken it's like a delayed fuse, it will go off in production
[05:56] <amurray> zyga: yeah that sounds bad - I am more than happy if you want to try and tackle that as a test 😀
[06:00]  * zyga reboots macos for updates
[06:00] <zyga-x240> but I'm also here
[06:01] <amurray> :)
[06:04] <zyga-x240> mvo: good morning
[06:04] <zyga-x240> how are you today?
[06:05] <mvo> good morning zyga-x240
[06:05] <zyga-x240> mvo: tests are not in a happy place, but not because of anything we did
[06:05] <mvo> zyga-x240: good! less crazy, what can I do for you?
[06:05] <zyga-x240> apt cannot fetch the index
[06:05] <mvo> zyga-x240: anything I can review?
[06:05] <zyga-x240> mvo: a 2nd review on https://github.com/snapcore/snapd/pull/9406 would be great
[06:05] <mup> PR #9406: many: allow ignoring running apps for specific request <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9406>
[06:06] <zyga-x240> it's +1 by samuele and is fairly short
[06:06] <zyga-x240> I've restarted some tests, the Azure ubuntu mirror has some issues
[06:06] <mvo> zyga-x240: cool, will do
[06:06] <zyga-x240> so the unit tests task fails early
[06:07] <zyga-x240> mvo: amurray has mostly fixed the apparmor 3 transition issue, we've just discussed some test improvements
[06:08] <zyga-x240> so not sure if there's a .1 coming but that would be my candidate
[06:11] <mvo> zyga-x240: ok
[06:12]  * amurray relocates.. back in 20mins
[06:12] <zyga-x240> o/
[06:22] <zyga> re
[06:28] <zyga> thanks for the review!
[06:34] <zyga-x240> ... value *errors.errorString = &errors.errorString{s:"cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure"} ("cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure")
[06:34] <zyga-x240> but at least the apt error is gone
[06:42] <zyga> I resolved conflicts on https://github.com/snapcore/snapd/pull/9446
[06:42] <mup> PR #9446: overlord,usersession: initial notifications of pending refreshes <Created by zyga> <https://github.com/snapcore/snapd/pull/9446>
[06:43] <zyga> I think that could land soon but needs a 2nd review too :)
[06:43] <zyga> oh,sorry, 1st review actually
[06:57] <zyga> mvo https://github.com/snapcore/snapd/pull/9507 can probably force-land
[06:57] <mup> PR #9507: overlord/snapshotstate/backend: specify tar format for snapshots <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9507>
[07:00] <zyga> mvo https://github.com/snapcore/snapd/pull/9502#pullrequestreview-510201180 is an easy win
[07:00] <mup> PR #9502: tests: more output for sbuild test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9502>
[07:05] <pstolowski> morning
[07:10] <zyga> pstolowski good morning
[07:10] <zyga> pstolowski I reviewed https://github.com/snapcore/snapd/pull/9501#pullrequestreview-510201666
[07:10] <mup> PR #9501: [RFC] wrappers: do not error out on read-only /etc/dbus-1/session.d filesystem on core18 <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9501>
[07:11] <pstolowski> thanks!
[07:13] <zyga> amurray https://github.com/snapcore/snapd/pull/9509#pullrequestreview-510208169
[07:13] <mup> PR #9509: multipass/docker-support: Mount /etc/apparmor* from the base snap <Created by alexmurray> <https://github.com/snapcore/snapd/pull/9509>
[07:13]  * zyga is on a review spree today
[07:16] <amurray> thanks (I keep forgetting to run spread-shellcheck...)
[07:23] <amurray> zyga: ok with any luck that should take care of your review comments - thanks again for taking the time to help me with this - let me know if you want me to squash these all down to just a few commits or not and if there is anything else need to do
[07:27] <amurray> ok I am going eod - thanks again zyga, I may be back later tonight but otherwise will catch up on scrollback next week
[07:53] <zyga> re
[07:54] <zyga> amurray not squashing is fine, I think that's okay
[07:54] <zyga> amurray perhaps mvo will decided to squash
[07:54] <zyga> amurray see you next week, thanks!
[07:54] <zyga> I'll push a test for the base refresh test into your branch later
[07:54] <zyga> amurray: have a lovely weekend!
[07:54] <mvo> zyga what PR?
[07:55] <zyga> mvo: https://github.com/snapcore/snapd/pull/9509
[07:55] <mup> PR #9509: multipass/docker-support: Mount /etc/apparmor* from the base snap <Created by alexmurray> <https://github.com/snapcore/snapd/pull/9509>
[08:01] <mup> PR snapd#9511 opened: o/snapstate: re-order remove tasks for individual snap revisions to remove current last <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9511>
[08:02] <zyga> pstolowski do you think we can re-order assertion vs snap download to fetch assertions before pulling, potentially huge snap?
[08:03] <pstolowski> zyga: theoretically yes, but i don't know the details of the code and don't know how easy or difficult that would be
[08:03] <zyga> ok
[08:03] <zyga> I was hoping it's swapping two tasks around as those seem to have distinct descriptions in a snap change
[08:04] <pstolowski> yeah, bth i don't remember if it's that simple or not
[08:04] <zyga> ok
[08:06] <pstolowski> *tbh
[08:18] <pstolowski> zyga: do you have a moment for HO? i'd like to talk about undo & interfaces
[08:21] <mvo> zyga: looking
[08:28] <zyga> sure, I need a moment
[08:31] <zyga> pstolowski standup?
[08:36] <mvo> zyga, amurray are you okay with me squash merging 9509 ?
[08:36] <zyga> yes
[08:36] <mvo> so that I can cherry pick into 2.47?
[08:36] <mvo> cool
[08:36] <zyga> mvo but it's not fully ready yet, I will work on that later today
[08:36] <mup> PR snapd#9406 closed: many: allow ignoring running apps for specific request <Needs Samuele review> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9406>
[08:36] <mvo> zyga do you know what the expectation is, should this go into groovy today so that there is a chance for it to be in the image?
[08:37] <zyga> hmmmm
[08:37] <zyga> I wanted to add a critical test
[08:37] <zyga> otherwise it's a risk of regression later
[08:37] <zyga> as in, it could be wrong now and we don't know
[08:37] <mvo> zyga ok, sure, let chat in a bit (I think you are in a HO right now :) ?
[08:37] <zyga> not that it is okay now but breaks later
[08:37] <zyga> yes
[08:37] <zyga> waiting for pawel
[08:37] <zyga> so hop in
[08:37] <zyga> and I'll explain
[08:38] <mvo> zyga let's chat when you are done, I don't want to interrupt you guys :)
[08:38] <zyga> he's afk for a moment
[08:38] <zyga> so hop in :)
[08:42] <zyga> pstolowski hop in :)
[08:54] <amurray> mvo: yep that's fine with me (squashing) - I just realised I used 'not' incorrectly in the task.yaml so I just pushed one more commit to fix that
[09:15] <mvo> amurray: thanks for this! zyga works on one additoinal spread test and then this should be good to go (sorry for the delay, was in a meeting)
[09:16] <zyga> yep
[09:18] <amurray> mvo zyga: I have one more commit in-the-works to try and fix the failures due to aa-status not existing on other distros... (I am changing it to use the one from the core snap)
[09:18] <zyga> ok
[09:18] <zyga> oh
[09:18] <zyga> as in /etc has no apparmor.d*
[09:18] <zyga> hmmmmm
[09:18] <zyga> this may be a more complex problem
[09:19] <zyga> as you know, we share host /etc
[09:19] <zyga> so we may not be able to easily create that directory
[09:19] <zyga> we could do a writable mimic on /etc to do that
[09:19] <zyga> I think we should
[09:19] <zyga> (I mean automatically0
[09:19] <zyga> but I'll wait for you to finish
[09:22] <amurray> zyga: no I don't think that is it - it is just that in task.yaml I try and run aa-status to see if the profile got loaded but it doesn't exist - so instead I am going to run /snap/core/current/sbin/aa-status to look for it
[09:22] <zyga> right
[09:22] <zyga> amurray will that work if you don't have libapparmor?
[09:22] <zyga> e.g. centos 7
[09:22] <zyga> perhaps on systems without apparmor we should just test that we don't fall over entirely
[09:23] <zyga> but not measure apparmor (which is not present anyway)
[09:24] <zyga> mvo https://github.com/snapcore/snapd/pull/9498#pullrequestreview-510207396
[09:24] <mup> PR #9498: client,daemon,snap: auto-import does not error on managed devices <Needs Samuele review> <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9498>
[09:24] <amurray> hmm perhaps, I am not sure.. I've gotta run now so feel free to run with this however you feel is good - I'll try check back again later
[09:24] <zyga-x240> ok
[09:34] <mvo> zyga \o/
[09:38] <pedronis> mvo: zyga: https://github.com/snapcore/snapd/pull/9498#discussion_r506109937
[09:38] <mup> PR #9498: client,daemon,snap: auto-import does not error on managed devices <Needs Samuele review> <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9498>
[09:52]  * zyga afk
[10:07] <amurray> mvo: sorry one more commit incoming on PR #9509 to try and make this use of aa-status in the regression test a bit more robust so hold off on squashing/merging for a bit - then with any luck the test should be more reliable on non-ubuntu platforms
[10:07] <mup> PR #9509: multipass/docker-support: Mount /etc/apparmor* from the base snap <Squash-merge> <⚠ Critical> <Created by alexmurray> <https://github.com/snapcore/snapd/pull/9509>
[10:08] <pedronis> pstolowski: I reviewed #9511,  also what is blocking #9391 ?
[10:08] <mup> PR #9511: o/snapstate: re-order remove tasks for individual snap revisions to remove current last <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9511>
[10:08] <mup> PR #9391: o/assertstate: introduce ValidationTrackingKey/ValidationSetTracking and basic methods <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9391>
[10:08] <zyga> re
[10:09] <pstolowski> pedronis: thanks
[10:10] <pstolowski> pedronis: merged 9391, sorry i missed it
[10:12] <mup> PR snapd#9391 closed: o/assertstate: introduce ValidationTrackingKey/ValidationSetTracking and basic methods <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9391>
[10:15] <pedronis> pstolowski: thx
[10:15] <pedronis> mvo: should we archive the 2.46 lane and create 2.48 ?
[10:15] <pedronis> (in the trello board)
[10:17] <mvo> pedronis: yes
[10:17] <pstolowski> zyga: do you have a moment for https://github.com/snapcore/snapd/pull/9511 (simple, needs 2nd review)?
[10:17] <mup> PR #9511: o/snapstate: re-order remove tasks for individual snap revisions to remove current last <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9511>
[10:17] <zyga> yes
[10:17] <pstolowski> ty
[10:17] <zyga> I had it open but was digging into other tasks
[10:20] <zyga> pstolowski LGTM
[10:21] <zyga> I was confused for a second because I though the intent was to reverse the sequence
[10:21] <zyga> but I think this is fine
[10:21] <zyga> +1
[10:22] <pstolowski> thanks
[10:22] <pedronis> because of blocked revision, current is not always the top
[10:23] <zyga> mmm, I see
[10:25] <pedronis> mvo: done
[10:25] <mvo> ta
[10:28] <pedronis> mvo: the bug in https://trello.com/c/OnPCcZSM/342-https-bugslaunchpadnet-ubuntu-cosmic-source-snapd-bug-1825298 seems wrong ?
[10:29] <mvo> pedronis: looking
[10:29] <pedronis> or I'm confused
[10:29] <pedronis> I'm missing the relation with zfs there
[10:30] <pedronis> for sure is not mentioned in the bug itself
[10:30] <mvo> pedronis: the comment is wrong, the bug was real at some point, not sure if it still is
[10:30] <mvo> yeah, the comment is bogus
[10:31] <pedronis> I would archive that card, unless we plan to do something, the bug still exist as bug
[10:31] <pedronis> and create a different card about testing with zfs
[10:31] <pedronis> mvo: ^
[10:32] <zyga> mvo FYI: there's an optional include syntax in apparmor
[10:32] <zyga> but not sure if available all the way back
[10:41] <mvo> pedronis: sorry for the delay - yes, card about zfs would be good
[10:52] <zyga-x240> https://github.com/snapcore/snapd/pull/9204 should pass on this iteration
[10:52] <mup> PR #9204: sandbox: track applications unconditionally <Created by zyga> <https://github.com/snapcore/snapd/pull/9204>
[10:52] <zyga-x240> I will need to prepare some more things there
[10:53] <zyga-x240> mvo: I will pick up Alex's PR now
[10:53] <zyga-x240> pedronis: I updated https://github.com/snapcore/snapd/pull/9422 - if you have some time to give it another look it would be great to get going on export manager
[10:53] <mup> PR #9422: overlord: add link participant for linkage transitions <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9422>
[11:01] <pedronis> zyga-x240: yes, I will look at it after lunch, hopefully before the standup
[11:01] <zyga-x240> thanks!
[11:02] <zyga-x240> the remaining part of export manager is large but this is crucial to make progress
[11:02] <rogpeppe> zyga: FYI that raspberry pi went down again the day before yesterday, and still required two power cycles to bring it up again
[11:03] <zyga-x240> rogpeppe: yes, that was our doing
[11:03] <zyga-x240> rogpeppe: thank you for rebooting it
[11:03] <rogpeppe> zyga-x240: ah, np
[11:03] <zyga-x240> rogpeppe: we have more ideas but we are exploring them locally
[11:03] <zyga-x240> rogpeppe: we should have more information later on
[11:03] <rogpeppe> zyga-x240: sorry, i had to reboot my computer and forgot to restart my IRC client if you were trying to get in touch
[11:03] <zyga-x240> rogpeppe: that's okay, you are really the most helpful bug reporter we ever had
[11:04] <rogpeppe> zyga-x240: i've very glad to be of help.
[11:04] <rogpeppe> i'm
[11:05] <zyga-x240> rogpeppe: some fixes for the bugs we discovered while analyzing your device are already fixed
[11:05] <zyga-x240> rogpeppe: some more are in progress
[11:05] <zyga-x240> rogpeppe: I sent you a message the other day
[11:05] <rogpeppe> zyga-x240: in which messaging medium?
[11:06] <zyga-x240> rogpeppe: I'm not sure if you are willing to do this, but buying a low-cost USB-TTL adapter would allow you to collect boot logs that will show what happens when the device fails to reboot for update
[11:06] <zyga-x240> rogpeppe: here on IRC
[11:06] <zyga-x240> it was an amazon UK link
[11:06] <zyga-x240> I can find that again
[11:06] <zyga-x240> it's a USB-to 3.3V serial port adapter
[11:06] <zyga-x240> just a cable you plug into a laptop
[11:07] <zyga-x240> open screen/minicom/putty and collect the serial logs on "snap refresh core18"
[11:07] <zyga-x240> we'd know exactly what fails
[11:07] <zyga-x240> if you could do that that would be amazing
[11:07] <zyga-x240> but if not we are re-creating that environment here, I should have some answers today
[11:08] <rogpeppe> zyga-x240: if you could provide detailed instructions for doing that on a windows machine, that would be very helpful - then i can walk my dad through doing it, maybe this weekend
[11:08] <zyga-x240> yes, that's totally fine (I mentioned putty for a reason)
[11:09] <zyga-x240> rogpeppe: it requires a hardware attachment, you'd have to purchase that and your dad would have to have it
[11:11] <rogpeppe> zyga-x240: if you sent the link by PM on IRC, i don't think i got it. i can't find it in my logs anyway.
[11:11] <zyga-x240> let me find it again
[11:12] <zyga-x240> rogpeppe: this looks sensible: https://www.amazon.co.uk/DSD-TECH-adapter-FT232RL-Compatible/dp/B07BBPX8B8/ref=sr_1_11_sspa?dchild=1&keywords=USB+TTL&qid=1602846716&sr=8-11-spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUEyUU41UjZVS0hGUTQ4JmVuY3J5cHRlZElkPUEwMTQ5NjIzMk1BOUJPSVUyT05VQyZlbmNyeXB0ZWRBZElkPUEwMzQxMzE2MTBRNTlWTTlEN0FMNiZ3aWRnZXROYW1lPXNwX210ZiZhY3Rpb249Y2xpY2tSZWRpcmVjdCZkb05vdExvZ0NsaWNrPXRydWU=
[11:12] <zyga-x240> it should work out of the box on windows
[11:13] <zyga-x240> we'd only need that, a laptop and putty you can download easily
[11:13] <rogpeppe> how do you connect that to the pi?
[11:13] <zyga-x240> rogpeppe: there are wires you connect to the pins on the GPIO header
[11:13] <zyga-x240> with the ethernet port on the bottom left
[11:14] <zyga-x240> you take the row of pins on the right
[11:14] <zyga-x240> there are two columns of pins
[11:14] <zyga-x240> the right column is the one we need
[11:14] <zyga-x240> skip the first two pins from the top, they supply power
[11:15] <zyga-x240> the next pin is ground, connect it to the adapters GND pin with the wire
[11:15] <zyga-x240> (the adapter has a jumper that can select 5V or 3.3V mode, we need the 3.3V mode for pi)
[11:15] <zyga-x240> the next two pins are TX/RX
[11:15] <zyga-x240> just plug the wires to the corresponding pins on the USB adapter
[11:15] <rogpeppe> zyga-x240: if you could find a diagram, that would be very helpful
[11:15] <zyga-x240> yeah, it's very well documented
[11:16] <rogpeppe> zyga-x240: i think i should probably order it here and try it out myself before attempting to get someone to do it remotely with no visuals :)
[11:16] <zyga-x240> that's a good idea
[11:17] <rogpeppe> ok, it should arrive here tomorrow.
[11:18] <zyga-x240> that's quick, we can sync tomorrow, just send me a message
[11:18] <zyga-x240> the good way to check if it works is to reboot a pi
[11:18] <zyga-x240> there's all kinds of log messages shown
[11:18] <zyga-x240> on windows you need putty 115200, 8N1, no hardware flow control
[11:18] <zyga-x240> on linux screen /dev/ttyUSB0 115200 is equivalent
[11:22] <mup> PR snapd#9036 closed: snapshots: import of a snapshot set <Needs Samuele review> <Skip spread> <Created by slimjim777> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9036>
[11:22] <mup> PR snapd#9506 closed: boot: skip some unit tests when running as root <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9506>
[11:31] <zyga-x240> amurray: can you rewrite your history to use canonical email address?
[11:31] <zyga-x240> mvo: ^ some annoyance to overcome
[12:02] <mup> PR snapd#9511 closed: o/snapstate: re-order remove tasks for individual snap revisions to remove current last <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9511>
[12:03] <zyga-x240> brb
[12:19] <mvo> zyga-x240: we just squash merge
[12:19] <mvo> zyga-x240: I mean, that should be fine, no?
[12:36] <pedronis> mvo: zyga-x240: I fear #9422 doesn't do anything atm so should be fine, but it shows some problems that will need some snapstate fixes that might be a bit risky before 2.48
[12:36] <mup> PR #9422: overlord: add link participant for linkage transitions <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9422>
[12:37] <mup> PR snapd#9502 closed: tests: more output for sbuild test <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9502>
[12:42] <mup> PR snapd#9469 closed: snapshots: import of a snapshot set <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9469>
[12:45] <zyga-x240> pedronis: ack
[12:45] <zyga-x240> pedronis: I'll read your review
[12:46] <zyga-x240> mvo: hmmm, I guess that solves the problem, yes
[12:51] <marcustomlinson> hey, does Arch Linux keep snaps somewhere other than /snap? looks like /var/lib/snapd/snap/?
[12:53] <zyga> marcustomlinson correct
[12:53] <marcustomlinson> I see thanks
[12:55] <marcustomlinson> zyga: is the home directory structure the same though? i.e. ~/snap/blah
[12:56] <zyga> marcustomlinson yes, it is the same everywhere
[12:56] <marcustomlinson> thanks!
[12:56] <zyga> my pleasure :-)
[13:28] <zyga-x240> CHURN CHURN CHURN INSERT DISK INTO DRIVE A
[13:32] <mup> PR snapd#9501 closed: wrappers: do not error out on read-only /etc/dbus-1/session.d filesystem on core18 <Bug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9501>
[13:34] <ogra> zyga-x240, shoudnt that be "DISK 1/12" ?
[13:35] <zyga-x240> mvo: how much data did you have to process?
[13:37] <mvo> zyga-x240: how much data?
[13:41] <zyga> that localization thing you mentioned
[13:43] <mvo> zyga: the apt-ddtp stuff? it's not small, maybe a gig of distro release to churn through but a lot of redundant things of course
[13:43] <mvo> zyga why do you ask :) ?
[13:44] <zyga> to compute the number of floppy disks needed for ogra ;)
[13:44] <mvo> hahaha
[13:47] <zyga> mvo I won't make it with that PR today, it requires a few more hours of careful coding and testing
[13:47] <zyga> mvo is it okay if we have it by Monday?
[13:49] <mvo> zyga yes
[13:49] <zyga> ok
[13:49] <zyga> I just don't want to rush it
[13:49] <mvo> zyga I would prefer sooner but if it does not happen it does not happen
[13:49] <mvo> zyga I will let sil2100 know
[13:49] <zyga> it should be a connected plug for most sensibility but that also changes how the service starts
[13:49] <zyga> because we IIRC first start then auto-connect (if no then  that's less of a problem)
[13:49] <zyga> ok
[13:57] <zyga-x240> mvo: I've added my analysis to https://github.com/snapcore/snapd/pull/9509#pullrequestreview-510495945
[13:57] <mup> PR #9509: multipass/docker-support: Mount /etc/apparmor* from the base snap <Squash-merge> <⚠ Critical> <Created by alexmurray> <https://github.com/snapcore/snapd/pull/9509>
[13:57] <zyga-x240> I'll fix it today, just not in the next 30 minutes
[13:59] <pedronis> zyga-x240: not sure it's useful but we run setup-profiles twice for core and snapd though
[13:59] <pedronis> also it seems I will to review this
[13:59] <zyga> indeed
[13:59] <zyga> thanks, I'll add a comment when I'm done
[14:54] <zyga> I'll make one last coffee of the day, vent the office and take a 30 minute break
[14:54] <zyga> then back to finish this
[15:52] <zyga> re
[15:52] <zyga> back to coding
[16:10]  * cachio lunch
[16:22] <mbeierl> Is it possible to allow a snap to read a file that I have mounted on NFS in an arbitrary locations?  I have an NFS mount under ~/, but of course get permission denied when using a snap to read a file from there
[16:24] <zyga> mbeierl under /home?
[16:24] <zyga> mbeierl it should work, unless we mis-detected nfs
[16:24] <zyga> mbeierl if we detect nfs mounts we enable a special mode that compensates for that
[16:24] <zyga> mbeierl but regular restrictions apply, e.g. snaps need to connect the home interface to access files in home
[16:24] <mbeierl> let me give a quick test with jq (as it's simple) to make sure.  This is with my osmclient snap and I may have missed something there
[16:25] <zyga> mbeierl if you have a moment, could you tell me two things:
[16:25] <zyga> mbeierl: dmesg | grep DENIED
[16:25] <zyga> mbeierl and how you've set up NFS to be mounted (systemd unit, fstab, something else)
[16:27] <mbeierl> A few denied: https://pastebin.ubuntu.com/p/pDq9djmsdy/
[16:28] <zyga> ah, hgfs (vmware)
[16:28] <zyga> but is that the thing being denied? or is there an actual NFS there as well?
[16:28] <mbeierl> And I was wrong.  This is not NFS, this is VMware hgfs (host/guest virtual filesystem)
[16:29] <zyga> okay
[16:29] <zyga> hgfs is mounted in /mnt/hgfs
[16:29] <zyga> we don't have any official support for that
[16:29] <zyga> but we can think of adding some
[16:29] <mbeierl> odd.  jq works, but my snap does not, so I need to double check on that
[16:29] <zyga> could you please report a quick bug for that on launchpad.net/snapd/
[16:29] <zyga> it won't be tomorrow but we can sort this out, I suspect
[16:29] <zyga> as a variant of home interface mode
[16:30] <mbeierl> but jq works, so I think it is the way I set up and published the osmclient snap, so I will do a comparison of the two first
[16:30] <zyga> especially that it is quite common
[16:30] <zyga> ok
[16:31] <mbeierl> I just jumped the gun, as I had a problem with jq like 6 months back and it did not work back then on NFS.  Things have changed, but I did not keep up, so let me make sure I really have a bug here and not pebkac
[16:31] <zyga> :D
[16:31] <zyga> I fixed a few more variants of nfs support
[16:31] <zyga> I'd love if you could confirm there is nothing more
[16:31] <zyga> or tell me what I've missed
[16:33] <mbeierl> zyga, ok I am stumped.  jq has no connections?  How is this magic done then?
[16:38] <mup> PR snapd#9512 opened: o/snapstate: move setting updated SnapState after error paths <Created by pedronis> <https://github.com/snapcore/snapd/pull/9512>
[16:39] <mbeierl> I can confirm: my osmclient snap works with NFS, just not HGFS.  The jq snap works with reading files from both
[16:48] <mup> PR snapd#9504 closed: many: verify that unit tests work with nosecboot tag and without secboot package <Run nested> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9504>
[16:53] <mup> PR snapd#9449 closed: interfaces: PTP hardware clock interface <Needs security review> <Created by slimjim777> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9449>
[16:53] <mup> PR snapd#9498 closed: client,daemon,snap: auto-import does not error on managed devices <Needs Samuele review> <Run nested> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9498>
[16:53] <mup> PR snapd#9503 closed: tests: use tests.backup tool <Run nested> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9503>
[17:19] <mup> PR snapd#9420 closed: tests/nested/manual/minimal-smoke: use 384MB of RAM for nested UC20 <Run nested> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9420>
[17:38] <zyga> mbeierl re
[17:38] <zyga> sorry, I had to go away
[17:39] <zyga> mbeierl what is the jq command you invoked?
[17:39] <zyga> mbeierl please report the bug about hgfs, I'll try to do something about that, I'm also using vmware often for things like that
[17:53]  * cachio afk
[18:19] <mup> PR snapd#9507 closed: overlord/snapshotstate/backend: specify tar format for snapshots <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9507>
[18:24] <mup> PR snapd#9513 opened: snapshotstate: detect duplicated snapshot imports <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9513>
[18:32] <zyga> d'ohhhh
[18:32] <zyga> drat
[19:02] <mbeierl> zyga, simply jq /mnt/hgfs/home/test.json and it is able to read the file.  snap connections jq shows no connections
[19:10] <zyga> mbeierl can you share your "snap version" please?
[19:10] <mbeierl> zyga, https://pastebin.ubuntu.com/p/3Mk9zyHzVF/
[19:11] <zyga> that is really interesting!
[19:11] <mbeierl> jq                   1.5+dfsg-1              6      latest/stable    canonical✓      -
[19:11] <mbeierl> how so?
[19:11] <zyga> can you pastebin /var/lib/snapd/apparmor/profiles/snap.jq.jq
[19:11] <zyga> because without connections, what should be granting access to hgfs?
[19:12] <mbeierl> http://paste.ubuntu.com/p/mRdWqZ8S7v/
[19:12] <zyga> this looks correct
[19:12] <zyga> was it really just
[19:12] <zyga> jq /mnt/hgfs/home/test.json
[19:12] <zyga> or
[19:12] <zyga> jq < /mnt/hgfs/home/test.json
[19:12] <zyga> and perhaps most importantly
[19:12] <zyga> command -v jq
[19:13] <zyga> is it /snap/bin/jq?
[19:13] <zyga> or something else?
[19:14] <mbeierl> https://pastebin.ubuntu.com/p/J6WJWngFZD/
[19:14] <mbeierl> command -v jq => /snap/bin/jq
[19:15] <zyga> hmm
[19:15] <mbeierl> I know... it's got me confused
[19:15] <zyga> and jq < test.json?
[19:15] <mbeierl> no message, no output
[19:15] <zyga> dmesg | grep DENIED
[19:16] <zyga> perhaps it was rejected?
[19:16] <mbeierl> wait - I added content to test.json so jq would have something to do, and it worked as expected, no denied
[19:16] <zyga> well, technically without an interface that bridges /mnt, it just doesn't exist from that snap point of view
[19:20] <mbeierl> zyga, I am silly.  jq syntax error.  I forgot the ".", so: jq . test.json gives me permission denied finally
[19:20] <zyga> ahhh
[19:20] <zyga> okay, no alarm then
[19:20] <zyga> :D
[19:21] <zyga> mbeierl does jq have any interfaces?
[19:21]  * zyga checks himself
[19:22] <zyga> nope
[19:22] <zyga> someone would have to add an interface to it
[19:22] <mbeierl> side note: jq works on the NFS share, which again is odd with no connections
[19:22] <zyga> to read stuff from removable media and other places
[19:22] <zyga> mbeierl where is that share?
[19:22] <zyga> but yes, it is odd
[19:22] <mbeierl> I have nfs mount /home/mark/git.  So it's under home
[19:23] <zyga> indeed