[Milhouse]

If you're getting a problem with flock then why not mention it rather than try and fix it yourself, which is likely to make the problem worse?

You definitely don't need sudo to run these scripts, just run them as your normal user. If you run them as sudo then your user will be root, you'll be using /root/.ssh for private/public keys and all files created by the scripts will be owned by root. Basically, you'll cause a lot of problems running with sudo, and at no point were you instructed to run the scripts with sudo.

I don't know what files are in your "projects" folder now. Assuming it's a standard Ubuntu system then try running the following to clean up the mess:

Code:

sudo chown -R 1001:1001 ~/projects

(the above assumes your user has uid:gid (user:group) 1001:1001).

The scripts also create temporary files which may be owned by root - you'll need to clean that up to:

Code:

sudo rm -fr /tmp/.oebuild.tmp

If that doesn't work I don't know what else to tell you. It's difficult trying to get someone to follow instructions that they just make it up instead.

[madhits]

If you're getting a problem with flock then why not mention it rather than try and fix it yourself, which is likely to make the problem worse?

You definitely don't need sudo to run these scripts, just run them as your normal user. If you run them as sudo then your user will be root, you'll be using /root/.ssh for private/public keys and all files created by the scripts will be owned by root. Basically, you'll cause a lot of problems running with sudo, and at no point were you instructed to run the scripts with sudo.

I don't know what files are in your "projects" folder now. Assuming it's a standard Ubuntu system then try running the following to clean up the mess:

Code:

sudo chown -R 1001:1001 ~/projects

(the above assumes your user has uid:gid (user:group) 1001:1001).

The scripts also create temporary files which may be owned by root - you'll need to clean that up to:

Code:

sudo rm -fr /tmp/.oebuild.tmp

If that doesn't work I don't know what else to tell you. It's difficult trying to get someone to follow instructions that they just make it up instead.

Well I keep trying not to ask you, i know your time is valuable. Since I know your really trying to help me and I appreciate it so much. I have permission errors now So I am going to wipe out the directories with the errors and re-download or change ownership of them..

[Milhouse]

Well I keep trying not to ask you, i know your time is valuable.

