Re: USB WiFi Adapter

[Timothy M Butterworth]

On Wed, Aug 24, 2022 at 9:45 PM John Scott  wrote:

> I would like to recap some points that've already been shared in this
> thread and also give some advice for those who want to use libre USB Wi-
> Fi adapters with Debian GNU/Linux.
>
> The best one can do with free software right now is 802.11n. There are
> two main families of chipsets for USB wireless adapters, ath9k_htc
> (AR7010 & AR9271) and "carl9170" (AR9170). The latter has some issues
> with 802.11n setups, so the former should be preferred.
>
> AR9271 is never dual-band capable; it is always 2.4GHz only. Whether an
> AR7010 or AR9170 adapter is dual-band capable depends on what wireless
> chip it is paired with. In general dual-band capable AR7010 adapters are
> somewhat challenging to find, but dual-band AR9170 adapters are easy to
> find.


Thanks I found a AR9271 on Amazon for $12.00 much better than $50.
https://smile.amazon.com/gp/product/B082Q2XFB9/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
I
do not need Gbps speeds as my connectivity bottle necks on my 4G LTE home
internet at 600 Kbps.



> For those interested in the technical details, ath9k_htc uses a custom
> Xtensa CPU and as such requires a custom cross toolchain. Currently we
> build this free firmware in Debian completely from source, which is
> quite an achievement! I'm the current maintainer of open-ath9k-htc-
> firmware in Debian (more on that package later), but much credit goes to
> the former maintainer Oleksij Rempel, especially for his encouragement
> of me. AR9170 uses an ordinary SuperH-2 CPU, and as such the carl9170
> firmware can be built with a standard SuperH cross toolchain. I've
> currently packaged gcc-sh-elf and binutils-sh-elf in Debian Unstable, so
> that when I get around to it (or when someone I can mentor expresses
> interest 😉️) we can build carl9170 from source as well.
>
> The firmware for AR9170 (AKA carl9170) is currently shipped in the
> firmware-linux-free package. However, due to complicated historical
> reasons, the firmware for ath9k_htc is in a separate firmware-ath9k-htc
> package, which tragically is not installed by default like all other
> free firmware is. There is a common misconception that because ath9k_htc
> adapters don't work out-of-the-box, but because the firmware also
> happens to be in the non-free firmware-atheros package, that this is
> actually non-free. That's not true; it's a fluke that the ath9k_htc
> firmware is in firmware-atheros, and we're working to get it removed
> from there.
>
> So here's what I want to emphasize: if there's a chance you'll be using
> an ath9k_htc adapter, install the firmware-ath9k-htc package. If you
> don't know whether the adapter you have (or will have) has ath9k_htc,
> installing that package won't hurt.
>
> In general, for issues such as this, one should consult the Free
> Software Foundation's Respects Your Freedom program, which certifies
> devices that are guaranteed to be the best one can do with free
> software. ThinkPenguin is just one of many vendors that sells USB
> wireless adapters that work with free software+firmware.
>
> Also, neither carl9170 nor ath9k_htc work with the Debian Installer
> right now, so if one needs to install over Wi-Fi, the Live installer
> should be considered.
>
> Disclaimer: I have been compensated by ThinkPenguin, an FSF RYF vendor,
> for my Debian wireless packaging work.
>
> If anyone has questions on the matter, or would like to help with
> wireless hacking, anyone is welcome to reach me privately.
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: USB WiFi Adapter

[John Scott]

I would like to recap some points that've already been shared in this
thread and also give some advice for those who want to use libre USB Wi-
Fi adapters with Debian GNU/Linux.

The best one can do with free software right now is 802.11n. There are
two main families of chipsets for USB wireless adapters, ath9k_htc
(AR7010 & AR9271) and "carl9170" (AR9170). The latter has some issues
with 802.11n setups, so the former should be preferred.

AR9271 is never dual-band capable; it is always 2.4GHz only. Whether an
AR7010 or AR9170 adapter is dual-band capable depends on what wireless
chip it is paired with. In general dual-band capable AR7010 adapters are
somewhat challenging to find, but dual-band AR9170 adapters are easy to
find. 

