Roman Savochenko via tde-users wrote: >> 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? > Raise a ticket in TGW, so that we do not forget it and much better provide a patch that addresses the issue (not commenting out in the code) > > 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. :) Of course there is no problem ... it just makes no sense. > >> As for the rest Kaffeine for example caused problems from the start to >> present. > > Not for me. :) > Obviously >> 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. :) > This is normal ... when you are not the "local authority". I actually like it. It is usually called team work. >> 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? > No idea, but this is the result, when you kind of fork and continue on your own. IMO it would be better for all parties that you try doing only temporary changes and try get them into the main repo, because other wise the work increases over time. At the end it is your own choice what you do. You are the "local authority for your work". If you wish you can write to me in private what issues you have, or post them here one by one, so that we could discuss. It would be great if you could contribute, but this includes obeying the local authority. I am pretty happy with the cooperation with this local authority. Few things/bugs that were bothering me and I fixed were accepted without big problems and I learned a lot. I also ported one or two applications and it also worked quite well. It is just a normal work flow that you have in every company or open source project. I really do not understand your frustration, but it is sad to hear disappointment. You probably never dealt with Gnome/KDE or other projects and their "local authorities" > So, you can see that here — > http://oscada.org/wiki/Special:MyLanguage/User:RomanSavochenko/Open_Source_Actions > not bad, not bad ... I wish I had the time to go through them and move them (if possible) into the main repo, but unfortunately, I do have very limitted time. Whenever I find time I will try to pick up one or two and try to create a patch. Let's see if it works. I do not promise anything. >> 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? :) This is waste of time, disk space (and electricity) I do not have such systems - in fact it is actually not recommended (it would be forbidden) to use them for security reasons. ____________________________________________________ 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