ah, ok... then its a similar problem, but for a different reason...
if you compile from source, then its trying to use master, as this will be the 'development branch' of these libraries.
BUT the issue is, you will want to be using the version that other users are using!
SO... the solution is, go into both factory and contrib libraries , and set the revision to 1.0.11, and then do 'init' on each, this will move you to using 1.0.11 along with other users.
note: there is one issue with this approach, if you specify a revision, then I believe you will not get a warning when we move to the next version( e.g. 1.0.12) ...
(though, I need to confirm this, as its a while since I wrote that code )
question: @a773 can you not used the released linux package? unless you are planning on helping development, it is a much better idea... we do not support the development version, as it may have untested/incomplete code etc.
what I need to do (or someone else) is actually detail the compiling from source with a bit more detail, and in particular how it should be done, as ideally users (that are not developers) should be using the tagged release from github, not the master branch.
@johannes this highlights an issue, which I've mentioned before...
really there are 2 types of users compiling from source:
a) users with unsupported platforms... they just want a build
for these users, they should build the currently released version, against the tag e.g. 1.0.11
this should then default the revisions to that tag (as it does with the pre-built binaries)
b) developers/testers who what to use a development version
this must not be used against the production release repos, as the code may contain code that could break these repos.
as I suggested before, my thoughts are as soon as we make a release, we must then tag the development code line with a new version (* see below on thoughts on this), and then we can have a branch version of the factory/contrib that corresponds to this version. (and that the build will use by default for revision) ... we will then merge from production to dev 'regularly'
new version... as before, I suggest we use a linux type convention of 'even numbers' for development and odd for release.
so an example for now might might be
1.0.11 is released,
we create a branch now (axoloti,axolotl-factory,axoloti-contrib) for 1.0.12, this is the dev branch...
(during dev we keep merging 1.0.11 to 12 for the factory/contrib)
when releasing, we create a 1.0.13 branch, and then if we are doing a minor release (1.0.14 for dev)
this is for minor release..
when we are on to 'major' releases, I want to move to
1.1.0 for dev
1.2.0 for release
1.3.0 for dev
1.4.0 for release
it may seem complex, but the point is, that users of type (a) or (b) will then always be connected to the correct object/patch versions, and the development environment will operate the same as release environment, when committing changes etc... much better for testing.
also, this mechanism allows for the app to know about 'upgrading' and moving the repo versions, something we cannot do if its just called 'master'