Impact of Heartbleed issue on KDE.org infrastructure
Hi everyone, As i'm sure you're all aware at this point, a vulnerability of OpenSSL could lead to sensitive information being leaked by web servers. The Good News: The vast majority of our services are running on the older Debian Squeeze, which uses OpenSSL 0.9.8o and is unaffected by the issue. The Bad News: Certain services are run through a third party intermediary (Incapsula) and some services are being hosted by Debian Wheezy systems (which did use a vulnerable version of OpenSSL). All such systems under the control of KDE Sysadmin have since been patched and have had the necessary services restarted. For information on the steps taken by Incapsula please see http://www.incapsula.com/blog/heartbleed-ssl-vulnerability-fixed.html As far as we are aware, all systems under kde.org have now had the issue corrected (assuming they were affected by the issue in the first case). Sites affected: forum.kde.org community.kde.org userbase.kde.org techbase.kde.org cdn.kde.org api.kde.org dot.kde.org blogs.kde.org reviewboard.kde.org (Both Git and Subversion) At no point were Identity, Bugzilla or SCM services affected by this issue. If anyone has any questions, please let us know. Thanks, Ben Cooksley KDE Sysadmin
Re: Kronometer now in KDE Review
2014-04-14 1:06 GMT+02:00 Albert Astals Cid aa...@kde.org: El Dilluns, 7 d'abril de 2014, a les 23:52:19, Elvis Angelaccio va escriure: Hi all, Hi! Hi Albert, with this email I'm going to ask a review for Kronometer, in order to be accepted in KDE. Kronometer is a stopwatch application for KDE. It's meant to be simple but also customizable. Kronometer has been moved to kdereview from its previous location, playground/utils. I'm not sure whether to ask the admission in extragear-utils or in kdeutils. Personally I don't see it being a broad enough use case to make sense to be in kdeutils. What do others think? Have you asked at kde-utils-devel https://mail.kde.org/mailman/listinfo/kde-utils-devel ? No, I have not yet asked. I will do it. What I'm looking for is the help of the KDE community with translations, packaging and bug-tracking. If the choice is definitely up to me, it would be nice to join the kdeutils module. Regarding the requirements for the admission: 1. There is the documentation in DocBook format. Thanks to Yuri Chornoivan for his help. 2. Source code is documented using the doxygen syntax, as suggested in the techbase documentation policy. 3. All the krazy code checker issues have been addressed. 4. No usability review has been done, but it's welcome. 5. Profiler: unfortunately I don't know how to do it. I used Valgrind and there shouldn't be memory leaks. I tried to use also Callgrind but I'm not able to understand its output. If a profiler check is strictly required, I'll need help for it. Nah, it's not like your app is doing anything very resource intensive so you don't need performance testing (just make sure you don't hog the cpu at 100% :D) Some small comment from my side: * You are passing an email address as bug address, you should leave the default bugzilla one there and create a kronometer bug entry in bugs.kde.org if you don't have power for that ask to the sysadmin guys about it. Yes, I put only a temporary email address, waiting for an official bugs entry. * Your choice of splitters to separate hours/minutes/seconds seems a bit weird do you think that anyone will use it to have something like very wide minutes and narrow the rest? I see your point, probably the splitters are unnecessary UI components for this use case. What do you think about an option in Interface settings? I could display by default a single QFrame (without splitters) and leave to the user an opt-in to allow the splitters. In this way I can reuse the existing code without too much refactoring. * The general/font/save settings probably would look nicer with a vertical spacer at the end that eats up empty space when the vertical space is bigger than needed (i.e. similar to what you have in interface settings). Good catch, there the spacers have been forgotten. Cheers, Albert Regards, Elvis 6. The application should be completely translatable, thanks again to the help of Yuri. Finally here the references: Kronometer repository in kdereview: *https://projects.kde.org/projects/kdereview/kronometer https://projects.kde.org/projects/kdereview/kronometer* Kronometer quickgit: http://quickgit.kde.org/?p=kronometer.git Kronometer website: http://aelog.org/kronometer/http://www.aelog.org/kronometer/ If you want to quickly browse the code, you can also do it whit the Woboq's code browser here: http://aelog.org/codebrowser/kronometer/ Thank you for your time, Elvis Angelaccio
Re: [kde-community] Impact of Heartbleed issue on KDE.org infrastructure
Hi Ben, On Tue, Apr 15, 2014 at 10:29 AM, Ben Cooksley bcooks...@kde.org wrote: ... Sites affected: forum.kde.org community.kde.org userbase.kde.org techbase.kde.org cdn.kde.org api.kde.org dot.kde.org blogs.kde.org reviewboard.kde.org (Both Git and Subversion) At no point were Identity, Bugzilla or SCM services affected by this issue. If anyone has any questions, please let us know. So in other words: since we probably all use Identity to log into these sites, there is no reason to change any passwords, right? Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300)
Re: [kde-community] Impact of Heartbleed issue on KDE.org infrastructure
On Tue, Apr 15, 2014 at 11:15 PM, Myriam Schweingruber myr...@kde.org wrote: Hi Ben, Hi Myriam, On Tue, Apr 15, 2014 at 10:29 AM, Ben Cooksley bcooks...@kde.org wrote: ... Sites affected: forum.kde.org community.kde.org userbase.kde.org techbase.kde.org cdn.kde.org api.kde.org dot.kde.org blogs.kde.org reviewboard.kde.org (Both Git and Subversion) At no point were Identity, Bugzilla or SCM services affected by this issue. If anyone has any questions, please let us know. So in other words: since we probably all use Identity to log into these sites, there is no reason to change any passwords, right? The Incapsula blog post was unclear as to whether they were affected or not. As for Reviewboard (the others are all Incapsula), then because Identity credentials were entered directly, they will need to be changed. Regards, Myriam Thanks, Ben -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ kde-community mailing list kde-commun...@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: Update needed to binary compatibility guide for Windows?
On Sunday 13 April 2014 23:15:30 Nicolás Alvarez wrote:
2014-04-13 22:36 GMT-03:00 Michael Pyne mp...@kde.org:
Hi all,
In the past couple of days our Binary Compatibility in C++ TechBase page
[1] was posted to Reddit [2].
That post received a response [3] which indicated that we're actually
missed a potential source of binary incompatibility with virtual
functions on Windows with MSVC.
Specifically, that adding an override of an existing virtual function in a
class may cause other vtable function entries to be re-ordered. E.g. in
something like:
class blah
{
public:
virtual void func1(int arg);
virtual void func2(int arg);
virtual void func3(int arg);
};
Adding a virtual override func2(char *arg) to the *end* might cause the
vftable to line up as if declared in this order:
class blah
{
public:
virtual void func1(int arg);
virtual void func2(int arg);
virtual void func2(char *arg);
virtual void func3(int arg); // moved
};
Is anyone able to confirm this behavior on Windows? If it's true, do we
want to adopt a constraint on our handling of virtual functions in leaf
classes based on this? (Adding virtual methods is already not permitted
for non-leaf classes)
I can confirm this behavior happens.
I compiled this class:
struct Testobj {
virtual void func1();
virtual void func2();
virtual void func3();
};
And a program that calls func1(); func2(); func3();
Then I added a func2(int) overload to the *end*:
struct Testobj {
virtual void func1();
virtual void func2();
virtual void func3();
virtual void func2(int);
};
and recompiled the class but not the program using the class.
Output of calling func1(); func2(); func3(); was
This is func1
This is func2 taking int
This is func2
This shows that if I declare func1() func2() func3() func2(int), the
vtable is laid out as func1() func2(int) func2() func3().
Tested with MSVC2010.
Awesome, please add this information to the guide on the wiki. The page is a
quite helpful one, i.e. no wonder it was posted to reddit. Having it as
extensive as possible is a good thing imo.
Cheers
--
Milian Wolff
m...@milianw.de
http://milianw.de
KF5 Update Meeting Minutes 2014-w16
Hello everyone, This is the minutes of the Week 16 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, notmart, tosky and myself Announcement: * I won't be around next week for the meeting, Riddell will run the one next week; * afiestas pushed all the changes he aimed at for solid; * he's going to move some runtime bits to kdelibs4support; * he also plan to have the new async powermanagement API on review soon; * agateau worked on translation support; * he also proposed changes to ECM for handling .qm files; * and there's been back and forth on how to handle qt based translations; * alexmerry worked on ECM online docs (thanks to winterz for getting them on api.kde.org); * he's almost done with the kde4 reference task; * he also completed the renaming from kde4support to kdelibs4support; * apol finished splitting important parts from kde-runtime; * he plans to finish on the documentation and l10n; * he'd also need someone to look at https://git.reviewboard.kde.org/r/117565/ ; * notmart fixed bugs in kxmlgui and kwidgetsaddons * tosky helped with translations on kf5; * he's still investigating but almost done with the remaining issue in kdoctools; * he'll also investigate why khelpcenter doesn't show anything; * ervin has been mostly sick, reviewing and annoying on list (in no particular order). If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Default bugzilla asignees for frameworks
Hey, As we now have people stepping up as frameworks maintainers, I think part of that maintainership should be becoming the default assignee for given framework on bugzilla. For example I filed a bug against KIO and that was assigned to kdelibs-b...@kde.org, where I imagine it gets drowned among other kdelibs bugs. Given we're going big with frameworks now, we /need to/ make our bug handling better than sending them to kdelibs-bugs. If there are no objections, I'll assign frameworks bugs to people as per the table here: https://community.kde.org/Frameworks/List Cheers -- Martin Klapetek | KDE Developer
Re: Default bugzilla asignees for frameworks
On Tuesday 15 April 2014 17:07:38 Martin Klapetek wrote: Hey, As we now have people stepping up as frameworks maintainers, I think part of that maintainership should be becoming the default assignee for given framework on bugzilla. For example I filed a bug against KIO and that was assigned to kdelibs-b...@kde.org, where I imagine it gets drowned among other kdelibs bugs. Given we're going big with frameworks now, we /need to/ make our bug handling better than sending them to kdelibs-bugs. If there are no objections, I'll assign frameworks bugs to people as per the table here: https://community.kde.org/Frameworks/List Please do so. It's indeed maintainer's duty. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Default bugzilla asignees for frameworks
El Dimarts, 15 d'abril de 2014, a les 17:07:38, Martin Klapetek va escriure: Hey, As we now have people stepping up as frameworks maintainers, I think part of that maintainership should be becoming the default assignee for given framework on bugzilla. For example I filed a bug against KIO and that was assigned to kdelibs-b...@kde.org, where I imagine it gets drowned among other kdelibs bugs. Given we're going big with frameworks now, we /need to/ make our bug handling better than sending them to kdelibs-bugs. If there are no objections, I'll assign frameworks bugs to people as per the table here: https://community.kde.org/Frameworks/List So how does one get all the bugs about kdelibs (including frameworks)? Cheers, Albert Cheers
Re: Default bugzilla asignees for frameworks
On Tue, Apr 15, 2014 at 9:13 PM, Albert Astals Cid aa...@kde.org wrote: So how does one get all the bugs about kdelibs (including frameworks)? For what purpose? If you just want an overview, you can do advanced search and select all the frameworks- products (simple click on first framework and shift-click on last; see [1]). Also note that not all frameworks have bugzilla products yet. [1] - http://bit.ly/1kuDo59 Cheers -- Martin Klapetek | KDE Developer
Re: Default bugzilla asignees for frameworks
On Tue, Apr 15, 2014 at 9:56 PM, Albert Astals Cid aa...@kde.org wrote: If you want to change the default assignee, that's fine, but then maybe add kdelibs-b...@kde.org as Default CC List: ? Sure, good point. Should it go to kdelibs-bugs though? Wouldn't something like frameworks-bugs be better so it's not mixed with kdelibs4 bugs? Cheers -- Martin Klapetek | KDE Developer
Re: Default bugzilla asignees for frameworks
We can add a CC list to the bugzilla product.
Re: Kronometer now in KDE Review
El Dilluns, 14 d'abril de 2014, a les 11:35:02, Elvis Angelaccio va escriure: 2014-04-14 1:06 GMT+02:00 Albert Astals Cid aa...@kde.org: * Your choice of splitters to separate hours/minutes/seconds seems a bit weird do you think that anyone will use it to have something like very wide minutes and narrow the rest? I see your point, probably the splitters are unnecessary UI components for this use case. What do you think about an option in Interface settings? I could display by default a single QFrame (without splitters) and leave to the user an opt-in to allow the splitters. In this way I can reuse the existing code without too much refactoring. I just don't see the need for the splitters, why would someone want to have them? Cheers, Albert
Re: Kronometer now in KDE Review
On Tue, Apr 15, 2014 at 10:27 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 14 d'abril de 2014, a les 11:35:02, Elvis Angelaccio va escriure: 2014-04-14 1:06 GMT+02:00 Albert Astals Cid aa...@kde.org: * Your choice of splitters to separate hours/minutes/seconds seems a bit weird do you think that anyone will use it to have something like very wide minutes and narrow the rest? I see your point, probably the splitters are unnecessary UI components for this use case. What do you think about an option in Interface settings? I could display by default a single QFrame (without splitters) and leave to the user an opt-in to allow the splitters. In this way I can reuse the existing code without too much refactoring. I just don't see the need for the splitters, why would someone want to have them? Cheers, Albert FWIW, the first time I saw a screenshot of this application, these splitters shocked me too a bit. I guess the design will iterate anyway, no? Aleix
Re: Kronometer now in KDE Review
On Tue, Apr 15, 2014 at 10:27 PM, Albert Astals Cid aa...@kde.org wrote: I just don't see the need for the splitters, why would someone want to have them? I see a limited usage (and only) in case they're collapsible (and grow by char width) what would allow to set a target scale (if you measure hours, you likely don't care about seconds et vv.) - but I think that it's mostly just skeumorphism (imitating individually wrapping hardware labels). Scale adjustment could be done better (automatic, resp. radiobutton or slider driven or a semi-automatic hybrid or different font sizes, or ...) on a virtual tool. Cheers, Thomas
Re: Update needed to binary compatibility guide for Windows?
On Mon, April 14, 2014 18:28:14 Ian Monroe wrote: On Sun, Apr 13, 2014 at 6:36 PM, Michael Pyne mp...@kde.org wrote: If it's true, do we want to adopt a constraint on our handling of virtual functions in leaf classes based on this? IMO we shouldn't worry about ABI on Windows. And not because meh Windows, but since Microsoft breaks C++ ABI with every compiler release, which is quite frequently these days. In general C++ ABI stability just isn't a thing on Windows. I've looked it up and you're right, they don't even pretend to try to maintain ABI compatibility (instead they recommend using an extern C wrapper or a COM interface). But at the same time we went through a time where GCC seemed to have to fix their C++ ABI every release and we tried to maintain the same binary compatibility standards throughout. I think what I'll do is note the issue. But in fact it may be worse: Do we require that applications never derive from our exported classes? I.e. do we export interfaces (which should not be derived from) or classes (which can be subclassed)? Because if we export classes with virtual methods, and then an application subclasses our class with their own virtual methods, then adding another virtual method to our most derived exported class would break the application even with the GCC ABI. Regards, - Michael Pyne
