Glad the isshe is resolved. Gentlemen, this is off-topic, but might as well bring it up here. I created an INDI repo on github:

github.com/indilib/indi

Anyone willing to handle the import of the code from SourceForge subversion over to github? I tried importing and it resulted in an unknown error. I also use svn:externals and not exactly sure how to do this in git (submodules?). So any GIT guru who can help is greatly appreciated. Of course, I want to reserve the history of the files/commits as much as possible during the import process.

Github is unable to do it by itself. I have tried it short time ago. I ended up doing it on my homa machine and then exporting it to github. I have a current mirror (from four hours ago) at my github account (github.com/jochym/indilib). I have a procedure to keep it in sync with sourceforge so I can bring it up to date.
Maybe we can use this as a base? Or just repeat the my steps for cloning and pushing to github (unfortunately I did not kept records of the import procedure - but it was rather straightforward). If we are going to use my repo we need to make sure some important history is not lost - my repo is based on trunk from subversion and does not have any other branches. What are your plans regarding this? Are we going to move to some git-based hosting (github, gitlab, others?) for mainline development (please, please say yes ? If so I can dig out some docs on one time full-repo imports. If you are planning to keep svn in sync - be warned it is not trivial and probably impossible in general (the structure in git is simply more complicated). But I think this is a good move. I was involved in two migrations from sourceforge to github and in both cases author is glad we did it. I am pretty busy right now so I am not really volunteering right now - but If nobody else will step up I will do it. For now you can clone my repo and check if it is ok. All my commits to sourceforge have been done using this repo and git-svn.
(BTW - we should probably move this to separate thread)

Yes I'm thinking of migrating to github. I just sent you an invitation for full admin access so you you can whatever is necessary to import trunk from Sourceforge or your github branch. Once import is complete, I'll disable the sourceforge subversion.

Good to know, I think this is a very good choice
I think the biggest issue here is the presence of svn:externals, as you already mentioned.
I saw a lot of them for the cmake directory (replicated in all the child drivers), I'm not sure if there are more of them.
This in git is simply unsupported.
There are two ways to solve this:
1) first remove the svn:external in svn, for instance, just make all drivers point to a unique directory. This way each subdirectory will be dependant from the root, but since git doesn't support "partial" clones, you either download the full repo, or none.
2) Use separated projects: for instance, one for indi-core, one for third-party, and another one for the shared files (cmake, for instance). indi-core and 3rd-party should depend on the "common" project using a git submodule.

Ok. I think I found a way to do it properly. Trying it right now. There is a tool (svn2git) which imports whole structure (branches and tags as well). I will write here how it went. Fingers crossed.
What other data is important to migrate? Issues? Other metadata.
One think I will need help with is a list of authors - we need a map from sf -> github.
I have accepted the invite and created a repo for experimental-import.
There is authors.txt file there (The data is extracted from svn log).
Please try to fill in any names/email info you know. It should be:
svn_user = github_user <email@domain>

Excellent (do I need to post more? )

Yes the externals is a bit of a problem.
Actually more so then the partial clone issue.
The repo is not so large by today's standards - my clone takes just 150MB.
So I would not loose any sleep over this issue. The structure of the tree
is harder - but in my opinion should be re-organized anyway.
Building indi and its drivers is not trivial for a novice and is a bit confusing.
So maybe we should use this opportunity for reorganization?

Well, I'm open to suggestions. The fact is all drivers need the common cmake_modules directory. I don't think a symlink will do it. Also, no need to migrate branches and tags, just trunk is enough.

As a new "builder" for the first time over the weekend, I had to hunt a little but the main issue is the kf5 dependency. It's probably better to say install KDE Framework 5 (the entire lot to make sure).

Note that I'm an amateur in development (BSc + 18 years) and many of the new recruits (Per for example) are very experienced too.

The build seemed relatively painless, although adding new drivers etc will be a different kettle of fish. I'd like to simply add a directory with a local cmake perhaps and the system then finds during the build. Focusing on restructuring to make it easy create new drivers and maintain existing - especially as I see INDI becoming more of a defacto cross platform system.

That is good - I have succeed in importing the whole tree (with tags and branches) but it resulted in the huge mess. i.e. the tree had a lot of branches of historical meaning and some probably even not much so (experiments/tests etc.).
Here is a list of branches
So you are saying we can do with just trunk and we will use svn for historical stuff ?

That will make it much easier and manageable.

As for the externals - if it is only cmake directory maybe we can just split it off into separate repo
and use git submodules to insert it it proper places? Would that be all right? It is not difficult git-wise
We just split the repo post-import and remove duplicating parts from the main repo and cmake repo.
This is a fairly well known procedure.

Yup, just trunk is sufficient. SourceForge subversion will remain RO. And I think "submodules" is the way to go after reading about the subject a bit, but I'm not sure how to proceed with this myself. As long as if I clone, for example, 3rdparty/indi-eqmod, then cmake_modules is automatically checkout out along.

That is a good point (multi platform support) - git submodules work on all platforms I suppose - symbolic links not so much.
Thanks to Jasem's efforts the build docs are much better now. I remember scratching my head quite a bit when I was starting my development of the new driver, and I still think the system is "slightly convoluted".