| Summary: | crashes at startup if marble-data is not installed | ||
|---|---|---|---|
| Product: | [Applications] marble | Reporter: | Tobias Doerffel <tobias.doerffel> |
| Component: | general | Assignee: | marble-bugs |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | ahepas1999, annma, fabo, ian.hawdon, justin.zobel, leandro.gfc.dutra, lure, marble-bugs, modax, mvr.rennes, nienhueser, rdieter, welsht |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Tobias Doerffel
2008-10-14 22:57:36 UTC
This problem must be fixed in marble code. nothing can be done in digiKam. Gilles Caulier *** Bug 175791 has been marked as a duplicate of this bug. *** I had some discussion about this in #kde-edu today with annma and pinotree. Root cause of this crash is that debian/ubuntu separates kdeedu/marble into three packages: - marble: standalone program - libmarble4: marble widget - marble-data: architecture independent data Crash is caused by the fact that libmarble (called by digikam), does not cope with missing data. It looks like that it cannot work without at all. We have to options to address this problem: 1. libmarble/marble is changed to cope with environment without data (not sure if this makes sense in practice) 2. libmarble (and indirectly marble) depend on marble-data (this is trivial change in debian/ubuntu packaging) I would like to get definite answer from Marble developers in what direction to go, otherwise we will use option 2. for KDE 4.2 packages (in order to avoid crash). Option 2 anyhow looks like a safer bet, even though that this brings additional 24 MB of compressed data (might be issue for Kubuntu CD). Some more ideas how to get around 24MB penalty (download) for library:
16:10 < MoDaX> there is a way to make digikam and other libmarble4 users to
depend on -data avoiding that dependency from libmarble4
16:11 < MoDaX> I might agree to going that way
16:11 < MoDaX> if all those 23 MB (30MB+ uncompressed) is really necessary
16:12 < MoDaX> but this rises a question, what if I don't want to find locations
in digikam
16:12 < MoDaX> this is extra
16:14 < MoDaX> 23 MB download is still big
16:14 < Lure> MoDaX: maybe marble-data should be just Suggest/Recommended package
for digikam, and libmarble widget should be good enough to behave
w/o data (display error message instead of widget, or empty globe
or something
16:15 < MoDaX> Lure: that would be absolutely perfect
16:15 < pinotree> imho the library should have the minimum required
16:15 < Lure> MoDaX: we just need to understand if w/o data at all is possible to
Marble developers
16:15 < pinotree> ie just the atlas map, no cities, etc
tackat, can you look into this rather soon please so that Debian packages and derived get fixe, thanks! > Root cause of this crash is that debian/ubuntu separates kdeedu/marble into
> three packages:
> - marble: standalone program
> - libmarble4: marble widget
> - marble-data: architecture independent data
Yes and we had rather discouraged this separation until Marble would reach binary compatibility.
We had also asked distributors to put a hard dependency onto the marble-data package as the source code was not entirely designed to work without portions of the data.
So in short: right now (2) is indeed the preferred option for now.
I'll commit some patch later today that will trim the amount needed for the srtm map down a bit more and hence reduce the deb/rpm size a bit.
Ok, I've just committed a fix which should reduce the size of the marble-data package by about 5 MB (at least it does so for the uncompressed JPGs -- but given that JPGs don't compress very well it should be about the same range). http://lists.kde.org/?l=kde-commits&m=123154731705347&w=2 If space is a concern you can always package Marble with the compile time option cmake -DTILES_AT_COMPILETIME=OFF This will only create the tiles for the atlas map at run time (so the user would get nagged with a dialog on first startup. This would save up to 10 MB, so the marble-data package should only weigh about 13 MB then (however I'd only suggest this method if getting it onto a live cd is an issue). I'll look into further options to reduce size in case of usage as a library. Regards, Torsten Torsten, thanks for explanations. We will fix KDE 4.2RC packages so that libmarble4 package will depend on marble-data. In my opinion, this bug could be closed as DOWNSTREAM. We'd like to move the library part of marble (libmarble) into kdesupport at some point in the future (I guess KDE 4.3 could be a good chance to do so). Now what we are toying with in terms of ideas for putting libmarble on diet is this: Move all data that is currently located in marble-data into the newly created package libmarble-data, _except_ for these mapthemes: - Precipitation maps, Temperature maps, Moon map, Schagen map. The latter map themes (which amount to about 4 MB) would then go into marble-data. That way we'd have libmarble which would depend on libmarble-data. marble which would depend on marble-data. *** Bug 185183 has been marked as a duplicate of this bug. *** There's now a wiki page for this: http://techbase.kde.org/Projects/Marble/NewMarbleMoldules SVN commit 1081126 by nienhueser: Remove exit() calls from the library part. Libraries should not force applications to terminate. Deal with no theme being loadable. While marble is not exactly useful without data, this prevents crashes and allows applications embedding a MarbleWidget to continue working even when marble is not correctly installed with regard to data files or their location. CCBUG: 172830 M +12 -10 MarbleMap.cpp M +4 -5 TextureTile.cpp M +6 -5 ViewParams.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1081126 *** Bug 268093 has been marked as a duplicate of this bug. *** *** Bug 263019 has been marked as a duplicate of this bug. *** *** Bug 268243 has been marked as a duplicate of this bug. *** *** Bug 254557 has been marked as a duplicate of this bug. *** Still a downstream/packaging issue, closing Thank you for the report, Tobias. As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |