Building from source creates unusable .desktop file when grep 2.23 is installed.

[rapgro]

Please use the cmake module directly from liblxqt and unbundle it. We suffer in Fedora from a bug with newer grep.
See lxqt/lxqt#957

[palinek]

I've submitted PR for this... but I don't know if others wish the liblxqt dependency...

[rapgro]

Thanks. 👍

[agaida]

See lxqt/lxqt#957
@palinek @PCMan @paulolieuthier @jleclanche
unfixed: compton-conf, libfm-qt, lximage-qt, obconf-qt and pcmanfm-qt
we should discuss it on the list if you agree - i see right now no downsides in a build-dependency, the resulting packages do not depend on liblxqt, because the pure cmake mechanics are used only at build time. Until we decide this we should push the '-a' thing into the packages.

BTW: the issue hit sid and will hit debian testing too soon and might affect all debian derivatives in a short amount of time

[agaida]

@ALL - the github bug tracking is horrible, we should really consider to use track or redmine for this

[luis-pereira]

@agaida IIRC @PCMan pushed for not having an liblxqt compile dependency.

[agaida]

i'm fine with that too - but in that case we should build our own pkg-lxqt-tools with some arch indipendend scripts in it. In other words. a script is a script is a script - and if the scripting is indipendend enought it should be no problem to put it in a separated packages/repo and avoid code dupes

[rapgro]

👍 for the independent scripts, what about in lxqt-common ?

[agaida]

@rapgro - i would not place build scripts in common. i would really pack them into a separated repo and make a package out of them. Hey - it's github, we don't have to pay per repository. Joke aside, its a lot easier to distribute if the scripts would be in a single package. A package with some internal used scripts is fast uploaded in case of changes and don't affect any users in case of changes.