Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

On Thu, Dec 17, 2020 at 12:21 AM Friedrich W. H. Kossebau wrote: > > Though please those who want to support Qt 5.13 for some more time, consider > adding support for KDE CI then. > Right, that Qt 5.13 ship has sailed with the recent CI purge by Ben to clean up the old 5.13 builders. If we want

Re: TotalReqall

On Fri, Dec 11, 2020 at 10:53 PM Loren Burkholder wrote: > > Hi all, > > I have created a program called TotalReqall. Its purpose is to aid > memorization of things. To this end, it includes the Sword library for > accessing the Bible (because it actually started as a Bible memory-only app) >

Re: TotalReqall

On Sat, Dec 12, 2020 at 1:12 PM Albert Astals Cid wrote: > > El dissabte, 12 de desembre de 2020, a les 2:23:48 CET, Loren Burkholder va > escriure: > > It is not religion based per se. > > find_package(sword REQUIRED) > > "The SWORD Project is the CrossWire Bible Society's free Bible software

Re: KOpeningHours in kdereview

On Thu, Dec 10, 2020 at 6:00 PM Volker Krause wrote: > > The most notable feature gap compared to the official specification is > probably school holidays, we lack a collection of international data for that > so far. That only occurs in about 2k out of the 1.8M opening hours expressions > in the

Re: KCGroups in KDEreview

of completeness. Covering them all would give you the basic building block for a GUI for systemd more generally. Additionally, if the "all the wrappers included" approach is taken it might eventually also be worth considering systemd-homed (portable user directories backed by encrypted sto

Re: KCGroups in KDEreview

of completeness. Covering them all would give you the basic building block for a GUI for systemd more generally. Additionally, if the "all the wrappers included" approach is taken it might eventually also be worth considering systemd-homed (portable user directories backed by encrypted sto

Re: TableView (QtQuick 2) with alternating row colors (DelegateChooser)

: parent, anchors.fill: parent - Binding an appropriate height/width and/or specifying an appropriate implicitHeight/implicitWidth. I would take a look at how other Plasmoids with a similar layout work to see what works best for your case. Regards, - Johan Ouwerkerk

Re: LiFE Exam

certain point I removed the entire ~/.local/share/kscreen/ directory - Upgrading various components. Currently I'm running kscreen 5.17, plasma-desktop 5.14 Hope it helps. Regards, - Johan Ouwerkerk

Re: Proposal: make squash-merging the default behavior for gitlab MRs

es the scratching... But it does require very active maintainers and it may not be a good fit for all projects. :) Regards, - Johan Ouwerkerk

Re: Proposal: make squash-merging the default behavior for gitlab MRs

stuff). But many drive-by contributors and newbies or even seasoned contributors won't be deterred at all from not having commit access to the main repo. Additionally I suspect not many people will object to a maintainer taking their changes but landing them in different commits or a slightly di

Re: Proposal: make squash-merging the default behavior for gitlab MRs

hould stick to a global default. So if you're the maintainer you could nudge the default towards what makes sense for your project and its dominant workflow. Go to Settings (side bar) > General > Squashing and merging. Apparently that has been a feature of Gitlab core since version 11. Regards, - Johan Ouwerkerk

Re: Question about copyright notices

d 2020 you are supposed to see something to the effect of `Copyright 2019-2020 Johan Ouwerkerk`, and suppose that in 10 years time I contribute again to that file then would become `Copyright 2019-2020, 2030 Johan Ouwerkerk`. What you don't do is bump a `Copyright` year indicator just

Re: Git merge workflow: reverse it?

On Mon, Aug 3, 2020 at 11:50 PM Albert Astals Cid wrote: > > El dimecres, 29 de juliol de 2020, a les 14:01:07 CEST, Bhushan Shah va > escriure: > > At plasma, we are experimenting with new workflow regarding how bugfixes > > are put on the stable branch [1]. > > > > # Current workflow > > > > -

Re: Porting a project to KDE

On Fri, Aug 14, 2020 at 5:33 PM Carl Schwan wrote: > > Le vendredi, août 14, 2020 4:44 PM, Francois Blanchette > a écrit : > > > Hi Carl, > > > > Thank you for your reply. > > > > Yes I meant port it to KDE because it is a qt 5.15 compliant > > application already. > > And yes i want to make

Re: Deprecate KRandomSequence ?

On Tue, Jun 30, 2020 at 7:32 PM Albert Astals Cid wrote: > > > > > If an application was relying on the random application sequence, it > > probably has bigger problems. > > Why? It's exactly what KRandomSequence (and QRandomGenerator) promise to do. > > And at least on KPat this is really

