Re: latest testing update broke my laptop

[Anssi Saari]

Stefan Monnier  writes:

> I use Debian Testing

Different story then. Breakage is expected in Testing. 

> so if you mostly reinstall from scratch when an upgrade comes along
> you'd likely be fine.

I've reinstalled Debian only once when it was time to switch to 64-bit
sometime in the decade before last. Reliability to me is the point of
Debian. Well, I have Arch too on my desktop but since I don't use it
much, usually there's some issue when upgrading.

Re: no sound after installing pulseaudio

[Christoph Brinkhaus]

Am Fri, Dec 23, 2022 at 09:12:28AM +0800 schrieb lou:

Hello Lou,

> i am running buster and install pulseaudio
> to let pulseaudio take effect i have to reboot
> but there's no sound though pavucontrol seems ok
> (pavucontrol shows sound is playing properly)
> to get sound back, i have to remove pulseaudio and reboot

With "pactl list" or "pcctl list short" you can identify some cryptic
address of your sound card.

With something as (taken from my system)
"pactl set-sink-volume alsa_output.pci-_00_14.2.analog-stereo +2%"
you can adjust the volume.

Or you simple try alsamixer which comes with some ncurses looking GUI.

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: no sound after installing pulseaudio

[lou]

Thank Jude and Christoph!

i run "pactl list":

Connection failure: Connection refused
pa_context_connect() failed: Connection refused

but in stretch, pulseaudio works after i install it

Re: Maximum time for offline updates?

[Yvan Masson]

Le 23/12/2022 à 07:50, to...@tuxteam.de a écrit :

On Thu, Dec 22, 2022 at 04:57:54PM -0500, Stefan Monnier wrote:

[...]


I find the idea of offline update rather odd: not only it's inconvenient
since the machine is unusable during this time, but on top of it, in
case of trouble, it can make it harder to fix the problem because you
may not be able to boot into a conveniently-usable system.


That was my feeling, too. Only very involved scenarios came to mind,
like "you have connectivity now, but are running on battery, and later
you'll have AC power but no connectivity" or something.

Cheers


Offline update has disadvantages, but it makes sure that every programs 
are restarted, thus avoiding strange issues or crashes due to conflicts 
in libraries versions ([1] is a KDE article that very briefly explaining 
this). In an another article I could not find anymore, someone from KDE 
explains that they receive many bug reports where issues comes from 
system update without reboot (I would also be interested to know what is 
"many" here).


Indeed, in a perfect setup, system should make a snapshot before updates 
are applied (see 6. in systemd.offline-updates manpage, note that I have 
not heard it is done yet by any distribution by default), and revert the 
changes if the update fails. Anyway, being able to fix a system that has 
been broken by *online* updates is only relevant if the user has 
technical skills to do so.


Windows, targeting both technical and non technical users, does exactly 
this. I did not use an Apple system for years, but I think it was quite 
similar for system updates. Please don't byte me ;-)


I definitely won't use those OS either unless I have to, but I admit 
they do many things very well and have competent UI designers. But our 
favorite OS is still the best because at least we have the choice 
between online and offline.


1. https://blog.neon.kde.org/2021/03/01/offline-updates-are-coming/

Regards,
Yvan


OpenPGP_signature
Description: OpenPGP digital signature

Re: no sound after installing pulseaudio

[Andrew M.A. Cater]

On Fri, Dec 23, 2022 at 06:08:01PM +0800, lou wrote:
> Thank Jude and Christoph!
> 
> i run "pactl list":
> 
> Connection failure: Connection refused
> pa_context_connect() failed: Connection refused
> 
> but in stretch, pulseaudio works after i install it
> 
>

Hi Lou,

As always, you may be better working with the most up to date stable Debian
release. Stretch is getting very old now, buster is oldstable and the
next major release is due in a few months.

Please consider updating to at least Debian 11 (bullseye).

With every good wish, as ever,

Andy Cater

Re: no sound after installing pulseaudio

[Christoph Brinkhaus]

Am Fri, Dec 23, 2022 at 06:08:01PM +0800 schrieb lou:
> Thank Jude and Christoph!

Hi Lou.
 
> i run "pactl list":
> 
> Connection failure: Connection refused
> pa_context_connect() failed: Connection refused

I have no idea why the message comes from but also how pulseaudio
communicates with the rest of the system.

Please check if pulseaudio is really running by checking with ps.
If the communication is running via dbus check if dbus is running.
If the communication is via TCP or UPD and localhost please check if
there is no firewall rule which blocks the traffic.

> but in stretch, pulseaudio works after i install it

