This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 485652 (navit)

Summary: Review Request: navit - Car navigation system with routing engine
Product: [Fedora] Fedora Reporter: Fabian Affolter <mail>
Component: Package ReviewAssignee: Peter Lemenkov <lemenkov>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: awilliam, benjavalero, bugzilla-redhat, fedora-package-review, jima, kvolny, lemenkov, linuxguy123, notting, opensource, rhbugs, sanjay.ankur, seg, stefano.cavallari, taljurf, thomas.moschny, tuju, valent.turkovic, vijivijayakumar, zarko.pintar
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://navit.sourceforge.net/
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-22 13:31:07 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 468631    
Bug Blocks:    

Description Fabian Affolter 2009-02-15 18:14:37 EST
Spec URL: http://fab.fedorapeople.org/packages/SRPMS/navit.spec
SRPM URL: http://fab.fedorapeople.org/packages/SRPMS/navit-0.1.0-1.fc10.src.rpm

Project URL: http://navit.sourceforge.net/

Description:
Navit is  modular design is capable of using vector maps of various formats 
for routing and rendering of the displayed map. It's even possible to use 
multiple maps at a time.
The GTK+ or SDL user interfaces are designed to work well with touch screen 
displays. Points of Interest of various formats are displayed on the map.
The current vehicle position is either read from gpsd or directly from NMEA 
GPS sensors.
The routing engine not only calculates an optimal route to your destination,
but also generates directions and even speaks to you using speechd.

rpmlint output (just to post some more information):
[fab@laptop24 SRPMS]$ rpmlint navit-0.1.0-1.fc10.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

This package is not ready for a review because there are still some issues.  Some persons offers their help and with a bug report we can better track the way to make navit work.
Comment 1 Valent Turkovic 2009-05-22 07:50:25 EDT
I will help if I can with this package, how can I help?
Comment 2 Zarko (grof) 2009-05-27 07:02:57 EDT
Any progress here?

What issues?
Comment 3 Valent Turkovic 2009-06-03 10:45:18 EDT
Do you need some help?
Comment 4 Fabian Affolter 2009-06-08 05:49:42 EDT
I'm (and was) a bit short on time.  Several stuff needs to be patched. There are a lot of patches, see Debian patch tracking system [1], and these patches needs to be integrated. 


[1] http://patch-tracking.debian.net/package/navit/0.1.1.~svn2246-1
Comment 5 Adam Williamson 2009-06-09 20:22:24 EDT
The spec contributed by Fabian is clearly based on my Mandriva spec (see, for comparison, http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/navit/current/SPECS/navit.spec?view=markup ) - it would have been polite to acknowledge this in the submission, Fabian.

I have built my own modified version of my Mandriva package...

http://adamwill.fedorapeople.org/navit/navit-0.1.0-1.aw_fc11.src.rpm
http://adamwill.fedorapeople.org/navit/navit.spec

obviously it's similar to Fabian's.

I tried building current SVN today, but on Fedora 11 it crashes as soon as it has to render text to a map. I've reported this to upstream: http://trac.navit-project.org/ticket/379 . I can provide that build too, if anyone's interested.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Adam Williamson 2009-06-09 20:23:50 EDT
forgot to mention, mine has some improvements over Fabian's, like dropping .la files.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 7 Adam Williamson 2009-06-09 20:50:35 EDT
btw, I think the -devel package is bogus...the 'libraries' are just plugins, they shouldn't have been installed as shared libraries by navit in the first place. they should only contain .so files (not .so.0.0.0 and .so.0) and these should be in the main package(s).