Re: CMake source files without license

On Wed, Jun 24, 2020 at 6:50 PM Albert Astals Cid wrote: > > +1 a > SPDX-License-Identifier: BSD-3-Clause > sounds like a great idea for default default CMakeLists.txt header > > Cheers, > Albert > +1. Based on some discussion quite a while ago on Matrix/IRC we went with BSD-2-Clause for

Re: License for generated file

On Wed, May 20, 2020 at 11:41 PM Albert Astals Cid wrote: > > El dimecres, 20 de maig de 2020, a les 6:07:28 CEST, Ivan Romanov va escriure: > > IANA doesn't provide any licesnse info. > > If there's no license info, that means that we can't ship it. Please remove > it from our repositories ASAP

Re: License for generated file

On Mon, May 18, 2020 at 8:59 PM Ivan Romanov wrote: > > Hello. > > Today I added generated file to QCA repo. This commit > https://invent.kde.org/libraries/qca/-/commit/cf929ce541b48e36a54691a37b31211d17334bf7. > And got such email mesage: The files marked with a * at the end have a > non valid

Re: Migration to Gitlab -- Update

On Sun, May 10, 2020 at 9:49 AM Ben Cooksley wrote: > > Following lengthy discussion in the original thread, it was agreed > that the original sysadmin proposal of various categories would be > implemented, with repositories organised according to that structure. > > You can find this documented

Re: Migration to Gitlab -- Update

On Sun, May 10, 2020 at 9:49 AM Ben Cooksley wrote: > > Following lengthy discussion in the original thread, it was agreed > that the original sysadmin proposal of various categories would be > implemented, with repositories organised according to that structure. > > You can find this documented

Re: kinfocenter development

On Sun, May 3, 2020 at 4:12 PM Gerold Jens Wucherpfennig wrote: > Am 03.05.20 um 16:00 schrieb Stefan Brüns: > > On Sonntag, 3. Mai 2020 15:50:40 CEST Gerold Jens Wucherpfennig wrote: > > LSB is dead, dead, dead ... > > > > Have a look at os-release: > >

Re: Context information needed for isolated words

On Sat, May 2, 2020 at 12:36 PM Eloy Cuadra wrote: > > Hi, > > There is a widespread problem across many text strings to be translated: some > isolated words are gender invariable in English, but not in many languages. > > For example, let's consider this case of a cascade menu: > > New > >

Re: Information regarding upcoming Gitlab Migration: clarifications

On Fri, May 1, 2020 at 6:38 AM Nate Graham wrote: > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > >> Am I the only person that just has all the repos on the same folder? I > >> thought it was the common thing to do :? > > > > I do too >

Re: Information regarding upcoming Gitlab Migration: clarifications

On Fri, May 1, 2020 at 6:38 AM Nate Graham wrote: > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > >> Am I the only person that just has all the repos on the same folder? I > >> thought it was the common thing to do :? > > > > I do too >

Re: Information regarding upcoming Gitlab Migration: clarifications

On Fri, May 1, 2020 at 6:38 AM Nate Graham wrote: > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > >> Am I the only person that just has all the repos on the same folder? I > >> thought it was the common thing to do :? > > > > I do too >

Re: Information regarding upcoming Gitlab Migration

On Tue, Apr 28, 2020 at 1:09 PM Adriaan de Groot wrote: > > One actor is "tooling", as Albert has pointed out. Whatever the resulting > structure is, it needs to be communicated to tool authors on time for tools to > be updated, released, and rolled out for use. Tools mentioned so far: > -

Re: Information regarding upcoming Gitlab Migration

On Mon, Apr 27, 2020 at 2:32 PM Piyush Aggarwal wrote: > > How long do redirects like this one work? If they will keep working > indefinitely, then maybe we can have all the repos at flat URLs for once and > then move them to respective subgroups? I don't think this works if you want $repo to

D29095: New much simpler mouse icon that works in both light and dark breeze

ouwerkerk added a comment. In D29095#655214 , @ngraham wrote: > FWIW all the mice in my house have this exact shape, but they're black, not gray. So I don't think the shape is too old-fashioned per se. It's the gray color that's anacrhonistic

D29095: New much simpler mouse icon that works in both light and dark breeze

ouwerkerk added a comment. In D29095#655060 , @saligari wrote: > > Maybe this is just me but the overall width to height ratio makes it seem that the closest "real" mice are quite dated as well. > > I don't understand what you mean with

D29095: New much simpler mouse icon that works in both light and dark breeze