For me its has been working using Bullseye out fo the box, too.

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: no sound after installing pulseaudio

[lou]

Thank Christoph and Andrew!

i can use stretch if i need pulseaudio

my problem is so strange that i give up

ps: Andrew, my experience shows that new isn't always better than old. 
many wifi adapter makers on Chinese market today support Windows XP for 
their new products

colorscheme in vi

[Pierre Frenkiel]

hi,
I wanted to open vi with a white background and a black fg
to do that, I put in my .vimrc, as recommended, a line
colorscheme white
that worked, except that each time I open vim, I get the message:
   cannot find color scheme 'white'
I don't worry, but is there a way to get rid of that warning?
best regards

Pierre Frenkiel

Re: colorscheme in vi

[Greg Wooledge]

On Fri, Dec 23, 2022 at 12:36:56PM +0100, Pierre Frenkiel wrote:
> I wanted to open vi with a white background and a black fg
> to do that, I put in my .vimrc, as recommended, a line
> colorscheme white
> that worked, except that each time I open vim, I get the message:
>cannot find color scheme 'white'
> I don't worry, but is there a way to get rid of that warning?

You could try using a different colorscheme.  Apparently, there's no
way to get vim to tell you their names, but the help says it looks
for "colors/{name}.vim", so you might be able to do something like
this to find them:

   locate colors | grep vim

I have no idea why a command that fails would still give you the desired
result.  Did you already have a .vimrc file before this?  Or did you
create a whole .vimrc file just for this line?

If creating the .vimrc file is what fixed it (by overriding the system
default vimrc), then you don't actually need a colorscheme line at all.
You just need a .vimrc file, and an empty one should suffice if you really
don't want any changes.

Re: no sound after installing pulseaudio

[Jude DaShiell]

Alternatively,
amixer set Master 100% unmute



Jude 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Fri, 23 Dec 2022, Christoph Brinkhaus wrote:

> Am Fri, Dec 23, 2022 at 09:12:28AM +0800 schrieb lou:
>
> Hello Lou,
>
> > i am running buster and install pulseaudio
> > to let pulseaudio take effect i have to reboot
> > but there's no sound though pavucontrol seems ok
> > (pavucontrol shows sound is playing properly)
> > to get sound back, i have to remove pulseaudio and reboot
>
> With "pactl list" or "pcctl list short" you can identify some cryptic
> address of your sound card.
>
> With something as (taken from my system)
> "pactl set-sink-volume alsa_output.pci-_00_14.2.analog-stereo +2%"
> you can adjust the volume.
>
> Or you simple try alsamixer which comes with some ncurses looking GUI.
>
> Kind regards,
> Christoph
>

Re: colorscheme in vi

[tomas]

On Fri, Dec 23, 2022 at 07:31:14AM -0500, Greg Wooledge wrote:
> On Fri, Dec 23, 2022 at 12:36:56PM +0100, Pierre Frenkiel wrote:
> > I wanted to open vi with a white background and a black fg
> > to do that, I put in my .vimrc, as recommended, a line
> > colorscheme white
> > that worked, except that each time I open vim, I get the message:
> >cannot find color scheme 'white'
> > I don't worry, but is there a way to get rid of that warning?
> 
> You could try using a different colorscheme.  Apparently, there's no
> way to get vim to tell you their names [...]

Try :colorscheme  

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: colorscheme in vi

[David]

On Fri, 23 Dec 2022 at 23:31, Greg Wooledge  wrote:
> On Fri, Dec 23, 2022 at 12:36:56PM +0100, Pierre Frenkiel wrote:

> > I wanted to open vi with a white background and a black fg
> > to do that, I put in my .vimrc, as recommended, a line
> > colorscheme white

"as recommended" by whom?

Because there is no colorscheme named "white" in Debian's
vim. The colorschemes are in /usr/share/vim/vim82/colors


> > that worked, except that each time I open vim, I get the message:
> >cannot find color scheme 'white'
> > I don't worry, but is there a way to get rid of that warning?
>
> You could try using a different colorscheme.  Apparently, there's no
> way to get vim to tell you their names,

To see the available colorschemes, do this in vim:
:colorscheme

Re: no sound after installing pulseaudio

[lou]

Thank Jude!

i try your command anyway though i have said i give up

i install pulseaudio again and have to reboot to get it to work

then i run your command, it solves my problem, Thanks!

Re: no sound after installing pulseaudio

[lou]

Christoph, your "pactl list" command didn't work because i didn't reboot 
buster after installing pulseaudio, Thanks anyway!

