Issue #148 Check openHAB version and perform an upgrade if different #149

rkoshak · 2017-12-28T21:54:36Z

Addresses Issue #148

I used the upgrade script as a template for what to copy over if the versions are different.

I was able to test the entrypoint_debian.sh but not the alpine. Unless grep, cut, tr, or tar do not exist in the alpine image it should not have any problems.

@BClark09, I'd appreciate a review to make sure I didn't miss anything.

Signed off by Richard Koshak rlkoshak@gmail.com

This change is

…e if the versions are different.

cniweb

You must run the update.sh

rkoshak · 2017-12-28T22:05:00Z

But that will download the newest OH, which is already in the image. But if we are fine with this redundant work that makes the changes much simpler but make the update depend upon

having internet access
installation of curl into the image
take a lot longer because it will redownload the whole OH distro

I assume you mean /openhab/runtime/bin/update. There is no update.sh file anywhere in the image.

cniweb · 2017-12-28T22:19:45Z

I mean this
https://github.com/openhab/openhab-docker/blob/master/update.sh
This file updates all relevant Dokerfiles and entipoints.sh files

rkoshak · 2017-12-28T22:22:41Z

Ok, now I think I understand. I'll have an update shortly...

rkoshak · 2017-12-28T22:39:58Z

Hmmm. I ran upgrade.sh and it is showing 42 changed files that I commited and 70 objects pushed but it only shows one commit and two files above. Did I mess something up along the way?

cniweb · 2017-12-28T22:43:24Z

No, I think, I is OK:
https://github.com/openhab/openhab-docker/pull/149/files

cniweb · 2017-12-28T22:43:55Z

Reviewed 42 of 42 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

cniweb · 2017-12-28T22:44:22Z

Review status: all files reviewed at latest revision, all discussions resolved, some commit checks pending.

Comments from Reviewable

wborn · 2017-12-28T23:00:10Z

Thanks for this PR @rkoshak!

Will it also perform an upgrade when updating the container to a newer version of the same SNAPSHOT version? People may already be using the 2.3.0-SNAPSHOT container now and want to upgrade and test it again just before 2.3.0 stable gets released.

@BClark09 how are such SNAPSHOT upgrades handled with the Debian/CentOS packages?

rkoshak · 2017-12-28T23:05:01Z

@wborn, it is based on the build-no field in version.properties. Since that number gets changed for every successful snapshot build it should work just fine to go from one snapshot version to another. that is why I chose that field to test against instead of the others fields in version.properties.

I'll note that theoretically, it should work for downgrading as well. It just checks to see if they are different, not whether the build number in the image is bigger than the one in your userdata.

wborn

Looks like some changes were not properly merged since this PR changes several lines back to a previous version.

wborn · 2017-12-28T23:15:41Z

entrypoint_debian.sh

-    echo "Please start the openHAB container with a pseudo-TTY using the -t option or 'tty: true' with docker compose"
-    exit 1
-fi
-


Why remove these lines that were added in #141?

I didn't intentionally remove any lines. Not sure what caused that. I'll look into it. My changes should only include additions and all in the same place,

wborn · 2017-12-28T23:17:54Z

entrypoint_debian.sh

@@ -52,14 +33,52 @@ case ${OPENHAB_VERSION} in
        cp -av "${APPDIR}/configurations.dist/." "${APPDIR}/configurations/"
      fi
    ;;
-  2.0.0|2.1.0|2.2.0|2.3.0-snapshot)
+  2.0.0|2.1.0|2.2.0-snapshot)


Looks like some changes were not properly merged since this changes the line back to a previous version.

:-| I literally cloned the repo a few hours ago. This is weird.

wborn · 2017-12-28T23:22:30Z

entrypoint_debian.sh

+    adduser openhab uucp2 &&\
+    adduser openhab dialout2 &&\
+    adduser openhab dialout3 &&\
+    adduser openhab uucp3 &&\


These lines were unchained in #142.

…and remade the edits. There were inconsistancies including changes from previous commits that were lost somehow.

rkoshak · 2017-12-28T23:49:21Z

