[04:22] <mup> PR snapcraft#862 opened: Add powerpc (32bit big-endian) support <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/862>
[06:35] <dholbach> good morning
[06:46] <trijntje_> good morning. What is the best way to grab a .jar from a website (like a github release) and place it into a snap
[07:08] <mup> PR snapd#2116 opened: add build-essential as classic dep for building on arm64 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2116>
[07:28] <mup> PR snapd#2114 closed: tests: add readme about spread's external backend <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2114>
[07:28] <mup> PR snapd#2115 closed: tests: only stop a service if it is running or ok (eg. active (exited)) <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2115>
[07:36] <Hanonim> Hi people !
[07:46] <mup> PR snapd#2116 closed: tests: add build-essential as classic dep for building on arm64 <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2116>
[07:47] <Hanonim> I'm testing snappy on KVM but when I install a snap, I can't run it
[07:50] <trijntje_> I'm trying to create a snap of cromwell, a workflow management system https://github.com/broadinstitute/cromwell
[07:50] <trijntje_> but I'm guessing that's not possible, because as a snap, it can't run any of the programs or scripts that are required unless they are also in the same snap?
[07:51] <trijntje_> Hanonim: what can't run? the install or the snap itself
[07:53] <Hanonim> trijntje: well for instance 'snappy install hello-world' works but then 'hello' doesn't (command not found)
[07:54] <trijntje> what about /snap/bin/hello ?
[07:54] <Hanonim> there is not /snap
[07:55] <Hanonim> in /apps maybe ?
[07:55] <Hanonim> there are hello-world files in /apps/bin
[07:56] <Hanonim> but not /snap/bin/hello per say
[07:57] <trijntje> What system are you on? On ubuntu 16.04 snaps get installed to /snap
[07:58] <Hanonim> I'm trying this example (KVM)
[07:58] <Hanonim> https://developer.ubuntu.com/en/snappy/start/#snappy-local
[08:03] <trijntje> Hanonim: In that case I don't know, I'm sorry
[08:03] <Hanonim> trijntje: no worries
[08:17] <trijntje> General question: I was thing about creating a snap for cromwell, a workflow management system https://github.com/broadinstitute/cromwell but I'm guessing that's not possible, because as a snap, it can't run any of the programs or scripts that are required unless they are also in the same snap?
[08:36] <mup> PR snapd#2117 opened: snapstate: avoid reboots if nothing in the boot setup has changed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2117>
[08:53] <mup> PR snapd#2108 closed: devicestate: merge overlord/boot into devicestate <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2108>
[08:55] <mup> PR snapd#2118 opened: overlord: merge overlord/boot pkg into overlord/devicestate <Created by mvo5> <https://github.com/snapcore/snapd/pull/2118>
[08:56] <mup> PR snapd#2119 opened: tests: abort tests if an update process is scheduled <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2119>
[09:06] <mup> PR snapd#2120 opened: Fix installed-size not being set in GET v2/snaps <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2120>
[09:17] <Mirv> so I defined a new part at https://wiki.ubuntu.com/snapcraft/parts but snapcraft can't use it, are there other steps to be taken for it to be available? snapcraft update says already up to date (and once even did update but no change).
[09:17] <Mirv> I didn't find documentation cloud parts yet at least, other than that wiki page
[09:21] <trijntje> I don't think that wiki page would be used directly, otherwise anybody could just edit it an break snaps for everyone
[09:28] <rvr> fgimenez: ping
[09:32] <fgimenez> hi rvr :)
[09:37] <rvr> fgimenez: Hey!
[09:37] <rvr> fgimenez: iahmad pointed me at a document with instructions about how to run spread tests, but it's not complete and couldn't get them running
[09:38] <rvr> fgimenez: So I need some help from you :)
[09:39] <fgimenez> rvr, sure! :) do you want to run them againsta a running ubuntu core instance?
[09:39] <rvr> fgimenez: I'm using the DragonBoard
[09:42] <fgimenez> rvr, ok, we have this document now https://github.com/snapcore/snapd/blob/master/tests/external-backend.md it explains the process to execute on an external instance
[10:07] <trijntje> I've succesfully create a snap and build it on amd64, but do I have to manually build and upload a snap for every architecture?
[10:10] <trijntje> I also noticed that nobody actually put the architecture in their snapcraft file in the snappy playpen https://github.com/ubuntu/snappy-playpen
[10:31] <ogra_> mvo, seems the pi and dragonboard unconditionally switching to stable for was not a one time issue ...
[10:31] <ogra_> mvo, see bug 1631791
[10:31] <mup> Bug #1631791: Pi 2 on ubuntu-core 424 no longer able to do anything <Snappy:New> <https://launchpad.net/bugs/1631791>
[10:31] <ogra_> i guess this is quite serious
[10:32] <ogra_> *for me
[10:36] <Mirv> ok, now it works, thanks if someone did something ;)
[10:58] <mvo> ogra_: yes, this is defintiely super serious - a critical bug
[11:15] <trijntje> Will it ever be possible to have something like a terminal snap? Since that would need to have access to any other command that is available on the system
[11:37] <kalikiana> trijntje: Check out bug 1618004
[11:37] <mup> Bug #1618004: Need a classic-bin interface to see classic binaries <Snappy:New> <https://launchpad.net/bugs/1618004>
[11:40] <trijntje> kalikiana: that looks very interesting, thanks. I'll comment and add my own usercase there as well
[11:46] <trijntje> *usecase
[11:48] <dr1337> Hi guys. Was wondering if anyone knows if Snappy has been ported to AllWinner soc?
[11:51] <rvr> fgimenez: I did export SPREAD_EXTERNAL_ADDRESS=192.168.1.41:8022 (dragonboard IP)
[11:52] <rvr> fgimenez: Then ./tests/lib/external/prepare-ssh.sh
[11:52] <rvr> fgimenez: But the  INSTANCE_IP=localhost
[11:55] <fgimenez> rvr in the call to prepare-ssh you should pass the instance ip and port as parameters
[11:55] <fgimenez> rvr, something like ./tests/lib/external/prepare-ssh.sh 192.168.1.41 22
[11:56] <rvr> fgimenez: Yeah, I just was reading the source of the bash script
[11:57] <rvr> fgimenez: Then, where is the spread command?
[12:01] <fgimenez> rvr, for dragonboard "spread -v -reuse external:ubuntu-core-16-arm-64" should work
[12:05] <rvr> fgimenez: Yes, but, where is the spread command?
[12:06] <ogra_> ppisati_, hmm, so i see morphis' uart oops on every boot here now ... using the last dailies
[12:06] <ogra_> (on the pi3)
[12:13] <ppisati_> ogra_: i'm working on it
[12:13] <ppisati_> ogra_: what do you have attached to your board?
[12:13] <ogra_> ppisati_, i know, just wanted you to know
[12:13]  * ppisati_ download the latest daily
[12:13] <ogra_> HDMI old apple USB kbd
[12:14] <ogra_> i couldnt get the wifi to connect, so later i also attached an ethernet cable
[12:15] <ppisati_> ogra_: is the daily built using the edge or beta channel?
[12:15] <ogra_> edge
[12:15] <ogra_> beta is the image on cdimage ... dailies (on people.u.c) are always edge
[12:15] <fgimenez> rvr, you mean spread itself, right? you can install it with "sudo snap install spread"
[12:15] <ppisati_> ogra_: i tried this morning rolling an image using edge, and i got a lot of errors because som,ething was trying to use the network while the network wasn't configured yet
[12:15] <ppisati_> neet to retry
[12:16] <ogra_> mvo, just FYI, i switched the dailies to core on friday
[12:16] <ogra_> ppisati_, yeah there seems to be an issue with the wifi ... wired works though
[12:17] <ppisati_> ogra_: one thing that i found, is that by disabling the fixed freq in config.txt, the serial oops disappear
[12:17] <ogra_> well, i can surely drop that if it doesnt have other illl effects
[12:18] <ppisati_> ogra_: you would loose the serial, since the core freq will keep chaning, and the srial baud rate would change too
[12:19] <ogra_> hmm
[12:19] <ppisati_> ogra_: but if you don't have a serial cable attached, it might make sense
[12:19] <ogra_> yeah, but thats nota solution ...
[12:19] <ppisati_> ogra_: it's just a workaround for the moment, until i found the root problem
[12:19] <ogra_> right
[12:20] <ogra_> dr1337, i dont think seires 16 has yet ... but there were 15.04 images iirc (dont ask me for what boards though)
[12:21] <ogra_> dr1337, if you have a borad that uses uboot and you have the ability to rebuild the uboot with the necessary config options enabled, it should be pretty straight forward though
[12:24] <ogra_> mvo, as i understand the f2fs mount errors we see on boot comes from /dev/ram* devices, do we really need to check them when looking for assertions ? (i think we should just exclude ram devices)
[12:25] <ogra_> *come
[12:25] <mvo> ogra_: no, this is a bug, I have a card to skip those in trello
[12:25] <ogra_> ah, k
[12:26] <ogra_> perhaps simply limiting it to removable devices would be enough
[12:27] <ogra_> (there is a udev var for this)
[12:29] <ppisati_> ogra_: so, building an image using edge, on boot i get util.py first and url_helper.py [DEBUG] stuff flooding my console
[12:30] <ppisati_> they try to connect to a remote host
[12:30] <ogra_> ppisati_, hmm, sounds like console-conf
[12:30] <ogra_> oh, no
[12:30] <ogra_> thats cloud-init i guess
[12:31] <ogra_> you need a patched ubuntu-device-flash ... not sure if mvo has already pushed that as snap to the store yet
[12:31] <ogra_> err
[12:31] <ogra_> s/ubuntu-devlce-flash/ubuntu-image/
[12:31] <ppisati_> they try to access a remote site but complain since the network is not available (and being the first boot, it's no surprise)
[12:32] <mvo> ogra_: what needs patching here? sorry, I miss some context
[12:32] <ppisati_> mvo: i ust built a new image using edge
[12:32] <ppisati_> mvo: and during boot, my console was spammed with
[12:32] <ogra_> ppisati_, https://github.com/CanonicalLtd/ubuntu-image/pull/69
[12:32] <mup> PR CanonicalLtd/ubuntu-image#69: include etc/ as well <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/69>
[12:32] <ppisati_> 'url_helper[DEBUG] can't connect http://..."
[12:32] <ogra_> mvo, ^^
[12:33] <ogra_> else cloud-init stays enabled
[12:33] <ogra_> mvo, (since you dropped the hook from livecd-rootfs)
[12:34] <mvo> ppisati_: oh, indeed, please ensure you have the latest ubuntu-image snap from edge
[12:34] <ppisati_> ubuntu-image         0.5+mvo8   15   canonical  devmode
[12:34] <mvo> ppisati_: please run "sudo snap refresh --devmode ubuntu-image"
[12:34] <ppisati_> and 'snap refresh' says i've the latest and greatest
[12:34] <ppisati_> k
[12:35] <ogra_> it lies :)
[12:35] <mvo> ppisati_: yeah, its a bit confusing for --devmode snaps
[12:35] <ogra_> (due to missing --devmode i guess)
[12:35] <ppisati_> ubuntu-image         0.5+mvo13  20   canonical  devmode
[12:35]  * ppisati_ rebuilds the image
[12:35] <rvr> fgimenez: This is running :)
[12:35] <ogra_> we should really make that automatic ... after all snapd knows it uses devmode ...
[12:36] <ogra_> so it could auto-apply the option for such snaps (and perhaps simply print a warning that devmode is on)
[12:37] <rvr> fgimenez: So, do these tests check snapd?
[12:53] <rvr> fgimenez: This is the output I got http://paste.ubuntu.com/23302958/
[12:59] <fgimenez> rvr, it begins to look good :) some of the errors seem to be related to an outdated sorce code (ubuntu-create-user for instance)
[13:39] <Mirv> is the directory for desktop file now "setup/gui" or "meta/gui"? I get conflicting docs / examples..
[13:42] <Mirv> ok, I guess setup
[14:15] <niemeyer> jdstrand: Do you have a moment for a call with pedronis and myself?
[14:25] <davmor2> ogra_: how do you login to snapweb?
[14:29] <mhall119> Mirv: awesome work on the qt 5.7 part! Does it pull source and build it, or does it use pre-build binaries?
[14:31] <ogra_> davmor2, log in ?
[14:31] <davmor2> ogra_: sorry access
[14:31] <ogra_> i never had to .... does it have a login rfeature now ?
[14:31] <ogra_> http://snapweb.local:4200/
[14:32] <davmor2> ogra_: cool I'll give that a try then thanks
[14:32] <ogra_> or use the IP instead of snapweb.local
[14:33] <davmor2> ogra_: success
[14:33] <ogra_> good
[14:34] <davmor2> ogra_: I'm just using usb rather than transfering to hdd
[14:43] <Mirv> mhall119: so pull (upstream only source) and build it, my qt-ubuntu dream is still alive but requires someone to guide me how to make the content interface work for real, maybe next week :)
[14:45] <mhall119> Mirv: I was talking to sitter the other day, and he suggested we could build our own binary tarballs of upstream's releases, and use those for the cloud part rather than re-building it for every apps
[14:46] <mhall119> that would be somewhere between what you have now and your qt-ubuntu dream, and would allow apps that don't want to use the shared version to bundle their own
[14:46] <Mirv> mhall119: sure, that could work too. that's why I suggested after: [qt57] to be only used in case the app developer absolutely requires newer Qt than what is available in Ubuntu, but if the use increases the part could be changed to that.
[14:50] <john-mcaleely> I'm seeing reports, which I don't fully have to hand, that some go binaries are not running on current snappy rpi images. is this a known issue?
[14:50] <john-mcaleely> JohnAgosta, ^ fyi
[14:51] <jdstrand> niemeyer: I'm on holiday today (and tomorrow), but saw this passing through. I can do it now if it is quick
[14:51] <ogra_> given that snapd is go itself, these must be very specific go bits that dont work in your binaries then
[14:51] <john-mcaleely> hmm. the log message is: Oct 1 20:59:49 PiCloud snap[3346]: runtime: this CPU has no floating point hardware, so it cannot run
[14:51] <john-mcaleely> Oct 1 20:59:49 PiCloud snap[3346]: this GOARM=6 binary. Recompile using GOARM=5.
[14:51] <john-mcaleely> let me dig in to how that snap is produced
[14:52] <ogra_> doea snap list work (or any other snap command)
[14:52] <john-mcaleely> I assume the platform is Pi2, but that's one of the things I don't have exactly, yet
[14:52] <john-mcaleely> yes
[14:52] <john-mcaleely> so I take your point that something odd is up
[14:52] <ogra_> pi2 or 3 shouldnt make any difference
[14:52] <john-mcaleely> hmm
[14:52] <jdstrand> john-mcaleely: that is probably the snap-confine bug stripping out auxv. that was fixed a while ago. you should use updated images
[14:52] <ogra_> the image is the same, only the uboot binary differs
[14:53] <john-mcaleely> jdstrand, aha. Got a bug # so I can read?
[14:53] <ogra_> LOL
[14:53] <john-mcaleely> fwiw, the issue manifests after an update
[14:54]  * ogra_ just found how the wifiSd card does its firmware upgrades for the embedded OS 
[14:54] <ogra_> this is hilarious
[14:55] <john-mcaleely> ondra, catch-up: http://pastebin.ubuntu.com/23303463/
[14:56] <ondra> john-mcaleely thanks!
[14:56] <jdstrand> john-mcaleely: https://bugs.launchpad.net/snap-confine/+bug/1621127
[14:56] <mup> Bug #1621127: snap-confine doesn't work with new snap-run/snap-exec flow <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1621127>
[14:56] <john-mcaleely> ondra, ^
[14:56] <jdstrand> john-mcaleely: you need the snap-confine from xenial-proposed
[14:56] <ondra> ogra_ snap list works
[14:57] <john-mcaleely> should this be killing nextcloud boxes?
[14:57] <jdstrand> I don't know what is in the images
[14:57] <john-mcaleely> it appears to be
[14:57] <ondra> ogra_ snap install hello-world and then I get GOARM complain
[14:57] <ogra_> ondra, yeah, then the issue is likely the snap confine bug, GO itself seems to be fine
[14:57] <jdstrand> but you can see if you have a fixed snap-confine by doing 'grep unsafe /etc/apparmor.d/usr.lib.snapd.snap-confine
[14:57] <ondra> john-mcaleely funny enough nextcloud is still running :)
[14:57] <jdstrand> it nothing comes back, you need an updated snap-confine/image
[14:57] <ondra> ogra_ what is confine bug? :)
[14:58] <john-mcaleely> ondra, this one https://bugs.launchpad.net/snap-confine/+bug/1621127
[14:58] <mup> Bug #1621127: snap-confine doesn't work with new snap-run/snap-exec flow <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1621127>
[14:59] <ondra> jdstrand grep unsafe gives me nothing
[14:59] <ondra> jdstrand I did run apt-get update && upgrade
[14:59] <ondra> jdstrand what else shall I update then?
[14:59] <john-mcaleely> ie, you're on a 16.04 system hosting snaps
[15:00] <jdstrand> ondra: you need xenial-proposed
[15:00] <ondra> jdstrand OK I have thant, I only updated snapd though
[15:00] <ondra> safe to run upgrade on all?
[15:00] <jdstrand> ondra: https://launchpad.net/ubuntu/+source/snap-confine/1.0.43-0ubuntu1~16.04.1
[15:01] <jdstrand> ondra: I don't know everything in xenial-proposed. just grab those two debs and install
[15:02] <ogra_> niemeyer, plars, http://paste.ubuntu.com/23303485/
[15:02] <ogra_> ;)
[15:03] <ondra> jdstrand OK snap-confine + snapd from xenial-proposed seems to do the trick for hello-world
[15:03] <jdstrand> hopefully snap-confine will get through SRU this week. ara is testing it
[15:03] <john-mcaleely> so why do users see broken-ness now on nextcloud boxes?
[15:03] <jdstrand> ok, I'm off today so wandering off unless niemeyer catches me soon
[15:03] <ara> jdstrand, well, kind of, I am asking peopole to test some of the bugs
[15:03] <john-mcaleely> has something been released too early?
[15:04] <niemeyer> jdstrand: Hello
[15:04] <ara> jdstrand, some of those are difficult to understand what needs to be tested
[15:04] <jdstrand> niemeyer: hey
[15:04] <ara> jdstrand, so I am pinging the original reporters
[15:04] <niemeyer> jdstrand: We can do it here so I don't disturb your holidays too much
[15:04] <jdstrand> that's fine
[15:05] <niemeyer> jdstrand: Our goal is to have most of the hardcoded logic in our assertions dropped in favor of snap declarations by the end of the week
[15:05] <jdstrand> niemeyer: if this is about snap declarations, vyi I started the review tools stuff last week and roadmr is working on the store side
[15:05] <jdstrand> niemeyer: yes, I saw the email. I think that is doable
[15:05] <niemeyer> jdstrand: For that, we'll need the actual declaration in place
[15:05]  * jdstrand nods
[15:06] <niemeyer> jdstrand: One thing we can do is to have a short term plan for importing the actual declarations directly in the store server, and then go back to the review tools for finishing it the proper way
[15:06] <niemeyer> jdstrand: As long as the assertions are up there, maintaining the status quo we have in code, we should be good to go for the RC
[15:06] <jdstrand> niemeyer: roadmr and I synced last week and decided how the review tools and the store will interact. he should be unblocked for entering into the store and for snapd queries. I don't know the status of his work
[15:07] <niemeyer> jdstrand: So the challenge is building a list of all assertions we need, and burning it down until friday
[15:07] <jdstrand> I should be able to finish up the review tools on wed
[15:07] <rvr> In which project do I fill a bug for console-conf?
[15:07] <ogra_> niemeyer, plars, so all we need now is a busybox for armv5l that has dd and wget enabled, some scriptery and we can directly flash images over wifi, independent of what the devel board we want to test currently does (as long as the wifiSD card has power), i tested with beagle, both pi's and the dragonboard, they can all boot fine from the wifiSD rootfs when you dd it to the SD part and use the SD->microSd adapter
[15:07] <jdstrand> (of course, that would not include a store rollout)
[15:07] <niemeyer> jdstrand: Yeah, I know there's some trickery around reviewing/store interactions
[15:07] <niemeyer> jdstrand: Which is why I'm proposing we side-step the initial loading so we're not blocked on that
[15:07] <jdstrand> niemeyer: there is, but we have the path forward and are unblocked on each other
[15:07] <niemeyer> jdstrand: As long as we have the assertion content itself, we should be able to move on in time for the RC
[15:08] <jdstrand> niemeyer: aiui the store has a form field for the payload for slots and plugs. but when roadmr and I last spoke, he said entering anything in there breaks things
[15:09] <niemeyer> ogra_: Interesting.. did you dd via wifi already?
[15:09] <niemeyer> jdstrand: Hmm.. things?
[15:09] <ogra_> niemeyer, not yet, but i should have a working setup for all of tezh above during this week
[15:10] <ogra_> after finding that hilarious autorun.sh thingie the rest is just finger training
[15:10] <jdstrand> niemeyer: I don't know the status of that-- but, it seems reasonable that, yes, if they can store the snap declaration for snapd to query on for lxd, docker and the kernel-module-control consumer, then the store can simply insert that payload in those form fields as if this was a subsequent run
[15:10] <niemeyer> jdstrand: Right
[15:10] <niemeyer> jdstrand: Cool, let's push that forward when you're back on Wed
[15:10] <jdstrand> that is all +1 from me
[15:10] <niemeyer> jdstrand: Have fun there!
[15:11] <jdstrand> but, importantly, I am working on the review tools, not the store side. please sync with roadmr for the store side status and storing of the snap declarations
[15:11] <jdstrand> (well, the review tools are store side, but I think you know what I mean)
[15:12] <niemeyer> jdstrand: Yeah, thanks
[15:12] <jdstrand> niemeyer: today is Candian thanksgiving so roadmr it off, but he should be back tomorrow
[15:13] <jdstrand> well, I'm assuming he is off
[15:13] <niemeyer> jdstrand: I think pedronis is in sync with him about that (or will be)
[15:13] <jdstrand> ok great
[15:14] <niemeyer> ogra_: Cool.. that's probably the trickiest part of it.. if we can get the wiif card to dd behind the device's back, the rest should work fine
[15:16] <ogra_> niemeyer, shouldnt be any prob really ... just time and work :)
[15:21] <ogra_> oh, whee ... wget is actually there already
[15:21] <ogra_> just need dd
[15:22] <ogra_> hmm, though /dev/mtdblock0 on the embedded linux only has 268K free ... we'll need to stream into dd from wget
[15:23] <ogra_> and need the images uncompessed on the server since we cant unxz them
[15:23] <ogra_> oh this is so much fun !!!
[15:25] <ogra_> but it is astonishing how insecure these wifiSD cards are ...
[15:33] <SuperJonotron> on 16.04.1 LTS, is there any way to allow access to modifying contents of the /etc/ folder?
[15:35] <ogra_> niemeyer, http://paste.ubuntu.com/23303624/
[15:35] <ogra_> :D
[15:35] <shuduo> ogra_: hi, i flash new beta3 pi2 image and went through console-conf. After finish, I use ssh to login pi2 but it prompt password need input. Is it expected?
[15:36] <ogra_> shuduo, did console-conf properly finish (i.e. telling you the ssh line you should use)
[15:37] <shuduo> ogra_: yes. i have booted it and went through console-conf but did not finish. Second time I finished and ssh line told me what i need.
[15:38] <ogra_> try a reboot then and file a bug that console-conf didnt finish
[15:41] <shuduo> ogra_: let me re-dd and try again. if it can be reproduced i will file a bug. thanks.
[15:43] <ogra_> i bet it can
[15:49] <ppisati_> ogra_: morphis: i've pushed out a new image containing a new kernel - with this image i cannot reproduce the serial oops anymore, if you can test it and comment that would be nice since i plan to push it out tomorrow
[15:49] <ppisati_> lp1630586
[15:50] <ppisati_> bug1630586
[15:50] <ppisati_> the bot is not collaborating...
[15:56] <ogra_> bug 1630586
[15:56] <mup> Bug #1630586: Pi3 kernel crash and is unreliable <patch> <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1630586>
[15:56] <ogra_> ppisati_, it is just picky
[15:57] <ogra_> (needs the space)
[16:56] <shuduo> ogra_: hi, i can reproduce the issue but i'm curious it happen only i gave a specific account (my colleague). but it works well with with my launchpad account
[17:53] <mup> PR snapd#2121 opened: snapy: do not auot-import from loop or non-dev devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2121>
[18:12] <mhall119> JamesTait: ping
[18:14] <mhall119> JamesTait: Have you proposed your ejabberd snap configs to upstream?
[19:22] <mup> PR snapcraft#835 closed: Add the test upstream rules <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/835>
[19:55] <mup> PR snapcraft#860 closed: In the downloader demo test, use https <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/860>
[20:03] <mup> PR snapd#2122 opened: snappy: disable auto-import of assertions on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/2122>
[20:15] <mup> PR snapd#2123 opened: daemon: ensure `snap create-user --known` errors on classic (unless --force-managed is added) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2123>
[20:15] <thomi> Does anyone know how to specify which version of go is used to build a snap with the 'go' snapcraft plugin ?
[20:16] <thomi> ahh, it seems I'm hitting https://bugs.launchpad.net/snapcraft/+bug/1616985
[20:16] <mup> Bug #1616985: the go plugin doesn't support go 1.7 <plugin> <Snapcraft:New> <https://launchpad.net/bugs/1616985>
[20:19] <mup> PR snapcraft#862 closed: Add powerpc (32bit big-endian) support <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/862>
[20:22] <mup> PR snapcraft#849 closed: Bugfixes for gated and validate commands <Created by ralsina> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/849>
[20:26] <SuperJonotron> ubuntu-core file system is read only and can't modify anything on the file system as root, is this normal?
[20:48] <mup> PR snapd#2124 opened: daemon: add postCreateUserSuite test suite <Created by mvo5> <https://github.com/snapcore/snapd/pull/2124>
[21:16] <mup> PR snapcraft#859 closed: Set GOBIN in go plugin build environment <Created by tasdomas> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/859>
[21:48] <mup> Bug #1632085 opened: Support "fudge factor" for file system sizing <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1632085>
[21:54] <mup> Bug #1632124 opened: snapd pegging cpu at 100% <Snappy:New> <https://launchpad.net/bugs/1632124>
[21:57] <niemeyer> ogra_: Looks promising!
[21:57] <dr1337> Hey guys do you know if canonical provides support to port to an unsupported ARM board?
[22:00] <thomi> jdstrand: I understand you're the person to talk to about click-reviewer-tools warnings? I'm trying to ship a snap that contains a shell script, and getting "Could not find compiled binaries for architecture 'amd64'".
[22:01] <thomi> jdstrand: I'm not sure what I should be doing differently though...
[22:12] <mup> Bug #1632130 opened: Can't download snaps from ARM hardware running Classic <Snappy:New> <https://launchpad.net/bugs/1632130>
[22:24] <JamesTait> mhall119, I haven't. Two reasons: 1) It's not just a straight `snapcraft`, you have to `snapcraft prime; patch -p0 < README.md; snapcraft`. 2) When I mentioned my snap of one of the ejabberd releases on the public mailing list, it was met with hostility, which rather put me off.
[22:26] <JamesTait> mhall119, http://lists.jabber.ru/pipermail/ejabberd/2016-August/009066.html
[22:49] <mup> Bug #1611078 changed: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <Snappy:Fix Released by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <https://launchpad.net/bugs/1611078>