xbianonpi / xbian

XBMC on Raspberry Pi, Bleeding Edge
https://xbian.org
GNU General Public License v3.0
294 stars 44 forks source link

new build tools won't run #561

Closed bairdy closed 9 years ago

bairdy commented 10 years ago

when trying the new autobuild tools the first command

cd xbian; ./run.me prepare

wont run the buildroot script to prepare the build environment i just get the error in clean installs of debian 7.5 or ubuntu 14.04

debian build

and running the command on its own to initialize a buildroot doesn't work. i have tried changing the permissions and also making executable but it doesn't make any difference

debian build1

mk01 commented 10 years ago

@bairdy

is the "xbian" directory git clone of xbianonpi/xbian ? if so, in "xbian" do a

git pull
sudo -s
./run.me prepare

then again "./run.me prepare", logout, login then

sudo -s
cd xbian
cd xbian-prep-root
$xbiangit --arch rpi --action build
bairdy commented 10 years ago

@mk01

yeah its a direct git clone of xbianonpi/xbian.

I have ran a git pull and still getting the same message when i run ./run.me prepare

but if i comment out

if [ "$1" = prepare ]; then
    (
#    cd $XBIANROOT
    sh ./create.buildroot prepare
    )
    if [ $? -eq 0 ]; then

in run.me and then edit create.buildroot to exact location for common.functions


if [ -e /home/build/xbian/common.functions ]; then
    . /home/build/xbian/common.functions
else
    echo "Wrong setup. Open folder containing xbianonpi/xbian clone and rerun \"./run.me prepare\""
    exit 500
fi

