[06:33] <netphreak> Hi, guys!
[06:38] <netphreak> Are os updates to Ubuntu snappy automatically installed/pushed, or does it require some manual process?
[07:33] <dholbach> good morning
[07:35] <didrocks> good morning dholbach!
[07:35] <dholbach> salut didrocks
[08:14] <netphreak> Are os updates to Ubuntu snappy automatically installed/pushed, or does it require some manual process?
[08:38] <didrocks> netphreak: they are automatically pushed, it will tell you and you will just need to reboot for some snaps to activate the new versions
[08:50] <zyga-phone> good morning
[09:14] <netphreak> ok.. If Ubuntu snappy is running on some IOT device. How do one manage a reboot?
[12:13] <kyrofa> Good morning
[12:22] <kyrofa> Daylight savings should die
[12:31] <ogra_> kyrofa, it wouldnt be that bad if it'd actually bring in interest ;)
[12:32] <kyrofa> ogra_, yeah that would improve things
[12:49] <kyrofa> ogra_, any idea why I can't use screen within the classic dimension? I figure maybe a mount is missing
[12:49] <ogra_> hmm, i never tried ...
[12:50] <ogra_> (and working mostly on the dragonboard these days i dont have a working classic dimension)
[12:50] <kyrofa> Ah, right
[12:50] <ogra_> i'd blame lxc/lxd though
[12:51] <kyrofa> ogra_, yeah I a
[12:51] <kyrofa> m
[13:19] <ogra_> ppisati, hmm, i have a hard time inplementing dragonboard kernel tarball/snap creation in livecd-rootfs due to a missing linux meta package for it
[13:19] <ogra_> do you think we could have one ?
[13:20] <ppisati> ogra_: we are discussing right now which 4.4 kernel to push to the archive for the db410c
[13:20] <ogra_> (something like: "apt-get install linux-image-*-generic-dragon410c" installs all existing packages by that name for example, so i end up with three of them)
[13:20] <ppisati> ogra_: you'll probably get that one
[13:21] <ogra_> ppisati, we also need the firmware in the archive (restricted i guess)
[13:22] <ogra_> (or in linux-firmware even ... if thats possible(
[13:46] <didrocks> hey kyrofa, how are you?
[13:46] <kyrofa> didrocks, excellent! And yourself?
[13:46] <didrocks> kyrofa: I'm good, escaping meetings for a while, but blocked on some snapcraft thingy :p
[13:46] <kyrofa> didrocks, let me help
[13:47] <didrocks> kyrofa: do you have a minute for some very quick HO? I'm unsure if I'm doing it wrong or not
[13:47] <kyrofa> Sure!
[13:48] <netphreak> When os updates for Ubuntu snappy are pushed, do they require a reboot of the device?
[13:55] <ogra_> netphreak, yes, but as long as you go with the defaults the system will care for that on its own
[13:58] <ogra_> mvo_, hmmm ... seeding grub on arm64 ?
[13:59] <netphreak> ok..
[13:59] <netphreak> Good to know i don't have to deal with that in a IOT device
[14:00] <ogra_> netphreak, well, you have to deal with the fact that it can do unexpected reboots though
[14:01] <netphreak> This part has been taken care of ;)
[14:01] <netphreak> Is there an eta on the Ubuntu Snappy version for Raspberry Pi 3?
[14:02] <ogra_> not yet, no ... thats a) something i do in my spare time ... and b) depends on the status of u-boot for the board
[14:02] <ogra_> not sure where b stands currently, it wasnt ready last week
[14:05] <mvo_> ogra_: sure, ricmm asked for that, grub-efi-arm64
[14:06] <ogra_> bah, waste of space
[14:09] <netphreak> hmm.. looking at github for u-boot for rpi3 - looks like there was a commit for rpi3 compatibility..
[14:09] <netphreak> https://github.com/zeldin/u-boot-rpi3/commits/master
[14:09] <ogra_> i know that swarren did start work on it last week
[14:09] <ogra_> but it wasnt complete back then
[14:10] <ogra_> https://github.com/swarren/u-boot/tree/rpi_dev
[14:10] <zyga-phone> hey ogra_ :)
[14:10] <ogra_> still marked WIP
[14:11] <ogra_> note that for 64bit mopde there are a bunch of kernel patches missing ... and i think the binary blob bootloader also needs to support it
[14:11] <ogra_> hey zyga-phone
[14:18] <netphreak> Ok.. thx for status :)
[14:38] <zyga-phone> jdstrand: https://github.com/ubuntu-core/snappy/pull/658
[14:38] <zyga-phone> jdstrand: this is going to ensure that configuration files for {apparmor,seccomp,...} are exectly what we want
[14:38] <jdstrand> cool :)
[14:38] <jdstrand> zyga-phone: and hi :)
[14:39] <zyga-phone> hey, good morning :)
[14:51] <dholbach> didrocks, shall we get together tomorrow some time to look at the survey results together?
[15:04] <ogra_> mvo_, so with your seeding of grub, what will happen with the always failing grub snappy service on arm64 ?
[15:04] <ogra_> (i dotn want to end up in a grub shell after reboot ... is that safe ?)
[15:08] <mvo_> ogra_: what grub service is failing? the migrate-grub one?
[15:08] <ogra_> yeah
[15:08] <mvo_> ogra_: we never call grub-install, so it should be ok
[15:08] <mvo_> ogra_: migrate-grub is also no more in the current snappy
[15:08] <ogra_> i just want to be sure it doesnt overwrite anything on the uboot side
[15:09] <zyga-phone> jdstrand: one request this week, we'd like to have a working developer mode and, before any launcher changes happenm the easiest path to getting that done is to write permissisve seccomp profile and complaining apparmor profile; do you think you could share a "permissive" seccopm profile with me (I suspect it would just contain all the syscalls but I'd rather have expects write that)
[15:10] <ogra_> beuno, soo ... ho0w do we get my cdimage snaps into the store automatically ? it would really be good if they could go in without human action
[15:11] <ogra_> could we pull them somehow from the store side ?
[15:12] <didrocks> dholbach: sure! whenever time is best for you as long as it's not lunch time
[15:12] <beuno> ogra_, the store won't pull stuff in, but there are APIs for a script running $wherever to do that
[15:12] <ogra_> beuno, hmm
[15:13] <ogra_> under what credentials would that run then ?
[15:13] <dholbach> didrocks, cool
[15:13] <ogra_> it needs to use the canonical account
[15:13] <beuno> ogra_, right, you'd generate a token specifically use for that script
[15:13] <beuno> soon to be replaced with macaroons
[15:14] <ogra_> is there a doc about that API ?
[15:17] <beuno> ogra_, I think you can just use snapcraft nowadays instead of learning about the API
[15:18] <ogra_> beuno, i have a bunch of binary snaps and will have to write a script in my home on the cdimage server (which doesnt have snapcraft instaklled, it is 12.04 iirc)
[15:18] <ogra_> so i doubt i can use snapcraft here
[15:19] <kyrofa> ogra_, yeah, store uploading requires debs in xenial only
[15:20] <ogra_> kyrofa, debs ?
[15:20] <kyrofa> ogra_, I mean snapcraft dependencies in the archives that are only in xenial
[15:20] <ogra_> yeah
[15:20] <kyrofa> ogra_, you might be able to get away with running snapcraft 1.x on 12.04, but not 2
[15:20] <ogra_> and i cant use a chroot or some such (no root access on that machine)
[15:21] <kyrofa> Ah, right
[15:21] <beuno> ogra_, lp:click-toolbelt is a self-contained ish script
[15:21] <beuno> that describes the APIs as well
[15:23] <ogra_> beuno, can i use it right away with snaps ?
[15:23] <ogra_> (looks easy)
[15:23] <ogra_> (judging by the README :) )
[15:25] <beuno> ogra_, yes
[15:25] <ogra_> yay
[15:25] <ogra_> i'll play with it, thanks a lot !"
[15:26] <beuno> ogra_, np, pindonga is a good source of help in that area
[15:26] <ogra_> ok, i'll bug him if i hit roadblocks
[15:27] <pindonga> ogra_, fwiw snapcraft has support for uploading snaps as well
[15:27] <ogra_> pindonga, not on a 12.04 machine :)
[15:27] <pindonga> that is true
[15:27]  * ogra_ needs to auto-upload the snaps from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[15:28] <ogra_> (and the macghine is 12.04 based without root access)
[15:28] <ogra_> the toolbelt looks promising though
[15:29] <ogra_> but since everyone mentions it ... does snapcraft have upload support for already existing snaps ?
[15:29] <jdstrand> zyga-phone: just have @unrestricted in the seccomp profile
[15:29] <ogra_> i.e. ones that arent built using snapcraft ?
[15:29] <zyga-phone> oh?
[15:29] <pindonga> ogra_, I think so, you just point it to the file
[15:29] <ogra_> cool
[15:29] <pindonga> eg, snapcraft upload /path/to/nsp
[15:29] <zyga-phone> just []byte(`@unrestricted`) ?
[15:30] <zyga-phone> jdstrand: ^^
[15:30] <jdstrand> zyga-phone: you might want a trailing newline
[15:30] <zyga-phone> ok
[15:30] <zyga-phone> Thanks, that's easy to do
[15:30] <zyga-phone> looks like developer mode is not going to be hard to create
[15:32] <didrocks> kyrofa: bug #1557018 FYI
[15:32] <kyrofa> didrocks, thank you!
[16:28] <didrocks> zyga-phone: FYI, I changed xkcd-webserver to be compatible (see https://github.com/ubuntu-core/snappy/pull/653)
[16:28]  * zyga-phone looks
[16:28] <zyga-phone> didrocks: thanks, I re-started integration tests
[16:28] <didrocks> zyga-phone: hum, it's pulling it from the store
[16:28] <didrocks> I didn't upload it yet
[16:28] <zyga-phone> didrocks: ah, then you'd better push it there :)
[16:29] <zyga-phone> and restart tests again (just say "retest this please" in the comment)
[16:29] <didrocks> zyga-phone: oh, great that we have this trigger and do it myself
[16:29] <didrocks> zyga-phone: I need to have the canonical account access then, asking mvo, he was supposed to give it to me :)
[16:30] <zyga-phone> ack
[16:42] <attente> Chipaca, stevebiscuit: hi, is there an api for asking snapd to authenticate?
[16:42] <Chipaca> attente: not yet
[16:43] <Chipaca> attente: why?
[16:43] <Chipaca> attente: `snappy login` authenticates the whole system
[16:43] <Chipaca> attente: after which requests to the store from snapd will use those creds
[16:43] <Chipaca> attente: is that enough for your current needs?
[16:43] <attente> Chipaca: for gnome-software to authenticate without using the CLI
[16:45] <Chipaca> attente: there will be one shortly, when we implement macaroon support probably
[16:45] <attente> Chipaca: ok, thanks
[16:46] <seb128> Chipaca, that's going to be before xenial right? ;-)
[16:47] <stevebiscuit> :D
[16:51] <Chipaca> seb128: I have made no promises, I'm not about to make any now
[16:53] <seb128> Chipaca, k, thanks
[16:53] <Chipaca> seb128: macaroon support should be ready server side this week, after which we'll be doing the client side work as soon as we can
[16:54] <seb128> Chipaca, good to know, we just need to figure out what we do client side for xenial if that's not ready before release
[17:17] <didrocks> zyga-phone: when you got a second: https://github.com/ubuntu-core/snappy-testdata/pull/6 :)
[17:17] <zyga-phone> Sure
[17:17] <didrocks> thx!
[17:18] <didrocks> thanks zyga-phone :)
[17:19] <zyga-phone> my pleasure :)
[17:37] <jdstrand> oh, meh, the description was legitimate. description shouldn't be down in the apps section
[17:37]  * jdstrand makes error more clear
[18:17] <jdstrand> kyrofa: hey, can you explain how icons are supposed to work these days? my understanding is the in snapcraft.yaml you specify the icon and it is copied to meta/icon.png and meta/snap.yaml has no reference to it
[18:18] <jdstrand> kyrofa: is that accurate? how does meta/gui/icon.png fit into this?
[18:18] <ogra_> i thought it lives in a subdir now
[18:18] <ogra_> next to the .desktop file
[18:18] <jdstrand> or is that wrong...
[18:18] <ogra_> (yeah, meta/gui/ )
[18:18] <ssweeny> is there something special needed to expose a service from a snap over dbus? I have what I *think* is an unconfined snap running but I get an error when starting the service
[18:18] <kyrofa> jdstrand, yeah your understanding fits with mine
[18:19] <kyrofa> jdstrand, the meta/gui/icon discussion is new to me
[18:19] <jdstrand> ok
[18:19] <jdstrand> it looks like trunk has meta/gui/icon.png
[18:19] <kyrofa> jdstrand, are we talking .desktop files and whatnot?
[18:20] <jdstrand> desktop files is for another time. just wondering about the icon for the moment
[18:20] <jdstrand> ssweeny: is this on 15.04 or 16.04?
[18:20] <ssweeny> jdstrand, 16.04
[18:20] <ssweeny> jdstrand, the error is Problem executing the daemon: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.44" is not allowed to own the service "core.trust.dbus.Agent.UbuntuLocationService" due to security policies in the configuration file
[18:20] <kyrofa> jdstrand, ah. Yeah sorry, I wasn't involved with that
[18:20] <jdstrand> ssweeny: yes, the dbus bus policy is not set
[18:21] <ssweeny> jdstrand, ok, how does one set that? :)
[18:22] <jdstrand> ssweeny: atm, you can't. once zyga's stuff lanks, you'll be able to use interfaces
[18:22] <ssweeny> aha
[18:23] <jdstrand> ssweeny: you used to be able to do a little with type: framework and bus-name (eg, like on 15.04), but frameworks don't work on 16.04 and are going away in favor of interfaces
[18:23] <ssweeny> jdstrand, any ETA on that? Or a branch I can follow?
[18:23] <ssweeny> jdstrand, yeah all I could find documentation-wise was the old framework stuff
[18:23] <jdstrand> I'm going to defer to zyga-phone on that. I know he wants to lands parts of the interfaces very soon. the dbus stuff we are probably going to need to work through a bit
[18:24] <ssweeny> jdstrand, ok, fair enough
[18:24] <ssweeny> jdstrand, thanks for the explanation
[18:24] <zyga-phone> dbus should "just work" assuming we have an interfaces that uses dbus for some configuration
[18:24] <zyga-phone> we don't have any yet
[18:24] <zyga-phone> (I'm being optimistic but it seesm simple)
[18:25] <ssweeny> zyga-phone, ok, so I'm blocked on this issue. Do you have any timeframe for something I could play with?
[18:26] <jdstrand> I have some conerns that we will define only a few dbus interfaces for people to use but the world will want 100s or more
[18:26] <jdstrand> but I guess we'll see how that shakes out
[18:26] <zyga-phone> day-few-days
[18:27] <ssweeny> zyga-phone, ok I can work with that, thanks
[18:27] <zyga-phone> for the moment we can start to look at a specific interface
[18:27] <zyga-phone> e.g. the one that will unblock you
[18:27] <zyga-phone> I'd encourage you to look at that earlier, to define what you need to interact with and how
[18:27] <zyga-phone> otherwise you can spend most of the time designing that part alone
[18:29] <ssweeny> zyga-phone, sure
[19:15] <attente> hi, is there a way for me to run snapd on my desktop? i keep getting a "error: daemon does not handle 0 listeners right now, just one"