[00:30] elopio, sergiusens: thanks for taking the time to make sure my code worked and fit the standards, that is much appreciated :) [00:31] and elopio, I'm glad we have quality standards, it ensures things don't break ;) === ayan_ is now known as ayan [01:09] jdstrand: how do i allow seccomp() with the latest version of snap & snapcraft? is there an interface i have to use (like x11 or unity7 etc.)? [01:36] tsimonq2: :) how is it going with the textwrap branch? [01:39] elopio: I'm getting there :) [01:56] elopio: I hope to have it done for tomorrow [01:57] elopio: it *seems* like the only thing blocking it are the unit tests failing because they expect a text wrap [02:09] elopio fixed https://github.com/ubuntu-core/snapcraft/pull/584 [02:10] elopio I had to manually review the vendored implementation and noticed that the upstream one is actually nicer :-P [02:50] tsimonq2: yes, that's what I think too. [02:50] elopio am now fighting this http://paste.ubuntu.com/17728277/ [02:50] elopio all green https://github.com/ubuntu-core/snapcraft/pull/588 ! [02:52] sergiusens: nice! I'll review it after dinner. [02:52] that tweetnacl error, I have no idea. [02:54] elopio I do, we need newer libraries and packages than what we have in trusty :-/ [02:55] elopio might be time to bring back that xenial lxd monster again [02:57] elopio: well it keeps failing, the unit tests [02:59] elopio already reviewed, but I will let you take a stance at it, is dinner over soon? If not I am going to bet [02:59] bed [02:59] sergiusens: go for it. I'm about to start. [02:59] I'll review it when it is SRU time. [03:18] elopio: could you peek at the build errors on https://github.com/ubuntu-core/snapcraft/pull/592 when you have the chance? I don't know what's wrong [03:53] elopio for dessert! https://github.com/ubuntu-core/snapcraft/pull/590 === chihchun_afk is now known as chihchun [07:48] I was wondering if anyone knew about the current status of 64-bit Ubuntu Snappy Core on the Raspberry Pi 3? [07:49] The most recent info I can find on it is that you can run the Pi 2 32 bit image with a 64 bit version in the works. I wondered if that had been released yet or if anyone knew when it's expected? [08:04] ConfusedIntern: hey [08:04] ConfusedIntern: I think everyone is waiting for the pi foundation to release required files for the pi to use 64 bit code [08:05] ConfusedIntern: from our end we will update the kernel snap when that happens [08:05] ConfusedIntern: and we already have the userspace (because it is shared) [08:05] ConfusedIntern: but right now the question is to the raspberry pi foundation, not ubuntu [08:05] ConfusedIntern: ogra can correct me if I'm wrong but IMHO this is how things look like today [08:13] zyga: Ah ok then. Thanks! === hikiko is now known as hikiko|afk [08:42] Anyone come up with a way of editing source files (like with sed) before building a snappy package from 'em? [08:52] jdstrand: will have a look [08:58] jdstrand: https://bugs.launchpad.net/snap-confine/+bug/1595444 FYI [08:58] Launchpad bug 1595444 in Snappy Launcher "current working directory is always /" [High,In progress] === hikiko|afk is now known as hikiko === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko [12:09] ayan: re seccomp> you don't need to do anything except have snapd 2.0.9 installed when you installed your snap. eg: [12:09] $ grep '^seccomp' /var/lib/snapd/seccomp/profiles/snap.hello-world.sh [12:09] seccomp [12:12] zyga: it looks like setup_snappy_os_mounts() isn't chdir()'ing back to the user's pwd after it does its thing [12:13] zyga: see the changes to setup_private_mount() that I did recently that does do that [12:14] zyga: were you planning on committing the arg filtering branch today? (I'd just like it in place for the snapd 2.0.10 landing if possible) [12:25] any example of a snapcraft.yaml using systemd socket activation feature for a daemon? thx [12:26] I thought I found some yaml syntax doc about that on ubuntu website before ... but I cannot find it anymore [12:28] ah, found it: https://developer.ubuntu.com/en/snappy/guides/meta/ ! [12:30] jdstrand: yes [12:30] jdstrand: but after spread works [12:30] jdstrand: btw, I have a fix for the chdir thing [12:30] jdstrand: I'm just going through the process where we get real system tests for this [12:40] zyga: awesome :) [12:40] thanks! :) [12:40] jdstrand: https://github.com/snapcore/snap-confine/pull/49/files [12:40] jdstrand: simple smoke test for debian and ubuntu :) [12:48] zyga: nice! [12:48] though, the curl bit is a bit weird. are all the spread tests doing that? [12:48] jdstrand: yes, spread is not available anywhere [12:49] hrm [12:49] hopefully spread-amd64.tar.gz doesn't get trojaned [12:50] surely one could at least snap the snap from the store and unsquash it? [12:50] s/snap the snap/snag the snap/ [12:50] jdstrand: perhaps but TBH this wouldn't be any different [12:50] sure it would [12:51] I need to ask gustavo about more debian hosts [12:51] niemeyer1: can you please add another debian-8 node to our spread pool [12:51] I don't know how well that instance is protected. we know how well the store is protected [12:51] anyway, I expressed my concern [12:51] jdstrand: yeah, I get your point [12:52] jdstrand: spread is one tarball, we could perhaps check the hash [12:52] even just an upload to LP in universe wuld help, then you could apt-get source it) [12:52] jdstrand: that's better than unsquashfs as it is universally easier to get without sudo [12:52] unsquashfs doesn't need sudo. did I misunderstand something? [12:53] anyway, I see you are thinking about it. that was all I wanted to have happen [12:53] :) [12:53] I mean sudo to install unsquashfs [12:53] this is just a travis limitation [12:53] if you want sudo you wait longer for a test slot [12:53] ah, that isn't on the node? [12:54] I don't know how those are setup [12:54] jdstrand: those are typically old ubuntu (trusty) [12:54] jdstrand: + loads of modifications by travis [12:54] jdstrand: we don't do anything there apart from getting spread [12:54] jdstrand: and running it [12:54] I'm surprised snapd tests are going to work there [12:55] I would think there would be kernel patches, etc that are needed [12:55] jdstrand: snapd doens't do much there [12:55] jdstrand: and we mock everything [12:55] jdstrand: real tests are spread tests [12:55] jdstrand: those run on lindode on the real ubuntu kernel [12:55] oh, these aren't for integration tests? I thought that was part of the allure of spread [12:56] jdstrand: no no, those are integration tests but there are layers [12:56] jdstrand: travis picks up github events [12:56] jdstrand: travis is then configured to download and run spread [12:56] ok, clearly I should stop distracting you. I find it interesting, but there are better things we can be doing than getting me up to speed on the test infrastructure :) [12:56] jdstrand: spread distributes the code to linode vms [12:56] jdstrand: and then real stuff happens on linode vms [12:56] :D [12:56] I see. neat :) [12:56] no worries, I'm looking at the build log [13:00] zyga: though while I have you-- have you seen the various fail to upgrade bugs on yakkety for the launcher? oh, maybe 1.0.30ubuntu1 fixes that... [13:04] jdstrand: yes [13:05] jdstrand: I think will be fixed with 1.0.33 [13:05] jdstrand: or perhaps one of the earlier ones [13:05] jdstrand: I don't release to debian so I feel pretty helpless about it [13:14] it will be nice when snapd on yakkety passes autopkgtests. so many bugs at fix committed... [13:14] jdstrand: do you know what's blocking it there? [13:17] zyga: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html . search for 'snapd' [13:18] the launcher has some always failed tests (though not sure why on armhf) and autopkgtests fail for all archs for sanpd [13:23] Hey ogra_ you're building os snaps for s390x, right? [13:23] indeed [13:25] jdstrand: the launcher should have 0 tests on !amd64 [13:25] jdstrand: this is now made so upstream [13:25] jdstrand: perhaps older tests [13:25] kyrofa: *core* :) [13:25] zyga, has that actually happened yet? [13:25] ogra_, does the store allow uploading snaps of that arch? [13:25] zyga: note my arg filtering branch re-enables i386 because I fixed the tests for it [13:25] is there anything I should be doing to have https://github.com/snapcore/snapd/pull/1380 re-reviewed and ideally, merged? [13:25] kyrofa, yep [13:26] zyga: talking about the internal testsuite of course, not autopkgtests [13:26] jdstrand: for snap-confine? yes that's what I was talking about as well [13:27] zyga: yes, for snap-confine. there isn't really any reason to not do it for all, but I felt strongly we needed at least 32 bit and 64 bit represented in the testsuite [13:27] stgraber: yep, someone has to look and review them [13:27] jdstrand: I'll add 32bit ubuntu to the linode mi [13:27] kyrofa, there are ubuntu-core snaps in the store for all arches except the 32bit powerpc [13:27] mix [13:27] ogra_, I'm gonna see if launchpad will open that for me then. Wait, the store accepts ppc64 as well? [13:27] It didn't last time I tried [13:28] it did when i uploaded the snap ... but thats a while ago [13:28] ogra_, well I tried probably a while before that, so nice [13:28] it is a hard requirement that we support these two arches on classic [13:28] so if it got dropped it has to come back :) [14:00] kyrofa mind moving your wiki part entry to the new wiki format? [14:06] sergiusens, you need to the new wiki page? [14:06] s/need/mean/ [14:08] sergiusens, done [14:09] kyrofa yeah [14:11] kyrofa thanks [14:20] hi, I made my first snap, just a python based cli. is there advice for getting a smaller file size? [14:23] skay: hey! you can filter with some stenza like snap: prime: or others that output to the snap file [14:23] skay: see those keywords in https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/ [14:23] didrocks: thanks! [14:24] yw ;) [14:24] so, why would a path be present in /snap/my-app/current/ and not be present when I run a shell in the snap? [14:24] or any command, not just a shell [14:24] is there a way to run a single unit test? './run-checks --unit' is better than without '--unit' but still a bit long [14:27] sergiusens: now that snap-confine works on Elementary 0.4, it sure would be nice if we could get the Panteon-Mail snap working for them [14:28] 'go test github.com/snapcore/snapd/interfaces/builtin' seems to do what I want [14:34] ogra_, I just asked jamiebennett to help with the bug links [14:34] kyrofa, is your nextcloud.occ a wrapper script (or could you make one for it and simply put in "sudo -i" in there ?) [14:35] that should fix the issue and even call sudo transparently [14:35] olli__, gracias ... i'd do it myself but i'm no OP here afaik [14:36] ogra_, it is. I'm not a huge fan of forcing sudo upon the users without warning, but that's not a bad idea [14:36] well, does it make any sense to run it without sudo ? [14:36] then building it in is indeed bad [14:36] ogra_, honestly no :P [14:36] but if you need sudo anywy that is a nice way of just getting it [14:37] ogra_, yeah, I think I'll do that, thank you :) [14:37] you simply get a password prompt [14:37] ogra_, but: this bug is still valid, yes? [14:37] (and could put an echo before it if you feel like ... to tell the user whats going on) [14:37] kyrofa ogra_ or check euid and provide feedback on why sudo is needed [14:38] well, i'm not sure, i think sudo does what it should ... we mangle the path in a place it cant use [14:38] sergiusens, the problem is actually that sudo doesn't have /snap/bin in the path, so just running with sudo doesn't work [14:38] right ... you need to use -i to make it process the pam login process [14:38] ogra_, not every app will have the use-case I have (i.e. where it makes no sense to run without sudo) [14:38] so /etc/profile.d gets read [14:38] kyrofa, yes, indeed [14:39] the prob is the other place to mangle it would be ~/.bashrc or /etc/environment ... of the host machine [14:39] hi all, is there a way for me to upload a snap (geany in this case) under my developer namespace, while reserving the canonical (little c) name for the upstream? [14:39] i think both would solve it but both are a no-no [14:40] or do I need to do like cwayne did and put my name into the package name, like: mhall119-geany [14:40] * ogra_ would put his name last [14:40] geany-ogra then? [14:40] mhall119, I've been using canonical names expecting to transfer them [14:43] kyrofa: ok, but what will show in Gnome Software for Geany if I do that? [14:43] mhall119, yeah [14:43] mhall119, I'm not sure I understand the question [14:43] mhall119, oh, you mean because it has both debs and snaps named geany? [14:43] mhall119, i suspect it pullls the name from the .desktop file ... but ask Laney, he knows the magic behind this [14:43] kyrofa: if I open the Software app on Ubuntu and search for "Geany", I don't want users to think that my snap is the official one to use [14:44] mhall119, why not? Does Geany package its debs? What is official? [14:44] Keep it in a non stable channel [14:45] And what kyrofa said [14:45] People will see you are the publisher [14:47] except that you cant see non-stable channels anywhere [14:47] (yet) [14:48] (my gitter snap is in beta and edge ... there is no way to see it with "snap find") [14:49] ogra_, yeah channels aren't very useful right now. No way to change channel without removing first, etc [14:49] yep [14:52] ogra_, verified, ppc64 accepted! Awesome [14:52] :D [14:52] ogra_, now I just need the LP team to unlock s390x for my snap recipes === chihchun_afk is now known as chihchun [14:53] hah [14:53] kyrofa: no, geany does not package it's debs [14:54] they rely (happily) on distros to package and published geany [14:56] so will there be a way to browse unstable/edge snaps in the store or is the intent to keep them user invisible for QA reasons? [14:57] didrocks1: ping. I [14:57] I'm copying your travis/docker setup from playpen, but I'm failing to collect a file afterwards. [14:58] didrocks1: can you give me a hand? https://travis-ci.org/ubuntu-core/snapcraft/jobs/139686897 (take a look at the coveralls statement) [14:59] davidcalle, https://github.com/ubuntu/snappy-playpen/wiki/Examples is taking some time to put together, but I said to didrocks1 earlier that I'm getting to the first items in the playpen where I'm like "ok, I documented something like this already" - maybe it's going to be quicker now ;-) [15:01] mhall119, right, that's my point. So what is official? [15:02] dholbach: I'll wait for it to be in a state you are comfortable with before sending the weekly update, can wait tomorrow! :) [15:02] cool [15:03] josepht found a little nit in the parser, if `source` is not there, we shouldn't fail [15:05] kyrofa: what's in the archive is official [15:05] mine is experimental [15:07] mhall119, if you don't anticipate getting it stable enough to be "the Geany snap" then yes, perhaps you should name it something else [15:08] kyrofa: it's not just that it's a snap, it's also using gtk3 which upstream hasn't switched to by default yet [15:09] sergiusens: 'source' in the snapcraft.yaml from 'origin'? [15:10] mhall119, I guess what I'm saying is that, until upstream wants to publish their own snaps, I don't see a problem with claiming the official name and trying to get something stable out there, just like we do with the archives. [15:11] mhall119, there is of course no problem with naming it something different either [15:15] didrocks1: ah, nevermind. I think I got it. [15:17] * ogra_ melts [15:19] elopio: ah sorry, didn't see the ping [15:19] glad you sorted it out [15:21] fgimenez: let's skip today, to see if I finish something before my swimming class. [15:22] elopio, ok, i was going to porpose the same to you :) (without the swimming part) [15:26] fgimenez: :D [15:28] jdstrand: is there some env variable or config I can set to temporarily entirely turn off apparmor in snapd? [15:28] jdstrand: I'd be fine with masking paths in /sys and/or /proc if that works as a way to have that code skipped (basically pretending the kernel doesn't have apparmor support) [15:30] stgraber: you can boot with apparmor disabled. you can install the snap with --devmode. you can modify the profile in /var/lib/snapd/apparmor/profiles/snap... to be in complain mode. you can compile ubuntu-core-launcher with --disable-confinement [15:30] stgraber: but why are you doing that? [15:32] jdstrand: running snapd inside an unpriv lxd container [15:32] so it is the snapd inside the container you want to disable apparmor? [15:33] ogra_, sudo is denied :P . I should have guessed that, of course it is [15:33] if so, I think the easiest you can do until the nesting work is done in lxd is to compile ubuntu-core-launcher without confinement [15:33] ah, crap, indeed [15:33] jdstrand: I've sorted out the squashfs part of the problem and tych0 is looking at apparmor namespacing but trying to see if there's any other issue we'll have to take care of after that [15:34] jdstrand: ok [15:34] ogra_, who's problem is that? snapd? [15:34] stgraber: go here: https://github.com/snapcore/snap-confine [15:34] kyrofa, that sudo doesnt work ? thats a feature :) [15:34] you would have to ship sudo and a sudoers file inside [15:34] ogra_, no no, I mean the environment thing, sorry [15:35] stgraber: see PORTING on how to use --disable-security. modify debian/rules for that. build the deb and use that in the container [15:35] ogra_, since I can't workaround it, I'd like to push it a little [15:35] jdstrand: ok, thanks [15:35] sergiusens: any idea about this error? https://travis-ci.org/ubuntu-core/snapcraft/jobs/139791578 [15:35] stgraber: I think that should work (if you have trouble with --disable-security, talk to zyga since he has been in charge of the cross distro story) [15:35] ogra_, but I don't know if it's something to be fixed in the snapd packaging or what [15:35] well, as i said, not sure we can actually call it a problem ... sudo behaves as advertised and snnapd cant really mangle the other configs that would enhance $PATH [15:36] stgraber: that should work with snapd 2.0.9 that is in xenial now, so I think that is the only thing to change [15:36] kyrofa, probably someone from the security team can elaborate if the sudo behaviour is correct [15:37] ogra_, alright, thanks [15:38] (i think it is though ... this is a tricky one) [15:38] jdstrand: yeah, my snapd was built from current git as I needed my squashfuse support patch [15:38] you should be doubly ok then :) === davidcalle is now known as davidcalle_afk [15:38] jdstrand, currently /snap/bin is in the user's path, but the `sudo` secure path doesn't include it, which means `sudo snapname.appname` doesn't work. Can you think of a secure way to fix that? [15:39] that is an old bug [15:39] jdstrand, I know, but I didn't see any bugs actually logged about it [15:39] jdstrand, maybe there was and I just duped it [15:40] jdstrand, I seem to remember it working in 15.04 though [15:40] elopio yeah, just discussing that with josepht right now, already have a fix. Let me push [15:40] I think there is one, however, I'm going to defer to mdes laur since he looked at secure path for something else recently on 16.04. he is on holiday though. is this something you can circle back on (I would think so, this bug is ancient)? [15:41] sergiusens: cool, I'll rebase mine. [15:43] jdstrand, oh certainly [15:44] I think he'll have most of the considerations at hand [15:44] jdstrand, I'm going to forget though, so I'm going to send out an email if that's okay? [15:45] kyrofa: please send to security@ubuntu.com and you might get people responding sooner :) [15:45] jdstrand, you got it! Is that an open list? [15:46] it's an email exploder for just the security team [15:46] Okay very good [15:47] jdstrand, do you know if a bug was ever logged about that issue? [15:47] jdstrand, I know it's old [15:48] * jdstrand looks [15:51] kyrofa: bug 1411671. it looks like we did fix it in 15.04 core images via ubuntu-core-config, but I think it needs to be revisited, esp. for changing this on classic [15:51] bug 1411671 in Snappy "/apps/bin should be added to sudoer's secure_path" [Wishlist,Fix released] https://launchpad.net/bugs/1411671 [15:51] jdstrand, ah, that explains why it used to work! [15:52] jdstrand, still worth a security email? [15:54] Also, I figure that bug should just be re-opened and mine marked dupe, but I'm not sure how to track a bug that's fixed in 15 and valid in 16. Just target to series? [15:57] jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/48/files [15:57] tyhicks: thanks for your comment [16:00] jdstrand, hmm, do you know if adding to secure_path via a sudoers.d snippet would work ? [16:01] ah [16:01] seems += will work [16:02] elopio https://github.com/ubuntu-core/snapcraft/pull/598 [16:03] argh [16:03] or not [16:03] * ogra_ just killed sudo on his laptop [16:03] damned [16:03] ogra_: :D [16:03] ogra_: when fiddling with sudo config, have a root session around [16:04] well, i havent seen recovery mode in years ... [16:04] zyga, if i actually plan to work on it i do that too ... damned spontanity at 34′C [16:05] all right my friends - I call it a day - see you all tomorrow again! [16:06] dholbach, enjoy! [16:06] you too [16:07] ogra_: 34!! where are you? [16:07] ogra_: still in greece? [16:31] morphis: hey [16:31] jdstrand: so what are we doing with pulseaudio and the recording on xenial [16:32] I may can spend and hour or so on monday to get this started [16:32] morphis: the agreement was to sru blocking recording and then work on pulseaudio/trust-store/interfaces migration to express recording in interfaces [16:33] morphis: sru is phase 1. interfaces phase 2 [16:33] right [16:33] phase 1 is what I meant [16:33] the meeting yesterday was for phase 2, but the meeting didn't happen and I need to reschedule [16:34] aye, I mainly meant the bug you pinged me about yesterday [16:34] morphis: yeah, that is part of phase 1 [16:35] jdstrand: so what is left for this is proper testing and then getting the SRU out [16:35] sounds great :) [16:35] jdstrand: I can do the testing on monday [16:35] maybe someone else can then help with the SRU [16:35] awesome! I'll make a note in the card. thanks! :) [16:36] morphis: what kind of help are you looking for? helping through the process? [16:37] either that or someone taking it completely [16:37] morphis: if I had a tested debdiff I could get it over the finish line [16:38] jdstrand: sounds good [16:38] jdstrand: then lets do it this way [16:40] morphis: great, thanks! [16:40] jdstrand: will ping you on monday then [16:40] cool [16:44] Hello. Doing sudo apt update on Ubuntu Mate on RPI - and getting this E: The repository 'http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial Release' does not have a Release file. - any ideas what could be happening. [16:44] Also this error is the first one - Cannot initiate the connection to ports.ubuntu.com:80 (2001:67c:1360:8001:1::2). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8001:1::2 80] [16:45] any reason why you have this ppa enabled ? [16:45] jdstrand: what does this mean:- "adjust snap to ship 'scmp_sys_resolver' [16:45] (forgive my ignorance) [16:48] scmp_sys_resolver is what is used to resolve a syscall number to a name (or vice versa). whatever snap that is should ship it as part of the snap. if it is snappy-debug, that is a known issue-- do 'apt-get install seccomp' [16:49] on the host, not in the snap? [16:49] seccomp is already the newest version (2.2.3-3ubuntu3). [16:49] on the host [16:51] popey: yes, on the host. is that snappy-debug? [16:51] yes [16:51] http://paste.ubuntu.com/17754105/ is the full output [16:52] am fixing the network-bind one first [16:52] popey: oh, install it in strict mode and that will go away [16:53] oh [16:53] there are some issues with complain mode logging that we're working through [16:56] super [16:56] snappy-debug also needs some work that will happen after some other higher priority interfaces work [16:57] I seem to be picking all the awkward apps to snap :) [17:00] popey: several of those denials are fixed in 2.0.9. plug the opengl interface and reinstall and two of those will go away (it may make the ptrace go away too) [17:04] jdstrand: sorry, what do you mean by "plug the opengl interface"? [17:05] popey: in qtox, make sure you have 'plugs: [ ..., opengl ]' [17:05] ah, i do [17:05] popey: upgrade to 2.0.9, then uninstall and reinstall qtox then [17:06] awesome, thanks [17:06] that uninstall/reinstall things is also queued up and will be resolved in the next couple of sru cycles [17:26] jdstrand, mvo, did you see bug #1595478 ? [17:26] bug 1595478 in ubuntu-core-launcher (Ubuntu) "package snap-confine 1.0.30 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.bin.snap-confine', which is also in package ubuntu-core-launcher 1.0.29+2" [Undecided,Confirmed] https://launchpad.net/bugs/1595478 [17:26] unsure where those packages are coming from [17:34] seb128: I did. I pointed it out to zyga today. I think 1.0.30ubuntu1 may fix it [17:36] jdstrand, thanks [17:39] elopio is our testing infra down? [17:46] so ubuntu-core-launcher /is/ snap-confine? [18:16] seb128, jdstrand they were falsely synced from debian (and i thought removed from the archive already) [18:17] croepha: re snap-confine is the name of the project. ubuntu-core-launcher is the package name for snap-confine in Ubuntu 16.04 for historical reasons [18:18] source package name* [18:18] jdstrand: gotcah [18:18] jdstrand: I mean, thanks :) [18:18] :) [18:20] jdstrand: can you look at https://bugs.launchpad.net/snappy/+bug/1595649 and see if this is a confinement thing (I don't think so, because it fails in --devmode too) or not? [18:20] Launchpad bug 1595649 in Snappy "Audio playback fails for KDE apps with Phonon" [Undecided,New] [18:26] mhall119: it'll be failing to find a phonon backend, it's based on a hardcoded path at compile time [18:27] by default ${CMAKE_INSTALL_PREFIX}/${PLUGIN_INSTALL_DIR}/plugins [18:31] so, im assuming that if I snap install with --devmode then i am essentially bypassing all the Apparmor/interfaces access control stuff right, i should essentially have all the rights as if I was running not in a snap right? [18:42] sgclark: ^^ see above. [18:42] d_ed: is there a configuration work-around for that, or does it require a patch to some upstream code? [18:42] croepha: I believe so, yes [18:44] croepha: yes, except that you still run in a different filesystem [18:45] mhall119: d_ed that is what I thought. I tried setting several env vars in qt5-launch without luck. [18:47] as far as I can see, no [18:48] however, it does also search the Qt install path - so one /could/ change phonon backends to install where Qt does or maybe add symlinks [18:48] ..or we fix upstream code [18:49] see ensureLibraryPathSet() in Phonon [18:49] ok [18:49] thanks [18:54] mhall119, zyga: Thanks === JanC is now known as Guest91547 === JanC_ is now known as JanC [18:56] popey: fyi, I updated snappy-debug for the new 2.0.9 policy which should help the experience a bit [18:56] it's in the store [18:58] jdstrand: hey, what is your opinion on https://github.com/snapcore/snap-confine/pull/48 [18:58] jdstrand: I'd like to move forward on that branch [19:04] jdstrand: also a small bug in https://github.com/snapcore/snap-confine/pull/7/files#r68295578 [19:04] jdstrand: thanks [19:06] is there a way to update all my snaps at once now? [19:07] uh.. [19:07] alan@gort:~$ sudo snap refresh snappy-debug [19:07] error: cannot perform the following tasks: [19:07] - Download snap "snappy-debug" from channel "stable" (revision 22 of snap "snappy-debug" already installed) [19:09] known issue [19:11] ok [19:15] popey: remove and reinstall and you should be set [19:21] ah [19:44] jdstrand: if you fix the one thing that probably leads to snap-confine crash I'll merge the seccomp filtering patch [19:45] zyga: huh? [19:45] what crash? [19:45] is it in the PR? [19:46] I see your notes [19:46] meh, last minute change [19:46] * jdstrand fixes [19:46] jdstrand: I've commented on the pull request [19:46] I see [20:11] zyga: done. note the ci tests failed for something unrelated [20:13] zyga: have you treid running refresh-bits in yakkety? === devil is now known as Guest11152 [20:41] anyone got xserver-xorg running in a .snap that I can look at? im having all kinds of issues, currently im getting a segfault in xf86OutputClassDriverList tracking it down now [20:41] ? [20:45] sergiusens: we have coverage: https://github.com/ubuntu-core/snapcraft/pull/597 [20:45] if integration tests pass in travis, you can land this one and the requirement. [20:49] croepha: I don't have specific details on that question (I don't know anyone who has tried that), but most people will not embed the X server in the snap and install use 'plugs: [ x11 ]' (or unity7) and install the snap on a 'classic' system (eg, a desktop system with X) [20:50] croepha: now, if you are trying to run X as a snap to serve to other clients for a system that doesn't have X (eg, an iot device), that hasn't been done yet, but others on the list might be able to help [20:50] s/list/channel/ [20:51] i am specifically trying to get xorg to run in core [20:51] I see [20:52] start with --devmode for sure since at some point the x11 interface will need to implement the slot side to allow X to run [20:52] ok, thanks for feedback, i'll keep pushing forward, i think ive traced the issue to a null pointer, now i need to figure out why its null in my case [20:52]