Re: Invoking "kcheckpass" from the terminal
Am 2019-08-12 16:20, schrieb Franklin, Jason: On Fri, Aug 9, 2019 at 8:15 PM Thiago Macieira wrote: On Thursday, 8 August 2019 12:00:34 PDT Franklin, Jason wrote: > However, after trying several invocations, I can't get the tool to behave as > expected (i.e., take a password on stdin and exit with 0/1 on success/ > failure). That's because the tool does not take the password on stdin. $ /usr/lib64/libexec/kcheckpass Only binary protocol supported You need to pass a file descriptor number with the -S option. This is what I discovered when trying it myself. This means that the commentary in the code for kcheckpass is way out of sync with the actual behavior of the tool. I think this should be fixed, and I'd be willing to help. I'm also curious, why doesn't the following work? echo -n 'test' | /usr/lib64/libexec/kcheckpass -S 0 I get "Communication breakdown on write". Seems like passing to stdin with file descriptor 0 should work. kcheckpass.c also makes debugging difficult, by setting a bunch of options to prevent unauthorised attaching to the process. You need to modify the source to turn those off. I really appreciate your response and the tip you provided here. I'll do my best to investigate further. However, I've noticed that this process is not well-documented at all. The README file included with kcheckpass isn't very helpful in guiding someone to debugging the code. Also, installing a Debian dbgsym package doesn't seem to be sufficient, as you noted here. I'd be very willing to help with this, but the package maintainers haven't responded to my query yet. I submitted the bug report below: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934185 I'm still hoping to hear back! I was probably the last one who touched the code and performed cleanups. Kcheckpass is not meant to be used from a command line - I'm sorry, that's just not the use case. We only use the binary protocol in kscreenlocker and removed everything else. The implementation is in: https://cgit.kde.org/kscreenlocker.git/tree/greeter/authenticator.cpp It's a pretty much stand alone class, so you can wrap this in an own class to interact with it. Cheers Martin
Re: RFC: Running clang-format across all Plasma (and more?) repos
Am 2019-07-11 16:18, schrieb David Edmundson: One topic discussed at the recent Plasma sprint was that we should run a code formatting tool (clang-format) over all our repos to ease all future review comments about whitespace. All new contributions simply have to run the same tool and we get consistent code without having to comment on every minor thing in a review individually. I've written up a wall of text outlining steps, challenges etc. https://phabricator.kde.org/T11214 Does anyone have any thoughts / objections? As someone being guilty of only focusing on whitespace changes I'm very much in favor of this idea. Cheers Martin
Re: CI system maintainability
Am 2019-03-28 07:40, schrieb Ben Cooksley: Does anyone have any ideas for a long term, proper fix to this? At this point given the amount of effort required to maintain a CI system vs. the amount of care actually being given by some developers (who are ignoring it's failure emails) it becomes questionable whether the effort is worth the return (and if not, we should just shut it down) Hi Ben, I at least consider the CI system we have as super important and I'm super happy with it and extremely thankful for all the work you and the other sysadmins put into it. Given that I would find it sad if it were shut down because some devs are not playing along. Given the thread and what I read we seem to have here a case where a dev pushed a broken change without code review. That's IMHO not how we work in KDE. I don't think the complete community should be punished for misbehavior of some. My suggestion is that you get the right to revert broken changes. If it holds back everything and you sent a mail, what else should you do? Cheers Martin
Re: Aw: Re: setWindowIcon for QDialog
Am 2019-03-06 23:13, schrieb Friedrich W. H. Kossebau:
Hi,
allow me to chime in with my AFAIK, which though is confirmed by my
quick look
at the code:
Am Dienstag, 5. März 2019, 18:21:00 CET schrieb Martin Flöser:
Hi Alexander,
according to the xprop output the _NET_WM_ICON property is not set.
The
method inside Qt responsible for this is:
https://code.woboq.org/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp.h
tml#_ZN10QXcbWindow13setWindowIconERK5QIcon
This method is called indirectly from QWidget::setWindowIcon. I am
pretty sure that it works as you can easily check by xprop any other
Qt
window. So the problem must be the icon. If I search for
labplot-worksheet I find only an icon in size 22x22. Looking at the
linked code, I notice that it's not one of the sizes Qt expects and
also
none of the sizes KWin expects, see
https://cgit.kde.org/kwin.git/tree/client.cpp#n1583
Isn't the more relevant code here the one at the start of that method?
// First read icons from the window itself
const QString themedIconName = iconFromDesktopFile();
if (!themedIconName.isEmpty()) {
setIcon(QIcon::fromTheme(themedIconName));
return;
}
From what I remember, one of the issues with Wayland (and then also
with KWin
& its custom X-equivalent "_KDE_NET_WM_DESKTOP_FILE") is that while
title
properties for windows are supported, icons are not (something about
graphics
resources and different metadata design *insert proper knowledge*). So
the
window managers and running-app-instance managers take the icon name
only from
the desktop file, no longer enabling to overwrite the icon for certain
windows.
Isn't this the issue still? At least I remember this vaguely from some
time
ago.
Not in this case as the window is missing the icon property as can be
seen in the xprop output.
But apart from that: yes if the desktop file is specified, the icon is
preferred over the custom icon. But in this specific case it's not the
reason.
Cheers
Martin
Am 2019-03-04 17:39, schrieb Alexander Semke:
> not shown in the window bar, left to the window title. Please check
> the attached screenshots. On windows the proper icon is shown, on
> linux/kwin the applicaion icon is used.
>
> It's X. The output of xprop:
>
> _NET_WM_ICON_NAME(UTF8_STRING) =
> _KDE_NET_WM_DESKTOP_FILE(UTF8_STRING) = "org.kde.labplot2"
> _KDE_NET_WM_COLOR_SCHEME(STRING) =
> "/usr/share/color-schemes/BreezeHighContrast.colors"
> XdndAware(ATOM) = BITMAP
> _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 2840133529
> WM_NAME(STRING) = "Import Data to Spreadsheet or Matrix"
> _NET_WM_NAME(UTF8_STRING) = "Import Data to Spreadsheet or Matrix --
> labplot2"
> _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x7, 0x26, 0x1e, 0x3, 0x0
> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG,
> _NET_WM_WINDOW_TYPE_NORMAL
> _XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
> WM_CLIENT_LEADER(WINDOW): window id # 0x508
>
> WM_HINTS(WM_HINTS):
> Client accepts input or input focus: True
> Initial state is Normal State.
>
> _NET_WM_PID(CARDINAL) = 29202
> _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 83886351
> WM_CLASS(STRING) = "labplot2", "labplot2"
> WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS,
> _NET_WM_PING, _NET_WM_SYNC_REQUEST, _NET_WM_CONTEXT_HELP
>
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
> user specified location: 819, 262
> user specified size: 536 by 711
> program specified minimum size: 522 by 711
> window gravity: Static
>
> P.S.: sorry for html and for the full-quote, writing from the
> web-frontend...
>
> GESENDET: Montag, 04. März 2019 um 15:08 Uhr
> VON: "David Edmundson"
> AN: kde-devel , "Kwin, NET API, kwin styles API,
> kwin modules API"
> BETREFF: Re: setWindowIcon for QDialog
>
> On Mon, Mar 4, 2019 at 1:49 PM Aleix Pol wrote:
>> On Sun, Mar 3, 2019 at 11:00 AM Alexander Semke
>
> wrote:
>> > With kwin, the specified icons are not shown
This quote sadly misses the possibly relevant initial " and I always
get the
default application's icon shown."
Cheers
Friedrich
Re: Aw: Re: setWindowIcon for QDialog
Hi Alexander,
according to the xprop output the _NET_WM_ICON property is not set. The
method inside Qt responsible for this is:
https://code.woboq.org/qt5/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp.html#_ZN10QXcbWindow13setWindowIconERK5QIcon
This method is called indirectly from QWidget::setWindowIcon. I am
pretty sure that it works as you can easily check by xprop any other Qt
window. So the problem must be the icon. If I search for
labplot-worksheet I find only an icon in size 22x22. Looking at the
linked code, I notice that it's not one of the sizes Qt expects and also
none of the sizes KWin expects, see
https://cgit.kde.org/kwin.git/tree/client.cpp#n1583
My suggestion is to try whether any other icon works. And if it does so,
ensure that all relevant icon sizes are available for the
labplot-worksheet.
Cheer
Martin
Am 2019-03-04 17:39, schrieb Alexander Semke:
not shown in the window bar, left to the window title. Please check
the attached screenshots. On windows the proper icon is shown, on
linux/kwin the applicaion icon is used.
It's X. The output of xprop:
_NET_WM_ICON_NAME(UTF8_STRING) =
_KDE_NET_WM_DESKTOP_FILE(UTF8_STRING) = "org.kde.labplot2"
_KDE_NET_WM_COLOR_SCHEME(STRING) =
"/usr/share/color-schemes/BreezeHighContrast.colors"
XdndAware(ATOM) = BITMAP
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 2840133529
WM_NAME(STRING) = "Import Data to Spreadsheet or Matrix"
_NET_WM_NAME(UTF8_STRING) = "Import Data to Spreadsheet or Matrix --
labplot2"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x7, 0x26, 0x1e, 0x3, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG,
_NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x508
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
_NET_WM_PID(CARDINAL) = 29202
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 83886351
WM_CLASS(STRING) = "labplot2", "labplot2"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS,
_NET_WM_PING, _NET_WM_SYNC_REQUEST, _NET_WM_CONTEXT_HELP
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 819, 262
user specified size: 536 by 711
program specified minimum size: 522 by 711
window gravity: Static
P.S.: sorry for html and for the full-quote, writing from the
web-frontend...
GESENDET: Montag, 04. März 2019 um 15:08 Uhr
VON: "David Edmundson"
AN: kde-devel , "Kwin, NET API, kwin styles API,
kwin modules API"
BETREFF: Re: setWindowIcon for QDialog
On Mon, Mar 4, 2019 at 1:49 PM Aleix Pol wrote:
On Sun, Mar 3, 2019 at 11:00 AM Alexander Semke
wrote:
>
> Hi,
>
> in LabPlot we have couple of modal dialogs, created on the heap
and shown with
> dlg->exec(). The dialog icon is set in the constructor of the
dialog via
> QDialog::setWindowIcon(), e.g.
>
setWindowIcon(QIcon::fromTheme(QLatin1String("labplot-worksheet")));
>
> The icon is set/handled by the window manager if I understand this
correctly.
> With kwin, the specified icons are not shown
Not shown where exactly?
Also X or xwayland?
Does running xprop and clicking on the window show the correct icon?
Re: Gitlab Evaluation & Migration
Am 2019-02-24 21:03, schrieb Ben Cooksley: On Mon, Feb 25, 2019 at 8:31 AM Martin Flöser wrote: Am 2019-02-23 10:44, schrieb Ben Cooksley: > Hi all, > Based on all of the above we'd like to propose migrating towards > Gitlab. Comments? I'm totally honest here: I'm not happy about yet another migration. This will be the fifth reviewing toolkit I use for KDE (reviewboard for svn, reviewboard for git, gerrit, phabricator and now gitlab). Each of the transitions was painful for everyone involved and the commit rate to the project I was involved suffered from the transitions. As an example for the problems: KWin's hacking document still mentions reviewboard: https://community.kde.org/KWin/Hacking#Submitting_Changes Please don't over exaggerate the numbers here. Gerrit was never an official system for reviews, it was something that was evaluated by a small group and which was never proceeded with as an official whole-of-KDE solution. Reviewboard for SVN/Git are basically the same thing (just a different instance url), so this is only really the third system, not the fifth You missed the point. What I wrote is that the transitions were painful - also the very simple transition from svn.reviewboard to git.reviewboard was painful. That it was the same tool doesn't matter. It was still a transition, it meant looking at two places, lost reviews, update to documentation, change of workflow, etc. etc. Also gerrit was a tool I used for KDE hacking. I wrote it will be the fifth toolkit for me. That's true for me and I don't over exaggerate any numbers here. Please also bear in mind that we've been on Git now for coming up on 9 years (I have mails for git.kde.org starting around June 2010) so switching systems twice in that time frame as software continues to mature seems quite reasonable to me. Please keep also in mind that the git transition took a long time and started for different projects at different times. That you as sysadmin had mails going back so long does not mean others as well. I consider it as a transition too early after Phabricator was praised so much. I was sure that this would be a solution for the next decade. I'm not pleased that we want to transit to another solution after just a few years. I understand that there is the feeling that our phabricator solution limits contributions from newcomers. I don't believe that and are afraid of the long term developers walking away due to the changes (which is something I saw with every transition). I don't know whether I will continue to contribute if I have to relearn the tooling - my time for KDE is currently very limited. If I have an hour to hack and have to spend half the time on how to contribute now, that sucks and lowers motivation. If you've worked with Github before then Gitlab is very similar, so the learning curve shouldn't be too steep. I haven't worked with github. Changing the tooling will not solve any of the contribution problems. Instead we introduce new ones like all documentation going out of life. Please consider whether the advantages are really worth it. Please also see my comments re. Phabricator upstream as to part of the reason why we're considering this, along with the feedback we received at Akademy last year. Well I remember how phabricator was praised for the very responsive team. That seems to have changed. But who guarantees that gitlab will continue to be responsive and cooperative? Will we have to switch again if the team stops to be responsive? You asked for comments. I gave comment that I'm not pleased about yet another transition. Please keep that in mind. It means learning and interrupted workflows for every one. If you have already decided and don't want anybody to point out that transitions are painful, please don't ask for comments. Instead say that sysadmins decided. That's at least honest - your reply gives me the feeling the decision is already done and negative feedback was not expected. Sorry to feel this way. Cheers Martin
Re: Gitlab Evaluation & Migration
Am 2019-02-23 10:44, schrieb Ben Cooksley: Hi all, Based on all of the above we'd like to propose migrating towards Gitlab. Comments? I'm totally honest here: I'm not happy about yet another migration. This will be the fifth reviewing toolkit I use for KDE (reviewboard for svn, reviewboard for git, gerrit, phabricator and now gitlab). Each of the transitions was painful for everyone involved and the commit rate to the project I was involved suffered from the transitions. As an example for the problems: KWin's hacking document still mentions reviewboard: https://community.kde.org/KWin/Hacking#Submitting_Changes I'm not pleased that we want to transit to another solution after just a few years. I understand that there is the feeling that our phabricator solution limits contributions from newcomers. I don't believe that and are afraid of the long term developers walking away due to the changes (which is something I saw with every transition). I don't know whether I will continue to contribute if I have to relearn the tooling - my time for KDE is currently very limited. If I have an hour to hack and have to spend half the time on how to contribute now, that sucks and lowers motivation. Changing the tooling will not solve any of the contribution problems. Instead we introduce new ones like all documentation going out of life. Please consider whether the advantages are really worth it. Best regards Martin
Re: Contributing to KDE is hard because of its build architecture
Am 2018-12-09 16:41, schrieb Konstantin Kharlamov: Official way of building dependencies is using kdesrc-build. It has multiple problems: Hi Konstantin, sorry for your bad experienced, but I think it would have been much easier. Assuming you are on a Debian based distribution the steps should just be: * sudo apt build-dep kmail * kdesrc-build kde-pim I personally don't have all dependencies build from source, but just the one I develop. Everything else I do through distro packages. I would never try to build something like webengine from source, that's just a mess. Cheers Martin
Re: KGlobalAccel is only Plasma centric?
Am 25. Juli 2018 10:46:48 MESZ schrieb Kai Uwe Broulik : >Hi, > >I don't think it's strictly Plasma-specific *but* you would need >kglobalaccel5 >daemon running for shortcuts to work. Not sure how feasible that is >elsewhere? > >Maybe needs an in-process option like KIO has it for other platforms >iirc. > kglobalaccel5 gets autostarted when needed and works on X11 unless the shortcuts are already taken by another de-specific shortcut system. On Wayland kglobalaccel needs support from the compositor which to my knowledge only KWin provides. No in-process solution could fix this. Cheers Martin
Re: bugs.kde.org: kio vs frameworks-kio vs kfile etc.
Am 2018-04-09 23:24, schrieb Nate Graham: On Mon, 09 Apr 2018 14:21:45 -0700 David Edmundson wrote > > Not sure why this seems to be the case for some items. Maybe a sysadmin can look into it? > > Voting is deliberately turned off by some maintainers who find it destructive. > That's definitely the case for plasmashell and kwin. Please don't change it. Actually KWin allows voting, but only gives users a single vote (which I think makes a lot of sense). That's probably just historical that it was not possible to disable voting (for me) back when I changed to only 1 vote. The intention was to have voting disabled as it was highly destructive, very pushy and had the very nasty functionality of confirming bugs by popular vote. The situation improved massively with only one vote. Cheers Martin
Re: How to temporarily change KConfig-data for a unit test?
Am 2018-02-13 21:44, schrieb Michael Heidelbach:
On 13.02.2018 20:38, Martin Flöser wrote:
Am 2018-02-13 15:42, schrieb Aleix Pol:
On Tue, Feb 13, 2018 at 1:14 PM, Michael Heidelbach
wrote:
Hi!
Currently I'm working on baloo-widgets. For a unit test I need to
temporarily change KConfig data.
My approach would be like this:
initTestCase()
KConfig config("baloofileinformationrc", KConfig::NoGlobals);
KConfigGroup settings = config.group("Show");
set everything to true here.
Revert the changes incleanupTestCase();
How is this done most efficiently and without messing too much with
baloofileinformationrc?
Ideally you should QStandardPaths::setTestModeEnabled(true), then you
can do as you please with config files which should end up in
~/.qttest.
A different approach could be to use a
KSharedConfig::openConfig(QString(), KConfig::SimpleConfig)
This creates an in-memory KConfig not backed by a file. That's what I
use in KWin to mock config. All the objects interacting with config
have a setConfig(KSharedConfigPtr) method which I can use to inject
the mocked config.
Cheers
Martin
Thanks Martin,
that sounds very interesting too. By looking at some of kwin's
autotests, I got the impression I could learn a lot about testing from
reading those. But for now, could you please point me to an example
for 'setConfig(KSharedConfigPtr)' or even better teach me how to find
one myself within KWin?
find yourself: git grep ::setConfig
Multiple examples are directly in KWin's main.h file
Cheers
Martin
Re: How to temporarily change KConfig-data for a unit test?
Am 2018-02-13 15:42, schrieb Aleix Pol:
On Tue, Feb 13, 2018 at 1:14 PM, Michael Heidelbach
wrote:
Hi!
Currently I'm working on baloo-widgets. For a unit test I need to
temporarily change KConfig data.
My approach would be like this:
initTestCase()
KConfig config("baloofileinformationrc", KConfig::NoGlobals);
KConfigGroup settings = config.group("Show");
set everything to true here.
Revert the changes incleanupTestCase();
How is this done most efficiently and without messing too much with
baloofileinformationrc?
Ideally you should QStandardPaths::setTestModeEnabled(true), then you
can do as you please with config files which should end up in
~/.qttest.
A different approach could be to use a
KSharedConfig::openConfig(QString(), KConfig::SimpleConfig)
This creates an in-memory KConfig not backed by a file. That's what I
use in KWin to mock config. All the objects interacting with config have
a setConfig(KSharedConfigPtr) method which I can use to inject the
mocked config.
Cheers
Martin
Re: Adding application to KDE and getting image of current
Am 2018-02-03 20:36, schrieb Nate Graham: I know, my answer sucks. I really do hate to have to bring it up. And I don't mean to throw cold water on your project or your enthusiasm! KSnip looks cool. The thing is, single-developer projects tend to have a predictable lifecycle: lots of energy and progress in the beginning, then around year two or three, the developer loses interest or gets too busy, and then the app stagnates for a few years and finally dies of bit-rot. It isn't *always* the case, but I've seen it too many times to ignore the pattern. Spectacle itself narrowly avoided this fate when community members took an interest and stepped up when its lead developer left at the beginning of 2017. It is now fairly healthy, under somewhat active development, and no longer so fragile. Fun fact: I had this exact discussion with the spectacle lead developer when he wanted to make it replace KSnapshot. And that's one of the situations where it really sucks to have been (partially) right. Cheers Martin
Re: Babe project - Legal feedback
Am 2018-02-03 18:07, schrieb Camilo Higuita Rodriguez: Hi,everyone I'd like to discuss something with the community, and maybe get some legal input: As some of you might already know I'm working on a open online platform to share music information between users, such as public playlists, comments on tracks and on the playback progress like soundcloud, share popular music suggestions, metadata, and discovery of new music from another users with integration with YouTube and Spotify etc... the platform will be integrated into Babe music player and could be use in any other music player The legal matter comes here: 1- I would like to either have the option to *stream live* the music an user is currently listening to to a group of friends. here the music file isn't being storaged in the audience computer... How ilegal is it? How illegal is to stream live, but privately, copyrighted music? and how illegal is it to stream owns music content to a selected group of friends? 2- If the stream part wouldn't be enought problem, I'd also like to sync a user playlist marked as public to some other friends, that would mean to share music files between users, and technically downloading another users music files. How illegal is this part? how illegal is to share a music file for example, in a conversation in telegram or whatsapp, or even how illegal is it to send a mp3 to a friend over an email or even over google drive? I'd like to get feedback about this issues Like Christian, I recommend to consult a lawyer specialized on Copyright law. What's extremely important is that there won't be an answer which is globally unique. I'll give you an example for my area of legislation (Germany). We have the concept of a private copy (Privatkopie) [1] which allows to share media with friends and family. There is a ruling of the highest German court (BGH) which can be interpreted as the number of friends and family is 7 [2]. Given that the answer to your questions from a German perspective is IMHO (though IANAL) that it is clearly illegal if a user would use this feature. Cheers Martin [1] § 53 URHG https://www.gesetze-im-internet.de/urhg/__53.html [2] BGH, GRUR 1978, 474
Re: Adding application to KDE and getting image of current cursor under wayland
Am 2018-02-02 19:04, schrieb Damir Porobic: 2. Is there a way to get an image of the current mouse cursor under KWin Wayland? No. Cheers Martin Wayland Maintainer
Re: Is it bad manners to refactor other people's code?
Am 2018-01-25 18:45, schrieb Michael Heidelbach: Hi! Currently I'm working on some code I couldn't understand until I split some long functions into smaller parts. As I couldn't find anything about the size-of-a-function topic in the KDE or Qt guide lines I consider this as a matter of personal taste. I don't want to step on anybody's toes, so my question is: Should I submit the refactored code as a review request or - now that I understand what is going on - weave my changes into the original code? And what do you think about this in general? If I would have been afraid of refactoring other peoples code, we would not have a Wayland port :-) I think if the code is in your opinion an improvement: go for it and open a review request. Cheers Martin
Re: Failure to build kwin "Could NOT find Qt5FontDatabaseSupport"
Am 2017-08-25 15:47, schrieb Andrey Voropaev: Hello! I'm trying to compile plasma-workspace on Linux using command: "kdesrc-build --include-dependencies plasma-workspace" The only thing that fails is "kwin" (and plasma-workspace itself). The exact error from the log file looks like this: Could NOT find Qt5FontDatabaseSupport (missing: Qt5FontDatabaseSupport_LIBRARY Qt5FontDatabaseSupport_INCLUDE_DIR) I'm using Qt 5.9.1 (git repo). It is also compiled from sources using: "configure -developer-build -opensource -nomake examples -nomake tests -confirm-license" What could be wrong here? You need to install the private API of Qt. On a debian based distro that's normally package qtbase5-private-dev Cheers Martin
