Tagged source tarball

[GoogleCodeExporter]

Could you please provide a tagged source tarball for download in the downloads 
section?  This is needed for meta distributions like Gentoo.

Original issue reported on code.google.com by matt...@gmail.com on 29 Mar 2012 at 3:07

[GoogleCodeExporter]

Yes, I can do that...

Can you provide me with a format of the name you'd like to see?
And for the compression, is gzip OK?

One more thing - usually I create all packages when things get somewhat stable, 
so this tarball will be subject to the same policy; I hope it is OK for you...
Kind regards,

Michal

Original comment by f.jo...@email.cz on 29 Mar 2012 at 5:24

• Changed state: Accepted
• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

This would be the best format for the tarball filename:

linuxtrack-[whatever version number].tar.bz2

gzip would also work but bzip would be preferable since it has better 
compression.  If it was gzip, then just change bz2 to gz.

All source files within the tarball should be in a directory with the same 
package name and version as the tarball filename just without the file 
extension of course:

linuxtrack-[whatever version number]

The version number is preferably a number separated by dots but if you needed 
to include a date or something after it like you're doing now for your zip 
files, that would not be a problem. In that case a format like this would be 
best:

linuxtrack-0.0_p20120229.tar.bz2 

Note that the additional date suffix should also be included in the directory 
that contains all the source files within the tarball like this:

linuxtrack-0.0_p20120229

File path would look like this after being untarred: 

linuxtrack-0.0_p20120229/AUTHORS
linuxtrack-0.0_p20120229/README
linuxtrack-0.0_p20120229/src/axis.c

... etc.

Once the tarball has been created, it should never be modified.  Only new ones 
should be created.  If anything has been changed in the tarball, the 
installation will fail because gentoo does md5 checksums on these files when it 
downloads them.  Also please keep a particular source tarball available for 
download for as long as you possibly can for stability.  Or at the very least, 
notify the package manager (by email or submit a bug on bugs.gentoo.org) that 
maintains the ebuild for linuxtrack that you are intending to remove an old 
tarball so that the package manager can perform a version bump on the ebuild 
before that happens.  Gentoo mirrors tarballs for packages once they make it 
into the portage tree but ultimately if the mirrors don't have them, then the 
package manager will look here for the tarball.

Thanks for the help!

Original comment by matt...@gmail.com on 29 Mar 2012 at 7:03

[GoogleCodeExporter]

In addition, it would make more sense to name the package portion linux-track 
instead of linuxtrack since the project name seems to be linux-track and not 
linuxtrack.

Original comment by matt...@gmail.com on 29 Mar 2012 at 7:21

[GoogleCodeExporter]

OK, will do that...
Right now, I'm waiting for a feedback on one bugfix, so when I have that sorted 
out, I'll upload a source tarball.
Thanks,

Michal

PS. I'll probably continue to use linuxtrack (without the hyphen), as I already 
use that for Ubuntu and Fedora packages. But thanks for pointing that out (and 
I hope it is not going to cause you problems)...

Original comment by f.jo...@email.cz on 29 Mar 2012 at 9:51

[GoogleCodeExporter]

linuxtrack without the hyphen will be fine.  It's just the difference between 
hardcoding linux-track in the source url vs using a built-in variable that 
stores the package name in the source url.

Original comment by matt...@gmail.com on 29 Mar 2012 at 10:02

[GoogleCodeExporter]

Looking over the package download folder, I'm not seeing tarball versioned 
source packages.  I'm only seeing binary builds.

Many source based distros (ie. Gentoo) require source snapshots/versions in 
order to integrate the project into their distribution.  Binaries are great, 
but binary distros (ie. Fedora) usually compile these in house can create their 
own packages.

(I'll look into this tomorrow for packaging for Gentoo, and using a TrackIR-5 
with FlightGear. ;-)

Original comment by rogerxx@gmail.com on 22 Oct 2013 at 5:58

[GoogleCodeExporter]

Hello,
I'll take a look - I should have the tarball on my machine, so I'll upload it.
One question though - maybe I'll upload it to my server, as google code is 
going to disable downloads alltogether. Anyway, I'll provide a link that you 
can use, that should not change in future.
Kind regards,

Michal

PS. Flightgear - may I ask you for a little help? A guy pointed me to better 
method to pass tracking data to flightgear, but my machine is not able to run 
it at all (Intel HD4000 GPU) - would you be so kind to try it out and let me 
know, how it goes? 

