[SOLVED] Failure on openhab core build on Nanoleaf bundle

Development IDE & Build
1

When I try to build the latest version on our nanoleaf bundle
I get the following issue, though I am aware we have changed or added a dependency

[WARNING] Feature resolution failed for [openhab-binding-nanoleaf/2.5.0.SNAPSHOT]
Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-nanoleaf; type=karaf.feature; version=2.5.0.SNAPSHOT; filter:="(&(osgi.identity=openhab-binding-nanoleaf)(type=karaf.feature)(version>=2.5.0.SNAPSHOT))" [caused by: Unable to resolve openhab-binding-nanoleaf/2.5.0.SNAPSHOT: missing requirement [openhab-binding-nanoleaf/2.5.0.SNAPSHOT] osgi.identity; osgi.identity=openhab-runtime-base; type=karaf.feature [caused by: Unable to resolve openhab-runtime-base/2.5.0.SNAPSHOT: missing requirement [openhab-runtime-base/2.5.0.SNAPSHOT] osgi.identity; osgi.identity=openhab-core-io-rest-sitemap; type=karaf.feature [caused by: Unable to resolve openhab-core-io-rest-sitemap/2.5.0.SNAPSHOT: missing requirement [openhab-core-io-rest-sitemap/2.5.0.SNAPSHOT] osgi.identity; osgi.identity=openhab-core-ui; type=karaf.feature [caused by: Unable to resolve openhab-core-ui/2.5.0.SNAPSHOT: missing requirement [openhab-core-ui/2.5.0.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.core.ui; type=osgi.bundle; version="[2.5.0.201911241710,2.5.0.201911241710]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.core.ui/2.5.0.201911241710: missing requirement [org.openhab.core.ui/2.5.0.201911241710] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.eclipse.jetty.proxy)(version>=9.3.0)(!(version>=10.0.0)))" [caused by: Unable to resolve org.eclipse.jetty.proxy/9.4.20.v20190813: missing requirement [org.eclipse.jetty.proxy/9.4.20.v20190813] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.eclipse.jetty.server)(version>=9.4.20)(!(version>=10.0.0)))"]]]]]]
Repositories: {
	file:/Users/stefanhohn/Development/checkout/openhab2-addons-branch/bundles/org.openhab.binding.nanoleaf/target/feature/feature.xml
	mvn:org.apache.karaf.features/framework/4.2.6/xml/features
	mvn:org.apache.karaf.features/standard/4.2.6/xml/features
	mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/2.5.0-SNAPSHOT/xml/features
	mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-tp/2.5.0-SNAPSHOT/xml/features
	mvn:org.ops4j.pax.web/pax-web-features/7.2.10/xml/features
}
Resources: {
...............

The full build output is attached.

Any help is greatly appreciated,
Stefan

oh-buildlogs.log (32.9 KB)

2

Did you try rebasing your branch on the latest master? It seems similar to:

1 Like
3

No, I hadn’t. Thanks, @wborn, for the hint and it finally did the trick.

As I am not a git guru myself I asked one of my trusted git genies who led me right path how to do the rebasing as I am working on a branch of a fork of the core-project.

So if anyone needs to do the same, here is what I had to do:

Git checkout master
Git remote add upstream https://github.com/openhab/openhab2-addons
Git pull upstream master
Git push origin master
Git checkout myBranchName
4

Just to clarify. These commands are for when you have NO changes made on master yet (and one should not make changes on master, but always on a branch). Otherwise you might end up with merge commit, cluttering your history. If you have changes on branch and want to rebase do on the branch:

git pull --rebase upstream master
git push --force-with-lease
5

“one should should not make changes on master”

I definitely agree.

Thanks for the advice, @hilbrand.

Just to be clear: I am not on the openhab repo directly but on our own fork (https://github.com/raepple/openhab2-addons/tree/canvas_touch_support) and the implementation itself is done on “myBranchName”. Only after the branch has been reviewed and QA-checked we intend it to merge to the openhab-core-repo (with all the review process that is involved).

(forgive me if a may use wrong wordings
git sometimes is really tough to understand with all its facets).

Again thanks for the advice. I will check your comment tomorrow with my Git guru :wink:

cheers
Stefan

6

Your free to do so. To be clear so you don’t get confused tomorrow. Depending on your develop preferences using --rebase is sometimes argued as not being proper git use. So if you’re git guru will argue that. Than know that if you use merge commits it will trigger every and each of the merge committed other contributors on git when you push it to your pr (as already happened on your own pr). Also we always squash all pull request because we don’t want to clutter the repo with a gazillion small commits that have no added value. And when we squash commits the merge commits are gone anyway. So merge commits don’t add anything here. If what I’m saying all sound like abra-ca-dabra then just let it read your git guru in case of objections to my suggestions :smile:

1 Like
7

Hi @hilbrand,

while having found who is obviously very intimate with the whole process :wink: can you explain something else to me?

What do these DCO checks mean? https://github.com/openhab/openhab2-addons/pull/6406/checks?check_run_id=323690483

Should I just do as explained there?

git rebase HEAD~39 --signoff

git push --force-with-lease origin canvas_touch_support

cheers
Stefan

8

No worries :wink: DCO stands for Developer Certificate of Origin. It checks if you have signed off on a commit. Which practical simply means if you have put the following line in the commit:

Signed-off-by: [your full name] <your e-mail>

It’s a statement that you state that you wrote that code and didn’t steal it.

The DCO check compares your commits with the e-mail address used to make the commits. In your case because you have a merge commit it complains about all the merged commits because are new for git as they have been merged. In such a case the suggested signoff should not be done.

In practice you should do the signoff on all your commits. But if you have trouble adding the sign off to earlier commits at least make sure the signoff is done in either at least one (new) commit or put the signoff in your pull request description.

1 Like
9

It was actually good that the dco was annoyed :slight_smile:

Together with my colleague I went into the whole merge situation and it showed that the branch had cluttered commits from the core-repo which noone of you would have merged without having been beaten to do so :wink: (similar to what you mentioned above with “Otherwise you might end up with merge commit, cluttering your history”).

Hence, we went back into history and applied the commits again the right way. Now the merge request looks much cleaner and the signoff is actually something that the commits and the mr deserve.

Thanks again @hilbrand for your guidance,
Stefan