Re: colorscheme in vi

[Max Nikulin]

On 23/12/2022 18:36, Pierre Frenkiel wrote:

I wanted to open vi with a white background and a black fg
to do that,


Do you mean graphical gvim window or vim running in a terminal? In the 
latter case which one and should vim follow terminal background? Is tmux 
or screen involved?


Besides colorscheme there is another setting
:set background=dark
or
:set background=light
I do not remember if proper value is reliably chosen during startup e.g. 
for terminal applications setting TERM=xterm-256color


Finally, if
colorscheme white
works despite the warning, what happens if you commented out or removing 
this line?

Re: colorscheme in vi

[Nate Bargmann]

* On 2022 23 Dec 06:54 -0600, David wrote:
> On Fri, 23 Dec 2022 at 23:31, Greg Wooledge  wrote:
> > On Fri, Dec 23, 2022 at 12:36:56PM +0100, Pierre Frenkiel wrote:
> 
> > > I wanted to open vi with a white background and a black fg
> > > to do that, I put in my .vimrc, as recommended, a line
> > > colorscheme white
> 
> "as recommended" by whom?
> 
> Because there is no colorscheme named "white" in Debian's
> vim. The colorschemes are in /usr/share/vim/vim82/colors

The problem as I see it is that he wants reverse colors in 'vi' but
edited '.vimrc'.  Historically those are two different programs but the
Debian alternatives eventually points 'vi' to 'vim.basic'.  I would
presume that a setting that works in historic 'vi' might not be
supported by 'vim.basic'.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: colorscheme in vi

[Pierre Frenkiel]

On Fri, 23 Dec 2022, Max Nikulin wrote:


On 23/12/2022 18:36, Pierre Frenkiel wrote:

I wanted to open vi with a white background and a black fg
to do that,


Do you mean graphical gvim window or vim running in a terminal? In the latter 
case which one and should vim follow terminal background? Is tmux or screen 
involved?


Besides colorscheme there is another setting
   :set background=dark
or
   :set background=light
I do not remember if proper value is reliably chosen during startup e.g. for 
terminal applications setting TERM=xterm-256color


Finally, if
   colorscheme white
works despite the warning, what happens if you commented out or removing this 
line?


hi, 
thank you for your post,

At last I actually did that, i.e. I replaced the vi binary by a script
which redirects stderr to /dev/null, and that works perfectly
best regards,
Pierre Frenkiel

Re: Maximum time for offline updates?

[Stefan Monnier]

>>> I find the idea of offline update rather odd: not only it's inconvenient
>>> since the machine is unusable during this time, but on top of it, in
>>> case of trouble, it can make it harder to fix the problem because you
>>> may not be able to boot into a conveniently-usable system.
>> That was my feeling, too. Only very involved scenarios came to mind,
>> like "you have connectivity now, but are running on battery, and later
>> you'll have AC power but no connectivity" or something.

That scenario is already (arguably better) served by the distinction
between downloading the update(s) and installing them, which APT
supports already.  No need to reboot into a special mode to perform
the install.

> Offline update has disadvantages, but it makes sure that every programs are
> restarted, thus avoiding strange issues or crashes due to conflicts in
> libraries versions ([1] is a KDE article that very briefly explaining
> this).  In an another article I could not find anymore, someone from KDE
> explains that they receive many bug reports where issues comes from system
> update without reboot (I would also be interested to know what is "many"
> here).

Rebooting after the updates is different from the offline update you describe.

> Indeed, in a perfect setup, system should make a snapshot before updates are
> applied (see 6. in systemd.offline-updates manpage, note that I have not
> heard it is done yet by any distribution by default), and revert the changes
> if the update fails.

