20 Nov
2024
20 Nov
'24
6:13 p.m.
ср, 20 нояб. 2024 г., 20:48 Roman Savochenko via tde-users <
users(a)trinitydesktop.org>gt;:
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. :)
impressive list! :)
thank you for all those years of work ....
Roman Savochenko via tde-users wrote:
entry
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 first. This is correct.
And in fstab you can point any udisks option, where are limits here? :)
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? :)
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…