Original comment by f.jo...@email.cz on 22 Oct 2013 at 6:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sure. Just send a link, or whatever.  Those Intel HD integrated graphics are 
pretty amazing.  (I have one here, Intel i7 here, but I also use a NVIDIA 
card.)  Try switching the default aircraft from the default c172p aircraft 
model to the c172p-canvas aircraft model.  (ie. Or use the Win32 build)  
Another tip supposedly the UFO aircraft model will also work around any budgy 
nasal scripting, supposedly causing frame rate issues.  Anyways, mention what 
you need and I'll do my best with the time I have.

I'll probably start working on a Gentoo ebuild, and/or more seriously looking 
over the code tomorrow or the next day.  Build deps look pretty basic, so I 
shouldn't have many problems.  Just one package I don't recognize, but if 
needed, I'll package that one too.  (Quite amazing such a small device requires 
so much code!)

Original comment by rogerxx@gmail.com on 22 Oct 2013 at 9:36

[GoogleCodeExporter]

Well, last time I tried, I got only a black screen, that I had to kill, so not 
much tweaking was possible, but I'll try once again. Thank you for those tips...

Let me know, if you need any help in identifying dependences - from the top of 
my head, you are going to need gcc and g++ multilib (at least for 64 bit 
build), maybe gobjc, libusb1 (track ir & friends), libcwiid (wiimote), libv4l 
(webcam), opencv (facetracking), wine/wine64 and nsis (wine plugin) and of 
course Qt (for GUI). What might be a problem is XPlane SDK, which is needed for 
XPlane plugin compilation.

And last, but not least, when I get home, I'll post here a commandline I use to 
build the whole thing (unfortunately I wasn't able to automate some things, so 
you have to specify them through configure parameters).

Kind regards,

Michal

Original comment by f.jo...@email.cz on 22 Oct 2013 at 10:37

[GoogleCodeExporter]

Hello,
for the universal packages and the source tarball (I use .tar.bz2, I hope it 
doesn't complicate things too much for you), please go to 

http://linuxtrack.eu/repositories/universal/

Now for the compilation, I use this line:

./configure --with-xplane-sdk=/home/sbuilder/devel/SDK/CHeaders 
--enable-wine-plugin --enable-mickey 
--with-wine-libs="-L/usr/lib/i386-linux-gnu -L/usr/lib/i386-linux-gnu/wine" 
--with-wine64-libs="-L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64/wine"

This should allow you to build the complete thing... Let me know in case you'd 
need any help.
Kind regards,

Michal

Original comment by f.jo...@email.cz on 22 Oct 2013 at 9:05

[GoogleCodeExporter]

Interesting, built successfully and apparently very cleanly with the basic 
dependencies here on Gentoo, even without media-libs/opencv.  Seems like a lot 
of the previously mentioned isn't required.  (ie. libcwiid and opencv, and I 
need to do further reading to know exactly what I have and don't have built, 
and not waste time here.)

Per comment #2 here, matt was absolutely correct.

Source package releases should be similar to the following, as it's common 
practice or considered the standard within the open source community.

linuxtrack-0.99.6.tar.gz (or bzip2)
linuxtrack-0.99.6.zip (I believe even .zip maybe well supported by many package 
managers if you insist, but most within open source just publish a compressed 
gzip or bzip2 tarball.)
Should contain a sub-folder ./linuxtrack-0.99.6/ containing all sources.

linuxtrack-1.0.0-beta1.tar.gz
./linuxtrack-1.0.0-beta1/

... and so on.  From this point, package managers (or volunteers like me) can 
do their jobs for their Linux distribution, and provide the package manager 
script. (ie. SRPM for RedHat/Fedora, EBUILD for Gentoo, ...)  With this method, 
you won't have to necessarily build binaries.  Package managers for the distros 
can do this and simply report any problems to you, saving you time.

Although I don't mind creating CVS/SVN/GIT ebuilds for Gentoo, as it is a 
source based distro and this is one of the main features of Gentoo as a 
developer platform, some of the Gentoo developers frown upon any CVS/SVN/GIT 
ebuild within Gentoo.  Their reason, CVS/SVN/GIT builds are not suitable for 
users.  And in your case, having no stable source version to package usually 
leaves users with only a broken build when the CVS/SVN/GIT version breaks.  I 
tend to like to create both a stable ebuild and CVS/SVN/GIT ebuild, but even 
then trying to get those CVS/SVN/GIT ebuilds into Gentoo's Portage is a 
struggle.

