Talk:TerraGear scenery build server: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 54: Line 54:


:: '''saiarcot895''': You're right, I forgot about that. I've built simgear (in headless mode) for unstable and will build it for testing (jessie) and stable (wheezy), and will build terragear for all three releases once simgear is done. This should be done in a few hours. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:36, 10 March 2014 (UTC)
:: '''saiarcot895''': You're right, I forgot about that. I've built simgear (in headless mode) for unstable and will build it for testing (jessie) and stable (wheezy), and will build terragear for all three releases once simgear is done. This should be done in a few hours. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 21:36, 10 March 2014 (UTC)
:: '''saiarcot895''': Simgear for all releases is done, and Terragear for unstable is done. However, Terragear on testing failed with an error in a boost include saying uintptr_t wasn't found...which doesn't make sense to me since boost is from the main Debian archives. [[User:Flyhigh|Flyhigh]] ([[User talk:Flyhigh|talk]]) 00:28, 11 March 2014 (UTC)


== TerraGear & TerraGear GUI (reeed) ==
== TerraGear & TerraGear GUI (reeed) ==

Revision as of 00:28, 11 March 2014

Server & Hosting (D-YETI)

By the way I personally would give some computing time and IO /Diskspace, at the server listed below, too, because I hope much more pople will benefit from it than running it for me alone. Since Terragear is not so easy to install and even with the gui doesn't always give the result I was expecting.

  • Intel® Core™ i5-4570 CPU @ 3.20GHz × 4
  • 32GB RAM
  • SSD + RAID
  • but rather slow Internet connection. (600kbit/s dn / 128kbit/s up)

Potential TerraGear Issues (psadro_gm)

An issue you will may hit is that some terragear tools don't behave very well when run at the same time (genapt and ogrdecode, in particular). this may work with two separate work directories, but I have not tried it. If using the same work directory, You can hit some directory / file creation collisions. To recitify these, I added a Boost global mutex so one can write at a time. With multiple users, this may become a bottleneck.

Packaging (saiarcot895 )

Hooray:Obviously, one major part of this would involve installing/packaging SimGear and TerraGear as *.deb files. This would greatly simplify the installation - we do have several instructions related to this, and even a script - so we could change the script to build SG/TG and then package things afterwards.

Ideally, SimGear would be built in "headless" mode - i.e. minus all the OSG dependencies, no sound etc required: http://wiki.flightgear.org/Building_using_CMake#SimGear_Build_Options

So we would first of all end up with something like "libsimgear-headless-dev" which could be used to build TerraGear. The next step would be creating a package for TerraGear itself that depends on SimGear-headless-dev

Once these two steps are completed, setting up TerraGear on Linux should become much more straightforward. And we could use these packages to set up a TerraGear build server.

All this will be based on TurnKeyLinux, which is a debian/wheezy based distro, intended for "remastering" - so that new virtual appliances can be easily created, and exported - so that others can install an ISO file to get a working TG setup.

For now, I simply built SG headless (libsimgearcore) and installed it system-wide and it's working properly.

But obviously it would be better to come up with packages for both, SG and TG (64bit). Which would be useful for all debian/ubuntu users, not just this particular effort.

Also, we would need to publish those packages, so that people only need to add the repo to download updates automatically.

Overall, this would help greatly simplify TG deployment obviously, no matter if it's about having a build server or not.

Looking at SG/FG, the best option seems to be to use cmake's cpack support to create packages: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators

saiarcot895: I think I can help here.
Part of the work may have been already done. We are distributing simgear in two packages (since there are two libraries): libsimgearcore and libsimgearscene. libsimgearcore doesn't have any graphical dependencies; it only depends on libc6. libexpat, libgcc1, libstdc++6, and zlib1g. The only drawback here is that the -dev package includes headers for both libraries, which would require both libraries be installed. Would libsimgearcore be equivalent to the library produced by SIMGEAR_HEADLESS?
saiarcot895: I just uploaded the terragear package to my flightgear-edge PPA. It should be built and available in about 20-30 minutes for users of Ubuntu Precise, Quantal, and Trusty, but not Saucy (someone decided to place the Boost libraries on Saucy at a weird place, and so I get to find a fix to that). If you use Debian, I think you can download the debs for the Quantal version and use that.
Hooray: There seems to be a dependency issue regarding libtiff according to [1] ? --Hooray (talk) 19:15, 15 February 2014 (UTC)
saiarcot895: Already on it. I got another dependency issue with libgdal (apparently, they changed the development package name right after Precise). Flyhigh (talk) 21:10, 15 February 2014 (UTC)
Hooray: Would it be a lot of work to set up launchpad such that it also provides a debian wheezy (64bit) package ? That's what I am currently using - otherwise, I'd need to change some things here - so it depends on the amount of work involved obviously. Thanks for looking into it! --Hooray (talk) 04:09, 16 February 2014 (UTC)
saiarcot895: Sorry for the delay. The Launchpad PPAs are Ubuntu-only, but I can easily create deb files for Wheezy. It's just a matter of publishing it somewhere. Also, I might have a patch to send regarding having an explicit #include <std::string> line in a file. Something is different in Precise that an explicit #include is necessary. Also, I finally fixed the annoying bug in Saucy; it was actually a bug in CGAL having the incorrect Boost location in its config file. Flyhigh (talk) 16:14, 8 March 2014 (UTC)
saiarcot895: I've built simgear and terragear for the unstable/sid repo, and the packages are available at http://128.61.105.135/apt. To get it down to wheezy, however, I'll have to bump up (at least) OpenSceneGraph from unstable because wheezy still has 3.0. Flyhigh (talk) 15:30, 9 March 2014 (UTC)
Hooray: Sorry for not getting back to this earlier, thanks for the updates and all your work here. You raised a few good points - I am wondering if we can avoid the OSG issue in this particular instance for now, because we really only require the "headless" part of SimGear for TG, i.e. OSG should not even be required normally, right ? Otherwise, you're right that it would make sense to also provide deb packages for wheezy. But just for TG, I think, we don't need to touch any OSG related stuff ? --Hooray (talk) 16:13, 9 March 2014 (UTC)
saiarcot895: You're right, I forgot about that. I've built simgear (in headless mode) for unstable and will build it for testing (jessie) and stable (wheezy), and will build terragear for all three releases once simgear is done. This should be done in a few hours. Flyhigh (talk) 21:36, 10 March 2014 (UTC)
saiarcot895: Simgear for all releases is done, and Terragear for unstable is done. However, Terragear on testing failed with an error in a boost include saying uintptr_t wasn't found...which doesn't make sense to me since boost is from the main Debian archives. Flyhigh (talk) 00:28, 11 March 2014 (UTC)

TerraGear & TerraGear GUI (reeed)

this damned build server idea doesn't want to go away!

very quickly now, to get me up to speed:

  • is a hosting server available for our use right away? or who are the probable candidate(s)?
  • who maintains the latest, compileable and functional TerraGear?
  • Is the above TG packaged with Gijs' GUI? If not, which one is packaged?

TurnkeyLinux (Hooray)

WebService / UI (Gijs, Hooray, reeed )

Gijs:It'd be nicer/better to have a web interface. That'll allow you to keep the interface and backend in sync (without asking people to recompile/redownload the GUI om each change), save people from downloading yet another tool and make it work/look the same on all systems.

Hooray: As I mentioned on the forum, I am not at all opposed to having a webservice, I just consider it much more straightforward to modify TerraGear GUI for now. if there's anybody interested in working on a web interface that would obviously be great, but short of that, I would simply modify TerraGear GUI to support two modes local (default) and remote (build server) over SSH. I already looked at the code briefly and the main issue is the amount of Qt code that runs locally, i.e. to download stuff for example - if that could be moved out into external programs, preferably part of TerraGear itself, then it would be trivial to support both, local AND remote TG installations. Currently, there's just too much stuff directly done, without calling external tools - so that would need to be factored out.
Overall, the TerraGear GUI is not such a complex code base, so I am not sure if keeping the frontend/backends in sync is such a huge issue ?? I mean, people ALREADY need to have a matching TG/TGGUI versions after all ...
I am certainly not going to stop anybody from coming up with a webservice - it's just something that I am probably not going to work on anytime soon - while modifying TGGUI accordingly would just take a few hours and involve well-understood steps.
So I wasn't thinking of forking TGGUI, but more about extending it to support local AND remote installations - selected/configured during startup.
Obviously you are much more familiar with the code in question here - but based on what I've seen, it would not be such a difficult undertaking to turn TGGUI into a "remote control" for a TG build server setup.
If frontend changes are such an issue, I would actually suggest to get rid of the hardcoded GUI and use Qt's scripting support for those *.ui files instead - that would allow you to automatically download QtScript while booting.
Finally, coming up with a working web service is in my opinion more difficult than using SSH to teach TGGUI to run a handful of commands remotely and fetch the results via SFTP - so yeah, I am kinda lazy here

Standalone GUI (via SSH)

If the consensus should end up being not to use TerraGear GUI, the most straightforward option for coming up with a simple GUI would be Python using SSH and GUI bindings: