Re: Debian home page -> Download link broken:

[David Wright]

On Mon 12 Jun 2023 at 19:26:41 (-0400), The Wanderer wrote:
> On 2023-06-12 at 18:55, David Wright wrote:
> > On Sun 11 Jun 2023 at 19:18:15 (-0400), The Wanderer wrote:
> >> On 2023-06-11 at 17:36, David Wright wrote:
> 
> >>> There are several sources:
> > 
> > [ snipped the back and forth ]
> > 
> > I'm sorry, but I just can't take seriously your not being acquainted
> > with the term "release".
> 
> Please don't put words in my mouth. Of course I'm familiar with that
> term. I just don't think of it when updating, perhaps in part because I
> update routinely when a release has not happened.

I was surprised; sorry to exaggerate.

> Either blocking updates which would change this information protects
> against something, or it doesn't.
> 
> This is the only meaningful thing that I can think of that it could be
> protecting against, aside from cases where people didn't realize that
> what they were using was a symbolic name.
> 
> If it does meaningfully protect against something that applies in my
> case, then I want to retain that protection. If it doesn't, then that's
> one less argument for why it should be done at all.

Perhaps one way to deal with this is to modify your earlier alias
suggestion to   alias apt-get-change 'apt-get --allow-releaseinfo-change'
which has no effect during normal use, but allows you to circumvent
the problem when you next encounter the error message.

> I think this just reflects how wide the gap between the way you think
> about these things and the way I think about these things is.

I guess so; takes all sorts.

> As before, however, every time I've tried to put a reason why - or an
> alternate explanation of my perspective on this, which might make more
> sense - into words, I've run into some kind or another of wall.
> 
> I suppose I should just stop trying to argue for my perspective on these
> mailing lists at all; I can't even remember the last time it went
> anywhere positive, or even necessarily didn't go somewhere unfortunate.

That would be disappointing; I read and keep many of your posts,
and would put misunderstandings down to the lack of nuance in emails,
as opposed to face-to-face conversations; I'd hate to cause any offence.

Cheers,
David.

Re: chromecast: no audio when casting screen

[javibarroso]

Hello, I'm trying to repply to an old thread, not sure if it will work 
(I'm using the link from 
https://lists.debian.org/debian-user/2021/02/msg00394.html openned with 
thunderbird)


*** Old thread ***
I have just find a posible solution

https://www.linuxuprising.com/2020/04/how-to-cast-your-gnome-shell-desktop-to.html?m=1

I will test it in unstable

Regards

El jue., 17 dic. 2020 10:19, Andrea Borgia  escribió:


   Il giorno gio 17 dic 2020 alle ore 07:12 Javier Barroso
ha scritto:


   It is a known issue , see

   https://support.google.com/chromecast/thread/27045993?hl=en


   Great find, thanks for the quick response too :)

*** Current repply ***
Now it is working without any workaround

Regards

Re: "dpkg-reconfigure" dash no longer works

[Linux-Fan]

Darac Marjal writes:



On 10/06/2023 16:08, S M wrote:

On Sat, Jun 10, 2023 at 02:12:14PM +0100, Darac Marjal wrote:


Is command-line editing part of POSIX, then? Are you suggesting that dash is
missing some bit of POSIX compliance? That's possible.
Command-line editing in vi-mode is defined by POSIX, but it's not mandatory  
as

far as I know.

OK, this looks like Bug #561663. If I read that bug correctly, the intention  
IS that dash should support command-line editing (in your case, you'd invoke  
it with -V for vi-style editing. The maintainer claimed the block was  
closed, but then they re-opened it two days later.


Interesting. I am also one of the niche users interested in running dash as  
a primary shell with vi-style line editing.


Last time I tried it (must be several years ago already), the vi-style  
editing did indeed work when enabled with `set -o vi`. On my current Debian  
oldstable (bullseye) workstation it does not work anymore.


Back when the vi-style editing worked it was _almost_ ready for "productive"  
use. Unfortunately, POSIX shells do not support bash's `\[` and `\]` in  
prompts that can be used to hide color code sequences from being counted  
towards the prompt length. This caused there to be a discrepancy between the  
observed and computed lengths leading to erratic line editing whenever the  
line exteeded the width of the window (happens often for me).


Hence I concluded that while it sounds nice to switch to `sh` as the primary  
shell in theory, this does not quite work in practice (for me anyways).


YMMV
Linux-Fan

öö


pgpHxp9oW5HUx.pgp
Description: PGP signature

bookworm upgrade report

[hans . ullrich]

Hi folks,

upgrade to bookworm went like a charm, but I got into two little issues.

First issue: kdeconnect crashed at any start - thus wondering, because on 
another computer it worked like a charme.

Second issue: Weatjer widget on plasma5 (KDE) did not find any town, but on 
another computer it worked well.

Third issue: On my EEEPC the latest kernel did not boot every time, sometimes 
it did, sometimes not (just hanged with a blank screen). The older 5.10-kernel 
always started.

Solution for all issues: As my systems are installed a long time ago, there 
are many libs and packages, which I used, but which are orphaned now (about 
240 packages roundabout here). After deinstalling all of them ( I used 
aptitude for this, there is a special section for orphaned packages), 
everything worked fine.

Note: apt autoremove does NOT do the trick!
Second note: apt purge `deborphan --guess-all`might uninstall packages or 
libs, you might want or need to keep, so it also does not the trick.

I did uninstall ell manually.

Just to give someone a hint, if something after upgrade to bookworm did not 
work as expected.

Happy hacking, best

Hans 

Re: bookworm upgrade report: boring

[CL]

Hello,

after two days usage I found a little issue.

I use Brave as browser and want to set here the dark mode.

But it seems that Brave doesn't remember the setting. After every switch 
off / switch on of the system the browser forget the dark setting.


Not a big issue but a little bit irritating.


Don't know if this is a problem of Bookworm or Brave.

---
mit freundlichen Grüßen / Best Regards

**Christian Lorenz**

mailto:cl.debian.mail...@t-online.de
---

Am 11.06.23 um 21:05 schrieb CL:

Hello,

can confirm the statement of Dan.

Just did an upgrade Bullseye -> Bookworm at two computer.

1. Lenovo V340-17IWL

XFCE Desktop

used as daily driver


2. NUC Kit DC53427HYE

XFCE Desktop

but used as server for a Nextcloud instance

general connetion via ssh


Both upgrades run smoothly and without any problems.

Only topic was the restart of the Nextcloud. They don't wanted the 
standard PHP 8.2.

Solution was a downgrade to PHP8.0

Until now no problems

Re: bookworm upgrade report: boring

[CL]

Hello,

Docker might be different. I don't use it yet - Not enough knowledge and 
a little bit afraid ;-)


I use a direct installation. Therfore this issue.

But as I already said no problem after the "downgrade".


---
mit freundlichen Grüßen / Best Regards

**Christian Lorenz**

mailto:cl.debian.mail...@t-online.de
---

Am 12.06.23 um 19:52 schrieb Celejar:

On Sun, 11 Jun 2023 21:05:32 +0200
CL  wrote:


...


Only topic was the restart of the Nextcloud. They don't wanted the
standard PHP 8.2.
Solution was a downgrade to PHP8.0


That's unusual - Debian Stable having too *recent* software :|

FWIW, I upgraded my Debian Stable Nextcloud (26.02 via Docker) server
to Bookworm without trouble. Nextcloud is using PHP 8.2.6, but the
Docker containers seem to be providing their own PHP, since I haven't
installed any native PHP packages. This is one reason it can be nice to
run software not in the repositories via Docker.

Re: bookworm upgrade report: boring

[Nate Bargmann]

* On 2023 13 Jun 10:01 -0500, Vincent Lefevre wrote:
> On 2023-06-13 06:41:41 -0500, Nate Bargmann wrote:
> > I've been experimenting with Arch Linux for some time and one thing I
> > like about its pacman package management system is that it has a tool
> > available named 'pacdiff'.  The details are off topic but in a nutshell
> > what it does is identify a locally modified config and the corresponding
> > new config files and can open them in 'vimdiff' giving a nice display of
> > the diff using the vim editor.  Once the editing is complete there is a
> > final step to discard the new config file or replace the current one
> > with it.  I do like that Debian retains the new file with various file
> > name extensions for future reference.
> > 
> > I know that apt allows for viewing a unified diff of the files, but it
> > has been quite some time since I've been presented with that menu that I
> > don't recall if editing based on the diff is an option.  It certainly
> > seems that calling vimdiff in that situation would be quite easy but I
> > realize that not many are comfortable with vim and would want a more
> > universal editor that I might not like.
> 
> This is not apt, but dpkg, which is rather limited:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=32877
> 
> (yes, 1999).

Apparently no developer interest.

> Some packages offer a 3-way merge, which is very useful. I think that
> in this case, the configuration file handling is done via ucf (the
> possibility of a merge is mentioned in its man page).

I have always chickened out on that option.  Looking at the ucf man page
and the description of the three-way merge it looks like the user would
have a yes or no option but no edit option.

I just completed upgrading my Lenovo T-410 laptop to Bookworm and the
only issue was a broken neovim package (I forgot I even had it
installed).  It needed a new runtime package installed as a dependency
so I had to use 'apt --fix-broken install' for the first time ever in
the nearly 24 years of using Debian.  That's an impressive track record.
However, I don't have any system that has done an in-place upgrade
throughout that time.  This laptop was originally installed when Buster
was Testing in late 2018.

My only real concern was the upgrade of Gnu Cash and that appears to
have been flawless (yes, I have off-site backups).

I've already had experience with GNOME 43 from an Arch Linux
installation on another laptop so the changes aren't too massive for me.
I do wonder how things will work with my dual-head desktop as I use an
extension to have separate workspaces on each monitor.  One of these days
I'll feel brave...

- 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

bookworm display power management issue

[Scott Lair]

Since upgrading to bookworm I'm having a display power management issue. I am 
using XFCE. Setting the display
power management slider to blank after 5 minutes does indeed blank the display. 
However, every 30 seconds or 
so the monitor comes back on, then simply displays no signal and goes back off 
again. This repeats every 
30 seconds or so. I am getting the same behaviour in MATE as well, so it's not 
unique to XFCE. The machine in
question is an HP Elitedesk 800 G3 with intel graphics. It did not have this 
issue on debian 11.

Looking for ideas on how to diagnose and fix.

thanks,

Scott 

Re: bookworm upgrade report: boring

[Celejar]

On Tue, 13 Jun 2023 16:46:36 +0200
Vincent Lefevre  wrote:

> On 2023-06-12 13:33:02 -0400, Celejar wrote:
> > Often, but apparently not always. For example, on one of my upgrades,
> > the old sshd_config had:
> > 
> > **
> > # Change to yes to enable challenge-response passwords (beware issues with
> > # some PAM modules and threads)
> > ChallengeResponseAuthentication no
> > **
> > 
> > whereas the new one had:
> > 
> > **
> > # Change to yes to enable challenge-response passwords (beware issues with
> > # some PAM modules and threads)
> > KbdInteractiveAuthentication no
> > **
> 
> In the /usr/share/doc/openssh-server/changelog.Debian.gz file:
> 
> openssh (1:8.7p1-1) unstable; urgency=medium
> [...]
> - ssh(1)/sshd(8): remove references to ChallengeResponseAuthentication
>   in favour of KbdInteractiveAuthentication. The former is what was in
>   SSHv1, the latter is what is in SSHv2 (RFC4256) and they were treated
>   as somewhat but not entirely equivalent. We retain the old name as a
>   deprecated alias so configuration files continue to work as well as a
>   reference in the man page for people looking for it.

Thanks.

> > Is this important?
> 
> If the alias is still there, this is not important. Otherwise, either
> the option could be ignored (so you get the default), possibly with a
> warning, or there could be a fatal error (but you would have noticed
> it); I don't know how sshd behaves in case of an unknown option.
> 
> But in any case, I would recommend to update the config.

That's indeed what I did.

> > What would have happened had I left the old version,
> > as opposed to switching to the new version? Presumably nothing, since
> > I'm using the safer default setting in either case, and I suppose I
> > could have taken the time to track down the change and its
> > implications, but running into these types of situations while
> > upgrading can be disconcerting.
> > 
> > > and reject the package version offered. Less stressful and speeds up
> > > the installation. If necessary, I investigate afterwards.
> > 
> > This is probably the logical thing to do, but I'm always worried that
> > there may be new settings that should be set, and so on.
> 
> I always look at the diffs (I track all the config files I modify),
> and sometimes at the logs too. In general, I do some kind of merge.

This is of course the responsible thing to do - my point was that these
types of situations can make upgrading not quite as boring as the OP's
experience :)

-- 
Celejar

Re: bookworm upgrade report: boring

[Vincent Lefevre]

On 2023-06-13 06:41:41 -0500, Nate Bargmann wrote:
> I've been experimenting with Arch Linux for some time and one thing I
> like about its pacman package management system is that it has a tool
> available named 'pacdiff'.  The details are off topic but in a nutshell
> what it does is identify a locally modified config and the corresponding
> new config files and can open them in 'vimdiff' giving a nice display of
> the diff using the vim editor.  Once the editing is complete there is a
> final step to discard the new config file or replace the current one
> with it.  I do like that Debian retains the new file with various file
> name extensions for future reference.
> 
> I know that apt allows for viewing a unified diff of the files, but it
> has been quite some time since I've been presented with that menu that I
> don't recall if editing based on the diff is an option.  It certainly
> seems that calling vimdiff in that situation would be quite easy but I
> realize that not many are comfortable with vim and would want a more
> universal editor that I might not like.

This is not apt, but dpkg, which is rather limited:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=32877

(yes, 1999).

Some packages offer a 3-way merge, which is very useful. I think that
in this case, the configuration file handling is done via ucf (the
possibility of a merge is mentioned in its man page).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: bookworm upgrade report: boring

[Vincent Lefevre]

On 2023-06-12 13:33:02 -0400, Celejar wrote:
> Often, but apparently not always. For example, on one of my upgrades,
> the old sshd_config had:
> 
> **
> # Change to yes to enable challenge-response passwords (beware issues with
> # some PAM modules and threads)
> ChallengeResponseAuthentication no
> **
> 
> whereas the new one had:
> 
> **
> # Change to yes to enable challenge-response passwords (beware issues with
> # some PAM modules and threads)
> KbdInteractiveAuthentication no
> **

In the /usr/share/doc/openssh-server/changelog.Debian.gz file:

openssh (1:8.7p1-1) unstable; urgency=medium
[...]
- ssh(1)/sshd(8): remove references to ChallengeResponseAuthentication
  in favour of KbdInteractiveAuthentication. The former is what was in
  SSHv1, the latter is what is in SSHv2 (RFC4256) and they were treated
  as somewhat but not entirely equivalent. We retain the old name as a
  deprecated alias so configuration files continue to work as well as a
  reference in the man page for people looking for it.

> Is this important?

If the alias is still there, this is not important. Otherwise, either
the option could be ignored (so you get the default), possibly with a
warning, or there could be a fatal error (but you would have noticed
it); I don't know how sshd behaves in case of an unknown option.

But in any case, I would recommend to update the config.

> What would have happened had I left the old version,
> as opposed to switching to the new version? Presumably nothing, since
> I'm using the safer default setting in either case, and I suppose I
> could have taken the time to track down the change and its
> implications, but running into these types of situations while
> upgrading can be disconcerting.
> 
> > and reject the package version offered. Less stressful and speeds up
> > the installation. If necessary, I investigate afterwards.
> 
> This is probably the logical thing to do, but I'm always worried that
> there may be new settings that should be set, and so on.

I always look at the diffs (I track all the config files I modify),
and sometimes at the logs too. In general, I do some kind of merge.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: bookworm upgrade report: boring

[Vincent Lefevre]

On 2023-06-12 18:00:58 +0100, Joe wrote:
> Yes. I run a fairly customised exim4, and during one upgrade, I think
> either to or from etch, I kept my configuration, and it broke the exim4
> installation. Exim4 was unconfigured, so it wouldn't run, but
> dpkg-reconfigure couldn't work either. Even a purge wouldn't enable
> reinstallation, and I had to resort to manually deleting files.

What files? If these are files under directories like /etc or
/usr/local (where the user can put his one things), this is not
normal, and I suppose that a bug should be reported. Otherwise,
this is not surprising.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RTL8812au support for wifi adapters

[Stefan Monnier]

> I have a PC that uses a Wi-Fi adapter TP-Link 725N which uses the rtl8812au
> driver. This is not an included driver on the installation to work out of
> the box. The way to install it in previous versions (kernel 5.+) was to
> router 4G connection from my smartphone to the bluetooth receiver, perform
> an “apt update”, “apt install dkms”, “git clone 'the rtl8812au driver’” and
> “dkms_install” the driver in my machine, wich took a very long time because
> of the poor bluetooth connection. In Debian 12 this method fails because
> after dkms_install there is an error regarding the Kernel 6.+: “Error! Your
> kernel headers for kernel … 6.1.0 cannot be found”. 
>
> It is very difficult to overcome this problem when I don’t have internet
> connnection and from what I’ve read, this is a widely used driver for
> several adapters from TP-Link. 

