| 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> | 00:51 |
|---|---|---|
| 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:58 |
| 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) | 01:59 |
| mup | PR snapd#3701 opened: tests: fix interfaces-cups-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3701> | 02:05 |
| PhoenixMage | How jailed are snaps? They seem to log to the root /var/log | 03:33 |
| PhoenixMage | ie, I now have samba.log files in /var/log after installing the samba snap I am working on | 03:34 |
| mup | PR snapd#3702 opened: interfaces: add missing test for camera interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3702> | 04:24 |
| 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:26 |
| 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? | 05:43 |
| mup | PR snapd#3704 opened: interfaces: convert lxd to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3704> | 07:52 |
| zyga-suse | good morning | 07:54 |
| 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:57 |
| zyga-suse | hey Chipaca, feels good to have the merge go in :) | 07:58 |
| Chipaca | yes | 08:00 |
| mvo | hey zyga-suse | 08:02 |
| mwhudson | zyga-suse: o/ | 08:05 |
| zyga-suse | hey hey | 08:06 |
| zyga-suse | I have one important bug to check and then I'd like to release suse and arch packages | 08:07 |
| 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:14 |
| zyga-suse | mvo: sure, where? | 08:15 |
| mvo | zyga-suse: suse, arch | 08:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:28 |
| mwhudson | zyga-suse: on the dependency side | 08:30 |
| mwhudson | zyga-suse: we can leave the i18n commented out for now i guess | 08:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| * 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:34 |
| mwhudson | mvo: ack | 08:35 |
| zyga-suse | mvo: the tarball has different name and internal directory name than the one before | 08:36 |
| 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:37 |
| zyga-suse | ok | 08:38 |
| 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:41 |
| * 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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, | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 | |
| 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:15 |
| 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:16 |
| mwhudson | you think that hasn't happened already? :) | 09:18 |
| * zyga-suse grabs some coffee while deps are pulled | 09:18 | |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| * 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:48 |
| ikey | *unfortunately* you guys forcibly statically link libseccomp :P | 09:49 |
| === chihchun_afk is now known as chihchun | ||
| 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:49 |
| 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:50 |
| zyga-suse | ikey: and if you have initial patches for solus please start sending them | 09:52 |
| mup | PR snapd#3707 opened: interfaces: convert io_ports_control to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3707> | 09:54 |
| * ikey sighs at libseccomp abuse of configure.ac | 09:59 | |
| ikey | [1] 1730 invalid system call snap run duckmarines | 10:13 |
| ikey | poo. | 10:13 |
| zyga-suse | I think you have to find the number somehow | 10:15 |
| zyga-suse | is that still from snap-confine or from the suckmarines binary alreday? | 10:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| ikey | changed dirs.go | 10:22 |
| ikey | ill change it back | 10:22 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| zyga-suse | ok, I'll get back to bugfixing | 10:47 |
| zyga-suse | please ping me if you find something odd to investigate | 10:47 |
| 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:48 |
| 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:49 |
| 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:50 | |
| 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 | 10:51 |
| 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:02 |
| 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:11 |
| ikey | zyga-suse, got a strace for running duckmarines: https://hastebin.com/akeviquqoc.erl if you wanna check later | 11:18 |
| 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:19 | |
| 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:20 |
| 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:21 |
| ikey | soo | 11:23 |
| ikey | looks like AF_NETLINK is needed and not whitelisted | 11:23 |
| ikey | or am i reading this wrong.. | 11:23 |
| zyga-suse | socket AF_NETLINK - NETLINK_ROUTE | 11:25 |
| zyga-suse | aah | 11:25 |
| zyga-suse | it wants a different type | 11:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| * sergiusens wonders when we will start seeing zyga-solus | 11:29 | |
| ikey | post-solus-release :p | 11:29 |
| zyga-suse | yes, likely | 11:30 |
| zyga-suse | nothing like hands-on | 11:30 |
| Son_Goku | morning all | 11:30 |
| 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:31 |
| 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:32 | |
| 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:33 |
| 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:34 |
| 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:36 |
| * 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:37 | |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| zyga-suse | pleasure :) | 11:46 |
| * ogra_ sighs about the flashplugin update he gets ... | 11:48 | |
| ogra_ | thats the only package i'd really love to see as classic snap one day :) | 11:49 |
| 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:56 |
| 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:57 |
| pstolowski | thanks | 11:58 |
| mup | PR snapcraft#1474 opened: kbuild plugin: use ARCH from environment if set <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1474> | 12:01 |
| kalikiana | ondra: ^^ | 12:02 |
| ondra | kalikiana do you have build of snapcraft with that change,so I can test it? | 12:04 |
| 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:06 |
| abeato | mvo, hey, is current core edge really built from master or is it a re-spin of 2.27? | 12:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| zyga-suse | sergiusens: what is the difference today? | 12:16 |
| zyga-suse | sergiusens: that they run via shell? | 12:16 |
| mvo | sergiusens: created and mentioned you | 12:17 |
| 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:18 |
| 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:19 |
| 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:20 | |
| 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:24 |
| 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:28 |
| 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:29 |
| ikey | Does apparmor require CONFIG_AUDITSYSCALL ? | 12:39 |
| ikey | (and thus, snap) | 12:39 |
| * zyga-suse doesn't know | 12:39 | |
| 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:40 |
| * zyga-suse is melting here | 12:41 | |
| ikey | anyone able to zgrep CONFIG_AUDITSYSCALL /proc/config.gz..? | 12:41 |
| ikey | (on buntu) | 12:41 |
| * 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:42 |
| 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:43 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 | |
| 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:53 |
| 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:54 |
| 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:56 |
| 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:57 |
| 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:58 |
| kalikiana | ondra: "ARCH=arm snapcraft --target-arch=arm64" is what I tested | 12:59 |
| ondra | kalikiana aha :) | 12:59 |
| ogra_ | crazy stuff | 12:59 |
| 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:00 |
| 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:01 |
| ogra_ | but i remember there was this odd mkimage thing | 13:02 |
| ondra | kalikiana LP is native | 13:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 | |
| zyga-ubuntu | ikey: :-) | 13:26 |
| 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:31 |
| 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:32 |
| === chihchun is now known as chihchun_afk | ||
| 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:52 |
| roadmr | jdstrand: totally | 13:53 |
| jdstrand | roadmr: thanks :) | 13:54 |
| 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:56 |
| 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:57 |
| zyga-ubuntu | mvo: as I said, I was hopping channels | 13:58 |
| Chipaca | zyga-ubuntu: what sort of broken snap? | 13:58 |
| 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 :) | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| zyga-ubuntu | mvo: I don't have Type=notify in snapd.service | 14:06 |
| zyga-ubuntu | Chipaca: not me | 14:06 |
| Chipaca | zyga-ubuntu: i suspect gnome-software | 14:07 |
| Chipaca | zyga-ubuntu: because of the icons | 14:07 |
| zyga-ubuntu | maybe | 14:07 |
| 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:08 |
| 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:09 |
| 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:11 |
| 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:12 |
| * zyga-ubuntu thinks about lunch | 14:15 | |
| pstolowski | zyga-ubuntu, thinking about it rarely helps ;) | 14:15 |
| * zyga-ubuntu eats stuff :D | 14:20 | |
| 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:22 |
| 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:23 |
| * zyga-ubuntu suspends this laptop to work on one less computer at a time | 14:32 | |
| 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:38 |
| ikey | having a shop is all well good provided you put the shop on a busy street and sell things people want | 14:52 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| zyga-suse | ikey: no, it's not mandatory | 15:07 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| ikey | the failed call is aa_kernel_interface_new(&kernel_interface, features, apparmorfs) == -1) { | 15:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| ikey | Could not open 'tunables/global' | 15:20 |
| ikey | pfft | 15:20 |
| * ikey adds profiles to pkg | 15:20 | |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:25 |
| 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:33 |
| 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:35 |
| ikey | ok how do i do that | 15:36 |
| ikey | lol | 15:36 |
| ikey | " /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/ w," mebbe? | 15:37 |
| zyga-suse | the synax is like | 15:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| Chipaca | ikey: http://i.imgur.com/eTic1wS.jpg | 15:43 |
| zyga-suse | :D | 15:43 |
| jaggz | Chipaca, http://paste.debian.net/980792/ | 15:44 |
| ikey | Chipaca, lol | 15:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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 is now known as ikey|afk | ||
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| jaggz | need to do some searches on it.. it sits there, after some errors.. http://paste.debian.net/980795/ | 15:58 |
| 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 | 15:59 |
| 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:00 |
| zyga-suse | missing support in snapd that is | 16:01 |
| * ogra_ wonders why GL snaps work just fine on his nvidia desktop | 16:01 | |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| jaggz | yeah.. :( | 16:13 |
| 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:14 |
| jaggz | doesn't look like it's a part of the debian package | 16:17 |
| popey | ogra_: ooh! Exciting! | 16:19 |
| popey | ogra_: once it does, will you make a new image for it? | 16:20 |
| ogra_ | popey, yep | 16:25 |
| ogra_ | popey, but i cant test it indeed ... so all up to you | 16:25 |
| popey | suh-weeeet | 16:25 |
| popey | look forward to that | 16:26 |
| popey | got some ideas for things to do with that silly device | 16:26 |
| 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:46 |
| jaggz | :/ | 16:49 |
| jaggz | zyga-suse, thanks :) | 16:49 |
| kalikiana | ondra: ogra_ https://forum.snapcraft.io/t/custom-environment-variables-for-kbuild-and-other-plugins/1639 | 16:50 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | kalikiana, well, i dont use kbuild anywhere (i find it way to opaque for porters) | 16:51 |
| 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:52 |
| ogra_ | kalikiana, yeah | 16:53 |
| kalikiana | ogra_: So that's for multi-arch, right? Not really the same problem? | 16:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| ogra_ | (it is only available on x86 | 16:59 |
| ogra_ | ) | 16:59 |
| 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:00 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| Pharaoh_Atem | I guess I'm going to fix mongodb (ugh) | 17:07 |
| === JanC is now known as Guest25300 | ||
| === JanC_ is now known as JanC | ||
| 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:10 |
| 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:11 |
| cachio | niemeyer, well fedora did not finish | 17:12 |
| ogra_ | kalikiana, https://forum.snapcraft.io/t/support-on-in-build-packages/1641 | 17:12 |
| 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:13 |
| cachio | niemeyer, also I think we need to try to speed up how the rmp is built | 17:14 |
| cachio | niemeyer, the .rpm it is taking about 5 minutes more than the .deb | 17:15 |
| === chihchun is now known as chihchun_afk | ||
| mvo | Pharaoh_Atem: yay! build looks unhappy but failure looks unrelated (something about liboost?) | 17:19 |
| mup | PR snapd#3711 opened: tests: adding new worker for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3711> | 17:20 |
| === nacc_ is now known as nacc | ||
| Pharaoh_Atem | mvo: mongodb isn't rebuilt against new boost | 17:29 |
| 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:30 |
| ogra_ | how weird, given that snapd doesnt use anything from mongodb | 17:31 |
| ogra_ | (or does it ?) | 17:31 |
| pedronis | we gopkg.in/mgo.v2/bson (not sure how that relates to mongo itself on distros though) | 17:34 |
| pedronis | *we use | 17:36 |
| ogra_ | ah | 17:36 |
| 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:02 |
| niemeyer | cachio: 5 minutes sounds pretty bad indeed | 18:24 |
| cachio | niemeyer, yes, i'll research a bit more | 18:59 |
| mup | PR snapcraft#1478 opened: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <https://github.com/snapcore/snapcraft/pull/1478> | 19:14 |
| 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:17 |
| arm1e | *hello | 19:18 |
| arm1e | not helo | 19:18 |
| 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:28 |
| kyrofa | arm1e, hey there! | 19:59 |
| kyrofa | Sorry for the delay, I had my face buried in a fajita. You still around? | 19:59 |
| bdmurray | Is there somebody interested in doing the SRU verification of snapd in -proposed? Its been there for a bit. | 20:04 |
| 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:06 |
| cachio | pedronis, ok, I'll take a look | 20:08 |
| cachio | pedronis, It appeared today | 20:08 |
| 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:13 |
| cachio | pedronis, yes, I am running a set of tests to try to reproduce the error | 20:14 |
| cachio | I'll keep up updated with the result | 20:15 |
| pedronis | thank you | 20:15 |
| cachio | yaw | 20:16 |
| 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:31 |
| arm1e | kyrofa: yup still here | 20:46 |
| kyrofa | arm1e, I'm happy to help point you in the right direction. Is there something particular you're trying to snap up? | 20:47 |
| 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:53 |
| === nacc is now known as Guest76500 | ||
| === nacc_ is now known as nacc | ||
| 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:57 |
| 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:58 |
| popey | magic, ta | 20:59 |
| mwhudson | morning | 21:18 |
| kyrofa | Good morning mwhudson, welcome | 21:20 |
| kyrofa | arm1e, what is that written in? | 21:41 |
| 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:42 |
| 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:46 |
| mwhudson | oh wait did 2.27 actually get released? | 21:47 |
| kyrofa | mwhudson, it's tagged anyway | 21:50 |
| mwhudson | and it was uploaded to artful | 21:50 |
| mwhudson | and even built! | 21:50 |
| kyrofa | mwhudson, your day is starting off strong | 21:52 |
| mwhudson | and it failed it's autopkgtest on i386 | 21:52 |
| kyrofa | Aw | 21:52 |
| 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:53 | |
| kyrofa | Sounds like https://forum.snapcraft.io/t/download-failure-416/1637/3 | 21:58 |
| mwhudson | omg my debian package built | 22:06 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| mwhudson | and some dubious merging | 22:22 |
| slangasek | that doesn't bother me ;) | 22:22 |
| mwhudson | ok | 22:22 |
| mwhudson | slangasek: http://paste.ubuntu.com/25286402/ <- this is what the debian patch ends up being | 22:23 |
| === ppisati is now known as ppisati_afk | ||
| 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:25 |
| mwhudson | ok afk for a bit | 22:28 |
| 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:35 |
| 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:36 |
| slangasek | mwhudson: how does a missing ITP not block the update? | 22:37 |
| 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:38 |
| 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:39 |
| arm1e | nacc: Not particularly. I would like to get gnucash working but that looks like a major ball-ache | 22:40 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| arm1e | nacc: So how do you choose the plugin? | 22:47 |
| nacc | arm1e: by knowing how the code is built (what tool) | 22:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| arm1e | Right, I would like to make a snap for get_iplayer | 22:54 |
| nacc | arm1e: link to source? | 22:55 |
| arm1e | https://github.com/get-iplayer/get_iplayer | 22:55 |
| nacc | arm1e: looks to be perl | 22:57 |
| 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:58 |
| 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? | 22:59 |
| arm1e | run the configure, check for deps if missing and add them via apt. once configured, make | 23:00 |
| 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:01 |
| nacc | arm1e: see the online documentation for the syntax | 23:02 |
| 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:04 |
| nacc | arm1e: you try to build? | 23:08 |
| nacc | arm1e: what do you mean find them? | 23:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| mwhudson | slangasek: because the functionality requiring that package is removed in debian for now | 23:17 |
| slangasek | mwhudson: ah ok | 23:17 |
| 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:18 |
| 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:19 |
| slangasek | mwhudson: snapd ESM | 23:35 |
| slangasek | :) | 23:35 |
| mwhudson | slangasek: shutup | 23:51 |
| slangasek | mwhudson: it's ok, ESM is security only! | 23:51 |
| 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:52 |
| mwhudson | hmm E: snapd: statically-linked-binary usr/lib/snapd/system-shutdown | 23:53 |
| 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> | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
