[00:51] <mup> PR snapcraft#1470 closed: catkin plugin: default to release build <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1470>
[01:58] <jaggz> snap install /tmp/meshlab-cYdtAIYBmTS1b7L2q8yrMdpAZ38qLv6Q_4.snap
[01:58] <jaggz> - 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] <jaggz> anyone know what that's about?  the dir exists.  I also intermittently get a core error
[01:59] <jaggz> ...
[01:59] <jaggz> # snap refresh core
[01:59] <jaggz> error: cannot perform the following tasks:
[01:59] <jaggz> - 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] <mup> PR snapd#3701 opened: tests: fix interfaces-cups-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3701>
[03:33] <PhoenixMage> How jailed are snaps? They seem to log to the root /var/log
[03:34] <PhoenixMage> ie, I now have samba.log files in /var/log after installing the samba snap I am working on
[04:24] <mup> PR snapd#3702 opened: interfaces: add missing test for camera interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3702>
[05:26] <mup> PR snapd#3703 opened: interfaces: improve and tweak bunch of interfaces test cases <Created by adglkh> <https://github.com/snapcore/snapd/pull/3703>
[05:43] <PhoenixMage> What is the correct way to create required directories for a snap?
[05:43] <PhoenixMage> ie, /etc if it doesnt exist?
[05:43] <PhoenixMage> Hooks?
[07:52] <mup> PR snapd#3704 opened: interfaces: convert lxd to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3704>
[07:54] <zyga-suse> good morning
[07:57] <zyga-suse> mvo: how are we doing?
[07:57] <mup> PR snapd#3657 closed: daemon, client, cmd/snap: implement snap start/stop/restart <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3657>
[07:57] <Chipaca> woooooooooooooo
[07:58] <zyga-suse> hey Chipaca, feels good to have the merge go in :)
[08:00] <Chipaca> yes
[08:02] <mvo> hey zyga-suse
[08:05] <mwhudson> zyga-suse: o/
[08:06] <zyga-suse> hey hey
[08:07] <zyga-suse> I have one important bug to check and then I'd like to release suse and arch packages
[08:14] <zyga-suse> some perspective form appimage developers: https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Issues
[08:14] <mup> PR snapd#3705 opened: interfaces: convert lxd_support to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3705>
[08:14] <mvo> zyga-suse: can you check if rc9 builds?
[08:15] <zyga-suse> mvo: sure, where?
[08:15] <mvo> zyga-suse: suse, arch
[08:16] <zyga-suse> with pleasure
[08:16] <zyga-suse> do you have tarballs?
[08:16] <zyga-suse> I'll build master locally but it would help to have rc tarballs
[08:16] <mvo> zyga-suse: I can prepare one, otherwise in the ppa
[08:16] <zyga-suse> (do you still make them manually?)
[08:17] <zyga-suse> for various reasons it is easier if they are on github (various tools can pull them like in debian)
[08:17] <mvo> zyga-suse: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+files/snapd_2.27~rc9.tar.xz
[08:17] <mvo> zyga-suse: aha, ok
[08:17] <zyga-suse> ok
[08:17] <zyga-suse> this is fine
[08:17] <mvo> zyga-suse: ok, thank you. I have a script that creates them now
[08:18] <zyga-suse> awesome, it would be good to commit that to the tree at some point
[08:18] <mup> PR snapd#3700 closed: tests: fix for  upgrade test on fedora <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3700>
[08:19] <mup> PR snapd#3706 opened: asserts,overlord/devicestate: support predefined assertions that don't establish foundational trust <Created by pedronis> <https://github.com/snapcore/snapd/pull/3706>
[08:28] <mwhudson> zyga-suse: so what's the debian update waiting on?
[08:28] <zyga-suse> mwhudson: not sure, I didn't look at debian seriously for too long :/
[08:28] <zyga-suse> mwhudson: I think we want 2.27 across the stack
[08:28] <mwhudson> zyga-suse: ok
[08:30] <mwhudson> zyga-suse: on the dependency side
[08:30] <mwhudson> zyga-suse: we can leave the i18n commented out for now i guess
[08:31] <zyga-suse> I think that's acceptable
[08:31] <mwhudson> zyga-suse: i need to find a sponsor to upload golang-go-flags-dev
[08:31] <zyga-suse> is the patch extensive?
[08:31] <zyga-suse> oh, I assumed you are a DD
[08:31] <mwhudson> no
[08:31] <mwhudson> zyga-suse: not yet :)
[08:31] <mwhudson> i am in the process
[08:31] <zyga-suse> great :)
[08:31] <mvo> mwhudson: let me know, I can help
[08:32] <mwhudson> the x/net fork can be avoiding by simply not running that test in the build?
[08:32] <mwhudson> mvo: https://anonscm.debian.org/cgit/pkg-go/packages/golang-go-flags.git/
[08:33] <mwhudson> oh wait
[08:33] <mvo> 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] <zyga-suse> some things failed on 2.25 still, but perhaps just racy tests
[08:34] <zyga-suse> I'll focus on 2.27
[08:35] <mwhudson> mvo: ack
[08:36] <zyga-suse> mvo: the tarball has different name and internal directory name than the one before
[08:37] <zyga-suse> not complaining but pointing out that we should perhaps use snapd-$version on the inside
[08:37] <zyga-suse> and pick whatever fixed on the outside
[08:37] <mvo> zyga-suse: meh, yes
[08:37] <mvo> zyga-suse: part of the problem is the debian build tools, but I don't want to make excuses
[08:37] <mvo> zyga-suse: I look into it
[08:37] <zyga-suse> debian build tools?
[08:37] <mvo> zyga-suse: the tarball is generated from the git repo, I will see what I can do with git-buildpackage
[08:38] <zyga-suse> ok
[08:41] <mwhudson> zyga-suse, mvo: and we thing we can use upstream instead of github.com/mvo5/libseccomp-golang for debian?
[08:41] <zyga-suse> I'd love to
[08:41] <zyga-suse> mvo: is that under golang CLA?
[08:44]  * zyga-suse needs to refresh some patches
[08:44] <zyga-suse> well
[08:44] <zyga-suse> packaging 010
[08:44] <zyga-suse> 101 even :P
[08:45] <mwhudson> 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] <ikey> zyga-suse, what are the chances of getting core snap to ship libselinux?
[08:46] <zyga-suse> ikey: hey
[08:46] <ikey> heya
[08:46] <zyga-suse> ikey: I saw your comments
[08:46] <zyga-suse> ikey: I need to look into it
[08:46] <mvo> mwhudson: yeah, upstream libseccomp-golang should be fine, all I did there was adjust for trusty
[08:46] <zyga-suse> ikey: it feels more like a bug in the app than something that really really should be in the core
[08:46] <mvo> mwhudson: our trusty libseccomp is heavily backported
[08:47] <ikey> zyga-suse, well its all over the place
[08:47] <zyga-suse> ikey: but I want to look at it for real before making any calls
[08:47] <mwhudson> okidoke
[08:47] <ikey> core's own Things use libselinux
[08:47] <ikey> like gio-querymodules:
[08:47] <ikey> and other bits
[08:47] <ikey> it would seem core isn't as clean and self contained as it thinks it is
[08:47] <zyga-suse> ikey: I see ./lib/x86_64-linux-gnu/libselinux.so.1
[08:48] <zyga-suse> (that's relative to core itself)
[08:48] <ikey> is it possible this is some derpy side effect of not having rexec?
[08:48] <ikey> *re-exec
[08:48] <zyga-suse> no, probably a bug somewhere else
[08:48] <ikey> ok
[08:48] <zyga-suse> look at dirs/dirs.go
[08:48] <zyga-suse> I think you may need to say that on solus you use lib64 to keep distro binaries
[08:48] <ikey> im loath to including libselinux in solus because, well, it infects stuff
[08:48] <mwhudson> mvo: http://people.canonical.com/~mwh/golang-go-flags-dev/
[08:48] <zyga-suse> (AFAIR snapd is there
[08:49] <zyga-suse> as are other relevant parts)
[08:49] <ikey> ah so multiarch vs multilib
[08:49] <ikey> curious, ty
[08:49] <zyga-suse> ikey: you should never have to include anything in the distribution to make a given snap work
[08:49] <ikey> that was my thought
[08:49] <zyga-suse> snaps don't see anything from the host really (not libraries)
[08:49] <zyga-suse> ikey: do you know how it roughly works at runtime?
[08:50] <zyga-suse> 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] <zyga-suse> ikey: some things like /dev, /proc and /sys are "normal" (dev may be empty-ish, depending on confinement)
[08:50] <zyga-suse> ikey: some things from the host are overlaid (e.g. parts of /etc)
[08:50] <ikey> right
[08:50] <zyga-suse> ikey: /home and /root are shared but $HOME is changed
[08:51] <zyga-suse> ikey: the real host root filesysystem is in /var/lib/snapd/hostfs
[08:51] <zyga-suse> ikey: (with certain things unmounted, like sysfs and dev because it confuses apps
[08:51] <zyga-suse> ikey: there's a long tail of small tweaks
[08:51] <ikey> aye
[08:51] <zyga-suse> ikey: but the main point is: the host distribution is not used for runtime libraries or executables
[08:52] <ikey> well thats the theory
[08:52] <zyga-suse> no, we really don't use them, what do you mean?
[08:52] <ikey> well at this point its not completely using the core snap either
[08:52] <zyga-suse> yep, something is not right yet
[08:53] <zyga-suse> but I bet this is packaging issue
[08:53] <zyga-suse> if you want I can install solus and help you out
[08:53] <ikey> you'll forgive me for saying but i dont quite see *how* it would be a packaging issue
[08:53] <zyga-suse> I'm working on opensuse and arch but then I can try out solus :)
[08:53] <ikey> when it looks more like the helper scripts are invoked host side
[08:53] <ikey> and not containerised
[08:54] <zyga-suse> can you please run the hello snap after setting SNAP_CONFINE_DEBUG=yes
[08:54] <ikey> setting where, /etc/environment?
[08:54] <zyga-suse> ikey: oh, one important point: if a snap uses 'classic confinement' then none of what I just said is true
[08:54] <ikey> sure
[08:54] <zyga-suse> ikey: just export it in your shell
[08:54] <zyga-suse> classic confinement is a different beast
[08:55] <ikey> yeah thats more at the appimage end of the spectrum
[08:55] <zyga-suse> mvo: this is still breaking: [  622s] FAIL: overlord_test.go:360: overlordSuite.TestEnsureLoopPrune
[08:55] <ikey> https://hastebin.com/ixovewisig.sql
[08:56] <mvo> zyga-suse: breaking where?
[08:56] <zyga-suse> mvo: the unit test fails randomly
[08:56] <zyga-suse> mvo: run it 1000 times and see the failure rate
[08:57] <mvo> ok
[08:57] <zyga-suse> ikey: this worked, can you try with a more complex snap next? what did you try to use before?
[08:57] <ikey> brackets went boom
[08:57] <ikey> but thats classic
[08:57] <zyga-suse> ikey: brackets is a classic snap :/
[08:57] <zyga-suse> so classic confinement uses different things
[08:57] <ikey> yer
[08:58] <zyga-suse> and what must be happening is that the snap itself is broken
[08:58] <zyga-suse> classic confinement is defined as follows:
[08:58] <ikey> a large number of them are broken*
[08:58] <Chipaca> pedronis: o/
[08:58] <zyga-suse> there is no file-system redirection
[08:58] <zyga-suse> the core snap is in a well-known spot
[08:58] <zyga-suse> as is the snap itself
[08:58] <zyga-suse> those resources are guaranteed
[08:58] <ikey> sure but wouldnt you also alter LD_LIBRARY_PATH to factor in core runtime?
[08:58] <ikey> before executing the snap
[08:58] <zyga-suse> other resources MAY be used but the snap author must do that with sanity
[08:59] <zyga-suse> ikey: no, because that's snaps responsibility, some snaps are built in a way that this is not a factor
[08:59] <zyga-suse> eg.
[08:59] <zyga-suse> try python0
[08:59] <ikey> eh
[08:59] <zyga-suse> and look at the binary itself
[08:59] <zyga-suse> and at how it is linked
[08:59] <ikey> yeah im gonna have to disagree there
[08:59] <zyga-suse> the fact is that many snap with classic confinement are built in as sloppy way
[08:59] <ikey> so even with LD_LIBRARY_PATH, rpath is going to work fine
[08:59] <zyga-suse> ikey: I can tell you why we're not setting LD_LIBRARY_PATH
[08:59] <zyga-suse> ikey: because that breaks classic snaps that do certain things
[08:59] <zyga-suse> there's no silver bullet here,
[09:00] <zyga-suse> snaps using classic confinement *may* run apps from the host distribution
[09:00] <zyga-suse> and then setting this would break that
[09:00] <zyga-suse> I would argue that brackets is just done incorrectly and assumes to run on a ubuntu-ish system too much
[09:00] <ikey> right but its not *just* brackets that fails
[09:00] <ikey> its the scratch setup scripts in core
[09:00] <ikey> i.e. update icon cache, schemas, etc
[09:00] <zyga-suse> scratch setup scripts?
[09:00] <ikey> idk what you call them :P
[09:01] <zyga-suse> we don't have *any* scripts
[09:01] <zyga-suse> so whatever you are describing comes from the snap itself
[09:01] <zyga-suse> 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] <ikey> 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] <zyga-suse> ikey: that must be a common bug in those snaps then, I'm sure it can be addressed
[09:02] <zyga-suse> (note that core doesn't ship any of that)
[09:02] <zyga-suse> many snaps use a common helper
[09:02] <zyga-suse> 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] <ikey> non-classic:
[09:03] <ikey> (assuming duckmarines is non classic)
[09:03] <zyga-suse> snap info foo
[09:03] <ikey> /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] <zyga-suse> this will tell you
[09:03] <ikey> DEBUG: confinement:  non-classic
[09:03] <zyga-suse> when you install a snap you have to say --classic
[09:04] <zyga-suse> mm, that's more interesting, let me see
[09:04] <ikey> it does eventually flop (no doubt due to missing apparmor)
[09:04] <ikey> [1]    5959 invalid system call  snap run duckmarines
[09:04] <ikey> but im more interested in the library fail first
[09:04] <zyga-suse> ikey: invalid system call == it was killed by seccomp
[09:04] <zyga-suse> can you look at your journalctl/dmesg and look for seccomp
[09:04] <zyga-suse> I wonder what killed it
[09:04] <zyga-suse> are you on x86 or x86_64 system?
[09:05] <ikey> x86_64
[09:05] <zyga-suse> ok
[09:05] <zyga-suse> (there were some socket/socketcall bugs on 32bit intel systems0
[09:05] <zyga-suse> because kernel changed
[09:05] <ikey> not seeing errors in either. odd.
[09:05] <pedronis> Chipaca: hi
[09:05] <zyga-suse> ikey: interesting, I just ran duckmarines on opensuse and it worked, no messages about missing libselinux.so.1
[09:06] <ikey> can you verify if you have a host-side libselinux?
[09:06] <zyga-suse> let me see what's going on deeper
[09:06] <zyga-suse> ikey: again, host side libselinux is not accessible in any normal way
[09:06] <ikey> sure
[09:06] <ikey> but can you? :P
[09:06] <zyga-suse> yes, checking anyway :-)
[09:06] <ikey> im seeing this:
[09:06] <ikey> 17/08/10 10:02:33.232761 taskrunner.go:367: DEBUG: Running task 298 on Do: Mount
[09:06] <ikey> led to reset devices.list on /system.slice: Invalid argument
[09:07] <zyga-suse> ikey: hmmm, can you do "snap changes"
[09:07] <ikey> https://hastebin.com/eramororan.sql
[09:07] <Chipaca> pedronis: i hate that i can't get aliases from the app info :-)
[09:08] <pedronis> Chipaca: they are not part of the snap anymore
[09:08] <Chipaca> pedronis: i know
[09:08] <zyga-suse> 2    Error   2017-08-09T18:51:45Z  2017-08-09T18:51:54Z  Install "hello-world" snap
[09:08] <zyga-suse> can you do "snap change 2"
[09:08] <pedronis> Chipaca: anyway you should probably build whatever you build close to where we build the alias symlinks no?
[09:08] <pedronis> so it shouldn't be your problem
[09:08] <zyga-suse> ikey: I have libselinux.so.1 but it is in /lib which is not shared
[09:09] <ikey> have you verified that with LD_DEBUG=libs?
[09:09] <pedronis> 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] <zyga-suse> ikey: let's try (though I bet it cannot be that simply because we pivot_root and ther host /lib is gone)
[09:09] <zyga-suse> ikey: one more tip
[09:09] <Chipaca> pedronis: i was trying to do it in wrappers, but wrappers doesn't have them
[09:09] <zyga-suse> ikey: snap run --shell snapname.appname
[09:09] <pedronis> Chipaca: s/other apps/normal app entry points/
[09:09] <zyga-suse> ikey: this drops you in a shell
[09:09] <Chipaca> pedronis: so i've got to do it in backend
[09:09] <ikey> aite
[09:10] <zyga-suse> where you can run stuff with same environment and other magic
[09:10] <Chipaca> pedronis: (the "normal" app entry points are done in wrappers)
[09:10] <zyga-suse> useful for debugging
[09:10] <pedronis> Chipaca: backend has stuff both for normal entrypoints and aliases so yes, seems a reasonable place
[09:10] <pedronis> crosscutting concerns and everything considering
[09:10] <ikey> the --shell looks an awful lot like my host system
[09:11] <zyga-suse> ikey: look at /proc/mountinfo
[09:11] <zyga-suse> ikey: aaaah
[09:11] <zyga-suse> I know what's the problem
[09:11] <zyga-suse> maaan
[09:11] <zyga-suse> so obscure
[09:11] <zyga-suse> :D
[09:11] <zyga-suse> sorry, it's my fault entirely
[09:11] <zyga-suse> go to cmd/snap-confine
[09:11] <mvo> mwhudson: many thanks, uploaded, waiting for the confirmation mail
[09:12] <pedronis> 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] <zyga-suse> ikey: sorry, go to cmd/libsnap-confine-private and fix classic.c
[09:12] <Chipaca> pedronis: and, to make things more interesting, UpdateAliases doesn't clean up on error
[09:12] <zyga-suse> ikey: super obscure because most distros are derivatives so we didn't notice
[09:12] <ikey> bool is_running_on_classic_distribution()
[09:12] <ikey> o_O
[09:12] <Chipaca> pedronis: </rant>
[09:12] <Chipaca> pedronis: :-)
[09:12] <zyga-suse> ikey: snapd knows this via other means but currently it doesn't say to snap-confine "you are on a classic distro"
[09:12] <mwhudson> mvo: you uploaded it to ubuntu :)
[09:12] <mvo> 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] <ikey> and what does "classic distro" mean?
[09:13] <zyga-suse> ikey: snapd can run in a "core" distro where everything is a snap
[09:13] <mvo> mwhudson: yes and to debian
[09:13] <zyga-suse> ikey: like ubuntu-core
[09:13] <mvo> mwhudson: for good measure ;)
[09:13] <mwhudson> mvo: ah ok
[09:13] <pedronis> mvo: yes
[09:13] <mwhudson> Rejected:
[09:13] <mwhudson> Unable to find distroseries: unstable
[09:13] <mvo> mwhudson: no, sorry, the initial upload was a mistake
[09:13] <zyga-suse> ikey: the kernel is a snap, the whole host filesystem is a snap, etc
[09:13] <ikey> wait so right now snapd is acting like its on ubuntu core?
[09:13] <mwhudson> mvo: ok:)
[09:13] <PhoenixMage> so close yet so far away to getting samba running as a snap
[09:13] <mvo> pedronis: great, I will move forward with that
[09:13] <zyga-suse> ikey: and in that mode, we don't have the mount namespace changes since the main namespace is the core snap already
[09:13] <ikey> xD
[09:13] <zyga-suse> ikey: that is actually going away as we introduce bases
[09:13] <ikey> gotcha
[09:13] <PhoenixMage> ldb: unable to stat module //lib/samba/ldb : No such file or directory buit the dir is populated with the modules
[09:13] <pedronis> mvo: remember that auto-refresh doesn't even go through api anymore for example
[09:13] <zyga-suse> ikey: but it is a pretty obscure part of snapd :)
[09:13] <mvo> mwhudson: happens all the time to me, I need to write me something that refuses to upload debian distor names to ubuntu
[09:13] <zyga-suse> ikey: sorry and thank you for finding it
[09:13] <ikey> awkward ikey with his not-derivative-ness
[09:13] <ikey> thanks bud
[09:13] <mvo> pedronis: yes, good point
[09:13] <zyga-suse> ikey: that should fix a loooot of things :)
[09:14] <ikey> yeah im sure lol
[09:14] <pedronis> mvo: so there's probably not even another option atm
[09:14] <mwhudson> mvo: i have this desire to write a wrapper for dput that does a whole bunch of validation
[09:14] <ikey> alright lemme rebase my patch and make it all solusy
[09:14] <mwhudson> mvo: like, if the target is a ppa and the version doesn't have "~ppa" in --> DENIED
[09:14] <zyga-suse> thank you :)
[09:14]  * zyga-suse adds that to his mental porting list
[09:15] <zyga-suse> mvo: that test fails all the time, let me investigate
[09:15] <mvo> mwhudson: I would give you an extra hug for such a wrapper
[09:15] <zyga-suse> 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] <mwhudson> zyga-suse: there are go libraries for all this stuff :)
[09:16] <mwhudson> but tbh i find the perl ones easier to use
[09:16] <zyga-suse> go-debhelper?
[09:16] <zyga-suse> ;-)
[09:16] <mwhudson> pault.ag/Debian/something
[09:16] <zyga-suse> fair enough, at some point the amount of ducktape exceeds critical mass and we get a black hole of packaging
[09:18] <mwhudson> you think that hasn't happened already? :)
[09:18]  * zyga-suse grabs some coffee while deps are pulled
[09:20] <mvo> zyga-suse: I'm preparing 2.27 now, should I also update the packaging/suse snapd.spec file?
[09:20] <zyga-suse> mvo: perhaps-ish, in which way?
[09:21] <mvo> zyga-suse: bump version number, add changelog
[09:21] <zyga-suse> mvo: please, I'll do the rest
[09:21] <mvo> zyga-suse: this is what I currently do on fedora too
[09:21] <mvo> zyga-suse: ok
[09:21] <zyga-suse> I will probably have more patches that I merge back to master
[09:21] <zyga-suse> mvo: I'm worried about that test failure though
[09:21] <zyga-suse> I'm running it now
[09:21] <mvo> zyga-suse: the prune one?
[09:21] <zyga-suse> yes
[09:21] <zyga-suse> mvo: (there's also arch, if you have one vm handy)
[09:22] <zyga-suse> mvo: I merged arch packaging back
[09:22] <mvo> I think we had it for a long time, no regression
[09:22] <mvo> zyga-suse: I have no vm but I can upadate version and changelog there too
[09:22] <zyga-suse> mvo: I think we fixed a while ago
[09:22] <zyga-suse> mvo: not sure if there's a changelog, look if anything seems obviously stale there
[09:22] <zyga-suse> mvo: I'll update arch as soon as I'm done with opensuse
[09:23] <mvo> zyga-suse: what does "Release: 2" in the suse spec file mean?
[09:23] <zyga-suse> mvo: it's -2 in debian-speak
[09:23] <zyga-suse> reset that to 1 if the upstream version is bumped
[09:23] <mvo> zyga-suse: aha, so I set it back to -1 ?
[09:23] <zyga-suse> precisely :)
[09:23] <mvo> ta
[09:23] <mvo> zyga-suse: there is no changelog in the suse spec file so that update is easy :)
[09:24] <zyga-suse> mvo: suse changelogs are in separate files
[09:24] <zyga-suse> snapd.changes
[09:24]  * zyga-suse sings along 
[09:24] <mvo> zyga-suse: fun
[09:24] <zyga-suse> so many ways to do everything
[09:24] <zyga-suse> mvo: I suspect both suse and arch will carry small patches
[09:24] <zyga-suse> mvo: but that is fine
[09:24] <zyga-suse> let's get the 2.27 elephant out of the door
[09:25] <zyga-suse> mvo: I plan to test your /snap symlink support patch in arch and add that to the release
[09:25] <zyga-suse> 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] <zyga-suse> pedronis: either something changed or our fix was wrong because it just always fails on opensuse tumbleweed for me
[09:26] <pedronis> zyga-suse: I don't know
[09:26] <mvo> zyga-suse: yeah, I have no arch packaging in the 2.27 branch so I will ignore that for now
[09:26] <pedronis> always seems strange though
[09:26] <mvo> mwhudson: is it very different?
[09:26] <zyga-suse> https://paste.gnome.org/p0rrl0u4j
[09:26] <zyga-suse> pedronis: can you have a look if that rings a bell?
[09:26] <pedronis> I mean it seems unrelated to details of the test
[09:26] <mwhudson> mvo: no, not really
[09:26] <zyga-suse> mvo: well, yes
[09:26] <zyga-suse> mvo: vendorized vs not
[09:26] <mwhudson> zyga-suse: that part is easy :)
[09:26] <zyga-suse> pedronis: ah, that I agree with
[09:27] <mvo> mwhudson: if you think it makes sense we can put the debian packaging into upstream git as well
[09:27] <pedronis> zyga-suse: nothing obvious comes to mind
[09:27] <zyga-suse> pedronis: let me dig, then
[09:28] <mvo> zyga-suse: what format is supported in snapd.changes? or is that just free form?
[09:28] <zyga-suse> mvo: "osc vc" format
[09:28]  * mvo googles
[09:28] <zyga-suse> one sec
[09:29] <zyga-suse> https://paste.gnome.org/pz2dhm3qz
[09:29] <zyga-suse> mvo: that's my latest entry
[09:29] <zyga-suse> (still WIP)
[09:29] <zyga-suse> entries are delimited by those dashes
[09:29] <pedronis> zyga-suse: also remember we fixed one but I think there's another one to fix, that we never got to
[09:29] <mwhudson> mvo: yeah that might make sense
[09:29] <zyga-suse> pedronis: yes but this is the one we fixed AFAIK
[09:29] <mvo> zyga-suse: mostly wondering about nesting
[09:30] <zyga-suse> mvo: not sure
[09:30] <mvo> mwhudson: let me know if I can help, otherwise I will welcome a PR :)
[09:30] <zyga-suse> pedronis: this is confirmed by git blame: 59472d24b3
[09:30] <pedronis> anyway always seems weird
[09:31] <zyga-suse> ikey: does it work better now/
[09:31] <zyga-suse> ikey: I'm really surprised even "hello" worked :)
[09:31] <zyga-suse> maybe because it is a shell script
[09:32] <ikey> zyga-suse, so
[09:32] <ikey> done some initial porting
[09:32] <ikey> there are more odd assumptions
[09:32] <ikey> /run/media is locked to MERGED_USR
[09:32] <ikey> that shouldn't be the case
[09:32] <ikey> /run/media is just modern-systemd-fhs-udev-udisks
[09:33] <ikey> and shouldn't rely on the MERGED_USR assumption
[09:33] <ikey> additionally.. why is /usr/src required?
[09:33] <ikey> this makes little sense to me ..
[09:33] <zyga-suse> ikey: some snaps have permissions to build and load a kernel module and they require access to the kernel source, if you have some on the machine
[09:33] <ikey> woa. no
[09:33] <ikey> thats wrong :P
[09:34] <zyga-suse> ikey: this is specifically for some bleeding edge observing/monitoring tools
[09:34] <ikey> so how do I turn off all kernel related functionality in snapd?
[09:34] <zyga-suse> ikey: that's not wrong, that's a permission that is controlled by snapd
[09:34] <ikey> believe me snapd isnt going to be able to deal with solus kernels
[09:34] <ikey> hell GRUB barely can
[09:34] <zyga-suse> ikey: this is all controlled by interfaces, unsafe interfaces are not allowed unless there's an assertion saying that a given snap from a given developer is trusted to do something specific
[09:34] <zyga-suse> ikey: e.g. we allow docker and lxd to do a lot of stuff to function
[09:35] <ikey> yeah i want to disable this at the distribution level
[09:35] <zyga-suse> ikey: because no meaningful way to confine them exists
[09:35] <ikey> kernel modules on solus should come only from our repositories
[09:35] <ikey> our kernels dont work like ubuntu kernels
[09:35] <zyga-suse> ikey: note that snaps won't be able to load those modules
[09:35] <zyga-suse> ikey: /usr/src is so that they can build them
[09:35] <zyga-suse> ikey: loading is controlled with seccomp and snapd interfaces
[09:36] <zyga-suse> ikey: that's fine, not all systems must support all interfaces
[09:36] <ikey> you'll see what i mean here about kernels: https://hastebin.com/ulureceful.go
[09:37] <ikey> i could potentially include an empty /usr/src (no owner) directory in the snapd pkg
[09:37] <ikey> which might mitigate that bit
[09:37] <zyga-suse> ikey: I think we just want to make that non-mandatory
[09:37] <zyga-suse> ikey: it's better
[09:37] <zyga-suse> ikey: and we are doing some of that for base snaps
[09:37] <ikey> gotcha
[09:38] <zyga-suse> ikey: where you can create an app that runs on top of really empty filesystem, with except for things like /snap to mount the actual code
[09:38] <ikey> ah
[09:38] <ikey> nice
[09:38] <zyga-suse> ikey: so you could eventually make snaps that use solus as a base
[09:38] <zyga-suse> ikey: and they still work on fedora/debian/opensuse
[09:38] <ikey> yeah i can definitely see use cases for that
[09:39] <zyga-suse> ikey: (mvo is leading that work)
[09:39] <ikey> fair play :]
[09:39] <zyga-suse> indeed!
[09:39] <zyga-suse> ikey: if you are interested in the security aspect I really encourage you to look at interfaces/
[09:39] <zyga-suse> ikey: all snaps get the same confinement by default
[09:39] <zyga-suse> ikey: and if you want to change that confinement you need to use one of the interfaces
[09:39] <zyga-suse> ikey: interfaces are like contracts between two parties
[09:39] <zyga-suse> ikey: and interfaces are not just permissions
[09:40] <ikey> right
[09:40] <zyga-suse> ikey: they come in pairs, a plug and a slot that may be connected
[09:40] <ikey> sorta like protocols
[09:40] <ikey> gotcha
[09:40] <ikey> [Package] Including empty directory: /usr/src
[09:40]  * ikey cheated
[09:40] <zyga-suse> ikey: simple things like "I want to create sockets and connect to the network" are so common that the slot is offered by the core snap implicitly
[09:40] <ikey> right
[09:40] <zyga-suse> ikey: but slots and plugs are really numerous, e.g. a slot representing a serial port
[09:41] <zyga-suse> ikey: on the dell gateway device there are a few of those
[09:41] <zyga-suse> ikey: and if you install a snap that does something over a serial port
[09:41] <zyga-suse> ikey: and connect it to the one you want (e.g. the "2nd serial port from the left"
[09:41] <zyga-suse> ikey: only *then* will that snap get permissions to talk to *that* particular device
[09:41] <zyga-suse> ikey: that's the general idea
[09:41] <zyga-suse> ikey: interface defines the "way to communicate"
[09:42] <zyga-suse> ikey: be it a file path, system call, or lots of complex rules
[09:42] <zyga-suse> ikey: each interface can control many aspects of the system sandbox: seccomp, apparmor, kernel modules, udev tagging, dbus bus permissions, etc
[09:42] <ikey> gotcha
[09:42] <ikey> makes sense
[09:42] <zyga-suse> ikey: interfaces are merged into snapd and audited for secuirty
[09:43] <zyga-suse> ikey: snaps can use powerful interfaces after having an assertion that say we trust them to do this
[09:43] <ikey> aye
[09:43] <zyga-suse> ikey: "powerful" interfaces are those that may break out of confinement (e.g. docker) or those that may expose user data or other privacy aspects
[09:43] <zyga-suse> that's about the rough idea
[09:44] <ikey> ok well progress
[09:44] <zyga-suse> ikey: if you have any security questions I'd love to know :-)
[09:44] <ikey> no library issues
[09:44] <zyga-suse> \o/
[09:44] <ikey> No schema files found: doing nothing.
[09:44] <ikey> [1]    2094 invalid system call  snap run duckmarines
[09:44] <zyga-suse> ikey: that syscall is worrying
[09:44] <zyga-suse> can you look at system logs and see if you see any audit messageS?
[09:44] <zyga-suse> (unless audit is off on solus)
[09:44] <ikey> audit is off because systemd broke it
[09:44] <zyga-suse> hmm?
[09:45] <ikey> you'd gain a 50gb ring buffer in a matter of minutes
[09:45] <ikey> they got into a fight
[09:45] <zyga-suse> do you see _anything_ in the logs when that message is printed
[09:45] <zyga-suse> specifically, which system call it is
[09:45] <ikey> nothing related now
[09:45] <zyga-suse> as a cheap wokraround you can disable seccomp
[09:45] <zyga-suse> --without-seccomp to configiure
[09:45] <zyga-suse> *configure
[09:45] <ikey> yeah but that seems nasty :p
[09:46] <zyga-suse> indeed
[09:46] <ikey> ill see if its kernel specific and try the LTS 4.9
[09:46] <zyga-suse> ikey: my gut feeling says it's related to socket
[09:46] <zyga-suse> 99% of our issues are there
[09:46] <zyga-suse> mybe it's a 32bit app running in a 64bit system
[09:46] <zyga-suse> also check libseccomp version
[09:47] <zyga-suse> we fixed some bugs there and maybe you are still affected
[09:47] <ikey> Name                : libseccomp, version: 2.3.2, release: 4
[09:48]  * ikey sees https://github.com/seccomp/libseccomp/commit/73d83e45efbe8c31067c97155162f17ca51b7435
[09:48] <zyga-suse> is that in your version?
[09:48] <ikey> nay
[09:48] <zyga-suse> aha
[09:48] <ikey> so im gonna take it to git
[09:48] <zyga-suse> may be it :)
[09:48] <zyga-suse> yeah, we're all pushing the edges here
[09:49] <ikey> *unfortunately* you guys forcibly statically link libseccomp :P
[09:49] <zyga-suse> working on snapd over last year we found so many interesting kernel bugs
[09:49] <zyga-suse> ikey: that's a workaround that I want to fix after 2.27
[09:49] <zyga-suse> it's all complex, nothing is perfect
[09:49] <zyga-suse> we really want to statically link it in one specific case
[09:50] <zyga-suse> I'll flipt the workaround
[09:50] <zyga-suse> you can link it dynamically
[09:50] <ikey> s'ok i can just rebuild :p
[09:50] <mwhudson> zyga-suse, mvo: EOD-ing now, hopefully some action tomorrow!
[09:50] <zyga-suse> mwhudson: thank you, enjoy your evening!
[09:52] <zyga-suse> ikey: and if you have initial patches for solus please start sending them
[09:54] <mup> PR snapd#3707 opened: interfaces: convert io_ports_control to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3707>
[09:59]  * ikey sighs at libseccomp abuse of configure.ac
[10:13] <ikey> [1]    1730 invalid system call  snap run duckmarines
[10:13] <ikey> poo.
[10:15] <zyga-suse> I think you have to find the number somehow
[10:16] <zyga-suse> is that still from snap-confine or from the suckmarines binary alreday?
[10:17] <ikey> idk, from "snap run duckmarines"
[10:17] <ikey> also, this is new:
[10:17] <ikey> error: cannot install "brackets": classic confinement is not yet supported on
[10:17] <ikey>        your distribution
[10:17] <zyga-suse> ikey: do you have /snap?
[10:18] <zyga-suse> ikey: classic confinement relies on this to exist
[10:18] <ikey> no im using /var/lib/snapd/snap
[10:18] <zyga-suse> ikey: there's a patch from mvo that makes that an actual check, not a hard-coded list
[10:18] <zyga-suse> then no classic confinement :/
[10:18]  * ikey patches it.
[10:18] <ikey> or are they all built that way?
[10:18] <zyga-suse> patches it how?
[10:18] <ikey> for /snap/
[10:18] <zyga-suse> they *require* /snap
[10:18] <ikey> ew
[10:18] <ikey> k.
[10:18] <zyga-suse> because classic confinement doesn't use mount namespaces and other goodies
[10:19] <zyga-suse> so it has no other way to say "this is something you can hard-code in your binaries"
[10:19] <ikey> so then classic confinement snaps (like - a whole bunch of them) wont work on most distros?
[10:19] <ikey> because they're using /var/lib/snapd/snap?
[10:19] <ikey> sod that
[10:19]  * ikey switches to /snap
[10:19] <ikey> im not *that* torn up about the FHS
[10:19] <zyga-suse> ikey: so far they don't work on fedora and arch but I'm not sure if arch will keep it that way
[10:19] <zyga-suse> fedora is very political about that, but I respect their decision
[10:20] <zyga-suse> ikey: with a patch proposed by mvo a symlink from /snap to /var/lib/snapd/snap is enough
[10:20] <zyga-suse> ikey: note that you need to patch both snapd and re-configure snap-confine
[10:20] <zyga-suse> ikey: when you make this decision
[10:20] <ikey> sure but at that point you have /snap anyway
[10:20] <ikey> so might as well use it
[10:20] <zyga-suse> ikey: yes
[10:20] <ikey> symlink or not
[10:21] <zyga-suse> I'd love to standardize /snap as a optional FHS feature one day
[10:21] <zyga-suse> ikey: (you want to see dirs/dirs.go for the snapd side)
[10:21] <zyga-suse> ikey: I think /snap is default though, not sure what you changed already
[10:22] <ikey> changed dirs.go
[10:22] <ikey> ill change it back
[10:25] <ikey> ok so im back to having classic "work"
[10:25] <ikey> im gonna have to bite the bullet probably and package up libselinux and provide the invalid ubuntu-named gtk-update-icon-cache-3.0
[10:25] <ikey> and that should "fix" the vast majority of classic snaps
[10:25] <zyga-suse> thank you!
[10:25] <ikey> and we'll use /snap too
[10:25] <zyga-suse> we should also do better checks on classic confinement snaps
[10:25] <zyga-suse> to figure out how to make that a bound problem
[10:26] <zyga-suse> not a "whack-a-mole"
[10:26] <ikey> aye
[10:26] <zyga-suse> ikey, sergiusens: hacks on the build tool, snapcraft
[10:26] <ikey> ah ok
[10:26] <zyga-suse> well, the meta-build swiss-army-knife
[10:26] <ikey> so what you could do is effectively an ABI report on the root and discover missing bits
[10:26] <zyga-suse> ikey: yeah, I think he is partially doing that today, not sure if at symbol level
[10:26] <ikey> so i wrote a tool while i was at intel to do simple abi reports: https://github.com/clearlinux/abireport
[10:27] <zyga-suse> oh, neat
[10:27] <zyga-suse> sergiusens: ^^ you want to see that
[10:27] <ikey> so in solus it looks like this:
[10:27] <ikey> https://dev.solus-project.com/source/libseccomp/browse/master/abi_symbols
[10:27] <ikey> https://dev.solus-project.com/source/libseccomp/browse/master/abi_used_libs
[10:27] <zyga-suse> neat
[10:27] <zyga-suse> I think we can learn from that
[10:27] <ikey> but i figured you could steal the core of abireport (Apache-2.0) to create a new kind of ABI tracker
[10:28] <ikey> that way you can raise warnings when there are missing providers for a used symbol
[10:28] <zyga-suse> yeah, I'm sure we can improve a lot in the tooling used so far;
[10:28] <zyga-suse> all the new-kind-of-apps projects are a huge community learning exercise
[10:28] <zyga-suse> and collective pushing-the-boundary work
[10:28] <ikey> fwiw i found it quite amusing when i saw the initial snap format
[10:29] <ikey> given how close it is the solus format
[10:29] <zyga-suse> yeah?
[10:29] <ikey> https://dev.solus-project.com/source/libseccomp/browse/master/package.yml
[10:29] <zyga-suse> btw, I'm not familiar with solus packages
[10:29] <zyga-suse> can you tell me more about them
[10:29] <ikey> that there is the build file for libseccomp
[10:29] <zyga-suse> ha
[10:29] <zyga-suse> interesting
[10:29] <ikey> we focus on automation and correctness
[10:29] <zyga-suse> did you see snapcraft.yaml?
[10:29] <zyga-suse> the one thing I love snapcraft did
[10:29] <mvo> ikey: nice, this looks way better than the spec files
[10:29] <zyga-suse> is to separate parts
[10:29] <ikey> so that actually splits into libseccomp and libseccomp-devel
[10:29] <ikey> (and libseccomp-dbginfo)
[10:29] <zyga-suse> so that you can have one snap with two elements inside
[10:30] <zyga-suse> one, say, written in C with typical build-install code
[10:30] <ikey> if you add emul32: yes you'll get libseccomp-32bit and libseccomp-32bit-dbginfo and libseccomp-32bit-devel
[10:30] <zyga-suse> and one written in something totally different, say python,
[10:30] <zyga-suse> and the logic is per-part
[10:30] <zyga-suse> so things compose more easily
[10:30] <ikey> yeah units is nice to have
[10:30] <ikey> the package.yml has some tricks up its sleeve like patterns
[10:30] <ikey> which dynamically constructs a subpackage based on a path math
[10:30] <zyga-suse> ikey: did you see http://build.snapcraft.io/ ?
[10:31] <ikey> s/mat/match/
[10:31] <ikey> failsed.
[10:31] <ikey> yeah its pretty
[10:31] <ikey> vs https://build.solus-project.com/
[10:31] <ikey> xD
[10:31] <zyga-suse> ikey: nice, I wrote something like that for debian a while back but it was not well received
[10:31] <ikey> yeaah Debian *enjoys* having hard packaging
[10:31] <ikey> very extreme example: https://dev.solus-project.com/source/libreoffice/browse/master/package.yml
[10:32] <ikey> id sooner do that than debian/control and debian/*.install ...
[10:32] <ikey> :p
[10:32] <ikey> (the format also supports profile guided optimisation and test suites fwiw)
[10:32] <zyga-suse> https://pypi.python.org/pypi/dh_splitpackage/0.2.3
[10:32] <zyga-suse> curiously the links to launchpad are dead
[10:33] <ikey> "without pulling your hair out" lol
[10:33] <zyga-suse> but the tarball is there
[10:33] <ikey> personally i find the linux world focuses too much on packages and package managers and superiority of these glorified tarballs (giftwraped, I guess)
[10:34] <ikey> i like to focus on features, scalability, delivery, cadence..
[10:34] <zyga-suse> ah
[10:34] <zyga-suse> found it
[10:34] <zyga-suse> http://bazaar.launchpad.net/~zyga/dh-splitpackage/trunk/view/head:/debian/splitpackage
[10:34] <zyga-suse> _ vs -
[10:34] <zyga-suse> yes, I agree a lot
[10:34] <ikey> oh cute yaml map
[10:35] <zyga-suse> not quite yaml but yeah
[10:35] <ikey> yamlish
[10:35] <zyga-suse> wow, I even wrote a man page
[10:35] <zyga-suse> http://bazaar.launchpad.net/~zyga/dh-splitpackage/trunk/view/head:/dh_splitpackage.1
[10:35] <ikey> check you being all dedicated
[10:35] <ikey> lol
[10:35] <ikey> oh dude you legit *wrote* a manpage
[10:35] <zyga-suse> _yes_ that's what I meant
[10:35] <zyga-suse> hand made
[10:36] <zyga-suse> yes, I was trying to help
[10:36] <zyga-suse> (then got ranty responses and lost interest)
[10:36] <ikey> use ronn
[10:36] <ikey> convert markdown to manpage :]
[10:36] <zyga-suse> nice! I was using rst2man later on
[10:36] <zyga-suse> but markdown is nicer
[10:36] <ikey> so i can do like https://github.com/solus-project/ypkg/blob/master/man/package.yml.5.md and have it generate to https://github.com/solus-project/ypkg/blob/master/man/package.yml.5
[10:37] <ikey> ah rst2man is pretty sweet yea
[10:37] <zyga-suse> heh
[10:37] <zyga-suse> reading my own man page I still think dh_splitpackage is a few times better than anything else currently in debian
[10:37] <zyga-suse> well
[10:37] <zyga-suse> thinking about what you said
[10:38] <zyga-suse> inclusion patterns could even be included from distro-wide global
[10:38] <ikey> yeah
[10:38] <zyga-suse> so there would be less repetition
[10:38] <zyga-suse> well :)
[10:38] <ikey> so you set distro policy from the outset
[10:38] <zyga-suse> I like how snaps don't have that problem
[10:38] <zyga-suse> yep
[10:38] <ikey> but the key is to allow extending the pattern
[10:38] <zyga-suse> snaps are not perfect
[10:38] <zyga-suse> but at least we let people make and ship apps without reading holy books of packaging
[10:38] <ikey> so you can see the default solus patterning here: https://github.com/solus-project/ypkg/blob/master/ypkg2/packages.py#L141
[10:39] <ikey> and in almost all cases it does the right thing ™
[10:39] <zyga-suse> nice
[10:39] <zyga-suse> yep
[10:39] <ikey> until cmake is a dick and decides to use /usr/lib
[10:39] <ikey> for both 32-bit and 64-bit
[10:39] <zyga-suse> well
[10:39] <ikey> thats cmake for ya.
[10:39] <ikey> lol
[10:39] <zyga-suse> linux distros are a dick
[10:39] <zyga-suse> we love to diverge
[10:39] <ikey> true
[10:39] <ikey> well tbf you all went down the multiarch route :P
[10:39] <ikey> i wanted pure 64bit
[10:39] <ikey> but nope, steam, skype, wine ....
[10:39] <zyga-suse> multiarch is great for arm cross compiling (and not just arm)
[10:40] <zyga-suse> though TBH fat binaries would have been better
[10:40] <ikey> yeah
[10:40] <zyga-suse> well :)
[10:40] <ikey> well, i got the whole "gah why you no use multiarch" thing a while back
[10:40] <zyga-suse> it's good to find others that share one's view
[10:40] <ikey> and its like, well, solus is only 64-bit native
[10:40] <ikey> so it makes not much sense :p
[10:40] <zyga-suse> I think multiarch is more than that
[10:40] <ikey> so instead we explicitly have lib64 and lib32
[10:40] <zyga-suse> 32/64 biarch is easier
[10:40] <ikey> and we split packages based on that
[10:40] <zyga-suse> multiarch is is a nice general concept
[10:40] <ikey> i.e. automatic -32bit -32bit-dbginfo -32bit-devel
[10:41] <zyga-suse> though again, fat binaries are just better still
[10:41] <zyga-suse> because it doesn't have this problem of where-is-$foo
[10:41] <ikey> dont think we'll ever "win" all the time we focus on vanilla ELF
[10:41] <zyga-suse> and even executables are >1 arch
[10:41] <zyga-suse> heh
[10:41] <zyga-suse> yes but note one thing:
[10:41] <zyga-suse> in "linux" we often "specify" things in a text file standing on plain apache somewhere
[10:41] <zyga-suse> and now it's the holly spec
[10:42] <ikey> we also need to lose this fixation on mutux provider names in the filesystem
[10:42] <ikey> "i am /usr/lib/someLIB"
[10:42]  * ikey shoots nvidia
[10:42] <zyga-suse> so elf spec could be extended arbitrarily if people agree
[10:42] <ikey> yeah
[10:42] <zyga-suse> ok, less rantin
[10:42] <ikey> lol
[10:42] <zyga-suse> I need to debug this test failure :)
[10:42] <ikey> yeah i should likely sort out apparmor in our 4.12
[10:42] <zyga-suse> and move on to update arch packaging for the release
[10:42] <zyga-suse> (no-more-patches, woot :)
[10:42] <ikey> noice
[10:43] <zyga-suse> 4.13 is better
[10:43] <ikey> 4.13 is also unstable
[10:43] <zyga-suse> ubuntu still has many patches that are not upstream and 4.13 will have them
[10:43] <zyga-suse> *hopefully all*
[10:43] <ikey> we offer "-lts" and "-current" in solus
[10:43] <zyga-suse> if you want to enable this LSM you want to take the few that didn't make it in 4.12
[10:43] <ikey> -lts = gkh's branch
[10:43] <zyga-suse> aha
[10:43] <zyga-suse> -lts-apparmor would be nice :)
[10:43] <ikey> and -current = mostly-stableish
[10:43] <zyga-suse> for snapd at least, that would give you full confinement
[10:43] <ikey> i.e. not rc and not mainline
[10:43] <zyga-suse> those are just in security/apparmor
[10:44] <ikey> well im gonna backport the apparmor stuff ofr our linux-current
[10:44] <zyga-suse> and you could perhaps even cherry pick those that land upstream
[10:44] <ikey> because having lsm specific kernels would seem silly
[10:44] <zyga-suse> aha, sounds good
[10:44] <zyga-suse> I can point you to the tree that has those
[10:44] <ikey> would love em
[10:44] <zyga-suse> jjohansen1: ^
[10:44] <ikey> i know 4.12 will be significantly easier to do than the 4.9
[10:44] <zyga-suse> ikey, jjohansen1 is working on upstreaming all of the apparmor changes
[10:44] <ikey> v nice
[10:44] <zyga-suse> yes :)
[10:45] <ikey> and ideally i want like-for-like confinement between solus and ubuntu
[10:45] <zyga-suse> ikey: since they are so self contained it should be easy to get a version for nearly any kernel that's not 3.x I heard
[10:45] <ikey> so people get the "full" snap experience
[10:45] <zyga-suse> *yes*
[10:45] <ikey> not "hm but my distro said no"
[10:45] <zyga-suse> thank you for caring about that!
[10:45] <ikey> eh its for the users - dont wanna screw em over
[10:46] <zyga-suse> snapd can tell you what it thinks about confinement via "snap debug"
[10:46] <zyga-suse> (I forgot the sub-command)
[10:46] <zyga-suse> but this is in 2.27 only
[10:46] <zyga-suse> so wait for the tarball for that :)
[10:46] <ikey> lolk
[10:46] <zyga-suse> it looks at the kernel securityfs and checks if all the features are on
[10:46] <ikey> ah
[10:46] <ikey> ok thats handy
[10:47] <zyga-suse> ok, I'll get back to bugfixing
[10:47] <zyga-suse> please ping me if you find something odd to investigate
[10:48] <zyga-suse> one thing that *is* going to suck initially is opengl support
[10:48] <zyga-suse> that's a few months away from being sane
[10:48] <zyga-suse> current approach is a stop-gap
[10:48] <ikey> yeah
[10:48] <zyga-suse> (for ! FOSS drivers)
[10:48] <ikey> i might use the nvidia-arch option and see if that works
[10:48] <zyga-suse> intel should be ok though it could be better supported in snapd as well
[10:48] <ikey> its *similar* to ours (but we symlinks it)
[10:49] <zyga-suse> I'd rather not, it's a gross hack
[10:49] <zyga-suse> mixes userspace with snaps
[10:49] <ikey> /usr/lib64/libGL.so.1: symbolic link to /usr/lib64/glx-provider/nvidia/libGL.so.384.59
[10:49] <zyga-suse> some of the common extension snap work will allow us to do this
[10:49] <ikey> bit messy and in time i think ill replace that with ld.so.conf trickery
[10:49] <zyga-suse> (e.g. theme snaps will lead the way)
[10:49] <ikey> yeah theme snaps..
[10:49] <ikey> people dislike lack of integration :p
[10:49] <zyga-suse> those are 1st priority for this cycle
[10:50] <zyga-suse> portal support, themes and a few other integration improvements
[10:50] <ikey> (especially now flatpak has them :P)
[10:50] <zyga-suse> yep :)
[10:50] <zyga-suse> that too :D
[10:50] <zyga-suse> I think our approach will be similar actually
[10:50]  * zyga-suse would love to have alexander here to talk details
[10:51] <ikey> heh
[10:51] <ikey> right well i need to go make myself look half human for the rest of the day
[10:51] <ikey> bbiab
[11:02] <mup> PR snapd#3707 closed: interfaces: convert io_ports_control to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3707>
[11:11] <mup> PR snapd#3708 opened: interfaces: convert two hardware_random interfaces to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3708>
[11:18] <ikey> zyga-suse, got a strace for running duckmarines: https://hastebin.com/akeviquqoc.erl if you wanna check later
[11:19] <zyga-suse> aha
[11:19] <zyga-suse> interesting
[11:19] <zyga-suse> so this is socket using AF_NETLINK
[11:19] <zyga-suse> we have netling mediation in the tree now
[11:19]  * zyga-suse looks
[11:20] <zyga-suse> this would be under netlink-observe I think
[11:20] <zyga-suse> ok two more things
[11:20] <zyga-suse> what does "snap version" say?
[11:20] <ikey> snap    2.26.14+git1302.gd1e575152.dirty
[11:20] <ikey> snapd   2.26.14+git1302.gd1e575152.dirty
[11:20] <zyga-suse> and did you install this snap before you got other parts in place, perhaps the security profiles are out of date
[11:20] <zyga-suse> hmm hmm
[11:20] <zyga-suse> can you look at /var/lib/snapd/seccomp/
[11:20] <ikey> only has bpf
[11:21] <zyga-suse> and look for the human-readable profile for this app (seccomp profiles are per-app)
[11:21] <zyga-suse> and if you can pastebin the plain text one
[11:21] <zyga-suse> (those are compiled with snap-seccomp btw)
[11:21] <ikey> https://hastebin.com/aqizajecat.pl
[11:23] <ikey> soo
[11:23] <ikey> looks like AF_NETLINK is needed and not whitelisted
[11:23] <ikey> or am i reading this wrong..
[11:25] <zyga-suse> socket AF_NETLINK - NETLINK_ROUTE
[11:25] <zyga-suse> aah
[11:25] <zyga-suse> it wants a different type
[11:26] <zyga-suse> curious
[11:26] <ikey> yeah mines off chasing NETLINK_KOBJECT_UEVENT
[11:26] <zyga-suse> yes
[11:26] <zyga-suse> one sec
[11:27] <zyga-suse> can you check which interfaces are conneccted?
[11:27] <zyga-suse> this one should be granted by pulseaudio interface
[11:27] <ikey> https://hastebin.com/cuqawagitu.rb
[11:28] <zyga-suse> oookay
[11:28] <zyga-suse> let me look
[11:28] <zyga-suse> very curious
[11:28] <zyga-suse> ah, my bad
[11:28] <zyga-suse> pulseaudio doesn't grant that for plugs
[11:28] <zyga-suse> so .. still a mystery
[11:28] <ikey> lol
[11:29]  * sergiusens wonders when we will start seeing zyga-solus
[11:29] <ikey> post-solus-release :p
[11:30] <zyga-suse> yes, likely
[11:30] <zyga-suse> nothing like hands-on
[11:30] <Son_Goku> morning all
[11:31] <zyga-suse> ikey: which revision of that snap are you on?
[11:31] <zyga-suse> I'm on 9
[11:31] <ikey> also 9
[11:31] <zyga-suse> ok, so I need to boot ubuntu to check
[11:31] <ikey> on ubuntu isn apparmor going to mediate the remaining network calls?
[11:31] <zyga-suse> but my working theory is that you kit a seccomp kill because the app is normally not even going to try something after getting an apparmor denial
[11:31] <zyga-suse> right
[11:32] <zyga-suse> this will fix itself when seccomp can return errors as well
[11:32] <ikey> heh
[11:32] <zyga-suse> this work is AFAIK done upstream now)
[11:32] <zyga-suse> or when you will get apparmor
[11:32] <zyga-suse> not sure if I'm right though
[11:32] <zyga-suse> ikey: one suggestion
[11:32] <zyga-suse> can you refresh that snap with --devmode
[11:32] <ikey> sure
[11:32] <zyga-suse> this will put seccomp into no-op mode
[11:32] <zyga-suse> and it _should_ at least show that it works
[11:32]  * zyga-suse looks at his profiles on suse
[11:33] <zyga-suse> ah, still on 2.25 here so no good comparison
[11:33] <ikey> ok so its definitely trying to start
[11:33] <ikey> libGL error: No matching fbConfigs or visuals found
[11:33] <ikey> libGL error: failed to load driver: swrast
[11:33] <ikey> this is fine
[11:33] <ikey> it cant find my nvidia
[11:33]  * ikey expected as much
[11:33] <ikey> but its gotten along a lot further
[11:33] <zyga-suse> the lethal seccomp is a workaround for lack of a kernel feature where we log stuff _and_ we don't kill
[11:34] <zyga-suse> did you enable any of the nvidia hacks/workarounds?
[11:34] <zyga-suse> (in snap-confine)
[11:34] <ikey> nah ill try the arch nvidia one and see if that works at all
[11:34] <zyga-suse> ok
[11:34] <zyga-suse> not sure if it will but let's see
[11:34] <zyga-suse> sorry about that, nvidia support is really hit-and-miss
[11:34] <ikey> yeah im used to that dw
[11:36] <zyga-suse> I would love to know how that works on an intel box
[11:36] <zyga-suse> mvo: does this make any sense to you? https://travis-ci.org/snapcore/snapd/builds/262982604?utm_source=github_status&utm_medium=notification
[11:37]  * zyga-suse notices ogra's huge gadget PR
[11:37] <ogra_> zyga-suse, same as the pi one just adjusted confiigs for pi2
[11:37] <zyga-suse> ikey: if you are familiar with the nvidia driver I could use some input
[11:37] <zyga-suse> yep
[11:37] <ogra_> *same as the pi3
[11:37] <ikey> cannot mount tmpfs at /tmp/snap.rootfs_JHOwxl/var/lib/snapd/lib/gl: No such file or directory
[11:37] <zyga-suse> ikey: on how I want to make that work in snaps
[11:37]  * ikey blows a rasberry at confinement
[11:38] <zyga-suse> you need an empty directory there
[11:38] <ogra_> :)
[11:38] <zyga-suse> in /var/lib/snapd/lib/gl
[11:38] <ikey> oh dude
[11:38] <ikey> game works
[11:38] <ikey> i mean the music is banging too
[11:38] <zyga-suse> wooooot
[11:38] <zyga-suse>  :D
[11:38] <zyga-suse> hahaha
[11:38] <zyga-suse> that's so great
[11:39] <zyga-suse> pics or it didn't happen :D
[11:39] <zyga-suse> better yet
[11:39] <zyga-suse> tweet a pic
[11:39]  * ikey doesn't control the solus twitter anymore :p
[11:39] <ikey> https://ibin.co/3WOU2Mq91dSg.png
[11:39] <zyga-suse> wat?
[11:39] <zyga-suse> who does?
[11:39] <ikey> josh does
[11:40] <ikey> he does social thingies
[11:40] <ikey> i control the G+
[11:40] <zyga-suse> ohhh, I'd love to see those bash prompts for git integration
[11:40] <ikey> and most tweets are reposts of that
[11:40] <ogra_> post it there then !
[11:40] <ikey> lol
[11:40] <ikey> s/bash/zsh/
[11:40] <ikey> :p
[11:40] <zyga-suse> (things you learn from random images :D
[11:40] <zyga-suse> aha
[11:40] <zyga-suse> you may be interested in *very* cool tab completion
[11:40] <ikey> fwiw classic snap last night: https://plus.google.com/+Solus-Project/posts/BN5p1arv3Fs
[11:40] <zyga-suse> snapd can do tab completion for snaps inside their confinement
[11:41] <zyga-suse> and we probably miss something for zsh intergration
[11:41] <zyga-suse> Chipaca can tell you all about this
[11:41] <ogra_> a lot i think
[11:41] <ikey> aye
[11:41] <zyga-suse> so you could tab-tab a command from a snap
[11:41] <zyga-suse> and the completer runs confined
[11:41] <ikey> nice
[11:42] <ikey> alright so it looks like the remaining "main ticket item" really now is to chuck apparmor into the kernel
[11:42] <ikey> and then see if that fixes !devmode
[11:42] <zyga-suse> yep
[11:42] <ikey> (gonna need it anyway)
[11:42] <zyga-suse> and please send your patches back
[11:43] <zyga-suse> I think we can do a 2.27.1 after we collect patches from distributions
[11:43] <ikey> yeah will do
[11:43] <zyga-suse> I may need one for opensuse apparently
[11:43] <zyga-suse> at least to fix this damn unit test
[11:43] <ikey> the patch is actually really basic right now
[11:43] <zyga-suse> I bet it is bleeding edge golang in tumbleweed
[11:43] <ikey> https://hastebin.com/jotepamoki.bash - but i dont wanna send it in yet due to the disabling of apparmor
[11:43] <zyga-suse> yeah, I hoped it would be easy but I just want them merged :)
[11:44] <ikey> and you might not like mkversion change :P
[11:44] <zyga-suse> super nice
[11:44] <zyga-suse> yep
[11:44] <zyga-suse> read it
[11:44] <zyga-suse> I think it's fine
[11:44] <ikey> ypkg sets $version as the package.yml key
[11:44] <zyga-suse> you can just call mkversion with an argument
[11:44] <ikey> and it means autogen then just works
[11:44] <zyga-suse> but no strong opinions
[11:44] <ikey> we use %autogen macro
[11:44] <ikey> which takes arguments too
[11:44] <ikey> so in autogen.sh i modified solus) to take $@
[11:45] <ikey> meaning that autogen.sh/mkversion.sh/configure all play nicely in a single chain
[11:45] <zyga-suse> ahh, I see
[11:45] <zyga-suse> cool :)
[11:45] <ikey> cheers for all the help so far, very much appreciated
[11:46] <zyga-suse> pleasure :)
[11:48]  * ogra_ sighs about the flashplugin update he gets ... 
[11:49] <ogra_> thats the only package i'd really love to see as classic snap one day :)
[11:56] <pstolowski> pedronis, hey, re your comment about having a "run-hook[refresh]" helper, are you suggesting a test-side only helper, or making "run-hook" tasks have different kinds?
[11:57] <pedronis> pstolowski: only in the tests
[11:57] <pstolowski> pedronis, ok good
[11:57] <pedronis> make the helper that lists kinds etc
[11:57] <pedronis> produce that
[11:57] <pstolowski> pedronis, because the latter would be problematic
[11:57] <pedronis> *helpers
[11:57] <pedronis> pstolowski: understood
[11:58] <pstolowski> thanks
[12:01] <mup> PR snapcraft#1474 opened: kbuild plugin: use ARCH from environment if set <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1474>
[12:02] <kalikiana> ondra: ^^
[12:04] <ondra> kalikiana do you have build of snapcraft with that change,so I can test it?
[12:06] <ondra> kalikiana not sure if this would work, as we are build on arm64 and kernel is arm64, but we need arch arm
[12:06] <Chipaca> i'm off to lunch
[12:06] <mvo> sergiusens: so "app-constrains" instead of "wrappers"? happy to change that
[12:09] <abeato> mvo, hey, is current core edge really built from master or is it a re-spin of 2.27?
[12:10] <mvo> abeato: today its 2.27 sorry for that, when a release is immanent edge is sometimes not really edge
[12:10] <mvo> abeato: I expect things to be normal by this evening
[12:10] <zyga-suse> edge is not what it seems to be on days like that
[12:10] <abeato> mvo, ack, nw
[12:10] <abeato> yeah, I suspected that... :)
[12:11] <mvo> cachio: hey, good morning! any last minute concerns aobut 2.27, otherwise I'm going to upload 2.27-final in a wee bit :)
[12:12] <sergiusens> mvo: well I am thinking, you didn't start a forum post to discuss this ;-)
[12:12] <ikey> zyga-suse, should i be setting DEFAULT_SECURITY_APPARMOR=y ?
[12:12] <ikey> right now its DEFAULT_SECURITY_DAC
[12:12] <mvo> sergiusens: doing that as we speak
[12:13] <sergiusens> mvo: for example, `no-environment` might be the better keyword, or when we kill our wrappers and just shove stuff in `env`, would that still be ok for your use case?
[12:13] <zyga-suse> ikey: mmmmm, I don't know, tyhicks or jdstrand can say
[12:13] <zyga-suse> (please help out)
[12:13] <mvo> sergiusens: absolutely, my use case is that I don't want #!/bin/sh (as my base snap does not have it ;)
[12:14] <zyga-suse> ikey: ^ mvo works on a test base snap that ships *nothing* :-) so apps execute in a very very empty place
[12:14] <ikey> ah cool
[12:14] <sergiusens> mvo: right, then `no-environment` might be the better fit as the wrapper is just an implementation detail
[12:15] <mvo> sergiusens: sure, works for me, I create a forum topic just to make sure that gustavo is aware and can weight in
[12:15] <sergiusens> mvo: would be nice to see `command`s of the style of the ones you see `snapcraft.yaml` allowed in `snap.yaml` and we are golden :-)
[12:15] <sergiusens> mvo: perfect
[12:15] <sergiusens> I'll add my comments
[12:16] <zyga-suse> sergiusens: what is the difference today?
[12:16] <zyga-suse> sergiusens: that they run via shell?
[12:17] <mvo> sergiusens: created and mentioned you
[12:18] <sergiusens> zyga-suse: in snapcraft you can do: `env PATH=$SNAP/bin my-command $SOME_VAR` in snap.yaml you cannot specify variables
[12:18] <zyga-suse> sergiusens: right
[12:18] <zyga-suse> sergiusens: but you can specify ... environment
[12:18] <sergiusens> and I know jdstrand explained the why's to me, but I just wish it were allowed
[12:19] <zyga-suse> what you said above needs to be handled by /bin/sh
[12:19] <zyga-suse> aha
[12:19] <sergiusens> zyga-suse: you can, but some commands require something like this: `command: my-command --work-dir $SNAP_USER_DATA`
[12:19] <zyga-suse> arguable we _could_ expand $SNAP_ variables
[12:19] <zyga-suse> arguably*
[12:20] <sergiusens> fwiw, the wrappers are mvo's invention ;-)
[12:20] <mvo> sergiusens: really?
[12:20]  * mvo can't remember
[12:20] <zyga-suse> whaat? :-D
[12:20] <zyga-suse> I won't say who complains about wrappers the most :D
[12:20] <mvo> lol
[12:20] <mvo> I always thought it was the other mike
[12:20]  * ikey & compiling linux-current...
[12:24] <sergiusens> mvo: ah mterry  in the middle of a bunch of your commits `git diff ac2a535d52a04d9ec848026d52c19d1471bbbe39^ ac2a535d52a04d9ec848026d52c19d1471bbbe39`
[12:24] <sergiusens> you made the sell for it on the Snappy Clinics though
[12:24] <mvo> sergiusens: heh, thats quite possible
[12:24] <mvo> sergiusens: the bad old days :)
[12:28] <sergiusens> zyga-suse: mvo the only reason we didn't move to `env` yet is due to the way environment was originally implemented, and that is mvo's invention ;-) We need env stacking to make it easy and dictionaries don't make that easy
[12:28] <zyga-suse> sergiusens: do you know about the merge-keys feature in yaml?
[12:28] <zyga-suse> (not sure if related but I was surprised today)
[12:28] <zyga-suse> http://yaml.org/type/merge.html
[12:29] <sergiusens> zyga-suse: yes
[12:29] <sergiusens> it makes the yaml look horrible, but some people like it ;-)
[12:29] <mvo> sergiusens: I'm still not so sure if it was my invention but my memory is sometimes flaky so I will not fight over it ;)
[12:39] <ikey> Does apparmor require CONFIG_AUDITSYSCALL ?
[12:39] <ikey> (and thus, snap)
[12:39]  * zyga-suse doesn't know
[12:40] <zyga-suse> again that would be something that jdstrand or jjohansen1 can answer
[12:40] <zyga-suse> ikey: I know this is not a good answer but you could cross-check with what the ubuntu config is
[12:40] <ikey> cuz CONFIG_AUDITSYSCALL is notoriously slow
[12:41]  * zyga-suse is melting here
[12:41] <ikey> anyone able to zgrep CONFIG_AUDITSYSCALL /proc/config.gz..?
[12:41] <ikey> (on buntu)
[12:42]  * zyga-suse boots
[12:42] <zyga-suse> one sec
[12:42] <ikey> ta
[12:42] <ikey> i know consolekit used to require it - but like nobody uses that now
[12:43] <zyga-ubuntu> ikey: zyga@fyke:~$ cat /boot/config-4.10.0-30-generic  | pastebinit
[12:43] <zyga-ubuntu> http://paste.ubuntu.com/25283420/
[12:43] <mup> PR snapcraft#1473 closed: catkin plugin: rosinstall-files is a pull property <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1473>
[12:43] <ikey> ouch you have it on
[12:48] <mup> PR snapd#3708 closed: interfaces: convert two hardware_random interfaces to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3708>
[12:48] <zyga-suse> pedronis: around?
[12:49] <pedronis> zyga-suse: yes
[12:49] <zyga-suse> https://paste.gnome.org/pqyailbdz
[12:49] <zyga-suse> I changed the prune function to log why things happen
[12:49] <zyga-suse> it seems change 1 should *not* be pruned
[12:49] <zyga-suse> (according to the test)
[12:50] <zyga-suse> my mind has melted today so I'm not sure if this is just still racy
[12:50] <zyga-suse> or is something else at play
[12:51] <zyga-suse> or maybe some scheduling or golang parts are different here
[12:51] <pedronis> sorry, I cannot really context switch to this atm
[12:51] <zyga-suse> OK
[12:51]  * zyga-suse keeps digging
[12:53] <ikey> there we go, officially snowing in hell
[12:53] <ikey> https://dev.solus-project.com/R3571:19e256059de04cae4f98d22f71ec0eb36ac02e13
[12:53] <zyga-ubuntu> zyga@fyke:~$ cat /boot/config-4.10.0-30-generic  | pastebinit
[12:53] <zyga-ubuntu> http://paste.ubuntu.com/25283420/
[12:53] <zyga-ubuntu> er, sorry
[12:54] <zyga-ubuntu> wooot :)
[12:54] <ikey> xD
[12:54] <zyga-ubuntu> may I tweet about this :)
[12:54] <zyga-ubuntu> or would you rather
[12:54] <ikey> nah go ahead
[12:54] <kalikiana> ondra: You don't need to build it, you can run it from source. Although I could make you a snap if you rather wait for it to build... I tested with this https://github.com/kubiko/dragonboard-gadget/pull/1
[12:54] <mup> PR kubiko/dragonboard-gadget#1: Use upstream kbuild plugin <Created by kalikiana> <https://github.com/kubiko/dragonboard-gadget/pull/1>
[12:54] <ikey> can link direct to the commit too as it shows the canonical.com patchwork
[12:54] <ikey> yknow, brownie points n all
[12:56] <ikey> i have a suspicion this audit change will fix some old bugs and expose some new ones, but we'll see once i have the nv ko rebuilds in..
[12:56] <ondra> kalikiana now I'm even more curious how you determine to use arm
[12:57] <ondra> kalikiana and cross compiling also working?
[12:57] <zyga-ubuntu> ikey: this will be very interesting indeed, I wonder what results you'll get
[12:57] <kalikiana> ondra: I don't. See the PR description :-)
[12:58] <kalikiana> It works the same way as CROSS_COMPILE now
[12:58] <ondra> kalikiana I'm checking your changes to dragonboard, and this looks so clean, just wondering how it works that it knows to use arm ARCH
[12:58] <ondra> kalikiana have you  tested native build on arm64?
[12:58] <ondra> kalikiana so when you cross compile, do you tell if to cross compile for arm64?
[12:59] <kalikiana> ondra: "ARCH=arm snapcraft --target-arch=arm64" is what I tested
[12:59] <ondra> kalikiana aha :)
[12:59] <ogra_> crazy stuff
[13:00] <ondra> kalikiana OK that would probably fail then when build in launchpad
[13:00] <ondra> kalikiana as you can't really defined there env variable, unless I don't know about it
[13:00] <ogra_> why would you cross build in lp ?
[13:00] <ondra> ogra_ there you native build
[13:00] <ogra_> right
[13:00] <ondra> ogra_ but that means you gonna end up with arm64 ARCH
[13:01] <ondra> ogra_ which will fail
[13:01] <ogra_> anything wrong with that ?
[13:01] <ogra_> why ?
[13:01] <ondra> ogra_ you have so bad memory :D
[13:01] <ogra_> it is only uboot
[13:01] <kalikiana> ondra: So Launchpad is native? Or Cross-compiling?
[13:01] <kalikiana> I assumed native
[13:01] <ogra_> yeah, lp is native
[13:01] <ondra> ogra_ remember, uboot for dragonboard fails unless you use arm64 toolchain, but defined arm ARCH
[13:02] <ogra_> but i remember there was this odd mkimage thing
[13:02] <ondra> kalikiana LP is native
[13:03] <ondra> ogra_ I don't know is this is specific to dragonboard or to arm64
[13:03] <ondra> ogra_ but for dragonboard I had to use this crazy combo to make it build
[13:03] <ogra_> yeah, i remember now
[13:04] <ogra_> though i think the dragonboard still boots fine if you just use armhf ... iirc the prob was that you need to use this mkimage call
[13:05] <kalikiana> ogra_: it actually won't build because there's no config in arch for it
[13:05] <ondra> ogra_ but it won't compile
[13:05] <kalikiana> Although I wonder, can that be fixed?
[13:05] <ondra> ogra_ only way to build is arm64 toolchain  + arm ARCH
[13:06] <ondra> and building arm64 architecture on  armhf seems even more broken, let alone it won't build anyway
[13:06]  * ikey makes a one-of-them-g+ posts
[13:26] <zyga-ubuntu> ikey: :-)
[13:31] <zyga-ubuntu> ikey: note that you may still be missing some more specific apparmor patches but I'll wait for a reply from jjohansen1 which is doing this work
[13:31] <zyga-ubuntu> ikey: I'm sure he can look at your config and tree and say if anything is missing
[13:31] <ikey> sure
[13:31] <ikey> ive taken them from your kernel.ubuntu.com backports tree
[13:31] <zyga-ubuntu> aha, that's good then
[13:32] <zyga-ubuntu> I *think* all of them are in the xenial tree but xenial uses older kernel and I'm not a real kernel dev
[13:32] <zyga-ubuntu> so not sure :)
[13:32] <ikey> ack
[13:52] <mvo> zyga-suse, zyga-ubuntu, zyga-*: if you type "mount|grep disk" what do you se?
[13:52] <jdstrand> roadmr: hey, can you sync r896 just whenever
[13:53] <roadmr> jdstrand: totally
[13:54] <jdstrand> roadmr: thanks :)
[13:56] <zyga-ubuntu> mvo: checking
[13:56] <zyga-ubuntu> mvo: note that I suspect I mounted them by clicking on them
[13:56] <zyga-ubuntu> mvo: oh wow
[13:56] <zyga-ubuntu> this is interesting
[13:56] <zyga-ubuntu> zyga@fyke:~/snapd$ mount | grep disk
[13:56] <zyga-ubuntu> /var/lib/snapd/snaps/core_2445.snap (deleted) on /media/zyga/disk type squashfs (ro,nosuid,nodev,relatime,uhelper=udisks2)
[13:56] <zyga-ubuntu> /var/lib/snapd/snaps/core_2462.snap (deleted) on /media/zyga/disk1 type squashfs (ro,nosuid,nodev,relatime,uhelper=udisks2)
[13:56] <zyga-ubuntu> check this out
[13:57] <mvo> zyga-ubuntu: aha! and snap list --all ? does it show those?
[13:57] <zyga-ubuntu> core                            16-2.27            2610  canonical       core
[13:57] <zyga-ubuntu> core                            16-2.27            2604  canonical       core,disabled
[13:57] <zyga-ubuntu> core                            16-2.27            2601  canonical       core,disabled
[13:57] <zyga-ubuntu> Chipaca: btw, snap list --all chokes on broken snaps to the point where it doesn't show *any* snaps
[13:58] <zyga-ubuntu> mvo: as I said, I was hopping channels
[13:58] <Chipaca> zyga-ubuntu: what sort of broken snap?
[13:59] <zyga-ubuntu> Chipaca: I had a few snaps I 'snap try'ied
[13:59] <mvo> zyga-ubuntu: interessting
[13:59] <zyga-ubuntu> Chipaca: to check specific encyptfs behavior
[13:59] <mvo> zyga-ubuntu: so these are really not on disk anymore?
[13:59] <zyga-ubuntu> (those snaps were on a fs my user cannot access)
[13:59] <zyga-ubuntu> mvo: yes
[13:59] <mvo> zyga-ubuntu: context is core not try :)
[14:00] <zyga-ubuntu> mm?
[14:00] <zyga-ubuntu> mvo, Chipaca: those broken snaps were there for months
[14:00] <zyga-ubuntu> and I never noticed any problem
[14:00] <zyga-ubuntu> because I wasn't runnin list --all
[14:00] <Chipaca> zyga-ubuntu: sudo curl -N -0 -s --unix-socket /run/snapd.socket http:/v2/snaps | pastebinit
[14:01] <zyga-ubuntu> Chipaca: I had to remove them so this will now work
[14:01] <zyga-ubuntu> zyga@fyke:~/snapd$ snap list --all
[14:01] <zyga-ubuntu> error: cannot list snaps: cannot list local snaps! cannot find installed snap "test-snapd-overmount" at revision x1
[14:01] <zyga-ubuntu> your command is still doing stuff
[14:01] <zyga-ubuntu> timed out
[14:02] <zyga-ubuntu> Chipaca: I got:
[14:02] <zyga-ubuntu> Błąd połączenia z serwerem: [Errno socket error] The read operation timed out
[14:02] <zyga-ubuntu> ran again and got
[14:02] <zyga-ubuntu> http://paste.ubuntu.com/25283709/
[14:02] <Chipaca> zyga-ubuntu: ok, get me snapd logs then
[14:02] <zyga-ubuntu> aaah
[14:02] <zyga-ubuntu> sie 10 14:43:40 fyke systemd[1]: snapd.service: Service hold-off time over, scheduling restart.
[14:02] <zyga-ubuntu> mvo: ^ remember this
[14:03] <zyga-ubuntu> sie 10 14:43:40 fyke systemd[1]: Stopped Snappy daemon.
[14:03] <zyga-ubuntu> sie 10 14:43:40 fyke systemd[1]: Started Snappy daemon.
[14:03] <mup> PR snapd#3709 opened: release: snapd 2.27 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3709>
[14:03] <zyga-ubuntu> we had this before
[14:03] <zyga-ubuntu> the sd-notify bug
[14:03] <zyga-ubuntu> right?
[14:03] <Chipaca> i sometimes agree with those logs: *fyke* systemd
[14:03] <zyga-ubuntu> snapd restarts periodically
[14:03] <mvo> zyga-ubuntu: yes, we had this before - where do you see it?
[14:04] <zyga-ubuntu> on fyke, apparently, on my dev system running
[14:04] <Chipaca> zyga-ubuntu: what did you have before that? a traceback or anything?
[14:04] <zyga-ubuntu> snap    2.27~rc9
[14:04] <zyga-ubuntu> snapd   2.27~rc9
[14:04] <zyga-ubuntu> Chipaca: nope
[14:04] <zyga-ubuntu> Chipaca: let me get you the full log
[14:04] <mvo> zyga-ubuntu: what version of snapd do you have installed as the deb?
[14:04] <zyga-ubuntu> http://paste.ubuntu.com/25283724/
[14:04] <zyga-ubuntu> 2.25
[14:05] <mvo> zyga-ubuntu: so this can happen if you have a snapd deb with "type=notify" in the deb but re-exec runs a version that does not support type=notify. but your case is the other way aroudn afact
[14:05] <Chipaca> out of curiosity, what's doing all those individual GETs?
[14:06] <zyga-ubuntu> mvo: I don't have Type=notify in snapd.service
[14:06] <zyga-ubuntu> Chipaca: not me
[14:07] <Chipaca> zyga-ubuntu: i suspect gnome-software
[14:07] <Chipaca> zyga-ubuntu: because of the icons
[14:07] <zyga-ubuntu> maybe
[14:08] <mvo> zyga-ubuntu: how often do you see this message?
[14:08] <zyga-ubuntu> mvo: according to the log I pasted, just a few times now
[14:08] <zyga-ubuntu> but I did hit the window a moment ago
[14:08] <zyga-ubuntu> when I was doing the queries for chipaca
[14:08] <zyga-ubuntu> maybe snapd panicked
[14:08] <zyga-ubuntu> while I had those broken snaps installed
[14:08] <zyga-ubuntu> and I ran list --all
[14:08] <Chipaca> zyga-ubuntu: you'd see the panic in the logs
[14:09] <ikey>  ✓  ufee1dead@ironhide  ~  dmesg|grep -i armor
[14:09] <ikey> [    0.026751] AppArmor: AppArmor initialized
[14:09] <ikey> heh
[14:09] <zyga-ubuntu> ikey: nice :D
[14:11] <zyga-ubuntu> mvo: out of curiosity, jump between beta and candidate
[14:11] <zyga-ubuntu> do it a few times and see what happens
[14:12] <mvo> zyga-ubuntu: will do in a bit, just in the middle of releasing 2.27 :)
[14:12]  * ogra_ does that multipple times a day ... but only on ubuntu core
[14:12] <ogra_> -p
[14:15]  * zyga-ubuntu thinks about lunch
[14:15] <pstolowski> zyga-ubuntu, thinking about it rarely helps ;)
[14:20]  * zyga-ubuntu eats stuff :D
[14:22] <ondra> kalikiana was thinking, without over complicating kbuild plugin, best thing would be if one can define env variable for each part build
[14:22] <ondra> kalikiana this could be quite handy feature and it'd probably solve lot of additional hacking
[14:23] <ondra> kalikiana and we could do it way, that whenever we are passing env variables, like for cross compiling, we could preference those defined in snapcract.yaml
[14:32]  * zyga-ubuntu suspends this laptop to work on one less computer at a time
[14:38] <zyga-suse> ikey: about your post earlier, I think having a common market and ease-of-deployment *is* a compelling reason for developers to target linux
[14:38] <zyga-suse> ikey: so indirectly, initiatives like snaps help to achieve that
[14:52] <ikey> having a shop is all well good provided you put the shop on a busy street and sell things people want
[15:00] <ikey> zyga-suse,
[15:00] <ikey> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[15:00] <ikey> (built it with libapparmor)
[15:01] <zyga-suse> aaah
[15:01] <zyga-suse> yeah
[15:01] <zyga-suse> ok, so now you need to install the apparmor profile for snap-confine
[15:01] <zyga-suse> it should have been built
[15:01] <zyga-suse> snap-confine.apparmor
[15:01] <ikey> ah ok
[15:01] <ikey> where does he go
[15:01] <zyga-suse> on debian this goes to /etc/apparmor.d/
[15:02] <ikey> ew.
[15:02] <ikey> so much ew.
[15:02] <zyga-suse> as usr.lib.snapd.snap-confine
[15:02] <ikey> thats blatant misuse of /etc
[15:02] <ikey> :P
[15:02] <zyga-suse> just encode the path in the name
[15:02] <ikey> yknow im going to send you patches to fix apparmor right?
[15:02] <ikey> lol
[15:02] <zyga-suse> well, in theory because this is something you can edit
[15:02] <ikey> Solus is on a mission to ban use of /etc/
[15:02] <ikey> yeah ive heard that theory a lot..
[15:02] <ikey> lol
[15:02] <zyga-suse> ikey: yes, I saw that, that *is* a good thing
[15:02] <ikey> ill figure out bzr during next week i think
[15:02] <zyga-suse> I don't know if apparmor supports stuff like /lib/apparmor.d
[15:02] <ikey> and work out the stateless approach
[15:02] <ikey> for now ill use /etc/ and cry later
[15:03] <zyga-suse> for that I bet you want to work on jdstrand and other apparmor upstreams
[15:03] <ikey> /etc/apparmor.d/usr.lib64.snapd.snap-confine
[15:03] <ikey> its there..
[15:03] <zyga-suse> yep
[15:03] <mvo> zyga-suse: meh, looks like opensuse in the tests is fragile, e.g. timeout errors
[15:03] <mvo> zyga-suse: on the download servers
[15:03] <zyga-suse> make sure the stuff inside matches the path
[15:03] <ikey> soo i guess the next question is how do i make it go
[15:03] <ikey> xD
[15:04] <zyga-suse> ikey: the first few lines show which file is being confined
[15:04] <zyga-suse> ikey: apparmor_parser -r /path/to/that/file
[15:04] <zyga-suse> that will load it
[15:04] <zyga-suse> and you can try running now
[15:04]  * ikey fixes up apparmor pkg
[15:04] <ikey> im guessing there is a systemd unit to load this cruft on boot
[15:04] <zyga-suse> mvo: download servers?
[15:04] <zyga-suse> ikey: yes, not a systemd unit buy old style script
[15:04] <zyga-suse> it's a part of userspace apparmor tools
[15:04] <zyga-suse> (it's convoluted)
[15:04] <ikey> o
[15:05] <ikey> [Package] Including empty directory: /var/lib/apparmor
[15:05]  * ikey sobs into a bucket
[15:05] <ogra_> "old style" ... tsk ...
[15:05] <mvo> zyga-suse: yeah, I retrigger and see what happens, I got a timeout from zyper in project prepare for opensuse
[15:05] <zyga-suse> oh
[15:05] <zyga-suse> interesting
[15:05] <zyga-suse> maybe our base image is very old
[15:06] <zyga-suse> and we get lots of updates
[15:06] <ikey> Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
[15:06] <ikey> Use --subdomainfs to override.
[15:06] <ikey> wut
[15:06] <zyga-suse> did you mount apparmorfs?
[15:06] <ikey> idk how it works lol
[15:06] <zyga-suse> in /sys/kernel/security/apparmor
[15:06] <ikey> should i assume i now need to build systemd with apparmor?
[15:06] <zyga-suse> ikey: I'd have a look at apparmor packaging in debian and in opensuse
[15:07] <zyga-suse> ikey: no, it's not mandatory
[15:10] <ikey> huh ok /sys/kernel/security/apparmor does exist
[15:10] <zyga-suse> mmm, maybe something else is missing, I'm sorry I don't know that error
[15:11] <zyga-suse> on tumbleweed I see securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
[15:11] <ogra_> pedronis, did you want to drop the timestamp checking of the system-user assertion or do i mis-remember that ? (regarding bug 1679739)
[15:11] <mup> Bug #1679739: System-User Assertions and the system time <Snappy:New> <https://launchpad.net/bugs/1679739>
[15:12] <mup> PR snapd#3710 opened: many: allow and support serials signed by the 'generic' authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3710>
[15:13] <ikey> securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
[15:13] <ikey> tmpfs /dev/shm tmpfs rw 0 0
[15:13] <ikey> er random 2line paste
[15:13] <ikey> but yeah, its definitely mounted
[15:14] <ikey> the failed call is 	    aa_kernel_interface_new(&kernel_interface, features, apparmorfs) == -1) {
[15:15] <tyhicks> ikey: can you strace apparmor_parser and see if there's a failing syscall inside of aa_kernel_interface_new()?
[15:15] <ikey> yea poking that now
[15:15] <zyga-suse> tyhicks: hey :)
[15:16] <tyhicks> hey zyga-suse :)
[15:16] <ikey> open("/etc/apparmor.d/usr.lib64.snapd.snap-confine", O_RDONLY|O_DIRECTORY|O_CLOEXEC) = -1 ENOTDIR (Not a directory)
[15:17] <tyhicks> that's not likely the issue
[15:17] <tyhicks> can you paste the entire strace somewhere so I can look?
[15:17] <ikey> https://hastebin.com/fimogokola.erl
[15:18] <tyhicks> thanks
[15:18] <tyhicks> what's the full apparmor_parser command that you're using?
[15:18] <ikey> the one zyga-suse gave me: sudo /sbin/apparmor_parser -f /etc/apparmor.d
[15:18] <ikey> er
[15:18] <ikey> with the filename*
[15:19] <ikey> sudo /sbin/apparmor_parser -f /etc/apparmor.d/usr.lib64.snapd.snap-confine
[15:19] <ikey> is -f wrong by any chance?
[15:19] <tyhicks> yes
[15:19] <tyhicks> -f is wrong
[15:19] <ikey> xD
[15:19] <tyhicks> so the failing open() was the issue :)
[15:19] <ikey> lol yeah
[15:19] <ikey> so -a or -r ?
[15:19] <tyhicks> I think you want -r instead of -f
[15:19] <ikey> ta
[15:20] <ikey> Could not open 'tunables/global'
[15:20] <ikey> pfft
[15:20]  * ikey adds profiles to pkg
[15:21] <ikey> /usr/lib64/snapd/snap-confine: error while loading shared libraries: libudev.so.1: failed to map segment from shared object
[15:21] <ikey> xD
[15:21]  * ikey goes to look at the confine file
[15:21] <zyga-suse> ikey: aha
[15:22] <zyga-suse> ikey: you may want to update paths in that file
[15:22] <ikey> its all multiarched up
[15:22] <zyga-suse> yep
[15:22] <zyga-suse> sorry
[15:22] <zyga-suse> but thank you for leading the way
[15:22] <ikey> heh
[15:22] <zyga-suse> I'll gladly take patches to imporve this
[15:23] <ikey> so we have @{multiarch}
[15:23] <ikey> is there anything like $LIB from ld?
[15:23] <ikey> fwiw this kinda demonstrates the sandboxing is working
[15:23] <ikey> lol
[15:23] <zyga-suse> some things are variables expanded by apparmor
[15:23] <zyga-suse> indeed :)
[15:23] <zyga-suse> but I don't know, I rarely look at the global includes
[15:23] <ikey> ok
[15:25] <ikey> @{multiarch}=*-linux-gnu*
[15:25] <nothal> ikey: No such command!
[15:25] <ikey> hrm ok
[15:25] <ikey> ..lol
[15:25] <ikey> gold
[15:33] <ikey> cannot create symbolic link /tmp/snap.rootfs_BPPk5I/var/lib/snapd/lib/gl/libEGL.so -> /var/lib/snapd/hostfs/usr/lib64/libEGL.so.1: Permission denied
[15:35] <zyga-suse> oh
[15:35] <zyga-suse> that's nvidia arch support
[15:35] <zyga-suse> since it was never tested under confinement you need to allow that symlink
[15:36] <ikey> ok how do i do that
[15:36] <ikey> lol
[15:37] <ikey> "    /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/ w," mebbe?
[15:37] <zyga-suse> the synax is like
[15:38] <jaggz> - 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))
[15:38] <ikey> needed a * at the end..
[15:38] <ikey> ok now we make progress:
[15:38] <ikey> cannot change profile for the next exec call: No such file or directory
[15:38] <ikey> lol
[15:38] <jaggz> what's that about?  I'm trying to install a snap from a file
[15:38] <zyga-suse>  path/to/file w,
[15:38] <zyga-suse> tyhicks: ^ symlinks?
[15:38] <zyga-suse> tyhicks: do I rememeber this correctly?
[15:39] <zyga-suse> jaggz: that's something for Chipaca
[15:39] <Chipaca> me? :-)
[15:39] <zyga-suse> ikey: that is /proc/$PID/attr AFAIR
[15:39] <ikey> open("/proc/24260/attr/exec", O_WRONLY) = 3
[15:39] <ikey> write(3, "exec snap.duckmarines.duckmarine"..., 33) = -1 ENOENT (No such file or directory)
[15:39] <zyga-suse> ikey: this is how apparmor profile changes are applied
[15:39] <zyga-suse> right
[15:39] <Chipaca> jaggz: but i was just about to say: could you ls -l /var/snap/meshalb for me?
[15:39] <zyga-suse> aha
[15:39] <zyga-suse> maybe snap.duckmarines.duckmarine is not a generated profile
[15:39] <zyga-suse> probably because snapd didn't generate a profile
[15:39] <tyhicks> zyga-suse: sorry, what specifically about symlinks are you asking? I don't see it in the scrollback
[15:39] <ikey> hm
[15:40] <zyga-suse> and probably because you are missing a patch so it determined that apparmor support is incomplete
[15:40] <zyga-suse> (lots of probably)
[15:40] <ikey> right
[15:40] <ikey> snap debug confinement yields partial
[15:40] <zyga-suse> tyhicks: I forgot the syntax for symlinks in apparmor
[15:40] <zyga-suse> ikey: so something is missing
[15:40] <ikey> yeah
[15:40] <ikey> but i fixed the library issue and libGL write issue
[15:40] <zyga-suse> ikey: or not compiled in or misisng
[15:40] <tyhicks> zyga-suse: you have to give permission to the symlink target since that's what apparmor mediates on
[15:40] <mup> Issue snapcraft#1475 opened: rust plugin recording <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1475>
[15:41] <zyga-suse> we look at /sys/kernel/security/apparmor/features
[15:41] <ikey> this bit worked for the arch confinement:
[15:41] <ikey>     /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/* w,
[15:41] <zyga-suse> tyhicks: thank you
[15:41] <ikey> though in truth it should likely be more strict and catch .so* only
[15:41] <zyga-suse> ikey: this is fine, you need more patches to get snapd to flip from "partial" to "strict"
[15:41] <ikey> aye
[15:41] <ikey> so more kernel work
[15:42] <ikey> well we made great headway
[15:42] <ikey> to the point that snapd-confine itself is happy through apparmor
[15:42] <ikey> now it just needs to execute this damn duck marines
[15:42] <ikey> telling ya, it best be a good game after all this :p
[15:43] <Chipaca> ikey: http://i.imgur.com/eTic1wS.jpg
[15:43] <zyga-suse> :D
[15:44] <jaggz> Chipaca, http://paste.debian.net/980792/
[15:44] <ikey> Chipaca, lol
[15:45] <jaggz> that's /var/snap/meshlab
[15:45] <Chipaca> jaggz: sigh, ok that's strange. How and what were you trying to install, and what version is your snapd?
[15:46] <jaggz> Chipaca, Trying to install meshlab.  snapd debian package is 2.21.  Meshlab's snap I downloaded from https://uappexplorer.com/snap/ubuntu/meshlab
[15:46] <jaggz> I also have received, intermittently, snap core errors
[15:46] <Chipaca> jaggz: why not "snap install meshlab"?
[15:47] <Chipaca> jaggz: what do the errors say?
[15:47] <jaggz> hrm.. that says it's already installed
[15:47] <jaggz> - 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)
[15:47] <Chipaca> jaggz: the ls output agrees that it's installed
[15:47] <jaggz> that was from a snap refresh core
[15:48] <Chipaca> jaggz: ok, "snap version" output please?
[15:48] <Chipaca> zyga-suse: ^ snap-update-ns error for you
[15:48] <zyga-suse> Chipaca: aha
[15:48] <jaggz> running /snap/bin/meshlab sits there.. strace -f shows: [pid 31791] execve("/snap/core/current/usr/bin/snap", ["/snap/bin/meshlab"], [/* 83 vars */] <unfinished ...>
[15:48] <zyga-suse> jaggz: ok, two questions
[15:48] <zyga-suse> jaggz: what is snap version
[15:49] <zyga-suse> jaggz: I understand you are on 2.21 but snapd pulls in updates
[15:49] <jaggz> ooh.. hold.. can't kill this program..
[15:49] <zyga-suse> jaggz: so I would expect that to be 2.26.14 actually
[15:50] <Chipaca> jaggz: you need to kill the strace explicitly (e.g. killall -9 strace)
[15:50] <jaggz> is it safe to kill -9 the running /snap/bin/meshlab?  (which is a symlink to /usr/bin/snap, as I figure you know)
[15:50] <Chipaca> jaggz: it should be yes
[15:50] <Chipaca> jaggz: I don't know what meshlab does :-)
[15:51] <jaggz> okay.. yeah.. had to -9 the strace itself
[15:51] <Chipaca> jaggz: can you "snap install hello-world" and see if that works reasonably?
[15:51] <jaggz> yeah, not an issue with meshlab itself -- it's software that lets you work on 3d point clouds and meshes
[15:51] <jaggz> btw: snap    2.27~rc4
[15:51] <jaggz> snapd   2.27~rc4
[15:52] <zyga-suse> aha
[15:52] <zyga-suse> ok
[15:52] <zyga-suse> so far so good
[15:52] <zyga-suse> ok
[15:52] <jaggz> snap install hello-world says something about climate change
[15:52] <jaggz> (kidding.. it's running)
[15:52] <zyga-suse> sudo snap-discard-ns core
[15:52] <jaggz> one line.. it's installed
[15:52] <zyga-suse> er
[15:52] <ikey> right cheers again all - much appreciated, looking forward to torturing you again tomorrow hopefully for the last time :D
[15:52] <zyga-suse> sudo /usr/lib/snapd/snap-discard-ns core
[15:52] <zyga-suse> I think that will fix it for you
[15:52] <Chipaca> jaggz: now e.g. hello-world.env should work
[15:52] <zyga-suse> ikey: with pleasure :)
[15:53] <jaggz> zyga-suse, nice clean.. no output.. returns to prompt.  :)
[15:53]  * ikey is off to fix his van and have dinner + wine and such niceties
[15:53] <Chipaca> mmm, dinner
[15:53] <Chipaca> reminds me i have a train to catch for dinner
[15:53] <Chipaca> 5 minutes more
[15:53] <ikey> most people have enough trouble catching a chicken for dinner
[15:53] <ikey> let alone a train...
[15:53]  * ikey grins and walks out slowly
[15:53] <jaggz> Chipaca, it does.  what's hello-world.env do?  just a plain dump of environment to see what's in it?
[15:54] <Chipaca> ikey: what can i say, i'm feeling peckish
[15:54] <ikey> :P
[15:54] <Chipaca> jaggz: yes
[15:54] <jaggz> ikey, what's wrong with the van?
[15:54] <ikey|afk> jaggz, battery is stone dead
[15:54] <jaggz> ikey|afk,
[15:54] <jaggz> ikey|afk, your fault, or possibly alternator?
[15:54] <ikey|afk> picked up another one couple days back, €80 -_-
[15:54] <ogra_> ikey|afk, perhaps Chipaca can borrow you his train after dinner ?
[15:54] <jaggz> well.. if you know how to fix it.. no need to talk  good luck :)
[15:54] <ikey|afk> partially my fault partially old van that i bought a while back
[15:55] <ikey|afk> 2005 van
[15:55] <jaggz> I had to replace my alternator a while ago.. 1994 van :)
[15:55] <ikey|afk> and its been lined up a couple weeks
[15:55] <ikey|afk> not starting each day
[15:55] <ikey|afk> stuck it on the jumps, went fine, cold start, *pfft*
[15:55] <jaggz> I leave mine for a month at a time or more.. but it's an older one and doesn't have computers sucking away at power all the time.. or whatever cars do nowadays
[15:55] <jaggz> okay.. so.. meshlab
[15:55] <mup> Issue snapcraft#1476 opened: foreign arch and sources setup for `build-packages` <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1476>
[15:55] <mup> Issue snapcraft#1477 opened: multi-arch build packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1477>
[15:55] <mup> PR snapcraft#1388 closed: beta <Created by snappy-m-o> <Closed by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1388>
[15:55] <mup> PR snapcraft#1395 closed: [WIP] python plugin: track the python packages installed during build <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1395>
[15:56] <Chipaca> jaggz: ok, so hello-world works, and with zyga's command you should no longer see the nasty ns-update thing ,so now we just need to figure out why the mesh thing isn't working
[15:56] <Chipaca> jaggz: as i don't know what it would do if it worked, i can only say maybe you need to connect interfaces to it for something? maybe there are "audit" lines in your syslog to help you figure that one out
[15:56] <Chipaca> and now i must run
[15:57] <Chipaca> jaggz: if you get stuck, open a forum topic on this, so we can debug it asynchronously
[15:57] <jaggz> ikey|afk, in case you ever need help.. ##electronics is a nice broad-topic channel with some really knowledgeable people.
[15:57] <jaggz> Chipaca, if it works I'll get a window up :)
[15:58] <jaggz> need to do some searches on it.. it sits there, after some errors.. http://paste.debian.net/980795/
[15:59] <Chipaca> let me try it
[15:59] <Chipaca> jaggz: that looks like the snap needs work
[15:59] <zyga-suse> jaggz: which GPU do you have?
[15:59] <jaggz> nvidia 970.  a post here says to reinstall the nvidia drivers
[16:00] <jaggz> I'm in debian, but this is for ubuntu: https://askubuntu.com/questions/451221/how-do-i-install-the-nvidia-driver-for-a-geforce-gt-630/451248#451248
[16:00] <Chipaca> ah, my game computer has that card, i can try it tonight
[16:00] <zyga-suse> jaggz: may be missing nvidia support :/
[16:00] <zyga-suse> sorry
[16:01] <zyga-suse> missing support in snapd that is
[16:01]  * ogra_ wonders why GL snaps work just fine on his nvidia desktop 
[16:02] <ogra_> (never had probs after the very initial issue with the leftover stale dirs from old nvidia driver packages)
[16:02] <zyga-suse> ogra_: magic and complexity across distros
[16:02] <ogra_> ah, yeah, non-ubuntu is indeed different
[16:02] <ogra_> meshlab works fine here btw ... (on an intel based laptop though)
[16:03] <jaggz> I'm checking out the first errors too -- I jumped to the final one with libGL
[16:03] <mup> PR snapd#3706 closed: asserts,overlord/devicestate: support predefined assertions that don't establish foundational trust <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3706>
[16:03] <jaggz> the first being a gtk thing: Gtk-Message: Failed to load module "gail"
[16:03] <ogra_> the gtk stuff is pretty normal i think
[16:04] <jaggz> ogra_, what distribution?
[16:04] <ogra_> ubuntu indeed :)
[16:04] <ogra_> but that shouldnt matter at alll
[16:04] <jaggz> yeah.. probably shouldn't.
[16:05] <ogra_> note that the snap seems to initially create its config on first start
[16:05] <ogra_> which takes a while
[16:05] <ogra_> (so be patient)
[16:05] <jaggz> with external outside packages (like nvidia's), who knows though
[16:05] <kalikiana> ondra: Maybe we should discuss it in the forum, and see if it makes sense for other plugins as well
[16:05] <jaggz> ogra_, do you get the gtk errors?
[16:05] <ondra> kalikiana was thinking same
[16:06] <ogra_> jaggz, yes, the older versions of the gnome/gtk desktop helper had them
[16:06] <ogra_> (i think they are fixed nowadays ... but the maintainer would have to re-build the snap to have it pick that up)
[16:06] <kalikiana> ondra: I just took a look at the konfig options, wondering if that's another possibility, but it seems like uboot's arm handling a little bit... special
[16:06] <jaggz> http://paste.debian.net/980796/  I was just testing "snap remove meshlab" btw
[16:07] <ogra_> kalikiana, pfft ... uboot was there first .... it is *everyone elses* arm handling thats broken :P
[16:07] <ogra_> (indeed :) )
[16:07] <jaggz> got those core errors again
[16:07] <ogra_> jaggz, your snapd installation seems seriously messed up
[16:08] <ogra_> what did "snap version" say ?
[16:08] <jaggz> I don't have much in it.. I don't mind removing it and doing a clean install..
[16:08] <jaggz> 2.27~rc4
[16:08] <ogra_> the full utput ...
[16:08] <ogra_> *out
[16:08] <jaggz> series  16
[16:08] <jaggz> debian  9
[16:08] <jaggz> kernel  4.9.0-3-amd64
[16:09] <ogra_> and snap as well as snapd show as 2.27~rc4 ?
[16:09] <ogra_> (smells like your core snap is on the edge channel for some reason)
[16:10] <ogra_> ogra@styx:~$ snap version
[16:10] <ogra_> snap    2.26.14
[16:10] <ogra_> snapd   2.26.14
[16:10] <ogra_> series  16
[16:10] <ogra_> ubuntu  16.04
[16:10] <ogra_> kernel  4.4.0-83-generic
[16:10] <jaggz> yeah.. sorry.. didn't paste them for that purpose
[16:10] <ondra> kalikiana yeah it's a bit special
[16:10] <jaggz> hmm.. I'm in debian testing
[16:10] <ogra_> this should be what you see on anything tracking the stable channel atm
[16:10] <ogra_> jaggz, your distro shoulldnt matter at all ... thats all internally managed by snapd
[16:11] <ogra_> via the core snap
[16:11] <jaggz> oh I'm at stretch
[16:11] <ogra_> snap info core|grep tracking
[16:11] <ogra_> that should tell you what core snap you have
[16:11] <jaggz> beta
[16:11] <ogra_> aha
[16:11] <ogra_> (why did you move it to beta ? )
[16:11] <jaggz> I'm too unknowledgeable to have done that :)
[16:11] <ogra_> snap refresh core --stable
[16:12] <ogra_> that would get you back onto stable ... though i guess you are again hitting the namespace error now
[16:12] <jaggz> namespace error?
[16:12] <jaggz> it's working on the refresh, btw
[16:12] <ogra_> yes, the stuff you pasted above
[16:13] <jaggz> yeah.. :(
[16:14] <jaggz> why's there no snap-update-ns
[16:14] <ogra_> popey, FYI https://code.launchpad.net/~ogra/+snap/linux-generic-allwinner ... (if that ever builds, it will have the nanopi air support in it ... but we'll need a dedicated gadget for that board too)
[16:17] <jaggz> doesn't look like it's a part of the debian package
[16:19] <popey> ogra_: ooh! Exciting!
[16:20] <popey> ogra_: once it does, will you make a new image for it?
[16:25] <ogra_> popey, yep
[16:25] <ogra_> popey, but i cant test it indeed ... so all up to you
[16:25] <popey> suh-weeeet
[16:26] <popey> look forward to that
[16:26] <popey> got some ideas for things to do with that silly device
[16:46] <zyga-suse> jaggz: snap-update-ns is not in 2.21 package
[16:46] <zyga-suse> it should be used from the core snap
[16:46] <zyga-suse> but something seems broken there
[16:49] <jaggz> :/
[16:49] <jaggz> zyga-suse, thanks :)
[16:50] <kalikiana> ondra: ogra_ https://forum.snapcraft.io/t/custom-environment-variables-for-kbuild-and-other-plugins/1639
[16:51] <ogra_> kalikiana, well, i dont use kbuild anywhere (i find it way to opaque for porters)
[16:52] <ogra_> kalikiana, i'd rather have a way to use an arch tag for build-packages :)
[16:52] <ogra_> (like stage-packages provide)
[16:52] <kalikiana> ogra_: You mean as in libfoobar:arm64?
[16:52] <ogra_> kalikiana, that would really help with something like https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml (see the cross gcc check there)
[16:53] <ogra_> kalikiana, yeah
[16:53] <kalikiana> ogra_: So that's for multi-arch, right? Not really the same problem?
[16:54] <ogra_> my gadgets usually already work fine for cross ... but i always need to tell the user to install the cross compiler manually (or have a sudo call in the snapcraft.yaml to apt install it)
[16:54] <ogra_> kalikiana, not multi arch, gadgets are usually single arch target but multiple arches for building
[16:55] <ogra_> reverse-multiarch i guess :)
[16:55] <popey> ogra_: https://code.launchpad.net/~ogra/+snap/linux-generic-allwinner it built!
[16:55] <popey> (can you tell I'm excited)
[16:55] <kalikiana> ogra_: When I say multi-arch I mean if you need to install armhf packages on an amd64 host - but I'm not clear on what exactly your use case is
[16:55] <ogra_> popey, great ... i'll roll a new gadget for it
[16:56] <ogra_> kalikiana, well, i dont install armhf packages ... look at the snapcraft.yaml above line 20-24
[16:56] <ogra_> kalikiana, i install a package that doesnt exist on armhf when building on x86
[16:57] <ogra_> that snapcraft.yaml works fine natively ... but spills an error telling you to install one additional amd64 package (teh cross compiler) when building on != armhf
[16:58] <kalikiana> ogra_: But this says you need the arm gcc. That's normally in gcc-arm-linux-gnueabihf - so that's not multi-arch, it's actually a native package
[16:58] <ogra_> kalikiana, since that package does not exist on armhf i can not just put it into build-packages without breaking the native build ... so on amd64 installs i'd like to be build-packages selective
[16:58] <ogra_> kalikiana, gcc-arm-linux-gnueabihf is an amd64-only package
[16:59] <ogra_> (it is only available on x86
[16:59] <ogra_> )
[17:00] <ogra_> it is a cross compiler built only on non-armhf ...  and not available at all on armhf
[17:00] <ogra_> (else i'd just list it in build-packages and the corss build would just magically work without any fiddling)
[17:02] <ogra_> kalikiana, but yes, essentially all i'd like is support for:
[17:02] <kalikiana> ogra_: Oh. So the problem is you need a different package depending on the architecture
[17:02] <ogra_> gcc-arm-linux-gnueabihfgcc-arm-linux-gnueabihf
[17:02] <ogra_> bah
[17:02] <ogra_> build-packages:
[17:02] <ogra_>   - foobar [amd64]
[17:02] <ogra_> something like this
[17:02] <ogra_> which is supported in stage-packages but not in build-packages
[17:02] <ogra_> kalikiana, yep, exactly
[17:03] <ogra_> (super hard to explain :) )
[17:03] <Pharaoh_Atem> mvo: running through a scratch build of 2.27: https://koji.fedoraproject.org/koji/taskinfo?taskID=21150688
[17:04] <ogra_> kalikiana, note that all other uboot builds use this way, not kabuild
[17:04] <ogra_> *kbuild
[17:04] <ogra_> kbuild support in u-boot is very rare and very new and only a few new arches support it yet
[17:04] <Pharaoh_Atem> gah
[17:05] <kalikiana> ogra_: So you want something like "on" for build-packages
[17:05] <ogra_> yeh!
[17:05] <Pharaoh_Atem> mongodb ftbfs with new boost 1.64 :(
[17:05] <ogra_> yeah!
[17:05] <Pharaoh_Atem> and it's blocking snapd :(
[17:05] <ogra_> Pharaoh_Atem, huh ? how can mongodb block snapd ?
[17:05] <kalikiana> ogra_: I didn't actually realize this doesn't exist, I never need it  - would you mind opening a forum topic for this?
[17:06] <ogra_> not at all ...
[17:06]  * ogra_ writes
[17:06] <kalikiana> Grand, thanks!
[17:06] <Pharaoh_Atem> ogra_: mongodb go driver -> mongodb-libs -> mongodb
[17:06] <ogra_> ah
[17:07] <Pharaoh_Atem> I guess I'm going to fix mongodb (ugh)
[17:10] <cachio> niemeyer, I think we need one more worker for fedora
[17:10] <cachio> today 2 builds failed at least becasue of fedora jobs didn't finish
[17:11] <cachio> niemeyer, is it ok if I move from 2 to 3?
[17:11] <niemeyer> cachio: Ah, probably then
[17:11] <niemeyer> cachio: What was the time delta between fedora finishing and the previous one?
[17:12] <cachio> niemeyer, well fedora did not finish
[17:12] <ogra_> kalikiana, https://forum.snapcraft.io/t/support-on-in-build-packages/1641
[17:13] <niemeyer> cachio: Question still stands
[17:13] <cachio> niemeyer, from the last disk removed until the job exceeded time is 15 minutes
[17:13] <cachio> and still 46 tasks were missing
[17:13] <niemeyer> cachio: Yeah, definitely sounds like a case for another worker
[17:14] <cachio> niemeyer, also I think we need to try to speed up how the rmp is built
[17:15] <cachio> niemeyer, the .rpm it is taking about 5 minutes more than the .deb
[17:19] <mvo> Pharaoh_Atem: yay! build looks unhappy but failure looks unrelated (something about liboost?)
[17:20] <mup> PR snapd#3711 opened: tests: adding new worker for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3711>
[17:29] <Pharaoh_Atem> mvo: mongodb isn't rebuilt against new boost
[17:30] <Pharaoh_Atem> and since snapd requires mongodb through requiring the go mongo driver
[17:30] <Pharaoh_Atem> it looks like mongodb unit tests are failing on s390x (*sighs*
[17:31] <ogra_> how weird, given that snapd doesnt use anything from mongodb
[17:31] <ogra_> (or does it ?)
[17:34] <pedronis> we  gopkg.in/mgo.v2/bson  (not sure how that relates to mongo itself on distros though)
[17:36] <pedronis> *we use
[17:36] <ogra_> ah
[18:02] <mup> PR snapcraft#1427 closed: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <Closed by alextnewman> <https://github.com/snapcore/snapcraft/pull/1427>
[18:24] <niemeyer> cachio: 5 minutes sounds pretty bad indeed
[18:59] <cachio> niemeyer, yes, i'll research a bit more
[19:14] <mup> PR snapcraft#1478 opened: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <https://github.com/snapcore/snapcraft/pull/1478>
[19:17] <arm1e> I would like to learn how to prodouce snap packages and have successfully followed the helo world example on snapcraft but I dont know where to look next to help me compile a snap for an application. Examples I have seen have lots of flags that I dont understand that are not in the snapcraft example. Can anyone point me in the right direction please
[19:18] <arm1e> *hello
[19:18] <arm1e> not helo
[19:28] <mup> PR snapd#3712 opened: overlord,store: send model assertion when setting up device sessions <Created by matiasb> <https://github.com/snapcore/snapd/pull/3712>
[19:59] <kyrofa> arm1e, hey there!
[19:59] <kyrofa> Sorry for the delay, I had my face buried in a fajita. You still around?
[20:04] <bdmurray> Is there somebody interested in doing the SRU verification of snapd in -proposed? Its been there for a bit.
[20:06] <pedronis> cachio: I'm seeing often failures like this one:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170810_183543_f1d6a@/log.gz   are we not waiting properly for the fakestore to be started or ther is something else going on
[20:08] <cachio> pedronis, ok, I'll take a look
[20:08] <cachio> pedronis, It appeared today
[20:13] <pedronis> or maybe we don't stop the service
[20:13] <pedronis> cachio: yes, I don't remember seeing this at least for a while, anyway it seems the reason we get reds here and there now
[20:14] <cachio> pedronis, yes, I am running a set of tests to try to reproduce the error
[20:15] <cachio> I'll keep up updated with the result
[20:15] <pedronis> thank you
[20:16] <cachio> yaw
[20:31] <ogra_> popey, if you upgrade your kernel to linux-generic-allwinner rev 2 and run: sudo fw_setenv fdt_file sun8i-h3-nanopi-neo-air.dtb ... and reboot ... i wonder if the wlan works :)
[20:46] <arm1e> kyrofa: yup still here
[20:47] <kyrofa> arm1e, I'm happy to help point you in the right direction. Is there something particular you're trying to snap up?
[20:53] <arm1e> would like to snap gnucash as I have a friend who wants to switch to solus (who are adding snap support)  but it will not be added to their repos as some of the dependencies are old
[20:57] <popey> ogra_: that'll be triicky given the machine has no network
[20:57] <ogra_> popey, huh ? wired didnt work ?
[20:57] <popey> it has no wired connector
[20:57] <ogra_> oh !
[20:57] <ogra_> i thought it had both
[20:58] <popey> this is why i'm so keen for wifi to work :D
[20:58] <ogra_> yeah, understood ... ok, then it needs a full image ... i'll give you something tomorrow
[20:59] <popey> magic, ta
[21:18] <mwhudson> morning
[21:20] <kyrofa> Good morning mwhudson, welcome
[21:41] <kyrofa> arm1e, what is that written in?
[21:42] <popey> arm1e: kyrofa https://forum.snapcraft.io/t/call-for-comments-testing-gnucash/1480
[21:42] <popey> jacob has worked on it, maybe you can work on it together?
[21:42] <kyrofa> popey, how handy, thank you!
[21:46] <mwhudson> ok maybe i have working debian packaging for 2.27
[21:46] <mwhudson> probably not but it's worth trying the build now at least :)
[21:47] <mwhudson> oh wait did 2.27 actually get released?
[21:50] <kyrofa> mwhudson, it's tagged anyway
[21:50] <mwhudson> and it was uploaded to artful
[21:50] <mwhudson> and even built!
[21:52] <kyrofa> mwhudson, your day is starting off strong
[21:52] <mwhudson> and it failed it's autopkgtest on i386
[21:52] <kyrofa> Aw
[21:53] <mwhudson> whoa hasn't passed there in a while
[21:53] <mwhudson> http://autopkgtest.ubuntu.com/packages/s/snapd/artful/i386
[21:53] <mwhudson> - Download snap "core" (2465) from channel "candidate" (received an unexpected http response code (416) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_2465.snap?t=2017-08-10T17:00:00Z&h=359a718c18b7c126e3302dce1d720f2333d87dec)
[21:53] <mwhudson> pff
[21:53]  * mwhudson bounces on the retry button
[21:58] <kyrofa> Sounds like https://forum.snapcraft.io/t/download-failure-416/1637/3
[22:06] <mwhudson> omg my debian package built
[22:17] <mwhudson> slangasek: https://anonscm.debian.org/git/collab-maint/snapd.git/log/?h=debian-2.27 <- mostly complete package of snapd for debian if you're interested
[22:18] <mwhudson> slangasek: the git history is a mess (do we care? i could clean it up) and the changelog needs work (not sure what we should do there, bring in all the upstream changelog entries?)
[22:18] <mwhudson> slangasek: but it works
[22:18] <mwhudson> slangasek: do you have an opinion on using pristine-tar for this package?
[22:18] <mwhudson> slangasek: s/works/builds/
[22:19] <slangasek> mwhudson: pristine-tar applies only if the package is non-native, do we have that here?  and is there an actual upstream tarball for us to import?
[22:19] <slangasek> git history> if it inherits from the previous package history, that's what I care about most
[22:19] <mwhudson> slangasek: the package is non-native in debian yes
[22:20] <slangasek> right, but still not in Ubuntu though it should be, bah
[22:20] <mwhudson> slangasek: i based it on the tarball from github https://anonscm.debian.org/git/collab-maint/snapd.git/log/?h=debian-2.27
[22:20]  * mwhudson blinks
[22:20] <mwhudson> slangasek: https://github.com/snapcore/snapd/archive/2.27.tar.gz
[22:21] <mwhudson> slangasek: in a sense the non-obvious canonicity of the tarball seems an argument in favour of pristine-tar for debian ... makes it clear what i used
[22:21] <mwhudson> (even if not where i got it from)(
[22:21] <mwhudson> slangasek: the git history is based on the previous packaging history yes
[22:21] <mwhudson> it just has "oh crap i forgot a bit" commits in
[22:22] <mwhudson> and some dubious merging
[22:22] <slangasek> that doesn't bother me ;)
[22:22] <mwhudson> ok
[22:23] <mwhudson> slangasek: http://paste.ubuntu.com/25286402/ <- this is what the debian patch ends up being
[22:25] <mwhudson> which all seems ok enough to me
[22:25] <mwhudson> need to ITP that gettext package but that doesn't need to block the update
[22:28] <mwhudson> ok afk for a bit
[22:35] <arm1e> kyrofa: Any help in learning how to compile snaps. I have no idea how to check for deps. Willing to read, but would prefer to practise
[22:35] <nacc> arm1e: what do you mean "check for deps"?
[22:35] <arm1e> dependencies
[22:36] <arm1e> Is there a good way to convert packages in the repos into snaps?
[22:36] <nacc> arm1e: right, i know what deps are -- i don't know what you mean by check for them?
[22:36] <nacc> arm1e: not really (that i know of)
[22:36] <nacc> arm1e: i mean, a classic snap is the easiest way, but you still have to write the snapcraft.yaml
[22:37] <slangasek> mwhudson: how does a missing ITP not block the update?
[22:38] <arm1e> nacc: Sure. I just got really confused after completing the hello-world snap locally then looking at the yaml files from other snaps which have a lot of other info from plugins etc. It seems a big jump
[22:38] <arm1e> Especially when you have never packaged before
[22:39] <nacc> arm1e: well, right, i think hello-world is just to get you familiar with the commands and some basic syntax
[22:39] <slangasek> mwhudson: and do those go dep path changes make their way back upstream?
[22:39] <arm1e> I want to learn how to do it but everywhere just does really simple syntax and nowhere really teaches you
[22:39] <nacc> arm1e: it doesn't, imo, make much sense to package something you're not familiar with. Do you have an application you care about?
[22:40] <arm1e> nacc: Not particularly. I would like to get gnucash working but that looks like a major ball-ache
[22:42] <nacc> arm1e: i would imagine for a classic snap of a given application that builds as a .deb, you could add all it's build-deps to build-packages, all the binary package's runtime deps to stage-packages and then try and build it normally (that is, if one of the existing plugins works). If they don't, you might need to write your own plugin to build
[22:44] <arm1e> see, I dont fully understand the difference between build / runtime deps and how you know which plugins should be used.
[22:44] <nacc> arm1e: do you understand the difference between build and runtime?
[22:45] <arm1e> build is to compile and runtime is to actually use the app, right?
[22:45] <nacc> arm1e: right
[22:45] <nacc> arm1e: those are distinct environments, so they can have different dependencies
[22:46] <nacc> arm1e: in other words, what you need to build something is not necesarily what you need to run it and v.v
[22:46] <arm1e> okay.
[22:47] <arm1e> nacc: So how do you choose the plugin?
[22:47] <nacc> arm1e: by knowing how the code is built (what tool)
[22:48] <arm1e> How do you know that? Is it in the source tarball?
[22:48] <nacc> arm1e: you look and see? I'm not sure how to answer it
[22:49] <nacc> it feels like a tautology: to build something, you have to know how to build it
[22:49] <arm1e> nacc: Where can I learn this?
[22:50] <nacc> arm1e: depending on the specific project, it might be the language (e.g., python or go) or it might be a specific build-tool (e.g. autotools)
[22:50] <nacc> arm1e: where can you learn what exactly? build something, I mean, that's the whole point
[22:51] <arm1e> nacc: What I mean is how can I tell if something is built in python etc?
[22:51] <nacc> arm1e: it's not built in python, it's written in python
[22:51] <nacc> arm1e: it's built by the python plugin by snapcraft
[22:51] <arm1e> I see, what I mean is how can I tell from the source what the language is
[22:53] <nacc> arm1e: you either know, because you're familiar with it, or you read documentation or you use `file` or ... i'm sure there are other ways
[22:54] <arm1e> Right, I would like to make a snap for get_iplayer
[22:55] <nacc> arm1e: link to source?
[22:55] <arm1e> https://github.com/get-iplayer/get_iplayer
[22:57] <nacc> arm1e: looks to be perl
[22:58] <arm1e> yup. What do I do about the deps, how will I know if they are in the base system of the snap as usually packages pull from the repos of the host system, but is it different for snap packages?
[22:59] <nacc> arm1e: how would you "build it
[22:59] <nacc> sorry, hit enter too fast
[22:59] <nacc> arm1e: how would you "build it" if you weren't thinking about snaps?
[23:00] <arm1e> run the configure, check for deps if missing and add them via apt. once configured, make
[23:01] <arm1e> only learnt that today, so may be wrong
[23:01] <nacc> right, so you add those deps to your snapcraft.yaml as build-packages
[23:01] <arm1e> just list the names?
[23:02] <nacc> arm1e: see the online documentation for the syntax
[23:04] <arm1e> what I mean is, once I have them listed, how do I know if the snap package will be able to find them?
[23:08] <nacc> arm1e: you try to build?
[23:08] <nacc> arm1e: what do you mean find them?
[23:10] <arm1e> Might be wrong but when you normally build, your deps only matter to you if they are not already on your system, if not the build fails, so you apt-get to install them then retry. When you download a snap, doesnt the new system require these deps to be installed too?
[23:11] <nacc> arm1e: isntalling a snap != building a snap
[23:11] <nacc> arm1e: and i feel like you're jumping several steps
[23:11] <arm1e> right
[23:11] <arm1e> sorry
[23:11] <nacc> arm1e: 1) building a snap is done with snapcraft (or using snapcraft.io)
[23:11] <nacc> *build.snapcraft.io
[23:11] <arm1e> gotcha
[23:11] <arm1e> continue :)
[23:11] <nacc> arm1e: in that case, it's done in a special environment that generates the squashfs image (which is what a snap is)
[23:11] <nacc> arm1e: you don't build the snap again anywhere else
[23:11] <arm1e> right, my bad
[23:12] <arm1e> sorry
[23:12] <nacc> arm1e: installing a snap is done via the store (or locally with --dangerous) and snaps contain all their dependencies
[23:12] <arm1e> so you would only need to have the runtime deps
[23:12] <nacc> (or should)
[23:12] <nacc> a confined snap does not have access to the system by default, so it won't run without its dependencies in the snap as well
[23:13] <nacc> a classic snap may work (if the dependencies happen to be installed) but won't otherwise -- and there's not a way to tie (currently) a snap to deb dependencies. So you should include them in your snap (IMO)
[23:13] <arm1e> so how do you ensure these dependencies are in the snap?
[23:14] <arm1e> Does it pull them from the system I am building on?
[23:14] <nacc> arm1e: you put them there? either via stage-packages (explicitly), or via the plugin (depending on the plugin)
[23:14] <nacc> arm1e: well, again, you build in a special enviornment, so it uses the ones in that environment, yes
[23:15] <arm1e> okay, so stage-packages are the explicit dependencies for a snap to install / run on another system
[23:15] <nacc> arm1e: i feel like maybe you should read the snapcraft.io pages a bit? https://tutorials.ubuntu.com/tutorial/create-your-first-snap?_ga=2.140231089.346536776.1502406151-840062186.1488838724#0
[23:15] <nacc> or that tutorial, maybe
[23:15] <nacc> arm1e: i'm pretty sure all of this on the website
[23:15] <nacc> arm1e: stage-packges are the list of packages you want to stage in the snap (see the website for definitino of stage)
[23:15] <arm1e> Yes. I will read them again tomorrow and try to get it to sink in. BTW there is no perl plugin so that makes it more difficult, right?
[23:16] <nacc> arm1e: and to be clear "install a snap" has no dependencies, it's just a squashfs image that gets mounted somehwere
[23:16] <nacc> arm1e: running the snap is the only thing that has dependencies on user's systems (which should all be included in the snap)
[23:16] <arm1e> nacc: sorry, I mean run a snap
[23:16] <arm1e> I am with you
[23:16] <nacc> arm1e: might be, yes, but it seems like some users have made one, which you can copy, and it's not clear you need it in this case (if there's a makefile)
[23:17] <mwhudson> slangasek: because the functionality requiring that package is removed in debian for now
[23:17] <slangasek> mwhudson: ah ok
[23:18] <slangasek> right, those would be the i18n bits of the patch
[23:18] <mwhudson> yep
[23:18] <mwhudson> -	"github.com/cheggaaa/pb"
[23:18] <mwhudson> +	"gopkg.in/cheggaaa/pb.v1"
[23:18] <arm1e> nacc: Will have a look in the morning. Thanks for your help. Time for bed
[23:18] <nacc> arm1e: gl!
[23:18] <mwhudson> ^ that path change should probably go upstream
[23:18] <mwhudson> or the debian packaging should be changed to the other path, i'm not sure what upstream considers canonical currently
[23:19] <mwhudson> the seccomp stuff is needed for trusty support upstream
[23:19] <mwhudson> so that remains necessary delta
[23:19] <mwhudson> for another 2 years i guess...
[23:35] <slangasek> mwhudson: snapd ESM
[23:35] <slangasek> :)
[23:51] <mwhudson> slangasek: shutup
[23:51] <slangasek> mwhudson: it's ok, ESM is security only!
[23:52] <mwhudson> slangasek: so what should debian's debian/changelog contain?
[23:52] <mwhudson> do i copy over the new entries from packaging/ubuntu-16.04/changelog and slap something debian specific on the top?
[23:53] <mwhudson> hmm E: snapd: statically-linked-binary usr/lib/snapd/system-shutdown
[23:56] <mup> PR snapcraft#1471 closed: catkin plugin: support passing args to cmake <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1471>