Here's what I think I'd do:
- boot with the old 5.+ kernel
- install the 6.1.0 kernel headers
- install dkms and the driver
- reboot using the new kernel


Stefan

Re: RTL8812au support for wifi adapters

[Charles Curley]

On Tue, 13 Jun 2023 09:20:46 -0300
Mateus Arruda  wrote:

> Hi, this is my first time reaching a Linux distribution team and also
> english is not my primary language, so please forgive me if I make
> any mistakes.

No worries. Although you may do better on a list for your primary
language. See https://lists.debian.org and
https://lists.debian.org/completeindex.html.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: RTL8812au support for wifi adapters

[Bret Busby]

On 13/6/23 20:20, Mateus Arruda wrote:

Hi, this is my first time reaching a Linux distribution team and also english 
is not my primary language, so please forgive me if I make any mistakes.

I have a PC that uses a Wi-Fi adapter TP-Link 725N which uses the rtl8812au 
driver. This is not an included driver on the installation to work out of the 
box. The way to install it in previous versions (kernel 5.+) was to router 4G 
connection from my smartphone to the bluetooth receiver, perform an “apt 
update”, “apt install dkms”, “git clone 'the rtl8812au driver’” and 
“dkms_install” the driver in my machine, wich took a very long time because of 
the poor bluetooth connection. In Debian 12 this method fails because after 
dkms_install there is an error regarding the Kernel 6.+: “Error! Your kernel 
headers for kernel … 6.1.0 cannot be found”.

It is very difficult to overcome this problem when I don’t have internet 
connnection and from what I’ve read, this is a widely used driver for several 
adapters from TP-Link.

With all that said, my contact is to request the inclusion of rtl8812au driver 
in the installation image so we don’t need to install it by workarounds.

I don’t expect to get a response, but if someone from Debian team reads this, 
thank you for your time and support.

Best regards,

Mateus



I have had problems with realtek wifi drivers on installations, and, 
instead of using bluetooth (I disable bluetooth on all of my computers), 
I did it by using USB tethering to my cellphone, to provide the Internet 
connection, with my cellphone having direct Internet access, in its own 
right, in addition to my 4G wifi modem/routers.


Does your cellphone have direct Internet access, and USB tethering 
functionality?


Also, which desktop environment are you using, and, does it have a GUI 
utility that deals with hardware drivers?


For example, I use the Mate desktop environment, which includes the 
Control Center, with has Administration -> Driver Manager, and, using 
that, in conjunction with the USB tethering to my cellphone, and, the 
direct Internet access of my cellphone, make actions like installing 
hardware drivers, such as the applicable Realtek wifi drivers, pretty 
much, a "plug and play" operation, with the wifi device on one of my 
computers, being a wifi dongle, that uses (possibly the same as yours) a 
Realtek wifi system;


"
*-network
   description: Wireless interface
   physical id: 6
   bus info: usb@3:14
   logical name: wlx90de8039844b
   serial: 90:de:80:39:84:4b
   capabilities: ethernet physical wireless
   configuration: broadcast=yes driver=rtl8821cu 
driverversion=5.15.0-73-generic ip=192.168.1.105 multicast=yes 
wireless=IEEE 802.11AC

"

Okay - for this computer (the one that has the wifi USB dongle), it is
"driver=rtl8821cu"
- yours has the "au" rather than the "cu" suffix, but, depending on 
whether the equipment (including your desktop environment and your 
cellphone) has the same functionality, you should be able to install the 
driver for your wifi adaptor, similarly easily.


..
Bret Busby
Armadale
West Australia
(UTC+0800)
..

RTL8812au support for wifi adapters

[Mateus Arruda]

Hi, this is my first time reaching a Linux distribution team and also english 
is not my primary language, so please forgive me if I make any mistakes.

I have a PC that uses a Wi-Fi adapter TP-Link 725N which uses the rtl8812au 
driver. This is not an included driver on the installation to work out of the 
box. The way to install it in previous versions (kernel 5.+) was to router 4G 
connection from my smartphone to the bluetooth receiver, perform an “apt 
update”, “apt install dkms”, “git clone 'the rtl8812au driver’” and 
“dkms_install” the driver in my machine, wich took a very long time because of 
the poor bluetooth connection. In Debian 12 this method fails because after 
dkms_install there is an error regarding the Kernel 6.+: “Error! Your kernel 
headers for kernel … 6.1.0 cannot be found”. 