For those interested in the technical details, ath9k_htc uses a custom
Xtensa CPU and as such requires a custom cross toolchain. Currently we
build this free firmware in Debian completely from source, which is
quite an achievement! I'm the current maintainer of open-ath9k-htc-
firmware in Debian (more on that package later), but much credit goes to
the former maintainer Oleksij Rempel, especially for his encouragement
of me. AR9170 uses an ordinary SuperH-2 CPU, and as such the carl9170
firmware can be built with a standard SuperH cross toolchain. I've
currently packaged gcc-sh-elf and binutils-sh-elf in Debian Unstable, so
that when I get around to it (or when someone I can mentor expresses
interest 😉️) we can build carl9170 from source as well.

The firmware for AR9170 (AKA carl9170) is currently shipped in the
firmware-linux-free package. However, due to complicated historical
reasons, the firmware for ath9k_htc is in a separate firmware-ath9k-htc
package, which tragically is not installed by default like all other
free firmware is. There is a common misconception that because ath9k_htc
adapters don't work out-of-the-box, but because the firmware also
happens to be in the non-free firmware-atheros package, that this is
actually non-free. That's not true; it's a fluke that the ath9k_htc
firmware is in firmware-atheros, and we're working to get it removed
from there.

So here's what I want to emphasize: if there's a chance you'll be using
an ath9k_htc adapter, install the firmware-ath9k-htc package. If you
don't know whether the adapter you have (or will have) has ath9k_htc,
installing that package won't hurt.

In general, for issues such as this, one should consult the Free
Software Foundation's Respects Your Freedom program, which certifies
devices that are guaranteed to be the best one can do with free
software. ThinkPenguin is just one of many vendors that sells USB
wireless adapters that work with free software+firmware.

Also, neither carl9170 nor ath9k_htc work with the Debian Installer
right now, so if one needs to install over Wi-Fi, the Live installer
should be considered.

Disclaimer: I have been compensated by ThinkPenguin, an FSF RYF vendor,
for my Debian wireless packaging work.

If anyone has questions on the matter, or would like to help with
wireless hacking, anyone is welcome to reach me privately.


signature.asc
Description: This is a digitally signed message part

Re: still blue

[Emanuel Berg]

Thomas Schmitt wrote:

>> I have a programmable keyboard so I've done some of that,
>> this new idea would be to have a all-blue, all-green etc
>> keyboard randomized each time,
>
> So i guessed that it's about something like these
>   https://www.amazon.com/programmable-keyboard/s?k=programmable+keyboard

Sure, the keyboard is a Logitech G Pro TKL with the US layout
suitable for programming (and writing in English), TKL =
tenkeyless or no numpad as I'd say it, and that's suitable for
me since those keys are too far from asdf and jkl; anyway, the
programmable part is also SUITABLE for me since I love
programming and colors and also programming for the physical
world :D

  https://dataswamp.org/~incal/kb/kb-full-group.conf
  https://dataswamp.org/~incal/kb/kb-bright-small.conf
  https://dataswamp.org/~incal/conf/.zsh/led-kb

-- 
underground experts united
https://dataswamp.org/~incal

Re: USB WiFi Adapter

[Andrew M.A. Cater]

On Wed, Aug 24, 2022 at 03:11:45AM +0200, basti wrote:
> https://elinux.org/RPi_USB_Wi-Fi_Adapters#Working_USB_Wi-Fi_Adapters
> 
> Am 24.08.22 um 01:55 schrieb Timothy M Butterworth:
> > All,
> > 
> > Can anyone recommend a USB WiFi adapter that will work without binary
> > blob proprietary drivers?
> > 
> > Thanks
> > 
> > Tim
> > 
> > -- 
> > ⢀⣴⠾⠻⢶⣦⠀
> > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ 
> > ⠈⠳⣄⠀⠀
>

Very old Atheros chipsets have some free firmware, I think.

If you can find them, those using Ath9k now have a free firmware and Atheros
 AR9271 

Essentially almost none now - which is why ThinkPenguin are so expensive. Oh
and as someone pointed out, you still need *a* blob to deal with regulatory
stuff, esp. in USA.

See also one of the very valid reasons why we're talking about firmware over
in debian-vote at the moment.

All the very best, as ever,

Andy Cater

Re: still blue

[Thomas Schmitt]

Hi,

i wrote:
> > Either by your keyborad lights or by above xterm
> > color setting.

Emanuel Berg wrote:
> :O
> Did I say that or did you read my mind?

In the original post of Mon, 25 Jul 2022 10:17:30 +0200, you wrote:

>...> I have a programmable keyboard so I've done some of that [1],
>...> this new idea would be to have a all-blue, all-green etc keyboard
>...> randomized each time,

So i guessed that it's about something like these
  https://www.amazon.com/programmable-keyboard/s?k=programmable+keyboard


Have a nice day :)

Thomas

Re: still blue

[Emanuel Berg]

Thomas Schmitt wrote:

> So i added the constraint that (Red - Green) must not be
> smaller than -64 and not larger than +32. This made the
> blueish impression quite stable.

OK! I added that ...

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/color-incal.el

(require 'math)

(defun color-p (c)
  (and (integerp c)
   (<= 0  c)
   (< c (** 2 8)) ))

(defun blue-p (r g b)
  (unless (and (color-p r)
   (color-p g)
   (color-p b) )
(error "Bogus data") )
  (let*((min-adv (** 2 6))
(rg  (ceil (/ (+ r g) 2.0)))
(diff(- b rg))
(rg-diff (- r g)) )
(and (<= min-adv diff)
 (< -64 rg-diff)
 (< rg-diff 32) )))

;; (blue-p   0   0  64) ; t
;; (blue-p   1   0  64) ; nil
;; (blue-p 191 191 255) ; t
;; (blue-p 191 192 255) ; nil

> I think the ultimate test for correctness it the personal
> impression of the colors.

Indeed, why not?

> Either by your keyborad lights or by above xterm
> color setting.

:O

Did I say that or did you read my mind?

Indeed, I would like to have "all blue" and all-green random
commands for the keyboard on a key-by-key basis :)

https://dataswamp.org/~incal/#hw

-- 
underground experts united
https://dataswamp.org/~incal

Re: Bookworm : graphic glitches all over my screen after upgrade

[piorunz]

On 24/08/2022 10:39, rudu wrote:

Then a reboot and ... bingo ! The artefacts were gone, everything back
in order.

So Sven, you must be right as I can see some mesa packages removed or
downgraded in my last move, hope that bug will be resolved soon.

I know it's a bit late, but Piotr asked me for an output, here it is :
$ inxi -G
Graphics:
   Device-1: NVIDIA G96C [GeForce 9400 GT] driver: nouveau v: kernel
   Display: x11 server: X.Org v: 1.20.11 with: Xwayland driver: X:
     loaded: modesetting gpu: nouveau resolution: 1920x1080~60Hz
   OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5

And for good mesure :
$ uname -a && cat /etc/debian_version
Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) x86_64
GNU/Linux
bookworm/sid

Thanks again to Piotr and Sven and all the subscribers of this great list
Rudu


Great to hear! I am glad you can enjoy your Debian system again. :)

Looking at your kernel version, why you are running two years old
kernel? Support for this kernel has ended upstream, your system is
vulnerable to security issues.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Will firefox-esr move to version 102 in bullseye?

[Tixy]

On Wed, 2022-08-24 at 21:13 +0200, Sven Joachim wrote:
[...]
> For Debian stable, I expect Firefox and Thunderbird to move to the 102
> branch after the next Bullseye point release, scheduled for September
> 10[1].  To build them, at least rustc 1.59 is needed, and Bullseye
> currently only has version 1.51 (packaged as rustc-mozilla).

I'm getting deja vu here [1], hopefully we won't be left with an
insecure Firefox in Debian this time.

[1] https://lists.debian.org/debian-user/2021/12/msg00260.html

-- 
Tixy

Re: Will firefox-esr move to version 102 in bullseye?

[Sven Joachim]

On 2022-08-24 15:01 -0400, Greg Wooledge wrote:

> On Wed, Aug 24, 2022 at 07:52:44PM +0100, Tixy wrote:
>> Mozilla stops supporting the old ESR a few months after a new one is
>> released [1]. So I assume Debian would ship the new one, certainly at
>> least at the point the old one gets known security vulnerabilities.
>>
>> [1] https://support.mozilla.org/en-US/kb/firefox-esr-release-cycle
>
> Yes, this is correct.  A current timeline seems to be here:
>
> https://wiki.mozilla.org/Release_Management/Calendar
>
> Looking at the ESR column in the first table, 2022-08-23 brought us
> ESR versions 91.13 and 102.2, while 2022-09-20 will have only version
> 102.3.
>
> So, as of Sept. 20th (projected), the 91.x ESR branch will be unsupported,
> and we'll all have to move to the 102.x branch, whether we want it or not.

For Debian stable, I expect Firefox and Thunderbird to move to the 102
branch after the next Bullseye point release, scheduled for September
10[1].  To build them, at least rustc 1.59 is needed, and Bullseye
currently only has version 1.51 (packaged as rustc-mozilla).

Cheers,
   Sven


1. https://lists.debian.org/debian-live/2022/08/msg6.html

Re: Will firefox-esr move to version 102 in bullseye?

[Greg Wooledge]

On Wed, Aug 24, 2022 at 07:52:44PM +0100, Tixy wrote:
> Mozilla stops supporting the old ESR a few months after a new one is
> released [1]. So I assume Debian would ship the new one, certainly at
> least at the point the old one gets known security vulnerabilities.
> 
> [1] https://support.mozilla.org/en-US/kb/firefox-esr-release-cycle

Yes, this is correct.  A current timeline seems to be here:

https://wiki.mozilla.org/Release_Management/Calendar

Looking at the ESR column in the first table, 2022-08-23 brought us
ESR versions 91.13 and 102.2, while 2022-09-20 will have only version
102.3.

So, as of Sept. 20th (projected), the 91.x ESR branch will be unsupported,
and we'll all have to move to the 102.x branch, whether we want it or not.

Re: Will firefox-esr move to version 102 in bullseye?

[Tixy]

On Wed, 2022-08-24 at 20:13 +0200, Anders Andersson wrote:
> While investigating my options for hardware acceleration in the
> browser I found a snippet on the debian wiki that I'm trying to parse:
> 
> From: https://wiki.debian.org/Firefox#Hardware_Video_Acceleration
> > This is for Debian 11 / Bullseye
> > [...]
> > firefox-esr is projected to be updated to version 102 sometime in 3Q 2022.
> 
> Normally I would not expect anything in the stable distribution to get
> a large update, but I know that firefox has been treated differently
> in the past, and the wording in the wiki made me wonder.
> 

Mozilla stops supporting the old ESR a few months after a new one is
released [1]. So I assume Debian would ship the new one, certainly at
least at the point the old one gets known security vulnerabilities.

[1] https://support.mozilla.org/en-US/kb/firefox-esr-release-cycle

-- 
Tixy

Will firefox-esr move to version 102 in bullseye?

[Anders Andersson]

While investigating my options for hardware acceleration in the
browser I found a snippet on the debian wiki that I'm trying to parse:

From: https://wiki.debian.org/Firefox#Hardware_Video_Acceleration
> This is for Debian 11 / Bullseye
> [...]
> firefox-esr is projected to be updated to version 102 sometime in 3Q 2022.

Normally I would not expect anything in the stable distribution to get
a large update, but I know that firefox has been treated differently
in the past, and the wording in the wiki made me wonder.

Re: Color of the active window title bar in ubuntu-mate?

[Max Nikulin]

On 22/08/2022 18:02, Greg Wooledge wrote:

On Mon, Aug 22, 2022 at 10:02:22AM +, Victor Sudakov wrote:

Any applications using standard decorations (Firefox, MATE Terminal,
Google Chrome etc).


It's worth pointing out, perhaps, that Google Chrome does *not* use
the standard window manager decorations by default.  There is, however,
an option you can toggle to make it do so.

(Unless this behavior changed in some recent version -- but I doubt it.)

Firefox, on the other hand, *does* use the regular widgets.


Behavior of Firefox depends on GTK_CSD and XDG_CURRENT_DESKTOP 
environment variables. Some time ago there were more if's for Gnome, 
KDE, etc.:


- 
https://hg.mozilla.org/integration/autoland/file/d58f8264/widget/gtk/nsWindow.cpp#l9192
- 
https://hg.mozilla.org/integration/autoland/file/tip/widget/gtk/nsWindow.cpp#l9192

The latter link is for current version without fixed revision.

"Customize toolbar" dialogue has "Titlebar" checkbox to change behavior. 
Recently I faced an issue with fluxbox and I blamed client side 
decoration at first, so I tried to disable it.

Re: Bookworm: Firefox v102 seems to be hanging quite often

[piorunz]

On 24/08/2022 10:16, local10 wrote:

Aug 23, 2022, 13:34 by pior...@gmx.com:


On 22/08/2022 21:19, local10 wrote:


Have upgraded to FF v102 a couple of days ago but it looks like something isn't 
quite right with this version of FF. Have to restart it once or twice a day 
because FF just stops responding. The issue doesn't seem to be related to any 
particular site. Same hardware, same Debian (Bookworm), same FF plugins.


Nobody else having issues with Firefox v102?



I can confirm that previous and current versions are very stable for me
in Debian Bookworm (testing repos).
I use Firefox in firejail and it never hangs or crashes.



Interesting, thanks. Are using NoScript and/or uBlock Origin plugins?


No, I use Adblock Plus, Privacy Badger and few more blockers.
If you suspect these two you mentioned, disable them for a day or two
and check the result.

And check fresh profile - start firefox via "firefox -P" command and
create new profile.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Disk error?

[Tixy]

On Wed, 2022-08-24 at 11:48 +0100, Tim Woodall wrote:
> On Wed, 24 Aug 2022, Andy Smith wrote:
> 
> > Hello,
> > 
> > On Wed, Aug 24, 2022 at 08:23:11AM +0100, Tim Woodall wrote:
> > > dpkg-deb (subprocess): decompressing archive 
> > > '/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb' 
> > > (size=4015516) member 'data.tar': lzma error: compressed data is corrupt
> > 
> > [?]
> > 
> > > Am I right that this must be a local error - apt will have verified the
> > > checksum while downloading the deb?
> > 
> > I think so. But you could confirm by downloading the .deb file
> > elsewhere and comparing using sha56sum or similar.
> > 
> Yes, the file seems good - it's cached by apt-cacher-ng.
> 
> > Assuming your local .deb file appears correct, I think I'd try
> > reading the file a number of times to check it can be reliably read.
> > 
> > If that works then I think I'd move on to a memory stress test. On
> > amd64 I'd use memtest86 but I don't know what is best for arm64.
> > 
> That's a good idea - actually this is amd64 - arm64 is being simulated.

So a bug in qemu is another possibility.

-- 
Tixy

Re: Disk error?

[piorunz]

On 24/08/2022 08:23, Tim Woodall wrote:

There's no SMART errors or anything like that either.

Anyone got any ideas - any logging I should add to try and track down
where the issue might be?


Sure, check dmesg as a first thing, if its a block device error it will
be recorded there.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Disk error?

[Tim Woodall]

On Wed, 24 Aug 2022, Andy Smith wrote:


Hello,

On Wed, Aug 24, 2022 at 08:23:11AM +0100, Tim Woodall wrote:

dpkg-deb (subprocess): decompressing archive 
'/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb' (size=4015516) 
member 'data.tar': lzma error: compressed data is corrupt


[?]


Am I right that this must be a local error - apt will have verified the
checksum while downloading the deb?


I think so. But you could confirm by downloading the .deb file
elsewhere and comparing using sha56sum or similar.


Yes, the file seems good - it's cached by apt-cacher-ng.


Assuming your local .deb file appears correct, I think I'd try
reading the file a number of times to check it can be reliably read.

If that works then I think I'd move on to a memory stress test. On
amd64 I'd use memtest86 but I don't know what is best for arm64.


That's a good idea - actually this is amd64 - arm64 is being simulated.


Cheers,
Andy

Re: Disk error?

[Andy Smith]

Hello,

On Wed, Aug 24, 2022 at 08:23:11AM +0100, Tim Woodall wrote:
> dpkg-deb (subprocess): decompressing archive 
> '/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb' 
> (size=4015516) member 'data.tar': lzma error: compressed data is corrupt

[…]

> Am I right that this must be a local error - apt will have verified the
> checksum while downloading the deb?

I think so. But you could confirm by downloading the .deb file
elsewhere and comparing using sha56sum or similar.

Assuming your local .deb file appears correct, I think I'd try
reading the file a number of times to check it can be reliably read.

If that works then I think I'd move on to a memory stress test. On
amd64 I'd use memtest86 but I don't know what is best for arm64.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Errors while performing postgresql backup (Was Re: Softraid & partclone)

[Andy Smith]

Hi Testler,

On Wed, Aug 24, 2022 at 07:54:03AM +0300, Testler Test wrote:
> > Let's see the output of "cat /proc/mdstat".
> 
> The raid status is as follows. No problem appears.
> 
> # cat /proc/mdstat
> Personalities : [raid1]
> md2 : active raid1 sdb3[1] sda3[0]
>   232623424 blocks super 1.2 [2/2] [UU]
>   bitmap: 1/2 pages [4KB], 65536KB chunk
> 
> md1 : active raid1 sdb2[1] sda2[0]
>   523264 blocks super 1.2 [2/2] [UU]
> 
> md0 : active raid1 sdb1[1] sda1[0]
>   16759808 blocks super 1.2 [2/2] [UU]

Yep, nothing to do there. Whatever problems you are seeing are not
likely to be related to the RAID layer.

What filesystem are you using on md2?

> -% Sda:

[…]

> SMART overall-health self-assessment test result: PASSED
> 
> -% sdb

[…]

> SMART overall-health self-assessment test result: PASSED

So, although it says "PASSED" for both of these, it would still be
good to look at all the attributes with "smartctl -A".

The most interesting thing to know would be the exact text of the
error messages that you are seeing (which I assume happen when you
fail to back up your database).

Are you just doing a pg_dump or are you shutting postgres down and
backing up the psql/data directory with usual filesystem tools?

Depending on what sort of errors you are seeing you may have a
damaged filesystem in which case it would be advisable to set it
read only and take an image of it to work with, so as to avoid
creating more damage.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Bookworm : graphic glitches all over my screen after upgrade

[rudu]

Piotr, Sven, Thank you for your help, see below.

Le 23/08/2022 à 20:55, piorunz a écrit :

On 23/08/2022 14:13, rudu wrote:

Hi,

Coming back from holidays, I did a pretty huge upgrade of my Bookworm
system on my aging desktop (2009).
After a reboot, what I could see is best described via this snapshot :
https://wtf.roflcopter.fr/pics/rVcN0HFu/vgQCGy7g.png


Only one thing I can think of is nouveau driver issue.
If I am not mistaken, Bookworm has libdrm-nouveau2 and
xserver-xorg-video-nouveau packages to provide nouveau driver.
Only libdrm-nouveau2 has seen new upstream release landing in bookworm
recently.

See in your apt logs if these packages were part of the upgrade you
undertaken recently? For me, history.log shows upgrade entry on
2022-08-03 (20 days ago): libdrm-nouveau2:amd64 (upgrade from version
2.4.110-1 to version 2.4.112-3).

Also please show output of
inxi -G
command in terminal. Install inxi if you haven't already.

--
With kindest regards, Piotr.


I've been already trying some downgrades, of :
Downgrade: xserver-xorg-video-nouveau:amd64 (1:1.0.17-2, 1:1.0.17-1), 
xserver-xorg-input-evdev:amd64 (1:2.10.6-2+b1, 1:2.10.6-2), 
xserver-xorg-core:amd64 (2:21.1.4-1, 2:1.20.11-1+deb11u1)

