=== Guest28469 is now known as devil_
=== console is now known as Guest2127
[17:09] <enoch85> hey kyrofa
[17:09] <enoch85> kyrofa: what about adding redis to the owncloud snap, would that be possible?
[17:44] <mvip> Hey guys. Is the RasPi 3 supported in the latest upstream images?
[17:44] <ogra_> not yet, no
[17:44] <mvip> ogra_ :(
[17:45] <ogra_> we rely heavily on u-boot ... thats not 100% done yet foor the pi3
[17:45] <mvip> ogra_ Should be relatively easy to do by pulling in the latest kernel, no?
[17:45] <mvip> ah ok
[17:45] <ogra_> it is on my TODO and we'll definitely have images once it is ready
[17:46] <mvip> well, it will be the same image, won't it?
[17:47] <ogra_> not sure yet ... it might need a different devicetree
[17:48] <ogra_> (which means differennt gadget snap in our current design)
[17:48] <ogra_> (which in turn means separate image)
[17:48] <mvip> hmm that would make our life a lot more painful as a vendor
[17:48] <mvip> as we'd need to maintain twice as many images
[17:49] <mvip> The upstream Raspbian images works fine with both RasPi3 and RasPi 2 fwiw
[17:49] <ogra_> well, after all i'd be shooting for a 64bit image in the long term
[17:50] <ogra_> which would mean separate image in any case
[17:50] <mvip> yeah, i guess that's a good point
[17:50] <ogra_> i'l try my best to get a single image for us ... but no promises :)
[17:51] <ogra_> (for 32bit)
[17:51] <mvip> Thanks, ogra_
[17:52] <mvip> It would be *very* cool to have a single image and then have the system auto-detect the 64 bit and pull down the 64 bit system as a system upgrade for the next a/b system. :)
[17:52] <mvip> not sure how viable that would be
[17:53] <ogra_> that would need quite some work
[17:53] <ogra_> (it is likely that you need a specific kernel for aarch64 ... we dont support switching kernels at all on installed images)
[17:54] <ogra_> i.e. it would only work if you hade two kernels in the same kernel package so it could be switched
[17:54] <mvip> IIRC, Raspbian uses the same kernel, but I'm not sure if it's fully 64 enabled yet
[17:54] <ogra_> it isnt
[17:54] <mvip> oh ok
[17:54] <ogra_> pi3 isnt 64bit capable yet ...
[17:56] <mvip> Wasn't that one of the major things in the Pi3?
[17:56] <ogra_> the SoC is 64bit ... bt afaik neither th bootlloader can initialize it in that mode yet nor are all kernel patches there
[17:56] <ogra_> and i'm rather doubtful that you can have a single kernel that does both
[17:57] <mvip> Interesting. Well, sounds like you're far more on top of this stuff than me. ;)
[17:57] <ogra_> just by trial and error ;)
[17:58] <mvip> Hahah
[17:58] <mvip> I just rebuilt my 4x RasPi cluster today with 3 RasPi 3s hoping to do some more QA/testing on Snappy. Didn't even think about that it wasn't supported.
[18:02] <popey> yeah, I have a pi3 on my desk which is waiting for snappy too :(
[18:21] <mvip> ogra_: yeah you're right. Looking at /proc/cpuinfo on Raspbian, I can confirm that the RasPi 3 is running as an ARMv7 and not ARMv8.
[19:05] <ali1234> ogra_: did you get the writable partition resize thing fixed?
[19:06] <ali1234> also someone got a 64 bit kernel to boot on the pi 3. but no communication between the videocore and arm
[19:16] <ogra_> ali1234, the GPT resizing is fixed since a while in the cdimage snaps
[19:17] <ali1234> cdimage.ubuntu.com?
[19:17] <ali1234> it only has 15.04?
[19:18] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[19:18] <ali1234> oh, you renamed it again?
[19:18] <ogra_> has kernel and os snaps (i'm working on auto-upload to the store atm)
[19:18] <ali1234> i can't keep up with all this
[19:18] <ogra_> renamd ?
[19:18]  * ogra_ didnt rename anything
[19:18] <ali1234> what is http://cdimage.ubuntu.com/ubuntu-snappy/
[19:19] <ogra_> officially released img files
[19:19] <ali1234> what is ubuntu-core then?
[19:19] <ogra_> the prodcut
[19:19] <ogra_> *product
[19:19] <ali1234> what is the difference?
[19:19] <ogra_> no difference
[19:19] <ogra_> different stages of the build
[19:20] <ogra_> in 15.04 we used to use a system-image server that pulled the tarballs from cdimage daily builds
[19:20] <ogra_> in 16.04 everything was switched to be snaps from the store (withou system-image server)
[19:20] <ogra_> so the interim step switched from tarball to snap
[19:20] <ali1234> has it ever occurred to you that all of this might be so complicated that hardly anyone will be able to understand it?
[19:20] <ali1234> and that this might hamper adoption?
[19:20] <ogra_> why would anyone need to understand it
[19:21] <ali1234> if i didn't need to understand the software i am running i would just use microcoft
[19:21] <ogra_> you will use ubuntu-device-flash to build an image (and later ubuntu-image)
[19:21] <ogra_> or you download a per-made image from http://cdimage.ubuntu.com/ubuntu-snappy/
[19:21] <ogra_> nothing has changed there
[19:21] <ogra_> (just the backend process has)
[19:21] <ali1234> let's say i have to do disaster recovery on a snappy drive
[19:22] <ali1234> where do i even look for "the files"?
[19:22] <ali1234> stuff like this
[19:22] <ali1234> that's just a hypothetical question
[19:22] <ogra_> in /writable
[19:22] <sergiusens> that should be the front facing website, not cdimage though
[19:22] <ogra_> nothing changed there
[19:22] <ogra_> sergiusens, well, the downloads will come from cdimage
[19:22] <ali1234>  /writable isnt mounted, the disk is dead
[19:22] <sergiusens> and if you want the 'os' you'd probably go to the vendor's website
[19:23] <ogra_> right
[19:23] <sergiusens> ogra_, only under dev; we also plan to put these under releases.ubuntu.com
[19:23] <ogra_> well ... s/"os"/"img"/
[19:23] <sergiusens> well infinity does
[19:23] <sergiusens> yeah img
[19:23] <ogra_> crazy canadians :)
[19:23] <ogra_> but yeah, might be under release.u.c
[19:23]  * sergiusens continues to fight python mocking
[19:24] <ogra_> in ayn case fro the enduser nothing really changed
[19:24] <ogra_> you either use u-d-f or dd a downloaded img file
[19:24] <ogra_> for the developer it is interesting to doownload the artefacts from cdimage to get the latest stuff atm though
[19:25] <ogra_> in case you want to try something thats not in the released img files yet
[19:25] <ogra_> which is why i pointed ali1234 there
[19:25] <ogra_> (like the fixed GT resizing)
[19:25] <ogra_> *GPT
[19:26] <ogra_> (though on the rpi that doesnt kick in anyway, since it uses an msdos table ... and that has not been broken to my knowledge)
[19:27] <ali1234> huh?
[19:28] <ogra_> huh ? huh ?
[19:28] <ogra_> :)
[19:28] <ali1234> so why doesn't /writable get resized on rpi?
[19:28] <ogra_> i havent heard of it not being resized ... nobody filed a bug
[19:28] <ali1234> two days ago you said you were fixing it
[19:29] <ogra_> (and i have personally not touched rpi in a while ... only tired the pi3 for a quick test)
[19:29] <ogra_> ali1234, hmm, not on the pi though ... the GPT resizing on dragonboards is known to be broken ... thats what i fixed ... (about aa week ago thouh)
[19:30] <ogra_> (well, GPT on dragonboard and amd64 in fact)
[19:30] <ogra_> ali1234, soory, that might have been some miscommunication ...
[19:31] <ali1234> it's broken on the pi
[19:31] <ali1234> with the all-snaps image
[19:31] <ogra_> i'll check that on monday then ... shouldnt be broken ... the code hasnt changed in ages
[19:31] <ali1234> http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz
[19:31] <ogra_> (it simply calls parted resizepart ... pretty dumb code)
[19:39] <ali1234> i'll test it again just to make sure
[19:41] <ali1234> then i'll try building my own image with ubuntu-device-flash and test that
[20:15] <ali1234> ogra_: confirmed that http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz does not resize /writable. i built an image with ubuntu-device-flash and make-rpi2-all-snap.sh and it does not boot at all.