[01:51] <sergiusens> bdmurray, on 15.04 you can snappy install lxd; on 16.04 (probably the recommended target for new dev); snappy enable-classic
[03:04] <wililupy> question: Is webdm still in the Snappy store? I try to install it with sudo snappy install webdm but I get webdm failed to install: snappy package not found
[07:04] <torbit> Hi guys,
[07:04] <torbit> I am trying to pull down the snappy core image for i386
[07:05] <torbit> I cant seem to get it
[07:05] <torbit> I get a 404 on this : wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
[07:05] <torbit> unxz -c ubuntu-15.04-snappy-amd64-generic.img.xz
[07:05] <torbit> does anyone have something that I can pull publicly ?
[07:08] <torbit> anyone online ?
[07:11] <torbit1> Ok seems like it was something on my network . sorry
[07:11] <torbit1> thanks
[07:58] <dholbach> good morning
[08:13] <fgimenez> good morning
[08:42] <renat> Hi all! It's Renat from Screenly again=)
[08:43] <renat> When setting up assign rules in the oem snap - is it possible to add device access rules (MODE="", GROUP="")?
[08:44] <renat> For example, we need to use /dev/vchiq. And I add appropriate option to the assign: section.
[08:44] <renat> assign: rules: - kernel: vhciq
[08:46] <renat> But it device isn't accessible because of very strict access mode.
[09:45] <JamesTait> Good morning all!  Happy Tuesday, and happy Hedgehog Day! 😃
[11:44] <torbit> Hi folks. I need some help
[11:44] <torbit> I downloaded a generic x86 image
[11:44] <torbit> I would like to know what the OEM part of the docs is exactly.
[11:44] <torbit> I am not getting that part very wekk
[11:44] <torbit> well I mean
[12:12] <kyrofa> Good morning
[12:15] <torbit> good morning kyrofa
[12:16] <torbit> although on my end it is afternoon . Nice sunny day in Nairobi
[12:16] <kyrofa> Hello torbit :) . I'm afraid I don't know much about OEM stuff right now, other than it's a bit in flux right now between 15.04 and 16.04
[12:17] <ogra_> torbit, essentially it contains the bootloader
[12:17] <torbit> ogra_ : hmmmm. I see
[12:17] <ogra_> amd64 is a bit special here though ... unlike the arm arches it only ships the bootloader config http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/generic-amd64/
[12:18] <torbit> well in my case I am working with some intel device.
[12:18] <ogra_> (grub gets simply pulled out of the rootfs when the oem snap gets put into place by ubuntu-device-flash)
[12:18] <torbit> oh.
[12:19] <torbit> that I did not know
[12:19] <mvo_> ogra_: how is the arm64 cdimage.u.c output looking? are we getting close to soemthing that we can consume :) ? u-d-f and the store are fixed so we can move again
[12:19]  * mvo_ lunch
[12:19] <ogra_> mvo_, oh, not done yet +
[12:19] <mvo_> ogra_: ok
[12:19] <mvo_> ogra_: just curious, no real rush
[12:19] <ogra_> i need to do the rpi bootloader update today, then i'll move on to cdimage
[12:19] <mvo_> ogra_: at least we can move forward now again with the store fixed
[12:20] <mvo_> ogra_: \o/ ok
[12:20] <ogra_> yeah :)
[12:20] <ogra_> mvo_, we wont be able to build arm64 until we have a kernel package in the archive though
[12:20] <torbit> ogra_: hmmmm. so I guess that means I need to create the root.tar.xz?
[12:20] <ogra_> ppisati said there were still bits blocking it
[12:21] <torbit> am I correct in assuming  this ?
[12:21] <ogra_> torbit, for wghat exactly
[12:21] <torbit> ogra_: in my case I am trying to create a bootable disk to flash a device
[12:21] <torbit> so use snappy core
[12:21] <torbit> the device is currently using ubuntu server
[12:21] <ogra_> torbit, sure, but why does the existing setup not work for you
[12:22] <ppisati> ogra_: yes, the dragonboard kernel won't enter the archive as it is, until we have a multi-arm64 kernel etc
[12:22] <ppisati> ogra_: for now you'll have to use my ppa
[12:22] <torbit> ogra_: so this is what I did, I took the generic image , made a bootable flash with DD
[12:22] <ogra_> ppisati, i doubt we want that for cdimage builds ... but i can copy it to the snappy hardware PPA i guess
[12:22] <ppisati> ogra_: k
[12:22] <torbit> ogra_: I plug it in an nothing .
[12:23] <ppisati> ogra_: i'm writing you an email right now
[12:23] <torbit> so I am not too sure what I am doing wrong to be honest
[12:23] <ppisati> ogra_: with uboot etcetc
[12:23] <torbit> ogra_: it is my first time
[12:23] <ogra_> torbit, well, it should work on any x86 system
[12:23] <ogra_> ppisati, ok, thanks !
[12:24] <torbit> ogra_: tell me does this platform need to have a screen to select this image in the boot loader or does it just boot into it
[12:24] <ogra_> torbit, you might want to take a look at the kernel cmdline on the created usb stick, could be that the early boot defaults to do all output to the serial console
[12:25] <ogra_> it should boot straight through
[12:25] <ogra_> (the first boot takes a while though, it creates ssh keys and such)
[12:26] <torbit> ogra_: hmmm. oooh I see. ok one sec I try this one more time
[12:27] <ogra_> is that 32 or 64bit hardware ?
[12:28] <torbit> ogra_: 32 bit
[12:28] <ogra_> oh
[12:28] <torbit> for sure
[12:28] <torbit> ogra_: it is intel chip based
[12:29] <ogra_> you might need to build an i386 image manually then
[12:29] <torbit> ogra_: can we DM ?
[12:30] <ogra_> the generic x86 image we offer pre-built is using UEFI and a 64bit kernel to boot
[12:30] <torbit> aaaaah
[13:09] <noizer> kyrofa Hi my snappy just rebooted automatically and some things dont work anymore just lik i installed python on my snap but when he executes a command he doesn't find python anymore :s
[13:10] <kyrofa> noizer, I can't remember-- are you on 15.04 or rolling?
[13:10] <ogra_> on rolling (snapcraft 2.0 snaps ;) )
[13:11] <kyrofa> noizer, hmm, can you check the shebang of the python script you're trying to run? What does it look like?
[13:11] <noizer> yea on rolling
[13:13] <noizer> kyrofa wait i dont use the shebang the command looks like : python file.py
[13:14] <noizer> and then the error is python not found
[13:15] <kyrofa> noizer, is this a daemon, or no?
[13:16] <noizer> no deamon
[13:17] <noizer> but when i do snappy list i don't get the core anymore so I think my snappy is broken :s
[13:18] <noizer> so I will install snappy again
[13:18] <beuno> kyrofa, FYI, you can now upload multiple architectures and releases
[13:19] <beuno> ogra_, ^
[13:19] <kyrofa> beuno, woo hoo!
[13:19] <kyrofa> beuno, do I need to do anything special? Or will foo_1.2_amd64.snap and foo_1.2_armhf.snap just magically go to the right place as long as the YAML is the same?
[13:19]  * ogra_ hugs beuno 
[13:20] <beuno> kyrofa, magically
[13:20] <kyrofa> beuno, I like magic
[13:20]  * beuno briefly naps in ogra_'s hug
[13:20] <kyrofa> Man that's a long hug
[13:21] <kyrofa> beuno, thanks for the hard work! I'm testing it out now
[13:21] <noizer> Kyrofa i think i found an issue of snappy. The pythonpath is only directed to the dist-packages and not to the site-packages
[13:21] <noizer> is that normal or?
[13:21] <kyrofa> noizer, they should be a symlink
[13:22] <noizer> when i putted some folders in the site-packages, they cant be imported :s
[13:22] <beuno> kyrofa, I'll leave the thanks in its original packing until it's gotten a bit of mileage and people are still happy  :)
[13:22] <kyrofa> beuno, haha
[13:23] <kyrofa> noizer, can you run ls -l on the directory containing site-packages?
[13:24] <renat> Hi guys! Let me repeat my question.
[13:24] <renat> When setting up assign rules in the oem snap - is it possible to add device access rules (MODE="", GROUP="")?
[13:24] <renat> For example, we need to use /dev/vchiq. And I add appropriate option to the assign: section.
[13:24] <renat> assign: rules: - kernel: vhciq
[13:24] <renat> But it device isn't accessible because of very strict access mode.
[13:26] <kyrofa> ogra_, renat's question may be best suited for you
[13:27] <sergiusens> kyrofa, elopio https://github.com/ubuntu-core/snapcraft/pull/286
[13:27] <ogra_> kyrofa, i have no clue about the capability system
[13:27] <ogra_> kyrofa, all i knew about was hw-assign ... i kind of lost track when we dropped that
[13:27] <kyrofa> ogra_, oh I thought OEM was 15.04
[13:27] <kyrofa> ogra_, I'm getting confused so quickly :P
[13:28] <ogra_> i dont even think in 15.04 there was a way to do it automated
[13:28] <kyrofa> ogra_, ah, now that you mention it, I do remember hearing that
[13:28] <ogra_> it was all a manual call to hw-assign asd i remember
[13:29] <sergiusens> ogra_, that is all 15.04 renat is talking about
[13:29] <sergiusens> ogra_, there was in the oem snap; mvo_ implemented
[13:29] <ogra_> sergiusens, well, do you remember if there was a way to do it from the oem ?
[13:29] <sergiusens> ogra_, surely asac knows about this since he wrote a guide
[13:29] <ogra_> ah, i didnt know
[13:29] <ogra_> i only ever used hw-assign back then
[13:29] <kyrofa> sergiusens, do you know about the mode/group bits?
[13:30] <ogra_> i dont think mode/group will help much ... apparmor will block before you even get to that
[13:30] <sergiusens> ogra_, kyrofa in case it is of interest https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
[13:30] <ogra_> mode and group should be handled through udev-acl anyway
[13:30] <sergiusens> kyrofa, no, I think it is just tagging
[13:31] <sergiusens> renat, if it is not a service, use sudo
[13:31] <renat> ogra_, not apparmor blocking me
[13:31] <renat> sergiusens, it's a service. Is it possible in 16.04?
[13:32] <sergiusens> renat, stick to 15.04 for now; if it is a service and blocked I don't know, seccomp maybe?
[13:32] <sergiusens> renat, sudo snappy install snappy-debug
[13:33] <renat> sergiusens, thanks. I will try.
[13:36] <sergiusens> jdstrand, maybe you have ideas ^
[13:37] <dholbach> sergiusens, kyrofa: let me know if you need snapcraft 2.1 uploaded to xenial
[13:38] <dholbach> ah no... you have upload rights for it now, right?
[13:39] <sergiusens> dholbach, hah, I don't need you for that anymore :-P
[13:39] <sergiusens> dholbach, sorry ;-)
[13:39] <dholbach> yeah... I know
[13:39] <dholbach> go go go!
[13:39] <sergiusens> dholbach, still waiting on pocketsphinx though ;-)
[13:42] <kyrofa> sergiusens, so you were able to build a rolling image that worked?
[13:47] <jdstrand> renat: if it is a service, it should be running as root so file perms shouldn't be an issue. I suggest 'sudo snappy install snappy-debug' and then 'sudo snappy-debug.security scanlog' in one console while trying to use the app in another.
[13:53] <renat> jdstrand, understood. thanks.
[13:53] <renat> Seems it's trying to access /proc/4212/mounts
[13:53] <renat> For the some reason
[13:55] <sergiusens> kyrofa, I downloaded from mvo_'s p.c.c
[13:55] <sergiusens> kyrofa, just this morning
[13:55] <kyrofa> sergiusens, ah okay
[13:55] <jdstrand> beuno, mvo_: I saw something about uploads to the store going to the write place. I noticed on a 15.04 bbb system that it is trying to install hello-world.canonical 1.0.18 over and over and over again
[13:56] <jdstrand> s/write/right/
[13:56]  * sergiusens goes for a quick run
[13:56]  * jdstrand is curious if these things are related
[13:57] <beuno> jdstrand, good question. What we've enabled, FWIW, is multiple binaries for different architectures andreleases
[13:59] <jdstrand> beuno: so that means that I can have an ar-snap for 15.04 and a squashfs-snap for rolling both targeting !edge and it all works?
[14:01] <beuno> jdstrand, correct
[14:01] <jdstrand> that sounds nice indeed
[14:02] <asac> ogra_: check out the guide
[14:02] <asac> it has that info
[14:02] <jdstrand> mvo_: fyi, something weird is happening on bbb 15.04 and hello-world.canonical starting yesterday
[14:03] <asac> ogra_: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
[14:03] <asac> search for assign:
[14:10] <mvo_> jdstrand: what is it?
[14:10] <mvo_> jdstrand: since yesterday you say? do you have some more details?
[14:10] <mvo_> jdstrand: there were some changes to the store related to the multi-dimension uploads
[14:11] <ogra_> asac, well, tell that renat ;)
[14:20] <asac> mvo_: what are multi dimension upload?
[14:21] <ogra_> 4D uploAds !
[14:21] <asac> 5D at least
[14:21] <asac> >(
[14:21] <ogra_> :)
[14:22] <noizer> kyrofa what was the update of the snappy build because it rebooted it for update (ubuntu 16.04)
[14:22] <kyrofa> noizer, you'd have to ask mvo_
[14:22] <awe__> hey, can any of you tell me how to view the kernel options for our latest snappy rolling ripi2 image?
[14:22] <kyrofa> noizer, remember you're on rolling, so some instability is not surprising
[14:23] <ogra_> awe__, isnt /proc/config.gz populated ?
[14:23] <davmor2> asac, ogra_: you seem to missing the point, there is no limit to multi ;)
[14:23] <ogra_> (i usually set that by default before giving ppisati my config)
[14:23] <noizer> awe_ what is changed during the update with the rolling version?
[14:23] <noizer> awe__ what is changed during the update with the rolling version?
[14:23] <awe__> ogra_, nope
[14:23] <kyrofa> noizer, can you pastebin your binary wrapper for me?
[14:24] <ogra_> awe__, hmm, then you need to apt-get source the package i fear ...
[14:24] <mvo_> asac: the same name for multiple architectures, i.e. no more ubuntu-core-armhf
[14:24] <ogra_> awe__, https://launchpad.net/ubuntu/+source/linux-raspi2
[14:24] <davmor2> asac, ogra_: What mvo_ was trying to create with that statement was "XD uploads" :D
[14:24] <awe__> ogra_, thanks dude
[14:26] <noizer> kyrofa http://pastebin.com/647GUD2q
[14:27] <kyrofa> noizer, I mean the one in /snaps/bin/
[14:27] <asac> mvo_: ok, i wouldnt call it |dimension"
[14:27] <asac> that name is already taken
[14:27] <asac> but just nit pikcing
[14:27] <asac> ttyl
[14:28] <noizer> kyrofa ok
[14:28] <kyrofa> noizer, I know, there are a lot of wrappers :)
[14:29] <mvo_> asac: I agree, we were calling it multi-arch before which is arguable way worse
[14:29] <noizer> kyrofa haha yea there are many wrappers but when my snappy was done with the update he doesnt have any snapp dir anymore :s
[14:29] <ogra_> http://foodnetwork.sndimg.com/content/dam/images/food/fullset/2012/9/25/0/ZB0307H_grilled-chicken-caesar-wrap_s4x3.jpg
[14:29] <ogra_> ;)
[14:29] <kyrofa> noizer, the /snaps directory is gone?
[14:30] <noizer> kyrofa yea he is gone
[14:31] <sergiusens> elopio, kyrofa time to stand
[14:31] <kyrofa> noizer, huh... yeah I'd reflash. Not sure what's going on there
[14:31] <kyrofa> sergiusens, ah, right thanks
[14:33] <noizer> maybe i will try again build a new image and see what he is doing while he is updating?
[14:33] <noizer> kyrofa
[14:37] <jdstrand> mvo_: sorry, got pulled away
[14:38] <awe__> ogra_, that branch was for wily...  and I can't seem to come up with the right source package name for 'apt-get source'
[14:38]  * awe__ jumps to #ubuntu-kernel
[14:39] <ogra_> awe__, just grab the .deb ... then dpkg -x /part/to/deb .
[14:39] <ogra_> (that will extract it to the current dir, probably create some ./tmp or some such )
[14:39] <mvo_> jdstrand: no problem, I'm am pretty busy myself with various issues
[14:39] <awe__> I'm not sure where the .deb lives or what it's name is
[14:39] <awe__> if I did, I certainly would do that!  ;)-
[14:39] <ogra_> it is linked from the above page i gave you
[14:39] <awe__> that's a wily branch
[14:40] <ogra_> https://launchpad.net/ubuntu/+source/linux-raspi2 shows wily and xenial
[14:40] <jdstrand> mvo_: http://paste.ubuntu.com/14857472/
[14:40] <awe__> ah, my bad
[14:40]  * awe__ goes and looks again
[14:40] <ogra_> clicking on the version will get you to the package
[14:40] <ogra_> (then click on "armhf" there to get the binary deb)
[14:41] <mvo_> jdstrand: so its reinstalling hello-world evey 1h?
[14:41] <ogra_> (under "Builds")
[14:41] <awe__> got it
[14:41] <jdstrand> mvo_: so, starting at 11:00 local (17:00 UTC), snappy started regenerating apparmor profiles on the hour, every hour for hello-world.canonical, but not other snaps
[14:42] <kyrofa> beuno, so I have version X uploaded to the store for armhf. I tried "Upload a New Version" of version X for amd64, and it's complaining that the version is already uploaded. Do I have to change the version per arch?
[14:42] <jdstrand> mvo_: the other snaps that are install (one sideload, snappy-debug and ufw) did not dual-land
[14:42] <jdstrand> I believe ufw may be an ar-based snap in rolling, and snappy-debug you need edge
[14:43] <jdstrand> oh, but his is all 15.04
[14:43] <mvo_> jdstrand: I suspect its actually reinstalling this every hour?
[14:43] <jdstrand> $ snappy list
[14:43] <jdstrand> Name         Date       Version      Developer
[14:43] <jdstrand> ubuntu-core  2016-01-20 13           ubuntu
[14:43] <jdstrand> bind9        2016-01-20 IKaMHDSJATaY sideload
[14:43] <jdstrand> hello-world  2015-12-27 1.0.18       canonical
[14:43] <jdstrand> snappy-debug 2016-01-06 0.10         canonical
[14:43] <jdstrand> ufw          2015-12-17 0.35         jdstrand
[14:43] <jdstrand> beagleblack  2015-12-17 1.12         canonical
[14:43] <jdstrand> mvo_: that is what I expect is happening
[14:43] <noizer> kyrofa any idea how i force an update,
[14:43] <jdstrand> s/expect/suspect/
[14:43] <kyrofa> mvo_, it seems that canonistack hasn't built a rolling image since it moved to all snaps
[14:44] <kyrofa> mvo_, do you know anything about that?
[14:45] <ogra_> we build images in canonistack ?
[14:45] <ogra_> since when
[14:46]  * ogra_ thought we dont build rolling images at all ... you always need u-d-f for it 
[14:47] <ogra_> kyrofa, nothing moved to all-snaps yet except mvos dir at people.c.c
[14:47] <jdstrand> kyrofa: aiui, there is nothing that automatically builds the os, kernel and gadget snaps used with these images. that work, aiui, is planned
[14:47] <ogra_> the cdimage builds still only produce the old setup
[14:47] <ogra_> (on my list for this week)
[14:50] <noizer> mvo_ is there a way to update the image with a command line?
[14:51] <ogra_> snappy update ubuntu-core
[14:51] <ogra_> (+ sudo )
[14:51] <mvo_> jdstrand: will "snappy list -u" show you hello-world as upgradable?
[14:51]  * jdstrand checks
[14:52] <mvo_> jdstrand: I'm still puzzled by this :)
[14:52] <kyrofa> jdstrand, ogra_ ah, I keep misunderstanding that. So rolling really is dead right now?
[14:52]  * jdstrand taps fingers
[14:52] <jdstrand> mvo_: it does not
[14:52] <jdstrand> $ snappy list -u
[14:52] <jdstrand> ...
[14:52] <jdstrand> hello-world  2015-12-27 1.0.18
[14:52] <jdstrand> ...
[14:53] <mvo_> jdstrand: hrm, hrm, that is confusing
[14:53] <jdstrand> mvo_: you said a change landed yesterday on the store. I imagine that change was between 1600 and 1700 UTC
[14:53] <mvo_> jdstrand: worth checking with the u1 guys
[14:54] <jdstrand> mvo_: it seems like this is perhaps something that needs to be backed out unless we know that it isn't affecting shipping devices
[14:54] <jdstrand> this would likely disrupt a service for a snap that this is happening to
[14:55] <ogra_> kyrofa, no, it is simply not moved to all snaps yet ... everything should work though
[14:55] <ogra_> (but using system-image)
[14:55] <mvo_> jdstrand: I forwarded your question
[14:55] <kyrofa> ogra_, "dead" = not getting any updates, I mean
[14:56] <ogra_> it is getting them daily ;)
[14:56] <ogra_> in fact all-snaps isnt getting any currently :)
[14:56] <ogra_> (apart from manual builds mvo_ does)
[14:57] <jdstrand> mvo_: thanks
[14:57] <kyrofa> ogra_, huh, okay. Yeah, I really misunderstood :P
[14:58] <noizer> kyrofa now i updated the ubuntu core again and yet i dont have a snapps dir
[14:59] <kyrofa> noizer, I'm afraid you've moved beyond my experience. sergiusens or mvo_ may be able to help you better
[14:59] <sergiusens> stgraber, hey, looking at using pylxd, but stumbled upon something which you were on the path to fix https://github.com/lxc/pylxd/pull/53
[15:01] <noizer> serguissens mvo_ Hi guys, i did just an update of my ubuntu core and now my snapps dir is totaly gone.
[15:01] <noizer> sergiusens
[15:01] <noizer> sergiusens mvo_ When i installed a snap with python he doesn't recognized the keyword python anymore
[15:02] <noizer> sergiusens mvo_ Any suggestions
[15:02] <noizer> ?
[15:02] <mvo_> noizer: are you running 16.04 (rolling) ?
[15:03] <mvo_> noizer: or is that on 15.04?
[15:04] <ogra_> mvo_, 16.04 system-image
[15:04] <noizer> mvo_ rolling
[15:05] <sergiusens> noizer, oh, python 2 is not part of rolling; you will need to use snapcraft and the python plugin
[15:05] <sergiusens> or use python3
[15:05] <sergiusens> kyrofa, ^
[15:05] <ogra_> sergiusens, i think he does use the python2 plugin
[15:06]  * ogra_ gave him the runes 
[15:06] <sergiusens> ogra_, when someone uses the copy plugin I always suspect ;-)
[15:06] <noizer> sergiusens sorry i use the python2 plugin at this time
[15:06] <ogra_> but if the /snaps dir is gone that wont help much :)
[15:06] <kyrofa> sergiusens, yeah no shebang or anything
[15:06] <ogra_> sergiusens, not copy ... just the same runes i use for mycroft
[15:07] <ogra_>   config:
[15:07] <ogra_>     plugin: python2
[15:07] <ogra_>     source: .
[15:07] <ogra_> and additionyl python packages via stage-ppackages in copy
[15:07] <ogra_> geez .... my typing ...
[15:07] <kyrofa> sergiusens, but the thing that's really confusing is is the /snaps dir
[15:08] <noizer> ogra_ but is there now a way to install them with pip?
[15:08]  * kyrofa went cross-eyed trying to read what ogra_ just said
[15:08] <mvo_> noizer: hm, sorry that 16.04 is a bit rocky, we had some incompatible changes recently but its stabelizing all again now. we moved to the new /snaps dir (instead of the previous /apps dir) and we moved to a new snap.yaml layout. those may have broken the image.  easiest might be to reinstall using http://people.canonical.com/~mvo/all-snaps/ -  I am updating the images as we speak
[15:08] <ogra_> kyrofa, like http://paste.ubuntu.com/14857655/ ... ;)
[15:09] <kyrofa> ogra_, hahaha
[15:09] <ogra_> config gets you the interpreter ... copy's stage-packages gets you extra modules
[15:09] <ogra_> i know i'm cheap ;) but it works
[15:09] <kyrofa> ogra_, ah, this is the "I don't want to write a setup.py" YAML?
[15:10] <noizer> mvo_ can you update me when the image is there to download?
[15:10] <ogra_> well, i dont want tio use sources if i can use prebuilt binaries ... :)
[15:11] <kyrofa> ogra_, heh :)
[15:14] <noizer> ogra_ can i install the packages then like a tornado?
[15:14] <noizer> (stage-packages)
[15:15] <ogra_> like a tornado ?
[15:15] <ogra_> dressed like a funnel whirling around ?
[15:15] <mvo_> noizer: sure, I will. I hope later today, there is one pending branch that needs review then I think all is in and the disruptions are over (fingers crossed)
[15:15] <noizer> tornado the python library
[15:15] <ogra_> ah
[15:15] <ogra_> you shoudl be able to
[15:15] <sergiusens> ogra_, nah, noizer use pip-packages; snapcraft help python2
[15:15] <ogra_> ah
[15:15] <ogra_> yeah, thats definitely different
[15:17] <noizer> ooooh ok
[15:24] <noizer> mvo_ i think i best need to wait until the problem is solved?
[15:26] <noizer> mvo_ or can i revert my update so I can work a little further?
[15:27] <mvo_> noizer: you can revert your update, just run "snappy rollback ubuntu-core"
[15:28] <noizer> mvo_ thx allot xD
[15:28] <noizer> mvo_ hopefully is it fixed soon :d
[15:29] <noizer> dammed mvo_ :p no version to roll back :p
[15:36] <mvo_> noizer: ha! of course
[15:36] <mvo_> noizer: ok, this is a bit tricky but you can force it via "grub-editenv", grub-editenv list will show whats there
[15:37] <mvo_> noizer: and if you look at /var/lib/snappy/snaps you need to set the snappy_os to the last os snap you have there
[15:37] <mvo_> noizer: its a bit risky but should work :)
[15:41] <noizer> mvo_ dammed i cant enter the classic mode anymore
[15:41] <mvo_> noizer: grub-editenv should be available in normal mode
[15:41] <mvo_> noizer: its all connected, the /snaps change also changed the data directory
[15:42] <mvo_> noizer: appologizes again, the timming is very unlucky, this is probably the worst distruption we had in the entire snappy lifecycle
[15:42] <noizer> mvo_ -bash: grub-editenv: command not found
[15:42] <noizer> mvo_ np i appreciate the good help over here so no worries
[15:47] <mvo_> noizer: hm, it should be under /usr/bin/grub-editenv
[15:48] <opny> Hello, in snapcraft how can I inform make plugin that an additional configure is needed?
[15:50] <kyrofa> opny, when you say "configure" I think autotools, not make. No?
[15:51] <noizer> mvo_ it think i will make a new image of the previous version. but can i disable automatic updates?
[15:53] <opny> kyrofa, yes, I'm not that good on the topic, sorry. I have a Makefile but requires a ./configure run first. Should I "extract" such ops from it ?
[15:54] <kyrofa> opny, nahh, you just need to use the autotools plugin!
[15:54] <kyrofa> opny, that will run configure for you (and allows you to specify configure options) as well as run make/make install for you
[15:55] <opny> kyrofa, I'll try thanks :)
[15:56] <kyrofa> opny, `snapcraft help autotools` will help
[15:57] <opny> kyrofa, oh.. great.. I used to read the plugin source till now..
[15:58] <kyrofa> opny, *cough* well that works, too...
[15:58] <opny> kyrofa, *cough* ya kind of..
[15:59] <ogra_> guys, stop sreading your germs in here !
[16:14] <torbit> hey folks. What does this mean ? `Device generic_amd64 not found on server https://system-image.ubuntu.com channel stable`
[16:15] <torbit> I run this command: ` ubuntu-device-flash core 15.04 -o my-snappy.img --channel stable`
[16:18] <ogra_> torbit, try adding --oem generic-amd64
[16:24] <torbit> ogra_: unkown flag
[16:24] <ogra_> huh ?
[16:24] <ogra_> cant be
[16:25]  * ogra_ wonders how old your ubuntu-device-flash is 
[16:25] <torbit> one sec I check for you
[16:25] <ogra_> though --oem has been supported from day one i think
[16:26] <torbit> well this may sound odd but I cant seem to get the version. However my -h flag gives me the following outout ```Usage:
[16:26] <torbit>   ubuntu-device-flash [OPTIONS] <core | query | touch>
[16:26] <torbit> Application Options:
[16:26] <torbit>       --revision=        revision to use, absolute or relative allowed
[16:26] <torbit>       --download-only    Only download.
[16:27] <torbit>       --server=          Use a different image server (https://system-image.ubuntu.com)
[16:27] <torbit>       --clean-cache      Cleans up cache with all downloaded bits
[16:27] <torbit>       --tls-skip-verify  Skip TLS certificate validation
[16:27] <torbit> Help Options:
[16:27] <torbit>   -h, --help             Show this help message
[16:27] <torbit> Available commands:
[16:27] <torbit>   core   Creates ubuntu core images
[16:27] <torbit>   query  Run queries against the image server
[16:27] <torbit>   touch  Flashes ubuntu touch images ```
[16:27] <ogra_> geez !
[16:27]  * ogra_ points to paste.ubuntu.com 
[16:27] <ogra_> :)
[16:27] <ogra_> also: ubuntu-device-flash core --help
[16:28] <ogra_> since you want to know the options for the core command
[16:28] <torbit> ogra_: http://pastebin.com/BxcU6qzM
[16:28] <torbit> same output as above
[16:29] <noizer> mvo_ will the image be updated today?
[16:30] <mvo_> noizer: thats my goal, I'm still waiting for one branch to land
[16:32] <noizer> mvo_ ok but when im trying to use an previous version it will automic update but can i disable thath?
[16:32] <mvo_> noizer: I disabled the new version for now on the server side
[16:33] <noizer> thx a lot :D
[17:05] <tsimonq2> dholbach: when I am using the guide here: https://developer.ubuntu.com/en/snappy/start/#snappy-local , can I get a newer image than 15.04?
[17:06] <tsimonq2> oic
[17:06] <tsimonq2> dholbach: is there a rolling image?
[17:07] <dholbach> tsimonq2: I don't think there's an official one, but you can roll one yourself using ubuntu-device-flash
[17:07] <tsimonq2> dholbach: how would I go about doing that?
[17:07] <dholbach> or use http://people.canonical.com/~mvo/all-snaps/
[17:08] <dholbach> which has the latest changes
[17:08] <tsimonq2> dholbach: so is this rolling edge?
[17:08] <ogra_> it will be
[17:08] <ogra_> this is a new architecture that currently only gets manual updates
[17:09] <ogra_> but shoulöd be implemented as default very soon
[17:09] <tsimonq2> dholbach: so I'll get the 1504 image as specified on the page, but can I upgrade release and channel?
[17:09] <tsimonq2> to rolling and edge?
[17:09] <ogra_> you can get a rolling release by using ubuntu-device-flash and using the rolling (xenial) release to build your image
[17:10] <dholbach> tsimonq2: ^ what ogra_ said
[17:10] <ogra_> but that will stop to roll soon due to the above switch :)
[17:10] <sergiusens> elopio, oh bummer
[17:10] <elopio> sergiusens: what? what???
[17:10] <sergiusens> elopio, mccabe
[17:10] <ogra_> (i.e. you will have to switch to the all-snaps setup by re-flashing your device)
[17:10] <dholbach> things will stabilise very soon and we'll recommend to use 16.04
[17:10] <ogra_> yeah
[17:10] <tsimonq2> ogra_: how does ubuntu-device-flash work_ is there a man page I can read?
[17:11] <ogra_> nope
[17:11] <ogra_> but it has multiple help options
[17:11] <elopio> sergiusens: ahh, you worried me for a moment :)
[17:11] <sergiusens> ogra_, u-d-f does have a man page, outdated, but there
[17:11] <ogra_> "ubuntu-device-flash --help" for the basicv app options ... "ubuntu-device-flash core --help" for image build related stuff
[17:12] <sergiusens> elopio, so on the tricky side; we might have to wing it for now with th examples
[17:12] <ogra_> ok, i'm wrong then :)
[17:12] <dholbach> all right, tsimonq2 - I leave you in good hands - I'm going to call it a day now - see you! :)
[17:12] <tsimonq2> bye dholbach
[17:12] <elopio> sergiusens: I'm not sure what does "wing it" means.
[17:12] <sergiusens> elopio, not everything will work until the snappy folk iron out all the bugs; there are workarounds but the examples should eventually work as is
[17:13] <sergiusens> elopio, I don't want to gross up the yaml just to workaround the ones that have no `uses`
[17:13] <elopio> sergiusens: yeah, bad week for releases.
[17:13] <elopio> sergiusens: here's an idea, let's release next monday :)
[17:14] <sergiusens> elopio, https://github.com/ubuntu-core/snappy/pull/416
[17:15] <sergiusens> elopio, well we need a tool for people to start finding bugs; and the all snaps images are already out
[17:15] <sergiusens> elopio, the closer we get to feature freeze the harder this will be (for snapcraft at least)
[17:16] <kyrofa> elopio, sergiusens I don't know what you guys are talking about. 1.0.1 works great
[17:16] <elopio> sergiusens: I'm just thinking that the releases notes you'll have to send explaining how to get all the pieces to get this working are way too complex.
[17:16] <tsimonq2> ogra_: okay, sorry, keyboard weirdness, so should I use the 16.04 image?
[17:16] <elopio> but if you think the release will be useful, let's do it.
[17:17] <ogra_> tsimonq2, depends what you are after
[17:17] <tsimonq2> ogra_: I want the latest
[17:17] <ogra_> sperfcifically if you plan to create snaps
[17:17] <ogra_> -rf
[17:18] <ogra_> it works different for the different releases
[17:18] <noizer> mvo_ is the update fixed because he reboots automatically again :s
[17:19] <ogra_> tsimonq2, if you can live with having to re-flash your device at some point, i'd go for mvo's images (you can also help to test the new setup) ... else stay with 15.04
[17:19] <ogra_> for xenial/rolling you will have to re-flash at some point, no matter which setup you use
[17:19] <tsimonq2> ogra_: I am just looking to have it in a KVM instance
[17:19] <ogra_> sicne we will make incompatible changes to the image design
[17:20] <ogra_> then grab the amd64 image from http://people.canonical.com/~mvo/all-snaps/
[17:20] <tsimonq2> alright cool
[17:20] <tsimonq2> downloading now
[17:21] <kyrofa> beuno, I have a question regrading the multi-arch uploads if you're around
[17:21] <tsimonq2> ogra_: for regular Ubuntu and flavors we have test cases, do you have manual test cases I can complete?
[17:23] <ogra_> tsimonq2, i dont think there are nay manual ones, elopio might be able to point you to them if they exist
[17:23] <ogra_> (but i thinnk snappy is all automated currently)
[17:24] <elopio> tsimonq2: just a few that we haven't been able to automate. https://github.com/ubuntu-core/snappy/blob/master/integration-tests/manual-tests.md
[17:24] <elopio> ogra_: I had to deautomate the image resize ones :'(
[17:25] <ogra_> elopio, i need to change all that code anyway since it breaks the dragonboard images
[17:26] <tsimonq2> ogra_: Okay, I have the Snappy image booted, what now?
[17:26] <elopio> ogra_: ok, please keep me posted of your plans there.
[17:26] <tsimonq2> and ssh'ed into
[17:26] <ogra_> elopio, well, i'm largely planninf to rip out parted completely
[17:26] <sergiusens> elopio, they will be complex either way
[17:26] <tsimonq2> running snappy update, looks like there is updates
[17:26] <sergiusens> elopio, in any case; shout works fine ;-)
[17:27] <ogra_> elopio, and switch to sgdisk for better GPT support
[17:27] <sergiusens> elopio, the other snaps using declared skills do as well
[17:27] <ogra_> tsimonq2, dunno, whatever you want to do with it ... buuld snaps ... install existing snaps etc
[17:27] <sergiusens> elopio, I think it will be
[17:28] <tsimonq2> ogra_: aaand I have an error: http://pastebin.ubuntu.com/14858708/
[17:29] <elopio> ogra_: dumb question. Why are we doing the resize during the boot and not after?
[17:30] <ogra_> elopio, because you cant easily rezize a partiton thats mounted :)
[17:31] <elopio> ogra_: not easily. But harder than do it during boot?
[17:31] <ogra_> a lot and error prone
[17:31]  * tsimonq2 just uses the 15.04 image for now
[17:31] <ogra_> especially with our bind-mount_farm living on top
[17:32] <elopio> ok, I was just wondering :)
[17:32] <ogra_> we could do it after boot but would to have remove all bind mounts and stuff
[17:32] <ogra_> and re-add them
[17:32] <ogra_> thats super hackish
[17:33] <ogra_> doing it cleanly before anything uses the partiton is a lot better
[17:34] <elopio> I agree that doing earlier is better.
[17:34] <elopio> I'm confused about where you draw the line on what's super hackish :D
[17:34] <ogra_> well, thats easy ... if something requires ten lines of code in one condition and 100 lines in another, just to reach the 10 line condition first ... thats what i call hackish ;)
[17:35] <elopio> but it works nicely, and moving away from parted sounds like a good thing anyway.
[17:35] <ogra_> well, parted is the preferred tool if it comes to MBRs ... but it lacks a lot when it comes to GPT sadly
[18:00] <ryanleesipes> Hello!
[18:01] <kyrofa> Hey there ryanleesipes, welcome :)
[18:05] <plars> ogra_: have you tried installing to emmc on the dragonboard? In particular, I'm wondering about the possibility of leveraging fastboot to write the needed partitions for snappy, and booting from that
[18:20] <sergiusens> elopio, anything really broken aside from things we don't control?
[18:21] <elopio> sergiusens: I'm still trying to get the autopkgtests running. It's reaaaly slow today, 75% creating the testbed.
[18:21] <elopio> sergiusens: the tests went well, I built all the snaps examples.
[18:22] <sergiusens> elopio, that is encouraging at least
[18:22] <elopio> sergiusens: I haven't run the binaries yet.
[18:26] <sergiusens> elopio, yeah, only the ones with migration-skill in them will work; the ones without won't ... yet
[18:27] <sergiusens> elopio, this is the dilema either we release or don't release, things are going to be broken as the previous non migration-skill stuff doesn't work anymore ;-)
[18:29] <elopio> sergiusens: well, release. Just explain that it's a safe point release to keep our cadence, but that people will have to wait to the next monday release to really use everything.
[18:34] <sergiusens> elopio, hah, that is the thing; we don't need to do anything; with a new ubuntu-core release everything should start working
[18:34] <zyga> sergiusens, elopio: we might have simple version if skills really working this week (at least in my tree), no real change for you guys but that made me think about one validation aspect, will we keep snapcraft aware of all the skill types and make it validate everything or is there some other plan?
[18:35] <zyga> like having a way to delegate to snappy somehow
[18:35] <zyga> "snappy check that skills make sense in snap.yaml"
[18:35] <sergiusens> zyga, ah, that crossed my mind; but it would be increasingly complicated to do that
[18:35] <elopio> sergiusens: also, keep an eye here: http://jenkins.elopio.net:8080/job/leo-snapcraft-test/11/console
[18:35] <elopio> it's finally running the examples install tests in scalingstack.
[18:36] <zyga> sergiusens: we don't have to solve it today but let's think about the approach we want to take
[18:36] <elopio> zyga, sergiusens: I'm ok with the snap failing to install if it's using an unexisting skill
[18:37] <sergiusens> zyga, in the end I think this goes closer to the review tools than snapcraft
[18:37] <elopio> zyga: what I expect is to have one snapcraft file for each valid skill, so we can run the tests to make sure that they keep working.
[18:37] <zyga> sergiusens: yes, that's true
[18:38] <sergiusens> zyga, we just want a consistent structure; don't really care about the contents (unless used by snapcraft)
[18:38] <sergiusens> just like we don't make sure every listed `stage-package` is valid until we need to use it
[18:40] <elopio> and even if the skill is valid, after installing we can't be sure that it's the correct one to use.
[18:40] <elopio> that's where we are missing the healthchecks.
[18:40] <sergiusens> elopio, the jenkins instance times out for me, I will not bother it to not reduce bandwith more
[18:40] <elopio> sergiusens: you can only access through the vpn.
[18:41] <sergiusens> elopio, ah, since it had your domain there I thought you were proying or something
[18:41]  * sergiusens might dissappear for a bit while connecting to the vpn
[18:46] <elopio> ahh, it's running on an old version.
[18:46] <elopio> I'll restart it with the hash of the latest.
[18:50] <sergiusens> elopio, seems the build failed
[18:51] <elopio> sergiusens: I launched the wrong revision.
[18:51] <elopio> watch #12 now :)
[18:51] <sergiusens> elopio, hah; but I need to disconnect :-P
[18:51] <elopio> well, now it doesn't have any output ofcourse.
[18:51] <sergiusens> irc is crappy on network switching
[18:52] <sergiusens> I need to go to the doctor for a bit so I'll check when I get back
[18:52] <elopio> sergiusens: I have an eye there, don't worry.
[18:52] <elopio> sergiusens: just one thing. I'm now with mvo's latest all snaps image, installing the downloader snap.
[18:52] <elopio> and when I run it, it says: aa_change_onexec failed with -1. errmsg: No such file or directory.
[18:53] <elopio> sergiusens: is that what we are expecting?
[18:53] <sergiusens> elopio, yes, that happens when the defaults are not taken into account
[18:53] <elopio> good.
[18:53] <elopio> I guess... :)
[18:54] <sergiusens> lol
[18:54] <sergiusens> elopio, network-client might become a mandatory key from what I heard, but we won't know until later (and I just heard about that now)
[18:55] <sergiusens> so not adding it here just to remove it later
[19:02] <sergiusens> elopio, change of plans, we are staying and going only tomorrow
[19:02] <kyrofa> sergiusens, I'm seeing SNAP_USER_DATA defined for services to be //snaps/<name>/<version>, where the systemd %h doesn't seem to be replaced
[19:03] <kyrofa> sergiusens, on the newest all-snaps. Can you verify?
[19:03] <sergiusens> kyrofa, let me check
[19:03] <sergiusens> hey jerryG
[19:04]  * sergiusens also says a late hi to ryanleesipes 
[19:05] <sergiusens> kyrofa, yeah, broken
[19:06] <kyrofa> sergiusens, argh. This ROS change is taking far too long right now, I think it's time to move on and wait until I can reliably test the resulting package
[19:06] <sergiusens> kyrofa, hmm, isn't that %h technically correct though?
[19:06] <elopio> sergiusens: lucky kid, got one extra day.
[19:06] <kyrofa> sergiusens, yeah that's been there forever. Something else is broken
[19:06] <sergiusens> kyrofa, it is replaced by systemd itself
[19:07] <kyrofa> sergiusens, right
[19:07] <kyrofa> sergiusens, but it only replaces with what it knows. And it looks like it's a /
[19:08] <sergiusens> kyrofa, oh, that means it replaced it for nothing
[19:08] <sergiusens> Chipaca, ideas ^
[19:09] <kyrofa> sergiusens, are you sure? Notice no leading slash: SNAP_USER_DATA=%h/snaps/ros-example.sideload/ILaUbGECDNAE
[19:10] <kyrofa> sergiusens, and when evaluated, SNAP_USER_DATA=//snaps/rosblahblah
[19:11] <sergiusens> kyrofa, that is indeed different
[19:19] <sergiusens> kyrofa, maybe this is a plain systemd bug? "This is the home directory of the user running the service manager instance. In case of the system manager this resolves to "/root"."
[19:20] <kyrofa> sergiusens, not outside the realm of possibility
[19:21] <sergiusens> pitti, if still around any idea my %h would expand to `/` instead of `/root`?
[19:21] <sergiusens> s/my/why/
[19:21] <kyrofa> sergiusens, the %h is valid (at least it should be). Is the root home dir setup correctly?
[19:21] <sergiusens> kyrofa, that might be it; but if the systemd man page says it will expand to /root maybe it is hardcoded somewhere :-P
[19:22] <kyrofa> sergiusens, oh, interesting point
[19:22] <kyrofa> sergiusens, yeah, root looks okay in my passwd
[19:31] <jdstrand> beuno, matiasb: not sure what you guys did, but it appears that my device is no longer reinstalling hello-world.canonical over and over again
[19:33] <matiasb> jdstrand, nothing? but if you get any more details or if it happens again, let us know
[19:34] <kyrofa> matiasb, hey, do you know anything about the new multi-arch upload support?
[19:36] <jdstrand> weird
[19:37] <matiasb> kyrofa, o/ yes, what would you like to know?
[19:38] <kyrofa> matiasb, I have version 1 of a given package released for armhf, and I tried uploading version 1 for amd64, but got a "this version is already uploaded" error. Do I need to have a different version per arch?
[19:39] <matiasb> kyrofa, yes, at the moment different version numbers are required for each upload, we are working to update that to allow same version numbers for different archs
[19:40] <kyrofa> matiasb, ah very good, thank you!
[19:40] <pitti> sergiusens: no, not off-hand
[19:41] <pitti> sergiusens: is that for a unit running as user who actually has / as home dir?
[19:41] <kyrofa> pitti, no, it's for root with /root as home dir
[19:41] <sergiusens> pitti, a system unit in /etc/systemd/system/.*.service
[19:43] <Chipaca> kyrofa: sergiusens: where are you seeing this?
[19:43] <kyrofa> Chipaca, newest all-snaps
[19:44] <Chipaca> noice
[19:45] <Chipaca> kyrofa: for apps, or for services, or both?
[19:45] <kyrofa> Chipaca, services (though I didn't try binaries)
[19:45] <Chipaca> is HOME set for services?
[19:53] <robert_ancell> zyga, in https://github.com/ubuntu-core/snappy/pull/409 you say "documented constants". Do you mean constants for the PolicyKit actions?
[20:04] <kyrofa> Chipaca, it at least used to be, but it was set for root. Remember those bugs a while back?
[20:09] <sergiusens> Chipaca, the systemd.unit manpage says it defaults to /root
[20:13] <awe__> hey guys, my snappy rolling image updated automatically today, and now my bluez snap seems to be broken
[20:14] <awe__> is there a known breakage?
[20:14] <awe__> basically all of the wrapper scripts can't seem to find the binaries anymore
[21:05] <dustino> Is there a Snappy eMMC flasher image available for the Beaglebone Black?
[21:10] <elopio> dustino: no, you'll have to flash it to the sd card.
[21:18] <sergiusens> elopio, how did testing go?
[21:20] <dustino> elopio: thanks. do you know if/when one will be made available?
[22:11] <enoch85> kyrofa: hey man
[22:11] <enoch85> kyrofa: long time no see...
[22:12] <enoch85> kyrofa: sorry I didn't had the time, just been busy with my own stuff recently
[22:12] <enoch85> kyrofa: but now all the VMs are done, finally
[22:13] <enoch85> kyrofa: os your plan to rebuild the owncloud snap when 16.04 are released?
[22:18] <jerryG_> sergiusens: hey sergiusens
[23:09] <elopio> sergiusens: sorry, I'm back. I died for a while.
[23:10] <elopio> I'm still not able to get the adt test bed working. Tried on xenial and wily, lxd and qemu. The four combinations give four diferent errors.
[23:10] <elopio> I
[23:12] <elopio> the rest looks as good as it gets. jenkins failed because of the missing locales, but only on the examples that seem to need utf8. I'm taking a look there to report a bug.
[23:13] <elopio> not new though, with that we are a lot better than before..