Purge: xserver-xephyr:amd64 (2:21.1.4-1)
Downgrade: xserver-xorg:amd64 (1:7.7+23, 1:7.7+22), xserver-common:amd64 
(2:21.1.4-1, 2:1.20.11-1+deb11u1)

... the stable versions of those packages.
But nothing changed.

Then, Piotr drew my attention to this libdrm-nouveau2 :
Downgrade: libdrm-nouveau2:amd64 (2.4.112-3, 2.4.104-1), 
libdrm-nouveau2:i386 (2.4.112-3, 2.4.104-1)

... still no luck.

Looking at its dependencies, I noticed a libdrm2 and libdrm-common 
packages. Their downgrade had some consequences :
Install: libllvm11:amd64 (1:11.1.0-6+b2, automatic), 
kwin-wayland-backend-x11:amd64 (4:5.25.4-2, automatic), 
libdrm-intel1:amd64 (2.4.104-1, automatic)
Downgrade: libglx-mesa0:amd64 (22.2.0~rc2-1, 20.3.5-1), libgbm1:amd64 
(22.2.0~rc2-1, 20.3.5-1), libgl1-mesa-dri:amd64 (22.2.0~rc2-1, 
20.3.5-1), libdrm-common:amd64 (2.4.112-3, 2.4.104-1), xwayland:amd64 
(2:22.1.3-1, 2:1.20.11-1+deb11u1), libglapi-mesa:amd64 (22.2.0~rc2-1, 
20.3.5-1), libdrm-amdgpu1:amd64 (2.4.112-3, 2.4.104-1), 
libdrm-radeon1:amd64 (2.4.112-3, 2.4.104-1), libdrm-radeon1:i386 
(2.4.112-3, 2.4.104-1), libdrm2:amd64 (2.4.112-3, 2.4.104-1), 
libdrm2:i386 (2.4.112-3, 2.4.104-1), libegl-mesa0:amd64 (22.2.0~rc2-1, 
20.3.5-1), libdrm-intel1:i386 (2.4.112-3, 2.4.104-1)
Remove: libxcb-present0:i386 (1.15-1), libglx-mesa0:i386 (22.2.0~rc2-1), 
libglvnd0:i386 (1.4.0-1), libxshmfence1:i386 (1.3-1), libdecor-0-0:i386 
(0.1.0-3), libfltk1.1:i386 (1.1.10-29), libwayland-cursor0:i386 
(1.21.0-1), libxcb-dri2-0:i386 (1.15-1), libxcb-dri3-0:i386 (1.15-1), 
libgbm1:i386 (22.2.0~rc2-1), libwayland-server0:i386 (1.21.0-1), 
libglx0:i386 (1.4.0-1), libdrm-nouveau2:i386 (2.4.104-1), libllvm14:i386 
(1:14.0.6-2), kwin-wayland-backend-drm:amd64 (4:5.25.4-2), libz3-4:i386 
(4.8.12-1+b1), libxcvt0:amd64 (0.1.2-1), libgl1-mesa-dri:i386 
(22.2.0~rc2-1), libxkbcommon0:i386 (1.4.1-1), freeglut3:i386 (2.8.1-6), 
libxcb-glx0:i386 (1.15-1), libwayland-egl1:i386 (1.21.0-1), 
libglapi-mesa:i386 (22.2.0~rc2-1), libsdl2-2.0-0:i386 (2.0.22+dfsg-6), 
libdrm-amdgpu1:i386 (2.4.112-3), libgl1:i386 (1.4.0-1), 
libwayland-client0:i386 (1.21.0-1), libxcb-sync1:i386 (1.15-1), 
libatomic1:i386 (12.1.0-8), libxcb-xfixes0:i386 (1.15-1)


Then a reboot and ... bingo ! The artefacts were gone, everything back 
in order.


So Sven, you must be right as I can see some mesa packages removed or 
downgraded in my last move, hope that bug will be resolved soon.


I know it's a bit late, but Piotr asked me for an output, here it is :
$ inxi -G
Graphics:
  Device-1: NVIDIA G96C [GeForce 9400 GT] driver: nouveau v: kernel
  Display: x11 server: X.Org v: 1.20.11 with: Xwayland driver: X:
    loaded: modesetting gpu: nouveau resolution: 1920x1080~60Hz
  OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5

