You are not logged in.
apt-get dist-upgrade -t=ascii-backports
Actually I always treated my HP 1000W printer config as a magic for myself. It was relatively difficult to do even in Debian without backports.
I am almost sure nothing changes if I downgrade from backports back to the updates and security.
I have another Debian Wheezy host with an old HP LJ 1000W printer connected to it.
I tried a CUPS wizard to add this printer as an IPP printer, but it did not work.
Then I have discovered following command:
lpadmin -p LaserJet -E -v ipp://x.x.x.x:631/printers/HP_LaserJet -m everywhere
and it created the printer which works from GUI programs like text editors.
After sending a document a Trinity popup appears which still indicates an error, but then the document is printed on the network printer anyway.
Please note: my workstation is running Devuan ASCII dist-upgraded to the backports.
Following commands used to install drivers on both CUPS server and client:
apt-get install printer-driver-foo2zjs hpijs-ppds hannah-foo2zjs
apt-get purge hplip hplip-cups hplip-data hplip-doc
CUPS on the server always worked for sure even since I had another Debian on my workstation a few years ago.
And also opening its IP in the browser and directing to print a test page from CUPS web interface works fine.
I have corrected how symbols displayed in chvt 0 terminal by executing following command:
dpkg-reconfigure console-setup
and by selecting UTF-8 on the first page, and then my national specific option on the next page, and then Terminus (though others work too) font on the third page.
After that ls and mc displays correct characters in text terminal.
And IMHO oldstable Devuan ASCII upgraded to backports is very stable and nice :b
And Devuan is the best universal Linux distribution suitable for physical hosts.
I would run other distros only in its virtual machines.
I will mention my backported dist-upgrade status in my further requests. Thank you very much for your help.
We get answers here so quickly and they are very helpful and professional.
Does someone sponsor support work? I have seen many support replies during my life, and it sometimes takes much more time to get even an answer for expensive proprietary software issues those are much easier.
And I have to ask: is this from your box that has been dist-upgraded from the backports repository?
Yes, it is after dist-upgrade -t=ascii-backports
Do you think nodm produces mentioned above problems only in a backported system like mine?
I am still not motivated for a downgrade anyway, just replaced nodm with slim, and almost everything is OK again.
People live and work on Ceres and it is fine for them generally.
As for me it is important to avoid significant configuration changes which is very seldom even with any and all backports installed on oldstable.
Though I still have to find a solution for text mode national symbols displayed incorrectly (only in Alt+F1..F6 terminal screens), I even did not pay attention to it earlier, may be before backports it was broken the same way.
After purging locales, installing this package once again and reconfiguring it for EN_US.UTF-8
I see several problems now:
1) In text terminal Alt+F1:
There are some fields still blank:
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Specifically LANGUAGE= and LC_ALL= are blank.
Also in text terminal I see a font which displays national symbols only partially while replacing about a half of them by a búbi character.
I guess I have to replace used font somehow?
2) During my last upgrade a few days ago I have replaced TDM display manager by nodm, and it seems nodm wipes out all localization fields.
Now I have replaced nodm by slim and at least I see in all terminals the same output of locales command which I see in text terminal described above in 1)
Btw, after replacing nodm by slim a few minutes ago I have correct working of all terminals in the desktop environment, all of them display mc and national symbols well. If I would not check specially I would not even notice that LANGUAGE= and LC_ALL= fields became blank.
Can you please let me know which script sets values for all LC_* fields from what I specified during re-configuring locales packages?
For now I would like to try at least to recover values for LANGUAGE= and LC_ALL= fields, how to do this?
And perhaps your locales are mis-configured so try
# dpkg-reconfigure locales
Sure, I tried it several times earlier, it does not help at all, I even tried reinstalling different versions of this package and then reverted its version back.
I guess I have to leave the desktop environment and try to recover a good configuration of locales in a general text console at first at Alt+F1.
Another problem appeared, even in other terminals locales became broken, I have already even removed ~/.config/plasma-localerc
and restarted Trinity:
locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE=
LC_NUMERIC=
LC_TIME=
LC_COLLATE=
LC_MONETARY=
LC_MESSAGES=
LC_PAPER=
LC_NAME=
LC_ADDRESS=
LC_TELEPHONE=
LC_MEASUREMENT=
LC_IDENTIFICATION=
LC_ALL=
Two new problems:
1) locale: Cannot set LC_CTYPE to default locale: No such file or directory
2) Most fields became empty in non KDE terminals the same way as in KDE konsole
Something goes wrong
I even cannot revert back without rollback. Will try to see zfs diff.
Is it correct?
cat ~/.config/plasma-localerc
[Formats]
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
The problem is still there
I have created a file:
cat ~/.config/plasma-localerc
[Formats]
LANG=en_US.UTF-8
The problem is still there
But at least I know a direction where to search for a solution, it is somewhere a KDE personal locales config.
Thanks for trying to help me, but I cannot find a plasma related locales config file:
find ~ -name plasma-localerc
find ~ -name \*locale\*
Hello,
I use Trinity R14.0.9 and some KDE5 programs from the Devuan repository like for example konsole:
dpkg -al | grep konsole
ii konsole 4:16.12.0-4 amd64 X terminal emulator
ii konsole-kpart 4:16.12.0-4 amd64 Konsole plugin for Qt applications
ii konsole-trinity 4:14.0.9-0debian9.0.0+0 amd64 X terminal emulator for TDE
ii konsolekalendar-trinity 4:14.0.9-0debian9.0.0+0 amd64 Trinity konsole personal organizer
After last upgrades of Trinity or may be Devuan backports I have got a strange behavior of locales in my system.
When I run command locale from konsole-trinity or lxterminal everything works fine:
locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
But if I run the same command locale from KDE konsole terminal I get a strange output like:
locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=
LC_NUMERIC=
LC_TIME=
LC_COLLATE=
LC_MONETARY=
LC_MESSAGES=
LC_PAPER=
LC_NAME=
LC_ADDRESS=
LC_TELEPHONE=
LC_MEASUREMENT=
LC_IDENTIFICATION=
LC_ALL=
The actual problem why ask about this is I do not see national characters in mc ran from KDE konsole neither correct pseudo-graphics.
While everything works fine when ran from other non KDE terminals like konsole-trinity and lxterminal.
If running:
LANG=C mc
then at least pseudo-graphics is displayed correctly, but national symbols are not visible yet, displayed as ??????.
As for Trinity, I only used it for a few days. It was when I was using Konqueror to surf that I discovered that Konqueror does not support modern web technologies. Also, I had some general issues with making things work.
Trinity is not about getting support for the newest technologies, it is about stability and a lack of at least a part of modern backdoors managed from invisible BIOS trojans which (backdoors) are most likely present in KDE4 and KDE5. Most likely modern KDEs just allow to manage records via network sockets by RPC calls and that is the problem because trojans have access to network interface while it is not easy for them to interact directly via ABI APIs.
It is like a ban of a person on his own PC ("personal computer"), what to say when someone gets banned in a server managed social network if they can ban even Knotes via IntelME like probes most likely even via communication channel in a power line.
It is a big fake that personal computers are personal since there is sometimes too much undesirable activity of some agencies.
My recordings in Trinity Knotes never disappeared while it happened even in the latest version of KDE4 already using database for notes storage on a modern computer with IntelME probes. After replacing KDE4 by Trinity it did not happen anymore and a few months later I also disabled IntelME mei kernel drivers.
There are many opinions of users who loved KDE3, that KDE5 is just a disaster in terms of which road is chosen for its development.
The "version collisions" of which you speak are more likely the more backported packages that are installed so trying to install everything you can from backports doesn't make much sense IMO.
When I got a version collision earlier I just installed the same with the option -t=ascii-backports
And finally I ended up with dist-upgrade -t=ascii-backports and almost everything works very well and smooth.
The only problem I get now: Rust 1.41.1+dfsg1-1~deb9u1 is not compatible with my old CPU.
Shell I try to recompile it from sources or use some type of rustup?
Actually I just wanted to play with Rust and could not, I am mainly a DotNet coder, but interested in learning Rust.
What is the best method to get a list of packages for a downgrade if I have a list of packages those I would like to keep at backports level?
Simple subset subtraction would not work because there are dependencies.
dpkg -al | grep "~bpo" | wc
466 4805 83673
aptitude search '?narrow(?installed, ?archive(oldstable-backports))' | wc
450 4470 29919
I guess, almost the same can be achieved by a command like:
dpkg -al | grep "~bpo"
bimon wrote:Is there a command which could downgrade or at least indicate a list of all backported packages
aptitude search '?narrow(?installed, ?archive(ascii-backports))'
Thanks for the suggestion, but it does not display anything to me.
You use the software packages you need no matter where they come from. Should you encounter problems, you solve them or reset the mess.
A few days ago I had to install libc-2.32 and the dependencies from Ubuntu just to solve dependency problems with the Firefox plugin Scrapbee. It works great.
You do not have to be rigid and obey authorities. It is better and more instructive to test yourself.
I prefer to have such things in KVM virtual machines and connect to them via ssh -X, which displays them in Trinity on ASCII.
But Trinity is a mess. Tested it last summer. When I started up and saw it, it was like coming home. I screamed right out. Good old KDE 3. I've been missing it. But after a few days I discovered that most of it was so outdated (there have been a lot of new standards and the like) that it became problematic to use it. Much more problematic than mixing software packages between different distributions and versions.
I have found Trinity the most rock solid reliable DE and still convenient enough at the same time, it looks for me like good old Windows XP I liked so much earlier.
Even Trinity v14.0.6 could display anything I wanted on ASCII and very seldom something from a virtual machine.
It excellently displays Microsoft Office 2010 and other programs from WINE, anything GUI related from Devuan ASCII repo I have ever tried, any Java programs, and I need nothing more.
Can you please indicate what are you missing in Trinity?
As for me I like Trinity on ASCII because I am sure they are so reliably rock solid that I will not stuck with trying to fix many different new things and spend hours/days or even weeks on that what can happen on rolling distros like Arch or even on Devuan testing.
And still ASCII is a very modern OS for me, it has ZFS, security fixes, capable to run anything modern in a KVM VM with Ceres, Arch, GUIX, etc. guests with a narrow subset of specialized software installed on each of them, I almost do not care if anyone from them fails because all of them running from zvols with snapshots.
Until I have created this thread yesterday I even forgot when I had any new unexpected problem with ASCII. But I had to replace KDE by Trinity about a year ago, KDE4 was hardly tolerant (after they changed where settings are kept, in a database instead of files), but KDE5 is a complete mess for me. I am not interested in so rapid progress when they break old things every 3-6 months, I am not a free of charge tester (and not a tester at all) for their DE experiments.
It looks like they do another Windows 10 rebranded as Vulkan+KDE5, if I ever need this mass surveillance probe sometimes for a play, I can temporary start it in a VM on a separated dedicated physical host (like a double or triple condom if someone likes this analogy) to avoid it even run on the same CPU as my valuable data.
bimon wrote:Do you mean that it is better to narrow upgrades to backports only for a very few set of packages which are needed very much?
Yes, that is the official recommendation from the Debian developers:
Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!
It is therefore recommended to only select single backported packages that fit your needs, and not use all available backports.
It is sometimes very difficult to resolve all version conflicts without just dist-upgrade to the very latest including backports which makes the whole process very smooth, and I have never experienced any stability issues related to oldstable distro problems though using all backports too. I agree that it would be nicer to stay at distro level versions where possible to avoid unexpected unnoticed problems from a next version of the distro.
Is there a command which could downgrade or at least indicate a list of all backported packages which could be downgraded to oldstable except a few ones manually choosen and all their required dependents to resolve version mess easier?
Like deborphan --guess-all for finding out unused packages?
Oh, sorry, it is my fault, a few months ago I have removed Trinity ld.so config trinitylibs.conf from /etc/ld.so.conf.d and used cached state of ld.so.conf
Java upgrade regenerated ld.so cache and therefore removed Trinity libs from ld.so.conf cache, fixed it and it works fine now.
bimon wrote:apt-get dist-upgrade -t=ascii-backports
Attempting to upgrade the entire system from a backports repository is a really bad idea.
Do you mean that it is better to narrow upgrades to backports only for a very few set of packages which are needed very much?
I am not sure if it is possible at all to avoid version collisions, it is easier to keep the latest available versions for all packages.
I have used to dist-upgrade from a backports since I began using Debian since etch v4 and it never broke my system ever.
Generally at first I dist-upgrade from the current (generally oldstable) repo and only then from backports, it always worked fine for me for many years, it was rock solid that is why I was often at oldstable level. It is first time since etch when I see an upgrade from backports in oldstable to break something, earlier it could be used in production without worrying breaks something, well anyway I always do zfs snapshots of course.
Even for this Devuan ASCII earlier during about two years I have made dist-upgrade from backports many times already generally about each 3 months just to include all available packages into upgrade and it worked fine up to this point of time.
I guess Java upgrade may somehow break paths for binaries or libraries, because according to the log Trinity after Java upgrade cannot find its library which is still present on the disk actually in the same place as earlier.
/opt/trinity/bin/tdm_greet: error while loading shared libraries: libtderandr.so.0: cannot open shared object file: No such file or directory
The file path is: /opt/trinity/lib/libtderandr.so.0
I have narrowed it down to these packages:
apt-get install openjdk-8-jdk openjdk-8-jre -t=ascii-backports
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
openjdk-8-jdk-headless openjdk-8-jre-headless
Suggested packages:
openjdk-8-demo openjdk-8-source visualvm icedtea-8-plugin fonts-indic
The following packages will be upgraded:
openjdk-8-jdk openjdk-8-jdk-headless openjdk-8-jre openjdk-8-jre-headless
4 upgraded, 0 newly installed, 0 to remove and 154 not upgraded.
Need to get 0 B/38.2 MB of archives.
After this operation, 105 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 614763 files and directories currently installed.)
Preparing to unpack .../openjdk-8-jdk_8u275-b01-1~deb9u1_amd64.deb ...
Unpacking openjdk-8-jdk:amd64 (8u275-b01-1~deb9u1) over (8u272-b10-0+deb9u1) ...
Preparing to unpack .../openjdk-8-jdk-headless_8u275-b01-1~deb9u1_amd64.deb ...
Unpacking openjdk-8-jdk-headless:amd64 (8u275-b01-1~deb9u1) over (8u272-b10-0+deb9u1) ...
Preparing to unpack .../openjdk-8-jre_8u275-b01-1~deb9u1_amd64.deb ...
Unpacking openjdk-8-jre:amd64 (8u275-b01-1~deb9u1) over (8u272-b10-0+deb9u1) ...
Preparing to unpack .../openjdk-8-jre-headless_8u275-b01-1~deb9u1_amd64.deb ...
Unpacking openjdk-8-jre-headless:amd64 (8u275-b01-1~deb9u1) over (8u272-b10-0+deb9u1) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for desktop-file-utils (0.23-1) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Processing triggers for hicolor-icon-theme (0.15-1) ...
Setting up openjdk-8-jre-headless:amd64 (8u275-b01-1~deb9u1) ...
update-binfmts: warning: current package is openjdk-8, but binary format already installed by openjdk-6
Setting up openjdk-8-jdk-headless:amd64 (8u275-b01-1~deb9u1) ...
Setting up openjdk-8-jre:amd64 (8u275-b01-1~deb9u1) ...
Setting up openjdk-8-jdk:amd64 (8u275-b01-1~deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Full list:
The following packages will be upgraded:
openjdk-8-jdk openjdk-8-jdk-headless openjdk-8-jre openjdk-8-jre-headless
This definitely breaks Trinity, just tested this a few minutes ago again.
May be my package hold list somehow is relevant to the problem?