Re: Possible problems with Intel drivers in 4.5.0 release
Martin, what you need to test ? I have a notebook with this current issue ( Fedora 13 ) and happens that even Meego SDk not works anymore, so is indeed a Intel issue. I have another machine to test, desktop, but remote one. []'s Em Segunda-feira 02 Agosto 2010, às 15:59:24, Martin Gräßlin escreveu: > Hi Release-Team, > > I know that the release is scheduled for tomorrow, nevertheless I want to > make > you aware of a possible problem with Intel graphics cards and compositing. > > I think I first have to explain a little bit: KWin uses a test to determine > if > OpenGL compositing is working during the startup. This seems to fail for some > Intel drivers since some time. It used to work and the code has not changed, > so it is most likely a driver bug. I was first made aware of this problem at > Akademy. Due to the fact that I do not own Intel hardware I was unable to > reproduce or try to fix the issue. > > Up to 4.4 KWin just disabled compositing if this check during startup failed. > In the 4.5 development cycle it was changed to fall back to XRender > compositing. The idea behind it was that you get translucancy when starting > from live cd or running in a virtual machine. It was not meant for the case > that the OpenGL driver causes an incorrect self check failure. > > This fallback to XRender causes slowness of the system and some effects not > working. Furthermore the complete UI says that it is using OpenGL compositing > although in truth XRender is used. > > When I was made aware of this problem with Intel drivers I reverted the > fallback to XRender both in trunk and branch (svn revs 1148315 and 1148316). > Unfortunately I missed one change (the original commit changed more than just > the fallback) which I found by pure luck this weekend (svn commit 1157978). > It's confirmed that this commit is now finally working: compositing is > disabled at startup. By disabling the functionality checks in the advanced > compositing preferences it is possible to get OpenGL compositing working > again. > > Now the question is what to do with this commit. Due to the fact that I > missed > this one line KWin is now saying that it disables compositing but in truth is > falling back to XRender. I see three possible solutions: > > 1. We ignore it. This might result in many complaints about slow KWin and > that > effects are not working any more (e.g. cube, coverswitch, blur, etc.). We > will > have many complaints about slow KWin anyway due to the enabling of blur and > the fact that many drivers are too bad for it. On the other hand we had no > bug > report to this issue. I only heard about this problem by fellow KDE > developers, which might be related to the fact that we have more recent > drivers/Xorg than most of our users. > 2. We backport this patch to 4.5.0. This means a lot of work due to the > schedule (sorry for writing that late, I had to think about this issue for > one > day) and will cause users not be able to use desktop effects any more. But it > would be the cleanest one. > 3. We backport to 4.5.1. This would mean a behavior change between 4.5.0 and > 4.5.1 which I would not like. > > To summarize: I am not happy with any of the three options I came up with. > And > I do not know what to do about it. Given that the release is tomorrow I guess > it's only possible to choose between option 1 and 3, while I think option 2 > would be the best. I think it's better to disable compositing instead of slow > compositing. So the question is, if we should backport the commit for 4.5.1. > > The best solution would be to fix the failing self check. But due to missing > hardware I am not able to investigate it. > > Sorry for writing that late > Martin Gräßlin > -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
Hello, On antradienis 03 Rugpjūtis 2010 00:22:54 Dirk Mueller wrote: > On Monday 02 August 2010, George Kiagiadakis wrote: > > Hello, > > > > While packaging KDE 4.5.0 I noticed that libkonq is BIC due to [1]. I > > am wondering why there was no SONAME bump for this. Actually, I was > > about to add a local patch to bump SONAME from 5 to 5a when that came > > into discussion with Tom Albers, who suggested to bring this here. > > Obviously, it is better if this SONAME bump is done upstream. What do > > you think? > > Good point. we should bump it to version 6? Yes, one of the main SONAME purposes is to manage BIC changes. Unfortunately, libraries outside kde(pim)libs break BC all the time but rarely ever bump SOVERSIONs (for example, kdebase-workspace libraries). Hopefully, such a bump in libkonq would set a good example for the future. -- Modestas Vainius 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 Monday 02 August 2010, George Kiagiadakis wrote: > Hello, > > While packaging KDE 4.5.0 I noticed that libkonq is BIC due to [1]. I > am wondering why there was no SONAME bump for this. Actually, I was > about to add a local patch to bump SONAME from 5 to 5a when that came > into discussion with Tom Albers, who suggested to bring this here. > Obviously, it is better if this SONAME bump is done upstream. What do > you think? Good point. we should bump it to version 6? Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: l10n packages tagged from trunk
On Monday 02 August 2010, Johannes Obermayr wrote: > I noticed that tags/KDE/4.5.0/l10n-kde4 is tagged from trunk/l10n-kde4. Whoops, indeed. I'll redo the tarballs for kde-l10n now. > I alarmed Dirk three times (within ~ 30 hours) on #opensuse-kde but it > seems it does not matter for him (no answer). :-( I'm not reading irc backlog in all that detail, but I do respond to email (also arrives at my mobile ;-) ). Thanks for letting me know, Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: l10n packages tagged from trunk
A Dilluns, 2 d'agost de 2010, Johannes Obermayr va escriure: > (Sorry for 2nd posting. But release-team does not have a kde- prefix ...) > > Hi, > > I noticed that tags/KDE/4.5.0/l10n-kde4 is tagged from trunk/l10n-kde4. Dirk, can you please fix this? And can we freeze the release until this is fixed? Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Saturday 31 July 2010 21:07:38 Volker Krause wrote: > On Thursday 29 July 2010 14:09:45 Dirk Mueller wrote: > > Hi, > > > > I just finished uploading the first set of KDE 4.5.0 tarballs to > > stable/4.5.0/src. Please let me know of any blocking issues (JRiddels PyQt > > 4.7 fix is not yet included I believe). > > > > kde-l10n tarballs are still building. > > I've uploaded the corresponding Akonadi server 1.4.0 tarball to > download.akonadi-project.org. CMakeLists.txt referenced to doc subdir, but this directory not exist in package -- Dima "Red Fox" Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter: fluffy_khv | Skype: dima.panov | Jabber.[org|ru]/GTalk/QIP: fluffy.khv 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
l10n packages tagged from trunk
(Sorry for 2nd posting. But release-team does not have a kde- prefix ...) Hi, I noticed that tags/KDE/4.5.0/l10n-kde4 is tagged from trunk/l10n-kde4. Pano checked the German tarball [1] for me and noticed the same. Thanks Pano. I alarmed Dirk three times (within ~ 30 hours) on #opensuse-kde but it seems it does not matter for him (no answer). :-( Johannes [1] https://build.opensuse.org/package/files?package=kde4-l10n&project=KDE%3ADistro%3AFactory ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Possible problems with Intel drivers in 4.5.0 release
Hi Release-Team, I know that the release is scheduled for tomorrow, nevertheless I want to make you aware of a possible problem with Intel graphics cards and compositing. I think I first have to explain a little bit: KWin uses a test to determine if OpenGL compositing is working during the startup. This seems to fail for some Intel drivers since some time. It used to work and the code has not changed, so it is most likely a driver bug. I was first made aware of this problem at Akademy. Due to the fact that I do not own Intel hardware I was unable to reproduce or try to fix the issue. Up to 4.4 KWin just disabled compositing if this check during startup failed. In the 4.5 development cycle it was changed to fall back to XRender compositing. The idea behind it was that you get translucancy when starting from live cd or running in a virtual machine. It was not meant for the case that the OpenGL driver causes an incorrect self check failure. This fallback to XRender causes slowness of the system and some effects not working. Furthermore the complete UI says that it is using OpenGL compositing although in truth XRender is used. When I was made aware of this problem with Intel drivers I reverted the fallback to XRender both in trunk and branch (svn revs 1148315 and 1148316). Unfortunately I missed one change (the original commit changed more than just the fallback) which I found by pure luck this weekend (svn commit 1157978). It's confirmed that this commit is now finally working: compositing is disabled at startup. By disabling the functionality checks in the advanced compositing preferences it is possible to get OpenGL compositing working again. Now the question is what to do with this commit. Due to the fact that I missed this one line KWin is now saying that it disables compositing but in truth is falling back to XRender. I see three possible solutions: 1. We ignore it. This might result in many complaints about slow KWin and that effects are not working any more (e.g. cube, coverswitch, blur, etc.). We will have many complaints about slow KWin anyway due to the enabling of blur and the fact that many drivers are too bad for it. On the other hand we had no bug report to this issue. I only heard about this problem by fellow KDE developers, which might be related to the fact that we have more recent drivers/Xorg than most of our users. 2. We backport this patch to 4.5.0. This means a lot of work due to the schedule (sorry for writing that late, I had to think about this issue for one day) and will cause users not be able to use desktop effects any more. But it would be the cleanest one. 3. We backport to 4.5.1. This would mean a behavior change between 4.5.0 and 4.5.1 which I would not like. To summarize: I am not happy with any of the three options I came up with. And I do not know what to do about it. Given that the release is tomorrow I guess it's only possible to choose between option 1 and 3, while I think option 2 would be the best. I think it's better to disable compositing instead of slow compositing. So the question is, if we should backport the commit for 4.5.1. The best solution would be to fix the failing self check. But due to missing hardware I am not able to investigate it. Sorry for writing that late Martin Gräßlin 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
branches/KDE/4.5/kdebase/workspace/powerdevil/daemon
SVN commit 1158370 by rjarosz:
Use same default value as in GUI, otherwise profiles from KDE 4.4 will use
aggressive power saving, which will park hard disk heads every 5 seconds or so.
If it's possible please put it into KDE 4.5.
CCMAIL: muel...@kde.org
CCMAIL: release-team@kde.org
M +1 -1 PowerDevilDaemon.cpp
--- branches/KDE/4.5/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp
#1158369:1158370
@@ -388,7 +388,7 @@
Solid::Control::PowerManager::setBrightness(settings->readEntry("brightness").toInt());
d->brightness = settings->readEntry("brightness").toInt();
-
Solid::Control::PowerManager::setPowerSave(settings->readEntry("setPowerSave",
true));
+
Solid::Control::PowerManager::setPowerSave(settings->readEntry("setPowerSave",
false));
// Compositing!!
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
PATCH: Fix severe speed regression when sending emails with KMail
Hello,
we have by accident introduced a bad regression in kdepimlibs in the 4.5
branch. The effect of that regression is that sending a mail can take quite a
long time, during which the GUI is blocked, up to several minutes.
We have fixed this issue in the 4.5 branch with revision r1156791 [1], which
was to late for the 4.5.0 tag.
The problem happens for KMail 1 (from the 4.4 branch) in combination with
kdepimlibs from the 4.5 branch.
Please include this patch in your packages. It is also attached to this mail,
for you convenience.
Dirk: Can you also please add the commit to the tag?
Technical background: Before sending a mail, KMail looks if any of the
recipients is a nickname or a contact group, to transform those to real
addresses. For those, we use a lookup/search in the Nepomuk database. By
accident, we used a regexp/contains search, instead of an exact match search,
which would have been sufficient. Apparently, Nepomuk/Virtuoso is quite slow
for regexp/contains searches, which is where the speed regression came from.
The patch restores the correct behaviour of doing an exact match search.
Regards,
Thomas McGuire
[1] http://websvn.kde.org:80/?revision=1156791&view=revision
Index: akonadi/contact/contactsearchjob.cpp
===
--- akonadi/contact/contactsearchjob.cpp (revision 1156790)
+++ akonadi/contact/contactsearchjob.cpp (revision 1156791)
@@ -50,7 +50,7 @@
void ContactSearchJob::setQuery( Criterion criterion, const QString &value )
{
- setQuery( criterion, value, ContainsMatch );
+ setQuery( criterion, value, ExactMatch );
}
void ContactSearchJob::setQuery( Criterion criterion, const QString &value, Match match )
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: [UPDATE] Re: KDEPIM 4.5 Planning
On Monday 02 August 2010, Allen Winter wrote: > would you be able to create kdepim4.5-beta2 and kdepim4.5-runtime-beta2 > with the KDE 4.5.0 release? anytime this week will be fine. If not, I can > do the betas. sure, I'll do them tomorrow morning. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Monday 02 August 2010, Eric Hameleers wrote: > Apparently this email originated outside of kde-packager mailing list. > I have no previous email about this conversation, so I would like to > know what this is about, and whether it is useful to rebuild my > 4.5.0 kdebase-workspace package for these two commits? This commit fixes a compile issue with gcc < 4.3. if you don't run into the compile issue, feel free to ignore it. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
BIC in libkonq
Hello, While packaging KDE 4.5.0 I noticed that libkonq is BIC due to [1]. I am wondering why there was no SONAME bump for this. Actually, I was about to add a local patch to bump SONAME from 5 to 5a when that came into discussion with Tom Albers, who suggested to bring this here. Obviously, it is better if this SONAME bump is done upstream. What do you think? Regards, George [1]. http://lists.kde.org/?l=kde-commits&m=126450750728231&w=2 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [UPDATE] Re: KDEPIM 4.5 Planning
On Wednesday 07 July 2010 4:58:24 am Dirk Mueller wrote: > On Wednesday 07 July 2010, Allen Winter wrote: > > > > KDEPIM Developers: Thomas will re-branch a 4.5 from trunk tomorrow > > > morning. Please do all your bug fixing for the 4.5 release in the 4.5 > > > branch -- no new strings without translator approval. > > I'm able to build those packages together with KDE releases, just let me > know. > Dirk, would you be able to create kdepim4.5-beta2 and kdepim4.5-runtime-beta2 with the KDE 4.5.0 release? anytime this week will be fine. If not, I can do the betas. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Mon, 2 Aug 2010, Dirk Mueller wrote: > Date: Mon, 2 Aug 2010 13:32:31 +0200 > From: Dirk Mueller > To: release-team@kde.org > Cc: kde-packa...@kde.org, Marco Martin , > Raphael Kubo da Costa > Subject: Re: KDE 4.5.0 tagged (1st try of tarballs uploaded) > > On Sunday 01 August 2010, Raphael Kubo da Costa wrote: > >> A workaround is to simply create the KConfig object before calling >> importLayout(), so that it is not passed as a temporary. I've committed >> revisions 1157732 (trunk) and 1157733 (4.5 branch) which fix the reported >> issue. >> > > Thanks. I've included this fix in the 4.5.0 tarball: > > a552e93b963879b97853fe5e4b699d27 kdebase-workspace-4.5.0.tar.bz2 > > Greetings, > Dirk Hi Dirk Apparently this email originated outside of kde-packager mailing list. I have no previous email about this conversation, so I would like to know what this is about, and whether it is useful to rebuild my 4.5.0 kdebase-workspace package for these two commits? Cheers, Eric -- Eric Hameleers Jabber: al...@jabber.xs4all.nl ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Sunday 01 August 2010, Raphael Kubo da Costa wrote: > A workaround is to simply create the KConfig object before calling > importLayout(), so that it is not passed as a temporary. I've committed > revisions 1157732 (trunk) and 1157733 (4.5 branch) which fix the reported > issue. > Thanks. I've included this fix in the 4.5.0 tarball: a552e93b963879b97853fe5e4b699d27 kdebase-workspace-4.5.0.tar.bz2 Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
