| 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> | 02:39 |
|---|---|---|
| mup | PR snapcraft#1821 opened: tests: use a simpler test for bzr and python <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1821> | 03:06 |
| mup | PR snapd#4416 opened: tests: performance measurements for basic snapd commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4416> | 04:55 |
| mborzecki | morning | 06:11 |
| mborzecki | mvo: morning | 06:32 |
| mvo | hey mborzecki, good morning! | 06:32 |
| mborzecki | mvo: i was playing a bit with interfaces-fuse_support test yesterday, and we may have a bigger problem at hand | 06:33 |
| mvo | mborzecki: oh? tell me more | 06:34 |
| mborzecki | the 'create' will try to remove fuse mount when you kill it | 06:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| mborzecki | mvo: otoh, is it possible to force a specific order of tests in spread (given 1 worker)? | 06:41 |
| 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:42 |
| mborzecki | ah, ok | 06:43 |
| 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:47 |
| mup | PR snapd#4417 opened: tests: fix catalog-update wait loop <Created by mvo5> <https://github.com/snapcore/snapd/pull/4417> | 06:49 |
| mborzecki | mvo: https://paste.ubuntu.com/26219568/ apparently we pick up snappy-app-dev helper too | 06:59 |
| mborzecki | mvo: https://paste.ubuntu.com/26219598/ SIGSYS | 07:06 |
| mvo | mborzecki: hm, interessting, smells like seccomp | 07:21 |
| 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:27 |
| mvo | mborzecki: what interface is the test currently using? | 07:29 |
| mborzecki | fuse-support | 07:29 |
| * mvo nods | 07:29 | |
| 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:32 |
| 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:34 |
| 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:35 |
| mvo | mborzecki: alternative action like what? | 07:36 |
| 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:37 |
| mvo | mborzecki: well, not *exactly* what you want, its still not configurable but switches to errno | 07:38 |
| mborzecki | right | 07:38 |
| mvo | mborzecki: please let me know if I should help with the interface update | 07:49 |
| mborzecki | mvo: is fuse-consumer apparmor profile kept in the filesystem? | 07:50 |
| kalikiana | good morning ^_^ | 07:51 |
| mborzecki | kalikiana: morning | 07:51 |
| kalikiana | hey mborzecki | 07:51 |
| mvo | mborzecki: yes, it should be there in /var/lib/snapd/profiles/apparmor | 07:53 |
| 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:54 |
| 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:56 |
| mvo | mborzecki: hm, strange. what distro/release are you on right now? | 07:59 |
| 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:00 |
| jjohansen | mborzecki: it will depend on your kernel | 08:01 |
| 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:02 |
| mborzecki | jjohansen: ta | 08:03 |
| mborzecki | mvo: yeah, the rules are listed for ubuntu 16.04 image | 08:03 |
| 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:06 |
| 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:07 |
| mvo | mborzecki: aha, good :) I was worried for a second | 08:09 |
| 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:37 |
| mvo | mborzecki: yay | 08:48 |
| mvo | mborzecki: thanks for finding this! | 08:48 |
| * sergiusens waves from the early morning | 09:24 | |
| 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> | 09:25 |
| 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:05 |
| 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:06 |
| * kalikiana coffee break | 10:13 | |
| 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:29 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | mvo_: hello from the south of france :-D | 10:37 |
| 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:38 |
| 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:39 |
| === daniellimws is now known as Guest79825 | ||
| === dows is now known as daniellimws | ||
| 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:41 |
| mvo_ | Chipaca: looks great! | 10:42 |
| Chipaca | mvo_: are the tests still mostly failing? | 10:42 |
| mvo_ | Chipaca: *slightly* better but still pretty bad, but some progress | 10:44 |
| 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:20 |
| mvo_ | mborzecki: very nice, thank you | 11:30 |
| 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:36 |
| mborzecki | mvo_: have you seen this? https://forum.snapcraft.io/t/yocto-rocko-core-snap-kernel-panic/3261 | 11:37 |
| 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:42 |
| mvo_ | hey niemeyer | 11:43 |
| mvo_ | mborzecki: yeah, "writing(0xe3f)" looks suspicious | 11:43 |
| 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:46 |
| mvo_ | mborzecki: your reply seems to be the best option - maybe we can figure out more with the image | 11:47 |
| niemeyer | Chipaca: Are you working today? | 12:02 |
| 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:03 |
| 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:04 |
| 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:08 |
| niemeyer | (mostly wondering about what we know) | 12:09 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| mborzecki | fwiw i thinking it has just downloaded the 'core' snap | 12:23 |
| 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:25 |
| mup | PR snapcraft#1815 closed: repo: handle invalid snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1815> | 12:53 |
| jdstrand | mvo_, mborzecki: I reviewed 4414. note that not allowing umount2 and umount was very intentional | 13:06 |
| 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:11 |
| mborzecki | jdstrand: thanks for the review, any suggestions what to do with mount points being left behind? | 13:13 |
| mup | PR snapcraft#1822 opened: tests: skip classic confined tests on armhf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1822> | 13:17 |
| sergiusens | kalikiana have you updated any of your PRs? | 13:27 |
| 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:28 |
| * kalikiana leaving for lunch now - more investigating test failures to look forward to after that | 13:36 | |
| sergiusens | kalikiana I've added comments to your PR; all related to the same potential root cause | 13:38 |
| 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:41 |
| 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:43 |
| 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:44 |
| jdstrand | mborzecki: is it actually removed though? | 13:45 |
| 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:46 | |
| 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:48 |
| 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:49 |
| jdstrand | mborzecki: so now you are using kill -9, then using nsenter ... umount ... from outside the snap? | 13:50 |
| 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:52 |
| mborzecki | jdstrand: i'll drop the policy update patch (we can revisit it later perhaps) and just update the test | 13:53 |
| 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:05 |
| mborzecki | jdstrand: ack, thanks | 14:06 |
| Chipaca | niemeyer: ok i have a bit of time to look at that traceback now | 14:10 |
| Chipaca | niemeyer: is that still needed? | 14:11 |
| niemeyer | Chipaca: Yeah, but not sure if we can do much without further data | 14:11 |
| 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:12 |
| mborzecki | in theory their layer and the recipe should carry all the patches | 14:14 |
| 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:15 |
| niemeyer | Chipaca: Thank you! | 14:16 |
| Chipaca | no probs | 14:16 |
| 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:17 |
| mvo_ | Chipaca: haha | 14:32 |
| 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:34 |
| kalikiana | re | 14:42 |
| 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:53 |
| 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:58 |
| 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> | 14:59 |
| 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:31 |
| kyrofa | Huh. I've been wondering why my computer mouse has been getting worse and worse | 15:46 |
| 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:47 |
| sergiusens | kyrofa you need to deplete it from time to time | 15:50 |
| 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 | 15:51 |
| kyrofa | sergiusens, I do deplete it, but not tremendously often. The battery life is pretty bad these days | 16:06 |
| kyrofa | However, this laptop is dreadful enough I got an extended warranty | 16:07 |
| 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:08 |
| 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:19 |
| mup | PR snapd#4418 opened: tests: enabling opensuse for tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4418> | 16:30 |
| * kalikiana going to wrap up for the not so productive day soon | 17:02 | |
| Son_Goku | kyrofa: you should check your redhat bugzilla bugs :) | 17:40 |
| 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:45 |
| 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. | 17:50 |
| 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:04 |
| 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:32 |
| j605 | anyone else facing this issue? | 18:33 |
| kyrofa | jdstrand, you're the alsa pro in my book. Any ideas there? | 18:34 |
| j605 | also I am using snapd git master | 18:41 |
| 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:26 |
| 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:27 |
| jdstrand | kyrofa: fyi, for a fun project I bought one of those wdc nextcloud box thingies | 19:28 |
| 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:29 |
| jdstrand | kyrofa: it should be fine as a file server certainly though, yeah? | 19:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| jdstrand | oh wow, yes :) | 19:34 |
| jdstrand | I'm all about small these days. though, that isn't that big | 19:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| jdstrand | j605: does 'snap interfaces' show that spotify has pulseaudio connected? | 19:38 |
| sergiusens | kyrofa how's that work going? | 19:42 |
| kyrofa | sergiusens, good, just finishing up | 19:42 |
| sergiusens | nice | 19:42 |
| 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:43 |
| j605 | jdstrand: it has this ":pulseaudio spotify" | 19:45 |
| j605 | I tried snap connect spotify:pulseaudio :pulseaudio but audio still doesn't work | 19:46 |
| jdstrand | j605: what is the output of 'sudo journalctl | grep audit'. feel free to paste it in paste.ubuntu.com | 19:48 |
| 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:49 |
| j605 | jdstrand: there is nothing to paste | 19:50 |
| jdstrand | j605: oh right, this is arch | 19:51 |
| 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:52 |
| jdstrand | j605: and what is the output of 'snap version'? | 19:53 |
| 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:54 |
| Odd_Bloke | kyrofa: sergiusens: Your thoughts on https://forum.snapcraft.io/t/snapcraft-support-for-pipenv/3264 would be appreciated. :) | 19:55 |
| 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:08 |
| kyrofa | sergiusens, hopefully not detouring into meta or pluginhandler? :D | 20:09 |
| sergiusens | kyrofa just a bit, on the call to load_dependencies; trivial if conflicts show | 20:10 |
| kyrofa | Okay good deal | 20:10 |
| 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:18 |
| wililupy | I want to use scriptlets in my snapcraft.yaml to install a kernel patch before build. Is there any examples of this? | 20:36 |
| 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:37 |
| 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 | 20:46 |
| 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:12 |
| 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? | 21:13 |
| kenvandine | jdstrand, confirmed it doesn't start without allow-sandbox | 22:03 |
| 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:04 |
| kenvandine | cachio__, probably just libglib2.0-0 | 22:05 |
| kenvandine | cachio__, and of course include gsettings in plugs | 22:05 |
| cachio__ | kenvandine, ok, I'll try with thtat | 22:06 |
| kenvandine | cachio__, good luck | 22:06 |
| * kenvandine runs out again | 22:06 | |
| jdstrand | kenvandine: ok. what are the denials? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