I don't know why Fabian removed the split of different rendering engines from my package. The reason they were split is to reduce dependencies - if you roll them all together, as Fabian did, you have to have libqt4 installed to install navit even if you have no intention of ever using the QT renderer. ditto cegui etc.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 8 Fabian Affolter 2009-06-10 16:30:58 EDT
(In reply to comment #5)
> The spec contributed by Fabian is clearly based on my Mandriva spec (see, for
> comparison,
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/navit/current/SPECS/navit.spec?view=markup
> ) - it would have been polite to acknowledge this in the submission, Fabian.

Yes, your spec file provides some lines to the Fedora spec file, especially the patches.  

(In reply to comment #6)
> forgot to mention, mine has some improvements over Fabian's, like dropping .la
> files.

In my spec file the following line takes care about the .la files
find %{buildroot} -name '*.la' -exec rm -f {} ';'

as suggest in the Packaging guidelines.

(In reply to comment #7)
> btw, I think the -devel package is bogus...the 'libraries' are just plugins,
> they shouldn't have been installed as shared libraries by navit in the first
> place. they should only contain .so files (not .so.0.0.0 and .so.0) and these
> should be in the main package(s).

It's good to have versioned plugins ;-) I agree that they should go in the main packages.

> I don't know why Fabian removed the split of different rendering engines from
> my package. The reason they were split is to reduce dependencies - if you roll
> them all together, as Fabian did, you have to have libqt4 installed to install
> navit even if you have no intention of ever using the QT renderer. ditto cegui
> etc.

I can't remember why I did this...perhaps the reason is simple: Just misremember. My spec file is still in an early stage (see %file section). The intention was to build a working prototype and then do the cleaning.

Aout the map: I personally see no reason to include a sample map because this blow the package size up and have only gain for a few users.
Comment 9 Adam Williamson 2009-06-10 17:24:29 EDT
"Yes, your spec file provides some lines to the Fedora spec file, especially the
patches."

Well, yes, the fact that the comments and filenames are exactly the same was a bit of a giveaway ;). Also the fact that you took the string literal fix, which would usually never be noticed on Fedora because it's set to be a warning, not an error as it is in Mandriva.

"In my spec file the following line takes care about the .la files
find %{buildroot} -name '*.la' -exec rm -f {} ';'"

Ah, sorry, missed that bit.

"It's good to have versioned plugins ;-)"

Not sure if you're serious or not there...there's usually no point versioning 'libraries' that are really private plugins for a certain app, because there's just no use case for it. I should ask upstream for clarification there.

"Aout the map: I personally see no reason to include a sample map because this
blow the package size up and have only gain for a few users."

I like including it because, if you don't, if you run navit with a default configuration, you see...nothing. It looks like the app's broken. At least with the default map, when you run Navit with a default configuration, you see something, you know it works.

(Does current SVN work for you, btw? I'd be interested to know.)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 Patrick Laughton 2009-06-11 13:29:50 EDT
Is my environment screwed up, or is autopoint looking for `cvs` during the build process?  I've tried both of your SRPMs to the same result.  Adding a BR leads to some sort of automake fun.  Am I missing something?
Comment 11 Adam Williamson 2009-06-11 15:52:19 EDT
I hadn't tried it in mock, so it's possible, but it builds on Mandriva's buildsystem (which uses clean chroots), so...

just a sec, I'll try it in mock here.

Hmm, you're right. Will investigate.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 12 Valent Turkovic 2009-06-18 08:59:50 EDT
When you manage to fix your current issues and build packages if you need somebody to test it I'm your man ;)
Comment 13 Patrick Laughton 2009-06-18 11:13:31 EDT
I'm waiting on this to test OSM data, myself. :-)
Comment 14 Adam Williamson 2009-06-18 13:20:07 EDT
I just added a BuildRequires: cvs , built it in mock, and it worked fine. Updated package coming in a minute.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 15 Adam Williamson 2009-06-18 14:07:32 EDT
Here's a new build with the CVS buildrequire added, and a patch to build the plugins properly (not versioned). Upstream has adopted a version of the plugin build patch. Also, an upstream dev is currently working on the crash I've seen in current SVN, so we may be able to package SVN instead soon.

http://adamwill.fedorapeople.org/navit/navit-0.1.0-3.aw_fc12.src.rpm
http://adamwill.fedorapeople.org/navit/navit.spec

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 16 Adam Williamson 2009-06-18 16:47:09 EDT
With the kind assistance of Martin Schaller from upstream, we've tracked the problem with current SVN down to a problem in freetype. It works if you rebuild freetype with -fno-strict-aliasing . I'll take this up with the freetype maintainer...once we get that solved, we ought to be able to do a package for current SVN instead of the old 0.1.0.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Adam Williamson 2009-06-18 17:02:25 EDT
my latest SVN .src.rpm is up at http://adamwill.fedorapeople.org/navit/navit-0.1.1-0.1.2347.aw_fc12.src.rpm , btw. If you rebuild freetype with -fno-strict-aliasing, you can even use it. :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Adam Williamson 2009-07-15 01:39:08 EDT
Since the reports of the freetype bug don't seem to be drawing much of a response, I've built a new package, with a workaround:

http://adamwill.fedorapeople.org/navit/navit-0.1.1-0.1.2395.aw_fc12.src.rpm
http://adamwill.fedorapeople.org/navit/navit.spec

it contains a patch that just disables freetype caching entirely in the offending code. This was suggested as a diagnostic technique by Martin Schaller, with the caveat that it will significantly reduce font rendering performance, but since it seems to perform OK on my (admittedly rather fast) system and our only other options are 'package nothing' or 'package something really old', I feel comfortable advocating this as the best choice to go with.

The package isn't entirely ready yet - I haven't given it a changelog yet and I haven't rpmlinted it, it may still be a bit rough - but it works, here.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 19 Callum Lerwick 2009-07-15 14:28:01 EDT
I'd really like to try this, but trying to build on F11 results in:

autoreconf: running: aclocal 
autoreconf: configure.in: tracing
autoreconf: configure.in: not using Libtool
autoreconf: running: /usr/bin/autoconf
configure.in:175: error: possibly undefined macro: AC_ENABLE_SHARED
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:176: error: possibly undefined macro: AC_DISABLE_STATIC
configure.in:183: error: possibly undefined macro: AC_DISABLE_SHARED
configure.in:184: error: possibly undefined macro: AC_ENABLE_STATIC
configure.in:187: error: possibly undefined macro: AC_PROG_LIBTOOL
autoreconf: /usr/bin/autoconf failed with exit status: 1
error: Bad exit status from /var/tmp/rpm-tmp.Jzcc2w (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.Jzcc2w (%build)

Help please? :)
Comment 20 Adam Williamson 2009-07-15 17:15:26 EDT
I'm possibly missing a build dependency...check if 'libtool' is installed.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Callum Lerwick 2009-07-16 00:55:51 EDT
Ah, I was indeed missing libtool. Got it built, and got it working, but it's configuration is a bit awkward. (Hand editing XML?) Haven't tried it with GPS yet.
Comment 22 Adam Williamson 2009-07-29 14:43:04 EDT
update: the freetype issue is being addressed (there's a patch that's in F11 now and has gone upstream, rawhide will get it in the next upstream freetype release). I'll send an updated build from the latest SVN snapshot with caching enabled again and the spec cleaned up, once that hits Rawhide.

Callum, yeah, the configuration is still fairly raw - navit is still a fairly alpha app in some ways, but it's already better than any available alternatives in several ways.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 23 Linuxguy123 2009-08-02 13:01:04 EDT
I'd just like to say that I too would like to see Navit on Fedora via rpms.    I am sure many other people will use navit on Fedora once they realize its available. 

Thank you to those that are working on this.
Comment 24 Adam Williamson 2009-08-03 00:26:05 EDT
I'm hoping to have a polished, review-ready package submitted as soon as the new freetype build hits rawhide (actually it may have done already, I'll check and work on this on Tuesday; I'm off Monday, it's a public holiday here).

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 25 Linuxguy123 2009-08-03 13:56:01 EDT
Will navit build against F11 ?  

Any chance that it could be submitted to F11/unstable or testing for those of us not working with F12 ?

Thanks
Comment 26 Adam Williamson 2009-08-03 15:47:09 EDT
actually the freetype fix was submitted to f11 before it went to rawhide, so f11 is ahead there. If you're really impatient to just get it working, you can grab the .src.rpm from comment #17 and build it. It should work fine. You may need freetype from updates-testing, not sure if it was pushed to stable yet.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 27 Adam Williamson 2009-08-07 19:35:16 EDT
OK, here's a new package. This one's actually review-ready: it has a changelog and passes rpmlint. I also cleaned up a few other bits and took out some commented-out stuff. This should be ready for review. If someone could do it, that'd be great. Thanks!

http://adamwill.fedorapeople.org/navit/navit-0.1.1-0.1.2431.aw_fc12.src.rpm
http://adamwill.fedorapeople.org/navit/navit.spec

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 28 Karel Volný 2009-08-19 10:05:51 EDT
(In reply to comment #27)
> http://adamwill.fedorapeople.org/navit/navit-0.1.1-0.1.2431.aw_fc12.src.rpm

just FYI, I did a koji scratchbuild: http://koji.fedoraproject.org/koji/taskinfo?taskID=1614676

after starting the application, the "Data" menu item is empty ... is that expected? - how do I load some larger map?
(er, if the answer is RTFM then just give me some time, I just had a quick peek, will take deeper look in a few days :-))
Comment 29 Adam Williamson 2009-08-19 12:30:03 EDT
RTFReadme :)

[adamw@adam ~]$ cat /usr/share/doc/navit-0.1.1/README.fedora
Navit comes with a sample map of Munich, but if you live (or drive!)
anywhere else, you'll need to add another map set. These are not
available as packages because they're rather large and the data changes
on a daily basis, so the packages would have to be refreshed very
often. For instructions on downloading or generating, and installing,
different types of map sets, see these Navit Wiki pages:

http://wiki.navit-project.org/index.php/OpenStreetMaps

http://wiki.navit-project.org/index.php/European_maps

http://wiki.navit-project.org/index.php/Garmin_maps

You should either add the appropriate configuration elements to
/etc/navit/navit.xml, or copy /etc/navit/navit.xml to
~/.navit/navit.xml and edit it there. You may have to remove or comment
out the section for the sample map set, also. Also note that the
default configuration assumes you have a GPS device active, and gpsd
running.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 30 Karel Volný 2009-08-20 12:47:37 EDT
soooo ...

(In reply to comment #29)
> http://wiki.navit-project.org/index.php/OpenStreetMaps

ok, this led me to downloading http://maps.navit-project.org/api/map/?bbox=-12.963867187500007,33.59619140625,34.1455078125,72.09228515625

> You should either add the appropriate configuration elements to
> /etc/navit/navit.xml,

so I did - I modified the template so it reads:

        <!-- Mapset template for openstreetmaps -->
        <mapset enabled="yes">
                <map type="binfile" enabled="yes" data="/var/local/osm_bbox_-13.0,33.6,34.1,72.1.bin"/>
        </mapset>

... needless to say that the file exists and is world readable

after starting navit, I still got the sample map, and the "Data" menu entry is empty

> You may have to remove or comment
> out the section for the sample map set, also.

ok, so let's try to disable it:

        <!-- If you dont want to use the sample map, either set enabled="no" in the next line or remove the xml file from the maps directory -->
        <mapset enabled="no">
            <xi:include href="$NAVIT_SHAREDIR/maps/*.xml"/>
        </mapset>

wov, now I can see the rest of the Europe, if I zoom out the map ... but still, the "Data" menu entry is empty ... OK, I'll go RTFM further ;-)

> Also note that the
> default configuration assumes you have a GPS device active, and gpsd
> running.

not a good default, IMO ...
Comment 31 Adam Williamson 2009-08-20 12:56:04 EDT
I'm not sure I've ever seen anything in the Data menu. I'm not entirely sure what it's for :)

The default may actually be different these days, I wrote the README for the Mandriva package back at version 0.1.0. I think it may not default to GPS mode any more, I'll have to check. Still, it would make a degree of sense, because it's specifically designed as a _navigation_ app, and that's not much use without GPS functionality. If you just want to look at maps there's better ways :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 32 Karel Volný 2009-08-21 06:09:28 EDT
(In reply to comment #31)
> The default may actually be different these days, I wrote the README for the
> Mandriva package back at version 0.1.0. I think it may not default to GPS mode
> any more, I'll have to check.

it spits out some error messages about not being able to communicate with gpsd, so it seems yes, it assumes that there should be GPS device

> Still, it would make a degree of sense, because
> it's specifically designed as a _navigation_ app, and that's not much use
> without GPS functionality. If you just want to look at maps there's better ways
> :)

well, route planning and review (that can be done before catching GPS signal) is quite important part of the navigation, and while navit does not seem to do this part well (yet?), what other better ways are there in Fedora? - you don't mean Firefox & http://maps.google.com, do you? :)
Comment 33 Hans Ulrich Niedermann 2009-08-21 11:33:44 EDT
I guess getting GPS position fixes from some GPS device into the computer and then distributed to local applications via gpsd or gypsy is an issue mostly orthogonal to a navit review.

As far as I can tell, setting up permissions for GPS devices and running gpsd is still a manual task on Fedora: https://fedoraproject.org/wiki/GIS/PositionFixes (corrections welcome)

So testing navit with gpsd might need manual work right now, but the existence of a navit package will make development of a plug and play gpsd solution so much more attractive that it will probably happen by itself :)
Comment 34 Adam Williamson 2009-08-21 11:45:34 EDT
I've already tested it with GPS input (from a Windows Mobile phone connected by USB, since I like having a complicated life...). It works very well. I used gpsd.

