On Sereda 20 Lystopad 7532 15:35:11 deloptes via tde-users wrote: > Roman Savochenko via tde-users wrote: > > 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. 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. 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. :) > 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_Actions > 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@xxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@xxxxxxxxxxxxxxxxxx
