Re: Review Request 129188: Add documentation for the GenerateProperties option

[Elvis Angelaccio]

> On Oct. 16, 2016, 2:38 p.m., Aleix Pol Gonzalez wrote:
> > src/kconfig_compiler/README.dox, line 216
> > 
> >
> > Are you sure this is needed? maybe we could make it so it's not needed? 
> > Looks the kind of thing that will generate crazy errors, hard to figure out.

It won't compile without (unless I'm doing something wrong). GenerateProperties 
adds "include xxx.moc" in the generated xxx.cpp file, but the compiler doesn't 
find xxx.moc without the GENERATE_MOC option. I don't know exactly how cmake 
handles the moc, but maybe xxx.{h,cpp} are generated after automoc has already 
been run?


- Elvis


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129188/#review100043
---


On Oct. 15, 2016, 9:31 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129188/
> ---
> 
> (Updated Oct. 15, 2016, 9:31 a.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> The `GenerateProperties` option is missing from: 
> https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html
> 
> This patch explains what the option does and how to use it.
> 
> 
> Diffs
> -
> 
>   src/kconfig_compiler/README.dox b9606f1d157229a22afbeaea7d56ee95732762a2 
> 
> Diff: https://git.reviewboard.kde.org/r/129188/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Re: Review Request 129197: Fix tests on FreeBSD

[Tobias Berner]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129197/#review100039
---



I'm kind of unsure if this is right. Yes, the tests run now, but isn't the 
issue rather in the way kpty works (or fails to work on FreeBSD)?

- Tobias Berner


On Oct. 16, 2016, 1:44 p.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129197/
> ---
> 
> (Updated Oct. 16, 2016, 1:44 p.m.)
> 
> 
> Review request for KDE Frameworks, Adriaan de Groot, Tobias Berner, Oswald 
> Buddenhagen, and Martin Tobias Holmedahl Sandsmark.
> 
> 
> Repository: kpty
> 
> 
> Description
> ---
> 
> Apparently, KPtyDevice can't be operated on after KPtyProcess finishes. Tweak 
> tests accordingly, so they actually test things while the process is still 
> running.
> 
> 
> Diffs
> -
> 
>   autotests/kptyprocesstest.cpp 8b0b5b0 
> 
> Diff: https://git.reviewboard.kde.org/r/129197/diff/
> 
> 
> Testing
> ---
> 
> make test on FreeBSD
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

Re: Review Request 129197: Fix tests on FreeBSD

[Gleb Popov]

> On Oct. 16, 2016, 4:12 p.m., Tobias Berner wrote:
> > I'm kind of unsure if this is right. Yes, the tests run now, but isn't the 
> > issue rather in the way kpty works (or fails to work on FreeBSD)?

>From what i've understood, this boils down to 
>`KPtyDevicePrivate::_k_canRead()` method in kptydevice.cpp. The line 284

if (!::ioctl(q->masterFd(), PTY_BYTES_AVAILABLE, (char *) ))

returns 0 in `available` and this makes method return `false`. This, in turn, 
make `waitFor*` methods return false too.

Now you mention it, i'm also unsure if this `ioctl` behaves different on Linux.


- Gleb


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129197/#review100039
---


On Oct. 16, 2016, 2:44 p.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129197/
> ---
> 
> (Updated Oct. 16, 2016, 2:44 p.m.)
> 
> 
> Review request for KDE Frameworks, Adriaan de Groot, Tobias Berner, Oswald 
> Buddenhagen, and Martin Tobias Holmedahl Sandsmark.
> 
> 
> Repository: kpty
> 
> 
> Description
> ---
> 
> Apparently, KPtyDevice can't be operated on after KPtyProcess finishes. Tweak 
> tests accordingly, so they actually test things while the process is still 
> running.
> 
> 
> Diffs
> -
> 
>   autotests/kptyprocesstest.cpp 8b0b5b0 
> 
> Diff: https://git.reviewboard.kde.org/r/129197/diff/
> 
> 
> Testing
> ---
> 
> make test on FreeBSD
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

Re: Review Request 129188: Add documentation for the GenerateProperties option

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129188/#review100043
---




src/kconfig_compiler/README.dox (line 216)


Are you sure this is needed? maybe we could make it so it's not needed? 
Looks the kind of thing that will generate crazy errors, hard to figure out.


- Aleix Pol Gonzalez


On Oct. 15, 2016, 11:31 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129188/
> ---
> 
> (Updated Oct. 15, 2016, 11:31 a.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> The `GenerateProperties` option is missing from: 
> https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html
> 
> This patch explains what the option does and how to use it.
> 
> 
> Diffs
> -
> 
>   src/kconfig_compiler/README.dox b9606f1d157229a22afbeaea7d56ee95732762a2 
> 
> Diff: https://git.reviewboard.kde.org/r/129188/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 220 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/220/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Sun, 16 Oct 2016 09:34:18 +
Build duration: 5 min 10 sec

CHANGE SET
Revision 8cc875369208e4729ad9b3aa6b2f664be5950013 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/plasma/packagestructure/dataengine-packagestructure.json
  change: edit 
src/plasma/packagestructure/containmentactions-packagestructure.json
  change: edit src/plasma/packagestructure/plasmageneric-packagestructure.json
  change: edit src/plasma/packagestructure/plasmatheme-packagestructure.json
  change: edit src/plasma/packagestructure/plasmoid-packagestructure.json

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,All,gcc - Build # 220 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/220/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Sun, 16 Oct 2016 09:34:18 +
Build duration: 1 min 12 sec

CHANGE SET
Revision 8cc875369208e4729ad9b3aa6b2f664be5950013 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit 
src/plasma/packagestructure/containmentactions-packagestructure.json
  change: edit src/plasma/packagestructure/plasmatheme-packagestructure.json
  change: edit src/plasma/packagestructure/dataengine-packagestructure.json
  change: edit src/plasma/packagestructure/plasmoid-packagestructure.json
  change: edit src/plasma/packagestructure/plasmageneric-packagestructure.json

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,NoX11,gcc - Build # 220 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/220/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Sun, 16 Oct 2016 09:34:18 +
Build duration: 4 min 36 sec

CHANGE SET
Revision 8cc875369208e4729ad9b3aa6b2f664be5950013 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/plasma/packagestructure/plasmoid-packagestructure.json
  change: edit src/plasma/packagestructure/plasmatheme-packagestructure.json
  change: edit src/plasma/packagestructure/plasmageneric-packagestructure.json
  change: edit 
src/plasma/packagestructure/containmentactions-packagestructure.json
  change: edit src/plasma/packagestructure/dataengine-packagestructure.json

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 220 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/220/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Sun, 16 Oct 2016 09:34:18 +
Build duration: 4 min 47 sec

CHANGE SET
Revision 8cc875369208e4729ad9b3aa6b2f664be5950013 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/plasma/packagestructure/plasmatheme-packagestructure.json
  change: edit 
src/plasma/packagestructure/containmentactions-packagestructure.json
  change: edit src/plasma/packagestructure/plasmageneric-packagestructure.json
  change: edit src/plasma/packagestructure/plasmoid-packagestructure.json
  change: edit src/plasma/packagestructure/dataengine-packagestructure.json

Re: Scrap Baloo Thread Feedback

[Christoph Cullmann]

Hi,

(evil top posting)

given the silence, I assume any interest in baloo has stopped once more, or?
Or are there any plans how to fixup the current situation?

Greetings
Christoph

- Am 7. Okt 2016 um 20:08 schrieb cullmann cullm...@absint.com:

> Hi,
> 
>> Hey
>> 
>> On Fri, Oct 7, 2016 at 6:34 PM, Christoph Cullmann  
>> wrote:
>>> Hi,
>>>
 On Fri, Oct 7, 2016 at 5:58 PM, Christoph Cullmann  
 wrote:
>
>>>
>>> 1) No handling of DB errors beside asserting
>>> 2) No handling of errors in the extractors (e.g. see the fixes I did, all
>>> extractors will need more of that)
>>> 3) No handling of NFS/large inodes/inconsistencies => crash
>>>
>>> In the end, in my opinion, you can rewrite close to all parts dealing with 
>>> the
>>> DB or
>>> any other thing internally. If ever any thing gots inconsistent, ATM you are
>>> doomed, forever,
>>> if not by luck my new startup code deletes the index, then you live again 
>>> until
>>> it is reindexed.
>>>

