FAQ & Troubleshooting

• When building buildroot with the make buildroot target (For example buildroot 2016 as in 5.29) not all sources are anymore available or are renamed as deprecated and as such buildroot fails. How does one work around this? Would it be possible to automate a process to verify if all sources are still available?
  
  A solution is to change the following file:
  
  

  buildroot_overlay/buildroot-2016.02.config_full_rename_to_.config

  (ignore the statement “Automatically generated file; DO NOT EDIT.” and change the line with
  

  BR2_BACKUP_SITE="http://sources.buildroot.net"

  into
  

  BR2_BACKUP_SITE="https://build.elinc.de/buildroot"

  Obviously all source files should be available in that directory.

Ok, so I checked out ebee-controller-meta, I did git submodule init and git submodule update and am ready to start working on a new feature branch on the controller project. When I go into it and do git status I see something like this:

~ pwd
/home/user/Ebee/LadepunktPlus/ebee-controller-meta
~ cd controller_software/
~ git status
HEAD detached at 14cc06c75
nothing to commit, working tree clean

This is not what I usually see on a standalone checked-out copy of controller-software. My questions are:

• Why do I see this differently?

• Should I create a branch from here to work on my feature as normally with git checkout -b ?

• Will I break something when I push my feature branch to origin from here?

Answers:

Q: Why do I see this differently?

In this case, the line HEAD detached at 14cc06c75 indicates that's the last reference pushed to the ebee-controller-meta branch in which you are (in this case master because it was just checked out). Note that you could also do git checkout master from there, and you'd see this:

~ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

but `master` on the controller project may be still out of sync with the reference on the meta! You can see this if you cd .. to an upper level on the ebee-controller-meta and do a git status… then you'll see changes on the ref. that look like this:

~ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   controller_software (new commits)

no changes added to commit (use "git add" and/or "git commit -a")

If at that point, you do `git submodule update` you will go back to the HEAD at the detached state in the point where the last reference was pushed.

Now you can go back to ebee-controller-meta/controller_software and move on…

Q: Should I create a branch from here to work on my feature as normally with git checkout -b ?

Yes, that's perfectly safe. As soon as you create a branch you'll be switched to it as always and everything will look normal again.

Q: Will I break something when I push my feature branch to origin from here?

Not at all. Just do git push -u origin my_new_branch as usual and everything will be fine.

So I have my feature branch merged to master on the controller_software. Now I have to update the reference on the meta project.

Questions:

• How do I do that? (assume I'm on the command line on the ebee-controller-master's project top level and provide commands from there).

• Should the commit have a special format and/or message? (atm. the common practice is to just write “upref”, I think that's fine, do we keep that?

Answer:

For an ref update on controller_software I usually do:

$ cd ebee-controller-meta/
# reset all to clean state:
$ git reset --hard --recurse-submodules 
# update META to recent state:
$ make update
$ cd controller_software
$ git checkout master
$ git pull
$ cd ..
# test if it works:
$ make controller-full
$ make controller-simulator-full
$ make run-unit-tests
# check that no unwanted changes are there:
$ git status
# commit with a link to the issue:
$ git commit -a -m 'update controller_software ref for https://gitlab.com/ebee_smart/controller_software/-/issues/<issue_id>'

Q: Why do I get an undefined reference error during the linking stage?

Answer:

When you added a new source file to the project, the linker might throw an “undefined error” at you, which you may solve, if the source code contains a Makefile.am (For example 5.12.7 has this), by adding this file to it. If there is no Makefile.am, you might have a newer version, which does this automatically, by so called autotools. If needed, you are able to do the opposite, by exclude one or more files, by adding these to the EXCLUDE_SRC_PAT variable in the Makefile.base