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