18 Nov
2024
18 Nov
'24
9:34 p.m.
Roman Savochenko via tde-users wrote:
Thanks for the tip. :)
Yes, that will work also without using udisks, but I have struck to the
problem through udisks, so resolved it through udisks, and read also many
such manuals before.
But TDE is supporting udisks and udisks2. This issue must be solvable
somewhere else.
Any way, that is strange of using direct mounting at
udisks presence, who
is correctly processed /etc/fstab for proper user with a record in
/etc/fstab: /dev/fd0 /media/floppy auto
noauto,users,owner,iocharset=utf8,codepage=866 0 0
This is the Debians recommendation - it doesn't know anything about TDE.
19 Nov
19 Nov
7:21 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
Ponedilok 18 Lystopad 7532 23:34:16 deloptes via tde-users написав:
I know that.
Roman Savochenko via tde-users wrote:
I know about TDE support udisks even from the source code, but udisks or TDE in arguments
is broken
about FD support. Due to the both default and custom mounting options are not acceptable
and it
mounts FD only from root:root and 755, when there is no record about FD in /etc/fstab.
Thanks for the tip. :)
Yes, that will work also without using udisks, but I have struck to the
problem through udisks, so resolved it through udisks, and read also many
such manuals before.
But TDE is supporting udisks and udisks2. This issue must be solvable
somewhere else. Any way, that
is strange of using direct mounting at udisks presence, who
is correctly processed /etc/fstab for proper user with a record in
/etc/fstab: /dev/fd0 /media/floppy auto
noauto,users,owner,iocharset=utf8,codepage=866 0 0
This is the Debians recommendation - it doesn't know anything about TDE. 
11:43 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
Roman Savochenko via tde-users wrote:
I know that.
Well, I don't know. I would just use the default options. I would also not
use /media, because media is used by the system to automatically mount
devices (I guess it is true for udisks2).
My understanding of your problem is that you create an entry in fstab and
use udisks in the same time. The entry in fstab causes TDE to read this
entry and omit udisks. Udisks does not need an entry in fstab anyway. So it
looks to me TDE has the correct precedence and this must be right.
In any case as you now use TDE with this part of the code removed, we can
not just try removing the fstab entry and see if this would work. But
honestly I also doubt you would try it anyway.
BR
20 Nov
20 Nov
6:20 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Sereda 20 Lystopad 7532 01:43:47 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
There is no problem with options here, since they are accepted correctly, there is a
problem with
missing options to control user of the mounted disk folder. And that missing is not the
problem
also of tdestoragedevice.cpp in processing the mounting options, due to udisks doesn't
allow
neither user, owner, uid or mask options.
I know that.
Well, I don't know. I
would just use the default options. I would also not
use /media, because media is used by the system to automatically mount
devices (I guess it is true for udisks2). My understanding of your problem is that you create an
entry in fstab and
use udisks in the same time. The entry in fstab causes TDE to read this
entry and omit udisks. Udisks does not need an entry in fstab anyway. So it
looks to me TDE has the correct precedence and this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is a single solution
for FD
without fixing udisks itself. And most solutions in Internet about treating that behaviour
of
udisks mean same appending an entry for FD to /etc/fstab, and TDE here tricks you starting
use
mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides this feature!!!
Regards, Roman
7:26 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
ср, 20 нояб. 2024 г., 09:21 Roman Savochenko via tde-users <
users(a)trinitydesktop.org>gt;:
On Sereda 20 Lystopad 7532 01:43:47 deloptes via
tde-users wrote:
In this case, I hope just one additional checkbox "prefer udisk(2) over
fstab" will cover this use case?
Roman Savochenko via tde-users wrote:
not
I know that.
Well, I don't know. I
would just use the default options. I would also use /media, because media is used by the system
to automatically mount
devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted correctly,
there is a problem with
missing options to control user of the mounted disk folder. And that
missing is not the problem
also of tdestoragedevice.cpp in processing the mounting options, due to
udisks doesn't allow
neither user, owner, uid or mask options.
My understanding of your problem is that you
create an entry in fstab and
use udisks in the same time. The entry in fstab causes TDE to read this
entry and omit udisks. Udisks does not need an entry in fstab anyway. So
it
looks to me TDE has the correct precedence and
this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is a
single solution for FD
without fixing udisks itself. And most solutions in Internet about
treating that behaviour of
udisks mean same appending an entry for FD to /etc/fstab, and TDE here
tricks you starting use
mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides
this feature!!!
Regards, Roman
____________________________________________________
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…
9:05 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On 2024/11/20 04:26 PM, Andrew Randrianasulu via tde-users wrote:
udisks2 also can use /etc/fstab, and
mediamanager.cpp wrongly overrides this feature!!!
In this case, I hope just one additional checkbox "prefer udisk(2) over fstab"
will cover this use case?
Sorry, I don't get it.
/etc/fstab is there to allow a sys admin to setup information on how to mount disks. For
example you could mount
specific partitions to specific folders and allow access to specific users *ONLY*.
If any non-root user could simply click a checkbox and bypass the rules in fstab and mount
disks at its own pleasure,
where would security go?
On a server or share computer, the above can't not be allowed and using fstab info is
the correct way, when present.
systemd does that and you can mount a disk with udisks and dbus without even having any DE
installed, as long as fstab
and policies allow you to do that.
On a personal computer with a single user, you can login as root, edit fstab and set up
mounting as you prefer or remove
the entry from there all together.
Maybe I am missing something, if so please point it out for my own knowledge :-)
Cheers
Michele
10:40 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Sereda 20 Lystopad 7532 09:26:14 Andrew Randrianasulu wrote:
ср, 20 нояб. 2024 г., 09:21 Roman Savochenko via
tde-users <
users(a)trinitydesktop.org>gt;:
I think for that just can be used the present CheckBox "Use default mount
option", which means as
force using udisks at TRUE, with this default parameters in /etc/fstab at presence, and
use custom
parameters from that dialogue at FALSE. Also with overriding by direct mount at an entry
presence,
with hidding the dialogue parameters as nonsenses and/or writing here about taking from
/etc/fstab
by mount.
On Sereda 20 Lystopad 7532 01:43:47 deloptes via
tde-users wrote:
In this case, I hope just one additional checkbox "prefer udisk(2) over
fstab" will cover this use case?
> Regards, Roman
> ____________________________________________________
> 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@trinitydes
>ktop.org Roman Savochenko via tde-users wrote:
not
I know that.
Well, I don't know. I would just use the default options. I would also use /media, because media is used by the system
to automatically mount
devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted correctly,
there is a problem with
missing options to control user of the mounted disk folder. And that
missing is not the problem
also of tdestoragedevice.cpp in processing the mounting options, due to
udisks doesn't allow
neither user, owner, uid or mask options.
My understanding of your problem is that you
create an entry in fstab
and use udisks in the same time. The entry in fstab causes TDE to read
this entry and omit udisks. Udisks does not need an entry in fstab
anyway. So
it
looks to me TDE has the correct precedence and
this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is
a single solution for FD
without fixing udisks itself. And most solutions in Internet about
treating that behaviour of
udisks mean same appending an entry for FD to /etc/fstab, and TDE here
tricks you starting use
mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides
this feature!!! 
11:42 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
Anno domini 2024 Wed, 20 Nov 12:40:33 +0200
Roman Savochenko via tde-users scripsit:
On Sereda 20 Lystopad 7532 09:26:14 Andrew
Randrianasulu wrote:
Investing manpower into a problem that may for some users exist on ancient hardware is not
a sane way to do when manpower is limited. If said users think it's worth their time
then they should just make the changes and submit a patch. That said, I just found a
single 3.5" floppy disk in the stack of archived software - needless to say that the
last floppy drive left over 20 jears ago. So if anybody needs it for the ancient floppy
drives just drop me note.
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
ср, 20 нояб. 2024 г., 09:21 Roman Savochenko via
tde-users <
users(a)trinitydesktop.org>gt;:
I think for that just can be used the present CheckBox "Use default mount
option", which means as
force using udisks at TRUE, with this default parameters in /etc/fstab at presence, and
use custom
parameters from that dialogue at FALSE. Also with overriding by direct mount at an entry
presence,
with hidding the dialogue parameters as nonsenses and/or writing here about taking from
/etc/fstab
by mount. On Sereda 20 Lystopad 7532 01:43:47 deloptes via
tde-users wrote:
In this case, I hope just one additional checkbox "prefer udisk(2) over
fstab" will cover this use case?
> Regards, Roman
> ____________________________________________________
> 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@trinitydes
>ktop.org Roman Savochenko via tde-users wrote:
> I know that.
Well, I don't know. I would just use the default options. I would also
not
use /media, because media is used by the system
to automatically mount
devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted correctly,
there is a problem with
missing options to control user of the mounted disk folder. And that
missing is not the problem
also of tdestoragedevice.cpp in processing the mounting options, due to
udisks doesn't allow
neither user, owner, uid or mask options.
My understanding of your problem is that you
create an entry in fstab
and use udisks in the same time. The entry in fstab causes TDE to read
this entry and omit udisks. Udisks does not need an entry in fstab
anyway. So
it
looks to me TDE has the correct precedence and
this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is
a single solution for FD
without fixing udisks itself. And most solutions in Internet about
treating that behaviour of
udisks mean same appending an entry for FD to /etc/fstab, and TDE here
tricks you starting use
mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides
this feature!!!
12:59 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Sereda 20 Lystopad 7532 13:42:20 Dr. Nikolaus Klepp via tde-users wrote:
Anno domini 2024 Wed, 20 Nov 12:40:33 +0200
Roman Savochenko via tde-users scripsit:
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.
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".
And the third, the FDC controllers were still appeared on MB 2010 year old! :)
On Sereda 20 Lystopad 7532 09:26:14 Andrew
Randrianasulu wrote:
Investing manpower into a problem that may for some users exist on ancient
hardware is not a sane way to do when manpower is limited. If said users
think it's worth their time then they should just make the changes and
submit a patch. That said, I just found a single 3.5" floppy disk in the
stack of archived software - needless to say that the last floppy drive
left over 20 jears ago. So if anybody needs it for the ancient floppy
drives just drop me note. ср, 20 нояб. 2024 г., 09:21 Roman Savochenko via
tde-users <
users(a)trinitydesktop.org>gt;:
I think for that just can be used the present CheckBox "Use default mount
option", which means as force using udisks at TRUE, with this default
parameters in /etc/fstab at presence, and use custom parameters from that
dialogue at FALSE. Also with overriding by direct mount at an entry
presence, with hidding the dialogue parameters as nonsenses and/or
writing here about taking from /etc/fstab by mount. On Sereda 20 Lystopad 7532 01:43:47 deloptes via
tde-users wrote:
> Roman Savochenko via tde-users wrote:
> > I know that.
>
> Well, I don't know. I would just use the default options. I would
> also
not
> use /media, because media is used by the system to automatically
> mount devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted
correctly, there is a problem with
missing options to control user of the mounted disk folder. And that
missing is not the problem
also of tdestoragedevice.cpp in processing the mounting options, due
to udisks doesn't allow
neither user, owner, uid or mask options.
> My understanding of your problem is that you create an entry in
> fstab and use udisks in the same time. The entry in fstab causes
> TDE to read this entry and omit udisks. Udisks does not need an
> entry in fstab anyway. So
it
> looks to me TDE has the correct precedence and this must be right.
udisks can use /etc/fstab options to customize own behaviour and that
is a single solution for FD
without fixing udisks itself. And most solutions in Internet about
treating that behaviour of
udisks mean same appending an entry for FD to /etc/fstab, and TDE
here tricks you starting use
mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly
overrides this feature!!!
In this case, I hope just one additional checkbox "prefer udisk(2) over
fstab" will cover this use case?
1:35 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
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.
May be TDE could be updated so that when you have udisks in the mount
options, that it would prefer using udisks over fstab.
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. 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.
As far as I understood tqtinterface was merged into the main code ... what
old compatibility do you mean? You have to adjust the headers a bit and
recompile, which the devs are doing anyway for us.
1:51 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
ср, 20 нояб. 2024 г., 16:35 deloptes via tde-users <users(a)trinitydesktop.org
And Debian versions come and go with its own set of restrictions .....
As for the rest Kaffeine for
:
Roman Savochenko via tde-users wrote:
I guess "formalizing" this as feature request will be more productive than
growing this thread :)
Sorry, I installed NetBSD on new hard drive and I do not have access to my
Linux hdd currently (there were only two sata power cables .. one goes into
bluray writer/reader, other into hdd)
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.
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. example caused problems from the start to present. 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.
As far as I understood tqtinterface was merged into the main code ... what
old compatibility do you mean? You have to adjust the headers a bit and
recompile, which the devs are doing anyway for us.
Well, I think this is about infamous user/developer divide that failed to
fail even with libre software. Software may be libre, but understanding it
and rebuilding it locally often not really simple. Pushing changes upstream
also not always work. You end up either doing A LOT of work, or swim with
your distro's choices. I prefer Slackware exactly because it doesn't try to
limit me from shooting myself into head with packaging/installing on my
local machine. But even Slackware has limits of flexibility .....
____________________________________________________
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…
6:30 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Sereda 20 Lystopad 7532 15:51:18 Andrew Randrianasulu via tde-users wrote:
And Debian versions come and go with its own set of restrictions .....
Yes, and the restrictions exactly presented and will be floated away just you try to
build.
ср, 20 нояб. 2024 г., 16:35 deloptes via tde-users
<users(a)trinitydesktop.org
Just improving my patch will be maximum productive, that proved. :)
Roman Savochenko via tde-users wrote:
I guess "formalizing" this as feature request will be more productive than
growing this thread :) 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. 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. Well, I think this is about infamous user/developer
divide that failed to
fail even with libre software. Software may be libre, but understanding it
and rebuilding it locally often not really simple.
And that is about trusting at least to whom, who participated in that project from its
begin and
knows-tests more in aspects of the program deep using by him.
Pushing changes upstream also not always work.
But when you can re-push with own changes-fixes that is work for you always. :)
You end up either doing A LOT of work, or swim with
your distro's choices. I prefer Slackware exactly because it doesn't try to
limit me from shooting myself into head with packaging/installing on my
local machine. But even Slackware has limits of flexibility .....
:)
2:45 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On 2024/11/20 10:35 PM, deloptes via tde-users wrote:
May be TDE could be updated so that when you have
udisks in the mount
options, that it would prefer using udisks over fstab.
Is that even possible? systemd reads fstab entry on boots and when manually instructed to
do so and use fstab
information when a disk needs to be mounted, regardless of whether you use mount, udisks,
udisks2 or other mounting methods.
As I also mentioned in my previous email, if a standard users could bypass fstab
permissions so easily, it would be a
security issue.
Again, if I said something wrong or I am missing some info, happy to hear about it.
Cheers
Michele
2:56 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
ср, 20 нояб. 2024 г., 17:46 Michele Calgaro via tde-users <
users(a)trinitydesktop.org>gt;:
On 2024/11/20 10:35 PM, deloptes via tde-users wrote:
KDE3 and TDE does have "administrator mode" in Kcontrol, so user expected
to configure system this way too .....
May be TDE could be updated so that when you have
udisks in the mount
options, that it would prefer using udisks over fstab.
Is that even possible? systemd reads fstab entry on boots and when
manually instructed to do so and use fstab
information when a disk needs to be mounted, regardless of whether you use
mount, udisks, udisks2 or other mounting methods.
As I also mentioned in my previous email, if a standard users could bypass
fstab permissions so easily, it would be a
security issue.
Again, if I said something wrong or I am missing some
info, happy to hear
about it.
Cheers
Michele
____________________________________________________
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…
22 Nov
22 Nov
4:10 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
Michele Calgaro via tde-users wrote:
Is that even possible? systemd reads fstab entry on
boots and when
manually instructed to do so and use fstab information when a disk needs
to be mounted, regardless of whether you use mount, udisks, udisks2 or
other mounting methods. As I also mentioned in my previous email, if a
standard users could bypass fstab permissions so easily, it would be a
security issue.
Again, if I said something wrong or I am missing some info, happy to hear
about it.
May be I was mistaken, but when reading udisks docs, I saw an option for the
mount command. Now looking again, I think it was the mount options for
udisks in the configuration file.
https://storaged.org/doc/udisks2-api/latest/mount_options.html
I do not have much time ATM to look into it in details though.
As far as I understand the problem Roman addressed, it is that TDE bypasses
udisks if there is fstab entry for the device, while the correct behavior
would be to see if udisks is allowed to handle the device, because udisks
itself honours fstab. But this is just my understanding and hypothesis for
now. In the docs of udisks it says it uses fstab and its config file. Both
are managed by root only, so it is for the root user to decide what the
user can do.
23 Nov
23 Nov
2:50 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On 2024/11/23 01:10 AM, deloptes via tde-users wrote:
As far as I understand the problem Roman addressed, it
is that TDE bypasses
udisks if there is fstab entry for the device, while the correct behavior
would be to see if udisks is allowed to handle the device, because udisks
itself honours fstab. But this is just my understanding and hypothesis for
now. In the docs of udisks it says it uses fstab and its config file. Both
are managed by root only, so it is for the root user to decide what the
user can do.
Hi Emanoil,
thanks for the info and for expressing the problem in understandable terms :+1:
I read further into the link you posted and the udisks docs and this cleared a few things
out.
Basically udisks will obey /etc/fstab for those devices which are listed there, as
indicated here:
" Also note that block devices having corresponding records in /etc/fstab are
excluded from the overrides as the mount
options are fully taken from such records just like before."
So whether we follow fstab or let udisks handle the device, in the end the results should
be the same, unless I miss
something.
Cheers
Michele
10:59 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
Michele Calgaro via tde-users wrote:
So whether we follow fstab or let udisks handle the
device, in the end the
results should be the same, unless I miss something.
So we are again at square 1 :)
I did not have to read all of the documentation - very busy week. I read at
one place that it merges the fstab and the udsisks config and handles the
mounting.
But if this is so as you describe it, then there is something missing in the
whole picture.
I go back one step to the first post by Roman
> Access is controlled by udisks or from /etc/fstab!
:)
>
> And udisks directly mounts floppy only in RO.
>
Here obviously he did not take time to do proper udisks config for floppy
devices, which would obviously overwrite the default fstab ... or if it is
correct that the issue was in Debian7 it could be that this was older
version of udisks or something back then
> And when you write a record about floppy in
/etc/fstab, TDE uses direct
> mounting by call mount for it, and that is wrong work also for userspace.
>
It seems to me he is unhappy that floppy was mounting RO (I assume the issue
is here, because default entry in fstab created by debian or so or default
mount options for floppy somewhere in the linux distro). So he disables the
code in TDE, so that udisks can pick up and mount the floppy RW.
> Then I just disabled the direct mounting at a
record in /etc/fstab, so
> TDE is using udisks for that and udisks reads /etc/fstab and mounts RW
> in userspace correctly in this way.
I can just conclude that the problem was/is in the fstab mount options for
floppy for whatever reason. Thus TDE code is just fine and the claims made
by Roman incl. the hack-patch is invalid.
If my understanding is wrong, we have to organize a debugging session with
vanilla TDE to reproduce the problem.
Meanwhile Roman can build or install vanilla TDE without his patch and check
if the issue is still there. Roman, you can also provide some log
information if you play the cooperative game.
BR
24 Nov
24 Nov
7:08 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Nedila 24 Lystopad 7532 00:59:30 deloptes via tde-users wrote:
If my understanding is wrong, we have to organize a
debugging session with
vanilla TDE to reproduce the problem.
Meanwhile Roman can build or install vanilla TDE without his patch and
check if the issue is still there. Roman, you can also provide some log
information if you play the cooperative game.
I have say already:
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.
So, I have done this for myself and closed the question!!!
--
Roman Savochenko
OpenSCADA (http://oscada.org), author and main developer
roman(a)oscada.org, tel:+380679859815
Kamjanske, 51939, Ukraine
20 Nov
20 Nov
5:48 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
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? :)
6:13 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
ср, 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…
22 Nov
22 Nov
4:01 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
Roman Savochenko via tde-users wrote:
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)
Obviously
This is normal ... when you are not the "local authority". I actually like
it. It is usually called team work.
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"
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.
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 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?
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. :)
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? :)
23 Nov
23 Nov
3:35 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
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.
> Do you know how many bugs I have fixed...
> http://oscada.org/wiki/Special:MyLanguage/User:RomanSavochenko/Open_Source_…
Preparing a "fix" means:
1. investigating the issue and understanding the root cause of the problem
2. modifying the code to fix such root issue
Preparing a "hack" means:
1. not understanding the root cause of a problem
2. modifying the code to hide the problem
In TDE we have no problems to accept "fixes", as many of our contributors have
experienced.
But we do have a problem with "hacks": we would rather have a program to keep
crashing to show that there is a problem
than hiding the problem away. Because once you start hiding things, the code will grow
more and more like the "Leaning
Tower of Pisa" and sooner or later it will become unstable and you don't even
know why.
> When the "local authority" acknowledges
all merging request through own
> knowledge, it take on self all responsibility from developers for applied
> or rejected code
We (the dev team - or apparently the so called "local authority") try our best
to keep the project in good health and
running. We all do this in our spare time, out of passion and totally for free.
Are we perfect? No.
Do we make mistakes? Absolutely.
We can't please all, we do our best effort. We try to listen to all people and when we
have to make a choice, we try to
do it in the interest of the project and its community. Because a project without a
community is a dead project.
We don't mind hearing constructive criticism, but gratuitous attacks when a patch is
not accepted is not going to
achieve anything.
Cheers
Michele
10:04 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Pjatnyca 22 Lystopad 7532 18:01:32 deloptes via tde-users wrote:
OK, how many sense in holding all previous binary and source packages? :)
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!
:)
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.
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(a)oscada.org, tel:+380679859815
Kamjanske, 51939, Ukraine
Roman Savochenko via tde-users wrote:
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!
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? 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. 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? 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? :) 
11:33 p.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
Roman Savochenko via tde-users wrote:
There are a lot of patches (PRs) in the queue there. No one complains,
except you. It is your free choice. I personally see it as symbiosis. And
at some point of time someone picks up the patch works it out and it either
accepted or rejected.
OK, how many sense in holding all previous binary and source packages? :)
Zero sense, because it is not a library/archive. It is working distro. Space
costs and it makes not sense to keep olds stuff for distros that are out of
support. Feel free to create a library/archive and pay for it. No one will
object. I see now in EU storage costs for 5TB are 12,97/month ... so about
78€/y. If it is important for you, you can provide for it.
AFAIK TDE is improving in the years and I know because I follow TGW,
contribute and read the many changes (when time allows). There are some
really good developers that joint in the past few years ... that contribute
constantly ... and have very high quality contributions ... not like me :)
I guess you describe here evolution. Sometimes evolution also makes
mistakes, but it tends to correct them over time. I personally had
conversations (chats and mails) with the "local authority" and understood
how they think and operate. I have very positive view of them ... they are
indeed acting as authority, because they are indeed the authority over TDE,
but they are cooperative and as far as you are also cooperative, it works
just fine. I am writing you this, to encourage you and the rest to
cooperate, because so it benefits the whole community.
And I choose to cooperate and saw my patches go into TDE (one of the first
patches is benefitting you too, because it solved UTF-8 in kalendar and
kontact and may be other applications)
I and I guess the rest have also no problems with your fork and patches. The
problem is with the attitude published in the news group, where everybody
can read it and in fact is factually not true. This is why I am writing to
you. Remember - the whole world reads this!
Well ... so you have a clone/fork of TDE which you commit to maintain
yourself. Why bother TDE?
KDE3 is not TDE ... the KDE3 team had it's own issues. I do not think you
can compare both. I mean you can compare if you wish of course, but it is
not right as these are two different things.
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.
I have done some calculations and it does not pay off to keep old hardware.
The productivity of CPUs is so low for the power consumption that it
obsoletes itself immediately. I had two Acrosser (i386) devices from 2007
with 256MB (yes MB) memory and 300MHz CPU. I had to compile the kernel
myself, because of a combination of available but not active drivers. It
was a pain. After one of them got broken (I guess the electronics for the
CF-IDE controller gave up) I bought a replacement (x86_64) with 4GB memory
a decent CPU and the almost same power consumption. Now I do not have to
compile the kernel anymore. It works like a charm.
This is called evolution. At some point of time things have to be replaced.
If I were you I would keep a repository of those old distros (also a
repository of the distro itself). I have local repositories, but I tend to
update to latest whenever possible.
Again, I write this as invitation to cooperate. It benefits everybody.
BR
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. 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! :)
Well ... everybody has the right of it's own opinion, even if it is wrong.
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? :) 
24 Nov
24 Nov
2:53 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Sunday 24 of November 2024 00:33:52 deloptes via tde-users wrote:
There were situations where thorough research clearly showed that the
proposed patch did not solve the cause of the problem, but one specific
consequence - only hides the real cause of the problem. While the other
potential consequences would remain unresolved and would probably wait for
the next hack, which would again solve the individual consequences, not
the cause. While the author fundamentally refused any cooperation in
finding a real cause. As a result, real repairs of the causes of the
problems were merged instead of the proposed hack.
Such an approach has caused that for all other patches from such an author
now "local authority" must assume that this is again a hack. And because
of the knowledge of the fundamental unwillingness to cooperate, "local
authorities", of course, have little motivation to devote time and effort
to these patches. So yes, such patches have been waiting for a long time.
It is not surprising that "local authorities" prefer to pay attention to
the authors who repeatedly give good contributions and cooperate very
well. Such cooperation allows the project a good move forward. And we
thank all such contributors! Thanks to good contributions and good
cooperation, some have already become part of the Core team.
Cheers
Slávek
--
I write
nothing to TGW right now since there lie tens my previous
patches!
There are a lot of patches (PRs) in the queue there. No one complains,
except you. It is your free choice. I personally see it as symbiosis.
And at some point of time someone picks up the patch works it out and it
either accepted or rejected.
6:04 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
вс, 24 нояб. 2024 г., 05:54 Slávek Banko via tde-users <
users(a)trinitydesktop.org>gt;:
On Sunday 24 of November 2024 00:33:52 deloptes via
tde-users wrote:
There were situations where thorough research clearly showed that the
proposed patch did not solve the cause of the problem, but one specific
consequence - only hides the real cause of the problem. While the other
potential consequences would remain unresolved and would probably wait for
the next hack, which would again solve the individual consequences, not
the cause. While the author fundamentally refused any cooperation in
finding a real cause. As a result, real repairs of the causes of the
problems were merged instead of the proposed hack.
To be honest I (as non-developer who somewhat forced to be) tend to see
things more from "forever novice" perspective: TDE is big codebase, and
assuming someone can jump right in and prepare professional quality
solution you simply can merge ... is a bit unrealistic?
yes, people might be uncomfortable to extreme if you ask them to do
professional analysis even without telling them *how* it done (assuming
here they, like you, know it by heart).
I guess it hurts both ways .....
Also, while we all hope to be able to do new things, learn etc - sad truth
is there definitely might be ceiling in how deep you understand something.
If you have all the time in the world (like me, being invalid) you of
course can try again and again and gain some better insight from different
angle (like reading history of objective-c as used by NeXT machines long
ago) but many people have much less time ...
I even tend to guess that all this labor division gone a bit too far lately
- people assume someone else will do all teaching/training/mentoring etc .
Too bad number of those 'someone else' does not grow magically ...
Moreover, I tend to think that exactly fact most developers chasing new,
trendy and powerful is not a feature, all things considered. Too much
initial (?) "move fast and break things" become unquestioned norm. So,
yeah, totally aligned with capitalism's goals of extracting just a bit more
of this sweet surplus value from selling slightly repainted thing again
and again in faster and faster loop ... leaving "boring" past codebase
behind, ever chasing its own tail.
So, on this sense of course TDE is welcomed divergence from mainstream. But
we surely all humans and thus have various hidden assumptions and ingrained
habits. May be reflecting on them periodically is good idea, even if it
cuts time from coding.
I write
nothing to TGW right now since there lie tens my previous
patches!
There are a lot of patches (PRs) in the queue there. No one complains,
except you. It is your free choice. I personally see it as symbiosis.
And at some point of time someone picks up the patch works it out and it
either accepted or rejected. Such an approach has caused that for all other patches
from such an author
now "local authority" must assume that this is again a hack. And because
of the knowledge of the fundamental unwillingness to cooperate, "local
authorities", of course, have little motivation to devote time and effort
to these patches. So yes, such patches have been waiting for a long time.
It is not surprising that "local authorities" prefer to pay attention to
the authors who repeatedly give good contributions and cooperate very
well. Such cooperation allows the project a good move forward. And we
thank all such contributors! Thanks to good contributions and good
cooperation, some have already become part of the Core team.
Cheers
Slávek
--
____________________________________________________
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…
9:07 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Sunday 24 of November 2024 07:04:02 Andrew Randrianasulu via tde-users
wrote:
вс, 24 нояб. 2024 г., 05:54 Slávek Banko via tde-users
<
users(a)trinitydesktop.org>gt;:
Yes, it is a large volume of code and it can be difficult to get a thorough
overview. But yes, even without obtaining a thorough overview, someone can
do a good finding of a specific bug and prepare a good fix. For example,
thanks to backtrace from the grash. And there is no problem to accept and
merge a good patch from anyone.
Likewise, there is no problem, if someone suggests a patch, we give him
comments that there is a need for some modifications and thanks to the
mutual cooperation between the author and the revising after a while we
move to a good patch, which we then like to merge. This is then beneficial
for both sides - the author gets feedback and will gain better overview
and experience, the project will gain repair and improvements.
However, when someone gives a patch that, for example, removes a line with
a call to release memory, at first glance it looks like an incorrect
solution. When the author on the comment: "This looks like this will
require a more thorough examination to solve the real cause of the
problem," he responds by calling: "No, it works for me, I will not do
anything else! You have to merge it as I did it!”, that's a problem. When,
after some time and thorough examination, it confirms that the problem was
elsewhere and the solution was different, but the author still shouts: "My
fix was correct! You should have merge it as I did it!", this is indeed a
problem to try to cooperate with such an author.
Cheers
Slávek
--
On Sunday 24 of November 2024 00:33:52 deloptes
via tde-users wrote:
There were situations where thorough research clearly showed that the
proposed patch did not solve the cause of the problem, but one
specific consequence - only hides the real cause of the problem. While
the other potential consequences would remain unresolved and would
probably wait for the next hack, which would again solve the
individual consequences, not the cause. While the author fundamentally
refused any cooperation in finding a real cause. As a result, real
repairs of the causes of the problems were merged instead of the
proposed hack.
To be honest I (as non-developer who somewhat forced to be) tend to see
things more from "forever novice" perspective: TDE is big codebase, and
assuming someone can jump right in and prepare professional quality
solution you simply can merge ... is a bit unrealistic?
yes, people might be uncomfortable to extreme if you ask them to do
professional analysis even without telling them *how* it done (assuming
here they, like you, know it by heart).
I guess it hurts both ways .....
I write
nothing to TGW right now since there lie tens my previous
patches!
There are a lot of patches (PRs) in the queue there. No one
complains, except you. It is your free choice. I personally see it
as symbiosis. And at some point of time someone picks up the patch
works it out and it either accepted or rejected.
9:50 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Nedila 24 Lystopad 7532 11:07:31 Slávek Banko via tde-users wrote:
However, when someone gives a patch that, for example,
removes a line with
a call to release memory,
And when "the root knowledger" is known nothing about zombie processes-threads
which are the ones,
who hold the memory, and when they are missing, that is about the memory releasing by the
thread at
such thread options, so waiting is spare here? :)
And this I was seen obviously, since I am using that constantly, and I see that constantly
on
hundred threads and I'll fix that when I see such here in next merge request —
theoretischer! :)
And what are you freezing in whole when even at the memory leaks here, most users will not
see that
at even ten sessions, when constant crashing must you restarting the system constantly?
:)
Tell us also about bad using "goto" from other "local authority"! :)
--
Roman Savochenko
OpenSCADA (http://oscada.org), author and main developer
roman(a)oscada.org, tel:+380679859815
Kamjanske, 51939, Ukraine
10:20 a.m.
New subject: LET'S STOP FOR GOOD -- [Re: Trying to install TDE on a (relatively) old Debian (9.13)]
@TDE team, contributors, users, whoever: let this be the last email on the subject, it
doesn't do any good to continue
arguing on this ML.
@Roman: you decided to go your own way with your own TDE fork/maintenance. Fine, no one is
telling you how and what you
should do. But please stop harassing the project, the devs, the users, the ML, TGW,
anything. You are not helping the
project nor the community and you are basically making a fool of yourself. For someone who
develops and maintains an
opensource project like openscada, you should really know better. This has nothing to do
with TDE, it's about human
behavior and etiquette.
I invite everyone not to reply any more on the subject.
Roman, if you keep harassing this ML, we will consider putting you under moderation from
now on.
Cheers
Michele
10:44 a.m.
New subject: LET'S STOP FOR GOOD -- [Re: Trying to install TDE on a (relatively) old Debian (9.13)]
On Nedila 24 Lystopad 7532 12:20:00 Michele Calgaro via tde-users wrote:
@Roman: you decided to go your own way with your own
TDE fork/maintenance.
Again! I was forced to create the my partial fork after my critical for me patches became
ignored by
YOUR, that I did not choose that!
You are not helping the project nor the community and
you are basically making a
fool of yourself.
And after that you even want to shut up me, making your fool?
For someone who develops and maintains an opensource
project like openscada, you should really know better.
I know and you not. :)
This has nothing to do with TDE, it's about human
behavior and etiquette.
So that is you, who started spoiling the behavior!
Roman, if you keep harassing this ML, we will consider
putting you under
moderation from now on.
You are moderating me far ago, so continue! :)
--
Roman Savochenko
OpenSCADA (http://oscada.org), author and main developer
roman(a)oscada.org, tel:+380679859815
Kamjanske, 51939, Ukraine
11:14 a.m.
New subject: LET'S STOP FOR GOOD -- [Re: Trying to install TDE on a (relatively) old Debian (9.13)]
@Roman:
As perfectly expected (see [1]) you have just made yourself a moderated member of this
ML.
All your future emails will be filtered and only approved if they are of any benefit to
the project or community.
Go, be proud of yourself and your behavior, celebrate! :-)
Cheers
Michele
[1] https://qz.com/967554/the-five-universal-laws-of-human-stupidity
or just google for Carlo Cipolla's Laws of Stupididy
7:50 a.m.
New subject: Trying to install TDE on a (relatively) old Debian (9.13)
On Nedila 24 Lystopad 7532 01:33:52 deloptes via tde-users wrote:
I guess you describe here evolution. Sometimes evolution also makes
mistakes, but it tends to correct them over time.
REvolution, due to many code were just changed in renaming the symbols, and Evolution is
about "the
using stabilisation of the mature code".
And I choose to cooperate and saw my patches go into TDE (one of the first
patches is benefitting you too, because it solved UTF-8 in kalendar and
kontact and may be other applications)
I have cooperated also before "the local authority" "climbs on
heavens" and start to think
they "know roots" and me is just stupid with fixing their saint breakages. :)
I and I guess the rest have also no problems with your fork and patches.
The problem is with the attitude published in the news group, where
everybody can read it and in fact is factually not true. This is why I am
writing to you. Remember - the whole world reads this!
And that is VERY GOOD, as I said you also!
Well ... so you have a clone/fork of TDE which you commit to maintain
yourself. Why bother TDE?
And that is not me say about to write in TGW! :)
KDE3 is not TDE ... the KDE3 team had it's own issues. I do not think you
can compare both. I mean you can compare if you wish of course, but it is
not right as these are two different things.
Ooo I can already compare, since the patchset achieves the original KDE3 in ALTLinux. :)
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.
I have done some calculations and it does not pay off to keep old hardware.
The productivity of CPUs is so low for the power consumption that it
obsoletes itself immediately. I had two Acrosser (i386) devices from 2007
with 256MB (yes MB) memory and 300MHz CPU.
256MB is enough for many old HW and KDE3 here, and I have two such ones: K6-2/600 and
P3/700 from
2000 years and which fine works right now.
There are a lot of patches (PRs) in the queue there.
No one complains,
except you. It is your free choice. I personally see it as symbiosis. And
at some point of time someone picks up the patch works it out and it either
accepted or rejected.
And I was forced to create the my partial fork after my critical for me patches became
ignored, that
I did not choose that!
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. I personally had
conversations (chats and mails) with the "local authority" and understood
how they think and operate. I have very positive view of them ... they are
indeed acting as authority, because they are indeed the authority over TDE,
but they are cooperative and as far as you are also cooperative, it works
just fine. I am writing you this, to encourage you and the rest to
cooperate, because so it benefits the whole community.
There is no benefits in symbols renaming also as no benefits in cmake in comparing
Autotools!
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. I had to compile the kernel
myself, because of a combination of available but not active drivers. It
was a pain. After one of them got broken (I guess the electronics for the
CF-IDE controller gave up) I bought a replacement (x86_64) with 4GB memory
a decent CPU and the almost same power consumption. Now I do not have to
compile the kernel anymore. It works like a charm.
This is called evolution. At some point of time things have to be replaced.
And I just use Debian 7 with 486 kernel and TDE 14.0.10 with all my actual patchset, and
don't say
about "evolution fouling", when we soon will be completely in the trash,
who'll survive of course
after the jeviary (jewish-aries) action in utilization the population and replacing us by
AI-robots. :)
If I were you I would keep a repository of those old
distros (also a
repository of the distro itself). I have local repositories, but I tend to
update to latest whenever possible.
Again, I write this as invitation to cooperate. It benefits everybody.
Maybe, due to I am already patching in fact all used packages by me, and in fact 14.0.10
is that
repository. :)
--
Roman Savochenko
OpenSCADA (http://oscada.org), author and main developer
roman(a)oscada.org, tel:+380679859815
Kamjanske, 51939, Ukraine
28
days inactive
34
days old
31 comments
6 participants
participants (6)
-
Andrew Randrianasulu -
deloptes -
Dr. Nikolaus Klepp -
Michele Calgaro -
Roman Savochenko -
Slávek Banko