Error message in Karaf console on Windows 10 #530

MHerbst · 2017-09-03T08:02:28Z

Since switching to Karaf 4.1.2 the following message appears on the Karaf console:

Error in initialization script: E:\openhab-2.2.0-SNAPSHOT\userdata\openhab-2.2.0-SNAPSHOTuserdataetc\shell.init.script: E:\openhab-2.2.0-SNAPSHOT\userdata\openhab-2.2.0-SNAPSHOTuserdataetc\shell.init.script

I have downloaded Karaf 4.1.2. and it does not show any error messages. I suppose it has something to do with the files used to start up openHAB.

The text was updated successfully, but these errors were encountered:

hr3 · 2017-09-06T06:37:20Z

I have the same problem, at least with #1031to #1033.

martinvw · 2017-09-13T11:15:00Z

I have / had it to, it is in a piece about setting up color output.

Does your environment run fine for the rest?

hr3 · 2017-09-13T11:25:17Z

I have some problems, but I think, it has other resons.

martinvw · 2017-09-13T11:33:26Z

In my case it also was not the reason to stop it from starting that was: openhab/openhab-docker#102

openhab_1  | Error in initialization script: /openhab/userdata/etc/shell.init.script: String index out of range: 0
openhab_1  | openhab> openhab2_openhab_1 exited with code 0

dominikbenner · 2017-09-13T12:14:44Z

Same issue here with build 1037.
In addition to that error message my logging is complete wrong.
There is no event.log and my openhab.log is under the root dir of the volume. So both logfiles are not located in userdata/logs.

gfischershaw · 2017-09-13T21:13:53Z

Others reported it starting after build 1003 and on or before 1010.

So is something now calling convertPaths twice?

martinvw · 2017-09-14T05:41:34Z

Others reported it starting after build 1003 and on or before 1010.

https://community.openhab.org/t/karaf-upgrade/33208

Celaeno1 · 2017-09-16T15:48:27Z

I updated from build 982 to build 1039. Having the same error!

Celaeno1 · 2017-09-17T18:34:13Z

I “solved” the problem! I commented the following line in userdata\etc\system.properties:

# karaf.shell.init.script = ${karaf.etc}/shell.init.script

Now, the error is gone!

Can anyone confirm this, too?

NurNano · 2017-09-17T19:55:02Z

Yea I can confirm this. Now it starts! But still creates a directory one directory abovoe the .bat. Named "OPENHA~2.0-B\userdata\logs" is in there at my system.

gfischershaw · 2017-09-17T21:01:45Z

Except that shell.init.script is likely never run since it is not defined.
Everything looks OK on the way in within karaf.bat, so I presume it must be the new version of karaf itself that was checked in on 1009.

Celaeno1 · 2017-09-18T02:35:59Z

I tested also with this in userdata\etc\system.properties:

karaf.shell.init.script = c:/Openhab2/userdata/etc/shell.init.script

or

 karaf.shell.init.script = etc/shell.init.script

The error also is gone! But now I would like to know how to test it! (--> if shell.script is running??)

Anyone else who knows that?

Celaeno1 · 2017-09-18T08:44:55Z

Further tests with:

\userdata\etc\system.properties:

karaf.shell.init.script = ${karaf.base}/etc/shell.init.script

result: --> C:\Openhab2\userdata\Openhab2userdata\etc\shell.init.script

karaf.shell.init.script = ${karaf.home}/etc/shell.init.script

result: --> C:\Openhab2\userdata\Openhab2runtime\etc\shell.init.script

It seems that at all variables are missing the \ or / in the path:

karaf.base = Openhab2userdata
karaf.home = Openhab2runtime
karaf.etc = Openhab2userdataetc

Then I forced an exception:

 Exception in thread "Karaf local console user openhab" java.nio.file.InvalidPathException: Illegal char 
<:> at index 2: $C:Openhab2userdataetc/shell.init.script
        at sun.nio.fs.WindowsPathParser.normalize(Unknown Source)
        at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
        at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
        at sun.nio.fs.WindowsPath.parse(Unknown Source)
        at sun.nio.fs.WindowsFileSystem.getPath(Unknown Source)
        at sun.nio.fs.AbstractPath.resolve(Unknown Source)
        at java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
        at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
        at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
        at java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(Unknown Source)
        at java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Unknown Source)
        at java.util.stream.ReferencePipeline$Head.forEach(Unknown Source)
        at 
