Hi Norbert,
Norbert Preining <norbert@preining.info> writes:
> Control: tag -1 +unreproducible
>
> Hi Nicholas,
>
> to be clear, tagging this bug as "unreproducible" means that **we** the
> developer cannot reproduce it. So please don't change it. Thanks.
>
> Also, moreinfo is still needed, and you didn't provide it.
>
I did. The minimum dataset needed to trigger was with an extensive set
of exclusion patterns that result in 436767 indexed files, with the
following results returned for balooctl indexSize
Actual Size: 3.27 GiB
Expected Size: 2.12 GiB
PostingDB: 424.52 MiB 19.516 %
PositionDB: 845.84 MiB 38.884 %
DocTerms: 344.65 MiB 15.844 %
DocFilenameTerms: 47.45 MiB 2.181 %
DocXattrTerms: 0 B 0.000 %
IdTree: 7.64 MiB 0.351 %
IdFileName: 35.77 MiB 1.645 %
DocTime: 22.29 MiB 1.024 %
DocData: 23.21 MiB 1.067 %
ContentIndexingDB: 0 B 0.000 %
FailedIdsDB: 0 B 0.000 %
MTimeDB: 2.59 MiB 0.119 %
>> > Can you reproduce this with current frameworks 5.77 in unstable?
>
> Since you haven't answered this questions, that BTW is alread at 5.78,
> we cannot really do anything.
>
> You don't expect us to try to triage bugs that we cannot reproduce on a
> system that is not running the current version?
>
I will upgrade this system in mid to late February, and hope to be
pleasantly surprised that this bug was fixed upstream :-) At that time,
how would you like me run baloo to generate a higher quality debugging
info? It could take up to a month to reproduce this bug, and by then
the reply will be "ignore for bullseye". This is a contributing factor
to why baloo is in perpetual beta (I'd argue alpha, but subjectivity ;-))
>> Has anyone on the team tried testing baloo with a large $HOME? Mine is
>> 131GB, in 142460 mixed files and directories. At the moment my
>> baloo_file process is consuming over a terabyte (!) of memory. After
>> resetting baloo and forcing a full reindex it takes a couple of weeks
>> before it gets out of control again and crashes.
>
> Well, maybe you should disable the service since it obviously is not
> able to cope with the amount of data/files/size you are asking it to
> index.
>
Right, that's why I filed this bug. With a non-toy dataset, baloo is
more often than not unusable. Typical lore says to disable baloo and
use the more robust recoll. I'm willing to conceded that it's possible
that there's something special about my data/files, and that they're
causing baloo to fail in a corner-case. If that's the case, what data
do you need? Other than all my files ;-)
>> Please don't sweep baloo bugs under the rug by tagging bugs containing
>> crashes with obvious misbehaviour as severity "normal", eg:
>
> Again, since it is not reproducible and nobody else has either reported
> this problem and none of us see this problem, it is normal, would you
> please kindly trust the decision of the maintainers?
> And thanks, you don't have to educate me about severities.
>
Important: "a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone." It is
clear that this bug meets Debian criteria for "important". If no one
else on the team (I'm a team member too) is testing baloo with a medium
size set of diverse file types than no one else one the team will be
able to reproduce it.
A politic of "normal + unreproducible" is a contributing factor to
why baloo is never fixed. In other words, it's a politic of ignoring
problems in baloo.
Cheers,
Nicholas
Attachment:
signature.asc
Description: PGP signature