We were just discussing the defaults. Actually I think when I wrote that doc, navit would just throw its toys out of the pram by default if you ran it without a GPS device connected, whereas now it runs but just complains a bit at the console. So it's probably fine to leave the default.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 35 Linuxguy123 2009-08-24 16:28:52 EDT
I'm happy to see all the activity happening with regards to Navit.  Good work.

Has it been published to any repositories yet ?

Thanks !
Comment 36 Adam Williamson 2009-08-24 19:48:44 EDT
no, I'm still waiting for someone to officially approve it. You can grab the last .src.rpm I posted and rebuild it, though. It works fine.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 37 Till Maas 2009-09-17 05:25:17 EDT
The release needs to include some date, e.g. of the time you created the snapshot or ideally of the time the revision was commited:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages

You can add the revision after the svn string in the release, if you want:

0.2.20090917svn2431


The patch does not have an comment wrt the upstream status:
https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment

You should probably run desktop-file-validate:
https://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files

The snippets to update the icon cache are missing:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache

Btw. there is the string NotReady in the status whiteboard, which should be removed once this package needs some reviewer action, ie if above issues are fixed.
Comment 38 Adam Williamson 2009-09-17 13:39:04 EDT
the date guideline seems somewhat absurd as SVN revision is _more_ precise than date, but who am I to argue with guidelines. =) will fix those up soon.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 39 Jason Tibbitts 2009-09-17 14:26:47 EDT
But the SVN revision doesn't tell you anything about when the checkout was taken, which is information we are trying to capture here.  You are more than welcome to include the SVN revision as outlined in the guideline.
Comment 40 Adam Williamson 2009-09-17 14:47:17 EDT
it's the wrong place to argue the toss, and i'm going to change the package, but i can't resist =)