ouwerkerk added a comment. One thing I find really striking about the new icon is how closely it resembles stress balls: F8253927: stress-ball-mice.png I kinda like that... :) REPOSITORY R266 Breeze Icons REVISION DETAIL

D29095: New much simpler mouse icon that works in both light and dark breeze

ouwerkerk added a comment. Hmm, the old icon also has the virtue of looking more like genuine computer mice: it resembles the logi(tech) style of mouse design quite well. This one is rather abstract while at the same time somehow not looking like any "real" mouse would, in particular in its

Re: KDE CI: Administration » Dependency Build Extragear stable-kf5-qt5 AndroidQt5.14 - Build # 10 - Still Failing!

On Thu, Apr 16, 2020 at 10:51 AM Ben Cooksley wrote: > Hi all, > > Does anyone know why the below would have suddenly started failing a > little while back? > > Thanks, > Ben > Based on the error message I would expect this to be related to the effort to fix Android pkgs not being generated for

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote: > > > > > We may need to do on-the-fly conversion of the kde: repo paths if they > > won't be expressible as 'kde:foo' in the future, but we should have the > > information needed to do this in kdesrc-build to make

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote: > > > > > We may need to do on-the-fly conversion of the kde: repo paths if they > > won't be expressible as 'kde:foo' in the future, but we should have the > > information needed to do this in kdesrc-build to make

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote: > > > > > We may need to do on-the-fly conversion of the kde: repo paths if they > > won't be expressible as 'kde:foo' in the future, but we should have the > > information needed to do this in kdesrc-build to make

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley wrote: > > On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk > wrote: > > > > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk > > wrote: > > > > > > Yes the only reason why a cleanup script migh

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley wrote: > > On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk > wrote: > > > > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk > > wrote: > > > > > > Yes the only reason why a cleanup script migh

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley wrote: > > On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk > wrote: > > > > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk > > wrote: > > > > > > Yes the only reason why a cleanup script migh

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote: > > Yes the only reason why a cleanup script might be needed is if the > logical path used to express the repo in dependency information > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets > remapped to `fra

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote: > > Yes the only reason why a cleanup script might be needed is if the > logical path used to express the repo in dependency information > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets > remapped to `fra

