Debian / Ubuntu Packages
Christian Vetter
David suggested on the OpenStreetMap mailing list that it would be
better to use official Debian / Ubuntu packages instead of offering
our own. He is currently the maintainer[1] of the Debian packages and
would also create 0.3 ones. I would suggest we mirror/link them as
soon as they are available. What do you think?
Regards,
Christian Vetter
Christoph Eckert
> David suggested on the OpenStreetMap mailing list that it would be
> better to use official Debian / Ubuntu packages instead of offering
> our own. He is currently the maintainer[1] of the Debian packages and
> would also create 0.3 ones. I would suggest we mirror/link them as
> soon as they are available. What do you think?
even better, as we could get rid of my rather hackish binary only packages.
Just let me know as soon the packages are ready, so I can remove the ones I
created.
--
Beste Grüße,
Best regards,
ce
David Paleino
Debian already has 0.2 SVN 405, which is blocked in unstable because I think
it's not too ready to go in testing :)
I already wrote to Christian about the monav-0.3.tar.gz tarball (I'm having
issues unpacking it).
If nothing bad happens (i.e. license issues for new files, or the like), the
new package will take around 10-30 minutes to be prepared and uploaded
(necessary changes, compilation, testing, upload).
Since Ubuntu is currently frozen, I can't request a sync there. So we could
either wait for Natty to be released (soonish), or I could test the package on
a Natty chroot and report whether the Debian package works as-is. If not, I can
prepare an Ubuntu revision to offer alongside the Debian one.
Kindly,
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
David Paleino
> Hi,
>
> David suggested on the OpenStreetMap mailing list that it would be
> better to use official Debian / Ubuntu packages instead of offering
> our own. [..]
MoNav 0.3 is in sid:
http://packages.qa.debian.org/m/monav/news/20110423T180419Z.html
It might take a while before all architectures get built, but I uploaded i386,
and amd64 should be there by tomorrow, if no problem arises.
Enjoy,
Christian Vetter
It seems that there is a problem with the patches you apply to MoNav:
03-dont_embed_resources:
Several Qt slots have been renamed and the patch still contains old names.
01-fix_build_issues:
Are you sure you need to add Qt GUI modules? I think i fixed all gui
dependencies a while ago. Did you append CONFIG+=nogui to the qmake
command line for the console applications? If build issues still
persist, could you send me the build errors?
02-toll-booth_routing:
This hack is probably not the right way to do it, since you are
forcing the decision on the user. Add another speed profile with a
node modifier that sets access=true for toll_booth if you want to give
the user the option to route through toll booths.
Regards,
Christian
David Paleino
> Hi,
Hello,
> It seems that there is a problem with the patches you apply to MoNav:
>
> 03-dont_embed_resources:
> Several Qt slots have been renamed and the patch still contains old names.
Uhm. I was sure I cleaned that up. The only remaining fix was gotoGPS →
gotoGPSLocation. Fixed that, thanks :)
http://git.debian.org/?p=pkg-osm/monav.git;a=commitdiff;h=bdc035161d81db7764af9f192ca8eefef90dd7cd
> 01-fix_build_issues:
> Are you sure you need to add Qt GUI modules? I think i fixed all gui
> dependencies a while ago. Did you append CONFIG+=nogui to the qmake
> command line for the console applications? If build issues still
> persist, could you send me the build errors?
Why isn't CONFIG=nogui the default for console-applications? (routing daemon,
preprocessor, packager) :)
By the way, routingdaemon fails to compile:
g++ -o ../bin/monav-daemon main.o LzmaDec.o directoryunpacker.o qtservice.o
qtservice_unix.o qtunixsocket.o qtunixserversocket.o moc_routingdaemon.o moc_qtunixsocket.o moc_qtunixserversocket.o -L/usr/lib -L../bin/plugins_client -lcontractionhierarchiesclient -lgpsgridclient -lQtNetwork -lQtCore -lpthread
contractionhierarchiesclient.cpp:56: error: undefined reference to
'QMessageBox::information(QWidget*, QString const&, QString const&, QFlags<QMessageBox::StandardButton>, QMessageBox::StandardButton)'
gpsgridclient.cpp:62: error: undefined reference to
'QInputDialog::getInt(QWidget*, QString const&, QString const&, int, int, int, int, bool*, QFlags<Qt::WindowType>)'
collect2: ld returned 1 exit status
make[2]: *** [../bin/monav-daemon] Error 1
make[2]: Leaving directory `/home/neo/deb/git/pkg-osm/monav/routingdaemon'
make[1]: *** [sub-routingdaemon-make_default] Error 2
make[1]: Leaving directory `/home/neo/deb/git/pkg-osm/monav'
(I'm adding CONFIG+="debug nogui")
> 02-toll-booth_routing:
> This hack is probably not the right way to do it, since you are
> forcing the decision on the user. Add another speed profile with a
> node modifier that sets access=true for toll_booth if you want to give
> the user the option to route through toll booths.
Uhm, I believe that routing across toll booths is rather common, so it probably
should go upstream. Would you accept a new speed profile "motorcar with toll
booths"? Or maybe modify the existing one?
Thanks for your mail,
Christian Vetter
On Tue, Apr 26, 2011 at 9:03 AM, David Paleino <da...@debian.org> wrote:
> On Mon, 25 Apr 2011 23:52:15 +0200, Christian Vetter wrote:
>
> Why isn't CONFIG=nogui the default for console-applications? (routing daemon,
> preprocessor, packager) :)
Because qmake fails to pass variables defined in project files to
subtargets, you have to add it on the command line.
>
> By the way, routingdaemon fails to compile:
>
> (I'm adding CONFIG+="debug nogui")
Have you added it to the command line call of qmake or to the project file?
> Uhm, I believe that routing across toll booths is rather common, so it probably
> should go upstream. Would you accept a new speed profile "motorcar with toll
> booths"? Or maybe modify the existing one?
I think you're right, we should include a new speed profile for that
use case in the next release.
Regards,
Christian
David Paleino
> On Mon, 25 Apr 2011 23:52:15 +0200, Christian Vetter wrote:
>
> > It seems that there is a problem with the patches you apply to MoNav:
> >
> > 03-dont_embed_resources:
> > Several Qt slots have been renamed and the patch still contains old names.
>
> Uhm. I was sure I cleaned that up. The only remaining fix was gotoGPS →
> gotoGPSLocation. Fixed that, thanks :)
>
> http://git.debian.org/?p=pkg-osm/monav.git;a=commitdiff;h=bdc035161d81db7764af9f192ca8eefef90dd7cd
And:
http://git.debian.org/?p=pkg-osm/monav.git;a=commitdiff;h=781039404a40b578b83666fa7a3347057784ab6d
since I missed it again. :/
David Paleino
> Hi,
>
> On Tue, Apr 26, 2011 at 9:03 AM, David Paleino <da...@debian.org> wrote:
> > On Mon, 25 Apr 2011 23:52:15 +0200, Christian Vetter wrote:
> >
> > Why isn't CONFIG=nogui the default for console-applications? (routing
> > daemon, preprocessor, packager) :)
>
> Because qmake fails to pass variables defined in project files to
> subtargets, you have to add it on the command line.
>
> [..]
>
> Have you added it to the command line call of qmake or to the project file?
To the command line call of qmake.
I didn't commit the change because it didn't work, but I changed lines 20, 22
and 23 to read:
qmake CONFIG+="debug nogui" [..]
Thanks,
Christian Vetter
Do you build the GUI and non-GUI applications in the same directory
without deleting the plugins in between? The console applications
build non-GUI version of the plugins, maybe you are trying to link
against existing builds from the GUI applications?
Regards,
Christian
David Paleino
> Do you build the GUI and non-GUI applications in the same directory
> without deleting the plugins in between? The console applications
> build non-GUI version of the plugins, maybe you are trying to link
> against existing builds from the GUI applications?
Aha! That's probably it. I'll try, and let you know.
David Paleino
> Do you build the GUI and non-GUI applications in the same directory
> without deleting the plugins in between? The console applications
> build non-GUI version of the plugins, maybe you are trying to link
> against existing builds from the GUI applications?
It worked indeed.
Thanks :)
Christian Vetter
Is there a reason the package is compiled in debug mode? Usually debug
mode should be several times slower when compared to release mode,
especially for the preprocessor ( up to a factor 10 ).
Regards,
Christian Vetter
Christian Vetter
On Thu, Apr 28, 2011 at 9:27 PM, David Paleino <da...@debian.org> wrote:
> On Thu, 28 Apr 2011 21:08:14 +0200, Christian Vetter wrote:
> I wanted to provide, in a near future, a monav-dbg package, containing debugging
> symbols, so that in case of a crash the user doesn't need to recompile the
> package to activate them.
Makes sense.
> This sounds odd. How come is it so? AFAICT, "debug mode" generally enables more
> messages to the console, and such. I haven't checked what it exactly does in
> MoNav, but a 10x slowdown seems odd.
Since the algorithm used in MoNav are quite complex a lot of sanity
checks are performed in the debug mode. Furthermore, the difference of
compiling a program which heavily relies on template usage with -O0
and -O3 is huge. Of course this is only noticeable when preocessing
larger amounts of data, but thats excactly what MoNav does. Removing
the sanity checks would account for a slowdown of about factor 3, the
rest is compiler optimization. IIt would be best to compile MoNav in
release mode and add debug symbols to that.
>
> It's common for Debian packages to enable it, and then strip debugging symbols
> off the binaries.
> However, I have no problem in disabling it -- still, if the slowdown is
> somehow solvable, I'd prefer keeping/re-enabling it later on.
Compiling in debug mode and adding debug symbols isn't quite the same
*g*. I believe most Debian applications are compiled with compiler
optimizations. QMake on the other hand turns of all optimizations in
the debug mode, it is mainly there for developers to check and debug
their program. Wouldn't it suffice to pass "-g" to gcc and use
CONFIG+=release instead?
Regards,
Christian Vetter
David Paleino
> Hi,
Hello,
(why not a new thread? :))
> Is there a reason the package is compiled in debug mode?
I wanted to provide, in a near future, a monav-dbg package, containing debugging
symbols, so that in case of a crash the user doesn't need to recompile the
package to activate them.
> Usually debug mode should be several times slower when compared to release
> mode, especially for the preprocessor ( up to a factor 10 ).
This sounds odd. How come is it so? AFAICT, "debug mode" generally enables more
messages to the console, and such. I haven't checked what it exactly does in
MoNav, but a 10x slowdown seems odd.
It's common for Debian packages to enable it, and then strip debugging symbols
off the binaries.
However, I have no problem in disabling it -- still, if the slowdown is
somehow solvable, I'd prefer keeping/re-enabling it later on.
Comments?
Kindly,
David Paleino
> On Thu, Apr 28, 2011 at 9:27 PM, David Paleino <da...@debian.org> wrote:
> [..]
> > It's common for Debian packages to enable it, and then strip debugging
> > symbols off the binaries.
> > However, I have no problem in disabling it -- still, if the slowdown is
> > somehow solvable, I'd prefer keeping/re-enabling it later on.
>
> Compiling in debug mode and adding debug symbols isn't quite the same
> *g*. I believe most Debian applications are compiled with compiler
> optimizations.
Well, yes :)
> QMake on the other hand turns of all optimizations in the debug mode, it is
> mainly there for developers to check and debug their program. Wouldn't it
> suffice to pass "-g" to gcc and use CONFIG+=release instead?
Done so now.
I'll upload a new revision ASAP.
Have a nice day,
Christian Vetter
Thanks for all your work :-D
Regards,
Christian Vetter