>>> I am not sure, I am all for removing complete indexing and use a other 
>>> indexer
>>> like tracker to exactly avoid the excurse into DB world and how to handle it
>>> in a safe way with close to zero person manpower.
>>>
>> 
>> It's avoiding the problem and hoping for the best, without any experiments.
> That is not true.
> 
> I did experiments and search works with tracker, but yes, a problem is 
> tagging,+
> which ATM doesn't work. Nor do I say that is a ready solution now, just a
> possibility
> to avoid having to maintain low level code with at most 1 person (how it looks
> ATM).
> 
> And I don't propose to go that road now, but ATM I see nobody doing any other
> experiments.
> 
> Besides, tracker is constantly maintained and used since >> 5 years:
> 
> https://github.com/GNOME/tracker/graphs/contributors
> 
>> 
>>>
>>> => That is good that we agree, but I find it very astonishing that we use 
>>> baloo
>>> in its
>>> current state more or less mandatory on all that systems were it by design 
>>> will
>>> fail.
>>>
>>> (and it fails if you read the bugs)
>>>
>> 
>> There is a certain amount of failure, but it's not "by-design". But
>> maybe I'm not seeing things clearly.
> You yourself stated that neither 32-bit issues nor NFS nor > 32-bit inodes 
> have
> any
> error handling. And that seems to have been known even during design and still
> we have this now as a framework per default used by any Plasma installation on
> systems exactly featuring that without error checking.
> 
>> 

