Re: kdepim and kdepim-runtime version strings in KDE SC 4.8.1
On Monday 12 of March 2012 14:38:41 Allen Winter wrote: Howdy, The version strings in the tarballs for kdepim and kdepim-runtime 4.8.1 still say 4.8.0. At the very least this is confusing us in the bug triaging. I just committed fixes in the KDE/4.8 branches for kdepim/CMakeLists.txt (commit 63467efd) kdepim-runtime/CMakeLists.txt (commit 5c55de19) It would be quite helpful if at some point the distros would push out updates to fix this. @Dirk While at this, do you use some script that makes whole 'tagging foo' or it's based around invoking git command directly? (I know there was one in kde-common/release for svn released stuff) Someone could work on automating updating version strings on tagging if one knew where to start. -- regards MM 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: Request for splitting oxygen-icons tarball
On Friday 02 of March 2012 13:35:24 Dirk Mueller wrote: On Tuesday 28 February 2012, Harald Sitter wrote: Phonon only does xz tarballs, so dep-wise xz is required anyway... you might just as well do the kde release tars in xz too ;) I'm fine with switching to xz. anyone having a problem with that? Gentoo hat Please do so. /Gentoo hat -- regards MM 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: Call for the next release codename to be Ritchie
On Thursday 13 of October 2011 12:07:05 Ivan Čukić wrote: As you all (probably) know, Dennis Ritchie has passed away. In my opinion, we should somehow make tribute to him. I'm not sure the idea to name a release after him would be fitting, but that's the only thing I've came up with. Dennis being other option. -- regards MM 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: What to release from where?
On Tuesday 21 of June 2011 02:46:13 Frederik Schwarzer wrote:
Hi,
because of all the trouble the moving migration caused so far,
As of now, Dirk had to ask before every release, what he should release
from where.
I thought it might be a good idea to make things more ... written-down.
http://techbase.kde.org/Projects/MovetoGit/Progress
I hope I got the current status correctly. If not, feel free to comment
here, make changes directly or hit me on IRC (icwiener).
What I am especially interested in is feedback from you, Dirk,
on how helpful this might be if properly maintained.
Excellent, thanks!
A small question to release-team here (and repo maintainers), would it be
doable to have the same branch names for all packages released under KDE SC
umbrella?
Currently, while KDE/${major}.${minor} is obviously the most popular one,
variations exist. I believe it doesn't help from packager point of view wrt
scripting the process - and certainly makes things a bit more complex from
distro packager point of view (hunting down all branching/tagging variants
from all project repos,
Sure it applies mostly to distros that track code from repositories - not just
when tarballs are released - which is minority I believe.
${major}.${minor} branch names can be also confusing (for newcomers but
still) in case of apps that provide own versioning as well, for instance
Okular in 4.6 branch reports itself as Okular 0.12.4, analogy with Marble
(randomly picked examples here, no strings attached).
Adding 'KDE/' prefix to branch names would without doubt denote that this
particular branch is to be used for fetching and tagging for KDE SC
distribution (when certain application is released so probably tagged
individually as well).
I understand however that consistency on this field and on tag names imposes
certain KDE workflow (to natively use KDE/${major}.${minor} branch names)
on apps that aim to sell themselves on their own or involves more merging
work otherwise (but hey. branches are cheap in git).
Btw, how did it happen that svn - git move caused so much dispersion in
branch names? (tagging fortunately is more or less consistent, thanks to Dirk
most likely).
--
regards
MM
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
On Tuesday 14 of June 2011 19:53:39 Albert Astals Cid wrote: Not sure about the other kdegraphics programs but at least for okular it is containing something that seems to be okular from 4.6.1 era. Dirk any idea how that happened? /me guesses it's because of okular git branch names being inconsistent with the rest of kdegraphics (the rest uses KDE/4.x whle Okular goes with 4.x) or because the newest Okular tag is v4.6.1 in git repo.. Out of curiosity, whose task is to tag versions after split now? Application provider (or particular repository admin) or release team (for all apps within KDE module being tagged) ? -- regards MM 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-pim] KDEPIM 4.5beta4 [Attn: Dirk]
On Friday 22 of October 2010 16:43:20 Volker Krause wrote: btw, there's also a new Akonadi server release (1.4.1) that contains important bugfixes for the next 4.5 release of kdepimlibs. Could you apply attached patch to 1.4 branch? -- regards MM diff -ru ../akonadi-1.4.0/qsqlite/src/qsql_sqlite.cpp ./qsqlite/src/qsql_sqlite.cpp --- ../akonadi-1.4.0/qsqlite/src/qsql_sqlite.cpp 2010-07-31 18:12:24.0 +0200 +++ ./qsqlite/src/qsql_sqlite.cpp 2010-09-08 15:23:16.152896580 +0200 @@ -323,7 +323,6 @@ setSelect(false); -Q_ASSERT(SQLITE_VERSION_NUMBER == 3006023); #if (SQLITE_VERSION_NUMBER = 3003011) //int res = sqlite3_prepare16_v2(d-access, query.constData(), (query.size() + 1) * sizeof(QChar), // d-stmt, 0); 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: BIC in libkonq
On Wednesday 04 of August 2010 18:01:27 Modestas Vainius wrote:
Hello,
On trečiadienis 04 Rugpjūtis 2010 15:09:32 Lubos Lunak wrote:
fact exactly the opposite. They both state that some libraries, by
design, do not keep binary compatibility, and that when a change
happens, soname should be changed.
The latter is exactly my point. libkonq 4.5 is BIC in comparison with
libkonq 4.4 and soname was NOT bumped (when should have). So what is
opposite there to my arguments?
In this case, our arguments were apparently discarded because making
an exception for libkonq doesn't make that much sense.
to me is missing at the end of that sentence. And, while I'm at it,
the
consequent any other opinions? is missing too.
Do I decide what ends up in tarballs? No. Things which do not make much
sense are typically not done. So conclusion is that nothing would have
been done wrt kdebase.
Given that there is still a week until 4.5.0, we may find all those BIC
cases and fix them in 4.5 by bumping soname where needed. Would there be
any objections to that? I think this question is on-topic for release-team
ML.
I admit it may be a
bit late as we do not package pre-releases nowadays (which may be our
fault but that's the way it is for now). Therefore, I cannot be in
supervisor position for these things until it is too late nor anybody
would listen to me.
Oh, poor you. But in case you'll get over this attitude and will be
interested in fixing the problem, you've been told where the right place
to discuss the problem is.
Thank you for suggestion. Maybe I will try again. Though even if you do not
agree, this has already been brought up on that list a couple of times
before and I can't say that situation has improved much over time. Yes,
libkonq has not broken BC during 4.x cycle before, but many others
non-kde(pim)libs did. In neither case soname was bumped with a good
exception of libplasma when it was in workspace and moved to kdelibs
(libplasma.so.{1,2,3}).
It's probably that the topic is not important or considered as not worth
the extra effort by majority of developers, so I don't expect situation to
improve greatly despite conclusion on k-c-d. It's not me, you or
release-team who can fix all cases each release. What's more, I'm also
afraid that when pushing too hard people might start doing otherwise for
the sake of extra safety - bump soname in advance as soon as trunk opens
without checking if changes are BC or not. Tracking BC is not an easy
task.
It is not. It should be done by developers themselves when they introduce
features, change code.
But.. such changes happen frequently in trunk (before next branching and after
previous one) so developers would need to either bump SOVERSION every time
they change ABI (hardly optimal, you'd end up with libplasma.so.50 early) or
postpone SOVERSION bump just before tagging for all libraries with public
interface that had their ABI changed. In the second case it's easy to forget
about it.
Also developers usually don't have tools to reliably detect ABI changes - but
disto devs sometimes do.
That being said, those equipped with sufficient tools - if possible - could
run their tool just before tagging and list all libraries with public
interface that need SOVERSION bump on kde-core-devel or kde-buildsystem ml
(but that would mean the need to package RC's in Debian I suppose? no idea
whether other distros have such means).
--
regards
MM
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: Unannounced optional runtime dependency for SC 4.5: Cagibi 0.1 in kdesupport
On Tuesday 13 of July 2010 23:04:26 Friedrich W. H. Kossebau wrote: Hi, due to a broken laptop and other real life circumstances I completely missed to announce in time another, while optional and at runtime, dependency for the SC 4.5 release, for the network:/ kio-slave in kdebase/runtime/kioslave/network: Cagibi 0.1(.0) from kdesupport (tagged in /tags/cagibi/0.1.0) Cagibi is a daemon for SSDP (the discovery part of UPnP) and, if accessable via D-Bus, used to also show UPnP devices/services in the network:/ kio-slave listings, otherwise silently ignore that data source. If the url info is present, a click on the UPnP device/service item will forward the user to the web interface of the respective device/service, e.g. of the router or media server. There is no cmake check (yet), as I had no idea how to test for a service only accessed via D-Bus (direct D-Bus calls, no D-Bus api xml installed yet to test for). So you won't have noticed this dependency from the builds. I (and some users) might be happy if you still consider adding Cagibi as official optional dependency, also by adding it to tags/kdesupport-for-4.5 :) If not, no harm is done, but it would be good to get this stuff out in I'm afraid you would need to release official cagibi source tarball to have it considered by distro packagers (especially before adding it as a buildsystem dependency). Until then likely nobody is going to pick it up. cheers -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)
Hello From what I understand, Plasma in KDE4 Workspace 4.5 relies on notifications provided by libdbusmenu-qt to control what to draw in system tray. And apparently Qt = Qt-4.6.2 contains known bug that causes 'close application' notifications not to be delivered - as a result causing system tray regressions - application icons not disappearing. https://bugs.kde.org/show_bug.cgi?id=232915 https://bugs.kde.org/show_bug.cgi?id=195998 https://bugs.kde.org/show_bug.cgi?id=241248 and similar reports. Because it's quite visually exposed and obvious bug (confirmed to be solved with mentioned Qt upgrade), I propose bumping Qt requirements to 4.6.3 for 4.5 branch and trunk for whole KDE SC release (currently it requires Qt 4.6.0). -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)
On Thursday 08 of July 2010 17:51:31 Andreas Pakulat wrote: On 08.07.10 17:36:09, Maciej Mrozowski wrote: Hello From what I understand, Plasma in KDE4 Workspace 4.5 relies on notifications provided by libdbusmenu-qt to control what to draw in system tray. And apparently Qt = Qt-4.6.2 contains known bug that causes 'close application' notifications not to be delivered - as a result causing system tray regressions - application icons not disappearing. https://bugs.kde.org/show_bug.cgi?id=232915 https://bugs.kde.org/show_bug.cgi?id=195998 https://bugs.kde.org/show_bug.cgi?id=241248 and similar reports. Because it's quite visually exposed and obvious bug (confirmed to be solved with mentioned Qt upgrade), I propose bumping Qt requirements to 4.6.3 for 4.5 branch and trunk for whole KDE SC release (currently it requires Qt 4.6.0). This has already been discussed and as a compile-time requirement doesn't make a runtime-requirement its been dis-approved (in fact this exact bump was made, discussed afterwards and reverted again (see r1135987 and r1136437 in kdelibs). IIRC the discussion was on kde-core-devel. Fair enough. Bug wranglers at bugs.kde.org won't appreciate such explanation though: Revert r1135987: the build-time dependency should only be a minor release of Qt (4.6) not a patch-level release (4.6.3). Qt maintains forward and backward binary compatibility within minor releases, so the patch-level releases are completely interchangable at runtime. People should aim to use the latest patch-level release anyway in order to get bugfixes. The question is: who cares whether Qt minor releases are interchangeable or not so that we can just specify minimal required dependencies to ensure only that stuff compiles? the build-time dependency should only be a minor release of Qt - is this policy written anywhere? Why is it more important that code compiles than providing better user experience? I think it's fundamental question. If one of goals of KDE community is striving to provide the best user experience by any means necessary and if bumping version of dependencies is guaranteed to help here for many users compiling KDE from source and actually giving a hint for packagers, maybe it should be doneTM. Also, as a potential bug reporter, I couldn't really accept such bug reports being RESOLVED (doesn't matter whether UPSTREAM or WONTFIX), because what it actually means is dontcaregoaway. Such bugs reports are valid because they're filled against properly built package (with respect to its build dependencies). It helps alienating community. cheers -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)
On Thursday 08 of July 2010 19:28:01 Thiago Macieira wrote: On Thursday 8. July 2010 18.42.36 Maciej Mrozowski wrote: The question is: who cares whether Qt minor releases are interchangeable or not so that we can just specify minimal required dependencies to ensure only that stuff compiles? the build-time dependency should only be a minor release of Qt - is this policy written anywhere? Why is it more important that code compiles than providing better user experience? I think it's fundamental question. The build-time requirement doesn't influence the run-time requirement of Qt. You can compile against 4.6.3 and then run against 4.6.0. So requiring 4.6.3 to compile will NOT get your bug solved. I disagree but let me explain. Someone fetches KDE tarballs. Tries to build them - then encounters build error stating that Qt dependencies are not met. Person in question upgrades Qt, then builds KDE and problem has been solved by avoiding it. If person in question is distro packager, he does the same, but he also ensures that runtime dependencies of packages he's preparing are matching build time dependencies. So problem has been avoided as well (note that KDE SC 4.5.0 is not out yet and number of bug reported already is significant). If said person purposely hacks buildsystem to allow older Qt version - he should be ready to grab the pieces. The only case when bug is not solved. You need to convince your distro to upgrade. And all KDE has to do is to say that distros should upgrade. And that should go without saying that distros should always upgrade. And they do. So what are you complaining about? Bug reported - ceck Bug fixed - check Distros upgrading - check Right. But those users who will go through this exact same procedure over and over AGAIN. Because: - they weren't told Qt-4.6.2 is broken in this regard (why would they? they just grab packages and build from source against whatever Qt version they happen to have) or - packager who prepared packages for them was not told Qt-4.6.2 is broken in this regard. So the only reliable way for them to find out is to personally experience bug, fill it (or seach bugzilla first), then be told to go away and complain elsewhere (usually distro). And all of this could have been avoided if dependencies were raised in first place. (and some people say it's distros that work like it compiles - release) Now, it's been enough noise already so most distro packagers are probably aware that current Qt dependencies for 4.5 are not what's supposed to be used actually, but there will always be people building from source manually. cheers -- Maciej Mrozowski Gentoo KDE release coordinator 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
New (optional but preferred) dep introduced in 4.5 - Opentts
As of July 2nd, kdeaccessibility/jovie introduces new optional (but preferred when both Speechd and Opentts are found) dependency in 4.5 branch (and trunk) - Opentts. No that it's any problem for me as a packager, but I thought introducing new dependencies that late (after May 11th: Dependency Freeze) should require exemption[1] or at least public announcement. 1. http://techbase.kde.org/Schedules/KDE4/4.5_Release_Schedule#May_11th:_Dependency_Freeze -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Observations and personal conclusions on the KDE release process since 4.0
On Wednesday 30 of June 2010 20:23:18 Simon Edwards wrote: The main issues for this cycle, IMHO, have been: * branches - Things being branched off earlier than expected, or work branches being merged later in the process make it harder to keep track of what exactly is going to be in 4.5. My thoughts exactly. But it's not only that. Why do you guys branch off before minor release? (4.x.0). Time between rc1 and release is important as important fixes usually are commited in this period. And while trunk and recently branched off code doesn't really differ much, any fixes *have* *to* be applied to both branches, otherwise trunk will be affected again. And while back/forward porting fixes is troublesome I suppose some fixed simply don't make it to both branches (forgotten, people being unaware of the need to fix both branches etc). Branching off relatively late (maybe even after minor release, not tagging, just in any case) would also (hopefully) mean a little shift towards maintenance from new features seemingly forcing developers to focus on polishing not-yet-released version instead of working in trunk. (which I believe may upset many developers and they'll choose to work in playground/local branches nevertheless). -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4.2 tarballs (try #1) uploaded
On Saturday 27 of March 2010 13:43:18 Eric Hameleers wrote: On Fri, 26 Mar 2010, Dirk Mueller wrote: I just finished uploading the first set of KDE 4.4.2 tarballs. Please let me know of any issues that you might experience. Intended release date is next week Tuesday/Wednesday (I'm sorry that I'm a day late with tagging). The kdebindings tarball fails to build with this error: [ 91%] Building CXX object python/pykde4/CMakeFiles/python_module_PyKDE4_kutils.dir/sip/kutils/sipkuti lspart7.o Linking CXX shared library ../../lib/pykde/kutils.so [ 91%] Built target python_module_PyKDE4_kutils [ 91%] Generating sip/nepomuk/sipnepomukpart0.cpp, sip/nepomuk/sipnepomukpart1.cpp, sip/nepomuk/sipnepomukpart2.cpp, sip/nepomuk/sipnepomukpart3.cpp, sip/nepomuk/sipnepomukpart4.cpp, sip/nepomuk/sipnepomukpart5.cpp, sip/nepomuk/sipnepomukpart6.cpp, sip/nepomuk/sipnepomukpart7.cpp sip: QDebug is undefined make[2]: *** [python/pykde4/sip/nepomuk/sipnepomukpart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_nepomuk.dir/all] Error 2 make: *** [all] Error 2 I am building against sip 4.10.1 and kde-qt 4.6.2-patched CC-ing people interested in getting it fixed. -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KPixmapCache breakage
On Thursday 25 of March 2010 03:27:31 Michael Pyne wrote: Hey all, My crash fix for 182026 fixed the crash but made the actual caching of pixmaps stop working. No one noticed which means either we probably don't actually need the cache in a lot of scenarios, or the memory-based cache is enabled by default (probably the latter but I'm too impatient to verify). Anyways, the problem was noticed by Parker Coates and is now fixed (hopefully for real this time) but when kdelibs is tagged please make sure you include revision 1107210 to ensure that the regression is not introduced into a release. Thanks and sorry for the issue. There is also other issue - kdelibs from 4.4 branch does not compile at the moment. There were a few recent kdelibs/kate backports to 4.4 branch: 1107144, 1107146, 1107147, 1107148 (the one that breaks compilation) and 1107150. Some of them look suspicious and may need review (apart from fixing the build) before tagging. -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thursday 21 of January 2010 12:22:43 Richard Dale wrote: I don't think we need a strict ban. I think the problem is that the kde bindings release schedule is unavoidably slightly behind the KDE libraries release schedule. However, the overall KDE release schedule doesn't take this into account. Certainly we didn't need the KDE 4.4 release to be branched off from the trunk a month before the actual release, while we are right in the middle of trying to sort out kdebindings. Not to mention that 4.4 branch actually suffers from the fact it's being created so early as not everyone is willing to backport all changes from trunk (and some changes cannot be backported) which means some developers are already commited to work in trunk in many cases while 4.4 is not even released yet. -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [PATCH] Making Soprano optional (again) in kdelibs
On Tuesday 29 of December 2009 13:50:12 Sebastian Kügler wrote:
On Sunday 27 December 2009 14:34:23 Maciej Mrozowski wrote:
While keeping if (NEPOMUK_FOUND) and alike CMake code is considerable
maintenance cost - this cost has already been born so there's nothing
else
to do for 4.4 (and dropping this code to simplify CMake files relying
on the fact that Nepomuk libs being mandatory would cause another
maintenance cost).
Wrong, keeping ifdef's brings long-term testing and maintainance costs, as
you basically get two branches in one code base, which means that testing
for each of those branches is cut down, and some new code has to be
written for two scenarios. That's why we try to reduce these cases to an
absolute minimum.
That's of course true and I agree (still making such change for 4.4 is risky
as it's easy to break something in the process and time is running out).
One little problem remains - in case no one noticed - *KDE* *SC* is now (as of
4.4) *officially* *the* *first* *Desktop* *Environment* *in* *the* *history*
*that* *requires* *two* *full*-*blown* *relational* *database* *servers*
*running*.
While Nepomuk has been made to need SPARQL-aware storage and it actually
stores real *data*, choosing relational database server (OpenLink Virtuoso in
this case) is somewhat justified.
Now *funny* part - Akonadi.
The *idea* is *great* - PIM resource access abstraction layer.
Let's try to justify the use of relational database server.
Applications' configuration used to be stored in KConfig and indeed there are
some akonadi_ xxx_resource_xxx* files in ~/.kde/share/config
Akonadi server is pure Qt4 application so can't use KConfig probably, but in
${XDG_CONFIG_HOME}/akonadi there are ini files so it is possible not to use
database to store configuration application, apparently..
Akonadi developers think otherwise as nearly all tables in akonadi database
are used to store... *configuration* like resource mappings, mimetypes, flags,
various properties, achieving impressive number of 11 1NF compliant (a few
exceptions) relations with just one (parttable) storing anything *relevant* -
actual data.
Sort of - as it's cache actually as data persistency is elsewhere.
Cache = temporary, *volatile* data, implemented by some proxy layer -
introduced only to gain performance, let me remind.
So... considering there are so many disk database systems (like berkdb, gdbm)
I can't find any justification for adding complexity by relying on full-blown
SQL database for storing configuration (11 tables is not 70, still it's
shooting a fly with cannon).
Also having larger relation count and in-database data integrity via foreign
keys is of course great excuse to dump SQLite and libmysqld (MyISAM) which is
otherwise ideal solution as it's embedded database (a'ka I don't need to care
about setting it up nor it drains significant amount of system resources).
Akonadi was probably initially meant to provide real storage and persistency
layer for PIM resources, code was written, and when it appeared it's not the
way to go, it was too late to get back. I would understand that (but only
that).
Also I think it's just a matter of time when someone finds konqueror browsing
history too slow with big history (that's actually fact - list seems to be
searched linearly - bug 206900) and decides to write relational database
backend for it (which is actually good idea provided small fast embedded
database is used) and then *totally* screws the design by overengineering it
by creating multiple relations with academic 3NF (or better) approach.
Then as a consequence thinking that SQLite is too silly for that purpose and
for instance preferring PostgreSQL with argumentation along the lines why
not, it's serious database server after all and I use it™.
Isn't it what Akonadi techbase indirectly says about MySQL (InnoDB)? Also
promptly noting lack of thread safely in SQLite despite the fact there's just
one akonadi server instance supposed to be run and the one is not supposed to
be shared among users as it's not groupware server.
I guess I'll start writing konqueror history backend using PostgreSQL
exclusively (dfaure won't let me sad panda/fortunately),
Klipper probably needs some good backend too - SQL is trendy nowadays and I
heard IBM Db2 is good. Screw common sense - *who* *does* *the* *job* -
*decides*, it's never too many database servers running in user's desktop
environment.
I think all above justifies my actions towards making Nepomuk (and thus
virtuoso) not mandatory wherever possible.
What are your *specific* problems with the soprano dependency?
This has been fixed by making Soprano check non-fatal.
It's been laid out in initial email to kde-buildsystem:
quote
Now, in kdelibs there's a little inconsistency with Nepomuk related CMake
options logic:
- Soprano is always required (unnecessarily)
- SDO is optional
- Nepomuk libs are built when both Soprano
Re: [PATCH] Making Soprano optional (again) in kdelibs
On Tuesday 22 of December 2009 21:32:29 Alexander Neundorf wrote:
Now, in kdelibs there's a little inconsistency with Nepomuk related
CMake options logic:
- Soprano is always required
- SDO is optional
- Nepomuk libs are built when both Soprano (with all needed backends
and parsers) and SDO are found
Proposals (patch):
- find_library(Soprano) - macro_optional_find_library(Soprano) keeping
Soprano backend checks (so only Soprano with all needed backends is accepted)
- other minor changes in FindNepomuk.cmake:
* set url in macro_log_feature of Soprano to
http://soprano.sourceforge.net/
* accidental trailing spaces removals
Other proposal - to make SDO mandatory
Actually I'd almost suggest make all that manadatory (soprano, SDO 0.2,
nepomuk), and if people scream, at least we maybe finally get to some real
solution. Right now it is just broken if nepomuk is optional but a hard
requirement in kdepim.
Actually one of those people screaming would be me :)
From my perspective it's much more convenient to have Nepomuk libs (and thus
soprano and SDO dependencies) optional for 4.4 as well.
Besides the only tool in kdepim that needs Nepomuk libs to build is mentioned
akonadiconsole which is more or less developer tool and not user application
and at least in current state - akonadi can live without Nepomuk QueryServer.
Also, one would argue but kdepim used to be quite standalone product (not part
of KDE4 Workspace, actively maintained also for KDE 3.5), so imho there's no
need to force some dependency for kdelibs only because it's mandatory in
kdepim.
While keeping if (NEPOMUK_FOUND) and alike CMake code is considerable
maintenance cost - this cost has already been born so there's nothing else to
do for 4.4 (and dropping this code to simplify CMake files relying on the fact
that Nepomuk libs being mandatory would cause another maintenance cost).
So I'm for
Or just ask for a comment on release-team@kde.org ?
Problem is, the last times I asked we didn't come to a real conclusion,
there were not too many people who answered...
In such case I guess it should be who does the job - decides.
(updated and reattached patch again as crossposting)
--
regards
MM
Index: cmake/modules/FindNepomuk.cmake
===
--- cmake/modules/FindNepomuk.cmake (revision 1066431)
+++ cmake/modules/FindNepomuk.cmake (working copy)
@@ -19,7 +19,7 @@
if (NOT DEFINED Soprano_FOUND)
find_package(Soprano)
include(MacroLogFeature)
- macro_log_feature(Soprano_FOUND Soprano Semantic Desktop Storing FALSE Soprano is needed for Nepomuk)
+ macro_log_feature(Soprano_FOUND Soprano Semantic Desktop Storing http://soprano.sourceforge.net/; FALSE Soprano is needed for Nepomuk)
endif (NOT DEFINED Soprano_FOUND)
if (NOT DEFINED SHAREDDESKTOPONTOLOGIES_FOUND)
@@ -64,9 +64,9 @@
mark_as_advanced(NEPOMUK_INCLUDE_DIR NEPOMUK_LIBRARIES NEPOMUK_QUERY_LIBRARIES NEPOMUK_ADDONTOLOGIES_FILE)
include(FindPackageHandleStandardArgs)
-# List all nepomuk and also all necessary soprano variables here, to make it
+# List all nepomuk and also all necessary soprano variables here, to make it
# easier for the user to see what was missing:
-find_package_handle_standard_args(Nepomuk DEFAULT_MSG
+find_package_handle_standard_args(Nepomuk DEFAULT_MSG
NEPOMUK_LIBRARIES NEPOMUK_INCLUDE_DIR NEPOMUK_ADDONTOLOGYCLASSES_FILE
Soprano_FOUND SOPRANO_PLUGIN_RAPTORPARSER_FOUND SOPRANO_PLUGIN_REDLANDBACKEND_FOUND
SHAREDDESKTOPONTOLOGIES_FOUND
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 1066431)
+++ CMakeLists.txt (working copy)
@@ -94,7 +94,7 @@
macro_log_feature(OPENGL_FOUND OpenGL API for developing portable, interactive 2D and 3D graphics applications http://mesa3d.sourceforge.net; FALSE STRONGLY RECOMMENDED: The 3D hardware acceleration available through the OpenGL API is used in applications ranging from graphics and modellers to screensavers and video players.)
set(SOPRANO_MIN_VERSION 2.3.70)
-find_package(Soprano REQUIRED COMPONENTS PLUGIN_RAPTORPARSER PLUGIN_REDLANDBACKEND)
+macro_optional_find_package(Soprano COMPONENTS PLUGIN_RAPTORPARSER PLUGIN_REDLANDBACKEND)
macro_log_feature(SOPRANO_FOUND Soprano Semantic Desktop Storing http://soprano.sourceforge.net; FALSE ${SOPRANO_MIN_VERSION} Provide metadata support (for semantic desktop).)
macro_log_feature(SOPRANO_PLUGIN_RAPTORPARSER_FOUND Soprano Raptor Parser RDF parser plugin for Soprano http://soprano.sourceforge.net; FALSE The Soprano raptor parser plugin is required to build the Nepomuk semantic desktop system.)
macro_log_feature(SOPRANO_PLUGIN_REDLANDBACKEND_FOUND Soprano Redland Backend Redland storage backend for Soprano http://soprano.sourceforge.net; FALSE The Soprano redland backend is required to build the
Re: branches/KDE/4.3/kdepim/kmail/icons
On Saturday 03 of October 2009 14:19:10 Thomas McGuire wrote: I think this change is wrong for the 4.3 branch. The 4.3 branch is supposed to use oxygen-icons from tags/kdesupport-for-4.3/kdesupport/oxygen-icons/, and I don't think those icons are in that oxygen-icons tag. I think this change should be reverted before tagging, as otherwise KMail from 4.3 branch will not have icons when used with kdesupport from the 4.3 tag. This shows that my question about oxygen icons tagging given to kdepim and oxygen developers over a weeks ago was quite in place. So... How does release plan for oxygen icons look like? Stable KDE releases are created by tagging 4.3 branch. Oxygen icons releases that accompany KDE stable releases (yes, there will be oxygen-icons-4.3.2, right?) are created by: - tagging kdesupport/oxygen-icons in trunk? (seems reasonable and seems to be de facto practice as well, explanation below) - or using *fixed* kdesupport-for-4.3 tag? I think those icons were removed exactly because they are now provided by trunk oxygen-icons and because they caused file collisions as reported by some packagers (like Pierre Schmitz recently and myself two weeks ago) which would mean - that 4.3.2 oxygen-icons release tagging follows kdesupport trunk (as opposite to being fixed to kdesupport-for-4.3). What's the desired approach here? Because it seems that what's supposed to be the practice (kdesupport-for-4.3 tag) is in fact just a theory. cheers MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
About tagging 4.3.1
About KDE 4.3.1 tagging. There are a few bugs apparently still present in 4.3 branch, do you think they are worth being blockers? https://bugs.kde.org/show_bug.cgi?id=202722 https://bugs.kde.org/show_bug.cgi?id=204605 Also there is some kdevelop crash that may have its origins in kdelibs https://bugs.kde.org/show_bug.cgi?id=204670 (apart from that, one minor issue with Notes plasmoid not being able to revert font color to 'Use theme color') -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: About tagging 4.3.1
On Thursday 27 of August 2009 21:50:44 Aaron J. Seigo wrote: they were in 4.3.0. they aren't blockers then, they aren't blockers now. it's more important to get fixes that -have- been made and do timely releases than wait for fixes that have yet to be made. Well, both bugs were reported after 4.3.0 was released and because I test only 4.3 branch I have no idea whether they were introduced after 4.3.0 (regressions), just before or present for a longer period of time (a'ka known). You apparently mean it's now more important to backport trunk fixes to 4.3 branch. While I always assumed they're being backported immediately after being commited to trunk - this way it would give more time for testings and catching issues earlier, thus making releases in more timely manner than what you seem to propose - backporting stuff now and expecting testers to catch in last minuete every possible problem introduced, not talking about fixing remaining issues. from announcement Dirk posted: We have a KDE 4.3.1 tagging milestone tonight at 23:59 UTC. If there are urgent bugs that must be fixed before 4.3.1, please tag them in bugs.kde.org with the kde-4.3.1-blocker keyword. -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Possible 4.3.0 blocker in the Konsole KPart?
On Tuesday 04 of August 2009 11:14:20 Aaron J. Seigo wrote: On Tuesday 04 August 2009, John Tapsell wrote: We still get lots of flack for the complete mess we made of 4.0 etc. i won't even argue the basis of your statement, but i will say that regardless of what anyone thinks about 4.0 it should not create subsequent paralysis and start us down a path of second-guessing and changing from the accepted release regimen. A high visibility bug like this will cause us even more grief. it's not high visibility. it's one odd visual artifact in konsole kpart usage when right clicking, and then only when you can see the top of the scroll area. it's not great, but it's hardly high visibility or of the sort that will cause us even more grief. A delay of a couple of days, on the other, people will understand. if we delayed for every bug of this magnitude, we'd never release [snip] Indeed, but unfortunately it as well sheds some light on amount of bugs actually introduced during development, and from downstream point of view it makes all 4.x.0 releases to be treated like development releases. Partially it's because KDE developers seem to be overloaded with amount of work - especially with multiple branches synchronization - which leads to bugfixes sometimes not hitting latest 'soon-to-be-stable' branch (4.3 now) or not hitting on time, as developers seem to be devoted to trunk (sometimes even when 4.3 in this case is not released). It gives a little bit of feel of being half-baked, and really makes in 'distro ready' with 3rd or 4th patch release, but I guess it's supposed to be like this? Fortunately, every next minor release is in general less problematic than previous one, so there is some quality-wise improvement. -- regards MM 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: 4.3.0 RC3
On Wednesday 22 of July 2009 16:08:00 Sebastian Kügler wrote: Hi all, Dirk added a fix for bug 200789 to the RC3 tarballs, they're now up. We'll release shortly (i.e. tonight as soon as I'm done with work-work). 4.3.0 has been postponed to 4th August. Cheers, Hi Is it possible to fix https://bugs.kde.org/show_bug.cgi?id=199840 before 4.3.0 is released as well? It's quite major regression - not working thumbnails view in dolphin due to segfaults in it's kioslave. Not sure whether you can reproduce it though. Also it would be nice to backport patch from https://bugs.kde.org/show_bug.cgi?id=198632 to 4.3 branch (although I could do it I guess) - it fixes installation location for some python modules from pykde4 that make it impossible to run for example system-config-printer-kde kcm module. We have it applied in Gentoo to 4.3 RC packages and I confirm it works. -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3 Beta2 tagged and tarballs uploaded (try#1)
On Wednesday 03 of June 2009 22:24:05 Ingmar Vanhassel wrote: At least kdebase-runtime [1], and kdebindings [2] fail here if I use the latest soprano release. Is soprano trunk required or will a soprano release follow? Further yet unstatisfied (but at least listed in CMakeLists.txt) dependencies for 4.3 seem to be: - yet unreleased eigen for kdeedu/step - yet unreleased sip/PyQt4 for pykde4 - trunk phonon for mplayerthumbs to work with phonon backend (and not mplyer executable - this one is optional though) If some of them are not going to be released before 4.3, well... packagers (for source based distros at least - eigen is purely build time dependency so may not bother binary distros) may need to either hold 4.3 releases or release snapshots of dependencies on their own. -- regards MM 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
A Friday 27 March 2009 23:49:32, Sebastian Kügler escreveu: I don't really see why putting Oxygen into kdesupport would mean that users get updates more often. I think it'll work the other way, branch is shipped every month, that means improvements to Oxygen can be shipped to the user usually in less than four weeks. By putting in them kdesupport (which is less visible and might not be updated by packagers along with a x.y.z release) the likely effect is that Oxygen is overall updated *less* often. I guess it's not the case here, as distributions usually follow weekly unstable snapshots as well, so it's very unlikely they will miss Oxygen icons release. On Saturday 28 of March 2009 01:27:58 Nuno Pinheiro wrote: Well my issue is another as nothing to do with the issues so far. its about control, we are creating a new kde3.x mess couse aplications are creating their hown versions of the same icons, and not teling any one they do so, couse well they dont have 2. second i have alrady done a couple of duplicated icons with slightly difrent names couse well i forgot i did icon a for app B and icon c for app D and a=c just that they dont. i have no idea of how many icons we have done so far no idea of what apps are using couse its out of the oxygen directory its scatered all around kde svn. 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. The idea, of frequent updates to Oxygen icons in kdesupport (and frequent releases) - will work and will give this control over icon distribution - provided backward compatibility issues with 4.2.x and 4.3.x regarding icons are resolved, and provided 3rd party (extragear/plasma and other as well) KDE application developers will respect that way of distributing them. (in short, any icon missing or report about icon being duplicated - contact Oxygen team - icon set updated and released in weekly manner as usual or sth like this - so that in effect every Oxygen icon create is in kdesupport/oxygen-icons) -- regards MM 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
A Friday 27 March 2009 23:49:32, Sebastian Kügler escreveu: I don't really see why putting Oxygen into kdesupport would mean that users get updates more often. I think it'll work the other way, branch is shipped every month, that means improvements to Oxygen can be shipped to the user usually in less than four weeks. By putting in them kdesupport (which is less visible and might not be updated by packagers along with a x.y.z release) the likely effect is that Oxygen is overall updated *less* often. And KDE packagers could use the same weekly manner of automatic packaging oxygen icons along with unstable (SVN) snapshots (so called 4.2.67 etc) -- regards MM 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 and Qt 4.4 and qt-copy patches
On Thursday 22 of January 2009 22:02:45 Olivier Goffart wrote: I sent an email in reply to dfaure, but it doesn't seems to have reached the mailing list. There is a notes in the qt-copy patches saying if they are included in Qt 4.4 branch. (or Qt 4.5, or none) Only released version are suported by QtSoftware support. But the point is that, for the KDE 4.2 release, there will be no released version of Qt containing some fixes that are very important for KDE stability. (Hence my email) Hi Is there any progress on that matter? I'm one of Gentoo packagers, and we really would like to know which patches are recommended for 4.4 for distributions (from KDE4 point of view) - as there's no further release planned in that line. So far we apply: 0248, 0254, 0256, 0262, 0263, and 0265 I guess all now-in-4.4-branch and now-in-4.5 should be safe but we would like not to guess. For example I found latest qt-copy patch (systray fix) - one of the most requested - only worsening situation (btw I don't need to rebuild whole KDE to make this patch work, do I?) -- regards MM -- Obdaruj swoja Walentynke ... lub siebie! Wygraj nagrody! Sprawdz http://link.interia.pl/f203a ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
question regarding packaging of kdebase
Hi Are there any plans to drop kdebase module (like kdebase.tar.bz2) and distribute is as kdebase-apps? So far, two submodules - runtime and workspace - have been extracted as kdebase-runtime and kdebase-workspace respectively. kdebase currently contains only apps/ sudirectory and some dummy CMakeLists.txt with add_subdirectory(apps) section only (as exported directly from SVN only to make it build together with other kdebase modules). It's not a problem really (for downstream packagers) just a little inconvenience. And it would be possibly easier to prepare - just svn export from /kdebase/apps/ -- regards MM Dzwon tanio do wszystkich! Sprawdz http://link.interia.pl/f200a ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
