Dear Sune, Sune Vuorela schrieb: > On 2009-05-22, John Stamp <jstamp@users.sourceforge.net> wrote: >> On Friday 22 May 2009 11:12:36 am Kai Wasserbäch wrote: >>> Dear mentors, >>> an updated package of kde-plasmoid-yawp has been uploaded to >>> mentors.debian.net, the new dgetable URL is: >>> http://mentors.debian.net/debian/pool/main/k/kde-plasmoid-yawp/kde-pl >>> asmoid-yawp_0.2.3-2.dsc > > Plasma-widgets are not packaged in kde-plasmoid packages, but in > plasma-widget-something, in this case probably plasma-widget-yawp Ok, I'll rename it. But how to best deal with the changelog? Keep it the way it is and just add a new entry with the new source package name? Keep it, rename all old occurrences of the source package name and add a new entry? Or just create a new package with a »clean« changelog under the new name? Should I rename the ITP or is it sufficient to just close it after the upload? O do I need to close the current ITP and file a new one with the correct data? (I'll wait with doing anything here, until I hear your opinion on it, just to not waste time on unneeded/-wanted stuff.) > How does this weather plasma widget differ from the two other we have in > debian? (the one in plasma-widget-weather and the one from > plasma-widgets-addons) It differs from the »LCD Weatherstation« (the one from the addons package) in the way, that it displays multiple days of forecasts, has customizable themes, is already largely l10n for several languages, displays the current satellite image on request and can be configured in much more detail (like number of days to show a forecast for). It differs from the plasma-widgets-weather plasmoid in the following ways: it's already l10n, it allows (customizable) themes, displays the current satellite image on request, has (IMHO) a cleaner/nicer UI and can be configured in much more detail. >> dpkg-shlibdeps_fix_spurious_dependencies.patch: >> >> Why not add pkg-kde-tools to your Build-Depends? You can set >> DEB_KDE_LINK_WITH_AS_NEEDED, plus you'll be using the same cmake setup >> that all of the other KDE packages use. > > If you can fix the issues by fixing the build system instead of using > --as-needed, it is much preferred to fix the build system (and send it > upstream). > > But depending on which libraries that is spurious, it might be better to > ignore it. > > for example, libgcc_s is unavoidable. I got libgcc_s, libQtSvg, libQtDBus and libQtNetwork as unneeded dependencies. And I don't think I can get rid of them, because they're part of some basic linking targets for KDE like kdeui or kdecore. Therefore I think the --as-needed approach is right now better, but if you'd prefer to have the required libraries listed manually, I guess I can do that. >> top_CMakeLists.txt_remove_FindPlasma_if-else-statement.patch: >> >> This patch seems to fix a problem that does not exist. You probably >> don't even need to restrict to kdelibs5-dev (>= 4:4.2.0). Or am I >> missing something? > > Plasma has changed quite a bit before and after 4.2.X, so I_think this > simplifies it a lot. So is it »correct« now: drop the patch but keep the versioned dependency? Thanks for your time and effort! Kind regards, Kai Wasserbäch -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: debian@carbon-project.org Jabber (debianforum.de): Drizzt URL: http://wiki.debianforum.de/Drizzt_Do%27Urden GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 (http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex)
Attachment:
signature.asc
Description: OpenPGP digital signature