On 6/5/24 19:53, gene heskett wrote:
On 6/5/24 17:25, Tom Dial wrote:
On 6/5/24 08:58, gene heskett wrote:
On 6/5/24 02:05, Tom Dial wrote:
On 6/4/24 04:26, gene heskett wrote:
On 2/19/22 06:31, Andrew M.A. Cater wrote:
Hi Gene,
If this was someone calling you from a TV station saying they had a TV
transmitter that was varying in power output - you'd have a mental checklist.
You'd get down there, perhaps schedule some sort of power down / reduced
power operation and then you'd check - power supplies, feeder cables, hot
spots on cables - whatever. Divide and conquer- working back to a baseline
of known working conditions and eliminating causes.
My suggestion to you of a reinstall is partly designed to get you out of this
"X happens, I did Y, now I've got Z" - to get to a known initial state.
Take out all the serial converters to UPS, lathe and so on. Wireless keyboard
doesn't present as serial in the same way that brltty does - if it did, I'd
have brltty with every install on this laptop.
Copy off your home directory as you did before - maybe using tar.gz and
preserving permissions. Start with the .iso that includes firmware - the
unofficial one.
Build back slowly - do an expert text mode install if you can. Then add your
Trinity desktop - I don't think any of us can help you there, since we don't
run trinity.
Check and you should find that brltty isn't installed at all. Then re-add
thingsgradually until you have the working system you want. Document it - write
down
the steps you take / copy configuration files you change.
That will also reveal logging / login slowdowns or whatever caused by
individual devices as you add them back. Keep a list as you go.
That's the counsel of perfection: alternatively:
apt rdepends brltty gives me:
me@mymachine:~$ apt rdepends brltty
brltty
Reverse Depends:
Suggests: speechd-el (>= 3.7.2)
Depends: brltty-espeak (= 6.3+dfsg-1+deb11u1)
Suggests: orca
Depends: brltty-x11 (= 6.3+dfsg-1+deb11u1)
Depends: brltty-speechd (= 6.3+dfsg-1+deb11u1)
Depends: brltty-flite (= 6.3+dfsg-1+deb11u1)
You could try apt-get remove (or equivalent) on each of those packages and
see if that clears it. I _know_ this is frustrating as all get out for you
but a clear approach, written down so that you can remember where you got
to will be very helpful.
Any attempt to remove cura or brltty, removes gnome leaving me I assume with a
text only system by the time gnome takes all its dependency's with it. Thanks
Tom.
Have you actually tried uninstalling brltty only, as a separate action from all
others?
I have a number of gnome installations, unfortunately for this discussion all
bookworm. None of them has brltty.
I have a few installations of bullseye and an older stretch installation, but none with gnome
installed. On all of them, though, "apt-rdepends -r gnome" fails to list brltty as a
gnome dependency. And on the bookworm systems, simulated installation of gnome ("apt install
-s gnome") shows brltty as a suggested package only and would not install it along with gnome;
on the stretch system, gnome installation makes no reference at all to brltty.
While I have both with only the radio buttons for keyboard and rodent plugged
into usb at install time. I have only one wired keyboard and no wired mice as
I've had a lightning strike on the pole that serves this house reach up and tap
me by way of my fingers on the keyboard. Wasn't that much of a tap, I've been
tapped a lot harder that that, hard enough to trigger a 6 month round of
shingles and the burns were months healing. And in this case did not damage the
keyboard or computer, but I did get the message. I've had many strikes on that
pole since I built a garage on the end of the house, which caused me to install
a 200 amp service and bring my grounding specs up to NEC. Zero problems since
then (2008)
Is it possible you have apt settings that automatically pull in suggested
packages, and that is interfering with attempts to remove brltty? I am not
expert enough wrt apt and its relatives to know whether that even makes sense,
and it seems a bit far fetched if maybe barely possible.
Maybe if you post the output from "apt-rdepends -r brltty" and "apt purge --simulate
brltty" it will be informative.
Neither of those utils are installed. Should they be?
apt should be installed. As far as I know it has been included by default in
the Debian base system as the preferred command line package management program
since buster or earlier. I have never had to install it. You probably should if
it is missing.
apt-rdepends is at least partly redundant with apt.
The command "apt-rdepends -r <package-name>", and "apt rdepends <package-name>" both
show reverse dependencies of <package-name>; the latter also shows suggestions (packages that suggest <package
name, I think).
If you have apt installed, you probably do not need apt-rdepends.
Regards,
Tom Dial
Regards,
Tom Dial
If all else fails, you can then share it with the list and say "I got to
step X with no problems, then Y happened - help me out here" and we'll
have some better idea. We all jib at you for being vague/not indluding
details but otherwise it is all just guesswork for the usual folk that
hang out here.
All the very best, as ever,
Andy Cater
How much longer till trixie is officially out?? What you are proposing sounds like several days work, and i have other irons in the fire. This release has been such a disaster for me because the install insists on installing and configuring orca and brltty w/o asking. I've done 40 some installs now, trying to stop it from wasting about a second while its yelling every keystroke at me because it thinks I'm blind. I finally have orca disabled and the computer is useful. The delays are a pain in the a$$ but i can do work now. It is not useful when orca is using 90% of a 6 core I5 yelling at me loud enough to announce and pronounce every keystroke or mouse motion/click loud enough to wake the neighbors. The first 23 installs never asked me if I wanted that crap. And if you nuked the orca executable it would not reboot but hung forever waiting for orca to start. I have it usable, the installer AFAIAC is broken and I don't want to have to go through all that again. Until the
installer ASKS me if I want it because it thinks I am blind, I have only one nerve left and and the suggestion that I do yet another install, is standing on it. Trying to remove it now, it insists on removing gnome and every dependency. I just checked again with synaptic, removing either orca or brltty still wants to destroy the system, Yet all I get when I fuss about the broken installer is "won't fix, not broken'.
Hi Gene,
I, too, am not in need of the services that brltty or orca provide, and have
noticed them hanging about from time to time, although I have not encountered
any difficulties like you describe.
On a bullseye system, apt-rdepends -r brltty informs me:
# apt-rdepends -r brltty
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
brltty
Reverse Depends: brltty-espeak (= 6.3+dfsg-1+deb11u1)
Reverse Depends: brltty-flite (= 6.3+dfsg-1+deb11u1)
Reverse Depends: brltty-speechd (= 6.3+dfsg-1+deb11u1)
Reverse Depends: brltty-x11 (= 6.3+dfsg-1+deb11u1)
brltty-espeak
brltty-flite
brltty-speechd
brltty-x11
If I understand apt-rdepends correctly, you should be able to remove/purge brltty
("apt purge brltty") without removing any installed packages other than the
four listed above.
apt-rdepends -r orca tells me:
# apt-rdepends -r orca
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
orca
Reverse Depends: gnome (>= 1:3.38+3)
Reverse Depends: gnome-orca (3.38.2-2)
Reverse Depends: orca-sops (1.0.2-2)
gnome
gnome-orca
orca-sops
So removing orca would also take gnome, and that probably is unacceptable to
you. Accordingly, you need to tame orca to find the process that causes it to
run and persuade it not to do that.
I found, on a bookworm install (I have no bullseye with gnome and orca), that running orca -s from a terminal
will bring up a settings panel with a check box for "Enable speech" under the "Speech"
tab. Unchecking that box and selecting the "Apply" button will silence Orca. I think that leaves
some of its subtasks running, as children of the systemd --user task; I am far from expert here. They do not
seem to use significant resources, however.
Alternatively, you can find orca's process, for instance, with "ps -ef | grep
orca", and kill it. The -HUP signal is enough. Or you can kill its parent process
(third column in the ps -ef output) if it is not a necessary one, or maybe teach it how
to not start orca in the first place,
I hope this is useful. Things like this can be very annoying.
Regards,
Tom Dial
Thank you Tom
Cheers, Gene Heskett, CET.