[ Agreed.  Ideally the updates should be performed in a "clone" of the current
  system, and only after it's done and sanity-checked should we switch to
  the new system.  We've known how to do that for many years (thanks to
  IBM's main frames, for example).  ]

> Anyway, being able to fix a system that has been broken by *online*
> updates is only relevant if the user has technical skills to do so.

But that is no different than for offline updates, is it?

> Windows, targeting both technical and non technical users, does exactly
> this. I did not use an Apple system for years, but I think it was quite
> similar for system updates. Please don't byte me ;-)

Indeed.  But they have different trade-offs.  They want to have as much
control as possible over the process so as to get as close as possible
to the "just works!" black box.  Basically they want their system
partition to be a binary blob that the end users can't even look at, so
updates merely require replacing one known binary blob with another, and
to minimize external factors they kick the users out before performing
the updates since for them users are fundamentally an annoyance (a
source of unpredictability).
And if something goes wrong along the way, their answer is "reinstall".

Debian's updates are hence quite different due to the basic
philosophical premise that user are here to help and that there isn't
just one "Debian version 10.1" but instead every Debian system is
different from the others.
So the upgrade scripts have to be a lot more careful to handle a much
wilder variety of situations, and they go through extra efforts to
interact correctly with a fully running system.

Indeed, for major upgrades, rebooting *some time* after the upgrade is
often a good idea, but that's different from the offline update
you describe.


Stefan "sorry for having hijacked your thread"

Re: xscreensaver problem

[Pierre Frenkiel]

Pierre Frenkiel

On Thu, 22 Dec 2022, Pierre Frenkiel wrote:


I have now a big problem with xscreensaver.
Up to yesterday, it worked perfectly, but I had to re-install Debian
on my PC, and now if fails
when I run "xscreensaver" I get:
   xscreensaver-systemd: 13:59:54: user bus connection failed: No medium 
found

If I run "xscreensaver-demo", I get "Segmentation fault"
I was unable to find what changes from my previous install to the new one
can explain that.
Has anybody an idea?
best regards,

Pierre Frenkiel


I found a good work around: instead of calling xscreensaver, I call
one on the binaries provided with the program: scooter
and that works perfectly
I'm just curious to understand why the xscreensaver itself no more works...

Re: Maximum time for offline updates?

[Yvan Masson]

Le 23/12/2022 à 16:03, Stefan Monnier a écrit :

I find the idea of offline update rather odd: not only it's inconvenient
since the machine is unusable during this time, but on top of it, in
case of trouble, it can make it harder to fix the problem because you
may not be able to boot into a conveniently-usable system.

That was my feeling, too. Only very involved scenarios came to mind,
like "you have connectivity now, but are running on battery, and later
you'll have AC power but no connectivity" or something.


That scenario is already (arguably better) served by the distinction
between downloading the update(s) and installing them, which APT
supports already.  No need to reboot into a special mode to perform
the install.

Yes APT can do that. Offline update also ensures that :
- the computer is not used while applying updates
- the computer is rebooted just after applying updates



Offline update has disadvantages, but it makes sure that every programs are
restarted, thus avoiding strange issues or crashes due to conflicts in
libraries versions ([1] is a KDE article that very briefly explaining
this).  In an another article I could not find anymore, someone from KDE
explains that they receive many bug reports where issues comes from system
update without reboot (I would also be interested to know what is "many"
here).


Rebooting after the updates is different from the offline update you describe.

Yes.>

Indeed, in a perfect setup, system should make a snapshot before updates are
applied (see 6. in systemd.offline-updates manpage, note that I have not
heard it is done yet by any distribution by default), and revert the changes
if the update fails.


[ Agreed.  Ideally the updates should be performed in a "clone" of the current
   system, and only after it's done and sanity-checked should we switch to
   the new system.  We've known how to do that for many years (thanks to
   IBM's main frames, for example).  ]


Anyway, being able to fix a system that has been broken by *online*
updates is only relevant if the user has technical skills to do so.


But that is no different than for offline updates, is it?

I agree.



Windows, targeting both technical and non technical users, does exactly
this. I did not use an Apple system for years, but I think it was quite
similar for system updates. Please don't byte me ;-)


Indeed.  But they have different trade-offs.  They want to have as much
control as possible over the process so as to get as close as possible
to the "just works!" black box.  Basically they want their system
partition to be a binary blob that the end users can't even look at, so
updates merely require replacing one known binary blob with another, and
to minimize external factors they kick the users out before performing
the updates since for them users are fundamentally an annoyance (a
source of unpredictability).
And if something goes wrong along the way, their answer is "reinstall".

Debian's updates are hence quite different due to the basic
philosophical premise that user are here to help and that there isn't
just one "Debian version 10.1" but instead every Debian system is
different from the others.
So the upgrade scripts have to be a lot more careful to handle a much
wilder variety of situations, and they go through extra efforts to
interact correctly with a fully running system.

Indeed, for major upgrades, rebooting *some time* after the upgrade is
often a good idea, but that's different from the offline update
you describe.
I am not an expert, but I have seen many times that just after some 
"minor" *online* update, let's say LibreOffice and a few libraries, that 
a very strange bug appears (some application refuses to start, clicking 
on a button does nothing, and so on). And rebooting or re-opening the 
session fixed that.


Anyway, I am sorry but I have probably not the skills to discuss if 
offline updates are a good thing or not (I just think "it depends", I 
personally also prefer to update via command line and then reboot if 
necessary). But I really want to find why it did stop after ten minutes, 
because other non technical people might encounter this issue and won't 
be able to fix their system.



 Stefan "sorry for having hijacked your thread"

No worries, it is always interesting to know how other think :-)




OpenPGP_signature
Description: OpenPGP digital signature

Re: no sound after installing pulseaudio

[Jude DaShiell]

I'm living on the command line most of the time.  If sound doesn't work
over here for me since I need to use a screen reader, the computer becomes
a paperweight.  I'm glad that fix worked for you and I should have told
you to do that command as root.  If that command ever fails, alsa got
locked up and you need to locate alsa.lck in the lock directory and delete
it then run the amixer command again.  I've had that happen earlier myself
from time to time and figure it's a good bit of information to have as a
back out method.



Jude  "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Fri, 23 Dec 2022, lou wrote:

> Thank Jude!
>
> i try your command anyway though i have said i give up
>
> i install pulseaudio again and have to reboot to get it to work
>
> then i run your command, it solves my problem, Thanks!
>
>
>

Re: colorscheme in vi

[Curt]

On 2022-12-23, David  wrote:
>>
>> You could try using a different colorscheme.  Apparently, there's no
>> way to get vim to tell you their names,
>
> To see the available colorschemes, do this in vim:
>:colorscheme
>
>

I have: blue, darkblue, default, delek, desert, elflord, evening,
industry, koehler, morning, murphy, pablo, peachpuff, ron, shine, slate,
torte, and zellner.

No comment.

Re: Maximum time for offline updates?

[debian-user]

Yvan Masson wrote:

[snip]
> 
> Indeed, in a perfect setup, system should make a snapshot before
> updates are applied (see 6. in systemd.offline-updates manpage, note
> that I have not heard it is done yet by any distribution by default),
> and revert the changes if the update fails. Anyway, being able to fix
> a system that has been broken by *online* updates is only relevant if
> the user has technical skills to do so.
> 
openSUSE does that by default, assuming you use their recommended
filesystem of btrfs. The snapper program takes a snapshot before any
update and again afterwards.

[snip]

Re: colorscheme in vi

[Curt]

On 2022-12-23, Nate Bargmann  wrote:
>
>> Because there is no colorscheme named "white" in Debian's
>> vim. The colorschemes are in /usr/share/vim/vim82/colors
>
> The problem as I see it is that he wants reverse colors in 'vi' but
> edited '.vimrc'.  Historically those are two different programs but the
> Debian alternatives eventually points 'vi' to 'vim.basic'.  I would
> presume that a setting that works in historic 'vi' might not be
> supported by 'vim.basic'.

You'd think it would be more a question of the terminal.

> - Nate
>

Re: colorscheme in vi

[Thomas Schmitt]

Hi,

Curt wrote:
> You'd think it would be more a question of the terminal.

I myself am living happily with
  :syntax off

This reduces the flippy-colorful appearance of vim to what i have chosen
as -bg and -fg of my xterms.


Have a nice day :)

