Recommendations for modifying code

I have CoreELEC building and have been modifying code by altering the source files that I found under the build.CoreELEC-Amlogic-ng.arm-20 directory, deleting the appropriate build_target file under the .stamps folder and rebuilding using DEVICE=Amlogic-ng make.

As I am starting to make more changes, this has become very cumbersome, changes are not tracked as the build.CoreELEC-Amlogic-ng.arm-20 folder is excluded from git, etc…

I take it altering code that you find in build folder isn’t the right way to do it, but that seems to be the only place that has source files in the repo I cloned. I’m broadly familiar with git, but haven’t really worked on projects this large before.

I have found that the linux code (for example) exists as another repo. I assume I should clone that and make changes there. Is this the right way? And if so, what do you need to do to get these changes built into the original CoreELEC repo I have building images?

What process is recommended to change code / develop CoreELEC code when the actual code seems to exists in different repos than the one used to build images?

I am no expert but I have cloned and built Visual Pinball on my Linux desktop. I only cared about the standalone version which was in a build folder. Since that project is setup to build for multiple platforms as well as the standalone version I assumed that was why the structure was that way.

It may be the same with CE since its made for multiple chipsets.

I assume you are cloning from GitHub - CoreELEC/CoreELEC: A lightweight OS for KODI so if you want to submit change and have them tracked then submit a pull request…

What do you mean the sources are not there? In GitHub, there’s only the one master branch visible for CE20 and CE21, and those should contain all the common and different code parts. For example take a look at the path projects/Amlogic-ce/devices.

You’ll want to create patch files to apply if you don’t want to copy-paste the same changes every time. Of course they may also need to be adjusted at times.

Exactly what I said, the repo GitHub - CoreELEC/CoreELEC: A lightweight OS for KODI doesn’t seem to actually contain the “actual” code. Just look at the changes - to me, it looks like (essentially) all that is ever done in that repo is bump packages numbers.

For example, the file I am currently looking at is amcsc.c. It lives in an entirely separate repo, GitHub - CoreELEC/linux-amlogic. I assume that when I built CoreELEC this was downloaded onto my computer, but like I said, it only appears to exists in the untracked build folder - why I was looking for a better method

So is the workflow: develop in a clone of GitHub - CoreELEC/linux-amlogic → create patch files of the changes I’ve made → and then copy these patches files to projects/Amlogic-ce/devices/Amlogic-ng/patches/linux in the different repo GitHub - CoreELEC/CoreELEC: A lightweight OS for KODI → rebuild?

fwiw - my experience is the same:

Checkout the version you want of CoreELEC/CoreELEC repo, the packages in that refer to the other repo as you mention - with the commit id / version to pull down on build.

Checkout the repo you want to make a change in e.g. CoreELEC/linux-amlogic for the corresponding commit id and make your changes, then place a git diff back in the appropriate patches folder in CoreELEC/CoreELEC - fingers crossed there is not another diff already there and clashing!

Then run the build.

@doppingkoala, I see you what you mean. CE is a FORK of LibreElec so I guess it only contains the special Amlogic modules and packaging to be CE?

I don’t think that is it. Having a look at the LibreELEC repo it also appears to be set up identically - no actual code and links to the actual code through packages from other repos. Doesn’t appear to be a CoreELEC specific approach to me now.

Now I guess the better question to ask would have been: For those unfamiliar with large “build systems”, dealing with packages, and having code split across different repos than the one it is built in, what workflow is recommended to effectively make and then build changes?

I have now got the suggested setup of cloning the other linux repo and creating patch files that I then place in the main CoreELEC/CoreELEC repo. While it is definitely a better approach than what I was doing before, it still feels somewhat cumbersome to me.

I think some degree of unwieldiness is unavoidable. I would also suggest trying to break things down into smaller components and trying to get them merged sooner. For example, if you fixed the erroneous conversion to BT.601, then you can submit a PR for that one. It’s also a good way to get feedback and avoid having to redo too much.

I am increasingly having problems updating to new tests builds - in that the updates just doesn’t seem to apply.

I copy the .tar to the update folder over samba, run sync via ssh, and confirm the .tar is in the update folder over ssh. After I reboot though, more often than not, CoreELEC just reboots like normal without applying the update.

Anyone have any suggestions?

Check the files /storage/init*.

There is only one /storage/init-previous.log. From the version numbers it appears to show the log for the last successful update

Then update was ok.

Try to remove that file and update again.

I get a new file /storage/init.log, with the following error log


Please do not reboot or turn off your CoreELEC device!

Found new .tar archive
Extracting contents of archive... FAILED
Failed to extract contents of archive file!
tar result: 'tar: invalid tar magic'

The archive is corrupt/invalid!

Cleaning up... done
Normal startup in 30s... NOW

I’ve now found that copying the same tar file, waiting 10-15 minutes, and rebooting updates the install fine.

Using sync command should save the file immediately.

Haven’t thoroughly tested it yet, but running sync on the tar file itself seems to be working immediately.

For anyone that has the same problem, the command was

sync /storage/.update/CoreELEC-Amlogic-ng.arm-20.5-Nexus_devel_20240503133610.tar

Obviously change the filename to suit the name of tar file.

I think you have some different issues. Maybe bad boot medium? Run this

dmesg | paste

Just sync is enough and commonly recommend on Linux platform. It’s like the “safe disconnect” a USB device at Windows.

After a successful update using sync on the tar file:

It’s now worked half a dozen times without issues

This doesn’t sound right:

[    5.846118@0]- systemd[1]: Configuration file /usr/lib/systemd/system/ is marked executable. Please remove executable permission bits. Proceeding anyway.

It is warning but should not be there. I don’t know why you got this with your image.

I’m building in WSL and was having issues with accessing files and permissions. Not having much idea about what I am doing, I ran chmod -R 777 on the entire folder the code and build is in - seemed to fix the problem I was having at the time. I would guess that may be the cause of the executable permissions