I copied the two files from master on this repo rather than my fork and remade the additions and ran update.sh.

I think I know what happened. It was a stupid mistake on my part. @wborn, can you confirm that the anomalies you identified are now fixed?

wborn · 2017-12-29T00:22:39Z

I think I know what happened. It was a stupid mistake on my part. @wborn, can you confirm that the anomalies you identified are now fixed?

Yes the anomalies are gone! :-)

wborn · 2017-12-29T00:24:42Z

entrypoint_debian.sh

@@ -46,20 +46,57 @@ fi
 # Copy initial files to host volume
 case ${OPENHAB_VERSION} in
  1.8.3)
-      if [ -z "$(ls -A "${APPDIR}/configurations")" ]; then
+      if [ -z a"$(ls -A "${APPDIR}/configurations")" ]; then


Why add the 'a' option here? It's not added for the alpine image and it doesn't seem to solve warnings when the dir does not exist.

I'm not sure where those a's came from. I did not intentionally ad them. I only made the changes after the comment about the updating. I certainly did not make changes to the 1.8.3 section of the script.

wborn · 2017-12-29T00:24:52Z

entrypoint_debian.sh

        # Copy userdata dir for version 1.8.3
        echo "No configuration found... initializing."
        cp -av "${APPDIR}/configurations.dist/." "${APPDIR}/configurations/"
      fi
    ;;
  2.0.0|2.1.0|2.2.0|2.3.0-snapshot)
      # Initialize empty host volumes
-      if [ -z "$(ls -A "${APPDIR}/userdata")" ]; then
+      if [ -za"$(ls -A "${APPDIR}/userdata")" ]; then


Why add the 'a' option here? It's not added for the alpine image and it doesn't seem to solve warnings when the dir does not exist.

wborn · 2017-12-29T00:32:12Z

entrypoint_debian.sh