Re: Update on Status of Gitlab Migration

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote: > > Yes the only reason why a cleanup script might be needed is if the > logical path used to express the repo in dependency information > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets > remapped to `fra

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne wrote: > > On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote: > > > > > A cleanup script could be handy. I think kdesrc-build will > > automatically pick up new repo paths from metadata and that should > >

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne wrote: > > On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote: > > > > > A cleanup script could be handy. I think kdesrc-build will > > automatically pick up new repo paths from metadata and that should > >

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne wrote: > > On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote: > > > > > A cleanup script could be handy. I think kdesrc-build will > > automatically pick up new repo paths from metadata and that should > >

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 9:01 PM Nicolás Alvarez wrote: > > How would it work during the "grace period"? Keeping an outdated read-only > mirror on the old URL? I have done some research into redirecting or > remapping from the old URL to the new one so we can keep it working for a > longer

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 9:01 PM Nicolás Alvarez wrote: > > How would it work during the "grace period"? Keeping an outdated read-only > mirror on the old URL? I have done some research into redirecting or > remapping from the old URL to the new one so we can keep it working for a > longer

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 9:01 PM Nicolás Alvarez wrote: > > How would it work during the "grace period"? Keeping an outdated read-only > mirror on the old URL? I have done some research into redirecting or > remapping from the old URL to the new one so we can keep it working for a > longer

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley wrote: > > Yes, the hostname git.kde.org will be fully retired as part of this > transition. > > From my understanding kdesrc-build will automatically pick this up > once we update sysadmin/repo-metadata to show the new repository > paths. > This is

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley wrote: > > Yes, the hostname git.kde.org will be fully retired as part of this > transition. > > From my understanding kdesrc-build will automatically pick this up > once we update sysadmin/repo-metadata to show the new repository > paths. > This is

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley wrote: > > Yes, the hostname git.kde.org will be fully retired as part of this > transition. > > From my understanding kdesrc-build will automatically pick this up > once we update sysadmin/repo-metadata to show the new repository > paths. > This is

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > Should anyone have any questions on the above, please let us know. > Does the migration also mean that `git.kde.org` push URL will be retired and would need to be remapped to `invent.kde.org`? In that case, it would be good to have a

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > Should anyone have any questions on the above, please let us know. > Does the migration also mean that `git.kde.org` push URL will be retired and would need to be remapped to `invent.kde.org`? In that case, it would be good to have a

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > Should anyone have any questions on the above, please let us know. > Does the migration also mean that `git.kde.org` push URL will be retired and would need to be remapped to `invent.kde.org`? In that case, it would be good to have a

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > To help assist with this, it would be appreciated if all holders of a > KDE Developer account could please login on our Gitlab instance (at > https://invent.kde.org/) and ensure they are listed as a 'Developer' > of the KDE group. You can

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > To help assist with this, it would be appreciated if all holders of a > KDE Developer account could please login on our Gitlab instance (at > https://invent.kde.org/) and ensure they are listed as a 'Developer' > of the KDE group. You can

Re: Update on Status of Gitlab Migration

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > To help assist with this, it would be appreciated if all holders of a > KDE Developer account could please login on our Gitlab instance (at > https://invent.kde.org/) and ensure they are listed as a 'Developer' > of the KDE group. You can

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

On Sun, Mar 22, 2020 at 3:20 AM Ben Cooksley wrote: > > We already do have a repository of artifacts :) > You can find the public view of this at > https://build-artifacts.kde.org/production/ > > > We already use Virtual Machines for both FreeBSD and Windows. > > The main problem here is that

CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

On Sat, Mar 21, 2020 at 10:27 PM Ben Cooksley wrote: > > On Sun, Mar 22, 2020 at 3:27 AM Johan Ouwerkerk > wrote: > > > > On Sat, Mar 21, 2020 at 1:32 AM Ben Cooksley wrote: > > > > > > Comments welcome. Please note that simply fixing the dependency &g

Re: Manner in which kde-gtk-config development is conducted

On Sat, Mar 21, 2020 at 1:32 AM Ben Cooksley wrote: > > Comments welcome. Please note that simply fixing the dependency > breakage in this case is not enough to resolve this - there are > underlying issues which need to be addressed here. > > Regards, > Ben Cooksley > KDE Sysadmin I cannot

Re: Fixing QNetworkAccessManager use

On Wed, Feb 19, 2020 at 2:09 PM Friedrich W. H. Kossebau wrote: > > Personally I am still unsure what the actual issue is. Why are redirects > needed at all. Why all the address changes all the time? > It is part of the HTTP spec for servers to be able to inform clients that resource /foo/bar

Re: Fixing QNetworkAccessManager use

On Wed, Feb 19, 2020 at 2:09 PM Friedrich W. H. Kossebau wrote: > > Personally I am still unsure what the actual issue is. Why are redirects > needed at all. Why all the address changes all the time? > It is part of the HTTP spec for servers to be able to inform clients that resource /foo/bar

Re: Fixing QNetworkAccessManager use

On Wed, Feb 19, 2020 at 2:09 PM Friedrich W. H. Kossebau wrote: > > Personally I am still unsure what the actual issue is. Why are redirects > needed at all. Why all the address changes all the time? > It is part of the HTTP spec for servers to be able to inform clients that resource /foo/bar

Re: Banning QNetworkAccessManager

On Mon, Feb 3, 2020 at 11:27 AM laurent Montel wrote: > > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit : > > I updated: > > > > https://community.kde.org/Policies/API_to_Avoid > > > > Which had no mention of this. > > > > David > > I think that you made an error > >

Re: Banning QNetworkAccessManager

On Mon, Feb 3, 2020 at 11:27 AM laurent Montel wrote: > > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit : > > I updated: > > > > https://community.kde.org/Policies/API_to_Avoid > > > > Which had no mention of this. > > > > David > > I think that you made an error > >

Re: Banning QNetworkAccessManager

On Mon, Feb 3, 2020 at 11:27 AM laurent Montel wrote: > > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit : > > I updated: > > > > https://community.kde.org/Policies/API_to_Avoid > > > > Which had no mention of this. > > > > David > > I think that you made an error > >

Re: Keysmith in kdereview

in KDE review for over three weeks, so unless there is urgent new feedback that leaves the question: what is next? Thanks again for all your help and feedback making Keysmith much better! Regards, -Johan Ouwerkerk On Wed, Dec 18, 2019 at 3:51 PM Bhushan Shah wrote: > > Hello everyone! > &

Re: Keysmith in kdereview

On Sat, Dec 28, 2019 at 6:38 PM Friedrich W. H. Kossebau wrote: > > That one is a blocker though to pass kdereview, for what I understand from > https://community.kde.org/ReleasingSoftware#Sanity_Checklist as linked from > https://community.kde.org/Policies/Application_Lifecycle#kdereview > > At

Re: Keysmith in kdereview

First of all sorry for the duplicate reply Friedrich. I messed up with the send button earlier. Here goes the second try: > > Did some usual-nitpick-CMake-code cleanup commit already (things which also > apply to other new Plasma repos, someone might want to brush over their > CMakeLists.txt as

Re: Keysmith in kdereview

First of all: sorry for the duplicate reply Albert. There was a mixup with the reply button on my end, unfortunately. Here goes attempt #2: > I think it'd be good if you used a QVarLengthArray instead of "char > code[m_pinLength];" > Yes that is a known wart. There are a few issues/MRs that

Re: Work Branches

Just one question here: what is the impact on projects in the KDE/ namespace which have only a single maintainer/contributor? Are we then essentially going to accept that users merge in their own MRs? And also, how then does that tie in with the expressed preference for fast-forward only merges

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

On Tue, Oct 15, 2019 at 9:17 AM Frederik Schwarzer wrote: > Now I will fix my latest revision and merge to master. Still: 19 commits > are not compiling anymore. > > Or am I missing something here? > > How would we deal with that? Is "short-lived branches" (as you stated > below) enough to reduce

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

On 14.10.2019 21:22, Frederik Schwarzer wrote: > If however, master had seen commits as well, fast-forwarding is > performing a rebase ... is that correct? The workflow would be: whenever master is updated, you rebase your local feature/work branch and force-push to the remote copy of the

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

Yes, please, pretty please with cherry on top. :) Regards, -Johan On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid wrote: > > I find the merge behavior to be not what we've been doing in phabricator so > given the idea is to maintain our workflows i'd appreciate if we can agree on >

Re: Framework for encrypted storage for apps

ntally corrupted, say. After all if I can store the secrets in an encrypted and robust fashion, then I can let the user export their data safely for backup purposes. So basically I guess that what I am asking: any examples, suggestions or other pointers which I can use as further starting p

Framework for encrypted storage for apps

Hi all, Bhushan asked me to kick off a discussion on frameworks-devel about a problem we face for otpclient. We are looking for help in deciding how to best implement storage of the secrets which are needed by the app. Any insights from people who are more familiar with frameworks would be much

Re: Review Request 128554: Check for xattr during config step, otherwise the build might fail (if xattr.h is missing). Missing xattr should now trigger an error message to prompt the user into install

-CREATION Diff: https://git.reviewboard.kde.org/r/128554/diff/ Testing --- Without xattr development headers cmake now complains when building with kdesrc-build. With xattr development headers installed, cmake & compilation steps pass with kdesrc-build. Thanks, Johan Ouwerkerk

Re: Review Request 128554: Check for xattr during config step, otherwise the build might fail (if xattr.h is missing). Missing xattr should now trigger an error message to prompt the user into install

> On Aug. 2, 2016, 1:03 p.m., Vishesh Handa wrote: > > Ship It! > > Johan Ouwerkerk wrote: > Should I push to master, or to another branch? Nevermind, there's only the one branch. :) - Johan --- This is an autom

Re: Review Request 128554: Check for xattr during config step, otherwise the build might fail (if xattr.h is missing). Missing xattr should now trigger an error message to prompt the user into install

/r/128554/#review97999 --- On July 29, 2016, 5:50 p.m., Johan Ouwerkerk wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewb

Re: Review Request 128554: Check for xattr during config step, otherwise the build might fail (if xattr.h is missing). Missing xattr should now trigger an error message to prompt the user into install

Diff: https://git.reviewboard.kde.org/r/128554/diff/ Testing (updated) --- Without xattr development headers cmake now complains when building with kdesrc-build. With xattr development headers installed, cmake & compilation steps pass with kdesrc-build. Thanks, Johan Ouwerkerk

Review Request 128554: Check for xattr during config step, otherwise the build might fail (if xattr.h is missing). Missing xattr should now trigger an error message to prompt the user into installing

/FindXattr.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/128554/diff/ Testing --- Thanks, Johan Ouwerkerk

Re: kdesrc-build and include-dependencies

I don't think kdesrc-build inspects the cmake files to discover deps, it relies on the project metadata GIT repo instead. So --include-dependencies only applies to the dependencies discovered through the project metadata repo, and then only those which kdesrc-build knows how to build. Any other

Re: [Kde-hardware-devel] Review Request 126381: kwayland backend for libkscreen

? `[m_thread,m_connection,_syncLoop] {...}` - Johan Ouwerkerk On Dec. 17, 2015, 6:53 p.m., Sebastian Kügler wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.revi