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.
I will help if I can with this package, how can I help?
Any progress here? What issues?
Do you need some help?
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
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
forgot to mention, mine has some improvements over Fabian's, like dropping .la files. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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
(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.
"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
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?
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
When you manage to fix your current issues and build packages if you need somebody to test it I'm your man ;)
I'm waiting on this to test OSM data, myself. :-)
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
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
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
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
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
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? :)
I'm possibly missing a build dependency...check if 'libtool' is installed. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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.
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
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.
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
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
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
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
(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 :-))
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
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 ...
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
(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? :)
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 :)
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
I'm happy to see all the activity happening with regards to Navit. Good work. Has it been published to any repositories yet ? Thanks !
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
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.
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
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.
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
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
%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
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
(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
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.
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
ping? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Adam, I suggest you to start another Review Request and close this as DUPLICATE. :)
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
I thought that there will be some issues with rights for setting/unsetting fedora-flags. However, I'm not sure.
I have supah cow powahz in Bugzilla, I can set any flags I like ;) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Heh, we'll see. :)
Update, please ? Thanks !
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.
Ping, Adam.
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
I'm happy to hear that navit hasn't been abandoned/forgotten. Keep at it, guys !
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
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
(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 :-)
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.
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.
Isn't there a reply in upstream ticket?
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.
Could you do a similar build for F13 ? I'll test it if you do. Thanks
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.
Oops! Please, disregard my comment about "mdbtools" - this was a copypaste typo
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
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
Any update?
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.
What is the status of this bug?
(In reply to comment #72) > What is the status of this bug? FE-DEADREVIEW, I'm afraid.
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
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.
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.
*** This bug has been marked as a duplicate of bug 654374 ***