that's what I thought at first, then I thought 'no, that doesn't quite add up either'. after all, *non*-pre-release packages don't convey that information in their evr either. kernel-2.6.31-1.fc12 doesn't give you any information on when kernel 2.6.31 was released, does it? you have to go look that up somewhere else. SVN revision 123456 does give you date information just as conveniently as a version tag in a regular package does - all you have to do is go upstream and find out when that SVN rev hit.

anyway, yeah, it's not particularly on-topic here. just worries my consistency bone.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 41 Adam Williamson 2009-09-18 15:57:53 EDT
ok, updated build with above points addressed:

http://adamwill.fedorapeople.org/navit/navit.spec
http://adamwill.fedorapeople.org/navit/navit-0.1.2-0.1.20090918svn2578.aw_fc12.src.rpm

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 42 Till Maas 2009-09-21 08:48:29 EDT
%makeinstall should not be used, is it really needed here?
Reference: https://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall_macro_should_not_be_used

Source0: does not work here (404):
http://downloads.sourceforge.net/navit/navit-2578.tar.bz2
Comment 43 Adam Williamson 2009-09-21 11:00:39 EDT
it's probably just a hangover from the MDV package, I'll check whether it's needed.

Source0 is expected not to work, this is an SVN snapshot build. The SVN location is listed in a comment near the top of the spec. Guess I could add the tarball creation command too.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 44 Till Maas 2009-09-21 11:30:14 EDT
(In reply to comment #43)

> Source0 is expected not to work, this is an SVN snapshot build. The SVN
> location is listed in a comment near the top of the spec. Guess I could add the
> tarball creation command too.

Yes, this is also required by the guidelines. Because this comment was missing, I expected the svn snapshot to be created by upstream.
https://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control
Comment 45 Linuxguy123 2009-09-25 13:18:12 EDT
I'm happy to see that someone (Adam (et al ?)) are sticking with the effort to get navit into Fedora.  Good work.  Some of us really appreciate your efforts. Keep it up and post if you need help.
Comment 46 Adam Williamson 2009-09-25 13:41:31 EDT
updated with latest points from Till addressed:

http://adamwill.fedorapeople.org/navit/navit.spec
http://adamwill.fedorapeople.org/navit/navit-0.1.2-0.2.20090918svn2578.aw_fc12.src.rpm

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 47 Adam Williamson 2009-09-30 14:22:15 EDT
ping?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 48 Peter Lemenkov 2009-10-05 10:24:12 EDT
Adam, I suggest you to start another Review Request and close this as DUPLICATE. :)
Comment 49 Adam Williamson 2009-10-05 10:46:36 EDT
peter: um. why? there doesn't appear to be any process problem with handling it here, that I can see?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 50 Peter Lemenkov 2009-10-05 10:54:10 EDT
I thought that there will be some issues with rights for setting/unsetting fedora-flags. However, I'm not sure.
Comment 51 Adam Williamson 2009-10-05 11:05:09 EDT
I have supah cow powahz in Bugzilla, I can set any flags I like ;)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 52 Peter Lemenkov 2009-10-05 11:10:18 EDT
Heh, we'll see. :)
Comment 53 Linuxguy123 2009-10-13 19:48:29 EDT
Update, please ?