It is very difficult to overcome this problem when I don’t have internet 
connnection and from what I’ve read, this is a widely used driver for several 
adapters from TP-Link. 

With all that said, my contact is to request the inclusion of rtl8812au driver 
in the installation image so we don’t need to install it by workarounds. 

I don’t expect to get a response, but if someone from Debian team reads this, 
thank you for your time and support. 

Best regards,

Mateus

Re: bookworm upgrade report: not so boring (was: boring)

[Reco]

Hi.

On Sun, Jun 11, 2023 at 12:31:31PM -0400, Dan Ritter wrote:
> The machine I am typing on has been upgraded from bullseye to
> bookworm. TL;DR: boring, which is good.

My experience is somewhat different.

1) NTP was replaced by NTPsec.

Not that I oppose the change, but 'ntpq -nc peers localhost' just
hangs after the upgrade.
Solved by replacing NTPsec with chrony (where I need )


2) Exim started tainting macro arguments in transports' configuration.

Broke my custom transports (aka mail delivery), but was easy to fix.


3) Kernel size has increased, again.

This time it bricked one of my armhf boards, just because NAND partition
has 5MB limit. It was time to decommission this particular hardware
anyway, but I'll try to work around it.


4) dhcpcd became multi-process monstrosity.

And it's my fault, but a custom apparmor profile caused the thing to
write 6-7 Gb of identical error messages before I saw it.
Note to self - do aa-complain *before* the upgrade, not *after*.


5) systemd-binfmtd fails on boot due to the python 3.11.

But it's nothing that 'systemctl mask' cannot solve.


6) Contrary to my expectations, CUPS, SANE and Strongswan upgrades were
easy.

Although I did not try to use the printer or the scanner after the upgrade.


So, bookworm has an interesting beginning, to say the least. Certainly
more interesting than buster->bullseye upgrade.

Reco

Re: bookworm upgrade report: boring

[Nate Bargmann]

* On 2023 12 Jun 07:51 -0500, Celejar wrote:
> On Sun, 11 Jun 2023 12:31:31 -0400
> Dan Ritter  wrote:
> > Everything's working. In the end, I didn't make any config
> > changes (left everything as "keep current config").
> 
> This is the part that always stresses me out; I often have changes in
> the default config files that I don't want to lose, but I'm also
> worried about not getting the latest versions of the config files. I
> usually try to accept the new files and manually bring in any important
> changes I've made to the old ones, but this takes time and patience to
> do right, and things can break if not done right :)

I've been experimenting with Arch Linux for some time and one thing I
like about its pacman package management system is that it has a tool
available named 'pacdiff'.  The details are off topic but in a nutshell
what it does is identify a locally modified config and the corresponding
new config files and can open them in 'vimdiff' giving a nice display of
the diff using the vim editor.  Once the editing is complete there is a
final step to discard the new config file or replace the current one
with it.  I do like that Debian retains the new file with various file
name extensions for future reference.

I know that apt allows for viewing a unified diff of the files, but it
has been quite some time since I've been presented with that menu that I
don't recall if editing based on the diff is an option.  It certainly
seems that calling vimdiff in that situation would be quite easy but I
realize that not many are comfortable with vim and would want a more
universal editor that I might not like.

Typically, if it appears that there are major changes to a config file
then I will install the maintainer's version, note it, and edit it for
needed local changes later.  I've been bitten by keeping all of my local
configs in the past so I don't do that any more.

- 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: Bookworm upgrade, usrmerge failure

[Bastien Durel]

