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