Thomas

Re: colorscheme in vi

[Nate Bargmann]

* On 2022 23 Dec 13:03 -0600, Curt wrote:
> On 2022-12-23, Nate Bargmann  wrote:
> >
> >> Because there is no colorscheme named "white" in Debian's
> >> vim. The colorschemes are in /usr/share/vim/vim82/colors
> >
> > The problem as I see it is that he wants reverse colors in 'vi' but
> > edited '.vimrc'.  Historically those are two different programs but the
> > Debian alternatives eventually points 'vi' to 'vim.basic'.  I would
> > presume that a setting that works in historic 'vi' might not be
> > supported by 'vim.basic'.
> 
> You'd think it would be more a question of the terminal.

That would certainly be another avenue provided the 'vi' program
respects those settings.  I don't think Vim does as it applies the
colorscheme and the background settings or their defaults.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: colorscheme in vi

[Curt]

On 2022-12-23, Nate Bargmann  wrote:
>
>> >
>> > The problem as I see it is that he wants reverse colors in 'vi' but
>> > edited '.vimrc'.  Historically those are two different programs but the
>> > Debian alternatives eventually points 'vi' to 'vim.basic'.  I would
>> > presume that a setting that works in historic 'vi' might not be
>> > supported by 'vim.basic'.
>>=20
>> You'd think it would be more a question of the terminal.
>
> That would certainly be another avenue provided the 'vi' program
> respects those settings.  I don't think Vim does as it applies the
> colorscheme and the background settings or their defaults.

Inside vim:

 :highlight Normal ctermfg=black ctermbg=white

