On Pjatnyca 22 Lystopad 7532 18:01:32 deloptes via tde-users wrote: > 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) I write nothing to TGW right now since there lie tens my previous patches! > > 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. OK, how many sense in holding all previous binary and source packages? :) > >> 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. I know how teams work, and this one just authoritarian cast tree, when someones on the top think they "know roots" and other do not, and for decades they can't fix problems fixed by experienced users "without the root knowledges". That is they let for users "eat the cactus" or drop down this mess, how do many inexperienced users for that broken KDE3. And for the "local authority", ALL difficult problems are fixed through hacks! :) > >> 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. Not fork but stupid re-branding, with constant symbols renaming forward and back, with changing the well tested and debugged building system and loss support of old systems, so caused many hidden and even visible broken code instead the using stabilisation of the mature code. Also as changing habits of the code development and debugging especially for partial fast building, by implementation cmake, ninja and so on. > 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". I NEVER overpress others, leaving for them the responsibility for their code, which they can improve after exploiting the applied code, especially when I don't know deep of the problem specific, that is when I don't use this function! And I was forced to create the my partial fork after my critical for me patches became ignored, that I did not choose that! > 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. I have no problem with my "hacks", also as I have no time and wishes to prove something for the "local authority"! :) > 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. That is not normal in my 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" I dealt with the official builds of some Linux distributions, and saw there horde of the patches to KDE3, so I can imagine about that "tradition". :) > >> 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. If that waste of time, then you can forget this problem, due to it mostly for Debian 7 and the old build 14.0.10. When you want to save disk space, remove old builds, which are not needed anybody exactly. And last versions for old distributions and HW I need, due to work with such hardware, where you cannot to install fresh distributions whether in reasons of kernels, or specific modules to them, also as through the productivity and do not generating HW garbage. -- Roman Savochenko OpenSCADA (http://oscada.org), author and main developer roman@xxxxxxxxxx, tel:+380679859815 Kamjanske, 51939, Ukraine
Attachment:
MediaManager.png
Description: PNG image
Attachment:
slave_media_fstabByUdisks.patch.gz
Description: GNU Zip compressed data
____________________________________________________ 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