[05:12] <milani> Very quiet. Do developers speak somewhere else?!
[05:47] <pmp> milani: they are here usually, I get great answers most of the time.
[06:46] <miken> Quite a few of the snappy devs will be travelling to a sprint, which will go for this week, so it may be hard to get peoples' attention :)
[08:19] <ysionneau> ogra_ : hi! where do I open a bug for UDF not supporting armhf userspace + aarch64 kernel? is there a github or a launchpad bug tracker for UDF?
[08:37] <noizer> zyga
[08:37] <noizer> are you there?
[11:27] <zzarr> hello! I'm new to snap packages, is it possible to make a package with a graphical environment?
[11:29] <zzarr> I have a dragonboard 410c with a HDMI/USB connected touch screen
[11:29] <zzarr> I wish to run a custom application on it
[11:45] <blackout24> zzarr, Yes there are applications packaged as snaps with a GUI like the ubuntu-calculator app
[11:49] <zzarr> nice!
[11:49] <zzarr> thanks blackout24
[12:58] <jdstrand> blackout24: fyi "apparmor restrictions don't seem to work on symlinks". They *do* work on symlinks, in precisely the way they are supposed to, but not in the way you are wanting. ie, apparmor will necessarily resolve symlinks when doing path name lookups for security reasons. That said, modifying the launcher profile to do what you want on Arch should not be particularly difficult
[13:16]  * ogra_ curses the jetlag
[13:18] <davmor2> ogra_: you just need to sleep
[13:21] <ysionneau> ogra_ any link to the ubuntu-device-flash bug tracker page?
[13:34] <ogra_> ysionneau, try https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch
[13:35] <ogra_> davmor2, :P
[13:36] <ysionneau> ogra_: thanks a lot!
[13:39] <ysionneau> ticket created: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1579767
[13:46] <josepht> is running a snap application via sudo supported?
[13:47] <qengho> josepht: Er, I don't think it matters. "sudo foo", where foo is a snap app name?
[13:49] <josepht> qengho: 'nmap localhost' works but 'sudo nmap localhost' does not.
[13:51] <ogra_> how does it fail
[13:51] <qengho> Root PATH?
[13:51] <wsnipex> hi, after the removal of old-security from snappy, is there still some way to provide apparmor profiles/overrides?
[13:51] <qengho> Try "sudo /snap/bin/nmap"
[13:53] <wsnipex> the reason I'm asking is that current plugs/slots are not sufficient to make my app work
[13:54] <josepht> on pi2 it fails with: route_dst_netlink: can't find interface "lo"
[13:54] <ogra_> wsnipex: file a bug
[13:55] <wsnipex> ogra_, on launchpad?
[13:56] <josepht> same on amd64 classic
[13:57] <ogra_> wsnipex: indeed
[13:57] <jdstrand> wsnipex: no. you can install the snap with --devmode to unblock you then file bugs at https://bugs.launchpad.net/snappy/+filebug addng the `snapd-interface` tag.
[13:58] <josepht> where "lo" is which ever interface nmap tries to use
[13:59] <wsnipex> jdstrand, bugs for what exactly? that the existing plugs will probably never be sufficient to make kodi work? or that there is no possibility to override apparmor/seccomp anymore?
[14:00] <ogra_> uuh, indeed we will get to a point where the plugs are sufficient to run kodi at some point
[14:00] <ogra_> else we would have failed
[14:01] <wsnipex> good to hear
[14:01] <ogra_> but we need to know which bits are missing, so we need bugs from you
[14:01] <jdstrand> wsnipex: a bug on what you want
[14:01] <jdstrand> wsnipex: in terms of new interfaces
[14:01] <jdstrand> wsnipex: what denials are you seeing, why you need that functionality, what the interface should look like, code, etc
[14:02] <wsnipex> I need at least this: https://github.com/wsnipex/xbmc/blob/246f93c30d51e8111e8ff8a6c268f7fb62643d9a/tools/Linux/apparmor-snap.kodi.kodi#L418
[14:02] <wsnipex> and its certainly not everything, since I didn't test all use cases by far
[14:03] <jdstrand> please file a bug
[14:03] <ogra_> the pulse interface is underway
[14:03] <ogra_> not sure you will get access to fstab though
[14:04] <wsnipex> I'm actually expecting that some of those might be refused
[14:04] <ogra_> or to the /media mountpoints
[14:04] <wsnipex> but what good is a media center without access to media ;)
[14:04] <ogra_> access to the homedir (and Video underneath etc) is there already
[14:04] <wsnipex> I know
[14:05] <wsnipex> but automounts usually end up on /media
[14:05] <jdstrand> wsnipex: no need to be fatalistic. file the bug and we'll see how this should work
[14:05] <wsnipex> ok
[14:06] <jdstrand> interfaces are different than the previous 'caps' model. there is more flexibility, etc
[14:06] <ogra_> jdstrand: i wonder if we shouldnt make the automounts end up in home somehow ... at least the user specific bits
[14:07] <ogra_> (through some provileged link or some such... without touching the actual implementation of udisks)
[14:07] <jdstrand> that gets tricky since the user has control of the directories things would be mounted into
[14:08] <ogra_> well, does he on a core install ?
[14:09]  * ogra_ thinks we'll bang our heads against quite a bunch of differences between desktop and core for the near future
[14:13] <josepht> journalctl -xe shows: audit: type=1400 audit(1462802034.408:65): apparmor="DENIED" operation="open" profile="snap.nmap.nmap" name="/proc/31883/net/dev" pid=31883
[14:14] <wsnipex> heh: /proc/@{pid}/net/dev r,
[14:19] <jdstrand> I think I added that to trunk recently
[14:39] <blackout24> jdstrand, thanks. Still hitting a wall right know trying to launch apps through ubuntu-core-launcher. I think I'll try compiling my kernel from the v4.4-aa3.5-beta1 branch instead of v4.5-aa.3.5-beta1 branch.
[14:46] <noizer> Hi guys, I asked one week ago something about Soft Floating. Zyga answerd my question then you need to make a chroot and compile it then en check if it works then. But how can I check if my chroot is correctly?
[14:49] <noizer> Or does somebody knows when Zyga is back?
[14:52] <jdstrand> noizer: zyga is sprinting this week. I suspect he will be online in an hour or so, but due to sprinting, may not be terribly responsive
[14:53] <noizer> jdstrand: Ok maybe someone else can help me out for now
[14:53] <noizer> jdstrand: Do you know mutch about chroot ...
[14:56] <jdstrand> noizer: I don't have any info on your question ("how can I check if my chroot is correctly?")
[14:56] <sborovkov> Hello. I've asked about this around 2 weeks ago and at that time this was not working - snap install snap-name config.yaml. Does anyone know when this will be working?
[14:57] <noizer> jdstrand: wait I will explain it totally.
[14:57] <jdstrand> sborovkov: snappy config is not back yet
[14:57] <jdstrand> I don't have an eta
[14:58] <jdstrand> sborovkov: JamieBennett could give an eta. see the above re people sprinting
[14:59] <noizer> I want to implement Nuance TTS on my snappy device on a rpi2 or 3. now the problem is raspberry pi 2 and 3 are hard float systems. Nuance works only with soft-float systems on ARM linux. What zyga told me is to debootstrap a arm soft-float system. mount /proc and sys and then chroot the debootstrapped build. Compile there my application with the Nu
[14:59] <noizer> ance TTS and then run.
[15:00] <noizer> jdstrand: now i compiled it and tested it but I have some problems maybe it isnt fully soft floating or I don't now what the exact problem
[15:00] <sborovkov> jdstrand: understood, thanks
[15:00] <qengho> Hmm, I don't think compiling on the same CPU is very important, but being on a no-hard-float CPU is important for testing.
[15:01] <jdstrand> noizer: I'm going to defer to others who have experience in this area
[15:03] <noizer> jdstrand: qengho What i done now is compiled it on a raspberry pi 1
[15:03] <zyga> good morning
[15:03] <noizer> zyga good morning
[15:03] <qengho> noizer: Great. I think you could have compiled anywhere, including amd64.
[15:04] <zyga> noizer: good morning
[15:05] <qengho> noizer: You have to make sure that your compiler emits ARM instructions for the CPU you are targeting. That's all. It's not a chroot trick. It's a configuration trick.
[15:06] <qengho> noizer: The important thing here is that even if you were on a RPi1, it could have been making instructions for hard-float CPUs. Compiling has nothing to do with running.
[15:07] <noizer> qengho: zyga hmm wait I got an *.so file from Nuance that is compiled with soft-floating. and I made an applicatoin with it and compiled it against the *.so file from nuance
[15:07] <noizer> but it should work?
[15:07] <qengho> If everything you just said is true, then it should have no hard-float problems.
[15:08] <zyga> noizer: hey, I'm going to be busy sprinting this week
[15:08] <noizer> zyga:  ok qengho is helping right now but thanks forallthe help you gave me?
[15:09] <qengho> noizer: Make sure your app -- the place YOU are running gcc or clang or whatever -- is making the right instuctions. Read its man page. When you compile, you are responsible for making sure what you're making is what you intend. The computer does not read minds. Tell it. Make sure. Read man pages.
[15:26] <josepht> jdstrand: does my snap need to be rebuilt for the /proc/@{pid}/net/dev change that landed in trunk recently?
[15:27] <jdstrand> it was added to trunk (I just checked), you do need trunk's snapd on your device. you will have to reinstall the snap
[15:28] <josepht> jdstrand: ack, thanks
[15:30] <ogra_> mvo, the livecd-rootfs change looks fine
[15:34] <noizer> qengho: So soft-floating works can work on a hard floating system?
[15:36] <qengho> noizer: yes. "floating point routines implemented in {soft,hard}ware". Some CPUs have instructions that handle the math faster, in silicon. If you don't' have it, you have to change the numbers into something you can compute in software, which is slower.
[15:38] <noizer> qengho: i know but what is a good way to change a standard Hard floating system in a soft floating system? what I done for now is made a chroot for it
[15:38] <qengho> noizer: The Right Way™ is to compile both, and test which path to take. But that's harder to get right. (Trust me. I know.)
[15:39] <qengho> noizer: I can't help you with your program. I have things I must finish.
[15:44] <noizer> qengho: ok np I will try further
[16:18] <josharenson> How can I build a snap to run on my Pi2? I have it built on my amd64 box, but it won't cross compile and it doesn't seem that snappy has snapcraft available as a snap. Do I need a non-snappy armhf system to do this? (which isn't that bad because I guess I can use my phone)
[16:18] <qengho> I found a Pandaboard ES b1 on my bookshelf yesterday, while cleaning. I'm pretty excited to try it out too.
[16:19] <qengho> If it doesn't work, I'm just going to mail it to rsalveti. He will find a use for it.
[16:19] <josharenson> qengho: I have an old one with several hundred days of uptime in my closet :-)
[17:13] <sborovkov> josharenson: I am using MATE to build snap for RPI
[17:13] <sborovkov> on RPI
[17:14] <josharenson> sborovkov: so essentially the solution I proposed.. A non-snappy armhf system :-/ what a bummer
[19:01] <popey> i build on my pi
[19:02] <popey> with a snappy install using classic dimension
[19:02] <popey> works well
[21:39] <kyrofa> josharenson, you should use the Launchpad armhf snap builder-- way faster than building on-device
[21:39]  * josharenson looks
[21:40] <kyrofa> josharenson, you can actually build your snap for all supported architectures that way
[21:40] <kyrofa> josharenson, and it's fast
[21:40] <josharenson> kyrofa: have a link to some docs?
[21:40] <kyrofa> josharenson, not actually documented I'm afraid, but you know what... I'll do that now
[21:41] <josharenson> kyrofa: haha ok, thanks
[21:41] <josharenson> kyrofa: I assume its similar to how PPAs work?
[21:41] <josharenson> that are built on lp
[21:41] <kyrofa> josharenson, easier, even
[21:41] <josharenson> kyrofa: of course, cause snappy :-)
[21:42] <kyrofa> josharenson, you just need your code on LP somewhere-- pushed to junk, pushed to a project, etc.
[22:17] <Kamilion> kyrofa: I'd also like to know of that documentation once it exists
[22:18] <kyrofa> Kamilion, almost done, I'll ping you both
[22:18] <kyrofa> Kamilion, just a quick and dirty walkthrough-- it should be actually documented by launchpad, but that's not me
[22:18] <Kamilion> Cool, thanks.
[22:18] <Kamilion> no worries, used to it
[22:19] <Kamilion> https://launchpad.net/~kamilion  <--- been doing it a while.
[22:27] <kyrofa> Kamilion, josharenson, hope this helps: https://rainveiltech.com/posts/building-your-snap-on-device-there-s-a-better-way
[22:28] <Kamilion> huh. How's owncloud been recently? I bailed like a year and a half ago after a mass exploit of owncloud vms.
[22:30] <kyrofa> Kamilion, I use it anyway
[22:31] <kyrofa> Kamilion, I like being able to share my calendar and files with my wife, etc.
[22:31] <kyrofa> Kamilion, and sync my contacts between my phone and laptop, etc.
[22:31] <Kamilion> has security been any better recently?
[22:35] <Ayyad> kyrofa, good read.. thank you
[22:38] <JanC> you can always run owncloud where it's only accessible through a tunnel/VPN or something like that, I guess
[22:38] <kyrofa> Ayyad, no problem!
[22:38] <kyrofa> Kamilion, I'm not an owncloud dev... I guess I can't speak to the security
[22:38] <Kamilion> kyrofa: fair enough
[22:39] <Kamilion> JanC: ssh tunneling has a very low WAF
[22:39] <Kamilion> https://en.wikipedia.org/wiki/Wife_acceptance_factor
[22:39] <kyrofa> Kamilion, but at least snappy makes the exploits less useful :)
[22:39] <Kamilion> (not web application firewall)
[22:39] <Kamilion> yeah, in theory
[22:40] <Ayyad> Kamilion, yeah.. I was wondering how that makes sense :D
[22:40] <Kamilion> https://mjg59.dreamwidth.org/42320.html
[22:40] <JanC> Kamilion: obviously whatever you use for tunneling would require pre-configuration
[22:41] <kyrofa> Kamilion, https://askubuntu.com/questions/760803/security-of-snaps-under-x11/760813#760813
[22:41] <kyrofa> Kamilion, owncloud doesn't use X :)
[22:41] <Kamilion> hahah, there IS no protection through X11
[22:41] <Kamilion> any application can just grab the keyboard or mouse or sendkeys to applications
[22:41] <kyrofa> Exactly
[22:41] <Kamilion> because That's Just How X Works
[22:42] <Kamilion> thankfully wayland doesn't have the same issues
[22:42] <kyrofa> Kamilion, yeah, mir doesn't either
[22:42] <Kamilion> ooh, is there a working wayland snap yet?
[22:42] <Kamilion> kyrofa: uh, yes it does
[22:42] <Kamilion> mir just kinda sticks two existing X components togther in an unholy mash of wtffery
[22:43] <Kamilion> it's still using many of the major x libraries, unfortunately
[22:43] <Kamilion> it's not like we could blame xorg or xfree86 either, they're working off the X Consortium's specs
[22:47] <Kamilion> (and if I'm currently mistaken about Mir, I apologise, the only real information I have on it is from around 2012 and a lot of stuff might have changed)
[22:47] <Kamilion> but last I knew the best description of it was "we embedded a window manager into the display server so we can call it a compositing server now"
[22:48] <Kamilion> I went with wayland myself
[23:05] <nhaines> That's... not how Mir works.