[kpimtextedit/Applications/19.04] src: Revert "Add more emoticons"
Git commit d585af51ee3ee505cf34787e7bb364f2b699b611 by Pino Toscano.
Committed on 01/04/2019 at 18:23.
Pushed by pino into branch 'Applications/19.04'.
Revert "Add more emoticons"
This adds a new feature to a frozen release branch.
Even more, the new feature adds a new UI visible string without
translating it, to circumvent the string freeze.
Similar commits like these (just with the proper i18n() string) were
done in the past days, breaking the feature and string freezes.
CCMAIL: mon...@kde.org
CCMAIL: release-team@kde.org
This reverts commit 5f35f89b1441959c776af7a93eedb077f1cf4c56.
M +0-1src/emoticon/emoticonunicodetab.cpp
M +1-9src/textutils.cpp
M +0-1src/textutils.h
https://commits.kde.org/kpimtextedit/d585af51ee3ee505cf34787e7bb364f2b699b611
diff --git a/src/emoticon/emoticonunicodetab.cpp
b/src/emoticon/emoticonunicodetab.cpp
index 12f3c29..8c29bc9 100644
--- a/src/emoticon/emoticonunicodetab.cpp
+++ b/src/emoticon/emoticonunicodetab.cpp
@@ -46,7 +46,6 @@ void EmoticonUnicodeTab::loadEmoticons()
createPlainTextEmoticonTab(i18n("Flags"),
KPIMTextEdit::TextUtils::unicodeFlagsEmoji());
createPlainTextEmoticonTab(i18n("Weather"),
KPIMTextEdit::TextUtils::unicodeWeatherEmoji());
createPlainTextEmoticonTab(i18n("Foods"),
KPIMTextEdit::TextUtils::unicodeFoodEmoji());
-createPlainTextEmoticonTab(QStringLiteral("Sports"),
KPIMTextEdit::TextUtils::unicodeSportEmoji());
} else {
createEmoticonTab(QString());
}
diff --git a/src/textutils.cpp b/src/textutils.cpp
index 4e80c1c..e9af096 100644
--- a/src/textutils.cpp
+++ b/src/textutils.cpp
@@ -176,8 +176,7 @@ QList TextUtils::unicodeFullEmoji()
+TextUtils::unicodeEventEmoji()
+TextUtils::unicodeFlagsEmoji()
+TextUtils::unicodeWeatherEmoji()
- +TextUtils::unicodeFoodEmoji()
- +TextUtils::unicodeSportEmoji();
+ +TextUtils::unicodeFoodEmoji();
}
QList TextUtils::unicodeFacesEmoji()
@@ -250,10 +249,3 @@ QList TextUtils::unicodeFoodEmoji()
0x1F366, 0x1F367, 0x1F368};
return lstEmoji;
}
-
-QList TextUtils::unicodeSportEmoji()
-{
-//Add more
-const QList lstEmoji{0x1F93A, 0x1F3C7, 0x26F7, 0x1F3C2, 0x1F3CC,
0x1F3C4, 0x1F6A3, 0x1F3CA, 0x26F9, 0x1F3CB, 0x1F6B4, 0x1F938, 0x1F93C, 0x1F93D,
0x1F93E};
-return lstEmoji;
-}
diff --git a/src/textutils.h b/src/textutils.h
index 7738575..0fd90e8 100644
--- a/src/textutils.h
+++ b/src/textutils.h
@@ -66,7 +66,6 @@ KPIMTEXTEDIT_EXPORT Q_REQUIRED_RESULT QList
unicodeEventEmoji();
KPIMTEXTEDIT_EXPORT Q_REQUIRED_RESULT QList unicodeFlagsEmoji();
KPIMTEXTEDIT_EXPORT Q_REQUIRED_RESULT QList unicodeWeatherEmoji();
KPIMTEXTEDIT_EXPORT Q_REQUIRED_RESULT QList unicodeFoodEmoji();
-KPIMTEXTEDIT_EXPORT Q_REQUIRED_RESULT QList unicodeSportEmoji();
}
}
Re: dropping libkface from KDE Applications - was - Re: What to do with the repos we don't ship anymore in KDE Applications 17.12
In data lunedì 13 novembre 2017 00:31:35 CET, Albert Astals Cid ha scritto: > El dilluns, 13 de novembre de 2017, a les 0:01:49 CET, Andreas Sturmlechner > va > escriure: > > On 12 November 2017 at 23:57, Albert Astals Cid <aa...@kde.org> wrote: > > > I don't understand why you want to move it to extragear if it is > > > unmaintained, who is going to do releases? > > > > Maybe I don't understand either, I'm fine with it going the same way as > > blogilo. > > Ok, if it's broken and noone seems to care about it lets drop it. > > I've CC'ed the 4 people that have made any commit in the last 4 years in case > they want to object, you have until this thursday at 23:59 UTC. The only commit I did recently was removing the LSM file (!). Apart from that, libkface is one of the many digikam-ware stuff around, i.e. things that either digikam people want to control fully (but without cring much about non-digikam usages), or that they stop caring once digikam stops using it. Since the case here is the latter, just drop it from Applications (where it should not have been part, to begin with). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Review Request 110962: Switch to an external LibRaw
Alle domenica 7 luglio 2013, Gilles Caulier ha scritto: On July 4, 2013, 11:15 a.m., Pino Toscano wrote: Ping. Gilles, can we please get rid of this libraw copy? Gilles Caulier wrote: I'm here... In one week, it's holidays time for me (3 weeks). I will review this entry in-deep in mid-july Gilles Caulier Pino, I propose to create a libkdcraw branch, based to git/master and to to apply your patch. This will be more easy to review and fix before to switch this branch in production. Also, just receive libraw 0.15.3 to apply on master. We can sync your branch easily with git. There, external-libraw. Note that libraw and extra cmake files are not (and will not) removed in that branch, to ease the eventual merging from master. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
Alle lunedì 8 luglio 2013, Gilles Caulier ha scritto: 2013/7/8 Pino Toscano p...@kde.org: Alle domenica 7 luglio 2013, Gilles Caulier ha scritto: On July 4, 2013, 11:15 a.m., Pino Toscano wrote: Ping. Gilles, can we please get rid of this libraw copy? Gilles Caulier wrote: I'm here... In one week, it's holidays time for me (3 weeks). I will review this entry in-deep in mid-july Gilles Caulier Pino, I propose to create a libkdcraw branch, based to git/master and to to apply your patch. This will be more easy to review and fix before to switch this branch in production. Also, just receive libraw 0.15.3 to apply on master. We can sync your branch easily with git. There, external-libraw. Note that libraw and extra cmake files are not (and will not) removed in that branch, to ease the eventual merging from master. And no files must be removed for the moment. Using an external libraw must be optional in this condition : 1/ check if external version is available on the system. 2/ check if it's 0.15.x version. if 1/ and 2/ and respected, well compile and link against shared version. ...else print a warning and indicate that internal version will be used. Again keeping using internal stuff? Please, pretty please, get out of the mindset that using a copy of an external library is a good thing, because it is plain wrong. I'll be even more clearer than what I said in the review request: the copy of libraw inside libkdcraw must go away, ASAP. As libraw still in early stage of development, i would to preserve internal version until official 1.x release, to be able to test and report quickly all problem to libraw team. Please explain how using an external version hinders testing, rather it is the other way round. Using an embedded copy means people could use two versions of the same libkdcraw, one using a system libraw and the other using the external version. Considering how things go in such cases (also when looking at the history of your own handling of copies of libraries), we would run into situations like this: fixes are made into the embedded copy, users using the system version report issues and those get fixed because the fix has been imported into the embedded copy or other stuff like this... been there, done that, please do not get into this situation, really. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/#review35568 --- Ping. Gilles, can we please get rid of this libraw copy? - Pino Toscano On June 11, 2013, 9:28 p.m., Pino Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/ --- (Updated June 11, 2013, 9:28 p.m.) Review request for KDE Graphics, Release Team and Gilles Caulier. Description --- Instead of using an embedded copy of LibRaw, look for an external LibRaw as mandatory dependency with a new CMake module and using its variables. Considering some LibRaw versions seem to be underlinked and not linking to OpenMP, link it manually in libkdcraw to overcome such lack. Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as otherwise LIBRAW_BUILDLIB would conflict with LibRaw. Once this RR is approved, I will remove the libraw code copy and the CMake modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it. This addresses bug 307146. http://bugs.kde.org/show_bug.cgi?id=307146 Diffs - CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd cmake/modules/FindLibRaw.cmake PRE-CREATION libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b Diff: http://git.reviewboard.kde.org/r/110962/diff/ Testing --- Compiles fine with both LibRaw 0.14.7 and 0.15.1. Thanks, Pino Toscano ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Review Request 110962: Switch to an external LibRaw
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/ --- Review request for KDE Graphics, Release Team and Gilles Caulier. Description --- Instead of using an embedded copy of LibRaw, look for an external LibRaw as mandatory dependency with a new CMake module and using its variables. Considering some LibRaw versions seem to be underlinked and not linking to OpenMP, link it manually in libkdcraw to overcome such lack. Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as otherwise LIBRAW_BUILDLIB would conflict with LibRaw. Once this RR is approved, I will remove the libraw code copy and the CMake modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it. This addresses bug 307146. http://bugs.kde.org/show_bug.cgi?id=307146 Diffs - CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd cmake/modules/FindLibRaw.cmake PRE-CREATION libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b Diff: http://git.reviewboard.kde.org/r/110962/diff/ Testing --- Compiles fine with both LibRaw 0.14.7 and 0.15.1. Thanks, Pino Toscano ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
On June 11, 2013, 6:03 p.m., Vadim Zhukov wrote: cmake/modules/FindLibRaw.cmake, line 19 http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line19 LIBRAW_DEFINITIONS should be mentioned at the top of the CMake module then. Also, they should be cached, or they'll lost after initial configure stage, causing problems on re-configure. Will fix. On June 11, 2013, 6:03 p.m., Vadim Zhukov wrote: cmake/modules/FindLibRaw.cmake, line 23 http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line23 HINTS should be more appropriate here than PATHS, no? From CMake manual: ... paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option. Same applies to the find_library() call. Will change. On June 11, 2013, 6:03 p.m., Vadim Zhukov wrote: cmake/modules/FindLibRaw.cmake, line 36 http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line36 This check looks ugly. LibRaw itself provides LIBRAW_CHECK_VERSION() macros (in libraw_version.h), which could be used in compile check. This way it should be more future-compatible than parsing header file itself. Rolf Eike Beer wrote: I bet that macro is a C macro, not a CMake one. So for finding out in CMake code which version was found this doesn't help. Yes, I know about the macros in libraw_version.h, but they cannot be used at all in version checks at CMake time. Currently, the version string is just printed, but in the future it might be used to force a minimum version. - Pino --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/#review34162 --- On June 11, 2013, 5:50 p.m., Pino Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/ --- (Updated June 11, 2013, 5:50 p.m.) Review request for KDE Graphics, Release Team and Gilles Caulier. Description --- Instead of using an embedded copy of LibRaw, look for an external LibRaw as mandatory dependency with a new CMake module and using its variables. Considering some LibRaw versions seem to be underlinked and not linking to OpenMP, link it manually in libkdcraw to overcome such lack. Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as otherwise LIBRAW_BUILDLIB would conflict with LibRaw. Once this RR is approved, I will remove the libraw code copy and the CMake modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it. This addresses bug 307146. http://bugs.kde.org/show_bug.cgi?id=307146 Diffs - CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd cmake/modules/FindLibRaw.cmake PRE-CREATION libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b Diff: http://git.reviewboard.kde.org/r/110962/diff/ Testing --- Compiles fine with both LibRaw 0.14.7 and 0.15.1. Thanks, Pino Toscano ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
On June 11, 2013, 6:11 p.m., Rolf Eike Beer wrote:
cmake/modules/FindLibRaw.cmake, line 36
http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line36
file(STRING ... REGEX ...) will greatly reduce the noise in the
temporary variable. Also you can directly put the match into the target
variable using string(REGEX REPLACE). And since you don't unset the version
variables otherwise people may eventually start using them. In this case
they should use the default names, which would be
LibRaw_VERSION_{MAJOR,MINOR,PATCH} then.
I didn't want to make use of the LibRaw_VERSION_{MAJOR,MINOR,PATCH} variables,
so I won't adopt them.
Regarding the temporary variables, if people use temporary undocumented
variables (even prefixed with underscore), that's their problem.
On June 11, 2013, 6:11 p.m., Rolf Eike Beer wrote:
cmake/modules/FindLibRaw.cmake, lines 3-7
http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line3
It would be good if a new Find*.cmake module would follow the
convention that CMake defines for new modules to make it easier for
everyone to use them.
See here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/readme.txt
Will change, even if it seems mostly a pedantic change than an actually useful
one...
- Pino
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110962/#review34165
---
On June 11, 2013, 5:50 p.m., Pino Toscano wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110962/
---
(Updated June 11, 2013, 5:50 p.m.)
Review request for KDE Graphics, Release Team and Gilles Caulier.
Description
---
Instead of using an embedded copy of LibRaw, look for an external LibRaw as
mandatory dependency with a new CMake module and using its variables.
Considering some LibRaw versions seem to be underlinked and not linking to
OpenMP, link it manually in libkdcraw to overcome such lack.
Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by
KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as
otherwise LIBRAW_BUILDLIB would conflict with LibRaw.
Once this RR is approved, I will remove the libraw code copy and the CMake
modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it.
This addresses bug 307146.
http://bugs.kde.org/show_bug.cgi?id=307146
Diffs
-
CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd
cmake/modules/FindLibRaw.cmake PRE-CREATION
libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce
libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b
Diff: http://git.reviewboard.kde.org/r/110962/diff/
Testing
---
Compiles fine with both LibRaw 0.14.7 and 0.15.1.
Thanks,
Pino Toscano
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
On June 11, 2013, 6:03 p.m., Vadim Zhukov wrote:
cmake/modules/FindLibRaw.cmake, line 36
http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line36
This check looks ugly. LibRaw itself provides LIBRAW_CHECK_VERSION()
macros (in libraw_version.h), which could be used in compile check. This
way it should be more future-compatible than parsing header file itself.
Rolf Eike Beer wrote:
I bet that macro is a C macro, not a CMake one. So for finding out in
CMake code which version was found this doesn't help.
Pino Toscano wrote:
Yes, I know about the macros in libraw_version.h, but they cannot be used
at all in version checks at CMake time. Currently, the version string is just
printed, but in the future it might be used to force a minimum version.
Vadim Zhukov wrote:
If you want only to get the libraw's version, then you could use
libraw_version() function. Just compile sample code which calls
libraw_version() and prints its output, and save output to the variable. As a
bonus you'll early check if found libraw could be used at all.
Rolf Eike Beer wrote:
@Pino: then simply unset() the variables, including the
LIBRAW_VERSION_CONTENT one.
@Vadim: that simply will not work, think about cross compiling.
One way to avoid parsing the version header most of the time will be
using the version from pkg-config, if present.
Vadim Zhukov wrote:
@Rolf: Yes, you're right about cross-compilation case. From the other
side, we basically don't need to retrieve the version - we need to check if
version we want is sufficient (if LIBRAW_FIND_VERSION was supplied). In this
case we could compile the code which looks like the following:
#include libraw.h
#include libraw_version.h
#if !LIBRAW_COMPILE_CHECK_VERSION_NOTLESS(${LIBRAW_MAJOR},
${LIBRAW_MINOR})
#error LibRaw version mismatch
#endif
@Vadim: Why should be a test program needed while
find_package_handle_standard_args handle the version check already?
The rest of the discussion is just overly pedantry on a private uninstalled
module which is to be used only by libkdcraw.
- Pino
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110962/#review34162
---
On June 11, 2013, 5:50 p.m., Pino Toscano wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110962/
---
(Updated June 11, 2013, 5:50 p.m.)
Review request for KDE Graphics, Release Team and Gilles Caulier.
Description
---
Instead of using an embedded copy of LibRaw, look for an external LibRaw as
mandatory dependency with a new CMake module and using its variables.
Considering some LibRaw versions seem to be underlinked and not linking to
OpenMP, link it manually in libkdcraw to overcome such lack.
Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by
KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as
otherwise LIBRAW_BUILDLIB would conflict with LibRaw.
Once this RR is approved, I will remove the libraw code copy and the CMake
modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it.
This addresses bug 307146.
http://bugs.kde.org/show_bug.cgi?id=307146
Diffs
-
CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd
cmake/modules/FindLibRaw.cmake PRE-CREATION
libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce
libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b
Diff: http://git.reviewboard.kde.org/r/110962/diff/
Testing
---
Compiles fine with both LibRaw 0.14.7 and 0.15.1.
Thanks,
Pino Toscano
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
On June 11, 2013, 6:38 p.m., Gilles Caulier wrote: libraw detection can be not enough. if you look in libkdcraw, you will see RawSpeed code backported too. http://rawstudio.org/blog/?p=800 This code is to speed up raw data extraction. It's not to process demosaicing. Here on my linux Mageia, librawspeed is not available. I don't know if other distro support this library. LibRaw 0.15 will not support RawSpeed. You must take a care about. In this case RawSpeed must be disabled. Also, settings from raw decoding container and widget have been validated with libraw 0.15.x. So do not accept an older version of libraw, else there will be serious problems... Gilles Caulier if you look in libkdcraw, you will see RawSpeed code backported too. Yet another copy of some 3rd party source?! Sigh It would be really helpful if your development way would not start by embedding some 3rd party library in the sources of some KDE application/library... For the rest: OK, it is fine to accept only LibRaw = 0.15. (I suspect they would work the same, but oh well...) - Pino --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/#review34173 --- On June 11, 2013, 5:50 p.m., Pino Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/ --- (Updated June 11, 2013, 5:50 p.m.) Review request for KDE Graphics, Release Team and Gilles Caulier. Description --- Instead of using an embedded copy of LibRaw, look for an external LibRaw as mandatory dependency with a new CMake module and using its variables. Considering some LibRaw versions seem to be underlinked and not linking to OpenMP, link it manually in libkdcraw to overcome such lack. Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as otherwise LIBRAW_BUILDLIB would conflict with LibRaw. Once this RR is approved, I will remove the libraw code copy and the CMake modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it. This addresses bug 307146. http://bugs.kde.org/show_bug.cgi?id=307146 Diffs - CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd cmake/modules/FindLibRaw.cmake PRE-CREATION libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b Diff: http://git.reviewboard.kde.org/r/110962/diff/ Testing --- Compiles fine with both LibRaw 0.14.7 and 0.15.1. Thanks, Pino Toscano ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 110962: Switch to an external LibRaw
On June 11, 2013, 6:38 p.m., Gilles Caulier wrote: libraw detection can be not enough. if you look in libkdcraw, you will see RawSpeed code backported too. http://rawstudio.org/blog/?p=800 This code is to speed up raw data extraction. It's not to process demosaicing. Here on my linux Mageia, librawspeed is not available. I don't know if other distro support this library. LibRaw 0.15 will not support RawSpeed. You must take a care about. In this case RawSpeed must be disabled. Also, settings from raw decoding container and widget have been validated with libraw 0.15.x. So do not accept an older version of libraw, else there will be serious problems... Gilles Caulier Pino Toscano wrote: if you look in libkdcraw, you will see RawSpeed code backported too. Yet another copy of some 3rd party source?! Sigh It would be really helpful if your development way would not start by embedding some 3rd party library in the sources of some KDE application/library... For the rest: OK, it is fine to accept only LibRaw = 0.15. (I suspect they would work the same, but oh well...) Gilles Caulier wrote: The reason to include libraw is simple : libraw API change agian and again, and i don't won't to puzzle libkdcraw source code with an amount of conditional rules. As i'm in contact with libraw team, i'm aware of plan and this is why i take a care to not have a shared component as libkdcraw which provide a broken binary compatibility with a lots of crash... Just my experience. Typicially, libraw as experiental code which are tested and removed if to much problem are reported... There is also another problem : how to be sure that 3rd party codec from libraw are compiled in shared version of system : There are 2 packs : one GPL2, one GPL3. These packages add new demosaicing methods and camera support. If libraw is not compiled with these components some parts of libkdcraw will not work as well. This will be very problematic for end users... This is another reason about libraw inclusion in libkdcraw. Like this i'm sure that all features are included... Libraw is a big puzzle. Take a care... Gilles Caulier If the API changes, then the version macros can be used to keep compatibility with multiple versions; it seems the libraw people are not breaking the API much lately, so hopefully the libkdcraw code won't be filled with a lot of these checks. Regarding the binary compatibility: if the libraw people bump SONAME/SOVERSION whenever the ABI changes, that's perfectly fine and will not cause issues (maybe just to self-compiling users which have no clue on what they are doing). If they break ABI without handling SONAME/SOVERSION bumps, that's their fault which they ought to solve. Regarding the extra packs: are those compiled/provided by default to libraw users? If they could cause licensing issues/incompatibilities, then compiling them as part of libkdcraw will *not* change their situation. - Pino --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/#review34173 --- On June 11, 2013, 5:50 p.m., Pino Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/ --- (Updated June 11, 2013, 5:50 p.m.) Review request for KDE Graphics, Release Team and Gilles Caulier. Description --- Instead of using an embedded copy of LibRaw, look for an external LibRaw as mandatory dependency with a new CMake module and using its variables. Considering some LibRaw versions seem to be underlinked and not linking to OpenMP, link it manually in libkdcraw to overcome such lack. Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as otherwise LIBRAW_BUILDLIB would conflict with LibRaw. Once this RR is approved, I will remove the libraw code copy and the CMake modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it. This addresses bug 307146. http://bugs.kde.org/show_bug.cgi?id=307146 Diffs - CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd cmake/modules/FindLibRaw.cmake PRE-CREATION libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b Diff: http://git.reviewboard.kde.org/r/110962/diff/ Testing --- Compiles fine with both LibRaw 0.14.7 and 0.15.1. Thanks, Pino Toscano ___ release-team mailing
Re: Review Request 110962: Switch to an external LibRaw
On June 11, 2013, 6:38 p.m., Gilles Caulier wrote: libraw detection can be not enough. if you look in libkdcraw, you will see RawSpeed code backported too. http://rawstudio.org/blog/?p=800 This code is to speed up raw data extraction. It's not to process demosaicing. Here on my linux Mageia, librawspeed is not available. I don't know if other distro support this library. LibRaw 0.15 will not support RawSpeed. You must take a care about. In this case RawSpeed must be disabled. Also, settings from raw decoding container and widget have been validated with libraw 0.15.x. So do not accept an older version of libraw, else there will be serious problems... Gilles Caulier Pino Toscano wrote: if you look in libkdcraw, you will see RawSpeed code backported too. Yet another copy of some 3rd party source?! Sigh It would be really helpful if your development way would not start by embedding some 3rd party library in the sources of some KDE application/library... For the rest: OK, it is fine to accept only LibRaw = 0.15. (I suspect they would work the same, but oh well...) Gilles Caulier wrote: The reason to include libraw is simple : libraw API change agian and again, and i don't won't to puzzle libkdcraw source code with an amount of conditional rules. As i'm in contact with libraw team, i'm aware of plan and this is why i take a care to not have a shared component as libkdcraw which provide a broken binary compatibility with a lots of crash... Just my experience. Typicially, libraw as experiental code which are tested and removed if to much problem are reported... There is also another problem : how to be sure that 3rd party codec from libraw are compiled in shared version of system : There are 2 packs : one GPL2, one GPL3. These packages add new demosaicing methods and camera support. If libraw is not compiled with these components some parts of libkdcraw will not work as well. This will be very problematic for end users... This is another reason about libraw inclusion in libkdcraw. Like this i'm sure that all features are included... Libraw is a big puzzle. Take a care... Gilles Caulier Pino Toscano wrote: If the API changes, then the version macros can be used to keep compatibility with multiple versions; it seems the libraw people are not breaking the API much lately, so hopefully the libkdcraw code won't be filled with a lot of these checks. Regarding the binary compatibility: if the libraw people bump SONAME/SOVERSION whenever the ABI changes, that's perfectly fine and will not cause issues (maybe just to self-compiling users which have no clue on what they are doing). If they break ABI without handling SONAME/SOVERSION bumps, that's their fault which they ought to solve. Regarding the extra packs: are those compiled/provided by default to libraw users? If they could cause licensing issues/incompatibilities, then compiling them as part of libkdcraw will *not* change their situation. Gilles Caulier wrote: Extra GPL2/GPL3 pack are not included in libraw in standard due to mixing licensing problem. It's separated packages. So distro packagers must take a care about and compile all as well. It's the same problem with RawSpeed which use another licensing than libraw core... Gilles Caulier So the inclusion of these packs in libkdcraw *is* creating a licensing issue to distro packagers already? Great... Gilles: putting everything in one source (libkdcraw) does not make a) licensing issues b) incompatibilities c) shipping issue go away at the same time, as you're creating new issues instead. Now, if you could help testing this in the way you like, we could cleanup all this embedding mess in libkdcraw. Thank you. - Pino --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/#review34173 --- On June 11, 2013, 5:50 p.m., Pino Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/ --- (Updated June 11, 2013, 5:50 p.m.) Review request for KDE Graphics, Release Team and Gilles Caulier. Description --- Instead of using an embedded copy of LibRaw, look for an external LibRaw as mandatory dependency with a new CMake module and using its variables. Considering some LibRaw versions seem to be underlinked and not linking to OpenMP, link it manually in libkdcraw to overcome such lack. Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by KDE4_ADD_LIBRARY
Re: Review Request 110962: Switch to an external LibRaw
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/ --- (Updated June 11, 2013, 9:28 p.m.) Review request for KDE Graphics, Release Team and Gilles Caulier. Changes --- Updated with the CMake style changes, and set minimum version to 0.15. Description --- Instead of using an embedded copy of LibRaw, look for an external LibRaw as mandatory dependency with a new CMake module and using its variables. Considering some LibRaw versions seem to be underlinked and not linking to OpenMP, link it manually in libkdcraw to overcome such lack. Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as otherwise LIBRAW_BUILDLIB would conflict with LibRaw. Once this RR is approved, I will remove the libraw code copy and the CMake modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it. This addresses bug 307146. http://bugs.kde.org/show_bug.cgi?id=307146 Diffs (updated) - CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd cmake/modules/FindLibRaw.cmake PRE-CREATION libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b Diff: http://git.reviewboard.kde.org/r/110962/diff/ Testing --- Compiles fine with both LibRaw 0.14.7 and 0.15.1. Thanks, Pino Toscano ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Review Request: aprs: use external QextSerialPort for TTY reading
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107536/ --- Review request for kdewin, Marble and Release Team. Description --- Instead of embedding an (old) copy of the QextSerialPort library, find for an external one; only if found enable the reading from TTY, which is otherwise disabled (leaving its configuration tab disabled). The drop of the internal QextSerialPort should also fix all the portability issues, since the plugin itself does not use any OS-dependent API, and it is then reenabled unconditionally. Hence, bug 241125 should now be fixed, and bug 237931 and bug 242039 should not happen anymore. @release-team: yes, I know this would introduce a new optional dependency, but on the other hand a copy of a 3rd party library would go away. Would this be acceptable at this point? This addresses bug 241125. http://bugs.kde.org/show_bug.cgi?id=241125 Diffs - cmake/modules/FindQextSerialPort.cmake PRE-CREATION src/plugins/render/CMakeLists.txt d82293ee782e735ff1c90e6e13d330fb7cf8563c src/plugins/render/aprs/AprsPlugin.cpp f406cec2ad665977830416aa7f5df59851a5e430 src/plugins/render/aprs/AprsTTY.cpp c65ac38b24269b608c8f3ea1452b670f9422174d src/plugins/render/aprs/CMakeLists.txt fb6ef13c80568a72a5bfcf8a2e675b969238b9f6 src/plugins/render/aprs/aprsconfig.h.in d0e6b5c4ce36080dc0e59422529c55728ff04b3a src/plugins/render/aprs/posix_qextserialport.cpp 118843f02a5c62fd708b9157e59a039dff06e238 src/plugins/render/aprs/qextserialport.h 457d831cffc4ae8c43ac7db2d85a20546eb65044 src/plugins/render/aprs/qextserialport.cpp 790e5a2701ba1291a645c4fd4b09a8a1c55d7541 src/plugins/render/aprs/qextserialport_global.h 013a6dcd4ecab97425b1286139af4f0e911c38c9 src/plugins/render/aprs/win_qextserialport.cpp 5f21d7302e61b50825f79a68b352d5b9544b3fa3 Diff: http://git.reviewboard.kde.org/r/107536/diff/ Testing --- The Aprs plugin compiles fine with and without an external QextSerialPort library. Thanks, Pino Toscano ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.0 tarballs (try#1) uploaded
Alle lunedì 25 luglio 2011, Jorge Manuel B. S. Vicetto ha scritto: I've noticed that on 4.6.95 there were tarballs for the gu, hi and mai locales that are not present for 4.7.0. Conversely, there's now a ug locale not present on 4.6.95. Are these changes intentional or an oversight? http://lists.kde.org/?l=kde-i18n-docm=130989993314535w=4 and, most important, http://lists.kde.org/?l=kde-i18n-docm=131106673005897w=4 -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [okular/4.6] /: bump version to 0.12.5
Alle sabato 2 luglio 2011, Max Brazhnikov ha scritto: I recreated kdegraphics tarball to include the right version of okular: 9054b67c661847e7b41c57a19492ade8 sources/kdegraphics-4.6.5.tar.bz2 kdegraphics has circular dependency on itself, namely mobipocket depends on okular. Dirk, please update mobipocket/4.6 to include also 6ab89608ce73af7c66640a4603e1f443eda691e1 which fixes the build within kdegraphics. Thanks and sorry for the late reply, -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdegraphics 4.6.4 tarball contains the wrong okular
Alle lunedì 20 giugno 2011, Dirk Mueller ha scritto: On Friday 17 June 2011, Albert Astals Cid wrote: with 4.x) or because the newest Okular tag is v4.6.1 in git repo.. okular was taken from svn, simply because thats the way it used to be at the beginning when I tagged 4.6.2, and nobody told me that I should switch to the git version, so I didn't. Nobody? I sent an email to this ml about that on May 25th (approx. one month ago), kdegraphics git migration complete. lemme understand, it is meanwhile expected that the okular git builds fine in a kdegraphics module again and that I should use the git tree now? Yes. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.1 tarballs (try #1) uploaded
Alle venerdì 4 marzo 2011, nlecure...@mandriva.com ha scritto: On Wednesday 02 March 2011, Sebastian K�gler wrote: If all lights are green, we'll publish tomorrow night, CET. (Sorry for my silence these days, it's really close to goldmaster time right now, and every minute is about 13 times as important right now. ;) Hi, I've noticed one more issue: kdebase-4.6.1 now contains the konqueror plugins that were previously outside kdebase. I've respinned the kdebase tarball now to remove them to not silently add such features to 4.6 branch. does anyone remember why it was added there? d032fb52e5fdf2eb0b3ab37a7a06eacf kdebase-4.6.1.tar.bz2 Thanks, Dirk i just saw that konq plugins is also on the kde-l10n files, i think they should be recreated without it. The affected .po files are in $lang/messages/kdebase, and they are: adblock.po akregator_konqplugin.po autorefresh.po babelfish.po dirfilterplugin.po domtreeviewer.po fsview.po imgalleryplugin.po khtmlsettingsplugin.po mf_konqplugin.po minitoolsplugin.po rellinks.po searchbarplugin.po uachangerplugin.po validatorsplugin.po webarchiver.po plus their documentations, $lang/docs/kdebase-apps/konq-plugins -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.1 tarballs (try #1) uploaded
Alle giovedì 3 marzo 2011, Dirk Mueller ha scritto: I've noticed one more issue: kdebase-4.6.1 now contains the konqueror plugins that were previously outside kdebase. Note they are no more outside kdebase. I've respinned the kdebase tarball now to remove them to not silently add such features to 4.6 branch. does anyone remember why it was added there? David Faure backported them to kde-baseapps 4.6 as well, to have them available for 4.6 as well. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 RC2
Alle mercoledì 20 gennaio 2010, Sebastian Kügler ha scritto: On Tuesday 19 January 2010 23:05:45 Dirk Mueller wrote: Hi, are we ready for KDE 4.4 RC2 tagging? Any known show stoppers? https://bugs.kde.org/show_bug.cgi?id=223313 A crasher in the KIO scheduler, doesn't seem fully fixed yet. KDE Platform Version: 4.4.59 (KDE 4.4.59 (KDE 4.5 = 20100107)) (Compiled from sources) This refers to the new KIO scheduler in trunk only, so should not affect KDE 4.4. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: moving Tellico l10n into kdereview
Hi, I just moved Tellico from KDE playgorund into kdereview. Based on http://techbase.kde.org/Policies/SVN_Guidelines I wasn't sure if any i18n or l10n files needed to be moved as well. I did that yesterday already :) Thanks anyay for notifying about it! Have a good review, -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
Alle sabato 28 marzo 2009, Cyrille Berger ha scritto: Lets say application A need icons cool_icon, which will only be available in KDE4.3, but application A is released before KDE4.3, solution for developers of application A: ship cool_icon and (forget to) remove it when 4.3 is available and becomes a required dependency for application A. That is perfectly fine, as long as (as written in my other email) the versions installed by the application are provided a) locally in the application datadir b) in the hicolour namespace This way, when the icon theme will provide the cool_icon (installed globally) needed by the application, it will override (as in runtime loading of the icon, not as in file overwriting) the local application version. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
Hi, Exactly, that's actually the reason, why in Gentoo, we get some number of duplicated icons causing file collisions that need to be handled. Of course, usually after some time, they are eventually removed from those packages. Some applications still ship some icons on their own (I could give some examples, like digikam, and used to - koffice). The possible reasons are: - some application developers don't know whether some icon is shipped already with KDE4 - some application developers don't want to assume that KDE4 shipping those newly added application icons is installed on user machine, so just in any case they ship icons themselves. Neither of the two. The *real* reasons for clashes between an icon installed with an icon theme and one installed with an application itself is just one: an application polluting the namespace of the global icon theme. Back to your digikam issue: this was actually an issue because they used to install the application icon within the oxygen icon theme... and that same icon was put in the trunk version of oxygen. The *only* sane way to resolve these issues is having applications install their icons within the hicolour namespace, with: - icons for the application (say, the one for representing it, usually in the 'apps' category) in the global icon theme (usually /usr/share/icons/hicolor) - other application icons within the local datadir of the application ($datadir/appname/icons/) This ensures some things: - private icons for an applications stay really private - as hicolour is the low-level denominator for icon themes, if you use any icon theme different than oxygen you can actually see application icon in the menu (either kde's or gnome's or any other xdg-menu implementation) - a better version of some icon (either the icon of an application icon or some private application one) provided globally in an icon theme will override the hicolor one (as expected) so that in effect every Oxygen icon create is in kdesupport/oxygen-icons) ... minus icons of applications (ie those in the 'apps' category) for applications which have no own hicolor version. As said above, any application should carry its own icon with the hicolor icon theme, otherwise there will be an happy question mark when being used in non-oxygen contexts (eg in a gnome menu). -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Getting ready for KDE 4.2.2
Alle venerdì 27 marzo 2009, Helio Chissini de Castro ha scritto: Dirk, just don't forget to ping oxygen guys to make package available too... Isn't the 4.2.x branch still providing Oxygen icons in kdebase/runtime? AFAIK buy last emails even 4.2.2 was splitted Well, there's still a branches/KDE/4.2/kdebase/runtime/pics/oxygen, which also exists in the current 4.2.2 tag. Should it be removed in both locations, or kdesupport's used for 4.3? -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.x point releases plans?
Hi, At the same time the schedule for 4.3 is fixed, what are the plans for the revision released of 4.2? Given that almost two weeks after KDE 4.2.0 are passed, it would be nice to schedule at least 4.2.1 and 4.2.2 to plan testing of fixes on the branch (and potential backport of tested semi-fixes in the branch). -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
Hi, For each main kde tree we will create a tag. For example for the current stable KDE release we create a tags/kdesupport-for-4.1/. Within that folder there are (cheap)copies of the kdesupport libraries which should be used for compiling the KDE 4.1 tree. For example: tags/kdesupport-for-4.1/phonon/(svn cp'ed from tags/phonon/4.2.0) tags/kdesupport-for-4.1/strigi/(svn cp'ed from tags/strigi/strigi/0.5.11) tags/kdesupport-for-4.1/qca/(svn cp'ed from tags/qca/2.0.1) Why not svn:externals to either the last stable release (tag), or /branches with externals to the stable branches? -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: show stopper list?
Alle lunedì 21 luglio 2008, Rex Dieter ha scritto: Dirk Mueller wrote: Anyone around who has more eyes and ears open and can bring in some show stoppers or critical/annoying bugs we have to fix before 4.1? One of the critical/annoying kind: * okular: print pdf produces no output, also print to file broken : http://bugs.kde.org/161759 Blame Trolltech, not Okular. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: show stopper list?
Alle lunedì 21 luglio 2008, Helio Chissini de Castro ha scritto: On Monday 21 July 2008 10:32:16 Pino Toscano wrote: Alle lunedì 21 luglio 2008, Rex Dieter ha scritto: Dirk Mueller wrote: Anyone around who has more eyes and ears open and can bring in some show stoppers or critical/annoying bugs we have to fix before 4.1? One of the critical/annoying kind: * okular: print pdf produces no output, also print to file broken : http://bugs.kde.org/161759 Blame Trolltech, not Okular. Okular or not, still be a a critical bug. ... which I (or from a KDE POV) can do exactly nothing. My most productive talk with Thomas Zander was a patches welcome! :) reply from him, so I gave up on this long ago. If Trolltech wants to help KDE for Qt bugs that (more or less badly) afflict KDE users, good; but doing the Don Quixote (and fighting against windmills) is quite pointless. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: show stopper list?
Alle lunedì 21 luglio 2008, Sebastian Kügler ha scritto: Does this have a trolltech bugtracker ID or has it been 'formally' reported? If so, we can point trolls to it telling them that it's release-critical. Just bugging someone on IRC is hardly traceable and thus it'll be even harder to get it fixed. Sure they have: - #212886 (open, for Qt 4.5.0) - #214505 (closed, for Qt 4.4.2) Small note regarding the closed one: if it would had not been for David Faure, the bug would most still probably be open and scheduled for Qt 4.5.0 (as it was up to weeks ago). Is it so difficult having the cooperation of Trolltech in this regard? Or things won't work if we (KDE) don't do the daily poking game? -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Anon kdesupport checkout requires auth
Alle venerdì 23 maggio 2008, Mark Constable ha scritto: Apologies for posting this again to this list but I have no idea where or who should be notified about this. [EMAIL PROTECTED] fur such question please. And reading the replies to the same problem might help: http://mail.kde.org/pipermail/release-team/2008-May/002065.html -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport taglib/admin needs svn auth
Hi, I'm not sure where to post this so apologies if this is not the right list for an anonymous checkout bug. [EMAIL PROTECTED] Fetching external item into 'taglib/admin' Authentication realm: https://svn.kde.org:443 KDE SVN account Password for 'admin': $ rm -rf kdesupport/taglib/admin $ svn up -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: the future of kdetoys
Hi, 1. kmoon This was removed from trunk (4.1) some weeks ago, already. The reason is the one you said, plasma_applet_luna. 4. kweather kweather is something curious. Some parts are ported (kweatherreport and kweatherservice) AFAIR, kweather has a service running on DCOP/D-Bus for getting the weather data, and clients communicate to it via the bus wire. Apart the kweather kicker applet, there is another client for it: the weather plugin for the kontact summary view. I don't know its state, though. (Although, I think it should be more-or-less working. Any PIM-er has an idea?) About the plasma thing: IMHO it was just the new rewrite, without taking in consideration kweather at all (especially that now the weather ions are plugins for the plasma engine, so no way to use those like the D-Bus kweather engine.) Anyway, let the plasma developers talk about that. 5. kworldclock kworldclock seems to be ok for the moment, but didn't have a maintainer. Also Henry de Valence works on a new plasma based world clock (see [3]). I think it's finding its new way as plasma applet, based on Marble. 6. ktux and 7. amor No maintainer and as far as I know nobody did work on this applications since 2006 (besides basic porting/i18n and similar tasks). At least for amor, I remember it was working. 8. kteatime I ported this application to KDE4 and took care of it since then. Please don't bring away the kde teapot reminder! :) [big snip] What do you think? Either move the working non-plasma stuff to kdeutils, or to some extragear, toys or utils. For the kicker stuff, maybe it's worth directly the removal (not even the move to unmaintained), as it's just that needs to be totally rewritten (or mostly), so you could start from KDE 3.5.x codebase. KDE 4.x porting does not add much, I think... -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDEPIM 4.1?
Hi, Sebas' Alpha1 announcement on the Dot [1] promises KDE-PIM as part of the 4.1 release. I don't think sebas promised on his own, but just said what is the idea so far, as (at least I didn't see it, but I'm not in KDE-PIM channels) there was annoucement or agreement on not shipping KDE-PIM with KDE 4.1 I have strong doubts about this. We need to discuss. I don't see why this discussion belongs to release-team. In my opionion, you PIM guys should discuss this, then come to release-team with a -single- idea about whether shipping or not, and in case of shipping, which parts of it should be. -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: String freeze ask
Alle giovedì 15 novembre 2007, Allen Winter ha scritto: On kdegames many changes was done on apps for KDE4.0, and some of our guys worked very hard to have up to date docbook. Unfortunatly, wasn't done at time for the string freeze. We have the 2 last games dockbook and many fix done by Burkhard (i18n translator) to commit. We are thinking it could be sad to have well translated unusual doc, so i'm asking if we can bypass the freeze in this case :/ Can we commit them asap?? Johann, We haven't gone into message freeze for docbooks yet. So no problem at all. Commit! Oh dear. Can we please clarify a solid message freeze date for the documentations? Translating needs its times (translation, review, testing), and allowing changes up to the day before the translations freezes will not help us translators providing complete translations for the application manuals. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: ERROR: there are duplicated POT files:
Hi, now the duplicates left are: kdgantt1.pot kpager.pot krunner.pot libplasma.pot Yesterday I added some move/delete rules for the orphan processing. Is the script run periodically, or just manually? In case of the latter, could anyone with a full l10n-kde4 checkout run it for all the languages? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 3.90.1 (KDE 4.0 alpha1) tarballs
Alle 09:45, martedì 8 maggio 2007, Anne-Marie Mahfouf ha scritto: For the kdeedu module I intend to add a text file called Dependencies.txt (or anything else if you have a better name) which will list the libs each app needs and for what functionality. [...] What do you think about extending that for all modules? Can't we use something like http://www.kde.org/info/requirements/3.5.php even for KDE4? It could be linked from the release announcement, as currently done with KDE3. -- Pino Toscano pgp5WHynqYppt.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