Thanks !
Comment 54 Peter Lemenkov 2009-10-18 06:47:44 EDT
Koji scratchbuild for F-11:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1752756

Ok, here is my

REVIEW:

+ rpmlint is almost silent:

[petro@Sulaco Desktop]$ ls navit-*
navit-0.1.2-0.2.20090918svn2578.fc11.ppc.rpm  navit-debuginfo-0.1.2-0.2.20090918svn2578.fc11.ppc.rpm  navit-graphics-qt-0.1.2-0.2.20090918svn2578.fc11.ppc.rpm  navit-graphics-sdl-0.1.2-0.2.20090918svn2578.fc11.ppc.rpm
[petro@Sulaco Desktop]$ rpmlint navit-*
navit-graphics-qt.ppc: W: no-documentation
navit-graphics-sdl.ppc: W: no-documentation
4 packages and 0 specfiles checked; 0 errors, 2 warnings.
[petro@Sulaco Desktop]$

These two warnings can be safely ignored.

+ The package is named according to the Package Naming Guidelines .
+ The spec file name matches the base package %{name}, in the format %{name}.spec unless your package has an exemption.

+/- The package meets the Packaging Guidelines, except the following

1. The package contains *.la files. Please, remove them.
2. You dont use parallel make - please, add not, that this package can't be build with parallel make or enable it.
3. I advice you to provide README.Fedora as the Source{X}, instead of creating it in spec. Since it doesn't contain mutable parts (such as %{libdir}), then no need to create every rebuild (this also reduces size of spec to review).
4. I don't fully understand what is "graphics" and how it differs from "gui" and "osd" (which also GUI, if I understood correctly). Could you, please, explain what is it?
5. The package doesn't own /etc/navit dir. See note below.