I could probably package a dated snapshot of the CVS/SVN/GIT tree by date (ie. 
linux-track-20131022.tar.gz), but even those are difficult to get into the 
tree, as it's still based off of CVS/SVN/GIT, while you already do provide 
binaries by version.  (Not too also further mention the trouble of finding a 
hosting domain for the snapshot.)

Shrugs.  If you have the binary builds already, should probably have the 
version of source code used already packaged alongside the binary?

This is probably where Matt left off.

Original comment by rogerxx@gmail.com on 22 Oct 2013 at 9:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Per your edited previous response, I'm able to download the 
linuxtrack-0.99.6.tar.bz2.  Thanks.

I've encountered one error after using your configure script:
Making all in src/wine_bridge
make[2]: Entering directory 
`/home/roger/src/linux-track/linux-track-read-only/src/wine_bridge'
makensis ltr_wine64.nsi
make[2]: makensis: Command not found

Either a configure dependency check failure, or statically linked code location.

(Sure looks like configure forget to check for dev-util/nsis when configured to 
build the wine code!)

Anyways, I think I have the basic requirements for creating the Gentoo EBUILD 
for use with flightgear, and I do not have x-plane currently.  I surmise I'll 
likely create useflags (configure option) for xplane and wine.  (Something I'll 
need to research a little later.)

Matter of fact, I think I have more than enough of the basic requirements for 
creating a package, as I find the code builds well when looking at the amount 
of code. ;-)

Original comment by rogerxx@gmail.com on 22 Oct 2013 at 9:41

[GoogleCodeExporter]

Hello,
thank you for spotting that - I'll update the configure to handle these cases 
(I concentrated first on the make it work right, now I'll have to do something 
to make it fail right ;) )

At the end of the configure run, there is a short summary of what is going/not 
going to be built - without libcwiid there will not be Wiimote support, and 
missing OpenCV means no facetracking. And the error you encountered is due to 
missing dev-util/nsis (nullsoft installer generator), that is used to package 
linuxtrack-wine bridge files.

Now to the fact, that the universal package is a zip file - I wanted to package 
both the traball and the signature, so the user can verify authenticity. I can 
upload just the tar.bz2 file, it is not a problem.

As for the naming, I decided to abandon the beta and things like that - too 
much fuss between different distros; the naming of the source package will 
always be linuxtrack-X.X.X.tar.bz2 - at least I hope is should be OK for all 
distros. Also the package contains the linuxtrack-X.X.X directory, which I 
think should be OK too...

I wouldn't want to distribute repository snapshots - most distros doesn't have 
reasonable package rollback in case I screw something up, so I'd like only the 
stable version to be packaged. On the other hand, the universal packages are 
easy to switch back and forth (you can even have several version installed at 
the same time), so there it wouldn't be such a problem.

In case you find any problem with the package, naming, whatever, just let me 
know.
Kind regards,

Michal

PS. As for the amount of code - the part doing the tracking itself is only 
relative small fraction and it took only several months to make it work 
reasonable well; the GUI plus some bells and whistles (TIR firmware extraction) 
took the most of last 4 years.

PPS. Please note, that in order to have the TrackIR working, you need to 
extrack it from the NP's driver package and you need wine for that!
Kind regards,

Michal

Original comment by f.jo...@email.cz on 23 Oct 2013 at 5:21

[GoogleCodeExporter]

Some nice work.

After some research, I now see where the TrackIR program is headed, albeit, I'm 
an avid CLI user.  Really a nice little device, with lots of possibilities.

Original comment by rogerx....@gmail.com on 23 Oct 2013 at 7:14

[GoogleCodeExporter]

For history reference: See Gentoo Bug #489324 for an attached "work in 
progress" EBuild script for Gentoo's Portage package manager.

http://bugs.gentoo.org/show_bug.cgi?id=489324

TODO: Builds and installs, but needs significant clean-up.  Will likely provide 
a very good starting template for other package managers.

Original comment by rogerxx@gmail.com on 25 Oct 2013 at 1:58

[GoogleCodeExporter]

Hello,
that significant cleanup - you mean in the built result, or the ebuild script?

I took a look at the link; for the moment, the ltr_gui is integral part of the 
thing, that can't be left out without significant drawbacks for the user.

However, if there is a need, I don't have problem to make some cli friendly 
setup/firmware extraction/plugin installation etc. applications...

That said, at this moment I'm focusing on getting it into shape for 1.0 release.
When that is done, I'm free to implement anything.
Kind regards,

Michal

Original comment by f.jo...@email.cz on 25 Oct 2013 at 7:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes. The previous was just an FYI for others surfing and finding this via 
Google.

I was thinking, ltr_gui could be omitted during install if the user specified 
so with command line USE Flags (ie. configure --option) during install on 
Gentoo if he/she already has a configure file and already has the firmware 
extracted.  This would save them from installing the QT dependencies and, they 
were only using ltr_pipe.  (ie. TrackIR for virtual mouse, etc...)  I have a 
hunch the future may desire such a feature.

You did catch an error with my logic, I was starting to likely think the 
ltr_pipe was ltr_gui as I was writing the packaging script.  So likely there's 
a missing "configure --enable-ltr-gui", for building without QT dependencies.

With this stated however, I do think most users will just build with the QT 
libraries (or include ltr_gui) as resources are quite abundant (for now ;-).  
On the flip, what if there are TrackIR devices for limited resource platforms 
such as mobile devices and somebody wants to build their favorite distro on it?

At this point, I think a developer or platform engineer would desire omitting 
the large QT libraries, and just package a static config file, along with 
bundled firmware.  (Just a thought here.)

BTW, the only blip in config.log about QT/qt is qtgui, so I presume the 
configure script should break on a missing qtgui and it doesn't.  Basically 
continues to build without building ltr_gui.  (Builds fine with 
=dev-qt/qtgui-4.8.4-r1 here on Gentoo.)

dev-libs/mini-xml & dev-qt/qtgui should be within a configure script, 
"--enable-ltr-gui", and then should check for the presence of the mini-xml & 
qtgui. ;-)

Original comment by rogerxx@gmail.com on 26 Oct 2013 at 1:27

[GoogleCodeExporter]

Hi,
I'm going to rewrite the configure.ac and check using pbuilder that it breaks 
if some vital part is missing... 

However, at this point, I wouldn't try to make it work without the Qt (ltr_gui, 
mickey, wii_server...). I understand the point, but I'd really like to get the 
1.0 out of the door, before doing such a deep cut. I'll keep it on my todo list 
for further development.

I'm thinking of comming up with some commandline tool, but there are 
situations, when it would be hard to do something without ltr_gui (GUI in 
general). For example troubleshooting tracking problems - single lightbulb in 
TrackIR's field of view can completely ruin the tracking and without seeing 
what the camera sees, you can't do much...Also tweaking sensitivities and 
similar things might be quite cumbersome (ltr_gui propagates changes directly 
to the clients, so you see the result in the realtime).

I know Qt is huge, but it has many benefits for me - especially its 
multiplatformness. However, if you know about a lightweight multiplatform GUI 
toolkit, please let me know and I'll take a look at it.
Kind regards,

Michal

Original comment by f.jo...@email.cz on 26 Oct 2013 at 11:04

[GoogleCodeExporter]

I agree about troubleshooting more then one infrared sources, such a a window 
in the background. :-/

However once a user has experienced this, they then usually know the symptoms 
and how the top level application will react when encountering a secondary 
reflective source or infrared source.  If the hardware is stationary inside, 
likely few problems will arise after initial installation.  However portable 
solutions will likely encounter this often.  Likely a simple OpenGL window (ie. 
glxgears) could be merrily integrated versus the entire QT GUI for 
troubleshooting.  Don't get me wrong, I find the QT linuxtrack interface 
fascinating, I'm more a GTK fan or lightweight CLI junky.

However, not complaining as QT's main asset is as a cross platform library.

... anyways.  Cheers!

Original comment by rogerxx@gmail.com on 27 Oct 2013 at 7:03

[GoogleCodeExporter]

Hello,
I absolutely understand your point and I'm going to look at that once things 
calm down after 1.0. 

As for GTK, I really tried (before I moved to Qt), but at the end I gave up. I 
spent two days working in glade to make the first GUI and I didn't manage to 
make it look right. Only then I tried Qt and had it done in two hours (just the 
GUI layout in designer). That, plus the portability and my urge to learn C++ 
pushed me over.

I don't want to join the GTK/Qt holy war, all I'm saying is, that it works for 
me.

The OpenGl window is something I though about too, but then there is the 
question of controls, plus all the other things that ltr_gui handles - I'll 
have to think about it.
Kind regards,

Michal

Original comment by f.jo...@email.cz on 27 Oct 2013 at 11:46

[GoogleCodeExporter]

Hi guys.

The linuxtrack GUi is Qt4 or Qt5?

Original comment by hectores...@gmail.com on 28 Oct 2013 at 7:40

[GoogleCodeExporter]

I'm building successfully with apparently QT4.  (=dev-qt/qtgui-4.8.4-r1)

Matter of fact, only QT4 seems to be within Gentoo's Portage (ie. package 
database), although I do see a dev-qt/qt3support-4.8.4, and I do have this 
installed too.

(Searching or grepping the config.log, config.log doesn't show anything for a 
qt/QT check.)

I would imagine I'm building with QT4 includes/libs.

Original comment by rogerxx@gmail.com on 28 Oct 2013 at 9:03

[GoogleCodeExporter]

I created Archlinux AUR package: https://aur.archlinux.org/packages/linuxtrack/

Original comment by hectores...@gmail.com on 28 Oct 2013 at 9:44

[GoogleCodeExporter]

I can't compile the new version. 0.99.7.1

This is the error:
checking for mxmlNewXML in -lmxml... no

Original comment by hectores...@gmail.com on 6 Nov 2013 at 3:51

[GoogleCodeExporter]

Hello,
linuxtrack(ltr_gui to be exact) requires mxml ( 
http://www.msweet.org/projects.php?Z3 ) to extract data needed for the wine 
plugin to work.
Currently the library is needed to compile the GUI, and the error surfaced with 
my current attempt to improve/prune/clean/... of the configure.ac .

In case you have the xmxl installed, can you check it does contain the function 
mxmlNewXML (use nm)?
Kind regards,

Michal

Original comment by f.jo...@email.cz on 6 Nov 2013 at 8:28

[GoogleCodeExporter]

Dependency =dev-libs/mini-xml-2.7-r1 (http://www.minixml.org/), and I myself 
last compiled fine against this version a week ago.  (Haven't tried recently 
though.)

Compiled using FEATURES="nostrip", should have something like this:

# nm /usr/lib64/debug/usr/bin/mxmldoc.debug  |grep mxmlNewXML
U mxmlNewXML

Original comment by rogerxx@gmail.com on 7 Nov 2013 at 2:00

[GoogleCodeExporter]

Hello,
I'm not sure, if it means the problem is solved or not...

However, you have to look for libmxml.so (my guess if /usr/lib64/libmxml.so); 
that should give you (you are right about the symbols):
#objdump -T libmxml.so | grep mxmlNewXML
00000000000082c0 g    DF .text  0000000000000075  Base        mxmlNewXML

Kind regards,

Michal

Original comment by f.jo...@email.cz on 7 Nov 2013 at 8:26

[GoogleCodeExporter]

The problem isn't solved.

My mxml library is provided by this package: 
https://www.archlinux.org/packages/community/x86_64/mxml/

$objdump -T /usr/lib/libmxml.so | grep mxmlNewXML
00000000000085b0 g    DF .text  0000000000000072  Base        mxmlNewXML

I attach the config.log.

This is the error in the config.log.

configure:16182: checking for mxmlNewXML in -lmxml
configure:16207: gcc -o conftest -march=core-avx-i -O2 -pipe -fstack-protector 
--param=ssp-buffer-size=4 -g -O2 -Wall -Wextra -Wshadow -Wfloat-equal -Wformat 
-Wformat-security          --param ssp-buffer-size=4 -fstack-protector 
-D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -O2 
-Wl,-O1,--sort-common,--as-needed,-z,relro conftest.c -lmxml   >&5
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/libmxml.so: 
undefined reference to `pthread_getspecific'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/libmxml.so: 
undefined reference to `pthread_key_create'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/libmxml.so: 
undefined reference to `pthread_once'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/libmxml.so: 
undefined reference to `pthread_setspecific'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/libmxml.so: 
undefined reference to `pthread_key_delete'
collect2: error: ld returned 1 exit status
configure:16207: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "LinuxTrack"
| #define PACKAGE_TARNAME "linuxtrack"
| #define PACKAGE_VERSION "0.99.7.1"
| #define PACKAGE_STRING "LinuxTrack 0.99.7.1"
| #define PACKAGE_BUGREPORT "http://code.google.com/p/linux-track/issues/list"
| #define PACKAGE_URL ""
| #define PACKAGE "linuxtrack"
| #define VERSION "0.99.7.1"
| #define YYTEXT_POINTER 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| /* end confdefs.h.  */
| 
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char mxmlNewXML ();
| int
| main ()
| {
| return mxmlNewXML ();
|   ;
|   return 0;
| }
configure:16216: result: no
configure:16221: error: in 
`/home/hector/archlinux/linuxtrack/src/linuxtrack-0.99.7.1':
configure:16223: error: Libmxml is needed for ltr_gui compilation!
See `config.log' for more details