>>
>> How about requirements such as resource consumption, ease of
>> integration, search speed are taken into consideration? Come on guys.
>> We're engineers over here.
>> 
> What is the argument here? If you take a look at bugs.kde.org, you see 
> that
> people are complaining about all
> of that with baloo. I see no evidence nowhere that e.g. baloo is 
> "superior" to
> what GNOME uses
> or any other solution (perhaps beside nepomuk, ok...).
>> 
>> What tests have been to obtain the evidence?
> What tests have been done to obtain the inverse evidence? I only hear here the
> complaint
> about not taking requirements like resource consumption or speed into account,
> but
> there is ATM zero evidence that e.g. tracker is slower.
> 
> And yes, there are "it hogs" 100% memory or time bugs open, thought you can
> hardly reproduce them
> as people are somehow scared to pack their home and send it to us. Not that a
> lot of that bugs
> got touched at all in Bugzilla.
> 
>> 
>>>

 Yup, you have. It's awesome. I no longer have the motivation to work on 
 Baloo.
>>> Thanks, but that makes me very sad, btw.
>>> Baloo came up to replace nepomuk, which was dead because it had too many 
>>> bugs
>>> and all maintainers left.
>>> Now we have baloo, which has many bugs, some even by design, and the 
>>> maintainer
>>> left, too.
>>>
>> 
>> Actually, Nepomuk was not dead. I was maintaining it. I killed it
>> because it had too many structural problems.
>> 
>> This is how the open source world works. People work on projects and
>> when it no longer scratches their itch (I no longer use Baloo), they
>> loose interest. This is "supposed" to be a hobby.
> That is ok, to see it as hobby.
> 
> But I am a bit unnerved that one proposes this as the generic index solution
> for our desktop, which should be stable, if nothing else, and knows that it 
> has
> severe
> limitations that are not handled (see above). I would have assumed that at 
> least
> the known "can't work here'
> cases are handled in a graceful way.
> 
> And given already one of the first things main.cpp of baloo_file does is:
> 
>// HACK: Untill we start using lmdb with robust mutex support. We're just 
> going
>to remove
>//   the lock manually in the baloo_file process.
>QFile::remove(path + "/index-lock");
> 
> that doesn't leave high hopes, sorry.
> 
> And the typical error check is:

Review Request 129197: Fix tests on FreeBSD

