[00:05] <mup> Issue snapcraft#1464 closed: Extract rosdep into its own package <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1464>
[00:05] <mup> PR snapcraft#1392 closed: catkin plugin: extract rosdep into new package <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1392>
[00:08] <mup> PR snapcraft#1479 opened: rosdep: add support for multiple dependency types <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1479>
[00:22] <slangasek> mwhudson: I think it's reasonable for the Debian debian/changelog to list Ubuntu history also, yes
[00:22] <mwhudson> slangasek: ok
[00:27] <mwhudson> what is usr/lib/snapd/system-shutdown for?
[00:27] <mwhudson> i have a guess that it might only be relevant on an all-core system?
[00:48] <PhoenixMage> Hi guys, when I set LD_LIBRARY_PATH in a yaml do I have to put the original library paths in also?
[01:20] <mwhudson> Aug 11 00:14:29 autopkgtest snapd[2412]: 2017/08/11 00:14:29.874892 task.go:303: DEBUG: 2017-08-11T00:14:29Z ERROR received an unexpected http response code (416) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_2465.snap?t=2017-08-11T02:00:00Z&h=ac56e373310e0069784f61009d0bad0e6c529795
[01:20] <mwhudson> ^ this is happening apparently repeatedly in the i386 autopkgtest, is it possible that something is broken with the i386 core snap or the cdn?
[01:31] <mwhudson> oh wait
[04:46] <mup> PR snapcraft#1480 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1480>
[06:06] <mup> PR snapd#3709 closed: release: snapd 2.27 release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3709>
[06:27] <jjohansen1> ikey|afk: apparmor depends (selects actually) CONFIG_AUDIT, it does not depend on CONFIG_AUDITSYSCALL
[07:04] <mup> PR snapd#3713 opened: osutil: ensure TestLockUnlockWorks uses supported flock <Created by mvo5> <https://github.com/snapcore/snapd/pull/3713>
[07:05] <mup> PR snapd#3711 closed: tests: adding extra worker for fedora <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3711>
[07:07] <mup> PR snapd#3703 closed: interfaces: improve and tweak bunch of interfaces test cases <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3703>
[07:12] <mup> PR snapd#3701 closed: tests: fix interfaces-cups-control test <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3701>
[07:35] <zyga-suse> good morning
[07:57] <mup> PR snapd#3675 closed: tests: restart snapd to ensure re-exec settings are applied <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3675>
[08:05] <arm1e> nacc: You still there?
[08:08] <mup> PR snapd#3704 closed: interfaces: convert lxd to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3704>
[08:38] <arm1e> can anyone help with creating a snap please.
[08:40]  * zyga-suse reboots
[08:57] <mvo> arm1e: hey, any specific question abut snapping ? its probably best to just ask the question :) then people can reply when they see the message. in any case, did you check out https://tutorials.ubuntu.com/tutorial/create-your-first-snap#0 already?
[08:58] <arm1e> okay. I am trying to compile a snap for get_iplayer. I have started the yaml file and added the run dependencies but to install you are supposed to run the following
[08:58] <arm1e>  install -m 755 ./get_iplayer /usr/local/bin
[08:58] <arm1e> how to i set that in the snap?
[08:59] <arm1e> Following the instructtions here btw: https://github.com/get-iplayer/get_iplayer/wiki/unix
[09:01] <zyga-suse> mvo: hey
[09:01] <zyga-suse> mvo: do you have a second?
[09:01] <zyga-suse> mvo: well, honestly, 5 minutes
[09:01] <mvo> arm1e: if you just want to make get_iplayer available you can use e.g. the organize rule in snapcraft to put it into the snap, there is no need to install it to /usr/local/bin, it just need to be in the snap (well, at least that is what I assume, I don't know get_iplayer)
[09:01] <mvo> zyga-suse: sure
[09:02] <mvo> zyga-suse: phonecall or chat?
[09:02] <zyga-suse> mvo: hangout
[09:02] <zyga-suse> I want to screen-share
[09:02] <arm1e> i am confused. (sorry)
[09:02] <zyga-suse> I'm in the standup HO
[09:04] <Chipaca> arm1e: if I remember get_iplayer, you don't need to run that install step, you can just run it from where it is
[09:04] <arm1e> Chipaca: so how do i snap it?
[09:04] <Chipaca> arm1e: doesn't it have a Makefile though?
[09:04] <ogra_> it does
[09:05] <arm1e> no mention in the doc, but will check
[09:05] <ogra_> Chipaca, seems it is a perl program ... that will need some extra fiddling to have perl work
[09:05] <Chipaca> arm1e: if it has a makefile, I _think_ snapcraft knows how to deal with it
[09:05] <ogra_> (at least if there asre any modules involved)
[09:05] <arm1e> found one
[09:06] <Chipaca> ogra_: i remember i played with snapping it "by hand" (before snapcraft) and indeed the tricky bit was the perl libs
[09:06] <Chipaca> but not super tricky, just more effort than i wanted back then :-)
[09:06] <ogra_> yeah
[09:06] <Chipaca> ogra_: also ffmpeg
[09:06] <ogra_> (my first snap was also a perl thing)
[09:06] <arm1e> https://github.com/get-iplayer/get_iplayer/blob/master/Makefile
[09:06] <Chipaca> (but that's optional)
[09:06] <Chipaca> arm1e: are you using snapcraft
[09:06] <arm1e> I have installed ffmpeg 3 from the ppa on the host machine
[09:07] <arm1e> Chipaca: yes
[09:07] <arm1e> here is my yaml file so far (be gentle, it is my first time!)
[09:07] <Chipaca> arm1e: snapcraft has a make plugin
[09:08] <arm1e> https://pastebin.com/Xv56Qn7K
[09:10] <Chipaca> arm1e: you should be able to use plugin: make instead of plugin: dump
[09:10] <arm1e> just trying that
[09:10] <Chipaca> arm1e: but somebody who groks snapcraft more than me should probably guide you
[09:10] <Chipaca> arm1e: https://snapcraft.io/docs/reference/plugins/make
[09:16] <arm1e> okay, pulling now
[09:19] <arm1e> Chipaca: error https://pastebin.com/QqebESbn
[09:20] <Chipaca> arm1e: looks like you need to tell it what to install manually (why even have a makefile?!). Fortunately the plugin supports this?
[09:20] <arm1e> how do i do it?
[09:21] <arm1e> is it the artifacts tag?
[09:24] <arm1e> really stuck now
[09:31] <Chipaca> arm1e: did the examples help?
[09:31] <arm1e> what examles?
[09:34] <arm1e> Chipaca: I cant work out the syntax for the make plugin
[09:37] <arm1e> Chipaca: all I get is 'Mapping values are not allowed'
[09:38]  * zyga-suse tries this on artful
[09:41]  * ikey cracks knuckles to begin another snapfest solus day
[09:42] <zyga-suse> hey
[09:42] <zyga-suse> :)
[09:42] <ikey> heya ^^
[09:42] <arm1e> Chipaca: the examples for make linked on the snapcraft page do not lead to anything other than a github error!
[09:44] <Saviq> kalikiana: hey, for some reason container builds (not cleanbuild) stopped working here, complain about snap/snapcraft.yaml missing, any ideas?
[09:44] <Saviq> it works the first time, but not after the container already exists
[09:45] <arm1e> Can anyone help with the syntax for the make plugin please?
[09:45] <kalikiana> Saviq: What version are you running?
[09:46] <Chipaca> arm1e: ouch
[09:46] <arm1e> Chipaca: what?
[09:46] <Chipaca> sergiusens_: ^ who's working on that?
[09:46] <Chipaca> arm1e: <arm1e> Chipaca: the examples for make linked on the snapcraft page do not lead to anything other than a github error!
[09:47] <arm1e> I know, not the best documentation is it
[09:47] <arm1e> ANy ideas how i can find examples?
[09:49]  * arm1e starts to regret beginning this work
[09:51] <pedronis> Chipaca: hi, maybe you can give a 2nd/3rd review to:  snapd#3712
[09:51] <mup> PR snapd#3712: overlord,store: send model assertion when setting up device sessions <Created by matiasb> <https://github.com/snapcore/snapd/pull/3712>
[09:52]  * zyga-suse reviews 3710 while waiting for packages downloads
[09:57] <arm1e> can someone please help me with the syntax to use options for plugins
[09:59] <zyga-suse> mvo: the test passes on artful and I can now compare the behavior
[09:59] <zyga-suse> arm1e: hey
[09:59] <zyga-suse> arm1e: which options for which plugin specifically?
[10:00] <zyga-suse> arm1e: (I'm sorry for the bad experience you had so far)
[10:01] <zyga-suse> quick question, does anyone remember that snap which had a fancy music player installed?
[10:02] <ikey> arm1e, see https://github.com/jeteokeeffe/lindacoin-wallet-snap/blob/master/snap/snapcraft.yaml#L61
[10:02] <zyga-suse> ikey: FYI I get the "bad system call" from duckmarines on ubuntu 17.10
[10:02] <ikey> there is an example there of make/autotools/organise/artifacts + dump
[10:02] <ikey> zyga-suse, oh interesting
[10:02] <arm1e> zyga-suse: I am having trouble with the build steps in make as the make file is crap. I need to specify the installation location
[10:02] <zyga-suse> arm1e: snapcraft sets DESTDIR I think
[10:02] <ikey> zyga-suse, the makefile is release-only
[10:02] <ikey> no actual install steps
[10:03] <ikey> so its a manual install of a perl script and manpage
[10:03] <ikey> i.e. "./get_iplayer" needs organising into usr/bin
[10:03] <zyga-suse> aha....
[10:03] <arm1e> zyga-suse: https://pastebin.com/Xv56Qn7K
[10:03] <zyga-suse> why don't you just run the get script and package the results?
[10:03] <arm1e> zyga-suse: I dont know how. I have not packaged before
[10:03] <zyga-suse> arm1e: some syntax there looks wonky
[10:03] <zyga-suse> arm1e: tabs vs spaces maybe?
[10:03] <ikey> and !yaml
[10:04] <zyga-suse> arm1e: my suggestion, skip the downloader, just get the bits you want to put into the snap
[10:04] <arm1e> this was the error https://pastebin.com/QqebESbn
[10:04] <zyga-suse> arm1e: using stage-packages means you get unpacked deb files into your snap, those are not always going to work
[10:04] <zyga-suse> make: *** No rule to make target 'install'. Stop.
[10:05] <arm1e> no, but I made sure that I had the correct versions mentioned in the get_iplayer docs
[10:05] <zyga-suse> arm1e: I don't see how you use a makefile since the earlier pastebin used the dump plugin
[10:05] <arm1e> it was an old version
[10:05] <arm1e> hang on a sec...
[10:05] <zyga-suse> I packaged python0 as a classic snap a while ago
[10:05] <zyga-suse> https://github.com/zyga/python0
[10:05] <zyga-suse> using make
[10:05] <zyga-suse> maybe that will help you out
[10:06] <ikey> 0.9.1.. damn..
[10:06] <zyga-suse> :D
[10:06] <zyga-suse> and so small :D
[10:06] <zyga-suse> I was researching bytecode evolution across python versions
[10:06] <ikey> ah
[10:06] <zyga-suse> ikey: try it, it is interesting
[10:06] <zyga-suse> ikey: ldd the binary
[10:06] <zyga-suse> ikey: and readelf the binary
[10:07] <ikey> sure
[10:07] <ikey> woa.
[10:07] <arm1e> https://pastebin.com/A9Bi4UTJ
[10:07] <ikey> only 2 DT_NEEDED
[10:07] <zyga-suse> arm1e: yaml still looks wonky
[10:07] <zyga-suse> arm1e: line 15
[10:08] <zyga-suse> ikey: note how it links to the core snap
[10:08] <arm1e> zyga-suse: Not like that in my text editor tho
[10:09] <zyga-suse> arm1e: fix your editor
[10:09] <ikey> zyga-suse, it does?
[10:09] <zyga-suse> arm1e: you must be mixing tabs and spaces
[10:09] <ikey> ldd on python0 https://hastebin.com/takerojuvi.go
[10:09] <ikey> wait im being a twit
[10:09] <ikey> i think i ldd'd the wrong guy :P
[10:09] <ikey> lol yeah i ldd'd the bin/ symlink
[10:10] <ikey> 	/snap/core/current/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (0x00007fdb2220f000)
[10:10] <arm1e> https://hastebin.com/esilogacib.cs
[10:10] <arm1e> pastebin is crap
[10:10] <ikey> ah you RPATH'd it
[10:10] <zyga-suse> ikey: more than that
[10:10] <zyga-suse> ikey: look at the dynamic linker
[10:10] <ikey> yea
[10:11] <zyga-suse> :-)
[10:11] <ikey> pretty snazzy
[10:11] <ikey> fwiw solus uses a different linker location to most
[10:11] <ikey> /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.14.32, BuildID[sha1]=06de7bdeae201f41009ee0ce7d0bfd4bd9748907, stripped, with debug_info
[10:11] <zyga-suse> oh, interesting!
[10:11] <ikey> but we have a compat link stuffed in /lib/
[10:11] <zyga-suse> aha
[10:11] <ikey> to keep chrome etc going
[10:11] <ikey> the toolchain itself is built to use /usr only
[10:12] <ikey> https://hastebin.com/eluzuyetiq.go :D
[10:13] <arm1e> zyga-suse: could you talk me through what I should be doing next please
[10:13] <arm1e> I am feeling lost
[10:13] <arm1e> ikey: I am learning this to be able to snap gnucash (evetually....maybe) to be able to runit in bloody solus!
[10:13] <ikey> heh
[10:14] <ikey> yeah they dont like using modern libs
[10:14] <zyga-suse> ikey: as for duckmarines
[10:14] <zyga-suse> if you add one line to its seccomp profile and rebuilt it will work
[10:14] <arm1e> ikey: I know, but I have my accounts on the thing. Tried to move away but cant
[10:14] <ikey> well what im seeing for python0 is this:
[10:14] <ikey> cannot change profile for the next exec call: No such file or directory
[10:14] <zyga-suse> I think the author made this snap and we broke compatibility by restricting sockets more
[10:15] <ikey> which means this fails:
[10:15] <ikey> 	if (aa_change_onexec(profile) < 0) {
[10:15] <zyga-suse> ikey: odd, python0 should not need that
[10:15] <zyga-suse> or maybe I forgot and it does
[10:15] <ikey> which is coming from:
[10:15] <ikey> open("/proc/18856/attr/exec", O_WRONLY) = 3
[10:15] <ikey> write(3, "exec snap.python0.python0", 25) = -1 ENOENT (No such file or directory)
[10:15] <zyga-suse> right
[10:15] <zyga-suse> it apparently does need that
[10:15] <zyga-suse> just that the profile is permissive
[10:15] <zyga-suse> ikey: as for the netlink socket
[10:16] <ikey> ah yeah
[10:16] <zyga-suse> ikey: I added "socket AF_NETLINK -  NETLINK_KOBJECT_UEVENT" to snap.duckmarines.duckmarines.src
[10:16] <ikey> yeah makes sense
[10:16] <zyga-suse> and re-built that with snap-seccomp compile foo.src foo.bin
[10:16] <Saviq> kalikiana: 2.33
[10:16] <zyga-suse> mvo: ^ any objection if I add go-flags to snap-seccomp
[10:16]  * arm1e Washes hand so that it can be held as he is led through packaging to help cure his ineptitude
[10:17] <zyga-suse> and this made it start up OK
[10:17] <ikey> fwiw im getting the profile change issue on *all* snaps
[10:17] <ikey> even duckmarines
[10:17] <zyga-suse> right, I think you are missing something in the kernel still, you just don't have the attr/exec file in proc right?
[10:17] <ikey> no i have it
[10:18] <ikey> /proc/7233/attr/exec for my shell exists
[10:18] <ikey> cat /proc/$$/attr/exec
[10:18] <ikey> cat: /proc/7233/attr/exec: Invalid argument
[10:18] <zyga-suse> hmmm
[10:18] <zyga-suse> ah
[10:18] <zyga-suse> right
[10:18] <ikey> its an empty file - no idea what its meant to do/have
[10:18] <zyga-suse> sorry so this is because the thing that gets written there
[10:18] <ikey> yeah
[10:18] <zyga-suse> the name of the apparmor profile to use
[10:18] <zyga-suse> such profile doesn't exist
[10:18] <Saviq> kalikiana: it's as if it's not entering /root/build_multipass - it's mounted fine
[10:18] <ikey> and the kernel cries about it
[10:18] <zyga-suse> because snapd didn't make one
[10:19] <zyga-suse> because you are still on partial confinement
[10:19] <ikey> right
[10:19] <zyga-suse> because not all apparmor features are detected
[10:19] <zyga-suse> one sec
[10:19] <ikey> ok
[10:21] <zyga-suse> hrm
[10:21] <zyga-suse> polari doesn't want to connect from artful for some reason
[10:22] <kalikiana> Saviq: Lemme see if I can reproduce
[10:22] <zyga-suse> ikey: I wanted to let you know which features I see on ubuntu
[10:22] <ikey> ok
[10:22] <zyga-suse> ikey: capability, caps/, dbus/, domain/, file/, mount/, namespaces/, network/, policy/, ptrace/, query/, rlimit/, signal/
[10:23] <zyga-suse> ikey: those with slashes are directories
[10:23] <ikey> capability  caps/       domain/     file/       policy/     rlimit/
[10:23] <zyga-suse> so the backport patch, must have been partial
[10:23] <ikey> seems it
[10:23] <zyga-suse> ikey: can you look at ubuntu sauce patches in any ubuntu kernel that affect security/apparmor directory
[10:24] <ikey> idk where to find those sauce patches
[10:24] <ikey> i have http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/log/?h=v4.13-apparmor-backport-to-v4.12
[10:24] <ikey> but those are missing capabilities obv
[10:24] <kalikiana> ^^ this makes me look forward to lunch
[10:24] <zyga-suse> yeah, looks like out of date
[10:24] <ikey> saw nothing about dbus, etc, in the presquash
[10:25] <zyga-suse> ikey: look at xenial tree at http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/
[10:25] <zyga-suse> ikey: then just look for patches that affect apparmor
[10:25] <zyga-suse> (in securty/apparmor directory)
[10:25] <ondra> kalikiana ping
[10:25] <zyga-suse> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/security/apparmor
[10:26] <ikey> thats a lot of signal noise
[10:26] <kalikiana> ondra: Hey
[10:27] <zyga-suse> ikey: note that this is based on 16.04 kernel which is older
[10:27] <zyga-suse> ikey: so some of those are merged upstream from your POV
[10:28] <ondra> kalikiana I have problem with prime: [ -lib ]
[10:28] <ondra> kalikiana it will still leave some bits there
[10:28] <ondra> kalikiana does seem to work for all other directories except lib
[10:29] <ondra> kalikiana or tell me what is cleanest way to pull stage package and only extract one file from it
[10:29] <ikey> sure but apparently the dbus work started in 2014
[10:29] <ikey> why/how are these not upstream?
[10:30] <zyga-suse> ikey: lots of reasons, one of which was rush to get phone features ready
[10:30] <ikey> yeah but roadmap is from 2011 :p
[10:30] <zyga-suse> ikey: the focus is on exclusively upstreaming them for some time
[10:30] <ikey> 6 years..
[10:30] <zyga-suse> ikey: some reason, AFAIK (not a 1st hand report) is some upstream discussions on specific mediation extensions
[10:32] <ikey> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/security/apparmor/apparmorfs.c#n1568
[10:32] <ikey> is the bits-i-dont-got
[10:33] <ikey> oh wow this is an old kernel
[10:33] <zyga-suse> xenial is old
[10:33] <zyga-suse> try artful
[10:33] <zyga-suse> artful has the same features but less patches
[10:33] <zyga-suse> so should be far closer to solus
[10:33] <ikey> yeah artful is rocking 4.11.0
[10:34] <mvo> zyga-suse: go-flags for snpa-seccomp is fine
[10:40]  * zyga-suse thinks about automatically fixing security profiles of certain snaps
[10:40] <zyga-suse> great experience for people
[10:40] <zyga-suse> kind of magic and windows-y
[10:40] <zyga-suse> but then again...
[10:40] <zyga-suse> well, maybe later
[10:43] <ikey> k so the upstream 4.13 patch is very different to the artful tree
[10:44] <zyga-suse> mvo: interesting, on suse we execute the cycles=2 line
[10:44] <zyga-suse> ikey: is 4.14 the next LTS kernel>
[10:44] <ikey> yea
[10:45] <ondra> kalikiana any idea?
[10:46] <ondra> kalikiana BTW what is syntax to add stage package as snap?
[10:46] <ondra> kalikiana or is that limited only to build packages?
[10:48] <kalikiana> ondra: I'd probably do the reverse, [lib/foobar.so] Not sure, though, what "some bits" would be left. Maybe from packages installed in another part?
[10:48] <kalikiana> ondra: stage package as a snap? Not sure what that means
[10:48] <ondra> kalikiana so what would be syntax if I want just one file?
[10:49] <ondra> kalikiana did we enable build-packages and stage-packages to be also snaps? or it's limited to only deb packages?
[10:49] <kalikiana> ondra: I just told you the syntax :-D
[10:49] <ondra> kalikiana OK let me try :)
[10:50] <kalikiana> ondra: Oh. Those are always Debian packages. You might want build snaps, which is something that has been proposed but doesn't exist yet.
[10:50] <ikey> well according to release/release.go i need all the apparmor features ubuntu has.. buh
[10:51] <ondra> kalikiana for example I'd like to pull in snap package as build dependency
[10:52] <ondra> kalikiana OK that works, except that lib dir is still there
[10:55] <kalikiana> ondra: Feel free to open a forum topic, as I said it's been proposed but doesn't exist
[10:55] <kalikiana> ondra: I thought you have a file lib/foo.so - how would that work without the directory?
[10:56] <ikey> long time since i had to make defconfig a kernel git and build one module lol
[10:58] <kalikiana> Saviq: Hmm I think I've reproduced with a repeated "snapcraft" invocation. Would you mind opening a forum topic so we can track it?
[11:00] <jdstrand> zyga-suse: https://bugs.launchpad.net/snapd/+bug/1663221
[11:00] <mup> Bug #1663221: snap/apparmor default confinement rejects socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT); <snapd-interface> <snapd:Fix Released by jdstrand> <https://launchpad.net/bugs/1663221>
[11:00] <Saviq> kalikiana: ack
[11:01] <kalikiana> Thanks
[11:01] <jdstrand> zyga-suse: that was the whole reason we did fine-grained mediation and I could've sworn I added that
[11:01] <zyga-suse> aha, thank you
[11:01] <zyga-suse> :)
[11:01]  * zyga-suse hugs jdstrand
[11:01] <jdstrand> https://bugs.launchpad.net/snapd/+bug/1663221
[11:02] <zyga-suse> mvo: so, some more data
[11:02] <zyga-suse> mvo: interesting actually
[11:02] <jdstrand> but either it got lost with all the commit/uncommit/commit/uncommit/recommit/... or I didn't submit that because of it
[11:02] <zyga-suse> mvo: on ubuntu the goroutine is scheduled quickly
[11:02] <zyga-suse> mvo: on suse it is cheduled nearly 500ms later
[11:02] <zyga-suse> *scheduled
[11:03] <zyga-suse> and some of the logic kicks in
[11:03] <jdstrand> mvo: I'm going to prepare a PR for that ^ and a couple of smaller fixes. I think it should be in 2.27 :\ (since we are now enforcing netlink mediation)
[11:03] <jdstrand> s/smaller/other small/
[11:03] <zyga-suse> mvo: ^^^
[11:03] <ondra> kalikiana no actually I'm pulling just one file from bin, but it adds me lib regardless
[11:03] <zyga-suse> rc++
[11:04]  * Chipaca takes a break
[11:05] <arm1e> zyga-suse: hey, gotta go soon. Any chance you can have another quick go at helping me fix the get_iplayer snap build
[11:05] <zyga-suse> mvo: it seems that on suse goroutines are only scheduled every 0.5s
[11:05] <zyga-suse> arm1e: sorry, I lost track of what the issue was
[11:06] <zyga-suse> arm1e: apart from some syntax errors
[11:06] <zyga-suse> arm1e: what was the last thing you were blocked on?
[11:06] <arm1e> cannot build it as the makefile is crap
[11:06] <zyga-suse> arm1e: who wrote the makefile
[11:06] <zyga-suse> arm1e: look at my python0 snap, it uses a separate makefile to fix the makefile that is crap in python0
[11:06] <arm1e> the author of the program, but you said something about manually installing it
[11:07] <zyga-suse> arm1e: specifically, write one that doesn't suck
[11:07] <arm1e> there is no real build
[11:07] <zyga-suse> arm1e: you can then patch or replace it
[11:07] <ogra_> popey, give it a try please :) http://people.canonical.com/~ogra/snappy/nanopi-air.img.xz
[11:07] <arm1e> zyga-suse: https://github.com/get-iplayer/get_iplayer/wiki/unix
[11:07] <zyga-suse> arm1e: sorry, I cannot jump into all the details now
[11:08] <zyga-suse> arm1e: I gave you ideas on how to fix it
[11:08] <zyga-suse> arm1e: one other idea
[11:08] <zyga-suse> arm1e: is the iplayer a pre-built binary?
[11:08] <zyga-suse> or are you really building it
[11:08] <arm1e> it seems to be prebuilt
[11:08] <zyga-suse> arm1e: so ignore *everything* else
[11:08] <zyga-suse> and just package the content
[11:08] <arm1e> how do i do that?
[11:08] <zyga-suse> using the dump plugin
[11:09] <zyga-suse> just get it as you would normally
[11:09] <zyga-suse> and once you have that
[11:09] <zyga-suse> package it using the dump plugin
[11:09] <arm1e> then it says to run 'install ./get_iplayer /usr/local bin. How do I set that?
[11:09] <zyga-suse> you don't get it
[11:09] <zyga-suse> install it on your machine
[11:09] <zyga-suse> then copy it into as snap
[11:09] <arm1e> oh
[11:09] <arm1e> how
[11:09] <zyga-suse> tadam
[11:10] <zyga-suse> copy all the files one by one into your repo with snapcraft yaml
[11:10] <zyga-suse> and "install" them using the dump plugin from a tarball or something
[11:10] <zyga-suse> do you get the overall idea?
[11:10] <arm1e> I do... i ink
[11:10] <arm1e> think
[11:10] <kalikiana> ondra: So you've got an empty lib/ in your snap? Could be a bug, but I think I'd need more context at this point. I'd say take it to the forum with some more details.
[11:10] <arm1e> will have a go later. Thanks!
[11:10] <zyga-suse> once that works you can think about maybe optimizing the initial step which will be manual for you once
[11:11] <zyga-suse> good luck
[11:12] <ogra_> zyga-suse, it is a perl script ... he'll have a hard time getting the module paths right etc ... (will need wrapper scripts etc)
[11:14] <ogra_> (perl stuff is sadly still ugly to snap )
[11:14] <ondra> kalikiana no, it's not empty, it has few libs in there
[11:15] <ondra> kalikiana is snapcraft as smart as keeping some libs which are needed by that executable?
[11:15]  * zyga-suse braks
[11:15] <zyga-suse> mvo: I get the problem now :)
[11:15] <zyga-suse> mvo: patch incoming if you are doing another RC anyway
[11:16] <kalikiana> ondra: You can answer that question better, I don't know what libs those are :-)
[11:16] <ogra_> doesnt snapcraft run ldd to check the libs a binary needs ?
[11:16] <ogra_> (i thought it does)
[11:17] <mup> PR snapcraft#1429 closed: cli: properly handle exceptions in lifecycle <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1429>
[11:17] <kalikiana> ogra_: Yes it does
[11:18] <ogra_> that should answer ondra's question then :)
[11:18] <ondra> kalikiana ogra_ probably the case it keeps dependencies needed by the binary
[11:19] <kalikiana> Well, as I said, I can only guess. Many possibilities.
[11:19] <kalikiana> Of course I'm happy to assume it's super smart and free of bugs in this particular case
[11:19] <ogra_> haha
[11:19] <ogra_> like all software you mean ?
[11:20] <kalikiana> Some software is more bug free than others
[11:20] <ogra_> lies :P
[11:20] <ogra_> :)
[11:30] <Saviq> kalikiana: https://forum.snapcraft.io/t/repeated-container-builds-fail-to-find-snapcraft-yaml/1649
[11:34]  * zyga-suse really breaks
[11:56] <pedronis> zyga-suse: fedora prepare is failing with:   Cannot download d/distribution-gpg-keys-1.12-1.fc25.noarch.rpm: All mirrors were tried
[11:57] <zyga-suse> pedronis: mmm, let me check
[11:57] <zyga-suse> pedronis: btw that ensure test is now better understood
[11:57] <mup> PR snapd#3714 opened: interfaces: a bunch of interfaces test improvement <Created by adglkh> <https://github.com/snapcore/snapd/pull/3714>
[11:57] <gary-wzl> zyga-suse: I just created another PR for interfaces improvement.
[11:57] <zyga-suse> pedronis: I don't know the reason of the effect yet but I know it is present and the cause is a test failure
[11:57] <zyga-suse> gary-wzl: I saw, I'lll review it soon
[11:57] <gary-wzl> zyga-suse: That'd be the last bunch of interfaces I work for the improvement.   :D
[11:58] <gary-wzl> Thanks. After they land, I'll merge master back to udev_tag branch.
[11:58] <zyga-suse> pedronis: the effect is that ensure ticks at 0.5s on suse and 0.01 on ubuntu
[11:58] <gary-wzl> Then we  probably have minimized diff size and can focus on code review for actual udev tagging rule. :)
[11:58] <gary-wzl> Thanks again!
[11:58] <zyga-suse> pedronis: (or sorry 0.02 on ubuntu)
[11:58] <zyga-suse> pedronis: if it is compiler or kernel I'm not sure yet, I'll move a binary from one to another to compare now
[11:59] <zyga-suse> pedronis: so that test behaves in a way it never expected simply because various Ensures are called way too infrequently
[11:59] <zyga-suse> pedronis: a simple "fix" is to multiply the mocked intervals by 5
[12:01] <zyga-suse> pedronis: one thing I also noticed is that suse uses xfs and btrfs
[12:01] <zyga-suse> pedronis: so if any of the tests are hitting disk and running some sync op
[12:01] <zyga-suse> pedronis: that might explain the extra slowdown
[12:02] <pedronis> so you are saying that NewTicker misbihaves a bit on suse?
[12:02] <pedronis> or whatever bit of go timers we use there
[12:03] <zyga-suse> pedronis: I tested that, NewTicker works OK at at least 20ms resolution
[12:03] <zyga-suse> it must be something else
[12:03] <zyga-suse> I also compared my boxes and time it takes to lock/unlock is even better on this suse box (perhaps just CPU differences)
[12:04]  * zyga-suse has a binary to move over now
[12:04] <zyga-suse> woaah
[12:07] <zyga> pedronis: http://paste.ubuntu.com/25289847/
[12:08] <zyga> pedronis: the binary was compiled on suse
[12:08] <mup> PR snapd#3715 opened: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3715>
[12:08] <zyga> and invoked on suse tumbleweed running 4.11.8 and ubuntu artful running 4.11.0
[12:08] <popey> ogra_: what exact command do you use for serial connection to your nano pi? I get no response from screen and minicom, but maybe settings?
[12:10] <zyga> pedronis: the diff whows that waitForPrune (from the test witness) runs at rougly each 50ms on ubuntu but roghly each ~400ms on suse
[12:10] <zyga> *shows
[12:10] <zyga> I'll try it the other way around now
[12:10] <zyga> but since this only depends on pthreads now, I think it's clear something is very wrong
[12:12] <jdstrand> mvo, zyga: fyi https://github.com/snapcore/snapd/pull/3715. I've milestoned it for 2.27 since it has a netlink mediation fix for QtSystems
[12:12] <mup> PR snapd#3715: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3715>
[12:12] <zyga> jdstrand: ok
[12:12] <zyga> jdstrand: would be nice to add a regression test for this
[12:12] <zyga> jdstrand: as we missed this in all the testing
[12:13] <jdstrand> zyga: I need a system with X and qtubuntu for that to be a true regression fix. otherwise the test would be artificial and just a test that we don't drop the rule (which we don't have per rule regression tests)
[12:14] <zyga> indeed :/
[12:14] <jdstrand> s/regression fix/regression test/
[12:14] <ikey> so i did something kinda naughty.
[12:15] <ikey> i took kernel 4.12, and artful kernel..
[12:15] <ikey> replaced security/apparmor tree with artfuls one
[12:15] <zyga> haha
[12:15] <ikey> then patched it with some bits from 4.13
[12:15] <ikey> and did some porting to current kernel
[12:15] <ikey> (like not using the new aafs_create_symlink or aa_sfs ops)
[12:15] <ikey> and it now builds
[12:15] <zyga> I think you want to get a hold of jjohansen1 as he probably has the right patches stashed somewhere
[12:15] <zyga> but thank you for doing this
[12:15] <zyga> ikey: and the bug you found with that game, regression
[12:15] <ikey> ive only kept the .policy + policy symlink from 4.13
[12:15] <zyga> ikey: and fix is upcoming (from jdstrand above)
[12:16] <ikey> oh ok
[12:20] <ikey> freenode is like the spiritual opposite of viagra.
[12:20] <mup> PR snapd#3716 opened: overlord: rely on more conservative ensure inteval <Created by zyga> <https://github.com/snapcore/snapd/pull/3716>
[12:21] <mvo> jdstrand: thanks, I have  a look. too late for 2.27 unfortuantely (unless we need to do a .1)
[12:22] <zyga> mvo: I think we doo
[12:22] <zyga> mvo: this is a regression breaking visual snaps
[12:22] <zyga> mvo: :/
[12:22] <zyga> mvo: we *really* need this fixed ASAP
[12:22] <ikey> plus ikey is gonna be hella awkward and have last minute PRs > 2.27
[12:23] <zyga> mvo: the bane of point releases is still with us
[12:24] <mvo> zyga: tell me more
[12:24] <ikey> like did he have a car
[12:24]  * ikey hides
[12:24] <mvo> ikey: heh :)
[12:24] <jdstrand> mvo: sorry, the netlink bits got lost on my end with all the commit/revert/commit/revert/commit/... stuff with seccomp arg filtering
[12:25] <jdstrand> :\
[12:25] <jdstrand> I always intended to submit this with the other netlink mediation since this was actually the bug that prompted the whole netlink mediation feature
[12:26] <mvo> jdstrand: ok, its not too terrible 2.27 is not in stable yet. so one of the 2.27 PRs caused a regression?
[12:26] <mvo> jdstrandand 3715 fixes it?
[12:27] <jdstrand> mvo: 2.26 finally enforced seccomp netlink mediation even though it was sent up ages ago
[12:28] <jdstrand> mvo: because the rules in 3715 weren't included (sorry), it regressed snaps that use QtSystems
[12:29] <jdstrand> mvo: 3715 fixes that
[12:29] <mvo> jdstrand: ok, so 2.26 is fine? and 2.27 is not unless we take 3715?
[12:29] <jdstrand> (QtSystems for mouse/keyboard detection via udev under X)
[12:29] <jdstrand> mvo: no, 2.26 has fine-grained netlink mediation
[12:30] <jdstrand> mvo: it does not have the rule for QtSystems to work (it should've)
[12:30] <jdstrand> mvo: therefore 2.26 has a regression
[12:30] <jdstrand> mvo: 3715 fixes that
[12:30] <zyga> mvo: if you don't mind please also take: https://github.com/snapcore/snapd/pull/3716
[12:30] <mup> PR snapd#3716: overlord: rely on more conservative ensure interval <Created by zyga> <https://github.com/snapcore/snapd/pull/3716>
[12:30] <zyga> mvo: it doesn't affect non-test code
[12:30] <jdstrand> as it happens, there aren't many applications that use this, but ikey picked one that does
[12:30] <zyga> mvo: and it will help with having less patches in distros
[12:31] <popey> ogra_: nvm, got screen working
[12:31] <mvo> zyga: sure
[12:32] <mup> PR snapd#3717 opened: overlord,store: no piles of return args for methods gathering device session request params <Created by pedronis> <https://github.com/snapcore/snapd/pull/3717>
[12:34] <Son_Goku> zyga: does this happen on Fedora 26 with golang 1.8.3 and 4.11.11?
[12:34] <zyga> Son_Goku: I didn't check yet
[12:34] <jdstrand> mvo: well, actually. looking at policy on my system, it seems that socket mediation is not in effect in 2.26, so 2.26 is *not* affected. 2.27 *will* regress without 3715
[12:34] <popey> ogra_: subbiquity isn't seeing the network
[12:34] <zyga> Son_Goku: my fedora box is right next to my suse box so I'll check soon :)
[12:34] <zyga> Son_Goku: I suspect it's related to golang 1.8.1 vs .3
[12:34] <ogra_> popey, damn ... can you capture dmesg and syslog and such ?
[12:35] <jdstrand> s/socket mediation/fine-grained socket mediation/
[12:35] <ogra_> well, actually only syslog off the SD i guess
[12:35] <popey> OK
[12:36] <popey> http://paste.ubuntu.com/25290000/ ogra_
[12:36] <popey> \o/ nice paste number
[12:36] <popey> pinnacle of my day. (I am easily pleased)
[12:36] <zyga> jdstrand: I noticed more pushes to the PR
[12:37] <zyga> jdstrand: is that really all we need?
[12:37]  * ikey had to be awkward and pick the weird app
[12:37] <ogra_> Aug 11 10:59:09 localhost kernel: [   26.303158] usbcore: registered new interface driver brcmfmac
[12:37] <ogra_> Aug 11 10:59:09 localhost kernel: [   26.412084] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.txt failed with error -2
[12:37] <ogra_> Aug 11 10:59:09 localhost kernel: [   27.475085] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[12:37] <jdstrand> zyga: just one-- 'r' to 'rw' in network-control
[12:37] <ogra_> \o/
[12:37] <zyga> right
[12:37] <jdstrand> zyga: it should've been rw to begin with
[12:37] <zyga> I'm curious how you found that
[12:37] <ogra_> popey, so it finds the device and loads the driver ... but i'm missing the firmware in the kernel snap
[12:37] <popey> ahh!
[12:37] <ikey> so yeah if those 4.12 patches exist anywhere id love em, because my kernel wont boot (and efi sucks for debugging)
[12:37] <jdstrand> zyga: oh and a comment change
[12:37] <zyga> jdstrand: hmm? you changed from r to rw now
[12:38] <popey> ogra_: so close :)
[12:38] <jdstrand> zyga: let's back up
[12:38] <ogra_> popey, we're close (but that takes another kernel snap build and some changes ... will take some time)
[12:38] <zyga> https://github.com/snapcore/snapd/pull/3715/commits/3948b14c51f62f5c806a0b2ede6a50e94ecd01e7
[12:38] <mup> PR snapd#3715: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3715>
[12:38] <popey> ogra_: I'm happy we're moving forward :)
[12:39] <jdstrand> zyga: I submitted the PR with 'r' for ieee80211 but meant to use 'rw'. I re-read the commit and noticed I wanted to fix a comment and to actually make ieee80211 rw
[12:39] <ogra_> yeah, me too ... i'm also looking into getting USB-OTG to work, then you can actually run the serial connection through the power cable ;)
[12:39] <ogra_> no more extra cable needed for initial setup
[12:39] <zyga> ah
[12:39] <zyga> makes sense
[12:39] <jdstrand> zyga: (if you notice the original commit message for ieee80211, it very clearly says it should be rw
[12:39] <popey> ooh, that would be awesome
[12:43] <ogra_> hmm ... why does it look for brcmfmac43430-sdio.txt ... we actually ship brcmfmac43430-sdio.bin already
[12:43]  * ogra_ wonders if a simple symlink would do 
[12:47] <zyga> afk, see you at the call
[13:11] <sgclark> Hi, silly me registered a bunch of kde apps under a personal account how do I fix it to use our kde account? :(
[13:11] <sgclark> in ubuntu store
[13:19] <popey> sgclark: heh, we can move them.
[13:19] <zyga> Pharaoh_Atem: hey
[13:19] <zyga>   Cannot download d/distribution-gpg-keys-1.12-1.fc25.noarch.rpm: All mirrors were tried
[13:20] <zyga> does that say we are on stale cache
[13:20] <zyga> and need dnf refresh
[13:20] <zyga> or that we are SOL
[13:20] <sgclark> popey: that would be lovely, thanks
[13:20]  * zyga boots F26
[13:22] <popey> sgclark: do you have a list of the ones you want moved over? Want to drop me a mail with them in? alan.pope@canonical.com and I will forward to the store people as it's a manual process I believe
[13:23] <sgclark> popey: I will email you, thankfully it wasn't a terribly long list. Thanks again.
[13:23] <popey> no problem, easily done
[13:37] <zyga-suse> not sure if it is btrfs or something else but "go test" in overlord uses 10MB/s of disk all the time
[13:37] <zyga-suse> while on ext4 I don't see that
[13:38] <zyga-suse> (I see rouhgly 1MB there)
[13:38] <zyga-suse> Chipaca: if it turns out to be those atomic file write things would you mind if I disable that for testing?
[13:39] <Chipaca> zyga-suse: i'm not sure if libeatmydata will work with go
[13:39] <Chipaca> zyga-suse: but feel free to tweak the code to give it a try
[13:40] <Chipaca> zyga-suse: however.......... i'll -1 a patch to actually do this
[13:40] <Chipaca> zyga-suse: if you understand what i mean
[13:41] <zyga-suse> Chipaca: mmm, eatmydata uses preloads wich won't work here
[13:41] <Chipaca> yeah
[13:41] <zyga-suse> Chipaca: if you'd -1 the patch then won't bother
[13:41] <Chipaca> zyga-suse: but do it locally to answer the question
[13:41] <Chipaca> zyga-suse: my opinions evolve with data, so get me data ;-)
[13:43] <zyga-suse> ha, very good answer
[13:44] <zyga-suse> OMG
[13:44] <zyga-suse> Chipaca: so with that thing disabled daemon tests run in ...3s
[13:44] <zyga-suse> so 100 fold better
[13:45] <zyga-suse> Chipaca: overlord tests finish in just 9 seconds
[13:47] <popey> jdstrand: do we have documented somewhere the steps needed to fiddle with aa rules in /var/lib/snapd/apparmor and then refresh aa? I have been googling but can't find a good guide
[13:47] <zyga> Pharaoh_Atem: question, what is "dnf reposync" good for, this literally *synchronizes the whole repo over to local disk*
[13:47] <zyga> Pharaoh_Atem: is that how one runs a mirror?
[13:48] <zyga-suse> Chipaca: vs minutes (still running)
[13:48] <kyrofa> popey, believe it or not, I can help you with that
[13:48] <Chipaca> zyga: and in a system with a non-insane filesystem
[13:48] <Chipaca> ?
[13:48] <zyga-suse> Chipaca: one sec
[13:48] <jdstrand> popey: https://forum.snapcraft.io/t/security-policy-and-sandboxing/554
[13:48] <jdstrand> I should update that for bpf
[13:48]  * jdstrand does so now
[13:49] <zyga-suse> Chipaca: on ext4 on artful, with the same patch I go down from 71 seconds to 5 seconds
[13:49] <kyrofa> jdstrand, that deserves to be much more discoverable than in the forum, IMO
[13:49] <zyga-suse> Chipaca: that's an insane win
[13:49] <zyga-suse> kyrofa: just blog about it and link to it :)
[13:50] <kyrofa> Haha
[13:50] <zyga-suse> Chipaca: so, are you interested in the patch now? :D
[13:50] <jdstrand> kyrofa: it was in the wiki and niemeyer thought it would be best in the forum. Note, it is primarily useful to interface developers
[13:50] <zyga-suse> this could cut the needless IO for testing
[13:50] <zyga-suse> and speed up cycles tremendously
[13:50] <ikey> sounds like fsync/sync woes?
[13:50] <zyga-suse> I'll give you tree-wide numbers
[13:50] <popey> jdstrand: i found that one, but the bit that's missing is how I refresh the apparmor rules after editing those files
[13:50] <zyga-suse> ikey: yes, exactly
[13:51] <popey> oh, found it :)
[13:51] <ikey> aka "why rpm is slow" ..
[13:51] <zyga-suse> Chipaca: on btrfs without this overlord tests take 139s
[13:51] <zyga-suse> Chipaca: so 139 vs 9
[13:52] <niemeyer> kyrofa: Ironically, the reason it's in the forum is precisely so it is visible
[13:52] <niemeyer> (cc jdstrand)
[13:52] <zyga-suse> ikey: hehe
[13:53] <Chipaca> zyga-suse: ok, less opposed to it now
[13:53] <Chipaca> zyga-suse: 70 to 5 is still impressive enough for me :-) what about spread tests?
[13:53] <Chipaca> bah
[13:53] <Chipaca> wait
[13:54] <zyga-suse> Chipaca: didn't try them yet
[13:54] <zyga-suse> Chipaca: but if we set this via environment
[13:54] <Chipaca> some of the spread tests failed because we weren't syncing in the right places
[13:54] <zyga-suse> Chipaca: we can nicely measure
[13:54] <pedronis> also do we really want to turn that off in spread tests?
[13:54] <zyga-suse> pedronis: not sure, perhaps, this is only there in case the machine crashes hard
[13:54] <Chipaca> so we need to be really careful about which ones we turn it off for. Not a blanket turn-it-off thing for spread.
[13:54] <zyga-suse> pedronis: the code is correct if we don't yank the power cable
[13:55] <zyga-suse> Chipaca: I'm talking about dir.Sync and fd.Sync calls
[13:55] <pedronis> anyway as Chipaca said it needs to be something we decide suite by suite and test and by tests
[13:55] <Chipaca> zyga-suse: the bootloeader code got into trouble without the syncs iirc
[13:55] <zyga-suse> Chipaca: why?
[13:55] <Chipaca> zyga-suse: garbage in the bootloader conf file on reboot
[13:55] <zyga-suse> Chipaca: do we unmount the /boot partition?
[13:55] <zyga-suse> if we see garbage then it feels like another bug
[13:56] <Chipaca> zyga-suse: this might've been when we remounted it ro
[13:56] <zyga-suse> because none of the sync calls are mandatory if you unmount the fileysystem
[13:56] <zyga-suse> not sure I follow that part, I don't know this code
[13:56] <zyga-suse> but still, overall it feels like TRTTD in tests
[13:57] <Chipaca> zyga-suse: integration-y stuff, for now we might want to not touch sync for core devices (the rest should be fine, and if not we learn)
[13:57] <Chipaca> zyga-suse: but, i'm still concerned so let's see your patch first
[13:58] <zyga-suse> ok
[13:58] <ikey> zyga-suse, https://dev.solus-project.com/R3571:43c64241912cc3bfc35a4299097e82b00e1f2cd6
[13:58] <ikey> >_>
[13:59] <ikey> we haz matching apparmors :3
[13:59] <zyga> woot
[13:59] <zyga> jjohansen1: ^^
[13:59] <zyga> can you please have a look
[13:59] <mup> PR snapcraft#1478 closed: Add cx_Freeze options targeting bin/snapcraft <Created by alextnewman> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1478>
[13:59] <ikey> i nicked http://kernel.ubuntu.com/git/ubuntu/ubuntu-artful.git/tree/security/apparmor?h=master-next
[13:59] <ikey> and then ported securityfs bits
[14:00] <zyga> ikey: do you have confinement "strict" now?
[14:00] <zyga> according to snapd?
[14:01] <ikey> im using nvidia gpu so i need to wait for repo kernel build + nvidia drivers to be published
[14:01] <ikey> nouveau doesnt support my GPU :P
[14:01] <ikey> so we'll find out in a bit
[14:01] <zyga> OK
[14:01] <ikey> i booted it headless and confirmed that the correct features showed in the sysfs
[14:02] <ikey> and that yknow, it actually booted..
[14:02] <ikey> unlike attempt 1..
[14:03] <ikey> is this the part where i make the joke about the solus and ubuntu kernels converging or is it too soon? :3
[14:03]  * ikey ducks
[14:04] <zyga> hahah
[14:04] <zyga> convergence ^_^
[14:04] <jdstrand> popey: it is in there (see Tips and Debugging)
[14:05] <jdstrand> and I updated it for seccomp-bpf as well (which now needs something akin to apparmor_parser (ie, snap-seccomp))
[14:07]  * zyga melts at 33C in warsaw now
[14:19] <roadmr> jdstrand: hey! tools r896  is now live in production
[14:24]  * zyga eats lunch slowly
[14:24] <zyga> mvo: do you mind if I pull in jdstrand's patch into opensuse and skip 2.27.1 tarball
[14:25] <Pharaoh_Atem> zyga: that requires metadata refresh
[14:25] <zyga> ikey: you want to pull in https://github.com/snapcore/snapd/pull/3715 as a patch on top of 2.27 as well
[14:25] <mup> PR snapd#3715: interfaces/misc: updates for unity7/x11 (LP: #1663221), browser-support, network-control (LP: #1679295) and mount-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3715>
[14:25] <zyga> Pharaoh_Atem: right, my thoughts exactly
[14:25] <mvo> zyga: works for me
[14:25] <zyga> nice
[14:25] <zyga> I may finish the week with something done
[14:26] <ikey> ah yeah i need to rebase my snapd
[14:26] <ikey> thanks
[14:26] <Pharaoh_Atem> zyga: so are we getting a 2.27.1 or do I need to pull a patch in?
[14:26] <Pharaoh_Atem> zyga: reposync lets you quickly make a local mirror, I believe
[14:26] <zyga> Pharaoh_Atem: we are getting both probably but I think you just need a patch
[14:26] <zyga> Pharaoh_Atem: have you used it, is it something I could keep at home
[14:27] <mup> PR snapd#3718 opened: tests: enable regression and completion suites for opensuse <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3718>
[14:27] <Pharaoh_Atem> zyga: I have not used it
[14:27] <Pharaoh_Atem> zyga: http://dnf-plugins-core.readthedocs.io/en/latest/reposync.html
[14:27] <Pharaoh_Atem> but I don't see why it couldn't work
[14:28] <zyga> Pharaoh_Atem: btw, so are we missing a dnf makecache call somewhere?
[14:28] <Pharaoh_Atem> zyga: yeah, you guys took it out entirely
[14:28] <arm1e> hey zyga-suse, back to try the iplayer snap for a bit
[14:28] <zyga> Pharaoh_Atem: aha, let me fix it then
[14:30] <zyga> Pharaoh_Atem: hmm, we *do* call "dnf makecache"
[14:31] <Pharaoh_Atem> hmm, maybe you need to add it to more places
[14:31] <Pharaoh_Atem> you probably took out --refresh
[14:31] <zyga> hmm, tell me about refresh
[14:32] <Pharaoh_Atem> dnf --refresh install forces metadata refresh before installing requested packages
[14:32]  * zyga curses at insane alt-tab behavior
[14:32] <zyga> is that what make cache also doesw?
[14:32] <zyga> we use dnf makecache in all the places we apt-get updated
[14:32] <Pharaoh_Atem> yes
[14:32] <Pharaoh_Atem> dnf makecache == apt update
[14:33] <zyga> hm, so something else is faulty
[14:33] <zyga> I'll have to reproduce this
[14:33] <Pharaoh_Atem> you've probably got the fault in all of them
[14:33] <Pharaoh_Atem> but you'll notice more on Fedora due to churn
[14:34] <zyga> people say that all the tests are red because of this on spread + fedora
[14:34] <zyga> so I want to see
[14:35]  * zyga wonders what is https://people.freedesktop.org/~mak/limba/
[14:36] <ikey> zyga, was https://github.com/ximion/limba
[14:36] <Pharaoh_Atem> that's ximion's project that predates flatpak and snap but had aspects of both
[14:36] <ikey> went the glick2 route
[14:36] <zyga> wow, this just gets better and better
[14:37] <zyga> maybe apart from maintaining snapd I will do a hobby weekend project that does another bundle format
[14:37] <ogra_> just merge support for them into snapd instead :P
[14:37] <ikey> lol
[14:37] <Pharaoh_Atem> haha
[14:37] <Pharaoh_Atem> let's not and say we didn't
[14:38] <zyga> I'll call my system flatpumbasnaptik
[14:38] <arm1e> zyga: you missed eopkg
[14:38] <zyga> and you will need to have it to install it
[14:38] <zyga> nothing like self-hosting
[14:38]  * ikey has every right to call his flatpak + snap system ikea.
[14:38] <zyga> lol
[14:38] <Pharaoh_Atem> mrrr
[14:39] <ikey> would explain having a few screws loose.. :p
[14:39] <arm1e> lol
[14:40]  * ogra_ would be more subtle and call it "Merkel" (her concept is to just swallow the programs of her opponents, thats why she wins all the time) 
[14:40] <zyga> ogra_: we'd probably have to go with "makrela" though
[14:40] <ogra_> haha
[14:40]  * zyga recalls "quality crap from pikea" from futurama
[14:40] <ogra_> ha
[14:41] <cachio> niemeyer, I saw this https://paste.ubuntu.com/25290471/
[14:41] <cachio> on linode
[14:42] <cachio> do you know what could be causing that?
[14:43] <zyga> cachio: we are bus
[14:43] <zyga> cachio: ran out of machines
[14:44] <cachio> zyga, ok
[14:44] <cachio> tx
[14:44] <arm1e> how can I find out where an ubuntu package (from repo) has installed its files (so that I can copy them into my snap)
[14:45] <zyga> arm1e: dpkg -L pkg
[14:45] <ikey> no wajig love?
[14:45] <ogra_> arm1e, you just list the packages of which you want the content in stage-packages
[14:46] <ogra_> arm1e, that will make sure they end up under $SNAP
[14:46] <ogra_> no need to copy around anything
[14:49] <ogra_> cjwatson, oh ! ... i just noticed "Revision" on my LP build details for a snap ... is that new ?  (thoough why is the revision showing 3 correctly on https://code.launchpad.net/~ogra/+snap/linux-generic-allwinner/+build/67084 but shows some hash on https://code.launchpad.net/~snappy-dev/+snap/core/+build/66911
[14:50] <ogra_> )
[14:54] <ikey> so um
[14:54] <ikey> tada https://ibin.co/3WWRyaQcdv5A.png
[14:54] <pedronis> zyga-suse: do we know what's the fedora problem?
[14:54] <ogra_> ogra@nanopi:~$ snap refresh linux-generic-allwinner
[14:54] <ogra_> error: cannot perform the following tasks:
[14:54] <ogra_> - Mount snap "linux-generic-allwinner" (3) ([daemon-reload] failed with exit status 1: Failed to execute operation: Connection timed out
[14:54] <ogra_> )
[14:54] <ogra_> WOAH!
[14:56] <zyga> pedronis: no, not yet
[14:56] <zyga> pedronis: I'm checking still
[14:56] <zyga> pedronis: we apparently do the right thing :/
[14:58] <arm1e> ogra_: so, I am trying to build get-iplayer and have installed it onto my host via a ppa. I already have stage packages for run dependencies, but are you saying i simply include get-iplayer too?
[14:58] <pedronis> shoudl we turn off the fedora suite until we understand?
[14:58] <pedronis> zyga-suse: it's a bit blocking anything atm
[14:58] <zyga> I know, working on it
[14:59] <zyga> hmm, not sure, are you in a rush to land something today?
[14:59] <pedronis> always
[15:00] <ogra_> arm1e, get-iplayer is simply a perl script, use the git tree in your source: entry and have it download the git ... then use some way to copy the get-iplayer script into your snap either via the dump plugin or through an install script snippet in snapcraft.yaml
[15:00]  * zyga moves to a colder room
[15:00] <zyga> 35C
[15:00] <pedronis> it's rainy here
[15:01] <arm1e> ogra_: woah, woah .... slow down
[15:01] <zyga> man I envy you so much
[15:01] <ogra_> yeah, rainy and cold here too
[15:01] <ikey> heh
[15:01] <ogra_> that moves east though ... you shoudl have it on the weekend
[15:01] <pedronis> zyga: it's a question if I'm in a rush or not, but blocked landings are always bad
[15:02] <pedronis> I suppose because 27.1 probably 2.28 is a  bit delayed?
[15:02] <ikey> hoping to get my solus changes for snapd PR'd today - assuming i make sufficient progress here that stuff works ™
[15:06] <zyga-suse> ikey: thank you, looking forward to it
[15:07] <zyga-suse> pedronis: I think 27.1 next week because we cannot release on Fridays
[15:07] <ikey> the hard bit is done now really zyga-suse
[15:07] <ikey> i have strict confinement
[15:07] <pedronis> that was not my question
[15:07] <pedronis> anyway
[15:07] <zyga-suse> ikey: you have no idea how happy I am about that
[15:07] <ikey> lol
[15:07] <zyga-suse> pedronis: I think the 2.28 schedule can stay unchanged
[15:07] <arm1e> ogra_: I have the git repo in the source and had the dump plugin selected but not sure how to use the install snippet
[15:07] <zyga-suse> pedronis: those are separate releases after all
[15:07] <zyga-suse> pedronis: but this is mvo's call
[15:07] <ikey> correct me if im wrong but i believe solus is the only other !buntu that has strict confinement..?
[15:07]  * ikey is thinking in marketeering terms :p
[15:08] <mup> PR snapd#3719 opened: interfaces: add new desktop and desktop-accessibility <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3719>
[15:08] <zyga-suse> ikey: yes
[15:08] <zyga-suse> ikey: that was exactly what I was thinking about
[15:08] <ikey> blogposting intensifies
[15:08] <kyrofa> ikey, oooo, indeed
[15:09] <ikey> for spite/brownie points ill also enable the linux-lts kernel..
[15:09] <ikey> lol
[15:10] <ikey> (not today though because im not that mental)
[15:10] <zyga-suse> jdstrand: should all UI snaps use the desktop plug?
[15:11] <ogra_> arm1e, http://paste.ubuntu.com/25290638/ like this ...
[15:11] <kyrofa> We have a desktop plug now?
[15:11] <mvo> zyga-suse: I look at 2.27.1 in a wee bit, just finishing some bits around the new ensureCore code
[15:12] <zyga-suse> mvo: k
[15:12] <zyga-suse> jdstrand: reviewed
[15:15] <nacc> arm1e: did you get your questions answered?
[15:15] <tpatel> auto-connection plug-slot issue
[15:17] <zyga-suse> tpatel: ?
[15:17] <tpatel> I have a snap which exposes a slot (socket-server) for snap-2 and has a plug(client-control) to be connected to snap-3. At install time I'm seeing snap-1:socket-server is autoconnected to snap-1:client-control. Is this is snapd BUG?
[15:18] <zyga-suse> what are socket-server and client-control?
[15:18] <zyga-suse> and which interface is that
[15:18] <tpatel> they are sockets
[15:19] <arm1e> hey nacc, think so. There is a lot to learn, bt I did read all of the stuff you linked last night. Very helpful thanks
[15:19] <flavianmanea>  Hello, I am having some issues on snapd, mainly, I was trying to build some rpms with snapd (https://snapcraft.io/docs/core/install-oe-yocto), to install them on MinnowBoard Max - Pulsar8. I have builded succesfully the packages, but there is a dependency in the snapd.rpm that I couldn't figure it out, and that is "kernel-module-squashfs", I couldn't figure it out if this should be present already in the kernel, or if there is
[15:19] <ogra_> what interface type did you use for them ?
[15:19] <arm1e> ogra_: will try that now, thanks
[15:19] <zyga-suse> tpatel: which snapd interface are those?
[15:19] <nacc> arm1e: yw
[15:19] <tpatel> zyga-suse: these are not snapd-core interface.
[15:19] <zyga-suse> flavianmanea: this is something for morphis__
[15:20] <zyga-suse> tpatel: ok, what kind of plugs are socket-server and client-control, I still don't get what the problem is
[15:20] <ogra_> flavianmanea, snap packages are squashfs files, so to make use of them you need squashfs support in your kernel (either via module or builtin)
[15:21] <jdstrand> zyga-suse: responded in the PR, but please see the accompanying forum topic
[15:21] <morphis__> flavianmanea: if your kernel has squashfs support build in rather than as a module you could drop that dependency
[15:21] <tpatel> socket-server is a slot name, client-control is a name of snap-3 slot which snap-1 needs to connect to.
[15:21] <zyga-suse> jdstrand: thank you
[15:21] <zyga-suse> tpatel: ok, slots and plugs have interface *types*, which types are you using there
[15:21] <zyga-suse> tpatel: the plug/slot names are arbitrary and irrelevant
[15:22] <zyga-suse> tpatel: the only thing that matters is the type of each of those
[15:22] <tpatel> this are content type
[15:22] <zyga-suse> aha
[15:22] <zyga-suse> ok
[15:22] <zyga-suse> did you define the "content" attribute on them?
[15:22] <tpatel> yes
[15:22] <zyga-suse> ok
[15:22] <zyga-suse> is it the same in both?
[15:23] <tpatel> yes. here is snapshot from .yaml file
[15:23] <tpatel> plugs:     #connect to slot provided by wifi-ap and use api to communicate     control:         content: socket-directory         interface: content         target: $SNAP_DATA/sockets         default-provider: wifi-ap  slots:     entouch-srvr:         content: socket-directory         interface: content         write:             - $SNAP_DATA/socks
[15:23] <ogra_> heh
[15:23] <zyga-suse> tpatel: perhaps pastebin that
[15:23] <ogra_> yeah ...
[15:23] <zyga-suse> it's hard to read this way
[15:23]  * ogra_ recommends paste.ubuntu.com
[15:24] <tpatel> zyga-suse: sorry this is my first time using this chat so not familiar with all the lingo. what is pastebin?
[15:24] <zyga-suse> tpatel: that's fine, it is a service that you can use to paste stuff into irc with nicer effects
[15:25] <ogra_> tpatel, http://paste.ubuntu.com/
[15:25] <zyga-suse> tpatel: go to paste.ubuntu.com and copy your stuff there
[15:25] <zyga-suse> submit that
[15:25] <zyga-suse> and give us a link
[15:25] <ogra_> and give us the resulting url
[15:26] <ikey> cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_qJM9hP//lib/modules: Permission denied
[15:26] <tpatel> heres ithe link http://paste.ubuntu.com/25290702/
[15:26] <ikey> soo close
[15:26] <flavianmanea> @morphis__: I see that I have under /usr/sbin - unsquashfs and mksquashfs (And I guess that I already have them installed, so I can drop this dependency). Thank you!
[15:26] <nothal_> flavianmanea: No such command!
[15:27] <zyga-suse> ikey: maybe missing mount mediation or more directory differences, not sure
[15:27] <ogra_> flavianmanea, no, you want to check /proc/filesystems
[15:27] <arm1e> ogra_: holy crap it might have worked
[15:28] <arm1e> seems to have built
[15:28] <ogra_> flavianmanea, the tools in /usr/bin are just the userspace tools, not the kernel bits
[15:28] <tpatel> zyga-suse: as you can see in this http://paste.ubuntu.com/25290702/ link there is entouch-srvr slot which is auto-connected to plug control. I dont want that to happen
[15:28] <zyga-suse> tpatel: are those on the same snap?
[15:28] <ogra_> flavianmanea, grep squash /proc/filesystems ... if that returns "squashfs" you are fine
[15:29] <ogra_> ogra@nanopi:~$ grep squash /proc/filesystems
[15:29] <ogra_> 	squashfs
[15:29] <ogra_> ogra@nanopi:~$
[15:29] <ogra_> like this
[15:29] <mup> PR snapcraft#1481 opened: cli: better error message for missing mksquashfs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1481>
[15:30] <arm1e> gotta go but will be back later. Thanks again!!
[15:30] <flavianmanea> Bad luck on my side, it seems that no squashfs pops up
[15:30] <tpatel> zyga-suse: Yes, they are defined in same snap. But plug control is needed to connect to slot wifi-ap:control and not to :entouch-srvr
[15:30] <ogra_> flavianmanea, then you want to build the kernel module
[15:30] <zyga-suse> tpatel: could you call them something else then, give them different content attribute?
[15:31] <ikey> cannot mount tmpfs at /tmp/snap.rootfs_2R3Okt/var/lib/snapd/lib/gl: Permission denied
[15:31] <ikey> lol the nvidia arch stuff is falling apart :p
[15:31] <tpatel> I do have them with different name.
[15:32] <zyga-suse> tpatel: I mean different content attribute name
[15:32] <zyga-suse> ikey: you can do a quick "broad fix" to allow arbitrary mount
[15:32] <zyga-suse> ikey: the apparmor rule is just "mount," AFAIR
[15:32] <zyga-suse> (for snap-confine)
[15:32] <ogra_> ikey, is your snap-confine suid root ?
[15:32] <ikey> ya
[15:33] <tpatel> zyga-suse: Can you send me a link where I can find other content type
[15:33] <zyga-suse> ogra_: it is, this is apparmor getting in the way
[15:33] <ogra_> ah
[15:33] <ogra_> evil apparmor
[15:33] <zyga-suse> tpatel: content type is just a string
[15:33] <ikey> is there another permission for remount>?
[15:33] <zyga-suse> tpatel: you can call it whatever you want
[15:33] <zyga-suse> ikey: remount? no I don't think so
[15:33] <ikey> cannot remount /tmp/snap.rootfs_wE0ycY/var/lib/snapd/lib/gl as read-only: Permission denied
[15:33] <tpatel> zyga-suse: Ok. Let me try that.
[15:33] <ikey> lol
[15:33] <tpatel> zyga-suse: thanks
[15:34] <zyga-suse> ikey: hmm
[15:36] <ikey>     mount fstype=tmpfs none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,
[15:36] <ikey>     mount options=(remount,ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/gl/,
[15:36] <ikey> made it "go"
[15:37] <ikey> but now my libGL is broken
[15:37] <ikey> and wasnt in 2.26
[15:37] <flavianmanea> Thanks guys for your help, gotta run. bye
[15:38] <ikey> it wasnt trying to mount a tmpfs there before so i wonder if its actually bork
[15:41] <mup> PR snapd#3713 closed: osutil: ensure TestLockUnlockWorks uses supported flock <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3713>
[15:42] <mvo> jdstrand: can I get a minimal version of 3715 for 2.27? or is all of it needed?
[15:43] <mvo> jdstrand: if we need it all, then thats fine, we just need to make sure to squash merge it so that the cherry pick to 2.27 is easier
[15:44] <mvo> zyga-suse: looks like fedora is still in an unhappy state, anything new here? can't land the 2.27.1 prs currently it seems
[15:45] <ikey> bash-4.3$ ls -la
[15:45] <ikey> ls: cannot open directory '.': Permission denied
[15:45] <ikey> bash-4.3$
[15:45] <ikey> ugh
[15:46] <ogra_> WOW ... so playing with libcomposite on a board can actually hard-kill systemd
[15:46]  * ogra_ wants upstart back ... sniff
[15:47] <mup> PR snapcraft#1482 opened: ci: skip the CLA check for pull requests from the bot <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1482>
[15:47] <ikey> so all my --shell's now have no read permissions..
[15:48] <zyga-suse> mvo: hmm, noop
[15:48] <zyga-suse> ikey: pwd?
[15:49] <ikey> bash-4.3$ cd /
[15:49] <ikey> bash-4.3$ ls
[15:49] <ikey> ls: cannot open directory '.': Permission denied
[15:49] <ikey> bash-4.3$
[15:49] <zyga-suse> ikey: that is correct
[15:49] <zyga-suse> ikey: so far at least
[15:49] <zyga-suse> ikey: cd $HOME
[15:49] <ikey> so why have a shell that cant read or do anything..?
[15:49] <zyga-suse> ikey: it can, it depends on the path obviously
[15:49] <ikey> oh its stuck to home.. gotcha
[15:49] <ikey> ok so my "libGL no longer works" issue is still there :/
[15:49] <zyga-suse> ikey: any apparmor denials?
[15:50] <zyga-suse> ikey: I suspect you will need to open up a lot of stuff in /var/lib/snapd/hostfs/ to allow the userspace distro driver to load
[15:50] <ikey> Aug 11 16:49:59 ironhide love[6211]: <audit-1400> apparmor="DENIED" operation="open" profile="snap.mrrescue.mrrescue" name="/var/lib/snapd/hostfs/usr/lib64/glx-provider/nvidia/libGL.so.384.59" pid=6211 comm="love" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[15:50] <ikey> ah.
[15:50] <ikey> cuz solus is weird.
[15:50] <ikey> and symlinks resolve
[15:50] <ikey> merci :P
[15:50] <zyga-suse> yes
[15:50] <zyga-suse> should be easy-ishj
[15:50] <ikey> damn solus xD
[15:50] <mup> PR snapcraft#1483 opened: lxd: path cannot have extra forward slashes <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1483>
[15:50] <zyga-suse> mvo: no idea what is going on, running some experiments again
[15:50] <ogra_> ikey, just switch to slackware
[15:51] <ikey> k done
[15:51]  * ikey is on slackware
[15:51] <ogra_> hah
[15:51] <zyga-suse> ikey: NOTE
[15:51] <zyga-suse> ikey: those things you are experiencing now
[15:51] <zyga-suse> ikey: those need to be patched in interfaces/builtin/opengl.go
[15:51] <zyga-suse> ikey: not in snap-confine's location
[15:51] <ikey> o
[15:51] <zyga-suse> ikey: the profile applies to the snap "mrrescure"'s app called "mrrescue"
[15:52] <zyga-suse> ikey: if this snap uses the opengl plug
[15:52] <ikey> ooo i c it
[15:52] <zyga-suse> ikey: (it probably does)
[15:52] <zyga-suse> ikey: then those extra confinement features should be adjusted for that interface
[15:52] <ikey>   /var/lib/snapd/hostfs/usr/lib64/glx-provider/** rm,
[15:53] <ikey> looks legit
[15:53] <zyga-suse> yep
[15:53] <kalikiana> Saviq: Seems like you hit a LXD bug https://github.com/snapcore/snapcraft/pull/1483
[15:53] <mup> PR snapcraft#1483: lxd: path cannot have extra forward slashes <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1483>
[15:53] <ikey> interfaces are cool. :]
[15:54] <zyga-suse> :D
[15:54] <zyga-suse> indeed they are
[15:54] <zyga-suse> powerful concept
[15:54] <ikey> like they literally give permissions..
[15:54] <zyga-suse> yep
[15:54] <zyga-suse> they can do a few more things :)
[15:55] <tpatel> zyga-suse: same content-name was the issue.
[15:55] <zyga-suse> tyhicks: \o/
[15:55] <Saviq> kalikiana: hah, it did start working for me at one point after I've edited that out ;)
[15:56] <Saviq> just didn't pay attention enough to see that's what fixed it :)
[15:56] <zyga-suse> tpatel: \o/ :D
[15:56] <jdstrand> mvo: the only thing that is needed is the change to unity7/x11. the others should commit fine and would only help people
[15:56] <kalikiana> Saviq: you mean you changed the path yourself?
[15:57] <Saviq> yes via `lxc edit`
[15:57] <ogra_> popey, next attempt http://people.canonical.com/~ogra/snappy/nanopi-air.img.xz
[15:57] <jdstrand> mvo: they aren't strictly required, but only add more access (ie, won't regress)
[15:57] <ogra_> ogra@nanopi:~$ ls /snap/linux-generic-allwinner/5/firmware/brcm/*txt
[15:57] <ogra_> ogra@nanopi:~$
[15:57] <ogra_> bah
[15:57] <ogra_> /snap/linux-generic-allwinner/5/firmware/brcm/brcmfmac43430-sdio.txt
[15:57] <tpatel> how can I request auto-connection of core plugs like firewall-control, hardware-observe, network-control, ppp etc.
[15:57] <zyga-suse> tpatel: request an assertion from the store
[15:57] <zyga-suse> tpatel: I think you just have to add them
[15:57] <zyga-suse> tpatel: and then upload to the store
[15:57] <zyga-suse> and open a forum topic
[15:58] <kalikiana> Saviq: Ah, didn't even think of that. I've always used commands like 'lxc device add', and that breaks irrepairably here...
[15:58] <Saviq> kalikiana: yeah `lxc edit` is a good friend :D
[15:59] <tpatel> zyga-suse: i have snap-declaration.json file which has all the details about plugs, slots, refresh-control from which I created snap-declaration assert locally. How can i upload that?
[16:00] <zyga-suse> tpatel: you cannot, only store can do that
[16:00] <zyga-suse> tpatel: you cannot sign it specifically
[16:01] <zyga-suse> tpatel: please open a forum topic
[16:01] <kalikiana> Saviq: Maybe I should look into using it from Snapcraft as well so containers don't need to be re-created in cases like this. It seems it takes stdin as well
[16:01] <tpatel> zyga-suse: ok. I will open a forum topic
[16:02] <ikey> :o ..
[16:02] <ikey> https://ibin.co/3WWmTJWule4u.png
[16:02] <ogra_> play it !
[16:02] <ikey> oh i died already
[16:02] <ikey> lol
[16:02] <ogra_> lol
[16:03] <zyga-suse> ikey: any denials? :-)
[16:04] <ikey> Aug 11 17:00:32 ironhide love[1992]: <audit-1400> apparmor="DENIED" operation="open" profile="snap.mrrescue.mrrescue" name="/sys/devices/platform/i8042/serio2/input/input12/capabilities/ev" pid=1992 comm="love" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[16:04] <tpatel> zyga-suse: I dont see any option to request assertion from my store account. I have opened a forum https://forum.snapcraft.io/t/request-for-plug-auto-connection-on-et-gw/1651
[16:04] <ikey> quite a few denials but i can deal with those tomorrow ™
[16:05] <jdstrand> fyi, that denial is either a bug in the snap or the security policy, not your system
[16:05] <zyga-suse> tpatel: thank you!
[16:05] <ikey> yeah i figured
[16:05] <ikey> cheers though
[16:06] <ogra_> ikey, snap connect mrrescue:joystick
[16:06] <niemeyer> cachio: That just means machines are in use
[16:06] <ogra_> i guess
[16:06]  * ikey hasn't got a joysti..
[16:06] <ikey> i dont think?
[16:06] <cachio> niemeyer, ok
[16:06] <ogra_> nom but connecting the interface will likely make the denial go away
[16:07] <niemeyer> cachio: We have 29 machines powered off right now
[16:07] <niemeyer> That's enough for another full suite run
[16:07]  * zyga-suse steals one
[16:08] <zyga-suse> jdstrand: could those be missing/out-of-date abstractions?
[16:08] <cachio> niemeyer, good
[16:09] <cachio> zyga-suse, did you do any progress with the issue preparing fedora?
[16:10] <zyga-suse> cachio: no but I'm still actively trying
[16:10] <zyga-suse> cachio: trying more brute force now, maybe it will fix  it
[16:10] <cachio> zyga-suse, ok, tx
[16:11] <jdstrand> zyga-suse: not that denial, no
[16:11]  * jdstrand steps away for a bit
[16:11] <zyga-suse> aha, ok
[16:11] <zyga-suse> jdstrand: o/
[16:13] <Saviq> kalikiana: not sure, you'd have to mangle the string you get from lxc... IMO better to use the CLI and blame lxd for issues
[16:24] <zyga-suse> Pharaoh_Atem: around?
[16:26] <ikey> zyga-suse, how evil would it be to bind mount /usr/share/themes + /usr/share/icons into the target?
[16:28] <zyga-suse> ikey: mmmm, not sure, may be evil
[16:28] <zyga-suse> are you looking to adopt theming from the host?
[16:28] <ikey> basically yeah
[16:28] <zyga-suse> I'd rather not as we are working on a large and comprehensive theme support
[16:28] <zyga-suse> (~3-5 months out)
[16:28] <zyga-suse> and a simple approach won't really work
[16:29] <ikey> on the plus side, more complex apps are now working..
[16:29] <ikey> https://ibin.co/3WWs63sWMwix.png
[16:29] <zyga-suse> woah, really nice
[16:29] <zyga-suse> which app is that?
[16:29] <ikey> "brave" browser
[16:29] <ikey> only has --beta
[16:29] <zyga-suse> nice :D
[16:29] <zyga-suse> how do you like channels so far?
[16:29] <ikey> makes sense tbh
[16:30] <ikey> lets devs get feedback and stage features without hitting production systems
[16:30] <ikey> and the 1% to run bleeding edge
[16:34] <zyga-suse> ikey: if you are interested in that, try the http snap
[16:34] <zyga-suse> I think the beta channel has some tab completion features
[16:35] <ikey> installed it, whassit do?
[16:36] <zyga-suse> ikey: it's a simple debugger for http
[16:36] <zyga-suse> we use it to talk to snapd sometimes
[16:36] <zyga-suse> if you packaged bash tab completion correctly
[16:36] <zyga-suse> in bash
[16:36] <zyga-suse> you should get http -<tab><tab> to work
[16:36] <ikey> not yet and i dont use bash either
[16:36] <zyga-suse> aha
[16:36] <ikey> i also need to set up the environment file
[16:36] <zyga-suse> right I know that, just saying this is a part of the snapd package
[16:36] <zyga-suse> there are two files for that
[16:36] <ikey> should i just put /snap/bin into global PATH?
[16:36] <zyga-suse> or three, lost track
[16:36] <zyga-suse> yes, please
[16:36] <ikey> sweet
[16:37] <ikey> any XDG cruft..?
[16:37] <zyga-suse> yes
[16:37] <zyga-suse> look at ...
[16:37] <ikey> hello /var/lib/snapd/desktop/applications
[16:37] <ikey> ok ill include that into global xdg too
[16:37] <ikey> then we can have working menus..
[16:38] <ogra_> http://paste.ubuntu.com/25291252/
[16:38] <ogra_> thats what snapd ships in ubuntu
[16:38] <zyga-suse> I think this is a bit messy today but you want to set XDG_DATA_DIRS, grep for that in packaging/
[16:38] <zyga-suse> I think we need to streamline this a little
[16:38] <tpatel> Is there any pre-install script to we can run like configure which runs after install?
[16:38] <ikey> yeah we can do this in solus in /usr/share/defaults/etc/profile.d/someThingy.sh
[16:38] <zyga-suse> tpatel: yes
[16:39] <tpatel> zyga-suse: which one?
[16:39] <zyga-suse> tpatel: install, I believe :D
[16:39] <ShalokShalom> hi there
[16:39] <ShalokShalom> i have some questions
[16:39] <zyga-suse> ikey: that should (after logging out) give you working desktop files
[16:39] <ikey> noice
[16:39] <ShalokShalom> hi ikey :)
[16:39] <ikey> heya
[16:39] <tpatel> zyga-suse: should it be installed under hooks?
[16:39] <zyga-suse> mvo: so about fedora
[16:39] <ShalokShalom> So:
[16:39] <ogra_> ikey, profile.d is sourced by the display manager/ graphical session  in solus ??
[16:39] <ShalokShalom> Can apps get isolated, so they dont interference with each other?
[16:39] <zyga-suse> mvo: running a few times I sometimes just pass
[16:39] <ShalokShalom> Whats about sharing the ressources?
[16:39] <ikey> ogra_, the global is
[16:40] <ogra_> typically thats only for shell
[16:40] <zyga-suse> mvo: and sometimes fail on not being able to download a specific package
[16:40] <ikey> because lightdm is a twit
[16:40] <ikey> we have to make it source globally
[16:40] <ShalokShalom> I currently make a comparsion sheet of all the currently available package managers
[16:40] <ogra_> well, we dont have that in ubuntu ...
[16:40] <ikey> you guys dont know how to do vanilla :P
[16:40] <ikey> with all due respect xD
[16:40] <zyga-suse> ShalokShalom: can you be more specific please
[16:40] <ikey> and systemd janked up any possibility of puritan logins anyway.
[16:40] <ShalokShalom> in which context?
[16:40] <zyga-suse> ShalokShalom: normally each snap is isolated from all the other snaps
[16:41] <ShalokShalom> so, for which question?
[16:41] <ogra_> well, lightdm is an ubuntu invention ... if its not us doing "vanilla" who is ? :)
[16:41] <ShalokShalom> ok, fine
[16:41] <ikey> ogra_, nah - everything *around* it :P
[16:41] <ogra_> heh
[16:41] <ikey> dont make me point you at your packages
[16:41] <ikey> lol
[16:41] <ShalokShalom> and rollback is also supported, yeah?
[16:41] <ogra_> ikey, i dont care so much for packages anymore, i care for snaps nowadays ;)
[16:41] <zyga-suse> ShalokShalom: depending what you mean but we have a revert feature
[16:41] <ShalokShalom> so, can Snappy also produce artifacts, like traditional package managers?
[16:41] <ikey> they are packages
[16:41] <ikey> >_>
[16:42] <ogra_> well ... they are gold :)
[16:42]  * ikey meant that to ogra_ not ShalokShalom 
[16:42] <ShalokShalom> zyga-suse: i like to roll back to an old version of a package
[16:42] <zyga-suse> ShalokShalom: artifacts?
[16:42] <zyga-suse> ShalokShalom: I see
[16:42] <ShalokShalom> can it share ressources?
[16:42] <zyga-suse> ShalokShalom: if you are the developer of the snap you can refresh or rollback to any revision
[16:42] <zyga-suse> ShalokShalom: if you are not the developer of that snap you can only refresh or rollback to a revision you have on your system
[16:42] <ShalokShalom> so, if i use 2 snappy packages, doe they share ressources?
[16:43] <zyga-suse> ShalokShalom: which resources are you referring to?
[16:43] <zyga-suse> it's too vague to answer
[16:43] <ShalokShalom> zyga-suse: of course
[16:43] <ShalokShalom> i mean for stability reasons
[16:43] <zyga-suse> ShalokShalom: you can also refresh to any channel the developer has created
[16:43] <ShalokShalom> shared libs
[16:43] <zyga-suse> ShalokShalom: each snap shares its base snap (e.g. the base core snap)
[16:43]  * ikey contemplates making /usr/share/Xsession.d a thing
[16:43] <zyga-suse> ShalokShalom: but otherwise is standalone and does not share anything with other snaps or the system itself
[16:43] <ShalokShalom> i mean, when i use x for y and z
[16:44] <ShalokShalom> two loads of x in RAM?
[16:44] <zyga-suse> ShalokShalom: yes
[16:44] <ShalokShalom> so each snap loads all depends for itself?
[16:44] <zyga-suse> ShalokShalom: unless that is coming from the core snap
[16:44] <zyga-suse> ShalokShalom: so once filesystem
[16:44] <ShalokShalom> what is the core snap?
[16:44] <ogra_> well, or you use a content interface
[16:44] <zyga-suse> ShalokShalom: so one inode and one copy
[16:44] <ShalokShalom> in practice
[16:44] <zyga-suse> ShalokShalom: it's the snap that implicitly acts as the root filesystem of all the other snaps
[16:44] <ShalokShalom> you like to stand a full desktop on snappy?
[16:44] <zyga-suse> ShalokShalom: it contains a number of applications
[16:45] <ShalokShalom> aha
[16:45] <zyga-suse> ShalokShalom: and a number of libraries
[16:45] <zyga-suse> ShalokShalom: but is otherwise small and "embedded"ish
[16:45] <ShalokShalom> and can contains so much as it like?
[16:45] <ShalokShalom> so, can i build a full desktop on it?
[16:45] <zyga-suse> ShalokShalom: if you can package the whole desktop in a snap, yes
[16:45] <ogra_> if you are the developer of x y and z you can make y and z use libs from x via the content interface ... that ojnly works for the same developer though
[16:45] <zyga-suse> ultimately yes but it may not be easy
[16:46] <ikey> and arguably a desktop is part of the OS experience, and should be kept separate
[16:46] <ikey> OS/Data/Apps
[16:46] <ogra_> well
[16:46] <ogra_> depends
[16:46] <ikey> Unless you're hot into phablets.
[16:46] <zyga-suse> I think both viewpoints are valid
[16:46] <zyga-suse> yep
[16:46] <zyga-suse> ShalokShalom: I think currently nobody has attempted that AFAIK
[16:46] <ShalokShalom> ok i see
[16:47] <zyga-suse> ShalokShalom: but some desktop environment devs are experimenting with packaging more and more of their stack this way
[16:47]  * ogra_ could imagine an lxqt snap on top of mir-kiosk on an ubuntu core image ... 
[16:47] <ikey> inb4 snudgie.
[16:47] <ShalokShalom> do you agree with this list? http://funkyimg.com/i/2wjbr.png
[16:47] <ikey> me thinks them some loose misleading terms
[16:47] <ogra_> ShalokShalom, snaps use deltas
[16:48] <ShalokShalom> aha, ok fine
[16:48] <ShalokShalom> by default?
[16:48] <ogra_> not sure what "artifacts" are supposed to be
[16:48] <ikey> and you can get deltas on debian. its just external and weird
[16:48] <zyga-suse> ShalokShalom: sorry this is to vague to answer
[16:48] <ShalokShalom> no containers
[16:48] <zyga-suse> ShalokShalom: can you start with a legend that explains what you mean by each
[16:48] <ShalokShalom> its the opposite, like in traditional package managers
[16:48] <ogra_> ShalokShalom, depends ... on desktop and server installs by default, on ubuntu core images not
[16:48] <ShalokShalom> zyga-suse: yep, i think so too
[16:48] <ikey> this chart is kinda comparing apples and oranges
[16:48] <ShalokShalom> ikey: so practically no
[16:49] <ikey> snaps and traditional package managers have different uses
[16:49] <ShalokShalom> while its interesting to know, thank a lot
[16:49] <ShalokShalom> ikey: not for me
[16:49] <ShalokShalom> imho, both should be convered
[16:49] <ogra_> (ubuntu core is typically running on low power devices, so deltas are possibly eagting your CPU there)
[16:49] <ShalokShalom> Habitat can do it
[16:49] <ikey> well then you dont get it like i do :P
[16:49] <ikey> snaps basically means "i can run stuff outside the confines of the OS from the random internet and run it safely"
[16:49] <ogra_> *eating
[16:49] <ShalokShalom> yeah, probably ikey
[16:49] <ikey> OS doesnt break snap, snap doesnt break OS
[16:49] <ikey> snap can come from anywhere, and as such, is shielded
[16:49] <zyga-suse> ikey: yes, that's really key
[16:50] <ikey> package manager is very much a traditional OS deployment thing
[16:50] <zyga-suse> decoupling of the os from all the apps
[16:50] <ikey> i.e. glorified tarballs
[16:50] <ShalokShalom> ikey: Habitat means "i can run stuff outside the confines of the OS from the random internet and run it safely and as commonly known.
[16:50] <ShalokShalom> you can do both
[16:50] <ikey> why are you explaining back to me that which im explaining to you - given you've the questions, not the answers? :P
[16:50]  * ikey feels Friday has drawn to a close
[16:50] <ShalokShalom> ?
[16:50] <ShalokShalom> i expanded it
[16:50] <ShalokShalom> read the full line ;)
[16:51] <ikey> i cant english anymore, sorry. lol
[16:51] <ShalokShalom> all fine
[16:51]  * ikey disappears in the direction that doesn't have apparmor in it
[16:51] <ShalokShalom> any more important points, who make a package manager?
[16:51] <ShalokShalom> next to "easy to write build scripts"
[16:51] <ikey> (transactions)
[16:52] <ShalokShalom> in the sense of?
[16:52] <ogra_> ShalokShalom, take a look at snapcraft
[16:52] <ShalokShalom> ok
[16:52] <ShalokShalom> i was already there
[16:52] <ogra_> (regarding packaging)
[16:52] <ikey> i.e. applying a transactional upgrade, something goes boom, and its peeled off
[16:52] <ikey> RPM distros do this
[16:52] <ikey> (well the not insane ones)
[16:52] <zyga-suse> ikey: snapd also keeps a copy of app data
[16:52] <ikey> ((hi yocto.))
[16:52] <zyga-suse> ikey: so we can really undo everything
[16:52] <ikey> ah nice
[16:52] <ikey> just using hardlinks ?
[16:52] <zyga-suse> ikey: and transactions are waaaay faster because, well, we mount apps
[16:52] <ogra_> and auto-rollback :)
[16:52] <zyga-suse> ikey: no, we copy the old way for now
[16:52] <ogra_> dnt forget about that  :)
[16:52] <ikey> nice
[16:53] <zyga-suse> (though we may take advantage of some things later on)
[16:53] <ShalokShalom> can Snappy run standalone?
[16:53] <ikey> btw ive not looked at the snap format
[16:53] <ikey> is it deduped?
[16:53] <zyga-suse> ikey: we also have "data common across revisions" if app is willing to take the risk of managing itself
[16:53] <ogra_> ShalokShalom, standalone ??
[16:53] <ikey> ah nice
[16:53] <zyga-suse> ikey: not across snaps
[16:53] <ikey> nah internally
[16:53] <ShalokShalom> without any other package manager
[16:53] <ogra_> yes, that is what Ubuntu Core does
[16:53] <ikey> like are files deduplicated within a single snap
[16:53] <zyga-suse> ikey: internally I think squashfs does this but I don't think it's a very important feature since there's hardly any duplication in typical snap[s
[16:53] <ikey> gotcha
[16:53] <ogra_> on Ubuntu Core the kernel, bootloader and rootfs are snaps
[16:53] <zyga-suse> ikey: though don't quote me, I'd have to check
[16:54] <ikey> yeah no worries
[16:54] <zyga-suse> ikey: one interesting thing is that snaps are compressed
[16:54] <ogra_> there is no other package manager provided
[16:54] <ikey> iirc squashfs does poke the inodes themselves
[16:54] <zyga-suse> so they end up much smaller than typical package for both download and at runtime
[16:54] <ikey> zyga-suse, depends how you define "typical package"
[16:54] <ShalokShalom> host snappy all the infos about the apps in itself?
[16:54] <ShalokShalom> or is something in the OS?
[16:54] <ogra_> ShalokShalom,
[16:54] <ogra_> ogra@nanopi:~$ apt
[16:54] <ogra_> Ubuntu Core does not use apt-get, see 'snap --help'!
[16:54] <ogra_> ogra@nanopi:~$
[16:54] <ikey> the internals of all solus eopkgs are install.tar.xz which is basically the same as xz -6
[16:54] <zyga-suse> ikey: I didn't do any hard measurements but I would be surprised to win a lot on de-duping files that are not just copies
[16:55] <ShalokShalom> ogra_: and this is also suitable for a full blown OS?
[16:55] <zyga-suse> (not perfect copy)
[16:55] <ikey> problem is the deltas are a bit more tricky because of the install.tar.xz ...
[16:55] <ShalokShalom> what Ubuntu Core does
[16:55] <ShalokShalom> standalone PM
[16:55] <ikey> instead of a hash-indexed binary with stream compression which could dedupe and delta ...
[16:55] <zyga-suse> ikey: snapd uses several different deltas (we can add more later)
[16:55] <ikey> noice
[16:55] <zyga-suse> ikey: and once we get incremental builds, deltas will be even nicer
[16:55] <ogra_> ShalokShalom, sure, it is a product canonical makes money off :)
[16:55]  * ikey has poor-mans-deltas
[16:55] <ShalokShalom> which means?
[16:55] <zyga-suse> ikey: we also plan to use squashdelta for computing deltas that are aware of the squashfs compression
[16:55] <ShalokShalom> why poor-man?
[16:55] <ogra_> ShalokShalom, its a standalone OS
[16:56] <ikey> i.e. x->y = z(y[new])
[16:56] <ShalokShalom> because they cant effort bandwidth?
[16:56] <ikey> zyga-suse, ah handy enough yeah
[16:56] <ShalokShalom> ogra_: with a desktop and all?
[16:56] <zyga-suse> ikey: so really a lot of optimization can be done but it is not hard, just something we need to sit on and do
[16:56] <ogra_> ShalokShalom, no, for IoT and server use ... but you could snap up a desktop indeed
[16:56]  * ikey gets meta and snaps snapd
[16:56] <zyga-suse> ikey: that's done, it's in the core snap :D
[16:57] <popey> ogra_: testing!
[16:57] <ikey> lol yeah saw that
[16:57] <ogra_> ShalokShalom, think libreelec ... fritzos ... etc  ...
[16:57] <zyga-suse> ikey: and as we work on base snaps we will shrink the core snap to just contain snapd
[16:57] <zyga-suse> and move the base filesystem to a new base snap
[16:57] <zyga-suse> (or the other way around)
[16:57]  * ikey looks forward to having his own base snap :p
[16:57] <zyga-suse> but there will be separate snaps for base rootfs
[16:57] <zyga-suse> and for "just ship snapd"
[16:57] <ikey> oh btw do I gotta sell my soul (sign CLA) to send you PRs?
[16:57] <zyga-suse> ikey: yeah, you can kind of do that now
[16:57] <zyga-suse> ikey: just with master
[16:57] <ogra_> ShalokShalom, but as i said above already, technically you could package lxqt and run that on top of the mir-kiosk snap and have a full desktop
[16:58] <ogra_> practically nobody did that yet
[16:58] <zyga-suse> ikey: I think so, but if you send us tiny (trivial) PR I think we don't need a CLA legally
[16:58] <zyga-suse> but please sign it
[16:58] <zyga-suse> it's much easier for us
[16:58] <ikey> but my soul
[16:58] <ikey> lol
[16:58] <zyga-suse> we have cookies
[16:58] <ikey> well you do make a good argument
[16:58] <ogra_> yummy cookies
[16:59] <ikey> hm the CLA changed
[16:59]  * ikey remembers the old one
[16:59] <ogra_> ShalokShalom, the point of core is that it can not break ... (kernels, and rootfs updates do auto-selftests after upgrades and automatically roll back to the former working version etc ... such a device is always on and working)
[16:59] <ogra_> thats what snap packages provide us ...
[17:01] <ikey> how do i sign the magical web form xD
[17:01] <ogra_> use your wand
[17:01] <ogra_> :P
[17:01] <ikey> damn knew i left something at work
[17:01] <popey> ikey: you have the url?
 ikey: Habitat means "i can run stuff outside the confines of the OS from the random internet and run it safely and as commonly known.
[17:01] <ikey> yeah i got it downloaded
[17:02] <ogra_> ShalokShalom, snaps can do that as well ... we call that "classic snaps"
[17:02] <ShalokShalom> ok, fine
[17:02] <ShalokShalom> so its possible to create 'artifacts'
[17:02] <ikey> but unsurprisingly it turns out evince still sucks..
[17:02] <zyga-suse> hehe
[17:02] <ogra_> ShalokShalom, i have no idea what artifacts is supposed to mean
[17:02] <zyga-suse> well
[17:02] <ikey> and instead spent years of development energy on populating the titlebar until the point i cant move the damned window
[17:02] <ShalokShalom> classic snaps
[17:02] <zyga-suse> there are some very nice email clients in a snap I hear
[17:02] <ShalokShalom> so not containers
[17:03] <ShalokShalom> classic packaging
[17:03] <zyga-suse> ShalokShalom: can you define artefacts please
[17:03] <zyga-suse> ShalokShalom: incidentally we do have snaps that use classic (aka: none) confinement
[17:03] <ShalokShalom> see above
[17:03]  * ikey moves that we call them snackages
[17:03] <ShalokShalom> opposite of isolated containers
[17:03] <zyga-suse> ShalokShalom: that also don't run on top of the core snap
[17:03] <ShalokShalom> hehe
[17:03] <zyga-suse> ShalokShalom: but instead run on top of the distro itself
[17:03] <zyga-suse> ShalokShalom: atom is a very common one
[17:03]  * ogra_ takes a bite from ikey's snackage
[17:03] <ikey> lol
[17:03]  * zyga-suse wants a snack now
[17:03] <zyga-suse> darn you guys
[17:04] <zyga-suse> it's too hot to think and now I'm also hungry ;D
[17:04] <zyga-suse> ShalokShalom: as another interesting example, try my python0 snap
[17:04]  * ikey pleads the fifth
[17:04] <zyga-suse> ShalokShalom: it contains a very old version of python compiled as a classic snaps that I assert will work anywhere
[17:04] <zyga-suse> ShalokShalom: even though it sees the full extend of the host filesystem
[17:05] <ogra_> ShalokShalom, if you get a tarball with all libs included from an ISV and unpack that to /opt ... thats kind of similar to classic (just that the execution is still snandboxed but allows access to the host)
[17:05] <zyga-suse> ShalokShalom: and for distros like solus, where even the dynamic linker is in some unusual (sic) place, it works
[17:05] <zyga-suse> ogra_: very lightly sandboxed, apparmor is in allow anything mode and seccomp is off
[17:05] <zyga-suse> ShalokShalom: classic confinement is based on trust and good will of developers
[17:06] <zyga-suse> ShalokShalom: and is regulated by the store
[17:06] <ogra_> zyga-suse, sue, but it is still actually running inside the core snap
[17:06] <zyga-suse> ShalokShalom: nobody can just upload a snap like that and trick users into installing it
[17:06] <zyga-suse> ogra_: classic confinement snaps? no, they run on the real fs
[17:06] <ShalokShalom> "classic confinement is based on trust and good will of developers" > Oh, that will fail
[17:06] <ShalokShalom> That will SO fail :D
[17:06] <ogra_> doesnt
[17:06] <zyga-suse> ShalokShalom: it is *exactly* like a curated archive
[17:06] <ShalokShalom> just joking
[17:06] <zyga-suse> ShalokShalom: where we get most of our software today
[17:06] <ogra_> since it still needs a full security review on upload
[17:06] <ShalokShalom> yeah, i know
[17:06] <zyga-suse> ShalokShalom: just the format is different
[17:06] <ShalokShalom> thats what i mean
[17:07] <ShalokShalom> of course
[17:07] <ogra_> a "normal"" snap can always get auto-uploaded ... the interfaces shield the OS from everything evil it could do
[17:07] <ikey> hmph
[17:07] <ikey> edit pdf - text doesnt stay
[17:07] <ogra_> classic snaps azutomatically get blocked on upload until a human reviewer approves it
[17:08] <ogra_> (because they dont use the interface concept)
[17:08] <mup> PR snapcraft#1484 opened: lxd: configure user in container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1484>
[17:09] <jjohansen1> zyga-suse: hrmmm, that is unfortunate. artful is going to be moving to a 4.14 based version in a week or two
[17:09] <ikey> heh, meta. fill out in chrome, "print" to PDF..
[17:09] <zyga-suse> jjohansen1: hey!
[17:09] <zyga-suse> ikey: I think you want to sort out the kernel details with jjohansen1 now :)
[17:09] <zyga-suse> good to see you again jjohansen1 :)
[17:10] <jjohansen1> hey zyga
[17:10] <ikey> oh kernel is basically done :P
[17:10] <jjohansen1> zyga: so I did respond on the CONFIG Q, yesterday
[17:10] <ikey> 4.9 will be the next struggle..
[17:12] <popey> ogra_: http://imgur.com/a/yszdI :(
[17:12] <jjohansen1> ikey, nothing wrong with going with the zesty/current artful version however, artful is going to switch to a newer version based on 3.14 in a week or two is all
[17:12] <popey> http://imgur.com/a/OALxD
[17:12] <ikey> jjohansen1, ive taken from artful master-next
[17:13] <ikey> and i can rebase it in due course
[17:13] <ogra_> popey, well, you know the drill ... syslog please ... that kernel snap should definitely have the firmware now
[17:13] <jjohansen1> ikey: also, there is a backport tree, the 4.13 backport if currently at 4.10, if you wait a week or so, I will have a 4.9 backport done
[17:13] <popey> kk
[17:13] <ogra_> i was convinced it would work :(
[17:13] <ikey> so i looked at 4.13->4.12 backport which isnt complete
[17:13] <ikey> it only has the stuff going upstream
[17:13] <jjohansen1> ikey: yes I know, however the kt has an unstable tree, with 4.13 in it
[17:14] <jjohansen1> it will be switching to that for artful, and it will have some 4.14 patches, and possibly a couple others
[17:14] <ikey> ah ok
[17:14] <popey> Aug 11 11:00:11 localhost kernel: [   18.809931] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.txt failed with error -2
[17:15] <popey> ogra_: http://paste.ubuntu.com/25291548/
[17:15] <ogra_> boo
[17:15] <ikey> ok sent my soul attached to a PDF..
[17:17] <ogra_> popey, very weird i definitely have that file in linux-generic-allwinner rev 5 here (which this image should use)
[17:17] <ogra_> ogra@nanopi:~$ ls /snap/linux-generic-allwinner/5/firmware/brcm/*txt
[17:17] <ogra_> /snap/linux-generic-allwinner/5/firmware/brcm/brcmfmac43430-sdio.txt
[17:17] <ogra_> ogra@nanopi:~$
[17:18] <ogra_> OH!
[17:18] <ogra_> ogra@nanopi:~$ ls /lib/firmware/4.11.0-13-generic/brcm
[17:18] <ogra_> ls: cannot access '/lib/firmware/4.11.0-13-generic/brcm': No such file or directory
[17:18] <ogra_> ogra@nanopi:~$
[17:18] <ogra_> so the snap has it ...
[17:19] <ogra_> but something is wrong with the bind-mount to /lib/firmware
[17:19] <ikey> read permissions? :P
[17:20]  * ikey kids but is still partially traumatised by today.
[17:20] <ogra_> ah, no ... silly me
[17:20]  * ogra_ was looking one level to deep :P
[17:20] <ikey> lol
[17:20]  * ikey hands ogra_ https://www.youtube.com/watch?v=emGri7i8Y2Y
[17:21] <ogra_> heh
[17:21] <popey> ogra_: soooo, wait for a rebuild?
[17:21] <ogra_> popey, ls /writable/system-data/snap/linux-generic-allwinner/
[17:21] <popey> or do you mean you don't know yet what's busted?
[17:22] <ogra_> do you see a 5 in there ?
[17:22] <popey> no
[17:22] <popey> 2 and current
[17:22] <ogra_> i have the feeling you got the wrong kernel snap in that image (i hate that ubuntu-image doesnt print the versions when building)
[17:22] <ogra_> popey, oh, wow
[17:22] <ogra_> popey, thats what we tested this morning :O
[17:23]  * ogra_ re-builds the img ... will take a moment
[17:23] <popey> eeb3f8d53bd3e2a717a251944eb3a0fa  nanopi-air.img
[17:23] <popey> thats the most recent one I tested
[17:23] <popey> md5sum
[17:23] <popey> haaaaang on
[17:23] <popey> could be pilot error
[17:23] <zyga> so, I want a synergy snap please
[17:24] <zyga> but I think we need support for user session services first
[17:24] <zyga-suse> mvo: running fedora repeatedly I don't see the failure
[17:24] <mvo> zyga-suse: hm, let me rerun the test then
[17:24] <zyga-suse> mvo: so I'd say that something may be failing at the network level
[17:25] <zyga-suse> mvo: and not at the level of some stale cache
[17:25] <popey> wheee, dding again, wifey is gonna be late for dinner now :D
[17:25] <zyga-suse> mvo: still inconclusive though
[17:25] <zyga-suse> mvo: but yes, re-running might be a good idea
[17:25] <mvo> zyga-suse: maybe it was a hickup on their servers
[17:25] <zyga-suse> mvo: thank you for staying on Friday to work on this :)
[17:25] <mvo> zyga-suse: yeah, I want the 2.27 fixe
[17:25] <mvo> ss
[17:25] <zyga-suse> mvo: I saw it once
[17:25] <zyga-suse> and then I re-run (inside the debug shell)
[17:25] <zyga-suse> I re-run the same dnf install and it worked
[17:25] <zyga-suse> so :/
[17:26]  * zyga-suse wants 2.27.1 too :)
[17:26] <mvo> zyga-suse: ok, retriggered and will see how it goes
[17:26]  * mvo gets dinner
[17:26] <jdstrand> mvo: so do you want a cherrypick?
[17:26] <zyga-suse> fingers crossed
[17:26] <zyga-suse> I'm still running it in a loop
[17:26] <jdstrand> mvo: I don't think it is needed, but if you do, I'll do it
[17:27] <mvo> jdstrand: its fine, I can squash-merge and cherry pick the entire commit into 2.27
[17:27] <popey> ogra_: is this the smallest device so far to run ubuntu core?
[17:28] <popey> NDAs aside ;)
[17:28] <ogra_> popey, physical size wise, yeah
[17:28] <popey> nice
[17:28] <jdstrand> mvo: from my perspective, that is perfect
[17:28] <ogra_> regarding power the beaglebone is still the smallest
[17:28] <jdstrand> mvo: thanks! and sorry for not commiting that sooner
[17:28] <ogra_> (800MHz single core, 256M )
[17:29] <popey> scrolled back in console...
[17:29] <ahoneybun> and one know how to get LP to build a snap?
[17:29] <mvo> jdstrand: thanks, waiting for tests, then I will cherry pick
[17:29] <ahoneybun> I don't have the option here: https://launchpad.net/kubuntu-manual
[17:29] <popey> [   26.613572] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: May 27 2016 00:13:38 version 7.45.41.26 (r640327) FWID 01-df77e4a7
[17:29] <popey> [   26.642154] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
[17:29] <zyga-suse> ahoneybun: you can use a snap recipe
[17:29] <zyga-suse> ahoneybun: but many people just use build.snapcraft.io
[17:29] <mup> Issue snapcraft#1485 opened: Make script aware of 407 when downloading gradle <Created by koppor> <https://github.com/snapcore/snapcraft/issue/1485>
[17:30] <ogra_> ahoneybun, not in the toplevel, you need a source tree
[17:30] <ogra_> popey, oooh !
[17:30] <ogra_> popey, and console-conf ?
[17:30] <ahoneybun> ogra_: source tree?
[17:30] <popey> http://paste.ubuntu.com/25291629/
[17:30] <popey> lots of stuff whizzing by
[17:30] <ogra_> ahoneybun, yeah, something with a snapcraft.yaml
[17:30] <ahoneybun> https://git.launchpad.net/kubuntu-manual/tree/
[17:30] <ahoneybun> so I need a .yaml file for LP to see it as an option?
[17:31] <ogra_> popey, oh my
[17:31] <popey> yeah, can't see console-conf now
[17:31] <ogra_> ahoneybun, https://code.launchpad.net/~aaronhoneycutt/kubuntu-manual/+git/kubuntu-manual/+ref/master
[17:31] <popey> too much spam
[17:31] <popey> back in an hour or so, need to take wifey to dinner
[17:32] <ogra_> ahoneybun, you can click the "create snap package" button on there ... but to build a snap you need a snapcraft.yaml
[17:33] <ahoneybun> all got to click a branch for it to be there
[17:33] <ahoneybun> got it
[17:33] <ahoneybun> thanks ogra_
[17:33] <ogra_> :)
[17:33] <ahoneybun> I'm trying to get khelpcenter (kde doc thing) to handle our sphinx docs
[17:34] <ahoneybun> it seems to handle docbook the most but sphinx does not export that
[17:37] <mup> PR snapd#3720 opened: Add initial support for Solus <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3720>
[17:37] <ikey> itshappening.gif
[17:37] <zyga-suse> wooooot
[17:37]  * zyga-suse reviews
[17:37] <ikey> might be some janky that you dont like
[17:38] <ikey> but only one way to find out
[17:38] <ikey> lol
[17:39] <ogra_> popey, once you are back ... full syslog please ... (though i might be gone then too, but i'll look at it over the weekend)
[17:41] <zyga-suse> jdstrand: ^
[17:41] <zyga-suse> ikey: reviewed
[17:43] <ikey> why wouldnt we want libgcc_s .. ?
[17:43] <zyga-suse> mm¿
[17:43] <ikey> "Same comment as above (may need pruning)
[17:43] <ikey> "
[17:43] <ikey> for libgcc_s and libapparmor
[17:43] <zyga-suse> I wasn't thinking about libgc_s specifically
[17:43] <zyga-suse> I just clicked there at random
[17:43] <ikey> oh
[17:43] <zyga-suse> the thing that hinted that this may be stale is libnih
[17:44] <zyga-suse> which was only ever used by upstart
[17:44] <zyga-suse> so unless you have upstart
[17:44] <zyga-suse> then I don't think you need it
[17:44] <zyga-suse> and then you probably don't need other entries
[17:44] <zyga-suse> so let's check
[17:44] <ikey> yeah i dropped nih + cgmanager
[17:45] <ikey> libcap was needed because im doing dynamic link of libcap
[17:46] <ikey> ok your comments have sod all context lol
[17:46] <zyga-suse> that makes sene
[17:46] <zyga-suse> *sense
[17:46] <ikey> "I'm curious about those two rules, they look fine but I wasn't aware we need them or that we perform those operations.
[17:46] <ikey> "
[17:46] <ikey> which?? :P
[17:46] <zyga-suse> so if you purned the list then +1 as I said
[17:46] <zyga-suse> snapctl
[17:46] <zyga-suse> and /usr/lib/snapd
[17:46] <ikey> hm that might've come back from rebase
[17:46] <ikey> lemme drop those two and see how she goes
[17:46] <zyga-suse> I'm curious because /usr/lib/snapd is already definitely mapped
[17:46] <zyga-suse> ah
[17:47] <zyga-suse> wait
[17:47] <zyga-suse> this may be from mvo's work
[17:47] <zyga-suse> on bare base snaps
[17:47] <zyga-suse> mvo: ^ a comment if you still have enrgy
[17:47] <ikey> i think its an artefact of the rebase
[17:48] <zyga-suse> *energy
[17:48] <ikey> ill rebuild with the changes and reinstall/reload apparmor and see if it screams blue murder
[17:48] <ikey> if not, suhweet
[17:51] <ikey> yea golden
[17:51] <ikey> -f pushed change
[17:51] <zyga-suse> thanks
[17:51] <ikey> brave and mrrescue being my new test apps
[17:51] <ikey> lol
[17:52] <zyga-suse> ikey: reviwed
[17:52] <ikey> merci
[17:52] <ikey> ah git
[17:52] <ikey> i know how i ended up doing that
[17:52] <ikey> from copying + editing:
[17:52] <ikey>     /usr/lib/@{multiarch}/libseccomp.so* mr,
[17:52] <ikey>     /lib/@{multiarch}/libseccomp.so* mr,
[17:52] <zyga-suse> ahh
[17:53] <zyga-suse> right
[17:53] <ikey> like not *just* insane >_>
[17:53] <ikey> (sorry xD)
[17:53] <ikey> need me to change the commit message btw?
[17:53] <ikey> saw the PR title edit
[17:54] <zyga-suse> nah, that's fine
[17:54] <zyga-suse> we are not that saint and holy :)
[17:54] <ikey> :D
[17:54] <zyga-suse> mvo: interestingly another run that goes on without failures
[17:54] <zyga-suse> mvo: since we yank disks I don't think this is any specific node that is affected
[17:55] <zyga-suse> mvo: but maybe I am mistaken and it's just one broken box spoiling our day
[17:56] <zyga-suse> ikey: did you try to run tests?
[17:56] <zyga-suse> ikey: go test ./...
[17:56] <zyga-suse> or similar
[17:56] <jjohansen1> ikey: btw the apparmor backport kernels are currently at git://kernel.ubuntu.com/jj/linux-apparmor-backports
[17:56] <ikey> yeah its where i was at jjohansen1
[17:56] <ikey> they were incomplete :)
[17:57] <ikey> i.e. ubuntu domain patches
[17:59] <ikey> zyga-suse, had massive pains trying to get test suite integrated into the pkg
[17:59] <ikey> damn go vendoring
[17:59] <zyga> ikey: that's fine
[17:59] <jjohansen1> ikey: hrmmm, well incomplete in the sense that they don't yet got back further than 4.10, and that they don't have all the features, they are exactly what they claim 4.13 backports.  Once the 4.14 pull is out there will be a 4.14 backport and there will be 4.13+outoftree
[17:59] <zyga> ikey: just wonder what happens when you clone master
[17:59] <zyga> ikey: and run go test ./...
[17:59] <zyga> and see what you get
[17:59] <jjohansen1> ikey: anyways sounds like you are aware of where things are
[17:59] <ikey> jjohansen1, yeah i mean i know they're 4.13 backports - but they're not "full" apparmor in the ubuntu sense :D
[17:59] <ikey> i started off with your backport tree fwiw
[17:59] <jjohansen1> ah
[18:00] <ikey> https://dev.solus-project.com/R3571:43c64241912cc3bfc35a4299097e82b00e1f2cd6
[18:00] <ikey> you can see the deleted patches
[18:00] <jjohansen1> ikey: so 4.14 will be very close, it looks like I probably won't be able to land 1 feature
[18:00] <ikey> because i had partial not strict confinement
[18:00] <ikey> ah ok
[18:02] <ikey> looks like solus will be spying on your kernels for a while then jjohansen1 :p
[18:02] <jjohansen1> :)
[18:02] <jjohansen1> ikey: just poke me if you need any help with any of it
[18:02] <ikey> oh sure - thanks
[18:03] <ikey> fwiw in the end I basically did: git rm -rf security/apparmor, cp -R $fromtheubuntukernel/security/apparmor security/. ; git add .
[18:03] <ikey> and then ported the securityfs bits across and kept watching make on a defconfig
[18:03] <ikey> until it was clean/error-free
[18:04] <ikey> so it might not be pure but by god it frackin works :p
[18:09] <jjohansen1> ikey: heh, that is how I recommend doing it, its just so much easier
[18:09] <ikey> :D
[18:09] <ikey> id rather carry one log across the stream then take it stick by stick ..
[18:10] <ikey> how do i know i have the same log at the end? xD
[18:10] <ikey> aw test failures
[18:10] <zyga> show me please
[18:10] <ikey> on the PR
[18:10] <zyga> ah, looking
[18:10] <ikey> little red angry crosses
[18:10] <zyga> ikey: ah
[18:10] <zyga> ikey: go to interfaces/builtin
[18:10] <zyga> ikey: run go test
[18:11] <zyga> ikey: it will fail
[18:11] <ikey> opengl
[18:11] <zyga> ikey: you want to fix that one place
[18:11] <zyga> yep
[18:11] <zyga> ikey: I suggest using one trick
[18:11] <zyga> ikey: instead of c.Assert(..., Equals, ...) use testutil.Contains
[18:11] <zyga> and just find the essentail part
[18:11] <ikey> yea
[18:11] <zyga> not the whole kitchen sink
[18:11] <zyga> it should be nicer and convey the point more
[18:11] <ikey> so when i run go test i have a billion things not found
[18:11] <ikey> and y'all don't do git submodules
[18:12] <zyga> no, it's just in one tree
[18:12] <ikey> eh
[18:12] <ikey> my CLI disagrees
[18:12] <ikey> lol
[18:12] <ikey> tests/lib/fakestore/store/store.go:34:2: cannot find package "gopkg.in/tylerb/graceful.v1" in any of:
[18:12] <ikey> etc
[18:13]  * ikey does the govendor thingy
[18:14] <ikey> imagine how much nicer this would be with .gitmodules .. lol
[18:15] <Pharaoh_Atem> please, don't encourage it
[18:15] <ikey> would be so much more manageable than this govendor thing
[18:15] <ikey> recursive clone, bam, done
[18:16] <zyga> ikey: just ./get-deps
[18:16] <zyga> that does it
[18:16] <zyga> ikey: govendor is easy too, just different
[18:16] <zyga> ikey: I don't mind it (govendor)
[18:16] <Pharaoh_Atem> >_>
[18:16] <ikey> snap/info_snap_yaml_test.go:822: undefined: snap.NewHookType
[18:16] <Pharaoh_Atem> I wish I had overlay tarballs
[18:16] <zyga> Pharaoh_Atem: go develop snapd without it ;) it's just a time saver
[18:16] <ikey> this is a concussion of failures
[18:17]  * Pharaoh_Atem guesses he'd have to make the overlay tarballs himself
[18:17] <zyga> ikey: so, that's odd
[18:17] <zyga> ikey: is this on master
[18:17] <ikey> so your HACKING doc is telling me to use go get
[18:17] <ikey> but i need git
[18:17] <ikey> not got get'd crap
[18:17] <zyga> ikey: I assume you set up all the go gooies okay (GOPATH and all that)
[18:17] <ikey> because my changes is elsewhere
[18:17] <ikey> well your tree is set up wonky
[18:17] <ikey> you dont have src or src/vendor
[18:17] <zyga> ikey: put your tree in $GOPATH/src/github.com/snapcore/snapd
[18:17] <popey> ogra_: http://paste.ubuntu.com/25291916/
[18:17] <ikey> so i cant set GOPATH=`pwd`
[18:18] <Pharaoh_Atem> nope
[18:18] <zyga> ikey: I never heard of that approach
[18:18] <ikey> its standard ._.
[18:18] <Pharaoh_Atem> zyga: it doesn't work
[18:18] <zyga> ikey: (in fact, none go project I saw did that)
[18:18] <ikey> many. many do
[18:18] <ikey> only libraries use root level
[18:18] <zyga> ikey: not saying it's wrong just unfamiliar
[18:18] <Pharaoh_Atem> ikey: that's news to me
[18:18] <Pharaoh_Atem> to date, I haven't see a Go package that works that way
[18:18] <ikey> so if you need to be imported from another project, you use root level
[18:18] <ikey> meet one https://github.com/solus-project/solbuild
[18:19] <popey> ogra_: https://raspberrypi.stackexchange.com/questions/62722/pi-zero-w-wifi-interference-with-tty
[18:19] <zyga> https://github.com/solus-project/solbuild/blob/master/.github/building.gif
[18:19] <zyga> lol
[18:19] <zyga> wat is that?
[18:19] <ikey> solbuild
[18:19] <zyga> I mean
[18:19] <zyga> why do you keep the gif in the tree
[18:20] <ikey> cuz its pretty
[18:20] <ikey> and its in the readme
[18:20] <ikey> lol
[18:20] <Pharaoh_Atem> :)
[18:20] <Pharaoh_Atem> I did something similar recently: https://blog.mageia.org/en/2017/07/21/dandifying-mageia-part-2/
[18:20] <zyga> Pharaoh_Atem: about that, where is snapd mageia?
[18:20] <Pharaoh_Atem> zyga: ask Akien :)
[18:20] <zyga> well, I haven't heard from him
[18:21] <ikey> k so
[18:21] <ikey>  ✓  ufee1dead@ironhide  …/Projects/go  ls src/github.com/snapcore/ -l
[18:21] <ikey> total 0
[18:21] <ikey> lrwxrwxrwx 1 ufee1dead ufee1dead 17 Aug 11 19:20 snapd -> ../../../../snapd
[18:21] <ikey> now lets see if she goes
[18:22] <ikey> zyga, feature request: make get-deps verbose plox
[18:22] <zyga> plox?
[18:22] <ikey> = pls/please
[18:22] <Pharaoh_Atem> zyga: he hasn't been around lately, I'll poke him next time I see him
[18:23] <zyga> ikey: pass -v to govendor sync
[18:23] <ikey> ok test is finally going xD
[18:24] <zyga> run tests across the tree to see what works and fails
[18:24] <zyga> maybe something odd will shoe up
[18:24] <zyga> show up
[18:26] <ikey> yer
[18:26] <ikey> doing your test-all-the-things command
[18:27] <ikey> yer im missing the solus snippet in the test suite
[18:29] <ikey> zyga, we'll just pretend none of this ever happened and move on. *cough*
[18:30] <zyga> ikey: well it's Friday :)
[18:30] <ikey> aint it just
[18:30] <ikey> lol
[18:30] <zyga> if I had any cold beer I'd love to try some
[18:30]  * ikey is silencing his brain with bonnie tyler 
[18:31] <zyga> it's dusk here and it's way to hot to work
[18:31] <ikey> heh
[18:31] <ikey> Ireland doesn't really have that issue .. -_-
[18:31] <zyga> ikey: just put your head into an overclocked pentium 4 for some time
[18:31] <ikey> lol
[18:32] <zyga> ikey: not that I recommend it
[18:32] <ikey> if i had my server still id be plenty warm
[18:32] <zyga> and some say that traveling to poland is cheaper than a pentium 4
[18:32] <ikey> dual-socket xeon used to sit under the desk
[18:32] <ikey> it went back to work when i went full time on solus
[18:33] <zyga> I'm looking forward to amd now
[18:33] <zyga> I need to sell my boxes
[18:33] <zyga> and unify under one nice VM host
[18:33] <ikey> not gonna have local h/w?
[18:33] <zyga> no I mean I want less local hw
[18:33] <pedronis> The job exceeded the maximum time limit for jobs, and has been terminated.
[18:33] <zyga> I have way too many computers now
[18:33] <ikey> ah
[18:33] <zyga> pedronis: :-(
[18:34] <pedronis> do we have enough resources now with all the other distro tests?
[18:34] <pedronis> that branch has the bump to 3 workers for fedora but doesn't seem enough
[18:34] <zyga> pedronis: interesting, I'll drop that if that is the case
[18:34] <zyga> I was testing on one locally
[18:35] <ikey> im sure that whatever the problem is, openstack is the solution
[18:35]  * ikey grins evilly
[18:35] <zyga> ikey: unless the problem is too many layers of abstraction
[18:36] <ikey> lol
[18:36] <ikey> or god awful python
[18:36] <ikey> which is all basically down to:
[18:36] <ikey> def busyFunction(args):
[18:36] <ikey>     return commands.getoutput("some slow ass command {}".format(args))
[18:36] <zyga> so, when I was in primary school I wanted to make games
[18:36] <zyga> I ran doom on my 386 DX box
[18:36] <zyga> and doom took a while to load
[18:37] <zyga> and I loved that
[18:37] <zyga> it did stuff
[18:37] <ikey> yea
[18:37] <zyga> and my programs at the time did not need that loading screen
[18:37] <zyga> so one day I impressed my friend by making a fake loading screen
[18:37] <zyga> where I would just do useless IO and wait a little until all the dots fill in
[18:37] <ikey> lol
[18:37] <popey> hahah
[18:38] <zyga> that was a pro app then
[18:38] <zyga> it meant serious stuff
[18:38] <ikey> now i know where plasma got it from ..
[18:38] <zyga> (also that was on DJGPP under dos, man those were the days)
[18:38] <popey> oh wow, allegro
[18:38] <zyga> no I didn't use allegro
[18:39] <popey> getting flashbacks to zip drives full of djgpp stuff
[18:39] <zyga> I remember downloading djgpp over modem for a week
[18:40] <zyga> and now bandwidth is next to free
[18:40] <zyga> but people don't download djgpp anymore
[18:40] <zyga> they download youtube and faceb ook
[18:40] <ikey> in the old SolusOS (debian based) days (not that long ago really) I was using the original mobile broadband, i.e. that devilcrap from 3
[18:40] <ikey> took over 7 hours to upload an ISO
[18:40] <popey> ouch
[18:40] <zyga> really?
[18:40] <ikey> thats when i fell out with filezilla
[18:40] <zyga> I'm on mobile broadband now
[18:41] <ikey> because it wouldnt resume the partial
[18:41] <zyga> and one thing I love is fantastic upload speed
[18:41] <ikey> zyga, i mean original mobile broadband. :p
[18:41] <ikey> not the stuff now
[18:41] <popey> yeah, but gprs vs 4g is quite a difference
[18:41] <kyrofa> Man you guys are old
[18:41] <ikey> i mean like 7 years ago or so
[18:41] <ikey> kyrofa, oi
[18:41] <ikey> im 28
[18:41] <ikey> i think
[18:41] <zyga> ikey: hmmmmm
[18:41] <ikey> ill get back to you on that
[18:41] <zyga> 7 years ago it was still faster :D
[18:41] <popey> where I went on holiday in portugal they had "wifi" which was a 3g dongle
[18:41] <zyga> maybe I had better broadband
[18:41] <kyrofa> I remember the sound of dialup... vaguely
[18:41] <popey> was fine for everyone to use at the same time. amazing how far it's come
[18:41] <zyga> hey kyrofa :)
[18:42] <ikey> Dialling attempt 9 of 10 ...
[18:42] <zyga> yeah, have you seen the ashen hair on my beard?
[18:42] <popey> Trumpet winsock :)
[18:42] <zyga> I feel so old when I look into the mirror
[18:42] <kyrofa> Hey zyga :) . Haha, that I have!
[18:42] <kyrofa> zyga, ogra_ isn't is super late for you guys?
[18:42] <ikey> zyga, my mirror doesn't make eye contact anymore..
[18:42] <kyrofa> It's the weekend!
[18:43] <zyga-suse> mvo: reproduced again, darn, I ran without --debug
[18:43] <ikey> wait how/why did i end up going down this snap road
[18:43] <ikey> i was meant to be doing budgie 10.4 and a solus release
[18:43]  * ikey retraces the last few days
[18:43] <zyga> kyrofa: 20:42 is mild
[18:44] <kyrofa> Ah right, you moved
[18:44] <zyga> ikey: I think it was a nice ride :-) you certainly made new grounds here
[18:44] <ikey> "its been real"
[18:44] <ikey> lol
[18:44] <ikey> i mean, being mature about it for a moment...
[18:44] <ikey> its nice to sit back and say, yknow what..
[18:44] <ikey> suck it, arch.
[18:44] <ikey> >_>
[18:45] <zyga> lol, why take a lob at arch out of a sudden?
[18:45] <ikey> oh its there
[18:45] <ikey> thats all
[18:46] <ikey> its anti-memery
[18:46] <ikey> remember, Arch is where newest and fixiest ™ happens first - before everyone! ™
[18:46] <zyga> memery?
[18:46] <ikey> anti-meme.
[18:46] <ikey> ry.
[18:46] <zyga> ah
[18:46] <ikey> lol.
[18:46] <zyga> one thing I like arch for is the immensly valuable and up-to-date wiki
[18:46] <zyga> that's an unversal asset for the whole community
[18:46] <ShalokShalom> ikey: no, we are quicker :P
[18:46] <ikey> wouldnt be sure about that
[18:47] <ikey> the emails ive had id say not all of you are that quick ;)
[18:47] <ShalokShalom> zyga: yea, i see so too
[18:47] <ShalokShalom> while Gentoos is also great
[18:47] <ShalokShalom> and the community is nicer...
[18:47] <ShalokShalom> imho
[18:47] <ikey> Gentoo went through the growing-up-pains a *long* time ago
[18:48] <mup> PR snapcraft#1481 closed: cli: better error message for missing mksquashfs <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1481>
[18:48] <zyga> community is a very vague thing unfortunately, some people are nice, some people are not nice, that's everywhere; some projects try to make sure their community behaves but this is just human nature
[18:48] <ikey> ya you're gonna get that in any walk of life, virtual or not
[18:49] <ikey> i feel like my PR has killed the testbot :p
[18:50]  * ikey is kinda jealous of the fancy automated builder
[18:50] <zyga> ikey: spread?
[18:51] <mup> PR snapcraft#1482 closed: ci: skip the CLA check for pull requests from the bot <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1482>
[18:51] <zyga> ikey: just use it :)
[18:51] <ikey> touché
[18:52] <ikey> nice comment here at the bottom: https://plus.google.com/+Solus-Project/posts/dxBEun53LVm
[18:52] <ikey> re: s/w availability
[18:52]  * ikey is finally off the hook almost
[18:52] <zyga> Pharaoh_Atem: does dnf keep any logs
[18:53] <zyga> yes
[18:53] <zyga> snaps make software egalitarian
[18:54] <ikey> it does solve that most awkward of issues for solus
[18:54] <zyga> no matter which distribution you use, you keep access to apps you want
[18:54] <ikey> its biggest strength and arguably its largest weakness
[18:54] <ikey> its independence
[18:54] <ikey> having the new fangled formats around allows us to keep doing that
[18:54] <zyga> ikey: try making a snap
[18:54] <ikey> (assuming critical mass + hype + corporate backing)
[18:54] <zyga> ikey: hand make it
[18:54] <ikey> why so? :p
[18:54] <zyga> to see how it is
[18:55] <ikey> i mean im not overly opposed to it
[18:55] <zyga> ikey: make meta/snap.yaml
[18:55] <ikey> but i did kinda do the whole YAML based packaging before y'all
[18:55] <zyga> ikey: stick some files you compiled
[18:55] <ikey> This won't be overly new to me :P
[18:55] <zyga> ikey: "snap try" the directory you were holding this in
[18:55] <zyga> and see how that is
[18:55] <ikey> ima leave that til tomorrow if thats alright lol, just waiting to see the results of the test build
[18:56] <zyga> sure :-)
[18:56] <ikey> and then im gonna find a corner in which to curl up and die
[18:56] <ikey> *or* buy pringles and watch netflix
[18:56] <ikey> *hrm*
[18:56] <ShalokShalom> Snappy is bond to Ubuntu One?
[18:56] <ikey> totally gonna get pringles.
[18:56] <zyga> ShalokShalom: nope,
[18:56] <zyga> ShalokShalom: ubuntu one the identity provider? no
[18:56]  * ikey considers a snap for solbuild .. xD
[18:57] <zyga> ShalokShalom: so far that's the only one but we have plans and work in progress for federation and local identity
[18:57] <ikey> (would be virtually impossible without --classic ..)
[18:57] <arm1e> ogra_: Hey man, you still around
[18:57] <popey> arm1e: i think he checked out for the weekend.
[18:58] <arm1e> ikey: shit me, you still working? Long day. Your new boss must be a real dick!
[18:58] <ikey> somethin like that
[18:59] <ikey> going to do a solus release soon, and i think having full (CLI) snap support would be a nice headline feature
[18:59] <arm1e> popey: cheers. Still stuck on this bloody snap!
[18:59] <ikey> anyone will tell you, near release time, hours go out the window
[18:59] <zyga> ikey: indeed
[18:59] <ShalokShalom> zyga: while this is true, are my experiences with the different communitys very often reproduceable
[18:59] <popey> arm1e: which one?
[18:59] <zyga> ShalokShalom: I don't deny that
[19:00] <arm1e> trying to make a get-iplayer snap, but it is just a perl executable and I cant get it to compile properly
[19:00] <popey> get_iplayer _may_ become redundant once BBC force the identity provider on us :S
[19:00] <arm1e> ikey: with flatpak too? That could set you apart from many others
[19:00] <ShalokShalom> arm1e: he is not working, he is chatting :P
[19:01] <ikey> we already have flatpak support arm1e
[19:01] <ikey> ShalokShalom, nuh uh
[19:01] <ikey> https://xkcd.com/303/
[19:01] <arm1e> ikey: I know,
[19:01] <ShalokShalom> ikey: so, you went back from AppImage?
[19:01] <ikey> never had appimage ShalokShalom ..
[19:01] <ShalokShalom> Or Flatpak
[19:01] <arm1e> popey: I know, I just wanted to see if i could do it. Trying to learn how to snap things
[19:01] <arm1e> popey: LOTS to learn!
[19:02] <ikey> does anyone else immediately go to "rhythm is a dancer" when someone threatens to snap a thing
[19:02] <ikey> ?
[19:02] <popey> The Power, here
[19:02] <ikey> ah
[19:02] <ikey> lol
[19:02]  * zyga doesn't recall the reference
[19:02] <ShalokShalom> just remember that one person in your room, self-proclaimed pro on this area, announced that after a long and intense research, Flatpak was choosen
[19:03] <ikey> ok thats not what i said at all and you might wanna wind it in ShalokShalom
[19:03] <ShalokShalom> not you
[19:03] <ShalokShalom> somebody else
[19:03] <ikey> your comment sounds malicious, just letting you know.
[19:03] <ShalokShalom> that comment sounded so as well
[19:04] <ShalokShalom> so i might have done a fine job in reproducing it
[19:04] <ShalokShalom> hi sabdfl :)
[19:04] <zyga> sabdfl: hey :)
[19:04] <zyga> sabdfl: ikey here just added snapd support to Solus OS
[19:04] <Pharaoh_Atem> sabdfl: Hey!
[19:05] <ikey> s/OS//
[19:05] <zyga> nice way to end Friday for me :)
[19:05] <ikey> >_>
[19:05] <zyga> sorry ;D
[19:05] <ikey> lol s'ok
[19:05] <ikey> another meme. :p
[19:05] <sabdfl> how was the experience, ikey?
[19:05] <ikey> Intense!
[19:05] <ikey> lol
[19:05] <sabdfl> :D
[19:05] <ikey> I think we pulled this off in like 3 days?
[19:05] <ShalokShalom> is there anything else in Snappy, that takes it off from the others?
[19:05] <ikey> including today
[19:05] <ShalokShalom> some unique feature?
[19:05] <ShalokShalom> focus?
[19:06] <ikey> and we're now at the point where Solus's kernel matches the apparmor implementation in Ubuntu Artful
[19:06] <sabdfl> zyga, do we have Solus in CI testing so we gate updates appropriately?
[19:06] <zyga> sabdfl: with confinement, no less
[19:06] <ikey> So Solus has full confinement for snaps. Woot
[19:06] <sabdfl> that's ace :)
[19:06] <arm1e> is anyone available to help me write the yaml for get-iplayer please. Keeps failing to compile
[19:06] <zyga> sabdfl: not yet but we are getting initial patches and we've already discussed spread and system testing
[19:06] <ShalokShalom> ikey: what makes you go aways from Flatpak?
[19:06] <sabdfl> classic and strict both work?
[19:06] <ikey> Couldn't have done it without the guys here, so, go team
[19:06] <zyga> sabdfl: we'll get there
[19:06] <zyga> sabdfl: yes
[19:06] <sabdfl> awesome
[19:06] <zyga> sabdfl: really, a first outside of ubuntu derivatives
[19:06] <ShalokShalom> they mean its not suitable to power a whole distro
[19:06] <ikey> sabdfl, classic has some library/path related issues we can compromise on in solus
[19:06] <ikey> like libselinux.so needing to be there and gtk-update-icon-cache-3.0 symlink
[19:06] <ShalokShalom> they = some ppl in #flatpak
[19:07] <ikey> then the vast majority of classics will "just work"
[19:07] <ShalokShalom> *away
[19:07] <zyga> sabdfl: some classic snaps assume too much of ubuntu but we can improve this with tooling and compromise across distros
[19:07] <sabdfl> ikey, i would like every distro to be a gate on snapd updates, so let's add what you need
[19:07] <ikey> sure - much appreciated :]
[19:07] <sabdfl> we should offer a testing service for snap publishers "test your snap on all supported distros"
[19:08] <zyga> oh that would be lovely, yes
[19:08] <zyga> and we have the means to do that technically
[19:08] <ikey> nice bit of value-add
[19:08] <ikey> free pipelining
[19:08] <sabdfl> i.e. when they release into edge/beta/candidate, we smoketest it for them, using a test suite they supply, on VMs of all the distros
[19:08] <Pharaoh_Atem> that'd be nice
[19:08] <zyga> I was working on out-of-the-box experience that tests how snaps behave simply by following install instructions from snapcraft.io
[19:08] <sabdfl> so there's less stress in --stable :)
[19:08] <Pharaoh_Atem> we need to get all the distros at parity first, but that'd be awesome
[19:08] <ikey> they'd know the distros would have problems .. before the distros
[19:08] <ikey> bit of a turning point
[19:08] <zyga> and we could generalize that to see how the same snap behaves across many releases of many OSes
[19:09] <sabdfl> and we'd have a concrete list of things we can smooth over centrally
[19:09] <sabdfl> zyga +1
[19:09] <Pharaoh_Atem> zyga: with F24 EOL, all currently supported Fedora releases will have snapd "just work" out of the box
[19:09] <zyga> Pharaoh_Atem: yes, I need to do some work to add F26 to our test pool
[19:09] <Pharaoh_Atem> though we're still gimped because snapd-xdg-open isn't in Fedora
[19:09] <zyga> Pharaoh_Atem: and also tumbleweed and opensuse leap .3
[19:09]  * ikey likes boxes and things that work outside of them
[19:10] <sabdfl> then let's get Fedora into the CI pipe too!
[19:10] <zyga> sabdfl: we have F25 in the CI today but we need to improve test coverage as not all tests are enabled today
[19:10] <Pharaoh_Atem> sabdfl: believe me, I want that more than anything :)
[19:10] <zyga> Pharaoh_Atem: speaking of that, any dnf log I can refer to to see why a particular dnf install failed?
[19:10] <Pharaoh_Atem> zyga: /var/log/dnf*.log
[19:11] <zyga> thank you!
[19:11] <Pharaoh_Atem> there's dnf.log, dnf.librepo.log, dnf.rpm.log
[19:11] <zyga-suse> Pharaoh_Atem: hmm interesting
[19:11] <zyga-suse> https://paste.gnome.org/pug2inoby
[19:12]  * arm1e is looking for anyone who can help write the yaml for get-iplayer please. Keeps failing to compile. 
[19:12] <arm1e> a mentor i suppose
[19:13] <Pharaoh_Atem> zyga-suse: that's because 1.12 is gone
[19:13] <Pharaoh_Atem> https://bodhi.fedoraproject.org/updates/FEDORA-2017-dba5166094
[19:13] <nacc> arm1e: pastebin the log (of the build failure)
[19:13] <Pharaoh_Atem> 1.13 was pushed out 2 days ago
[19:13] <zyga> Pharaoh_Atem: but I dnf install foo
[19:13] <arm1e> nacc: will do
[19:13] <zyga> Pharaoh_Atem: am I missing something?
[19:13] <Pharaoh_Atem> zyga: it's possible you're on a broken mirror?
[19:13] <Pharaoh_Atem> try forcing a refresh
[19:14] <Pharaoh_Atem> "dnf --refresh install <pkg>"
[19:14] <zyga> Pharaoh_Atem: let me patch that
[19:15] <zyga> trying again
[19:15] <arm1e> nacc: http://paste.ubuntu.com/25292200/
[19:15] <ShalokShalom> so, is there anything else to add for you? http://funkyimg.com/i/2wjmo.png
[19:15] <arm1e> I kind of get the problem, I think the syntax in the yaml is wrong.
[19:16] <nacc> arm1e: and your yaml?
[19:16] <ShalokShalom> ah, Snappy runs only on Linux, yeah?
[19:16] <arm1e> nacc: http://paste.ubuntu.com/25292206/
[19:17] <arm1e> nacc: I was told earlier to use a snippet to install and got sent the syntax for the install part of the file
[19:17] <nacc> arm1e: iiuc, you are just trying to put the get_iplayer script in a good place?
[19:17] <arm1e> I think so
[19:18] <nacc> arm1e: i think with the dump plugin you can ignore that (tbh) and just create an application that will call get_iplayer
[19:18] <nacc> arm1e: note that it doesn't really make sense to hav ea yaml without any applications
[19:19] <nacc> arm1e: i *think* you could probably go through the building steps, stop at stage and see what is in your staged fs at that point. I expect you'd see get_iplayer somewhere and that's all your application needs to call (i think)
[19:19] <nacc> arm1e: you *might* need a wrapper script since you're using the dump plugin, to set PERL5LIB and/or PATH correctly
[19:20] <arm1e> nacc: I think I should probably just give up and try a different application
[19:22] <zyga> re
[19:22] <zyga> ShalokShalom: I'd like to understand what you mean by sharing libraries
[19:22] <zyga> ShalokShalom: libraries can be shared just as they can be in flatpak
[19:22] <zyga> ShalokShalom: and more actually
[19:23] <ShalokShalom> sharing ressources
[19:23] <zyga> ShalokShalom: as you are not at the whim of your runtime provider
[19:23] <zyga> ShalokShalom: so you can share just as much as in the flatpak approach + whatever else you want amongst the snaps you make
[19:23] <zyga> ShalokShalom: which is not techically possible in flatpak
[19:23] <ShalokShalom> so, use one library for dozens of apps
[19:23] <ShalokShalom> while one time in RAM
[19:23] <zyga> ShalokShalom: I'm not sure that is really the case in flatpak if they come bundled
[19:23] <zyga> ShalokShalom: unless it happens to happen because of ostree
[19:23] <ShalokShalom> "whatever else you want amongst the snaps you make" ?
[19:23] <zyga> but I cannot confirm that for you
[19:24] <zyga> ShalokShalom: as a snap author you can share content between the snaps you own
[19:24] <ShalokShalom> the old PC-BSD bundle system also shared ressources
[19:24] <zyga> ShalokShalom: so you can, say, ship the whole java runtime in one snap
[19:24] <zyga> ShalokShalom: and then have a few snaps re-use it
[19:24] <zyga> ShalokShalom: then you trully share it in ram and on disk
[19:24] <zyga> ShalokShalom: flatpak allows you to bundle stuff in your package and gives you the runtime
[19:24] <ShalokShalom> yeah, thats what i mean
[19:24] <zyga> ShalokShalom: (thought I'm not a FP expert so ask them please)
[19:25] <ShalokShalom> sure
[19:25] <ShalokShalom> i do this anyway
[19:25] <zyga> ShalokShalom: but if I have N packages that happen to bundle the same library
[19:25] <zyga> ShalokShalom: I don't know if it is guaranteed that ostree will de-duplicate it
[19:25] <zyga> it might, but I cannot say
[19:25] <ShalokShalom> like to be save, that everyone can insist, if i do something unfair by accident
[19:25] <zyga> and I don't know the conditions that make it de-duplciated
[19:25] <ShalokShalom> Flatpak and Snappy are both for Linux only, yes?
[19:25] <popey> Depends on the perspective
[19:25] <zyga> ShalokShalom: both rely on linux kernel features extensively
[19:26] <zyga> ShalokShalom: but
[19:26] <arm1e> nacc: what would you recommend?
[19:26] <ShalokShalom> Snappy depends on something?
[19:26] <ShalokShalom> systemd?
[19:26] <ShalokShalom> popey: at the current state
[19:26] <popey> Also, the sheet seems to only focus on user-facing features, not the developer facing features
[19:26] <zyga> ShalokShalom: it doesn't mean they cannot eventually work in other operating systems
[19:26] <ShalokShalom> Habitat runs on OS X and Windows too, as an example
[19:26] <nacc> arm1e: you're pretty close (given that it's a perl script that you're wrapping, no compilation is necessary, which makes it easy
[19:26] <ShalokShalom> eventually
[19:26] <zyga> ShalokShalom: we depend on the kernel mostly, userspace we do depend on systemd and udev
[19:26] <ShalokShalom> this sheet is about the current state of development
[19:26] <nacc> arm1e: but it's a lot easier to snap something you understand deeply, IMO (at least how it builds/installs)
[19:27] <zyga> ShalokShalom: though mostly as a convenience, we chose not to abstrat this away because mostly everybody agrees
[19:27] <arm1e> nacc: problem is I dont understand most of what you wrote
[19:27] <ShalokShalom> ok fine
[19:27] <ShalokShalom> i see
[19:27] <zyga> ShalokShalom: and we made a deputy systemd package that allows systemd to run on top of an existing init system so that it can manage snapd and nothing else
[19:27] <nacc> arm1e: yeah, i understand
[19:27] <ShalokShalom> aha, ok fine, thanks a lot
[19:27]  * zyga knows nothing about habitat
[19:27] <arm1e> nacc: I only chose this because I managed to get it to work on solus and it is the only thing I have ever packaged
[19:27] <zyga> ShalokShalom: is that a build-from-source approach?
[19:27] <ShalokShalom> yeah, its my prefered system until
[19:27] <ShalokShalom> yes sure
[19:28] <ShalokShalom> both
[19:28] <zyga> ShalokShalom: so you have no guarttee that what you get is the same really, it's a differnet build each time
[19:28] <nacc> arm1e: i don't know what solus is -- but like i said you are actually close
[19:28] <zyga> that's nice but it's a different class of systems
[19:28] <nacc> arm1e: if you add a an application, I think you'll immediately see what i meant
[19:28] <arm1e> ikey: Did you hear that!! Blasphemy!
[19:28] <nacc> arm1e: and then when you run your application, i think you'll see what i meant about the wrapper script (because it probably won't run)
[19:29] <arm1e> nacc: application as in set the command for get iplayer
[19:29] <ikey> sorry didnt hear i wasnt here :3
[19:30] <zyga> Pharaoh_Atem: I think that has fixed it, I'll commit this soon
[19:30] <nacc> arm1e: https://snapcraft.io/docs/snaps/metadata#snap.yaml as in an entry under apps:
[19:30] <nacc> arm1e: right now you're not snapping anything
[19:30] <ShalokShalom> zyga: https://github.com/habitat-sh/habitat#habitat
[19:30] <zyga> I need to put the thermal paste on my suse laptop, it is really crazy hot all the time
[19:30] <ikey> fedora failed on my PR @_@
[19:30] <nacc> arm1e: parts are bits and pieces of a final snap, but you're not exposing an entry point to that result
[19:30] <zyga> ikey: yep, I'll fix that
[19:30] <zyga> that's what I'm working on now
[19:30] <zyga> (on my suse box, because life is great :)
[19:30] <arm1e> nacc: I think i follow
[19:30] <ShalokShalom> Provide repeatable builds
[19:31] <zyga> ShalokShalom: curl https://raw.githubusercontent.com/habitat-sh/habitat/master/components/hab/install.sh | sudo bash
[19:31] <ShalokShalom> Provide idempotent behavior (the same inputs to the same asset provide the same outcome)
[19:31] <zyga> I fear every project that does this
[19:31] <ShalokShalom> why?
[19:31] <zyga> really? do you not see why this is dangerous
[19:31] <nacc> awful :/
[19:31] <ShalokShalom> look at the .sh if you fear
[19:31] <ikey> "run random command from internet"
[19:31] <zyga> haha
[19:31] <zyga> well
[19:31] <ikey> "Ok boss"
[19:31] <zyga> I need to show you one nice script
[19:31] <ShalokShalom> its not random
[19:31] <ShalokShalom> its from Chef
[19:31] <zyga> that if you wget it it is benine
[19:31] <ikey> ive never seen it before, its random
[19:31] <zyga> and if you pipe it it owns your system
[19:31] <ShalokShalom> a well known Company
[19:31] <ikey> if i do this in a starbuckets on public wifi i deserve whats coming to me.
[19:31] <ShalokShalom> and community
[19:31] <zyga> measuring the speed at which you read
[19:31] <zyga> that's why
[19:32] <ikey> *starbucks
[19:32] <ikey> ..starbuckets? long day.
[19:32] <zyga> it means that whoeever made that page doesn't appreciate secure design
[19:32] <pedronis> cachio: niemeyer:  got again  The job exceeded the maximum time limit for jobs and has been terminated.  2nd time in a row even if I merged master with the 3 workers for Fedora
[19:32] <ikey> secure design = pythonic os.system("rm -rf some/path") - right zyga ?
[19:32] <ikey> because you used a secure language
[19:32]  * ikey runs
[19:32] <ShalokShalom> You check all the source code of applications that you pack?
[19:32] <cachio> pedronis, which job?
[19:32] <ikey> ShalokShalom, actually thats a new goal for solus
[19:33] <ShalokShalom> hahahahaha
[19:33] <ikey> building a source->customer pipeline
[19:33] <ikey> imean client.
[19:33] <ikey> *grin*
[19:33] <Pharaoh_Atem> you mean something that'll keep Solus afloat :)
[19:33] <Pharaoh_Atem> it's on that boat in the ocean after all :)
[19:33] <ikey> Solus has no issues staying afloat
[19:33] <ikey> Well built boat
[19:33] <ikey> Not like that one irish boat we wont talk about
[19:33] <ikey> *cough*
[19:34]  * Pharaoh_Atem sniggers
[19:34] <ShalokShalom> Solus remembers me on btrfs
[19:34] <ikey> wat
[19:34] <ikey> also props for the ascii-banner-of-death on travis
[19:34] <zyga> ShalokShalom: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
[19:34] <zyga> this is why
[19:35] <zyga> mvo, pedronis: I'll cut the number of workers to 1 until we can fix the quota
[19:35] <zyga> and I think I have the fix for fedora now
[19:35] <pedronis> cachio: https://travis-ci.org/snapcore/snapd/builds/263451621?utm_source=github_status&utm_medium=notification
[19:35] <zyga> Pharaoh_Atem: I find the --refresh part confusing because it seems to differ on interactive vs batch somehow
[19:35] <zyga> Pharaoh_Atem: it doesn't fail interactively, is --refresh inferred somehow>
[19:36] <pedronis> zyga: won't 1 worker make things worse ?
[19:36] <zyga> pedronis: we'll see
[19:36] <zyga> pedronis: I'll measure it
[19:36] <Pharaoh_Atem> zyga: ?
[19:36] <Pharaoh_Atem> it shouldn't be different
[19:36] <zyga> Pharaoh_Atem: it doesn't fail now but it did before
[19:36] <Pharaoh_Atem> are you not doing --assumeyes?
[19:36] <Pharaoh_Atem> (aka -y)
[19:36] <zyga> I am
[19:37]  * Pharaoh_Atem shrugs
[19:37] <zyga> -                dnf -q -y install $DNF_FLAGS "$package_name"
[19:37] <zyga> +                dnf -q -y --refresh install $DNF_FLAGS "$package_name"
[19:37] <Pharaoh_Atem> worksforme
[19:37] <zyga> yeah
[19:37] <zyga> a bit of magic
[19:37] <cachio> pedronis, the problem is that https://paste.ubuntu.com/25292297/
[19:37] <zyga> not always failed tho
[19:37] <Pharaoh_Atem> $DNF_FLAGS?
[19:37] <zyga> Pharaoh_Atem: yep, --setopt=install_weak_deps=False
[19:37] <cachio> pedronis, that produced the error
[19:37] <pedronis> cachio: ah
[19:37] <zyga> (optionally)
[19:37] <ikey> s/DNF/DNR/
[19:37] <pedronis> so I see
[19:38] <pedronis> not enough workes we fail, too many workers we fail
[19:38] <ShalokShalom> zyga: again, you trust Chef in this case
[19:38] <cachio> pedronis, heheh
[19:38] <zyga> ShalokShalom: I don't trust unsigned stuff piped into root shell, period
[19:38] <ShalokShalom> you can take any app in Github, a lot of stuff from there is in the distros, unchecked
[19:38] <cachio> pedronis, to many jobs in parallel
[19:38] <zyga> ShalokShalom: yes, but I don't run happily installing them
[19:38]  * ikey is afraid enough of running his own scripts as root, let alone someone elses :p
[19:38] <zyga> ShalokShalom: *especially* if I make a package manager
[19:38] <ShalokShalom> why?
[19:39] <ShalokShalom> is it about your scare?
[19:39] <ShalokShalom> its computer science
[19:39] <zyga> ShalokShalom: because it is irresponsible to my users
[19:39] <cachio> pedronis, at some point we will need more machines
[19:39] <ShalokShalom> science != scare
[19:39] <ikey> science frequently = scary
[19:39] <zyga> ShalokShalom: and if I claim to know enough to make a package manger I should not be making that mistake
[19:39] <ShalokShalom> which mistake?
[19:39] <zyga> ShalokShalom: I cannot make a bank by writing the word BENK on a cardbord box
[19:39] <ShalokShalom> the whole thing is written
[19:39] <ShalokShalom> claim = unproved
[19:39] <zyga> well, in software we can, and that is the problem
[19:40] <ShalokShalom> that thing runs
[19:40] <ShalokShalom> so its something else as a claim
[19:40] <ShalokShalom> you seem to be in trouble with semantics
[19:40] <zyga> ShalokShalom: I just gave you evidence that piping a script to shell is insecure and can be benine on inspection and malicious in execution
[19:40] <pedronis> cachio: well I have been failing to merge a branch for all the afternoon, and all a bit of the evening
[19:40] <ShalokShalom> zyga: no
[19:40] <Pharaoh_Atem> zyga: you can put that before install subcommand
[19:41] <ShalokShalom> using ANY source code that is unchecked is potentally insecure
[19:41] <pedronis> cachio: I'm going to give up for now
[19:41] <zyga> ShalokShalom: I don't dispute that
[19:41] <ShalokShalom> this source is secure, since the providers are Github and Chef
[19:41] <zyga> Pharaoh_Atem: what specifically?
[19:41] <cachio> pedronis, try again in few hours
[19:41] <ShalokShalom> plus, this is a way to distribute your software across
[19:41] <Pharaoh_Atem> ‎[15:37] ‎<‎Pharaoh_Atem‎>‎ $DNF_FLAGS?
[19:41] <ShalokShalom> distros
[19:41] <pedronis> cachio: in a few hours I'll sleep
[19:41] <Pharaoh_Atem> ‎[15:37] ‎<‎zyga‎>‎ Pharaoh_Atem: yep, --setopt=install_weak_deps=False
[19:41] <ShalokShalom> so, what are the alternatives? ship with an AppImage? :P
[19:41] <zyga> Pharaoh_Atem: yes, it is just used for install
[19:42] <cachio> pedronis, hehe, I can do it
[19:42] <ShalokShalom> or maybe ship with Debian, just takes *decades* until they decide its ready?
[19:42] <zyga> ShalokShalom: well, that's the right question to ask, from there you can come up with answers and some of those are actually better than the pipe to root
[19:42] <ShalokShalom> this is the answer
[19:42] <ShalokShalom> you decide to trust
[19:42] <ShalokShalom> the difference is from where this script comes
[19:42]  * sergiusens wonders if the conversation will just go in circles from here on
[19:42] <ShalokShalom> plus you can read it
[19:43] <ShalokShalom> its open source
[19:43] <ikey> sergiusens, i personally guarantee it from experience.
[19:43] <zyga> ShalokShalom: trust is out of the equation, this is just plain insecure at every level and is a nice way to exploit people, it's an opium for developers because it feels easy but it is not a real solution to the problem IMO
[19:43] <cachio> pedronis, I'll re build it in 1 hour
[19:43] <zyga> ShalokShalom: I will refer you again to the URL where you cannot inspect it if you copy-paste the command for install instructions
[19:43] <ShalokShalom> sergiusens: how do you think that people remember things?
[19:43] <cachio> pedronis, it should be quiet at that time
[19:44] <ShalokShalom> it goes always in circles, since this is how humans intelligible
[19:44] <zyga> ShalokShalom: I will just let you know that in snapd we take security very seriously and we don't recommend such things, you may take that as a green point we do :)
[19:44] <ShalokShalom> zyga: exploit that script
[19:44] <ShalokShalom> NOW
[19:44] <ikey> wtf
[19:45] <ShalokShalom> its easy
[19:45] <ShalokShalom> according to him/her
[19:45] <ShalokShalom> start
[19:45] <sergiusens> ShalokShalom: well, you can read the logs from time stamp N to M and iterate if you want to remember that way
[19:45] <ikey> FYI this isnt how conversations work..
[19:45] <popey> This conffrontational conversation isn't particularly welcome here.
[19:45] <zyga> ShalokShalom: I think you need to re-read what I said, I think I don't have any more arguments because you failed to understand the arguments I made earlier
[19:45] <nacc> zyga must have infinitely more patience than i do
[19:46] <ikey> cant we just get back to how awesome solus is?
[19:46] <ikey> xD
[19:46] <nacc> heh
[19:46] <ikey> imean snap
[19:46] <ikey> waat
[19:46] <zyga> ShalokShalom: for the sake of argument, my point is not that this is exploted and evil
[19:46] <Pharaoh_Atem> ...
[19:46] <zyga> ShalokShalom: but that it teaches you to do the wrong thing
[19:46] <ShalokShalom> insecure means its easy to exploit
[19:46] <zyga> ShalokShalom: and that lesson comes from exactly the kind of people that should care about security and integrity
[19:46] <ShalokShalom> you simply share blog posts who support your opinion
[19:46] <zyga> ShalokShalom: so in my opinion it is fair to question that
[19:47] <ShalokShalom> question it
[19:47] <Pharaoh_Atem> I know I'd never run a script that I'm told to curl | sudo bash :)
[19:47] <Pharaoh_Atem> that's just asking for trouble
[19:47] <zyga> ShalokShalom: I shared evidence to refute your claim that one can inspect the script contents
[19:47] <zyga> ShalokShalom: it is in fact not something you can inspect reliably
[19:47] <ShalokShalom> yeah, to drive in a car is also dangerous
[19:47] <Pharaoh_Atem> it's also possible to write obfuscated shell script
[19:47] <ikey> https://upload.wikimedia.org/wikipedia/commons/thumb/0/03/Circle-withsegments.svg/612px-Circle-withsegments.svg.png
[19:47] <ShalokShalom> according to statistic
[19:48] <sergiusens> ShalokShalom: please, can we get to the point of what all this conversation is about. Specifically on how it relates to snaps, snapcraft or anything that usually goes on in here?
[19:48] <ShalokShalom> it's also possible to write obfuscated _everything_
[19:48] <ShalokShalom> yeah, dodge it
[19:48] <zyga> ShalokShalom: note that it does not depend on obfuscation, quit the opposite
[19:48]  * zyga hugs sergiusens 
[19:49] <zyga> ShalokShalom: anyway, I think sergiusens is quite right
[19:49] <zyga> this is quite off topic
[19:49]  * ShalokShalom shakes his head
[19:52] <mvo> zyga: meh, still failing the PR from jamie :/
[19:52] <mvo> zyga: this may have to wait until tomorrow it seems
[19:52] <zyga> mvo: fix up
[19:52] <ikey> look sharp
[19:53] <ikey> ..sorry. xD
[19:53] <zyga> 3721
[19:53]  * zyga summons mup's power
[19:53] <zyga> oh mup, show the URL to the branch I just made
[19:53] <mup> PR snapd#3721 opened: tests: use dnf --refresh install to avert stale cache <Created by zyga> <https://github.com/snapcore/snapd/pull/3721>
[19:53] <zyga> thank you mup
[19:53] <mvo> zyga: oh, nice
[19:54] <zyga> ikey: next week we should look at those qemu images with solus snapshot that we can use to start running full system tests against
[19:55] <ikey> yeah that'd be sweet
[19:55] <ikey> uhm probably gonna have to build the images from solus itself (derpy package manager) but i can probably automate the initial creation of some qemu rootfs's
[19:55] <ikey> any particular image constraints i need to consider?
[19:55] <zyga> ikey: that's the goal
[19:55] <zyga> ikey: real images
[19:55] <ikey> so self contained bootloader?
[19:55] <ikey> or..?
[19:56] <zyga> ikey: ideally a disk image that I can just play with (or instructions on how to make one)
[19:56] <ikey> cuz i would hazard a guess you're using systemd units to set a target
[19:56] <zyga> ikey: hmm, I don't follow
[19:56] <ikey> and need cmdline control
[19:56] <zyga> ikey: well
[19:56] <zyga> ikey: not really, we ssh in
[19:56] <ikey> aah
[19:56] <ikey> ok so more at the cloud-init end of the spectrum
[19:56] <zyga> ikey: if you are curious just look at tests/ and spread.yaml
[19:56] <ikey> sure
[19:56] <zyga> ikey: basically we boot a system
[19:57] <zyga> ikey: and then start making stuff to it
[19:57] <ikey> aye
[19:57] <zyga> ikey: in snapd specifically we build the package out of the tree you are in
[19:57] <zyga> ikey: install it
[19:57] <zyga> ikey: and then run ~1000 different integration tests
[19:57] <zyga> ikey: that are all small snippets of shell described as task.yaml
[19:57] <zyga> ikey: in various directories under test/
[19:57] <ikey> so very cloud-init'y
[19:57]  * ikey approves :p
[19:58] <zyga> ikey: maybe, not that familiar with cloud-init :)
[19:58] <zyga> ikey: but it's simple and it works OK
[19:58] <zyga> ikey: we have abstractions for package installs and stuff like that
[19:58] <ikey> yeah its just a case of pumping instructions to a slave machine really
[19:58] <zyga> ikey: so most tests will need centralized poking to get going
[19:58] <ikey> yea
[19:58] <zyga> ikey: yes
[19:58] <zyga> ikey: we have several backends, qemu for local testing is a nice way to start but eventually we will want to upload a solus image to lindoe
[19:59] <zyga> ikey: where we can use it to test against incoming PRs
[19:59] <zyga> ikey: do you have a headless/server image (smaller)
[19:59] <ikey> eh
[19:59] <ikey> solus is "desktop only" xD
[19:59] <ikey> but I can cook something up for you
[19:59] <ikey> network-manager/kernel/sshd/
[19:59] <zyga> something minimal
[20:00] <ikey> we do something similar already for the solbuild backend
[20:00] <zyga> I think it's a common thing to test package builds
[20:00] <ikey> its a precooked rootfs that we use as the bottom layer in an overlayfs system
[20:00] <zyga> so yeah, I'm sure we can do this
[20:00] <zyga> yep
[20:00] <ikey> dramatically reduces initialisation cost
[20:00] <ikey> meaning i can build, say, nano, in a matter of seconds
[20:00] <zyga> we can also do lxd but we haven't used it in snapd much
[20:00] <zyga> *cough* at all *cough*
[20:00] <ikey> lol
[20:00] <zyga> ikey: I'm really tempted to install solus now you know
[20:01] <ikey> i could cook you an unstable ISO
[20:01] <zyga> ikey: my wife will hate me more for putting NaN+1 computers on my desk
[20:01] <ikey> we're split into unstable/shannon repos
[20:01] <zyga> ikey: please!
[20:01] <ikey> (yes, more water themes)
[20:01] <zyga> shannon?
[20:01] <ikey> i.e. river shannon
[20:01]  * zyga googles
[20:01] <ikey> in the old days we had a /v1/ repo
[20:01] <zyga> ah
[20:01] <ikey> then solus went rolling release
[20:01] <zyga> I read about the naming scheme somewhere
[20:01] <ikey> and we had to preserve /v1/ path for updates
[20:01] <ikey> but automatically migrate people to a *new* repo
[20:01] <ikey> so, shannon was born
[20:01] <niemeyer> pedronis: Was fedora last again?
[20:02] <zyga> Pharaoh_Atem: if you are still around, could you look at https://github.com/snapcore/snapd/pull/3721 quickly please?
[20:02] <mup> PR snapd#3721: tests: use dnf --refresh install to avert stale cache <Created by zyga> <https://github.com/snapcore/snapd/pull/3721>
[20:03]  * zyga takes a break for shower
[20:04]  * ikey bakes an ISO
[20:11]  * arm1e just finished eating the dirtiest donner kebab and he's not even drunk! YUMMY!!
[20:12] <cachio> niemeyer, was ubuntu-16.04-64 the last
[20:12] <niemeyer> cachio: So why did it take so long?
[20:13] <cachio> niemeyer, a lot of "no powered off servers in Linode account exceed halt-timeout"
[20:13] <arm1e>  nacc, right lets continue
[20:13] <cachio> niemeyer, I counted 19
[20:36] <niemeyer> cachio: Yeah, I see a lot of machines on right now
[20:36] <sergiusens> zyga: have you seen this -> https://github.com/snapcore/snapd-xdg-open/issues/6#issuecomment-321906336 ?
[20:37] <zyga> sergiusens: looking
[20:37] <niemeyer> cachio: and indeed most of them seem to be running for a few minutes rather than stuck
[20:37] <zyga> sergiusens: sweet, thank you
[20:37] <niemeyer> So we just have too much going on today?
[20:39] <niemeyer> 9mins, 18mins, 3mins... it's all churning
[20:39] <niemeyer> cc pedronis
[20:39] <zyga> yeah, possibly
[20:39]  * zyga EODs
[20:39] <zyga> I'll merge 3721 if it goes green
[20:39]  * zyga goes to spend some time with his son
[20:39] <cachio> niemeyer, yes, and we are adding more tests and workers
[20:39] <ikey> 3720 is stuck in a time warp
[20:40] <cachio> niemeyer, at some point we will need some extra machines I suppose
[20:41] <niemeyer> ikey: Not sure about 3720, but 3270 definitely is
[20:41] <niemeyer> ;)
[20:41] <ikey> heh
[20:41] <niemeyer> cachio: Not sure.. I'm curious about why do we have so many machines firing at once
[20:41] <arm1e> nacc: right, I am ready to fix this ba**ard!
[20:41] <niemeyer> cachio: IIRC, we have a limit of 3 jobs in travis
[20:41] <niemeyer> 3*20?
[20:41] <niemeyer> We have 70 machines
[20:42] <cachio> niemeyer, now, the count sohuld be 3 * 25
[20:43] <niemeyer> cachio: Ah, are we that far already?  That'd explain the issues we've observed today
[20:43] <cachio> niemeyer, yes
[20:44] <cachio> niemeyer, it started after I added an extra worker for fedora
[20:44] <arm1e> okay, i am settled in. Drink next to me, chocolate bar to the other side. Focussed on the laptop and ready to finish making this bloody snap - if anyone is able to hold my hand
[20:44] <cachio> and last week 2 workers for opensuse were added too
[20:44] <niemeyer> cachio: Oh
[20:45] <niemeyer> cachio: Okay.. definitely pushing the limits
[20:45] <cachio> niemeyer, so, this week we added 3 workers
[20:45] <cachio> yes
[20:46] <niemeyer> Alright.. I'll grab 10 more VMs..
[20:46] <niemeyer> I'm expecting a call from finance any day now.. :)
[20:46] <cachio> niemeyer, nice :)
[20:47] <niemeyer> arm1e: What's up there?  I'm sure somebody with an equal amount of drinks and chocolate might be able to help around here :)
[20:48] <arm1e> niemeyer: the prblrm ish thart tit wongt tompihsh annd I am confusgthed
[20:48] <arm1e> niemeyer: sorry, mouth full!!
[20:51] <arm1e> i want to be able to build snaps to help other users and enable more packages for other distros but I need to learn how to do it. I therefore decided to learn by doing. I completed the hello world stuff on the websites and have read the docs, so I decided to try an application. I am attempting get-iplayer:
[20:52] <arm1e> niemeyer: http://paste.ubuntu.com/25292206/ here is the yaml, but I am stuck
[20:52] <popey> Unfortunately you're breaking new ground because I don't think we have many perl snaps
[20:52] <nacc> arm1e: sorry, was afk, back now
[20:52] <arm1e> popey: get me :)
[20:53] <nacc> in this particular case, i think we don't need much perl support, per se
[20:54] <popey> basically dump the pl in, along with whatever other modules, set the environment up and you're done?
[20:54] <nacc> popey: that'd be my guess, yeah
[20:54] <nacc> popey: based upon what arm1e showed me before
[20:57] <tpatel> Which snapd version does install hooks introduced?
[21:00] <tpatel> which version of snapd supports install hooks?
[21:00] <pedronis> tpatel: the upcoming one (now in candidate), 2.27
[21:01] <tpatel> thanks pedronis
[21:02] <tpatel> Can we control start of more than 1 services? Like app1 then app2 and so on
[21:03] <zyga> woot green
[21:03] <tpatel> currently is done in alphabetical order
[21:04] <mup> PR snapd#3721 closed: tests: use dnf --refresh install to avert stale cache <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3721>
[21:05] <arm1e> nacc: so what exactly should I do next? YOu may have to dumb it down a lot
[21:11] <arm1e> Anyone else who wants to try to help me http://paste.ubuntu.com/25292206/ here is the yaml, but I am stuck
[21:12] <arm1e> team effort
[21:14] <mup> Bug #1710305 opened: installing any snap crashes with "failed to load system roots and no roots provided" <Snappy:New> <https://launchpad.net/bugs/1710305>
[21:20] <nacc> arm1e: ok, have you added an app?
[21:20] <nacc> arm1e: add an app first
[21:20] <arm1e> no problem. with a command field or just the app
[21:21] <nacc> arm1e: hrm? see the link i sent you on the snapcraft page earlier?
[21:22] <popey> apps:
[21:22] <popey>   get-iplayer:
[21:22] <popey>     command: get_iplayer
[21:22] <popey>     plugs:
[21:22] <popey>       - network
[21:22] <popey> ^ like that
[21:24] <nacc> popey: thanks :)
[21:26] <arm1e> what is the -network plug for? Just to allow access to the internet?
[21:28] <popey> ya
[21:28] <arm1e> snapping now
[21:29] <arm1e> slowly
[21:29] <arm1e> done
[21:29] <popey> you may need to create a launcher script
[21:29] <popey> which sets all the PERL env vars
[21:29] <popey> but I don't know which ones
[21:32] <nacc> more than likely you'll need to set PERL5LIB to point inside $SNAP somewhere so it looks in the snap fs for modules
[21:35] <ikey> 2017-08-11 20:43:17 Error executing autopkgtest:ubuntu-17.04-amd64:tests/main/refresh-all-undo :
[21:35] <arm1e> nacc: error -->http://paste.ubuntu.com/25292865/
[21:35] <ikey> i think it just network-broke..
[21:37] <nacc> arm1e: sorry, where do you get that error?
[21:37] <nacc> arm1e: it's best to provide the command you are running in the paste(s)
[21:37] <nacc> arm1e: otherwise i have no context :)
[21:37] <arm1e> installed the snap and ran the command get-iplayer (as defined in the yaml)
[21:37] <nacc> arm1e: ah is that when running the command?
[21:38] <nacc> arm1e: ok, so you see how INC has a bunch of paths in it?
[21:38] <nacc> arm1e: is this is a classic or confined snap?
[21:38] <nacc> ok, looks to be confined per the yaml
[21:38] <nacc> just in devmode
[21:38] <popey> devmode
[21:38] <arm1e> which is best?
[21:39] <nacc> arm1e: you should be abl to run someth9ing like `snap run --shell get-iplayer` and look around
[21:39] <nacc> that's the fs that your snap runs in
[21:39] <nacc> fs environment
[21:39] <nacc> i'm guessing you're missing some runtime package dependencies
[21:41] <nacc> arm1e: i think you're missing a stage-package of 'perl'
[21:41] <nacc> arm1e: which will pull in perl-modules which will install Env.pm in your snap
[21:43] <arm1e> will have a look now
[22:07] <arm1e> nacc: I have the required perl dependencies from the online docs for get-iplayer so I dont know how to fix this problem
[22:08] <nacc> arm1e: what do you mean?
[22:08] <nacc> arm1e: did you look in the shell?
[22:29] <arm1e> nacc snap run --shell get-iplayer does nothing
[22:32] <nacc> arm1e: no, it does something
[22:32] <nacc> it just may not seem like anything
[22:32] <nacc> it is putting you in a shell in the snap
[22:32] <arm1e> no, it errors out
[22:34] <arm1e> nacc: 'no tty present and no askpass program specified
[22:34] <nacc> arm1e: oh then it doesn't "do nothing", it "fails".
[22:34] <arm1e> ok hang on
[22:35] <nacc> arm1e: it's important to be specific since i'm doing a bunch of other stuff and not at your computer :)
[22:35] <arm1e> nacc: tried the command and it fails :p
[22:36] <arm1e> I can look in /snaps/get-iplayer
[22:36] <arm1e> is that the same?
[22:37] <nacc> arm1e: are you ssh'd in?
[22:37] <arm1e> no
[22:37] <nacc> arm1e: also, keep in mind, if you ran it once, and it succeeded, then you're in the snap shell
[22:37] <arm1e> just in normal terminal
[22:37] <nacc> so running it again won't work
[22:37] <arm1e> I might be in then as ls in home shows nothing
[22:38] <arm1e> What do I do now?
[22:40] <nacc> arm1e: right
[22:40] <nacc> arm1e: so you need to figure out if you can run perl
[22:40] <nacc> and if hwen you run perl, what @INC is set to, etc.
[22:40] <nacc> and if stuff is ther (like Env.pm)
[22:41] <arm1e> so how do i figure that out?
[22:42] <arm1e> i mean, how do i run perl?
[22:44] <nacc> arm1e: literally
[22:44] <nacc> arm1e: run `perl`
[22:45] <nacc> does it run?
[22:45] <arm1e> i tried that and it looked like it does but I still get the locale warning. Nothing about ENV tho
[22:48] <nacc> locale is probably fine
[22:48] <nacc> ok, then try to run your script
[22:48] <nacc> arm1e: you can use locate to find it, if it's not in a well-defined location (it might just be in .)
[22:48] <nacc> arm1e: and or /snap/bin
[22:48] <nacc> arm1e: and then debug why it won't start
[22:48] <arm1e> in the shell or out of it
[22:53] <arm1e> locate command not found
[22:55] <nacc> arm1e: bah, well, yeah, it won't be :/ -- you'll need to just look around in your snap
[22:55] <nacc> arm1e: it's probably in /snap/<snap-name>/current/ ...
[22:55] <arm1e> I can find the script in /snap/bin but it still gives the error
[22:55] <nacc> arm1e: right, you are now trying to *fix* the error :
[22:55] <nacc> :)
[22:55] <nacc> arm1e: by installing packages, etc, that maybe you are missing
[22:56] <arm1e> I cant find evidence of what the package is that is missing
[22:58] <nacc> arm1e: so normally you'd have a perl-modules installed, which has /usr/share/perl/5.24.1/Env.pm (with the appropriate version for 16.04)
[22:58] <nacc> arm1e: do you have that in your shell env?
[22:58] <arm1e> looking
[23:02] <arm1e> there is no Env.pm on the host machine in /usr/share/perl5
[23:03] <nacc> arm1e: not on the host machine, in the snap
[23:04] <arm1e> oh
[23:04] <arm1e> hold on
[23:05] <arm1e> nacc: Not in snap either
[23:08] <nacc> arm1e: then you're missing some dep
[23:09] <nacc> as i said
[23:09] <nacc> arm1e: did you try just dding perl to your stage-packages?
[23:09] <arm1e> will
[23:11] <ikey> https://plus.google.com/+Solus-Project/posts/8joLvCfgWrz
[23:11]  * ikey collapses in a corner
[23:15] <arm1e> nacc: re-snapped with perl as a dependency. Still get the same error. Very late now so going to bed but will try again tomorrow. Getting cloaser but still annoying!!
[23:16] <nacc> arm1e: ok
[23:16] <arm1e> nacc: thanks for the help so far
[23:17] <nacc> arm1e: yw