How to update core bundles?

I am currently working on the bundle, however I am failing to deploy it into my test openHAB system.

openhab> bundle:list
START LEVEL 100 , List Threshold: 50
 ID │ State  │ Lvl │ Version            │ Name
177 │ Active │  80 │ │ openHAB Core :: Bundles :: REST Interface :: Core

openhab> bundle:update 177 file:///usr/share/openhab/

openhab> bundle:list
START LEVEL 100 , List Threshold: 50
 ID │ State     │ Lvl │ Version            │ Name
177 │ Installed │  80 │ │ openHAB Core :: Bundles :: REST Interface :: Core

When I not either start the bundle or re-start openHAB, I get:

org.osgi.framework.BundleException: Could not resolve module: [177]
  Unresolved requirement: Import-Package: org.openhab.core.addon; version="[4.1.0,5.0.0)"

But the missing bundle is there:

openhab> bundle:list org.openhab.core.addon
START LEVEL 100 , List Threshold: 50
 ID │ State  │ Lvl │ Version            │ Name
150 │ Active │  80 │ │ openHAB Core :: Bundles :: Add-on XML

/cc @J-N-K @wborn Any idea?

Try packages:export | grep org.openhab.core.addon to see if this package is exposed by anything. It looks to me that you miss a addon bundle itself, the model bundle might ship just DTO classes

The command does not work in the openHAB console:

gogo: CommandNotFoundException: Command not found: packages:export

The exception makes sense if you deploy a 4.1.0 bundle in a 4.0.0 system as it does not have 4.1.0 bundles. Try deploying it in a 4.1.0 snapshot runtime instead.

I’m on 4.1.0 (build Build #3561).

Did you also try to restart the runtime? Sometimes I have to do that to get updated bundles working.

Restarting the runtime doesn’t help either, the bundle does not start with the same error.

I had a look at the available package versions, and noticed that I had 4.1.0~20230724092152-1 installed, which I then noticed is a usual scheme for openHAB.

Checking the available snapshot packages, I decided to try 4.1.0~S3562-1 which works fine.

/cc @Benjy Seems like there was something going on with out Linux packages …

1 Like

Thanks @florian-h05,

4.1.0~20230724092152-1 can only happen if a Linux package build was triggered manually. It will adopt the name 4.1.0~S####-1 if it’s tied to a particular openHAB build. It’s likely that the first 4.1.0 snapshot was built at a strange time when everything else was changing to version 4.1.0. It is rather strange that this build succeeded.

S3562 was the first 4.1.0 build to be triggered by our CI processes and looks to be behaving correctly… did APT/DNF offer S3562 as an upgrade over 20230724092152?

No, dnf installed 2023… instead of S3562. Let’s wait what happens once CI pushed the next package release to the repos.

Thanks again, I’ve removed the package from Artifactory so that won’t be offered again.

I triggered a build manually because it failed because the build config needed to be reconfigured to download 4.1.0 instead of 4.0.0.

AFAIK the .deb package version is irrelevant to all the Java code. The bundle versions are based on the info in the manifests inside the JARs. So if it was some issue with a certain build, it would impact any packaging method (.zip, .deb, .rpm, Docker etc.).

1 Like

Thanks @wborn, yes the .deb packaging is irrelevant to Java code and also the included distro scripts. So as you say the original problem is likely to do with the distro build.

Removing the manual version was necessary as the version string appears to DNF and APT as later than automatic snapshots. I’ve made Change versioning format for manually built snapshots by BClark09 · Pull Request #221 · openhab/openhab-linuxpkg · GitHub so that it’s less of a problem in the future.

1 Like

My fault, for future generations - it should be package:exports :wink:

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.