Proposal of release blocker (missing translations for some .desktop files)

[David Faure]

This is unfortunate.

However I would suggest adding .desktop.in to scripty, rather than forbidding 
this extension.

I have no idea why people ever called foo.cmake the files that are passed to 
cmake's configure_file for preprocessing, it seems like a bad idea to me, it's 
confusing with files that actually contain cmake code (like FindFAM.cmake, 
KF5AuthMacros.cmake or CTestConfig.cmake).

On the other hand, naming "input" files that have to be preprocessed
".in" seems completely logical to me.
This leads to .h.in for headers, .desktop.in for desktop files, and it even 
allows .cmake.in for cmake files that need preprocessing, like 
kconfig/KF5ConfigConfig.cmake.in
What should it be named otherwise? kconfig/KF5ConfigConfig.cmake.cmake ? ;-)

PS: Luigi Toscano <luigi.toscano at tiscali.it> rejects my email, indeed.

Cheers,
David.

On dimanche 3 janvier 2021 17:16:17 CET Luigi Toscano wrote:
> Hi,
> 
> scripty recognizes a few extensions as "desktop files" and extract their
> strings. Additional files can be added by adding an ExtraDesktop.sh file
> which lists them.
> 
> So far, .desktop.in is *not* a recognized pattern by default.
> 
> There has been an increase of repositories which use desktop.in.
> Apart from kwave, which has historically not agreed to the change back in
> the days (but that may be reevaluated, I guess) and workarounded the
> problem with an ExtraDesktop.sh file.
> 
> Most of the repositories have been changed recently, but some of them have
> been not properly working for a while.
> There are repositories part of the release service, one part of Plasma and a
> few with independent release cycles. In no particular order:
> 
> kte-collaborative
> snorenotify
> kube
> kwave
> dragon
> konqueror
> dolphin
> xdg-desktop-portal-kdegraphics
> svgpart
> markdownpart
> kimagemapeditor
> kgraphviewer
> okteta
> kmymoney
> kmplayer
> 
> (see https://lxr.kde.org/search?_filestring=desktop.in&_string= )
> 
> I'd like to hold on all the release of all affected repositories until this
> is fixed. I think RS 20.12.1 is not affected, but the Plasma 5.21 branching
> is, and so the future 21.04 (but let's hope to have that fixed by then).
> 
> 
> Unfortunately my email provider is acting up today and I can't push any
> proposal change to solve this in a way (revert to .desktop.cmake as
> expected) or another (let ignore that in scripty - I don't want really want
> yet another set of special exceptions through ExtraMessages.sh).


-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5