The background's more light gray than white, though (but if it were
white, you wouldn't be able to see the white cursor).

So now we need a black cursor, maybe (left as an exercise).

> - Nate
>

Gnome/Kde color correction

[Erwan David]

Hello,

I have colord-kde installed, in the system settoings I get

"You need Gnome Color Management installed in order to calibrate devices"


Which package should I install ?


I already have

ii  colord 1.4.6-2.1    amd64    system 
service to manage device colour profiles -- system daemon
ii  colord-data    1.4.6-2.1    all  system 
service to manage device colour profiles -- data files
ii  colord-kde 22.12.0-1    amd64    Color 
management for KDE
ii  colord-sensor-argyll   1.4.6-2.1    amd64    system 
service to manage device colour profiles -- argyll sensor plugin
ii  elpa-color-theme-modern    0.0.3-3  all  deftheme 
reimplementation of classic Emacs color-themes
ii  fonts-noto-color-emoji 2.038-1  all  color emoji 
font from Google
ii  gnome-color-manager    3.36.0-1+b1  amd64    Color 
management integration for the GNOME desktop environment


(so yes, gnome-color-manager is installed)

Re: colorscheme in vi

[Pierre Frenkiel]

On Fri, 23 Dec 2022, Curt wrote:


On 2022-12-23, Nate Bargmann  wrote:



Because there is no colorscheme named "white" in Debian's
vim. The colorschemes are in /usr/share/vim/vim82/colors


The problem as I see it is that he wants reverse colors in 'vi' but
edited '.vimrc'.  Historically those are two different programs but the
Debian alternatives eventually points 'vi' to 'vim.basic'.  I would
presume that a setting that works in historic 'vi' might not be
supported by 'vim.basic'.


You'd think it would be more a question of the terminal.


- Nate

for me,  the colorschemes are in /usr/share/vim/vim90/colors,
but it's difficult to make more confusing:
if I put in .vimrc "colorscheme white" or any unknown color (qwert for example)
I get a message "cannot find colorscheme xxx", but I have  black on white
characters with vim.
if I put a known color (blue for example), I have no message, but I get
white on black characters.
to get rid of the message, I replaced the vi binary by a script where
stderr is redirected to /dev/null

Re: Maximum time for offline updates?

[Yvan Masson]

For those interested, I reported this upstream: 
https://github.com/PackageKit/PackageKit/issues/590


Yvan


OpenPGP_signature
Description: OpenPGP digital signature

Re: colorscheme in vi

[Lee]

On 12/23/22, Thomas Schmitt wrote:
> Hi,
>
> Curt wrote:
>> You'd think it would be more a question of the terminal.
>
> I myself am living happily with
>   :syntax off
>
> This reduces the flippy-colorful appearance of vim to what i have chosen
> as -bg and -fg of my xterms.

I used to agree with you about the flippy colors but then I tried
  https://github.com/egberts/vim-syntax-bind-named
and it is _so_ much easier editing a bind RPZ file with syntax errors
highlighted (unless your eyesight is good enough to easily tell the
difference between a comma and a period .. then maybe not so much
better)
and a happy extra is that editing other types of files is also easier
with syntax coloring .. but again, maybe I think it's better because
of my poor eyesight

Regards,
Lee

Re: loss of screen resolution, part 2

[gene heskett]

On 12/20/22 12:27, Kleene, Steven (kleenesj) wrote:

On Monday, December 19, 2022 9:12 PM, I wrote:

Today I have my new desktop and did a clean install of Bullseye.  I call fvwm
with startx, and once again my screen is 1024x768.


On Monday, December 19, 2022 9:49 PM, Timothy M Butterworth wrote:

Newer Intel graphics require closed source binary blobs. Try installing
firmware-linux-nonfree.


I did that and am still stuck.  Thanks for the suggestion.

On Monday, December 19, 2022 10:29 PM, Felix Miata  
replied:

Cardinal rule of PC shopping for use with Linux, unless you are a Linux
developer:
   Make sure the major PC components are several months or more older than
   your selected distro's original release date.


I've heard that rule often but trusted a local friend who's built many Linux
machines to build mine.  I've used *ix for 40 years but never assembled the
hardware.  And here I am.


To use Bullseye, at the least you need either a backport kernel containing
Alder Lake support, or Bookworm (Testing) or Sid (Unstable).


I'll try Testing and, if that fails, maybe an add-on graphics card.  Thanks.

On Tuesday, December 20, 2022 2:47 AM, Bret Busby  wrote:

Perhaps, it would be worthwhile, to download and try a Linux Mint live iso,


