Re: drkonqi's many debuggers
On Thursday, 31 August 2023 03:42:59 PDT Halla Rempt wrote: > On dinsdag 29 augustus 2023 05:22:56 CEST Thiago Macieira wrote: > > True, but the majority of our user base is still Linux, so if we had to > > choose only one, it would have to be gdb. > > Um, no? The majority is on Windows. Yes, we have certain hero apps (like Krita) that would skew the statistics. So maybe you're right. But that doesn't change the conclusion because the vast majority of Windows users won't have a debugger installed. Those few that do won't have the debugger in the standard $PATH because it's just not the way things are done on Windows. So rephrasing what I meant to say, "the vast majority of users who have any debugger installed are Linux users with gdb". But I maintain that we should support both GDB and LLDB. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: drkonqi's many debuggers
On Monday, 28 August 2023 21:33:25 PDT Nate Graham wrote: > On 8/28/23 22:25, Thiago Macieira wrote: > > It does because it might be missing in the system far more often than gdb. > > We'd get more backtraces and therefore more data if we focused on gdb > > > > Another point is that Linux distributions have been shipping gdb with > > debuginfod support for a year or two. lldb support for it is still > > pending: > > https://github.com/llvm/llvm-project/issues/52732 > > > > Therefore, I repeat: if there's room for only one, it's gdb. > > > > If we do support both, then on Linux gdb must be used in preference. > > DrKonqi itself could declare a required build dependency on lldb, and > then we would know it's present on the system. Distros that don't > package it would then have to omit DrKonqi, or start packaging it. Build dependencies don't necessarily translate to runtime dependencies. What you're asking for is package management, something we don't control. Yes, we could convince all packagers to add it, but a) that's not a sure-fire guarantee b) do we even want to? Do we want to make it so every user who installs Plasma Workspace must have a debugger? No, debuggers are optional. Then there's my argument about libdebuginfo integration. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: drkonqi's many debuggers
On Monday, 28 August 2023 20:30:36 PDT Harald Sitter wrote: > I am not quite following. We can depend on any debugger we want, > surely? I mean, there are practical implications to consider for sure, > but gdb being the dominant debugger on Linux doesn't prevent us from > depending on lldb instead. It does because it might be missing in the system far more often than gdb. We'd get more backtraces and therefore more data if we focused on gdb Another point is that Linux distributions have been shipping gdb with debuginfod support for a year or two. lldb support for it is still pending: https://github.com/llvm/llvm-project/issues/52732 Therefore, I repeat: if there's room for only one, it's gdb. If we do support both, then on Linux gdb must be used in preference. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering .
Re: drkonqi's many debuggers
On Monday, 28 August 2023 12:59:01 PDT Adriaan de Groot wrote: > (puts on FreeBSD hat) On the non-GNU side of the world, lldb is the thing > that is "installed anyway" and gdb takes extra effort. Though I don't know > if the lldb integration works -- I have both installed, and I don't know if > I ever bother to interact with DrKonqi (sorry). True, but the majority of our user base is still Linux, so if we had to choose only one, it would have to be gdb. That's probably why we need to have both gdb and lldb supported. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: drkonqi's many debuggers
On Monday, 28 August 2023 08:23:00 PDT Harald Sitter wrote: > On a related note: does anyone have opinions on using lldb instead of > gdb? This contradicts your earlier point of: > I am wondering if we couldn't just focus on one debugger > and get less code with a better experience (both in writing and > reading it). If you want *one* debugger, then it has to be GDB on Linux, because it's the one that most people will have installed. $ lldb --version zsh: command not found: lldb -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: Fwd: KDiff3 v 1.9.6 Windows crash
On Wednesday, 16 November 2022 13:51:47 PST Michael Reeves wrote: > This is the question I need answered. Windows by default gives the most > useless crash report I've ever seen. All I know from that is that the crash > point is inside qt but that doesn't help at all with a Qt based > application. Worse a lot the documentation I find assumes you are a) > debugging a drive and/or b) working with msvc project that you can > reproduce the crash in. The same as anywhere else: run the application inside the debugger (gdb if it is MinGW). When it crashes, type "bt". -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: global shortcuts
On Saturday, 22 January 2022 04:33:24 PST Martin Koller wrote: > Hi, > > which component is responsible for acting on global shortcuts, e.g. > what triggers that Alt-F2 is opening krunner ? kglobalacceld -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Re: KPluginLoader UBSAN warnings (object has invalid vptr)
On Thursday, 15 October 2020 07:22:59 PDT Milian Wolff wrote: > I have the feeling that this might be a limitation of UBSAN? Or is this an > actual problem - does anyone know? I've seen similar warnings that were impossible. See https://bugreports.qt.io/browse/QTBUG-85398 I'm not sure yet if this is an UBSan bug or if there was some weird, duplicate symbol problem. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Re: Is kdeinit still actual?
On Monday, 27 April 2020 03:53:38 PDT Alexander Volkov wrote: > As for KIO slaves, they are started from processes that are already > linked with many KDE libraries and there is no > > much benefit in starting them from kdeinit. That's an incorrect conclusion. Your premise is correct: the process that launches them links to many KDE libraries. But since that launch is a regular fork() + exec(), the premise is irrelevant. The KDE libraries will be loaded again, relocated and initialised, before the ioslave code is run. A quick test here shows kdeinit and one ioslave (file.so, that was already running) are sharing 2380 kB between them. The ioslave has a total of 548 kB of additional private memory that isn't shared with anything else in the system. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products
Re: ELF Dissector in kdereview
On Tuesday, 1 October 2019 05:06:57 PDT Jonathan Riddell wrote: > -isystem > /usr/include/capstone/.. [...] > /usr/include/c++/7/cstdlib:75:15: fatal error: stdlib.h: No such file or > directory That -isystem is the mistake. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products
Re: Time formats / LC_TIME challenge for 4-digit year support
On Tuesday, 4 December 2018 11:42:41 PST Jaroslaw Staniek wrote: > I did not know there are such differences for the locale system. But by no > means my email is a call to "patch" the Qt-level problem by having a KF5 > solution. And I am skeptical if Qt can be patched in version 5 with such > incompatible change. Hopefully these poor man analysis help some other app > developers If you want that, please submit your patch to unicode.org. They need to update the CLDR to have 4-digit years for the locale of your choice. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: Installing qml caches
On Sunday, 8 July 2018 09:06:58 PDT Simon Hausmann wrote: > And use the QtQuickCompiler build > option with 5.11. Is that just running qmlcachegen on all the *.qml? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: c++11 and workspace
On Thursday, 17 August 2017 08:52:21 PDT Martin Flöser wrote: > Am 2017-08-17 16:48, schrieb Hugo Pereira Da Costa: > > Hi, > > > > Quick question on the status of c++11 features that I can include in > > breeze. Are std::function allowed ? > > In workspace you can/should use C++11, KWin/master even requires C++14. Confirm if you mean the core language or the standard library. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: QProcess::startDetached and bash stdout capture
On sábado, 25 de março de 2017 09:03:28 PDT David Faure wrote:
> On samedi 25 mars 2017 16:50:37 CET Thiago Macieira wrote:
> > One problem is because the launched process inherits the pipes to stdout
> > and stderr
>
> Really, even with startDetached? I assumed that was more "detached" than
> that
But you may want:
int fd = open("/dev/null", O_RDWR);
dup2(fd, STDIN_FILENO);
dup2(fd, STDOUT_FILENO);
dup2(fd, STDERR_FILENO);
close(fd);
Like I said, this may be useful to add as a flag to QProcess::startDetached
too.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
Re: QProcess::startDetached and bash stdout capture
On sábado, 25 de março de 2017 09:03:28 PDT David Faure wrote: > On samedi 25 mars 2017 16:50:37 CET Thiago Macieira wrote: > > One problem is because the launched process inherits the pipes to stdout > > and stderr > > Really, even with startDetached? I assumed that was more "detached" than > that ;) Right, nothing in it closes stdout, because people want to see the output. When we're connected to the terminal, that's usually useful. If we're connected to a pipe... not so much. > > but the shell sees the process group it launched exiting. > > I never understood much about "process group". Is it the issue here? Is the > helper considered part of the same process group as kdialog? startDetached does setsid(), so it starts a new session and process group. I have to confess not understanding SID and PGID very well either, but I do know that each process the shell launches is in its own process group and the shell waits for the process group to exit, not just the process it launched. > > It will probably close the pipe. Normally, this process would exit soon > > with SIGPIPE, but since a lot of code relating to sockets and pipes turns > > SIGPIPE off, it's possible that the detached process never receives > > SIGPIPE and simply remains forever. > > I'm confused as to which one you call the "detached process" here, > kdialog or the helper. The helper. > Are you saying what I need is a call to sigaction to re-enable exiting on > SIGPIPE, in kdialog, just before returning from main()? No, that won't help. > Could it be related to SIGCHLD, rather? I know QProcess[Manager] plays with > that, and it sounds like what the shell is waiting for from kdialog. But > surely inhibiting the -receiving- of SIGCHLD in kdialog shouldn't break the > parent shell receiving SIGCHLD when kdialog terminates? No, SIGCHLD isn't the case here. SIGCHLD is reset to default state by exec() and even if it were ignored in the helper, it wouldn't make a difference. > > > I tried close(1) like the kde4 kdialog was doing (due to forking, > > > though), > > > no change. > > > > There's another problem: you have a race condition between the parent > > (kdialog) exiting and the grandchild (helper) writing its information > > before closing stdout. > > No no, kdialog is the one writing to stdout. It's just writing out the dbus > service name that it knows the helper will use. > It's much simpler that way, it avoids all the issues you mention. Hmm... ok, then I don't understand. I need a bit more of information. 1) does the shell read properly from kdialog and get the service address? Is it correct? 2) did kdialog exit? Is kialog the process in state? 3) is the helper still running? Can you paste the ps j for it? I'd like to see the PGID and SID. If you can show the shell, the zombie process and ps itself, it would help comparison. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: QProcess::startDetached and bash stdout capture
On sábado, 25 de março de 2017 08:50:37 PDT Thiago Macieira wrote: > One problem is because the launched process inherits the pipes to stdout and > stderr, but the shell sees the process group it launched exiting. It will > probably close the pipe. Normally, this process would exit soon with > SIGPIPE, but since a lot of code relating to sockets and pipes turns > SIGPIPE off, it's possible that the detached process never receives SIGPIPE > and simply remains forever. Just found out that startDetached ignores SIGPIPE for all its child processes. And that has been there forever (see [1]). It's one of those old bug reports we used to get that the launched process received SIGPIPE after trying to write to stdout (like it should!) and then we decided to "help" the customer without understanding the issue properly. The problem is that this is very common: launched processes often write debugging information to stderr... So we can't change it now. Instead, we could add a flag to startDetached and to indicate we should close stdin, stdout and stderr, reopening with /dev/null, and let SIGPIPE back to the default. [1] http://code.qt.io/cgit/qt/qt.git/tree/src/corelib/io/qprocess_unix.cpp? h=v4.5.1#n1316 -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: What's kde-core-devel for?
On quinta-feira, 15 de dezembro de 2016 22:18:31 PST Albert Astals Cid wrote: > In the old days it had kdelibs development discussion but not that that has > moved over to kde-frameworks-devel, waht's kde-core-devel for? > > Can we kill it and move parts of it to kde-devel and other parts maybe to > release-team (like adding new software to releases and such)? > > What do people that read this list think? This list is about discussions about changes that affect all applications. How about killing kde-frameworks-devel and bringing that discussion back here where it belongs? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: Test your applications on Wayland
Em quarta-feira, 12 de outubro de 2016, às 07:47:44 CEST, Martin Graesslin escreveu: > Best is of course if Qt would release a 5.7.1, so that this cherry-picking > is no longer required. Most important is the first of those three patches > as without the applications are pretty much unusable. Should happen in the next couple of weeks, now that 5.6.2 is closed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: Review Request 128909: initial, minimal support for OS X
On quarta-feira, 14 de setembro de 2016 17:58:26 PDT René J.V. Bertin wrote: > > On Sept. 14, 2016, 7:33 p.m., Anthony Fieroni wrote: > > > processcore/processes_darwin_p.cpp, line 104 > > > <https://git.reviewboard.kde.org/r/128909/diff/1/?file=476875#file476875 > > > line104>> > > > > *inline* must be used in function definition not in declaration. > > I didn't see the point of the way the keyword is being used here either, but > I aligned myself to the current practice. > > So I take it I shouldn't only correct `argMax()`? It's all in the same .cpp, it doesn't matter. Inline is correct where it is. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: Why do we need to run two kwalletd?
Em sábado, 28 de maio de 2016, às 16:14:23 BRT, Albert Astals Cid escreveu: > El dissabte, 28 de maig de 2016, a les 10:19:59 CEST, Thiago Macieira va > > escriure: > > Commit https://quickgit.kde.org/? > > p=kwallet.git=commit=f7c1586264e029be50f3d9ca15ccad268a8c5601 renamed > > the binary and the D-Bus name for kwalletd in the name of > > coinstallability. > > > > Coinstallation is fine, but as a consequence, people with mixed KDE 4 and > > KF5- based systems now have two kwalletd running and often two > > kwalletmanager running, with two icons in their systrays and little > > information which is which. > > > > Moreover, there are two sets of wallets, with subtle differences because > > one was migrated off the other at some point in time, but then they > > diverged. > > > > Was that the correct/wise decision? Why not have *one* wallet for all > > programs? > > I think it was not a wise decision, it was probably done for people thinking > with a "KDE 5" mindset in which everything would move to KF5 & friends at > the same time. > > I don't think it's an easily fixable solution at this point unfortunately, > I'd like to be proven wrong :) It's simple to make kwalletd5 acquire both D-Bus names, which would prevent kwalletd from doing so. I don't know how to prevent it from being launched in the first place, though, so we just need to make sure that kwalletd5 starts first. There also needs to be a way to migrate the contents of the old wallet into the new. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Why do we need to run two kwalletd?
Commit https://quickgit.kde.org/? p=kwallet.git=commit=f7c1586264e029be50f3d9ca15ccad268a8c5601 renamed the binary and the D-Bus name for kwalletd in the name of coinstallability. Coinstallation is fine, but as a consequence, people with mixed KDE 4 and KF5- based systems now have two kwalletd running and often two kwalletmanager running, with two icons in their systrays and little information which is which. Moreover, there are two sets of wallets, with subtle differences because one was migrated off the other at some point in time, but then they diverged. Was that the correct/wise decision? Why not have *one* wallet for all programs? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: Qt 4 Builds
On domingo, 27 de março de 2016 10:57:18 PDT Ben Cooksley wrote: > As a general anecdote, the community needs to decide if we are going > to continue releasing and supporting Qt 4 builds at all. Considering > Qt 4 itself is EOL per upstream I believe, I think it's time we > followed suit. Not completely EOL'ed yet. Security fixes are still applied for now, but no other changes. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: Policy regarding QtWebKit and QtScript
Em sábado, 5 de março de 2016, às 08:09:22 PST, Thomas Friedrichsmeier escreveu: > I would advise KDE projects to be very > reluctant about moving away from QtWebKit, unless and until they have > very compelling reason to do so Like security. That's a compelling reason. The other day I noticed something strange with one of my online web mail accounts I only access using rekonq (QtWebKit), so it may be that the engine is already past expiration date. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: KDE file dialog
On terça-feira, 1 de março de 2016 21:20:03 PST Mark Gaiser wrote: > Isn't it possible to have the platform theme as it was before (with no > plasma deps) for others to use and then some "more fancy" plugin on top of > that which would implement just the plasma specific things? That way > everyone would be happy. Yes. Just volunteer to write that plugin. It may be even accepted as part of the Qt Project. The point is that it's not going to happen without developer effort. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: KDE file dialog
On terça-feira, 1 de março de 2016 00:44:05 PST Sven Brauch wrote: > > If you're not in the Plasma desktop, you should get the dialogs from the > > desktop you're in. For example, if you're in GNOME, the GTK style plugin > > should get the GTK dialogs. > > But that assumes the desktop you're in actually provides this > functionality. Only if it's a Qt-based desktop. If it's another desktop, then it's Qt's job to integrate with it properly. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: KDE file dialog
On segunda-feira, 29 de fevereiro de 2016 21:42:11 PST Sven Brauch wrote: > Hey, > > On 02/28/2016 03:58 PM, Luigi Toscano wrote: > > This is what I use: > > export QT_QPA_PLATFORMTHEME=kde > > > > and you need the integration plugin installed. It used to be part of > > Frameworks (frameworksintegration), it will be part of Plasma (but > > hopefully still usable without). > > It isn't, unfortunately. For example, it requires KSNI support, because > for some weird reason that is part of the platform theme. > > So using QT_QPA_PLATFORMTHEME=kde is basically not a viable solution for > any non-plasma desktop out there. Instead you are stuck with a 3rd party > solution like qt5ct to at least set the Qt / icon theme (color scheme is > quite hard already), and there is basically no viable option to get e.g. > KDE file dialogs back (instead of the unusable Qt5 default ones). If you're not in the Plasma desktop, you should get the dialogs from the desktop you're in. For example, if you're in GNOME, the GTK style plugin should get the GTK dialogs. The only left-over is for a Qt 5 app on a KDE 4 desktop. In that case, I'd argue that the Plasma plugin should be loaded, but it needs to be installed too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: Policy regarding QtWebKit and QtScript
On Saturday 26 December 2015 11:50:16 Adriaan de Groot wrote: > On Friday 25 December 2015 13:34:01 Allan Sandfeld Jensen wrote: > > Does Chromium build on FreeBSD already? In know in QtWebEngine we have > > several qmake conditions that would need to be changed from linux to > > posix:!mac, but I haven't tried because I wasn't sure if FreeBSD was even > > support by Chromium. > > There is a chromium port. I took a look at it, there's 380 patches that it > applies. I don't know how much of that is related to the application or how > much applies to the underlying engine. I have no idea if the application > works (well). I'll kick off a build just before I leave for Xmas dinner. Some of those changes may be only to unbundle some libraries and cause chromium to link to system-provided ones. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Policy regarding QtWebKit and QtScript
On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer wrote: > IIRC Thiago said that it didn't use private stuff, so recompiling should be > more than enough (in case it is really needed). I might be wrong. But that's the kind of breakage that is easily caught before Qt releases and should get fixed in updated qtwebkit source packages. qtquick1 is a whole other story. Its life ends now. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Policy regarding QtWebKit and QtScript
On Wednesday 23 December 2015 00:06:18 Luigi Toscano wrote: > Shouldn't it be the other way around? Workable solution first and drop the > old one later? The big problem of keeping qtwebkit in the 5.6 release is that it would need to be supported for the 3 years of the long term support release and that is simply too much to ask for, for a module that needs security updates we are hardly getting from upstream. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Why is C90 enforced in KDE?
On Monday 07 December 2015 09:29:59 Thomas Lübking wrote: > Either way, Qt5 supports down to MSVC 2010, Qt4 down to MSVC 2008, so either > we Qt 5.6 supports MSVC 2008. Qt 5.7 raises the minimum to MSVC 2012. Neither compiler supports stdint.h or some other nice C99 functions, like isnanf. You need MSVC 2013 for that. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Why is C90 enforced in KDE?
On Monday 07 December 2015 21:36:13 Thomas Lübking wrote: > You also may have some (personal, at least) data on relevant MSVC 2013 is in > practice? Because every gcc in the wild as well as clang should be able to > handle C99 - and so should MSVC 2015 and the intel compiler(s of the past). > Afaics, MSVC 2013 is the deal breaker here; but no warranty on that > statement... MSVC 2013 has good support for C99. MSVC 2012 does not. I should point all that MSVC has supported // comments in C sources since before it was known as Visual. But that's not the problem. The problem is the C99 Library, which MSVC did not support until 2013 and it only did so because C++11 imported it by reference. Microsoft does not care for C. They didn't implement C99 because they didn't want to, not because their compiler team was unable to. So my recommendation: write C++ code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KSyCoca, Thread safety, and Cache invalidation
On Saturday 14 November 2015 14:19:18 David Faure wrote: > indeed. > > > This code: > > > qCDebug(SYCOCA) << "checking file timestamps"; > > > const QDateTime stamp = QDateTime::fromMSecsSinceEpoch(timestamp); > > > > You're using the function that creates a LocalTime timestamp and yet: > QDateTime::fromMSecsSinceEpoch() indeed creates a localtime timestamp, > which means it calls qt_localtime() which calls tzset(), so it's not > threadsafe. > > #1 0x77118d1f in qt_tzset () at tools/qdatetime.cpp:2117 > #2 0x77119194 in qt_localtime (msecsSinceEpoch=1447506886000, > localDate=0x7fffbed0, localTime=0x7fffbec0, > daylightStatus=0x7fffbebc) at tools/qdatetime.cpp:2 333 We can easily add a mutex around this. An uncontended mutex on Linux is very, very fast. It might cause some false sharing and cache thrashing, but it shouldn't be too noticeable. > Yeah, I'm 100% sure most code out there doesn't convert to localtime, > hence my suggestion of QFileInfo::lastModifiedUtc(), to avoid breaking code. > > But then we also need QDateTime::fromMSecsSinceEpoch(time_t, UTC) ? Yeah... Another way, a little more difficult, would be to be lazy: keep the UTC date and wait for the user to decide which timezone to use. The problem with lazy is that QDateTime is shared and I removed the laziness in 5.5 due to threading problems. It's possible to do it if we do it right: we'd have to make sure we always write to the same members and in the same order. We'd need some atomics. > Is there really no way to do localtime/UTC conversions in a threadsafe way? The problem is finding out what timezone it is in the first place. We have QTimeZone and we could read the system file, bypassing localtime_r and tzset. John would know more. > This tzset() issue is really awful, we'll never manage to make sure that > 100% of the code that needs to be threadsafe uses UTC everywhere. Hence the mutex. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: [Development] Please help me get my pending review count down
On Thursday 20 August 2015 17:16:40 Thiago Macieira wrote: > On Friday 21 August 2015 01:45:12 Albert Astals Cid wrote: > > So with your new patches and https://git.reviewboard.kde.org/r/124856/ i > > can run konsole fine both with --nofork and in the normal mode. > > It wasn't racy before because the call from the parent process was queued > in the socket of the child process, but it didn't get processed until > app.exec() back in main() had been called. At that point, app existed and > had been registered. > > With the patches, the handling of the socket is done in a thread, so it > happens immediately, before KUniqueApplication::start returns and, > therefore, before the /MainApplication object is registered. > > The solution in the patch is a hammer. We can do it with more finesse by > having the child automatically start the new instance if it wasn't running > before. I don't see why we need the call to newInstance from the parent. The patches are in for Qt 5.6. My review count is now down to 51 pending patches. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?
On Monday 31 August 2015 14:41:00 Friedrich W. H. Kossebau wrote: > #ifdef COMPILING_TESTS > #if defined _WIN32 || defined _WIN64 Remove the Windows check. The next lines are valid outside of Windows too and should be used on all platforms. If and when I change Q_DECL_EXPORT to be protected visibility instead of default, this will be required. > # if defined(calligrasheetsodf_EXPORTS) > # define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT > # else > # define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_IMPORT > # endif -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: [Development] Please help me get my pending review count down
On Sunday 02 August 2015 10:32:21 Thiago Macieira wrote: ... which makes me wonder: did I fix the problem but never gave Albert the patches that fixed them? And the answer is... yes-kinda. I had fixed the issue, but never applied it to QtDBus. By replacing QThread with QDaemonThread, the problems went away. Note that continuing execution on the child side of fork() was not supported and now is TOTALLY broken. You'll deadlock. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 23:53:44 Jarosław Staniek wrote: Don't do that. If you use nullptr, there's no going back to zero because it's not the same. You've irrevocably locked yourself into requiring a compiler that supports it. I should say back to Q_NULLPTR, right? It's just helping people with old compilers by making the code SC. Back to anything that is not nullptr: 0, NULL, __null, Q_NULLPTR, whatever. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 04:07:41 Thomas Lübking wrote: We could just detect the compiler, and in need define nullptr 0x0, look the other side and hope for the best (ie. anybody on modern compilers anyway and nobody actually making use of std::nullptr_t atm. but just of the keyword) - not very nice, but better than breaking compilation(?) and not as invasive. It's not the same thing. First of all, it can't be a variable, it would have to be a macro. Second, a literal zero can be cast to boolean, integrals and floating point, but nullptr can't. That's the whole reason why nullptr exists in the first place. Q_NULLPTR isn't nullptr: when you use it, you acknowledge that it may be a zero and thus won't resolve ambiguities when calling overloads -- or, worse, will call the wrong overload (the one with int instead of the one with a pointer). Defining a macro for nullptr is dangerous... My recommendation: it's broken now so leave it. Fix it if someone complains, but otherwise just leave it. In one year's time, the discussion will be moot. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 14:34:49 Jarosław Staniek wrote: I also think we agree that anything other than 0 is good for readability and readability should be the priority. Note that the Qt 5.7 policy still allows and even asks for use of 0 as null in some places. The policy is: * always use nullptr in public headers. No exceptions. * use nullptr or 0 in non-public headers or regular sources so readability is good. There's no point in using nullptr where 0 is obviously a null pointer, like: char *s = 0; Then, there's the consistency factor -- a reason to cover the topic of null pointers in the guide. I find neither Qt is consistent in what to use, Qt is not an example here then. The policy above applies to Qt 5.7. For 5.6, only the first part applies and it needs to be Q_NULLPTR. In the worst case if someone calls us too modern, e.g for embedded projects, we'd be able a macro to ECM kdecompilersettings that defined nullptr back to 0 (or is this already supported by cmake/etc.?) Don't do that. If you use nullptr, there's no going back to zero because it's not the same. You've irrevocably locked yourself into requiring a compiler that supports it. PS: A Krazy check checking for usage of NULLs and Q_NULLPTR would be lovely. Checking the use of 0's isn't easy, right? -Wzero-as-null-pointer-constant Qt headers should pass that starting with 5.6. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 08:28:51 Ivan Čukić wrote: It isn't. The page is just plainly wrong. In that case, I retract my previous comments. Where are the *proper* requirements documented then (for future reference)? That's the list of platforms the Qt CI tests on. It lists both CI tested and untested things there. I would have said the docs or the wiki somewhere, but I've just discovered that the docs are wrong... :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
On Thursday 13 August 2015 12:59:01 Ivan Čukić wrote: Qt 5.5 requires gcc 4.8 for linux and windows. So even they increment the versions from time to time. s/8/5/ and you'd be correct. The Qt minimum version will rise to GCC 4.7 with Qt 5.7 and Qt will stop compiling in C++98 mode at that time. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 01:08:19 Ivan Čukić wrote: This is from the Officially supported platforms page at http://doc.qt.io/QtSupportedPlatforms/ Qt 5.5: Windows * - MinGW 4.9, MinGW 4.8 (apart from MSVC) Linux - 32/64bitgcc 4.8.1, gcc 4.9.1 I thought that was official enough. It isn't. The page is just plainly wrong. That's the list of platforms the Qt CI tests on. It's not the list of platforms we are supposed to compile with and support. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: [Development] Please help me get my pending review count down
On Tuesday 28 July 2015 19:06:59 Thiago Macieira wrote: Deadline: 6 weeks before Qt 5.7 feature freeze. If we reach that date and the patches are still not integrated, I will have to make a decision as Maintainer as to the future of them. It will be to either apply them despite any breakages caused in KDE applications or to drop them altogether, including all the fixes for race conditions and deadlocks. I will probably err on the side of caution, though. The Qt release team has published the feature freeze date for Qt 5.7 as Dec 18. 6 weeks before that is Nov 13. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Tuesday 04 August 2015 17:52:18 Ben Cooksley wrote: I'm assuming QLocale isn't routed through the platform plugin like other parts of Qt do in these cases, so we can't manipulate things there? Right. If a LC_TIME solution isn't possible, we could consider a QSystemLocale configuration that allowed the GUI platform plugin to set some details. Obviously this would not apply to non-GUI apps. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Tuesday 04 August 2015 10:03:20 John Layt wrote: One problem would be to update running processes (QLocale to track the locale file and emit some signal on changes) This is one of the areas Qt doesn't do well, on Windows and Mac soon as the underlying locale is change you get different results from QLocale, leading to inconsistent looking UI and weird bugs. On Linux it doesn't respond to changes at all until the app restarts, a more consistent approach. The best approach would be to have a QEvent that the app can catch and know to refresh everything when it is ready to do so. Again, something on the plan but a longer term issue to solve, as monitoring locale files or envvars or a registry for changes across multiple platforms in Qt would take some work. The problem with that is a thundering herd. All applications suddenly start updating, even if they haven't got anything to show. It's the same problem and requires the same solution as the language itself. There are mechanisms, but they're neither very well-used and they cause thundering herd. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Tuesday 04 August 2015 10:03:20 John Layt wrote: Nor do we want to use the data in the POSIX file as it has too many shortcomings and lacks features and simply uses a different set of format codes to CLDR. That POSIX file can only ever really be used to tell non-Qt POSIX locale using apps what settings to use under Plasma (i.e. Gtk/glibc stuff). If we're going to use a locale file for Qt internally we'd be better looking to load the CLDR json format instead. Indeed, it's an option I had been thinking of to replace Qt's custom locale feature once we stop shipping our internal CLDR data, or to allow embedded platforms to choose what supported locales to ship, but there are issues there and I'm not sure it's something Thiago would buy into. Ugh... If the date/time format in the POSIX locale is different, there are probably other differences too. I withdraw my requirement to make /bin/ls work then. What's your suggestion to make this work for a KDE environment and applications, John? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Monday 03 August 2015 21:57:36 John Layt wrote: The problem actually is that Plasma is not considered a system platform by QLocale, it doesn't go looking for what Plasma wants, it just uses the underlying GNU/Linux system settings. Convince Qt to hard-code in a lookup of some Plasma config file with user overrides to be applied whenever Qt apps run under Plasma and then you can get what you need. I had plans somewhere for how that would work, and how we could also make Gtk apps use our settings too by manipulating the LC_* settings. That's not going to happen. The only solution I'm going to accept is one that also applies to /bin/ls. So far, the idea of setting LC_TIME to a file containing the rules is the only solution I've seen to accomplish that. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Monday 03 August 2015 22:15:51 John Layt wrote: One problem is Qt completely ignores the contents of that file, and indeed I'm not sure it would even manage to extract the correct locale name even so you'd end up with some default. We just need to fix QSystemLocale and make it fall back to the C API if the locale is a file or one not found in the database it carries. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Monday 03 August 2015 22:00:04 John Layt wrote: On 3 August 2015 at 20:07, David Jarvie djar...@kde.org wrote: As I understand it, a QDateTime is invalid if either the date or time component is invalid. People would usually expect that if QDateTime::isValid() returns false, the object must be invalid. So a date-only value in which only the date was valid would make the whole object invalid, which is misleading and would almost certainly lead to mistakes. That is correct and it is a long-standing QDateTime behaviour that I would hate to change in a non-major release due to the huge amount of code that expects it to work that way. It's just not an option to use. QDateTime::isValid() indicates whether it's a valid date-time pair. It isn't. The QDateTime object may still contain a valid date or valid time though. And I agree with John that we can't change it in 5.x and we probably won't change in 6.0 either because that would lead instead to code that assuming that a date-only QDateTime equals a full QDateTime at midnight. Or, worse, somehow parsing a time-only QDateTime as a few hours into Nov 24, -4713, which leads to severe issues when this time-only QDateTime somehow gets converted to time_t (out of range). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Monday 03 August 2015 08:33:54 Martin Klapetek wrote: If the format you're looking for requires support from translators, please add a new class to QtCore. Suppose there's such QLocale setting as described above, then it would be just a matter of some regexp inside the time formatting function which would add/remove the ap/AP strings for the clock. I imagine. How would that setting be set? Who would set it? Is that something that the clock app would use and allow the user to set? If so, why not extract the time format and show that to the user? Or, at least, parse it to set the default of Use 24-hour clock? If the user wants to toggle 24-hour, save the new time format in the config file and use it to format the time next time. Alternatively, do you John have any roadmap about QLocale? Perhaps we could help with filling the missing bits into QLocale directly too. The roadmap currently stands as follows: Does this mean there is no roadmap? :) It means the roadmap is empty. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Replacement for KDateTime
On Sunday 02 August 2015 17:08:04 Martin Klapetek wrote: On Sun, Aug 2, 2015 at 3:26 PM, John Layt j...@layt.net wrote: If you do this you also need all of KLocale again which we also do not want. Don't even go there, we changed it for a purpose. Fwiw, over the year(s) of Plasma5, many times it was expressed that KLocale is greatly missed, especially when it comes to date/time formatting. QLocale just doesn't cut it and the digital clock applet is doing many tricks to get the stuff formatted as wanted. The biggest downside is that it applies to the clock applet only, so there can't be a single system-wide Use 24h-clock format switch. Clock in panel can/will be 24h format while everything else will be LC_TIME format (time stamps in Dolphin eg). If the format you're looking for is in the CLDR, you're welcome to add the support to QLocale. If the format you're looking for requires support from translators, please add a new class to QtCore. Alternatively, do you John have any roadmap about QLocale? Perhaps we could help with filling the missing bits into QLocale directly too. The roadmap currently stands as follows: -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: [Development] Please help me get my pending review count down
On Sunday 02 August 2015 13:46:02 Christoph Cullmann wrote: Hi, is one of the problems the misuse of QDBus in KUniqueApplication before the actual QApplication is constructed? That's the working theory, but it's not proven. All I know is what Albert reported when I asked him to test my patches in a KF5 environment and a Unity one. Would it be possible to just create in that case a temporary QCoreApplication on the stack in KUniqueApplication::start? QtDBus is supposed to work with construction, destruction and reconstruction of QCoreApplication. I think I have tests for that, but I would be surprised if you found a few cobwebs. Kate had similar I get stuck problems until the QApplication was correctly constructed in all cases before the first QDBus use. That's one of the things I fix in this patchset by moving the socket handling to another thread. However, I think I forgot to include the patches that change QCoreApplication event delivery and creates the QDaemonThread class... QDBusConnectionManager isn't using QDaemonThread, but delivery of events when QCoreApplication isn't extant relies on those patches. ... which makes me wonder: did I fix the problem but never gave Albert the patches that fixed them? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: [Development] Please help me get my pending review count down
[cross-posting to k-c-d to get KDE dev attention] On Tuesday 28 July 2015 14:51:49 Thiago Macieira wrote: - QtDBus changes: https://codereview.qt-project.org/101967 https://codereview.qt-project.org/102762 https://codereview.qt-project.org/103731 https://codereview.qt-project.org/103732 https://codereview.qt-project.org/103733 https://codereview.qt-project.org/103734 https://codereview.qt-project.org/103735 https://codereview.qt-project.org/103736 https://codereview.qt-project.org/103737 https://codereview.qt-project.org/103738 https://codereview.qt-project.org/103739 https://codereview.qt-project.org/103740 https://codereview.qt-project.org/109632 https://codereview.qt-project.org/109633 https://codereview.qt-project.org/109634 https://codereview.qt-project.org/109635 https://codereview.qt-project.org/109636 https://codereview.qt-project.org/109859 https://codereview.qt-project.org/109860 https://codereview.qt-project.org/110204 https://codereview.qt-project.org/110446 https://codereview.qt-project.org/110447 On the QtDBus changes: most are already reviewed and approved (thanks Alex!), but I need someone to investigate why KUniqueApplication is broken in konsole. There will be no new bugfixes or features to QtDBus until the set of changes above integrates because everything I develop (as can be seen from the change numbers) comes on top of the existing changes that haven't integrated. The changes listed above have been pending for months, especially because they seem to break konsole. As I don't have a debug build of a KF5-powered Konsole (or a release one, for that matter), I cannot debug this issue. I need help. I need someone to take the whole set of changes, apply to their Qt 5.5 build and test KF5-powered applications to see what gets broken and why. Please provide patches to either QtDBus, KF5 or the applications. If you can't provide patches, information will be welcome so others may produce patches. I may try to fix the issue myself, but it's not easy to do blind fixes for issues you can't reproduce. Deadline: 6 weeks before Qt 5.7 feature freeze. If we reach that date and the patches are still not integrated, I will have to make a decision as Maintainer as to the future of them. It will be to either apply them despite any breakages caused in KDE applications or to drop them altogether, including all the fixes for race conditions and deadlocks. I will probably err on the side of caution, though. We don't want either to occur. Can anyone help? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KSyCoca, Thread safety, and Cache invalidation
On Monday 20 July 2015 16:05:06 David Faure wrote: Or maybe QDateTime::currentDateTime() could avoid calling the awful tzset()? Thiago, any input? QDateTime::currentDateTimeUtc() does not call tzset. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KSyCoca, Thread safety, and Cache invalidation
On Tuesday 14 July 2015 19:28:58 Thomas Lübking wrote: Actually, checking currentTime() is already the problem here (causing the IO for the timezone stuff), see http://marc.info/?l=kde-core-develm=143533622526705w=1 (the 1st paragraph part of my comment somehow turned into a second-level quote) Comparing a monotic timer (QElapsedTime) is however - at least on linux - close to cost free PLUS: one can have an entirely free do not check again during this event cycle flag. If you just need to measure duration, QElapsedTime is your tool. Do not use QTime for this, as it can be affected by clock jumps and it accesses the timezone. If you need a machine-comparable time with other systems or across reboots, use QDateTime::currentDateTimeUtc(). That avoids refreshing the timezone database to convert to local time. Only use QDateTime::currentDateTime() if you want to show something to the user. There's no other valid reason. (writing to a log counts as showing to the user) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Frameworks compiler and Qt requirements after Qt 5.7?
On Friday 26 June 2015 17:46:21 Martin Gräßlin wrote: Thus I think the question about compiler requirement and Qt requirement are not coupled. Just because we raise the one or the other doesn't mean we should raise both. Yes, it does. You need to raise at a minimum to the minimum that the minimum Qt requires. If the minimum Qt is 5.6, then KDE's current requirements are higher than Qt's. So no change is necessary. If the minimum Qt is 5.7, then Qt's requirements are higher. Effectively, Qt's requirements become KDE's. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Frameworks compiler and Qt requirements after Qt 5.7?
On Friday 26 June 2015 16:24:50 Mark Gaiser wrote: Qt 5.7 minimal requirement GCC 5.1 (or somewhere in 5.x) Clang 3.6.1 (or perhaps even 3.7) MSVC 2015 We then have full C++11 support across the board and much of C++14 supported as well. MSVC clearly being the limiting one in that area for the C++14 support, but still quite decent. Current test results for tst_compiler with MSVC 2015: SKIP : tst_Compiler::cxx14_binary_literals() Compiler does not support this C++14 feature SKIP : tst_Compiler::cxx14_init_captures() Compiler does not support this C++14 feature SKIP : tst_Compiler::cxx14_generic_lambdas() Compiler does not support this C++14 feature SKIP : tst_Compiler::cxx14_constexpr() Compiler does not support this C++14 feature SKIP : tst_Compiler::cxx14_decltype_auto() Compiler does not support this C++14 feature SKIP : tst_Compiler::cxx14_return_type_deduction() Compiler does not support this C++14 feature SKIP : tst_Compiler::cxx14_aggregate_nsdmi() Compiler does not support this C++14 feature SKIP : tst_Compiler::cxx14_variable_templates() Compiler does not support this C++14 feature The reason for this is that we chose to require SD-6 for C++14 support and MSVC 2015 does not follow it. Therefore, for Qt's purposes, MSVC 2015 supports *no* C++14. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 123874: Fix build with Qt = 5.4.2
On Thursday 21 May 2015 17:32:33 Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123874/ --- Review request for Build System, Phonon and Harald Sitter. Repository: phonon Description --- Or to be more accurate, with commit 3eca75de67b3fd2c890715b30c7899cebc096fe9 I am not convinced this is best solution, but requires least changes to current cmake code. Upgrade past commit 083c9269ed73e8771e1dbe10812696b45b7389f3 and report back if it worked. If there are problems, let's fix them in Qt itself. If there are issues that can't be fixed in Qt itself, then kde-multimedia would be the wrong mailing list to discuss it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Alternative to QDateTime::isDateOnly ?
On Tuesday 28 April 2015 22:32:12 Christian Mollekopf wrote: On the other hand, the problem of the variable return type is not solved by that, overloads and separate getters always seemed like a workaround to me, so it seems like Qt would benefit from something like boost::variant (aka. a discriminated union) Why wouldn't QVariant be enough? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Distros and QtWebEngine
On Tuesday 21 April 2015 15:44:35 Kevin Kofler wrote: Thomas Lübking wrote: I know nothing about the trouble w/ QWebEngine¹, but what is insinuated here is that it's completely unusable, unmaintainable, undistributable - ie. Qt then simply won't have any full blown web engine, resp. has one that nobody uses? That issue would seem -a tiny bit- fr beyond kdepim or anything KDE related, to me those claims read: Qt now has no longer a web kit/engine. That's exactly the problem. I have objected to the QtWebKit deprecation on those exact grounds on the upstream Qt mailing list, but my complaints have fallen on deaf ears. I think that's not a fair characterisation that they fell on deaf ears. They were heard, but it's simply a matter of fact that WebKit is no longer a possible target, since Apple removed the necessary bits out of WebKit and they're a much harder group to work with than Google. So it's simply not an option to continue to develop WebKit. If someone has 100 full-time developers to spare, I'm sure un-deprecation could happen. (I'm not exaggerating) That said, Google is a web-centric company and as such more likely to put evil stuff into their browser than Apple. In fact, Chromium and Chrome already have the reputation of hiding spyware (mis)features in their code. I'm not sure about spyware, but they do have a history of inserting things of theirs, like the HTTP-over-QUIC they recently talked about. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review request: QBluez
On Tuesday 17 February 2015 23:00:15 Albert Astals Cid wrote: It doesn't have the DBus ObjectManager, so that call should fail like that. Well, then the test should try to detect it and QEXPECT_FAIL, havign tests fail means something is bad, and as you say it's not bad, just expected. QEXPECT_FAIL is when you know it's wrong but either can't solve it or can't do it now. If it's an expected situation, handle the situation. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review request: QBluez
On Monday 16 February 2015 23:51:17 Albert Astals Cid wrote: I'd like to ask for a review of the QBluez library [1]. Using Q* is usually frowned upon since the Qt people have made it quick clear that they reserve the right to use Q* names themselves, i'd look for a new name. Unless, of course, you want to contribute the code to the Qt Project. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 122320: use xcb-screen count instead of qguiapplication.screens
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122320/#review75433 --- Can you explain why the count is different and why XCB's count is the correct one? In the commit message. - Thiago Macieira On Fev. 4, 2015, 12:31 a.m., Nick Shaforostoff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122320/ --- (Updated Fev. 4, 2015, 12:31 a.m.) Review request for kde-workspace, Martin Gräßlin and Thomas Lübking. Repository: plasma-workspace Description --- this patch makes kcminit behave like in kde4: it uses proper xcb screen count which may be different from QGuiApplication::screens().count(). for example when i connext external monitor via vga to my laptop, xcb screen count is still '1', while QGuiApplication::screens().count() returns '2'. switching from QGuiApplication to QCoreApplication still wasn't possible because modules like 'mouse' need gui initialized and would crash if kcminit uses QCoreApplication. Diffs - startkde/kcminit/CMakeLists.txt b17951f startkde/kcminit/main.cpp 1008966 Diff: https://git.reviewboard.kde.org/r/122320/diff/ Testing --- i have built kcminit on ubuntu vivid alpha 32-bit, replaced binaries and libraries in the system and successfuly could run kcminit_startup and reboot also went fine. Thanks, Nick Shaforostoff
Re: Another proposal for modernization of our infrastructure
On Saturday 31 January 2015 20:56:41 Martin Graesslin wrote: I have to agree. Whenever I need to do a change for Qt I need to google for how to do it. Including putting serious thought in how the push command must look like, how I need to adjust the examples provided and for which ref/for/foo it has to be this time. This is something which seriously concerns me with the outlook of gerrit. git has a steep learning curve, gerrit adds quite some further steepness to it Ossi has been working on a new script called git-gpush that will automate most of the pushing work for you. All you'll need to do is tell it which commits you want to push, like: git gpush HEAD +thiago +ossi +tronical It would have been ready if I had had the time to review it. You can find it in his dashboard and mine (in qt/qtrepotools). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Another proposal for modernization of our infrastructure
On Friday 30 January 2015 10:57:33 Ben Cooksley wrote: Given that upstream has had multiple attempts now at an improved interface, I would question whether they would be willing to accept a user interface which is suitable for our needs. It appears that they are quite comfortable with an interface many find unintuitive or difficult to use. If they weren't, considering the number of backers it has - one would think someone would have sponsored such an interface. They would have if they still had major problems with the usability of the tool. It probably just so happens that all the backers are used to the interface, however bad it might be, and don't feel the need to sponsor such a work. I find myself in that category. Provided there is a one-page-diff support, Gerrit works very well for me and I don't find it clumsy at all. That's not to say I don't want it improved -- I do -- but I don't feel the pressing need to for someone to work on it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Another proposal for modernization of our infrastructure
On Saturday 31 January 2015 20:37:31 Christoph Feck wrote: On Saturday 31 January 2015 20:07:42 Eike Hein wrote: [...] Qt is using gerrit and we intend to remain a major stakeholde in Qt development, which means a sizable number of KDE developers need to be familiar with gerrit anyway [...] Excuse me, but if KDE developers will have to follow equivalent steps as described at http://qt-project.org/wiki/Setting-up-Gerrit to contribute, then I predict another big loss of developers. Please note the instructions stop at the Configuring Git heading. All of the rest is already done for anyone who is already using Git. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Another proposal for modernization of our infrastructure
On Thursday 29 January 2015 17:22:45 Thomas Lübking wrote: Maybe it's possible to borrow or upstream the Qt mod? See the repository qtqa/gerrit in the Qt infrastructure (Gitorious, Gerrit, etc.). See commits 6f3d74b7bda9d86a16d33ed16a0806b74482d57c, f6ec276bbd6980e4619e85abd3b3d62f7156fbfc, 2f6d90dc0ba7853d32a902dbaf92e69ba133c2b1, d124a6d287ef836b3290d92baa2f1e14b18a36bd and 66522d326988614cbe544103f99be14e415e44bd. Ismo, what's the status on upstreaming the one-page-review feature? What did upstream say last time this was attempted? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Another proposal for modernization of our infrastructure
On Friday 30 January 2015 10:04:01 Martin Graesslin wrote: Also I don't think it can be improved, this looks really fundamental in gerrit. I am not the only one who notices the problem and AFAIU Qt even patches around the issues. Given that I'm not confident that we can improve the software, that upstream accepts the changes and that upstream doesn't break the UI again in future releases. Many of your complaints about usability (threading, replies, etc.) are solved or at least partially addressed in the new Gerrit UI, which versions like 2.7 have. It might not be the default on the installation, so check the settings and try to turn it on. Note that there's no patch to make an single-page all-diff for the new UI. It only exists for the old UI, which is why the new UI is disabled for the Qt Gerrit. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Changes to our Git infrastructure
On Saturday 03 January 2015 15:35:12 Jeff Mitchell wrote: - Not needing a CLI tool in an obscure language (PHP, Java, .NET,...). .NET is a framework, not a language. Maybe you meant C#. Regardless, I fail to see how any of those are obscure. They're three of the most popular and widespread languages in the world. For command-line applications on Linux? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Changes to our Git infrastructure
For Gerrit: - Code Reviews: - CLI client to make changes to the code review system and to manage the review (including retrieving the commits/patches) Check. It's ssh host gerrit subcommand Client should have good documentation. - System should automatically set the CC / Reviewers / etc for a review rather than the submitter needing to know who to set. Check. Also, from experience with Tizen's Gerrit: if the automatic list has more than 3 people, all reviews stop getting done since everyone will be overwhelmed by reviews and they will thinki it's someone else's problem on this one. - Changes should be shown per-commit. Check. - Updates to reviews should leave prior reviews intact. Check. - Patches should be readable, commentable on line by line. Check. - Proposed changes are vetted by the CI system (compilability, tests, etc). Check. The most common use is to run before merging into the official tree; Qt is the only project I know that does it after. - Ability to accept the changes through the code review system Check. - Can mark a review as Bad (Don't Ship This) / Okay (Fine with it going in) / Good (Ship It) Check. And you can change at will, add more categories, roles, etc. - Can determine whether the review was by someone with commit rights. Check. Not obvious, but it is doable, since you can look up people's group memberships. Might make a nicer feature to list the group(s) they're member of in the UI. - Can produce a list of review requests given a certain set of criteria easily (preferrably savable) Vague requirement without knowing what criteria were in mind here. So I'm going to go and say check since it can look up the criteria I want. - Developers can tweak proposed changes easily before they are landed without the involvement of the submitter. Check, you can push a new commit with the same Change-Id. - Post Commit Review: - Be able to comment on reviews, other than by replying to a mail on kde-commits Check. - Project Management: - Coherent and Performant It's Java, but unlike Jenkins, we don't seem to have had problems with it for Qt. - One canonical place to get the desired information (no more duplication) Vague requirement. - Can either be links to elsewhere or directly hosted by the system Check. - Covers items like documentation (wiki, api), bug tracking, task boards, CI, code browsing and reviews, etc. Vague. Assuming items like documentation ... are in Git, everything works. - Repository Hosting: - Strong case has been made for retaining scratch repositories. Out of scope, needs separate website and tools. - A weaker case exists for clone repositories - making them more nice to have than critical. Out of scope, needs separate website and tools. Though it might be possible with the command-line, just not the web UI. I need to investigate. - Anongit propagation should be within 1 minute. Totally out of scope. - Overall: Sensible email notifications Check, requires modifications from the Qt Project, since the default email notifications are not sensible. - Overall: Capable web APIs for the system as a whole Check. There are also a couple of items which come from sysadmin, to make things easier for us in the long run: - Supported well: Upstream should be stable with a viable future. We should also be able to build a relationship with one or more developers who authored/maintain the application. This is helpful in obtaining assistance should it be necessary and assists us in getting additions upstreamed. Check. Dozens of projects use Gerrit. - Integrated: A single application which handles everything will always be able to offer a better and more coherent experience than several applications we have connected to each other. There is also a lower maintenance burden from an integrated application, as it is one piece of software to update - not 3 or 4. Not check, since Gerrit alone will not correspond to KDE's desires (project creation, scratch clones, etc.) - Care about compatibility: Upstream should have an interest in stable interfaces, both externally facing (Web APIs) and internal (application plugins, etc) As the recent Dr Konqi problems have demonstrated, upstreams which act without regard for backwards compatibility can introduce significant problems for us. Check. - Scalable: The applications which make up our infrastructure need to be able to handle the demands we place on them without consuming resources unnecessarily. I understand it is, but you'll have to speak to other sysadmins. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Changes to our Git infrastructure
On Saturday 03 January 2015 12:39:42 Lydia Pintscher wrote: On Sat, Jan 3, 2015 at 12:07 PM, Thiago Macieira thi...@kde.org wrote: For Gerrit: I think before checking Ben's list against specific implementations we should make sure the list is actually correct and complete. It's the basis for an important decision so let's do this step-by-step? :) I was only going to comment on the request to automatically add reviewers but then I thought I might as well give more information instead of a single paragraph. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Changes to branch management
On Tuesday 23 December 2014 17:45:23 Milian Wolff wrote: +1 to all of the above. What about tags btw? In KDevelop e.g. it would only be a nuisance if someone would delete one of our stable branches, but deleting one of the release tags would be ugly as I'd then need to figure out what commit was chosen for what release. Bye and thanks for your continuous work Ben, much appreciated! Take care. Tags shouldn't be deleted, period. That's something for the repo owner, in case of a mistake. Also note that people will get those tags and git remote prune doesn't delete them. So don't push bad tags. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: ThreadWeaver: using QObject's as Jobs
On Tuesday 25 November 2014 12:07:27 Milian Wolff wrote: On Monday 24 November 2014 19:28:57 Thiago Macieira wrote: On Monday 24 November 2014 23:00:45 Mirko Boehm wrote: Can I inherit from QObjectDecorator and pass this as the JobInterface *decoratee? The decorator wraps and object and acts as a QObject. It does not really care if the wrapped job is a QObject already. It will add defined signals to the job. Please don't create new classes named Q + Capital letter unless you're doing that inside the Qt Project. This object lives in the ThreadWeaver namespace, so that should be fine, no? It's decorating a QObject after all. Ah, then it's ok. It's the global namespace that's a problem. As long as no one builds Qt with -qtnamespace ThreadWeaver :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: ThreadWeaver: using QObject's as Jobs
On Monday 24 November 2014 23:00:45 Mirko Boehm wrote: Can I inherit from QObjectDecorator and pass this as the JobInterface *decoratee? The decorator wraps and object and acts as a QObject. It does not really care if the wrapped job is a QObject already. It will add defined signals to the job. Please don't create new classes named Q + Capital letter unless you're doing that inside the Qt Project. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: attica_kde.so closing crash
On Sunday 16 November 2014 18:18:07 Jeremy Whiting wrote: ==22353== Address 0x1cd1b758 is not stack'd, malloc'd or (recently) free'd This looks like the case of accessing memory from a plugin that has been unloaded. Note how the backtrace started from qlibraryCleanup in qlibrary.cpp, which is unloading all plugins. This is a plugin-unload-order problem. The KDE platform plugin got unloaded after the bearer manager plugin. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: attica_kde.so closing crash
On Monday 17 November 2014 12:07:36 Jeremy Whiting wrote: Ok, how can I fix the unload order then? You don't. The libraries are unloaded in alphabetical order, but I might change that later to a QHash and then the order is arbitrary and random. Fix the problem in a different way. If necessary, submit a patch to QNetworkAccessManager and/or the bearer plugins so it stops tracking the pointer on plugin unload. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: New CHANGELOG: keyword
On Saturday 08 November 2014 01:52:06 Albert Astals Cid wrote: El Divendres, 7 de novembre de 2014, a les 16:35:21, Thiago Macieira va escriure: On Saturday 08 November 2014 00:58:49 Albert Astals Cid wrote: Hi, we've added a new CHANGELOG: keyword to https://techbase.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_ an d_ SVN_log_messages So that you highlight that that comit should end up in the release notes. We still need something that parses it but step by step :) Why not use the Qt script[1]? I also recommend making it a tag like Qt's, so people can write more than one line. https://codereview.qt-project.org/76087 Does the Qt tag support being there without text and thus creating the changelog based on the first line of the commit? You'd have to modify the script for that. We don't do that in Qt because the commit subject and the changelog have different audiences. The commit subject and most of the body are meant for other developers of the same source code and describe why the change was made, how it was made, other alternatives, risks, etc. The changelog is meant for the users of the API, who aren't familiar with the internals, and describe what changed that is relevant for them. Example: QMainWindow: respect the maximum size of the central widget Make sure the dock widgets get the available space when the central widget cannot expand any more. [ChangeLog][QtWidgets][QMainWindow] Dock widgets will now be resized properly when the central widget has a fixed size. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KDE4 SSL
On Tuesday 21 October 2014 08:13:07 Rolf Eike Beer wrote: Am Dienstag 21 Oktober 2014, 10:52:38 schrieb Thiago Macieira: On Monday 20 October 2014 21:00:51 Pali Rohár wrote: Hello! Do you know which KDE4 libraries are using SSL and TLS protocols? And it is now possible to disable SSLv2 and SSLv3 protocols in KDE4 libraries? That would be QtNetwork, by way of kdecore and kio. SSLv2 is already disabled by default. To disable SSLv3 by default, you need to modify QtNetwork. What happens if OpenSSL is built with no-ssl3? Then SSLv3 isn't enabled. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KDE4 SSL
On Monday 20 October 2014 21:00:51 Pali Rohár wrote: Hello! Do you know which KDE4 libraries are using SSL and TLS protocols? And it is now possible to disable SSLv2 and SSLv3 protocols in KDE4 libraries? That would be QtNetwork, by way of kdecore and kio. SSLv2 is already disabled by default. To disable SSLv3 by default, you need to modify QtNetwork. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Question about QSslCipher::protocolString
On Sunday 19 October 2014 18:14:36 Thomas Lübking wrote: On Sonntag, 19. Oktober 2014 16:35:35 CEST, Dawit A wrote: protocolString: SSLv3 ... However if one uses openssl directly, the following information is returned: $ openssl s_client -connect blog.mozilla.org:443 New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA ... So the negotiated protocol when using openSSL directly is returned as TLSv1.1 where as QSslCipher almost always returns SSLv3. My question is why the negotiated protocol in QSslCipher is different from the one we get through openssl directly? I get SSLv3 from blog.mozilla.org, but TLSv1.2 from mail.google.com. Checking qDebug() QSslSocket::defaultCiphers();, QSslCipher(name=ECDHE-RSA-AES256-GCM-SHA384, bits=256, proto=TLSv1.2) is top of the list here and most SSLv3 variants on the very bottom. -- THERE IS NO TLSv1.1 IN THAT LIST, NOR IN ::supportedCiphers() However, I don't know why QSslSocket doesn't provide TLSv1.1 (here) This is looking like a Qt bug instead. Can you investigate QSslSocket instead? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled
On Friday 26 September 2014 07:05:09 Marko Käning wrote: Hi Thiago, On 26 Sep 2014, at 07:01 , Thiago Macieira thi...@kde.org wrote: And still it needs to be studied for Qt5, unless the plan is to never transition to Qt 5 (which means KDE-on-Mac will stop compiling within 2 years). did you miss our efforts on KF5 including setting up an OSX/CI system [1]? René has also produced patches for KF5 frameworks, which my OSX/CI system could prove to be buildable already. :-) So, we’re aware of it, but René is up to now focusing more on cleaning up KDE4, since we’re not yet there with any KF5 ports on MacPorts. But we’re getting there these days. :-D You're missing my point. My point is that this problem requires a Qt 5 solution, since the proposed solution won't work there. That solution should be understood, if not developed, before this patch gets accepted. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled
On Friday 26 September 2014 11:08:23 René J.V. Bertin wrote: Patches should *always* be upstreamed, especially when we are essentially the distributor (in essence we are carrying forks of our own projects due to these patches). Heh, and when upstream means Qt, we'll probably have to maintain our own local patches waiting and hoping they'll ever get incorporated upstream? Remark, that's about the same situation as we (kde-mac) are currently in w.r.t. KDE Why do you think those patches would not get into Qt? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled
On Thursday 25 September 2014 13:32:41 René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120363/ --- Review request for KDE Software on Mac OS X and kdelibs. Repository: kdelibs Description --- Applications can be defined in their CMake file as being `NOGUI`, but until now this has had very limited effect. Especially on OS X, those applications can still construct a minimal GUI and thus have visual presence in the Dock and application switcher (and have a menubar as well). This patch proposes to define a preprocessor token, `KDE_WITHOUT_GUI`, for those targets, and uses that token to set the default value for the `GUIenabled` option of the `KApplication` and `KUniqueApplication` classes. This could potentially be combined on OS X with the CoreFoundation call that turns a running application into an agent (see https://git.reviewboard.kde.org/r/120354). Note that this change can't apply to a Qt5-based build since QApplication no longer has that extra parameter. Are we sure we want to add a new feature that is Qt4-only and has a short lifetime? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled
On Thursday 25 September 2014 22:32:35 René J.V. Bertin wrote: Ah, apparently Thiago missed the multiple recent reminders of the fact that we OS X users are going to be stuck in/with KDE4 for a tad longer than the average Linux user (Debian apart, maybe? ;)) Anyway, I guess I'm going to have to look again at how exactly `GUIenabled=false` leads to the qt_menu.nib not being loaded in Qt ... Note that you're applying the change to X11 too and that will have an impact, but limited lifetime. If the problem is Mac only, then maybe apply the solution to Mac only too. And still it needs to be studied for Qt5, unless the plan is to never transition to Qt 5 (which means KDE-on-Mac will stop compiling within 2 years). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using Gerrit for code review in KDE
On Monday 15 September 2014 16:49:39 Milian Wolff wrote: Where do I see the diff there? In the gerrit that runs on qt-project, I can easily click one button to go to a unified or side-by-side diff view. Is that a custom extension? Generally, it seems as if the qt-project gerrit has a much cleaner GUI. I'm pretty lost when looking at the one up there... It's an extension. Ossi, where's the source code for the Gerrit the Qt Project uses? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Retiring and testament
On Tuesday 09 September 2014 17:41:59 Kevin Ottens wrote: You will still see me around of course. I'm retiring from KDE Frameworks, not from KDE. I just want to focus mainly on Zanshin and some of my community work (french promo, manifesto, e.V.). Because of my other involvements you'll probably see me sending patches from time to time to KF5, just don't expect me to monitor closely what's going on or to drive anything anymore. Hi Kevin Thank you for so much work you've done and for leading the KF5 effort. Also, I am actively discussing with Kevin Krammer to pass him the torch. I guess most of you know him. He will be a good replacement since he has a good view on the whole stack. Not to neglect the fact we both have the same first name so you feel right at home. Yeah, thanks for making the transition easy! The first name helps! -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KDE Applications December 2014 release: which apps are targeting Qt4/Qt5?
On Monday 21 July 2014 13:26:32 Frank Reininghaus wrote: * Many applications have an embedded terminal, which is provided by the Konsole KPart. If Konsole does not release a Qt5-based version in December, then any application which does will not have an embedded terminal any more. * All of Konqueror's functionality is provided by KParts that are provided by libraries and applications and that are loaded at runtime. If some of these KParts will not have a Qt5-based release, then the functionality of a Qt5-based Konqueror would be severely limited. Are we figuring out a way to co-install both sets of KParts and load the right one at runtime? The Qt plugin mechanism should be enough to prevent the wrong .so file from being loaded, but it would be easier on the system if the files were on different paths on the filesystem. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: code guideline
On Saturday 28 June 2014 08:51:42 Rodrigo Bonifacio wrote: Dear all, is there any code guideline that recommends developers to avoid the use of exception handling mechanisms within the core libraries of KDE? I'm going to let others speak about the use of exceptions in your own code, but note this: Qt classes are not exception-safe. So if you are allowed to use exceptions in your part of the KDE libraries, make sure that you don't: a) use Qt container types, like QList and QVector, on types that may throw on construction or copying b) let exceptions escape back into Qt code, including: 1) slot activation 2) event handling 3) callbacks (such as qSort) Using QString and QByteArray in code that uses exceptions is mostly safe because no exception can happen inside them. Stack unwinding would be no different than a regular end of scope anyway. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Compatibility problems with latest GTK+ applications
Em qui 08 maio 2014, às 15:01:10, Martin Gräßlin escreveu: On Thursday 08 May 2014 14:39:49 Matthias Klumpp wrote: 2014-05-08 9:31 GMT+02:00 Martin Gräßlin mgraess...@kde.org: * CSD styled windows don't react on compositing changes [1] * Double decorated windows [2] * CSD styled windows do not detect when re-parented to a decoration [3] * CSD context menu ignores _NET_ALLOWED_ACTIONS [4] * CSD context menu doesn't use _NET_DESKTOP_NAMES [5] * CSD context menu doesn't honor _NET_DESKTOP_LAYOUT [6] * Shadow included in CSD window [7] * Window disappears when middle clicking client side decoration [8] * Missing maximize and minimize buttons in client side decoration [9] * Decoration buttons do not follow custom specified layout in desktop environment [10] * A hung GTK application cannot be closed [11] * Context menu on window decoration is not the one of the environment [12] * No time based drag delay on window moving [13] * No drag delay on window resize [14] That is pretty great, thank you for taking the time! Some of these things unfortunately are design-decisions by GNOME, which I raised in IRC discussions a while ago, and where I think the interest is pretty low for fixing them (after getting some feedback on e.g. the CSD menus). which of the bug reports do you consider affected by design-decisions? I did not even report the mismatching cursors and the missing close button for dialogs and similar things. I'd say at least 11, 12. A design decision of any CSD is that the client controls its closing and, therefore, if the client is hung, you can't tell it to close. You can kill the application with kill, xkill or using a global shortcut (Alt+F4, Ctrl+Alt+Esc, etc.) As for the context menu, it can be said it's part of the themeing: the CSD application needs to get information from the desktop in order to draw the proper decorations. You could say that includes what the context menu should look like. That said, I fully expect 4, 6, 9, 13 and 14 to be also closed as working as designed because of the UX decisions. That is, we think this dialog shouldn't have a close button, so we won't draw it, despite what the desktop says. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Co-installability
Em ter 29 abr 2014, às 21:00:57, Christoph Feck escreveu: I cannot remember we had these issues with the KDE3-KDE4 transition. Can anyone explain what changed? What's wrong with separate prefixes? There's no such thing as separate prefixes. Everything in Linux distro is installed to /usr. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: DBus-activated applications
Em sex 04 abr 2014, às 20:32:55, David Faure escreveu: The new idea, as a result of last year's freedesktop summit, is to improve upon this and generalize it : even the first instance can be started with a DBus call, using DBus activation (these .service files installed in share/dbus-1/services). Did you have a chance to discuss with Lennart and Kay about systemd+kdbus not using /usr/share/dbus-1/services, but systemd unit files instead? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 117157: Unlock session via DBus
Em seg 31 mar 2014, às 08:55:05, Martin Gräßlin escreveu: Personally I have to disagree. To me the graphical login is a an asset which needs to be protected in a stronger way. Access to a tty should not equal access to the graphical system. The fact that X is broken should not result in us adding further insecurities which need to be fixed up once we transit to Wayland. The opposite has to happen: all the small security issues we let in, because X was already broken need to get fixed. This thread turned into a nice TODO list I'm not asking for it to be insecure. I've already authenticated by logging in to the virtual console. So let me unlock my session via D-Bus. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Review Request 117157: Unlock session via DBus
Em dom 30 mar 2014, às 10:12:11, Thomas Lübking escreveu: On Sonntag, 30. März 2014 00:07:15 CEST, Martin Klapetek wrote: However many distros disable gdb attach to running processes by default; you have to either be root or echo 1 somewhere in /proc (for which you also need to be root). /proc/sys/kernel/yama/ptrace_scope I'd never heard of Yama. It stands to reason that most distros do not have it, which in turn means most distros allow attaching. And I guess most developers will enable the tracing feature so they can attach and debug processes. On top of this, one could also have ksmserver PTRACE_ATTACH/SEIZE itself (at least on linux that used to be a singleton feature), but root access more or less implies game over in this context (you could simply replace ksmserver or the greeter app with a fixed variant and wait for the next incident) Usually, root access and same-user access imply game-over. Which is why I think this feature should be allowed in. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 117157: Unlock session via DBus
Em dom 30 mar 2014, às 10:10:06, Thomas Lübking escreveu: un/locking depending on HW dongles (bluetooth, USB) is certainly a nice feature, but requires some sort of internal support (where you'd just configure the HW id to trigger this) Unlocking via a dbus command is imo very problematic. I disagree. The user already authenticated via their password before they were able to send the D-Bus command in the first place. So why not allow them to unlock? If we require a password, the user would be trapped into having it in his shell history or invited to store it (plaintext) on disk. If such tool would be required, it could work by having the user solve a captcha before reading the PW from stdin (to prevent automization) $ kscreenlocker unlock 9*8+3? 75 Password? $ Please don't invent authentication mechanisms. That's what we have PAM for. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 117157: Unlock session via DBus
Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu: I disagree. The user already authenticated via their password I should have been more precise in the first sentence: Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk] How does the password end up on disk? before they were able to send the D-Bus command in the first place. So why not allow them to unlock? Because we protect the session, not the shell. Occasional access will already be stopped by having to use gdb in the first place and even then it's possible to protect the process from manipulation by the same UID. I maintain that this is not a protection. Unlocking without a password remains possible, but you're making it difficult for those of us who tinker with KDE and sometimes misconfigure the authentication. In the past, I could kill a process when I had improperly installed KDE and the greeter couldn't authenticate via PAM. Now I have to kill ksmserver or cause the session to exit via D-Bus. All processes by the same user should be trusted. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 117157: Unlock session via DBus
Em dom 30 mar 2014, às 21:40:36, Thomas Lübking escreveu: On Sonntag, 30. März 2014 20:53:01 CEST, Thiago Macieira wrote: Em dom 30 mar 2014, às 19:38:14, Thomas Lübking escreveu: Unlocking via a dbus command [that requires password authentication] is imo very problematic [because that will end up exposing the password on-disk] How does the password end up on disk? One of the use-cases in the linked bug is to invoke this by pam_usb or some bluetooth script. If the dbus call would require a password, the script could end up looking like qdbus org.kde.kscreenlocker unlock 1ns3cur3 Don't pass the password via D-Bus. The call should just be: qdbus org.kde.kscreenlocker unlock The development situation is special and actually what i had in mind when saying any way to circumvent authentication to this very session should be guarded by a special knowwhatido key [or require active authentication] I've already authenticated by logging in, even if in another terminal. Just unlock the session already. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 117157: Unlock session via DBus
Em seg 31 mar 2014, às 00:01:13, Thomas Lübking escreveu: If they can gain access to a TTY login we are already screwed leaving aside the present issue (/MainApplication quit being exposed to dbus) and given ptrace (gdb solution) is denied: in how far? (beyond killing the session, ie. being a nasty little jerk They can already access all of the other applications and the user's files. They can attach gdb to any of the user processes. They can listen to all messages on D-Bus. They can attach to any IPC mechanism the user has access to. They can also launch new X applications. So they may not cause the session to unlock, but they can still launch a keylogger application that will take effect when the legitimate user returns and unlocks the screen. And, oh, the attacker can change the user's password! If it's a matter of unlocking the screen, they can use passwd to change the password, unlock the screen with the new password and then happily use the running session. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 117157: Unlock session via DBus
Em seg 31 mar 2014, às 01:43:22, Thomas Lübking escreveu: On Montag, 31. März 2014 00:36:29 CEST, Thiago Macieira wrote: They can already access all of the other applications depends on whether they actively suppress such. and the user's files. true. They can attach gdb to any of the user processes. depends on whether they actively suppress such. We've already established that the default is allowing ptracing. They can listen to all messages on D-Bus. They can attach to any IPC mechanism the user has access to. True. Question is whether applications expose secrets or access to other shells/services via dbus. Ie. can you highjack an open ssl connection, control banking software etc. Yes, given the use of kioslaves, it's very easy to make extra requests via KIO and get the banking details. KWallet passwords and cookies are transferred over D-Bus, not to mention that the wallet and the cookie jar will be open and ready for requests. They can also launch [...] a keylogger True and if you enter a password into anything that does not grab the keyboard, this is a general issue of X11 (and if you've physical access to the machine, that doesn't matter either, because you can add a cronjob/service to track the device nodes) Agreed. But we won't get that fixed until Wayland. Neither KWallet nor the KDE password dialogs (including those from the polkit agent) nor website passwords grab the keyboard. In fact, the only tool I know that does that is pinentry (gpg-agent). Leaving access to an open shell is certainly bad enough - beyond question. The question is whether gaining direct access to a running session and random open clients (and leaving the stage untraced) is more valuable and thus worth pretection. We're assuming that the attacker already gained access to the session at this point. For example, if you've left a logged in shell in a virtual console. At that point, it's already game over. Since that is so, let's stop trying to cover the sun with a sieve. Instead, let's make the life of developers and helpgivers easier: let there be an unlock command via D-Bus, without transiting the password again. And, oh, the attacker can change the user's password! Errhemmm... Without providing the present one? /That/ trick you gotta show me. =) Right, it does ask for the current password. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: KF5: Parsing times with timezone abbreviations
Em seg 24 mar 2014, às 04:33:34, Kevin Kofler escreveu: Hi, what is the recommended way to parse times with short timezone abbreviations, such as 16:00 CET, in Qt 5 / KF5 land? (I am asking because this is the format the BBC is using for weather observation times in their RSS files.) In kdelibs 4, this should do what we want: dateTime = KDateTime::fromString(timeString, %H:%M %Z).toLocalZone().dateTime(); but KDateTime is deprecated in KF5. Time zone abbreviations are useless, since they are not unique. Simply strip them out of your string before passing to QDateTime. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Moving Baloo forward
Em sáb 22 fev 2014, às 10:37:04, GEO escreveu: Is the metadata any more sensitive than the data itself? If you're copying a file to an unencrypted filesystem, then the data is no longer secure. You could a share a document not containing any personal information (a third party document stored on your hdd), but the comments or tags could contain information you do not want to share with others. It's just as likely that I may want to back up my data with the metadata. Also, considering many file formats support embedded revisions and comments, before sharing stuff you should always run a cleaner. Many a big company were caught putting out documents in Microsoft Word formats where one could read older revisions and comments. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Moving Baloo forward
Em sex 21 fev 2014, às 21:00:07, Nicolás Alvarez escreveu: 2014-02-21 20:30 GMT-03:00 Sebastian Kügler se...@kde.org: On Thursday, February 20, 2014 08:58:48 GEO wrote: Maybe a strange idea, but it would resolve the privacy problem: Baloo could optionally encrypt all the attributes using a user defined password, meaning baloo stores encrypted strings as file attributes. I have no experience with file attributes, but I suppose the performance of search queries would suck, because of the decryption. Use an encrypted filesystem. :) That's a solution for a different problem. The problem in discussion is when you copy a file (perhaps to an unencrypted pendrive) unaware that you're also copying xattrs/metadata. Encrypting your main filesystem doesn't help with that. Is the metadata any more sensitive than the data itself? If you're copying a file to an unencrypted filesystem, then the data is no longer secure. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