[Gleb Popov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129197/
---

Review request for KDE Frameworks, Adriaan de Groot, Tobias Berner, Oswald 
Buddenhagen, and Martin Tobias Holmedahl Sandsmark.


Repository: kpty


Description
---

Apparently, KPtyDevice can't be operated on after KPtyProcess finishes. Tweak 
tests accordingly, so they actually test things while the process is still 
running.


Diffs
-

  autotests/kptyprocesstest.cpp 8b0b5b0 

Diff: https://git.reviewboard.kde.org/r/129197/diff/


Testing
---

make test on FreeBSD


Thanks,

Gleb Popov

Re: Review Request 129187: Fix dangling pointer in KPackageJob

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129187/
---

(Updated Oct. 16, 2016, 12:13 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Changes
---

Submitted with commit cfb69e21fb0aad92f403487b4c8a75b2b0bc8041 by David 
Edmundson to branch master.


Repository: kpackage


Description
---

A KPackage::Package object uses qexplicitlyshareddata, and it designed
to be kept on the stack and copied. However, PackageJob takes a pointer
to a package, which it later updates, which is expected to exist for the
lifecycle of the job.

This means

Package p = PackageLoader::self()->loadPackage(..);
p.install();

will crash.

Given that, I don't think this is an application error, and but a
library bug.

Both plasmashell installation and uninstallation have this problem:

BUG: 370718
BUG: 369935

As Package is not a QObject we can't just use a QWeakPointer, and
we can't just copy the Package in the packagejob as we need to detatch
and update the *original* KPackage instance. Also to match behaviour we need to 
do this without changing any other
KPackage instances sharing the same shareddata.

Not a neat fix at all, but there aren't many options that work
without breaking API or behaviour.


Diffs
-

  autotests/plasmoidpackagetest.h 2488f5c83bd60a693ae15bb5ee5628571ca18252 
  autotests/plasmoidpackagetest.cpp d7eb9e1a6d7f6e0465627fc0429f2da60c5af238 
  src/kpackage/package.cpp 207886e2d295773f5239c5804fc7c3a5f1120276 
  src/kpackage/private/package_p.h c97cbb68fa42b1335699e76e904cea5ebba75eba 
  src/kpackage/private/packagejob.cpp 84c20b2515ba3f0aba40bf6c1b69829a40bff9ed 

Diff: https://git.reviewboard.kde.org/r/129187/diff/


Testing
---

Crashing unit test
No longer crashes.


Thanks,

David Edmundson

Review Request 129202: Handle faulty provider as initialized

[Andreas Cord-Landwehr]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129202/
---

Review request for KDE Frameworks, Aleix Pol Gonzalez, Dan Leinir Turthra 
Jensen, and Jeremy Whiting.


Repository: knewstuff


Description
---

Always mark a provider as initialized when all initializion steps
are performed, in particularly when an error occured. This ensures
that the UI is correctly updated when the initialization steps finished.


Diffs
-

  src/attica/atticaprovider.cpp bc590ce2a2170f69d0b6d8049f7d5da5d0c1d0cd 

Diff: https://git.reviewboard.kde.org/r/129202/diff/


Testing
---

manual testing


Thanks,

Andreas Cord-Landwehr

Re: Scrap Baloo Thread Feedback

[Boudhayan Gupta]

Hi,

Unfortunately I've been hit my multiple pretty severe health scares in the
last month, and have no idea when I'm going to be at 100% again.

For the time being I'd rather not hold up any development, so don't hold
back anything on my account.

-- Boudhayan

On 16 October 2016 at 17:46, Christoph Cullmann  wrote:

> Hi,
>
> (evil top posting)
>
> given the silence, I assume any interest in baloo has stopped once more,
> or?
> Or are there any plans how to fixup the current situation?
>
> Greetings
> Christoph
>
> - Am 7. Okt 2016 um 20:08 schrieb cullmann cullm...@absint.com:
>
> > Hi,
> >
> >> Hey
> >>
> >> On Fri, Oct 7, 2016 at 6:34 PM, Christoph Cullmann 
> wrote:
> >>> Hi,
> >>>
>  On Fri, Oct 7, 2016 at 5:58 PM, Christoph Cullmann <
> cullm...@absint.com> wrote:
> >
> >>>
> >>> 1) No handling of DB errors beside asserting
> >>> 2) No handling of errors in the extractors (e.g. see the fixes I did,
> all
> >>> extractors will need more of that)
> >>> 3) No handling of NFS/large inodes/inconsistencies => crash
> >>>
> >>> In the end, in my opinion, you can rewrite close to all parts dealing
> with the
> >>> DB or
> >>> any other thing internally. If ever any thing gots inconsistent, ATM
> you are
> >>> doomed, forever,
> >>> if not by luck my new startup code deletes the index, then you live
> again until
> >>> it is reindexed.
> >>>
> 
> >>> I am not sure, I am all for removing complete indexing and use a other
> indexer
> >>> like tracker to exactly avoid the excurse into DB world and how to
> handle it
> >>> in a safe way with close to zero person manpower.
> >>>
> >>
> >> It's avoiding the problem and hoping for the best, without any
> experiments.
> > That is not true.
> >
> > I did experiments and search works with tracker, but yes, a problem is
> tagging,+
> > which ATM doesn't work. Nor do I say that is a ready solution now, just a
> > possibility
> > to avoid having to maintain low level code with at most 1 person (how it
> looks
> > ATM).
> >
> > And I don't propose to go that road now, but ATM I see nobody doing any
> other
> > experiments.
> >
> > Besides, tracker is constantly maintained and used since >> 5 years:
> >
> > https://github.com/GNOME/tracker/graphs/contributors
> >
> >>
> >>>
> >>> => That is good that we agree, but I find it very astonishing that we
> use baloo
> >>> in its
> >>> current state more or less mandatory on all that systems were it by
> design will
> >>> fail.
> >>>
> >>> (and it fails if you read the bugs)
> >>>
> >>
> >> There is a certain amount of failure, but it's not "by-design". But
> >> maybe I'm not seeing things clearly.
> > You yourself stated that neither 32-bit issues nor NFS nor > 32-bit
> inodes have
> > any
> > error handling. And that seems to have been known even during design and
> still
> > we have this now as a framework per default used by any Plasma
> installation on
> > systems exactly featuring that without error checking.
> >
> >>
> 
> >>
> >> How about requirements such as resource consumption, ease of
> >> integration, search speed are taken into consideration? Come on
> guys.
> >> We're engineers over here.
> >>
> > What is the argument here? If you take a look at bugs.kde.org, you
> see that
> > people are complaining about all
> > of that with baloo. I see no evidence nowhere that e.g. baloo is
> "superior" to
> > what GNOME uses
> > or any other solution (perhaps beside nepomuk, ok...).
> >>
> >> What tests have been to obtain the evidence?
> > What tests have been done to obtain the inverse evidence? I only hear
> here the
> > complaint
> > about not taking requirements like resource consumption or speed into
> account,
> > but
> > there is ATM zero evidence that e.g. tracker is slower.
> >
> > And yes, there are "it hogs" 100% memory or time bugs open, thought you
> can
> > hardly reproduce them
> > as people are somehow scared to pack their home and send it to us. Not
> that a
> > lot of that bugs
> > got touched at all in Bugzilla.
> >
> >>
> >>>
> 
>  Yup, you have. It's awesome. I no longer have the motivation to work
> on Baloo.
> >>> Thanks, but that makes me very sad, btw.
> >>> Baloo came up to replace nepomuk, which was dead because it had too
> many bugs
> >>> and all maintainers left.
> >>> Now we have baloo, which has many bugs, some even by design, and the
> maintainer
> >>> left, too.
> >>>
> >>
> >> Actually, Nepomuk was not dead. I was maintaining it. I killed it
> >> because it had too many structural problems.
> >>
> >> This is how the open source world works. People work on projects and
> >> when it no longer scratches their itch (I no longer use Baloo), they
> >> loose interest. This is "supposed" to be a hobby.
> > That is ok, to see it as hobby.
> >
> > But I am a bit unnerved that one proposes this as the generic index
> solution
> > for our desktop, which should be stable, if nothing else, and knows