A while ago "lupdate" started to work 10+ times slower than it was.

The practical implication of this is FTBFS of QuiteRSS on
[arm64,armel,armhf,mipsel] and other architectures due to timeout because
"lupdate" work silently for 150+ minutes where it used to take minutes to do
the same job...
---

Happiness is when what you think, what you say, and what you do are in
harmony.
        -- Mahatma Gandhi

severity 823822 importantthanks
Hi Dmitry! Please allow me to explain you why I'm downgrading the severity of this bug.
lupdate is a tool that scans source code to check for translatable strings and create/update the
templates translators need to do their job.
Once this templates are translated lrelease is used to get the binary files that will serve as
databases for translated strings.
So lupdate is a tool meant to be run during the development process and not during the build
process. Using it as a part of the build process is just wrong. On the other hand running
lrelease at build time is actually a very nice idea.
If somehow upstream needs to run lupdate *after* the tarballs or the git tag has been pushed
then you can safely run it before packaging the source code. This is of course not nice, but
upstream shouldn't be forcing you to do this in the first place.
So the tool is not used in it's right place and a workaround is available, thus downgrading the
severity to important.
Please note that I *do* acknowledge the bug. I have been looking at
https://bugreports.qt.io/browse/QTBUG-27936[1]
and a good test case could really serve well here. Please note that upstream will certainly not
botter too much if it runs slow on slow archs as I have said before this tool is not meant to be
part of the build process.
Kinds regards, Lisandro.
-- Lisandro Damián Nicanor Pérez Meyer

http://perezmeyer.com.ar/[2]
http://perezmeyer.blogspot.com/[3]

--------
[1] https://bugreports.qt.io/browse/QTBUG-27936
[2] http://perezmeyer.com.ar/
[3] http://perezmeyer.blogspot.com/

severity 823822 importantthanks
Hi Dmitry! Please allow me to explain you why I'm downgrading the severity of this bug.
lupdate is a tool that scans source code to check for translatable strings and create/update the
templates translators need to do their job.
Once this templates are translated lrelease is used to get the binary files that will serve as
databases for translated strings.
So lupdate is a tool meant to be run during the development process and not during the build
process. Using it as a part of the build process is just wrong. On the other hand running
lrelease at build time is actually a very nice idea.
If somehow upstream needs to run lupdate *after* the tarballs or the git tag has been pushed
then you can safely run it before packaging the source code. This is of course not nice, but
upstream shouldn't be forcing you to do this in the first place.
So the tool is not used in it's right place and a workaround is available, thus downgrading the
severity to important.
Please note that I *do* acknowledge the bug. I have been looking at
https://bugreports.qt.io/browse/QTBUG-27936[1]
and a good test case could really serve well here. Please note that upstream will certainly not
botter too much if it runs slow on slow archs as I have said before this tool is not meant to be
part of the build process.
Kinds regards, Lisandro.
-- Lisandro Damián Nicanor Pérez Meyer

http://perezmeyer.com.ar/[2]
http://perezmeyer.blogspot.com/[3]

--------
[1] https://bugreports.qt.io/browse/QTBUG-27936
[2] http://perezmeyer.com.ar/
[3] http://perezmeyer.blogspot.com/

No worries. Thank you for explanation. I've bumped severity only due to
#823822 (quiterss' FTBFS on timeout due to 150+ min in lupdate)...

Thanks for suggestion. I'll try to replace lupdate with lrelease...

I've introduced 'lupdate' as workaround for run-time segfaults in some
locales due to missing translations (as I recall). I know no indicators to
notice when 'lupdate' is necessary... If 'lrelease' is insufficient then it
may be preferable to run 'lupdate' on build-time as a precaution.

OK. Makes sense.

Thank you. :)

QuiteRSS may be a good case...

---

However beautiful the strategy, you should occasionally look at the
results.
        -- Winston Churchill

I thought so :-)

Segfaults because of missing translations? First time I hear that (but there's
always a first time for everything ;-) ).

Moreover I can reproduce it. I asked Ossi upstream to give me some hints about
how to debug it.

They are looking for a small, self-contained test case. But I wonder if that's
possible with this bug.