+
+        # Clear the cache and tmp
+        rm -rf ${APPDIR}/userdata/cache/*
+        rm -rf ${APPDIR}/userdata/tmp/*


With these commands hidden files will not be cleared from the directories which may result in issues some day.

openHAB now creates both directories. So you should be okay deleting these directories before openHAB is started.

Good to know. I'll change it to remove both the folders. However, this would mean that earlier version of OH that don't create those folders will not work, right? What version introduced that behavior?

To hedge the bets I've changed it to remove the folders and then recreate them so the older releases that do not recreate these folders will still work.

wborn · 2017-12-29T00:33:06Z

entrypoint_debian.sh

+      # Upgrade userdata if versions do not match
+      curVersion=$(< ${APPDIR}/userdata/etc/version.properties grep build-no | cut -d : -f 2 | tr -d '[:space]')
+      imgVersion=$(< ${APPDIR}/userdata.dist/etc/version.properties grep build-no | cut -d : -f 2 | tr -d '[:space]')
+      echo "Current \"${curVersion}\" Image \"${imgVersion}\"" # TODO remove


Either remove the echo or the TODO. ;-)

Done, see forthcoming update

wborn · 2017-12-29T00:33:37Z

entrypoint_debian.sh

+        cp ${APPDIR}/userdata.dist/etc/profile.cfg ${APPDIR}/userdata/etc/
+        cp ${APPDIR}/userdata.dist/etc/startup.properties ${APPDIR}/userdata/etc
+        cp ${APPDIR}/userdata.dist/etc/org.apache.karaf* ${APPDIR}/userdata/etc/
+        cp ${APPDIR}/userdata.dist/etc/org.ops4j.pax.url.mvn.cfg ${APPDIR}/userdata/etc/


I think it would be better to always use double quotes with files and directories.

Done, see forthcoming update

martinvw

@rkoshak Thanks for picking this up!

martinvw · 2017-12-29T07:14:16Z

1.8.3/amd64/alpine/entrypoint.sh

+        cp /tmp/${backupFile} ${APPDIR}/userdata/backup/
+        echo "You can find backup of userdata in ${APPDIR}/userdata/backup/${backupFile}"
+
+	# Copy over the updated files


Do we really want to also be managing this list here? Would it be better to call the backup and update scripts instead?

The update script will download the zip file each time. Would it be better to include the list of files in the distribution for a package manager (and the backup/restore scripts) to use?

Yes that would be great :-)

No, I don't really but it was a bigger job across two repos to pull them out into a list that can be used in both places. This list doesn't change that frequently so I figured we would kick the can down the road just a bit until we can figure out how to make the list usable for both.

My initial thoughts were perhaps that part of the script could be pulled out into a separate script that both entrypoint and all the installation and upgrade scripts call. Then not only would the list be reusable here but the actual behavior. That would guarantee that Docker would keep up with changes to the upgrade process in the future. I don't know if the apt/yum installers can support that though.

For me it would be okay as a first step.

Btw: I think that @BClark09 did not mean it as an improvement on this PR but the openHAB-generic side of things.

Yep that's right, I agree what you're doing is good for now but when I have the time (may be a few weeks), I'll add the proposed list to openhab-distro, and make subsequent PRs for openhab-docker and openhab-linuxpkg. :)

wborn · 2017-12-29T16:09:38Z

I was able to test the entrypoint_debian.sh but not the alpine. Unless grep, cut, tr, or tar do not exist in the alpine image it should not have any problems.

Upgrading using this PR works very well for me! 😄 👍 I've made a local build of the images and tested upgrading on amd64, with alpine/debian, 2.0.0, 2.1.0, 2.2.0, 2.3.0-snapshot.

Perhaps it is better to exclude /userdata/backup when making a new backup? Currently each backup contains a backup of the backups which is a waste of space.

rkoshak · 2018-01-03T15:04:43Z

Glad it works for you to. The upcoming update will also have the exclusion of the backups folder from the tar file. Thanks for testing this out.

- removed extraneous a options from the if statements - removed extraneous echo - use double quotes on all directroies and files - remove the whole cache and tmp folders then recreate them - exclude the backups folder from the tar

wborn

Thanks for the improvements @rkoshak! Please also have a look at my new comments.

wborn · 2018-01-03T20:25:05Z

entrypoint_alpine.sh

+
+        # Make a backup of userdata
+        backupFile=userdata-$(date +"%FT%H:%M:%S").tar
+        tar --exclude="${APPDIR}/userdata/backup" cf "/tmp/${backupFile}" "${APPDIR}/userdata"


On Alpine TAR creation now fails with:

openhab-upgrade | + tar --exclude=/openhab/userdata/backup cf /tmp/userdata-2018-01-03T21:24:11.tar /openhab/userdata openhab-upgrade | BusyBox v1.27.2 (2017-12-12 10:41:50 GMT) multi-call binary. openhab-upgrade | openhab-upgrade | Usage: tar -[cxtZzJjahmvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]... openhab-upgrade | openhab-upgrade | Create, extract, or list files from a tar file openhab-upgrade | openhab-upgrade | Operation: openhab-upgrade | c Create openhab-upgrade | x Extract openhab-upgrade | t List openhab-upgrade | f Name of TARFILE ('-' for stdin/out) openhab-upgrade | C Change to DIR before operation openhab-upgrade | v Verbose openhab-upgrade | Z (De)compress using compress openhab-upgrade | z (De)compress using gzip openhab-upgrade | J (De)compress using xz openhab-upgrade | j (De)compress using bzip2 openhab-upgrade | a (De)compress using lzma openhab-upgrade | O Extract to stdout openhab-upgrade | h Follow symlinks openhab-upgrade | m Don't restore mtime openhab-upgrade | exclude File to exclude openhab-upgrade | X File with names to exclude openhab-upgrade | T File with names to include

wborn · 2018-01-03T20:26:23Z

entrypoint_alpine.sh

+        rm -rf "${APPDIR}/userdata/cache"
+        rm -rf "${APPDIR}/userdata/tmp"
+	mkdir "${APPDIR}/userdata/cache"
+	mkdir "${APPDIR}/userdata/tmp"


Please correct the indentation

wborn · 2018-01-03T20:27:51Z

entrypoint_debian.sh

+
+        # Make a backup of userdata
+        backupFile=userdata-$(date +"%FT%H:%M:%S").tar
+        tar --exclude="${APPDIR}/userdata/backup" cf "/tmp/${backupFile}" "${APPDIR}/userdata"


On Debian TAR creation now fails with:

openhab-upgrade | + tar --exclude=/openhab/userdata/backup cf /tmp/userdata-2018-01-03T21:18:25.tar /openhab/userdata openhab-upgrade | tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options

wborn · 2018-01-03T20:28:20Z

entrypoint_debian.sh

+        rm -rf ${APPDIR}/userdata/cache
+        rm -rf ${APPDIR}/userdata/tmp
+	mkdir ${APPDIR}/userdata/cache
+	mkdir ${APPDIR}/userdata/tmp


Please add double quotes here too and correct the indentation.

…removed the exclude option from the tar for now pending further research.

rkoshak · 2018-01-04T15:04:29Z

OK, this fever is hitting me harder than I thought. Let me go back and figure out what I messed up. I'm pretty sure I ran with the exclude option inside the container to test it but perhaps not.

I've removed the excludes option from the tar and fixed the indentation and quotes problems identified. I will need to look into why the tar command doesn't support the standard --exclude option and determine if there is an alternate. If not I'll have to go about excluding the backups some other way.

andrey-yantsen · 2018-01-04T18:33:33Z

IMHO, checking by build-no is not really a good idea, here are build numbers for stable releases:

2.0 — Release Build
2.1 — - release build -
2.2 — Release Build

Looks like it's better to concatenate openhab-core/openhab-distro with build-no.

wborn · 2018-01-04T20:34:48Z

entrypoint_alpine.sh

+
+        # Make a backup of userdata
+        backupFile=userdata-$(date +"%FT%H:%M:%S").tar
+        tar -c -f "/tmp/${backupFile}" -X "${APPDIR}/userdata/backup" "${APPDIR}/userdata"


When the backup dir does not exist the container fails to start on Alpine with:

openhab-upgrade | + tar -c -f /tmp/userdata-2018-01-04T21:00:58.tar -X /openhab/userdata/backup /openhab/userdata openhab-upgrade | tar: /openhab/userdata/backup: No such file or directory

So making sure the dir exists will fix it, e.g. add: mkdir -p "${APPDIR}/userdata/backup"

cniweb

I think -X is the problem

… it to before the tar, change the tar to save straight to the backup folder which we can do now that we are excluding the backup folder from the backup and we know it exists. Moved the * outside the double quotes in the cp for the karaf etc files.

rkoshak · 2018-01-05T20:57:47Z

Sigh, alpine is a pain in the butt. Seems common sense to me that if you are telling tar to ignore the file, it shouldn't care that the directory doesn't exist in the first place.

Moving the test to see if the backup exists and creating it before the tar should fix it. I'll move it on the debian side to keep the two in sync with each other.

On the plus side, now that I can guarantee that the backup folder will exist before the tar and we are excluding it, I can skip the step of taring it to tmp and copying it over and just tar is to backups in the first place. I should have thought of that before. It is amazing how much clearer one can think when without a fever.

This update should fix the problem with the tar and copy commands (I now know to check Travis) ;-)

@andrey-yantsen, you have a good point. I'll submit another update later today or sometime tomorrow when I figure out the best way to use all of the fields in version.properties. Maybe I should just diff the files and see if they are identical and assume any change means a different version.

rkoshak · 2018-01-05T21:25:58Z

:-( I don't understand the travis error. It is failing on a line that isn't part of anything I changed:

The command '/bin/sh -c apk update && apk upgrade && apk add --no-cache ca-certificates fontconfig ttf-dejavu libpcap-dev unzip dpkg gnupg wget curl bash shadow openjdk8 zip su-exec && rm -rf /var/cache/apk/*' returned a non-zero code: 1

As far as I can tell at this point it was an intermittent download error.

BClark09

Hi @rkoshak, sorry to be a pain. I missed this the first time round, could you add:

cp "${APPDIR}/userdata.dist/etc/custom.system.properties" "${APPDIR}/userdata/etc"

To that list? This is a file that was created after the first list I suggested and completely forgot about it until now.

wborn · 2018-01-06T00:03:30Z

Thanks @rkoshak for solving the backup issues!

When I upgrade a container from 2.1.0 to 2.2.0 it no longer properly starts. It looks like a new file that was added in 2.2.0 /userdata/etc/overrides.properties is also missing. Without this file issue openhab/openhab-distro#573 occurs and you first need to enter a command on the Karaf console for the container to properly start.

rkoshak · 2018-01-06T00:16:23Z

Hmmmm. Checking @BClark09's latest upgrade script in the 2.3 snapshot overrides.properties is not one of the files copied over. I do see overrides.properties listed in userdata.dist. Are there any unknown or unexpected side effects if I copy over this file for all versions, or should I only do it for 2.1.0 to 2.2.0 upgrades, or upgrades from 2.1.0 to anything else? @BClark09, does this need to also be addressed in the upgrade script?

@BClark09, no problem I'll add that list. Does that file exist for earlier versions of OH too? I'm concerned about needing to add some error checking so it doesn't error out when the file doesn't exist in openhab.dist in earlier versions.

I based the original list on the upgrade script for 2.2 snapshot (around build 950) and assumed, falsely that no changes have been made. I should have checked. Of course, I may have just missed it. I'm usually a lot better at this sort of thing. Definitely not showing my best developer skills on the PR.

Update forthcoming...

…ded the missing custom.system.properties and system.properties to the list.

…data.dist

rkoshak · 2018-01-06T00:27:58Z

I also discovered system.properties was missing from the list. Added them both. Decided to added overrides.properties as well. Running out of time, I'll pull a 2.1 image tomorrow and check that I haven't broken it because overrides.properties doesn't exist.

Drat, upon rereading @wborn's comment now I'm sure I just broke it. Arg. Slow down Rich!

* Skip copy of non-existing files * Fix excluding backups directory on Alpine * Simplify grep and add missing double quotes * Correct indentation Signed-off-by: Wouter Born <eclipse@maindrain.net>

wborn · 2018-01-06T03:32:14Z

I've done some more testing and had another look at the code which resulted in the PR rkoshak#1 . So it would be nice if you can merge it. With that all my issues and remarks are resolved @rkoshak! 🙂 🎉

BClark09 · 2018-01-06T11:22:32Z

overrides.properties is not one of the files copied over

Oops, it should be!

Does that file [custom.system.properties] exist for earlier versions of OH too?

Afraid not, it's a new file for 2.2

wborn · 2018-01-06T11:30:23Z

Afraid not, it's a new file for 2.3

I ran into it as well so added a check in my fixes and improvements PR: https://github.com/rkoshak/openhab-docker/pull/1/files#diff-f57fa2e79c10b7b9f67f63d7c84009e3R70

We can add some more elegant checks and logic for adding/removing files in future PRs. The current PR will make working with openHAB containers a lot easier on a daily basis. 👍

andrey-yantsen · 2018-01-06T19:22:12Z

Just in curiosity: can't we just copy all etc/*.properties (except for users & keys), add all.policy, few *.cfg and finally copy all new files from userdata.dist which aren't presented in current userdata? For the last step we could use something like false | cp -ir userdata.dist/etc userdata/etc, (piping false required because alpine doesn't know cp -n).

As for version.properties comparison — for now we have sha1sum, sha256sum and sha512sum in both debian and alpine images, and as far as I understand we can interpret any difference in those files as different builds.

Fixes and improvements

…age and container to use cmp which compares the whole file.

rkoshak · 2018-01-06T22:02:04Z

Changes have been merged @wborn.

Just in curiosity: can't we just copy all etc/*.properties (except for users & keys), add all.policy, few *.cfg and finally copy all new files from userdata.dist which aren't presented in current userdata?

That's a question for @BClark09. I'm strongly of the opinion that we should use the same upgrade approach as the upgrade script in /usr/share/openhab2/bin for an apt/yum installed OH. Since each file is copied over individually in that script I assume there is a good reason why.

If there isn't a good reason, then I would prefer to change to the proposed or some other approach until we can extract out the copying of the etc files and clearing of the cache gets pulled out into a single script or some such that apt, yum, the upgrade script and these entrypoint scripts can all call rather than have Docker deviate from the behavior of the existing upgrade script.

As for version.properties comparison — for now we have sha1sum, sha256sum and sha512sum in both debian and alpine images, and as far as I understand we can interpret any difference in those files as different builds.

That seems a little heavy. I've implemented it using cmp in this latest update.

wborn

Thanks LGTM now!

andrey-yantsen

You've changed the way of checking for a new build, but you've forgot about the messages right after this check :)
And you've accidentally committed .entrypoint_debian.sh.swp

andrey-yantsen · 2018-01-07T09:44:58Z

entrypoint_alpine.sh

@@ -45,6 +45,48 @@ case ${OPENHAB_VERSION} in
        cp -av "${APPDIR}/userdata.dist/." "${APPDIR}/userdata/"
      fi

+      # Upgrade userdata if versions do not match
+      if [ ! -z $(cmp "${APPDIR}/userdata/etc/version.properties" "${APPDIR}/userdata.dist/etc/version.properties") ]; then
+        echo "Image build number \"${imgVersion}\" is different from userdata build number \"${curVersion}\""


Variables imgVersion and curVersion are undefined now

andrey-yantsen · 2018-01-07T09:45:19Z

entrypoint_debian.sh

@@ -60,6 +60,48 @@ case ${OPENHAB_VERSION} in
        cp -av "${APPDIR}/userdata.dist/." "${APPDIR}/userdata/"
      fi

+      # Upgrade userdata if versions do not match
+      if [ ! -z $(cmp "${APPDIR}/userdata/etc/version.properties" "${APPDIR}/userdata.dist/etc/version.properties") ]; then
+        echo "Image build number \"${imgVersion}\" is different from userdata build number \"${curVersion}\""


Variables imgVersion and curVersion are undefined now

Clearly, I'm doing something wrong with git. I made the change to the echo again and checked it in again. Hopefully, it shows up this time.

OK, looks like it matches what I thought the last checkin was supposed to be.

…ow that wasn't part of the last update.

rkoshak · 2018-01-08T17:52:03Z

Hmm, my last comment isn't here.

I've fixed hopefully the last issue pointed out by @andrey-yantsen.

I think it is ready for a final review and whatever the next steps are.

cniweb · 2018-01-10T19:14:17Z

Review status: all files reviewed at latest revision, 16 unresolved discussions.

Comments from Reviewable

Implemented a check against the openHAB version and perform an upgrad…

cdd9aab

…e if the versions are different.

cniweb requested changes Dec 28, 2017

View reviewed changes

cniweb requested a review from BClark09 December 28, 2017 22:00

cniweb added the update label Dec 28, 2017

cniweb requested a review from smerschjohann December 28, 2017 22:20

Cleaned up problems found by Codacy, ran upgrade.sh

811b983

cniweb approved these changes Dec 28, 2017

View reviewed changes

cniweb requested a review from martinvw December 28, 2017 22:46

wborn requested changes Dec 28, 2017

View reviewed changes

wborn reviewed Dec 28, 2017

View reviewed changes

Copied the original .sh files from master on the openhab-docker repo …

f423134

…and remade the edits. There were inconsistancies including changes from previous commits that were lost somehow.

wborn reviewed Dec 29, 2017

View reviewed changes

martinvw reviewed Dec 29, 2017

View reviewed changes

Suggested updates made:

1db013e

- removed extraneous a options from the if statements - removed extraneous echo - use double quotes on all directroies and files - remove the whole cache and tmp folders then recreate them - exclude the backups folder from the tar

wborn requested changes Jan 3, 2018

View reviewed changes

Fixed indentation and double quotes around some of the directories, …

74c4a07

…removed the exclude option from the tar for now pending further research.

wborn requested changes Jan 4, 2018

View reviewed changes

cniweb requested changes Jan 5, 2018

View reviewed changes

BClark09 suggested changes Jan 5, 2018

View reviewed changes

rkoshak added 2 commits January 5, 2018 17:23

Reordered the files copied over from userdata.dist alphabetically, ad…

aed3cc6

…ded the missing custom.system.properties and system.properties to the list.

Added overrides.properties to the list of files copied over from user…

f57ecac

…data.dist

Fixes and improvements

c30a1f9

* Skip copy of non-existing files * Fix excluding backups directory on Alpine * Simplify grep and add missing double quotes * Correct indentation Signed-off-by: Wouter Born <eclipse@maindrain.net>

rkoshak and others added 3 commits January 6, 2018 14:32

Merge pull request #1 from wborn/upgrade

6184ed6

Fixes and improvements

Changed the test to see if version.properties is different between im…

63dc879

…age and container to use cmp which compares the whole file.

Forgot to run upgrade.sh

07a9607

wborn approved these changes Jan 6, 2018

View reviewed changes

andrey-yantsen reviewed Jan 7, 2018

View reviewed changes

Fixing echo that referred to previously removed variables. Not sure h…

fc27cf8

…ow that wasn't part of the last update.

cniweb approved these changes Jan 10, 2018

View reviewed changes

cniweb merged commit d574a3c into openhab:master Jan 10, 2018

wborn mentioned this pull request Jan 10, 2018

Could not launch framework java.lang.RuntimeException: Could not resolve mvn:org.eclipse.tycho/org.eclipse.osgi #146

Closed

BClark09 mentioned this pull request Mar 22, 2018

Error installing boot feature repository org.apache.karaf.features:framework:4.1.5 #165

Closed

Issue #148 Check openHAB version and perform an upgrade if different #149

Issue #148 Check openHAB version and perform an upgrade if different #149

Conversation

rkoshak commented Dec 28, 2017 • edited by cniweb

cniweb left a comment

Choose a reason for hiding this comment

rkoshak commented Dec 28, 2017

cniweb commented Dec 28, 2017

rkoshak commented Dec 28, 2017

rkoshak commented Dec 28, 2017

cniweb commented Dec 28, 2017

cniweb commented Dec 28, 2017

cniweb commented Dec 28, 2017

wborn commented Dec 28, 2017

rkoshak commented Dec 28, 2017

wborn left a comment

Choose a reason for hiding this comment

wborn Dec 28, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkoshak commented Dec 28, 2017

wborn commented Dec 29, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkoshak Jan 3, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkoshak Jan 3, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinvw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wborn commented Dec 29, 2017

rkoshak commented Jan 3, 2018

wborn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkoshak commented Jan 4, 2018

andrey-yantsen commented Jan 4, 2018

Choose a reason for hiding this comment

cniweb left a comment

Choose a reason for hiding this comment

rkoshak commented Jan 5, 2018

rkoshak commented Jan 5, 2018 • edited

BClark09 left a comment

Choose a reason for hiding this comment

wborn commented Jan 6, 2018

rkoshak commented Jan 6, 2018

rkoshak commented Jan 6, 2018 • edited

wborn commented Jan 6, 2018

BClark09 commented Jan 6, 2018 • edited

wborn commented Jan 6, 2018

andrey-yantsen commented Jan 6, 2018

rkoshak commented Jan 6, 2018

wborn left a comment

Choose a reason for hiding this comment

andrey-yantsen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkoshak Jan 7, 2018 • edited

Choose a reason for hiding this comment

rkoshak commented Jan 8, 2018

rkoshak commented Dec 28, 2017 •

edited by cniweb

wborn Dec 28, 2017 •

edited

rkoshak Jan 3, 2018 •

edited

rkoshak Jan 3, 2018 •

edited

rkoshak commented Jan 5, 2018 •

edited

rkoshak commented Jan 6, 2018 •

edited

BClark09 commented Jan 6, 2018 •

edited

rkoshak Jan 7, 2018 •

edited