And for good mesure :
$ uname -a && cat /etc/debian_version
Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) x86_64 
GNU/Linux

bookworm/sid

Thanks again to Piotr and Sven and all the subscribers of this great list
Rudu

Re: Bookworm: Firefox v102 seems to be hanging quite often

[local10]

Aug 23, 2022, 13:34 by pior...@gmx.com:

> On 22/08/2022 21:19, local10 wrote:
>
>>> Have upgraded to FF v102 a couple of days ago but it looks like something 
>>> isn't quite right with this version of FF. Have to restart it once or twice 
>>> a day because FF just stops responding. The issue doesn't seem to be 
>>> related to any particular site. Same hardware, same Debian (Bookworm), same 
>>> FF plugins.
>>>
>> Nobody else having issues with Firefox v102?
>>
>
> I can confirm that previous and current versions are very stable for me
> in Debian Bookworm (testing repos).
> I use Firefox in firejail and it never hangs or crashes.
>

Interesting, thanks. Are using NoScript and/or uBlock Origin plugins?

Re: Disk error?

[Marco]

Am 24. Aug 2022, um 08:23:11 Uhr schrieb Tim Woodall:

> There's no SMART errors or anything like that either.

Run badblocks to check your disk.

> Anyone got any ideas - any logging I should add to try and track down
> where the issue might be?

Check the disk with badblocks and test the installation in a fresh
installed system on another machine, e.g. virtual machine.

Disk error?

[Tim Woodall]

I got this error while installing build-essential

Preparing to unpack .../03-libperl5.34_5.34.0-5_arm64.deb ...
Unpacking libperl5.34:arm64 (5.34.0-5) ...
dpkg-deb (subprocess): decompressing archive 
'/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb' (size=4015516) 
member 'data.tar': lzma error: compressed data is corrupt
dpkg-deb: error:  subprocess returned error exit status 2
dpkg: error processing archive 
/tmp/apt-dpkg-install-zqY3js/03-libperl5.34_5.34.0-5_arm64.deb (--unpack):
 cannot copy extracted data for './usr/lib/aarch64-linux-gnu/libperl.so.5.34.0' 
to '/usr/lib/aarch64-linux-gnu/libperl.so.5.34.0.dpkg-new': unexpected end of 
file or stream

Am I right that this must be a local error - apt will have verified the
checksum while downloading the deb? (and it worked on rerunning - the
deb was in acng)

I can find nothing anywhere that suggests anything has gone wrong (other
than this error) but (and I'm sure it's a coincidence) since installing
ACNG (on the same machine) I've been getting a number of errors similar
to things like this where files appear to be corrupted but work on the
next attempt.

There's no SMART errors or anything like that either.

Anyone got any ideas - any logging I should add to try and track down
where the issue might be?

Tim.

Re: still blue

[Thomas Schmitt]

Hi,

i wrote:
> > # Minimum brightness for blue to be perceivable
> > blue_base=64
> > # Minimum advantage of blue over (red + green)/2
> > blue_advantage=64

Emanuel Berg wrote:
> Thanks a lot, this is what I had in mind exactly!

My eyes still perceived too much reddishness. They obviously need enough
green to compensate for the given red value.
So i added the constraint that (Red - Green) must not be smaller than -64
and not larger than +32. This made the blueish impression quite stable.

I also looked up in the web how to change the background color of an xterm
from inside:

  # 
https://superuser.com/questions/592090/change-xterm-change-background-color-without-clearing-the-screen
  echo -n -e '\e]11;rgb:'"$rhex"/"$ghex"/"$bhex"'\a'

(One should use a dedicated xterm for color display, because i don't know
 yet how to inquire the original bg color of the xterm.)


> Is this a correct implementation?
> (defalias '** #'expt)

Lookth like Lithp. (Not my turf.)

I think the ultimate test for correctness it the personal impression of
the colors. Either by your keyborad lights or by above xterm color setting.


Have a nice day :)

Thomas