+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines .
+ The License field in the package spec file matches the actual license.

- MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. Please, add the following files as %doc:

COPYING
COPYRIGHT
GPL-2
LGPL-2

+ The spec file is written in American English.
+ The spec file for the package is legible.
+ The sources used to build the package matches the upstream source. I cannot compare with md5sum/sha256sum, but after diffing I found no changes (except in one datafile).
+ The package successfully compiles and builds into binary rpms on at least one primary architecture. See koji link above.
+ All build dependencies are listed in BuildRequires.
+ The spec file handles locales properly. This is done by using the %find_lang macro.

- The package must NOT bundle copies of system libraries. Unfortunately, navit contains large parts from some packages, available in Fedora. Please, remove them before building (at %prep stage). Namely:

* 'navit/support' directory is full of duplicated libraries.
* 'navit/map/shapefile' contains parts of shapelib
* 'navit/map/poi_geodownload' contains mdbtools
* it also contains librafy for operations with fibonnaci numbers under 'navit/fib-1.1' directory, but it seems that it wasn't included in Fedora yet, so it's safe to keep it.

- The package must own all directories that it creates. Please, add /etc/navit as %dir.
+ The package does not list a file more than once in the spec file's %files listings.
+ Permissions on files are set properly.
+ The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ The package consistently uses macros.
+ The package contains code, or permissible content.
+ Anything, the package includes as %doc, does not affect the runtime of the application.

