20 Nov
2024
20 Nov
'24
5:48 p.m.
On Sereda 20 Lystopad 7532 15:35:11 deloptes via tde-users wrote:
There is no problem in building for archived Debian for such support, and I do that for my
project,
so proving the developing to environments of starting the program and some early. :)
Roman Savochenko via tde-users wrote:
And in fstab you can point any udisks option, where are limits here? :)
That is not about "manpower", the
first, but about limiting udisks
features and without proper informing in dialogues about used mounting
parameters and mechanisms. And to add that, I need up to one hour, but
prove that is a problem, it seems there will be one day and more.
If you have entry in fstab, you limit udisks - also TDE chooses fstab entry
first. This is correct. May be TDE could be updated so that when you have
udisks in the mount
options, that it would prefer using udisks over fstab.
And do that more unobvious?
The second,
that is about positioning TDE as "with a primary goal of
retaining the function and form of traditional desktop computers.", which
means of the software working on "traditional" HW where this software
appeared, but of course the "two standards way" brought KDE3 to breaking
such possibility by cmake, tqtinterface and including new code with
anchoring it to new interfaces without saving the old compatibility, so
for Debian 7 the last is 14.0.10, for Debian 8 is 14.0.13, for Debian 9
is 14.1.0. That is, for new versions we must start to throw out the old
HW also as for MancurtoScoft (MS)! The authoritarian development
conception-process causes to I am patching this only for myself (and my
users), also as CD-RW icons, playing DVD in Kaffeine and so on, after
breaking those by the "local authority".
I am not aware of any TDE dependency on specific hardware. The
compatibility to the Debian system is driven by Debian. TDE supports the
Debian version as long as Debian supports this version. As for the rest Kaffeine for example caused problems
from the start to present.
Not for me. :)
I am not aware that some "local authority"
did something on purpose to break
something, but honestly this is the reason I never liked or used it and I
stick to kplayer.
When the "local authority" acknowledges all merging request through own
knowledge, it take on self
all responsibility from developers for applied or rejected code, so freezing the changes,
which
could be reworkered whether the Author or someone else after testing in the end
environment.
Relating to Kaffeine and other, the "local authority" waits that I very want to
place my code to
their repository, so I must listen their instruction and obey without a word even know
their are
wrong. :)
As far as I understood tqtinterface was merged into
the main code ... what
old compatibility do you mean?
Do you know how many bugs I have fixed during moving to tqtinterface and cmake, and how
many there
are leaved hidden issues after potential building sensitive code with other optimisation
options
and without some specific in Autotool?
So, you can see that here —
http://oscada.org/wiki/Special:MyLanguage/User:RomanSavochenko/Open_Source_…
You have to adjust the headers a bit and
recompile, which the devs are doing anyway for us.
So, where are you already compiled 14.1.3 for Debian 7,8,9? :)