Original comment by hectores...@gmail.com on 12 Nov 2013 at 3:26

Attachments:

• config.log

[GoogleCodeExporter]

Hello,
apparently the libmxml depends on pthreads, and for some reason it is not 
picked up...
I just checked a fix to repository (see 
http://code.google.com/p/linux-track/source/detail?r=780 , changes to 
configure.ac, then run autoreconf to apply)- can you try if it solves the 
problem?
Kind regards,

Michal

Original comment by f.jo...@email.cz on 12 Nov 2013 at 7:00

[GoogleCodeExporter]

checking for mxml.h... yes :-)

The r780 is Ok. You can create a tarball package?

Original comment by hectores...@gmail.com on 12 Nov 2013 at 7:34

[GoogleCodeExporter]

Thank you for the report. I'll create the tarball as soon as possible (I tried 
and for 64bit the wine plugin didn't build and I have to find out why).

One question for you - should I ping you somehow when a new version comes out? 
Or is there another mechanism for that?
Kind regards,

Michal

Original comment by f.jo...@email.cz on 13 Nov 2013 at 11:22

[GoogleCodeExporter]

You can send me an email if new version comes out.

Original comment by hectores...@gmail.com on 13 Nov 2013 at 2:29

[GoogleCodeExporter]

Will do...
The 0.99.8 is up at 
http://www.linuxtrack.eu/repositories/universal/linuxtrack-0.99.8.tar.bz2 .
Kind regards,