Thank you.  I hope to stick with Debian but will keep this in mind.



Another possibility comes to mind because there are cheap one way cables 
out there, just waiting to snag some shekels from the relatively new 
bee.  So you might be able to get the get-edid to work with a different 
cable that is all there for 2 way traffic. There is also the possibility 
the monitor is too old to have an edid response but that is only a 
suspect if it is over a decade old.


On Tuesday, December 20, 2022 10:36 AM, Max Nikulin wrote:Or 

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid

Thanks.  get-edid doesn't find any EDIDs, and there are no edid files under
/sys/devices.


From: Max Nikulin 
Sent: Tuesday, December 20, 2022 10:36 AM
To: debian-user@lists.debian.org
Subject: Re: loss of screen resolution, part 2

External Email: Use Caution


On 20/12/2022 09:49, Timothy M Butterworth wrote:

Newer Intel graphics require closed source binary blobs. Try installing
firmware-linux-nonfree.


In the previous thread somebody spotted an issue with fetching modes
supported by the monitor. Examples of commands to debug such problem:

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid


.


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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: loss of screen resolution, part 2

[gene heskett]

On 12/21/22 03:37, to...@tuxteam.de wrote:

On Tue, Dec 20, 2022 at 05:26:06PM +, Kleene, Steven (kleenesj) wrote:

[...]


On Tuesday, December 20, 2022 10:36 AM, Max Nikulin wrote:

get-edid | parse-edid
edid-decode /sys/class/drm/card0-HDMI-A-1/edid

Thanks.  get-edid doesn't find any EDIDs, and there are no edid files under
/sys/devices.


Could it just be that the microcontroller (in the display)
responsible for providing the EDID is dead?

Cheers


That, Tomas,  depending on how old the purchase receipt is, should be 
grounds for returning it for credit against one that works.


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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: no sound after installing pulseaudio

[Joe B]

What worked for me was running alsamixer from the terminal and unmuteing the 
main control and turning the volume all the way up. rebooted then tested with 
pavucontrol..

Hope this helps

> On Dec 23, 2022, at 5:42 AM, lou  wrote:
> 
> Christoph, your "pactl list" command didn't work because i didn't reboot 
> buster after installing pulseaudio, Thanks anyway!
> 
> 

Dell CMOS Setup -> System Configuration -> SATA Operation -> RAID On vs AHCI

[David Christensen]

debian-user:

I have a SanDisk Ultra Fit USB 3.0 16 GB flash drive with Debian 
installed on it EUFI, GPT, and Secure Boot.  I use it for maintenance/ 
trouble-shooting on newer computers.



When I boot the flash drive in a Dell Precision 3630 Tower that has 
Windows 11 Pro installed on the internal NVMe drive, the internal PCIe 
NVMe drive is not visible to Linux:


2022-12-23 19:16:13 root@bullseye ~
# cat /etc/debian_version ; uname -a
11.5
Linux bullseye 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) 
x86_64 GNU/Linux


2022-12-23 19:17:48 root@bullseye ~
# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda  8:01 14.9G  0 disk
|-sda1   8:11  953M  0 part  /boot/efi
|-sda2   8:21  954M  0 part  /boot
|-sda3   8:31  954M  0 part
| `-sda3_crypt 254:10  954M  0 crypt [SWAP]
`-sda4   8:41 11.2G  0 part
  `-sda4_crypt 254:00 11.2G  0 crypt /
sr0 11:01 1024M  0 rom

2022-12-23 19:19:24 root@bullseye ~
# l /dev/n*
/dev/null  /dev/nvram

/dev/net:
./  ../  tun


STFW I see that the 'nvme' kernel module must be loaded.  Doing so does 
not resolve the issue:


2022-12-23 19:17:51 root@bullseye ~
# modprobe nvme

2022-12-23 19:19:17 root@bullseye ~
# lsmod | grep nvme
nvme   49152  0
nvme_core 131072  1 nvme
t10_pi 16384  2 sd_mod,nvme_core

2022-12-23 19:19:21 root@bullseye ~
# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda  8:01 14.9G  0 disk
|-sda1   8:11  953M  0 part  /boot/efi
|-sda2   8:21  954M  0 part  /boot
|-sda3   8:31  954M  0 part
| `-sda3_crypt 254:10  954M  0 crypt [SWAP]
`-sda4   8:41 11.2G  0 part
  `-sda4_crypt 254:00 11.2G  0 crypt /
sr0 11:01 1024M  0 rom