Le lundi 12 juin 2023 à 14:02 -0400, Jeffrey Walton a écrit :
> On Mon, Jun 12, 2023 at 5:48 AM Bastien Durel
>  wrote:
> > 
> > Hello,
> > 
> > During bookworm upgrade, I ran into some usrmerge failures, which
> > led
> > to an hard-to-fix situation
> > 
> > Paramétrage de usrmerge (35) ...
> > 
> > FATAL ERROR:
> > Both /lib/x86_64-linux-gnu/libidn.so.11 and /usr/lib/x86_64-linux-
> > gnu/libidn.so.11 exist.
> > 
> > You can try correcting the errors reported and running again
> > /usr/lib/usrmerge/convert-usrmerge until it will complete without
> > errors.
> > Do not install or update other Debian packages until the program
> > has been run successfully.
> > 
> > E: usrmerge failed.
> > 
> > root@corrin:/root # /usr/lib/usrmerge/convert-usrmerge
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libm.so.6: version
> > `GLIBC_2.29' not found (required by /usr/bin/perl)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.28' not found (required by /usr/bin/perl)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.33' not found (required by /usr/bin/perl)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.34' not found (required by /usr/bin/perl)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.25' not found (required by /lib/x86_64-linux-
> > gnu/libcrypt.so.1)
> > /usr/bin/perl: /lib/x86_64-linux-gnu/libc.so.6: version
> > `GLIBC_2.36' not found (required by /lib/x86_64-linux-
> > gnu/libcrypt.so.1)
> > root@corrin:/root # rm /usr/lib/x86_64-linux-gnu/libidn.so.11
> > Erreur de segmentation (core dumped)
> > root@corrin:/root # ls -l /usr/lib/x86_64-linux-gnu/libidn.so.11
> > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found
> > (required by ls)
> > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found
> > (required by /lib/x86_64-linux-gnu/libselinux.so.1)
> > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not found
> > (required by /lib/x86_64-linux-gnu/libselinux.so.1)
> > ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> > (required by /lib/x86_64-linux-gnu/libselinux.so.1)
> > 
> > As no system tool was usable in this situation (dpkg crashed too),
> > I
> > powered-off the machine and restored it from backup. I then
> > installed
> > usrmerge on bullseye, fixed the problems, then done the bookworm
> > upgrade without any other problems.
> > 
> > As usrmerge is mandatory on bookworm ; and usrmerge failure during
> > upgrade leads to (could lead to ?) big problems ; shouldn't its
> > installation be advised in 4.1 or 4.2 chapters of the upgrade guide
> > ?
> > 
> > I know 5.1.14 says merged-/usr is now required ; but it does not
> > warn
> > about failures, and I don't think I'm the only one who don't read
> > the
> > next chapter before starting upgrade ;)
> 
> I wonder if you have a bunch of stale symlinks...
> 
> Does symlinks report any dangling links for the problem shared
> libraries?
> 
>     sudo symlinks -r / | grep dangling
> 
> If the list of dangling looks safe to clean-up, then you can run
> 
>     sudo symlinks -r -d /
> 
> Jeff
> 

Hello.

I have a bunch of them, here a those in /usr : 

dangling: /usr/bin/rust-llvm-dwp -> llvm-dwp-14
dangling: /usr/bin/clhsdb -> /etc/alternatives/clhsdb
dangling: /usr/bin/rust-lld -> lld-14
dangling: /usr/bin/rust-clang -> clang-14
dangling: /usr/bin/x-terminal-emulator -> /etc/alternatives/x-terminal-emulator
dangling: /usr/bin/hsdb -> /etc/alternatives/hsdb
dangling: /usr/share/phpmyadmin/docs/html -> ../../doc/phpmyadmin/html
dangling: /usr/share/man/man1/policyeditor.1.gz -> 
/etc/alternatives/policyeditor.1.gz
dangling: /usr/share/man/man1/itweb-settings.1.gz -> 
/etc/alternatives/itweb-settings.1.gz
dangling: /usr/share/man/man1/x-terminal-emulator.1.gz -> 
/etc/alternatives/x-terminal-emulator.1.gz
dangling: /usr/share/man/man3/SSL.3ssl.gz -> ssl.3ssl.gz
dangling: /usr/share/man/man3/cerfcf.3.gz -> cerf.3.gz
dangling: /usr/share/man/man3/cerfcl.3.gz -> cerf.3.gz
dangling: /usr/share/man/man3/cerfl.3.gz -> cerf.3.gz
dangling: /usr/share/man/man3/cerff.3.gz -> cerf.3.gz
dangling: /usr/share/pyshared/paste/evalexception/media/MochiKit.packed.js -> 
../../../../javascript/mochikit/MochiKit.js
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-util-buffer.el -> 
/usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-util-buffer.el
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-mode.el -> 
/usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-mode.el
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-mode-autoloads.el 
-> /usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-mode-autoloads.el
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php-project.el -> 
/usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php-project.el
dangling: /usr/share/emacs/site-lisp/elpa/php-mode-1.23.0/php.el -> 
/usr/share/emacs/site-lisp/elpa-src/php-mode-1.23.0//php.el
danglin