[00:51] PR snapcraft#1470 closed: catkin plugin: default to release build [01:58] snap install /tmp/meshlab-cYdtAIYBmTS1b7L2q8yrMdpAZ38qLv6Q_4.snap [01:58] - Copy snap "meshlab" data (cannot copy "/var/snap/meshlab/4" to "/var/snap/meshlab/4": failed to copy all: "cp: cannot stat '/var/snap/meshlab/4': No such file or directory" (1)) [01:59] anyone know what that's about? the dir exists. I also intermittently get a core error [01:59] ... [01:59] # snap refresh core [01:59] error: cannot perform the following tasks: [01:59] - Setup snap "core" (2601) security profiles (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": fork/exec /usr/lib/snapd/snap-update-ns: no such file or directory) [02:05] PR snapd#3701 opened: tests: fix interfaces-cups-control test [03:33] How jailed are snaps? They seem to log to the root /var/log [03:34] ie, I now have samba.log files in /var/log after installing the samba snap I am working on [04:24] PR snapd#3702 opened: interfaces: add missing test for camera interface [05:26] PR snapd#3703 opened: interfaces: improve and tweak bunch of interfaces test cases [05:43] What is the correct way to create required directories for a snap? [05:43] ie, /etc if it doesnt exist? [05:43] Hooks? [07:52] PR snapd#3704 opened: interfaces: convert lxd to common iface [07:54] good morning [07:57] mvo: how are we doing? [07:57] PR snapd#3657 closed: daemon, client, cmd/snap: implement snap start/stop/restart [07:57] woooooooooooooo [07:58] hey Chipaca, feels good to have the merge go in :) [08:00] yes [08:02] hey zyga-suse [08:05] zyga-suse: o/ [08:06] hey hey [08:07] I have one important bug to check and then I'd like to release suse and arch packages [08:14] some perspective form appimage developers: https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Issues [08:14] PR snapd#3705 opened: interfaces: convert lxd_support to common iface [08:14] zyga-suse: can you check if rc9 builds? [08:15] mvo: sure, where? [08:15] zyga-suse: suse, arch [08:16] with pleasure [08:16] do you have tarballs? [08:16] I'll build master locally but it would help to have rc tarballs [08:16] zyga-suse: I can prepare one, otherwise in the ppa [08:16] (do you still make them manually?) [08:17] for various reasons it is easier if they are on github (various tools can pull them like in debian) [08:17] zyga-suse: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+files/snapd_2.27~rc9.tar.xz [08:17] zyga-suse: aha, ok [08:17] ok [08:17] this is fine [08:17] zyga-suse: ok, thank you. I have a script that creates them now [08:18] awesome, it would be good to commit that to the tree at some point [08:18] PR snapd#3700 closed: tests: fix for upgrade test on fedora [08:19] PR snapd#3706 opened: asserts,overlord/devicestate: support predefined assertions that don't establish foundational trust [08:28] zyga-suse: so what's the debian update waiting on? [08:28] mwhudson: not sure, I didn't look at debian seriously for too long :/ [08:28] mwhudson: I think we want 2.27 across the stack [08:28] zyga-suse: ok [08:30] zyga-suse: on the dependency side [08:30] zyga-suse: we can leave the i18n commented out for now i guess [08:31] I think that's acceptable [08:31] zyga-suse: i need to find a sponsor to upload golang-go-flags-dev [08:31] is the patch extensive? [08:31] oh, I assumed you are a DD [08:31] no [08:31] zyga-suse: not yet :) [08:31] i am in the process [08:31] great :) [08:31] mwhudson: let me know, I can help [08:32] the x/net fork can be avoiding by simply not running that test in the build? [08:32] mvo: https://anonscm.debian.org/cgit/pkg-go/packages/golang-go-flags.git/ [08:33] oh wait [08:33] mwhudson: if you create something that I just need to sign/dput, that would be best for me [08:34] * zyga-suse iterates on the opensuse package [08:34] some things failed on 2.25 still, but perhaps just racy tests [08:34] I'll focus on 2.27 [08:35] mvo: ack [08:36] mvo: the tarball has different name and internal directory name than the one before [08:37] not complaining but pointing out that we should perhaps use snapd-$version on the inside [08:37] and pick whatever fixed on the outside [08:37] zyga-suse: meh, yes [08:37] zyga-suse: part of the problem is the debian build tools, but I don't want to make excuses [08:37] zyga-suse: I look into it [08:37] debian build tools? [08:37] zyga-suse: the tarball is generated from the git repo, I will see what I can do with git-buildpackage [08:38] ok [08:41] zyga-suse, mvo: and we thing we can use upstream instead of github.com/mvo5/libseccomp-golang for debian? [08:41] I'd love to [08:41] mvo: is that under golang CLA? [08:44] * zyga-suse needs to refresh some patches [08:44] well [08:44] packaging 010 [08:44] 101 even :P [08:45] mvo: i've made something for you to upload but i'm going to test build it before i give you the link :) [08:46] zyga-suse, what are the chances of getting core snap to ship libselinux? [08:46] ikey: hey [08:46] heya [08:46] ikey: I saw your comments [08:46] ikey: I need to look into it [08:46] mwhudson: yeah, upstream libseccomp-golang should be fine, all I did there was adjust for trusty [08:46] ikey: it feels more like a bug in the app than something that really really should be in the core [08:46] mwhudson: our trusty libseccomp is heavily backported [08:47] zyga-suse, well its all over the place [08:47] ikey: but I want to look at it for real before making any calls [08:47] okidoke [08:47] core's own Things use libselinux [08:47] like gio-querymodules: [08:47] and other bits [08:47] it would seem core isn't as clean and self contained as it thinks it is [08:47] ikey: I see ./lib/x86_64-linux-gnu/libselinux.so.1 [08:48] (that's relative to core itself) [08:48] is it possible this is some derpy side effect of not having rexec? [08:48] *re-exec [08:48] no, probably a bug somewhere else [08:48] ok [08:48] look at dirs/dirs.go [08:48] I think you may need to say that on solus you use lib64 to keep distro binaries [08:48] im loath to including libselinux in solus because, well, it infects stuff [08:48] mvo: http://people.canonical.com/~mwh/golang-go-flags-dev/ [08:48] (AFAIR snapd is there [08:49] as are other relevant parts) [08:49] ah so multiarch vs multilib [08:49] curious, ty [08:49] ikey: you should never have to include anything in the distribution to make a given snap work [08:49] that was my thought [08:49] snaps don't see anything from the host really (not libraries) [08:49] ikey: do you know how it roughly works at runtime? [08:50] ikey: as a big approximation: the *base* snap (e.g. core but other bases are in progress) is used as the root filesystem [08:50] ikey: some things like /dev, /proc and /sys are "normal" (dev may be empty-ish, depending on confinement) [08:50] ikey: some things from the host are overlaid (e.g. parts of /etc) [08:50] right [08:50] ikey: /home and /root are shared but $HOME is changed [08:51] ikey: the real host root filesysystem is in /var/lib/snapd/hostfs [08:51] ikey: (with certain things unmounted, like sysfs and dev because it confuses apps [08:51] ikey: there's a long tail of small tweaks [08:51] aye [08:51] ikey: but the main point is: the host distribution is not used for runtime libraries or executables [08:52] well thats the theory [08:52] no, we really don't use them, what do you mean? [08:52] well at this point its not completely using the core snap either [08:52] yep, something is not right yet [08:53] but I bet this is packaging issue [08:53] if you want I can install solus and help you out [08:53] you'll forgive me for saying but i dont quite see *how* it would be a packaging issue [08:53] I'm working on opensuse and arch but then I can try out solus :) [08:53] when it looks more like the helper scripts are invoked host side [08:53] and not containerised [08:54] can you please run the hello snap after setting SNAP_CONFINE_DEBUG=yes [08:54] setting where, /etc/environment? [08:54] ikey: oh, one important point: if a snap uses 'classic confinement' then none of what I just said is true [08:54] sure [08:54] ikey: just export it in your shell [08:54] classic confinement is a different beast [08:55] yeah thats more at the appimage end of the spectrum [08:55] mvo: this is still breaking: [ 622s] FAIL: overlord_test.go:360: overlordSuite.TestEnsureLoopPrune [08:55] https://hastebin.com/ixovewisig.sql [08:56] zyga-suse: breaking where? [08:56] mvo: the unit test fails randomly [08:56] mvo: run it 1000 times and see the failure rate [08:57] ok [08:57] ikey: this worked, can you try with a more complex snap next? what did you try to use before? [08:57] brackets went boom [08:57] but thats classic [08:57] ikey: brackets is a classic snap :/ [08:57] so classic confinement uses different things [08:57] yer [08:58] and what must be happening is that the snap itself is broken [08:58] classic confinement is defined as follows: [08:58] a large number of them are broken* [08:58] pedronis: o/ [08:58] there is no file-system redirection [08:58] the core snap is in a well-known spot [08:58] as is the snap itself [08:58] those resources are guaranteed [08:58] sure but wouldnt you also alter LD_LIBRARY_PATH to factor in core runtime? [08:58] before executing the snap [08:58] other resources MAY be used but the snap author must do that with sanity [08:59] ikey: no, because that's snaps responsibility, some snaps are built in a way that this is not a factor [08:59] eg. [08:59] try python0 [08:59] eh [08:59] and look at the binary itself [08:59] and at how it is linked [08:59] yeah im gonna have to disagree there [08:59] the fact is that many snap with classic confinement are built in as sloppy way [08:59] so even with LD_LIBRARY_PATH, rpath is going to work fine [08:59] ikey: I can tell you why we're not setting LD_LIBRARY_PATH [08:59] ikey: because that breaks classic snaps that do certain things [08:59] there's no silver bullet here, [09:00] snaps using classic confinement *may* run apps from the host distribution [09:00] and then setting this would break that [09:00] I would argue that brackets is just done incorrectly and assumes to run on a ubuntu-ish system too much [09:00] right but its not *just* brackets that fails [09:00] its the scratch setup scripts in core [09:00] i.e. update icon cache, schemas, etc [09:00] scratch setup scripts? [09:00] idk what you call them :P [09:01] we don't have *any* scripts [09:01] so whatever you are describing comes from the snap itself [09:01] unfortunately classic confinement snaps are always going to be a hit-and-miss because when it runs on the developer's machine it doesn't mean it will run elsewhere for sure, like strictly confined snaps do [09:01] all the GUI snaps do seem to invoke gtk-update-icon-cache-3.0 (which doesnt exist) and there are some spam-debug lines about schemas, etc [09:02] ikey: that must be a common bug in those snaps then, I'm sure it can be addressed [09:02] (note that core doesn't ship any of that) [09:02] many snaps use a common helper [09:02] and if the helper has a bug we just need to fix it in one place and the next revision of those snaps will improve [09:03] non-classic: [09:03] (assuming duckmarines is non classic) [09:03] snap info foo [09:03] /snap/duckmarines/9/usr/lib/x86_64-linux-gnu/glib-2.0/gio-querymodules: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory [09:03] this will tell you [09:03] DEBUG: confinement: non-classic [09:03] when you install a snap you have to say --classic [09:04] mm, that's more interesting, let me see [09:04] it does eventually flop (no doubt due to missing apparmor) [09:04] [1] 5959 invalid system call snap run duckmarines [09:04] but im more interested in the library fail first [09:04] ikey: invalid system call == it was killed by seccomp [09:04] can you look at your journalctl/dmesg and look for seccomp [09:04] I wonder what killed it [09:04] are you on x86 or x86_64 system? [09:05] x86_64 [09:05] ok [09:05] (there were some socket/socketcall bugs on 32bit intel systems0 [09:05] because kernel changed [09:05] not seeing errors in either. odd. [09:05] Chipaca: hi [09:05] ikey: interesting, I just ran duckmarines on opensuse and it worked, no messages about missing libselinux.so.1 [09:06] can you verify if you have a host-side libselinux? [09:06] let me see what's going on deeper [09:06] ikey: again, host side libselinux is not accessible in any normal way [09:06] sure [09:06] but can you? :P [09:06] yes, checking anyway :-) [09:06] im seeing this: [09:06] 17/08/10 10:02:33.232761 taskrunner.go:367: DEBUG: Running task 298 on Do: Mount [09:06] led to reset devices.list on /system.slice: Invalid argument [09:07] ikey: hmmm, can you do "snap changes" [09:07] https://hastebin.com/eramororan.sql [09:07] pedronis: i hate that i can't get aliases from the app info :-) [09:08] Chipaca: they are not part of the snap anymore [09:08] pedronis: i know [09:08] 2 Error 2017-08-09T18:51:45Z 2017-08-09T18:51:54Z Install "hello-world" snap [09:08] can you do "snap change 2" [09:08] Chipaca: anyway you should probably build whatever you build close to where we build the alias symlinks no? [09:08] so it shouldn't be your problem [09:08] ikey: I have libselinux.so.1 but it is in /lib which is not shared [09:09] have you verified that with LD_DEBUG=libs? [09:09] Chipaca: I don't know what you did for other apps, but isn't something you can take care of in backend or wrappers ? [09:09] ikey: let's try (though I bet it cannot be that simply because we pivot_root and ther host /lib is gone) [09:09] ikey: one more tip [09:09] pedronis: i was trying to do it in wrappers, but wrappers doesn't have them [09:09] ikey: snap run --shell snapname.appname [09:09] Chipaca: s/other apps/normal app entry points/ [09:09] ikey: this drops you in a shell [09:09] pedronis: so i've got to do it in backend [09:09] aite [09:10] where you can run stuff with same environment and other magic [09:10] pedronis: (the "normal" app entry points are done in wrappers) [09:10] useful for debugging [09:10] Chipaca: backend has stuff both for normal entrypoints and aliases so yes, seems a reasonable place [09:10] crosscutting concerns and everything considering [09:10] the --shell looks an awful lot like my host system [09:11] ikey: look at /proc/mountinfo [09:11] ikey: aaaah [09:11] I know what's the problem [09:11] maaan [09:11] so obscure [09:11] :D [09:11] sorry, it's my fault entirely [09:11] go to cmd/snap-confine [09:11] mwhudson: many thanks, uploaded, waiting for the confirmation mail [09:12] Chipaca: it seems simple, I'm probably missing something, because we do tell backend about what aliases we want to make very precisely [09:12] ikey: sorry, go to cmd/libsnap-confine-private and fix classic.c [09:12] pedronis: and, to make things more interesting, UpdateAliases doesn't clean up on error [09:12] ikey: super obscure because most distros are derivatives so we didn't notice [09:12] bool is_running_on_classic_distribution() [09:12] o_O [09:12] pedronis: [09:12] pedronis: :-) [09:12] ikey: snapd knows this via other means but currently it doesn't say to snap-confine "you are on a classic distro" [09:12] mvo: you uploaded it to ubuntu :) [09:12] pedronis: quick question - I want to add auto-download/install of misisng bases (and also of missing content-provider snaps). do you think snapstate is the right place? [09:12] and what does "classic distro" mean? [09:13] ikey: snapd can run in a "core" distro where everything is a snap [09:13] mwhudson: yes and to debian [09:13] ikey: like ubuntu-core [09:13] mwhudson: for good measure ;) [09:13] mvo: ah ok [09:13] mvo: yes [09:13] Rejected: [09:13] Unable to find distroseries: unstable [09:13] mwhudson: no, sorry, the initial upload was a mistake [09:13] ikey: the kernel is a snap, the whole host filesystem is a snap, etc [09:13] wait so right now snapd is acting like its on ubuntu core? [09:13] mvo: ok:) [09:13] so close yet so far away to getting samba running as a snap [09:13] pedronis: great, I will move forward with that [09:13] ikey: and in that mode, we don't have the mount namespace changes since the main namespace is the core snap already [09:13] xD [09:13] ikey: that is actually going away as we introduce bases [09:13] gotcha [09:13] ldb: unable to stat module //lib/samba/ldb : No such file or directory buit the dir is populated with the modules [09:13] mvo: remember that auto-refresh doesn't even go through api anymore for example [09:13] ikey: but it is a pretty obscure part of snapd :) [09:13] mwhudson: happens all the time to me, I need to write me something that refuses to upload debian distor names to ubuntu [09:13] ikey: sorry and thank you for finding it [09:13] awkward ikey with his not-derivative-ness [09:13] thanks bud [09:13] pedronis: yes, good point [09:13] ikey: that should fix a loooot of things :) [09:14] yeah im sure lol [09:14] mvo: so there's probably not even another option atm [09:14] mvo: i have this desire to write a wrapper for dput that does a whole bunch of validation [09:14] alright lemme rebase my patch and make it all solusy [09:14] mvo: like, if the target is a ppa and the version doesn't have "~ppa" in --> DENIED [09:14] thank you :) [09:14] * zyga-suse adds that to his mental porting list [09:15] mvo: that test fails all the time, let me investigate [09:15] mwhudson: I would give you an extra hug for such a wrapper [09:15] mwhudson: I have a desire for a debian dev tool that is not a wrapper over wrappers over perl but ... well [09:15] * zyga-suse sings along [09:15] zyga-suse: there are go libraries for all this stuff :) [09:16] but tbh i find the perl ones easier to use [09:16] go-debhelper? [09:16] ;-) [09:16] pault.ag/Debian/something [09:16] fair enough, at some point the amount of ducktape exceeds critical mass and we get a black hole of packaging [09:18] you think that hasn't happened already? :) [09:18] * zyga-suse grabs some coffee while deps are pulled [09:20] zyga-suse: I'm preparing 2.27 now, should I also update the packaging/suse snapd.spec file? [09:20] mvo: perhaps-ish, in which way? [09:21] zyga-suse: bump version number, add changelog [09:21] mvo: please, I'll do the rest [09:21] zyga-suse: this is what I currently do on fedora too [09:21] zyga-suse: ok [09:21] I will probably have more patches that I merge back to master [09:21] mvo: I'm worried about that test failure though [09:21] I'm running it now [09:21] zyga-suse: the prune one? [09:21] yes [09:21] mvo: (there's also arch, if you have one vm handy) [09:22] mvo: I merged arch packaging back [09:22] I think we had it for a long time, no regression [09:22] zyga-suse: I have no vm but I can upadate version and changelog there too [09:22] mvo: I think we fixed a while ago [09:22] mvo: not sure if there's a changelog, look if anything seems obviously stale there [09:22] mvo: I'll update arch as soon as I'm done with opensuse [09:23] zyga-suse: what does "Release: 2" in the suse spec file mean? [09:23] mvo: it's -2 in debian-speak [09:23] reset that to 1 if the upstream version is bumped [09:23] zyga-suse: aha, so I set it back to -1 ? [09:23] precisely :) [09:23] ta [09:23] zyga-suse: there is no changelog in the suse spec file so that update is easy :) [09:24] mvo: suse changelogs are in separate files [09:24] snapd.changes [09:24] * zyga-suse sings along [09:24] zyga-suse: fun [09:24] so many ways to do everything [09:24] mvo: I suspect both suse and arch will carry small patches [09:24] mvo: but that is fine [09:24] let's get the 2.27 elephant out of the door [09:25] mvo: I plan to test your /snap symlink support patch in arch and add that to the release [09:25] pedronis: remember the prune test that failed? [09:25] * mwhudson stares at the upstream packaging/ubuntu-16.04 and the one from debian's 2.21-2 [09:25] pedronis: either something changed or our fix was wrong because it just always fails on opensuse tumbleweed for me [09:26] zyga-suse: I don't know [09:26] zyga-suse: yeah, I have no arch packaging in the 2.27 branch so I will ignore that for now [09:26] always seems strange though [09:26] mwhudson: is it very different? [09:26] https://paste.gnome.org/p0rrl0u4j [09:26] pedronis: can you have a look if that rings a bell? [09:26] I mean it seems unrelated to details of the test [09:26] mvo: no, not really [09:26] mvo: well, yes [09:26] mvo: vendorized vs not [09:26] zyga-suse: that part is easy :) [09:26] pedronis: ah, that I agree with [09:27] mwhudson: if you think it makes sense we can put the debian packaging into upstream git as well [09:27] zyga-suse: nothing obvious comes to mind [09:27] pedronis: let me dig, then [09:28] zyga-suse: what format is supported in snapd.changes? or is that just free form? [09:28] mvo: "osc vc" format [09:28] * mvo googles [09:28] one sec [09:29] https://paste.gnome.org/pz2dhm3qz [09:29] mvo: that's my latest entry [09:29] (still WIP) [09:29] entries are delimited by those dashes [09:29] zyga-suse: also remember we fixed one but I think there's another one to fix, that we never got to [09:29] mvo: yeah that might make sense [09:29] pedronis: yes but this is the one we fixed AFAIK [09:29] zyga-suse: mostly wondering about nesting [09:30] mvo: not sure [09:30]