- The package must NOT contain any .la libtool archives. See my note above.

+ The package includes a %{name}.desktop file.
+ The package does not own files or directories already owned by other packages.
+  At the beginning of %install, the package runs rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ All filenames in the package are valid UTF-8.

Please, fix/comment my notes, and I'll continue.
Comment 55 Peter Lemenkov 2009-10-23 06:00:18 EDT
Ping, Adam.
Comment 56 Adam Williamson 2009-10-26 16:51:58 EDT
i'm ridiculously busy with f12 release right now, have no time to work on this. but i acknowledge your remarks and will see if I can do anything about fixing them once I have spare time again.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 57 Linuxguy123 2009-10-27 12:36:36 EDT
I'm happy to hear that navit hasn't been abandoned/forgotten.   Keep at it, guys  !
Comment 58 Adam Williamson 2009-11-26 16:36:31 EST
OK, I'm looking at the external libraries now. None of the stuff in support/ is actually used. The configure script properly checks for system-wide copies of all those libraries before using the internal copies; they're just there for platforms where systemwide copies aren't available (like WinCE, for instance). you can see this happening in configure.in , and if you run a build of navit in mock and kill it halfway through, you can see that the SUBDIRS variable in navit/navit/support/Makefile is empty.

I can stick something in %prep to remove this subdirectory, but I'm not sure anything in the guidelines actually requires that, and I'm reluctant to do anything in the spec file which is not actually necessary to the build or required by the guidelines - can you cite a specific point in the guidelines that requires this kind of thing to actually be *removed* prior to build?

On the shapefile stuff, I see what you mean. I'm not getting very far trying to hack it up to build against the system shapefile instead. I'll try and get help from upstream with that.

just a note that I'm working on it...

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 59 Adam Williamson 2009-12-11 14:47:22 EST
I did file an upstream ticket:

http://trac.navit-project.org/ticket/508

