Re: CDash of kdelibs
On Thursday 21 July 2011 21:44:48 Alexander Neundorf wrote: > On Thursday 21 July 2011, Volker Krause wrote: > > On Wednesday 20 July 2011 21:51:43 Alexander Neundorf wrote: > > > Hi, > > > > > > Dave, if you find some time, could you please have a look at the issue > > > here, whether it behaves as it should with using CTEST_USE_LAUNCHERS ? A > > > link to a dashboard before and the new one with the launchers are below. > > > > > > On Wednesday 20 July 2011, Rolf Eike Beer wrote: > > > > Am Dienstag, 19. Juli 2011, 09:03:17 schrieb Volker Krause: > > > > > On Monday 18 July 2011 21:21:36 Alexander Neundorf wrote: > > > > > > Volker, are you still doing "make Nightly" ? > > > > > > > > > > well, something inbetween I guess, manual ctest calls but not using > > > > > the script in quality. > > > > > > > > > > > If so, this is quite limited and has a bootstrapping problem. > > > > > > Did you consider using the ctest scripts in svn in quality/ ? > > > > > > > > > > That didn't exist back when I set up this build (it's running for > > > > > more than 1.5 years now) I think :) > > > > > > > > Whatever you did two days ago it made things worse IMHO. There is the > > > > > > I wouldn't say it got worse. > > > Here you see the compile commands and I actually didn't see an occasion > > > where warnings for multiple files were mixed into one entry: > > > http://my.cdash.org/viewBuildError.php?type=1&buildid=210655 > > > You also see the command which was invoked > > > Not quite sure why it considers > > > "Generating parts.moc" a warning. Adding this to the exceptions regexp > > > should help here. > > > > I think we need a more general solution for that. If you look at e.g. the > > Akonadi build, you'll see it consideres an entire generated file as > > "warning". > > > > > The number of warnings changed from 2400 to 300, this seems a bit much. > > > Here is the "old" build: > > > http://my.cdash.org/viewBuildError.php?type=1&buildid=209926 > > > > Since it seems to combine all warnings for a file now, I think those > > numbers are plausible. Ie. the 300 is the number of files with warnings, > > not the total amount of warnings anymore. No idea if that's intentional or > > desired though. > > 300 is a lot, too much to keep an eye on. > Are there warnings which we want to have enabled, but we don't want to see > them on the dashboard ? > Probably for all moc and lex files, so we should add exceptions for those. > What about all the 'Ksomething' is deprecated warnings ? That's slightly more complicated than just filtering them out on CDash IMHO. Deprecation warnings are quite important, especially regarding the KDE Frameworks 5 efforts, those should obviously be fixed by porting away from the obsolete API. However, if you look at the kdelibs warnings, you'll notice that most of them are for K3Network classes used inside K3Network itself. That's obviously something we are never going to fix (apart from dropping K3Network altogether). So, these warnings are useless, but this can't be fixed with CDash filters but needs real code changes (e.g. a K3NETWORK_DEPERECATED define that's empty inside K3Network itself). > And the lots of warnings: > 'virtual bool KFoo::doSomething(...)' was hidden > by 'virtual ..." ? Do we want to see them there ? Hard to say, they can be anything from really useless to indicating tricky to find bugs. regards Volker signature.asc Description: This is a digitally signed message part.
Re: Review Request: Only show KSysguard & SystemSettings in menus when running KDE
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102038/#review4952 --- 1) The git diff you have uploaded is cooked 2) As System Settings maintainer, I find this unacceptable as people using KDE applications under other desktops need to access System Settings for the purpose of altering settings shared by KDE applications - and managed through System Settings. Examples: - Colour scheme - Style used - Etc - Ben On July 21, 2011, 10:39 p.m., Jeremy Bicha wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102038/ > --- > > (Updated July 21, 2011, 10:39 p.m.) > > > Review request for KDE Base Apps. > > > Summary > --- > > Add OnlyShowIn:KDE line to KSysguard & SystemSettings. Otherwise, it's very > frustrating when running any other desktop (Gnome Shell, Unity, etc.) and > seeing multiple apps named the same thing with the same icon without any way > to distinguish them. > > > Diffs > - > > ksysguard/gui/ksysguard.desktop 7e8ff32f1e275ee246e79da039509e28e56987cf > systemsettings/app/systemsettings.desktop > 5934a194675cfe152ebdbfd4a9db45ebd48b67a8 > > Diff: http://git.reviewboard.kde.org/r/102038/diff > > > Testing > --- > > > Thanks, > > Jeremy > >
Formal complaint concerning the use of the name "System Settings" by GNOME
To all concerned developers, As you may or may not be aware, the name "System Settings" for an application is currently in use by KDE. A recent renaming by your GNOME control center developers to this name creates a naming conflict. This naming conflict will cause severe problems for users as a result. It will also cause problems for those members of the KDE Community supporting the usage of KDE applications on GNOME, as it will not be possible to adjust the settings used by KDE applications. This will be because they will both appear, leading to GNOME packagers stupidly patching the system to not show the KDE System Settings under GNOME. As KDE occupied this name first, it is ours as a result, and I will NOT be relinquishing it to satisfy your personal (selfish) desires, which will cause numerous problems for users on both sides. System Settings cannot just be shown on KDE, as the application is used to configure multiple settings shared between KDE applications such as Localisation (language, region, currency, calendar), Style, Colours, Fonts among others. As KDE System Settings maintainer, I request that you immediately rename it once again to another name which is not in conflict. Regards, Ben Cooksley KDE System Settings Maintainer
Re: Enviroment variables and KAuth
2011/7/5 Konstantinos Smanis > Is it a bug or feature that no enviroment variables (most notably > $PATH) are set for DBus-activated KAuth helpers? > Manually launching the helper from a shell doesn't lead to this > behaviour: enviroment variables are properly set. > KAuth helpers are always triggered by DBus, so they follow DBus activation's paradigm. Besides that, no environment variables should be relevant to an helper, and can instead be harmful, so you can indeed consider that a feature. > > Konstantinos Smanis >
Re: Fixes in Git (first in stable, then merge to master)
Le ven. 22 juil. 2011 08:37:23 CEST, Johannes Sixt a écrit : > Am 7/21/2011 23:22, schrieb Aurélien Gâteau: >> What I have been doing recently to avoid cherry-picking is to create my >> fixes in a separate work branch, then merge the branch in both 4.7 and >> master branches. This way the commits do not have different commit ids. > > But this works only if you fork off your topic from a commit that is in > both 4.7 and master, i.e., before 4.7 and master forked. Do you do that? > > This is a very reasonable (and git-ish) way to avoid cherry-picks and > still avoid merging 4.7 into master. (But the latter, avoiding to merge > 4.7 into master, is very un-git-ish.) > > -- Hannes Oh. Good point. I guess I didn't bump into the problem so far because I have been doing this for Gwenview repository only. So it's not a very good advice after all :/ Aurélien
Re: Fixes in Git (first in stable, then merge to master)
Am Fri, 22 Jul 2011 14:52:20 +0200 schrieb Aurélien Gâteau : > Oh. Good point. I guess I didn't bump into the problem so far because > I have been doing this for Gwenview repository only. So it's not a > very good advice after all :/ Yes it is. Branching off before tagging and keeping that branch a common source for both, stable and master - so you can fwd merge in either, is indeed a good solution but requires quite some discipline (and that branch to be public, oc) So it basically does not work on large projects - at least w/o a workflow "tool" (that rises a staging for direct commits and ensures sync merging) or unless you can threaten ppl. to fire them ;-) Cheers, Thomas
Re: Review Request: Make “No multiscreen configuration” message prettier
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101810/#review4971 --- This review has been submitted with commit 6ef52bd4ed9c4b62a3cd5b6229a1bb71434092c7 by Kai Uwe Broulik to branch master. - Commit On June 30, 2011, 9:02 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101810/ > --- > > (Updated June 30, 2011, 9:02 p.m.) > > > Review request for KDE Base Apps. > > > Summary > --- > > I always found Bluedevil’s notifications so nice, so I patched the Multi > monitor configuration KCM to use something similar to indicate that this > configuration is not available on the respective machine. > > Comparison screenshot: http://privat.broulik.de/xineramapatch.png > > > Diffs > - > > kcontrol/xinerama/kcmxinerama.h fc83e5a > kcontrol/xinerama/kcmxinerama.cpp 86fbf38 > > Diff: http://git.reviewboard.kde.org/r/101810/diff > > > Testing > --- > > > Thanks, > > Kai Uwe > >
Re: Review Request: Make “Edit File Type” button more discoverable
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101800/#review4975 --- This review has been submitted with commit 131fabf76ec4688561892ba87e2aa86ad828ca70 by Kai Uwe Broulik to branch master. - Commit On June 30, 2011, 10:34 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101800/ > --- > > (Updated June 30, 2011, 10:34 p.m.) > > > Review request for kdelibs. > > > Summary > --- > > On IRC this evening somebody found it hard to find the options to edit a > specific file type. The KCM is a mess unfortunately but I told him that you > could edit specific file types directly from the properties dialog. > That button is hard to spot, though, which I also often found annoying. It is > neither labled nor does it stand out as “button”. > This patch solves that issue. > > It is in need of discussion whether the label itself should stay but the > button definitly has to look like a clickable target. > > Comparison screenshot: privat.broulik.de/filedialogpatch.png (this screenshot > is from the initial attempt where i forgot the capitalization :P) > > > Diffs > - > > kio/kfile/kpropertiesdialog.cpp 3382daa > > Diff: http://git.reviewboard.kde.org/r/101800/diff > > > Testing > --- > > > Thanks, > > Kai Uwe > >
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Friday, July 22, 2011 04:21:14 AM Ben Cooksley wrote: > To all concerned developers, > > As you may or may not be aware, the name "System Settings" for an > application is currently in use by KDE. A recent renaming by your > GNOME control center developers to this name creates a naming > conflict. This naming conflict will cause severe problems for users as > a result. It will also cause problems for those members of the KDE > Community supporting the usage of KDE applications on GNOME, as it > will not be possible to adjust the settings used by KDE applications. > > This will be because they will both appear, leading to GNOME > packagers stupidly patching the system to not show the KDE System > Settings under GNOME. > > As KDE occupied this name first, it is ours as a result, and I will > NOT be relinquishing it to satisfy your personal (selfish) desires, > which will cause numerous problems for users on both sides. > System Settings cannot just be shown on KDE, as the application is > used to configure multiple settings shared between KDE applications > such as Localisation (language, region, currency, calendar), Style, > Colours, Fonts among others. > > As KDE System Settings maintainer, I request that you immediately > rename it once again to another name which is not in conflict. This is not just a theoretical concern see https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/735166 Thanks to your mail here, I knew how to respond. Scott K
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Fri, Jul 22, 2011 at 08:21:14PM +1200, Ben Cooksley wrote: > As KDE occupied this name first, it is ours as a result, and I will > NOT be relinquishing it to satisfy your personal (selfish) desires, > which will cause numerous problems for users on both sides. Always nice to meet a fellow free desktop developer. Please be aware that no harm is meant. However, your tone is not what we're used to. Our mailing lists are moderated and though you can disagree all you want, please always show some respect. See for instance https://live.gnome.org/CodeOfConduct Now lets go into something more productive and perhaps we can fix this before the sunny Desktop Summit. -- Regards, Olav (moderator)
Re: Review Request: Use platform palette and fonts when running on other desktop environments
> On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: > > hmm. but now things are still done twice in a kde session, no? > > what was wrong with the suggestion to notify qt that it should update > > "stuff"? > > Aurélien Gâteau wrote: > createApplicationPalette() is indeed called twice when running on a KDE > session, but it is not a regression introduced by this change so I think it > is outside of the scope for now. I tried not doing anything in > kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the > kcm as Olivier suggested, but that didn't work: the palette change was not > propagated to the running application. > > What worries me right now is that the text area of KWrite does not get > updated at runtime. I thought it was due to the widget being custom, but it > correctly updates itself without the patch. > > Aurélien Gâteau wrote: > Finally found time to do more testing. It turns out the behavior of > KWrite text area is the same with or without the patch so it's not a > regression. Therefore, I think the patch should go in. > > Thomas Lübking wrote: > Sh*t - i forgot that I wanted to comment on that: kate keeps own color > schemes for the text area, they're completely unrelated to he rest of the > system. > (since you need to configure syntax highlightning and don't want that to > run into a conflict with the system palette de toujours) > > So yes, that's not a regression for sure, sorry. > > Dominik Haumann wrote: > With regard to kwrite: It uses the system colors as long as they were > never changed. Changed once, these system settings are overwritten. Hence, > this is very likely a KatePart issue. > > Aurélien Gâteau wrote: > Oh. Thanks Thomas and Dominik, it suddenly makes more sense! If there is > no other objection I'd like to merge this patch this week. Anyone against > that? I just merged the changes in. Unless I spot some obvious regressions, I plan to backport the patch in time for 4.7.1. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101805/ > --- > > (Updated July 2, 2011, 9:19 p.m.) > > > Review request for kdelibs and Olivier Goffart. > > > Summary > --- > > When a KDE application is running on GNOME it looks odd right now because it > does not use the GNOME palette and fonts, contrary to Qt-only applications. > Attached patch fixes this by relying on the platform plugin to set the > correct palette and fonts if we are not running in a full KDE session. > > Patch was suggested by Olivier Goffart. > > > Diffs > - > > kdeui/kernel/kglobalsettings.cpp 1a497c7 > > Diff: http://git.reviewboard.kde.org/r/101805/diff > > > Testing > --- > > # On KDE > - Run kwrite on KDE => KDE palette and fonts > - Change palette and fonts from System Settings => kwrite updates itself > correctly > > # On GNOME > - Run kwrite on GNOME => GNOME palette and fonts > - Change palette and fonts from GNOME Tweak Tool => palette gets applied, > font does not for now > > > Thanks, > > Aurélien > >
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
> > Now lets go into something more productive and perhaps we can fix this > before the sunny Desktop Summit. Hi Olav, In terms of being productive surrounding this, I have several questions: Screenshots on your live wiki indicate that GNOME developers were aware of the use of the "System Settings" name by KDE. Why did your developers deliberately proceed with the use of this name, knowing it would cause a conflict? (This was the primary reason why I was particularly angry about the discovery of your use of this name) Is there any reason why it cannot be renamed once more as soon as is possible so that the next release your team makes fixes this issue? I would prefer to resolve this issue as soon as possible, to minimise the work packagers will inevitably do to block KDE System Settings under GNOME, and the resulting KDE application user support issues that will arise. Regards, Ben Cooksley KDE System Settings Maintainer
Re: Fixes in Git (first in stable, then merge to master)
Alex Fiestas wrote: > Last few days I have been patching some pieces of our workspace here and > there, the first set of patches I did them directly into master which if > I remember correctly was against the policy. > So, the second round of fixes I tried to do it the right way, which is: > 1-Create the patch while using 4.7 (optional I guess) > 2-Test the patch in 4.7 > 3-Commit the patch in 4.7 > 4-Checkout master branch > 5-Merge 4.7 into master > > [...] > > So, at this point I'm wondering if the policy is bad or (and this option > is the more plausible) I don't know how to use the tool. > > Cheers and sorry for the cherry-pick's I've done so far. There is no active policy saying you're supposed to merge. Almost everybody in KDE is still doing cherry-picks. KDevelop is the only KDE project I know that consistently uses forward-merges from the stable branch to master. --- It *would* be good to switch to the new workflow of doing changes in the lowest supported branch and up-merging, but it's not that easy. We need to: - Figure out how to solve the scripty problem. scripty does its own conflicting commits to .desktop files in both branches, and that won't change[1]. We probably need a custom merge tool for .desktop-like files that ignores translations. - Check if there is any change in 4.7 that isn't in master, and if so, see if that's intentional (4.7-specific hack, or the version bumps) or an oversight (never cherry-picked into master). - Do the initial merge from 4.7 to master, solving the conflicts. The more they have diverged, the harder this is. - Get *everyone* to start with the new workflow for that particular repository (see below). Else, if some people keep cherry-picking while others expect merging, the next one to try merging may get conflicts about all the cherry-picks people did since the last merge, and a merge will make commits appear duplicated in the log (as ossi pointed out to me). Off to read about custom git merge drivers... -- Nicolas
Re: Fixes in Git (first in stable, then merge to master)
On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote: > There is no active policy saying you're supposed to merge. Almost everybody > in KDE is still doing cherry-picks. KDevelop is the only KDE project I know > that consistently uses forward-merges from the stable branch to master. > > --- > > It *would* be good to switch to the new workflow of doing changes in the > lowest supported branch and up-merging, but it's not that easy. We need to: > > - Figure out how to solve the scripty problem. scripty does its own > conflicting commits to .desktop files in both branches, and that won't > change[1]. We probably need a custom merge tool for .desktop-like files that > ignores translations. > > - Check if there is any change in 4.7 that isn't in master, and if so, see > if that's intentional (4.7-specific hack, or the version bumps) or an > oversight (never cherry-picked into master). > > - Do the initial merge from 4.7 to master, solving the conflicts. The more > they have diverged, the harder this is. > > - Get *everyone* to start with the new workflow for that particular > repository (see below). Else, if some people keep cherry-picking while > others expect merging, the next one to try merging may get conflicts about > all the cherry-picks people did since the last merge, and a merge will make > commits appear duplicated in the log (as ossi pointed out to me). During the stable branch freeze before a minor version release (such as currently before the 4.7 release), it isn't possible to commit bug fixes to stable first and then merge to master. Only master can be committed to, so presumably we'll have to continue to commit to master and cherry-pick later once the freeze ends. Either that or change the policy on freezes. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Fixes in Git (first in stable, then merge to master)
David Jarvie wrote: > On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote: > During the stable branch freeze before a minor version release (such as > currently before the 4.7 release), it isn't possible to commit bug fixes > to stable first and then merge to master. Only master can be committed to, > so presumably we'll have to continue to commit to master and cherry-pick > later once the freeze ends. Either that or change the policy on freezes. You could branch 4.7 into (say) 4.7-fixes to do bugfixes during the freeze, and merge it back into 4.7 when the freeze ends. -- Nicolas
Re: Re: Fixes in Git (first in stable, then merge to master)
On Saturday 23 July 2011 01:42:16 David Jarvie wrote: > On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote: > > There is no active policy saying you're supposed to merge. Almost everybody > > in KDE is still doing cherry-picks. KDevelop is the only KDE project I know > > that consistently uses forward-merges from the stable branch to master. > > > > --- > > > > It *would* be good to switch to the new workflow of doing changes in the > > lowest supported branch and up-merging, but it's not that easy. We need to: > > > > - Figure out how to solve the scripty problem. scripty does its own > > conflicting commits to .desktop files in both branches, and that won't > > change[1]. We probably need a custom merge tool for .desktop-like files > > that > > ignores translations. > > > > - Check if there is any change in 4.7 that isn't in master, and if so, see > > if that's intentional (4.7-specific hack, or the version bumps) or an > > oversight (never cherry-picked into master). > > > > - Do the initial merge from 4.7 to master, solving the conflicts. The more > > they have diverged, the harder this is. > > > > - Get *everyone* to start with the new workflow for that particular > > repository (see below). Else, if some people keep cherry-picking while > > others expect merging, the next one to try merging may get conflicts about > > all the cherry-picks people did since the last merge, and a merge will make > > commits appear duplicated in the log (as ossi pointed out to me). > > During the stable branch freeze before a minor version release (such as > currently before the 4.7 release), it isn't possible to commit bug fixes to stable first and then merge to master. Only master can be committed to, so presumably we'll have to continue to commit to master and cherry-pick later once the freeze ends. Either that or change the policy on freezes. Seriously: is this technically enforced or is it believed that developers know about it? Personally I have no idea when the stable branch will be tagged or released. I commit to the stable branch in order to fix a bug and in the hope that it will some day end on the users' systems. But I do not care when this will happen and I never was blocked because of some tagging freeze. So unless this is not technically enforced, the policy are nice words which I beleive nobody cares about. Cheers Martin signature.asc Description: This is a digitally signed message part.