org.apache.karaf.shell.impl.console.ConsoleSessionImpl.executeScript(ConsoleSessionImpl.java:490)
       at org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:342)
       at java.lang.Thread.run(Unknown Source)

Maybe someone else knows where and what to do, now??

MHerbst · 2017-09-18T19:08:58Z

I have compared the batch files and the system.properties file delivered with openHAB with the files delivered with plain Karaf.

And finally I found this comment in the system.properties file delivered with Karaf

#
# Location of a shell script that will be run when starting a shell
# session.  This script can be used to create aliases and define
# additional commands.
# Do not use absolute paths to avoid problems on windows.
#
karaf.shell.init.script = etc/shell.init.script,etc/scripts/*.script

After changing openHAB's system.properties file as follows:

karaf.shell.init.script = etc/shell.init.script,etc/scripts/*.script

the error message disappeared!

It seems that everything works correctly with this change, but I am not sure whether it is also OK for Linux environments and therefore it will need some further testing.

@kaikreuzer Do you have any idea why this setting was modified for openHAB and changed to an absolute path?

kaikreuzer · 2017-09-19T07:21:44Z

@MHerbst I assume I didn't read the comment carefully enough and must have changed it to an absolute path. The issue is that we have different locations of the etc folder for the different installation types. I am actually not 100% certain, where the "." location is for an apt-based installation (@BClark09 can you tell?). If it is the "openHAB application", we might have a chance to move these scripts to runtime/etc, which should be the same for all installation types; might be worth a try.

BClark09 · 2017-09-19T10:13:58Z

Editing system.properties to contain the following should be enough:

karaf.shell.init.script = etc/shell.init.script

To test, I added the following line to $OPENHAB_USERDATA/etc/shell.init.script

bentest = { help $args } ;

So it looks like the working directory is $OPENHAB_USERDATA, just as it is in @MHerbst's instance.

kaikreuzer · 2017-09-19T10:51:48Z

Thanks, the fix should then pretty simple indeed.
Actually I had hoped we could move the stuff to runtime in order to keep userdata clean, but it seems that there isn't a simple way to reference this folder then :-(

kaikreuzer · 2017-09-19T11:01:30Z

@MHerbst I just noticed that the line

# Do not use absolute paths to avoid problems on windows.

Isn't contained in our system.properties, so that is why I didn't notice that. Browsing the Karaf code, I now just found this from 8 days ago 😲 - so before removing that prefix, I would want to clarify what this is about on https://issues.apache.org/jira/browse/KARAF-5352.

jbonofre · 2017-09-19T12:27:52Z

The value looks good to me. It seems that the problem is that karaf.etc = Openhab2userdataetc (the / is missing).

BClark09 · 2017-09-19T12:52:19Z

@jbonofre The underlying cause for that problem is a mystery (at least to me) however. It is set properly in oh2_dir_layout.sh:

set KARAF_ETC=%OPENHAB_USERDATA%\etc

which gets passed to karaf.etc in karaf.bat:

-Dkaraf.etc="%KARAF_ETC%" ^

MHerbst · 2017-09-19T12:55:41Z

@jbonofre Too me it seems that the "/" or "" is removed somewhere within Karaf itself if the entry contains a reference to an environment variable.
I have modified the batch file that starts Karaf and printed all environment before Karaf is started. All environment variables (KARAF_HOME, KARAF_ETC, KARAF_BASE) had correct values.
As you can see in this post #530 (comment), it works if {$karaf.etc} is replaced by a fully qualified path.

Maybe the cause lies in the code that resolves the variables in non-Linux/Unix environments.

kaikreuzer · 2017-10-06T03:03:01Z

@MHerbst Could you test that on a plain Karaf installation and if there are problems when setting KARAF_ETC manually, would you add a comment to https://issues.apache.org/jira/browse/KARAF-5352? To me it yet isn't clear where the path gets set and where the backslash is lost on the way.

I also wonder whether it needs to be forward or back slashes on Windows, at the moment we seem to have an unhealthy mix...

hr3 · 2017-10-06T05:41:51Z

I put the echos in runtime/bin/karaf.bat behind
381 if "%IS_RUNNABLE%" == "true" (
and get this on Windows10Pro(32Bit) 1703 15063.608

Launching the openHAB runtime...
WARNING: Running Karaf on a Java HotSpot Client VM because server-mode is not available.
Install Java Developer Kit to fix this.
For more details see http://java.sun.com/products/hotspot/whitepaper.html#client

JAVA:"C:\Program Files\Java\jre1.8.0_144\bin\java"
JAVA_OPTS:"   -Dopenhab.home=C:\openHAB\OPENHA~1.0-S   -Dopenhab.conf=C:\openHAB\OPENHA~1.0-S\conf   -Dopenhab.runtime=C:\openHAB\OPENHA~1.0-S\runtime   -Dopenhab.userdata=C:\openHAB\OPENHA~1.0-S\userdata   -Dopenhab.logdir=C:\openHAB\OPENHA~1.0-S\userdata\logs   -Dfelix.cm.dir=C:\openHAB\OPENHA~1.0-S\userdata\config   -Djetty.host=0.0.0.0   -Dorg.ops4j.pax.web.listening.addresses=0.0.0.0   -Dorg.osgi.service.http.port=8080   -Dorg.osgi.service.http.port.secure=8443 -XX:+UseG1GC   -Djava.awt.headless=true"
JAVA_HOME:"C:\Program Files\Java\jre1.8.0_144"
OPTS:"-Dkaraf.startLocalConsole=true -Dkaraf.startRemoteShell=true"
CLASSPATH:"C:\openHAB\OPENHA~1.0-S\userdata\conf;C:\openHAB\openhab-2.2.0-SS1055\runtime\bin\..\lib\boot\org.apache.karaf.diagnostic.boot-4.1.2.jar;C:\openHAB\openhab-2.2.0-SS1055\runtime\bin\..\lib\boot\org.apache.karaf.jaas.boot-4.1.2.jar;C:\openHAB\openhab-2.2.0-SS1055\runtime\bin\..\lib\boot\org.apache.karaf.main-4.1.2.jar;C:\openHAB\openhab-2.2.0-SS1055\runtime\bin\..\lib\boot\org.osgi.core-6.0.0.jar"
OPENHAB_USERDATA:"C:\openHAB\OPENHA~1.0-S\userdata"
OPENHAB_LOGDIR:"C:\openHAB\OPENHA~1.0-S\userdata\logs"
KARAF_HOME:"C:\openHAB\openhab-2.2.0-SS1055\runtime\bin\.."
KARAF_BASE:"C:\openHAB\OPENHA~1.0-S\userdata"
KARAF_ETC:"C:\openHAB\OPENHA~1.0-S\userdata\etc"
KARAF_DATA:"C:\openHAB\OPENHA~1.0-S\userdata"
KARAF_OPTS:""
MAIN:"org.apache.karaf.main.Main"
ARGS:"       "

                          __  _____    ____
  ____  ____  ___  ____  / / / /   |  / __ )
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  |
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/
    /_/                        2.2.0-SNAPSHOT
                               Build #1055

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.

Error in initialization script: C:\openHAB\openhab-2.2.0-SS1055\userdata\openHABopenhab-2.2.0-SS1055userdataetc\shell.init.script: C:\openHAB\openhab-2.2.0-SS1055\userdata\openHABopenhab-2.2.0-SS1055userdataetc\shell.init.script
openhab>

hr3 · 2017-10-06T13:03:10Z

I modyfied C:/oh22/userdata/etc/system.properties line 31 and document the results

#karaf.shell.init.script = ${karaf.etc}/shell.init.script		#C:\oh22\userdata\oh22userdataetc\shell.init.script
#karaf.shell.init.script = ${karaf.etc}\shell.init.script		#C:\oh22\userdata\oh22userdataetcshell.init.script
#karaf.shell.init.script = ${karaf.etc}					#C:\oh22\userdata\oh22userdataetc
#karaf.shell.init.script = C:\oh22\userdata\etc\shell.init.script	#C:\oh22\userdata\oh22userdataetcshell.init.script
#karaf.shell.init.script = C:/oh22/userdata/etc/shell.init.script	#works
#karaf.shell.init.script = etc/shell.init.script			#works
 karaf.shell.init.script = shell.init.script				#C:\oh22\userdata\shell.init.script

BClark09 · 2017-10-06T13:35:04Z

So, in otherwords ${karaf.etc} is fine until the point in which it's processed by the Java process, where it gets muddled by backslashes?

MHerbst · 2017-10-08T17:56:11Z

@kaikreuzer I have performed some tests and added the results to the Apache jira. It doesn't matter how KARAF_ETC is set. The Java code of Karaf seems to perform some conversion while expanding karaf.etc and this conversion probably does not work correctly on Windows 10. It seems that all directory names a translated to the system's standard separator character. Therefore it makes no difference whether you use forward or back slashes.

I also wonder whether it needs to be forward or back slashes on Windows, at the moment we seem to have an unhealthy mix...

This is really a problem. Generally, Windows supports forward and back slashes and you can even mix different slashes in a path. In Java code (and properties files) I normally use forward slashed in order to avoid escaping of the back slashes.
But if some Java code e.g. tries to figure out whether a path contains a (back) slash at the end this may fail if the code only checks for operating system's standard separator (value of system property "file.separator").

kaikreuzer · 2017-10-08T20:13:47Z

Many thanks for your analysis and for reporting details at the Karaf issue tracker. Let's see if the issue can be confirmed and fixed there!

matushromada · 2017-10-28T11:43:32Z

Hi, it seems that the issue was resolved in Karaf issue tracker. But the error still appears on the latest OH snapshot.

martinvw · 2017-10-29T18:16:23Z

Please note that the version in which it is fixed is not released so we have to wait for that:

matushromada · 2017-10-30T05:48:40Z

Thanks for explanation!

kaikreuzer · 2017-11-18T23:43:08Z

#570 is merged, so please check whether the issue is solved in distro 1083 and above!

BClark09 · 2017-11-19T00:48:48Z

Alas:

kaikreuzer · 2017-11-19T08:06:23Z

No good. This init script is a pain, even on my Mac it now fails on the first startup.
Does anyone happen to know in which file the Karaf fix is contained? Is it something that we manually need to sync to the openHAB distro? I have taken shell.init.script from Karaf 4.1.3, so this should be up to date.

martinvw · 2017-11-19T13:56:11Z

Afaik the problem originates from around:

https://github.com/openhab/openhab-distro/blob/master/distributions/openhab/src/main/resources/userdata/etc/shell.init.script#L50

It seems that they commented out line 53 but that makes the vars unused, so maybe we should just remove the whole block.

However I fear that we have bigger problems :-(

https://community.openhab.org/t/jetty-update-karaf-4-1-3-upgrade-and-full-lsp-support/36354/12

And my own test with the docker upgrade is also not looking good, note that I have version 1084 instead of 1083.

kaikreuzer · 2017-11-19T14:32:30Z

Could you test if you find some changes to shell.init.script that make it work better (maybe also without causing having to start twice, which might help for the docker setup)?

matushromada · 2017-11-19T17:03:50Z

Trying to answer Kai's question about which file the fix is contained: It seems that is system.properties as seen here.

martinvw · 2017-11-19T17:09:21Z

Thanks! but imho this looks pretty okay already:

openhab-distro/distributions/openhab/src/main/resources/userdata/etc/system.properties

Line 31 in b1c1118

karaf.shell.init.script = ${karaf.etc}/shell.init.script

MP91 · 2017-11-21T07:43:50Z

I´m still getting the same error on windows with snapshot 1084...

matushromada · 2017-11-21T09:23:28Z

I've noticed here (Fix startup scripts on windows), that issue with shell.init.script on windows was resolved in karaf by using "etc/shell.init.script" in system.properties
Not sure if I'm helpful or bringing just noise - just tell me.

MP91 · 2017-11-21T13:36:26Z

It seems to work with just karaf.shell.init.script = shell.init.script. So without any further paths. But I will investigate the behavior further

martinvw · 2017-11-21T13:49:16Z

It seems to work with just karaf.shell.init.script = shell.init.script. So without any further paths. But I will investigate the behavior further

Maybe a stupid question but isn't that maybe caused by the fact that it cannot find the file and no error will happen. Because the actual error is in the file itself AFAIK.

MP91 · 2017-11-21T14:45:19Z

Yes, that was the point. The path to the script was wrong. With ${karaf.etc} it was still the path where the backslashes were missing.
But unfortunately it is still not working even if the path is correct and the script is executed. The error is everytime: "command not found"...

martinvw · 2017-11-21T14:50:37Z

Sorry, I'm having another problem on my machines they complain about an error in the actual script, that is on Mac OS and Linux.

BClark09 · 2017-11-21T15:02:49Z

To take a step back a bit, before Karaf 4.1.2 the line in question was:

 karaf.shell.init.script = etc/shell.init.script

This uses a relative path which is safely parsed through Java for Windows.

The line in openHAB's verson of system.propeties now contains:

 karaf.shell.init.script = ${karaf.etc}/shell.init.script

Which evaluates to a full path and gets garbled by the process. The fix, that is not currently in openHAB's implementation is this one:

apache/karaf@066d28a

To resolve this issue we need to at least set this to a relative path (i.e. etc/shell.init.script) OR pull in this patch.

martinvw · 2017-11-21T15:15:09Z

So that is actually in karaf-4.2.0.M1? At least according to github. Please try it would be great if that finally solves it :-)

BClark09 · 2017-11-21T16:22:26Z

It'll work in both versions:

Version	FileStream.java contains...	system.properties should contain...
Karaf 4.1.2	`Path cur = Paths.get(System.getProperty("karaf.base"));`	`karaf.shell.init.script = etc/shell.init.script`
Karaf >=4.1.3	`Path cur = Paths.get(System.getProperty("karaf.etc"));`	`karaf.shell.init.script = shell.init.script`

After downloading a standalone Karaf 4.1.3, system.properties contains the fix also, so I do not think that the openHAB upgrade to Karaf has changed all of the associate files. openHAB's version of system.properties might be stale at this point. @MP91 was on the right track, if we simply replace system.properties with karaf's default (plus the options in a custom.system.properties)

BClark09 · 2017-11-21T17:38:13Z

@martinvw, @kaikreuzer, would the distro contain the Karaf default system.properties if we simply remove it from this repository? If so, then I think the appropriate fix should be:

Delete system.propeties
Add custom.system.properties with the following information:

karaf.name=openhab
karaf.local.user=openhab
mdnsName=openhab
smarthome.servicepid=org.openhab
smarthome.servicecfg=${openhab.runtime}/services.cfg
smarthome.userdata=${openhab.userdata}
smarthome.configdir=${openhab.conf}
org.quartz.properties=${openhab.runtime}/etc/quartz.properties
jetty.keystore.path=${openhab.userdata}/etc/keystore
jetty.truststore.path=${openhab.userdata}/etc/keystore
equinox.ds.block_timeout=240000
equinox.scr.waitTimeOnBlock=60000

(Which also resolves this todo)

martinvw · 2017-11-21T18:49:46Z

Sounds hopeful, I hope @kaikreuzer can give a detailed opinion

kaikreuzer · 2017-11-22T08:15:53Z

Add custom.system.properties which also resolves this todo

I do not understand why this should work. The todo references https://issues.apache.org/jira/browse/KARAF-3949 which is still unresolved.

So the correct fix would instead be to keep the existing system.properties and only update all the "standard" settings to be identical to what is shipped in Karaf 4.1.3.

BClark09 · 2017-11-22T08:26:48Z

The first line of Karaf's system properties in 4.1.3 is:

${optionals} = custom.system.properties

Anything written in the referenced file overwrites the standard system.properties.

kaikreuzer · 2017-11-22T08:30:43Z

Interesting :-)
So it might be worth to tell this to the Karaf people on their issue tracker!

So if this works - please create an according PR!

BClark09 · 2017-11-22T08:34:01Z

Will do, the screenshot of the working instnce I added above uses the custom file so all should be fine. Will deleting the file on this repo cause it to be replace by Karaf's default?

BClark09 · 2017-11-22T14:58:11Z

Done :-)

hr3 · 2017-11-23T07:58:53Z

.

matushromada · 2017-11-23T10:20:37Z

Using documentation for updating on Windows the error persists. Should I propose to add a file for deletion - system.properties - during the update process?

BClark09 · 2017-11-23T12:26:07Z

Good spot! The list in the Updating the openHAB Runtime section should include both files for deletion:

userdata\etc\system.properties
userdata\etc\custom.system.properties

matushromada · 2017-11-23T12:50:35Z

Done #575

kaikreuzer mentioned this issue Nov 17, 2017

Upgrade Karaf to 4.1.3 or 4.2.0.M1 #566

Closed

BClark09 mentioned this issue Nov 22, 2017

Use custom.system.properties to override Karaf defaults #579

Merged

kaikreuzer closed this as completed in #579 Nov 22, 2017

Error message in Karaf console on Windows 10 #530

Error message in Karaf console on Windows 10 #530

Comments

MHerbst commented Sep 3, 2017

hr3 commented Sep 6, 2017

martinvw commented Sep 13, 2017

hr3 commented Sep 13, 2017 • edited

martinvw commented Sep 13, 2017 • edited

dominikbenner commented Sep 13, 2017

gfischershaw commented Sep 13, 2017

martinvw commented Sep 14, 2017

Celaeno1 commented Sep 16, 2017

Celaeno1 commented Sep 17, 2017 • edited

NurNano commented Sep 17, 2017 • edited

gfischershaw commented Sep 17, 2017

Celaeno1 commented Sep 18, 2017 • edited

Celaeno1 commented Sep 18, 2017

MHerbst commented Sep 18, 2017

kaikreuzer commented Sep 19, 2017

BClark09 commented Sep 19, 2017

kaikreuzer commented Sep 19, 2017

kaikreuzer commented Sep 19, 2017

jbonofre commented Sep 19, 2017

BClark09 commented Sep 19, 2017 • edited

MHerbst commented Sep 19, 2017 • edited

kaikreuzer commented Oct 6, 2017

hr3 commented Oct 6, 2017 • edited

hr3 commented Oct 6, 2017 • edited

BClark09 commented Oct 6, 2017

MHerbst commented Oct 8, 2017 • edited

kaikreuzer commented Oct 8, 2017

matushromada commented Oct 28, 2017

martinvw commented Oct 29, 2017 • edited

matushromada commented Oct 30, 2017

kaikreuzer commented Nov 18, 2017

BClark09 commented Nov 19, 2017

kaikreuzer commented Nov 19, 2017

martinvw commented Nov 19, 2017

kaikreuzer commented Nov 19, 2017

matushromada commented Nov 19, 2017

martinvw commented Nov 19, 2017 • edited

MP91 commented Nov 21, 2017

matushromada commented Nov 21, 2017 • edited

MP91 commented Nov 21, 2017

martinvw commented Nov 21, 2017

MP91 commented Nov 21, 2017 • edited

martinvw commented Nov 21, 2017

BClark09 commented Nov 21, 2017 • edited

martinvw commented Nov 21, 2017

BClark09 commented Nov 21, 2017 • edited

BClark09 commented Nov 21, 2017 • edited

martinvw commented Nov 21, 2017

kaikreuzer commented Nov 22, 2017

BClark09 commented Nov 22, 2017

kaikreuzer commented Nov 22, 2017

BClark09 commented Nov 22, 2017 • edited

BClark09 commented Nov 22, 2017

hr3 commented Nov 23, 2017 • edited

matushromada commented Nov 23, 2017

BClark09 commented Nov 23, 2017 • edited

matushromada commented Nov 23, 2017

hr3 commented Sep 13, 2017 •

edited

martinvw commented Sep 13, 2017 •

edited

Celaeno1 commented Sep 17, 2017 •

edited

NurNano commented Sep 17, 2017 •

edited

Celaeno1 commented Sep 18, 2017 •

edited

BClark09 commented Sep 19, 2017 •

edited

MHerbst commented Sep 19, 2017 •

edited

hr3 commented Oct 6, 2017 •

edited

hr3 commented Oct 6, 2017 •

edited

MHerbst commented Oct 8, 2017 •

edited

martinvw commented Oct 29, 2017 •

edited

martinvw commented Nov 19, 2017 •

edited

matushromada commented Nov 21, 2017 •

edited

MP91 commented Nov 21, 2017 •

edited

BClark09 commented Nov 21, 2017 •

edited

BClark09 commented Nov 21, 2017 •

edited

BClark09 commented Nov 21, 2017 •

edited

BClark09 commented Nov 22, 2017 •

edited

hr3 commented Nov 23, 2017 •

edited

BClark09 commented Nov 23, 2017 •

edited