1 Jul
2018
1 Jul
'18
11:16 p.m.
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.
1 Jul
1 Jul
11:41 p.m.
New subject: [trinity-users] today's immature bothersome question
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
2 Jul
2 Jul
12:35 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 16:41:26 Mike Bird wrote:
On Sun July 1 2018 16:16:01 dep wrote:
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
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
12:54 a.m.
New subject: [trinity-users] today's immature bothersome question
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
1:10 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sun July 1 2018 17:54:14 Mike Bird wrote:
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
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.
1:34 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 18:10:12 Mike Bird wrote:
On Sun July 1 2018 17:54:14 Mike Bird wrote:
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
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.
1:41 a.m.
New subject: [trinity-users] today's immature bothersome question
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
1:57 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 18:41:16 Mike Bird wrote:
On Sun July 1 2018 18:34:23 William Morder wrote:
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.
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
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
1:35 a.m.
New subject: [trinity-users] today's immature bothersome question
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
6:20 a.m.
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
4:08 p.m.
New subject: [trinity-users] today's immature bothersome question
On July 1, 2018 7:41 PM, Mike Bird <mgb-trinity(a)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.
7:07 p.m.
New subject: [trinity-users] today's immature bothersome question
On Monday 02 July 2018 09:08:21 dep wrote:
On July 1, 2018 7:41 PM, Mike Bird
<mgb-trinity(a)yosemite.net> wrote:
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
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
1 Jul
1 Jul
11:58 p.m.
New subject: [trinity-users] today's immature bothersome question
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.
--
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>
2 Jul
2 Jul
12:23 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
On Sunday 01 July 2018 19:16:01 dep wrote:
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?
--
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>
/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.
12:47 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
On Sunday 01 July 2018 19:58:34 Gene Heskett wrote:
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 19:16:01 dep wrote:
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? /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.
1:03 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 20:47:58 William Morder wrote:
On Sunday 01 July 2018 17:23:52 Gene Heskett wrote:
That is not findable on this wheezy machine.
On Sunday 01 July 2018 19:58:34 Gene Heskett
wrote:
I use ALSA, and it starts when I boot up.
Have you messed with this toy?
sudo sysv-rc-conf On Sunday 01 July 2018 19:16:01 dep wrote:
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? /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. 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(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
--
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>
1:48 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 18:03:13 Gene Heskett wrote:
On Sunday 01 July 2018 20:47:58 William Morder wrote:
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
On Sunday 01 July 2018 17:23:52 Gene Heskett
wrote:
That is not findable on this wheezy machine.
On Sunday 01 July 2018 19:58:34 Gene Heskett
wrote:
I use ALSA, and it starts when I boot up.
Have you messed with this toy?
sudo sysv-rc-conf 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? > 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
>
2:12 a.m.
New subject: [trinity-users] today's immature bothersome question
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.
--
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
2:20 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 19:12:16 Felix Miata wrote:
William Morder composed on 2018-07-01 18:48
(UTC-0700):
It's being charged to your account. We figured that you must have the most
money, since you are keeping track.
Bill
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.
2:14 a.m.
New subject: [trinity-users] today's immature bothersome question
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
2:19 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 19:14:45 Mike Bird wrote:
On Sun July 1 2018 18:48:27 William Morder wrote:
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
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
10:31 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 22:14:45 Mike Bird wrote:
On Sun July 1 2018 18:48:27 William Morder 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.
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.
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(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
--
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>
11:27 a.m.
New subject: [trinity-users] today's immature bothersome question
Am Montag, 2. Juli 2018 schrieb Gene Heskett:
On Sunday 01 July 2018 22:14:45 Mike Bird wrote:
What about adding that alsactrl-comman into .xinitrc or .xsessionrc? e.g.:
( sleep 1m; alsactrl .....) &
nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
On Sun July 1 2018 18:48:27 William Morder
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.
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.
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
11:37 a.m.
New subject: [trinity-users] today's immature bothersome question
On Monday 02 July 2018 07:27:54 Dr. Nikolaus Klepp wrote:
Am Montag, 2. Juli 2018 schrieb Gene Heskett:
Haven't tried that. Doesn't work in rc.local either
On Sunday 01 July 2018 22:14:45 Mike Bird wrote:
What about adding that alsactrl-comman into .xinitrc or .xsessionrc?
e.g.:
On Sun July 1 2018 18:48:27 William Morder
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.
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.
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 ( sleep 1m; alsactrl .....) &
nik
--
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>
11:48 a.m.
New subject: [trinity-users] today's immature bothersome question
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
12:34 p.m.
New subject: [trinity-users] today's immature bothersome question
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
--
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>
1:01 p.m.
New subject: [trinity-users] today's immature bothersome question
On Mon July 2 2018 05:34:50 Gene Heskett wrote:
On Monday 02 July 2018 07:48:29 Mike Bird wrote:
Hi Gene,
That's good. There's a good chance Kate's suggestion of checking
the controls in kmix will solve your problem.
--Mike
ls -l /etc/*.d/S*alsa*
lrwxrwxrwx 1 root root 20 Oct 5
2015 /etc/rcS.d/S21alsa-utils -> ../init.d/alsa-utils
2:36 p.m.
New subject: [trinity-users] today's immature bothersome question
On Monday 02 July 2018 09:01:14 Mike Bird wrote:
On Mon July 2 2018 05:34:50 Gene Heskett wrote:
BTDT enough times to pay for the t-shirt. Tain't there.
On Monday 02 July 2018 07:48:29 Mike Bird wrote:
Hi Gene,
That's good. There's a good chance Kate's suggestion of checking
the controls in kmix will solve your problem.
--Mike
ls -l /etc/*.d/S*alsa*
lrwxrwxrwx 1 root root 20 Oct 5
2015 /etc/rcS.d/S21alsa-utils -> ../init.d/alsa-utils
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
--
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>
10:30 p.m.
New subject: [trinity-users] today's immature bothersome question
On Mon July 2 2018 07:36:36 Gene Heskett wrote:
On Monday 02 July 2018 09:01:14 Mike Bird wrote:
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 Mon July 2 2018 05:34:50 Gene Heskett wrote:
BTDT enough times to pay for the t-shirt. Tain't there. On Monday 02 July 2018 07:48:29 Mike Bird wrote:
Hi Gene,
That's good. There's a good chance Kate's suggestion of checking
the controls in kmix will solve your problem.
--Mike ls -l /etc/*.d/S*alsa*
lrwxrwxrwx 1 root root 20 Oct 5
2015 /etc/rcS.d/S21alsa-utils -> ../init.d/alsa-utils
3 Jul
3 Jul
12:06 a.m.
New subject: [trinity-users] today's immature bothersome question
On Monday 02 July 2018 18:30:34 Mike Bird wrote:
On Mon July 2 2018 07:36:36 Gene Heskett wrote:
Not now, was though.
On Monday 02 July 2018 09:01:14 Mike Bird wrote:
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.) On Mon July 2 2018 05:34:50 Gene Heskett wrote:
BTDT enough times to pay for the t-shirt. Tain't there. 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 (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.
--
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>
1:12 a.m.
New subject: [trinity-users] today's immature bothersome question
On Mon July 2 2018 17:06:11 Gene Heskett wrote:
On Monday 02 July 2018 18:30:34 Mike Bird wrote:
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
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.
2 Jul
2 Jul
10:07 a.m.
New subject: [trinity-users] today's immature bothersome question
On Sunday 01 July 2018 21:48:27 William Morder wrote:
--
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 Sunday 01 July 2018 18:03:13 Gene Heskett wrote:
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.
On Sunday 01 July 2018 20:47:58 William Morder
wrote:
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
On Sunday 01 July 2018 17:23:52 Gene Heskett
wrote:
That is not findable on this wheezy machine. 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 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(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)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
12:44 p.m.
New subject: [trinity-users] today's immature bothersome question
On Monday 02 July 2018 03:07:16 Gene Heskett wrote:
On Sunday 01 July 2018 21:48:27 William Morder wrote:
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.
On Sunday 01 July 2018 18:03:13 Gene Heskett
wrote:
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.
On Sunday 01 July 2018 20:47:58 William Morder
wrote:
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 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. 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
2:33 p.m.
New subject: [trinity-users] today's immature bothersome question
On Monday 02 July 2018 08:44:39 William Morder wrote:
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.
On Monday 02 July 2018 03:07:16 Gene Heskett wrote:
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.
On Sunday 01 July 2018 21:48:27 William Morder
wrote:
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.
On Sunday 01 July 2018 18:03:13 Gene Heskett
wrote:
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. 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 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.
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>
6:21 p.m.
New subject: [trinity-users] today's immature bothersome question
On Monday 02 July 2018 07:33:44 Gene Heskett wrote:
[trimming just a bit ...]
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 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.
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
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. 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
8:40 p.m.
New subject: [trinity-users] today's immature bothersome question
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 ...]
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.
[...]
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. 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.>
--
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>
3:35 a.m.
New subject: [trinity-users] today's immature bothersome question
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
3:18 p.m.
New subject: [trinity-users] today's immature bothersome question
On July 1, 2018 11:35 PM, Michael <mb_trinity_desktop(a)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.
2364
days inactive
2366
days old
37 comments
8 participants
participants (8)
-
dep -
Dr. Nikolaus Klepp -
Felix Miata -
Gene Heskett -
J Leslie Turriff -
Michael -
Mike Bird -
William Morder