[00:36] <netphreak> how do i build a snappy gadget?
[07:54] <mwhudson> mvo: ping
[07:54] <mvo> mwhudson: pong
[07:54] <mwhudson> mvo: did you see my question about golang-github-coreos-go-systemd a week ago?
[07:56] <mvo> mwhudson: uh, I did but I did not looked into the details. we do use very little of systemd
[07:56] <mvo> mwhudson: let me check
[07:57] <mwhudson> mvo: maybe we just don't care then :-)
[07:57] <mwhudson> in which case it case stay in -proposed until y for all i care
[07:57] <mvo> mwhudson: we only use the "activation" part
[07:57] <mvo> mwhudson: the activation.Listerners part to be precise
[07:58] <mvo> mwhudson: I certainly do not care :)
[07:59] <mwhudson> mvo: noted
[07:59] <mwhudson> :-p
[10:57] <oparoz> Hello. What should we do with packages which rely on alternative-updates (/etc/alternatives) ? Manually re-create all symlinks in the yaml?
[10:58] <ogra_> which alternatives would they set (i mean, where..-. the alternatives system of the OS itself wont be reachable by the snap package)
[10:59] <ogra_> all you could do it ship it inside your snap and set an alternative inside the snap work dir ... not sure that makes any sense
[11:00] <oparoz> ogra_: the problem is that we're not being asked, some packages install their binaries that way and they will be missing from the snap if we don't do something
[11:01] <ogra_> asked for what ?
[11:02] <oparoz> ogra_: Where to install the binary
[11:02] <ogra_> you could use the copy plugin to copy binaries around
[11:02] <ogra_> the alternatives system in ubuntu doesnt ask you either normally ... it uses the defaults
[11:03] <oparoz> ogra_: Well in the case of ImageMagick, they're not even being created in the snap, so symlinks have to manually be created
[11:03] <ogra_> (that would be a viloation of "no asking questions" that we have in all ubuntu packages)
[11:04] <oparoz> ogra_: Yes, that makes sense for Ubuntu, but since it's one of the things which doesn't work in s snap, I was wondering if the Snappy team had designed a workaround
[11:04] <ogra_> and snapcraft does not run postinst scripts by design ...
[11:04] <ogra_> so your best bet is to use the copy plugin i guess
[11:05] <oparoz> ogra_: How do you copy a symlink whch doesn't exist?
[11:06] <oparoz> ogra_: I guess it doesn't exist but outside of the snap where the package was installed
[11:06] <oparoz> ogra_: *I guess it does exist
[11:06] <ogra_> you copy a file to the name of the symlink
[11:09] <seb128> so attente pointed out that removing/purging ubuntu-snappy still leads to snappy wanting to reboot your system
[11:09] <ogra_> pitti, yo ... how are systemd timers supposed to be removed if a package that created it is removed ?
[11:09] <seb128> seems like because the systemd timer is left behind
[11:10] <seb128> what ogra said :p
[11:10] <ogra_> heh :)
[11:10] <seb128> I guess the snappy rm script should clean that out?
[11:10] <seb128> what is adding the timer? is that the snappy postinst?
[11:10] <ogra_> dunno
[11:11] <ogra_> debian/snappy-autopilot.timer it seems
[11:11] <oparoz> ogra_: If I use copy, I'll end up with a copy, not a symlink, the plugin help doesn't mention symlinks
[11:12] <ogra_> right
[11:12] <ogra_> you could file a bug against snapcraft to allw adding links
[11:12] <ogra_> in the copy plugin
[11:12] <oparoz> ogra_: I'll do that, thanks
[11:13] <ogra_> til then, just copy them around as an interim solution
[11:13] <ogra_> (its not like that will created gigabytes :) )
[11:13] <ogra_> *create
[11:16] <oparoz> ogra_: True, those files are tiny. I was just wondering about their dependencies if it used relative paths internally, but we'll see
[11:34] <pitti> ogra_: hm, they aren't stopped with some autogenerated prerm "systemctl stop" commands from dh_systemd_start?
[11:35] <pitti> ogra_: do you mind doing a bug report against init-system-helpers with details about this for reproduction?
[11:35] <ogra_> i will have to check the snappy source
[11:35] <pitti> sorry, /me just spent some 3 hours reviewing a 500 kB hilariously bad openssl patch, I need a break now
[11:35] <ogra_> yeah, no hurry
[11:36] <pitti> ogra_: at first sight, I guess the intention is that dh_systemd_start foo.timer ought to start it at package install and stop it at removal?
[11:36] <pitti> or am I missing more context here?
[11:36] <ogra_> no, thats correct ... the issue is that it keeps trunning even if the package is removed
[11:37] <ogra_> there is no pre/postrm in the debian dir apparnelty
[11:37] <ogra_> *apparently
[11:38] <pitti> so I guess the timer is also not started on pacakge install
[11:38] <ogra_> only a completely generic debian/ubuntu-snappy-cli.postinst
[11:38] <pitti> or maybe it is, and dh_s_s is only doing half of its job
[11:38] <pitti> oh, it should be autogenerated, not in teh source
[11:38] <pitti> i. e. /var/lib/dpkg/info/package.{pre,post}rm
[11:39] <pitti> dh_* goes into debian/rules, not d/{pre,post}{inst,rm}
[11:40] <ogra_> ah
[11:40] <ogra_> debian/ubuntu-snappy-cli.install ...
[11:40] <ogra_> debian/*.timer /lib/systemd/system/
[11:40] <ogra_> it is in the wrong package
[11:40] <ogra_> mvo, ^^^ can we move the timer to ubuntu-snappy.install ?
[11:40] <seb128> the rules has
[11:41] <seb128> # we want the autopilot timer enabled by default
[11:41] <seb128> 	dh_systemd_enable \
[11:41] <seb128> 		-pubuntu-snappy \
[11:41] <seb128> 		snappy-autopilot.timer
[11:41] <ogra_> i guess thats enough (since we dont even seem to use debhelper here)
[11:41] <seb128> but yeah, I guess the .install is wrong
[11:41] <seb128> ogra_, you do ^
[11:41]  * ogra_ is busy with livecd-rootfs atm ... i was hopng mvo could quickly do it with his next upload
[12:16] <asac> docker not working on latest builds is known?
[12:16] <asac> docker
[12:16] <asac> /snaps/docker/1.6.2.005-16.04.1-2/bin/docker: line 4: /var/lib/snaps/docker/1.6.2.005-16.04.1-2/bin/bin_arch: No such file or directory
[12:16] <asac> /snaps/docker/1.6.2.005-16.04.1-2/bin/docker: line 11: select_bin: command not found
[12:17] <asac> ok ic
[12:17] <asac> docker assumed that it gets started in the SNAP direcxtory
[12:17] <asac> not DATA
[12:18] <asac> kickinz1: when do you plan to do a new docker build?
[12:23] <mvo> ogra_: hm, we need the autoupdate timer in snappy (or we won't get updates)
[12:23] <mvo> ogra_: I guess what we don't want is the autoreboot
[12:24] <ogra_> mvo, doesnt ubuntu-snappy debeond on -cli ?
[12:24] <ogra_> *depend on
[12:24] <mvo> ogra_: it does
[12:24] <mvo> ogra_: but we want auto updats on the desktop as well
[12:24] <ogra_> yeah, then we need to split out the reboot bit
[12:25] <mvo> yes
[12:30] <sergiusens> kgunn, mvo give me 5 min, I overslept and need coffee
[13:07] <kgunn> sergiusens: mvo well...i completely overslept sorry
[13:07] <kgunn> you likely didn't need me
[13:07] <kgunn> ?
[13:11] <sergiusens> kgunn, we were done in 10 minutes and then just caught up with life stuff :-P
[13:11] <sergiusens> an email will come out soon explaining the plan
[13:13] <kgunn> sergiusens: mvo i apologize...
[13:13] <mvo> kgunn: no worries
[13:13] <mvo> kgunn: I missed a pretty important meeting myself this morning too, so no worries.
[13:14] <kgunn> :)
[13:14] <mvo> kgunn: but sergiusens and I discussed the issue and I will send a mailafter my current meeting with the outcome. I think we have a good plan
[13:14] <kgunn> that's great
[13:15] <kgunn> mvo: sergiusens if my team can or needs to help in any way lemme know
[13:22] <kyrofa> sergiusens, github now verifies signed commits!
[13:23] <sergiusens> kgunn, actually I want to talk to you about the qml plugin; but later today as daytime is in diapers for us still :-)
[13:24] <sergiusens> kyrofa, what does that mean? sorry for my lack of excitement :-P
[13:24] <kgunn> sure
[13:24] <sergiusens> kyrofa, fwiw, I finished the command refactor and am happy with it; I barely had to change any tests ;-)
[13:25] <kyrofa> sergiusens, did you know you could sign your commits with your gpg key? I've always done it, but now github actually supports uploading your public key and it'll verify the commit actually came from that person
[13:25] <kyrofa> sergiusens, ah, good news! I'll be looking at it momentarily
[13:27] <sergiusens> kyrofa, I'm going to try and fix the webui one now; it is annoying me.
[13:27] <kyrofa> sergiusens, sounds good
[13:35] <sergiusens> kyrofa, maybe I won't disable as it didn't fail this time :-P
[13:35] <kyrofa> sergiusens, *sigh*
[13:51] <ysionneau> hmm there was a script to generate snappy image somewhere, does anybody have the url?
[13:51] <ysionneau> called "ubuntu-image"
[13:52] <ogra_> ysionneau, thats zygas script
[13:53]  * ogra_ has lost the url though, i always just use ubuntu-device-flash directly
[13:53] <ysionneau> I can't find it in his ~zyga web dir :'
[13:54] <ogra_> it was somewhere on github iirc
[13:54] <ysionneau> ah!
[13:54] <ysionneau> https://github.com/zyga/devtools/blob/master/ubuntu-image
[13:54] <ysionneau> here it is!
[13:54] <ysionneau> thx
[13:56] <kyrofa> ogra_ is elite though. He can remember all those magical incantations
[13:56] <ogra_> haha, well, i usually need my special incarnation anyway ... so a wrapper script just gets in the way :)
[13:56] <kyrofa> ogra_, good point
[14:09] <qengho> On config change, should I be using systemctl/systemd to reload the configuration of services that my snap provides?
[14:10] <qengho> I would guess I'm supposed to have implemented all my own PID-finding-and-killing logic, but that makes me sad.
[14:11] <ogra_> snappy service ...
[14:15] <qengho> ogra_: Is that requirement supposed to be exposed to the user?  On "snappy config NewFile", they should know this program needs to get "snappy service restart"?
[14:15] <ogra_> well, dont you require sudo for your cobfig call ?
[14:15] <ogra_> *config
[14:16]  * ogra_ wouldnt let ordinary users change snap configs 
[14:16] <qengho> ogra_: Yes, config file is writable by root only. Why?
[14:16] <ogra_> and i think there was a bug open for Chipaca` to actually tellö users about the needed service restart or do it automatically
[14:17] <qengho> Ah!
[14:37] <elopio> nessita: is there a group without the 24 hour restriction for registering snaps?
[14:37] <elopio> I have to add like three today.
[14:39] <nessita> elopio, nopes, but we are lowering that right now to 3 minutes
[14:39] <nessita> elopio, branch is on its way to trunk and then staging
[14:39] <qengho> tar-content plugin is going away. copy replaces it. But, copy also requires "files" schema key. Hrm.
[14:40] <elopio> nessita: ok, I can live with 3 minutes. Thanks.
[14:44] <netphreak> hi, guys!
[14:44] <nessita> elopio, ó/
[14:44] <nessita> \o/
[14:45] <netphreak> I have a snap.yml gadget file and some boot-assets. How do i build a image?
[14:45] <kyrofa> qengho, if you want to duplicate how tar-plugin works, just use '*': '.' for files
[14:45] <kyrofa> qengho, it's just explicit is all
[15:06] <noise][> mvo: I'm assuming desktops will use the same 4x daily (spread out) autoupdate checks? is that accurate?
[15:07] <mvo> noise][ yes
[15:07] <mvo> noise][ that is the plan at least - any concerns?
[15:07] <noise][> mvo: excellent, thanks
[15:07] <mvo> noise][ fwiw, the apt timer change has also landed in xenial
[15:08] <noise][> mvo: apt timer change?
[15:09] <mvo> noise][ oh, nevermind
[15:09] <mvo> noise][ sorry, I I thought you might be concerned about upload load in general, snappy is one part of it, apt is another one
[15:10] <noise][> ok, my main concern is just that snappy doesn't hammer the package index in herds, and sounds like that's sorted (or will be for desktop as well)
[15:47] <netphreak> What's the latest version of snap craft?
[15:53] <sergiusens> kyrofa, fixed your commented things except for the execute one which I don't really follow
[15:53] <kyrofa> sergiusens, just a typo in the doc string
[15:53] <kyrofa> sergiusens, not part of your PR technically
[15:53] <kyrofa> Not super important
[15:55] <kyrofa> netphreak, 2.7
[15:56] <sergiusens> available for xenial only
[15:56] <kyrofa> netphreak, future reference: https://github.com/ubuntu-core/snapcraft/releases
[15:56] <sergiusens> kyrofa, oh, sorry my eyes read it correctly! :-P
[15:56] <kyrofa> netphreak, indeed. For pre-xenial, 1.1.0
[15:57] <kyrofa> sergiusens, hahaha, I had you questioning your english skills
[15:58] <sergiusens> kyrofa, done :-)
[15:58] <sergiusens> kyrofa, more that there's a docstring PEP mentioning the language of a docstring (Execute or Executes)
[15:59] <kyrofa> sergiusens, ohhh
[15:59] <netphreak> How do i upgrade to the latest xenial version?
[15:59] <kyrofa> netphreak, just apt-get upgrade
[15:59] <kyrofa> (assuming that you're running xenial, of course)
[15:59] <netphreak> which i'm not ;)
[16:00] <kyrofa> netphreak, then you'd need to run from source, which can be done but will have some issues and may not build snaps that can actually target 16.04
[16:00] <kyrofa> netphreak, I can walk you through that if you want to do it anyway
[16:01] <netphreak> ok.. i'll just download a xenial virtual box image, if available?
[16:01] <netphreak> might save us both some time ;)
[16:01] <kyrofa> netphreak, do you have any device with snappy ubuntu core 16.04 on there?
[16:02] <netphreak> nope
[16:02] <kyrofa> netphreak, because you can run snapcraft from there (and then test out the resulting snap immediately)
[16:02] <netphreak> I'm just about to get into the whole world of snaps ;)
[16:02] <kyrofa> netphreak, you can do that in vbox if you like. But if you just want the normal desktop, just use http://cdimage.ubuntu.com/daily-live/current/
[16:03] <netphreak> vbox is fine.. I have my other devtools running on osx
[16:04] <sergiusens> kyrofa, netphreak I wouldn't run from source; I'd install lxd and create a xenial container
[16:04] <sergiusens> I do that on my DO droplet to work from my phone ;-)
[16:04] <kyrofa> netphreak, let me be more clear. If you run ubuntu desktop in a VM, you'll need to have another snappy install to run the snaps (e.g. another VM). You can, however, use snapcraft from the snappy install directly, thus potentially saving you a VM
[16:04] <sergiusens> oh that works too
[16:05] <netphreak> ahh.. well.. i Have a Raspberry 2 lying around i will install ubuntu snappy on - to test the snaps
[16:05] <kyrofa> sergiusens, yeah that's my daily workflow-- my dev laptop is still trusty
[16:05] <kyrofa> netphreak, ah, snapcraft doesn't cross-compile, so you should probably run snapcraft from there as well
[16:05] <kyrofa> (lxc I mean)
[16:06] <netphreak> my plan was to make a gadget (provision) a custom image for the rpi.
[16:08] <sergiusens> vila, hey I saw your macaroon branch, a bit too late though; it looks good but there was a refactor going on in place; would you mind rebasing? If not I can do it for you. It's about https://github.com/ubuntu-core/snapcraft/pull/433
[16:10] <vila> sergiusens: rebasing is not a problem. /me looks at pull/443
[16:10] <netphreak> is this possible from a VM with Xenial?
[16:10] <kyrofa> sergiusens, yeah this looks good, only have the [<directory> --output <snap-file>] thing now
[16:10] <vila> sergiusens: also, are you ok with me proposing that work piece by piece or do you prefer to see the whole first ?
[16:11] <kyrofa> netphreak, yeah that should be arch-independent
[16:11] <netphreak> ok.. thx.. ;)
[16:11] <kyrofa> vila, smaller PRs are ideal
[16:11] <netphreak> Another question.. The snappy maven plugin.. Does it support other versions than openjdk 7?
[16:13] <vila> sergiusens, kyrofa: RIght, but given the flux in the store with macaroons, I'll have to carry some more baggage (like the SNAPCRAFT_WITH_MACAROONS env var) during the transition. If it's ok for you, it's ok for me ;)
[16:14] <kyrofa> vila, we can always land to an intermediate branch for easier reviews, then one big merge once the feature is done
[16:14] <sergiusens> vila, as kyrofa mentions, an intermediate branch might be better
[16:18] <vila> sergiusens, kyrofa: right, things are still too much in flux to know what's the best ;) I'm working locally on a stack of branches anyway, I'll come back when things get clearer
[16:19] <vila> sergiusens: wow, that pull/433 shuffle lots of things around, time for me to re-learn ;)
[16:22] <sergiusens> vila, not that much; ideally snapcraft.config and snapcraft._store should go into snapcraft.storeapi; we inherited snapcraft.storeapi because no one wanted to push a new package into ubuntu and we were involved late in the game ;-)
[16:32] <vila> sergiusens: ack. Yeah, well, if there was a package in ubuntu today it would make our life harder anyway ;) Let's revisit when the dust settle...
[16:42] <vila> sergiusens: oh, pull/433 hasn't landed yet ! Close to EOD so I'll rebase tomorrow. What was the rationale to get rid of the commands ?
[16:42] <kyrofa> Hey ogra_ any idea why libxml was removed from the edge ubuntu-core?
[16:43] <kyrofa> vila, trying to get rid of some global state and better command-line parameters
[16:44] <ogra_> kyrofa, are you sure it was ever there ?
[16:44] <kyrofa> ogra_, yeah unsquashfs comparing stable to edge
[16:44]  * ogra_ doesnt see it removed within the last weeks on http://people.canonical.com/~ogra/core-image-stats/
[16:45] <ogra_> kyrofa, stable ?
[16:45] <ogra_> 15.04 you mean ?
[16:45] <kyrofa> ogra_, ah, I'm talking about the ubuntu-core snap
[16:46] <kyrofa> ogra_, no, the channels
[16:46] <ogra_> we never had a stable release of 16.04 to my knowledge
[16:47] <vila> kyrofa: ack, thanks
[16:47] <ogra_> ah
[16:47] <ogra_> kyrofa, seems it was dropped here http://people.canonical.com/~ogra/core-image-stats/20160318.changes
[16:48]  * ogra_ would suspect the dhcp client dropped a superflouous dep
[16:48] <sergiusens> vila, long story short, we are getting rid of global state in `common`
[16:48] <kyrofa> ogra_, ahh, okay
[16:48] <sergiusens> vila, so we are creating a ProjectOptions class and initializing with that
[16:49] <sergiusens> vila, the problem is, we will end up with a bunch of comand duplication and sanity check code if we kept commands
[16:50] <sergiusens> vila, like seen here https://github.com/ubuntu-core/snapcraft/pull/430/files#diff-d2ba7d06874f884cc15ce0ef1fa9d31fR27
[16:51] <vila> sergiusens: ack, thanks for the detailed explanation, appreciated (will save me time when rebasing) !
[16:52] <ogra_> kyrofa, bug 1551351 and bug 1556175 ... seems the dhcp client switched to use some internal libs instead because they handle signals differently
[16:52] <kyrofa> ogra_, ah very interesting, okay thanks for digging into that! :)
[16:53] <ogra_> np
[16:53]  * ogra_ finds it funny that firefox offers to open snaps with vlc 
[16:57] <netphreak> ogra_: How do i build/assemble a gadget (downloaded the one you gave me a link to yesterday)
[16:57] <ogra_> netphreak, currently still with snappy build --squashfs
[16:57] <ogra_> i hope to get to it tomorrow to make it use snapcraft snap instead
[16:58] <netphreak> ok ;)
[16:58] <netphreak> thx for the pointer..
[17:04] <ogra_> sergiusens, so it would be nice to have snapcraft use /boot/initrd.img-core instead of /usr/lib/ubuntu-core-generic-initrd/initrd.img-core with the kernel plugin, do you need a bug for that ?
[17:04] <ogra_> (i copy it from /boot to /usr/ib atm but would like to drop the duplication before release)
[17:04] <netphreak> Is it possible to setup a private snap repo?
[17:06] <kyrofa> ogra_, please do make a bug if you can
[17:06] <ogra_> sure
[17:06] <netphreak> any docs on that?
[17:08] <kyrofa> netphreak, I don't believe that's supported. Not sure if there are plans to
[17:10] <ogra_> bug 1567564
[17:10] <ogra_> kyrofa, ^
[17:10] <kyrofa> ogra_, thank you!
[17:10] <ogra_> np
[17:10] <netphreak> according to this it might be?
[17:10] <netphreak> https://lists.ubuntu.com/archives/snappy-devel/2015-October/001076.html
[17:11] <sergiusens> ogra_, yes please
[17:11] <kyrofa> netphreak, ah, I do actually think the store supports private snaps. I remember seeing something about that
[17:11] <sergiusens> ogra_, I can land the change as soon as the ubuntu-core that is in makes its way to stable
[17:12] <ogra_> sergiusens, well, we dont have a stable 16.04 yet
[17:12] <ogra_> (we really should just throw one out ... even without any testing so we have a base to work with)
[17:12] <kyrofa> ogra_, not sure what I got when I generated a stable image then :P
[17:12] <netphreak> i´ve browsed through lots of documentation - but can't seem to figure out how it works..
[17:12] <ogra_> kyrofa, most likely some old tarball based thing
[17:13] <ogra_> none of the all-snap builds have been pushed to stable yet to my knowledge
[17:13] <kyrofa> ogra_, I'm able to install all-snap stuff there... curl https://search.apps.ubuntu.com/api/v1/package/ubuntu-core
[17:13] <ogra_> and we never actually released any image on cdimage
[17:13] <kyrofa> Huh.
[17:13] <ogra_> http://cdimage.ubuntu.com/ubuntu-snappy/
[17:13] <ogra_> only 15.04
[17:14] <ogra_> i know that elopio and mvo wanted to do that and then we didnt
[17:14] <ogra_> ... and i guess now we are waiting for the changes to gadget and kernel ... (once again)
[17:14] <kyrofa> ogra_, edge breaks every other day. Is that really all there is?
[17:14] <ogra_> yes
[17:14]  * kyrofa cries
[17:15] <ogra_> 16.04 all snaps never had an actual release
[17:15] <ogra_> only what mvo and I produce in your people.canonical.co dirs
[17:15] <ogra_> *com
[17:15] <kyrofa> ogra_, which is all edge then, I assume?
[17:15] <ogra_> yeah
[17:16] <kyrofa> That doesn't explain why I can install my squashfs snaps on the image I generated using stable though
[17:16] <ogra_> thoggh it might be that mvo released one of each snap to stable for his images (but they still werent released in the actual release spot)
[17:16] <kyrofa> ogra_, yeah maybe that's it
[17:20] <kyrofa> Hmm... ogra `snappy purge` seems to be gone. Know anything about that?
[17:20] <ogra_> nope ... but someone complained that snappy purge only works after you called snappy remove
[17:21] <ogra_> (which i found weird TBH)
[17:21] <kyrofa> ogra_, yeah I remember seeing a special purge flag in the code that will allow you to purge an installed snap
[17:22] <kyrofa> But now `snappy purge` results in "Unknown command `purge'. Please specify one of [...]"
[17:22] <ogra_> my focus was more on image builds this week though ... i didnt do much inside snappy systems themselves
[17:23] <ogra_> so i wouldnt have noticed it being dropped
[17:24] <kyrofa> Ah, apparently `remove` also purges now
[17:24] <kyrofa> So they removed purge
[17:31] <ogra_> they purged it :)
[18:00] <kyrofa> ogra_, by the way, thanks to the launchpad builders, I published owncloud for arm64 a few days back
[18:02] <kyrofa> (finally)
[18:11] <netphreak> ubuntu-device-flash gives me an error 'unknown flag `gadget''
[18:11] <netphreak> Running on 16.04 desktop
[19:38] <sergiusens> kyrofa, can you merge master?
[19:38] <kyrofa> sergiusens, did it ages ago ;)
[19:38] <kyrofa> i.e. about 2 minutes
[19:38] <sergiusens> kyrofa, heh, so the squashing thing has changed a bit
[19:38] <kyrofa> sergiusens, how so?
[19:39] <sergiusens> kyrofa, look at the commit
[19:39] <sergiusens> kyrofa, it adds a ref to the PR
[19:39] <kyrofa> Hmm
[19:40] <sergiusens> kyrofa, what I regret is that I didn't pay attention to the small box for the message and got the stack of commits in there
[19:40] <kyrofa> sergiusens, doesn't look like you cleaned up the squashed commits either :P
[19:40] <kyrofa> sergiusens, yeah I say fix it
[19:40] <sergiusens> kyrofa, you wanna do it? pretty please? :-)
[19:40] <kyrofa> sergiusens, doing now
[19:41] <kyrofa> sergiusens, so should we leave titles off of that little box, then? Since it puts in the reference?
[19:41] <kyrofa> Just make sure the PR title is what we want?
[19:41] <sergiusens> kyrofa, I am lost with what you mean
[19:41] <sergiusens> what little box?
[19:42] <kyrofa> When you merge, the box with the message in it
[19:42] <kyrofa> Or was this in there?
[19:42] <kyrofa> My questions will be answered next time I merge something. Just let me do the next one
[19:42] <sergiusens> oh, that has the bug number and the sign-offs, not sure we can just wipe it
[19:42] <sergiusens> kyrofa, by default it prefills with all the commits
[19:42] <sergiusens> kyrofa, you have to edit to get the right thing still
[19:42] <kyrofa> Oh no, I didn't mean wipe it. I was asking if github ALSO adds the title to it
[19:43] <sergiusens> kyrofa, it adds it because there are N commits
[19:43] <kyrofa> sergiusens, do we like the PR references?
[19:43] <sergiusens> kyrofa, I think we do; but that was automatic
[19:43] <kyrofa> Sounds good, just want to know for my cleaning here
[19:45] <kyrofa> sergiusens, note those references will show up in our changelogs
[19:45] <kyrofa> Which might actually be awesome
[19:52] <kyrofa> sergiusens, fixed by the way
[19:58] <sergiusens> kyrofa, remerge yourself now then :-)
[19:58] <kyrofa> sergiusens, already done
[20:47] <kgunn> so i just took a moment to update and try to build with snapcraft 2.7....not sure it's 2.7s fault...but i'm failing
[20:48] <kgunn> curious what anyone else is experience is?
[20:48] <kgunn> i've built mir snap easily with no issues updating each time since 2.2
[21:01] <stgraber> jdstrand: lxd 2.0 rc9 uploaded to the store
[21:16] <oparoz> Is /tmp noexec in a snap?
[21:17] <oparoz> Or is it even writable?
[21:31] <sergiusens> kgunn, what's the error?
[21:33] <Domi> Hello, I have to write a paper on Windows IoT and Ubuntu Snappy Core. What hardware should I get to try these Operating Systems? Raspberry Pi 2 or 3?
[22:34] <jdstrand> stgraber: approved
[22:35] <stgraber> jdstrand: thanks
[23:49] <catbus1> Hi, snapcraft login uses ubuntu one sso, I entered the email, password with or withou the one-time password, neither worked.
[23:49] <catbus1> Failed to establish a new connection: [Errno -3] Temporary failure in name resolution
[23:49] <catbus1> uh dns doesn't work
[23:53] <catbus1> nm