2022-12-23 18:46:19 root@laalaa ~/laalaa.tracy.holgerdanske.com
# l /dev/n*
/dev/null  /dev/nvram

/dev/net:
./  ../  tun


The work-around is to change CMOS Setup -> System Configuration -> SATA 
Operation from "RAID On: to "AHCI".  The problem is that Windows needs 
the former and it is a hassle to change the CMOS settings back and forth 
every time I want to run Debian.  If I change it to AHCI and forget to 
change it back, Windows breaks.  If and when I make this mistake on a 
client computer, it will be very embarrassing.  I want a portable Debian 
on a USB flash drive or USB SSD to work on newer computers without 
changing the CMOS settings that the factory set for Windows.



Comments or suggestions?


David

Re: Dell CMOS Setup -> System Configuration -> SATA Operation -> RAID On vs AHCI

[Jeffrey Walton]

On Fri, Dec 23, 2022 at 10:29 PM David Christensen
 wrote:
>
> debian-user:
>
> I have a SanDisk Ultra Fit USB 3.0 16 GB flash drive with Debian
> installed on it EUFI, GPT, and Secure Boot.  I use it for maintenance/
> trouble-shooting on newer computers.
>
>
> When I boot the flash drive in a Dell Precision 3630 Tower that has
> Windows 11 Pro installed on the internal NVMe drive, the internal PCIe
> NVMe drive is not visible to Linux:
>
> 2022-12-23 19:16:13 root@bullseye ~
> # cat /etc/debian_version ; uname -a
> 11.5
> Linux bullseye 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21)
> x86_64 GNU/Linux
>
> 2022-12-23 19:17:48 root@bullseye ~
> # lsblk
> NAME   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
> sda  8:01 14.9G  0 disk
> |-sda1   8:11  953M  0 part  /boot/efi
> |-sda2   8:21  954M  0 part  /boot
> |-sda3   8:31  954M  0 part
> | `-sda3_crypt 254:10  954M  0 crypt [SWAP]
> `-sda4   8:41 11.2G  0 part
>`-sda4_crypt 254:00 11.2G  0 crypt /
> sr0 11:01 1024M  0 rom
>
> 2022-12-23 19:19:24 root@bullseye ~
> # l /dev/n*
> /dev/null  /dev/nvram
>
> /dev/net:
> ./  ../  tun
>
>
> STFW I see that the 'nvme' kernel module must be loaded.  Doing so does
> not resolve the issue:
>
> 2022-12-23 19:17:51 root@bullseye ~
> # modprobe nvme
>
> 2022-12-23 19:19:17 root@bullseye ~
> # lsmod | grep nvme
> nvme   49152  0
> nvme_core 131072  1 nvme
> t10_pi 16384  2 sd_mod,nvme_core
>
> 2022-12-23 19:19:21 root@bullseye ~
> # lsblk
> NAME   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
> sda  8:01 14.9G  0 disk
> |-sda1   8:11  953M  0 part  /boot/efi
> |-sda2   8:21  954M  0 part  /boot
> |-sda3   8:31  954M  0 part
> | `-sda3_crypt 254:10  954M  0 crypt [SWAP]
> `-sda4   8:41 11.2G  0 part
>`-sda4_crypt 254:00 11.2G  0 crypt /
> sr0 11:01 1024M  0 rom
>
> 2022-12-23 18:46:19 root@laalaa ~/laalaa.tracy.holgerdanske.com
> # l /dev/n*
> /dev/null  /dev/nvram
>
> /dev/net:
> ./  ../  tun
>
>
> The work-around is to change CMOS Setup -> System Configuration -> SATA
> Operation from "RAID On: to "AHCI".  The problem is that Windows needs
> the former and it is a hassle to change the CMOS settings back and forth
> every time I want to run Debian.  If I change it to AHCI and forget to
> change it back, Windows breaks.  If and when I make this mistake on a
> client computer, it will be very embarrassing.  I want a portable Debian
> on a USB flash drive or USB SSD to work on newer computers without
> changing the CMOS settings that the factory set for Windows.
>
> Comments or suggestions?

The NVMe is provisioned to the Intel Optane accelerator. Optane takes
a small but fast NVMe, and combines it with a slow HDD, and makes the
system (kind of) perform like there's one large SSD.

The NVMe drive should not appear as a seperate drive when it is
provisioned for Optane.

I'm running Kubuntu on a Dell XPS 8930 that came preinstalled with
Windoze. It also had the Optane acceleration. I had to disable Optane
to get access to the NVMe. Once Optane was broken I was able to load
the OS on the NVMe, and make the HDD a large storage/scratch drive.

Jeff