in my seemingly never-ending attempt to equip the GPD device with TDE and optimize its configuration, i'm trying to set the screen not to just blank but to power down when the screensaver is called. but when i get to kcontrol > system administration > monitor & display, i get:
Will not save configuration
Configuration file "/home/dep/trinity/share/config/kiccconfigrc" not writeable.
Please contsact your system administrator.
So I got up and walked into the other room, where there is a mirror, and contacted myself face-to-face, but it got no better. And looking in the referenced directory I see that it, alone among the config files there, has root ownership and instead of the plain text file icon has one of the little question-mark icons signifying an unknown filetype. if i try to open it with kate, it is blank. it is *not* a symlink.
before i break smething i thought i'd ask -- is there any reason this file has these atributes?
dep
Sent withProtonMailSecure Email. Because privacy matters.
On Sun July 1 2018 16:16:01 dep wrote:
in my seemingly never-ending attempt to equip the GPD device with TDE and optimize its configuration, i'm trying to set the screen not to just blank but to power down when the screensaver is called. but when i get to kcontrol > system administration > monitor & display, i get:
Will not save configuration
Configuration file "/home/dep/trinity/share/config/kiccconfigrc" not writeable.
Please contsact your system administrator.
So I got up and walked into the other room, where there is a mirror, and contacted myself face-to-face, but it got no better. And looking in the referenced directory I see that it, alone among the config files there, has root ownership and instead of the plain text file icon has one of the little question-mark icons signifying an unknown filetype. if i try to open it with kate, it is blank. it is *not* a symlink.
before i break smething i thought i'd ask -- is there any reason this file has these atributes?
Hi Dep,
FWIW I just tried that here and what I saw was different.
(1) Possible typo but I have a dot before trinity in that path you cite.
(2) Upon clicking Monitor & Display I was prompted for a root password. (I usually get to these controls from RandR / Configure Displays / Admin Mode which also requires a root password).
(3) I made some changes and they affected three files: twinrulesrc tdesurc kdeglobals
(4) I checked all the systems I maintain. None had a kiccconfigrc. They're currently a mix of Devuan 1.0 and Devuan 2.0 and they're at TDE 14.0.5 as I haven't started testing today's new version yet.
(5) Again, on all of the systems I maintain, both /home/*/.trinity/share/config/ and all the files therein are owned by the relevant user's owner and group.
At a guess you at sometime in the past logged into TDE (or a predecessor) as root. I see no reason not to fix the ownership of that file. I don't currently have a GIT of TDE handy so I can't figure out why you might have a kiccconfigrc while I don't but I wouldn't worry about that. Maybe my test didn't touch the exact area you're working with. Also I don't understand why you were not prompted for a root password.
--Mike
On Sunday 01 July 2018 16:41:26 Mike Bird wrote:
On Sun July 1 2018 16:16:01 dep wrote:
in my seemingly never-ending attempt to equip the GPD device with TDE and optimize its configuration, i'm trying to set the screen not to just blank but to power down when the screensaver is called. but when i get to kcontrol > system administration > monitor & display, i get:
Will not save configuration
Configuration file "/home/dep/trinity/share/config/kiccconfigrc" not writeable.
Please contsact your system administrator.
So I got up and walked into the other room, where there is a mirror, and contacted myself face-to-face, but it got no better. And looking in the referenced directory I see that it, alone among the config files there, has root ownership and instead of the plain text file icon has one of the little question-mark icons signifying an unknown filetype. if i try to open it with kate, it is blank. it is *not* a symlink.
before i break smething i thought i'd ask -- is there any reason this file has these atributes?
Hi Dep,
FWIW I just tried that here and what I saw was different.
(1) Possible typo but I have a dot before trinity in that path you cite.
(2) Upon clicking Monitor & Display I was prompted for a root password. (I usually get to these controls from RandR / Configure Displays / Admin Mode which also requires a root password).
(3) I made some changes and they affected three files: twinrulesrc tdesurc kdeglobals
(4) I checked all the systems I maintain. None had a kiccconfigrc. They're currently a mix of Devuan 1.0 and Devuan 2.0 and they're at TDE 14.0.5 as I haven't started testing today's new version yet.
(5) Again, on all of the systems I maintain, both /home/*/.trinity/share/config/ and all the files therein are owned by the relevant user's owner and group.
At a guess you at sometime in the past logged into TDE (or a predecessor) as root. I see no reason not to fix the ownership of that file. I don't currently have a GIT of TDE handy so I can't figure out why you might have a kiccconfigrc while I don't but I wouldn't worry about that. Maybe my test didn't touch the exact area you're working with. Also I don't understand why you were not prompted for a root password.
--Mike
My guess is that the permissions on that folder got changed somehow. I sometimes see that when I am trying to save a text file where I've made changes. (Also, I think that Mike is probably right about that little missing dot, as that indicates hidden files inside your folder in a Linux system. In your top menu, click on "show hidden files" and "hide hidden files", and you will see how they appear and disappear. In Linux every little dot and space counts.)
As Mike points out, maybe you logged in as root; perhaps you opened konqueror or other file manager as root?
Some command-line may work the magic you want. [Change ~ to your username!] chmod -R 700 /home/~/.trinity | chown -R ~/home/~/.trinity | chgrp -R ~ /home/~/.trinity and/or chmod -R 700 /home/~/.trinity/* | chown -R ~/home/~/.trinity/* | chgrp -R ~ /home/~/.trinity/* (This give rwx permissions to user only, dep or whatever you call your username.)
If this doesn't work, try: chmod -R 770 /home/~/.trinity | chown -R ~/home/~/.trinity | chgrp -R ~ /home/~/.trinity and/or chmod -R 770 /home/~/.trinity/* | chown -R ~/home/~/.trinity/* | chgrp -R ~ /home/~/.trinity/* (This will give rwx permissions to user and group, both the same as your username; some processes may operate under your group name, not as user.)
NOTE WELL that I am using ~ to represent your top-secret username (which it is better that you don't publish online, of course); the /* in this case represents everything inside that folder, so I need the asterisk for that. (I don't give out my own username to anybody, although I feel sure that all the 3-letter government agencies have got it by now.)
If this doesn't solve your problems, then you might have some deeper issues. In the past, when I had similar experiences, I used to just reinstall my system; but nowadays I try to avoid doing that when possible.
Bill
chmod -R 770 /home/~/.trinity | chown -R ~/home/~/.trinity | chgrp -R ~ /home/~/.trinity and/or chmod -R 770 /home/~/.trinity/* | chown -R ~/home/~/.trinity/* | chgrp -R ~ /home/~/.trinity/*
**** DO NOT DO THIS ^^^ ****
This would wreck many permissions that should not be 770.
--Mike
On Sun July 1 2018 17:54:14 Mike Bird wrote:
chmod -R 770 /home/~/.trinity | chown -R ~/home/~/.trinity | chgrp -R ~ /home/~/.trinity and/or chmod -R 770 /home/~/.trinity/* | chown -R ~/home/~/.trinity/* | chgrp -R ~ /home/~/.trinity/*
**** DO NOT DO THIS ^^^ ****
This would wreck many permissions that should not be 770.
I wanted to get that warning out quickly. Now I have time for some explanation.
(1) My good ~/.trinity has precisely 0 files with 770 permission. Don't wreck yours. Another suggestion was made for 700 permission. Well my ~/.trinity does have 951 files with 700 permission but they're still the minority. For example I have 2049 files with 600 permission.
DON'T MASS-BORK YOUR PERMISSIONS. UNLESS YOU CAN RESTORE FROM A BACKUP, RECOVERY COULD TAKE DAYS OF WORK.
(2) Commands such as those above should not be linked by pipe "|". They should be linked by semicolon ";" or in some cases ampersand "&".
When commands are linked by pipe the output of one is fed as the input to the next. Even if the next ignores the unwanted input this can still cause problems. Consider "ls | ls". If the second ls finishes before the first the pipe breaks and the first ls is prematurely terminated. If that first ls was instead a command changing every file in your ~/.trinity it would be killed at an arbitrary point in the proceedings instead of completing its job.
So what should you do instead of borking your ~/.trinity?
find ~/.trinity -not -user U -o -not -group G -exec ls -dl {} ;
Replace U with your user and G with your group in the above.
If the resulting files look like they should belong to you then you can:
chown -R U:G ~/.trinity
--Mike
On Sunday 01 July 2018 18:10:12 Mike Bird wrote:
On Sun July 1 2018 17:54:14 Mike Bird wrote:
chmod -R 770 /home/~/.trinity | chown -R ~/home/~/.trinity | chgrp -R ~ /home/~/.trinity and/or chmod -R 770 /home/~/.trinity/* | chown -R ~/home/~/.trinity/* | chgrp -R ~ /home/~/.trinity/*
**** DO NOT DO THIS ^^^ ****
This would wreck many permissions that should not be 770.
I wanted to get that warning out quickly. Now I have time for some explanation.
(1) My good ~/.trinity has precisely 0 files with 770 permission. Don't wreck yours. Another suggestion was made for 700 permission. Well my ~/.trinity does have 951 files with 700 permission but they're still the minority. For example I have 2049 files with 600 permission.
DON'T MASS-BORK YOUR PERMISSIONS. UNLESS YOU CAN RESTORE FROM A BACKUP, RECOVERY COULD TAKE DAYS OF WORK.(2) Commands such as those above should not be linked by pipe "|". They should be linked by semicolon ";" or in some cases ampersand "&".
When commands are linked by pipe the output of one is fed as the input to the next. Even if the next ignores the unwanted input this can still cause problems. Consider "ls | ls". If the second ls finishes before the first the pipe breaks and the first ls is prematurely terminated. If that first ls was instead a command changing every file in your ~/.trinity it would be killed at an arbitrary point in the proceedings instead of completing its job.So what should you do instead of borking your ~/.trinity?
find ~/.trinity -not -user U -o -not -group G -exec ls -dl {} ;
Replace U with your user and G with your group in the above.
If the resulting files look like they should belong to you then you can:
chown -R U:G ~/.trinity
--Mike
I have not had those problems, but thanks for clarifying my own question: how to change the permissions of files inside a folder to 600 only (rw for user), but 700 for the folder (because rwx is necessary to enter the folder).
Bill
On Sun July 1 2018 18:34:23 William Morder wrote:
I have not had those problems, but thanks for clarifying my own question: how to change the permissions of files inside a folder to 600 only (rw for user), but 700 for the folder (because rwx is necessary to enter the folder).
You'd need a more complicated command than "chmod -R" to do that right because you'd need to consider any subfolders. The "find" command can do it but I don't want to post dangerous commands here which might be used in the wrong circumstances. Anyone who needs to try this can "man find" and figure out exactly what is needed in their particular situation.
--Mike
On Sunday 01 July 2018 18:41:16 Mike Bird wrote:
On Sun July 1 2018 18:34:23 William Morder wrote:
I have not had those problems, but thanks for clarifying my own question: how to change the permissions of files inside a folder to 600 only (rw for user), but 700 for the folder (because rwx is necessary to enter the folder).
You'd need a more complicated command than "chmod -R" to do that right because you'd need to consider any subfolders.
Right, there's my problem. When I set everything for 600 permissions, I end up with folders that I can't open; when I set it for 700, I end up with rwx permissions on files where I don't want that.
Will do some research on this.
The "find" command can do it but I don't want to post dangerous commands here which might be used in the wrong circumstances. Anyone who needs to try this can "man find" and figure out exactly what is needed in their particular situation.
--Mike
Always willing myself to defer to other people's knowledge and expertise; I am not afraid of dangerous commands, however, but no doubt you are right about letting them get out there in the wild.
Also, I take it as a given that EVERYTHING ought to be backed up before attempting any experiments, or explorations of the unknown parts of your system. If readers didn't hear me say that before, consider it said now.
I've messed up my machines more times than I can count, but I always had backups before trying anything new.
Bill
On Sun July 1 2018 18:10:12 Mike Bird wrote:
(2) Commands such as those above should not be linked by pipe "|". They should be linked by semicolon ";" or in some cases ampersand "&".
Slightly OT correction FWIW: that should read double ampersand "&&".
--Mike
On 2018-07-01 19:35:46 William Morder wrote:
Some command-line may work the magic you want. [Change ~ to your username!] chmod -R 700 /home/~/.trinity | chown -R ~/home/~/.trinity | chgrp -R ~ /home/~/.trinity and/or chmod -R 700 /home/~/.trinity/* | chown -R ~/home/~/.trinity/* | chgrp -R ~ /home/~/.trinity/* (This give rwx permissions to user only, dep or whatever you call your username.)
If this doesn't work, try: chmod -R 770 /home/~/.trinity | chown -R ~/home/~/.trinity | chgrp -R ~ /home/~/.trinity and/or chmod -R 770 /home/~/.trinity/* | chown -R ~/home/~/.trinity/* | chgrp -R ~ /home/~/.trinity/* (This will give rwx permissions to user and group, both the same as your username; some processes may operate under your group name, not as user.)
NOTE WELL that I am using ~ to represent your top-secret username (which it is better that you don't publish online, of course); the /* in this case represents everything inside that folder, so I need the asterisk for that. (I don't give out my own username to anybody, although I feel sure that all the 3-letter government agencies have got it by now.)
If this doesn't solve your problems, then you might have some deeper issues. In the past, when I had similar experiences, I used to just reinstall my system; but nowadays I try to avoid doing that when possible.
Bill
Since this is an ownership issue, not a privileges issue, one should use
| chown <user>:<group> <filepath>
to fix the ownership instead of changing the access privileges.
Leslie
On July 1, 2018 7:41 PM, Mike Bird mgb-trinity@yosemite.net wrote:
FWIW I just tried that here and what I saw was different.
(1) Possible typo but I have a dot before trinity in that path you cite.
yup, was indeed a typo.
(2) Upon clicking Monitor & Display I was prompted for a root password.
(I usually get to these controls from RandR / Configure Displays / Admin Mode
which also requires a root password).
as does mine, now that i have set a root password. for some reason distributions discourage the creation of a root password -- i cannot imagine how it enhances security, except that it might discourage morons from logging in as root all the time -- and then applications demand a password that doesn't exist. in the error i encountered, if i clicked past it there was later the opportunity to enter administrator mode with (if memory serves) the user password. (how any of this is an improvement over plain old su escapes me, but i didn't write it and my opinion wasn't solicited).
though michael's script is actually a more elegant solution imho to the issue i was tryingt to address. and i was mostly puzzled by the permissions on this single configuration file -- seemed kind of odd.
(3) I made some changes and they affected three files:
twinrulesrc
tdesurc
kdeglobals
once i saw it i realized i was familiar with that configuration screen and remembered that many things one does there can break stuff in an especially inconvenient way -- so i am happy to know which files to squirrel away some place in case i ever go experimenting with it again.
(4) I checked all the systems I maintain. None had a kiccconfigrc. They're
currently a mix of Devuan 1.0 and Devuan 2.0 and they're at TDE 14.0.5 as
I haven't started testing today's new version yet.
apparently it isn't as big a deal as it seemed. but thanks to the maintainers, anyway. i hadn't heard of the file before, either. one of the things on the todo list was rename it, log out, log back in, and see if a.) it made and difference and b.) if a new one got generated and if so what its permissions were. (fortunately, alt-ctrl-f1 on the gpd gives us a nice normal text screen, unlike the gemini which is, yes, weird. (and part of the reason i'm about to dclare linux on the gemini a noble but ultimately useless exercise and switch it all over to sailfish.)
(5) Again, on all of the systems I maintain,
both /home/*/.trinity/share/config/ and all the files therein are owned
by the relevant user's owner and group.
At a guess you at sometime in the past logged into TDE (or a predecessor)
as root. I see no reason not to fix the ownership of that file. I don't
currently have a GIT of TDE handy so I can't figure out why you might have
a kiccconfigrc while I don't but I wouldn't worry about that. Maybe my test
didn't touch the exact area you're working with. Also I don't understand
why you were not prompted for a root password.
now this *is* a puzzle, the only thing i can think of is a couple of scripts that one runs, if one is not foolhardy, on the gpd after any significant upgrade (desktop, kernel) to protect the device from any waywardness the upgrade might have introduced. they're done by the guy who has tuned various linuces for the gpd, and a good job he has done, too:
https://github.com/stockmind/gpd-pocket-ubuntu-respin
because none of the various iso images have trinity as the desktop, they're configured to be especially hospitable to unity; there is a "kde" switch that can be applied, but surely that is aimed at the wants and desires of current kde. i have not seen the switch making any difference with TDE.
and that having been said, i hope you get this before the snows of winter -- protonmail has been under a really orchestrated dds attack for a couple of days now, so the mail is in fits and starts, and in the lulls i ponder happily the punishments one wishes on the perpetrators . . . and conclude that while nothing available in this life would suffice, use of a baseball bat as a dental instrument would be a nice preview.
dep
Sent withProtonMailSecure Email. Because privacy matters.
On Monday 02 July 2018 09:08:21 dep wrote:
On July 1, 2018 7:41 PM, Mike Bird mgb-trinity@yosemite.net wrote:
FWIW I just tried that here and what I saw was different.
(1) Possible typo but I have a dot before trinity in that path you cite.
yup, was indeed a typo.
(2) Upon clicking Monitor & Display I was prompted for a root password.
(I usually get to these controls from RandR / Configure Displays / Admin Mode
which also requires a root password).
as does mine, now that i have set a root password. for some reason distributions discourage the creation of a root password -- i cannot imagine how it enhances security, except that it might discourage morons from logging in as root all the time -- and then applications demand a password that doesn't exist. in the error i encountered, if i clicked past it there was later the opportunity to enter administrator mode with (if memory serves) the user password. (how any of this is an improvement over plain old su escapes me, but i didn't write it and my opinion wasn't solicited).
though michael's script is actually a more elegant solution imho to the issue i was tryingt to address. and i was mostly puzzled by the permissions on this single configuration file -- seemed kind of odd.
(3) I made some changes and they affected three files:
twinrulesrc
tdesurc
kdeglobals
once i saw it i realized i was familiar with that configuration screen and remembered that many things one does there can break stuff in an especially inconvenient way -- so i am happy to know which files to squirrel away some place in case i ever go experimenting with it again.
(4) I checked all the systems I maintain. None had a kiccconfigrc. They're
currently a mix of Devuan 1.0 and Devuan 2.0 and they're at TDE 14.0.5 as
I haven't started testing today's new version yet.
apparently it isn't as big a deal as it seemed. but thanks to the maintainers, anyway. i hadn't heard of the file before, either. one of the things on the todo list was rename it, log out, log back in, and see if a.) it made and difference and b.) if a new one got generated and if so what its permissions were. (fortunately, alt-ctrl-f1 on the gpd gives us a nice normal text screen, unlike the gemini which is, yes, weird. (and part of the reason i'm about to dclare linux on the gemini a noble but ultimately useless exercise and switch it all over to sailfish.)
(5) Again, on all of the systems I maintain,
both /home/*/.trinity/share/config/ and all the files therein are owned
by the relevant user's owner and group.
At a guess you at sometime in the past logged into TDE (or a predecessor)
as root. I see no reason not to fix the ownership of that file. I don't
currently have a GIT of TDE handy so I can't figure out why you might have
a kiccconfigrc while I don't but I wouldn't worry about that. Maybe my test
didn't touch the exact area you're working with. Also I don't understand
why you were not prompted for a root password.
now this *is* a puzzle, the only thing i can think of is a couple of scripts that one runs, if one is not foolhardy, on the gpd after any significant upgrade (desktop, kernel) to protect the device from any waywardness the upgrade might have introduced. they're done by the guy who has tuned various linuces for the gpd, and a good job he has done, too:
https://github.com/stockmind/gpd-pocket-ubuntu-respin
because none of the various iso images have trinity as the desktop, they're configured to be especially hospitable to unity; there is a "kde" switch that can be applied, but surely that is aimed at the wants and desires of current kde. i have not seen the switch making any difference with TDE.
and that having been said, i hope you get this before the snows of winter -- protonmail has been under a really orchestrated dds attack for a couple of days now, so the mail is in fits and starts, and in the lulls i ponder happily the punishments one wishes on the perpetrators . . . and conclude that while nothing available in this life would suffice, use of a baseball bat as a dental instrument would be a nice preview.
dep
I used to keep a folder (on a flash drive), with all my specially-tweaked config files, etc.; all those things that end in -rc, as well as a lot of the files that you find in /etc/ - although I have still to match up all the old KDE3 config files to their TDE counterparts, as they live in different places (which doesn't always seem consistent), or they don't even have the same extensions. So I can't always solve the problem by changing kde to tde, or by copying the file to its new location.
This is what I would *like* to do, but it's still somewhat a work-in-progress on my current machines that are running Devuan Jessie with TDE. As I mentioned to Gene, however, it is *almost* THERE, but not quite.
When I get my stuff together, I will try to make a list of these config files, along with my quick scripts or commands for configuration. If this is of interest to anybody else, I will be glad to share.
Bill
On Sunday 01 July 2018 19:16:01 dep wrote:
/home/dep/trinity/share/config/ etc....
I have that file, its owned by me:me and is rw only for me. And contains: DVI-I-1= DefaultProfile= EnableICC=false HDMI-1= VGA-1=
No clue what could have sneezed and screwed it up, but there it is.
No clue of the effect of setting some of those options might be. And no manpage. So your guess is likely better than mine.
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote:
/home/dep/trinity/share/config/ etc....
I have that file, its owned by me:me and is rw only for me. And contains: DVI-I-1= DefaultProfile= EnableICC=false HDMI-1= VGA-1=
No clue what could have sneezed and screwed it up, but there it is.
No clue of the effect of setting some of those options might be. And no manpage. So your guess is likely better than mine.
Oh, I just found one thing that has not been fixed, I have audio during boot until tdm starts after I log in. After login, I still have to do an "alsactl restoreRETURN" before I have any sound. Can this be fixed?
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote:
/home/dep/trinity/share/config/ etc....
I have that file, its owned by me:me and is rw only for me. And contains: DVI-I-1= DefaultProfile= EnableICC=false HDMI-1= VGA-1=
No clue what could have sneezed and screwed it up, but there it is.
No clue of the effect of setting some of those options might be. And no manpage. So your guess is likely better than mine.
Oh, I just found one thing that has not been fixed, I have audio during boot until tdm starts after I log in. After login, I still have to do an "alsactl restoreRETURN" before I have any sound. Can this be fixed?
I use ALSA, and it starts when I boot up.
Have you messed with this toy? sudo sysv-rc-conf Be careful, if you haven't use that before; although I suspect that you know it. Don't make changes there unless you know what to do.
Also, look in Trinity Control Center / Sound & Multimedia / Sound System Both parts, General / Hardware ought to be examined.
Bill
On Sunday 01 July 2018 20:47:58 William Morder wrote:
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote:
/home/dep/trinity/share/config/ etc....
I have that file, its owned by me:me and is rw only for me. And contains: DVI-I-1= DefaultProfile= EnableICC=false HDMI-1= VGA-1=
No clue what could have sneezed and screwed it up, but there it is.
No clue of the effect of setting some of those options might be. And no manpage. So your guess is likely better than mine.
Oh, I just found one thing that has not been fixed, I have audio during boot until tdm starts after I log in. After login, I still have to do an "alsactl restoreRETURN" before I have any sound. Can this be fixed?
I use ALSA, and it starts when I boot up.
Have you messed with this toy? sudo sysv-rc-conf
That is not findable on this wheezy machine.
Be careful, if you haven't use that before; although I suspect that you know it. Don't make changes there unless you know what to do.
Also, look in Trinity Control Center / Sound & Multimedia / Sound System Both parts, General / Hardware ought to be examined.
Bill
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sunday 01 July 2018 18:03:13 Gene Heskett wrote:
On Sunday 01 July 2018 20:47:58 William Morder wrote:
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote:
/home/dep/trinity/share/config/ etc....
I have that file, its owned by me:me and is rw only for me. And contains: DVI-I-1= DefaultProfile= EnableICC=false HDMI-1= VGA-1=
No clue what could have sneezed and screwed it up, but there it is.
No clue of the effect of setting some of those options might be. And no manpage. So your guess is likely better than mine.
Oh, I just found one thing that has not been fixed, I have audio during boot until tdm starts after I log in. After login, I still have to do an "alsactl restoreRETURN" before I have any sound. Can this be fixed?
I use ALSA, and it starts when I boot up.
Have you messed with this toy? sudo sysv-rc-conf
That is not findable on this wheezy machine.
You should be able to get it by installing through apt:
sudo apt-get install sysv-rc-conf
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I seem to recall that you could make some of these changes through the Trinity Control Center, but sysv-rc-conf is much easier, so long as you are careful. A lot of things can slow down your machine, because they are configured to run at startup when you don't need them; while other things that you want, like your sound system, might be disabled.
Bill
Be careful, if you haven't used that before; although I suspect that you know it. Don't make changes there unless you know what to do.
Also, look in Trinity Control Center / Sound & Multimedia / Sound System Both parts, General / Hardware ought to be examined.
Bill
William Morder composed on 2018-07-01 18:48 (UTC-0700):
On Sunday 01 July 2018 18:03:13 Gene Heskett wrote:
On Sunday 01 July 2018 20:47:58 William Morder wrote:
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote:
You people who don't trim quotes of quotes of quotes of quotes ad infinitum should be reimbursing Tim for the cost of hosting this mailing list's archive.
On Sunday 01 July 2018 19:12:16 Felix Miata wrote:
William Morder composed on 2018-07-01 18:48 (UTC-0700):
On Sunday 01 July 2018 18:03:13 Gene Heskett wrote:
On Sunday 01 July 2018 20:47:58 William Morder wrote:
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote:
You people who don't trim quotes of quotes of quotes of quotes ad infinitum should be reimbursing Tim for the cost of hosting this mailing list's archive.
It's being charged to your account. We figured that you must have the most money, since you are keeping track.
Bill
On Sun July 1 2018 18:48:27 William Morder wrote:
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I'm sorry if I seem to be dogging you today Bill but I do not recommend messing with sysv-rc-conf. Debian and its major derivatives automatically enable everything that is installed and so there is no need to enable and disable services in runlevels as there is in other distros.
Nor does the runlevel change when TDE is started, and the OP said that sound was working until he starts TDE. IIRC OP did not say which sound system was working before TDE and which sound system he is using in TDE.
The most likely explanation for his problem is that they are different and that there is a problem with the sound system he is using in TDE.
Alternatively, if the before TDE sound system and during TDE sound systems are the same, the most likely explanation is a problem with the TDE configuration of that sound system.
In practice there is not much difference between these two cases. The place to look is the configuration of his current TDE sound system.
--Mike
On Sunday 01 July 2018 19:14:45 Mike Bird wrote:
On Sun July 1 2018 18:48:27 William Morder wrote:
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I'm sorry if I seem to be dogging you today Bill but I do not recommend messing with sysv-rc-conf. Debian and its major derivatives automatically enable everything that is installed and so there is no need to enable and disable services in runlevels as there is in other distros.
Nor does the runlevel change when TDE is started, and the OP said that sound was working until he starts TDE. IIRC OP did not say which sound system was working before TDE and which sound system he is using in TDE.
The most likely explanation for his problem is that they are different and that there is a problem with the sound system he is using in TDE.
Alternatively, if the before TDE sound system and during TDE sound systems are the same, the most likely explanation is a problem with the TDE configuration of that sound system.
In practice there is not much difference between these two cases. The place to look is the configuration of his current TDE sound system.
--Mike
No problem, dog away.
In any case, I need to use sysv-rc-conf for some of my own needs. Whether other people do or not, that's up to them.
Bill
On Sunday 01 July 2018 22:14:45 Mike Bird wrote:
On Sun July 1 2018 18:48:27 William Morder wrote:
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I'm sorry if I seem to be dogging you today Bill but I do not recommend messing with sysv-rc-conf. Debian and its major derivatives automatically enable everything that is installed and so there is no need to enable and disable services in runlevels as there is in other distros.
Nor does the runlevel change when TDE is started, and the OP said that sound was working until he starts TDE.
Yes, I can hear system noises before I login. Login and they become muted and firefox is silent, until I stop whatever FF is playing and issue the alsoctl restore command, which reports a can't do that, system is busy, but when I restart FF playing whatever, it then works till the next reboot.
IIRC OP did not say which sound system was working before TDE and which sound system he is using in TDE.
Alsa seems to be the tool of choice. I have had some of Leonart P's stuff installed but could not make it work w/o a lot of fiddling, so I took it back out, sometimes with rm. Apt-get seems not to be very good at cleaning up the messes it has installed.
Maybe I can't see the forest because of all the trees, but I can't see any logical reason why starting tde should mute the sound system, perhaps someone could clarify why that is so, requiring an intervention by alsactl before it works again.
The most likely explanation for his problem is that they are different and that there is a problem with the sound system he is using in TDE.
Alternatively, if the before TDE sound system and during TDE sound systems are the same, the most likely explanation is a problem with the TDE configuration of that sound system.
In practice there is not much difference between these two cases. The place to look is the configuration of his current TDE sound system.
I just did, and turned off the remote access and the timeout, we'll see at the next reboot. Usually at about 30 day intervals. 14 days uptime right now.
--Mike
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Am Montag, 2. Juli 2018 schrieb Gene Heskett:
On Sunday 01 July 2018 22:14:45 Mike Bird wrote:
On Sun July 1 2018 18:48:27 William Morder wrote:
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I'm sorry if I seem to be dogging you today Bill but I do not recommend messing with sysv-rc-conf. Debian and its major derivatives automatically enable everything that is installed and so there is no need to enable and disable services in runlevels as there is in other distros.
Nor does the runlevel change when TDE is started, and the OP said that sound was working until he starts TDE.
Yes, I can hear system noises before I login. Login and they become muted and firefox is silent, until I stop whatever FF is playing and issue the alsoctl restore command, which reports a can't do that, system is busy, but when I restart FF playing whatever, it then works till the next reboot.
IIRC OP did not say which sound system was working before TDE and which sound system he is using in TDE.
Alsa seems to be the tool of choice. I have had some of Leonart P's stuff installed but could not make it work w/o a lot of fiddling, so I took it back out, sometimes with rm. Apt-get seems not to be very good at cleaning up the messes it has installed.
Maybe I can't see the forest because of all the trees, but I can't see any logical reason why starting tde should mute the sound system, perhaps someone could clarify why that is so, requiring an intervention by alsactl before it works again.
The most likely explanation for his problem is that they are different and that there is a problem with the sound system he is using in TDE.
Alternatively, if the before TDE sound system and during TDE sound systems are the same, the most likely explanation is a problem with the TDE configuration of that sound system.
In practice there is not much difference between these two cases. The place to look is the configuration of his current TDE sound system.
I just did, and turned off the remote access and the timeout, we'll see at the next reboot. Usually at about 30 day intervals. 14 days uptime right now.
--Mike
What about adding that alsactrl-comman into .xinitrc or .xsessionrc? e.g.:
( sleep 1m; alsactrl .....) &
nik
On Monday 02 July 2018 07:27:54 Dr. Nikolaus Klepp wrote:
Am Montag, 2. Juli 2018 schrieb Gene Heskett:
On Sunday 01 July 2018 22:14:45 Mike Bird wrote:
On Sun July 1 2018 18:48:27 William Morder wrote:
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I'm sorry if I seem to be dogging you today Bill but I do not recommend messing with sysv-rc-conf. Debian and its major derivatives automatically enable everything that is installed and so there is no need to enable and disable services in runlevels as there is in other distros.
Nor does the runlevel change when TDE is started, and the OP said that sound was working until he starts TDE.
Yes, I can hear system noises before I login. Login and they become muted and firefox is silent, until I stop whatever FF is playing and issue the alsoctl restore command, which reports a can't do that, system is busy, but when I restart FF playing whatever, it then works till the next reboot.
IIRC OP did not say which sound system was working before TDE and which sound system he is using in TDE.
Alsa seems to be the tool of choice. I have had some of Leonart P's stuff installed but could not make it work w/o a lot of fiddling, so I took it back out, sometimes with rm. Apt-get seems not to be very good at cleaning up the messes it has installed.
Maybe I can't see the forest because of all the trees, but I can't see any logical reason why starting tde should mute the sound system, perhaps someone could clarify why that is so, requiring an intervention by alsactl before it works again.
The most likely explanation for his problem is that they are different and that there is a problem with the sound system he is using in TDE.
Alternatively, if the before TDE sound system and during TDE sound systems are the same, the most likely explanation is a problem with the TDE configuration of that sound system.
In practice there is not much difference between these two cases. The place to look is the configuration of his current TDE sound system.
I just did, and turned off the remote access and the timeout, we'll see at the next reboot. Usually at about 30 day intervals. 14 days uptime right now.
--Mike
What about adding that alsactrl-comman into .xinitrc or .xsessionrc? e.g.:
Haven't tried that. Doesn't work in rc.local either
( sleep 1m; alsactrl .....) &
nik
On Mon July 2 2018 03:31:56 Gene Heskett wrote:
Yes, I can hear system noises before I login. Login and they become muted and firefox is silent, until I stop whatever FF is playing and issue the alsoctl restore command, which reports a can't do that, system is busy, but when I restart FF playing whatever, it then works till the next reboot.
System sounds before login may be happening without ALSA so at the moment I'm not sure whether ALSA is working before login.
You could try speaker-test (ALSA white noise generator) to see if ALSA is working before login (or aplay if you have something playable).
Let's check that ALSA is set to start automatically. Do you have
ls -l /etc/*.d/S*alsa*
You should have a link called something like /etc/rcS.d/S16alsa-utils to /etc/init.d/alsa-utils.
--Mike
On Monday 02 July 2018 07:48:29 Mike Bird wrote:
ls -l /etc/*.d/S*alsa*
lrwxrwxrwx 1 root root 20 Oct 5 2015 /etc/rcS.d/S21alsa-utils -> ../init.d/alsa-utils
On Mon July 2 2018 05:34:50 Gene Heskett wrote:
On Monday 02 July 2018 07:48:29 Mike Bird wrote:
ls -l /etc/*.d/S*alsa*
lrwxrwxrwx 1 root root 20 Oct 5 2015 /etc/rcS.d/S21alsa-utils -> ../init.d/alsa-utils
Hi Gene,
That's good. There's a good chance Kate's suggestion of checking the controls in kmix will solve your problem.
--Mike
On Monday 02 July 2018 09:01:14 Mike Bird wrote:
On Mon July 2 2018 05:34:50 Gene Heskett wrote:
On Monday 02 July 2018 07:48:29 Mike Bird wrote:
ls -l /etc/*.d/S*alsa*
lrwxrwxrwx 1 root root 20 Oct 5 2015 /etc/rcS.d/S21alsa-utils -> ../init.d/alsa-utils
Hi Gene,
That's good. There's a good chance Kate's suggestion of checking the controls in kmix will solve your problem.
--Mike
BTDT enough times to pay for the t-shirt. Tain't there.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Mon July 2 2018 07:36:36 Gene Heskett wrote:
On Monday 02 July 2018 09:01:14 Mike Bird wrote:
On Mon July 2 2018 05:34:50 Gene Heskett wrote:
On Monday 02 July 2018 07:48:29 Mike Bird wrote:
ls -l /etc/*.d/S*alsa*
lrwxrwxrwx 1 root root 20 Oct 5 2015 /etc/rcS.d/S21alsa-utils -> ../init.d/alsa-utils
Hi Gene,
That's good. There's a good chance Kate's suggestion of checking the controls in kmix will solve your problem.
--Mike
BTDT enough times to pay for the t-shirt. Tain't there.
OK, so we know ALSA is set to start automatically. I don't think we know yet that it is working as system sounds can happen without ALSA.
(1) Please use speaker-test before login to determine whether ALSA works before login. Make a note of which speakers it finds. Can you hear them all? ctrl-C to stop it when you get bored.
(2) What precisely tain't there? Kmix? Some slider you were expecting?
(3) In Control Center / Sound & Multimedia / Sound System is it enabled on the General tab?
(4) ... and is networked sound enable? (Easier if it is not.)
(5) ... and which Audio Device is selected on the Hardware tab?
BTW, a possible kludge for your situation might be to disable "restore volumes on login" in kmix / settings / configure kmix.
--Mike
On Monday 02 July 2018 18:30:34 Mike Bird wrote:
On Mon July 2 2018 07:36:36 Gene Heskett wrote:
On Monday 02 July 2018 09:01:14 Mike Bird wrote:
On Mon July 2 2018 05:34:50 Gene Heskett wrote:
On Monday 02 July 2018 07:48:29 Mike Bird wrote:
ls -l /etc/*.d/S*alsa*
lrwxrwxrwx 1 root root 20 Oct 5 2015 /etc/rcS.d/S21alsa-utils -> ../init.d/alsa-utils
Hi Gene,
That's good. There's a good chance Kate's suggestion of checking the controls in kmix will solve your problem.
--Mike
BTDT enough times to pay for the t-shirt. Tain't there.
OK, so we know ALSA is set to start automatically. I don't think we know yet that it is working as system sounds can happen without ALSA.
(1) Please use speaker-test before login to determine whether ALSA works before login. Make a note of which speakers it finds. Can you hear them all? ctrl-C to stop it when you get bored.
(2) What precisely tain't there? Kmix? Some slider you were expecting?
(3) In Control Center / Sound & Multimedia / Sound System is it enabled on the General tab?
(4) ... and is networked sound enable? (Easier if it is not.)
Not now, was though.
(5) ... and which Audio Device is selected on the Hardware tab?
BTW, a possible kludge for your situation might be to disable "restore volumes on login" in kmix / settings / configure kmix.
--Mike
I won't slap down on a bible, but I faintly recall setting that option way back when. And it had no effect, but I think its still on. Due to poor gain in my speakers, most of kmix has been wide open for years.
On Mon July 2 2018 17:06:11 Gene Heskett wrote:
On Monday 02 July 2018 18:30:34 Mike Bird wrote:
BTW, a possible kludge for your situation might be to disable "restore volumes on login" in kmix / settings / configure kmix.
I won't slap down on a bible, but I faintly recall setting that option way back when. And it had no effect, but I think its still on. Due to poor gain in my speakers, most of kmix has been wide open for years.
Hi Gene,
It is better to have "restore volumes on login" checked. Without it you may find that when you make a small adjustment in volume your sound level jumps or disappears.
However for kmix to work properly it has to be configured to match your system as Kate mentioned.
That's why disabling "restore volumes on login" is a possible kludge rather than a fix.
--Mike
On Sunday 01 July 2018 21:48:27 William Morder wrote:
On Sunday 01 July 2018 18:03:13 Gene Heskett wrote:
On Sunday 01 July 2018 20:47:58 William Morder wrote:
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote:
/home/dep/trinity/share/config/ etc....
I have that file, its owned by me:me and is rw only for me. And contains: DVI-I-1= DefaultProfile= EnableICC=false HDMI-1= VGA-1=
No clue what could have sneezed and screwed it up, but there it is.
No clue of the effect of setting some of those options might be. And no manpage. So your guess is likely better than mine.
Oh, I just found one thing that has not been fixed, I have audio during boot until tdm starts after I log in. After login, I still have to do an "alsactl restoreRETURN" before I have any sound. Can this be fixed?
I use ALSA, and it starts when I boot up.
Have you messed with this toy? sudo sysv-rc-conf
That is not findable on this wheezy machine.
You should be able to get it by installing through apt:
sudo apt-get install sysv-rc-conf
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I seem to recall that you could make some of these changes through the Trinity Control Center, but sysv-rc-conf is much easier, so long as you are careful. A lot of things can slow down your machine, because they are configured to run at startup when you don't need them; while other things that you want, like your sound system, might be disabled.
Bill
It might be a good idea, and it may not. But the fact is that I have 5 machines here still running wheezy and one jessie, which wheezy is now officially EOL even for security stuff. Until the lcnc crew have made up a jessie or stretch installer, So the likelyhood of my playing with this is quite low.
The jessie install is quite stable, but I have a rock64 running stretch that while its 20x faster than a pi, has problems with the login screen that in 6+ months, has not been fixed, so there is no way I could honestly say stretch is stable. Reboots after an update are a try this and see if it works, then try that, each one taking a full 10 second powerdown to get it to even try to reboot.
Until you finally get the ducks in order and a successful login can be done. That same rock64 runs jessie perfectly from power restoration to the next power failure. That I'd call stable.
Be careful, if you haven't used that before; although I suspect that you know it. Don't make changes there unless you know what to do.
Also, look in Trinity Control Center / Sound & Multimedia / Sound System Both parts, General / Hardware ought to be examined.
Bill
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Monday 02 July 2018 03:07:16 Gene Heskett wrote:
On Sunday 01 July 2018 21:48:27 William Morder wrote:
On Sunday 01 July 2018 18:03:13 Gene Heskett wrote:
On Sunday 01 July 2018 20:47:58 William Morder wrote:
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote: > /home/dep/trinity/share/config/ etc....
I have that file, its owned by me:me and is rw only for me. And contains: DVI-I-1= DefaultProfile= EnableICC=false HDMI-1= VGA-1=
No clue what could have sneezed and screwed it up, but there it is.
No clue of the effect of setting some of those options might be. And no manpage. So your guess is likely better than mine.
Oh, I just found one thing that has not been fixed, I have audio during boot until tdm starts after I log in. After login, I still have to do an "alsactl restoreRETURN" before I have any sound. Can this be fixed?
I use ALSA, and it starts when I boot up.
Have you messed with this toy? sudo sysv-rc-conf
That is not findable on this wheezy machine.
You should be able to get it by installing through apt:
sudo apt-get install sysv-rc-conf
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I seem to recall that you could make some of these changes through the Trinity Control Center, but sysv-rc-conf is much easier, so long as you are careful. A lot of things can slow down your machine, because they are configured to run at startup when you don't need them; while other things that you want, like your sound system, might be disabled.
Bill
It might be a good idea, and it may not. But the fact is that I have 5 machines here still running wheezy and one jessie, which wheezy is now officially EOL even for security stuff. Until the lcnc crew have made up a jessie or stretch installer, So the likelyhood of my playing with this is quite low.
The jessie install is quite stable, but I have a rock64 running stretch that while its 20x faster than a pi, has problems with the login screen that in 6+ months, has not been fixed, so there is no way I could honestly say stretch is stable. Reboots after an update are a try this and see if it works, then try that, each one taking a full 10 second powerdown to get it to even try to reboot.
Yup, I remember that hangup from running Debian with systemd. Once I changed to Devuan, it no longer hangs on reboot. However, changing over to Devuan is not necessarily smooth and easy - although some here would disagree. I think it all depends on what one already has installed.
Until you finally get the ducks in order and a successful login can be done. That same rock64 runs jessie perfectly from power restoration to the next power failure. That I'd call stable.
Be careful, if you haven't used that before; although I suspect that you know it. Don't make changes there unless you know what to do.
Also, look in Trinity Control Center / Sound & Multimedia / Sound System Both parts, General / Hardware ought to be examined.
On the whole, I agree with your approach, I think, which seems to be: take it slow, and don't mess with a working system. Even when my system is not running quite perfectly, it's still better than one that doesn't run at all, and time wasted with reinstallation.
Right now I have a lot of little glitches that keep building up, but I have a feeling that most are somehow related, as I've never had them before; and all are new since installing Devuan. So I mostly just keep trying to trace the source (or sources) of these issues, waiting until the inevitable reinstallation ... which could be another month or two.
Bill
On Monday 02 July 2018 08:44:39 William Morder wrote:
On Monday 02 July 2018 03:07:16 Gene Heskett wrote:
On Sunday 01 July 2018 21:48:27 William Morder wrote:
On Sunday 01 July 2018 18:03:13 Gene Heskett wrote:
On Sunday 01 July 2018 20:47:58 William Morder wrote:
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote: > On Sunday 01 July 2018 19:16:01 dep wrote: > > /home/dep/trinity/share/config/ etc.... > > I have that file, its owned by me:me and is rw only for > me. And contains: > DVI-I-1= > DefaultProfile= > EnableICC=false > HDMI-1= > VGA-1= > > No clue what could have sneezed and screwed it up, but > there it is. > > No clue of the effect of setting some of those options > might be. And no manpage. So your guess is likely better > than mine.
Oh, I just found one thing that has not been fixed, I have audio during boot until tdm starts after I log in. After login, I still have to do an "alsactl restoreRETURN" before I have any sound. Can this be fixed?
I use ALSA, and it starts when I boot up.
Have you messed with this toy? sudo sysv-rc-conf
That is not findable on this wheezy machine.
You should be able to get it by installing through apt:
sudo apt-get install sysv-rc-conf
Then I will send you a screenshot of my own run levels, or somebody else can do so; or you can do some research on how to set the run levels in sysv-rc-conf.
I seem to recall that you could make some of these changes through the Trinity Control Center, but sysv-rc-conf is much easier, so long as you are careful. A lot of things can slow down your machine, because they are configured to run at startup when you don't need them; while other things that you want, like your sound system, might be disabled.
Bill
It might be a good idea, and it may not. But the fact is that I have 5 machines here still running wheezy and one jessie, which wheezy is now officially EOL even for security stuff. Until the lcnc crew have made up a jessie or stretch installer, So the likelyhood of my playing with this is quite low.
The jessie install is quite stable, but I have a rock64 running stretch that while its 20x faster than a pi, has problems with the login screen that in 6+ months, has not been fixed, so there is no way I could honestly say stretch is stable. Reboots after an update are a try this and see if it works, then try that, each one taking a full 10 second powerdown to get it to even try to reboot.
Yup, I remember that hangup from running Debian with systemd. Once I changed to Devuan, it no longer hangs on reboot. However, changing over to Devuan is not necessarily smooth and easy - although some here would disagree. I think it all depends on what one already has installed.
Don't forget that the rock64 is NOT an armhf like the pi's, its a full arm64. I don't think the compiler is quite ready for a full 64 bit 4 core arm. In any event, the login screen becomes locked if not logged in within 10 seconds of its appearance. If the screen locker and its pw requirement could be nuked, that would help since ones pw is no good with the screen locker, once it kicks in, its power button time to get back into it. I'd a lot druther it just turned the monitor off in 10 to 20 minutes of inactivity. Barring a prowler in the night, I am the only one that will ever make new fingerprints on any of these keyboards here. The paranoid security, as if all this was sitting on a kiosk in Grand Central Station is extremely anti-productive. In a single user environment, its very poor quality BS because it only grows resentment.
Until you finally get the ducks in order and a successful login can be done. That same rock64 runs jessie perfectly from power restoration to the next power failure. That I'd call stable.
Be careful, if you haven't used that before; although I suspect that you know it. Don't make changes there unless you know what to do.
Also, look in Trinity Control Center / Sound & Multimedia / Sound System Both parts, General / Hardware ought to be examined.
On the whole, I agree with your approach, I think, which seems to be: take it slow, and don't mess with a working system. Even when my system is not running quite perfectly, it's still better than one that doesn't run at all, and time wasted with reinstallation.
I would not go so far as to say that, because I am forever twiddling the lcnc configs. Adding a function or expanding the gui. But thats not the os, its an app, so if I screw it up, the machine keeps on keeping on. And I see the errors so I can fix it.
Going off-topic a bit:
For instance, when doing "rigid tapping" where you are threading a hole by driving the tap into the hole at the same rate as the pitch of the tap. You tell the code how deep to drive the tap, and when that depth is reached, it reverses the spindle and unscrews it from the hole, staying with the pitch as it backs out of the hole. But there is mechanical inertia in the spindle drive that prevents an instant reversal. Depending on the machine it may take 3 or 4 turns of the spindle to get stopped, and 3 or 4 turns to get back to normal speed in reverse and might be typical of a lathe turning a 40 lb chuck at 300 rpms. This means the tap is driven further into the hole than intended, and a broken tap if it hits the bottom of the hole. So I've added some stuff to the lathes hal file to measure it and to show both turns of the spindle and actual distance traveled, visible in the gui so by cutting air, capturing those measurements and adjusting the code accordingly, a broken tap from hitting the bottom of the hole should be a thing of the past.
I intend to make that functional on the mill, but the initial capture is in encoder counts, which unlike the lathe and the way I'm getting those counts there, the mill has 2 separate scales to deal with depending on the backgear status. So that code is a bit more complex and unfinished just yet. But it will be in due time. Its also not as big a problem since the mill can go from 2500 revs fwd, to 2500 revs in reverse, in a fraction of a second. FWIW this is something that no pricy commercially sold software can do.
Right now I have a lot of little glitches that keep building up, but I have a feeling that most are somehow related, as I've never had them before; and all are new since installing Devuan. So I mostly just keep trying to trace the source (or sources) of these issues, waiting until the inevitable reinstallation ... which could be another month or two.
That shouldn't be the case, Bill.
Bill
Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene
On Monday 02 July 2018 07:33:44 Gene Heskett wrote:
[trimming just a bit ...]
It might be a good idea, and it may not. But the fact is that I have 5 machines here still running wheezy and one jessie, which wheezy is now officially EOL even for security stuff. Until the lcnc crew have made up a jessie or stretch installer, So the likelyhood of my playing with this is quite low.
The jessie install is quite stable, but I have a rock64 running stretch that while its 20x faster than a pi, has problems with the login screen that in 6+ months, has not been fixed, so there is no way I could honestly say stretch is stable. Reboots after an update are a try this and see if it works, then try that, each one taking a full 10 second powerdown to get it to even try to reboot.
Yup, I remember that hangup from running Debian with systemd. Once I changed to Devuan, it no longer hangs on reboot. However, changing over to Devuan is not necessarily smooth and easy - although some here would disagree. I think it all depends on what one already has installed.
Don't forget that the rock64 is NOT an armhf like the pi's, its a full arm64. I don't think the compiler is quite ready for a full 64 bit 4 core arm. In any event, the login screen becomes locked if not logged in within 10 seconds of its appearance. If the screen locker and its pw requirement could be nuked, that would help since ones pw is no good with the screen locker, once it kicks in, its power button time to get back into it. I'd a lot druther it just turned the monitor off in 10 to 20 minutes of inactivity. Barring a prowler in the night, I am the only one that will ever make new fingerprints on any of these keyboards here. The paranoid security, as if all this was sitting on a kiosk in Grand Central Station is extremely anti-productive. In a single user environment, its very poor quality BS because it only grows resentment.
You ought to be able to diable the screen locker. I never use them except manually. Like you, I am the only one here, if one doesn't count the occasional vermin in this building, so there is no reason for ultra-security about physical access to my machine. When I leave, I lock everything down manually.
Until you finally get the ducks in order and a successful login can be done. That same rock64 runs jessie perfectly from power restoration to the next power failure. That I'd call stable.
Be careful, if you haven't used that before; although I suspect that you know it. Don't make changes there unless you know what to do.
Also, look in Trinity Control Center / Sound & Multimedia / Sound System Both parts, General / Hardware ought to be examined.
On the whole, I agree with your approach, I think, which seems to be: take it slow, and don't mess with a working system. Even when my system is not running quite perfectly, it's still better than one that doesn't run at all, and time wasted with reinstallation.
I would not go so far as to say that, because I am forever twiddling the lcnc configs. Adding a function or expanding the gui. But thats not the os, its an app, so if I screw it up, the machine keeps on keeping on. And I see the errors so I can fix it.
Oh, I am a constant fiddler & an habitual twiddler. I just mean that I stay away from doing a full installation, as I don't quite have it to the point (as I used to do on my old Hardy Kubuntu machine) where I could go from not working to completely restored system in about half an hour. However, I am almost there, and when I get that with my Jessie system, I want to make it so that upgrades (to Stretch/Ascii) will not be any big deal. But at a glance, it looks and runs almost exactly like my legendary desktop of yore, the one that poets used to sing lays about, and that the bards composed epics to celebrate. It's almost there, but not quite.
Going off-topic a bit:
[interesting ... but snip ... sorry ... to please Felix ...]
Right now I have a lot of little glitches that keep building up, but I have a feeling that most are somehow related, as I've never had them before; and all are new since installing Devuan. So I mostly just keep trying to trace the source (or sources) of these issues, waiting until the inevitable reinstallation ... which could be another month or two.
That shouldn't be the case, Bill.
Cheers, Gene Heskett
Well, I have discussed some of them, and got help, but the solutions don't quite resolve my issues. And these glitches are annoying, but don't interrupt my work.
For example, I mentioned in an earlier thread that the GUI of some programs suddenly gets "bleached" white, like the default KDE3 or maybe Gnome setting? No matter what I've tried, they refuse to use my system colors. Yet when I reinstall my system, generally everything returns to normal. This seems to happen about every third time that I reinstall, without apparent rhyme or reason. I install everything by specific steps, so this should not change, if my system itself hasn't changed. And sometimes, if I just reinstall yet again, immediately, everything is back to normal.
The same with my mount points. I create special mount points for all my extra hard drives (beyond sda partitions, that is). Some are internal, and continue to work fine, but my external drives suddenly cannot be mounted except as root, and remain accessible only within a root environment (for example, if I open Konqueror as root). This means that I cannot play media files from those partitions, for example, though I can transfer them back and forth. I have gone into fstab and mtab settings, examine ownership and permissions, etc., and nothing changes. Only one drive, which is formatted as a Linux filesystem, has become partially accessible, though I still must jump through hoops to mount it. My other external hard drives remain inaccessible except when I access them through a root environment; that is, either a root shell, or by opening Konqueror as root. Yet when I reinstall, most likely this problem will go away, as again, it only happens maybe on every third installation (and never happened when I ran Kubuntu Hardy 8.04).
There are a few other annoyances, but as I say, I prefer to keep working at the moment, rather than spend a day or two reinstalling everything.
However ... unless somebody has some really useful suggestions to make about how to solve these problems, I am not asking for help. I am just making observations about some of my minor annoyances. As I said, my system is getting close to perfect, and then the Dragon Kings will yield their Jewel of Enlightenment, the President will probably arrange to pin a medal on my chest, or maybe there will be a Nobel Prize for personal modification of a desktop environment? Anyway, almost perfect ... *SIGH*
Bill
On Monday 02 July 2018 14:21:18 William Morder wrote:
On Monday 02 July 2018 07:33:44 Gene Heskett wrote:
[trimming just a bit ...]
It might be a good idea, and it may not. But the fact is that I have 5 machines here still running wheezy and one jessie, which wheezy is now officially EOL even for security stuff. Until the lcnc crew have made up a jessie or stretch installer, So the likelyhood of my playing with this is quite low.
The jessie install is quite stable, but I have a rock64 running stretch that while its 20x faster than a pi, has problems with the login screen that in 6+ months, has not been fixed, so there is no way I could honestly say stretch is stable. Reboots after an update are a try this and see if it works, then try that, each one taking a full 10 second powerdown to get it to even try to reboot.
Yup, I remember that hangup from running Debian with systemd. Once I changed to Devuan, it no longer hangs on reboot. However, changing over to Devuan is not necessarily smooth and easy - although some here would disagree. I think it all depends on what one already has installed.
Don't forget that the rock64 is NOT an armhf like the pi's, its a full arm64. I don't think the compiler is quite ready for a full 64 bit 4 core arm. In any event, the login screen becomes locked if not logged in within 10 seconds of its appearance. If the screen locker and its pw requirement could be nuked, that would help since ones pw is no good with the screen locker, once it kicks in, its power button time to get back into it. I'd a lot druther it just turned the monitor off in 10 to 20 minutes of inactivity. Barring a prowler in the night, I am the only one that will ever make new fingerprints on any of these keyboards here. The paranoid security, as if all this was sitting on a kiosk in Grand Central Station is extremely anti-productive. In a single user environment, its very poor quality BS because it only grows resentment.
You ought to be able to diable the screen locker. I never use them except manually. Like you, I am the only one here, if one doesn't count the occasional vermin in this building, so there is no reason for ultra-security about physical access to my machine. When I leave, I lock everything down manually.
I have not been able to find that in the xfce menu's. If someone can tell me how, I'll be happy to do it. Or an automatic login as 1st user would also be a solution. As it is, if I want to do something, its almost guaranteed I'll have to ssh into it from this machine.
Thank you.
[...]
Well, I have discussed some of them, and got help, but the solutions don't quite resolve my issues. And these glitches are annoying, but don't interrupt my work.
For example, I mentioned in an earlier thread that the GUI of some programs suddenly gets "bleached" white, like the default KDE3 or maybe Gnome setting? No matter what I've tried, they refuse to use my system colors. Yet when I reinstall my system, generally everything returns to normal. This seems to happen about every third time that I reinstall, without apparent rhyme or reason. I install everything by specific steps, so this should not change, if my system itself hasn't changed. And sometimes, if I just reinstall yet again, immediately, everything is back to normal.
That might be a memory problem indicator. Has memtest86 given it a clean report after several cycles?
Thats also a symptom of wandering around poking at things as root.
The same with my mount points. I create special mount points for all my extra hard drives (beyond sda partitions, that is). Some are internal, and continue to work fine, but my external drives suddenly cannot be mounted except as root, and remain accessible only within a root environment (for example, if I open Konqueror as root). This means that I cannot play media files from those partitions, for example, though I can transfer them back and forth. I have gone into fstab and mtab settings, examine ownership and permissions, etc., and nothing changes. Only one drive, which is formatted as a Linux filesystem, has become partially accessible, though I still must jump through hoops to mount it. My other external hard drives remain inaccessible except when I access them through a root environment; that is, either a root shell, or by opening Konqueror as root. Yet when I reinstall, most likely this problem will go away, as again, it only happens maybe on every third installation (and never happened when I ran Kubuntu Hardy 8.04).
Mount, generally speaking is a restricted command, accessible only by root.
There are a few other annoyances, but as I say, I prefer to keep working at the moment, rather than spend a day or two reinstalling everything.
However ... unless somebody has some really useful suggestions to make about how to solve these problems, I am not asking for help. I am just making observations about some of my minor annoyances. As I said, my system is getting close to perfect, and then the Dragon Kings will yield their Jewel of Enlightenment, the President will probably arrange to pin a medal on my chest,
probably with a staple gun. :(
or maybe there will be a Nobel Prize for personal modification of a desktop environment?
Hummm, you probably shouldn't let your imagination out to play w/o a chaperone. Gets one in trouble, BTDT myself. ;-)
Anyway, almost perfect ... *SIGH*
Bill
Lots of wistfull sighing going on here.>
On Sunday 01 July 2018 06:16:01 pm dep wrote:
optimize its configuration, i'm trying to set the screen not to just blank but to power down when the screensaver is called.
I have not read any of the other replies, but an alternative is to add an Applet to your Panel that calls this Batch file. (I use the Gnome-Mines system icon for grins and place it on the far opposite side from the TDE Menu.)
=========== goodnight.sh #!/bin/bash
dcop kdesktop KScreensaverIface lock sleep 3 xset dpms force standby ===========
It locks the session and after 3 seconds turns the screen off.
I've used this for 5+ years on my old Dell laptop (with CentOS, Ubuntu, Gnome, KDE, TDE), so I don't remember if it's hardware specific, so change as needed for your hardware.
Best, Michael
On July 1, 2018 11:35 PM, Michael mb_trinity_desktop@inet-design.com wrote:
I have not read any of the other replies, but an alternative is to add an
Applet to your Panel that calls this Batch file. (I use the Gnome-Mines
system icon for grins and place it on the far opposite side from the TDE
Menu.)
========================================================================================================================================================================================================================================
goodnight.sh
#!/bin/bash
dcop kdesktop KScreensaverIface lock
sleep 3
xset dpms force standby
=====================================================================================================
It locks the session and after 3 seconds turns the screen off.
I've used this for 5+ years on my old Dell laptop (with CentOS, Ubuntu, Gnome,
KDE, TDE), so I don't remember if it's hardware specific, so change as needed
for your hardware.
Excellent. Thank you very much.
dep
Sent withProtonMailSecure Email. Because privacy matters.
-
dep -
Dr. Nikolaus Klepp -
Felix Miata -
Gene Heskett -
J Leslie Turriff -
Michael -
Mike Bird -
William Morder