[02:39] PR snapcraft#1818 closed: meta: create XDG_RUNTIME_DIR in wrappers [03:06] PR snapcraft#1821 opened: tests: use a simpler test for bzr and python [04:55] PR snapd#4416 opened: tests: performance measurements for basic snapd commands [06:11] morning [06:32] mvo: morning [06:32] hey mborzecki, good morning! [06:33] mvo: i was playing a bit with interfaces-fuse_support test yesterday, and we may have a bigger problem at hand [06:34] mborzecki: oh? tell me more [06:34] the 'create' will try to remove fuse mount when you kill it [06:35] it tries 2 things, first it attempts to do an unmount and if that fails it will try to run fusermount -u [06:35] and it works nicely like this when I run it on my laptop [06:36] when running as snap, it gets a 'bad system call' and shuts down without cleaning the mount point [06:36] mborzecki: ohhhh [06:36] mborzecki: so a confinement issue! [06:36] the mount point is still visible in mount namespace of the snap, and any attempts to fusermount -u end up with a 'bad system call' [06:37] mborzecki: interessting [06:37] yeah, i'd like to try strace today and see where it fails exactly [06:37] mborzecki: whats slightly odd is that it appears the test sometimes works and sometimes dosn't [06:37] mborzecki: sounds great, thanks for looking into this [06:37] i think there are 2 things [06:38] the mount point in mount namespace, don't know if it's a problem during the cleanup (maybe not?) [06:38] and the other thing is that create command forks like 3-4 times [06:39] `ps aux | awk '/[t]est-..` is called right after running the command, so it's possible that we may pick up the forks [06:39] * mvo nods [06:39] mborzecki: yeah, thats interessting as well [06:41] mvo: otoh, is it possible to force a specific order of tests in spread (given 1 worker)? [06:42] mborzecki: yes, it prints something like "use -seed=1234" at the start [06:42] mborzecki: this way you can re-create the order [06:42] mborzecki: afaik you cannot force a specific order in the sense of run test: "a,b,c" [06:43] ah, ok [06:47] PR snapd#4410 closed: tests: make journalctl check wait a bit for output [06:49] PR snapd#4417 opened: tests: fix catalog-update wait loop [06:59] mvo: https://paste.ubuntu.com/26219568/ apparently we pick up snappy-app-dev helper too [07:06] mvo: https://paste.ubuntu.com/26219598/ SIGSYS [07:21] mborzecki: hm, interessting, smells like seccomp [07:27] mvo: fixed seccomp rules by hand, added umount2, compiled with snap-seccomp and the mount point gets cleaned up properly now, though I'm not sure jdstrand will be happy about that [07:29] mborzecki: what interface is the test currently using? [07:29] fuse-support [07:29] * mvo nods [07:32] mborzecki: hm, I think if we extend the interface and allow umount/umount2 in seccomp and add an appamror umount fstype=fuse.* rule that should be ok [07:32] mborzecki: afaict apparmor supports umount restrictions [07:32] mborzecki: plus it seems odd that we give people the ability to fuse-mount stuff but not umount this again :) [07:34] mvo: afaiu it goes like this: libfuse tries unmount2 -> gets -EPERM -> tries setuid fusermount helper (fusermount -u mborzecki: right, except thta in our case we don't get EPERM but SIGSYS [07:34] but in our case it's, umount2 -> SIGKILL (seccompt) [07:35] yup [07:35] * mvo nods [07:35] mborzecki: so we could probably just allow the syscall and apparor would deny [07:35] mborzecki: and then things would work as apparmor give eperm [07:35] btw. i don't see any support for specifying alternative action in snap-seccomp rules :) [07:36] mborzecki: alternative action like what? [07:37] mborzecki: eperm instead of sigsys? [07:37] errno [07:37] right [07:37] there is a PR for that https://github.com/snapcore/snapd/pull/3998 [07:37] PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features [07:38] mborzecki: well, not *exactly* what you want, its still not configurable but switches to errno [07:38] right [07:49] mborzecki: please let me know if I should help with the interface update [07:50] mvo: is fuse-consumer apparmor profile kept in the filesystem? [07:51] good morning ^_^ [07:51] kalikiana: morning [07:51] hey mborzecki [07:53] mborzecki: yes, it should be there in /var/lib/snapd/profiles/apparmor [07:54] mborzecki: ups, the other way around /var/lib/snapd/apparmor/profiles [07:54] mborzecki: you will need to "sudo apparmor_parser -r /path/.../file" load it [07:54] mborzecki: (if you modify it) [07:56] mvo: hm i may be missing something, the plug is connected, but snap.test-snapd-fuse-consumer.create profile does not contain any rules from fuse_support.go [07:59] mborzecki: hm, strange. what distro/release are you on right now? [08:00] our spread debian-sid image [08:00] mborzecki: hm, that should be fully apparmor supported [08:00] uhh `Dec 20 06:42:24 debian snapd[8236]: AppArmor status: apparmor is enabled but some features are missing: dbus, mount, network, signal` [08:01] mborzecki: it will depend on your kernel [08:02] or should, 4.13 has ptrace, 4.14 signal and mount, unfortunately there were problems with 4.14 so network and dbus didn't make it [08:02] mborzecki: aha, I think in this case we just enable "partial" support, which irrc means we confine snap-confine itself but not not apply full confinement for the snaps [08:02] those will be tried again in 4.1 [08:02] thanks jjohansen [08:02] make that 4.16 [08:03] jjohansen: ta [08:03] mvo: yeah, the rules are listed for ubuntu 16.04 image [08:06] mvo: take that back, i can see that the profile has some/many rules, but none of the fuse specific ones we have in the source code [08:07] mborzecki: hm, that is odd, let me see [08:07] mvo: nvm, got it now, damn, forgot that the interface was not connected yet [08:09] mborzecki: aha, good :) I was worried for a second [08:37] mvo: ok, eveything seems to work fine, i've punched rule through seccomp (whitelisted umount2) and apparmor (umount fstype=fuse.* ) [08:37] the spread test should be fixed as well [08:48] mborzecki: yay [08:48] mborzecki: thanks for finding this! [09:24] * sergiusens waves from the early morning [09:25] PR snapcraft#1821 closed: tests: use a simpler test for bzr and python [10:05] PR snapd#4413 closed: tests/main/postrm-purge: stop snapd before purge [10:06] PR snapd#4390 closed: tests: change interfaces-fuse_support to be debug friendly [10:13] * kalikiana coffee break [10:29] mvo_: since #4390 was merged, if you don't mind, i'll rebase #4414 on top of master [10:29] PR #4390: tests: change interfaces-fuse_support to be debug friendly [10:29] PR #4414: tests/main/interfaces-fuse_support: workaround multiple matching processes [10:29] mborzecki: sure === __chip__ is now known as Chipaca [10:37] mvo_: hello from the south of france :-D [10:38] Chipaca: hello my friend! great to see you, I hope you are just here to make us jealous :) ? I assume you are on vac? [10:38] mvo_: I am on vac, yes [10:38] Chipaca: how many degrees today? :) [10:38] Chipaca: send us a picture of beautiful sun or something :) [10:39] mvo_: but this Walk thing which i started as a friday bugged me so i pushed a fix [10:39] it's a cold 9C today, terrible === daniellimws is now known as Guest79825 === dows is now known as daniellimws [10:41] mvo_: mborzecki: yesterday, https://i.imgur.com/DM3GLCO.jpg [10:41] that's in the woods around Valbonne [10:41] nice [10:42] Chipaca: looks great! [10:42] mvo_: are the tests still mostly failing? [10:44] Chipaca: *slightly* better but still pretty bad, but some progress [11:20] mvo_: i've updated #4414 [11:20] PR #4414: tests/main/interfaces-fuse_support: fix confinement, allow unmount, fix spread tests [11:30] mborzecki: very nice, thank you [11:36] mborzecki: I requested a review from jdstrand for 4414, he will be the right person to double check the apparmor rules [11:36] mvo_: great, thanks [11:37] mvo_: have you seen this? https://forum.snapcraft.io/t/yocto-rocko-core-snap-kernel-panic/3261 [11:42] > github.com/snapcore/snapd/overlord/state.(*State).writing(0xe3f) [11:42] Mornings [11:42] *State address looks bogus [11:42] niemeyer: hey [11:43] hey niemeyer [11:43] mborzecki: yeah, "writing(0xe3f)" looks suspicious [11:46] Bug #1623125 changed: fixrtc script does not catch "Last mount time: n/a" string (Ubuntu Xenial):New> [11:46] mborzecki, mvo_: o/ [11:46] cachio__: I've just updated the travis spread binary to drop support for compression.. let's see if it makes any difference [11:47] mborzecki: your reply seems to be the best option - maybe we can figure out more with the image [12:02] Chipaca: Are you working today? [12:03] niemeyer: not unless you count pushing code to github as working [12:03] Chipaca: I'm wondering if you'd have any insights about this issue: https://forum.snapcraft.io/t/yocto-rocko-core-snap-kernel-panic/3261 [12:04] Chipaca: The reason why I'm asking you specifically is because the segfault comes from the progress bar [12:04] Which was touched recently, so seems suspect [12:04] niemeyer: i'll take a look (not now though) [12:04] Chipaca: Thanks! [12:08] mborzecki: You've asked for some information on that thread.. did you dig through the traceback to have an idea of what was going on? [12:09] (mostly wondering about what we know) [12:14] niemeyer: from what i understand there may be 2 things, first there's a segfault when the task has completed, for some reasong *State in task looks weird, then there's a mount which returned 127 exit code (awfully similar to command not found in the shell) [12:15] mborzecki: Yeah, the mount failing isn't so concerning.. they're playing with a new environment and there might be things going on [12:16] mborzecki: But that segfault is worth making sure is not something on our plate [12:16] mborzecki: On quick inspection, I cannot see how to land there [12:17] But I won't spoil with my train of thinking as there might be something else going on that I'm not seeing [12:23] fwiw i thinking it has just downloaded the 'core' snap [12:25] going through the backtrace, there's this tuple `0x966ca248, 0x4`, in places where a string is passed, 'core' is 4 characters, it's downloaded first and the mount error in `snap install ..` output also mentiones 'core', so it must be the same code path [12:53] PR snapcraft#1815 closed: repo: handle invalid snaps [13:06] mvo_, mborzecki: I reviewed 4414. note that not allowing umount2 and umount was very intentional [13:11] meh, with all this test stuff today, I'm looking forward to my lunch break [13:11] kenvandine: why does thunderbird need allow-sandbox: true? [13:13] jdstrand: thanks for the review, any suggestions what to do with mount points being left behind? [13:17] PR snapcraft#1822 opened: tests: skip classic confined tests on armhf [13:27] kalikiana have you updated any of your PRs? [13:28] sergiusens: I addressed the remaining points on snapcraft#1817 - still running on Travis, though [13:28] PR snapcraft#1817: grammar: support strings [13:28] adding those unit tests was surprisingly tedious :-/ [13:36] * kalikiana leaving for lunch now - more investigating test failures to look forward to after that [13:38] kalikiana I've added comments to your PR; all related to the same potential root cause [13:41] sergiusens: Thanks! Will address them after lunch [13:41] mborzecki: there is nothing that can be done with the way it is mounted. [13:41] mborzecki: if this is causing test failures, then mark the test as manual [13:43] mborzecki: well, you could fiddle with allow_root (man fuse) so root could unmount it outside of the snap, but this would not be a totally representative test [13:44] mborzecki: but it is arguably better than disabling the test [13:44] jdstrand: we store the mount namespace, so `nsenter --mount=/run/snapd/ns/test-snapd-fuse-consumer.mnt umount /var/snap/test-snapd-fuse-consumer/16/mount_point` from the test seems to do the trick of unmounting [13:45] mborzecki: is it actually removed though? [13:46] jdstrand: fwiw `nsenter --mount=/run/snapd/ns/test-snapd-fuse-consumer.mnt mount` does not list it anymore [13:46] jdstrand: can i do something else to verify that it's gone-gone? [13:46] * jdstrand notes that to set allow_root, you'd have to modify the security policy within the test to allow reading /etc/fuse.conf [13:48] mborzecki: oh, are you running the snap as root? [13:48] yes [13:48] mborzecki: and unmounting as root? [13:48] ok, phew [13:48] that should be fine then [13:48] ok, great [13:49] I thought you were running the snap as non-root, which allowed the fuse mount, then were able to unmount as root outside the snap, which would've been bad (the kernel is supposed to deny that) [13:50] mborzecki: so now you are using kill -9, then using nsenter ... umount ... from outside the snap? [13:52] jdstrand: i'm doing create $MOUNTPOINT & ; read the file ; kill job-pid ; wait (will expect to exit with a failure now); nsenter .. mount (veirfy that the moint point is left behind) ; nsenter umount (to be added as well) [13:53] jdstrand: i'll drop the policy update patch (we can revisit it later perhaps) and just update the test [14:05] mborzecki: sounds good. that will test the interface in how it is expected to behave. note, we shouldn't change that interface with the policy you have, but we could introduce fuse-control (but no one from the field has requested this so I suggest waiting til someone does) [14:06] jdstrand: ack, thanks [14:10] niemeyer: ok i have a bit of time to look at that traceback now [14:11] niemeyer: is that still needed? [14:11] Chipaca: Yeah, but not sure if we can do much without further data [14:12] Chipaca: I had a quick look and the code path smells like it should be impossible [14:12] niemeyer: it's a custom build, dunno what version / patches it has [14:12] niemeyer: the bits about progress there in any case are not new code [14:12] they're the task progress adapter thing [14:12] Right, that's one of the questions to ask [14:12] mborzecki asked a few others [14:14] in theory their layer and the recipe should carry all the patches [14:15] do we know if the '586' in the name implies anything? [14:15] niemeyer: in any case, give me a shout on telegram if it comes back and you'd like my eyes again [14:15] i might not be on irc much :-) [14:16] Chipaca: Thank you! [14:16] no probs [14:17] mvo_: I don't know how my #4394 is special, but it's green every time :-D [14:17] PR #4394: snap: give the snap.Container interface a Walk method [14:32] Chipaca: haha [14:34] Chipaca: while you are here, what is the tl;dr summary for command-not-found and snap integration? where do we stand currently? [14:34] Chipaca: just asking to help, no pressure [14:42] re [14:53] PR snapd#4411 closed: tests/lib/prepare-restore: disable rate limiting in journald [14:53] PR snapd#4417 closed: tests: fix catalog-update wait loop [14:58] PR snapd#4404 closed: data/selinux: allow messages from policykit [14:59] PR snapd#4396 closed: snap: use the -no-fragments mksquashfs option [15:31] sergiusens: I added tests for verifying passing-through of properties as per your suggestion and also added a .copy() there. Thanks for catching that! [15:46] Huh. I've been wondering why my computer mouse has been getting worse and worse [15:47] Last night I realized that my laptop lid doesn't close all the way [15:47] I think my battery is expanding [15:50] kyrofa you need to deplete it from time to time [15:51] I unplug often [15:51] this is all anecdotal; but it was the xp with the test phones during the ubuntu touch days [16:06] sergiusens, I do deplete it, but not tremendously often. The battery life is pretty bad these days [16:07] However, this laptop is dreadful enough I got an extended warranty [16:08] I've lost track of the number of screens I've had replaced [16:08] Even had the lower body replaced once [16:19] kyrofa you should get an xps 13 or a surface laptop :-P [16:19] sergiusens, I got a dell m3800, another of their Ubuntu offerings [16:19] It's terrible, but the XPS13 I got back in... what... 2012... is still trucking along [16:30] PR snapd#4418 opened: tests: enabling opensuse for tests [17:02] * kalikiana going to wrap up for the not so productive day soon [17:40] kyrofa: you should check your redhat bugzilla bugs :) [17:45] Son_Goku, huh, I haven't received any emails [17:45] I'll take a look [17:45] you probably don't have email stuff set up ;) [17:50] Chipaca: Thank you! [17:50] Oops.. bad key, but thanks again anyway! :) [17:50] Forum software was just updated, please ping if there are issues. [18:04] Son_Goku, NOW I got notified [18:04] Just a bit behind apparently [18:04] PR snapd#4419 opened: tests: fix snapctl configure core tests for rpi2 and 3 [18:32] I installed the spotify snap in Arch Linux, and when trying to play audio I get: [18:32] ALSA lib conf.c:3750:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.confALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default [18:33] anyone else facing this issue? [18:34] jdstrand, you're the alsa pro in my book. Any ideas there? [18:41] also I am using snapd git master [19:26] kyrofa: wow, you're in a jam if I'm the alsa pro :P [19:26] jdstrand, :D [19:26] j605: fyi, I am not a pro, but I was able to get alsa working in a test snap and put the instructions in a bug. let me get that for you [19:27] j605: hopefully this will help you: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5 [19:27] Bug #1598309: The aplay command doesn't work [19:28] kyrofa: fyi, for a fun project I bought one of those wdc nextcloud box thingies [19:29] jdstrand, oh yeah? Awesome! [19:29] kyrofa: I don't have it yet, but looking forward to playing with it [19:29] I'll warn you in advance: it's not the most performant option [19:29] The RAM is pretty low and, of course, overall it's slow [19:30] kyrofa: it should be fine as a file server certainly though, yeah? [19:31] jdstrand, yeah should be [19:31] jdstrand, but before too long, you'll find yourself thinking "I should be using RAID..." [19:31] I wonder if the rpi3 would be better... I have an rpi2 I was planning to use [19:32] I hear it's a bit faster [19:32] Haven't hooked mine up yet [19:32] anyway, it should be fun [19:33] (I use a slightly more beefy server for my nextcloud instance: https://pasteboard.co/GZ7SdxM.jpg) [19:33] Yeah! Thanks for letting me know :) [19:34] oh wow, yes :) [19:34] I'm all about small these days. though, that isn't that big [19:35] Downside of being a camera junky. RAW photos and video take so much space [19:35] oh yeah [19:35] Yeah it's a micro. I just needed the hard drives more than anything [19:35] kyrofa: do you do edits over the network? [19:36] jdstrand: but I though spotify was using pulseaudio and it should just work [19:36] is this comment related to my problem, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/16 [19:36] Bug #1598309: The aplay command doesn't work [19:36] j605: sorry, I didn't read backscroll. I'm using the spotify snap it and it is working with pulseaudio [19:37] j605: is pulseaudio running on your system? [19:37] jdstrand, not typically. I probably could if I was using ethernet, but I usually have at least one or two projects on my local disk that I'm working on. Once they're complete, I transfer them off to only live on the server [19:37] j605: is the pulseaudio interfacec connected? [19:37] jdstrand: yeah I use pulseaudio [19:38] j605: does 'snap interfaces' show that spotify has pulseaudio connected? [19:42] kyrofa how's that work going? [19:42] sergiusens, good, just finishing up [19:42] nice [19:43] kyrofa should we close elopio's PRs or are you going to overwrite them? [19:43] sergiusens, I'll close them once I have the alternative up [19:43] I was going to re-use, but they've diverged pretty far at this point [19:45] jdstrand: it has this ":pulseaudio spotify" [19:46] I tried snap connect spotify:pulseaudio :pulseaudio but audio still doesn't work [19:48] j605: what is the output of 'sudo journalctl | grep audit'. feel free to paste it in paste.ubuntu.com [19:49] ogra_: hey-- oddly when I did 'sudo snap refresh core --candidate' (from stable) on my bbb, on reboot it dropped me to a uboot shell. not knowing what to do, I simply typed 'reset' (cpu reset) and it booted fine. have you ever seen that? [19:50] jdstrand: there is nothing to paste [19:51] j605: oh right, this is arch [19:52] closing spotify does not exit the program, crtl+c on snap run causes a segfault [19:52] :( [19:52] j605: I don't use arch so my best advice would be to create a topic on https://forum.snapcraft.io/ [19:52] j605: that said... if you run it from a terminal, what output do you see? [19:53] j605: and what is the output of 'snap version'? [19:54] 2.30.r282.ge1eddad26-1 [19:54] it is git master [19:54] ok, it's good that you have a new snapd [19:55] kyrofa: sergiusens: Your thoughts on https://forum.snapcraft.io/t/snapcraft-support-for-pipenv/3264 would be appreciated. :) [20:08] kyrofa I'd just close his PRs then :-) [20:08] sergiusens, yeah that's the plan [20:08] kyrofa I'll be almost done with DT NEEDED later tonight, also taking a bit of a detour to simplify things [20:09] sergiusens, hopefully not detouring into meta or pluginhandler? :D [20:10] kyrofa just a bit, on the call to load_dependencies; trivial if conflicts show [20:10] Okay good deal [20:18] jdstrand: https://forum.snapcraft.io/t/spotify-does-not-play-audio/3266 the backtrace looks interesting [20:18] after reboot into lts kernel, I tried snap again and this time I got a better backtrace when it crashed [20:36] I want to use scriptlets in my snapcraft.yaml to install a kernel patch before build. Is there any examples of this? [20:37] I basically want to run gzip -cd patch.tar.gz | patch -p1 but I worry that it won't go to the correct directory where the kernel source is located. Are there any env variables I can use to ensure that it is patched properly? [20:46] jdstrand, i can try it without. It wouldn't launch at all without the browser-support interface [20:46] but that might not be related [21:12] kenvandine: I expect it to need the browser-support interface. I wasn't necessarily expecting that allow-sandbox: true was needed. Can you just change that to 'allow-sandbox: false' and see if it works? [21:12] kenvandine: it might need it, but I want to confirm it [21:12] and understand why [21:13] kenvandine, hey, I am trying to make a gsettings snap work in a linode image, any idea which packages should I install to allow it to work? [22:03] jdstrand, confirmed it doesn't start without allow-sandbox [22:04] hey cachio__ [22:04] kenvandine, hey [22:04] it depends on which schemas it needs to access. Just schemas provided by the snap? [22:04] kenvandine, yes [22:05] cachio__, probably just libglib2.0-0 [22:05] cachio__, and of course include gsettings in plugs [22:06] kenvandine, ok, I'll try with thtat [22:06] cachio__, good luck [22:06] * kenvandine runs out again [23:58] kenvandine: ok. what are the denials?