Michal

Original comment by f.jo...@email.cz on 14 Nov 2013 at 6:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Need the GNU Debugger to compile?

/bin/sh: gdb: command not found
/bin/sh: line 0: test: -gt: unary operator expected

How to disable the opencv libraries?

Original comment by hectores...@gmail.com on 14 Nov 2013 at 7:50

[GoogleCodeExporter]

Hello,
as for gdb, nothing asks for it, as far as I know... At least it is neither in 
configure, nor any of the makefiles. Where do you get that error?

As for OpenCV, pass empty OPENCV_LIBS and OPENCV_CFLAGS to configure...
Kind regards,

Michal

Original comment by f.jo...@email.cz on 14 Nov 2013 at 7:59

[GoogleCodeExporter]

I get the error in the make. 

Original comment by hectores...@gmail.com on 15 Nov 2013 at 2:41

[GoogleCodeExporter]

Hello,
I see now, it seems that qmake uses gdb during the build to obtain some index...
So given the fact, that ltr_gui is mandatory, it seems that gdb will have to 
become a dependency... Is that a problem?
Kind regards,

Michal

Original comment by f.jo...@email.cz on 15 Nov 2013 at 8:26

[GoogleCodeExporter]

Is not a problem. 

Original comment by hectores...@gmail.com on 15 Nov 2013 at 9:37

[GoogleCodeExporter]

A build time dependent for GDB is likely not a problem, as it's likely 
installed by most already compiling code.  And will only likely become a 
problem if it's a runtime dependency.

Original comment by rogerxx@gmail.com on 15 Nov 2013 at 10:02

[GoogleCodeExporter]

I'm pretty much sure the gdb is not needed at runtime.

Original comment by f.jo...@email.cz on 15 Nov 2013 at 10:17

[GoogleCodeExporter]

Ditto.

Original comment by rogerxx@gmail.com on 15 Nov 2013 at 10:26