no reply yet :(

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 60 Karel Volný 2010-02-23 08:37:38 EST
(In reply to comment #59)
> I did file an upstream ticket:
> 
> http://trac.navit-project.org/ticket/508
> 
> no reply yet :(

just a note, the ticket got assigned meanwhile

it has milestone 0.2.0, but I'm unable to find any release schedule ... however, Trac Roadmap says 53% complete, more than half, woohoo :-)
Comment 61 Valent Turkovic 2010-03-07 09:36:40 EST
When can we expect Navit to be released in Fedora repos? This is a great application and would make a great addition to Fedora GPS apps.
Comment 62 Adam Williamson 2010-03-07 11:17:13 EST
I can't tell you, because I'm waiting on the upstream ticket discussed above.

If you can contribute code that would address the use of built-in copies of shared libraries, that would let me do it faster. I'm not a coder, I can't do it.
Comment 63 Valent Turkovic 2010-05-06 11:23:48 EDT
Isn't there a reply in upstream ticket?
Comment 64 Adam Williamson 2010-05-21 16:02:49 EDT
Indeed. Sorry for the late follow-up, I've been busy with F13.

http://adamwill.fedorapeople.org/navit/navit.spec
http://adamwill.fedorapeople.org/navit/navit-0.1.2-0.3.20100521svn3291.aw_fc12.src.rpm

new build. Current SVN, with fixes for the identified problems with system-wide resources: as mentioned on the upstream ticket, it now uses system shapelib, and mdbtools usage has been removed.
Comment 65 Linuxguy123 2010-06-17 10:23:54 EDT
Could you do a similar build for F13 ?  I'll test it if you do.

Thanks
Comment 66 Peter Lemenkov 2010-07-19 05:07:18 EDT
Ok. summarizing of what should be done:

* Interestingly, it fails to build on F-14 but builds fine on F-13:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2328357 (F-14)
http://koji.fedoraproject.org/koji/taskinfo?taskID=2328369 (F-13)

This must be fixed.

* rpmlint isn't silent:

work ~/Desktop: rpmlint navit-*
navit.i686: W: spelling-error %description -l en_US gpsd -> gypsy, Gypsy, gypsum
navit.i686: W: incoherent-version-in-changelog 0.1.2-0.2.20090918svn2578 ['0.1.2-0.3.20100521svn3291.fc13', '0.1.2-0.3.20100521svn3291']
navit.i686: W: no-manual-page-for-binary navit
navit.i686: W: no-manual-page-for-binary maptool
navit-graphics-qt.i686: W: spelling-error %description -l en_US xml -> XML, cml, ml
navit-graphics-qt.i686: W: no-documentation
navit-graphics-sdl.i686: W: spelling-error %description -l en_US xml -> XML, cml, ml
navit-graphics-sdl.i686: W: no-documentation
4 packages and 0 specfiles checked; 0 errors, 8 warnings.
work ~/Desktop: 

Don't forget to add proper %%changelog entry for every src.rpm version bump. All other messages should be discarded

* The package contains *.la files. Please, remove them.
* You dont use parallel make - please, add note, that this package can't be
build with parallel make or enable it.
*. I advice you to provide README.Fedora as the Source{X}, instead of creating
it in spec. Since it doesn't contain mutable parts (such as %{libdir}), then no
need to create every rebuild (this also reduces size of spec to review).  Not a blocker - feel free to reject/ignore this particular advice.
* The package doesn't own /etc/navit dir.
* Please, add the following files as %doc:

COPYING
COPYRIGHT
GPL-2
LGPL-2

* navit still contains large parts from some packages, available in Fedora. Please, remove them before building (at %prep stage). Namely:

'navit/support' directory is full of duplicated libraries.
'navit/map/shapefile' contains parts of shapelib
'navit/map/poi_geodownload' contains mdbtools
it also contains librafy for operations with fibonnaci numbers under 'navit/fib-1.1' directory, but it seems that it wasn't included in Fedora yet,
so it's safe to keep it.
Comment 67 Peter Lemenkov 2010-07-19 05:08:56 EDT
Oops! Please, disregard my comment about "mdbtools" - this was a copypaste typo
Comment 68 Adam Williamson 2010-07-19 10:29:39 EDT
we already dealt with all the shared resources, AFAIK. I'll look at the other stuff in a bit.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 69 Mamoru TASAKA 2010-07-30 06:36:44 EDT
Just a note:

(In reply to comment #66)
> Ok. summarizing of what should be done:
> 
> * Interestingly, it fails to build on F-14 but builds fine on F-13:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2328357 (F-14)
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2328369 (F-13)

gpsd of F-14 one and F-13 one have some big difference.
ref:
https://bugzilla.redhat.com/show_bug.cgi?id=556642
http://lists.fedoraproject.org/pipermail/devel/2010-April/135395.html
Comment 70 Tareq Al Jurf 2010-09-06 09:53:19 EDT
Any update?
Comment 71 Adam Williamson 2010-09-08 08:39:12 EDT
sorry, I just don't seem to find much time for packaging stuff these days :/ it may be better to let someone else take over the package, even.
Comment 72 Mamoru TASAKA 2010-09-22 13:13:27 EDT
What is the status of this bug?
Comment 73 Peter Lemenkov 2010-09-22 13:17:13 EDT
(In reply to comment #72)
> What is the status of this bug?

FE-DEADREVIEW, I'm afraid.
Comment 74 Adam Williamson 2010-09-22 13:28:50 EDT
the status is that i'm busy and didn't have time to get back to it yet.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 75 Mamoru TASAKA 2010-09-22 13:31:07 EDT
Okay, once closing as NOTABUG.

If someone wants to import this package into Fedora, please open
a new review request and mark this one as a duplicate of the
new one, thank you.
Comment 76 viji 2010-11-17 06:20:26 EST
Taking over this, will be filing a new review request by EOD.

So far tested the build with Fedora 13 and 14, everything looks great.
Comment 77 Jason Tibbitts 2010-11-17 13:12:31 EST

*** This bug has been marked as a duplicate of bug 654374 ***