Honestly, I'd much rather you followed the instructions as they have been given to you, and for you to give me the proper details when something doesn't work, rather than for you to repeatedly misread instructions then try and work things out for yourself (apparently under the impression it couldn't possibly be due to a mistake on your part) only to make the situation far, far worse because you don't even tell me the other problems you've caused by trying to fix things yourself.

If you'd asked when you made your first mistake we probably wouldn't still be here, 3-4 days later, trying to clear up the mess you probably caused by trying to fix your first mistake.

So yeah, not asking me out of politeness really isn't helping.

I have permission errors now So I am going to wipe out the directories with the errors and re-download or change ownership of them..

Starting from scratch and following the instructions you've been given to the letter really would be the best solution, in all honesty.

The only commands that needed sudo were those that included the command "sudo". Nothing else requires sudo.

Using only your normal user account create your ~/.git.conf file (with your GIT_USERNAME and GIT_PASSWORD), your ssh public/private keys (both as previously explained), and then run the following commands:

Code:

mkdir ~/projects
cd ~/projects
git clone git://github.com/LibreELEC/LibreELEC.tv.git
wget -q www.nmacleod.com/public/oebuild/oebuild.tar.gz -O - | tar xzf -
mv build.conf.sample build.conf

That's 5 (FIVE) separate commands - one command per line. Copy & paste exactly as they are written above.

Now, to build Generic:

Code:

PROFILE=x86 ./autobuild.sh

then sit back and wait (hopefully) - typically several hours.

If you do get any errors or problems, do ABSOLUTELY NOTHING other than to paste the entire contents of your console (in PuTTY, right click the title bar and choose "Copy All to Clipboard"), paste it into pastebin.com (be careful not to include your github password in any pasted text) and then post the link - if you're not sure send me a PM with the link and I'll continue the discussion in this public thread pasting whatever information helps move the discussion forward.

[madhits]

yep its going, finally at the compile stage. This is the long one I'm sure. I know the git login was an issue at first and not sure i ever needed the ssh publickey or not really. Do you know if that's required?

I want to compile this with all the in between steps to using your scripts and hopefully make it super easy for someone who wants to do it for the first time or incase I forget and need to do this again.

[Milhouse]

I know the git login was an issue at first and not sure i ever needed the ssh publickey or not really. Do you know if that's required?

The git login is something that became a requirement over time as the number of Github API requests exceeded the non-authenticated rate limit, so I'll add that to the post. The ssh public key is also something that may be required by certain repositories added since I wrote those instructions. Why the key is required, I've no idea (edit: possibly because the inputstream.* repositories use the "[email protected]" url when cloning - I may update the scripts to try and work around that annoyance).

[Milhouse]

@madhits: I've eliminated the need for the ssh public/private key by rewriting the urls of those repositories using the "[email protected]" notation. Just update the scripts:

Code:

cd ~/projects
wget -q www.nmacleod.com/public/oebuild/oebuild.tar.gz -O - | tar xzf -

and don't forget to re-apply the changes you need (ie. add support for your legacy hardware):

Code:

echo "=master forwardPatch http://nmacleod.com/public/oebuild/patches/00_legacy_hardware.txt" >> ./lepull.dat

Then build.

[madhits]

@madhits: I've eliminated the need for the ssh public/private key by rewriting the urls of those repositories using the "[email protected]" notation. Just update the scripts:

Code:

cd ~/projects
wget -q www.nmacleod.com/public/oebuild/oebuild.tar.gz -O - | tar xzf -

and don't forget to re-apply the changes you need (ie. add support for your legacy hardware):

Code:

echo "=master forwardPatch http://nmacleod.com/public/oebuild/patches/00_legacy_hardware.txt" >> ./lepull.dat

Then build.

Well I had the ssh key installed so that went on without a hitch. I also included the legacy hardware patch also. Its sitting at the compile stage? How long does this take? Its at 0.00% and has not moved? Is that bad? Opened the log.job1 and it says I need tools g++,, Ill install and start it again I guess.

UPDATE: Started it again and now its showing progress and time count down. Must have needed g++ for that.

[Milhouse]

Its sitting at the compile stage? How long does this take?

Depends on your hardware. For me, with an FX-8350 (8 cores, 4GHz) and 8GB RAM, 24GB swap and an SSD, it takes 3 hours to build Generic (PROFILE=x86). If you have better hardware, it will be quicker. It's not unheard of for people with lower end hardware to take all day, or even longer. You probably need at least 2GB of RAM and 2GB swap.

Its at 0.00% and has not moved? Is that bad?

First of all it needs to build what's called the toolchain - these are all the tools (utilities, compilers etc.) that need to be built before the operating system itself can be built using the tools from the toolchain.

Building the toolchain is about 50% of the entire build process, and it will be stuck on 0.00% for quite a while.

Opened the log.job1 and it says I need tools g++,, Ill install and start it again I guess.

Yes, log.job1 is the detailed build log so worth checking if it looks like the build has stalled (spinner no longer moving).

I guess you've hit the dependency check. I've added g++, xsltproc, xfonts-utils to the list in my first post. If you run "sudo apt-get add <list of missing packages>" then the missing packages will be installed and you should be good to restart the build (just re-run "PROFILE=x86 ./autobuild.sh").

[madhits]

Its sitting at the compile stage? How long does this take?

Depends on your hardware. For me, with an FX-8350 (8 cores, 4GHz) and 8GB RAM, 24GB swap and an SSD, it takes 3 hours to build Generic (PROFILE=x86). If you have better hardware, it will be quicker. It's not unheard of for people with lower end hardware to take all day, or even longer. You probably need at least 2GB of RAM and 2GB swap.

Its at 0.00% and has not moved? Is that bad?

First of all it needs to build what's called the toolchain - these are all the tools (utilities, compilers etc.) that need to be built before the operating system itself can be built using the tools from the toolchain.

Building the toolchain is about 50% of the entire build process, and it will be stuck on 0.00% for quite a while.

Opened the log.job1 and it says I need tools g++,, Ill install and start it again I guess.

Yes, log.job1 is the detailed build log so worth checking if it looks like the build has stalled (spinner no longer moving).

I guess you've hit the dependency check. I've added g++, xsltproc, xfonts-utils to the list in my first post. If you run "sudo apt-get add <list of missing packages>" then the missing packages will be installed and you should be good to restart the build (just re-run "PROFILE=x86 ./autobuild.sh").

Its going to take all day. My system is old.

[madhits]

When the build finishes, which might take several hours - it takes 3 hours on a 8-core 4GHz FX-8350 with 8GB RAM/24GB swap and SSD - you'll find the new tar file in the LibreELEC.tv/target/x86 directory.

Copy the tar file to the "/storage/.update" folder on your x86 device and reboot to upgrade.

If you want an img.gz file to be created at the end of your build (in addition to a tar file) use the following command to start the build:

Code:

PROFILE=x86 BUILD_MKIMAGE=yes ./autobuild.sh

You can use the .img.gz like any other LibreELEC disk image to create a clean installation, although it really shouldn't be necessary unless you need your SIL680 driver to boot the system.

It seems like I lost my ssh connection to the machine over night. I went to the LibreELEC.tv directory and there is no target folder. So does that mean its still going? Assuming yes. There is a script in here called create_tar.sh. Is that script called at the end of the build process?

I think the build might have stopped. There are no new lines being added to the log.job1 file. I might have to start all over again :-(

THANKS

[Milhouse]

It seems like I lost my ssh connection to the machine over night. I went to the LibreELEC.tv directory and there is no target folder. So does that mean its still going? Assuming yes.

Probably not, once the ssh connection terminated it's likely the build processes would die.

Check if anything is still being written to log.job1.

If nothing is being written (and hasn't been written for a while) then restart the build with "PROFILE=x86 ./autobuild.sh"

There is a script in here called create_tar.sh. Is that script called at the end of the build process?

Nothing to do with the build whatsoever. DO NOT RUN IT.

I think the build might have stopped. There are no new lines being added to the log.job1 file. I might have to start all over again :-(

Yep.

[popcornmix]

It seems like I lost my ssh connection to the machine over night. I went to the LibreELEC.tv directory and there is no target folder. So does that mean its still going? Assuming yes. There is a script in here called create_tar.sh. Is that script called at the end of the build process?

If ssh connection closes, the jobs launched from it will be closed.
Installing gnu screen is recommended which allows ssh connections to be dropped and re-attached without the jobs being quit.

[madhits]

Just for an update. I started all over using a better system that I can work directly with and has 8gb ram and a core i3 cpu. Its not super fast but better to cut down on the super long build process. We shall see.

For the record you have to create the shh key or it will not work. I got errors again during download but they were different repos this time. So I assume it comes up when you hit some sort of unauthenticated limit.

I still error's on pvr stalker repo this time, so I opened a new window and ran the make command for it. Now that its in the sources directory will the build use it?

[Milhouse]

For the record you have to create the shh key or it will not work. I got errors again during download but they were different repos this time. So I assume it comes up when you hit some sort of unauthenticated limit.

I still error's on pvr stalker repo this time, so I opened a new window and ran the make command for it.

For the record, no you don't (not any more). The pvr.stalker repo uses https so you definitely don't require an ssh key (you did yesterday for the inputstream.* repositories as they used git@github, but not now for any repo when using the latest scripts).

Do you have a log of this latest error?

Now that its in the sources directory will the build use it?

Probably, depends on the actual error though. What did I say about trying to fix errors...?

[Milhouse]

I just ran the scripts on a fresh project directory, no .git.conf, no .ssh, and didn't experience any errors or problems - every repository and every patch downloaded as it should, and within a few minutes I've started building LibreELEC for x86_64.

Without details of the errors you saw I have no idea what the problem is with pvr.stalker, this repository is using https so does not require an ssh key (besides which, the latest scripts avoid using those urls that require keys so you should never need a public key while cloning).

It's unlikely to be an Github authentication rate limit issue as building x86 makes very few Github API requests (unlike building pi1/pi2).