do_wipe()
{
    dir="$1"
    do_run rm -fr "$dir/working"

it gives me the message

Successfully initialised. Please logout and login again.

but after logging out then back in and then running

$xbiangit --arch rpi --action build

i get

--arch: command not found

and the /etc/profile.d/xbiangit.sh looks to set up fine as follows

export xbiangit=/home/build/xbian/run.me
export XBIANROOT=/home/build/xbian

export PATH=/usr/lib/ccache:$PATH
export MAKEFLAGS="-j$(grep -c processor /proc/cpuinfo )"
mk01 commented 10 years ago

@bairdy

sorry for late answer .... at first.

can you also check that the xbiangit.sh is run upon login ? you can check the actual environment with

env

and you should see all that variables set. so

env | grep 'xbiangit\|XBIANROOT\|MAKEFLAGS'

should list you all three variables. if not, it is not started on login. what distro is that and what shell is your login name using ? sh/bash/ash/dash ... ?

mk01 commented 10 years ago

I just see you wrote that. I use Wheezy 7.5 also. the /etc/profile.d/ directory is loaded from /etc/profile on line 33. if you do that after login what you get?

. /etc/profile.d/xbiangit.sh
echo $XBIANROOT
mk01 commented 10 years ago

@bairdy

also please do a git pull now and then in xbian directory as there are fixes and updates to the scripts each day. (but not that it would matter for this particular problem)

bairdy commented 10 years ago

@mk01

I had trashed that install of debian :( but reset it up with a new install of 7.6.

I have now managed to get the tools working as far as building the buildroot so far as i aint had a time to test any further as of yet but I had a couple of issues to get that far with a virgin system in that get it working i did the following

./run.me prepare

I got

Something went wrong

so Installed schroot and debootstrap then tried again but still had no luck so again i uncommented line 26 in run.me

if [ "$1" = prepare ]; then
    (
#    cd $XBIANROOT
    sh ./create.buildroot prepare
    )
    if [ $? -eq 0

and in create.buildroot i had to change lines 22 & 23 to look at the exact location of common.funtions like so

if [ -e /home/build/xbian/common.functions ]; then
    . /home/build/xbian/common.functions
else

and then ./run.me prepare ran successfully, I then logged out and back in again and ran

cd .xbian-prep-root; 
$xbiangit --arch armhfwheezy --action build

and it downloaded the buildroot system untill it tried copying qemu-user-static which was missing and the script crashed out and running

$xbiangit --arch armhfwheezy --action build

is presuming its set up properly and wont go any further

maybe we should check missing depends before setting up?

bairdy commented 10 years ago

but after trashing the build-root folder and installing qemu-user-static it allows to re-download the buildroot and sets it up fine :)

will check the building over the next couple of days

mk01 commented 10 years ago

definitely could happen that I missed some packages in the prepare phase (or the problem of yours was that it didn't finish successfully). back to missed stuff - could be as at the time of writing the scripts I already had running system and I didn't test it from scratch after... so if you can pinpoint the issues, let me know. I will review the initial stuff myself as well.

mk01 commented 10 years ago

@bairdy

all you said was correct and should be fixed. so the first two cases. the packages which are installed onto your native host are in ./xbian-prep-root/build/config in config_deb_base variable. currently there is qemu-user-static in the list.

but to help you can open create.buildroot script, go to line 67 (after you pull the fixed one). function do_prep() starts there. just put "set -x" somewhere at the beginning of the function. this will output to stdout each command which is being run from that moment. so instead of variables in the code you will see how it was all interpreted and what was tried to run.

thanks again!

for the building - maybe this will be the part you will not have such troubles anymore as it is now daily used for those packages and quite lot was fixed there anyway

xbian-package-cec:
xbian-package-kernel:
xbian-package-shairplay:
xbian-package-tvheadend:
xbian-package-xbianhome:
xbian-package-xbmc:

I suppose any other package will be only less complicated to handle - there is no howto currently about the structure of build configs and how to adapt them for other packages (or completely new packages) - we have to do this. when you come there and you will be interested just always go straight for XXX/build/config file and read the few lines. then maybe also check for the XXXX/hook.d directory which allows to inject the build process with some specifics of particular package. for instance today I created setup for 3.12.y RPI kernel in 3 minutes (by reusing what's there).

just maybe one note to that, if you plan to edit sources (or even post patches) always remember that "--action build" will start with "git reset --hard + clean" and "git pull" after (to update sources from upstream) what means you would loose your code. in that case currently you have to run three operations "make, install, deb" what will just reconfigure & recompile sources, install them to tmp dir and build a deb. it won't touch the files in any other way.

other way is to create .patch file right after you edit sources to save your changes. then you can run just "$xbiangit --arch rpi" to reset & rebuild. patch you just copy into XXX/patches dir - only files with .patch extension are used during "patch" run (what also means if you want to disable any of the patches just temporarily feel free to rename it to anything else). good luck!

mk01 commented 10 years ago

last thing, for the packages repositories do it's fetch - merge (pull) now and then. or do it definitely in case the build process won't be successful. it is more than likely that it was fixed in-between and pushed to git by us.

bairdy commented 10 years ago

its working better now and have been able to build xbmc but have had to install everything in ./xbian-prep-root/build/config manually as it was complaining that they where not there specifically swig, i have now tried to compile the kernel just to test and that is now complaining

/bin/sh: 1: arm-linux-gnueabi-gcc: not found
mk01 commented 10 years ago

@bairdy

so swig was missing when xbmc run the configure step ? there are two components xbmc is using for generating python interfaces code (it is autogenerated). java, swig. problem is that java as multithreaded app is causing qemu to crash. thats why we run this step out of standard compile run (but still automatically for you) in native environment (it is not architecture dependent). so swig + java should be available in your host machine, then with a patch we remove java from configure checks for xbmc. swig is still checked - so should be installed in the buildroot and native machine as well but it is just few kB as package. will recheck the "prepare" code and buildroot packages if I missed swig there, you check please if you have it installed in your debian and buildroot as well. btw: you can enter the buildroot 'installation' any time with (and check for presence of swig for instance):

su
schroot -c armhfwheezy -p
dpkg-query -W swig

if you get "swig XXX" where XXX is any version number, it is installed. if you get empty output or just "swig" install it still from the shell with "apt-get install swig".

for kernel: it is only package we build with cross compilation. it is faster and there are no troubles with lib-dev dependencies as it has none. only requirement is having cross compiler installed. unfortunately Debian doesn't provide this from standard apt sources, you have to use their Embedian platform (Ubuntu provide this as standard component). Add

deb http://www.emdebian.org/debian/ stable main

to apt sources, apt-get update, and apt-cache search gnueabi. you should see gcc-4.3-arm-linux-gnueabi i the list, try to install it. then you should be fine with the kernel too. also install embedian apt keys to you Debian installation:

apt-get install emdebian-archive-keyring

this wasn't told in the first versions of wiki but I updated it later. you missed this point or it wasn't clear? feel free to check it again and tell us if it should/can be rewritten better. please.

report back!

mk01 commented 10 years ago

@bairdy

ok now got exactly what you meant. you had to install all from this config file as stated in "config_deb_base" variable manually. this should be installed automatically in the "prepare" step. but there was this bug before so it wasn't. for others it should be fine ...

thanks again.

bairdy commented 10 years ago

@mk01

dont know if you fixed the installing of the initial deps for the host system but i have just booted up a ubuntu 14.04 on a vm and pulled the latest from git to test the initial prep and when i have just ran ./run.me prepare its doesnt seem to be installing schroot qemu-user-static etc.

i know it maybe going back a little instead of linking to a file with the deps but i altered the run.me to

if [ "$1" = prepare ]; then
    (
    apt-get update && apt-get upgrade
    apt-get install -y libltdl-dev dpkg-dev git debootstrap autoconf automake swig doxygen libtool autopoint pkg-config lzop openjdk-7-jre-headless openjdk-6-jre-headless- openjdk-6-jre- qemu-user-static schroot kpartx parted btrfs-tools dosfstools u-boot-tools coreutils
    if [ -r ./create.buildroot ]; then
        sh ./create.buildroot prepare

and all seems to press and work fine instead of not installing anything

bairdy commented 10 years ago

also previous note about installing the cross compiler works a treat i missed it completely in the wiki but it took a little more work to install as the compiler is missing the dep libgmp3c2 which aint in the debian repo for wheezy but is there for sid and squeeze but installing the squeeze deb works fine :)

bairdy commented 10 years ago

@mk01

don't know what happening but when creating the debs they aint getting filled up with the package thats being created and after extracting them to see whats been packaged the only thing being inserted is the control folder and contents

mk01 commented 10 years ago

@bairdy

yes, wheezy and cross tools is a bit tricky, that's why I didn't bother at all with steps. ubuntu is ok and debian jessie also. all needed packages (as dependencies) are included correctly in std repo, although cross tools directly are still separe.

regarding the deb creation. you can run (once compiled) --action install and --action deb . install should deploy the binaries from working folder under the ./content structure and deb should then just call dpkg-deb. so you can with --debug trace what is happening with "install" step.

CurlyMoo commented 9 years ago

Run fine in a live environment.