ubuntu-phone team mailing list archive

[David Marceau <uticdmarceau2007@xxxxxxxx>]

On 03/16/2014 11:24 AM, Oliver Grawert wrote:
> hi, Am Sonntag, den 16.03.2014, 11:03 -0400 schrieb David Marceau:
>> On 03/16/2014 09:42 AM, David Marceau wrote:
>>> On 03/16/2014 08:09 AM, Oliver Grawert wrote:
> 
>> QUESTION:  What's the best block size for ubuntu phone bs=1MiB,
>> but that seems a bit high.
> the same that is used by the system-image-upgrader script in
> recovery mode ...
I must say it was well hidden because I looked under the phablet-flash
stuff and couldn't find it there.
https://github.com/ycheng/miscscripts/blob/master/utouch_dev/bringup/system-image-upgrader#L145
https://github.com/ycheng/miscscripts/blob/master/utouch_dev/bringup/system-image-upgrader#L272
These indicate 4096 Byte block size.
I understand that flashboot has some parameters to tell the sizes for
each partition.  Are we using flashboot anywhere in the process?
Could we plug it in there?

> 
>> 
>> I tried: /sbin/dumpe2fs / | grep 'Block size'
> 
>> But I got an error. dumpe2fs 1.42.9 (4-Feb-2014) /sbin/dumpe2fs:
>> Attempt to read block from filesystem resulted in short read
>> while trying to open /
> 
> you *have* to do it in recovery mode, else there are plenty of 
> mountpoints on top of the loop device that you can not easily
> unmount... (and without re-initializing the bigger loop device the
> kernel wont notice the bigger partition size)
> 
>>> sudo losetup -c /dev/loop0 sudo resize2fs /dev/loop0
> 
> none of these tools will be available in recovery mode (you would
> have to port them to bionic first to even make them available)
WARNING RANT: I feel like I don't have the control over this stuff.
Why is it there are still dependencies on bionic(ANDROID stuff)?

BACK TO REALITY:
Understood.  I won't continue on the resize loop0 path.

> 
> seriously (on your PC):
> 
> sudo apt-get install qemu-user-static sudo qemu-debootstrap --arch
> armhf trusty my-devel-chroot sudo chroot my-devel-chroot (do
> whatever you want to do wrt development)
> 
> is the better approach ...
> 
> ciao oli

Ok, thanks for the qemu tips and your patience, I'll try it this
afternoon and let you know.


I tried these non-qemu cross-compile tricks, but it didn't work
because of other complications:
git clone git://github.com/davecheney/golang-crosscompile.git
source golang-crosscompile/crosscompile.bash
go-crosscompile-build linux/arm

go-linux-arm get gopkg.in/v0/qml
can't build package gopkg.in/v0/qml because it contains C++ files
(all.cpp) but it's not using cgo nor SWIG

CXX=/var/lib/schroot/chroots/click-ubuntu-sdk-13.10-armhf/usr/bin/arm-linux-gnueabihf-g++
go-linux-arm get gopkg.in/v0/qml
can't build package gopkg.in/v0/qml because it contains C++ files
(all.cpp) but it's not using cgo nor SWIG

go-linux-arm build .
can't build package gopkg.in/v0/qml because it contains C++ files
(all.cpp) but it's not using cgo nor SWIG

GOARM=5 go-linux-arm build .
can't build package gopkg.in/v0/qml because it contains C++ files
(all.cpp) but it's not using cgo nor SWIG