[07:39] <svij> is there no "snap update" command, or will it update automagically?
[07:40] <zyga> svij: it's snap refresh
[07:41] <svij> ah I see, is there no command to update all snaps, rather than one single with refresh? (I don't need it right now, just curious)
[07:43] <zyga> svij: it will be refresh, just not implemented yet
[07:43] <svij> zyga: ah okay
[07:43] <svij> thx
[07:57] <dholbach> kyrofa, sergiusens: once you're both up, can we chat about the snapcraft sessions at UOS and get them scheduled?
[08:02] <slvn> jdstrand, zyga, about SDL2 failling with UDEV for Initialization of INIT_Joystick. That happens when calling "udev_monitor_new_from_netlink", and apparmor says :  audit: type=1400 audit(1461830101.683:1127): apparmor="DENIED" operation="create" profile="snap.MyApp.app" pid=11228 comm="MyApp" family="netlink" sock_type="raw" protocol=15 requested_mask="create" denied_mask="create"
[08:02] <slvn> (maybe I need to use the plug network ?)
[08:02] <zyga> slvn: I suspect that will stay denied for a while unless netlink support in apparmor is improved, for now I'd compile joystick support out
[08:03] <slvn> zyga, it's not blocking anyway.. joystick is just not initialized.. just report the issue
[08:03] <zyga> ah, ok
[08:06] <slvn> zyga, also audio was failing, but it's not *killing* the apps, it just stays not initialized.
[08:13] <slvn> zyga, just correcting myself, in fact, audio pulse if really failling (.shm_open() failed: Permission denied). So I need to desactivate it.
[08:17] <zyga> slvn: we know about audio, we'll get something supported, if you check the backlog we discussed this issue last night
[08:17] <zyga> slvn: there are still a few things to decide before that can happen but we do know about it
[08:19] <slvn> zyga, ok
[08:45] <ysionneau> about Mark shuttleworth's email : what's "GA" ?
[08:48] <zyga> ysionneau: general release?
[08:48] <ysionneau> A for Release ? :o
[08:51] <zyga> availability? :)
[08:54] <zyga> globally awesome release :)
[08:55] <Gunther_> hehe we also discussed the meaning of "GA" here :)
[08:59] <ysionneau> :)
[09:00] <vijaikumar> General Availability
[09:05] <ysionneau> thanks
[09:29] <Gunther_> latest allsnaps: sudo snap remove trionet error: can't remove "trionet": cannot find mounted snap "trionet" at revision 100001
[09:29] <Gunther_> :(
[09:31] <Gunther_> did work before, but at one time complained about: sudo snap remove trionet [-] Remove snap "trionet" from the system error: cannot perform the following tasks: - Remove snap "trio
[09:31] <Gunther_> and after reboot I am stuck
[09:32] <zyga> Gunther_: it's known broken for now
[09:32] <zyga> Gunther_: will be fixed with the next SRU
[09:32] <zyga> Gunther_: you can use my script to reset snap state: github.com/zyga/devtools
[09:33] <zyga> Gunther_: look at reset-state
[09:33] <Gunther_> ok thanks
[09:33] <zyga> Sorry for the bad experience
[09:33] <Gunther_> no problem, I am developer myself
[09:38] <Gunther_> zyga: worked great ;-) all snaps removed including the kernel (ooops)
[09:38] <zyga> Gunther_: ooops
[09:38] <zyga> Gunther_: this was tested on the desktop
[09:39] <zyga> Gunther_: it would need some love on devices
[09:39] <zyga> Gunther_: can you look at what would be needed to make it work there and fix it please
[09:39] <Gunther_> zyga: I ll try
[09:40] <dpm> oh, I just discovered a nice snap trick: https://bugs.launchpad.net/snappy/+bug/1574829/comments/1
[09:40] <dpm> snap without sudo
[09:53] <asac> pitti: where is the rename of wlan0 to wlxXXXXXX done? I couldnt find the matching rule in udev
[09:54] <pitti> asac: in xenial release it is still /lib/systemd/network/90-mac-for-usb.link
[09:55] <asac> ahh... /me was already thinking maybe its in systemd
[09:55] <pitti> asac: however, that will change soon (also in xenial) to /lib/udev/rules.d/73-special-net-names.rules due to bug 1574483
[09:55] <asac> ok gotcha... let me study the .link file a bit though so i know how that works
[09:56] <pitti> asac: see /usr/share/doc/udev/README.Debian.gz
[09:56] <pitti> that still refers to a wrong name (01- instead of 90-)
[09:57] <qengho> My gnome-disks UI looks pretty hilarious after using snappy for a while.
[10:53] <zyga> _morphis: hey, you should be able to rebase n-m interface on top of https://github.com/ubuntu-core/snappy/pull/1078 now
[10:53] <_morphis> zyga: awesome!
[10:53] <_morphis> will do, thanks a lot for that!
[10:54] <zyga> _morphis: https://github.com/ubuntu-core/snappy/pull/1078/files#diff-939866a2238749d2c6989a8a757f430f
[10:54] <keestu> Hi, I use ubuntu since last 5 years. I came across  about the snappy. I have dev embedded board, and i have a question now.  Is it possible to get ubuntu core into the this embedded device ?
[10:55] <zyga> keestu: yes, you need a kernel that works there and a supported bootloader
[10:55] <zyga> keestu: though right now devices (boards) are in rapid development after 16.04 release so expect a lot of changes in the next few weeks
[10:56] <keestu> zyga,  thanks, my knowledge is petty limited to this. I have a board, where we port android, linux with qt, how snappy is going to be different ?
[10:57] <zyga> keestu: if you have a working kernel, it should be not much different
[10:57] <zyga> keestu: the only requirement is a supported arch, what SoC
[10:57] <zyga> keestu: (you don't build snappy entirely from source,)
[10:58] <zyga> keestu: you just buld the kernel and gadget snaps, the rest is stock and shared by all devices
[10:58] <keestu> so, snappy is a way to get the customized desktop feel in embedded device ?
[10:58] <zyga> keestu: snappy has no desktop feel
[10:58] <zyga> keestu: anyway, please familiarize yourself with the documentation on snappy that's available on ubuntu.com now
[10:59] <keestu> zyga,  i am looking at the business perspective.  We see the customers demanding porting android to our embedded device.
[10:59] <keestu> zyga, sure.
[11:00]  * zyga -> lunch
[11:00] <keestu> :)
[11:00] <keestu> bon appetit
[11:15] <slvn> zyga, another issue snap+SDL2+x11. At first install (after reset-state), it doesn't connect to x11. I need to remove the snap, then reinstall it. then it can connect to x11. The syslog error was "apparmor="DENIED" operation="connect" profile="snap.MyApp.app" pid=22559 comm="MyApp" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0"
[11:15] <slvn> peer="unconfined"
[11:20] <ogra_> ppisati, have you seen bug 1574103 ?
[11:20] <ogra_> and bug 1574075 might also be interesting
[12:03] <sergiusens> dholbach I will have to rain check on that and ask for it to be in a couple of hours; both kyrofa and myself are unavailable right now
[12:08] <seb128> sergiusens, can parts/files have dynamic values?
[12:08] <seb128> like "somelib: /usr/lib/$(ARCH)/somelib"?
[12:08] <seb128> sergiusens, hey btw :-)
[12:19] <jdstrand> slvn: fyi, you need to plugs either unity7 or x11. did it not autoconnect?
[12:25] <slvn> jdstrand, both are in the plugs list (and also opengl) of the snapcraf.yaml file
[12:26] <slvn> maybe the reset-state script is incomplete ?
[12:26] <jdstrand> slvn: would you mind filing a bug for that? show your snapcraft.yaml, how you installed, the denial and the policy in /var/lib/snapd/apparmor/profiles/snap.MyApp.app
[12:27] <slvn> first install -> x11 doesn't work. then remove, and install again. it works
[12:27] <jdstrand> slvn: and please add that detail :)
[12:28] <slvn> jdstrand, yep. I go away now, but I will re-try that later and fill a report.
[12:28] <jdstrand> slvn: thanks. others have seen this but I don't think there is a bug
[12:29] <slvn> jdstrand, if first install always fail to launch, it's kind of problematic for me :)
[12:29] <jdstrand> slvn: very much indeed :)
[12:29] <bencc> can I package an erlang app with snappy and do hot code upgrade?
[12:30] <slvn> jdstrand, but i'll double check later and let you know! ++
[12:30] <bencc> upgrade the code while the app is till running?
[12:30] <dholbach> sergiusens, I'll have to leave at 16:00 or 16:15 UTC today - it'd be good if we could talk about it before
[12:42] <zyga> slvn: you can always connect manually but I'm wondering why auto-connect did not work
[12:42] <zyga> slvn: thanks, I'll investigate this
[13:05] <wesleymason> Snapcraft Q: is there a variable representing the install stage path that I can, for example, pass to a makefile to tell the target where to install into
[13:05] <wesleymason> ?
[13:07] <kgunn> zyga: just confirm, if i change something in snap, go build it and snapd, copy over and fire up snapd...i should see the change i made in snap?
[13:08]  * kgunn swears he saw this before, hopes he's not going crazy
[13:08] <zyga> kgunn: in a meeting, you need to copy snapd (and restart it, devtools helps)
[13:08] <zyga> kgunn: for security changes disconnect and reconnect
[13:08] <kgunn> zyga: was doing pkill -9 snapd, then starting
[13:08] <oparoz> wesleymason, $SNAPCRAFT_STAGE
[13:09] <zyga> not really
[13:09] <zyga> kgunn: try github.com/zyga/devtools
[13:09] <zyga> there are more bits and magic there
[13:09] <zyga> and it's all made for this use case
[13:09] <wesleymason> oparoz: great, cheers
[13:09] <kgunn> zyga: ok
[13:09] <kgunn> so i can't just go build snap/snapd, copy over?
[13:10] <zyga> you can but you need more, devtools does all that
[13:10] <zyga> and more :-)
[13:10] <zyga> try it
[13:10] <kgunn> ok, i may need help, cause my vm i use for mir isn't the standard one
[13:10] <zyga> syure
[13:10] <zyga> sure*
[13:10] <kgunn> mainly ssh  config i suppose
[13:11] <oparoz> Is there a recommended way to use start-stop-daemon in init scripts? Default policy doesn't allow scripts to call it
[13:12] <ogra_> first of all you would have to ship it in your snap :)
[13:13] <ogra_> (and then i dont think it would be accepted or used at all in the end ... given we use systemd in snappy )
[13:14] <oparoz> ogra_, I get "access denied", so it must be there, just not allowed. The way I understand it is that systemd calls whatever start script is given to it, so it shouldn't be an issue to call this command, no?
[13:15] <kgunn> zyga: actually...i got it....devtools talking to my vm, i see devtools.snap in there :)
[13:15] <kgunn> relying on magic now
[13:15] <ogra_> oparoz, it is a tool from sysvinit scripts ... it should really not be used at all in systemd envs
[13:16] <ssweeny> jdstrand, zyga, is there a recommended way to do service logging in snappy? My location-service snap is trying to create /var/log/location-service which obviously isn't going to work
[13:16] <zyga> kgunn: cool, just use refresh-bits (it has --help and is trivial to read)
[13:16] <zyga> ssweeny: I don't think there is one, maybe just let systemd manage logging
[13:16] <zyga> ssweeny: but I don't really know
[13:16] <ssweeny> zyga, ok, thanks
[13:16] <ogra_> ssweeny, "snappy service logs" used to do that ...
[13:16] <zyga> kgunn: I will gladly take patches for new features
[13:16] <kgunn> zyga: hmmm, with latest tools...do i have to sudo snap for such things as "snap list" ?
[13:16] <ogra_> i would expect that to be back once the snap service command comes back
[13:16] <zyga> kgunn: yes, because the socket is root-owned
[13:17] <zyga> kgunn: or chmod 666 /path/to/socket (/var/snapd.socket AFAIR)
[13:17] <zyga> kgunn: it's not handled by devtools because I was always lazy and using sudo
[13:17] <kgunn> that's right...i see a note
[13:17] <kgunn> ok, fully relying on devtools...and i still don't see my mod
[13:17] <zyga> kgunn: if you get it supported, just send me a patch please, I was annoyed by this once and there was one bug hidden by this already
[13:17] <zyga> kgunn: what's the mod about? policy change?
[13:18] <zyga> kgunn: you should connect/disconnect or remove/install the snap because there is no logic that detects interface implementation changes yet
[13:18] <zyga> kgunn: you should also check generated profiles (/var/lib/snapd/{apparmor,seccomp}/profiles
[13:19] <jdstrand> ssweeny: if you want your own log, you need to change the path to somewhere in SNAP_DATA
[13:19] <ssweeny> jdstrand, yeah that was my other thought
[13:20] <zyga> jdstrand: hey, gustavo recommended that we work on making n-m interface supported on the desktop; it would also unblock a bunch of prospective snaps; can you tell me if the current policy there is safe for desktop use?
[13:20] <jdstrand> ssweeny: (if you don't want systemd to handle it-- with systemd it will capture stdout and stderr and you can use journalctl to see the output from your service)
[13:20] <kgunn> jdstrand: isn't there a command line to list interfaces?
[13:20] <zyga> jdstrand: (just comment on the pull request anytime you have a moment to look at it)
[13:20] <kgunn> i thot i recalled that...couldn't find the email
[13:20] <zyga> kgunn: snap interfaces
[13:20] <kgunn> dang it...soo simple
[13:20] <kgunn> shoulda guessed
[13:20] <zyga> :-)
[13:21] <seb128> does anyone know if parts/files have dynamic values?
[13:21] <seb128>  like "somelib: /usr/lib/$(ARCH)/somelib"?
[13:21] <ssweeny> jdstrand, ah so I can just change logging to stdout and stderr and systmd will take care of it for me? cool
[13:21] <zyga> seb128: I don't think they do
[13:21] <seb128> :-(
[13:21] <zyga> seb128, kyrofa: or sergiusens would know
[13:21] <zyga> seb128: what are you trying to build?
[13:21] <seb128> they are not around though
[13:21] <seb128> a GTK app
[13:21] <zyga> seb128: you can use $SNAP_ARCH
[13:21] <zyga> seb128: it's an env variable we set
[13:21] <seb128> to install thing?
[13:21] <jdstrand> ssweeny: note, it will also show up in syslog, but yes
[13:21] <zyga> seb128: you'd have to do a wrapper for it though
[13:21] <zyga> (or patch gtk)
[13:21] <seb128> at build time?
[13:21] <zyga> seb128: no, at runtime
[13:22] <seb128> that doesn't interet me
[13:22] <zyga> seb128: for build-time i don't know
[13:22] <zyga> (I'm hacking on the other side)
[13:22] <zyga> seb128: I'd recommend starting with amd64, then working with snapcraft hackers to generalize
[13:22] <jdstrand> zyga: re nm-- we had a rather lengthy discussion on that at the eod yesterday but I didn't think we came to a conclusion. but to specifically answer your queston, no, the nm policy is not safe for confined apps-- it grants too much privilege
[13:23] <zyga> seb128: for the runtime part I think we should perhaps explore patching some bits to understand snap runtime layout
[13:23] <zyga> jdstrand: ok, could we do a simple version for now that still works on the desktop and land that, iterating on a broader one using some other ways (attributes, more ifaces)
[13:23] <seb128> zyga, I'm on i386 so starting with amd64 is not going to work for me :p
[13:23] <zyga> jdstrand: I think the key is to ensure that we don't leave the desktop as we progress
[13:24] <zyga> seb128: oh, sorry
[13:24] <zyga> seb128: i386 is fine though, it's just a suggestion to try to solve the simpler problem first
[13:24] <seb128> right
[13:24] <seb128> well I've the arch coded
[13:24] <seb128> but I wanted to push that so jdstrand and others can play with it
[13:24] <jdstrand> zyga: I feel like I am missing context. we left it yesterday that we need more discussion for the desktop case
[13:24] <seb128> but it sucks if everyone needs to sed the arch before building
[13:25] <zyga> jdstrand: I just talked about this in the standup, gustavo recommended that we ensure it works on the desktop before it lands
[13:25] <jdstrand> well, then I need to understand the direction
[13:25] <jdstrand> zyga: did niemeyer_ comment in the pr?
[13:25] <zyga> jdstrand: checking
[13:27] <zyga> jdstrand: nope
[13:27] <zyga> there's the community sync in 3 minutes
[13:27] <zyga> let's continue that after if you have time, otherwise let's do it by email
[13:28] <jdstrand> zyga: email is probably best so everyone has context
[13:31] <seb128> did anyone look at snap and translations?
[13:31] <seb128> what would be the right place to discuss the topic/put notes?
[13:31] <seb128> list? launchpad pad? spec?
[13:34] <ogra_> seb128, UOS ? :)
[13:39] <ppisati> ogra_: ack
[13:40] <seb128> ogra_, right, because that's going to be useful if nobody of the snappy team is interested and joining
[13:41] <seb128> is there any plan to mount some part of the snaps to normal system locations?
[13:41] <seb128> rather than trying to make everything reallocatable?
[13:42] <seb128> mvo, hey, do you know if it somebody discussed making locales part of the core image before?
[13:43] <ogra_> i think that was discussed and deemed to be to space hungry
[13:44] <ogra_> (given it was designed for embedded without actual users)
[13:44] <zyga> seb128: I doub't that
[13:44] <zyga> (not relocatable)
[13:44] <seb128> zyga, :-(
[13:44] <ogra_> seb128, i suspect we're moving into -pd territory ...
[13:44] <seb128> ogra_, are such gaps documented somewhere? launchpad bugs?
[13:44] <ogra_> not that i know of ...
[13:45] <zyga> seb128: I think that would be against the idea of snappy
[13:45] <ogra_> but i personally wouldnt see locales as something to have in core ...
[13:45] <seb128> ogra_, you would see each application needing to ship the libc locale definition?
[13:46] <seb128> + to patch glib to allow relocating those
[13:47] <caio1982> hi there, i am snapping a system monitor tool and i wonder what plugs would be necessary to access /proc/vmstat and a given /etc file like /etc/mtab... is there one?
[13:49] <ogra_> seb128, well, a snap *has to be* completely inependend from the core system,. they always need to be separately upgradeable ...
[13:49] <ogra_> thats one of the base definitions of snappy
[13:50] <seb128> ogra_, with, snaps don't have to ship their own libc, do they?
[13:50] <ogra_> they can
[13:50] <seb128> but don"t have to?
[13:50] <ogra_> thats the one thing they could use ... but nothing stops you to ship your own
[13:51] <seb128> well, shipping your translations, fine
[13:51] <seb128> having to ship the glibc locale definitions
[13:51] <seb128> I doubt it's something any appdev is going to want
[13:51] <seb128> also glibc doesn't support relocating those
[13:52] <ogra_> well, but shipping them in core means you add a dependency
[13:52] <seb128> depends to what?
[13:52] <seb128> snaps depends on the core anywhy
[13:52] <seb128> anyway
[13:52] <ogra_> between the system and the snap
[13:53] <ogra_> i.e. what if glibc locale handling code changes in incompatible ways in the system snap
[13:53] <ogra_> you would need something liek a versioned dependency
[13:59] <seb128> ogra_, you are saying "what if glibc changed in an incompatible way", but that's already an issue since you don't force snaps to ship a copy of glibc
[14:00] <ogra_> sure
[14:01] <seb128> if you have this stance it's fine, but then be consistent and force snaps to include a libc copy
[14:01] <dholbach> niemeyer, which time between 14 and 20 UTC would work for you for an interface session next week (3-5 May)?
[14:01] <dholbach> zyga, ^ too
[14:01] <seb128> if you allow them to rely on the core one there is no point to say that can only be for some parts of libc
[14:02] <zyga> dholbach: any except standups but I'm flexible
[14:02] <ogra_> seb128, right, the "it is useless on headless IoT systems without users" thing is still valid though ...
[14:02] <ogra_> we'd need two core setups
[14:02] <seb128> unsure
[14:03] <seb128> you might want your ls, etc to be in german
[14:03] <ogra_> which ls ?
[14:03] <seb128> your commands on the core
[14:03] <ogra_> on my router i only have that web UI :P
[14:03] <seb128> well, you might want that webui in german
[14:03] <ogra_> on my drone i even only have that mobnile app that talks to it
[14:03]  * zyga checks backlog
[14:04] <ogra_> sure, but for that i dont need glibc locales necessarily
[14:04] <seb128> right
[14:04] <seb128> we need frameworks :p
[14:04] <ogra_> good idea !
[14:04] <zyga> seb128: though ogra was spot on on pocket-desktop area, I think on personal the core snap could provide you with a gtk runtime interface
[14:04] <ogra_> uh
[14:04] <zyga> seb128: so if you want that runtime to be something you depend on, great, but I don't know if that's exactly what we want to do with gkt
[14:04] <ogra_> a whiole runtime is to much imho
[14:04] <zyga> seb128: perhaps for SDK runtime first
[14:05] <zyga> seb128: we don't need frameworks, we need interfaces
[14:05] <zyga> seb128: anything that a framework could do is doable with a new interface
[14:05] <seb128> can an interface snap add files to /var and /lib in your snap mount?
[14:06] <zyga> seb128: an interface can let a snap do this
[14:06] <zyga> seb128: we still don't have hooks, when we get them from new state engine we'll be able to react to all actions (connect, etc)
[14:06] <zyga> seb128: if you tell me more about the problem perhaps I could suggest a solution
[14:07] <seb128> zyga, trying to get translations working in my snap
[14:07] <seb128> which requires to have locales generated in /usr/lib/locale/locale-archive
[14:08] <seb128> that can be relocated
[14:08] <seb128> by then gettext tries to read from /usr/share/locale:/usr/share/langpack-locale
[14:08] <seb128> which can't be relocated
[14:08] <seb128> but as an appdev I don't want to have to learn how to generate libc locales
[14:09] <zyga> seb128: the appdev part should be solved with snapcraft support
[14:09] <seb128> I guess we could teach snapcraft to generate those though
[14:09] <seb128> that still doesn't solve the fact that glibc doesn't let you relocate/specify another dir to load the .mo
[14:10] <seb128> out of patching glibc's code and rebuilding glibc as part of your snap
[14:10] <zyga> seb128: doesn't textdomaindir do that?
[14:10] <seb128> no
[14:10] <seb128> it works only for the gettext command line
[14:10] <zyga> I mean
[14:10] <seb128> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=114461
[14:10] <zyga> bindtextdomain
[14:10] <seb128> zyga, no
[14:10] <zyga> why not? it seems to do just that?
[14:11] <zyga> (assuming you build an app from source)
[14:11] <seb128> well
[14:11] <seb128> right, I'm repackaging a deb
[14:11] <zyga> ah, right
[14:11] <seb128> but then if you do that
[14:11] <zyga> for deb-repacking I agree
[14:11] <seb128> what if need also strings from libc
[14:11] <seb128> +you
[14:11] <zyga> what is the domain used by libc?
[14:11] <zyga> this feels like a SDK runtime problem
[14:11] <zyga> locale generation is perhaps more subtle
[14:12] <seb128> libc.mo
[14:12] <seb128> SDK sort of
[14:12] <zyga> but I think a snap developer should just end up with a bunch of .mo files
[14:12] <zyga> that they can even filter out if they want
[14:12] <seb128> gettext() is not specific to a SDK
[14:12] <zyga> yes, but SDK should just solve it for people
[14:12] <zyga> for just fishing parts of binary debs, it feels tricky
[14:12] <seb128> it could
[14:12] <zyga> so back to interfaces
[14:12] <zyga> we could design an interface that lets you do bind mounts and other magic
[14:13] <zyga> I just wonder if that's a solution (it doesn't feel like one)
[14:14] <seb128> yeah, maybe not
[14:14] <seb128> maybe we just make those part of pd
[14:14] <seb128> and declare that core users can't have translations
[14:14] <zyga> basic locales? I would say yes
[14:14] <zyga> core users will probably use webapps
[14:14] <zyga> and if not, they can bundle the world if they want a custom kiosk localized GUI
[14:15] <seb128> well, I guess as long as we provide easy tools to help them to bundle the world...
[14:15] <seb128> it still feels to me that locales are a base feature of the OS and shouldn't have to be bundle
[14:15] <zyga> I think we should explore both sides, patching sources to understand snap runtime layout and environment variables and reach for low-hanging fruit
[14:15] <seb128> but it's a good point that they take space and are not needed on a core
[14:16] <zyga> eventually I would hope that all important upstream projects have a getenv("SNAP") somewhere
[14:16] <seb128> is having the deb repackaging case working a goal
[14:16] <zyga> and that they just work
[14:16] <seb128> or just something hacking we play with?
[14:16] <zyga> that depends on if the upstreams support snap internally :)
[14:16] <seb128> yeah, I don't agree with that
[14:17] <zyga> I think our patches to n-m weren't merged
[14:17] <seb128> projects shouldn't have to getenv for platform specifc hacks
[14:17] <zyga> but if they were ,you could repackage nm (or be closer to) instead of having to build it
[14:17] <zyga> seb128: I somewhat disagree, this is a big shift
[14:17] <zyga> seb128: relocatability
[14:17] <zyga> seb128: nothing really supports that out of the box yet
[14:17] <zyga> perhaps it is not SNAP, perhaps SNAP Is in some common platform glue
[14:17] <morphis> sergiusens: ping
[14:18] <zyga> but patching upstreams for native relocatability would be worth-while IMHO
[14:22] <qengho> Spin up a new autopkgtest machine that uses "dpkg --instdir=/relocated/" to install.
[14:24] <popey> jdstrand: I have an app doing "Bad system call" inside a snap, in dmesg I see an apparmor failure with sig=31 arch=40000003 syscall=45 compat=1 ip=0xf77e3547 code=0x0 - is this something I can work around, a bug, or something else?
[14:24]  * zyga looks
[14:24] <qengho> Oh, popey. So innocent.
[14:25] <popey> wat wat wat
[14:25] <zyga> that's shmctl
[14:25] <ogra_> scmp_sys_resolver 45
[14:25] <ogra_> run that
[14:25] <jdstrand> popey: on the device do 'scmp_sys_resolver 45'
[14:25] <kyrofa> Hey seb128 dholbach I'm around now
[14:25] <ogra_> zyga, how do you know ? it varies between arches ;)
[14:25] <jdstrand> popey: it must be on the device/vm
[14:25] <zyga> ogra_: yes, true, I checked for amd64
[14:26] <popey> jdstrand: inside the snap?
[14:26] <zyga> brb
[14:26] <ogra_> :)
[14:26] <popey>  this is on my laptop
[14:26] <ogra_> zyga, it is brk on armhf
[14:26] <jdstrand> zyga, ogra_: note the syscall numbers are different depending on the arch
[14:26] <popey> (amd64)
[14:26] <jdstrand> popey: ok, on amd64 that should be recvfrom
[14:26] <popey> yes
[14:27] <jdstrand> popey: you need to plug one of network, x11 or unity7
[14:27] <jdstrand> popey: if you are, autoconnecting isn't working for you
[14:27] <popey> I have all 3
[14:27] <popey>     plugs: [x11, network, network-bind, unity7, opengl]
[14:27] <jdstrand> popey: right, my understanding is that removing and installing again will get it to connect
[14:27] <jdstrand> popey: otherwise you can manually connect
[14:28] <jdstrand> zyga: I asked slvn to file a bug for that, but I think he had to step away. do you have a bug for this? ^ is it known to you?
[14:28] <popey> jdstrand: removing "it" as in, the snap?
[14:28] <jdstrand> popey: yes
[14:29] <seb128> jdstrand, that's 32 bits code on amd64, unsure if that makes a difference?
[14:29] <jdstrand> zyga: in other news, I figured out why the unintended bluez change ended up in my branch and have adjusted my processes
[14:29] <seb128> if I understood popey correctly
[14:29] <jdstrand> seb128: I think you just confused me :)
[14:29] <jdstrand> he had a seccomp denial
[14:30] <seb128> right, I'm just saying that he's multiarching
[14:30] <jdstrand> so I just asked that he run scmp_sys_resolver on whatever architecture logged the denial
[14:30] <seb128> k
[14:30] <jdstrand> multiarch doesn't matter
[14:30] <seb128> I was mentioning in case
[14:30] <jdstrand> thanks
[14:30] <seb128> np
[14:31] <popey> bah! got into the state where I have to nuke and pave again :(
[14:31] <seb128> :-(
[14:31] <seb128> hey kyrofa
[14:32] <seb128> is there a way to tell snapcraft to rebuild without wipping out the deb cache?
[14:32] <popey> seb128: I ended up installing apt-cacher-ng on my laptop
[14:32] <seb128> popey, :-(
[14:32] <popey> seb128: feel free to point your apt at my laptop as a proxy ㋛
[14:32] <seb128> but thanks for the tip
[14:32] <kyrofa> seb128, you can clean individual steps of the lifecycle-- would that help?
[14:33] <popey> (I appreciate you may not want to)
[14:33] <kyrofa> seb128, instead of cleaning the pull, just clean back to build
[14:33] <seb128> kyrofa, I ended up reworking my yaml but that feels like a workaround
[14:33] <seb128> kyrofa, oh ok
[14:33] <kyrofa> seb128, essentially instead of cleaning everything, you say "don't wipe out the pulled stuff."
[14:33] <seb128> I ended up having 2 parts
[14:33] <seb128> and cleaning only one
[14:34] <seb128> I didn't know that my issue was due to "cleaning the pull"
[14:34] <seb128> or that was a thing
[14:34] <seb128> thanks
[14:34] <kyrofa> seb128, no problem! Yeah try `snapcraft clean -s build` (by default it cleans everything, including the pull step)
[14:34] <seb128> that sounds like a poor default :p
[14:34] <seb128> kyrofa, thanks!
[14:36] <dholbach> kyrofa, thanks... I was wondering if sergiusens, you and I could pick dates/times for the snapcraft UOS sessions
[14:37] <dholbach> we're still very much free to pick times between 14 and 20 UTC on 3-5 May
[14:37] <kyrofa> dholbach, yeah sounds good. sergiusens is running a few errands right now and I have a meeting in a few minutes, but after that I'm free all day
[14:43] <popey> Argh, "sudo snap install mylocalfoo.snap" on a clean box will download ubuntu core, fail to install it, fail to download my local snap from the store, but install my local one anyway, without ubuntu-core. So next time I try something it tries to download ubuntu-core again!
[14:43] <ogra_> uh
[14:44] <ogra_> popey, so your snap is i386 ?
[14:44] <ogra_> i wonder if it tries to download the matching core
[14:45] <popey> nope
[14:45] <ogra_> hmm, k
[14:45] <ogra_> i wonder why it fails then
[14:46] <popey> also, you have to remove snaps before installing them again, or you get a broken snap installed.
[14:46] <popey> repeatedly installing the same snap over and over leads to a non-functioning snap
[14:47] <jdstrand> popey: between those two and not autoconnecting, it sounds like you are hitting 3 bugs :\
[14:47] <popey> \o/
[14:47] <jdstrand> popey: 4 now :\
[14:47] <roadmr> a bug trifecta
[14:47] <jdstrand> popey: would you mind filing them?
[14:47] <popey> sure thing
[14:47] <jdstrand> I don't think any are filed
[14:47] <jdstrand> thanks!
[14:51]  * zyga confused signal number with syscall number
[14:51] <ogra_> mvo, ricmm, http://paste.ubuntu.com/16095818/ should we start with that ?
[14:52] <slvn> jdstrand, zyga : I have just retried this "auto-connect" issue with new package name, and it worked. then I did a "reset-state". the first new install was longer (installation of 64 MB ? whereas the snap is 2 Mo ...). and x11 didn't connect. re-install, it worked. To me, the issue seems something missing in the script "reset-state". Since this is non-official, should I make be a bug report ?
[14:52] <zyga> slvn: interesting
[14:52] <zyga> slvn: no, I'll experiment, thanks
[14:52] <zyga> slvn: the first time when you installed the snap it bundled ubuntu-core with it
[14:52] <zyga> slvn: when you installed the snap, was that side-loaded (locally on your FS) or from the store?
[14:52] <zyga> slvn: snap install ./foo.snap or snap install foo
[14:53] <zyga> ogra_, jdstrand: How do  you lookup syscalls?
[14:53] <ogra_> scmp_sys_resolver
[14:53] <jdstrand> zyga: signal vs syscall> easy to do
[14:53] <zyga> jdstrand: I know how to lookup signal numbers
[14:54]  * jdstrand wants to get to fixing snappy-debug to help people in this regard but has a few more things to tend to first
[14:54] <zyga> jdstrand: but not syscall numbers
[14:54] <jdstrand> scmp_sys_resolver ...
[14:54] <zyga> ahhh
[14:54] <jdstrand> (on the device)
[14:54] <jdstrand> always on the device :)
[14:54] <zyga> thanks!
[14:55] <jdstrand> (unless you know your archs are the same of course)
[14:55] <zyga> yeah, I had an index somewhere but I lost it now
[14:56] <jdstrand> seb128: hey, I saw you mention something about trying to get the tree together for me and others to test-- what is the status (just wondering if I should move to the next thing on my list and circle back or not-- no big rush)
[14:58] <seb128> jdstrand, I'm about to push
[15:00] <slvn> zyga, I have always installed the snap from my FS. I haven't played with the store yet.
[15:01] <dholbach> kyrofa, ok
[15:07] <jdstrand> seb128: thanks
[15:09] <seb128> jdstrand, ok, lp:~ubuntu-desktop/+junk/gnome-calculator-snap updated
[15:09] <jdstrand> seb128: thanks!
[15:09] <seb128> jdstrand, yw!
[15:10] <seb128> jdstrand, I'm going to file some bugs now about the issues we had/have and the workaround we did
[15:10] <seb128> jdstrand, btw got https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1576066 filed about the 32bits issue
[15:11] <zyga> jdstrand: just curious, what's the outlook on non-enforcing seccomp landing in the kernel?
[15:11] <seb128> jdstrand, "justincornack" says that updating libseccomp to 2.3.0 should fix it
[15:12] <jdstrand> zyga: I need to work with them on it. we have a good relationship with them, it is just devmode is a couple places down the list atm
[15:13] <zyga> jdstrand: sure understood
[15:13] <zyga> jdstrand: is there a place where I can look at the list?
[15:13] <jdstrand> zyga: at my list?
[15:13] <jdstrand> the security team trello board
[15:13] <zyga> jdstrand: do you have a link handy by any chance?
[15:14] <jdstrand> seb128: oh interesting
[15:14] <jdstrand> seb128: thanks!
[15:14] <seb128> jdstrand, yw!
[15:16] <seb128> jdstrand, I guess we should SRU https://github.com/seccomp/libseccomp/commit/73d83e45efbe8c31067c97155162f17ca51b7435
[15:16] <seb128> desrt, ^
[15:16] <desrt> this won't help
[15:17] <seb128> oh :-(
[15:17] <desrt> this only helps if the C library is indeed calling those new functions
[15:17] <slvn> zyga, not sure you got the message : I have always installed the snap from my FS. I haven't played with the store yet.
[15:18] <zyga> slvn: ah, thanks
[15:18] <zyga> slvn: perhaps there's some interesting bug in that case, I'll give it a try
[15:18] <desrt> actually, i may take that back.  i have no idea what this does =)
[15:18] <desrt> and maybe it does contain/improve demuxing for that call, indeed
[15:18] <zyga> slvn: I know for a fact that there are plenty of related bugs fixed in master (to be released very soon)
[15:18] <zyga> slvn: perhaps tomorrow it will be in the archive
[15:19] <seb128> jdstrand, desrt, there are also other commits in trunk that might help in fact, our version is old
[15:19] <slvn> zyga, I used the same SDL2/snap of the other bug to test it.
[15:19] <ogra_> you have high hopes about our SRU process it seems :)
[15:19] <seb128> e.g https://github.com/seccomp/libseccomp/commit/d32c3bfa4b07add90dcd04292eb4ba278dd103ba
[15:20] <zyga> slvn: right, we had a bug that didn't auto-connect in some cases, I suspect it is that, I'll check again when I have power
[15:20] <seb128> though pitti backported some of those changes already it seems
[15:20] <zyga> slvn: I'll ping you tomorrow, after the release is out
[15:20] <slvn> zyga, I'll also tomorrow if there is some update:
[15:20] <desrt> https://github.com/seccomp/libseccomp/commit/983835f3e0fd000a42c8beaea9d7fbe726ffff65
[15:20] <desrt> this is the one that will really help
[15:21] <desrt> " + * Convert a multiplexed pseudo socket syscall into a direct syscall "
[15:21] <zyga> jdstrand: there's a micro task for home to auto-connect
[15:21] <zyga> jdstrand: do you think we should set it to auto-connect and let the store flag that for review?
[15:22]  * ogra_ wonders if we should prehaps grow the reviwers team 
[15:23] <zyga> gahh, sorry, battery dies
[15:23]  * zyga orders a new battery, power cuts are annoying
[15:23] <zyga> ttyl
[15:26] <jdstrand> zyga: I think autoconnecting is fine-- the store currently flags for manual review. But the topic overall has an unclear path. sabdfl said to do one thing with x11/unity7 and niemeyer another. home to me is the same sort of thing.
[15:31] <mvo> ogra_: I like that, lets do it
[15:32] <ogra_> mvo, ok, will upload then
[15:33] <seb128> jdstrand, what's the right component to file the bug about "unity7 plug profile needs updating for menus"
[15:34] <jdstrand> seb128: snapd. add the snapd-interface tag
[15:34] <seb128> jdstrand, thanks
[15:37] <mvo> ogra_: nice, let us try to test today/tomorrow and see how it goes
[15:37] <ogra_> yeah
[15:37] <ogra_> well, we need someone who has a uboot gadget snap for i386
[15:37] <ogra_> i was hoping ricmm has something like that handy
[15:38] <seb128> jdstrand, bug #1576287
[15:46] <jdstrand> seb128: thanks
[15:53] <sborovkov> Hello, how do I enable classic shell now? snap enable-classic does not work
[15:57] <jdstrand> mvo: hey, does being a member of ubuntu-core on github give me commit access?
[16:02] <mvo> jdstrand: hm, I actually don't know, commit access to snappy on github? just create your branch and send a pull-request
[16:03] <jdstrand> mvo: I did that, but I also got an invite not long ago nad just accepted. my branch is tagged Reviewed. I wasn't sure if I should wait or commit and wanted to ask what the commit policy was
[16:04] <mvo> jdstrand: oh, ok. I think I saw that there was one outstanding question on the branch. or did that get resolved? if resolved one of us will merge it
[16:05] <jdstrand> mvo: I resolved it and made two reverts based on mailing list and bug feedback
[16:06] <mvo> jdstrand: nice, let me have a look then, I can merge it
[16:06] <mvo> jdstrand: usually (but not always) its branch-owner != person-who-merges
[16:06] <jdstrand> I see
[16:07] <mvo> jdstrand: we also have no separate branch for xenial and yakkety (love the name)
[16:07] <mvo> (yet)
[16:07] <jdstrand> ok
[16:07] <seb128> jdstrand, mvo, just for the record that's some bug reports about the issues we hit when playing with gnome-calculator https://bugs.launchpad.net/ubuntu/+bugs?field.tag=snap-desktop-issue
[16:08] <jdstrand> nice
[16:09] <seb128> jdstrand, I guess there is already one for the gsettings proxy work?
[16:10] <seb128> or is it only in specs like https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement?
[16:12] <seb128> opened one, we can close it if needed
[16:13] <jdstrand> seb128: the proper confinement for gsettings is a separate thing. snaps on classic could utilize that, but we'll likely simply need to add it and say it is a limitation of the mediation (much like X is)
[16:14] <jdstrand> s/need to add it/need to add the rules for the global gsettings/
[16:14] <seb128> jdstrand, right, good, thank we can use bug #1576308
[16:15] <wililupy> Good morning ogra_, mvo.
[16:17] <ogra_> wililupy, good evening :)
[16:19] <seb128> jdstrand, the libseccomp issue, gnome-calculator on i386 hits the bug (it needs to download currency info from internet), I can test patchs if you want, just ping me with commits or debs
[16:21] <wililupy> I got the system to boot today after adding ahci to the initrd modules in snapcraft, but I still had to edit the grubenv file on /dev/sda2 to point to my kernel snap to boot up properly.
[16:22] <jdstrand> seb128: thanks
[16:24] <ogra_> wililupy, right, and that bit is out of my territory of knowledge ... mvo might be a better counterpart here
[16:25] <wililupy> ogra_ Thank you so much for your assistance on this. I now have a working Kernel snap with the modules in it, so now all I have to do is snap up the application and test it and I could be back on schedule. I still need to work on the grubenv so that install is easy and doesn't require user intervention.
[16:26] <mvo> wililupy: hm, is your kernel called vmlinuz and the initird.img ? the code currently assumes that
[16:26] <wililupy> mvo, do you know why the grubenv doesn't update with the snappy_kernel= variable?
[16:26] <mvo> wililupy: a symlink is probably fine
[16:26] <wililupy> let me check mvo.
[16:27] <mvo> wililupy: it should if the kernel snap is of type: kernel, could you paste your meta/snap.yaml please? I need to look what is going on
[16:27] <wililupy> definitely mvo.
[16:27] <mvo> wililupy: and please pastebin the output of grub-editenv right after you installed your kernel
[16:27] <wililupy> sure.
[16:27] <mvo> (but before you manually adjusted something)
[16:27] <mvo> cool, thank you!
[16:30] <wililupy> mvo: meta/snap.yaml: https://pastebin.canonical.com/155478/
[16:32] <ogra_> oha
[16:32] <wililupy> mvo: (hd,2)/EFI/ubuntu/grub.d/grubenv: https://pastebin.canonical.com/155479/
[16:33] <ogra_> why doesnt snapcraft set "type: kernel" ?
[16:33] <mvo> wililupy: could you please add "type: kernel" and see if that helps?
[16:33]  * ogra_ guesses there is your issue
[16:33] <mvo> aha ogra_ was faster :)
[16:33]  * mvo hugs ogra_
[16:33] <ogra_> heh
[16:33]  * ogra_ hugs mvo 
[16:33] <wililupy> I can post my snapcraft.yaml
[16:34] <mvo> just add this one line first, that sounds very likely to be the culprit
[16:34] <ogra_> but it is weird, given the snapcraft kernel plugin was used
[16:34] <ogra_> i woudl actually expect that it sets that
[16:35] <wililupy> https://pastebin.canonical.com/155480/
[16:35] <wililupy> type: kernel before the parts: section?
[16:35] <ogra_> in meta/snap.yaml
[16:36] <wililupy> gotcha ogra_
[16:36] <ogra_> and then just "snapcraft snap" the dir
[16:37] <kyrofa> It seems /snap/bin is not in the PATH if I try to run with sudo. This worked in rolling-- is it a bug, or is it supposed to work this way?
[16:38] <sergiusens> popey I logged bugs about install/remove/install/remove/.../.../install
[16:38] <wililupy> snapcrafting now.
[16:39] <sergiusens> seb128 log a bug about the ARCH thing, we can support it easily
[16:39] <seb128> sergiusens, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576232
[16:40] <jdstrand> mvo: thanks for the merge. I'm not sure who is doing release notes, but one of those commits fixes bug #1575914
[16:42] <mvo> jdstrand: uh, thanks. a "Closes: LP#1575914" in the commit picks it up automatically
[16:43] <sergiusens> seb128 thanks, I love bugs! :-)
[16:43] <seb128> yw!
[16:43] <jdstrand> mvo: oh, whoops
[16:43] <jdstrand> mvo: I'll know for next time
[16:44] <wililupy> mvo, ogra_ same error, I have to modify the grubenv to boot up properly.
[16:44]  * jdstrand updates his notes for autoclosing snappy bugs
[16:45] <mvo> jdstrand: no worries, I will add it later manually
[16:47] <wililupy> weird, it didn't update the snap.yaml...
[16:47] <wililupy> I updated it in the snap directory and then re-ran snapcraft snap.... hmmmm
[16:47] <ogra_> E: config/hooks/15-remove-grub-common.chroot failed (exit non-zero). You should check for errors.
[16:47] <ogra_> P: Begin unmounting filesystems...
[16:47] <ogra_> P: Saving caches...
[16:47] <ogra_> GRRR !
[16:49] <wililupy> looks like snapcraft snap overwrote my meta/snap.yaml with the one without type:kernel.
[16:50] <ogra_> hmm, it shouldnt do that
[16:51] <kyrofa> wililupy, the snap folder it _output_, not input
[16:51] <kyrofa> is*
[16:52] <wililupy> kyroga, the snap directory, correct?
[16:52] <wililupy> kyrofa ^
[16:53] <kyrofa> wililupy, right
[16:53] <ogra_> kyrofa, we only wannt to check a one line change in snap.yaml .. and not re-build anything but the snap
[16:53] <om26er> stgraber, Hi! ChrisTownsendwas helping me debug an lxc container not starting, he suggested me to show the logs to you. Can you please take a look at these logs ? http://paste.ubuntu.com/16102061/
[16:54] <wililupy> I modified the snap/meta/snap.yaml there, then went back to my source directory and ran snapcraft snap.
[16:54] <kyrofa> ogra_, try `snapcraft snap snap` then?
[16:54] <kyrofa> ogra_, tell snapcraft to use the snap directory to create the snap rather than going through its lifecycle to do so
[16:54] <wililupy> I'll t ry that, can't hurt
[16:55] <ogra_> kyrofa, yeah, thats what i mean abover with <ogra_> and then just "snapcraft snap" the dir
[16:55] <ogra_> :)
[16:55] <ogra_> i should have written "snapcraft snap snap" :)
[16:55] <kyrofa> wililupy, ogra_ it's also worth noting that snapcraft will re-generate the meta/ directory each time, even if the rest of the lifecycle has already run
[16:55] <ogra_> oh
[16:55] <kyrofa> wililupy, ogra_ i.e. you don't need to rebuild the project just to change the meta/ dir
[16:56] <ogra_> well, he could just move the snapcraft.yaml away :)
[16:56] <ogra_> then it will just roll the dir into a snap
[16:56] <ogra_> without regenerating anything
[16:57] <wililupy> meta/snap/snap.yaml still has my changes after running snapcraft snap snap
[16:57] <wililupy> Another u-d-f and a burn in on the device...
[16:58] <ogra_> mvo, hmm, not sure why but seems my changes to live-build/ubuntu-core/hooks/15-remove-grub-common.chroot make the world explode (on all arches)
[16:59]  * ogra_ doesnt understand why ... very weird 
[17:01] <ogra_> http://paste.ubuntu.com/16103786/
[17:01]  * ogra_ scratches head
[17:01] <wililupy> ogra_, mvo, kyrofa: That did it!!
[17:01] <ogra_> wililupy, well, we still dont know why snapcraft.yaml doesnt add the type field
[17:01] <ogra_> it should do that by default with the kernel plugin
[17:02] <wililupy> yeah, should I put in a bug?
[17:05] <ogra_> sergiusens, ^^^ is that a bug ? (kernel plugin not setting type: kernel in snap.yaml)
[17:06] <sergiusens> ogra_ you have to do that in your snapcraft.yaml
[17:07] <ogra_> sergiusens, https://pastebin.canonical.com/155480/
[17:07] <ogra_> does it need extra mentioning of type: kernel ?
[17:12] <sergiusens> ogra_ yes
[17:12] <ogra_> ah !
[17:12]  * ogra_ didnt know :)
[17:12] <sergiusens> ogra_ we have no contract for plugins changing top level things
[17:13] <ogra_> pfft :P
[17:13] <sergiusens> ogra_ it is a constant discussion we have internally as it would be ideal to also create apps and commands
[17:13] <ogra_> yeah
[17:13] <sergiusens> ogra_ but then what happens when the use wants to do something special :-)
[17:15] <ogra_> well, if it is set at the top level you dont touch it ... if nothing is set at the toplevel the plugin takes over
[17:15] <sergiusens> ogra_ what if you want to payload a kernel in a normal snap app?
[17:15] <sergiusens> for some weird reason
[17:16] <ogra_> notmal snaps dont have a type ?
[17:16] <ogra_> *normal
[17:17] <sergiusens> ogra_ implicit type 'app'
[17:24] <wililupy> sergiusens, so where in my snapcraft.yaml to I tell it that it is a type: kernel snap?
[17:25] <sergiusens> wililupy same level as name, summary, ...
[17:26] <wililupy> sergiusens: so after description: add type: kernel before parts:
[17:27] <sergiusens> wililupy order doesn't matter in yaml, just make it at the same level
[17:27] <wililupy> sergiusens: ack. Going to try it now.
[17:41] <sergiusens> ubottu hey
[17:42] <sergiusens> kyrofa hey, can you reach nodejs.org?
[17:42] <kyrofa> sergiusens, yessir
[17:42] <sergiusens> darn, what happened to my DNS?
[17:42]  * sergiusens reboots router
[18:10] <sergiusens> kyrofa here you go https://github.com/ubuntu-core/snapcraft/pull/490
[18:11] <sergiusens> kyrofa that is the one you thought of when you thought you thought incorrectly
[18:14] <sergiusens> elopio do you know the status of https://github.com/ubuntu-core/snapcraft/pull/480 ?
[18:17] <sergiusens> ogra_ so I push this (https://launchpad.net/snapcraft/+milestone/2.8.5) to yakety; wait for it to go in smoothly and then tag every bug in there to hint the SRU and then dput to xenial and wait?
[18:17] <sergiusens> is that it in a nutshell?
[18:17] <kyrofa> sergiusens, ah, you're right :P
[18:38] <ogra_> sergiusens, yeah
[18:38] <ogra_> there is a wikipage too for it
[19:00] <sergiusens> ogra_ I read the wiki page, twice; it assumes I know a bunch of things already :-)
[19:00] <sergiusens> ogra_ thanks
[19:00] <ogra_> heh
[19:00] <ogra_> bah ...
[19:01] <ogra_> so i cant remove /boot/grub on the os snap because there is a file in it !
[19:01] <ogra_> silly stuff ...
[19:01] <ogra_> unicode.pf2
[19:01]  * ogra_ removes it anyway
[19:09] <oparoz> Is there a particular reason the command wrapper changes the working dir to SNAP_DATA?
[19:09] <ogra_> it is the writable dir the snap provides ....
[19:09] <ogra_> (the default writable dir)
[19:10] <sergiusens> oparoz afaik it doesn't unless you tell it to
[19:10] <oparoz> Sure, but isn't it the user's responsibility to call commands from SNAP_DATA?
[19:10] <oparoz> sergiusens, maybe it's because I'm still on an older rolling Snappy then
[19:10] <ogra_> the user would call from SNAP_USER_DATA ;)
[19:11] <sergiusens> oparoz yeah, not seeing it http://paste.ubuntu.com/16118454/
[19:11] <ogra_> SNAP_DATA is somewhere in /var/lib ... it is the writable bit your snap knows about and if executed without any cotext that is the place where binaries can write
[19:11] <kyrofa> sergiusens, the wrapper cds into it
[19:12] <sergiusens> kyrofa not from what I am seeing here though
[19:12] <sergiusens> look at my pastebin
[19:12] <ogra_> if you execute a snap app in context of a user, then SNAP_USER_DATA is your place
[19:12] <sergiusens> unless you are talking about a daemon
[19:12] <oparoz> ogra_, let's say the user wants to wget something from a folder in SNAP_DATA, the files end up in the root of SNAP_DATA instead of the folder
[19:13] <sergiusens> kyrofa the qtlaunch script does iirc
[19:13] <sergiusens> but it is meant for UI apps, launched from a desktop file, so it should not really matter
[19:13] <kyrofa> sergiusens, oh, it was services with a workingdir I think
[19:13] <ogra_> oparoz, that shouldnt happen, the stuff should end up in SNAP_USER_DATA in such a scenario ...
[19:14] <ogra_> (i know it did in the past by default when i used my unconfined wget)
[19:14] <oparoz> ogra_, sergiusens that's the wrapper that gets created https://paste.ubuntu.com/16118505/
[19:15] <oparoz> Just before ubuntu-core-launcher, there is a cd $SNAP_DATA
[19:15] <oparoz> sergiusens, ogra_ could it be because of the security policy?
[19:15] <kyrofa> oparoz, probably an old version, I don't see it in the current: https://github.com/ubuntu-core/snappy/blob/master/snappy/binaries.go#L62
[19:15] <oparoz> I mean does it have an influence on the wrappers?
[19:15] <ogra_> it could well be that i'm not up to date ...
[19:16]  * zyga smells 15.04 snappy
[19:16] <ogra_> regarding my knowledge
[19:16] <zyga> oparoz: that's 15.04 right?
[19:16] <kyrofa> zyga, nah, not 15.04
[19:16] <oparoz> Thanks kyrofa
[19:16] <oparoz> zyga, thats the mvo image from february
[19:16] <zyga> ah
[19:16] <zyga> ancient stuff then
[19:16] <kyrofa> zyga, so rolling stable
[19:16] <oparoz> Indeed
[19:16] <zyga> SNAP_APP_doesn't exist anymore
[19:17] <ogra_> february  ?
[19:17] <ogra_> you should really update
[19:17] <kyrofa> ogra_, to what? A 16 image? :P
[19:17] <ogra_> yeah ...
[19:17] <oparoz> :)
[19:17] <ogra_> feb is definitely before 2.0
[19:17] <kyrofa> Indeed
[19:18] <zyga> oparoz: you can use my script to build a new image using mvo's udf
[19:18] <zyga> oparoz: github.com/zyga/devtools
[19:18] <ogra_> for 16.04 only the images from the last two weeks are actually ok
[19:18] <zyga> oparoz: though images are not fully supported now, you may have to re-flash periodically as we stabliize
[19:18] <zyga> ogra_: full of bugs, the next set will be okay (with next version of snapd)
[19:18] <oparoz> Thanks zyga, the problem is that all users of the ownCloud snap are still on that image, so I can't update yet
[19:19] <ogra_> sure, full of bugs, but up to date with the right concepts at least
[19:19] <ogra_> while all older images are simply broken
[19:19] <zyga> oparoz: I see
[19:19] <oparoz> But thanks for confirming that the change of dir doesn't happen any more
[19:19] <zyga> ogra_: I agree
[19:19] <zyga> there were more changes in the last month than in the year before
[19:20] <oparoz> ogra_, we have enough trouble getting people to test the image. If they need to re-flash every week, we're going to lose all of them
[19:20] <ogra_> yeah, understood
[19:20] <zyga> oparoz: it would be nice to at least switch to 2.0 snappy because that old image feels like tech debt personified, it's going to bite you more the longer you wait
[19:20] <oparoz> But yeah, it's problemtic because some problems don't apply any more
[19:20] <ogra_> it is just that any development you do on them is moot ... since the design of snappy changed a lot
[19:20] <zyga> you probably require an interface, you won't find that on that old image
[19:21] <kyrofa> zyga, still using old-security there. Fortunately the interfaces required are simple (network and network-bind)
[19:21] <zyga> I think you have a tough choice ahead
[19:21] <zyga> kyrofa: cool, nothing fancy to access hdds?
[19:21] <kyrofa> zyga, we're splitting partitions
[19:21] <zyga> kyrofa: ah, interesting
[19:22] <oparoz> We're going to have to switch in the next 2 weeks anyway
[19:22] <kyrofa> So the upgrade path is actually pretty easy. It's just that 16 a) isn't stable and b) doesn't seem to support preinstalling snaps so we can't generate a factory image
[19:23] <kyrofa> Unless mvo's new u-d-f fixed the --install and it works on 16
[19:23] <zyga> we're working on making udf saner again but it's still a roadmap
[19:23] <ogra_> i thought that was fixed a while ago
[19:23] <zyga> I mean a permanent fix
[19:23] <zyga> not another layer of duct tape
[19:24]  * ogra_ doesnt know what everyone has against duct tape ... 
[19:24]  * oparoz agrees :D
[19:25] <oparoz> except when it comes to software development ;)
[19:25] <zyga> I'd hear what you say if I dind't have duct tape over my ears ;)
[19:25] <ogra_> well, at least you'll get rid of these hairs in your ears then :P
[19:26] <kyrofa> zyga, anyway, we'd love to jump to 16. But we need those things
[19:26] <kyrofa> So rolling stable is at least giving people something to test
[19:26] <zyga> kyrofa: those things?
[19:26] <kyrofa> stability and preinstalled snaps
[19:27] <zyga> kyrofa: I'm not sure I know what you refert to now
[19:27] <zyga> ah
[19:27] <zyga> stability as in debian stable, that I understand
[19:27] <zyga> preinstalled snaps, soon :)
[19:27] <zyga> ish
[19:27]  * zyga loves 'ish'
[19:27]  * ogra_ used to work for "ish" 
[19:27] <oparoz> zyga, weeks?
[19:27] <zyga> oparoz: ask me after the next sprint
[19:27] <oparoz> zyga, OK
[19:28] <zyga> oparoz: now I can reliably predict by looking at coffee leftovers or other wizardy
[19:28] <kyrofa> oparoz, which is in 10 days
[19:28] <zyga> ish
[19:28] <zyga> yep
[19:28] <ogra_> https://de.wikipedia.org/wiki/Ish_%28Unternehmen%29
[19:28] <ogra_> (not even available in english )
[19:28] <kyrofa> ogra_, wait.. you were serious? :P
[19:28] <zyga> LOL
[19:28] <ogra_> yeah :)
[19:28] <zyga> that explains a lot ;)
[19:28] <zyga> hehe
[19:29] <zyga> lovely company name
[19:29] <ogra_> that was my last job before canonical ...  leading a tech team of 15 ppl
[19:29]  * zyga recalls the company that makes light bulbs "osram", which is very popular in poland despite the name
[19:29] <ogra_> cable internet was the new thing in germany back then
[19:29] <kyrofa> I can hear the promo now: "Stable... fast.. _ish_"
[19:30] <oparoz> (kyrofa, 10 days is good, we can make a decision then)
[19:43] <kyrofa> Hey sergiusens I figured out what was wrong with the ROS example
[19:44] <kyrofa> sergiusens, it's a locale issue-- setting LC_ALL=C fixes it
[19:44] <kyrofa> sergiusens, I guess something changed on xenial?
[19:44] <ogra_> should be C.UTF-8 nowadays
[19:44] <ogra_> (and iirc thats the default fallback in xenial)
[19:45] <kyrofa> ogra_, setting that works too, but without it it barfs
[19:45] <kyrofa> ogra_, but my ignorant american self doesn't know very much about locales :(
[19:45] <ogra_> yeah, you're i ascii-land
[19:47] <ogra_> wow, snapcraft grew some solid dependencies ...
[19:47]  * ogra_ notes while reading image build logs that it pulls in 30 packages and eats 10MB nowadays
[19:48] <ogra_> (50MB installed)
[19:56] <oparoz> IF I want to add "reload to a daemon, I simply add reload-command to the "app" in the yaml?
[19:57] <zyga> oparoz: not sure
[19:57] <zyga> gimme a sec
[19:57] <oparoz> https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/
[19:57] <oparoz> No mention or reload, so I gues not...
[19:59] <zyga> one sec :)
[19:59] <zyga> checking now
[19:59] <oparoz> Thanks zyga :)
[20:00] <zyga> oparoz: so there's restart condition
[20:00] <zyga> but there is no restart command
[20:00] <zyga> wait
[20:00] <zyga> checking services
[20:00] <oparoz> zyga, I've noticed that restart works out of the box, but reload doesn't, so I thought I needed to add something to the yaml
[20:01]  * ogra_ sighs ... livecd-rootfs doesnt like me today
[20:01] <zyga> there are ExecStop
[20:01] <zyga> ExecStopPost
[20:01] <zyga> ExecStart
[20:01] <zyga> and that's it
[20:01] <oparoz> :(
[20:01] <zyga> there's also Restart
[20:01] <zyga> what are you looking for exactly?
[20:02] <ogra_> cant you send a HUP to the process if it is in the same snap ?
[20:02] <oparoz> zyga, in quite a few situations, you just want to reload a config without having to bring everything down and up again
[20:02] <zyga> oparoz: do what ogra_ said
[20:03] <oparoz> OK, I will give it a go
[20:16] <oparoz> pkill didn't work, but kill did, thanks ogra_
[20:17] <ogra_> good
[20:22] <wililupy> ogra_ adding the type: kernel to the snapcraft.yaml makes it work as designed!
[20:22] <ogra_> yay
[20:22] <wililupy> No need to change anything manually.
[20:22] <ogra_> good you finally got everything working :)
[20:23] <wililupy> Yes!
[20:23] <wililupy> Now on to building the app snap. This should be a little more straight forward.
[20:23] <zyga> oparoz: pkill would need /proc access
[20:24] <wililupy> Thank you so much ogra_, mvo, sergiusens, kyrofa!
[20:24] <zyga> morphis: any updates on https://github.com/ubuntu-core/snappy/pull/1036
[20:24] <ogra_> np
[20:24] <oparoz> Ah, thanks zyga. That was a question I had. Any daemon requesting access to /proc is hutdown, correct?
[20:24] <zyga> oparoz: not really, just denied access to pkill wound't be able to find all the details probably
[20:24] <zyga> oparoz: (depending on how pkill is written)
[20:25]  * zyga should finish the current post on snappy security
[20:26] <oparoz> zyga, OK, so denied access which some "app" may not be too happy about
[20:40] <ogra_> yay, finally ...
[20:40]  * ogra_ has the images building again 
[20:43] <zyga> ogra_: cool :-)
[20:43] <ogra_> silly stuff ...
[20:43] <ogra_> something like:
[20:43] <ogra_> [ -d /boot/grub ] && rm -f /boot/grub
[20:44] <ogra_> makes everything explode ...
[20:44] <ogra_> because on all arches where that dir doesnt exist the test exits non-zero and tears down live-build
[20:45]  * ogra_ hates that common sense doesnt apply in some cases ...
[20:46] <zyga> ogra_: like almost always?
[20:46] <ogra_> heh
[20:46] <zyga> ogra_: note that common sense is just that, common, it's not really always sensible :)
[20:46] <kgunn> zyga: i was just wondering, when hacking on snap/snapd and using your tools...i was just doing refresh-bits snap/snapd/run-snapd...but should i be doing 'refresh-bits setup' first ?
[20:46] <ogra_> so true
[20:47] <kgunn> i'm still not seeing any of my changes applied when i run the tools
[20:47] <kgunn> fwiw, i did try doing refresh-bits setup...but didn't make a diff
[20:48] <zyga> kgunn: setup is needed once per vm boot
[20:48] <zyga> kgunn: it ensures that regular snapd doesn't start by accident
[20:48] <zyga> kgunn: I run setup snapd run-snapd; then only snapd run-snapd
[20:49] <zyga> kgunn: what were you hoping to happen?
[20:50] <zyga> kgunn: what changes?
[20:52] <zyga> kgunn: after you push the new snapd to your VM you should uninstall/reinstall your mir snap
[20:52] <zyga> kgunn: and observe interfaces reported by snap interfaces
[20:52] <zyga> kgunn: and observe generated apparmor/seccomp profiles
[20:53] <kgunn> zyga: so question...if i don't install mir snap at all, and only run the mod'd snapd...and i type snap interfaces...i should see the mod correct?
[20:53] <zyga> what mod?
[20:53] <kgunn> zyga: mod== addition of an interface called mir
[20:53] <zyga> what were you expecting to see exactly, from what I remember from your branch you woundn't see anything new
[20:54] <zyga> there is no way to see the list if interfaces
[20:54] <zyga> just the list of plugs and slots
[20:54] <zyga> those come from snaps
[20:54] <zyga> note that the OS snap would *not* offer the mir slot
[20:54] <zyga> it would be offered by mir itself
[20:54] <zyga> so you'd have to install new snapd, install mir (snap) and see what the rsult is
[20:54] <kgunn> ok
[20:55] <zyga> does that make sense?
[20:55] <zyga> snapd would contain the implementation of mir interface
[20:55] <zyga> but that would only show up when you install the mir snap
[20:55] <zyga> normally snappy logs and ignores unknown interfaces on snaps
[20:56] <zyga> but with your patches, mir snap would really gain the mir slot
[20:56] <zyga> and would really gain the permanent permissions resulting from that slot
[20:56] <zyga> right?
[20:56] <kgunn> zyga: ok, maybe i've been trying to see something that simply won't happen
[20:57] <kgunn> i'll fiddle a bit more later with this...good to know on the setup run first time on vm tho
[21:46] <sergiusens> kyrofa sadly saying please is mandatory
[21:49] <ogra_> you could also friendly say please though
[21:49] <ogra_> :P
[21:55] <sergiusens> ogra_ not to a build system that decides to fail :-P
[21:55] <sergiusens> ogra_ imagine saying please to livecd rootfs ;-)
[21:55] <ogra_> i did, it helped !
[22:15] <thekeymaker> if you are building snaps using snapcraft on ubuntu 16.04, is there a easy way to try(run) them instead of installing them with the command snap install ./my-snap?
[22:53] <zyga> thekeymaker: not yet
[22:54] <zyga> thekeymaker: though installing them is very lightweight
[22:54] <zyga> thekeymaker: we just copy and mount them
[22:54] <zyga> there are plans to add a new command that will be even better but that's not finalized
[22:55] <zyga> thekeymaker: and also note that unless you run master you should remove the snap first, this will avoid hitting a number of known, fixed but (not released) bugs
[23:10] <oparoz> zyga are symlinked followed when a snap is removed or purged?
[23:10] <oparoz> *symlinks
[23:10] <zyga> I'm not sure, probably
[23:10] <zyga> but I don't really know and it's rather too late for me to check now
[23:11] <zyga> (and give you an accurate answer)
[23:11] <oparoz> yeah, no worries, was surprised to still see you here ;)
[23:11]  * zyga is writing a very long article 
[23:11] <oparoz> Ah :)
[23:44] <Domi> Hello, does anyone use Python in a snap?